Simplistic programming is underrated • Hacker News Board

Re: Simplistic programming is underrated

#21

Post by lordCarbonFiber » Thu, Dec 07, 2017, 1:35 AM UTC

dvt wrote: post #18

lordCarbonFiber wrote: post #15

Earlier quoted context omitted.

Except the over head of that loop is orders of magnitude higher than the reduction. Did you get the bounds right; what happens if you accidently start at 1 or end at "Simple" is great until you're debugging off by one errors or any other errors between chair and keyboard. Complexity, in the sense that this guy rails against, is expressiveness . And, expressive code beats "simple" code every day of the week. --Quick e…

> Except the over head of that loop is orders of magnitude higher than the reduction. Except that it's not. Read the SO answer I linked. > The nooks for bugs in your "simple" loop are so profound that, in a language with expressive maps, I wouldn't accept that code in a review. Yep, I've definitely worked with people like you. With all due respect, I just think you're fundamentally wrong. Off-by-1 errors will happen…

Off by one errors can't happen in the functional version. There's no reason to take a fatalist stance here. Just saying "well those programmers should write more tests" is silly when you could say, well why not tests and write code that is naturally hardened against foot guns.

I was referring to mental overhead; though in a more modern language like rust the performance implications would be far less profound than the linked SO discussion.

Re: Simplistic programming is underrated

#22

Post by lhnz » Thu, Dec 07, 2017, 1:37 AM UTC

I've been thinking about this lately, too.

I strongly believe this, to the extent that I have a preference for code which is simple but incorrect over complicated but correct.

Obviously simple and correct is best, but if I can't get that (at least in the short-term) I would sacrifice correctness for simplicity.

You can often incrementally improve a simple solution, but it is very difficult to simplify a complicated solution.

Re: Simplistic programming is underrated

#23

Post by goialoq » Thu, Dec 07, 2017, 1:39 AM UTC

dvt wrote: post #18

lordCarbonFiber wrote: post #15

Earlier quoted context omitted.

Except the over head of that loop is orders of magnitude higher than the reduction. Did you get the bounds right; what happens if you accidently start at 1 or end at "Simple" is great until you're debugging off by one errors or any other errors between chair and keyboard. Complexity, in the sense that this guy rails against, is expressiveness . And, expressive code beats "simple" code every day of the week. --Quick e…

> Except the over head of that loop is orders of magnitude higher than the reduction. Except that it's not. Read the SO answer I linked. > The nooks for bugs in your "simple" loop are so profound that, in a language with expressive maps, I wouldn't accept that code in a review. Yep, I've definitely worked with people like you. With all due respect, I just think you're fundamentally wrong. Off-by-1 errors will happen…

Why have a compiler at all if you want to defer all error-checking to runtime?

Re: Simplistic programming is underrated

#24

Post by RandomInteger4 » Thu, Dec 07, 2017, 1:40 AM UTC

liveoneggs wrote: post #11

dvt wrote: post #3

> I like the concept of “simplistic programming” by which I mean “programming that is so simple that people will criticize you for it”. At first, that sounds strange… can we really get criticized for being “too simple”? Of course, we do. Oh man, this hits home. I've attempted to be a voice of reason on this front so many times, I've practically given up on it. I've come to the conclusion that most programmers suffer…

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?

Re: Simplistic programming is underrated

#25

Post by RandomInteger4 » Thu, Dec 07, 2017, 1:42 AM UTC

dvt wrote: post #18

lordCarbonFiber wrote: post #15

Earlier quoted context omitted.

Except the over head of that loop is orders of magnitude higher than the reduction. Did you get the bounds right; what happens if you accidently start at 1 or end at "Simple" is great until you're debugging off by one errors or any other errors between chair and keyboard. Complexity, in the sense that this guy rails against, is expressiveness . And, expressive code beats "simple" code every day of the week. --Quick e…

> Except the over head of that loop is orders of magnitude higher than the reduction. Except that it's not. Read the SO answer I linked. > The nooks for bugs in your "simple" loop are so profound that, in a language with expressive maps, I wouldn't accept that code in a review. Yep, I've definitely worked with people like you. With all due respect, I just think you're fundamentally wrong. Off-by-1 errors will happen…

Why does a programmer need to know an index counter exists if the index counter isn't used inside the for loop?

Re: Simplistic programming is underrated

#26

Post by hbt » Thu, Dec 07, 2017, 1:43 AM UTC

The blog post barely gets into the idea of what simplicity means in programming.

If you have any interest in the topic, I recommend Rich Hickey talk "Simplicity matters" https://www.youtube.com/watch?v=rI8tNMsozo0

My personal favorite is: Living with complexity 2010 by Don Norman (Author of Design of everyday things)

https://www.amazon.ca/Living-Complexity-Donald-Norman/dp/026...

Re: Simplistic programming is underrated

#27

Post by samiralajmovic » Thu, Dec 07, 2017, 1:43 AM UTC

Discarding previous knowledge where it is applicable and simpler is obviously unwarranted. Similarly to how we utilize Newtons laws within a lower energy and mass range, we should prefer the simpler equations where they make sense. However, I'm not sure that a for loop is actually simpler than map reduce as it depends on the context. Who is reading your code? How complex is the code inside the for loop? What kind of problem are you solving? The vocabulary associated with functional programming is better equipped to handle mathematical expressions than imperative code and in this case, simpler.

In essence; adding complexity for the sake of complexity or to come of as intelligent is bad...

Re: Simplistic programming is underrated

#28

Post by squiggleblaz » Thu, Dec 07, 2017, 1:45 AM UTC

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…

I dunno, I find the second one harder. Because now you have to know about array indices and things like that. The for loop forces you to deal with petty details. The map reduce lets someone else deal with that.

I tend to think there's some additional overhead from Javascript's particular object oriented implementation of mapping and reducing when compared with haskell's i.e.

     f xs = foldr + 0 (map (\x -> x * x) xs)

seems a bit easier to me.

Is it habit? Probably. But I really find it hard to understand why maps and folds are simpler than manual iterative loops.

Re: Simplistic programming is underrated

#29

Post by DSMan195276 » Thu, Dec 07, 2017, 1:47 AM UTC

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…

I agree, but I think it depends a lot on your background as well as the background of the people who are likely to be looking at and modifying the code. Virtually any programmer is going to be able to eventually read and understand the second version while requiring little extra research, but for a lot of programmers they will have no idea how to reason about the first and no idea how to use/modify/extend it, so it is just some weird black-box.

Yes, obviously they can learn, and I don't think learning a bad thing (It's absolutely a necessary skill for a programmer, or anybody), but if the only place in the code that ever uses map/reduce is that one location, then programmers that come by it are likely not going to get a lot out of the time they're going to sink trying to figure it out. If it was just a basic loop, then overall people will likely spend less time figuring it out. For one piece of code it's not that big of a deal, but if your code-base is just full of fun little one-liners everywhere, it quickly becomes a mess to understand.

But with that, if your code is already full of stuff like map/reduce, then I think using map/reduce instead of the basic loop may very-well be preferred for readability (Though of course, your citation brings up performance concerns, which should also be taken into consideration). I think most important is just keeping the code-base consistent.

Re: Simplistic programming is underrated

#30

Post by dvt » Thu, Dec 07, 2017, 1:47 AM UTC

lordCarbonFiber wrote: post #21

dvt wrote: post #18

Earlier quoted context omitted.

> Except the over head of that loop is orders of magnitude higher than the reduction. Except that it's not. Read the SO answer I linked. > The nooks for bugs in your "simple" loop are so profound that, in a language with expressive maps, I wouldn't accept that code in a review. Yep, I've definitely worked with people like you. With all due respect, I just think you're fundamentally wrong. Off-by-1 errors will happen…

Off by one errors can't happen in the functional version. There's no reason to take a fatalist stance here. Just saying "well those programmers should write more tests" is silly when you could say, well why not tests and write code that is naturally hardened against foot guns. I was referring to mental overhead; though in a more modern language like rust the performance implications would be far less profound than th…

> Just saying "well those programmers should write more tests" is silly when you could say, well why not tests and write code that is naturally hardened against foot guns.

I don't think off-by-1 errors are that big of a foot gun, compared to, like, having a null as part of the language, or pointers, or about a million other things.

> I was referring to mental overhead

Gotcha. I still think that "linear step-by-step" thinking like "you take stuff out of a bucket, and then do stuff to it" is easier to parse than map-reduce, which requires you to have a "big picture" view of the whole process.