I'm a recovering programmer who has been designing video games since the 1980s, doing things that seem baroquely hardcore in retrospect, like writing Super Nintendo games entirely in assembly language. These days I use whatever tools are the most fun and give me the biggest advantage.
james.hague @ gmail.com
Where are the comments?
Remembering a Revolution That Never HappenedTwenty-three years ago, a book by Edward Cohen called Programming in the 1990s: An Introduction to the Calculation of Programs was published. It was a glimpse into the sparkling software development world of the future, a time when ad hoc coding would be supplanted by Dijkstra-inspired manipulation of proofs. Heck, no need to even run the resulting programs, because they're right by design.
Clearly Mr. Cohen's vision did not come to pass, but I co-opted the title for this blog.
That book is a difficult read. It starts out as bright-eyed and enthusiastic as you could expect a computer science text to be, then rapidly turns into chapter-long slogs to prove the equivalent of a simple linear search correct. It wasn't the difficulty that made the program derivation approach unworkable. Reading and writing music looks extraordinarily complex and clunky to the uninitiated, but that's not stopping vast numbers of people from doing so. The problem is that for almost any non-trivial program, it's not clear what "correct" means.
Here's a simple bit of code to write: display a sorted list of the filenames in a folder. That should take a couple of minutes, including googling around for how to get the contents of a directory.
Except that on some systems you're getting weird filenames like "." and ".." that you don't want to display.
Except that there are also hidden files, either based on an attribute or a naming convention, and you should ignore those too.
Except that you need the sort to be case insensitive or else the results won't make sense to most users.
Except that some people are using spaces between words and some are using underscores, so they should be treated the same when sorting.
Except that a naive sort is going to put "File 10" before "File 9", and while that's logical in the cold innards of the CPU, it's no excuse to present the data that way.
And this is a well-understood, weird old relic of a problem that's nothing compared to all the special cases and exceptions needed to implement a solid user experience in a modern app. Making beautiful code ugly--and maybe impossible to prove correct--by making things easier for the user is a good thing.
(If you liked this, you might enjoy Write Code Like You Just Learned How to Program.)