Oberon (2009)
ignorethecode.net
Oberon (2009)
1–10 of 149 posts
Re: Oberon (2009)
#2Too bad the link in the article is offline: http://bluebottle.ethz.ch/ and http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads takes forever to load somehow.
Re: Oberon (2009)
#3I remember trying out an Oberon-07 compiler some years back. The speed at which it worked was impressive: it was able to build itself and the standard library modules in a small fraction of a second.
Re: Oberon (2009)
#4I remember trying out an Oberon-07 compiler some years back. The speed at which it worked was impressive: it was able to build itself and the standard library modules in a small fraction of a second.
Pascal family languages parse quickly because they won't let you use anything before it's defined.
Re: Oberon (2009)
#5I remember trying out an Oberon-07 compiler some years back. The speed at which it worked was impressive: it was able to build itself and the standard library modules in a small fraction of a second.
Pascal family languages parse quickly because they won't let you use anything before it's defined.
[deleted]
Re: Oberon (2009)
#6I remember trying out an Oberon-07 compiler some years back. The speed at which it worked was impressive: it was able to build itself and the standard library modules in a small fraction of a second.
Pascal family languages parse quickly because they won't let you use anything before it's defined.
Probably a controversial opinion, but I absolutely wish this was more common. It's a thing in F# as well. With JS/TS projects I always ensure the ESLint rule for only using what's been declared before is enabled.
I don't want to scroll up and down a file constantly when referring to previous things that might reference something at the bottom of the file, which then references something near the top, which then references something in the middle, which then references something at the bottom again... I despise working in that manner.
Re: Oberon (2009)
#7I think tilling WM workflows are more practical than the UI design the article is describing:
>Everything is a Command Line
Tilling WMs naturally favors TUI apps and opening up a quick terminal in which you input text to do your task.
>To launch applications or execute commands, you first type them somewhere and then middle-click them
keybinding meta+d: dmenu-run
>Everything is Zoomable
Tilling WMs with workspaces (or tags) are more efficient than context switching by trying to find the desired window via zooming in and out.
Re: Oberon (2009)
#8> Oberon is very much in active use at ETH Zürich. We used it as one of our main operating systems.
The article being from 2009, this must've been an interesting period for the students, as back then the introductory programming course was using Eiffel, taught by Bertrand Meyer himself.
Re: Oberon (2009)
#9I think tilling WM workflows are more practical than the UI design the article is describing: >Everything is a Command Line Tilling WMs naturally favors TUI apps and opening up a quick terminal in which you input text to do your task. >To launch applications or execute commands, you first type them somewhere and then middle-click them keybinding meta+d: dmenu-run >Everything is Zoomable Tilling WMs with workspaces (o…
> Tiling WMs naturally favors TUI apps
More like: "Tiling window managers only work well with resizable TUI apps" - there's still far too many text-mode programs that assume fixed-size console buffer dimensions (think: software still using ancient versions of ncurses) - also assuming that your chosen terminal emulator is capable of dynamically resizing (and re-flowing) normal stdout text.
Re: Oberon (2009)
#10I remember trying out an Oberon-07 compiler some years back. The speed at which it worked was impressive: it was able to build itself and the standard library modules in a small fraction of a second.
Pascal family languages parse quickly because they won't let you use anything before it's defined.
True, AIUI, but there's a bit more to it than that.
This paper is very readable and talks about Niklaus Wirth's ruthless approach to compiler optimization. https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90...