I'll take the bait and provide evidence on why you should write a programming language.
First, it's technically very difficult, but you will gain deeper insight into the art of the craft. So, if you are a TC chaser or career minded person, then spending half a year writing a language will help you master the coding aspect of the game. I've started many languages since I started college, and each one was instructional. (I'm now 40 and an early retiree)
Second, it's fun.
Third, it may turn into something new. If some people don't write a new programming language, then we are stuck with what we have. This advice basically admits that the status quo is good enough.
The authors saying that the language, as a project, is a lifetime appointment? Well, this reveals everything. I believe if you want to do a programming language, then you must be willing to invest at least a decade or two.
So, here, I am at forty preparing to launch a SaaS around a language that I designed ( http://www.adama-lang.org/ ). The kicker, I believe, is that a project like this requires wandering the desert alone for quite a while.
I'm preparing to launch, and I just started to load test my shiny new production cluster. Low and behold, it sucks. Fortunately, I have a tremendous number of dashboards and isolated it to how I'm interacting with RDS. I've got my work cut out for me which I'll write about.
However, I have a potentially interesting business precisely because I evolved a language which solved a niche use-case. The number of problems that I have had to solve up to this point is not for the faint of heart. Life and reality are harsh mistresses.
So, maybe, yes, you can save yourself some heartache by not writing a language. Perhaps, a better way to think or phase this is "Writing a programming language is a lonely affair that will most likely end in tragedy after a long death march".
With respect to your first point, I'm reminded of Peter Alvaro's comment "the only good reason to design a programming language is to shape your understanding of the problem". He points out that he was the only user of his first PL, but he had no regrets of about that, because it shaped all his later thought in his research.
> Third, it may turn into something new. If some people don't write a new programming language, then we are stuck with what we have. This advice basically admits that the status quo is good enough... The authors saying that the language, as a project, is a lifetime appointment? Well, this reveals everything. I believe if you want to do a programming language, then you must be willing to invest at least a decade or two.
Sounds like someone should persuade some big-name university to hand out honorary PhDs to people who build new languages that produce demonstrable value (even if the value is not business value).
To solve a problem about 23 years ago I wrote a programming language + interpreter. It was meant to be a simple language to write phone surveys in, so basically a kind of DSL for a single purpose. The programmers who built the survey taking system that would use my language discovered they could write much of it in the language itself, which surprised me a lot. Was a really fun project. No idea what happened to it.
The problem with writing a _general-purpose_ programming language (as a solo-developer), is the fact that writing the language (i.e defining the syntax+semantics, writing the parser/compiler) is only half the battle - the rest of your time is spent on less technically interesting QoL features, like an IDE, standard library, debugger, syntax highlighting etc. which are nonetheless vital for making the programming language actually usable. (I still think writing your own PL is a useful exercise just to see how the sausage is made, but it should be made clear that there is a world of difference between a toy language and one that people would actually want to use)
It's for this reason that nowadays I rarely write my own "new" programming languages from scratch, but rather embed them as DSLs inside existing programming languages using macros. This way you get the full ecosystem of the host language for free, leaving you more time to work on designing the language to suit your needs. If you combine macros with clever uses of GADTs you can even get the host language to "type-check" programs written in your DSL. OCaml and Lisp/Racket are my favourite host languages to use for this approach.
I do however feel that your QoL will depend on whether or not you make a compiler or a translator. The key benefit of a translator is that you can co-opt the host language's standard runtime and debugger.
Agree with all of this. Don't do any yak-shaving you don't want to do just for the fun of it; build your language and its tooling on existing systems so you can spend your time on what makes it special, instead of what doesn't.
> It's for this reason that nowadays I rarely write my own "new" programming languages from scratch, but rather embed them as DSLs inside existing programming languages using macros. This way you get the full ecosystem of the host language for free
I don't understand what you mean by this, so I'm hoping you can clarify. What's the advantage of doing this over the alternative way: writing a parser which would compile to code in the host language, or some primitives that you've arranged in the host language that would represent the bytecode of your language interpreter. From there you can leverage whatever in the host language you want, including its type system, packages, language semantics, FFI access to other languages. Really whatever you like.
What you're suggesting is leveraging a macro system to help you write what is essentially a parser/compiler, which is a good win. But I don't see what that buys you past that point. If I do things the other way, by writing a parser that consumes a *.my_lang file and compiles it to primitives or actual source code in the host language, I can still leverage all the benefits of the host language just as you describe doing with a macro system. The advantage of doing things this way is you're not limited to languages with tolerable metaprogramming capabilities.
Yeah it's pretty bad these days. If you tell someone you are writing a PL, they expect:
- a complete parser/compiler and debugger toolchain
- a complete language server implementation, and language modes for all popular IDEs including VSCode, VIM, Emacs, etc.
- a package manager with a large, secure, and vibrant package ecosystem
- a community with live chat support and a strong Stack Overflow presence
- robust documentation with copious examples, tutorials, guides, and technical info. These days even a multi-hundred page book with professional editing available for free is expected.
- That you will be responsive to bugs, provide patches promptly, and review/merge community feature requests asap. They will get very mad with you if you don't, and likely write a blog post about how much of a tyrant you are over your project.
- your language is expected to have undergone a full independent security audit, and to be up-to-date on the latest security issues. It's expected to be stable with complete backwards compatibility.
- you have to manage the community and deal with petty interpersonal conflicts or else word gets out that your language has a "toxic community"
- support for all major operating systems and hardware architectures including Mac, Windows, and all distributions of Linux, as well as esoteric hardware.
- support for the web through wasm, so you need experts at that as well as x86 and ARM platforms now.
- And on top of all that, your project needs to be completely open source, with a free and open license that permits royalty free, patent free, commercial use. Oh, and your users both corporate and personal expect your work to be completely free as in beer. They won't pay anything for it. Not even a dollar. And if you ask them to pay something they don't weigh the value of your product versus the competition, they balk immediately and don't even consider it. It's been a non-starter to ask for money for a PL for decades.
It used to be the case that you could write down a spec on paper and call it a PL. Back in the 60s you could call that a "programming language" without even writing an implementation of the parser. Today a programming language is a massive undertaking and the saddest part of it all is that it's been commoditized. I've even seen a sentiment out there that programming languages are done, that we've invented all we need to. All future languages are unnecessary, and all current languages are largely the same. Could you imagine? So as hard as programming languages are, DO write them. That's my message. Just do so responsibly and with clear eyes and expectations.
This is so strangely sad. Go ahead and write a programming language. Have a weird hobby you clank away on that might not see the light of day. If you burn out on it, that's one thing and that's okay; you've exhausted the medium. Move on to something else you enjoy. Grow for the sake of growing.
Just because something hasn't become big doesn't mean it's a failure. I've labored in dark early hours over paintings and music that will never see the light of day, but it's a vital part of how I express and cultivate myself. My journal.
99% of art is unknown personal projects. Embrace yours. Why be bitter?
For me it's a question of what my goals are. If I have three equally fascinating projects I could spend my free time on, which one advances me towards my goals.
Thank you so much for these words. I have „wasted“ around 5 years designing my own and was recently bitter about that „wasted“ time. Only now I started shifting my perspective that this was a thrilling hobby that I really liked and it wasnt wasted at all. Your words were final nail in that coffin of bitterness. Thank you, kind internet stranger, you changed my life for the better
Back in the 80's when I started my career creating a PL was a right of passage. You got bonus cred if it were compiled and not interpreted! Most people weren't writing general-purpose languages and the languages were very domain-focused - but they were languages nonetheless. It's been kinda sad to see that die. So I agree with you - go write that programming language if that floats your boat and just have fun doing it for the sake of doing it.
I have also been working on a programming language, but longer than the author of this piece (since 2011), and the author is correct.
Designing a language consumes you; you never see programming the same way again. Whenever I write C (I'm implementing the interpreter in C), I get annoyed because I have to work around C's warts to do what I want, and that is only happening because I think in my language.
And the design never stops. As mentioned, I've been designing mine since 2011, and I'm only now writing an interpreter after two failed attempts to bootstrap a compiler.
So the author is correct: don't write a programming language unless you are prepared to be marked and scarred for life.
> I get annoyed because I have to work around C's warts to do what I want, and that is only happening because I think in my language
That is exactly what motivated me to start thinking about my own language and what made me want to keep working on it in the early to mid 1990s. Luckily, I started learning several languages so that I'd have a better idea of the design space. Someone suggested I take a look at a relatively unknown language called Python because it fit how I was thinking about things. He was right and that was the anecdote for me - finding a language that fit how I thought about programming well enough to eliminate enough of the annoyances that were my motivation.
The lesson... If you're thinking about designing a language, study as many other languages as you can so that you get a better sense for the design choices involved and how various concepts fit together. Ask people experienced with those languages what they like / dislike about them. Write something challenging enough to get a first hand understanding of some of those pros and cons. If you push on with your own language, this will help your efforts significantly. If you get lucky, you might find a language that stops your descent into the rabbit hole.
The above might only work if you can accept that languages are sufficiently complex that they all have real problems, even yours when it's "done".
> If you're thinking about designing a language, study as many other languages as you can so that you get a better sense for the design choices involved and how various concepts fit together.
I've written C, C++, Python, Ruby, Lua, Bash, POSIX sh, C#, Java, JavaScript, Common Lisp, Racket, Haskell, bc, dc, Zig, BASIC, Tcl, and some others I'm probably forgetting, and I've studied Rust, D, Ada, Idris, Coq, Isabelle/HOL, HAL/S, OpenGL shaders, Cilk, Cyclone, Ceylon, Scala, Clojure, Kotlin, F#, Scheme Lisp, Jai, Julia, Perl, Nim, and probably even more that I am forgetting.
Does all of that count? :)
> Ask people experienced with those languages what they like / dislike about them. Write something challenging enough to get a first hand understanding of some of those pros and cons. If you push on with your own language, this will help your efforts significantly.
Yes, I agree. And I have done all of that.
> If you get lucky, you might find a language that stops your descent into the rabbit hole.
"Lucky" is the operative word. Unfortunately, I'm picky and haven't been that lucky.
I was looking for your comment in this thread and I'm not disappointed.
It's fortunate you went ahead despite every thing telling you to do otherwise. And then tricked other people into joining you. A bit evil probably but they consented, in the end. You are probably only partly responsible.
Article author here. The two years mentioned in the post is the time spent actually implementing it. I spent a few more years thinking about it prior, and I thought that implementing the basic ideas would prove, our not, whether it worked, and then I'd be done.
Well, guess what, it didn't actually turn out that way. At least I'm more understanding of people who annoyingly promote their own languages all the time.
> So the author is correct: don't write a programming language unless you are prepared to be marked and scarred for life.
I write and wrote internal languages mostly; a bunch of them made it to production inside larger (for my country) companies for years and even a decade. The scarring part is that I always add the features I want and when I go to a mainstream language, I always miss those features. So since 2018 we have been doing a new language and one of them will be publicly launched this or next year so I can at least use that for day to day programming without being annoyed by missing features. Note that I already have that using Racket with a bunch of macros but in my business it is easier to introduce your own language than use Racket...
> I get annoyed because I have to work around C's warts to do what I want, and that is only happening because I think in my language.
What's worse is that PL authors are usually students of PL history, and the history of PLs is littered with "We did things this way out of necessity. We wouldn't have done this if we had more time/resources." Which would be fine but then we are all stuck using those tools with all their arbitrary limitations and quirks for 50 years. If you ever thought "I could write something to make this so much easier", the impulse is 100x worse as a PL designer, because you realize how many things we do are done for no reason at all beyond history and happenstance.
On the bright side, it probably better equips you to actually argue about where C (or any language) has faults from a language design perspective, which is a relatively rare point of view.
> I've been designing mine since 2011, and I'm only now writing an interpreter after two failed attempts to bootstrap a compiler.
You are lucky (or unlucky) that you have reached that stage. I'm trying since 2004 and had at least 6 failed attempts on design and 3 different implementations that never finished. Fortunately for me, since I had a lot of failed designs (as opposed to implementations) I better appreciate existing designs even with their warts.
It's funny/interesting that an 1kloc implementation of minimal self hosting Go exist, or C/pascal/oberon compilers ; perfect hindsight view etc. You theoretically could (well if nobody does, no you can't) create a nice language and its implementation quickly.
A programming language is a tool. And like all tools, the situation is very different depending on if you are writing a personal tool that solves your problems or if you are trying to solve other's problems.
I used to lurk in a programming language design group. I joined it because I wanted to "solve everyone's problem" with a new language because I had some success with solving my own problems with a previous language (which is not for everyone; it's a Forth dialect).
For few year I saw some people theorizing and analyzing with little practical results. It's fascinating how people can know about "analysis paralysis" and still fall for it. Meanwhile, I lost interest in my own attempt and returned to my Forth dialect.
Today it powers a few programs that run 24/7. And it is also my goto scripting language. It's not available on Github/Gitlab/whateve because I'm too lazy to do something that will certainly have zero benefits for me ( however curiously, it is half-documented because writing docs helps with spotting silly decisions sometimes).
It is true that you are never done with that sort of program, there's always something to improve or fine tune. Also, since you are the sole user you cannot rely on a ecosystem and just "import their.stuff".
But I think the great mistake is really to start making a tool, a programming language, with no plans on what to use it for; or worse, expect others to use it. The Internet is indeed littered with born-dead or short-lived languages. They are solutions without a problem to solve.
It is true: it's a deep pit you'll enter. But the conclusion is wrong. If you feel it's fun -- then do write your own programming language. Even if you won't finish (which is likely). But you'll think about things that are a lot of fun, and you will have more clarity about what you do not like about existing languages, and why. And you'll learn that there are things you need to solve that you did not think about before. That some things cannot be combined, and that you will have to choose.
It is a very good experience, there is a lot to learn. As long as your goal is not to get it done quickly...
The key to writing a PL and surviving is to have an exit strategy. Figure out ahead of time how long you will spend on this project, otherwise it’s liable to last half a decade or more before your interest wanes.
PL design is like crack for programmers. It is a lot of fun, which is why you see hundreds of little languages posted here every month.
The danger is that some people get don’t have a clear idea. About what it takes to write a pl. They can get quick wins with a parser generator and maybe some easy semantics, which give a good taste of how fun PLs are but also belie the fact that the hardest parts are exponentially harder than that.
Anyone embarking on a PL needs to be clear eyed about a few things.
1. You’ll never make money off of it. No one sells compilers anymore, and there are like 2 big for-profit languages out there out of thousands. If you do make money, let us all know how.
2. The odds are your language will have exactly one user, yourself. Get comfortable with the possibility you will spend years on something and no one will really appreciate it.
3. The real work in creating a language is not technical but community building. Languages need people who speak/write it to thrive, so as much or more work needs to be put into the community effort for the language to succeed. If all you want to do is work on technical problems that’s fine, but technical prowess doesn’t make a language popular.
4. Get ready for criticism. Every programmer has their opinions about languages and they will be sure to tell you their opinion of your language. It will not be good. The only people who will appreciate your language are other language designers. Most everyone else will start by telling you how you’re doing things the wrong way, and they’ll end by asking why you’re eating your time with all this anyway. Get ready for that and steel yourself against it.
Who cares? I'm not writing my programming language for you: I'm writing it for myself. It's about the journey, not about the destination. (Btw, the author is right)
Readit News
First, it's technically very difficult, but you will gain deeper insight into the art of the craft. So, if you are a TC chaser or career minded person, then spending half a year writing a language will help you master the coding aspect of the game. I've started many languages since I started college, and each one was instructional. (I'm now 40 and an early retiree)
Second, it's fun.
Third, it may turn into something new. If some people don't write a new programming language, then we are stuck with what we have. This advice basically admits that the status quo is good enough.
The authors saying that the language, as a project, is a lifetime appointment? Well, this reveals everything. I believe if you want to do a programming language, then you must be willing to invest at least a decade or two.
So, here, I am at forty preparing to launch a SaaS around a language that I designed ( http://www.adama-lang.org/ ). The kicker, I believe, is that a project like this requires wandering the desert alone for quite a while.
I'm preparing to launch, and I just started to load test my shiny new production cluster. Low and behold, it sucks. Fortunately, I have a tremendous number of dashboards and isolated it to how I'm interacting with RDS. I've got my work cut out for me which I'll write about.
However, I have a potentially interesting business precisely because I evolved a language which solved a niche use-case. The number of problems that I have had to solve up to this point is not for the faint of heart. Life and reality are harsh mistresses.
So, maybe, yes, you can save yourself some heartache by not writing a language. Perhaps, a better way to think or phase this is "Writing a programming language is a lonely affair that will most likely end in tragedy after a long death march".
From http://lambda-the-ultimate.org/node/5569 - Three Things I Wish I Knew When I Started Designing Languages. Alvaro's talk led to an HN discussion at https://news.ycombinator.com/item?id=19428433
Sounds like someone should persuade some big-name university to hand out honorary PhDs to people who build new languages that produce demonstrable value (even if the value is not business value).
Seems to be the criteria for a PhD, anyway.
It's for this reason that nowadays I rarely write my own "new" programming languages from scratch, but rather embed them as DSLs inside existing programming languages using macros. This way you get the full ecosystem of the host language for free, leaving you more time to work on designing the language to suit your needs. If you combine macros with clever uses of GADTs you can even get the host language to "type-check" programs written in your DSL. OCaml and Lisp/Racket are my favourite host languages to use for this approach.
You have https://microsoft.github.io/language-server-protocol/ for doing the integration between IDE and your parser.
Also, https://highlightjs.org/ which lets you broadcast your code in a pretty way.
I do however feel that your QoL will depend on whether or not you make a compiler or a translator. The key benefit of a translator is that you can co-opt the host language's standard runtime and debugger.
I don't understand what you mean by this, so I'm hoping you can clarify. What's the advantage of doing this over the alternative way: writing a parser which would compile to code in the host language, or some primitives that you've arranged in the host language that would represent the bytecode of your language interpreter. From there you can leverage whatever in the host language you want, including its type system, packages, language semantics, FFI access to other languages. Really whatever you like.
What you're suggesting is leveraging a macro system to help you write what is essentially a parser/compiler, which is a good win. But I don't see what that buys you past that point. If I do things the other way, by writing a parser that consumes a *.my_lang file and compiles it to primitives or actual source code in the host language, I can still leverage all the benefits of the host language just as you describe doing with a macro system. The advantage of doing things this way is you're not limited to languages with tolerable metaprogramming capabilities.
It is still a fun exercise, though.
- a complete parser/compiler and debugger toolchain
- a complete language server implementation, and language modes for all popular IDEs including VSCode, VIM, Emacs, etc.
- a package manager with a large, secure, and vibrant package ecosystem
- a community with live chat support and a strong Stack Overflow presence
- robust documentation with copious examples, tutorials, guides, and technical info. These days even a multi-hundred page book with professional editing available for free is expected.
- That you will be responsive to bugs, provide patches promptly, and review/merge community feature requests asap. They will get very mad with you if you don't, and likely write a blog post about how much of a tyrant you are over your project.
- your language is expected to have undergone a full independent security audit, and to be up-to-date on the latest security issues. It's expected to be stable with complete backwards compatibility.
- you have to manage the community and deal with petty interpersonal conflicts or else word gets out that your language has a "toxic community"
- support for all major operating systems and hardware architectures including Mac, Windows, and all distributions of Linux, as well as esoteric hardware.
- support for the web through wasm, so you need experts at that as well as x86 and ARM platforms now.
- And on top of all that, your project needs to be completely open source, with a free and open license that permits royalty free, patent free, commercial use. Oh, and your users both corporate and personal expect your work to be completely free as in beer. They won't pay anything for it. Not even a dollar. And if you ask them to pay something they don't weigh the value of your product versus the competition, they balk immediately and don't even consider it. It's been a non-starter to ask for money for a PL for decades.
It used to be the case that you could write down a spec on paper and call it a PL. Back in the 60s you could call that a "programming language" without even writing an implementation of the parser. Today a programming language is a massive undertaking and the saddest part of it all is that it's been commoditized. I've even seen a sentiment out there that programming languages are done, that we've invented all we need to. All future languages are unnecessary, and all current languages are largely the same. Could you imagine? So as hard as programming languages are, DO write them. That's my message. Just do so responsibly and with clear eyes and expectations.
Just because something hasn't become big doesn't mean it's a failure. I've labored in dark early hours over paintings and music that will never see the light of day, but it's a vital part of how I express and cultivate myself. My journal.
99% of art is unknown personal projects. Embrace yours. Why be bitter?
A warning that many naive young recruits ought to give credence to, before it's too late (when the cost has been sunk, and you're knee deep in it).
(Warning - comic gold, get a tissue) https://aphyr.com/posts/353-rewriting-the-technical-intervie...
And then read the rest of the stories on the site.
They're all both extremely technically interesting and very good short fiction.
Designing a language consumes you; you never see programming the same way again. Whenever I write C (I'm implementing the interpreter in C), I get annoyed because I have to work around C's warts to do what I want, and that is only happening because I think in my language.
And the design never stops. As mentioned, I've been designing mine since 2011, and I'm only now writing an interpreter after two failed attempts to bootstrap a compiler.
So the author is correct: don't write a programming language unless you are prepared to be marked and scarred for life.
That is exactly what motivated me to start thinking about my own language and what made me want to keep working on it in the early to mid 1990s. Luckily, I started learning several languages so that I'd have a better idea of the design space. Someone suggested I take a look at a relatively unknown language called Python because it fit how I was thinking about things. He was right and that was the anecdote for me - finding a language that fit how I thought about programming well enough to eliminate enough of the annoyances that were my motivation.
The lesson... If you're thinking about designing a language, study as many other languages as you can so that you get a better sense for the design choices involved and how various concepts fit together. Ask people experienced with those languages what they like / dislike about them. Write something challenging enough to get a first hand understanding of some of those pros and cons. If you push on with your own language, this will help your efforts significantly. If you get lucky, you might find a language that stops your descent into the rabbit hole.
The above might only work if you can accept that languages are sufficiently complex that they all have real problems, even yours when it's "done".
I've written C, C++, Python, Ruby, Lua, Bash, POSIX sh, C#, Java, JavaScript, Common Lisp, Racket, Haskell, bc, dc, Zig, BASIC, Tcl, and some others I'm probably forgetting, and I've studied Rust, D, Ada, Idris, Coq, Isabelle/HOL, HAL/S, OpenGL shaders, Cilk, Cyclone, Ceylon, Scala, Clojure, Kotlin, F#, Scheme Lisp, Jai, Julia, Perl, Nim, and probably even more that I am forgetting.
Does all of that count? :)
> Ask people experienced with those languages what they like / dislike about them. Write something challenging enough to get a first hand understanding of some of those pros and cons. If you push on with your own language, this will help your efforts significantly.
Yes, I agree. And I have done all of that.
> If you get lucky, you might find a language that stops your descent into the rabbit hole.
"Lucky" is the operative word. Unfortunately, I'm picky and haven't been that lucky.
I can vouch for that! Fortunately, I have a great team to collaborate with.
It's fortunate you went ahead despite every thing telling you to do otherwise. And then tricked other people into joining you. A bit evil probably but they consented, in the end. You are probably only partly responsible.
Well, guess what, it didn't actually turn out that way. At least I'm more understanding of people who annoyingly promote their own languages all the time.
I write and wrote internal languages mostly; a bunch of them made it to production inside larger (for my country) companies for years and even a decade. The scarring part is that I always add the features I want and when I go to a mainstream language, I always miss those features. So since 2018 we have been doing a new language and one of them will be publicly launched this or next year so I can at least use that for day to day programming without being annoyed by missing features. Note that I already have that using Racket with a bunch of macros but in my business it is easier to introduce your own language than use Racket...
Why is it easier?
What's worse is that PL authors are usually students of PL history, and the history of PLs is littered with "We did things this way out of necessity. We wouldn't have done this if we had more time/resources." Which would be fine but then we are all stuck using those tools with all their arbitrary limitations and quirks for 50 years. If you ever thought "I could write something to make this so much easier", the impulse is 100x worse as a PL designer, because you realize how many things we do are done for no reason at all beyond history and happenstance.
You are lucky (or unlucky) that you have reached that stage. I'm trying since 2004 and had at least 6 failed attempts on design and 3 different implementations that never finished. Fortunately for me, since I had a lot of failed designs (as opposed to implementations) I better appreciate existing designs even with their warts.
You "just" have to get to the point where your compiler is written in your own language. This may take a while. Go got there in V1.5:
https://go.dev/doc/go1.5
If not, your language will be marked and swept.
I used to lurk in a programming language design group. I joined it because I wanted to "solve everyone's problem" with a new language because I had some success with solving my own problems with a previous language (which is not for everyone; it's a Forth dialect).
For few year I saw some people theorizing and analyzing with little practical results. It's fascinating how people can know about "analysis paralysis" and still fall for it. Meanwhile, I lost interest in my own attempt and returned to my Forth dialect.
Today it powers a few programs that run 24/7. And it is also my goto scripting language. It's not available on Github/Gitlab/whateve because I'm too lazy to do something that will certainly have zero benefits for me ( however curiously, it is half-documented because writing docs helps with spotting silly decisions sometimes).
It is true that you are never done with that sort of program, there's always something to improve or fine tune. Also, since you are the sole user you cannot rely on a ecosystem and just "import their.stuff".
But I think the great mistake is really to start making a tool, a programming language, with no plans on what to use it for; or worse, expect others to use it. The Internet is indeed littered with born-dead or short-lived languages. They are solutions without a problem to solve.
It is a very good experience, there is a lot to learn. As long as your goal is not to get it done quickly...
PL design is like crack for programmers. It is a lot of fun, which is why you see hundreds of little languages posted here every month.
The danger is that some people get don’t have a clear idea. About what it takes to write a pl. They can get quick wins with a parser generator and maybe some easy semantics, which give a good taste of how fun PLs are but also belie the fact that the hardest parts are exponentially harder than that.
Anyone embarking on a PL needs to be clear eyed about a few things.
1. You’ll never make money off of it. No one sells compilers anymore, and there are like 2 big for-profit languages out there out of thousands. If you do make money, let us all know how.
2. The odds are your language will have exactly one user, yourself. Get comfortable with the possibility you will spend years on something and no one will really appreciate it.
3. The real work in creating a language is not technical but community building. Languages need people who speak/write it to thrive, so as much or more work needs to be put into the community effort for the language to succeed. If all you want to do is work on technical problems that’s fine, but technical prowess doesn’t make a language popular.
4. Get ready for criticism. Every programmer has their opinions about languages and they will be sure to tell you their opinion of your language. It will not be good. The only people who will appreciate your language are other language designers. Most everyone else will start by telling you how you’re doing things the wrong way, and they’ll end by asking why you’re eating your time with all this anyway. Get ready for that and steel yourself against it.