Oberon was the programming language and environment used to teach first year programming classes at the university of antwerp when I studied there back in the late 90's. I ended up using it as my main programming environment for months at a time. There was a definite learning curve because of the weird mouse approach. They used mouse behavior that I haven't seen anywhere else, like interclicks (chorded mouse button click combinations). Mostly though there were keyboard alternatives, like ctrl-enter for middle click, so you didn't have to have the mouse in hand all the time. Once the learning curve was over I remember finding the keyboard/mouse behavior quite efficient, though you did need a three-button mouse to make full use of it.
I initially had a negative reaction to the clunky appearance of oberon and the weird conventions, but grew to like it quite a bit over the course of the year. It was really a programmer's OS, because there was essentially no difference between documents, programs and user interfaces. You could look at any application and decompose it into its building blocks and program code quite easily because "view source" was an intrinsic part of the system. The downside was that it didn't actually do much, given that there was basically no way to port existing software so it ran inside the oberon environment. Had it somehow gained the ability to run other programming languages than Oberon within the same UI paradigm it might have been quite popular as a geek OS.
Not only that, for me it showed me that it is possible to have operating systems implemented in GC enabled systems programming languages, contrary to what C guys keeping on preaching.
Native Oberon System 3 was quite an improvement with the Gadgets interface.
I think only by experimenting such operating systems, in a similar way to Lisp and Smalltalk machines, one can be convinced of the viability of GC enabled languages at the OS level.
Sadly, most efforts that came after Oberon don't offer much more than a plain CLI, thus reinforcing the common belief that GC enabled systems programming languages are not viable for OS development.
We lost a lot in computing by having just the UNIX/C model as the only one to follow.
Comments
Oberon was the programming language and environment used to teach first year programming classes at the university of antwerp when I studied there back in the late 90's. I ended up using it as my main programming environment for months at a time. There was a definite learning curve because of the weird mouse approach. They used mouse behavior that I haven't seen anywhere else, like interclicks (chorded mouse button click combinations). Mostly though there were keyboard alternatives, like ctrl-enter for middle click, so you didn't have to have the mouse in hand all the time. Once the learning curve was over I remember finding the keyboard/mouse behavior quite efficient, though you did need a three-button mouse to make full use of it.
I initially had a negative reaction to the clunky appearance of oberon and the weird conventions, but grew to like it quite a bit over the course of the year. It was really a programmer's OS, because there was essentially no difference between documents, programs and user interfaces. You could look at any application and decompose it into its building blocks and program code quite easily because "view source" was an intrinsic part of the system. The downside was that it didn't actually do much, given that there was basically no way to port existing software so it ran inside the oberon environment. Had it somehow gained the ability to run other programming languages than Oberon within the same UI paradigm it might have been quite popular as a geek OS.
Not only that, for me it showed me that it is possible to have operating systems implemented in GC enabled systems programming languages, contrary to what C guys keeping on preaching.
Native Oberon System 3 was quite an improvement with the Gadgets interface.
I think only by experimenting such operating systems, in a similar way to Lisp and Smalltalk machines, one can be convinced of the viability of GC enabled languages at the OS level.
Sadly, most efforts that came after Oberon don't offer much more than a plain CLI, thus reinforcing the common belief that GC enabled systems programming languages are not viable for OS development.
We lost a lot in computing by having just the UNIX/C model as the only one to follow.