12

Reading Niklaus Wirth, one can notice that despite some popularity of Pascal, he is not glad that Oberon (as a "polished" successor of Pascal and Modula) didn't get much popularity. I never did anything in Oberon, but reading the page Oberon For Pascal Developers I really did not like many of the changes as a Delphi/pascal developer, for example

  • forcing the reserved words to be always uppercase
  • making the language case-sensitive
  • getting rid of enumeration types

What do you think about Oberon, is it really "a better Pascal" from your point of view?

gnat
  • 21,442
  • 29
  • 112
  • 288
Maksee
  • 2,653
  • 1
  • 16
  • 12
  • 3
    Oberon seems like a distant echo of the Ada/Pascal era in programming. It may be slightly better than Wirth's original Pascal language, but obviously it is inferior to Turbo Pascal/Delphi. – mojuba Nov 16 '10 at 09:17
  • 2
    @mojuba, that looks like an answer to me... – glenatron Nov 16 '10 at 10:22
  • Wasn't this closed once already? What happened to the edit history? – Robert Harvey Nov 16 '10 at 19:29
  • I had a brief fascination with Oberon in my college years. I wish I knew more about it to have an opinion. – Barry Brown Nov 17 '10 at 18:03
  • There's a possible spell error in "O`v`eron For Pascal Developers" ;) (but it says it all -- that thing is over ..) – mlvljr Nov 17 '10 at 21:17
  • 1
    Requiring upper case reserved words would be a deal-breaker for me. I find lower case much easier to read. – GrandmasterB Nov 17 '10 at 21:18
  • I love there is no GO to , one of the main features and simplified grammar – Mariuz Sep 06 '12 at 06:53
  • Why is the question "Is Oberon really a better Pascal" acceptable on this site while a similar question like "Is Java really a better C++" would start a flame war and would be probably closed? Please note that I have chosen C++ / Java arbitrarily, any language pair X, Y in which Y was more or less directly derived from X, and both X and Y are still actively used would probably lead to a similar situation. – Giorgio Sep 06 '12 at 08:59
  • Pascal was originally designed for teaching students programming. Is Oberon good for that? – Sulthan Sep 06 '12 at 09:28
  • Can EXIT escape multi-level loops? If not, omitting GOTO was a bad decision. – zvrba Sep 06 '12 at 15:00
  • @Giorgio I think it is a fair question in this case because both languages in question (Pascal, Oberon) were developed by the same person for similar reasons. I'm not sure there are many other cases like that, and Java, C++ would not fit that criteria. – sdg Sep 06 '12 at 18:18
  • @sdg: Actually my comment was rather provocative. I think it is OK to compare objective experiences with different languages and it would also be OK to compare C++ and Java (AFAIK Java was indeed strongly inspired by C++). Unfortunately not all languages are created equal: a question about Pascal vs Oberon can result in a very quiet discussion whereas a question about C++ vs Java would probably lead to some kind of third-world war. (I think this shows that some programmers develop religious feelings towards the language they know better.) Bottom line: I am not against language comparisons. – Giorgio Sep 06 '12 at 18:29
  • A successor language is not always automatically revered as an improvement. IMHO Oberon was too terse, unproductive and with an annoying state-in-a-state abstraction to be a general purpose language. OTOH that same horrible state-in-a-state abstraction made Java popular. Parts of Modula2: yes. Oberon: No IMHO. – Marco van de Voort Sep 06 '16 at 08:15

2 Answers2

8

Yes, I would call Oberon a better Pascal. With Oberon, Professor Wirth got to the core of object oriented programming with type extension and procedure variables. I find it elegant that Oberon is a smaller language than Pascal with much more power.

Oberon 2 took the language a step further by binding methods to records.

I do dislike the upper case reserved words. I find the syntax an improvement with the elimination of many begins and ends.

Oberon was used to write a very interesting operating system described in Project Oberon: The Design of an Operating System and Compiler.

Blake
  • 406
  • 2
  • 10
  • 2
    Agree, Oberon is better. The problem with Oberon is that it came too late. Many others improved upon Fortran, Basic, Pascal, C, so Oberon has severe competitors. Then, the language is only part of the solution. The 'best' language has good libraries, or an infrastructure. Javascript is great because of the tie to web applications. Then, react is even greater, building on JS. Who cares about language simplicity? We want simple objects like react components to build web apps. – Roland Feb 24 '20 at 13:59
5

It is better, and worse, in various ways:

It is nice to have garbage collection, and facilities for modular and Object Oriented programming. It is a relatively small language; easy to parse, and implement.

The lack of enumerations is a pain (indeed, in the extended Oberon dialect we use, we added them back).

Relative to more modern languages, its minimalism is a bit brutal, and treating strings as arrays of characters in any language is ghastly.

Of course, Pascal has evolved quite a bit too, e.g. see Component Pascal.

grrussel
  • 469
  • 3
  • 5
  • How do you do type extension on enumerated types in your extended Oberon dialect? Reason I ask: Professor Wirth said he couldn't see a good way to do it, and that's why he removed enumerated types from the language. – John R. Strohm Nov 17 '10 at 22:40
  • 2
    Actually, I believe that despite its name, Component Pascal is a successor to Oberon, not Pascal (except indirectly, of course). It goes something like Algol-X (never implemented) -> Algol-W -> Pascal -> Modula (never implemented) -> Modula-2 -> Oberon -> (some revisions of Oberon) -> Component Pascal. – Jörg W Mittag Nov 20 '10 at 15:20
  • 2
    Wirth was a purist; he decided it was better to lose the type safety of enums for extensibility and orthogonality. We write a lot of code that benefits from type checking of enums, where co-incidental value collisions would otherwise introduce subtle errors. In short, since we control both the entire Oberon code base, and the compiler, we do without type extension on enums, in order to prevent a class of extremely irritating program errors. – grrussel Nov 21 '10 at 19:51