SlideShare a Scribd company logo
Worse Is Better,
for Better or for Worse



            @KevlinHenney
Worse is better, for better or for worse - Kevlin Henney
Worse is better, for better or for worse - Kevlin Henney
In 1990 I proposed a theory, called
Worse Is Better, of why software would
be more likely to succeed if it was
developed with minimal invention.
It is far better to have an underfeatured
product that is rock solid, fast, and
small than one that covers what an
expert would consider the complete
requirements.
   Simplicity: The design is simple in
    implementation. The interface should be
    simple, but anything adequate will do.
   Completeness: The design covers only
    necessary situations. Completeness can be
    sacrificed in favor of any other quality.
   Correctness: The design is correct in all
    observable aspects.
   Consistency: The design is consistent as far
    as it goes. Consistency is less of a problem
    because you always choose the smallest
    scope for the first implementation.
Implementation characteristics are foremost:
   The implementation should be fast.
   It should be small.
   It should interoperate with the programs
    and tools that the expected users are
    already using.
   It should be bug-free, and if that requires
    implementing fewer features, do it.
   It should use parsimonious abstractions as
    long as they don’t get in the way.
#!/usr/bin/perl
# --------------------------------------------------------   PerlInterpreter
# PerlInterpreter must be the first line of the file.
#
# Copyright (c) 1995, Cunningham & Cunningham, Inc.
#
# This program has been generated by the HyperPerl
# generator. The source hypertext can be found
# at http://c2.com/cgi/wikibase. This program belongs
# to Cunningham & Cunningham, Inc., is to be used
# only by agreement with the owner, and then only
# with the understanding that the owner cannot be
# responsible for any behaviour of the program or
# any damages that it may cause.
# --------------------------------------------------------   InitialComments


# InitialComments
print "Content-type: text/htmlnn";
$DBM = "/usr/ward/$ScriptName";
dbmopen(%db, $DBM , 0666) | &AbortScript("can't open $DBM");
$CookedInput{browse} && &HandleBrowse;
$CookedInput{edit}   && &HandleEdit;
$CookedInput{copy}   && &HandleEdit;
$CookedInput{links} && &HandleLinks;
$CookedInput{search} && &HandleSearch;
dbmclose (%db);
if ($ENV{REQUEST_METHOD} eq POST) {
$CookedInput{post}   && &HandlePost;
}
# &DumpBinding(*CookedInput);
# &DumpBinding(*old);
# &DumpBinding(*ENV);
# -------------------------------------------------------- WikiInHyperPerl
Worse is better, for better or for worse - Kevlin Henney
Worse is better, for better or for worse - Kevlin Henney
Worse is better, for better or for worse - Kevlin Henney
Worse is better, for better or for worse - Kevlin Henney
In a purist view of object-oriented
methodology, dynamic dispatch is the only
mechanism for taking advantage of attributes
that have been forgotten by subsumption.
This position is often taken on abstraction
grounds: no knowledge should be obtainable
about objects except by invoking their
methods. In the purist approach,
subsumption provides a simple and effective
mechanism for hiding private attributes.
OOP to me means only messaging,
local retention and protection and
hiding of state-process, and extreme
late-binding of all things. It can be
done in Smalltalk and in LISP. There
are possibly other systems in which
this is possible, but I'm not aware of
them.


                              Alan Kay
One of the most pure object-oriented
programming models yet defined is
the Component Object Model (COM). It
enforces all of these principles
rigorously. Programming in COM is
very flexible and powerful as a
result. There is no built-in notion
of equality. There is no way to
determine if an object is an
instance of a given class.

                                     William Cook
   "On Understanding Data Abstraction, Revisited"
William Cook, "On Understanding Data Abstraction, Revisited"
newStack =
   (let items = ref() 
   {
      isEmpty =   #items = 0,
      depth =   #items,
      push =  x  items := xˆitemsy  y  0...#items,
      top =   items0
   })
Worse is better, for better or for worse - Kevlin Henney
Worse is better, for better or for worse - Kevlin Henney
var newStack = function() {
    var items = []
    return {
        isEmpty: function() {
             return items.length === 0
        },
        depth: function() {
             return items.length
        },
        push: function(newTop) {
             items = items.unshift(newTop)
        },
        top: function() {
             return items[0]
        }
    }
}
Any application that can be
written in JavaScript, will
eventually be written in
JavaScript.

                    Atwood's Law
Worse is better, for better or for worse - Kevlin Henney
Worse is better, for better or for worse - Kevlin Henney
There have always been fairly severe
size constraints on the Unix operating
system and its software. Given the
partially antagonistic desires for
reasonable efficiency and expressive
power, the size constraint has
encouraged not only economy but a
certain elegance of design.

         Dennis Ritchie and Ken Thompson
          "The UNIX Time-Sharing System", CACM
This is the Unix philosophy: Write
programs that do one thing and do
it well. Write programs to work
together. Write programs to handle
text streams, because that is a
universal interface.



                        Doug McIlroy
Worse is better, for better or for worse - Kevlin Henney
True architectural style
does not come from a
conscious effort to create
a particular look. It
results obliquely — even
accidentally — out of a
holistic process.
Worse is better, for better or for worse - Kevlin Henney
Stewart Brand, How Buildings Learn
 See also http://www.laputan.org/mud/
When a design decision
can reasonably go one of
two ways, an architect
needs to take a step back.
Instead of trying to decide
between options A and B,
the question becomes
"How do I design so that
the choice between A and
B is less significant?" The
most interesting thing is not
actually the choice
between A and B, but the
fact that there is a choice
between A and B.

                   Kevlin Henney
     "Use Uncertainty As a Driver"
Properly gaining control
of the design process
tends to feel like one is
losing control of the
design process.
The classic essay on
"worse is better" is
either misunderstood
or wrong.


                Jim Waldo
Decide for yourselves.




           Richard P Gabriel

More Related Content

Similar to Worse is better, for better or for worse - Kevlin Henney

Worse Is Better, for Better or for Worse
Worse Is Better, for Better or for WorseWorse Is Better, for Better or for Worse
Worse Is Better, for Better or for Worse
Kevlin Henney
 
Old Is the New New
Old Is the New NewOld Is the New New
Old Is the New New
Kevlin Henney
 
Worse Is Better, for Better or for Worse
Worse Is Better, for Better or for WorseWorse Is Better, for Better or for Worse
Worse Is Better, for Better or for Worse
Kevlin Henney
 
ADC-BSC EAST 2013 Keynote: Worse Is Better—For Better or for Worse
ADC-BSC EAST 2013 Keynote: Worse Is Better—For Better or for WorseADC-BSC EAST 2013 Keynote: Worse Is Better—For Better or for Worse
ADC-BSC EAST 2013 Keynote: Worse Is Better—For Better or for Worse
TechWell
 
Worse Is Better, for Better or for Worse
Worse Is Better, for Better or for WorseWorse Is Better, for Better or for Worse
Worse Is Better, for Better or for Worse
Kevlin Henney
 
Week 4 Assignment - Software Development PlanScenario-Your team has be.docx
Week 4 Assignment - Software Development PlanScenario-Your team has be.docxWeek 4 Assignment - Software Development PlanScenario-Your team has be.docx
Week 4 Assignment - Software Development PlanScenario-Your team has be.docx
estefana2345678
 
Effective Java
Effective JavaEffective Java
Effective Java
Brice Argenson
 
The Taming Of The Code
The Taming Of The CodeThe Taming Of The Code
The Taming Of The Code
Alan Stevens
 
Excavating the knowledge of our ancestors
Excavating the knowledge of our ancestorsExcavating the knowledge of our ancestors
Excavating the knowledge of our ancestors
Uwe Friedrichsen
 
Oopp Lab Work
Oopp Lab WorkOopp Lab Work
Oopp Lab Work
Heather Dionne
 
Life & Work of Butler Lampson | Turing100@Persistent
Life & Work of Butler Lampson | Turing100@PersistentLife & Work of Butler Lampson | Turing100@Persistent
Life & Work of Butler Lampson | Turing100@Persistent
Persistent Systems Ltd.
 
DevOps - Introduction to data science
DevOps - Introduction to data scienceDevOps - Introduction to data science
DevOps - Introduction to data science
Frank Kienle
 
Designing A Project Using Java Programming
Designing A Project Using Java ProgrammingDesigning A Project Using Java Programming
Designing A Project Using Java Programming
Katy Allen
 
The UNIX philosophy
The UNIX philosophyThe UNIX philosophy
The UNIX philosophy
Kevin Maiyo
 
Visualization of Complex Systems
Visualization of Complex SystemsVisualization of Complex Systems
Visualization of Complex Systems
Chris Laffra
 
Shamsa altayer
Shamsa altayerShamsa altayer
Shamsa altayer
shamsaot
 
DockerCon SF 2015: Keynote Day 1
DockerCon SF 2015: Keynote Day 1DockerCon SF 2015: Keynote Day 1
DockerCon SF 2015: Keynote Day 1
Docker, Inc.
 
5 Design Patterns Explained
5 Design Patterns Explained5 Design Patterns Explained
5 Design Patterns Explained
Prabhjit Singh
 
ADUF - Adaptable Design Up Front
ADUF -  Adaptable Design Up FrontADUF -  Adaptable Design Up Front
ADUF - Adaptable Design Up Front
Hayim Makabee
 
Jun 08 - PMWT Featured Paper -Tarabykin - XP PAPER - FINAL
Jun 08 - PMWT Featured Paper -Tarabykin - XP PAPER - FINALJun 08 - PMWT Featured Paper -Tarabykin - XP PAPER - FINAL
Jun 08 - PMWT Featured Paper -Tarabykin - XP PAPER - FINAL
Alex Tarra
 

Similar to Worse is better, for better or for worse - Kevlin Henney (20)

Worse Is Better, for Better or for Worse
Worse Is Better, for Better or for WorseWorse Is Better, for Better or for Worse
Worse Is Better, for Better or for Worse
 
Old Is the New New
Old Is the New NewOld Is the New New
Old Is the New New
 
Worse Is Better, for Better or for Worse
Worse Is Better, for Better or for WorseWorse Is Better, for Better or for Worse
Worse Is Better, for Better or for Worse
 
ADC-BSC EAST 2013 Keynote: Worse Is Better—For Better or for Worse
ADC-BSC EAST 2013 Keynote: Worse Is Better—For Better or for WorseADC-BSC EAST 2013 Keynote: Worse Is Better—For Better or for Worse
ADC-BSC EAST 2013 Keynote: Worse Is Better—For Better or for Worse
 
Worse Is Better, for Better or for Worse
Worse Is Better, for Better or for WorseWorse Is Better, for Better or for Worse
Worse Is Better, for Better or for Worse
 
Week 4 Assignment - Software Development PlanScenario-Your team has be.docx
Week 4 Assignment - Software Development PlanScenario-Your team has be.docxWeek 4 Assignment - Software Development PlanScenario-Your team has be.docx
Week 4 Assignment - Software Development PlanScenario-Your team has be.docx
 
Effective Java
Effective JavaEffective Java
Effective Java
 
The Taming Of The Code
The Taming Of The CodeThe Taming Of The Code
The Taming Of The Code
 
Excavating the knowledge of our ancestors
Excavating the knowledge of our ancestorsExcavating the knowledge of our ancestors
Excavating the knowledge of our ancestors
 
Oopp Lab Work
Oopp Lab WorkOopp Lab Work
Oopp Lab Work
 
Life & Work of Butler Lampson | Turing100@Persistent
Life & Work of Butler Lampson | Turing100@PersistentLife & Work of Butler Lampson | Turing100@Persistent
Life & Work of Butler Lampson | Turing100@Persistent
 
DevOps - Introduction to data science
DevOps - Introduction to data scienceDevOps - Introduction to data science
DevOps - Introduction to data science
 
Designing A Project Using Java Programming
Designing A Project Using Java ProgrammingDesigning A Project Using Java Programming
Designing A Project Using Java Programming
 
The UNIX philosophy
The UNIX philosophyThe UNIX philosophy
The UNIX philosophy
 
Visualization of Complex Systems
Visualization of Complex SystemsVisualization of Complex Systems
Visualization of Complex Systems
 
Shamsa altayer
Shamsa altayerShamsa altayer
Shamsa altayer
 
DockerCon SF 2015: Keynote Day 1
DockerCon SF 2015: Keynote Day 1DockerCon SF 2015: Keynote Day 1
DockerCon SF 2015: Keynote Day 1
 
5 Design Patterns Explained
5 Design Patterns Explained5 Design Patterns Explained
5 Design Patterns Explained
 
ADUF - Adaptable Design Up Front
ADUF -  Adaptable Design Up FrontADUF -  Adaptable Design Up Front
ADUF - Adaptable Design Up Front
 
Jun 08 - PMWT Featured Paper -Tarabykin - XP PAPER - FINAL
Jun 08 - PMWT Featured Paper -Tarabykin - XP PAPER - FINALJun 08 - PMWT Featured Paper -Tarabykin - XP PAPER - FINAL
Jun 08 - PMWT Featured Paper -Tarabykin - XP PAPER - FINAL
 

More from JAX London

Everything I know about software in spaghetti bolognese: managing complexity
Everything I know about software in spaghetti bolognese: managing complexityEverything I know about software in spaghetti bolognese: managing complexity
Everything I know about software in spaghetti bolognese: managing complexity
JAX London
 
Devops with the S for Sharing - Patrick Debois
Devops with the S for Sharing - Patrick DeboisDevops with the S for Sharing - Patrick Debois
Devops with the S for Sharing - Patrick Debois
JAX London
 
Busy Developer's Guide to Windows 8 HTML/JavaScript Apps
Busy Developer's Guide to Windows 8 HTML/JavaScript AppsBusy Developer's Guide to Windows 8 HTML/JavaScript Apps
Busy Developer's Guide to Windows 8 HTML/JavaScript Apps
JAX London
 
It's code but not as we know: Infrastructure as Code - Patrick Debois
It's code but not as we know: Infrastructure as Code - Patrick DeboisIt's code but not as we know: Infrastructure as Code - Patrick Debois
It's code but not as we know: Infrastructure as Code - Patrick Debois
JAX London
 
Locks? We Don't Need No Stinkin' Locks - Michael Barker
Locks? We Don't Need No Stinkin' Locks - Michael BarkerLocks? We Don't Need No Stinkin' Locks - Michael Barker
Locks? We Don't Need No Stinkin' Locks - Michael Barker
JAX London
 
Java performance: What's the big deal? - Trisha Gee
Java performance: What's the big deal? - Trisha GeeJava performance: What's the big deal? - Trisha Gee
Java performance: What's the big deal? - Trisha Gee
JAX London
 
Clojure made-simple - John Stevenson
Clojure made-simple - John StevensonClojure made-simple - John Stevenson
Clojure made-simple - John Stevenson
JAX London
 
HTML alchemy: the secrets of mixing JavaScript and Java EE - Matthias Wessendorf
HTML alchemy: the secrets of mixing JavaScript and Java EE - Matthias WessendorfHTML alchemy: the secrets of mixing JavaScript and Java EE - Matthias Wessendorf
HTML alchemy: the secrets of mixing JavaScript and Java EE - Matthias Wessendorf
JAX London
 
Play framework 2 : Peter Hilton
Play framework 2 : Peter HiltonPlay framework 2 : Peter Hilton
Play framework 2 : Peter Hilton
JAX London
 
Complexity theory and software development : Tim Berglund
Complexity theory and software development : Tim BerglundComplexity theory and software development : Tim Berglund
Complexity theory and software development : Tim Berglund
JAX London
 
Why FLOSS is a Java developer's best friend: Dave Gruber
Why FLOSS is a Java developer's best friend: Dave GruberWhy FLOSS is a Java developer's best friend: Dave Gruber
Why FLOSS is a Java developer's best friend: Dave Gruber
JAX London
 
Akka in Action: Heiko Seeburger
Akka in Action: Heiko SeeburgerAkka in Action: Heiko Seeburger
Akka in Action: Heiko Seeburger
JAX London
 
NoSQL Smackdown 2012 : Tim Berglund
NoSQL Smackdown 2012 : Tim BerglundNoSQL Smackdown 2012 : Tim Berglund
NoSQL Smackdown 2012 : Tim Berglund
JAX London
 
Closures, the next "Big Thing" in Java: Russel Winder
Closures, the next "Big Thing" in Java: Russel WinderClosures, the next "Big Thing" in Java: Russel Winder
Closures, the next "Big Thing" in Java: Russel Winder
JAX London
 
Java and the machine - Martijn Verburg and Kirk Pepperdine
Java and the machine - Martijn Verburg and Kirk PepperdineJava and the machine - Martijn Verburg and Kirk Pepperdine
Java and the machine - Martijn Verburg and Kirk Pepperdine
JAX London
 
Mongo DB on the JVM - Brendan McAdams
Mongo DB on the JVM - Brendan McAdamsMongo DB on the JVM - Brendan McAdams
Mongo DB on the JVM - Brendan McAdams
JAX London
 
New opportunities for connected data - Ian Robinson
New opportunities for connected data - Ian RobinsonNew opportunities for connected data - Ian Robinson
New opportunities for connected data - Ian Robinson
JAX London
 
HTML5 Websockets and Java - Arun Gupta
HTML5 Websockets and Java - Arun GuptaHTML5 Websockets and Java - Arun Gupta
HTML5 Websockets and Java - Arun Gupta
JAX London
 
The Big Data Con: Why Big Data is a Problem, not a Solution - Ian Plosker
The Big Data Con: Why Big Data is a Problem, not a Solution - Ian PloskerThe Big Data Con: Why Big Data is a Problem, not a Solution - Ian Plosker
The Big Data Con: Why Big Data is a Problem, not a Solution - Ian Plosker
JAX London
 
Bluffers guide to elitist jargon - Martijn Verburg, Richard Warburton, James ...
Bluffers guide to elitist jargon - Martijn Verburg, Richard Warburton, James ...Bluffers guide to elitist jargon - Martijn Verburg, Richard Warburton, James ...
Bluffers guide to elitist jargon - Martijn Verburg, Richard Warburton, James ...
JAX London
 

More from JAX London (20)

Everything I know about software in spaghetti bolognese: managing complexity
Everything I know about software in spaghetti bolognese: managing complexityEverything I know about software in spaghetti bolognese: managing complexity
Everything I know about software in spaghetti bolognese: managing complexity
 
Devops with the S for Sharing - Patrick Debois
Devops with the S for Sharing - Patrick DeboisDevops with the S for Sharing - Patrick Debois
Devops with the S for Sharing - Patrick Debois
 
Busy Developer's Guide to Windows 8 HTML/JavaScript Apps
Busy Developer's Guide to Windows 8 HTML/JavaScript AppsBusy Developer's Guide to Windows 8 HTML/JavaScript Apps
Busy Developer's Guide to Windows 8 HTML/JavaScript Apps
 
It's code but not as we know: Infrastructure as Code - Patrick Debois
It's code but not as we know: Infrastructure as Code - Patrick DeboisIt's code but not as we know: Infrastructure as Code - Patrick Debois
It's code but not as we know: Infrastructure as Code - Patrick Debois
 
Locks? We Don't Need No Stinkin' Locks - Michael Barker
Locks? We Don't Need No Stinkin' Locks - Michael BarkerLocks? We Don't Need No Stinkin' Locks - Michael Barker
Locks? We Don't Need No Stinkin' Locks - Michael Barker
 
Java performance: What's the big deal? - Trisha Gee
Java performance: What's the big deal? - Trisha GeeJava performance: What's the big deal? - Trisha Gee
Java performance: What's the big deal? - Trisha Gee
 
Clojure made-simple - John Stevenson
Clojure made-simple - John StevensonClojure made-simple - John Stevenson
Clojure made-simple - John Stevenson
 
HTML alchemy: the secrets of mixing JavaScript and Java EE - Matthias Wessendorf
HTML alchemy: the secrets of mixing JavaScript and Java EE - Matthias WessendorfHTML alchemy: the secrets of mixing JavaScript and Java EE - Matthias Wessendorf
HTML alchemy: the secrets of mixing JavaScript and Java EE - Matthias Wessendorf
 
Play framework 2 : Peter Hilton
Play framework 2 : Peter HiltonPlay framework 2 : Peter Hilton
Play framework 2 : Peter Hilton
 
Complexity theory and software development : Tim Berglund
Complexity theory and software development : Tim BerglundComplexity theory and software development : Tim Berglund
Complexity theory and software development : Tim Berglund
 
Why FLOSS is a Java developer's best friend: Dave Gruber
Why FLOSS is a Java developer's best friend: Dave GruberWhy FLOSS is a Java developer's best friend: Dave Gruber
Why FLOSS is a Java developer's best friend: Dave Gruber
 
Akka in Action: Heiko Seeburger
Akka in Action: Heiko SeeburgerAkka in Action: Heiko Seeburger
Akka in Action: Heiko Seeburger
 
NoSQL Smackdown 2012 : Tim Berglund
NoSQL Smackdown 2012 : Tim BerglundNoSQL Smackdown 2012 : Tim Berglund
NoSQL Smackdown 2012 : Tim Berglund
 
Closures, the next "Big Thing" in Java: Russel Winder
Closures, the next "Big Thing" in Java: Russel WinderClosures, the next "Big Thing" in Java: Russel Winder
Closures, the next "Big Thing" in Java: Russel Winder
 
Java and the machine - Martijn Verburg and Kirk Pepperdine
Java and the machine - Martijn Verburg and Kirk PepperdineJava and the machine - Martijn Verburg and Kirk Pepperdine
Java and the machine - Martijn Verburg and Kirk Pepperdine
 
Mongo DB on the JVM - Brendan McAdams
Mongo DB on the JVM - Brendan McAdamsMongo DB on the JVM - Brendan McAdams
Mongo DB on the JVM - Brendan McAdams
 
New opportunities for connected data - Ian Robinson
New opportunities for connected data - Ian RobinsonNew opportunities for connected data - Ian Robinson
New opportunities for connected data - Ian Robinson
 
HTML5 Websockets and Java - Arun Gupta
HTML5 Websockets and Java - Arun GuptaHTML5 Websockets and Java - Arun Gupta
HTML5 Websockets and Java - Arun Gupta
 
The Big Data Con: Why Big Data is a Problem, not a Solution - Ian Plosker
The Big Data Con: Why Big Data is a Problem, not a Solution - Ian PloskerThe Big Data Con: Why Big Data is a Problem, not a Solution - Ian Plosker
The Big Data Con: Why Big Data is a Problem, not a Solution - Ian Plosker
 
Bluffers guide to elitist jargon - Martijn Verburg, Richard Warburton, James ...
Bluffers guide to elitist jargon - Martijn Verburg, Richard Warburton, James ...Bluffers guide to elitist jargon - Martijn Verburg, Richard Warburton, James ...
Bluffers guide to elitist jargon - Martijn Verburg, Richard Warburton, James ...
 

Worse is better, for better or for worse - Kevlin Henney

  • 1. Worse Is Better, for Better or for Worse @KevlinHenney
  • 4. In 1990 I proposed a theory, called Worse Is Better, of why software would be more likely to succeed if it was developed with minimal invention.
  • 5. It is far better to have an underfeatured product that is rock solid, fast, and small than one that covers what an expert would consider the complete requirements.
  • 6. Simplicity: The design is simple in implementation. The interface should be simple, but anything adequate will do.  Completeness: The design covers only necessary situations. Completeness can be sacrificed in favor of any other quality.  Correctness: The design is correct in all observable aspects.  Consistency: The design is consistent as far as it goes. Consistency is less of a problem because you always choose the smallest scope for the first implementation.
  • 7. Implementation characteristics are foremost:  The implementation should be fast.  It should be small.  It should interoperate with the programs and tools that the expected users are already using.  It should be bug-free, and if that requires implementing fewer features, do it.  It should use parsimonious abstractions as long as they don’t get in the way.
  • 8. #!/usr/bin/perl # -------------------------------------------------------- PerlInterpreter # PerlInterpreter must be the first line of the file. # # Copyright (c) 1995, Cunningham & Cunningham, Inc. # # This program has been generated by the HyperPerl # generator. The source hypertext can be found # at http://c2.com/cgi/wikibase. This program belongs # to Cunningham & Cunningham, Inc., is to be used # only by agreement with the owner, and then only # with the understanding that the owner cannot be # responsible for any behaviour of the program or # any damages that it may cause. # -------------------------------------------------------- InitialComments # InitialComments print "Content-type: text/htmlnn"; $DBM = "/usr/ward/$ScriptName"; dbmopen(%db, $DBM , 0666) | &AbortScript("can't open $DBM"); $CookedInput{browse} && &HandleBrowse; $CookedInput{edit} && &HandleEdit; $CookedInput{copy} && &HandleEdit; $CookedInput{links} && &HandleLinks; $CookedInput{search} && &HandleSearch; dbmclose (%db); if ($ENV{REQUEST_METHOD} eq POST) { $CookedInput{post} && &HandlePost; } # &DumpBinding(*CookedInput); # &DumpBinding(*old); # &DumpBinding(*ENV); # -------------------------------------------------------- WikiInHyperPerl
  • 13. In a purist view of object-oriented methodology, dynamic dispatch is the only mechanism for taking advantage of attributes that have been forgotten by subsumption. This position is often taken on abstraction grounds: no knowledge should be obtainable about objects except by invoking their methods. In the purist approach, subsumption provides a simple and effective mechanism for hiding private attributes.
  • 14. OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. Alan Kay
  • 15. One of the most pure object-oriented programming models yet defined is the Component Object Model (COM). It enforces all of these principles rigorously. Programming in COM is very flexible and powerful as a result. There is no built-in notion of equality. There is no way to determine if an object is an instance of a given class. William Cook "On Understanding Data Abstraction, Revisited"
  • 16. William Cook, "On Understanding Data Abstraction, Revisited"
  • 17. newStack =   (let items = ref()  { isEmpty =   #items = 0, depth =   #items, push =  x  items := xˆitemsy  y  0...#items, top =   items0 })
  • 20. var newStack = function() { var items = [] return { isEmpty: function() { return items.length === 0 }, depth: function() { return items.length }, push: function(newTop) { items = items.unshift(newTop) }, top: function() { return items[0] } } }
  • 21. Any application that can be written in JavaScript, will eventually be written in JavaScript. Atwood's Law
  • 24. There have always been fairly severe size constraints on the Unix operating system and its software. Given the partially antagonistic desires for reasonable efficiency and expressive power, the size constraint has encouraged not only economy but a certain elegance of design. Dennis Ritchie and Ken Thompson "The UNIX Time-Sharing System", CACM
  • 25. This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. Doug McIlroy
  • 27. True architectural style does not come from a conscious effort to create a particular look. It results obliquely — even accidentally — out of a holistic process.
  • 29. Stewart Brand, How Buildings Learn See also http://www.laputan.org/mud/
  • 30. When a design decision can reasonably go one of two ways, an architect needs to take a step back. Instead of trying to decide between options A and B, the question becomes "How do I design so that the choice between A and B is less significant?" The most interesting thing is not actually the choice between A and B, but the fact that there is a choice between A and B. Kevlin Henney "Use Uncertainty As a Driver"
  • 31. Properly gaining control of the design process tends to feel like one is losing control of the design process.
  • 32. The classic essay on "worse is better" is either misunderstood or wrong. Jim Waldo
  • 33. Decide for yourselves. Richard P Gabriel