What will programming look like in 2020? (2012)

Well… No.

It misses some landmark features like HKTs, and it likely never won't get them.

Inspiration? Sure. But what lang today doesn't take that?

> I’m not sure I’d call Rust mutable-first either.

So what do the affine types track? ;-)

> As for side-effects, I suspect the next leap in PL development will be an efficient algebraic-effects system with a good dev experience (or at least a trade-off so appealing it overcomes the necessary friction).

Let's make "some effect system" out of it and I'm with you.

But it likely won't be Rust getting such features in the near or midterm future (no clue about such a possibility in the far future, though).

Other languages are almost there on the other hand side. Scala for example will get "ability tracking" real soon™ now.

Rust may seem a little bit like a FP lang at frist if you're coming form one. But after writing some code you going to realize that Rust's philosophy is quite different form a FP lang: Rust embraces mutability and side-effects at its core! It "just" tries to make that more safe.

Pascal. That could be used as a systems programming language. Maybe it's not perfect - C++ wins when it comes to resource management - but that doesn't mean it's unfixable. Just fix the bits you don't like. Sorted.

I could go on: Dylan, Ada, even Basic. They all "work". We've been inventing language after language after language, and yet all the key ideas were already there.

Now, it's true, many are lacking the kinds of libraries we want. And most of these languages don't receive the love they need to smooth over the rough edges that have programmers reaching for the more popular languages.

Let us now consider programming languages that can be programmed graphically. These kinds of tools get announced with great hype, only to be ignored when everyone realises that it's more fuss that it's worth.

And yet, it's maybe not a complete wash. NodeRed looked practical, and Scratch seemed to have a place. In principle, the whole idea that a program can be viewed as a schematic has appeal.

Then there's the "MX" tool for STM32 MCUs (microcontrollers). It can used to configure the pins and peripherals of your MCU. I hated it at first, but now I'm seeing its advantage at simplifying configuration, even if it does spew out a ton of stuff.

One thing about MX is that it "understands" the chip, so it knows about conflicts of pins and the limitations of the chip. The key thing here is that it's a metatool, a kind of Domain Specific "Language" (although it's actually graphical). It can achieve something that general-purpose languages can't. There's no magic here, of course, the MX only understands the chips because it has been programmed to.

MX is completely useless for making things like database applications, for example.

So DSLs /can/ work - maybe - but they tend to suffer from the same problems as graphical programming tools. They are also niche products, so they don't tend to get much interest. They also tend to suffer from the problem of "walled gardens" - whereby anticipated things are trivial, but unanticipated things are impossible.

One of my own ideas is a kind of "compilation language". It would be a language, possibly a subset of a larger language, in which you could give developers something that "understands" their problem domain. I'm thinking something along the lines of C++'s notion of "constexpr all the things". Perhaps we could push this idea so far that we could build a set of libraries that the compiler itself executes and can validate other developer code.

This is obviously true in abstract, but the real breakthrough happens when you make those concepts ergonomic for the working developer. The theory behind dependent types is well established, but I can't really write my next project in Idris, can I?

Similarly, there was a time when C was the only sensible choice to write anything non-academic, non-toy. It's not like people didn't know about OOP or functional programming back then, but it wasn't a realistic possibility.

Or parametric subtype polymorphism, also known by its common name "generics". The concept has been around at least since the 70s, C++ templates weren't widely used before what, 1990?

> My guess for the future is more that we will see a kind of split between a big group of people using advanced low-code like tools for programming day to day things

This has arguably already happened, we call them data scientists. Many of them are technical and have some light scripting skills but they couldn't be put to work on, say, your average backend project. Obviously this is a gross generalization, titles mean literally nothing, I'm pretty sure there exist data scientists that kick ass at coding.

Except for the perpetual no-code and DSL memes, whether git would dominate as much as it did was pretty much up in the air in 2012. Same with functional languages. In 2012 the mainstream was what, Java 1.6? ML/Haskell was like a breath of fresh air, it's hard to understate how pure OOP a la early Java sucks. The fact that some functional features would become mainstream wasn't a given back then, if anything, that is the surprising turn of events.