
A basic forking server in Oberon-2 - eatonphil
https://github.com/norayr/voc/tree/master/src/test/server
======
mizzao
Any comment on what is so special about this?

~~~
nine_k
If you ever wondered where Go took a lot of good ideas from, look at Modula /
Oberon.

~~~
theamk
In the code the link points to, I just see another C-like language.

What "good ideas" should I be looking at? I am not Oberon expert, but in any
other language I'd say this code is pretty bad:

\- logic errors: We keep going even if error occurs (none of the error checks
have return in them).

\- In two different source files, "System" is imported under two different
names. Is this just to confuse the readers?

\- Hardcoded string length (Mod.s:17). If someone to change the message, you
have to be very careful to update the length.

\- Arbitrary constants (why '2' in Mod.s:23)?

~~~
soapdog
Oberon and its siblings are awesome. I believe that to fully appreciate Oberon
& friends, you need to have a bit of context on its creation and usage.

Oberon is a language by Niklaus Wirth, so it is not a C-like language, it is a
different branch of the Algol family, it is the Pascal branch were we have
Pascal, Modula and Oberon (in their different versions).

This family of languages are very easy to port and to construct performant
compilers. They are not only easy to learn from a student point of view but
also can be used for real useful work.

In its home university in Zurich, they created the oberon system which is a
computer hardware, operating system, programming language and userland
applications solution that they used all over the university. This was done
when GUIs and the Mac were in its starting years (circa 1987).

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.

If you're interested in exploring things further here are some links:

[https://en.wikipedia.org/wiki/Oberon_(operating_system)](https://en.wikipedia.org/wiki/Oberon_\(operating_system\))

[https://schierlm.github.io/OberonEmulator/](https://schierlm.github.io/OberonEmulator/)

[http://www.projectoberon.com/](http://www.projectoberon.com/)

~~~
eudox
>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.

~~~
vidarh
> 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.

~~~
bogomipz
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
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.Repor...](https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf)

~~~
bogomipz
Thanks for the detailed response. I appreciate it. I intend to look into this
branch a little more when I have some time. Cheers.

------
photigragraphy
In college I wrote a (miserable) Modula-2 compiler. Its funny seeing Oberon-2
being used in the wild but brings back a touch of nostalgia.

------
asimuvPR
OT: This is very nice code. It reads very well.

------
zerr
How do you type these ALL CAPS keywords, isn't this very daunting?

~~~
vidarh
Significant caps or caps used by convention to separate syntactic elements was
quite common for a while when syntax highlighting was still relatively rare.
E.g. AmigaE [1] is another language which heavily used caps (correct case was
a compulsory part of the syntax).

You get used to it quickly, but I can't say I miss it.

[1] [http://strlen.com/amiga-e](http://strlen.com/amiga-e)

------
guitarbill
caps in file extensions, how weird

