The Siren Song of Little Languages
6 comments
·January 10, 2025eternityforest
It's so easy to get wrapped up building tools and frameworks and protocols and never do anything with them, or do anything else with your life, so I think it's important to have reasonable expectations.
Understanding what kind of things people will build with you language would probably help, so you don't waste time trying to please people who will not use your language anyway.
recursivedoubts
> The problem seems to be languages with a small, well written specification.
that’s why I’m making my language as big and poorly specified as possible:
emmanueloga_
I think it is a problem of incentives: programming languages with small, elegant specs are often created by academics, and academia and the software industry have fundamentally incompatible incentives.
tptacek
I'm not sure I understand the cryptography analogy.
oddity
It's a fun observation, but the causality in this feels off. There are tons of esoteric programming languages that are difficult to write in and no one talks about because they have no other value. BF is not very useful for writing things in, but it has some value in being easy to implement. Would anyone sane genuinely encourage others to write something nontrivial in BF? What person looks at BF and says "ah, yes, this is a language I might like to write my next spreadsheet app and networking library in, let me play around in it for a bit to see if it might work", much less follow up with "oh no, I got distracted reimplementing it instead"? On the other hand, if I'm implementing an interpreter for fun, I'm going to pick something with a nice spec and my ability to actually use it is irrelevant. BF is great for implementing a spec exactly such that all existing tests and benchmarks just work.
I think the more likely scenario in a counterfactual world where Shen and Forth are difficult to implement is not that we have more things written in Shen and Forth, but that we have strictly fewer reasons to talk about Shen and Forth.
I am not convinced that the group that builds implementations and the group that builds the kinds of things that beget ecosystems for anyone other than compiler developers actually have much overlap. I do, however, think there is a strong overlap between the group that builds implementations and terminal-stage new-language addicts. An ecosystem for other things will maybe happen later if there's some other value to the language.
Where I think the article does hit on something is slightly less direct: users are more tolerant of a messy specification than implementors. C, C++, Python, Java and all the other languages that people actually use are ugly as sin at a semantic level, and yet we get by with copious handwaving. There are many problems, of course, with some of the handwaving users do to reason about these languages (hello, many warts of C), and generally, a preference for spec a user can keep in their head is a big productivity win, but if you want a language that people can use, you can afford to make your language a bit more complicated.
TL;DR: idk, make your pretty language with a beautiful spec if you want. Most languages are unused anyway. But there probably are diminishing usability returns for maximal spec beauty. If you care about that kind of thing, that is.
Being popular is not the only goal of a programming language. Scheme is very successful language, not because it's much used but because it's small and elegant it's often used as a teaching tool and hence it has come to influence many of the designers of more popular languages.