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

Why most “clever” code ain’t so clever after all

drive.google.com

Post reply on HN
Print view View original

61–70 of 104 posts

Re: Why most “clever” code ain’t so clever after all

#61

Post by [deleted] »

rkalfane wrote: post #56
belovedeagle wrote: post #45

This article hinges on a rather silly fallacy. Luckily the author does us the favor of making his mistake very clear in the curve-fitting analogy; but first look at the code. He gives several examples of poorly-written FP code (which we're supposed to believe is "clever" by virtue of being FP), then introduces some new problem constraint which is carefully selected to make the FP solution break but some equally ridic…

I honestly didn't see the same thing as you, my understanding is that using the Lagrange Interpolation is the "clever" choice, but when you add more points, you'll end up with a higher order polynomial and widely different curve which is probably not what you wanted in the beginning. I read the piece more as a reminder that most specs are usually incomplete/too specific/not conveying what is actually needed, and a wa…

[deleted]

Re: Why most “clever” code ain’t so clever after all

#62

Post by kirrent »

belovedeagle wrote: post #45

This article hinges on a rather silly fallacy. Luckily the author does us the favor of making his mistake very clear in the curve-fitting analogy; but first look at the code. He gives several examples of poorly-written FP code (which we're supposed to believe is "clever" by virtue of being FP), then introduces some new problem constraint which is carefully selected to make the FP solution break but some equally ridic…

As a physics grad that curve fitting section was hard to read. Only very low degree polynomial fits can ever be used, through some coincidence with the underlying trend, for extrapolation. A polynomial fit is a simple and easy method to fit a curve which you can use for interpolation if you want. Unless you have some clearly identifiable trend, then extrapolation doesn't mean anything no matter what curve fitting method you use.

It's like criticizing a Taylor series for diverging from the target function as you get far away from its centre. No shit that'll happen. It's the name of the game.

I do have to agree that that section read a lot like satire.

Re: Why most “clever” code ain’t so clever after all

#64

Post by tromp »

squeaky-clean wrote: post #39
ezyang wrote: post #24

I didn't make it past the fizzbuzz example. But I wouldn't call the solution with cycle all that clever. Here's a better one: https://themonadreader.files.wordpress.com/2014/04/fizzbuzz.... the punchline reproduced below: fizzbuzz' :: Int -> String fizzbuzz' n = (test 3 "fizz" . test 5 "buzz") id (show n) where test d s x | n `mod` d == 0 = const (s ++ x "") | otherwise = x fizzbuzz :: [String] fizzbuzz = map fizzbuz…

Feature request: Client should be able to specify either 3, or 1023 for the number needed to print "fizz." Feature request: Client should be able to optionally request "Lizard" as another string whenever the number is a multiple of 13. That's what the article is referring to. Your function may be more clever, but it's more specific, works in only exactly the requested cases and is harder to change.

    fizzbuzz' n = (test 1023 "fizz" . test 5 "buzz" . test 13 "Lizard") id (show n)
easy as pie...

Re: Why most “clever” code ain’t so clever after all

#65

Post by cwbrandsma »

I remember the days of seeing inline assembly in code (delphi). We griped about that code quite a bit, but this was in the days before "you can't outsmart the compiler". Was it clever: yes. Was it maintainable: no. Was it necessary: YES! This was drawing code, doing it via the normal language routines was just not a performant solution.

Re: Why most “clever” code ain’t so clever after all

#66

Post by bmm6o »

iagorodriguez wrote: post #7

I run a small dev company. This is the first lessons we teach our programmers. If your code cant be understood by someone else with minimal efforts it is not good enough.

> If your code cant be understood by someone else with minimal efforts it is not good enough.

The article doesn't use "clever" as an antonym for "readable", though. The point is that clever code can be excessively brittle.

Re: Why most “clever” code ain’t so clever after all

#67

Post by Strilanc »

emblem21 wrote: post #23

for(var i in list) { (function(element) { someAsyncCallThatNeedsTheRightIndexedElement(element); })(list[i]); } I've seen people grumble that this is " too clever " I've been known to snap back " Bootcamps don't have a monopoly on what technical solutions are valid " Pointers are probably too clever for most people. Admittedly, goto is too clever for me. :(

Note: this is fixed in ES6. Using `let` instead of `var` will treat each iteration's variable as distinct:

    a = []
    for (let i = 0; i  console.log('hi ' + i))
    for (let e of a)
        e()
Logs:

    hi 0
    hi 1
    hi 2
Actually, it's almost surprising in the opposite direction now.

Re: Why most “clever” code ain’t so clever after all

#68

Post by kylemuir »

junto wrote: post #46
kylemuir wrote: post #35

Earlier quoted context omitted.

Thankfully, it also has the same "Alt-Enter" to revert said LINQ query :)

Exactly, but colleagues also have to be encouraged not to always trust what Resharper suggests!

Definitely agree - my pet peeve (although I haven't seen it for a while) is introducting circular references by adding compiled dlls from /bin/debug as references instead of adding a project reference.

I use to see it a lot a few years ago, maybe I just got a little better at my job?

Re: Why most “clever” code ain’t so clever after all

#69

Post by GFK_of_xmaspast »

kirrent wrote: post #62
belovedeagle wrote: post #45

This article hinges on a rather silly fallacy. Luckily the author does us the favor of making his mistake very clear in the curve-fitting analogy; but first look at the code. He gives several examples of poorly-written FP code (which we're supposed to believe is "clever" by virtue of being FP), then introduces some new problem constraint which is carefully selected to make the FP solution break but some equally ridic…

As a physics grad that curve fitting section was hard to read. Only very low degree polynomial fits can ever be used, through some coincidence with the underlying trend, for extrapolation. A polynomial fit is a simple and easy method to fit a curve which you can use for interpolation if you want. Unless you have some clearly identifiable trend, then extrapolation doesn't mean anything no matter what curve fitting met…

You can get away with high-degree polynomial interpretation if you have control over the node locations, see for example Nick Trefethen's chebfun: http://www.chebfun.org and book: https://people.maths.ox.ac.uk/trefethen/ATAP/

Re: Why most “clever” code ain’t so clever after all

#70

Post by mannykannot »

segmondy wrote: post #31
iagorodriguez wrote: post #7

I run a small dev company. This is the first lessons we teach our programmers. If your code cant be understood by someone else with minimal efforts it is not good enough.

This is a very delicate subject. If the program is using language constructs and can't be understood because the reading programmer doesn't know it, then who's fault is it? why have multiline if/else when a tenary operator can do? I rather read a = b ? c : d; than possibly 4 lines of code, p/s ignore the names of the variable. There are plenty of code out there that are so easy to understand if you read them one line…

There is a tendency for the discussion of complexity in programming to descend into an obsession with trivial minutiae.
Post reply on HN