I wrote my own “proper” programming language (2020)
mukulrathi.com
mukulrathi.com
I just wish more tooling existed that was language-agnostic so that it's easier to get off the ground with something “serious”. I'm talking debuggers, parse-tree-aware diffs, autocompletion like Intellisense, etc.
The reason indie languages never succeed is because without a strong corporate backer or other such commitment to longevity, the risk of doing anything serious in it only to have to rewrite the entire thing in the next new indie language is far too great. Or at least it should be for any seasoned engineer worth their paycheck.
Tooling helps prove that. But a strong standard library and a proven track record counts for so much more.
I'm not a "developer". I am a ham. I am not a hamster.
Now, imagine five semi-core devs of Python get together and make a compiled language.
edited because i use a local llm on my phone for speech-to-text and i was testing with nearly white noise (fans and aerated water...) "FUTO"
https://imgs.xkcd.com/comics/standards_2x.png
Sure, when everyone and his dog can publish their (soon to be unmaintained once the novelty feelings wear off) language, the world will be a better place.
I'm curious about some of the seemingly slightly oddball signs of late stage civilisation collapse and I'd not seen this one mentioned before?
And the XKCD character got the reason wrong. People aren't making languages because they think there are too many languages.
As far as I'm concerned, the more the better. I make languages because there aren't enough.
Debuggers are the outlier in your group but there's not exactly a void for those other wishes. As just one slice, building a tree-sitter [1] grammar gives the basis for good editor integration [2], formatters [3], structural diff [4] and other dev tools. Similarly if you're expressing some form of program, targeting LLVM IR connects your creation with a fairly extensive compiler toolchain.
Language agnostic tooling exists, but there still needs to be some abstraction layer and a mapping to that.
[1]: https://tree-sitter.github.io/
Huh?
Programming languages have done lots and lots of ideas.
So many that they're starting to blend together.
When you master the principles of parsing, it is straightforward to do in any language by hand with good performance. It is easy to write a function in any language that takes a range string, such as "_a-zA-Z" and returns a table of size 256 with 65-90, 95 and 97-122 set to 1 and the rest set to zero. You can build your parser easily on top of these tables (this is not necessarily optimal but it is more than good enough when you are starting).
For the backend, you can target another language that you already know. It could be javascript, c or something else. This will be much easier than targeting llvm.
Start with hello world and build up the functionality you need. In no more than 10k lines of code (and typically significantly less), you can achieve self hosting. Then you can rewrite the compiler in itself. By this point you have identified the parts of the language you like and the parts that you don't or are not carrying weight. This is the point at which maybe it makes sense to target llvm or write a custom assembly backend.
The beauty of this approach is you keep the language small from the beginning without relying on a huge pile of dependencies. For a small compiler, you do not need concurrency or other fancy features because the programs it compiles are almost definitionally small.
Now you have a language that is optimized for writing compilers that you understand intimately. You can use it to design a new language that has the fancy things you want like data race protection. Repeat the same process as before except this time you start with concurrent hello world and build in the data race protection from the beginning.
It's perhaps not a "proper" language because I targeted Javascript. So I didn't have to write the back half of the compiler. Since it's dependent typed, I had plenty of work to do with dependent pattern matching, solving implicits, a typeclass-like mechanism, etc.
Next I may do a proper backend, or I may concentrate on the front end stuff (experiment with tighter editor integration, add LSP instead of the ad hoc extension that I currently have, or maybe turn it into a query-based compiler). Lots of directions I could go in.
At the moment, I'm looking into lambda-lifting the `where` clauses (I had punted lambda lifting to JS), and adding tail call optimization. I lost Idris' TCO when I self-hosted, so I currently have to run the self-hosted version in `bun` (JavaScriptCore does TCO).
https://protobuf.dev/reference/protobuf/textformat-spec/
He most likely wants to have the type structure generated by protocol buffer as opposed to parsing JSON
The latter requires asserting in a million places that this key exists in this map with this type, which will require a million lines of crap code.
Not to mention packing and unpacking the serialized data and maintaining two separate sets of corresponding structures/records that have to be kept in sync.
Once you have the grammar, you can use it with IParse developed in C++, which produces an abstract parse tree.
IParse has a build-in scanner for C like terminals, which are now used in many languages. You can implement your own scanner. IParse also has an unparser, which allows you to generate pretty printed output with just some annotations in the grammar.