Why programming languages matter [video]

Research around functional languages involves their execution models. Even ignoring execution models immutability is a staple of functional programming which is not good for performance.

As a counter-counter point, I hear your sentiment a lot, I work for 22 years in the profession now -- and I am a fairly average programmer so I don't claim any credentials or anything.

...And I've never seen your sentiment work. Nobody is really learning anything, people just want to tinker with stuff and never read history or even best practices. All I see are people going in circles forever.

Maybe there's a smaller percentage of much clever programmers out there. I wouldn't know because I never (so far) attempted to do anything beyond web apps (though I do regret that a lot and might yet change it). And maybe these people are truly evolving the art. I mean we have Golang, Rust, WASM, and others so I know these people exist.

But somehow that almost never penetrates the broader programming community. Maybe Rust is the only true example because people started wanting to have sum types in their day-job languages -- which I view as a good thing. Such sentiments have the potential to gain enough critical mass to have language designers reconsider their initial choices (f.ex. Elixir is working on an optional type checker, one that's stricter and more descriptive and correct than the one coming with Erlang).

So I don't know. I wish you are correct but after 22 years in the sidelines the only true improvements I've seen are Elixir / Golang (in terms of transparent parallelism where Elixir wins over Golang but Golang is still much better than almost everything else out there as well) and Rust (for the aforementioned compile-time guarantees and other ones like memory safety).

Outside of that though? Nope. "Hey let's have one more JS framework, we didn't have a new one this month" is something I've seen a lot of, not to mention the eternally growing list LISP interpreters because apparently that's the peak of our collective intelligence and ambition. :(

I just get sad. HN is a place where a supposed intellectual elite gathers but they don't seem to be interested in anything beyond their pet language that will never have even 1% of the goodness that a much-derided language like Golang has. And I view that as a waste of energy and time, and as a very sad thing in general.

I mean that people over-fixate on syntax or language quirks, but when you start writing for (and deploying for) production then it turns out that many others things are much more important. And I wish people were more practical in our area and they are often not, they are like kids who only want to play even.

And even though I am eating down votes I will keep saying it: fangirling over LISP I view as a collective drag and to the detriment of the entire programming area.

Obviously I am not a world dictator saying what should people spend their time on. I am saying that if you want to truly move the art forward, well, we have 5000 other problems that are at least 100x more important than "oh look I can code a basic LISP interpreter".

My opinion, obviously, but it's also one that I would not be easily dissuaded from.

On that I totally agree.

But how will language performance evolve as the nature of the hardware our programs run on evolves? IMHO this is not an easy question to answer right now.

C compilers don’t produce 100% optimal assembly language in all cases, but typically the assumptions they make are light. The executable code they output is somewhat predictable and often close enough to hand-optimised assembly in efficiency that we ignore the difference. But this whole approach to programming was originally designed for single-threaded execution on a CPU with a chunk of RAM for storage.

What happens if we never find a way to get a single core to run much faster but processors come with ever more cores and introduce other new features for parallel execution? What happens if we evolve towards ever more distributed systems, but farming out big jobs to a set of specialised components in the cloud at a much lower level than we do today? What happens if systems start coming with other kinds of memory that have different characteristics to RAM as standard, from content-addressable memory we already have today to who-knows-what as quantum technology evolves?

If we change the rules then maybe a different style of programming will end up being more efficient. It’s true that today’s functional programming languages that control mutation and other side effects usually don’t compile down to machine code as efficiently as a well-written C program can. The heavier runtimes to manage responsibilities like garbage collection and the reliance on purely functional data structures that we don’t yet know how to convert to efficient imperative code under the hood are bottlenecks. But on the other hand, those languages can make much stronger assumptions than a lower-level language like C in other ways, and maybe those assumptions will allow compilers to safely allocate different behaviour to new hardware in ways that weren’t possible before, and maybe dividing a big job into 500 quantum foobar jobs that each run half as fast as a single-threaded foobaz job still ends up doing the job 200x faster overall.