simple

Difference between version 17 and 18 - Previous - Next
"There are two ways of constructing a software design; one way is to
''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."
So said Tony Hoare, but where and when?
deficiencies. The first method is far more difficult.''
[SLB] Nice quote. The full article's here: [http://www.braithwaite-lee.com/opinions/p75-hoare.pdf]
: -- [SLB] [PYK]: Hoare's 1980 ACM [https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf%|%Turing Award lecture] ([https://web.archive.org/web/20070211210228/http://www.braithwaite-lee.com/opinions/p75-hoare.pdf%|%alternate], [https://dl.acm.org/ft_gateway.cfm?id=1283936&type=pdf%|%original]).
----
[KISS]
----
[Charles Moore] also wanted designs to be simple. He once put it this way:
''Keep it simple. A simple solution has elegance. It is the result of an exacting effort to understand the real problem and is recognized by its compelling sense of rightness.''
''Keep It Simple. A simple solution has elegance. It is the result of exacting effort to understand the real problem and is recognized by its compelling sense of rightness. I stress this point because it contradicts the conventional view that power increases with complexity. Simplicity provides confidence, reliability, compactness, and speed.''
''I stress this point because it contradicts the conventional view that power increases with complexity. Simplicity provides confidence, reliability, compactness, and speed.''
: -- [Charles Moore], in [http://home.iae.nl/users/mhx/sf0/sf0.html%|%Starting Forth], by Leo Brodie
----
A nice essay by Leslie Lamport: [http://research.microsoft.com/users/lamport/pubs/future-of-computing.ps].
(Ironic that this is by the guy who wrote [LaTeX], of all things, but it's a good essay nonetheless.)
[https://lamport.azurewebsites.net/pubs/future-of-computing.pdf%|%The Future of
Computing: Logic or Biology]
([https://www.microsoft.com/en-us/research/uploads/prod/2016/12/The-Future-of-Computing.pdf%|%alternate]
,[http://research.microsoft.com/users/lamport/pubs/future-of-computing.ps%|%alternate]),
by Leslie Lamport, is a nice essay (ironic that this is by the guy who wrote
[LaTeX], of all things, but it's a good essay nonetheless).
----
Bob Colwell: "Design Fragility" [http://www.computer.org/computer/homepage/0104/random/]
[https://web.archive.org/web/20050624084830/http://www.computer.org/computer/homepage/0104/random/%|%Design
Fragility], by Bob Colwell
* Complexity breeds fragility. * Fragility breeds surprises. * Surprises are bad. ----
Good quote from Anders Hejlsberg [http://www.artima.com/intv/simplexityP.html]:
"There's one kind of simplicity that I like to call simplexity. When you take something incredibly complex and try to wrap it in something simpler, you often just shroud the complexity. You don't actually design a truly simple system. And in some ways you make it even more complex, because now the user has to understand what was omitted that they might sometimes need. That's simplexity.
''There's one kind of simplicity that I like to call simplexity. When you take something incredibly complex and try to wrap it in something simpler, you often just shroud the complexity. You don't actually design a truly simple system. And in some ways you make it even more complex, because now the user has to understand what was omitted that they might sometimes need. That's simplexity.
So to me, simplicity has to be true, in the sense that the further down you go the simpler it gets.
It shouldn't get more complicated as you delve down."
It shouldn't get more complicated as you delve down.''
: -- [http://www.artima.com/intv/simplexityP.html%|%Delegates, Components, and Simplexity A Conversation with Anders Hejlsberg, Part III], by Bill Venners and Bruce Eckel
----
"We have simple solutions, what we need are simple problems." (Benjamin Franklin)
Objection: But our problems are so frightfully complex... Reply: Well, then simplify them... [RS]
''We have simple solutions, what we need are simple problems.''
: -- Benjamin Franklin
[RS]: Objection: But our problems are so frightfully complex... Reply: Well, then simplify them...
----
"The mistake frequency of programmers and coders increases with the quantity of coding to be written.
Short pieces of program can be written error-free, whereas long routines will inevitably contain mistakes." (Grace Murray Hopper, 1958)
''The mistake frequency of programmers and coders increases with the quantity
of coding to be written. Short pieces of program can be written error-free,
whereas long routines will inevitably contain mistakes.''
: -- Grace Murray Hopper, 1958
----
I can't help but add: "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary" [http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-3.html]. Personally, I think the [dodekalogue] hits this mark much better than (at least the later) Scheme reports.
('''[TCV]''' notes that to be fair to the Schemers, there are many who feel that the latest Scheme standard (R6RS) went somewhat against this grain of simplicity. The ratification results page [http://www.r6rs.org/ratification/results.html] contains some interesting rationales from both sides.)
''Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.''
: -- [http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-3.html%|%Revised5 Report on the Algorithmic Language Scheme]
Personally, I think the [dodekalogue] hits this mark much better than (at least the later) Scheme reports.
[TCV]: To be fair to the Schemers, there are many who feel that the latest Scheme standard (R6RS) went somewhat against this grain of simplicity. The ratification results page [http://www.r6rs.org/ratification/results.html] contains some interesting rationales from both sides.)
----
The above can be taken as a paraphrase of Antoine de Saint-Exupery:
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
''Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.''
----
[dbohdan] 2015-09-09: The talk [http://www.infoq.com/presentations/Simple-Made-Easy%|%Simple Made Easy] ([https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md%|%transcript]) by Rich Hickey of Clojure fame is relevant here. It pays to not confuse the simple with the merely easy.
[dbohdan] 2015-09-09: The talk [http://www.infoq.com/presentations/Simple-Made-Easy%|%Simple Made Easy] ([https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md%|%transcript]) by [Rich Hickey] of [Clojure] fame is relevant here. It pays to not confuse the simple with the merely easy.
<<categories>> Arts and crafts of Tcl-Tk programming | Concept | Development