Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simplistic programming is underrated

lemire.me

Post reply on HN
Print view View original

71–80 of 93 posts

Re: Simplistic programming is underrated

#71

Post by zimpenfish »

AceJohnny2 wrote: post #31

I really liked this, because it resonates with my approach. I think I first realized the basics of this some time in college. As a teenager around '96 I discovered IRC, and hung around chatrooms being, well, a teenager. I discovered smileys, & how 2 use abbrevs to pack more in Also related, Pascal's comment in a quickly-written letter to a friend: "I would have written a shorter letter, but I did not have the time."…

> Only a few years later did I realize that what was more impressive was being able to (just as quickly) form clear complete sentences.

What's even more impressive still is knowing when to use which rather than locking yourself into a prescriptivist hole.

Re: Simplistic programming is underrated

#72

Post by spdionis »

dvt wrote: post #62
thethirdone wrote: post #60

Earlier quoted context omitted.

> No? Not only can they happen, but I'd argue that it's easier for them to occur when using `reduce`, because you have to remember the initializer. I would say that's not an off by one error. Its a similar scale and type of error, but not the same.

It's much more insidious than an off-by-one error in a for-loop - the initializer is hidden!

Unless you use a language that actually enforces you to pass required parameters to a function call.

Re: Simplistic programming is underrated

#73

Post by carussell »

spdionis wrote: post #72
dvt wrote: post #62

Earlier quoted context omitted.

It's much more insidious than an off-by-one error in a for-loop - the initializer is hidden!

Unless you use a language that actually enforces you to pass required parameters to a function call.

... which still wouldn't fix this problem, because the initializer is not a required parameter. It's allowed to be omitted by design, to signify that the first element shall be skipped and never passed as the second arg to the callback—or to put it another way, instead of being called once for each element, it's meant to handle the gaps between elements.

Re: Simplistic programming is underrated

#74

Post by carussell »

thethirdone wrote: post #60
carussell wrote: post #53

Earlier quoted context omitted.

> Off by one errors can't happen in the functional version. No? Not only can they happen, but I'd argue that it's easier for them to occur when using `reduce`, because you have to remember the initializer. Omitting it has no effect in the given example, but the given example is contrived. It's not rare to be dealing with something more complex than a list of numbers, so let's try that instead. Let's say your items ar…

> No? Not only can they happen, but I'd argue that it's easier for them to occur when using `reduce`, because you have to remember the initializer. I would say that's not an off by one error. Its a similar scale and type of error, but not the same.

Er, the single-parameter version of reduce differs from the two-parameter version in that the semantics are changed to literally skip the callback invocation where the first element gets passed as x. Instead of being called n times, it gets called n-1 times. It's one of the most clear-cut manifestations of fences vs posts—the quintessential off-by-one problem.

Re: Simplistic programming is underrated

#75

Post by liveoneggs »

RandomInteger4 wrote: post #24
liveoneggs wrote: post #11

Earlier quoted context omitted.

what's funny is that the code compiles the small map-reduce and the for loop to exactly the same bytecode probably. :)

Not my area of expertise, so I want to ask this question: Do compiler optimizations exist to automatically parallelize a for loop, which can be parallelized, no matter how to programmer wrote their for loop? If not, then map / reduce offers non-trivial performance benefits over a for loop. Mapping, as far as I'm aware, is "embarrassingly parallel", assuming the function that's mapped is pure? I think?

in perl6 this is done with the hyper operator, but for a small data set a for loop (non parallel) will almost always just run faster.

Re: Simplistic programming is underrated

#76

Post by arethuza »

dvt wrote: post #10
Y_Y wrote: post #8

Earlier quoted context omitted.

Is map-reduce really less simple than a for-loop? I agree with your other examples, but I see these too things as totally equivalent (unless you're in a language that make a dog's dinner of this type of thing, like old C++).

I think so, consider[1]: var r = array.map(x => x*x).reduce((total, num) => total + num, 0); vs its for-loop counterpart: var r = 0.0; for (var j = 0; j Maybe I'm just not as smart as everyone else, but I only have to keep like two things in my mind when looking at the for loop (easy), whereas in the map-reduce case, I need to have a very "holistic" view of what's going on (hard). [1] https://stackoverflow.com/questi…

What about:

(loop for x in a summing ( * x x ))

Re: Simplistic programming is underrated

#77

Post by ld00d »

I've been working on a project lately that was designed by a really smart guy. It follows the OOP patterns and IoC and all of that. Trouble is you can introduce such complexity that maintenance from someone a few years later can get incredibly difficult. A lot of this code I'm working in has implicit dependencies that are really hard to trace w/o stepping through line by line. If the code was more explicit, maybe it would offend the ideologists, and maybe it wouldn't be as flexible as it is (debateable), but it sure as hell would be easier to maintain.

Re: Simplistic programming is underrated

#79

Post by AnimalMuppet »

dvt wrote: post #10
Y_Y wrote: post #8

Earlier quoted context omitted.

Is map-reduce really less simple than a for-loop? I agree with your other examples, but I see these too things as totally equivalent (unless you're in a language that make a dog's dinner of this type of thing, like old C++).

I think so, consider[1]: var r = array.map(x => x*x).reduce((total, num) => total + num, 0); vs its for-loop counterpart: var r = 0.0; for (var j = 0; j Maybe I'm just not as smart as everyone else, but I only have to keep like two things in my mind when looking at the for loop (easy), whereas in the map-reduce case, I need to have a very "holistic" view of what's going on (hard). [1] https://stackoverflow.com/questi…

Both map-reduce and for-loop are idioms. That is, they are things that one fluent in the language should be able to read at a glance. I suspect that dvt has more experience with languages where the for-loop is the standard idiom.

And in fact, many languages have only one or the other as a standard idiom. So it's really pretty simple: Use the one that's a standard idiom in the language that you're using.

Your language offers both? It's still pretty simple: Use the one that's better understood by the people that you're working with.

They understand both? The project still probably leans one way or the other. Prefer the one that is more commonly used in the project. Projects wind up using subsets of languages; using things outside the subset, while valid, looks "odd" within the project.

It's all about minimizing the cognitive load on the reader. It's not about what the writer prefers.

Re: Simplistic programming is underrated

#80

Post by sincerely »

mythrwy wrote: post #66
_tulpa wrote: post #63

Earlier quoted context omitted.

My pet peeve on HN is people writing comments like they're gonna be peer reviewed. Either the less common words that they use are obviously out of place like someone just discovered a thesaurus ( conflated is my favourite example), or it's consistently formal and quasi-academic so I have to put extra effort into reading it. Either way it just makes the authour sound like a pretentions wanker.

Yep. "Orthogonal" is one of my favorites. Along with "order of magnitude".

“order of magnitude” is a pretty useful concept, to be fair.
Post reply on HN