Why Do Most New Languages Fail?

New programming languages are invented everyday. Some of these try to solve domain-specific issues, but others hope to become big players among the general-purpose languages used by software developers. Perhaps it’s simply human nature. There are already many general-purpose programming languages in wide use out there in the real world, but some of us are never satisfied. We can’t help but see the flaws in the existing tools, and out of some OCD-like compulsion, we must attempt to create something better. Unfortunately, most of these new programming languages die shortly after birth.

What makes the difference between programming languages that fail and those that succeed? Some will argue that it comes down to new languages having familiar semantics. Others will claim that it’s purely down to luck. I believe the truth is rather simple: most new programming languages are impractical to use, on a variety of levels. Furthermore, for a new language to succeed, it must, as with any product we hope people will use, fill some kind of niche. It must do at least one thing that the others don’t, or do some things better than the competition.

I believe that most programming languages that fail do so for at least one of the following reasons:

1. The language is impractical. This means highly unusual syntax, high verbosity, oddball semantics that don’t work well together. It’s the good old “it works well for the toy problem the inventor wanted to solve, but nothing else”.
2. The tools are impractical. The stock implementation of the language only runs on one platform. You have to build it from sources, and it has 50 dependencies, but you don’t have 3 hours to spare just to try this out. The tools have weird command-line flags, it’s unclear how to even compile/run a program written in this language.
3. The language can’t interface with anything. Hardly any libraries ship with it, it can’t interface with C code easily. All you can easily hope to write in this language are command-line programs that use stdin and stdout, but your application requires access to a MIDI controller and OpenGL, you can’t use this language.
4. The language is slow as hell. The stock implementation isn’t a compiler, but a very naive interpreter. The language runs slower than Python, but has none of Python’s qualities. It’s inventors claim it would be easy for someone else (not them) to make a fast compiler for it, but nobody is doing it.
5. The stock implementation is incomplete and unmaintained. Perhaps this language was some cool academic idea. The bare minimum needed for one publication was implemented, but once this publication was accepted, the partial implementation was left to rot. This new language never got past the prototype stage, and probably never will.

For a new language to succeed, it has to be practical. It has to be useful. It has to have something to offer over the competition. This is very challenging because the world doesn’t stay still. The landscape has changed since the invention of Python back in 1991. If you wanted to compete against Python in the dynamic language realm, for example, you’d be competing against Python itself, which is now a very mature product shipping with dozens of libraries and volumes of documentation. Since Python came around, the bar has been raised.

To those who hope to eventually create a new programming language, I would give the following advice:

1. Study programming languages in general, but also study languages you wish to compete against. If it’s dynamic languages you’re interested in, look at Python, Ruby and JavaScript. They each have glaring design flaws. To compete against them, you should take advantage of this and do better at the things they do poorly. You should also try to avoid introducing glaring design flaws of your own.
2. Study compiler design. Speed matters more than you think. You would be smart to design your language in a way you know for a fact a compiler could easily optimize. This will give you a speed advantage over the competition, and probably make your language more robust as a result. Hint: nonsense, complex, unintuitive semantics tend to hinder optimization. Simple, straightforward, consistent semantics make compiler design and optimization simpler.
3. Be grounded in reality. Make your implementation pragmatic. If your language is to become popular, it means you won’t be the only user. Design your implementation to be portable, minimize dependencies on external libraries. Release precompiled binaries. Make sure your language can interface with C, because it is the de-facto standard systems language. Everything has C bindings, you should be able to support those.
4. Eat your own dog food. You should be trying out your new language on various problems and making sure it works well for common use cases. You should be trying to anticipate the needs of future users.
5. Put the work into it. Your compiler isn’t gonna write itself, and nobody likes half-finished, untested products. If you want to create a successful programming language, you might well have to spend a few years polishing your implementation. It might take a large amount of effort for your project to be complete enough for people to notice this little gem of yours.

I would also like to add that it probably helps to prototype things. If you want to create a new programming language, it might be pretty easy for you to write a simple interpreter and prototype a version of your language that uses a LISP-like syntax. Just remember that there’s often a pretty big gap between prototype and final product.