Archive
The LSP
Objects of subtypes should behave like those of supertypes if used via supertype methods. – Barbara Liskov
Having learned the “Liskov Substitution Principle” as an object-oriented design aid many years ago, I was delighted to discover this video of Ms. Liskov accepting her Turing award in 2009: Barbara Liskov Lecture Video – A.M. Turing Award Winner.
If you don’t have the time to watch the hour long lecture by this extraordinary lady, but you’re curious to know more about Ms. Liskov, here are my notes:
- She “accidentally” entered programming.
- She created the CLU and ARGUS programming languages.
- “Let’s face it, in systems we write programs in C & C++ because efficiency really matters“.
- She was surprised that her paper on sub-types took off and her name became acronym-ized: “LSP”.
- She’s not a fan of DSLs or AOP because “readability is more important than writeability“.
- Abstract types, via encapsulation, were a boon to “reasoning about correctness“: understanding where you are in the code and how you got there.
- While creating CLU, she didn’t care about inheritance because it breaks encapsulation and makes “reasoning about correctness” more difficult. She simply used composition and called the methods of child objects via delegation.
- Since she is a practitioner, she stayed away from theoretical work, e.g. polymorphic lambda calculus.
A Hoarrific Failure
Work started (on the 503 Mark II software system) with a team of fifteen programmers and the deadline for delivery was set some eighteen months ahead in March 1965.
Although I was still managerially responsible for the 503 Mark II software, I gave it less attention than the company’s new products and almost failed to notice when the deadline for its delivery passed without event.
The programmers revised their implementation schedules and a new delivery date was set some three months ahead in June 1965. Needless to say, that day also passed without event.
I asked the senior programmers once again to draw up revised schedules, which again showed that the software could be delivered within another three months. I desperately wanted to believe it but I just could not. I disregarded the schedules and began to dig more deeply into the project.
The entire Elliott 503 Mark II software project had to be abandoned, and with it, over thirty man-years of programming effort, equivalent to nearly one man’s active working life, and I was responsible, both as designer and as manager, for wasting it.
The above story synopsis was extracted from Tony “Quicksort” Hoare‘s 1980-ACM Turing award lecture.
Mr. Hoare’s classic speech is the source of a few great quotes that have transcended time:
I conclude that 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…. No committee will ever do this until it is too late.
A feature which is included before it is fully understood can never be removed later.
At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success.
The price of reliability is the pursuit of the utmost simplicity. It is a price which the
very rich find most hard to pay.The mistakes which have been made in the last twenty years are being repeated today on an even grander scale. (1980)
Dontcha think that last quote can be restated today as:
The mistakes which have been made in the last fifty years are being repeated today on an even grander scale.
Since man’s ability to cope with complexity is relentlessly being dwarfed by his propensity to create ever greater complexity, the same statement might probably be true 50 years hence, no?
A Friction-Based Separation Of Concerns
Alan Kay is one of the inventors of the Smalltalk programming language and a Turing award winner. During an interview with Dr. Dobbs’s Andrew Binstock, Mr. Kay had this to say:
American business is completely fucked up because it is all about competition. Our world was built for the good from cooperation. – Alan Kay
From the moment we stepped foot into the classroom and received our first gold star, we’ve been brainwashed with the BS idea that separation from, and competition with, other individuals is good and noble. In school, collaboration on assignments and tests is akin to “cheating“. In business, subjective reward systems pit team mates against each other for money and stature.
At least in school, everyone knows what the score is. There is no group purpose, vision, or mission; it’s all about individual achievement relative to other individuals. In business, so-called leaders constantly cry out for team work and collaboration while keeping idiotic policies/processes/procedures/structures in place that guarantee a friction-based separation of concerns between individuals and groups within the org. The reason this counterproductive “behavior” will continue unabated ad infinitum is because all the players involved in the game simply take it for granted. To “us” (yes, that includes you and me), it’s simply the way it’s always been and it’s simply the way it always should be. This thinking malady is so acute that not many people even try to search for alternatives. Those poor souls that do, are often ostracized into silence.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 