OOPSLA Conference: Growing a Language

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: ▶ this video

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

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

This Guy Steele talk is related to this topic: ▶ this 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)

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: ▶ this video We Really Don't Know How to Compute! by Gerald Sussman: link

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

Always reminds me of Guy Steele's "Growing a Language" talk - ▶ this video Think it's a great fit for IF alright.

Neat. I wonder if this was an inspiration for Guy Steele's famous "Growing a Language" talk, or if he came up with the same idea independently. ▶ this video

As someone who has been designing a language since late 2012 (and it's about to have its first public release early next year O.o), here are some thoughts. Avoid gradual typing : Absolutely. I had gradual typing and abandoned it. Gradual typing is not as good as simple Go-like inference, and that simple inference is easy to implement and takes care of 95% of the "problem." However, you also need one or more dynamic typing escape hatches. When I implemented a config file format by tweaking JSON, I had to implement dynamic typing in C. Avoid self-hosting your compiler : It depends. You probably should avoid it by default, unless your language is just so much better than the original. Rust is an example of this (compared to C++). I'm writing in C, and I want memory safety [1], so bootstrapping makes sense. Avoid writing your own code generator, linker, etc. : This is excellent advice! Use the standard tools. Of course, me being me, I'm breaking it. :) I am trying a different distribution method, where you distribute an LLVM-like IR, and the end machine then generates the machine code on first run. In that case, there's no linker necessary, but I do have to write my own code generator. Fun. Avoid bike shedding about syntax : Yes, absolutely. I did this, but the syntax still changed enormously ! Cross-platform support is a challenge : Yes, in more ways than one. First, you have to somehow generate code for all of the platforms, then you have to make sure your library works on all

Really feels like the project is spreading itself too thin. There are existing community build Package Managers for Zig. It's weird to start replacing things that are good enough™, while core stuff like the languag and compiler is not even ready for hobby projects. The zig folks should really have this talk running on a loop: ▶ this video

> What do more experienced people here think of that? "Experienced" person here. I've done a parser generator grammar or two. I've implemented several parsers. I mostly agree, but it depends on your use case. Most people writing parsers are doing so for a bespoke language, usually for config of an internal-use-only program or something like that. Such parsers won't be great, but they will work for people that: 1. Know the language, or 2. Are expected to know the language. In that case, I agree with Guy Steele. Why these two caveats? Because as people have said, error reporting from the parser will be subpar. This includes hand-written recursive descent ones. So knowing the language is important. (The second item is specifically for situations where new employees might not know the language yet, but it's part of their job, so they will learn it.) This is, by far, the greatest amount of parsers in use. I would estimate 99.5% or more. Of course, most people don't think about those parsers; they think about the hardened parsers for general-purpose languages in wide use, but while they get a lot of attention, they are few and far between. Guy Steele's advice doesn't apply as well to such situations. For me, I wrote a parser for an existing language. I had to write the parser to that, and that language had a lot of baggage. It made no sense in that case. For the parser I'm currently writing, it also makes no sense. This is for what I hope to become a widely-used general purpose lan

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