I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?
Remembering a Revolution That Never Happened
Twenty-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.)
permalink April 21, 2013
previouslyExploring the Lower Depths of Terseness
Expertise, the Death of Fun, and What to Do About It
Don't Be Distracted by Superior Technology
Simplicity is Wonderful, But Not a Requirement
The Highest-Level Feature of C