
Oberon 07 compiler – written in JavaScript and translates to JavaScript - colinprince
https://github.com/vladfolts/oberonjs
======
erikpukinskis
For anyone who doesn't know what Oberon is:

"Oberon is a general-purpose programming language created in 1986 by Professor
Niklaus Wirth and the latest member of the Wirthian family of ALGOL-like
languages (Euler, Algol-W, Pascal, Modula, and Modula-2). Oberon was the
result of a concentrated effort to increase the power of Modula-2, the direct
successor of Pascal, and simultaneously to reduce its complexity."

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

~~~
vidarh
> and simultaneously to reduce its complexity

This is one of things I admire about Wirth. Through most of his career, he
seems to have removed more from his languages than he added. Oberon is like
the end result of a serious of very careful incisions. It's austere, but it's
austere for very specific reasons: What he removed, he tended to remove
because he either found through extensive experience with the languages that
it did not add much, or because implementing it in an obvious, efficient way
was tricky.

Famously, he also strictly enforced his simplicity also on the compilers, by
insisting that e.g. things like optimizations should "pay for themselves" by
speeding up the compilation of the compiler itself more than the extra code in
the compiler would slow it down (though it is of course worth keeping in mind
that the official compilers were part of a computer science curriculum, not
commercial products).

~~~
pjmlp
Kind of, you are forgetting the startup that ETHZ sponsored with Component
Pascal and the fact that Oberon (the OS) was actively used at ETHZ IT
department, not only for teaching. :)

~~~
i_don_t_know
Apparently, it didn't lead to a sustainable business model. (Well, they seem
to have made it work for a surprisingly long time.) But eventually the company
abandoned the product and made it available for free:
[http://www.oberon.ch/blackbox.html](http://www.oberon.ch/blackbox.html)

Also, I _think_ there is still quite an active community around BlackBox in
Russia. Unfortunately, I don't speak Russian and cannot really provide any
links to their forums, etc.

~~~
pjmlp
That has been the problem with Wirth languages, he has written on an essay
that he was kind of naïve to think that people would care for quality and
flock to Algol derived languages.

The Russians are quite active in all Oberon derived languages, not only CP.

[http://oberoncore.ru/](http://oberoncore.ru/)

[http://www.inr.ac.ru/~blackbox/](http://www.inr.ac.ru/~blackbox/)

[http://www.inr.ac.ru/~info21/](http://www.inr.ac.ru/~info21/)

------
Koshkin
One of the interesting features of Oberon the language is that its syntax
allows for very fast compilation times, to the point that on today's hardware
there is little need in storing library modules' code in the form of binary
objects. For example, building the Oberon compiler from its sources and the
sources of the Oberon standard library (all written in Oberon) only takes a
fraction of a _second_.

~~~
nine_k
AFAICT it was one of design goals, considering the hardware. I remember how a
Pascal compileron a PDP-11 would tell me "15 KB used" upon compilation. It
seemed to only keep the relevant part of symbol table,plus a small work area,
in RAM. Everything else went straight to disk as machine code.

~~~
vidarh
The common workaround for this kind of thing for other languages was to either
write to disk in between multiple passes and/or load code for one pass at a
time. We still have multiple passes in many compiler toolchains in the form of
compiler->assembler->linker, but there were older compilers with ridiculous
numbers of passes out of sheer necessity.

E.g. here is a HN discussion about a 63 pass compiler for the IBM 1401 [1]

(There's been a resurgence in interest in multiple passes in the form of
"nanopass" architectures, but today that's driven out of a desire to simplify
code, whereas before it used to be out of a need to minimize memory use or
even fit the code needed in memory)

But, yes, this is one of the drivers in a lot of older languages, but
particularly the Wirth-ian ones, for declarations before use, etc. so that the
language can be easily parsed and compiled in a single pass. The Wirth
compilers typically didn't build an AST either.

[1]
[https://news.ycombinator.com/item?id=9289070](https://news.ycombinator.com/item?id=9289070)

------
vidarh
The page says it's written in Oberon "with extensions", and compiled to
Javascript, not written in javascript.

(not a criticism, by the way - to me that makes it more interesting...)

------
yazan94
Are lesser known languages such as Oberon really commercially used? Or are
they more academic in nature?

~~~
pjmlp
Yes they are used commercially.

CFB Software, an Australian company, exists since 1997 selling Oberon
compilers for ARM Cortex-M3, Cortex-M4, Cortex-M7 Microcontrollers and Xilinx
FPGA Systems.

[http://www.astrobe.com/default.htm](http://www.astrobe.com/default.htm)

Systems programming language with GC support, running on tiny device boards.

------
tomcam
Wonderful! Syntax feels very much like Oberon. But I couldn't find which
version of Oberon it extends.

~~~
vidarh
It's not clear - the documentation references both "original Oberon" and
Oberon 07. But the differences between the original release and Oberon 07 are
very tiny, and the additions his "Eberon" [1] makes are bigger, so I think the
extensions probably dominates the changes anyway.

[1]
[https://github.com/vladfolts/oberonjs/wiki/Eberon](https://github.com/vladfolts/oberonjs/wiki/Eberon)

~~~
mhd
Oberon 07 actually _removed_ features -- like multiple return statements...

The extensions on the other hand seem pretty hefty, and I'd be worried that
they change the language's character a bit too much. Some of that seems to be
necessary for JavaScript interaction, though. Then again, one probably doesn't
pick Oberon if one enjoys working with the current weird OOP/FP/FRP morass.

~~~
pjmlp
> Then again, one probably doesn't pick Oberon if one enjoys working with the
> current weird OOP/FP/FRP morass.

I am passionate about Oberon, collect all Wirth related papers and enjoyed
using Native Oberon back in the day, when the OS was made available on the
PCs, around 1996 or so.

He is one of my "idols" in history of computing and I even had the opportunity
to meet him once, as he gave an Oberon conference at CERN.

However, I have learned many paradigms and languages since those days, to be
happy just doing plain Oberon on the job.

Nowadays any JVM or .NET language is more my kind of thing for it, the only
thing missing is standard AOT compilation as part of their canonical
toolchains, but that is slowly being taken care of.

At least some of his ideas regarding safe OS architectures seem to live on
those runtimes, and MSR work.

~~~
mhd
I read my previous post again and just wanted to make clear that this "morass"
was referring specifically to the JavaScript "landscape", not the paradigms in
general...

And yeah, I remember Native Oberon, too. In the mid-90s it seemed much more
open about what OS was taking over. Win95 just came out, OS/2 was still an
alternative (Warp), Linux was making the rounds, and then some oddballs like
Oberon or QNX...

Marrying Oberon with the browse feels a bit weird, though. The ETHZ
workstations were rather reductionist, and hosting that on a modern browser
stack... (For a double whammy, one could write the backend in Go, the mirror
universe Oberon)

~~~
pjmlp
> For a double whammy, one could write the backend in Go, the mirror universe
> Oberon

Fully agree, _Goberon_ for lack of more imaginative name. :)

I guess for that to be fully possible, the plugin package needs to be better
supported, as it still is a bit WIP and rather fresh.

Then it would be "only" a matter of porting the runtime to bare metal. :)

