• IDEs. Almost useless. Code completion can be fun, but not as helpful as some folks claim. I've had folks tell me that VB is an acceptable language because of Visual Studio. Syntax coloring is perhaps the most useful feature ever invented. The rest should be optional add-ons, so we can dispense with them and free up memory and processor cycles.

As crutches go, there are worse things to depend on.

• Debuggers. Useless. Except when the language definition is so bad that the semantics are so murky that you cannot understand what was supposed to happen. For example, VB. When a debugger is necessary, it's really time to get a better language.

Based on my experience teaching programming, debuggers can be unhelpful. For some people, they lead to clouded thinking and a weird empirical style of programming where there's no semantic significance to the code -- no meaning -- just pure hackery.

• Ant scripts, etc for compiling. Incremental compilation and linking isn't really all that great an idea. With hyper-complex languages, it's a necessary hack, but really needs to be seen as a hack. It's not necessary or even desirable.

A better language with less reliance on incremental compilation seems like a far, far better thing than sophisticated Ant scripts.

• Sites like Stackoverflow to help if you're too stuck on a bug. Sometimes helpful.

As with debuggers, there's a possibility that some folks will appear to be successful through simple blundering luck. That's a bad thing.

• IDEs. Almost useless. Code completion can be fun, but not as helpful as some folks claim. I've had folks tell me that VB is an acceptable language because of Visual Studio. Syntax coloring is perhaps the most useful feature ever invented. The rest should be optional add-ons, so we can dispense with them and free up memory and processor cycles.

  As crutches go, there are worse things to depend on.

• Debuggers. Useless. Except when the language definition is so bad that the semantics are so murky that you cannot understand what was supposed to happen. For example, VB. When a debugger is necessary, it's really time to get a better language.

  Based on my experience teaching programming, debuggers can be unhelpful. For some people, they lead to clouded thinking and a weird empirical style of programming where there's no semantic significance to the code -- no meaning -- just pure hackery.

• Ant scripts, etc for compiling. Incremental compilation and linking isn't really all that great an idea. With hyper-complex languages, it's a necessary hack, but really needs to be seen as a hack. It's not necessary or even desirable.

  A better language with less reliance on incremental compilation seems like a far, far better thing than sophisticated Ant scripts.

• Sites like Stackoverflow to help if you're too stuck on a bug. Sometimes helpful.

  As with debuggers, there's a possibility that some folks will appear to be successful through simple blundering luck. That's a bad thing.

20 years ago... 1991...

Let's see. I was using SunOS and VAX VMS.

We wrote code using text editors (vi or edit).

I -- personally -- don't use debuggers and never did. Some folks used the adb debugger on SunOS. I actually used it a few times to recover a stack traceback from a core dump file. I have no idea what was available on VAX VMS. I used print statements in the code.

We used make for compiling.

We read the paper documentation, thought and ran experiments. Indeed, that still works. Stack Overflow is overused by a few people who -- for inexplicable reasons -- refuse to run experiments or think.

30 years ago... 1981...

Let's see. I was using Univac Exec 8 and IBM OS.

We wrote code using text editors (I can't recall the Univac one, but the IBM one was the TSO environment's editor)

I -- personally -- don't use debuggers and never did. Those machines were "mainframes" and could not be single-stepped through anything. There was no "debugger". You had to insert print statements in your code.

We wrote scripts for compiling.

We read the paper documentation, thought and ran experiments.

40 years ago... 1971...

Let's see. I was using an IBM 1620 that had no OS.

We wrote code using punched paper cards.

Debugging meant single-stepping the processor. It was rarely helpful, so I learned to insert "print" statements in my code.

We run the compiler by hand to produce a deck of punched paper cards which we then ran. "by hand" meant literally loading cards into a card reader to install the compiler or assembler. Then loading the source code into a card reader to produce object code. Then loading the resulting object code into the card reader to run the program.

We read the paper documentation, thought and ran experiments.

20 years ago... 1991...

Let's see. I was using SunOS and VAX VMS.

We wrote code using text editors (vi or edit).

I -- personally -- don't use debuggers and never did. Some folks used the adb debugger on SunOS. I actually used it a few times to recover a stack traceback from a core dump file. I have no idea what was available on VAX VMS. I used print statements in the code.

We used make for compiling.

We read the paper documentation, thought and ran experiments. Indeed, that still works. Stack Overflow is overused by a few people who -- for inexplicable reasons -- refuse to run experiments or think.

30 years ago... 1981...

Let's see. I was using Univac Exec 8 and IBM OS.

We wrote code using text editors (I can't recall the Univac one, but the IBM one was the TSO environment's editor)

I -- personally -- don't use debuggers and never did. Those machines were "mainframes" and could not be single-stepped through anything. There was no "debugger". You had to insert print statements in your code.

We wrote scripts for compiling.

We read the paper documentation, thought and ran experiments.

40 years ago... 1971...

Let's see. I was using an IBM 1620 that had no OS.

We wrote code using punched paper cards.

Debugging meant single-stepping the processor. It was rarely helpful, so I learned to insert "print" statements in my code.

We run the compiler by hand to produce a deck of punched paper cards which we then ran. "by hand" meant literally loading cards into a card reader to install the compiler or assembler. Then loading the source code into a card reader to produce object code. Then loading the resulting object code into the card reader to run the program.

We read the paper documentation, thought and ran experiments.

"Get Off My Lawn You Rotten Kids"

• IDEs. Almost useless. Code completion can be fun, but not as helpful as some folks claim. I've had folks tell me that VB is an acceptable language because of Visual Studio. Syntax coloring is perhaps the most useful feature ever invented. The rest should be optional add-ons, so we can dispense with them and free up memory and processor cycles.

As crutches go, there are worse things to depend on.

• Debuggers. Useless. Except when the language definition is so bad that the semantics are so murky that you cannot understand what was supposed to happen. For example, VB. When a debugger is necessary, it's really time to get a better language.

Based on my experience teaching programming, debuggers can be unhelpful. For some people, they lead to clouded thinking and a weird empirical style of programming where there's no semantic significance to the code -- no meaning -- just pure hackery.

• Ant scripts, etc for compiling. Incremental compilation and linking isn't really all that great an idea. With hyper-complex languages, it's a necessary hack, but really needs to be seen as a hack. It's not necessary or even desirable.

A better language with less reliance on incremental compilation seems like a far, far better thing than sophisticated Ant scripts.

• Sites like Stackoverflow to help if you're too stuck on a bug. Sometimes helpful.

As with debuggers, there's a possibility that some folks will appear to be successful through simple blundering luck. That's a bad thing.