Hacker News new | ask | show | jobs
by n0tth3dro1ds 1283 days ago
> How do you debug/reason about this?

Debug? You don’t. You have to break your sexy chained-functional-style 1-liner into a “boring” multi-line loop to actually set meaningful breakpoints and work through any problems that may arise. Which is why I dislike this style of code — once something goes wrong, it’s WAY more cumbersome to debug and almost always makes you “unroll” it into its boring, “classic” form. And, of course, once you do that, you’re now debugging something DIFFERENT than what’s shipping in production! And you have to be extra careful to ensure that all of the logic has been kept the same, lest you ship a patch that doesn’t actually fix the bug! This is my prototypical “what programming is NEVER about” example: programming is never about how pretty the code is. Programming is about shipping features, and then being able to diagnose and fix problems with what you shipped.
2 comments
phoronixrly 1283 days ago
That is both plainly incorrect (you can drop a breakpoint without breaking the chain, see comment below), and missing the point -- I mean, I appreciate the lecture on what programming is all about, but in this case the programming is all about having fun, and writing a solution as fast as possible ¯\_(ツ)_/¯.
link
n0tth3dro1ds 1283 days ago
So you have to add code to debug it with #tap? I don’t care if the chain is unbroken: you have to CHANGE THE CODE YOU SHIPPED in order to properly debug it. That’s idiotic. And before you say “oh, this is just an exercise”, I can tell you from personal experience that I encounter this endlessly in prod code with both Python and Kotlin chained functional style garbage. It is often not debuggable without break-up and unrolling.
link
aiwv 1283 days ago
> you have to CHANGE THE CODE YOU SHIPPED in order to properly debug it

If I'm at the point where I need to debug a production process with breakpoints, I'd rather just find a new job than worry about my coworker's coding style.

link
dragonwriter 1283 days ago
> Debug? You don’t.

If by “debug” you mean “step through with a debugger” (at least Ruby’s standard debugger), sure (except at the steps with blocks, which you can easily insert as noops as needed with #tap). But, honestly, I almost never resort to using a debugger in practice, so minor variations in where breakpoints can be set aren’t something I see as a big deal.

> and almost always makes you “unroll” it into its boring, “classic” form.

No, it never makes you unroll it in Ruby.

link