Comment by YeGoblynQueenne | Hacker News Reader

Comment by YeGoblynQueenne | Hacker News Reader

Parent Full thread

YeGoblynQueenne

Beware the conclusions drawn from the first read through the writings of our functional programmer forefathers (and the second, and the third), for "a little knowledge is a dangerous thing". The unprepared mind of the imperative programmer is especially prone to following the revelations of the old masters before achieving real understanding.

A while ago, I was working in company X, that sold a web platform for job boards, with multiple big and famous clients. One time, there was a bug in our platform, that had to do with a for-loop with an always-true condition. The loop -which was in our core platform code and so deployed in every single website we maintained- caused untold havok, as resources disappeard down a black hole and all our servers dropped to their knees and asked for mercy.

In the aftermath of the incident, when an explanation had to be given to those UpStairs running the show, it was put to them that the cause was an (effectively) unconditional loop. Now, as a lowly junior dev, I was not present in the deliberations but, given what followed, I can imagine the conversation:

  Those UpStairs: "How can we ensure that the same thing never happens again?"

  Senior Software Person: "Well, there is no way to ever be 100% safe. A for-
  or while-loop can always go wrong."

  Those UpStairs: "Is there any alternative to for- and while-loops?"

  Senior Software Person: "Not really. I mean, there is recursion of course..."

  Those UpStairs: "Recursion? What is that?"

Shortly after, we had a big emergency meeting to discuss What Should be Done to Avoid the Same Problems in the Future, where we were instructed to not use the looping constructs of the langauge in which our platform was written, anymore. Instead, we should only ever use recursion to write loops.

The language of our platform was C#, mind. A language that (to my knowledge, and certainly at the time, around 4.0) does not even support tail-call optimisation. Not to mention, it's just as easy to go into an infinite recursive loop as it is to go into an infinite imperative loop, if not easier.

Suffice to say that nobody followed the instructions given from On High, either because they found it too much work, or because they found it too stupid, or because they were just busy pulling their hair out.

It's just as easy (if not easier) to make a mistake with a recursive call such that it never terminates. Why did your team suggest it as an alternative and why was it accepted? TBH the whole story seems very hard to believe.

Of course it was a bad decision. Like I say, I wasn't there when the decision was taken, but I don't think it was suggested by anyone in the tech team. Instead, what I imagine happened, is that, like in the (completely speculative) dialogue in my previous comment, someone who had no idea about what a for-loop is decided they're dangerous, asked if there is any alternative and when one of the techies present blurted out "recursion", the management person figured out it's better than for-loops.

I commend your skepticism, of course, but I don't think that's so hard to believe. I'm sure we all have stories of non-technical managers making stupid decisions based on complete misunderstanding of computers and programming languages and principles, after a quick explanation by a technical person.

I mean, imagine trying to explain recursion to someone who doesn't even really get for-loops.

Imagine "Those UpStairs" is angry, panicked and shouty. Imagine "Senior Software Person" is put-upon and long past arguing with "Those UpStairs".

I can see it.

Been there, had that rammed up good and hard. I can see it.

I wouldn't replace loops with recursion, generally speaking. It's probably at least as hard to write and understand explicit recursion as it is a for loop, and it's still fairly prone to off-by-one errors.

Explicit loops have a use, as does explicit recursion, but in the vast majority of cases, I use higher-order functions, like map, filter, flatmap, and fold.

The real problem is choosing tools that have more power than you need. This increases the surface area for potential bugs and it requires future reader to parse more code that's just there for plumbing.

> it's still fairly prone to off-by-one errors.

Can you explain this further? If you want to work your way through an array, for instance, you return once you have an empty array. If your result is stored in a data structure that can be appended, I don't see how it's possible to have an off-by-one error. You must be referring to another use case.

Yeah -- in some nontrivial recursive situations, you might have multiple base cases or different 0 and 1 cases. I've just often run into situations where testing my algorithm reveals that one of the cases isn't exactly right, and therefore the result doesn't match expectations. It's much more difficult to get a `map` wrong, though. What could possibly go awry? I guess the moral is, more power, more responsibility, so it's best to save power for when you absolutely need it.

C# has foreach loops, available for decades i.e. since very beginning.

C# also has LINQ, available for many years i.e. since 3.5.

Also, when management is asking “How can we ensure that the same thing never happens again?” they rarely interested in language level. In my experience, they don’t care whether the problem was caused by for or any other f-word in the code. This question is usually about QA and deployment workflows.

C# 4.0 had Linq, which can replace loops in most cases.

Reply on news.ycombinator.com