Near Future of Programming Languages [pdf]

It's hard to know what I don't know. I try to look at what people are doing/liking. But I feel confident that programming is inherently going to be about expressing the essence of the problem you're solving - a program will necessarily be as complex as the problem it's solving - and I think that limit is within reach of the approach I'm advocating, which is a conservative extrapolation of things we mostly already value. So I don't see the need to do anything more radical.

> If Idris is a big step ahead of Java, by how much do you think costs at, say, Google or Amazon or Citibank would drop if they decided they would all switch to Idris tomorrow? I'm fairly certain that it wouldn't be anywhere near 30%, and I'm not even sure costs wouldn't actually rise.

A lot of the value of better programming would be new opportunities, not just cutting costs. I think the industry switching to Idris-level languages will bring a factor of 10 to 100 improvement in productivity - i.e. I expect we'll see companies of ~100 people putting the Google/Amazon/Citibanks out of business, and companies of less than 10 people competing heavily with the giants. That's the sort of thing technological improvements enable - compare the rate at which new videogames are being produced now, and how small the teams producing them are, or look at WhatsApp being treated as a serious competitive threat to Facebook with a staff of 10. I think there's been a lot of productivity gain recently that isn't fully captured in economic measures, because we've (rightly) become a lot more quality-of-life focused culturally, and so our productivity has gone into quality-of-life improvements that aren't so visible in GDP terms.

But I fully expect the transition to take decades, with good reason - I agree that a large company switching tomorrow wouldn't reap much benefit from Idris (though I do think we're at the stage where a technologically-aggressive startup should consider it).

Btw Visual Basic continues to exist under Visual Basic.NET and if you stick to the basics you could learn to write C# GUI programs pretty quickly.

I agree writing GUIs by hand is very counter-productive.

I tend to agree. The two big wins from a more “functional” style, from my perspective, are the clear emphasis on the data and the way effects are more explicit and controlled.

I want things like higher order functions and algebraic data types and powerful interface/class systems. With those I gain many useful ways to represent and manipulate data that I don’t have in most languages today.

In a world where most mainstream languages are just discovering filter, map and reduce on their built-in list types, a language like Haskell gives me, out of the box, tools like mapAccumWithKey that work with any data structure as long as it provides the specific, clearly defined interfaces required for the algorithm to make sense.

In a world where most mainstream languages are worrying about accidentally derefencing nulls or whether there’s a proper type for enumerating a set of values, functional languages routinely use algebraic data types and pattern matching, and some go much further.

Arguably, these aren’t really functional concepts at all, in that you could have them just as well in an imperative language. However, in practice it is the functional-style languages that are far ahead in these areas, because they are a natural way to work in languages that emphasize composition of functions and careful, explicit handling of data.

I also want to know that I’m not applying effects on resources unintentionally, or sharing resources without proper synchronisation, or trying to apply effects on resources in an invalid order, or failing to acquire or release resources properly, or leaving resources in a mess if something aborts partway through an intended sequence of effects. This aspect goes a lot further than just making data constant-by-default, but it certainly doesn’t require trying to remove state and effects altogether. These things aren’t so much about making my code more expressive but about stopping me from making mistakes.

I want a language that will stop me from accidentally modifying a matrix in-place in one algorithm while some other algorithm has a reference to that matrix that it assumes won’t change. I don’t want a language that will stop me from ever modifying a matrix in-place. Sometimes modifying things in-place is useful.

I want a language that will be explicit about the initialisation and lifetime and clean-up of a locally defined cache or temporary buffer. I don’t want a language that tells me I can’t cache a common, expensively computed result 15 levels deep in my call hierarchy without changing the signature of every function on every possible path to that point in the code, or a language that will let me do whatever I want but only if I use some magic “unsafe” keyword that forfeits most or all useful guarantees about everything else in the universe as well.

In this respect, my personal ideal programming style for most tasks very much would be a hybrid of imperative/stateful and functional/pure styles, with the key point being that the connections between them should be explicit, obvious and deliberate.