4 ms·

Oberon 07 actually removed features -- like multiple return statements... The extensions on the other hand seem pretty hefty, and I'd be worried that they chan

by mhd 10y ago

Oberon 07 actually removed features -- like multiple return statements... The extensions on the other hand seem pretty hefty, and I'd be worried that they change the language's character a bit too much. Some of that seems to be necessary for JavaScript interaction, though. Then again, one probably doesn't pick Oberon if one enjoys working with the current weird OOP/FP/FRP morass.

vidarh 10y ago
Yes, most of Wirths language revisions removes more features than they add. I agree the extensions seem hefty to some extent, but most of them look like they should change the grammar very little. I wish he'd publish a BNF for the full thing and a diff against the original Oberon 07 BNF, to make it easier to see the full impact, though. I see he's given grammar fragments a couple of places. In terms of semantics they do clearly deviate quite a bit from the overall philosophy of Oberon (e.g. making MAP a built in type despite the big variety of design tradeoffs people might want), but it still seems quite restrained compared to most modern languages.
pjmlp 10y ago
> Then again, one probably doesn't pick Oberon if one enjoys working with the current weird OOP/FP/FRP morass. I am passionate about Oberon, collect all Wirth related papers and enjoyed using Native Oberon back in the day, when the OS was made available on the PCs, around 1996 or so. He is one of my "idols" in history of computing and I even had the opportunity to meet him once, as he gave an Oberon conference at CERN. However, I have learned many paradigms and languages since those days, to be happy just doing plain Oberon on the job. Nowadays any JVM or .NET language is more my kind of thing for it, the only thing missing is standard AOT compilation as part of their canonical toolchains, but that is slowly being taken care of. At least some of his ideas regarding safe OS architectures seem to live on those runtimes, and MSR work.
- mhd 10y ago
  I read my previous post again and just wanted to make clear that this "morass" was referring specifically to the JavaScript "landscape", not the paradigms in general... And yeah, I remember Native Oberon, too. In the mid-90s it seemed much more open about what OS was taking over. Win95 just came out, OS/2 was still an alternative (Warp), Linux was making the rounds, and then some oddballs like Oberon or QNX... Marrying Oberon with the browse feels a bit weird, though. The ETHZ workstations were rather reductionist, and hosting that on a modern browser stack... (For a double whammy, one could write the backend in Go, the mirror universe Oberon)
  - pjmlp 10y ago
    > For a double whammy, one could write the backend in Go, the mirror universe Oberon Fully agree, Goberon for lack of more imaginative name. :) I guess for that to be fully possible, the plugin package needs to be better supported, as it still is a bit WIP and rather fresh. Then it would be "only" a matter of porting the runtime to bare metal. :)

by mhd 10y ago

vidarh 10y ago

Yes, most of Wirths language revisions removes more features than they add. I agree the extensions seem hefty to some extent, but most of them look like they should change the grammar very little. I wish he'd publish a BNF for the full thing and a diff against the original Oberon 07 BNF, to make it easier to see the full impact, though. I see he's given grammar fragments a couple of places. In terms of semantics they do clearly deviate quite a bit from the overall philosophy of Oberon (e.g. making MAP a built in type despite the big variety of design tradeoffs people might want), but it still seems quite restrained compared to most modern languages.

pjmlp 10y ago

> Then again, one probably doesn't pick Oberon if one enjoys working with the current weird OOP/FP/FRP morass. I am passionate about Oberon, collect all Wirth related papers and enjoyed using Native Oberon back in the day, when the OS was made available on the PCs, around 1996 or so. He is one of my "idols" in history of computing and I even had the opportunity to meet him once, as he gave an Oberon conference at CERN. However, I have learned many paradigms and languages since those days, to be happy just doing plain Oberon on the job. Nowadays any JVM or .NET language is more my kind of thing for it, the only thing missing is standard AOT compilation as part of their canonical toolchains, but that is slowly being taken care of. At least some of his ideas regarding safe OS architectures seem to live on those runtimes, and MSR work.

mhd 10y ago
I read my previous post again and just wanted to make clear that this "morass" was referring specifically to the JavaScript "landscape", not the paradigms in general... And yeah, I remember Native Oberon, too. In the mid-90s it seemed much more open about what OS was taking over. Win95 just came out, OS/2 was still an alternative (Warp), Linux was making the rounds, and then some oddballs like Oberon or QNX... Marrying Oberon with the browse feels a bit weird, though. The ETHZ workstations were rather reductionist, and hosting that on a modern browser stack... (For a double whammy, one could write the backend in Go, the mirror universe Oberon)
- pjmlp 10y ago
  > For a double whammy, one could write the backend in Go, the mirror universe Oberon Fully agree, Goberon for lack of more imaginative name. :) I guess for that to be fully possible, the plugin package needs to be better supported, as it still is a bit WIP and rather fresh. Then it would be "only" a matter of porting the runtime to bare metal. :)