4 ms·

I'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

I'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 ago
  I'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.
  - dualogy 10y ago
    > 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. Issue is that a beginner pre-conditioned long enough on "verboser, imperativer" models/languages, when reading/comprehending such a codebase, has to literally mentally expand every 1 line into 10 upon reading, for quite a while .. some weeks, some months, as more intuitive grasp sets in slowly over time. Probably what happened at OP's quoted company and with the different speeds in comprehending what "clever" (compact) code some of their coders came up with, what they flippantly called "code that was harder to understand by others"..
  - majkinetor 10y ago
    I totally agree. Plus, it keeps job interesting. Language is important and its expressivness. Babel 17 is must read.
  - pron 10y ago
    If a couple of esoteric language features can consistently reduce your codebase tenfold, you might want to rethink how you engineer your apps. Unless you're writing your application in FORTRAN (and I mean the version before 1958 and the introduction of procedural code) or assembly, I doubt there are any two general-purpose languages that show a 10x difference in code size in large applications.
  - lacampbell 10y ago
    I can't up on this enough. If the line count is low and the interfaces are great I'll forgive all manner of oneliners.
fho 10y ago
Welcome to Haskell ... where clever people write frameworks that even dumb people can't break ;-) e.g. https://code.facebook.com/posts/302060973291128/open-sourcing-haxl-a-library-for-haskell/ https://code.facebook.com/posts/302060973291128/open-sourcin...
sfifs 10y ago
> And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". If you ever wonder this, then it's definitely a problem with your code and not the reader. Code that cannot be easily read and understood by others is worthless in any commercial setting.
- douche 10y ago
  If you're too numb or stubborn to learn the tools that your programming environment provides for writing higher quality code, I have little sympathy and would suggest that such a person fond another line of work. If, for instance, someone were writing C# and insisted on hand-rolling for loops in all cases[1], because LINQ is "too hard", that's them being lazy and unwilling to invest a tiny amount of effort in learning more effective methods. [1] There are some cases where it's more performant to use a plain foreach or bare for, but unless you're in tight loops or dealing with ginormous collections, it's a premature optimization.
  - clebio 10y ago
    Or working in game development with low latencies to achieve high frames per second.
stcredzero 10y ago
And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". This is not an absolute, and needs to be answered in the context of the question: "Does my team work?"

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 ago
I'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.
- dualogy 10y ago
  > 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. Issue is that a beginner pre-conditioned long enough on "verboser, imperativer" models/languages, when reading/comprehending such a codebase, has to literally mentally expand every 1 line into 10 upon reading, for quite a while .. some weeks, some months, as more intuitive grasp sets in slowly over time. Probably what happened at OP's quoted company and with the different speeds in comprehending what "clever" (compact) code some of their coders came up with, what they flippantly called "code that was harder to understand by others"..
- majkinetor 10y ago
  I totally agree. Plus, it keeps job interesting. Language is important and its expressivness. Babel 17 is must read.
- pron 10y ago
  If a couple of esoteric language features can consistently reduce your codebase tenfold, you might want to rethink how you engineer your apps. Unless you're writing your application in FORTRAN (and I mean the version before 1958 and the introduction of procedural code) or assembly, I doubt there are any two general-purpose languages that show a 10x difference in code size in large applications.
- lacampbell 10y ago
  I can't up on this enough. If the line count is low and the interfaces are great I'll forgive all manner of oneliners.

fho 10y ago

Welcome to Haskell ... where clever people write frameworks that even dumb people can't break ;-) e.g. https://code.facebook.com/posts/302060973291128/open-sourcing-haxl-a-library-for-haskell/ https://code.facebook.com/posts/302060973291128/open-sourcin...

sfifs 10y ago

> And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". If you ever wonder this, then it's definitely a problem with your code and not the reader. Code that cannot be easily read and understood by others is worthless in any commercial setting.

douche 10y ago
If you're too numb or stubborn to learn the tools that your programming environment provides for writing higher quality code, I have little sympathy and would suggest that such a person fond another line of work. If, for instance, someone were writing C# and insisted on hand-rolling for loops in all cases[1], because LINQ is "too hard", that's them being lazy and unwilling to invest a tiny amount of effort in learning more effective methods. [1] There are some cases where it's more performant to use a plain foreach or bare for, but unless you're in tight loops or dealing with ginormous collections, it's a premature optimization.
- clebio 10y ago
  Or working in game development with low latencies to achieve high frames per second.

stcredzero 10y ago

And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb". This is not an absolute, and needs to be answered in the context of the question: "Does my team work?"