The simplicity cliche

[michiguel]

This is what i feel when someone tries to lecture me of how my code can be simpler, and why i have to insert asserts everywhere in my source codes. I feel like these are way over-rated specially in chess forums. Dr Dobb's tells it like it is Discuss!

Excellent.

Every discipline have their own fetishes, and this is one of them for computer science. I expressed more than once, unsuccessfully, that there are other words that do not mean much. "Clean" code, "Beautiful" code, what do they mean? You cannot actually define them. But, you can define "readable", and "straightforward", for instance. You can define "simplicity", but as the article says, why does it matter? Einstein has been paraphrased saying "everything should be as simple as possible, but not simpler" and that seems to be the spirit of the article.
http://quoteinvestigator.com/2011/05/13 ... #more-2363

Miguel

[bob]

My comment would be "if you can write it, you can debug it, regardless of simplicity."

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” –Brian Kernighan

No disrespect, but I am with Brian on this one.

I'm not. Its a cute "saying". But "clever" does not have to mean "impossible to understand". Just "clever" or "fast" or whatever the goal happens to be.

[bob]

But complex things can be combined from simpler ones (composition). When we will have even better optimizing compilers, this will be the way.

Problem is, I am 65 years old now. I won't be programming long enough to see a compiler basically "rewrite" a program like that.

[bhlangonijr]

This is what i feel when someone tries to lecture me of how my code can be simpler, and why i have to insert asserts everywhere in my source codes. I feel like these are way over-rated specially in chess forums. Dr Dobb's tells it like it is Discuss!

Good article, thanks!

It is very important to distinguish "complicated" from "complex" though.

Complicated is bad, complex is not.

I like The Zen of Python (Sorry if i am polluting your thread with this):

The Zen of Python

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.
Namespaces are one honking great idea -- let's do more of those!

http://www.python.org/dev/peps/pep-0020/

[Daniel Shawul]

Glad you liked it. He so had me by the first paragraph that I would have believed anything he said afterwards. So poetically written even for a non-native English speaker like me. Anyway I guess it is good to have a standard to follow and preaching simplicity may be in general the better alternative. As for me, I struggle to follow coding standards, and as the article puts it I am one of those who node and move to the next thing. Have you ever asked a question in java/c# forums and showed some code as a beginner? You get much lecture on coding standards than your actual question.

[lucasart]

I'm sorry to disagree with all of you, but I remain convinced that simplicity is the key to writing clean / readable / reusable code. You are trying to play on the words or to reverse the causality by saying that simplicity doesn't matter and cleanlyness / readibility / reusability is the essence. I say, they are corrollary of simplicity.

The problem at hand is, as a whole, sometimes very complex. True talent is to be able to break down a complex problem into small and individually simple problems. A great example is the apparition of Fruit. Everyone was surprised, because at the time it was the reign of complexity, and people assumed that the more code they had, the more complex features (search/eval) they had, the better their engine would be. Well, turns out this is plainly wrong, and the more complex and messy code is, the more these features badly interact with each other in obscure ways that the programmer does not understand. The key to Fruit's success is simplicity. When you read the code, everything is KISS-compliant. True talent is to make something hard look simple.

This is not only true of computer science:
* "If you can't explain it simply, you don't understand it well enough." - Albert Einstein.
* "Simplicity is the ultimate sophistication" - Leonardo Da Vinci.
* "Less is more" - Ludwig Mies van der Rohe.

And back to the field of computer science, to give you an example from people who solve much more complex problems than we do:
www.schedmd.com/slurmdocs/coding_style.pdf
As you can see Linus Torvalds is an Ayatollah of simplicity.

[Daniel Shawul]

Nodes and moves to the next thing.

[Michel]

Simplicity is important in collaborative projects. That is why Stockfish
development is so successful these days. Stockfish's code is crystal clear and the
developers go to great length to keep it that way, even rejecting patches
that have been demonstrated to give elo gain.

There are star programmers that can quickly turn out large amounts of
complex and more or less working code but they are useless in a
collaborative environment since other people cannot work with this code.

[Henk]

Simplicity is important in collaborative projects. That is why Stockfish
development is so successful these days. Stockfish's code is crystal clear and the
developers go to great length to keep it that way, even rejecting patches
that have been demonstrated to give elo gain.

There are star programmers that can quickly turn out large amounts of
complex and more or less working code but they are useless in a
collaborative environment since other people cannot work with this code.

So never collaborate otherwise you have to write simple boring code.

[Daniel Shawul]

Classy move, you want me to comment on something probably controversial like droping patches that give elo? State what you feel about it yourself. I would rather not comment on specific projects but I will say this. Are you sure it is not just the collaborative effort, and not simplicity or whatever? I don't feel compelled to assign a certain attribute to a success or failure of a project. That is a job for marketers. 'Simplicity!'...revels in thou awesomeness, 'Knowledge!'...you get the picture. Success is rarely summed up with one word/attribute like that in real life. "It is a sum of many small things that add up to a great outcome", says the preacher in me.

I know pretty complex projects written in hard-core C++ that could have benefited from a large mass of fortran coders. But the core programmers insist on their ways and are infact happy about it cause it keeps away those guys. It is like they are saying screw you professors we are the new cool kids with c++ savvy. You know what, they are missing out on a ton of knowledge and real science weren't they so religious about the code. That is what I call missing the big picture. Note that this is a big project not a single person could ever comprehend by himself and finish like a chess program. This one professor that happened to be C++ savy took the open source project and did many stuff in a short time. The programmers didn't like that one bit so he is blacklisted now. But i don't think he cares because he has a legal branch that he benefits from by providing support and giving lectures and stuff. Anyway I node in assent and move on to the next thing, if i failed to convince you