[HN Gopher] The Oberon+ Programming Language
___________________________________________________________________
The Oberon+ Programming Language
Author : AlexeyBrin
Score : 132 points
Date : 2023-03-18 13:48 UTC (9 hours ago)
(HTM) web link (oberon-lang.github.io)
(TXT) w3m dump (oberon-lang.github.io)
| illiarian wrote:
| > During my work with Oberon and systems implemented in Oberon, I
| kept asking myself what properties the language would need to
| have so that I could use it for my own systems too, without
| giving up the goal of making it as simple as possible.
|
| From here: https://oberon-lang.github.io/2021/07/15/motivation-
| for-a-ne...
|
| And yet it carries over all of the inanities of the many Oberons
| before it like:
|
| - Four different loops (while, for, repeat, and loop)
|
| - Useless distinction between procedures and functions
|
| - Randomly selected ASCII symbols to show what is exported and/or
| read-only
|
| - extremely awkward and limited exception handling (you have to
| call a procedure that cannot hav a return type using a built-in
| pcall procedure that writes exception info into a variable you
| pass into it)
|
| and so on.
|
| All of Oberons are just walking around in circles re-implementing
| the same weird ideas again, and agian, and agian, and again.
| Rochus wrote:
| > _extremely awkward and limited exception handling_
|
| The design is well-balanced and simple, and you can do
| essentially everything you can do with Java exceptions, just
| without complicated syntax constructions; see https://oberon-
| lang.github.io/2022/05/15/towards-exception-h... for more
| details.
| illiarian wrote:
| PCALL(P), P cannot have a return type
|
| You cannot handle handle exceptions in a block of code
| without extracting into a procedure... that cannot return
| anything.
|
| Yeah, I doubt you can "do everything you can do with Java
| expressions.
|
| And of course Oberon's syntax construction is more complex:
| you need to have an external variable that gets populated,
| you need to match on three different types etc.
| Rochus wrote:
| > _without extracting into a procedure_
|
| That's a one second problem; just give back the value via
| VAR parameter; the design decision is well justified in the
| referenced article.
|
| > _do everything you can do with Java expressions_
|
| "exceptions", not "expressions"; what do you think one
| cannot do with the Oberon approach?
|
| > _you need to have an external variable that gets
| populated_
|
| That's the Pascal philosophy; even an index variable of a
| FOR loop has to be declared up front in the declaration
| section; either you like it or not; personally I prefer the
| in-place declaration approach, but the language would
| become much more complex and it doesn't make sense to just
| rebuild C++ or Java.
| illiarian wrote:
| > That's a one second problem; just give back the value
| via VAR parameter
|
| Ah yes. "Just".
|
| And these people accuse other languages of having complex
| syntaxes or complexities in general.
|
| > what do you think one cannot do with the Oberon
| approach
|
| I think it's obvious what I wrote. You can't wrap blocks
| of code, to do that you need to extract it into a proc
| that among other things (like actual params passed to it
| needs an additional parameter) needs an awkward `out`
| parameter etc.
|
| Is the result sorta kinda equivalent to Javas? If you
| squint hard enough, yes
|
| > That's the Pascal philosophy; even an index variable of
| a FOR loop has to be declared up front in the declaration
| section
|
| I know the Pascal philosophy: create awkward verbose
| languages with useless constraints while claiming it's
| for the sake of simplicity.
|
| > but the language would become much more complex and it
| doesn't make sense to just rebuild C++ or Java.
|
| 1. There's nothing wrong with complexity
|
| 2. There a multiple languages that don't have
| Pascal/Oberon's constraints, decisions, and awkward
| workarounds which are neither Java nor C++
| Jtsummers wrote:
| > 1. There's nothing wrong with complexity
|
| But you don't like the distinction between procedures and
| functions or different types of loops? Pick a side here.
| illiarian wrote:
| I don't like people pretending that the language is
| simple, and commenters berating other languages for being
| complex while the language they promote and defend has
| quite a few of complex things and awkward workarounds for
| no reason.
| Rochus wrote:
| That's like ranting about wine instead of just ordering a
| beer ;-)
| illiarian wrote:
| Poor metaphor is poor
| sedatk wrote:
| > Four different loops
|
| I think that having four different loops is better than jumping
| through four different hoops for different loop styles.
| illiarian wrote:
| You don't jump through different hoops in most languages [1].
|
| In Oberons you jump through the hoops because only `loop` is
| allowed to have `exit`, for example. Which is a constraint
| for the sake of constraints. Repeat is a do/while, but it
| doesn't have while's elseif statement. Again, because
| reasons. And so on.
|
| Oberon is nothing but hoops instead of loops.
|
| [1] Go's decision to not include do/while is on par with
| Oberon's decisions for loops: stupid and unreasaonable.
| timbit42 wrote:
| I like having a few different loops to keep code more readable.
| I think there should be two at a minimum for whether the
| condition is before or after the looped code.
|
| I agree with the rest, but the rest of the language is great.
| illiarian wrote:
| > I like having a few different loops to keep code more
| readable.
|
| When they have similar semantics, and are not arbitrarily
| designed.
|
| In Oberon:
|
| - while has an elseif statement. Repeat is a do/while,
| doesn't have an elseif statement
|
| - loop is allowed an exit. No other loops are allowed to
| terminate early. And that is literally the only reason loop
| exists
|
| etc.
| flykespice wrote:
| > - useless dinsctintion between procedures and functions?
|
| Uh? care to elaborate?
| illiarian wrote:
| A proc is a function with no return.
|
| A function is a function that returns something.
|
| Oberon+ keeps it's predecessors' idiotic distinction, but
| takes it one step further: both functions and procedures are
| decalred with `proc` or `procedure`, functions are `proc`s
| that have a return type.
|
| And yet:
|
| - procedure calls don't have to specify parameters
| apparently, but function calls must specify all parameters
|
| - functions cannot be used in Oberon+'s weird exception
| handling. [1] You do a call with `PCALL(res, P, args)` where
| res is a variable that will hold the result of the exception
| if it happened, and P is the procedure. You cannot pass
| functions (aka procedures which have a return type)
|
| As the spec so wonderfully says [2],
|
| --- start quote ---
|
| There are two kinds of procedures: proper procedures and
| function procedures. The latter are activated by a function
| designator as a constituent of an expression and yield a
| result that is an operand of the expression. Proper
| procedures are activated by a procedure call. A procedure is
| a function procedure if its formal parameters specify a
| result type. Each control path of a function procedure must
| return a value.
|
| --- end quote ---
|
| [1] https://github.com/oberon-
| lang/specification/blob/master/The...
|
| [2] https://github.com/oberon-
| lang/specification/blob/master/The...
| tragomaskhalos wrote:
| For anyone wondering about the funky asterisk against some of
| those identifiers, the docs say: An identifier
| declared in a module block may be followed by an export mark (*
| or -) in its declaration to indicate that it is exported
| jhbadger wrote:
| This is from normal traditional Oberon, however.
| codetrotter wrote:
| Any relation to the Oberon operating system?
|
| https://en.wikipedia.org/wiki/Oberon_(operating_system)
| eterps wrote:
| Only the language part of it
| Rochus wrote:
| There is a version of the Oberon System compatible with the
| Oberon+ toolchain and IDE, see https://github.com/rochus-
| keller/OberonSystem
| sfpotter wrote:
| I don't like how verbose Pascal-like languages are. I don't want
| to have to type tons of keywords to get anything done. Curly
| brackets are a big improvement over pairs of "begin" and "end"
| all over. Makes it hard to see the forest for the trees when
| skimming some code to figure out what it does. That on its own
| makes something like this a complete nonstarter for me, leaving
| aside issues like support, quality of implementation, uptake,
| etc.
| zabzonk wrote:
| apart from that (which i agree with) is that in most pascal-
| like languages you have to define variables at the top of a
| function, and their scope is the whole function. both c
| (nowadays, define at top of a {} scope) and c++ (define
| anywhere inside a function) do much better which, together with
| irritating long names, may explain why c and c++ won out over
| the pascal-likes.
|
| speaking as an ex professional delphi programmer here - i have
| written lots of object pascal code, and have no desire to write
| any more.
| unwind wrote:
| C is declare anywhere and has been for a looong time (C99).
| zabzonk wrote:
| sorry, my bad, i don't do any c programming these days.
|
| but to be pedantic, i think you mean define rather than
| declare, though of course you can also declare things at
| different scopes.
| stefncb wrote:
| No, I think they do mean declare. In C89 you can define a
| variable anywhere, like so: int x;
| f(); x=3;
|
| The improvement was allowing declarations anywhere.
| rightbyte wrote:
| Isn't the first row both the declaration and definition
| is this case?
|
| (I assume f() is a call.)
| pjmlp wrote:
| Delphi supports local variable declarations for quite some
| years now, and Ada does it since its introduction in 1983.
| cardanome wrote:
| For me, "begin" and "end" are actually much more comfortable to
| type, because I don't have too move my hands for that, I can
| stay pretty much on the home row. Curly Braces are way too far
| on the right top to do that and then you either have to use you
| weak fingers or move quite a bit.
|
| (Granted I am touch typing and also using Colemak layout, so
| rarely ever move my hands. For people that hunt and pek, I
| believe curly braces are easier to type.)
|
| I don't think there is much practical difference between curly-
| braced vs keyboard based syntax. Both are similarly easy to
| read, especially with syntax highlighting. After a while, your
| brain will automatically parse "begin" and "end" as a symbol,
| same as curly braces, so you won't notice the "noise".
|
| As for the pros and cons:
|
| Pascal style syntax is slightly better for new people learning
| to program. Learning how to even type those weird curly braces
| and understanding the difference between all the styles of
| braces just takes focus away from actually learning how to
| program.
|
| Curly braced C-style syntax is better for people that already
| know how to program because everyone is already familiar with
| at least one curly braced language.
| zabzonk wrote:
| > because everyone is already familiar with at least one
| curly braced language.
|
| so, logically, they must have learned how to use {} in the
| first place, probably with few problems.
|
| i have taught god-knows how many people c and c++ (used to be
| a commercial trainer for those languages) and i can assure
| you that very, very few, if any, had problems with {}.
| 082349872349872 wrote:
| A normal swiss keyboard does not even have {}
| open-source-ux wrote:
| Ruby and Julia use the 'end' keyword in code blocks. A bit
| less noise compared to Pascal's 'begin' and 'end' syntax.
| iroddis wrote:
| I also find curly braces/parens/etc annoying to type, but
| recently had my mind blown when I saw a typing tutor program
| that recommended using left-shift to create those characters.
|
| For 35+ years I've been using right-shift for things on the
| right side of the board, cranking my hand and stretching my
| fingers and complaining about programming languages with poor
| typing ergonomics.
|
| It's taking forever to break the habit, but so far it feels
| so much better.
| chrisdhal wrote:
| When I took typing in high school (mid-80s in the US), on
| an IBM Selectric, we were taught that way. If the key you
| wanted to capitalize (or needed the shift for) was on the
| left hand, you would use the right shift key and vice
| versa.
|
| I didn't know it at the time, but that one semester class
| was immensely useful for me throughout my career.
| peterfirefly wrote:
| I took typing as an elective class in school in Denmark
| fully expecting it to be useful for decades. And I was
| right :)
|
| The teacher was a bored and unpleasant secretary and the
| typewriters were mechanical (and the shift keys so heavy
| for our pinkies) but it was still the most useful thing I
| did in school since I learned to read in first grade.
| ghodith wrote:
| Interest, in contrast I have the bad habit of never using
| right shift, which is definitely inefficient when typing
| capital A for example.
|
| I've not been very successful changing this habit.
| vanjajaja1 wrote:
| Wow I'm analyzing some motor patterns I wasn't even aware
| of...
|
| I think playing video games has made LeftShift + letter a
| really easy combo, right shift feels quite uncomfortable,
| but I did find that I use it when typing !
| hota_mazi wrote:
| > For me, "begin" and "end" are actually much more
| comfortable to type,
|
| Type, maybe, but they are visual noise when you read code.
|
| BEGIN and END are also not as easy to match with
| editors/IDE's as pairs of symbols.
| cardanome wrote:
| There is no difference in noise for me between curly braces
| or keywords because my brain parses both as a single token.
| I don't process "e"-"n"-"d", it is just one thing "end",
| same as a curly brace is.
|
| Of course some people can't read words by shape and instead
| have to sound out the individual letters every time, so I
| guess it can be more annoying for some people.
|
| And I don't mean to be patronizing, I actually have the
| opposite problem. I am faster at parsing whole words than
| symbols which is why I really struggle with modern UI that
| solely relies on icons. It drives me mad.
| sedatk wrote:
| I'm actually okay with begin and end, but, writing a function's
| name twice on both the declaration and after the end statement
| sounds like a HUGE chore. If that's mandatory, it's immediately
| a mood killer for me about Oberon+.
| bluedino wrote:
| That seems like it would be a simple thing to change.
| timbit42 wrote:
| Pascal required BEGIN and END for every block, such as: IF
| <cond> THEN BEGIN <code> END ELSE BEGIN <code> END END, but
| Modula-2 and Oberon don't require BEGIN or END around code
| blocks: IF <cond> THEN <code> ELSE <code> END. BEGIN is now
| only used to denote the end of variable declaration and the
| beginning of the code. You can see this if you click the posted
| link. I think it was a valid complaint in Pascal, but not in
| it's derived languages.
| shadowofneptune wrote:
| If you've dismissed a whole host of languages just at a glance,
| you're missing out. Lua has little in common with Pascal, which
| has little in common with Fortran, etc. As a sister post to
| this says, you see them more as tokens once you are familiar.
| Emboldening or coloring keywords also helps, as for any
| language.
| nequo wrote:
| I think it's less about typing them and more about reading
| them. Curly braces reduce the number of keywords in the
| language (unless the alternative is indentation sensitivity
| like in Python or Haskell). This means that if I see a word, it
| is easier to infer if it is a variable name or if it does
| something structural.
|
| How about a treesitter-based editor extension that converts
| between begin/end and {/}, as if they were ligatures? Actually
| this might not even need treesitter.
| armchairhacker wrote:
| > How about a treesitter-based editor extension that converts
| between begin/end and {/}, as if they were ligatures?
| Actually this might not even need treesitter.
|
| See emacs prettify-symbols-mode (https://emacs.stackexchange.
| com/questions/46529/configuring-...)
| pjmlp wrote:
| Code is read much more times than written, and hieroglyphs
| don't help.
| mpweiher wrote:
| Actually they do, particularly for reading, as they separate
| language boilerplate from actual content.
|
| For example, to call a function, we just use the name of the
| function and parentheses, rather than saying "call". This is
| useful, because it allows the reader to focus on what is of
| interest.
| pjmlp wrote:
| Other than BASIC, COBOL, Assembly and a few others, call
| isn't a thing.
| mpweiher wrote:
| EXACTLY.
| canadianfella wrote:
| [dead]
| LudwigNagasena wrote:
| Ad hoc hieroglyphs that change from project to project indeed
| make it harder to read code. But as long as they are the core
| part of the language and they represent orthogonal features
| (ie they don't bloat the number of ways you can represent
| identical solutions), I don't see why it should be a problem.
| On the contrary, putting less visual weight on tokens with
| smaller information content looks natural.
| zabzonk wrote:
| so, you recommend cobol?
| pjmlp wrote:
| Well, it is cloud ready.
|
| https://www.microfocus.com/en-us/products/visual-
| cobol/overv...
| zabzonk wrote:
| what has this to do with "hieroglyphs"?
| pjmlp wrote:
| It doesn't have them.
| revskill wrote:
| The funniest thing i see is programmers are getting prroblems to
| grok functional programing concepts.
| themodelplumber wrote:
| I thought the background context by the author was interesting to
| read:
|
| https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne...
| sacnoradhq wrote:
| If you want a scalable GC:
|
| - Don't throw everything into a single global heap
|
| - Don't rely on stop the world GC
|
| - Support actors and zero-copy message passing
|
| .. in other words, be like Pony's ORCA.
| luixmg wrote:
| Is this what it used to be component Pascal?
| rurban wrote:
| No, much younger. See https://oberon-
| lang.github.io/2021/07/15/motivation-for-a-ne...
| [deleted]
| skybrian wrote:
| The justification for putting generic types on modules is
| interesting. It seems they tried a lot of other variations but
| couldn't find one that was simple:
|
| https://oberon-lang.github.io/2021/07/17/considering-generic...
| badsectoracula wrote:
| A few years ago i was also thinking of how Oberon-07 could be
| extended to support more generic types - mainly so containers,
| etc, can be more type safe - and pretty much came to the same
| conclusion that putting types on the modules themselves is by
| far the simplest approach. Though my approach was a bit
| different (judging from the code examples) in that parametric
| modules were more like templates that were specialized during
| import.
|
| Specifically in Oberon-07 when you have a module "Foo" with a
| type "Bar" you use it in another module as "Foo.Bar". With
| parametric modules, a "Foo<T>" module would need to be imported
| an a specialized form as -e.g.- "Foo<INTEGER>" and thus the
| "Bar" type would need to be used as "Foo<INTEGER>.Bar".
|
| In my mind that was both the simplest and smallest change that
| would allow for the most flexibility (the parameters would be
| any token acceptable by the language, not just types, meaning
| that they could be used for constants or even affect other
| imports).
|
| I did consider implementing a compiler for this, but then i
| decided that if i'm going to make a compiler for an
| incompatible language that already practically nobody uses,
| might as well make my own language that also changes some
| things i dislike about Oberon-07 (like the uppercase keywords,
| using # for the inequality string and * to export stuff from
| modules).
| olah_1 wrote:
| I really see how Nim was influenced by Oberon now. Will Oberon+
| actually compete with Nim in some ways?
| Rochus wrote:
| That's like competing apples with oranges; some people like the
| former, some the latter, some both; if you prefer a Python like
| syntax an a much more complex language, then Nim is your
| choice.
| xkriva11 wrote:
| I like it is not using uppercase keywords. Is the grammar still
| LL(1)?
| srean wrote:
| I was looking for coroutines. Modula had them, but I couldnt find
| them here. Just a note I mean coroutines, not preemptive threads.
|
| Here is how it looks like in Modula-2.
|
| https://www.modula2.org/reference/isomodules/isomodule.php?m...
| mikewarot wrote:
| I did coroutines under Turbo Pascal wayyyyy back in the
| 1980s[1]. It's really just a matter of copying the stack and
| some book-keeping.
|
| Free Pascal has threads.
|
| [1] https://www.pcorner.com/list/PASCAL/TASKER4.ZIP/TASKER.PAS/
| dang wrote:
| Related:
|
| _Show HN: New Oberon+ to C99 transpiler for near native
| performance_ - https://news.ycombinator.com/item?id=29591993 -
| Dec 2021 (2 comments)
|
| _The Oberon+ Programming Language_ -
| https://news.ycombinator.com/item?id=27864582 - July 2021 (4
| comments)
|
| _The new Oberon+ programming language - modern simplicity_ -
| https://news.ycombinator.com/item?id=27855767 - July 2021 (4
| comments)
|
| Others? (Lots of original Oberon, of course)
| ZoomZoomZoom wrote:
| Oberon and Oberon+ are very interesting and are certainly a step
| forward from Pascal. Wish Oberon+ had moved forward a few more
| steps, like making everything an expression, for example, or more
| lax variable declaration rules (which probably require scoping
| rules changes).
|
| If only the FPC compiler supported it and allowed combining units
| in Oberon with Pascal ones in one project!
|
| The language specs: https://github.com/oberon-
| lang/specification/blob/master/The...
| shadowofneptune wrote:
| You appear to be familiar with Pascal, so I am surprised you
| find the statement-heavy approach an issue. What would be the
| benefit of making this change?
| ZoomZoomZoom wrote:
| My Pascal days are far in the past, but I recently used
| Lazarus to quickly prototype a simple GUI app (not many tools
| beat it yet for the task) and was a bit annoyed by the
| syntax.
|
| Relying on expressions greatly reduces the need for
| transitory variables, and in case of Pascal, where you can't
| just declare them as you go, this would be especially
| important to clear the code from ops inessential to the task
| at hand.
|
| `let foo = if (bar > 0) then bar else frobnicate() end` would
| be nice to have, as well as begin-end blocks with their own
| scope (can't fathom the reasons it's not allowed) and
| evaluated to the last statement. Rust and Nim get it mostly
| right.
| shadowofneptune wrote:
| This does feel then like a matter of taste. While Pascal's
| predecessor language Algol did allow syntax like that,
| adding it back to Pascal-like languages would make it into
| a different kind of language.
| ZoomZoomZoom wrote:
| What makes the language what it is is rather a
| philosophical question. I don't think I agree with you on
| this specific point.
|
| I'm not against evolution, especially when you have
| others to test the feature extensively for years. But I'm
| not a language designer and my opinion on the matter
| holds no weight.
| Rochus wrote:
| Oberon+ is not set in stone; if there are good ideas that fit
| into the concept of simplicity and add significant value, they
| should be considered. From my point of view, however, one
| should rather avoid proliferation, as one can observe it with
| e.g. C#, C++ or TypeScript.
| ZoomZoomZoom wrote:
| It's very nice to hear and I agree that languages have to
| move slowly, considering each move. On the other hand, when
| the user base is still slim you have much more freedom to be
| a bit more adventurous, add and deprecate things more freely.
| Some of the features can also be optional and available for
| those not afraid to try unstable things.
|
| It's a bit interesting that I initially stumbled on Oberon+
| while searching for something typed which compiles to
| straight Lua and was surprised seeing the scope of the
| project.
|
| In any case, I wish you all the best in the development of
| the language!
| Rochus wrote:
| Thanks.
|
| > _when the user base is still slim you have much more
| freedom to be a bit more adventurous, add and deprecate
| things more freely_
|
| When designing a language, it's hard to get rid of the
| initial sins, so if in doubt, leave a feature out, so you
| don't regret it later; once enough people are involved with
| the language and writing code with it, any change that
| isn't backwards compatible is an imposition on everyone
| involved.
| ZoomZoomZoom wrote:
| I agree completely.
|
| Playing the devil's advocate: On the other hand, making a
| whole new language is rarely a way to GTD now, it's
| usually an investment in the future. For surviving into
| that future the language usually needs the involvement of
| the community. And for that one has to consider what
| new/different/radical things does the language offer to
| the public to hook them on. May be it's OK to sin a
| little and get straight closer to v1.0? Of course, a few
| will hurt but they'll live.
| abecedarius wrote:
| I guess you could make changes like that while keeping backward
| compatibility with older Oberon, but that's probably kind of a
| pain, no? I agree that such changes would make Oberon more to
| my taste.
|
| Maybe what we really want would be semantically close to
| Oberon+ but abandoning Wirth's surface syntax. (You could still
| respect the design discipline of allowing a simple fast
| compiler.)
| ZoomZoomZoom wrote:
| I'm fine with Nim for my limited set of problems, but it's
| its own thing and not exactly in the family. Ideally, it
| would be something supported by the FPC compiler.
| sitkack wrote:
| I have so much respect for the design aesthetic of Wirth, but I
| don't like OO. What would a Wirthian FP language look like?
|
| I asked the oracle
|
| > Wirthian functional programming language would emphasize
| simplicity, elegance, and readability while incorporating
| functional programming concepts such as immutability, first-class
| functions, and recursion. It would provide strong typing,
| modularity, and a minimal standard library, staying true to
| Wirth's design principles.
|
| It also tells me that Elm, Idris, PureScript, F* and Gleam share
| many of these same qualities.
|
| The thing that I didn't appreciate about the design of Wirthian
| languages earlier is that he really focused on mechanical and
| compiler-writer sympathy, designing languages that were fast and
| easy to compile.
|
| I just discovered Pascal-S, it is like Cool or ChocoPy, a subset
| language designed for compiler students to implement.
|
| https://static.aminer.org/pdf/PDF/000/530/289/pascal_s_a_sub...
| pjmlp wrote:
| Easy, Standard ML.
| stefanos82 wrote:
| First time I read about Oberon was when I saw Ginger Bill
| presenting Odin language and visited his website to learn more.
| It was when I visited its FAQ [1] that saw the major influences
| that inspired him to design a new language and one of them was
| Oberon-2 which is an extension to Oberon itself.
|
| Fascinating stuff!
|
| [1] https://odin-lang.org/docs/faq/
| hsn915 wrote:
| Yea I was going to comment and say if anyone is interested in a
| modern language the follows in the tradition of Pascal/Oberon
| they should look into Odin
| carapace wrote:
| The whole Oberon system is great fun.
| https://people.inf.ethz.ch/wirth/ProjectOberon/index.html
|
| It's a single-user workstation, developed from the CPU on up,
| compiler & language, OS with unique GUI, all documented in a
| book, and you can run it online in a browser via a JS emulator
| for the CPU: http://schierlm.github.io/OberonEmulator/
|
| People used it at ETH as their main system to run the University!
| pjmlp wrote:
| Note that the evolution of it was Active Oberon and AOS
| operating system, much more closer to modern languages and OS
| stacks.
| alex_suzuki wrote:
| I studied CS at ETH from 2001 to 2006. Oberon was the main
| language used for teaching our introductory CS courses IIRC.
| Fun times. :-)
___________________________________________________________________
(page generated 2023-03-18 23:00 UTC)