[mmatants]

It feels like the early language wins were due to the languages themselves introducing new concepts, not just syntax changes. Allowing higher-level reasoning.

Then, past a certain point, most of the new concepts started coming in via frameworks and libraries (although of course things like functional programming and interesting typing approaches are still language-driven tools).

Thus, these days, I would look at libraries and frameworks as sources of new productivity unlocks. E.g. in the Web world, jQuery saved millions of work-hours and qualitatively unlocked some new things. Then Angular (and eventually React) started realizing huge savings from declarative UI definitions. My preference for one next innovation in this area is a higher-level framework for user input modeling (a huge source of bugs these days).

[wtbob]

> It feels like the early language wins were due to the languages themselves introducing new concepts, not just syntax changes. Allowing higher-level reasoning.

I was looking for somewhere in these threads to post my comments, and I think this is the right place: yes, you're exactly right, it really is about higher-level reasoning.

Assembly enabled one to think about instructions and operations instead of hex codes. Structured languages enabled one to think about programs, rather than sequences of mnemonics. Functional programming enabled one to think about functional transformations of data; object orientation enabled one to think about collections of functionality grouped with data; both structured the structure, in different ways. With each improvement, we were able to reason at a higher level than before.

But we're not at an optimal level yet: we still do not have mainstream ways to manipulate the structure of our structure (… of our structure of our structure, ad infinitum). We still don't have a mainstream way of dealing with our programs as data.

It may not be mainstream, but we do have a way: it's older than every other programming language other than Fortran: it's symbolic expressions, which enable one to reason about and manipulate one's code as data (and data as code).

The article we're both replying to is a prime example of the Blub Paradox: Uncle Bob can see how Java is better than C++, C, assembler or hex codes, but can't see how Python — and, yes, Lisp — are better than Java.

[skybrian]

The language still matters, but indirectly, because it constrains which frameworks can easily be built. It's doubtful that jQuery and React would have been invented using Java. Even JavaScript is nicer with a language extension (JSX).

[kuschku]

The thing is, Java has (with some tricks) a fully pluggable compiler. And even without tricks, compile time processing is possible.

But Java is "uncool". That’s the big issue.

[skybrian]

The issue is that if you want to do template-like things using language constructs (internal DSL), the syntax is quite limiting.

There are tricks using annotations and strings, and Java 8's lambda expressions do help. But it's still awkward to define a React-like mini-language within Java.

[kuschku]

Well, anything that is a valid syntax can then be modified by the annotation processor.

Add the fact that you can do blocks, and label blocks, and you can do practically s-expressions.

[thyrsus]

I'd bet that, because the erlang family (erlang, elixir, erlang flavored lisp, ....) introduces important concepts when multiprocessing is involved, that they lead to a non-linear increases in productivity when multiprocessing is relevant to the problem. Further, multiprocessing may be more widely applicable than widely recognized, because the benefit has previously been lost to the former complexity and error-prone nature of multiprocessing.