3 ms·

Those examples clearly show how used programmers have gotten to the ease of use that languages like Ruby (the one used in the examples) provide. "Just pad the a

Those examples clearly show how used programmers have gotten to the ease of use that languages like Ruby (the one used in the examples) provide. "Just pad the array with zeroes" sounds like an easy enough idea until you realize this might imply reallocating several gigabytes of memory depending on the size of your data set, possibly even running out of memory. Either way, the example implementation assumes the first and last elements are treated as having only one neighbor; which seems like an odd specification for the algorithm in the first place. To me it seems like the source of this code smell is a bit further up in the call stack. As for the second example, it becomes even more obvious how inefficient the "better" solution is. Just copy the entire array except the last element, in reverse order no less (so it can't just be memcpy()'d). This is what happens when you teach kids Ruby (or php, or pythin or...) because the job market demands it, but not the fundamentals (i.e. C, C++, Pascal, etc.). As for elegance, both "improved" examples seem extremely ugly to me. Not only do they turn a clearly readable if statement into something more magical, they also mutate their data before operating on it. Turning 5 lines of structured code into a one-line abomination isn't elegant, it's dumb. It decreases maintainability. It increases complexity. It makes room for errors to hide. It's, to put it simply, bad coding style.

nikanj 8y ago
And if you argue against this insanity at a code review, some clod is going to misquote Knuth at you. "Don't prematurely optimize" doesn't mean "just alloc half a gig of memory, and profile later if performance is unsatisfactory."
- efdee 8y ago
  Ironically, complaining about the elegant solution of padding the array with "well this is going to suck on a multi-gigabyte in-memory dataset" is pretty much the definition of premature optimization. Chances are very high his dataset is not multi-gigabyte in-memory.
  - dahart 8y ago
    Not really. Making a one-time allocation for a linear pass through an array is almost always bad. It’s often just as bad for many small arrays as it is for one big array. The idea to not prematurely optimize was never intended to be a free pass to use wasteful practices everywhere until there’s a horrible problem, it’s more about avoiding factoring your code into something you can’t maintain. Generally speaking, baking your corner cases into your precondition code is more dangerous than avoiding allocations. The idea was also not to leave concerns about performance completely off the table until your application is correct; it is assumed that you are making somewhat reasonable choices for your unoptimized code and your architecture, not that you are actively trying to slow things down with unnecessary allocations.
  - deleted 8y ago
    [deleted]
  - DarkWiiPlayer 8y ago
    I disagree with two points of what you said. The first is that you call something that copies an arbitrarily long memory section to avoid two ifs "elegant", the other is everything else. Elegant code uses less instructions, clear structure and is in general one of the better implementations in terms of performance. The suggested implementation shifts the workload into standard ruby functionality, but multiplies it by many times in the process; turns the clear structure of two conditionals into weird data trasnformations that and ultimately performs much worse than just the two extra ifs. The multi-gigabyte-dataset was obviously an extreme example (yet one that may very well happen in practice). The point is, bad code like that is inevitable going to slow down an application, the question is whether you care about speed at all. Arguably, if you're using ruby, you probably don't. Premature optimization usually refers to taking straight-forward code and making it more complex based on certain performance assumptions, like unrolling loops or writing inline assembly. This is bad because, well written code is most of the time fast enough, and if it does need optimizations, that will become clear soon enough. Choosing not change your code in a way that considerably impacts performance based on ones individual perception of cleverness and elegance, however, is not an optimization; it's avoiding a dumb mistake that will bite you in the ass later on.
taco_emoji 8y ago
Padding with zeroes doesn't have to involve reallocating anything--you could wrap the array in an iterator that first yields 0, then yields each array element, then yields 0 again. E.g. in C# using Linq: foreach (var num in myArray.Prepend(0).Append(0)) { /* blah */ }

nikanj 8y ago

And if you argue against this insanity at a code review, some clod is going to misquote Knuth at you. "Don't prematurely optimize" doesn't mean "just alloc half a gig of memory, and profile later if performance is unsatisfactory."

efdee 8y ago
Ironically, complaining about the elegant solution of padding the array with "well this is going to suck on a multi-gigabyte in-memory dataset" is pretty much the definition of premature optimization. Chances are very high his dataset is not multi-gigabyte in-memory.
- dahart 8y ago
  Not really. Making a one-time allocation for a linear pass through an array is almost always bad. It’s often just as bad for many small arrays as it is for one big array. The idea to not prematurely optimize was never intended to be a free pass to use wasteful practices everywhere until there’s a horrible problem, it’s more about avoiding factoring your code into something you can’t maintain. Generally speaking, baking your corner cases into your precondition code is more dangerous than avoiding allocations. The idea was also not to leave concerns about performance completely off the table until your application is correct; it is assumed that you are making somewhat reasonable choices for your unoptimized code and your architecture, not that you are actively trying to slow things down with unnecessary allocations.
- deleted 8y ago
  [deleted]
- DarkWiiPlayer 8y ago
  I disagree with two points of what you said. The first is that you call something that copies an arbitrarily long memory section to avoid two ifs "elegant", the other is everything else. Elegant code uses less instructions, clear structure and is in general one of the better implementations in terms of performance. The suggested implementation shifts the workload into standard ruby functionality, but multiplies it by many times in the process; turns the clear structure of two conditionals into weird data trasnformations that and ultimately performs much worse than just the two extra ifs. The multi-gigabyte-dataset was obviously an extreme example (yet one that may very well happen in practice). The point is, bad code like that is inevitable going to slow down an application, the question is whether you care about speed at all. Arguably, if you're using ruby, you probably don't. Premature optimization usually refers to taking straight-forward code and making it more complex based on certain performance assumptions, like unrolling loops or writing inline assembly. This is bad because, well written code is most of the time fast enough, and if it does need optimizations, that will become clear soon enough. Choosing not change your code in a way that considerably impacts performance based on ones individual perception of cleverness and elegance, however, is not an optimization; it's avoiding a dumb mistake that will bite you in the ass later on.

taco_emoji 8y ago

Padding with zeroes doesn't have to involve reallocating anything--you could wrap the array in an iterator that first yields 0, then yields each array element, then yields 0 again. E.g. in C# using Linq: foreach (var num in myArray.Prepend(0).Append(0)) { /* blah */ }