4 ms·

I don't disagree with the theme, but it would be much more persuasive coming from a Lisp corner of the world. Just today, I was discussing with a friend about

I don't disagree with the theme, but it would be much more persuasive coming from a Lisp corner of the world. Just today, I was discussing with a friend about the lack of tail calls in mainstream languages (outside of FP), and how the typical reason cited ("you lose debug stack traces!") makes no sense under any scrutiny (the stack losses from looping are necessarily total, yet tail calls can easily be implemented flexibly to allow for optional stack growth in certain situations like debugging). So we get more complexity (iterative loops) because the pop culture of software development repeats irrational conclusions (apparently) without thinking. Same goes for folk advice like "never rewrite" (okay, okay, it went badly for Netscape once, or something), "never build your own tools/languages" (yes, this isn't software, but the Empire State Building was constructed within a single year by a firm that constructed all of its own tools custom for the job), "role-based access control is necessary for security" (capabilities are actually quite cool), "always reset your password every three months" (lulz). There are many others. I am starting to believe that behind every phrase of false but universally-accepted IT folk wisdom s a billion dollar idea waiting to be demonstrated; extra if you can combine a few together AND give the currently lost wanderers out there a bridge to the simpler, more enduring way.

housecarpenter 5y ago
This may be somewhat off-topic, but I think the point of "you lose debug stack traces!" is that with tail call elimination, you have more possibility for confusion from people who inadvertently write a tail call, or who write something tail-recursive without caring about the stack growth (e.g. if it only recurses a few times in their use cases). That's where the increased difficulty comes from; of course loops/state machines/tail-recursive functions are hard to debug either way. I guess basically the problem is that with loops you know what you're in for with regards to debugging, whereas tail-recursion is kind of implicit---you have to learn how to recognize a tail call, which is non-trivial, or at least non-trivial compared to distinguishing a loop from a function call.

housecarpenter 5y ago

This may be somewhat off-topic, but I think the point of "you lose debug stack traces!" is that with tail call elimination, you have more possibility for confusion from people who inadvertently write a tail call, or who write something tail-recursive without caring about the stack growth (e.g. if it only recurses a few times in their use cases). That's where the increased difficulty comes from; of course loops/state machines/tail-recursive functions are hard to debug either way. I guess basically the problem is that with loops you know what you're in for with regards to debugging, whereas tail-recursion is kind of implicit---you have to learn how to recognize a tail call, which is non-trivial, or at least non-trivial compared to distinguishing a loop from a function call.