This story inspired me tonight: reading about how he didn't know if it would work or not, and how he fixed bugs as they arose is true hacking style. And it's definitely a way to get things done. So that's what I did tonight, and made a ton of progress; just hounding down and stomping on bugs mercilessly.
Why wasn't I doing that already? I'd been reading too much Dijkstra, that the "competent" programmer can show whether his code will work or not. It's definitely possible to do it that way, but it's (very sadly) too high a standard for me to reach in reasonable time (or maybe at all), for more than toy problems. Dijkstra used this approach to write a multitasking operating system. I'm pretty sure I couldn't do that.
So, there are two ways to do things, an easy way and a hard way. Once you've done it the easy way, it's probably a lot easier to cover up the traces and make it look like you did it the hard way.
And a guy who is famous both for being incredibly clever and for being rather arrogant and insecure told all his competitors that they were incompetent if they didn't do it the hard way.
Programming is a form of mathematics. Maths papers are terse and beautiful and look as though they have sprung fully armed from the head of Zeus.
But you don't see the days of hacking through examples and crazy leaps of intuition (that are almost always wrong) in the finished paper, because the mathematician removes them from the story in order to leave an argument that is easy to verify.
I am not saying that Dijkstra couldn't do things the hard way. I would be amazed if his best stuff was done the hard way.
I think it really depends on how well you know the underlying system. Once, I was working on a project written in object pascal and I got to the point where opening the debugger was on average the slower approach to solving most problems. However, I am no where near that point when writing .Net code because the language and the platform became to complex for me to really understand.
I like this experimental approach, it's like debugging, except you can also edit what inputs you accept. But is it actually accepted by mathematicians as an accurate description of what they do?
http://en.wikipedia.org/wiki/Proofs_and_Refutations
> the guy wrote a multitasking operating system with this approach. I'm pretty sure I couldn't do that.
You'd be surprised at how doable that is if you actually tried. It's the same as every other problem in programming: break it down in to two pieces, figure out which one is the easier, if it is trivial solve it, otherwise recurse.
You'd need an overall sketch of the architecture before you began but once you have that worked out it's 'just programming' to get you to the finish line.
The hardest part to get right is security, especially if you go multi-user, but since you just specify 'multitasking operating system' that one is somewhat limited in scope.
Thanks, I appreciate the support, but my opps, you caught my initial phrasing before I clarified to disambiguate: I didn't mean to write an operating system; but to write one in Dijkstra's way (ie by showing - proving - that it works before you write it). ugghh I shudder just saying it.
I'm sorry; I didn't mean to dig a pitfall to entrap a helpful fellow traveler. When I noticed that a reading with the last two sentences as separable was misleading, I edited directly. I think the "sadly" part was communicated though, and I've tucked away your remarks for when I'm confronted by a multitasking OS. I think debugging the race conditions would be nightmarish.
The trick is to write your OS in such a way that you minimize the chance of having races. The way I chose was to mimick 'QnX', a message passing real time OS.
Yes, that was one of the main problems when I was busy with this. I had a guitar footpedal switch wired to the reset button so I didn't have to dive under the desk all the time.
This was before the age of virtual machines on PCs. Getting it to become self hosting took about 6 months or so.
It's not possible to do unless you fully understand the problem you're trying to solve. When you're exploring the problem you need a "scratch area". In modern times, the scratch area is your programming environment rather than paper and chalkboard.
Why wasn't I doing that already? I'd been reading too much Dijkstra, that the "competent" programmer can show whether his code will work or not. It's definitely possible to do it that way, but it's (very sadly) too high a standard for me to reach in reasonable time (or maybe at all), for more than toy problems. Dijkstra used this approach to write a multitasking operating system. I'm pretty sure I couldn't do that.