Slashdot Mirror
Dr. Dobb's Calls BS On Obsession With Simple Code
theodp writes "Over at Dr. Dobb's, Editor-in-Chief Andrew Binstock has a nice rant on The Misplaced Obsession with Simplicity. 'Any idiot can write complex code,' goes the old maxim, 'the true art is writing simple code.' Right, Andrew? Wrong (mostly). Binstock explains, 'It's not true that any idiot can write complex code. Complex code is difficult, often very difficult, to write. It's entirely true that it's more difficult to maintain, too. But that's the nature of complexity. Some things are intensely difficult to express in code and they require complexity, simply because they're not inherently simple.' After citing the complex-but-necessarily-so code of Al Aho and sometimes-misguided reverence for cyclomatic complexity limits to help make his point, Binstock concludes, 'My view of simplicity is unemotional and free of idolatry because I define it with respect to complexity, rather than the other way around: Simplicity is the quality of code that is no more complex than required to express the underlying complexity. In this way, simple code can be intensely complex. There is no inherent good/bad dichotomy.'"
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Keep on knockin'
https://robbiecrash.me
When you redefine your opposition's argument and then knock it down with your own argument it is called a strawman. That's what he just did there.
No one is saying in regards to simplicity that all programs should be two line bits of nothing.
What people are instead saying is that code should be efficient, tight, and achieve the end goal as simply and directly as possible.
What we are and have always been talking about is efficiency. It goes back to the first computers that had very limited memory. They required VERY efficient code because they simply didn't have the storage or memory to run anything that took up more space. As a result, code for those machines tended to be very very efficient. It was a requirement.
When we complain about complexity, we are not complaining that the task of the program is too complex. Rather, we're complaining that the program is badly coded. We are complaining that it is inefficient and disorganized.
So nice try. Try again.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Stop tripling the size of your code for use-cases that no one has asked for, people!
Yeah, just let it throw a bugcheck when something happens outside of the design parameters and let the user sort it out with your support department. /sarcasm
Security risks. Data corruption. Performance edge cases. Productivity loss. Unexpected bluescreens. Actual damage to physical hardware controlled by the software. You know all that bad stuff could have been easily prevented if the programmer anticipated those situations, and the people hiring that programmer probably expected the software to be well-made... It's much less expensive to do it ahead of time than to fix it when it breaks. Change in development = cheap, change in production = expensive.
Those things aren't part of the formal requirements in your world?
Socialism: a lie told by totalitarians and believed by fools.
I've never seen formal requirements which detail every edge case I need to account for.
There's an assumption we'll be writing robust code, and as it gets created we build in as much error checking and handling as we can think of, and over time you usually end up adding more.
If coders had to be told in writing every error condition to check for, there wouldn't be any -- because the client wouldn't know (especially true when you have to create a library to do some of the work), and the developers would just say "not in the spec".
Come to think of it, I've never seen formal requirements for much more than the really high-level systems stuff. From my perspective, a system which has been fully designed and spec'd out before anybody writes code is a myth.
Lost at C:>. Found at C.