28 ms·
As it turned out, more flexibility led to devs writing code that others actually struggled to understand. This is what happens in almost every language. Niftyn
by stcredzero 10y ago
As it turned out, more flexibility led to devs writing code that others actually struggled to understand.
This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging.
"Clever" should be regarded as a limited resource. Also, the shop should encourage a culture where "clever" with regards to making code easier to understand should be valued above all else.
- fbreduc 10y agothis is a developer problem not a language issue, i've seen "nifty" code in go just as well..
- tostitos1979 10y agoSome languages make it easy to shoot yourself in the foot with nifty. I found Perl and Scala to be in that camp.
- stcredzero 10y agoThe design of a language/environment can sometimes exacerbate this particular developer problem. Because so much of the power of Smalltalk lay in its powerful debugging, weird proxy stuff had a potent impact.
- Daishiman 10y agoSome languages have footguns and constructs that are error prone.
- michaelchisari 10y agoI don't agree that all languages are created equal in this regard. I think that there are cultural norms and expectations that come with certain languages that make them more or less susceptible to "cleverness." For instance, python has never had the problems that ruby or perl had.
- stcredzero 10y agoI don't agree that all languages are created equal in this regard. I never said that. I'm only asserting that no language is completely immune, because hubristic cleverness is intermediate to stupidity and genius. I think that there are cultural norms and expectations that come with certain languages that make them more or less susceptible to "cleverness." Cultural norms can indeed help or hurt.
- atilaneves 10y agoI've seen Ruby-like Python. Just because Ruby makes it easier to do metaprogramming doesn't mean you can't do it in Python.
- michaelchisari 10y agoOf course it's not impossible.
- WkndTriathlete 10y agoAgreed, but they also complained about map() and flatMap(). I have to think that eventually every developer can understand the more straightforward monads, functors, and Either - which, along with type aliases, IMO, can make code a lot more readable. I think the more esoteric features should be reserved for complex code, especially if it's possible that those features can prove runtime correctness at compile time and result in easily-composable modules. I wouldn't expect more than one or two developers to need to develop such a subsystem, however, so the "clever" is used in isolation.
- faitswulff 10y agoThe full comment is actually: > No map, no flatMap, no fold, no generics, no inheritance… Do we miss them? Perhaps we did, for about two weeks. So they weren't complaining about map and flatMap, they just missed them.
- nine_k 10y agoThey only missed these features for 2 weeks? Good for them! Their problem domain is likely so simple and neat that it fits the Go's limited built-in types well, and does not lead to frequent copy-paste programming. If so, Scala has been an overkill.
- kjksf 10y agoAs simple as a distributed, horizontally scalable SQL database, perhaps? (https://github.com/cockroachdb/cockroach https://github.com/cockroachdb/cockroach). Those dumb Go programmers and their toy programs (https://quicknotes.io/n/1XB0 https://quicknotes.io/n/1XB0).
- nrjdhsbsid 10y agoI always work with a few developers that complain about my long variable names and aversion to certain shortcuts like ternary operators. They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse. Some of their code is so "clever" that I've refactored the line with 7 method calls just to understand what the hell is going on. Lambdas and fluent syntax make me quiver with fear. In the wrong hands they let you do unspeakable things
- kbenson 10y ago> aversion to certain shortcuts like ternary operators. > They don't understand that unclear code is probably the number one cause of technical debt. At the same time, verbosity can have an obfuscation quality all of its own. For simple assignment, I find a ternary operator very clear and concise, and much preferable to a 5-9 line (depending on style) if/else for a simple assignment. It also might keep you from using the single statement version of if/else if your language supports it, and that's probably justification in itself given how many problems that's caused in the past. Specifically, I think: usefulMetric = wantComplexCalc ? complexCalc(foo) : simpleCalc(foo); is preferable to: if ( wantComplexCalc ) { usefulMetric = complexCalc(foo) } else { usefulMetric = simpleCalc(foo) } even if only because it doesn't obscure intent with what is essentially boilerplate.
- ludicast 10y agoAgreed, plus obviously your "if" statement doesn't do the assignment to usefulMetric. One more way the ternary wins (along with functional languages that use "if"s as expressions).
- kbenson 10y agoD'oh! Fixed. Thanks. :)
- LgWoodenBadger 10y ago
- hliyan 10y agoAs the saying goes: it's easier to write code than understand it. Therefore if you write code as cleverly as you can, then by definition you're not smart enough to understand it...
- deleted 10y ago[deleted]
- JulianK 10y agoFor those that like trivia, the original quote I believe is by Kernighan and it's about debugging code rather than writing it, which I feel makes more sense: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" https://en.wikiquote.org/wiki/Brian_Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan
- nradov 10y agoYes but occasionally there's no other option. I once had to code a parser for a data format with an odd non-BNF grammar with a bunch of special cases. In order to meet the functional requirement for user-friendly error reporting when parsing invalid inputs I was forced to write really clever (in a bad way) code. Fortunately we haven't found any serious defects in it because I don't think I understand it well enough to debug it.
- arvinsim 10y agoIt is okay to write clever code if necessary. Solutions to some problems require it. Clever code for the sake of being clever is rarely worthy it.
- true_religion 10y agoI sometimes optimistically believe that my cleverness will increase over time.
- lacampbell 10y agoI'd much rather deal with concise, clever code that has a sane interface and works, rather than sprawling long winded code where everything is void and the same low level constructs are used everywhere. And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".
- pron 10y ago> And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". There are two problems with this argument. First, brilliance in code is not a property of what linguistic abstractions the code makes use of, but the elegance of the algorithm and engineering. I sincerely doubt that no brilliant code had been written prior to the introduction of your favorite linguistic abstractions. Second, even supposing you're right, what difference does that make? If your code's maintainers are dumb, do you think that you could change this reality by making life harder for them, or is it your job to adapt yourself to the reality of the system you're a part of? When creating something for dumb people to use, is it a sign of good craftsmanship to make it harder for them to work with?
- nemothekid 10y ago>And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". IMO, the answer is people vastly underestimate the cognitive cost of reading code. "Code" rarely exists in a vacuum, the reader has a universe of inputs, outputs, problems, solutions, failures and goals. The cognitive cost of trying to read someone's code is something that must be paid multiple times per day and at one point do you have to wonder - is the gain in expressiveness for a single programmer worth the cognitive cost of the multiple programmers who have to parse that code. I'd imagine the answer is no - especially for companies that spend more time iterating and patching based on customer feedback than actually designing and architecting systems. My belief is that expressive languages have their place but companies are far more likely to build their software in a "patch-test-iterate" environment which favors less expressive languages.
- runT1ME 10y agoI'll keep repeating myself: the cognitive cost of "code" is dwarfed by the cost of understanding an application. If a couple esoteric languagn features take an extra few hours to learn but reduce LOC tenfold, it's a price I'd pay every time. Not everyone feels this way, the investment to learn these features may not pay off right away, and if you come from a "move fast and break things" language (python/php/js) it can feel like a waste of time.
- hobarrera 10y agoThis is one of the extremely cool things about python. There's always one right way to do this, and it's usually pretty obvious. There's also quite clear, standard style guidelines, so code is generally formatted pretty much homogeneously, and tends to be a lot more readable than many other languages.
- ajyoon 10y agoPer the Zen of Python, there should always be exactly one sensible way to do something, but unfortunately this is not often the case. List comprehension can be achieved just the same with functools, itertools, explicit for loops, etc. That said, I do tend to have that mantra a little more present in my head when I'm working with Python.
- devdoomari 10y agoyep... making 'understandable' is really important. But given that discipline, scala would outshine go since scala has much better typechecking than go - e.g. http://getquill.io/ http://getquill.io/ can typecheck against a running DB schema, etc.
- edejong 10y agoThis (lengthy) quote comes to mind. If you think it is interesting, please read the whole EWD. EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the one-liners”. It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question “Can you code this in less symbols?” —as if this were of any conceptual relevance!— or he just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. " [1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...
- galacticpony 10y agoI think it is interesting that you left out the very next few sentences, which provide very relevant context: "I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque." While I agree with the general sentiment, it's very important to take anything Dijkstra says with a huge grain of salt. He was a mathematician first and foremost. He obsessed about things like a mathematician. Such people, while very smart, make for very unproductive software engineers. They also have a way of sounding deceptively smart and thoughtful, when really they're just talking out of their ass. Beware.
- PopsiclePete 10y agoIt got really bad the past 10 years or so with the "look at what I can do, ma!" blog posts where someone spends 4 pages violating the language in order to get clicks. It's especially endemic in Ruby-land, I find.