4 years ago by open-source-ux
One principle that Niklaus Wirth has always espoused and with which I agree: you cannot reduce the complexity of a programming language by expanding the size of the language with greater features. This sounds like a contradiction, but as Wirth says in the preface to his Oberon programming tutorial:
"The language Oberon emerged from the urge to reduce the complexity of programming languages, of Modula in particular. This effort resulted in a remarkably concise language. The extent of Oberon, the number of its features and constructs, is smaller even than that of Pascal. Yet it is considerably more powerful."
The FreePascal of today has grown considerably over time. The same can be said of many popular languages today: PHP, Ruby, Python, C#, Javascript, etc. Some languages start big from the beginning (e.g. Ada).
With large languages there is also the feeling you've only learned a subset of the language, blissfully unaware of many other features the language offers. At least with smaller languages you have a greater chance to master the language whole.
Of course, it doesn't automatically follow that a smaller language will be simpler or easier to grasp. (There is plenty of argument surrounding Go's supposed simplicity.)
4 years ago by choeger
At some point the language becomes so small that the true featureset is hidden in libraries or extensions.
Prime example: Lisp. The language has the smallest possible syntax, but its semantics are mostly in special forms. If you don't know the exact meaning of all special forms, you don't know the language.
4 years ago by Rochus
Right. To claim that Lisp is more flexible than any other programming language is like claiming that you are much more flexible at the atomic level than at the molecular level. Flexibility has its price. It's always a trade-off.
4 years ago by dhosek
Ada was a real bear of a language. When it was introduced as the language of instruction in some class at UIC back in the 80s, students had to work on teams as a single compilation was enough to consume the weekly CPU time allocation for a student account on the VM/CMS mainframe. They had to set up file sharing between accounts and move to a new account with each new day's login. I think there were a few cases where students ran out of CPU time even with pooled accounts before they could complete an assignment.
4 years ago by Koshkin
One of the nice things about Oberon-07 is that the compiler Iâve played with could compile itself and the standard library all in a tiny fraction of a second.
4 years ago by lboasso
When I benchmarked oberonc [0], an oberon-07 self-hosting compiler for the JVM, it took about 100 ms with a hot VM on a old Intel i5 @ 2.80GHz. That compiler follows the same one-pass compilation approach.
4 years ago by anta40
I take a look at the list and found this: https://github.com/prospero78/Oberon07ru
Looks interesting. I wonder how hard/easy to port this to Linux/Mac, for example.
4 years ago by Koshkin
I think Krotovâs is the one that I have tried. The package includes (or used to include) a simple IDE (a code editor) also written in Oberon, which provides another good example.
https://github.com/AntKrotov/oberon-07-compiler
Linux seems to be supported.
4 years ago by MarcusE1W
If you are looking for a Oberon compiler that is easy to port then you could consider OBNC.
The compiler is written in C and should compile on many POSIX compatible systems. Works like a charm on the Pinebook Pro for example.
4 years ago by amedvednikov
V compiles itself in 150 ms on my machine.
0.6 seconds on a free tier AWS instance:
4 years ago by bvrmn
^^ We can insert that message as a definition of shameless plug in a dictionary.
4 years ago by pjmlp
Note that before Oberon-7 happened, after Oberon came Oberon-2, Component Pascal, Active Oberon and Zonnon.
Although Wirth seems to only have been involved with Oberon-2 and Component Pascal.
4 years ago by ggm
The Pascal compiler on UNIX (v7, 4.1BSD) was idiomatic. I think probably no more than any other language, but enough to make me (graduate from York, a pascal teaching university) put off by micro-differences from what I learned.
The uplift to C was simpler in some ways. Why use a confusing port which winds up having to call C system libraries, when you can code directly in the language the system libraries is coded in?
Fortran, oddly, this wasn't such a big deal. Maybe the bulk of necessary code in Fortran meant the barrier to entry was lower.
4 years ago by undefined
4 years ago by rramadass
Must read paper by Wirth : A Plea for Lean Software. The more the industry "advances" the more relevant this becomes.
4 years ago by mro_name
yes, see the pdf via https://news.ycombinator.com/item?id=24059704
4 years ago by eatonphil
If you're interested in more Wirth I recommend his book, Compiler Construction. It's a great small piece on building a language from scratch.
4 years ago by lboasso
When I read this book I had an hard time running and compiling the source code included. If you want to read the book and try out the example compiler (oberon0), you can follow the instructions here: https://github.com/lboasso/oberon0. You just need a JVM >= 8 and the oberonc compiler: https://github.com/lboasso/oberonc
4 years ago by setpatchaddress
Second this. Much easier to follow than the dragon book. And youâll end up with a better implementation if you follow Wirth vs the YACC dudes.
4 years ago by Rochus
Primarily because it omits many essential things and focuses on only one (now outdated) architecture.
4 years ago by gatestone
There is a lot of Wirth influence in Go, like âgoroutinesâ, and Oberon style type embedding. Google Go team including Rob Pike are fans of Wirth, and Robert Griesemer actually comes from ETH.
4 years ago by Rochus
> a lot of Wirth influence in Go, like âgoroutinesâ
Go inherited a lot from Oberon, but definitely not goroutines; rather e.g. the separate declarations of methods from the type declaration and the type binding syntax (which was actually an idea by H. Mössenböck, implemented in Oberon-2 in 1991, see e.g. ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/1xx/160.pdf).
4 years ago by pjmlp
Well, between Oberon and Go, there is Active Oberon, which has co-routines.
Although goroutines are already in Limbo.
4 years ago by Rochus
The author of Active Oberon is Patrik Reali in the group of J. Gutknecht. Gutknecht (not Wirth) started to extend the Oberon language with direct support for concurrency and active objects (see e.g. https://link.springer.com/chapter/10.1007/3-540-62599-2_41). There were coroutine libraries for Oberon, but it was not part of Wirth's Oberon language. I don't think the concurrency support of Active Oberon has much in common with goroutines (but a lot in common e.g. with Ada protected objects). Modula-2 inherited its coroutine support from earlier languages (Mesa, Simula).
4 years ago by Rochus
Apparently channels (incl. "mk" instead of "make"), the communication operator "<-", the "select" statement and "goroutines" (using "begin" instead of "go") were already present in http://swtch.com/~rsc/thread/newsqueak.pdf in 1994, even before Limbo.
4 years ago by jhoechtl
If Wirth would have been an US resident, working at UC or MIT, Delphi would have taken over the world instead of C and descendants.
4 years ago by sgt101
I think Delphi got caught out by the coupling of the IDE and the need to support that maintenance - GNU C++ was a shot across the bows, but when Java came that business model sank.
Unfortunately. Pascal and decedents have a lot going for them.
4 years ago by noir_lord
The pricing model was weird as well.
For commercial development it was either cheap or hugely expensive there wasn't much in the middle - that was the norm when it was created but they failed to react to the move to a different pricing model during it's heyday.
4 years ago by benibela
And it is not open-source
Nowadays most people refuse to pay for languages at all, when there are open-source languages.
4 years ago by AnimalMuppet
Baloney. Borland was running Delphi. Having Wirth 3000 miles nearer would have made very little difference.
4 years ago by p_l
The main competitor of Delphi ultimately was Visual Studio, especially VB and later VC#.
And it was the mess that Borland (by then bough up, I think) made with Delphi 8 that was critical in decline of Delphi.
4 years ago by mattgreenrocks
I grew up using big languages. Hell, my first language was Perl, then I learned C++. Recent languages I liked are Haskell and Rust.
I'm a bit concerned that my technical aesthetics gravitate towards these types of languages. I really like the ideas and design of things like Scheme and C (and I use the latter when possible). Though I suspect I admire their simplicity from an ease of implementation POV more than day-to-day usage.
But I never actually sit down and study why something like Oberon is better from a design standpoint. I just nod my head at the simplicity bullet point, and go right back into worrying about insanity like "can I std::move this smart pointer in a copy constructor" with remarkably little cognitive dissonance.
I think what I'm asking is: have you had luck using a language with a lean, Wirth-style design? I tend to fixate on what those languages lack (e.g. Go's lack of generics) vs you get in return.
4 years ago by AnimalMuppet
Languages with all the bells and whistles make you worry about how all the things interact in the situation you're dealing with (like your std::move example). A simple language can be much easier to reason about, because there's less to reason about.
On the other hand, if the simple language doesn't have what you need, then you have to do it yourself. Worse, if the language tries to "protect you from yourself" (as Wirth languages tended to), the language may block you from doing it yourself.
To me, that was the most frustrating problem with the original (pre Turbo) Pascal. Some guy thousands of miles away, who knew zero about my circumstances, was deciding what his language would allow me to do. When you're on the wrong end of that, it's very frustrating.
So I would say that either large or small languages can work, they just have different trade-offs. But avoid languages that try to restrict what you are allowed to do, even if they do it "for your own good". Languages need escape hatches. If they're clearly marked in the code, that's even better.
4 years ago by Rochus
> why something like Oberon is better from a design standpoint
It's not "better". Wirth simply left out everything that did not seem absolutely necessary to him at the time. His colleague and he wanted to save work by doing this, i.e. to make their Oberon project at that time feasible for two developers on a part-time basis. With Oberon-07 he went even a step further in that direction.
4 years ago by peter_d_sherman
>"On this website you will find information on Pascal for small machines, like Wirth compilers, the UCSD Pascal system, many scanned books and other files on UCSD Pascal, Pascal on MSX and CP/M, Delphi programming on PC, Freepascal and lazarus on Windows and Raspberry Pi, Oberon systems.
Many sources of early Pascal compilers!"
[...]
"WIRTH (1)1970- Pascal compilers, the P2-P4 compilers, Pascal-S, student VU Pascal (the forerunnner of the Amsterdam Compiler Kit), Andrew Tanenbaum, Professor R.P van de Riet.
1980 â UCSD P-System, Turbo Pascal, Pascal-M, 10 years VAX/VMS Pascal programmer, teacher of the Teleac support course Pascal, teacher and examinator Exin/Novi T5 Pascal
1990 â Turbo Pascal 3 on CP/M to Delphi on Windows
2010 â Freepascal + Lazarus on Windows and Linux"
Daily digest email
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.