OOPSLA Conference: Growing a Language

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

in “Loreline – Tools for writing interactive fiction” · View on HN

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

in “Aesop in Words of One Syllable” · View on HN

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

in “A decade of developing a programming language” · View on HN

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

in “Zig Package Manager MVP” · View on HN

> 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

in “We Need to Know LR and Recursive Descent Parsing Techniques” · View on HN

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

in “Ask HN: If you designed a new programming language, what would its features be?” · View on HN

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

in “What memory model should Rust use?” · View on HN