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.'"
Everything should be made as simple as possible, but not simpler.
Interesting article, but this seems an issue of a very pedantic interpretation of a common idiom.
When I (or I suspect most) whine about pointlessly complex code, it's just that. Code that is more complex than is reasonable for the problem. No one expects a simple solution for a challanging problem. It's an overly complex solution to a simple problem which we complain about...
The way I heard it was "Everything should be made as simple as possible, but no simpler." However I have since learned that me be a paraphrase of the actual quote, "It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience."
I have often noticed that complexity is added to code when it grows over time. Typically, a project starts off very well. We have requirements and we use the best possible design with limited future expansion capabilities and come up with simple code that works well. However, over time, things change and we come across situations that the original code cannot handle. But instead of writing from scratch, we hack it and that is how complexity and subsequently bugs get added. In my experience, the base infrastructure code for any system always looks simplistic and beautiful. The ugly part is often how it has been used over the years.
You know what's bad?
An object with a single 2200 line method that takes 70 parameters
You know what's also bad?
300 tightly coupled classes that have no individual use.
Striking the balance is what is really important and there's no one size fits all metric for that beyond peer review.
I find myself cringing every time someone comes in and makes a grand sweeping statement about simplicity or density or whatever else because it ignores problems by carpet bombing a philosophy.
Cyclomatic complexity doesn't mean much without analysis.
Any idiot can write complex code.
Bzzt, wrong. It's:
Any idiot can write complicated code.
"Simplicity is the ultimate sophistication."
-- Leonardo da Vinci
"Plurality should not be assumed without necessity."
-- William of Ockham, often referred to as Ockham's Razor -- the simplest explanation is usually the right one.
"Everything should be made as simple as possible, but not simpler."
-- Attributed to Einstein
"If you can't explain it to a six year old, you don't understand it yourself."
-- Albert Einstein (attributed)
"Truth is ever to be found in the simplicity, and not in the multiplicity and confusion of things." -- Issac Newton
"Beauty of style and harmony and grace and good rhythm depend on simplicity."
-- Plato
"The greatest ideas are the simplest."
-- William Golding, Lord of the Flies
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage to move in the opposite direction."
-- E.F. Schumacher
"Those guys are all wrong."
-- Andrew Binstock, Editor in Chief, Dr. Dobbs
Choose well, reader...
#fuckbeta #iamslashdot #dicemustdie
Frankly, I was a little disappointed in this article. His arguments seems a bit - for lack of a better term: simple.
Is there anyone out there who is arguing that simple solutions to inherently complex problems exist and are a good thing?
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
Simplicity is word that gets batted around a lot. When it used to mean "the shortest distance to a solution to the immediate problem", you are often trading immediate simplicity for longer term inflexibility.
I've found the simplest solutions are those which are well designed, which take into account not just the immediate problem at hand, but reasonable future variations of that problem. The up front investment in thought and design and pay off in a big way down the road when new problems can be solved more elegantly, quickly, and be more maintainable.
Its like someone who collects books. You could just stack them up on the floor, but finding one or adding more is going to increase the chance that they all fall over. If you take the time to get some bookshelves and think of a cataloging system, your book collecting is going to scale much better.
Good design and good structure benefit simplicity. If you ignore it, you are just pushing complexity into the future.
The people who I think need to be berated are the folks who write the obfuscated code or do things like overload operators not because they need to, but because they can.
I think you mean beheaded. And their heads mounted on the wall above the server room :)
UPS Sucks
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?
-Brian Kernighan
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.
Brooks made a big point in "No Silver Bullet" about the difference between what he called accidental complexity (introduced by the developers) and essential complexity (introduced by the reality of the problem). And the key thing is that the accidental complexity needs to be avoided or fixed with tools, but the essential complexity can't be avoided.
I am officially gone from
"I had incorporated some sophisticated regular expression pattern-matching.."
So many simple projects turn the corner of complexity, and never look back, right about at that statement.
Join the Slashcott! Feb 10 thru Feb 17!
In journalism school I had a professor who had personally interviewed the Dalai Lama and as a result he often had a very practical outlook on things. When he gave us our first writing assignment (an obituary for a famous person of our choice who was still alive... I decided William Safire had died of a heart attack upon learning that genetic testing proved Hillary Clinton was not, in fact, a congenital liar), someone immediately asked how many column inches he wanted. He replied with a question: "How long is a man's arm?" People started trying to measure their arms against things or guesstimate the average length of a man's arm, asking if that meant he wanted 30 column inches. Finally he quieted everyone and said, "A man's arm is long enough to get the job done. No more. No less." Likewise, the articles we were to write were to be long enough to get the job done. No important things left out, no filler added in. It was an important lesson in judgment.
I think the same applies to code. It should be just complex enough to get the job done. No more, no less. Sometimes that means you're going to have complex code, but it shouldn't be any more complex than it needs to be.
Even the source he cites admits that complex code is a bitch to maintain.
Compare .NET code to the compiled machine code. .net runtime is nothing but a set of functions in a separate file. using simple functions means main()can be an outline of the program, for example .
... 1000 more lines
Which is easier to understand and work on? The
By any measure, Linus Torvalds is an incredibly successful programmer. His guideline is 6-8 lines per function or so.
Consider these two example programs:
Stand
Turn left
Walk four steps
Turn right
Walk two steps
Turn right
Vs:
heatlunch()
readslashdot()
Even if the function heatlunch() is used nowhere else, using it makes the program far more understandable than inlining the walking code to get to the microwave.
Even very complex problems can be made to look simple at various levels of abstraction. Hiding complexity inside objects that represent real-world objects is a good way to make the code that uses those objects simpler.
In development, plan to do at least one major refactoring after the project is feature-complete to move complicatons in and out of abstractions, add new abstractions or collapse old old ones as needed to make things "feel good".
A separate class - are you mad? Just template them on , sheesh!
Also FatPhil on SoylentNews, id 863
I liken this to an overflowing garbage can. Every subsequent coder delicately places his code on top of the steaming pile, praying that it all holds together.
Then someone makes one too many changes. The pile topples, and the poor sod who touched it last is the one who has to take the garbage out (rewrite it).
Last post!
I work on highly-available systems (telecom equipment, core network stuff). Even there, some parts of the system can be less robust and some parts need to be as robust as possible.
The design for a given component needs to take into account how robust that component needs to be. Do you check EVERY POSSIBLE error condition and figure out intelligent ways to handle them (can be quite difficult and very time-consuming) or can you just panic the system if you detect something has gone wrong and you don't know how to handle it?
In some cases, you need to trade off between reliability and performance. In other cases you need to ship a product so it goes out with known corner cases that aren't handled because in the real world that condition should never happen.
There already exists a word for "no more complex than required", and that term is ELEGANT.
Its been around since the beginning of programming. Get with the program. This is a non-story.
GCS/MU/P d- s:- a-- C++++$ UL++ P+ L++ E+ W++ N o K- w--- O M+ V- PS+++ PE Y+ PGP t+ 5- X R++ tv+ b++ DI++ D++ G+ e++ h-