[p4bl0]

Interesting project :).

> First, let's write a standard that's as polished as it can be. Then, once the standard is ready, we can start making it real.

I've learned on several occasions that things don't actually work that way. Writing the actual code and running/testing it is the only way to ensure that your ideas will indeed work and that you didn't miss corner cases. Except of course if the problem at hand is trivial, but that's clearly not the case here, and I feel like trial and error will be much necessary.

Note that this isn't only true for code. It's about writing in general, even when doing theoretical science that doesn't translate to code in the end.

There is a PhD Comics, I think, where a character says something like "remember kids, the only difference between fooling around and doing science is writing it down". Exactly.

---------------

From the todo list:

> procedural, functional, imperative?

Authors should probably also look into reactive programming and dataflow languages such as Lustre, Esterel, ReactiveML, etc. Probably some good inspiration there for this kind of tasks :).

[mkl]

> There is a PhD Comics, I think, where a character says something like "remember kids, the only difference between fooling around and doing science is writing it down"

That's from Adam Savage on Mythbusters. Here's the exact wording and where he got it: https://imgur.com/1h3K2TT/

[ianbicking]

I think there's a lot of value to thinking things through before into a relatively formal thing like this; like probably this is already a second system... the first probably being bespoke codegen tools or something, as the docs seem to be from people who have spent some real time struggling with existing tools.

When you are doing a second system you've already experienced the architecture you get when you explore by the seat of your pants. You've built some intuition, but you've hit the point when you need larger and more formal plans.

In this case the designer may not have previously even wanted or considered writing a programming language, but realized the generality and complexity of their ambitions required the very formalism of a programming language, and then that the plan was a real part of the finished product.

[flir]

> I've learned on several occasions that things don't actually work that way.

It might work (maybe) if your goal is "reimplement a popular language but fix the mistakes". Eg "we're gonna build on [langA] but allow breaking changes and call it [langB]".

Lots of examples where that hasn't worked, but then there's lots of examples where new languages just fail regardless of pedigree.