IDEs: order-of-magnitude improvement?
rzwitserloot posted in programming on December 8th, 2006
It’s a common claim that the ‘invention’ of programming languages (versus assemblers) amounted to an ‘order of magnitude’ shift in the ease of programming. Most people I talk to agree to this.
From here it gets fishier. Joel claims there are 5 silver bullets and that’s it - and more recently insinuates there are none, except for the invention of programming languages here
I feel for that camp, because the essence of the message: That programming is intractably difficult, is (to me) absolutely true.
There are a number of features which have been claimed to be ’silver bullets’ - in the sense that they provide an order-of-magnitude improvement. And for every claim, there are a lot of detractors.
For example, I’ve asserted that IDEs are a silver bullet before, on a forum that’s known for rabid python and LISP fan-boy-dom due to the history of the site. Whoops.
More interesting, to me, is that ones favourite style of programming more or less dictates what one considers magic bullet versus no magic bullet.
Personally, I think this is all a bunch of bull. So much depends on so many factors that calling any one thing ’silver bullet’y and something else ‘not important’ is fallacious for a very large group of programmers and situations. There is only ‘a good idea’, and ‘general improvement’.
And, of course, programming is intractably difficult. A definition if ’silver bullet’ which means: Solves ALL your problems, is a pipe dream. Most specific problems can be solved, but at some point you bump up against the problem that programming is actually hard.
Relevant links:
IDEs are nice, though (thanks for that link Axel, by the way).
Reg Braithwaite nails this whole silver bullet thing as a storm in a teacup. Good read. He really does the meta-topic of why programming is intractably difficult far more justice than I can.

December 8th, 2006 at 8:05
IDEs can certainly being an improvement in productivity from code navigation features.
I hope you’re not thinking of stuff like getter-setter generation and other boilerplate expander macros though, since those only exist to fix problems in the language.
December 8th, 2006 at 21:36
boilerplate is a term that indicates there’s a problem. Pattern is usually similar.
I refer generally to come-from, follow, and company.