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

21–30 of 104 posts

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

#21

Post by slededit »

TeMPOraL wrote: post #9
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.

Do you maintain a high-enough level within the team though? Most "clever code" I've seen is called clever by people who are not yet proficient enough in a language to understand it. So with unskilled programmers pretty much anything that isn't straight combination of classes, loops and conditionals will be considered clever. There's a tradeoff here - I get the business reasons why one may want to have the codebase at…

Not every company wants highly skilled programmers. Depending on the complexity of the project, and cost of defects unskilled programmers may be the most cost effective.

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

#23

Post by emblem21 » 

  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. :(

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

#24

Post by ezyang »

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 fizzbuzz' [1..]
The article is very interesting and worth a read. In particular, this implementation doesn't come out of "thin air": it's been golfed from an implementation that defines a simple domain specific language to solve FizzBuzz. And if you understand your problem well enough, DSLs are an extreme force multiplier.

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

#25

Post by rev_null »

partisan wrote: post #2

Not the OP of the article. Just wanted to get perspective from Haskell devs on the points raised in the article.

I find it interesting that he dismisses the use of Maybe. The monadic solution isn't clear, but when used as a Monoid, it's clear and easy to modify:

https://gist.github.com/anonymous/7a1829f61cf9302c188f80a736...

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

#26

Post by TeMPOraL »

slededit wrote: post #21
TeMPOraL wrote: post #9

Earlier quoted context omitted.

Do you maintain a high-enough level within the team though? Most "clever code" I've seen is called clever by people who are not yet proficient enough in a language to understand it. So with unskilled programmers pretty much anything that isn't straight combination of classes, loops and conditionals will be considered clever. There's a tradeoff here - I get the business reasons why one may want to have the codebase at…

Not every company wants highly skilled programmers. Depending on the complexity of the project, and cost of defects unskilled programmers may be the most cost effective.

I know. Took me a while to realize it and understand why companies think that way, but it boils down to the fact that as programmers, we're not paid to do a good job, we're paid to do a good enough job. Those two goals are very often at odds. It seems to be a typical clash of craftsmanship with market economy.

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

#27

Post by wangchow »

So long as the "cleverness" is well-documented it's not a problem. Authors should explain why it is written the way it is. Problem solved.

I've seen some weird-ass calculations in code with no comments. If the author has gone through so much effort to come up with the clever solution why not add some commentary so the next guy can read it quickly.

That's why every language has support for comments..

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

#28

Post by atoko »

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. :(

Try using .call

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

#30

Post by Jach »

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. :(

When "too clever" is "I don't understand", yeah, it's bad. I'd snap back with "let's use clojurescript then". Or I'll clarify whether they think 'var i' in the loop is too clever or the scope fixing code that's pretty common to do in JS is too clever.
Post reply on HN