?

Log in

No account? Create an account
entries friends calendar profile Elf Sternberg's Pendorwright Projects Previous Previous Next Next
Programmers think too holistically for their own good - Elf M. Sternberg
elfs
elfs
Programmers think too holistically for their own good

This may be an idiosyncrasy, but I doubt it, because I see too many examples of it in open-source code all the time: I have this strong suspicion that software developers think too holistically. There’s even a rather trenchant and famous cartoon illustrating how a developer loses context with a simple interruption and has to rebuild the scaffolding of his thoughts before he can fix the issue.


I had this problem recently. I’ve been noodling with a small lisp interpreter that I was building as an exercise, and one of my steps was to write a lisp-like “cons” list library, recodify each node from a record-in-a-vector to lists-in-lists, and then build upward from there. My target language was Coffeescript. There are three major components to the interpreter: an eval() function, the environment, and the syntax.


Special forms are injected into the environment at initialization time, and obviously both the “define function” and “if” statements need to be able to call eval() to evaluate their arguments, since this is an interpreter that works its way to the bottom of the AST and then evaluates upward to a final result.


As I was making the changes, I got terribly lost making the special forms respond to cons lists rather than vectors or dictionaries. The structure of a node from the reader became (type value blame), where a value would be a cons list of nodes when type became “list”. The distinction between the two types became muddled in my head, and I kept worrying about what it would mean to switch to the other phase of processing.


And then I realized: I should stop worrying. Everything I needed really was right before my eyes. Knowing the code in front of me, I could easily reason about everything I was doing right then, right there. This data structure would get handed off eventually, but I shouldn’t care. There shouldn’t be context above and beyond what’s on the screen.


I think this is why I’m really starting to like F# and Haskell and that family of languages so much. (And Lisp, really); I shouldn’t have to think that hard, I shouldn’t be spending every day at the utter limit of my human understanding just to get my job done. I know, that’s the holy grail of development, yet I’m convinced that it’s not only a reachable goal, it’s one we perversely avoid. We’re proud to plumb code through multiple layers when we ought to be ashamed of it.


I think we ought to consider the baseball bat as a unit of code quality: if the code is so hard to understand the next guy will want to come after you with a baseball bat, maybe you should consider re-writing it.

2 comments or Leave a comment
Comments
From: cjfens Date: March 31st, 2015 06:50 pm (UTC) (Link)

baseball bat standard

I think we ought to consider the baseball bat as a unit of code quality: if the code is so hard to understand the next guy will want to come after you with a baseball bat, maybe you should consider re-writing it.

This is my definition of a well-written proof in mathematics :)
tcepsa From: tcepsa Date: April 4th, 2015 03:53 am (UTC) (Link)
I saw something awhile back that suggested perhaps one of the reasons why software developers are reluctant to embrace practices and tools that reduce errors in their software is because of the high that we get when we track down a bug (and how it is so much more satisfying for our brains to experience that rather than to try to appreciate the amount of work saved by crafting a well-written piece of code). (Though my forays into test-driven development suggest that perhaps it could work as a stand-in. It's almost as satisfying to get to green, especially after a tricky refactoring, as it is to find and fix a bug ^_^ )
2 comments or Leave a comment