5 ms·
“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ev
by inopinatus 5y ago
“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”
— Brian Kernighan, The Elements of Programming Style
(fortunately the interview itself is not so trite as the headline)
- javajosh 5y agoHere's an example: I was writing some code that needed predicates and assertions and at first I did the functional thing and mapped the list of preds into a list of assertions. It worked and was short and DRY, but it had lots of downside, not the least of which is that it ruined stack traces (this was in JS). It turned out to be better to just do the simple thing and statically define a list of assertions that mirrored the preds. It was far longer and more repetitive, but much easier to read and understand.
- 6gvONxR4sf7o 5y agoIt’s a real shame languages have such shitty stack traces for functional style code. It’s nothing fundamental about the style, so I’m hoping the situation improves over time.
- dragonwriter 5y ago> It’s a real shame languages have such shitty stack traces for functional style code. It’s nothing fundamental about the style It is, though. Stack traces are fundamentally high-impedance for anything other than structured imperative code.
- jgwil2 5y agoCould you elaborate?
- seanhunter 5y agoI'm obviously not the person you responded to, but one thing to note is that the stack is going to be a more useful source of debugging information if the function call stack is encoding the logic of the program, which I would assert is more often the case in imperative style programming. Imagine for example a state machine implemented two ways. In an imperative style where you have a big if STATE_IS_X /then function_x() /else if STATE_IS_Y ... tree calling a function for each state. Secondly in a functional style where you have a pattern match on a list of tuples of (state, function). In the first case the stack tells you exactly which state you were in and which function got called. In the second case the call stack will look the same in each case because you just match on the first part, unpack the second part into a variable and call the function in the variable.
- jgwil2 5y agoI guess I see what you're saying, but shouldn't it be evident which function got called based on the next stack frame up? When I look at stack traces I guess I'm usually just trying to figure out the sequence of calls so that I can know where to look for a bug, but if I needed to inspect state I would probably be doing it in a debugger.
- ummonk 5y agoThis sounds like one of the many cases that is just begging for good codegen frameworks.
- enriquto 5y ago> “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” By becoming more clever! That's the very principle of learning: to become more clever. The act of debugging your own code to become more clever is a well-known learning technique called "Kernighan's ladder", precisely due to this inspiring quote.
- scollet 5y agoThat's fun. I remember writing a little bit of clever (at the time) code for simplicity and speed. Ended up doing debugging and sanity checks via napkin math to confer with my partner because it was easier than reading through the function.
- vegai_ 5y ago>The act of debugging your own code to become more clever is a well-known learning technique called "Kernighan's ladder", precisely due to this inspiring quote. According to Google, you seem to be the first person to use that phrase.
- Cthulhu_ 5y agoI guess you have a point, but, you don't only code for yourself; the quote applies to others as well, and in practice, few people code in a vacuum. Don't write clever code; the problem you're solving with code is difficult enough already.