News for hackers. Stuff that matters.
Re:What will programming look like in 2020? (2012) by kaba0 on Sunday September 26, 2021 @11:20AM (#28661542)
I may not really get your point: are you trying to prove or disprove the original article?

In my opinion it does hold up, since indeed we can hardly even be 2x more productive in a barebone project with different programming languages, let alone an order of magnitude.

And what you are getting at is as far as I remember was the escape hatch mentioned by Brooks himself, that is the only significant improvement in productivity will come from the ecosystem. And I think we are behind even at that, in that we unfortunately have many NIH projects doing the exact same thing across language ecosystems, with not much interoperability. Eg. the JVM, Python, JS ecosystem has barely any shareable elements. Hopefully something like Graal’s polyglot might change it in the future.

Re:What will programming look like in 2020? (2012) by kragen on Sunday September 26, 2021 @12:06PM (#28662027)
Well, I was hoping to disprove it, and then I looked at things I'd written recently in high-level languages, for which I had logs of how long it took me, and came to the opposite conclusion: Python might be more productive than Ada, but not by an order of magnitude. Of course someone else might be a much better programmer than I am in Python, but in all likelihood their improvement over me in lower-level languages would be even bigger.

The library ecosystem is a great bright spot: the cost of modularity has fallen to such a point that leftPad is its own NPM module. The fact that Python has a separate leftPad as the .rjust method on strings seems less significant than the reduction of duplication within each ecosystem. Historically if you wanted your library to be usable from anywhere, like D-BUS, you wrote it in C, and that's still a viable option; but Rust is shaping up to be a better alternative there.

I do think we can be more than 2× more productive in a barebones project with better programming languages, because I've been programming in assembly language this week, and it is pretty slow going. But I reluctantly came to the conclusion that Brooks was right: the big leap in raw productivity was from assembly to Algol 60, not Algol 60 to JS. (And, separately, from batch mode to interactive programming.)