OOPSLA Conference: Growing a Language

In case anyone hasn't seen this most excellent talk on this topic, I highly recommend: Guy Steele - Growing a Language (OOPSLA '98) [VIDEO]

This is an excellent talk, and exactly where my mind went, too. I might suggest watching this upload of it instead, to avoid capture errors in the older upload: [VIDEO]

For some reason that version has a large number of audio glitches. But very recently the Computer History Museum published a cleaned-up version: [VIDEO] Good!

Not writing, but I have found all of Brett Victor's speeches to be incredibly inspiring on how I think about what I want to work on and where we're going. Inventing on Principle by Brett Victor: [LINK] Growing a Language by Guy Steele: [VIDEO] We Really Don't Know How to Compute! by Gerald Sussman: [LINK]

This Guy Steele talk is related to this topic: [VIDEO] A good watch for the fine people in this thread (and please ignore explicit or implied linkages to Java--it's full of the broad concepts, not narrowly JVM stuff)

It’s a tragedy. I feel the work they were doing was important. At least we got this talk from guy steele [VIDEO]

Funny you ask that, because I am making a programming language! (1) Structured concurrency, best explained at [1], [2], [3], and [4]. More on this later. (2) Extensibility. Most people think that this means macros. It doesn't. However it's done, as curryst said, languages are not perfect, and extending a language is important. See "Growing a Language" by Guy Steele, Jr. [5] More on this later. (3) Like many other posts, having real-world units like feet, meters, pounds, kilograms, etc., for calculations and type checking, but the default number type should also be a BigRational. (4) Ranged types, like Ada, allowing programmers to explicitly limit the range a type can be, eliminating errors. For example, a type that is used in the denominator of a division could be restricted to being not zero, and you don't need to worry about divide-by-zero for those divisions. (5) Consistency, a massively underrated feature. The use of something in the language should be the same everywhere . This simplifies learning and makes it easier to understand features you haven't seen yet. (6) Design-by-Contract and other formal methods "in the small". It should be possible to use formal methods on little pieces of code. Even if you can't go so far as to prove them correct, it should be easy to increase your confidence that they are. (7) Conditions and restarts instead of exceptions. Conditions and restarts come from Lisp, and it is one of the greatest ideas in computer science that almost nobody kn

The shallowness of rusts correctness has pretty much killed my interest in it. Much of its purported virtue seems to be mostly lore and myth, and doesn't keep its promises under close inspection and scrutiny. For example the "Rustonomicon" is only half finished and doesn't have that much real insight that couldn't be gained from a lot of basic-ish rust tutorials. The memory model is not propery defined and only kinda sorta borrowed from C++ as the article mentions. The borrow checker has only been formally specified and veryfied in a much simplified form and only very recently [2] ,with the actual model "just being what the borrow checker implementation does". Having a fancy datalog based borrow checker is cool, but I'd much rather have a formal specifiation of the semantics. Rust took the big bang approach of building everything at once, implementing stuff first without any formal semantics and just floating on an iceberg of implementation definedness, with endless discussions on how things COULD be formalized. That's pretty much the antithesis to rusts safety philosophy; it's teaching water but drinking barrels of wine. It wants your code to be well defined and follow its rules, but its rules are completely arbitrary, not properly defined nor written down. I wish instead they had just started with a small borrow checked core language, and grown it from there, like described in Guy Steeles talk on "growing a language" [1]. I feel that Zig is doing a much better job in this r