The paradigmatic chasm between programmers and normal humans is huge.

I was just reading a blog entitled The Myth of the Super Programming Language and came across an astonishing comment; partially reproduced here, (as I can't link to the comment itself)

...

Here’s a case study. I once asked our secretary to backup our shared mini-computer in the morning, before the rest of the company showed up. I wrote down, on paper, a simple set of instructions, that covered every case I could think of. For example, I wrote down “Go to any terminal. If you see c:> on the screen [ed. i.e. a developer forgot to logout before going home the night before], type ‘logout’. When you see ‘login:’ type ‘operator’, and then when you see ‘password:’ type ‘yyy’. Then type ‘backup’.”
I came in one morning and found the following on EVERY screen in the office:

c:> logout
login: operator
password: yyy
c:> logout
login: operator
password: yyy
c:> logout
login: operator
password: yyy
…

I had to ask her why she did this – being a programmer, I couldn’t understand what was in her mind. It turned out that the concept of ’sequence’ was not bred into her thought process. In essence, she treated the instructions in a declarative, pattern-matching manner. After every action, she re-scanned the whole sheet of instructions and picked the closest match, instead of treating the instructions in a sequential manner as I had intended. Every time she successfully logged in as operator, the closest match on the sheet of instructions was “if you see C:>, type ‘logout’”, so she did that. Again and again.
The paradigmatic chasm between programmers and normal humans is huge. We can’t even recognize that programmable computers are a burden to the general population, not a boon.
What we need are programming languages that allow software engineers to produce products – encased in epoxy – that provide solutions to specific problems. Whether we choose to use programmable computers inside the epoxy is our own problem, not the customers’.

Wow.

I think I now understand how there is a market for apple products.

I truly never understood before.

Disagree and agree so strongly

I watched a strange documentary type program recently:

zeitgeist

It goes into a lot of different ideas, about a whole heap of different (sometimes completely unrelated) ideas.

One thing that I liked in it was that there is some factual truth to the christian bible. That basis being that all of the stories and characters in it are direct representations of  astrological signs and their astronomical connections.

That was about it though.

The logically impossible is possible

In Java, how do you avoid a NullPointerException?
Easy, you test if an object equals null before trying to call any methods on it. Any idiot could tell you that.
What do you do when that null check is what is throwing your NullPointerException?
That's not so obvious ...... you fix your classpath.

So I'm running some JUnit tests in eclipse, and a particular test is throwing a NullPointerException.

Line 53's throwing NPE I think to myself, easy I'll just add a check for null. The problem was, that line was already a null check. So I fired up the debugger to try and work out what was happening. The eclipse inspect feature is great, so I put a breakpoint on line 53, and inspected the variable, yup it's null. I then inspected the null test, and it resolves to true.

So why is it throwing NPE when it's executed? What the hell is going on here? After double and triple checking that I wasn't just going crazy, I sat back and brain stormed some possible causes for a check for null actually causing a null pointer exception. nothing. I've been in a similar position a few years ago; I was debugging some code and it seemed that eclipse was telling me that true == false. Yep, despite what I learned in philosophy, the logically impossible actually is physically possible. It turned out to be a combination of null values, autoboxing, default values for Booleans and eclipse's inspect function.  With that memory I started making random changes to the variable and surrounding code, to see if anything would change the behaviour. Finally I made a change that removed the references to the null object, and found that I was still getting the NPE. This shouldn't have happened. Somehow my changes had no affect on the outcome. Then it hit me, the file I was modifying wasn't being used in the classpath. I checked my eclipse classpath, and for some bloody reason, someone had put a pre-compiled jar of the very source code I was modifying into the eclipse classpath. That jar was needed at deploy time and was built by our ant build scripts, but shouldn't be referenced by eclipse as you can just reference the project itself. I removed the jar from the classpath, and all was well. The question is, why would the debugger take me to that source code instead of to the class file in the jar that was actually used at run time? I guess eclipse was confused by having multiple versions of a class, only one of which had source code. I'm sure there's some kind of moral to the story here, "think outside the box", "rely on your experience", "nothing is impossible", but it's probably something more mundane like don't screw up up your classpath or even better null is evil.