Made me smile. This is a great analogy. Tactics vs strategy. You can become more efficient at low-level tasks by doing faster text editing. However, as you get into actual software engineering, the first time you need to do some semantic refactoring will wipe out any time you saved through low-level efficiency.

That applies to Java and C# only, where the language grammar is so simplified that you can be 99% confident semantic refactoring didn't screw your code up.

> You can become more efficient at low-level tasks by doing faster text editing.

It's not efficiency for efficiency's sake. It's for being able to code at the speed of thought, to tighten your feedback loop to the point where the act of writing & editing happens in your mind in larger syntactical units.

Also, for actual software engineering, nothing beats a pen and a piece of paper.

Sometimes I use pen and paper quite effectively, but between the slowness of writing and the difficulty of editing, I wouldn't describe it as ideal.

Some of us would say well-designed instead of simplified :-)

That's a longer topic. Having worked professionally both with Java (Eclipse, Netbeans, IntelliJ IDEA) and Common Lisp (Emacs + SLIME), I've experienced both sides of the coin. On the one hand, working with a language without a proper REPL and macros is painful to me. On the other hand, I frequently wish it was even possible to have semantic completion and automatic refactoring in Common Lisp, even at 10% of what you get for Java out of the box in an IDE...