Is there a point to an all-encompassing programming language?

Question

There are many programming languages in use throughout the world today, including languages that specialize in database manipulation, functionality, object-orientation, concurrency, etc. Would there be any point in making a language that could do all these things very well, or is it best to keep these languages separate to some degree?

The reason I ask is because I had been interested in building a very basic compiler. As I became more familiar with the concepts behind compilers and the hurdles and obstacles to overcome, I realized that I should probably come up with a language that had some sort of goal. I spoke with a friend about a language that could "do it all", and he said that there was simply no point. I am still confused as to why he might claim this.

Answer 1

You can make a language that does all these things. The problem is that it won't be able to do all these things well, because they're contradictory. For example, database manipulation is fundamentally about changing the state of the system, so it's directly opposed to purely functional programming¹. So is fault tolerance, where a program that's running code that's mathematically proven to terminate might actually fail to terminate because the machine crashes. Object orientation with the hiding of implementation-specific details is opposed to structural polymorphism where a function might inspect the state of its arguments and expects to know about all the ways in which an object can be built. Having static type guarantees is opposed to dynamic type analysis. A language can't provide safe memory accesses and precise memory management in all cases. And so on.

The best you can expect is a “kitchen sink” language that includes all the features that the designers thought of. The thing is, to effectively use some of the features, the programmer needs to restrict themselves to a subset of the language that copes with those features. Of the languages commonly used in industry, C++ is the most kitchen-sinky, and that makes it hard to use because you can never be sure what features a piece of code uses and what assumptions you can make on that piece of code. For example, the type of a Haskell function makes it apparent whether it has a side effect; the type of a Rust function makes its memory management behavior apparent; with C++, you have to look at the documentation and hope that it tells you what you need.

With a kitchen sink language, you really have multiple languages in one, without the benefit of a clear barrier between the languages. Multiple languages that are each good at their job works better.

¹ _{If you put the database state in a monad, like Haskell does, you're no longer doing purely functional programming. You're doing imperative programming with a type system that models the impurity.}

Answer 2

The problem is that the requirements of various programing language specializations work against each other.

For example, for systems programming (think operating systems and drivers), you want a language that's close to the metal, with predictable and high performance and you're willing to trade a lot of convenience to achieve that goal.

On the other hand, for application programming, convenience is pretty much the most important thing, and performance is secondary.

Sometimes it's possible to do both.

For example, consider unsafe in C#: under normal circumstances, C# doesn't have pointers, but you can use them if you need to, in specifically marked unsafe areas.

Another example is the concept of zero cost abstractions in C++: abstractions usually have some performance cost, but in C++, some of them are very carefully designed in such a way that they do not.

But in such cases, it's almost always a compromise. Like in the two examples above: unsafe means that C# is not truly safe, only "mostly safe" language. And zero cost abstractions might be less convenient than other abstractions.

And I haven't even started considering that different people like different language features (for example static vs. dynamic typing).

I think designing and implementing an all-encompassing language might be possible, but it would take a lot of time and effort and learning from what worked and what didn't in previous languages. If a single person were to create it themselves, it would probably take a lifetime.