Near Future of Programming Languages [pdf]

I do, because the things that you mostly value (I guess I value them a lot less) seem to me incredibly complex for the good that they do, and we already have some alternatives that seem both more powerful and vastly simpler. But I am skeptical of them, too, though :)

> 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 is a very powerful statement, and I'd like to know why you'd think that. I would even like to know what makes you think that any language (never mind which) can make such an impact, even though we've seen nothing of this sort. I do not share your belief that Idris could make such an impact or anywhere near it, nor probably any other language.

I am skeptical, because having looked at Idris and played with it a bit, I was completely underwhelmed. Java + JML can do pretty much the same, if not better, and for a lowe cost, and this is not a statement about Java+JML being a leap forward. I have no idea if Eve could make an impact as big as the one you predict, but at least I don't feel I can instinctively reject this possibility as easily as I could Idris, as Eve actually brings a lot of new things to the table, where Idris feels like some ergonomic improvement over things that may have had some potential that never materialized, in the hope that better ergonomics is what should do it.

I would like to point out one more problem with viewing the abundance of research as a proxy for utility or of an "established idea", one that touches on my own personal biases :) When you publish a paper, certainly in good journals/conferences, you must exhibit some significant novelty. This, ironically, rewards the more complicated (and so arguably less useful in the real world) frameworks and punishes the simpler ones. For example, I've seen papers talking about embedding separation logic, or specifying amortized worst-case complexity in Coq. You won't see such papers on TLA, because doing both in TLA is rather trivial. Lamport himself complained that he had trouble publishing a paper on specifying and verifying realtime systems in TLA because it is so straightforward that it was hard to demonstrate mathematical novelty. He had to artificially add an extra novelty (the use of a model checker) to make the paper worthy of publication [1].

[1]: http://lamport.azurewebsites.net/pubs/pubs.html#real-simple

The language gap is relative to where he thinks we should be aiming for, what the author thinks is possible. If you think that we're already "there", then there is no gap for you, and there's nothing wrong with feeling that way.

Personally, I agree with the author: we can do vastly better. I think it's a failure of imagination and effort, not potential.

All purity does is force you to change the type of a function that wants to log something, to reflect that it’s returning a value that, when evaluated at run-time, will have the side-effect of printing to the console. It’s still a pure function since it returns the same description given the same argument(s), the only difference is that when this description is evaluated by the run-time system, something will be printed to the console (in accordance with the description).

In other words, you’re not restricting the effects your program can have, only how you can choose to describe them (as first-class values whose evaluation has a side-effect that is not observable by your code).

It’s all explained perfectly in this talk: https://www.infoq.com/presentations/io-functional-side-effec...

They can do this because they know a set of higher order patterns, beyond just a knowledge of "objects" and "classes". Beyond just a design approach of identifying classes as the "nouns" in a problem domain.

These higher order patterns represent those business processes, as you call them.

Sadly such a skill is very rarely seen, or even in demand, given that data modeling is the basis for most design today.

That needs substantiation. It's not immediately obvious in any way.

About Babel, notice how we never had a problem playing with language-level features that target the PC? That's the difference a good VM makes (although on the PC case, it's not virtual). Besides, you are conflating VMs and languages somehow - they have only a tenuous relation.

About the speed, Javascript misses most of the expressiveness of Python and Ruby. It's more on line with Java but if you want dynamically typed languages, with PHP and Perl too. Yet, it's not any faster than PHP and Perl. It has reasonably fast runtimes - those are not an issue for the language, but are not a big selling point either.

Overall, the reason Javascript still exists and is viewed as a serious language is all because it has a monopoly on the browsers. It was worked on enough that if that monopoly goes away it will still be a good choice for some stuff, but it is not an stellar language, and can't be coerced into becoming one unless it can pass through a Perl5 - Perl6 level transition.