Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oberon (2009)

ignorethecode.net

Post reply on HN
Print view View original

131–140 of 149 posts

Re: Oberon (2009)

#131

Post by galaxyLogic »

4bpp wrote: post #113
galaxyLogic wrote: post #82

Earlier quoted context omitted.

Instead of zooming I think a better approach is Windows-within-Windows. Or is that the same thing? You don't need to "zoom" so much as "enter" into a sub-desktop. Which is different than multiple desktops side-by-side. Smalltalk had/has this feature. You create a new "project-window". You can then "enter" it and within it you can open any number of windows including project-windows. This works really well with progra…

Up until the mid-2000s, a lot of complex GUI applications (such as Visual Studio 6) in the Windows world used a paradigm somewhat ambiguously named MDI (cf. https://documentation.help/Win32/MDI%20Frames.htm ) which is what you describe sounds like. Unfortunately, UI design/HCI fashions turned against it hard and it went all but extinct; last I checked, few GUI toolkits even support it. Gtk was on the vanguard of the…

I think the MDI was too complicated for most people. Simplicity wins. And wasn't it like an application had to implement it to use it, not part of the OS-GUI by itself?

But Smalltalk "project windows" was and is truly simple. I think you can still check them out in Pharo and/or Squeak.

They are not of much use to casual computer user I think. Their benefit comes when the computer is used to perform complex multi-level tasks like producing software.

Re: Oberon (2009)

#132

Post by pjmlp »

Rochus wrote: post #97
dfawcus wrote: post #92

As I described it to some folks recently, Go can be simply characterised as a slightly stripped version of the Oberon-2 (or Component Pascal) language, recast in a C like syntax, and with a number of small additions. Removed from Oberon-2: Sets, Type Extension (classful OO scheme) Added by Go: Maps, Slices, Strings, Interfaces, Channels, Coroutines. Such that I suggested it is well worth reading the Oberon-2 language…

> Go can be simply characterised as a slightly stripped version of the Oberon-2 Well, not really; there are not much similarities between Oberon and Go besides the receiver syntax of Oberon-2 bound procedures (which was invented by Mössenböck btw) and the fact that both are garbage collected. In your list "removed from Oberon" you should add type inclusion (Go doesn't even have implicit coercion); there is an interse…

And the unsafe vs SYSTEM package, and module initialization.

Re: Oberon (2009)

#133

Post by pjmlp »

Rochus wrote: post #127
tanakian wrote: post #124

Earlier quoted context omitted.

coroutines module comes with Oberon S3 system. also Ulm's Oberon compiler has coroutines module.

Thanks. I don't know the Ulm compiler, and I unfortunately don't have System 3 (can you please provide a link with the source code and/or a working Linux binary?), but I have the source code of V2 and V4 (both ETH and Linz versions, from 1992 to Linz 1.7) where there are no coroutines.

System 3 is packaged as part of Active Oberon.

Re: Oberon (2009)

#134

Post by pjmlp »

mhd wrote: post #77
gtirloni wrote: post #57

Earlier quoted context omitted.

I remember being impressed by Modula-3 back then. I wish it wasn't so difficult to compile the compiler.

Ah, Modula-3, one of my perennial favorites. Definitely a different continuation of Modula-2 than Wirth's own Oberon. Agree on the tooling issues. If it would've "sold" better, so many languages of the last two decades could've been avoided.

This is one of those,I wish D would take more inspiration from, instead Nim, Swift, C# (with post v7 improvements) seem to be the ones more closer to it, in language design for systems programming with GC.

Re: Oberon (2009)

#135

Post by pjmlp »

rbanffy wrote: post #67
romwell wrote: post #37

Never heard of? Come on! It's the most interesting thing yet to happen in desktop computing.

I made the same complaint when Apple discontinued the Newton. It was their most interesting computer. In the long run, an evolutionary dead-end (Unix won), but still interesting.

Including Dylan

Re: Oberon (2009)

#136

Post by moomin »

pacod wrote: post #91

When I started to study computer sciences in Germany in 1991, we used Oberon on X11 terminals during the the initial "Praktische Informatik I" lecture as our first programming language. Oberon being new, the professor said he wanted to make sure that everyone starts under the same conditions and with no pre-knowledge. So we wrote our linked lists, hash tables, trees, sorting algorithms etc. in Oberon. That time almos…

My experience with Modula-3 was very similar. People hated it.

Re: Oberon (2009)

#137

Post by chadcmulligan »

Koshkin wrote: post #3

I 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.

I am compelled to mention delphi - it has compile times of a few seconds on any old hardware.

Re: Oberon (2009)

#138

Post by Rochus »

pjmlp wrote: post #133
Rochus wrote: post #127

Earlier quoted context omitted.

Thanks. I don't know the Ulm compiler, and I unfortunately don't have System 3 (can you please provide a link with the source code and/or a working Linux binary?), but I have the source code of V2 and V4 (both ETH and Linz versions, from 1992 to Linz 1.7) where there are no coroutines.

System 3 is packaged as part of Active Oberon.

Im looking for the original Ceres source code from 1992/1993.

Re: Oberon (2009)

#139

Post by Rochus »

tanakian wrote: post #124
Rochus wrote: post #97

Earlier quoted context omitted.

> Go can be simply characterised as a slightly stripped version of the Oberon-2 Well, not really; there are not much similarities between Oberon and Go besides the receiver syntax of Oberon-2 bound procedures (which was invented by Mössenböck btw) and the fact that both are garbage collected. In your list "removed from Oberon" you should add type inclusion (Go doesn't even have implicit coercion); there is an interse…

coroutines module comes with Oberon S3 system. also Ulm's Oberon compiler has coroutines module.

Because of pjmlp's hint I just looked into the repositories https://github.com/btreut/a2 and https://github.com/metacore/A2OS, but didn't find a coroutines module. I'm aware that Active Oberon (Patrik Reali, 2004) includes concurrency, but this is a different language than the one used for System 3.

Re: Oberon (2009)

#140

Post by 4bpp »

galaxyLogic wrote: post #131
4bpp wrote: post #113

Earlier quoted context omitted.

Up until the mid-2000s, a lot of complex GUI applications (such as Visual Studio 6) in the Windows world used a paradigm somewhat ambiguously named MDI (cf. https://documentation.help/Win32/MDI%20Frames.htm ) which is what you describe sounds like. Unfortunately, UI design/HCI fashions turned against it hard and it went all but extinct; last I checked, few GUI toolkits even support it. Gtk was on the vanguard of the…

I think the MDI was too complicated for most people. Simplicity wins. And wasn't it like an application had to implement it to use it, not part of the OS-GUI by itself? But Smalltalk "project windows" was and is truly simple. I think you can still check them out in Pharo and/or Squeak. They are not of much use to casual computer user I think. Their benefit comes when the computer is used to perform complex multi-leve…

> I think the MDI was too complicated for most people. Simplicity wins. And wasn't it like an application had to implement it to use it, not part of the OS-GUI by itself?

It's true that MDI generally existed at a different level of abstraction (the "toolkit" that draws widgets rather than the "windowing system" that assigns screen regions to applications and lets them draw to those regions, while giving the user control over which application gives what region), but in contexts where the OS also provided a canonical platform GUI toolkit (such as Windows, see the documentation I linked above), the MDI implementation would naturally also come from the same vendor.

I'm aware that a common argument of the anti-MDI push was in fact that the OS window manager should be able to handle management of (sub)windows better and more natively than an application vendor's own low-resource proprietary implementation in the context of subwindows, but this superiority of platform window management never actually materialised and in 2022 I'm still occasionally finding myself trying to chase down all the different subwindows of multi-window applications that wound up on separate workspaces. Pre-single-window GIMP was a particularly egregious offender in this regard.

Post reply on HN