5 ms·

>Sometimes I feel that Pascal and its successors are not fully appreciated by our world that grew too enamored with C. There were some awesome ideas and solutio

by eudox 10y ago

>Sometimes I feel that Pascal and its successors are not fully appreciated by our world that grew too enamored with C. There were some awesome ideas and solutions created there in Switzerland at that time when create a full package of hardware and software was something that people still tried to do. Having been taught Modula-2 in Programming 102 class in college (this was a year ago), I disagree completely. Software development has this camp with a contrarian, 'this was done at Xeroc PARC' mentality where we're using terrible computers because Smalltalk or the Lisp machine or Oberon failed and nasty Unix took over. But when you actually have to use these languages, well, they're terrible. They're C, with all its flaws, but a more indented/structured syntax. Pascal, Modula, and Oberon have no lessons that have not been learnt by some or another language, and done better.

_ph_ 10y ago
No, they are not C with all its flaws. They offer strict type checking, preventing a lot of constructs which would have unintended consequences when passing a C compiler. Modula introduced a proper module concept, without the need for header files without their issues, allowing for fast separate compilation of modules. Go picks up a lot of these ideas and brings them to a modern language.
vidarh 10y ago
> They're C, with all its flaws, but a more indented/structured syntax. There are many reasons to criticise aspects of Modula-2 or Oberon, but saying "they're C, with all its flaws" totally misses the mark. The entire language family belongs to a very different tradition. Wirth spent most of his career removing features, and adding much less than he removed. For good reason: Oberon as a language contains the bare minimum that his experience with systems-engineering (the OS and all applications for the Oberon systems that ran ETH Zurich for many years were written in Oberon itself) showed that they needed. This went down to the compiler: Unlike languages like C, Oberon is designed to be easy to compile. The grammar is positively tiny - it fits on 1-2 pages of A4 in a readable font, with comments. It can parsed and compiled in a single pass with a clear separation of the lexical scanner and parser, without any hacks or ambiguity, and I believe only with a single token lookahead. C isn't by any means a horrible language to compile compared to most newer languages, but compared to Oberon it's a monstrosity. This design philosophy follows through from the compiler through the support libraries, through the OS. It's austere, yes (the Oberon-07 language report is 17 pages...), and if you don't like austere languages, you won't like Oberon. But that too is a feature that separates it from C. As someone else pointed out, Go is a much better comparison than C. Oberon is garbage collected, for example, which instantly put it very much in a different "camp" to C back when it was launched, in an era where the thought of using garbage collection for a systems programming language was seen as something only the weird dynamic typing lisp and smalltalk people would consider.
- Avshalom 10y ago
  What it comes down to is that Wirth has always understood the difference between simple and jury-rigged in a way that Pike and the Unix crew never have.
- bogomipz 10y ago
  Can you elaborate on this "Unlike languages like C, Oberon is designed to be easy to compile?" I thought that was one of the reasons that C looks the way it does was to be easier to compile
  - vidarh 10y ago
    I mentioned some already, but to reiterate and expand. - The grammar size. This is the complete EBNF for Oberon 07 [1]. For comparison, here is a C 2011 grammar [2]. C is quite simple to parse, but still more complex than Oberon. - The Wirth languages can generally be compiled in a single forward pass. Dialects that allow forward references tends to require them to be specifically declared. Explicitly specified forward references minimize the amount of state the compiler needs to hold on to to fix up the typically minimal amount of references, but Oberon 07 doesn't have them anyway. This doesn't matter so much now, but in the 80's it was a big deal to be able to do single pass compilation without lots of memory spent on keeping a lot of bookkeeping or a syntax tree around (the Wirth compilers typically never constructs an AST, but directly emits opcodes during parsing by calling into a code-generation module, at the cost of losing out on quite a bit of optimization opportunities; on the other hand it also makes the compilers very simple and blazing fast). - No preprocessor. - In C, the presence of typedef means that there are constructs that are semantically ambiguous until you consult the symbol table (the parsers can still be context free, but you can't fully resolve the type of symbol in certain situations until you look at the symbol table). Also not a big deal, but things add up. To be clear, C is one of the easier languages to parse. I'm not implying C is particularly complex. The verbosity of Yacc/Lex vs "straight" EBNF overstate the complexity of the C grammar somewhat. And compare it e.g. to C++ or (run...) Ruby (which I love dearly to use, but the grammar is a crime against parser writers everywhere) and it's trivial. But Oberon took it several steps further. C is what you get if you build something through accretion and gradual changes while experimenting, despite trying to contain complexity. The result is small, but not minimal. Meanwhile modern Oberon is what you get when you go on a 40+ year quest (even though Wirth is 82 years old, the latest revision of the Oberon 07 language report was May 3rd this year! [3]) to eliminate every unnecessary feature from an Algol-style language while adding only the bare minimum in its stead. The Oberon dialects (Oberon, Oberon-2, Oberon 07 - the latter is the newest and deriving from Oberon rather than Oberon-2) are strictly smaller languages than their by now distant ancestor in Pascal, despite being substantially more powerful. Consider that the language report for Oberon-07 is 17 pages including the table of contents and introduction, and despite duplicating the language productions both in each chapter and in an appendix... I prefer less austere languages these days (Ruby...), but I wish more language designers spent more time studying Wirth's work and actually paid attention to how their design affected parsing and code generation complexity. [1] http://oberon07.com/EBNF.txt http://oberon07.com/EBNF.txt [2] http://www.quut.com/c/ANSI-C-grammar-y.html http://www.quut.com/c/ANSI-C-grammar-y.html for the Yacc grammar, and http://www.quut.com/c/ANSI-C-grammar-l-2011.html http://www.quut.com/c/ANSI-C-grammar-l-2011.html for Lex [3] https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Repor...
coldtea 10y ago
>But when you actually have to use these languages, well, they're terrible. They're C, with all its flaws, but a more indented/structured syntax. That couldn't be further from the truth.

by eudox 10y ago

_ph_ 10y ago

No, they are not C with all its flaws. They offer strict type checking, preventing a lot of constructs which would have unintended consequences when passing a C compiler. Modula introduced a proper module concept, without the need for header files without their issues, allowing for fast separate compilation of modules. Go picks up a lot of these ideas and brings them to a modern language.

vidarh 10y ago

> They're C, with all its flaws, but a more indented/structured syntax. There are many reasons to criticise aspects of Modula-2 or Oberon, but saying "they're C, with all its flaws" totally misses the mark. The entire language family belongs to a very different tradition. Wirth spent most of his career removing features, and adding much less than he removed. For good reason: Oberon as a language contains the bare minimum that his experience with systems-engineering (the OS and all applications for the Oberon systems that ran ETH Zurich for many years were written in Oberon itself) showed that they needed. This went down to the compiler: Unlike languages like C, Oberon is designed to be easy to compile. The grammar is positively tiny - it fits on 1-2 pages of A4 in a readable font, with comments. It can parsed and compiled in a single pass with a clear separation of the lexical scanner and parser, without any hacks or ambiguity, and I believe only with a single token lookahead. C isn't by any means a horrible language to compile compared to most newer languages, but compared to Oberon it's a monstrosity. This design philosophy follows through from the compiler through the support libraries, through the OS. It's austere, yes (the Oberon-07 language report is 17 pages...), and if you don't like austere languages, you won't like Oberon. But that too is a feature that separates it from C. As someone else pointed out, Go is a much better comparison than C. Oberon is garbage collected, for example, which instantly put it very much in a different "camp" to C back when it was launched, in an era where the thought of using garbage collection for a systems programming language was seen as something only the weird dynamic typing lisp and smalltalk people would consider.

Avshalom 10y ago
What it comes down to is that Wirth has always understood the difference between simple and jury-rigged in a way that Pike and the Unix crew never have.
bogomipz 10y ago
Can you elaborate on this "Unlike languages like C, Oberon is designed to be easy to compile?" I thought that was one of the reasons that C looks the way it does was to be easier to compile
- vidarh 10y ago
  I mentioned some already, but to reiterate and expand. - The grammar size. This is the complete EBNF for Oberon 07 [1]. For comparison, here is a C 2011 grammar [2]. C is quite simple to parse, but still more complex than Oberon. - The Wirth languages can generally be compiled in a single forward pass. Dialects that allow forward references tends to require them to be specifically declared. Explicitly specified forward references minimize the amount of state the compiler needs to hold on to to fix up the typically minimal amount of references, but Oberon 07 doesn't have them anyway. This doesn't matter so much now, but in the 80's it was a big deal to be able to do single pass compilation without lots of memory spent on keeping a lot of bookkeeping or a syntax tree around (the Wirth compilers typically never constructs an AST, but directly emits opcodes during parsing by calling into a code-generation module, at the cost of losing out on quite a bit of optimization opportunities; on the other hand it also makes the compilers very simple and blazing fast). - No preprocessor. - In C, the presence of typedef means that there are constructs that are semantically ambiguous until you consult the symbol table (the parsers can still be context free, but you can't fully resolve the type of symbol in certain situations until you look at the symbol table). Also not a big deal, but things add up. To be clear, C is one of the easier languages to parse. I'm not implying C is particularly complex. The verbosity of Yacc/Lex vs "straight" EBNF overstate the complexity of the C grammar somewhat. And compare it e.g. to C++ or (run...) Ruby (which I love dearly to use, but the grammar is a crime against parser writers everywhere) and it's trivial. But Oberon took it several steps further. C is what you get if you build something through accretion and gradual changes while experimenting, despite trying to contain complexity. The result is small, but not minimal. Meanwhile modern Oberon is what you get when you go on a 40+ year quest (even though Wirth is 82 years old, the latest revision of the Oberon 07 language report was May 3rd this year! [3]) to eliminate every unnecessary feature from an Algol-style language while adding only the bare minimum in its stead. The Oberon dialects (Oberon, Oberon-2, Oberon 07 - the latter is the newest and deriving from Oberon rather than Oberon-2) are strictly smaller languages than their by now distant ancestor in Pascal, despite being substantially more powerful. Consider that the language report for Oberon-07 is 17 pages including the table of contents and introduction, and despite duplicating the language productions both in each chapter and in an appendix... I prefer less austere languages these days (Ruby...), but I wish more language designers spent more time studying Wirth's work and actually paid attention to how their design affected parsing and code generation complexity. [1] http://oberon07.com/EBNF.txt http://oberon07.com/EBNF.txt [2] http://www.quut.com/c/ANSI-C-grammar-y.html http://www.quut.com/c/ANSI-C-grammar-y.html for the Yacc grammar, and http://www.quut.com/c/ANSI-C-grammar-l-2011.html http://www.quut.com/c/ANSI-C-grammar-l-2011.html for Lex [3] https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Repor...

coldtea 10y ago

>But when you actually have to use these languages, well, they're terrible. They're C, with all its flaws, but a more indented/structured syntax. That couldn't be further from the truth.