On the Design of Programming Languages (1974) [pdf] | Hacker News Reader

On the Design of Programming Languages (1974) [pdf]

web.cs.ucdavis.edu

80 pointsjruohonen45 comments

He has some good points. This one is from a different paper (Good Ideas, Through the Looking Glass):

Designers had ignored both the issue of efficiency and that a language serves the human reader, not just the automatic parser. If a language poses difficulties to parsers, it surely also poses difficulties for the human reader. Many languages would be clearer and cleaner had their designers been forced to use a simple parsing method.

Who are Wirths, Dijkstras, Hoares, McCarthies and Keys of today? I mean - who represents current generation of such thinkers? Genuinely asking. Most stuff I see here and in other places is about blogposts, videos and rants made by contemporary "dev influencers" and bloggers (some of them very skilled and capable of course, very often more than I am), but I would like to be in touch with something more thoughtful and challenging.

very hot and edgy take: theoretical CS is vastly overrated and useless. as someone who actively studied the field, worked on contemporary CPU archs and still doing some casual PL research - asides from VERY FEW instances from theoretical CS about graphs/algos there is little to zero impact on our practical developments in the overall field since 80s. all modern day Dijkstras produce slop research about waving dynamic context into java program by converting funds into garbage papers. more deep CS research is totally lost in some type gibberish or nonsense formalisms. IMO research and science overall is in a deep crisis and I can clearly see it from CS perspective

I assume that you are talking about modern "theoretical CS", because among the "theoretical CS" papers from the fifties, sixties, seventies, and even some that are more recent I have found a lot that remain very valuable and I have seen a lot of modern programmers who either make avoidable mistakes or they implement very suboptimal solutions, just because they are no longer aware of ancient research results that were well known in the past.

I especially hate those who attempt to design new programming languages today, but then demonstrate a complete lack of awareness about the history of programming languages, by introducing a lot of design errors in their languages, which had been discussed decades ago and for which good solutions had been found at that time, but those solutions were implemented in languages that never reached the popularity of C and its descendants, so only few know about them today.

https://news.ycombinator.com/item?id=47257461

Well, I think there is something to it. Computers were at some point newly invented so research in algorithms suddenly became much more applicable. This opened up a gold mine of research opportunities. But like real life mines at some point they get depleted and then the research becomes much less interesting unless you happen to be interested in niche topics. But, of course, the paper mill needs to keep running and so does the production of PhDs.

Indeed, we don't really need affine type systems, what use could we get for them in the industry. /s

If you really have followed the research in type systems and see how it *factually* intersects with practical reality you wouldnt joke about it. Its a bizzare nonsense what they do in „research“ and sane implementations (only slightly grounded in formalisms) are actually used

I do, and hope that one day stuff like dependent types and formal proofs are every day tools, alongside our AI masters, which also don't use any learnings from scientific research.

> theoretical CS is vastly overrated and useless

> as someone who actively studied the field,

Does not compute.

Your comment is mere empty verbiage with no information.

Your critique is valid, but I am not in a mood to prove myself to anons on the internet :)

"I come to talk low-effort shit, not to think or inform". Par for the course, I suppose.

I am not the "anon" here; you are.

You made a preposterous statement, got called out, and are now making excuses.

Anybody who claims to have studied "Theoretical Computer Science" can/will never make the statements that you did (and that too in a thread to do with Niklaus Wirth's achievements who was one of the most "practical" of "theoretical computer scientists"!).

Here is wikipedia for edification - https://en.wikipedia.org/wiki/Theoretical_computer_science and https://en.wikipedia.org/wiki/Computer_science

Contemporary PL designers who have inspired my programming language design journey the most are people like Chris Granger (Eve), Jamie Brandon (Eve/Imp/others), Bret Victor (Dynamicland), Chris Lattner (Swift / Mojo), Simon Peyton Jones (GHC/Verse), Rich Hickey (Clojure), and Jonathan Edwards (Subtext). My favorite researcher is Amy J. Ko for her unique perspective on the nature of languages. Check out her language "Wordplay" which is very interesting.

Thanks for pointers

Also I just became aware of this list: https://people.futureofcoding.org

I can't claim to be equal to the greats, but I do run a Discord server where I think and talk a lot about both the philosophy and practice of language design while building tools that I hope will change the state of the art: https://discord.gg/NfMNyYN6cX

There is a lot of good computer science, but the computer science community today is vastly larger than it was in the 1960s and 1970s when Dijkstra, Knuth, Wirth, and others became legends. There are so many subfields of CS, each with its own deep literature and legendary figures. It’s difficult to be a modern Dijkstra or Knuth due to these factors, though to be fair, it is an impressive feat for Dijkstra to be Dijkstra and for Knuth to be Knuth even in their heydays. It’s just easier to get famous in an upstart field compared to getting famous in a mature field.

I think there are two typical paths to widespread visibility across CS subfields: (1) publishing a widely-adopted textbook, and (2) writing commonly-used software. For example, many computer scientists know about Patterson and Hennessy due to their famous computer architecture textbooks, and many computer scientists know about people like Jeff Dean due to their software.

Reading more academically-oriented literature such as the ACM’s monthly periodical “Communications of the ACM” is also a good way to get acquainted with the latest developments of computer science.

https://news.ycombinator.com/item?id=47257461

Researchers in Programming Languages and Compilers (a large list!) - https://www.cs.cmu.edu/~mleone/language-people.html

Programming Language Research (categorized by subjects) - https://www.cs.cmu.edu/~mleone/language-research.html

Last updated 1996.

Ah, didn't check that.

Nevertheless, a useful starting page to begin one's research from.

Somebody needs to create a similar list for current times. Maybe the co-author of "Elements of Programming" and preserver of "Software History" artifacts, named Paul McJones would be the right person? ;-)

The key, then, lies not so much in minimising the number of basic features of a language, but rather in keeping the included facilities simple to understand in all their consequences of usage and free from unexpected interactions when they are combined. A form must be found for these facilities which is convenient to remember and intuitively clear to a programmer, and which acts as a natural guidance in the formulation of [their] ideas.

We've successfully found some strong patterns for structuring programs that transform data in various ways for the kinds of programs Wirth was imagining. The best patterns have proven themselves by being replicated across languages (for example discriminated unions and pattern matching) and the worst have died away (things like goto and classical inheritance).

There's still work to do to find better languages though. A language is good if it fits the shape of the problem and, while we've found some good patterns for some shapes of problems, there are a lot more problems without good patterns.

I had hoped there'd be more languages for everyday end-user problems by now. At the start of the SaaS era it seemed like a lot of services were specific solutions that might fit into a more general modelling language. That hasn't happened yet but maybe a programming language at just the right level of abstraction could make that possible.

> and the worst have died away (things like goto and classical inheritance)

What's so wrong about classical inheritance, and how it died away while being well-supported in most popular programming languages of today (Python, C++, Java, C#, TS, Swift)?

Inheritance has its uses, but is easily overused.

In a sense, it’s like global variables. About every complex program [1] has a few of them, so languages have to support them, but you shouldn’t have too many of them, and people tend to say “don’t use globals”.

[1] some languages such as classical Java made it technically impossible to create them, but you can effectively create one with

  class Foo {
    public static int bar;
  }

If you’re opposed to that, you’ll end up with making that field non-static and introducing a singleton instance of “Foo”, again effectively creating a global.

In some Java circles, programmers will also wrap access to that field in getters and setters, and then use annotations to generate those methods, but that doesn’t make such fields non-global.

> Inheritance has its uses, but is easily overused.

This I can agree with, but it is far from being "worst pattern". Everything can be like salt.

Yes, but inheritance used to be like salt. That’s why it, like “goto” and global variables, got so much attention.

I think the legend goes Wirth created the Pascal language to be the most easily compilable. To show my age, I recall a class used Modula-2 when I was in college, also from Wirth, very Pascal-like.

> most easily compilable

I think it was more that it would be easy to write a compiler for, which meant that CS students could write one. Don't have a source for this that I can remember, though.

Nowadays you can enjoy it on GCC, as it is now an officially supported frontend, after GNU Modula-2 got merged into it.

https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gm2

Even available on compiler explorer to play with, https://godbolt.org/z/ev9Pbxn9K

Yes, that was a common trend across all programming languages designed by him.

That is also how P-Code came to be, he didn't want to create a VM for Pascal, rather the goal was to make porting easier, by requiring only a basic P-Code interpreter, it was very easy to port Pascal, a design approach he kept for Modula-2 (M-Code) and Oberon (Slim binaries).

With all due respect to Wirth, P-Code did not originate in a vacuum. Martin Richards's BCPL compiler, dating from the late 1960s, targeted a hypothetical OCode machine. Furthermore, although there were backends for this that generated good machine code on popular computers of the time, Richards also had a backend that generated a severely reduced instruction set, which he called Intcode. You could write an assembler and interpreter for Intcode in a few hundred lines of Fortran (I did), which meant you could have a slow BCPL implementation on a new machine in a day or so's work, and then you could write a better backend in BCPL.

I have never been able to determine whether Wirth knew of this work, but, given that Richards's 1969 BCPL paper described OCode, I suspect he was aware of it, and that it influenced his design of the Pascal-P compiler. (I am not sure when Intcode appeared, but it was present when I obtained the BCPL compiler in 1972, a year before the Pascal-P release.)

This is interesting!

Would you mind posting links to the relevant papers?

The original paper is probably behind a paywall. But you can have a look at an excerpt (chapter 2) from the book Virtual Machines (2006) by Iain D. Craig.

https://beckassets.blob.core.windows.net/product/readingsamp...

And there's the chapter 7 in the Richard's book (1979): https://archive.org/details/richards1979bcpl/page/n131/mode/...

You will find much more information and references at the software preservation site.

https://softwarepreservation.computerhistory.org/BCPL/

Very Nice and Thank You.

Your last link (BCPL history) contains links to a lot of papers (all?) by Martin Richards one of which is (pdf) INTCODE - An Interpretive Machine Code for BCPL which i presume was what "vincent-manis" was referring to in addition to the other papers on BCPL Language/Compiler/Manuals. Seems quite comprehensive, i must say.

We really need to publicize all of Martin Richards' contributions to computer science. He seems to be one of those unsung heroes mentioned everywhere having contributed to Languages/Compilers/VMs/OSes but not that well-known.

From the site;

BCPL—the language and systems built with it—connects the first few generations of computer scientists and software engineers, spanning mainframes to minis to micros. It was driven from the UK, but with a tributary into the heart of US research institutions, where it begat C, the most popular systems programming language of all time.

With all due respect to Martin Richards, neither did his BCPL, given that bytecodes as idea go back to compilers being developed in 1950's after FORTRAN came to be, and was already part of CPL ideas anyway.

If fact there were all operating systems written with such ideas like Burroughs B5000 in 1961, nowadays still sold by Unisys, and thanks to this approach being easily retargeted to modern hardware.

Why this "who did it first thread?" in first place?

You had commented before I created a new account, so I will just add that I have never seen Wirth claim that he or his colleagues at ETH were the originators of the idea. Moreover, this idea was already used in Wirth’s “first” language, namely Euler, which he published in 1965 while at Stanford. An even earlier example may be Schorre’s META‑II from 1964 (UCLA).

Regarding the popular opinion here that Pascal was created for educational purposes (only) - implicitly meaning not for building real, large-scale software - Wirth considered these two characteristics equivalent, and in his view one was a necessary condition for the other.

From the summary/abstract of his original publication about Pascal (The Programming Language Pascal) written in 1970 and published in Acta Informatica in 1971:

In view of its intended usage both as a convenient basis to teach programming and as an efficient tool to write large programs, emphasis was placed on keeping the number of fundamental concepts reasonably small, on a simple and systematic language structure, and on efficient implementability.

I seem to remember (but I can't find the source) that Wirth initially had three aims in designing Pascal:

1. To use it in teaching a structure programming course to new students. As in the late 60's all student programming was batch mode (submit your program to an operator to run, and pick up the printout the following day), this meant the compiler had to be single-pass and give good error messages.

2. To use it in teaching a data structures course involving new data structures worked out by Wirth and Hoare.

3. To use it in teaching a compilers course. This meant the compiler code had to be clean and understandable. Being single-pass helped in this.

Related must-read is Wirth's Turing Award Lecture; From Programming Language Design to Computer Construction (pdf) - http://pascal.hansotten.com/uploads/wirth/TuringAward.pdf

It's also worth noting that statements like

  for (i = 1; i <= 100; i++) {
    S;
    if (P) {
      break;
    }
  }

are just as bad since `break' (and `continue' and early `return') are a just gotos in disguise.

They are just gotos, but does that mean that they are bad (along with their friend try/catch, who is also a goto?), or does that mean that gotos can be useful when used with restraint?

Gotos get a bad rep because they become spaghetti when misused. But there are lots of cases where using gotos (or break/continue/early return/catch) makes your code cleaner and simpler.

Part of a programmer's job is to reason about code. By creating black and white rules like "avoid gotos", we attempt to outsource the thinking required of us out to some religious statement. We shouldn't do that.

Gotos can be useful and can lead to good code. They can also be dangerous and lead to bad code. But no "rule of thumb" or "programming principle" will save you from bad code.

Yes, break, continue, and return are all "just" gotos in disguise. But they restrict the power of the goto enough to not cause the problems that goto causes while providing a good deal of semantic power to users. Namely, all of these are essentially variations on early return (you can also throw in the logical && and || operators here, albeit they are slightly different in having two exit points rather than one--they're a fusion of if and break, essentially). And it sort of turns that there are a lot of cases where "return when any of these conditions, tested in a particular order, holds" turns out to be the most natural way to express an algorithm, and these goto-like constructs are the most natural way to write them.

(FWIW, this is essentially the argument that Knuth makes in his defense of goto paper)

The argument in the article was that the for loop is (potentially) "lying" and that is still true in my example. Niklaus Wirth's Modula-2 had a LOOP statement in which an EXIT statement could occur anywhere. That statement was at least not misleading. In Wirth's last revision of his last programming language Oberon the loop statement is removed and return is no longer a statement but a clause at the end of a function procedure. This makes Oberon a purely structured language.

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

I saw on page 25 (the third PDF page) a nice argument against variable shadowing. I can think of a couple of modern languages I wish had learned this ;)

That's an argument against references isn't it? Rather than shadowing.

Looks like AI slop to me :)

Reply on news.ycombinator.com