Hacker News Reader

Comment by msla | Hacker News Reader

I never got the big appeal of Wirth languages. When they weren't just vanilla Algol derivatives, they were making a virtue out of a performance hack (enforced define-before-use to enable single-pass compilers) or relying on non-standard variants (Turbo Pascal/Delphi) to claim that uninspiring base languages were competitive.

As an aside, Oberon-2 isn't a C++ alternative because it apparently has mandatory garbage collection, which isn't acceptable to C++ programmers now (which is why they're going to Rust instead of Go) and damned well wasn't acceptable to them in 1997, else they would have moved to Java.

View on HN

It's very simple: Simplicity.

A Wirth-style compiler for a Wirth-style language can be written fairly rapidly by a single person, and the languages, compilers and runtime systems can be easily understood. The Oberon-07 language report, including the grammar, is 17 pages.

If simplicity doesn't matter to you, then this won't appeal to you, and that's fine. I mostly use Ruby these days, whose parser (in MRI anyway) is likely longer than the whole Oberon-07 language report alone (I haven't measured, but ca. Ruby 1.8.6 the parser alone was 6k lines+), so I've surrendered the simplicity, but it still stands out to me as an ideal and inspiration.

Wirth was perhaps too ascetic in his insistence on keeping the compilers minimal, but you can fine less extreme versions carried on in extensions done in the PhD dissertations of students in his group.

> Wirth was perhaps too ascetic

Maybe too ascetic in terms of getting the most adopters, but a wonderful reminder to designers of development tools that most designs are probably far more complex than they need to be, even when optimizing for non-simplicity criteria.

So not a wasted effort!

> It's very simple: Simplicity.

Well, simplicity in a programming language is IMO only a virtue as long as it doesn't come at the cost of too much functionality, which with Pascal it surely did.

There's a reason that of C and Pascal, C is the one that survived. It's the simplicity of Pascal that ultimately killed it, since it forced any practical implementation to heavily extend the language (Turbo Pascal, Apple's Clascal, etc). Even USCD's famous P-System extended as much as it subsetted the language. What this meant is there was in practice no Pascal standard, only these isolated ecosystems which eventually died one at a time.

In contrast to Pascal, C (which was designed only a couple of years later) was functionally complete enough, even in original K&R form, that it was implemented as a standard, and the standard endured past the lifetime of any individual implementation.

The simplicity of Pascal also came at extreme cost in terms of performance and usability. For example most non-trivial Pascal programs (certainly any use for systems programming) end up using the "variant record hack" for type casts (e.g. pointer to int). So, rather than not allow type casts, Pascal allowed it but made it have a runtime cost of load/store rather than being free. Or another example - Pascal only supported value or var (passed by reference) function parameters, so if you want to efficiently pass a record or array type you'd have to pass it as "var" to avoid being copied, even if the caller wasn't meant to modify it.

Hmm.. or how about Pascal's "simple" for loops, which took the form "for i := x to y", which means you couldn't use it for "i = 0 to (N-1)" without the cost of calculating "N-1" and would have to use a while or repeat loop for that instead at the cost of readability/maintainability.

Or how about Pascal's (variable sized) "conformant array" function parameters which the language didn't allow you to pass to another function... Or how about the fact that Pascal didn't support length-1 strings (length 0 and 2+ ok, though), since it made things "simple" by regarding 'a' as a char vs 'ab' as a string (incompatible types).

Yes, it was simple, but very poorly thought out, and practically useless unless extended.

Nobody, including Wirth, wanted Pascal in its original form to survive, or at least to be in widespread use, given he iterated on it multiple times. You'll note the article is not about Pascal. For a reason. Pascal is a very different beast to the Oberon family, which proved itself - in it's unexpanded form - viable to implement both a OS and applications, whether or not you like the tradeoffs of the languages.

Focusing on Pascal is also irrelevant to the point I made, which was to answer the general point of the appeal of Wirth's languages.

But even with Oberon, Wirth doesn't seem to have learnt the usability lesson, and removed stuff like enumeration types and variant records.

I get the appeal of a simple language, but was just pointing out that in addition to compromising functionality it also lead to the death of Wirth's languages by means of there effectively being no standard.

I've probably had as much exposure to Wirth's languages as anyone:

- Learnt Algol-W in college c. 1979 - Implemented ISO-Pascal (me +1) at Acorn (UK) c.1982 - Used Modula-2 to program parts of PANOS at Acorn

Have spent the last few months programming in Acorn ISO Pascal on an 8-bit emulator (BeebEm), struck by how awful the language itself really was!

You appear to want him to have different goals for these languages than he had. That they don't have mass adoption is fine. It's not their primary value.

That said, "death" is too harsh, all the time there are multiple implementations of both Wirth-derived (the most prominent being Delphi, which is still being developed and sold) and "pure" Wirth languages available and in use. If anything, I find it more remarkable that they've been seen as much adoption as they have outside of teaching. There's even a very expensive commercial ARM implementation of Oberon-07.

It's in any case largely irrelevant to the question of their appeal.

I don't want to work in Oberon (or Pascal) any more than you do (but, to tie it back to this article, I also don't want to work in C++ unless I have to), but in terms of distilling lessons of what is needed from a language, and a learning tool, it is up there with Smalltalk and Lisp (other languages I don't want to work in) as one of a small handful of the language designs that will continue to influence for a long time to come.

And that is a large part of their appeal - not for day to day use, but for the lessons you can learn from them. I don't care if nobody uses them. I care about the research they contributed to and spawned, and what I can still learn from them.

> and removed stuff like enumeration types and variant records.

Oberon replaced variant records with extended types, type tests, and procedure variable (function pointers), sufficient to do OOP. In terms of his goal of focusing on sticking to the bare essentials, it was a good tradeoff, and it sparked novel work.

I really don't see Wirth in reality as a huge influence in the history of programming language design. All of Wirth's languages are in essence tweaks on ALGOL from which they all (starting with ALGOL-W) were derived. What's so new about any of Wirth's languages, even Oberon? OOP had already been done 20 years prior in Simula, as well as more recent pre-Oberon languages.

He certainly left his mark on the computer industry in terms of products based on his work, but would, say, a hypothetical "Turbo Algol" have been much different than "Turbo Pascal"? The popularity of Turbo Pascal (& Delphi) really had more to do with the implementation (speed, IDE, language extensions) than the base language itself.

> I really don't see Wirth in reality as a huge influence in the history of programming language design.

C# is influenced by Pascal and Modula-2 because Anders Hejlsberg had a huge hand in creating it.

Go and Lua are also quite heavily influenced by the Wirthian languages.

Ada is also a direct descendant of Pascal and Modula-2. For a while in the 80's, Ada was more popular than C++ because of the DoD standardizing on it but the DoD and NASA still use it today. NASA's Artemis project uses Ada. The Canadian air traffic controls system all run Ada.

Wirthian languages have been focused on safety for 50 years. The industry is just now catching up with safety-focused Rust as a first step. It's long overdue. C and C++ were dangerous enough offline but using them online is just asking to get hacked. Sure, safe code can be written in them but not many C and C++ programmers are capable of doing so. Why wouldn't you want a language that handled the bulk of that for you?

C# is really managed C, and the C lineage is more ALGOL -> BCPL -> B - > C

Sure Ada saw some success, and is even a pretty decent language, but I fail to see that there is much Wirth in there, certainly not his minimalist aesthetic!

Lets not forget that Wirth was on the ALGOL design group, and Pascal was initially designed as it saw ALGOL as being too complex for teaching purposes.

So there is a little bit of Wirth on ALGOL as well.

I don't believe Wirth was involved with any of the official ALGOL versions. He submitted his own proposal for an ALGOL-60 replacement which was rejected and became ALGOL-W (Wirth), which I briefly used in college c.1979. The actual successor to ALGOL-60 was ALGOL-68 which Wirth had no input on.

There's a useful language family tree on the WikiPedia ALGOL page. ALGOL is really the grandfather of all modern structured programming languages. I guess the way it was named "Algol = Algorithmic language" about says it all.

Wirth became minimalist with Oberon, which came after Modula-2 and Ada.

> What's so new about any of Wirth's languages, even Oberon?

You've been given the answer already: Simplicity. You keep ignoring it.

Both of implementation (which can be met by e.g. Smalltalk, Lisp, Scheme, Forth as well), and of usability (which some might argue the former could, but the reality is most people have gravitated towards languages closer to the ALGOL family for usability).

And yes, it's "tweaks" on ALGOL, but those tweaks mattered, in terms of simplifying implementation. ALGOL users expected gc (though it was not technicall required), Pascal users didn't (though it wasn't forbidden). ALGOL's added complexity around type checking of variants mattered. ALGOL's file IO was bizarre (giving me horrible flashbacks to Simula's equally broken IO), and ALGOL 68's definition of formatted IO took up several dozen pages of the spec... ALGOL supported user defined precedence rules for operators, which, while it's not hard to implement is significant added complicity vs. a typical hardcoded recursive descent parser for Pascal, Modula-2 or Oberon.

Having used Simula (it was compulsory for CS classes at my university way back), the OOP in Simula is really quite different and at a far higher complexity level than Oberon.

Another comment listed influence directly on languages. But the influence on languages is far broader in terms of the simplicity of the languages being a facilitator for an explosion in language designs. It was seeing the ENBF for Pascal that got me to start experimenting with parsers and compilers, for example, because the simplicity made it clear that it was possible for a hobbyist to create their own from scratch. The existence of simple Wirth-language compilers made experimentation easy - I spent too much of my teen years looking at compiler source, and the Pascal compilers were easy to understand and modify. I wrote my first expression parser in Pascal, and my first code generator, and soon I ended up bootstrapping my own Pascal-inspired language.

Simplicity matters.

It's easy to forget that now when we have decades of hardware progress and orders of magnitude more RAM and CPU to work with, and decades of additional books and resources on how to build compilers using methods that were computationally infeasible at the time.

The existence of very simple compilers and languages has also been part and parcel of a lot of work at ETHZ that is not part of the Wirth languages themselves, but that was enabled by having access to simple languages as a foundation. Personal favourites of mine is work such as Franz' work on Semantic Dictionary Encoding, which led to his work on JVM JIT's etc.. Franz' student Andreas Gal came up with trace trees [1]. Brandis did fantastic work on showing a wide range of optimisations could be added to Oberon at a fraction of the complexity of the similar optimisations in gcc at the time. Mossenbock and Brandis did excellent work on SSA generation. Franz did simple but excellent work on protocol extension (dynamically propagating method overrides at runtime; I used parts of that in my experimental/unfinished Ruby compiler). There were many more. Some undoubtedly would have happened with more complex compilers to work on as well, but if you read the reports and dissertations from that period at ETHZ you also see plainly the influence that Wirth's approach carried over in the students subsequent approaches and focus on simplicity.

> a hypothetical "Turbo Algol" have been much different than "Turbo Pascal"?

It would have been slower and too big, and so lost a significant part of what made Turbo Pascal important.

In terms of implementation being more important, the speed etc. of Turbo Pascal depended heavily on the simplicity of compilation. Being able to keep the source, the compiler, the editor and the compiled object code in memory at once was a big deal facilitated by the extreme simplicity of the language.

[1] "Incremental Dynamic Code Generation with Trace Trees", Andreas Gal, Michael Franz, 2006: https://static.aminer.org/pdf/PDF/000/286/022/profile_driven...

Well, OK, and I certainly can't refute personal experience even if I don't totally understand it.

I played with C parsers (using my own parser generator ... written in Modula-2 as it happens) back in '82 and never found the grammar overly intimidating. Of course you're familiar, but just do a quick scroll up and down to remind yourself of the length (or lack of it):

https://cs.wmich.edu/~gupta/teaching/cs4850/sumII06/The%20sy...

And it seems 25% of that is the expression syntax which really would be better (more efficiently) handled outside of the grammar via precedence climbing (which would also neatly handle Algol's user-defined precedence), and which would result in a smaller parser as well as faster one.

As far as I/O, not sure that Pascal had too much to crow about there ... you could open files, but not close them, no way to associate a filename with a file, a need to put any non-temporary file as a program parameter, the odd file buffer variable concept, with an equally odd syntax treating file types as if they were pointers to the element type...

A language that fascinated me at the time, but I never got to play with was Occam - designed specifically for the Transputer which was really way ahead of it's time and never caught on.

> I don't want to work in Oberon (or Pascal) any more than you do (but, to tie it back to this article, I also don't want to work in C++ unless I have to), but in terms of distilling lessons of what is needed from a language, and a learning tool, it is up there with Smalltalk and Lisp (other languages I don't want to work in) as one of a small handful of the language designs that will continue to influence for a long time to come.

Other languages did simplicity better without sacrificing expressiveness by allowing natural extensions of the language. Wirth languages, by being Algol-derived, are overly-complex syntactically in ways that make them non-extensible, and possess ill-considered semantics on top of that.

Pascal was designed for learning programming concepts, not for real world use. Others modified it for real world use but Modula-2 was designed for real world use and is a huge improvement over Pascal.

Here is the specification for the latest version of the original Oberon language (also called Oberon-07):

http://miasap.se/obnc/oberon-report.html

It is also worth mentioning that Oberon-07 is a purely structured language in the sense that each sequence of statements is either fully executed or not executed; the only exception is ASSERT(FALSE) which halts the program.

So in Oberon:

  WHILE i < 100 DO
     ...
  END
  (*Is i >= 100 here? Yes of course, otherwise the loop guard would be lying.*)

In C:

  while (i < 100) {
     ...
     if (i >= 10) break;
     ...
  }
  /*Is i >= 100 here? No, not necessarily. Why is the loop guard lying then?*/

in 01997 it was acceptable to them and that's why most of them did move to java, once hotspot came out if not earlier

c++ projects today are very different from c++ projects in the 01990s when basically all 'serious' software was either c++ or c

a lot of c++ projects in the 01990s were what we think of now as java projects or c# projects (or django projects): line-of-business systems full of boilerplate and shitty architecture, not streamlined mega-optimized aaa game engines or web browsers

c++ projects today are the niche that was left over, which is, yeah, basically the cases where you can't afford gc

— ⁂ —

the appeal of wirth languages is that you get 90% of the value of a monstrosity like pl/i or c++ for about 5% of the complexity

language complexity hurts you three times: when you are learning the language, when you are choosing a compiler, and when you are debugging your code

so actually sometimes you get 200% of the value of a monstrosity like pl/i or c++

hopefully at some point someone will develop a wirthified version of rust, but i don't think wirth will do it this time

>in 01997 it was acceptable to them >c++ projects today are very different from c++ projects in the 01990s >a lot of c++ projects in the 01990s

You got the year wrong with that '0' prefix. The decade you're referring to is the 11990s.

This might be the finest criticism I've seen of attempts to extend the Christian epoch forward or backwards.

For those that don't know, my comment is based on the Holocene Era calendar, aka Human era calendar (HE). Basically, human civilization started roughly 12k years ago, in ~-10000BCE. The HE calendar lets us express all human-era events using positive numbers, and does so in a way that just tacks a '1' onto the popular Gregorian calendar so it's very easy to convert.

https://en.m.wikipedia.org/wiki/Holocene_calendar

https://longnow.org/ideas/long-now-years-five-digit-dates-an...

Good luck getting people to agree on anything.

Maybe we could start the epoch from when Homo erectus invented fire two million years ago and align with the Christian era for convenience.

So this is now the year 2,002,023 FE (Fire Era).

> c++ projects today are very different from c++ projects in the 01990s when basically all 'serious' software was either c++ or c

As an example, as late as '99, my first large web application was C++, and that was not an unusual choice at the time.

I worked on a greenfield web application in C++ last year. It still is a viable choice for web backend even today.

Depends on how much effort is done in security.

Most of the stuff I have exposed to the Internet written in C or C++, has done so by using a safer managed language and only accessing the native code via libraries.

Naturally there is the issue of on which language those runtimes were written on, but even so, the trusted computing base is much smaller than having the application fully written in C++, with possible C idioms while parsing data coming out of the network.

My own reason for preferring lightweight languages like Python over C++ for web services is not security but flexibility: it takes more code to do things in C++, and it takes more work to debug that code when the program is small. The things you get in exchange (mostly performance, since callability from an FFI is not a consideration) are often not worth it. Most web services I've worked on have a much harder time meeting the demands on their flexibility than those on their performance.

Back in the 90s when Modula 2 was that latest thing, the selling point was that it was as efficient as C (in theory), but safer. The Wirth languages were called 'bondage and discipline' languages for the safety they offered to beginning programmers. No buffer overflows, and you could specify a metres type and be assured that someone wouldn't accidentally cast an variable of type yards to it. It also offered modular programming with implementation hiding.

Safety wasn't fashionable back then

Computers were slow so speed meant a lot more. We should have switched back to safe languages when we started networking.

The typical excuse if we ignore what was happening outside Bell Labs in systems programming.

It is acceptable to those that use Unreal C++ and C++/CLI.

Many did move to Java (or .NET), that is one of the reasons C++ is hardly seen in distributed computing stacks 20 years later, or most CNCF projects, other than existing OSes and RDMS.

Those targeting OSes like Android, or ChromeOS, hardly have an option, unless they feel like using their own OpenGL/Vulkan based GUI, and create JNI wrappers (or JS callbacks) for like 80% of the OS surface .

Reply on news.ycombinator.com