5 ms·

I don't think that Brooks was arguing that any given fixed programming task could not be made easier over time; clearly, even in 1986, there were programming ta

I don't think that Brooks was arguing that any given fixed programming task could not be made easier over time; clearly, even in 1986, there were programming tasks that had become trivial by use of existing code but were originally quite challenging to code on their own. I think Brooks was talking about the work of the individual programmer: given two identical programmers, with the same available libraries of existing code, is there a language or IDE that will make one 10x more productive than the other? And I think the answer is still, no.

brabel 6y ago
Exactly, this blog post missed the point completely. Unbelievable.
joshuafcole 6y ago
I think the lines between "available library of existing code", language, and IDE are much murkier than they might appear. If one programmer is given raw assembly and the other Python, you're probably going to see at _least_ a 10x productivity bump to the python user _even if they use no additional libraries_. Language and IDE choices impact the vocabulary available to express solutions in the same way.
- vannevar 6y ago
  You can certainly contrive a counter-example---even in 1986, you could say much the same thing about assembly and something like C or BASIC. But once that leap of abstraction was made, we seem to have hit a plateau of expressive power. Is the jump from C to Rust as empowering as the jump from assembly to C? I don't think it is.
jnwatson 6y ago
You're added premise is an implicit point of Luu's article. Or perhaps the point is that Brooks' framing doesn't really apply when you can avoid programming altogether. The silver bullet is open source. The ability to utilize the millions of hours of other people's work to accomplish your programming task is the game changer, and is what makes formerly complicated tasks trivial. The essential complexity of the software I deal with is about two orders of magnitude more complicated than stuff I dealt with 20 years ago. I'm not sure that 20 years from now it will be another two orders of magnitude, but perhaps with utility computing and higher level orchestration concepts, it very well might be.
- astine 6y ago
  Broooks framing does apply when you can avoid programming altogether. He specifically mentions that as is prefered solution to the problem. Rather than coding systems from scratch, in which case you have to deal with the essential complexity inherent in the problem, you can either buy software or share components between developers and avoid having to deal with the problem altogether.

brabel 6y ago

Exactly, this blog post missed the point completely. Unbelievable.

joshuafcole 6y ago

I think the lines between "available library of existing code", language, and IDE are much murkier than they might appear. If one programmer is given raw assembly and the other Python, you're probably going to see at _least_ a 10x productivity bump to the python user _even if they use no additional libraries_. Language and IDE choices impact the vocabulary available to express solutions in the same way.

vannevar 6y ago
You can certainly contrive a counter-example---even in 1986, you could say much the same thing about assembly and something like C or BASIC. But once that leap of abstraction was made, we seem to have hit a plateau of expressive power. Is the jump from C to Rust as empowering as the jump from assembly to C? I don't think it is.

jnwatson 6y ago

You're added premise is an implicit point of Luu's article. Or perhaps the point is that Brooks' framing doesn't really apply when you can avoid programming altogether. The silver bullet is open source. The ability to utilize the millions of hours of other people's work to accomplish your programming task is the game changer, and is what makes formerly complicated tasks trivial. The essential complexity of the software I deal with is about two orders of magnitude more complicated than stuff I dealt with 20 years ago. I'm not sure that 20 years from now it will be another two orders of magnitude, but perhaps with utility computing and higher level orchestration concepts, it very well might be.

astine 6y ago
Broooks framing does apply when you can avoid programming altogether. He specifically mentions that as is prefered solution to the problem. Rather than coding systems from scratch, in which case you have to deal with the essential complexity inherent in the problem, you can either buy software or share components between developers and avoid having to deal with the problem altogether.