Why programming languages matter [video] (opens in new tab)

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.

Yeah, your comment is likely the answer. I am just bitter why is all that happening so darned slow. I really hoped that 22 years in my career I would've seen certain problems disappear forever (as in, be solved, formalized, nailed, and never ever discussed again). But alas, nope.

We who want to achieve stuff, not play all our careers. :/

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.

Same. The dynamic typing helps with prototyping but all MBAs have consistently proven they are NOT willing to have the prototype rewritten in something better later.

I don't think static typing is the right way to go for every kind of application (imagine doing data analysis without dynamic typing), but every dynamic programming language should ideally support progressively adding types to a codebase.

Sure. But now we get to the really hairy problem: library coverage and community support. That's why I think most languages should start converging together already.

IMO we the programmers scatter ourselves too much.

Actors were developed in MACLISP, Commonlisp’s parent.

Oh? Nice, missed that. Is it on the level of Erlang's VM or at least Go's goroutines?

There's a language called PARLANSE which is a parallel LISP.

http://www.semdesigns.com/products/parlanse/index.html

STM is about hardware, not programming languages, but is decently recent so maybe someone will actually try it in hardware and see if it provides a good benefit for the increased complexity of the chip.

Region based memory management was first conceived in 1967 and is achievable by any programming language that lets you manage memory yourself.

Mutable value semantics in native code have been available since at least 1980 with Ada.

Lifetimes in Cyclone seem the best example of PL research in the last 50 years you have there, as it’s only 20 years old.

Overall, I’m still unsure if this list proves the point that there is active useful research in the PL space or if it proves that there’s very little in the PL space to research. More research is probably required.

Rust compiler enables trivial parallelism by enforcing multiple readers ^ writer; and it’s beautiful.

See Rayon.

Futhark (https://futhark-lang.org) is an example of a functional language specifically designed for writing "normal" high-level functional code that compiles to parallel execution.

Functional programming is not based off how hardware is implemented. Serial execution of instructions and mutating chunks of memory at a time are all core parts of how the hardware works which aren't functional. Doing graph reduction and making tons of copies will be slow.

It is a lot easier to write a paper demonstrating some feature than to write a production-quality ecosystem based on that feature. There isn't much either the academic side nor the engineering side can do about that.

And it's not like every academic idea that worked in a paper has worked as well as hoped when someone tried to turn it into a production-quality ecosystem.

The central core of Rust is mutability NAND sharing, enforced by a borrow checker. Was that really established 30 years prior? I thought that came from the Cyclone research language (v1 release 2006) which was only a few years prior to the initial stages of Rust (late 2000s, depending on how you count it)

Proving legality of transformations in the compiler is frequently impossible. Consequently, the main mode of implementation has been to essentially think of the problems in terms of the user saying that this loop is parallel, please make it run in parallel. OpenMP or Rust's rayon crate, for example. The other similar innovation has been programming SIMD as if each lane were an independent thread, which is essentially the model of ispc or CUDA (or #pragma omp simd, natch).

The other big impossible task is that most code isn't written to be able to take advantage of theoretical autoparallelization--you really want data to be in struct-of-arrays format, but most code tends to be written in array-of-struct format. This means that vectorization cost model (even if proven, whether by user assertion or sufficiently smart compiler, legal) sees it needs to do a lot of gathers and scatters and gives up on a viable path to vectorization really quickly.

It's not totally clear what you're looking for.

As you noted, polyhedral compilers work on a pretty restricted subset of programs, but are fairly impressive in what they do. There has been research on distributed code generation [1] as well as GPUs [2]. While there has been work on generalizing the model [3], I think the amount of parallelization that a compiler can do is still very limited by its ability to analyze the code (which is to say, highly restricted).

Then you've got a large class of data-parallel-ish constructs like Rayon [4] as well as executors which may work their way into the C++ standard at some point [5]. How much safety these provide depends greatly on the underlying language. Generally speaking, the constructs here are usually pretty restricted (think parallel map), but often you can write more-or-less arbitrary code inside, which is often not the case in the polyhedral compilers.

If you don't care so much about safety and just want access to every parallel programming construct under the sun, Chapel [6] may be interesting to you. There is no attempt here, as best I can tell, to offer any sort of safety guarantees, but maybe that's fine.

On the other end of the spectrum you have languages like Pony [7] that do very much care about safety, but (I assume, haven't looked deeply) this comes with tradeoffs in expressiveness.

(I work in this area too [8].)

Overall, there are some very stringent tradeoffs involved in parallelizing code and while it certainly has been and continues to be a very active area of research, there's only so much you can do to tackle fundamentally intractable analysis problems that pop up in the area of program parallelization.

[1]: https://www.csa.iisc.ac.in/~udayb/publications/uday-sc13.pdf

[2]: https://arxiv.org/pdf/1804.10694.pdf

[3]: https://inria.hal.science/file/index/docid/551087/filename/B...

[4]: https://docs.rs/rayon/latest/rayon/

[5]: https://github.com/NVIDIA/stdexec (disclaimer: I did a quick Google search on this, not 100% sure this is the best link)

[6]: https://chapel-lang.org/

[7]: https://www.ponylang.io/

[8]: https://regent-lang.org/

Languages like Erlang (or Elixir) that naturally split programs into isolated processes with local state and that communicate via message passing map well onto multi core systems. No need to have the compiler figure that out for you - instead it is expressed directly in the code.

One of the prerequisites to this is for the mainstream to stop doing things which are incompatible with concurrency.

Mutation (and other effects) makes the order of computations important. If you're writing to and reading from variables, the compiler is not free to move those operations around, or schedule them simultaneously.

And you probably don't want to be rid of all mutation. So what if you separated the mutating from the non-mutating? Well you'd need a sufficiently powerful type system. Likely one without nulls - as they can punch a hole through any type checking.

If you want this stuff in the mainstream, you at least have to get all the nulls and mutation out of the mainstream, which I don't think will happen.

The industry for the most part heeded "goto considered harmful" (1968), but hasn't done so with "the null reference is my billion dollar mistake (2009)". Maybe we just have to wait.

Especially when doing things like mapping or list comprehension. I'd love to be able to do operations on collections in parallel by simply marking my functions as pure. Just a simple xs.map {x -> f(x)} combined with "f" marked as pure confirmed by the compiler to make the magic happen.

It isn't really. There have been plenty of innovations in parallel computing:

* Go, with goroutines and heavy use of channels.

* Rust which is free of data races and generally improves the safety of multithreaded programming via Sync, Send and just safer APIs (e.g. Mutex).

* Chapel, which is a language designed primarily for multithreaded and multiprocess computing.

Those are just the ones I know about. There's obviously way more.

Take a look at Halide, which can autovectorize and multi-thread graphics computations (but does require a restricted language).

Array languages, such as APL and others, tend to be easily parallisable given primitives tend to focus on intent and how to transform data rather than imperative operations.

Some of the SIMD operations feel very reminicent of APL primitives

Piquant and jejune?

same here, some companies are hiring a compiler team for AI in fact.

I was told Rice and UIUC provide the best compiler program, though not necessarily AI related, should be similar though.