Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Dr. Dobb's Calls BS On Obsession With Simple Code

timothy posted about a year ago | from the my-dear-watson-this-isn't-perl dept.

Programming 381

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.'"

cancel ×

381 comments

Sorry! There are no comments related to the filter you selected.

To quote Einstein (5, Insightful)

BenSchuarmer (922752) | about a year ago | (#44123497)

Everything should be made as simple as possible, but not simpler.

Re:To quote Einstein (1)

invid (163714) | about a year ago | (#44123589)

Everything should be as complicated as it needs to be, and no more complex.

Re:To quote Einstein (4, Insightful)

lgw (121541) | about a year ago | (#44123773)

Arguing against stupid "complexity metrics" is fair. A programmers job is to game the system. Give him a metric other than making the customer happy, and it will not end well.

But I've seen far too much code that was simply far more complex than it needed to be. Stop tripling the size of your code for use-cases that no one has asked for, people!

If you can make assumptions that significantly simplify your code, and those assumptions fit within the actual, stated requirements of the work (ignoring requirements that exist only in your head), for goodness sake make those assumptions.

Re:To quote Einstein (4, Insightful)

internerdj (1319281) | about a year ago | (#44123925)

Not all customers are smart enough to know to ask for everything. Even a smart customer may not be able to give you a real answer for what happens in X cornercase. Presumably you (or someone like you) are being paid to hash out all the hidden requirements and assumptions to achieve the customer-stated requirements.

Re:To quote Einstein (0)

Anonymous Coward | about a year ago | (#44124155)

Ah, I see you take your inspiration from ToadyOne.

Good man, good man.

Re:To quote Einstein (0)

Anonymous Coward | about a year ago | (#44123615)

The article could've been simpler.

Re:To quote Einstein (1)

Anonymous Coward | about a year ago | (#44123651)

BTW did Einstein really say that, or was it attributed to him by default?

Re:To quote Einstein (5, Informative)

Spy Handler (822350) | about a year ago | (#44123741)

It's paraphrase of Einstein who said something like that at various times in his life, but not those exact words.

Here's an exact quote from Einstein:

"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." - From "On the Method of Theoretical Physics", Oxford, June 10, 1933.

Re:To quote Einstein (5, Funny)

girlintraining (1395911) | about a year ago | (#44123701)

That quote is attributed to Einstein, but you should know by now a great many quotes are attributed to him, but very few can be proven to have been from him. -_-

"There's no such thing as a correct quote citation on the internet." -- Abraham Lincoln

Re:To quote Einstein (3, Funny)

93 Escort Wagon (326346) | about a year ago | (#44123899)

In the words of Albert Einstein: "I never said most of the things I said."

Re:To quote Einstein (1)

sosume (680416) | about a year ago | (#44123991)

"There's no such thing as a correct quote citation on the internet." -- Abraham Lincoln

pure gold

Re:To quote Einstein (0)

Anonymous Coward | about a year ago | (#44123713)

That's too simple of a dictum, though: Sometimes there are benefits to added complexity that aren't required but may be worthwhile anyway. It's possible to make some of my work simpler, but is the added complexity worth the benefits? There are value judgments involved, not the black and white of possible/impossible.

Re:To quote Einstein (-1)

Anonymous Coward | about a year ago | (#44123811)

Your mom says it as "Fuck me with cocks 10" and no smaller." Your sissy, cuckolded daddy unfortunately is less hung than a tooth pick.

Re:To quote Einstein (1)

Drethon (1445051) | about a year ago | (#44123875)

Or as they say with requirements. The best requirement is usually the shortest requirement that is complete and unambiguous (plus a few other things depending on the software level).

Re:To quote Einstein (1)

lightknight (213164) | about a year ago | (#44123935)

Indeed. Simplicity is but an ingredient to the main dish that is perfection...it is not the sole ingredient; too much, and the flavor is ruined; too little, and the inner ideal is never glimpsed.

Re:To quote Einstein (1)

Baby Duck (176251) | about a year ago | (#44124169)

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupery

Meh (5, Insightful)

Anrego (830717) | about a year ago | (#44123541)

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...

Hello World! (1)

Dareth (47614) | about a year ago | (#44123601)

The is a good reason I need a separate class defined to output each character in the string "Hello World!"

Re:Hello World! (1)

Cenan (1892902) | about a year ago | (#44124003)

Of course you do, how would you localize it if you didn't? Man, some people...

Re:Meh (0)

Anonymous Coward | about a year ago | (#44123675)

True but you can't get up on your high horse over that can you?

Re:Meh (0)

Anonymous Coward | about a year ago | (#44123909)

You're kidding right? When I come into a new job and need to re-write some god awful code, it's common to reduce 3000 lines to 400. It become easier to understand, smaller, more maintainable and more resource-efficient.

As far as I'm concerned, the simple solution which solves the same problem is worthy of getting on my high horse. I'm quite proud of fixing code in this way. I'm not proud of writing needlessly complex shit. Only idiots use "lines of code" as a metric.

Re:Meh (2, Insightful)

Anonymous Coward | about a year ago | (#44123677)

I think Dr. Dobb's stopped being relevant oh like 10 years ago. Its like a total kids magazine now, nothing like it was years ago. Most articles in it are unreadable.

Re:Meh (0)

Anonymous Coward | about a year ago | (#44123855)

So I take it you're a subscriber? You certainly write like you're 12 years old.

Re:Meh (0)

Anonymous Coward | about a year ago | (#44123867)

One of the programmers I work with complains when you use more than 1 function to do a job. Even if it means writing a 20 page function. His code is unmaintainable because you can't change even a tiny part of it without breaking something 3 pages down. He cries that my code is too complex because I break things down into small simple functions and multiple files and build complex behaviors out of them so he has to swap between files.

He used to work on IE at Microsoft, so that might tell you something.

Re:Meh (2)

spiffmastercow (1001386) | about a year ago | (#44123921)

One of the programmers I work with complains when you use more than 1 function to do a job. Even if it means writing a 20 page function. His code is unmaintainable because you can't change even a tiny part of it without breaking something 3 pages down. He cries that my code is too complex because I break things down into small simple functions and multiple files and build complex behaviors out of them so he has to swap between files.

He used to work on IE at Microsoft, so that might tell you something.

Do you re-use your functions, or do they only exist to break apart a single operation into smaller blocks? If it's the latter, then he may have a good point.

Re:Meh (1)

interval1066 (668936) | about a year ago | (#44123983)

My thought exactly. Binstock is certainly correct, but the tone of the article is as if there is a world-wide problem that needs to be addressed. I don't think so. I think he feels the need to qualify a programmatically philosophical point that everyone implicately understands already. For example, I've never had a manager look at my project and say "It has to be simpler!", meanwhile I'm always questioning my code and looking for stuff I can remove. When I get to a point where I simply can't, I move on.

Re:Meh (1)

phantomfive (622387) | about a year ago | (#44124129)

For example, I've never had a manager look at my project and say "It has to be simpler!",

He probably did have a manager (or some coworkers) who did say that, which is why he was motivated enough to write a rant on the topic.

Re:Meh (2)

rwv (1636355) | about a year ago | (#44123993)

It wasn't until the mention of Cyclomatic Complexity that I understood what the summary was saying. It boils down to writing individual functions logically with as many if/else/while/for/switch branches as you need. Oftentimes, breaking up code into multiple functions to satisfy some arbitrary Cyclomatic "Complexity" coding standard makes it MORE COMPLEX. On the other hand, Cyclomatic Complexity can be used to find spaghetti code that would make a good project for refactoring. At the end of the day... human analysis figures out what is simple vs. complex. It's impossible to know how complex a piece of software is with code metrics alone.

When dealing with egos (0)

Anonymous Coward | about a year ago | (#44124095)

You claim to be a brilliant programmer, yet don't give me an elegant solution to an interesting problem. That's truly the set of problems -- ego, elegance, and interest. Most of us are writing software that's boring, aren't truly in the small brilliant fraction, and the problesm we are addressing are uninteresting.

Einstein quote (2)

olsmeister (1488789) | about a year ago | (#44123547)

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."

Re:Einstein quote (1)

phantomfive (622387) | about a year ago | (#44124065)

Over on the c2 wiki [c2.com] there's a quote somewhere, "Judging things solely on the basis of simplicity is an overly simplistic approach." That seems to be what this guy is getting at, although his thinking isn't very clear.

Simple (0)

Anonymous Coward | about a year ago | (#44123549)

It is really very simple. If you write complex code to solve a problem, someone else solves with simple code, you have just shown your inferiority WRT the other engineer.

"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."

Yes! (0)

Anonymous Coward | about a year ago | (#44123553)

Hoorah!

Sort of (1)

Intrepid imaginaut (1970940) | about a year ago | (#44123581)

In databases things get normalised down to their most basic elements, which is neccessary and good. In coding, everything might individually be simple, but the whole might be horrendously complex. Good documentation makes almost anything simple though, and by that I mean docs written intentionally to explain the overall codebase rather than disconnected sections.

Re:Sort of (0)

Anonymous Coward | about a year ago | (#44123669)

Normalization only applies to a Relational Database.

Even in a relational database, normalization is a set of rules that can be applied along a range of strict to loose depending on the circumstances of the usage. Saying normalization is always necessary and good is a misleading and inaccurate statement.

Re:Sort of (1)

Intrepid imaginaut (1970940) | about a year ago | (#44123815)

Okay, most databases and most use cases.

Re:Sort of (1)

rjstanford (69735) | about a year ago | (#44123963)

Have you ever looked at a 5NF database? They can be hugely inefficient and remarkably hard to get right.

So the news is... (1)

gentryx (759438) | about a year ago | (#44123585)

Your code shouldn't be more complex than it really needs to be. But isn't that the way we thought about simple code all the time?

Re:So the news is... (1)

roboticon (2715841) | about a year ago | (#44123687)

Your code shouldn't be more complex than it really needs to be.

Obviously your writing is too simple, because he states the rule simply as "simplicity is the quality of code that is no more complex than required to express the underlying complexity".

Obviously he needs to apply the rule... (1)

gentryx (759438) | about a year ago | (#44123783)

...to his writing, too. Or, as Antoine de Saint-Exupéry has put it: "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

Re:Obviously he needs to apply the rule... (0)

Anonymous Coward | about a year ago | (#44124045)

in other words, Build first, Optimize later

Re:So the news is... (0)

Anonymous Coward | about a year ago | (#44123725)

Yeah, I don't know who he is railing about with the editorial, but he says what I've been doing:

This brings me to the point that is truly the heart of the matter: It's not simplicity that matters, but readability. Can the code be understood with the least amount of effort given its inherent complexity? That is the true criterion. How readable, or if you prefer, how maintainable is the code with respect to its complexity?

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.

Re:So the news is... (2)

SirGeek (120712) | about a year ago | (#44123779)

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 :)

Agree, but not completely (5, Insightful)

parallel_prankster (1455313) | about a year ago | (#44123599)

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.

Re:Agree, but not completely (1)

ADRA (37398) | about a year ago | (#44123923)

Rewrites vs refactoring are all to common and this pattern is surely nothing new. One way is to design for change up front. This can be accomplished in many ways, but can be vastly simplified by cgood coupling/cohesion, as well as avoiding any kind of fixed constants. It may make initial implementation slower, but it'd leave the system in a better state for change in the future. Of course this flexability can itself lead to greater complexity, so buyer beware.

Ultimately, we all code in different ways at vastly varying backgrounds and skill levels. If coding was just about me, it would do exactly what I want, and it would be quite simple, becase any code that I write (with appropriate comments) -should- be understandable by myself a year or two out. Introducing new people without perfect vision of how I code means there's always complexity. Thats why we establish common patterns. If nothing else they establish a language of coding which one would hope your co-workers understand enough to comprehend.

Eg. In OO, if I have a class has words like Factory, Abstract, DAO/DTO, etc.. a developer should be able to infer the general use for these classes.

Re:Agree, but not completely (1)

parallel_prankster (1455313) | about a year ago | (#44123975)

Right, but then if you keep writing code for future expansion, you are over designing. A lot of the times, it is really hard to predict what direction this project is going to take. You also end up with pieces of code that are being maintained for future really. You do bring out another interesting point. Code that looks simple to me may not look simple to others.

Re:Agree, but not completely (1)

Tablizer (95088) | about a year ago | (#44124107)

In finance there's the concept of Future Value in which the cost of the present is weighed more heavily than future costs. This also applies more or less to software: we know the here-and-now needs but the future is too murky in terms of product direction or even its very existence.

One can learn a lot about design choices by studying finance theory because it trains you to better weigh probabilistic options and related costs in your mind. (Game theory has some similarities also.)

I look for "bargain future-proofing" where if it's easy and only slightly more code to prepare for reasonable future changes, I'll go ahead add such to the initial design. However, if the candidate preparation adds significant complexity to the design without a high probability (roughly 70%) of actual need occurrence, then it's not worth it.

It takes both programming experience and experience with the domain (industry type) to make good estimations of future directions.

Re: Agree, but not completely (0)

Anonymous Coward | about a year ago | (#44123933)

Sometimes the code is more complex than it needs to be, even in the beginning of the project.

Problems really start when this bad code is used and even copied many times. At that point most programmers think that it is impossible to fix and even best programmers need a week to fix it.

Compare algebraic simplifications (1)

Anonymous Coward | about a year ago | (#44123631)

Why do we simplify expressions in algebra? Because ink is expensive? Because it takes too much time to write a lot of letters? Or because calculations are very hard to understand when they take up entire pages when they could be simplified to a few letters?

good developers writes good code, bad ones don't (1)

jellomizer (103300) | about a year ago | (#44123639)

Writing code Simple or Complex really depends on the Developer and the mindset of the developer at the time.

Sometimes the Simple Code actually makes it too hard to manage. Say you are given specs and you find it fits nicely in a mathematical function. So you create that function and it works fine, until a new change happens then you function is just wrong and you need to redo it. However if you make your code a bit more complicated, that change might be just a simple if statements, and you are all set again.

The line depends on the skill of the developer. Having worked with recent grads who really did write good code, however lacked experience, got really frustrated at my designs because they accounted for "changes that wasn't in the specs". Why are you using a String instead of an Int, the int is faster and takes up less space, the data told us this element is a number. However my experience told me for that case you could come across a state where it could be a string. Months later there was an Oh By the Way We have this case which made it a string, and we didn't have to remap a bunch of fields. Experience is key.

   

Re:good developers writes good code, bad ones don' (0)

Anonymous Coward | about a year ago | (#44124007)

You're the guy who puts all those dictionaries in the code with strings as keys. I hate you.

captcha: damage

Carpetbombing Philosophy (2, Insightful)

Anonymous Coward | about a year ago | (#44123647)

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.

Re:Carpetbombing Philosophy (1)

SirGeek (120712) | about a year ago | (#44123789)

You mean an MBA ?

I like my data to be complex (1)

Anonymous Coward | about a year ago | (#44123649)

Not my code. As long as the data doesn't have to be turing-complete I'm satisfied.

Premise is wrong. (2, Insightful)

Anonymous Coward | about a year ago | (#44123657)

Any idiot can write complex code.

Bzzt, wrong. It's:

Any idiot can write complicated code.

"rant" is a nice way of putting it (5, Insightful)

girlintraining (1395911) | about a year ago | (#44123671)

"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...

Re:"rant" is a nice way of putting it (2)

chthon (580889) | about a year ago | (#44123817)

In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.

Antoine de Saint-Exupery (1900 - 1944)

Re:"rant" is a nice way of putting it (1)

fahrbot-bot (874524) | about a year ago | (#44124067)

"If you can't explain it to a six year old, you don't understand it yourself."
-- Albert Einstein (attributed)

Having recently spent time with a friend and her six-year-old daughter, I can honestly, accurately, say that is not true. The kid is really, really smart - for a six-year-old - but, like *all* six-year-old humans, her brain simply isn't developed enough to grasp many - many - concepts. This also applies, to a lesser extent, to gifted kids (my wife was a Gifted Education teacher). In either case, any parents (or Albert Einsteins) who say otherwise are fooling themselves.

interesting topic, disappointing article (2)

dirtyhippie (259852) | about a year ago | (#44123673)

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?

Re:interesting topic, disappointing article (0)

Anonymous Coward | about a year ago | (#44123861)

printf("yes");

That one simple statement actually does a LOT of stuff. The % operators are hellish to get just right (unless you do not mind memory over/under runs). Many implementations get something as simple as

short xyz = 1;
printf("%d", xyz);

Results in a memory overrun in many versions of printf.

right way is
printf("%h", xyz);

That is but one example of something complex that is simple to write that is hard to get right.

Re:interesting topic, disappointing article (0)

Anonymous Coward | about a year ago | (#44124125)

That one simple statement actually does a LOT of stuff. The % operators are hellish to get just right (unless you do not mind memory over/under runs)

The simple solution: use a more modern language. Don't waste your time using the wrong tool for the job. (If your printfs are in a performance-critical section, just put down the keyboard and find a new career)

Re:interesting topic, disappointing article (3, Insightful)

Hentes (2461350) | about a year ago | (#44124043)

Complex problems are defined as problems with no simple solution. The article is not just simple, it's a tautology.

Re:interesting topic, disappointing article (2)

fahrbot-bot (874524) | about a year ago | (#44124089)

Frankly, I was a little disappointed in this article. His arguments seems a bit - for lack of a better term: simple.

Well... Any idiot can make a complex argument. :-)

PEP20 (3, Interesting)

RobbieCrash (834439) | about a year ago | (#44123709)

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.

Re:PEP20 (1)

darkstar949 (697933) | about a year ago | (#44123841)

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.

Those two always bother me though because when it comes to software development it always seems like there is an exception to every rule. Something like Ukkonen's algorithm [wikipedia.org] is both hard to explain and a good idea and that's just the first one to come to mind.

Re:PEP20 (1)

RobbieCrash (834439) | about a year ago | (#44123961)

The concept seems more difficult than the implementation in that case, which I don't think is the point of those lines.

I always looked at those lines as don't do result = d.x(y + l.u(v[i[m + 4*t.base(vvv)]])) when you can instead spread it out over a few more lines and make it more readable, less Perly. Either way, you're still going to need the logic figured out, but one is easy to explain and figure out at a glance, while the other is a bunch of back and forth and what the fucks.

No good examples in article so I can't agree (1)

locopuyo (1433631) | about a year ago | (#44123733)

I didn't see any good examples in his article. The only example he had was a switch statement with 35 cases being simplified by using a table which somehow makes it harder to read than scrolling through a 35 case switch statement. I'm not convinced at all. This guy sounds like he could benefit from reading Clean Code by Robert C. Martin.

Re:No good examples in article so I can't agree (1)

darkstar949 (697933) | about a year ago | (#44123893)

This guy sounds like he could benefit from reading Clean Code by Robert C. Martin.

I wouldn't be supprised if "Clean Code" is what prompted the article in the first place.

Re:No good examples in article so I can't agree (0)

Anonymous Coward | about a year ago | (#44124085)

Yup. Martin's "Clean Code" is all about making individual functions as small as possible, at the expense of exploding the overall codebase into an over-abstracted mess.

Good design is simpler than no design (2)

joeaguy (884004) | about a year ago | (#44123757)

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.

Sometimes too much of the complexity is hidden (1)

jandrese (485) | about a year ago | (#44123771)

I see this a lot with the various "on rails" development schemes, where they sweep a tremendous amount of complexity under the rug so users can quickly develop whatever they want. Only later they discover that something is broken or slow with their project and now fixing it requires a herculean effort because they never really understood what was happening before. It's discouraging and many projects just resign themselves to being broken or start to incorporate ugly workarounds to try to avoid the problem without really fixing it.

My code is always simple (1)

jbeaupre (752124) | about a year ago | (#44123775)

I limit it to 1's and 0's

Clever code (2)

Teckla (630646) | about a year ago | (#44123799)

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

Re:Clever code (1)

gweihir (88907) | about a year ago | (#44124111)

"As clever as possible" means "as complicated as possible" here, not as "elegant, simple and clear as possible".

He just redifined everything. Its a strawman. (4, Interesting)

Karmashock (2415832) | about a year ago | (#44123821)

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.

Re:He just redifined everything. Its a strawman. (0)

Anonymous Coward | about a year ago | (#44124119)

Actually - today it's considered good programming to prefer some simplicity over some efficiency. That is - shaving a few lines of code in exchange for extra complexity is not considered a good merit.
Shaving an unnecessary loop, however - is usually deemed worth the extra complexity that it might bring.

Of course it's more complicated than that - if a code sits in the critical path of a real time application - than it might be extremely complex - to shave those 5 extra function calls.

The zen of python defines the complexity issue quite clearly:

  Simple is better than complex.
        Complex is better than complicated.

My Complex Rule (0)

Anonymous Coward | about a year ago | (#44123827)

If you write some code and you can't explain what it does, without reading comments or external documentation, then it was written in a way should be simplified.

Re:My Complex Rule (1)

gweihir (88907) | about a year ago | (#44124099)

That will fail once you do more complicated things. The benchmark is whether the code with its documentation can be understood in a reasonable amount of time with respect to the complexity of the problem solved. You should make code as simple as possible, but not simpler. You are trying to make it simpler than possible.

coding becoming like fine wine (0)

Anonymous Coward | about a year ago | (#44123853)

Complex, simple, OOA/D, functional, good coders, bad coders, sloppy code, hacked code, elegant code, modular code.

Coding is truly an art much like producing fine wine.
And like fine wine, no one gives a damn. It's freaking alcohol... not grape juice...

In conclusion, code just needs to damn work for the given purpose and be maintainable for the target skill level to maintain it. That's it, who cares about complex vs simple. Much like fine wine, as long as it's alcohol no one really cares on the making part.

Lame excuse (1)

Teckla (630646) | about a year ago | (#44123887)

I'm afraid software developers will read this article and use it as a lame excuse to write complex code, because it's easier to write complex code than to write simple code, though it's much, much harder to maintain, enhance, and debug complex code.

Complex code hides bugs. Complex code is generally less robust and reliable. Complex code usually has more security holes.

Sure, some things have to be complex. But generally, you should strive for small functions (methods) that do one thing, and do it well, and keep side effects as localized as possible.

And the same applies up the stack. Make sure each layer (methods -> objects -> programs -> etc.) alone can be grokked inside the head of a single person. This is how you manage complexity. This is how you build big systems.

Re:Lame excuse (1)

gweihir (88907) | about a year ago | (#44124083)

Indeed. And it applies to architecture and design just as well:

"There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult." --Tony Hoare

Writing complex code where simple code would be adequate and much clearer is the hallmark
of incompetence.

Once again reinventing Fred Brooks (3, Insightful)

dkleinsc (563838) | about a year ago | (#44123889)

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.

Re:Once again reinventing Fred Brooks (1)

gweihir (88907) | about a year ago | (#44124011)

Exactly. And where you face essential complexity, make sure what you do is as clear and well-structured as possible. "Simple" does not mean "simplistic".

Funny thing is no real engineers have any problems with that idea or are unaware of it. It is just people in IT that seems to still struggle with fundamental engineering concepts.

Obsession with simplicity all about offshoring (0)

Anonymous Coward | about a year ago | (#44123895)

Use bright, talented programmers to get the initial job done, throw "simple" code across the ocean to $3/hr code monkeys in India.

Re:Obsession with simplicity all about offshoring (1)

gweihir (88907) | about a year ago | (#44124047)

"Code monkeys" in India are not able to do simple things in a simple way. They have a tendency to introduce unneeded complexity, because of deficient education and lack of experience. I have seen this several times, at least once with project-killing consequences.

Gone are the days (1)

ChrisMaple (607946) | about a year ago | (#44123927)

Dr. Dobb's Journal's motto was once "Running light without overbyte." Looks like this valuable maxim is now beyond their ability.

Sometimes it's a good choice to use more complex code when it provides a substantial speed increase. Sometimes it's good to slap something together just so it will run. But if there's no substantial advantage to code that isn't simple, simple is best.

Man bites dog (1)

Tough Love (215404) | about a year ago | (#44123937)

Black is White. Freedom is slavery. Simplicity is bad. Complexity is good. Binstock is +1 Funny.

what? (1)

serbanp (139486) | about a year ago | (#44123939)

The article is mildly entertaining (especially for the awk bits), but the ending is plain stupid, i.e. flat and inane beyond belief ;-)

I don't think that a sane person would explain the apparent improvement of newish cars reliability by the increasing number of built-in programmable gadgets with their millions of code lines. If anything, there is an optimum beyond which the cars will start failing in new and spectacular ways...

The truth revealed (2)

sl4shd0rk (755837) | about a year ago | (#44123959)

"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.

Workarounds make code complex (1)

jmyers (208878) | about a year ago | (#44123971)

A lot of what makes code ugly and complex is working around bugs and incomplete features in languages, database, etc. Every time I start a new project I try to start with a good clean framework. If never fails that you hit a point where documented features dont work and after waisting many hours of research you find the ugly hack workarounds. These acheive the end result but make you cringe when you maintain the code.

It's about the human, not the computer (1)

Tablizer (95088) | about a year ago | (#44123981)

"Readability and change-ability by future maintainers" should be the primary goal. Obtaining that goal doesn't necessarily lead to the most simplest (smallest) code.

However, it's often a difficult goal to codify (describe precisely) because human psychology and physiology are still half-science-half-art subjects. And, every individual is different and thinks and sees better under different circumstances compared to other individuals.

It's best to get multiple opinions on different styles to try to find a consensus.

This reminds me of a debate on the readability of a sample Lisp case-like and IF-like statement set versus the VB equivalent of a given application. To me the VB version just looked easier to read than the Lisp version despite Lisp being smaller in the test, partly because VB forces certain line-spacing and repetitious keyword conventions on you. It looked closer to how one may document an algorithm on paper for quickest visual absorption. You lose some compactness because of that, but a consistent and familiar "product" can improve visual identification of the parts.

The Lisp fan claimed that "one will eventually get used to" the Lisp approach and it would grow easier to read for anybody who tried long enough, not just him. I'm a bit skeptical of that claim, plus my future replacement may not have that experience and be starting from scratch reading Lisp.

The Algol-style block constructs (as found in VB, C, ADA, etc.) are deeply ingrained in most developers. Even if it was possible to "get used to" Lisp's approach, the pool of experienced Lisp developers may have to reach a certain size threshold in order to make replacement staffing viable for a typical company.

The Algol style has been time-tested, and very few tech companies have gotten rich from Lisp despite being popular with graduates. The pudding doesn't favor Lisp yet.

(C's case/switch statement really needs an overhaul, BTW, at least for derivative languages of C where machine speed is a secondary concern.)

Clarity is what is actually important (1)

gweihir (88907) | about a year ago | (#44123985)

KISS is not "make it simple". KISS is "keep it as simple as possible while retaining clarity, but not simpler". It is about not adding complexity _unless_ needed. Anybody competent understands that. This "rant" is entirely redundant and shows a lack of understanding of fundamental engineering principles.

Bill Atkinson -2000 lines of code (1)

WillAdams (45638) | about a year ago | (#44124005)

The problem is there isn't a way to determine from a simplistic line of code metric whether or no a line is truly needed, resulting in sloppy bloated code.

Every line of code which is properly designed out of a block of code is a line which will not have to be executed, debugged, stored or every worried about again:

http://folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt [folklore.org]

Debugging "simple code" sometimes terrible (1)

hsmith (818216) | about a year ago | (#44124017)

I've had to debug systems where code was abstracted so much - to make such simple routines that it was nearly impossible to debug. So, though simplification helps - sometimes writing a long routine maybe preferable.

unemotional? (1)

phantomfive (622387) | about a year ago | (#44124029)

My view of simplicity is unemotional and free of idolatry

Calling your opponents 'idolaters' is the opposite of unemotional. It is an emotionally charged indication that you don't actually understand the other viewpoint.

How Long Is A Man's Arm? (2)

guttentag (313541) | about a year ago | (#44124057)

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.

His only source contradicts him (2)

Hentes (2461350) | about a year ago | (#44124071)

"I had incorporated some sophisticated regular expression pattern-matching technology into AWK Brian Kernighan once took a look at the pattern-matching module that I had written and his only addition was putting a comment, 'Abandon all hope, ye who enter here.' As a consequence, neither Kernighan nor Weinberger would touch that part of the code. I was the one who always had to make the bug fixes to that module"

Even the source he cites admits that complex code is a bitch to maintain.

That article is void of content. (0)

Anonymous Coward | about a year ago | (#44124109)

The only "example" he brings is one of awk where the matching module by Aho was labelled as unmaintainable by other programmers. Then basically Binstock states "Aho is a superb programmer, so the module must have been written as simple as possible". What rubbish. It's like stating that a great pianist will find the best fingerings for a piece he plays well, and you just need to write them down.

The actual truth is that a great pianists will find fingerings intuitively that suit their skill set and style of playing. But that does not mean that most of them are fit for writing down, publishing and teaching to others.

Good fingerings are matched to the problem space, not to the performer space. And good code matches the problem space to the tool space, the used language and libraries.

The article does not get any of this. It just harps about "complex problems exist, so complex code is fine". The truth is that the concepts underlying complex code can usually be expressed in an understandable manner: read "The Art of Computer Programming" for a lot of examples. And transferring the structure and transparency of a good human-readable description to code without large losses is an art requiring lots of diligence and a thorough grasp of the language and its patterns, and how they match the problem patterns.

Hacking code from the ground up is pretty much the opposite. And particularly hard-core programmers who can read core dumps, back traces, assembly and so on dive into the mind frame of the machine rather than the abstract representation of the problem in human-understandable terms. They need discipline to pattern their code along the lines of the principles of the solution.

And I should know. I learnt coding when the output was made available hours after your input (and that includes compilation errors), possibly with a core dump. I soldered my first computer together myself. When I bought my first disk drive, I had to write bootstrap loader and BIOS (in assembly language, of course) before being able to boot first time.

His main point (1)

phantomfive (622387) | about a year ago | (#44124121)

The summary misses (what I consider) his main point, but here it is:

This brings me to the point that is truly the heart of the matter: It's not simplicity that matters, but readability. Can the code be understood with the least amount of effort given its inherent complexity? That is the true criterion. How readable, or if you prefer, how maintainable is the code with respect to its complexity?

I disagree (1)

stanlyb (1839382) | about a year ago | (#44124165)

The problem is not that the complex code is "bad", but that there are many stupid developers using pretty much complex libraries and modules, and don't forget the copy/paste methodology, and the result is something that is "somehow" working, and extremely complex and hard to read. Well written and maintained code is always pleasure to read, no matter its complexity or the used libraries. One more thing, give an idiot a hammer, and every problem he face would look to him like a nail.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>