Why most “clever” code ain’t so clever after all
drive.google.com
Why most “clever” code ain’t so clever after all
1–10 of 104 posts
Re: Why most “clever” code ain’t so clever after all
#2Not the OP of the article. Just wanted to get perspective from Haskell devs on the points raised in the article.
Re: Why most “clever” code ain’t so clever after all
#3C. Alexander in _Notes on the Synthesis of Form_, rather explicitly puts forth the essential architectural problem in a semiformal form - a constraint satisfaction problem.
The closest application of CSP-like problems in places close to statistics-land is in neural networks, where Rumelhart published in multiple places that the objective of neural networks, including the backprop net that he reinvented, was soft CSP. So actually, there is probably a path towards formal equivalence.
Of course, there's a disgustingly large amount of work done on the analogies between CSP and Ising model at criticality, because you only need to look at the damned things (compare to Hopfield model). The other path is to look at R. Sole's work on munging for power law-ish things in software. So physical methods for software are actually quite old hat (from the 90's). It's just that it's all really fucking hard condensed matter stuff.
This is quite close to Huberman's work at PARC about networks and stuff, which led to the different Adamic and Huberman munging for power laws in networks and Internet things.
Re: Why most “clever” code ain’t so clever after all
#4Whether or not something is "clever" as opposed to annoying or obtuse depends heavily on context. In the context of a production programming environment, it's all about cost/benefit. Does it reduce the team's cognitive load? At what cost?
Re: Why most “clever” code ain’t so clever after all
#5This is a fairly well known thing in all programming communities that matter, but it was good to see it pointed out once again.
However, I would argue that the classic guarded function using modulo would actually be clearer. It takes a moment to follow the logic of cycling up an infinite list, and modulo statments are far clearer and easier to understand to most people, I would say. In addition, it's easier to change than either of the above, and equally declarative: modulo is a declarative operation as is a guard: when x % 3 is zero, it IS fizz.
Re: Why most “clever” code ain’t so clever after all
#6You can code yourself into a corner no matter what language you use. I've not seen much of this beautiful many-seamed code that could suddenly accommodate unanticipated feature requirements without rearchitecture, but I have enjoyed a certain amount of seamful boilerplate requiring much burnishment as changes are made. I don't think I'm anywhere near as experienced as the author but I still think this article is setting up strawmen and knocking them down.
Re: Why most “clever” code ain’t so clever after all
#7I 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.
Re: Why most “clever” code ain’t so clever after all
#8This is a fairly well known thing in all programming communities that matter, but it was good to see it pointed out once again. However, I would argue that the classic guarded function using modulo would actually be clearer. It takes a moment to follow the logic of cycling up an infinite list, and modulo statments are far clearer and easier to understand to most people, I would say. In addition, it's easier to change…
What about when x is 15?
Re: Why most “clever” code ain’t so clever after all
#9I 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 the "lowest common denominator" level for the team. But then again, programming is a craft, so that person who says lambdas in Java are "clever code" (real example from my work) should IMO suck it up and spend few hours learning; then the code will stop being "clever" to them.
Re: Why most “clever” code ain’t so clever after all
#10Cycled lists and the modulo operator are two different abstractions for thinking about the same problem, in the same vein of "blind men grasping at elephant." They are different perspectives on the similar problem.
The reason we think that cycling a list is "clever" but using modulo is "boring" is because most of us use modulo often, and cycling rarely. There is nothing inherently "clever" about either of the two approaches.
In an alternate universe where we all used Haskell, perhaps the modulo solution would come off as "clever". And perhaps this article would be pointing out the flaws in the modulo approach instead: the fact that numbers divisible by both 3 and 5 have to be treated by a special case, the fact that it doesn't easily generalize to fizz buzz bazz, etc.