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

101–110 of 149 posts

Re: Oberon (2009)

#101

Post by Rochus »

_fz_ wrote: post #98
Rochus wrote: post #96

Earlier quoted context omitted.

[1] is not complete; this one is missing: https://github.com/rochus-keller/Oberon/ ;-)

Project Oberon 2013 emulator and RISC compiler in Go: https://github.com/fzipp/oberon https://github.com/fzipp/oberon-compiler

Looks like quite a diligence; I wrote an Oberon to C++ transpiler some years ago; here is a C++ version of the Oberon system: https://github.com/rochus-keller/OberonSystem/tree/master/CP.... My Oberon+ compiler generates CIL bytecode and C99 source code. Here is a version of the Oberon system which runs on .NET (cross-platform, without emulator): http://software.rochus-keller.ch/OberonSystem_SDL_CLI_Assemb.... And here is the corresponding C99 version: http://software.rochus-keller.ch/OberonSystem_ObxIDE_Cgen_20.... Both are directly generated from the sources in https://github.com/rochus-keller/OberonSystem/tree/FFI, using SDL2 for platform independence.

Re: Oberon (2009)

#102

Post by dfawcus »

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…

Yeah - I skipped the type inclusion, as I just viewed it as a misfeature, assuming we're talking about the implicit casts between different number types.

As to ':=' in Go, yeah - a new thing over Oberon-2. Since assignment in Go uses C style '=' whereas Oberon uses Pascal style ':=', I certainly was not confusing them.

The characterisation came about because of an implicit complaint (from C programmers) about a choice of Go for a project. Now never having used Oberon-2, but having read the report, I used the comparison to a stripped version it as a way of showing how simple the language actually was. Something like 25 pages being sufficient to describe it.

The things which struck me were:

   O2 MODULE becomes Go package (and similar syntax use)
   O2 NEW retained as Go new, but &Foo{} generally preferred
   O2 export of symbol via '\*' tag becomes Go export via capital letter.
   O2 Open arrays replaced by Go slices or strings.
   O2 WITH because Go 'type switch'
   O2 'type guard' becomes Go 'type assertion'
   O2 VAR parameters to PROCEDURES become Go pointer parameters to funcs
But in the end it is very much a subjective thing, so unless using the non classful parts of Oberon-2 reveals significant differences, I'd have to stick with my evaluation.

Re: Oberon (2009)

#103

Post by PcChip »

aebtebeten wrote: post #55
goatsneez wrote: post #38

Earlier quoted context omitted.

FYI, a flavor of Oberon will also fly to space soon it turns out... https://arxiv.org/abs/1709.03404v1

> ...all memory accesses are indirect ... module-data is position independent and may be moved in case memory should fail due to radiation damage. I once used a debugger that shipped with a rather snarky easter egg command: "find my bug". One of its more useful suggestions was "Maybe a cosmic ray error? Use smaller chips!".

Wouldn't smaller chips make the problem worse?

Re: Oberon (2009)

#104

Post by dang »

Related:

Oberon OS Walkthrough (2009) - https://news.ycombinator.com/item?id=25786470 - Jan 2021 (59 comments)

Oberon (2009) - https://news.ycombinator.com/item?id=6498878 - Oct 2013 (31 comments)

Oberon, a delightfully insane system - https://news.ycombinator.com/item?id=593323 - May 2009 (30 comments)

(Lots of previous Oberon threads generally so maybe I won't list them)

Re: Oberon (2009)

#105

Post by dfawcus »

mseepgood wrote: post #100
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…

> Added by Go: Maps, Slices, Strings, Interfaces, Channels, Coroutines. Also added by Go: Type parameters (generics)

The characterisation was against Go 1.15 as that is what is current in the version of Debian we're using (11?).

So other than noting that Go 1.18 adds Generics but they can be ignored due to us targeting 1.15, they weren't mentioned.

As I recall the another thing we get in 1.18 (as a side effect of the Generics constraints mechanism) is a slight improvement in static checking for certain constructions of type switch.

Re: Oberon (2009)

#106

Post by 082349872349872 »

PcChip wrote: post #103
aebtebeten wrote: post #55

Earlier quoted context omitted.

> ...all memory accesses are indirect ... module-data is position independent and may be moved in case memory should fail due to radiation damage. I once used a debugger that shipped with a rather snarky easter egg command: "find my bug". One of its more useful suggestions was "Maybe a cosmic ray error? Use smaller chips!".

Wouldn't smaller chips make the problem worse?

I think it jocularly meant "use something with fewer gates and a smaller cross section", not "use a smaller feature size". Or I could easily have misremembered: this was all last century.

Re: Oberon (2009)

#107

Post by pklausler »

fm77 wrote: post #32
JulianMorrison wrote: post #4

Earlier quoted context omitted.

Pascal family languages parse quickly because they won't let you use anything before it's defined.

Well, not really. Consider the following: type ItemPtr = ^Item; SomeOtherType = record a,b,c:integer; end; Item = record Data:string; Next:ItemPtr; end; The first time the parser hits "Item", its not defined.

Pascal require(s|d) a "forward" declaration on such a type, no?

Re: Oberon (2009)

#108

Post by jrm4 »

Dangit. This is the sort of thing that's equal parts frustrating and exciting, in that I've had a lot of these ideas independently and this is the first time I'm discovering that someone has implemented them. Especially this infinite canvas idea, which I'm very confident would work wonders for me (and many other people) mostly owing to the power of "spatial memory," which I feel like is a wildly underused human feature. (e.g. memory palaces)

Re: Oberon (2009)

#109

Post by joshspankit »

jrm4 wrote: post #108

Dangit. This is the sort of thing that's equal parts frustrating and exciting, in that I've had a lot of these ideas independently and this is the first time I'm discovering that someone has implemented them. Especially this infinite canvas idea, which I'm very confident would work wonders for me (and many other people) mostly owing to the power of "spatial memory," which I feel like is a wildly underused human featu…

An important thing to be aware of is that spatial memory is not universal, and thee is quite a bit of variation among those who have the ability to use it successfully.

I don’t say this to discourage. Quite the opposite: I say this to say if someone doesn’t understand the benefits of your ideas don’t take it as a general “this will not work” but instead go share them with someone else

Re: Oberon (2009)

#110

Post by Rochus »

dfawcus wrote: post #102
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…

Yeah - I skipped the type inclusion, as I just viewed it as a misfeature, assuming we're talking about the implicit casts between different number types. As to ':=' in Go, yeah - a new thing over Oberon-2. Since assignment in Go uses C style '=' whereas Oberon uses Pascal style ':=', I certainly was not confusing them. The characterisation came about because of an implicit complaint (from C programmers) about a choic…

> Something like 25 pages being sufficient to describe it.

Wirth attached importance to the fact that there are only 16 pages; on closer inspection, however, one realizes that not everything has been specified and the omission of redundant descriptions easily leads to ambiguity in the given writing style.

> in the end it is very much a subjective thing

The differences and little similarities, as far as specified, are objectively ascertainable. But of course there are far more important things. From my point of view Oberon (including Oberon-2 and especially Oberon-07) is too minimalistic for non-academic projects anyway. That's why I threw my hat into the ring with Oberon+ (http://www.oberon-lang.ch ); its specification is still small with about 50 pages.

Post reply on HN