Here is the most valuable exercise I can think of for language development: write a function that produces a formatted error string that renders the location of the cause of the error and the reason for the error. Once you have this, it will be much easier to write your compiler from the ground up because every step of the way you can validate that the compiler is only handling inputs that you it expect it to and rejecting everything else.

The error reporting function is not easy to write correctly, but a decent one can be written in fewer than 100 lines of lua (and I am certain it can be done in all but the least expressive languages in under 200).

> the Gleam language, which is written in Rust and has first-party LSP support

How have I never heard of this language before?

https://gleam.run/

I've been working on lowering the bar for designing new languages lately:

https://github.com/codr7/shi

Very much a work in progress, but I hope to soon be able to provide the same minimal interpreter in Java/C/Common Lisp, each using the unique strengths of the host language.

The author mentions he decided against using Treesitter, but I’d highly recommend using it. It’s phenomenal, especially when you’re in the prototyping phase.

I wrote a parser combinator library for TypeScript that I have been having a lot of fun with [1]. It has limitations, I wouldn't use it to write a full language programming language like Gleam, but for "language-ish projects", parser combinators can be lovely to use. I used it to build a typed version of Mustache [2].

> Rather, I’m after a particular kind of software hygge: Loads instantly, doesn’t crash, and fits nicely in the hand.

The author is talking about the language, but this is what parser combinators feel like to me, and could be another option. Tarsec is probably the most fun side project I have built in a while.

[1] https://github.com/egonSchiele/tarsec

[2] https://github.com/egonSchiele/typestache

> If you graphically drag a point around, the coordinates in the source code should automatically update. If you edit the source code, the graphical UI should automatically update.

That sounds difficult.

I'm trying to think through how that would work, you would have to map language elements to geometry elements and be able to seamlessly update both on any changes. Plus be able to insert/delete elements on both the text and geometry sides including during renamings and reorderings of elemental lists.

I suppose one could treat the geometry elements as the 'model' (to use MVC parlance) and the 'view' could either be source code or UI elements generated on the fly. Maybe add some 'non-display' attributes for comments and whatnot for pretty printing the source code.

I'm sure someone much smarter than me figured out how to do this kind of thing back in the '70s.