I have nothing against Kotlin, but we should be much more ambitious for the Next Generation of programmers. There's so much more progress to be made in (mainstream) programming languages than the tiny step from Java to Kotlin.
As it has always been in the history of programming, what it takes for this potential to come true is for the current generation of programmers to retire, leaving room for fresh paradigms.
Imagine if all the industry got one generation after Assembly language was "hey, we've made the instruction codes shorter and an IDE that can navigate to line numbers".
"hey, we've made the instruction codes shorter and an IDE that can navigate to line numbers".
That's almost what happened with C. In general I agree with your point though.
"As it has always been in the history of programming, what it takes for this potential to come true is for the current generation of programmers to retire, leaving room for fresh paradigms."
Not so sure about this. I see more of a trend to repeat previous errors because the industry as a whole quickly forgets lessons.
Does it truly forget? A lot of the past knowledge is locked away or it was only experienced by 1000 programmers back in the 70s. It stands to reason that the huge amounts of programmers today have to learn their own lessons.
I think maybe in 2050 or so we will reach software development maturity, once the base of experienced developers is not dwarfed by the generation of developers joining the work force in one single year.
Keep in mind that the number of programmers is not only increasing moderately in developed countries, but much more so in developing countries, where hundreds of millions of people are joining the global middle class.
A lot of past knowledge is also very available and mostly ignored. Even the most popular books about programming are read only by a tiny minority of programmers. Listening to our elders is simply not part of the current programming culture.
I always think that a lot of the young guys who are struggling with C would actually read K&R instead of random blogs they would quickly have a solid understanding.
Most of today's books are really bad in comparison. Too long, no depth.
On the other hand the cool thing about programming is that you can get started and be productive without almost no knowledge of theory. Compare that to physics or math where anything interesting requires years of prior training.
I hope we'll find some balance where we don't lose the ability to get started quickly but still respect and study older achievements.
Edit: Oh ho ho. I missed that "Next Generation of Programmers" is in the title. I think it's a pretty misleading title. I think Kotlin just makes places where java is required less painful.
You mean like Rust, Scala, Clojure, Haskell, Erlang, etc?
I don't think Kotlin is aimed at the Next Generation of programmers. I think it's squarely aimed at "We Have A Big App In Java" or "It's This Or Java" programmers. The other bits that don't seem related (the typescript support, the native support), support that because it reduces code duplication. Why write things twice (once in Kotlin, once it java), when you could just write things once, in Kotlin.
Don't get me wrong, they are sanding down a lot of rough corners; but ultimately their explicit goal of really nice java interop limits them. But their goals isn't to be for the Next Generation of programmers, it's to be for java programers.
> we should be much more ambitious for the Next Generation of programmers
There's a lot of value in using simpler (but modern) languages in production instead of something choke-full of paradigms. Creators of popular languages seem to more or less agree with that (e.g. Java -> Kotlin, C++ -> Golang, Scala -> Dotty/Scala3).
If I remember correctly, one of the motivators for Go was the desire to avoid having to use C++ by the original authors. That said, I agree that Pyhon -> Golang fits in that trend too.
To be fair, Googlers can't write modern C++ because they have a critical mass of legacy code that has never been exception-safe. Avoiding RAII kneecaps the whole language badly.
The beauty of RAII is that every resource is tied to the lifetime of an object, and every object is always in a usable state. Having to call extra open/close methods and check error codes breaks these invariants, and leads to objects with bad fidelity to the normal copy and move semantics the language is built on.
Totally agree - and "new paradigms" isn't the same thing as "choke-full of paradigms". What's more, there's as much value in taking things away than in adding them (how about classes for example?)
While Clojure has failed to become mainstream so far, it certainly hasn't failed to be influential. Whatever programmers use in a generation, it may have a lot of ideas from Clojure in it!
And while it's far from mainstream, it's certainly a healthy language with a vibrant community nowadays. There's also a lot of exciting work being done on ClojureScript, and I think that it has even higher value proposition seeing how front-end development with Js is a hot mess right now.
Revolutions do happen! For instance, JavaScript, with all its defects, brought a lot of great ideas to the mainstream (first-class functions, data literals, etc.).
The two aren't incompatible. Progress tends to be made of revolutionary jumps followed by evolutionary refinements. It's perfectly legitimate and useful for Kotlin to fall firmly under the "evolutionary refinement" category, and we can all reap the rewards of that evolution, while other teams elsewhere are trying for the revolutionary jump.
Instance derivation is likely not impossible when typeclasses support is there. I wonder how expensive it could be, though. Making them also usable from Java (e.g. Comparable) would likely be problematic sometimes due to Java's inconsistencies.
Can receiver lambdas (the "DSL" feature) be used to produce something comparable? For something comparable to LINQ, though (same expression targeting e.g. an object graph and an SQL database), compiler support would likely be needed.
Such an argument is bereft of logic and full of lazy moralization and Utopian rhetoric.
It has not always been that incumbent programmers hold back the next generation and in many cases it was absolutely warranted due to shortsighted and narrow-minded ambitions. Your talk of "fresh paradigms" reeks of NIH syndrome.
The advancement of an industry requires careful consideration and conscientious measurement of competency, not some nihilistic desire to burn everything down for the sake of some vague Utopian future.
As it has always been in the history of programming, what it takes for this potential to come true is for the current generation of programmers to retire, leaving room for fresh paradigms.
Imagine if all the industry got one generation after Assembly language was "hey, we've made the instruction codes shorter and an IDE that can navigate to line numbers".