Comment by jiggawatts | Hacker News Reader

Comment by jiggawatts | Hacker News Reader

For over a decade now, I've been pondering a "perfect" language.

Of course, such a thing is impossible, because we're always learning, and we can always do better, but it leads to some interesting avenues of thought. We can claim that certain concepts are mandatory, which can be used to reject languages that can never meet our ultimate requirements.

For example, a common complaint is the "impedance mismatch" between, say, query languages such as SQL or MDX, and object oriented languages such as Java and C#. Similarly, JSON has become popular precisely because it has zero "mismatch" with JavaScript -- it is a nearly perfect subset.

This leads one to the obvious conclusion: An ideal language must have subsets, and probably quite a few. If it doesn't, some other special-purpose language would be forced on the developers, and then our ideal language isn't perfect any more!

The way I envision this is that the perfect language would have a pure "data" subset similar to JSON or SQL tables, with absolutely no special features of any type.

The next step up is data with references.

Then data with references and "expression" code that is guaranteed to terminate.

Then data with expressions and pure functions that may loop forever, but have no side-effects of any kind.

At some point, you'd want fully procedural code, but not unsafe code, and no user-controlled threads.

At the full procedural programming language level, I'd like to see a Rust-like ownership model that's optional, so that business glue code can have easy-to-use reference types as seen in C# and Java, but if a library function is called that uses ownership, the compiler takes care of things. You get the performance benefit where it matters, but you can be lazy when it doesn't matter.

Interestingly, C# is half-way there now with their Span and Memory types, except that this was tacked on to an existing language and virtual machine, so the abstractions are more than a bit leaky. Unlike Rust, where the compiler provides safety guarantees, there are a lot of warnings-to-be-heeded in the dotnet core doco.

TL;DR: We don't need separate simplified languages, we need powerful languages with many simpler subsets for specialist purposes.

I think you would be interested in Noether, a full language design based around this principle: https://tahoe-lafs.org/~davidsarah/noether-friam4.pdf. I've always been sad that an implementation was never created. It's one of the most unique designs for a language in the past decade.

Thank you for the reference, it's very interesting to see that someone has has had the same line of thought!

I'm reading through the presentation slides for Noether, and it almost exactly follows my line of thinking, but uses much more precise definitions and restrictions than my own hand waving.

However, it only goes "down" to a very pure functional language. I would argue to that there is a need to take a step further to a data-only language also.

I agree. For an extreme example, by taking an extremely restricted subset of Python, Numba is able to get crazy speed-ups, automatic compilation to GPU kernels, etc. I've been waiting for someone to implement the subset of Python that allows for no GIL and huge speedups by cutting out some of the dynamic stuff. I'd bet 99% of the code I write would fit in that subset.

Some people are already exploring this idea of "language subset".

For example, Dhall (https://dhall-lang.org/) could be seen as a subset of Haskell, with less features but guaranteed termination!

> because we're always learning, and we can always do better

I think this is a very important point, but it should IMO be considered along with context. Languages are always used with a particular tech stack, targeting particular hardware, all with its own performance characteristics. For example languages with garbage collection will have to have a different design from languages that use reference counting. And that's OK!

It's useful IMO to think of languages in terms of the use cases they're effective in. Some are good for resource constrained environments, others are highly flexible, others are great at expressing mathematical concepts. All those are unique use-cases and it shouldn't be surprising that the best languages for each are very different.

Where I think languages can run into trouble is where they try to be all things to all people. A universal tool sounds cool in theory, in reality they risk becoming mediocre at everything or developing what are affectionately named footguns. These steepen the learning curve and can also cause problems in real-world deployments of software in that language.

An analogy I like to use is prime vs zoom lenses on DSLR cameras.

A common observation by professionals is that when they have a zoom lens attached to their camera, the pictures tend to be either one extreme zoom or the other. That is, they wanted "as much as possible" and just set the zoom range to the maximum in that direction.

Which means that most of the zoom range is (almost) never utilised.

The big advantage of prime lenses is that by sacrificing the ability to zoom, the quality can be better. A 35-50mm zoom is never going to be as good as two separate 35mm and 50mm prime lenses.

So if you want to maximise quality, get primes.

But then your camera bag will be heavier, and your wallet lighter.

Also, you now cannot have any intermediate zoom range in those rare times that you do need it.

So there's always some trade-off being made.

Languages like C++ are like zoom lenses. They allow almost any programming paradigm, and various mixes too. You can have a procedural program with memory safety, with functional bits thrown in, and call out to unsafe C code if you want.

Languages like Haskell or JavaScript are like a prime lens, with a lot of decisions fixed at one extreme or another.

I suspect that what's needed is the zoom-like flexibility of languages like C++, but with defined subsets that work more like a "prime" language. With physical lenses, this is impossible. You can't take the zoom bits out, leaving the prime behind. With software... I think it can be done.

This isn't that unusual an idea. Mainstream languages are already slowly converging on this concept. For example, C# has a project-level "unsafe" flag, which turns a set of language features on or off.

Reply on news.ycombinator.com