Barbara Liskov, the Power of Abstraction
OOPSLA 2009 opened with Barbara Liskov as the keynote speaker. She is famous for, among others, the Liskov Substitution Principle. This principle states that:
A subtype should be substitutable for its super-type.
That is, it should be possible to use a subtype in the same way as if the type itself was used. Any difference in behavior should NOT be noticeable to the client.
A History of Abstract Data Types
Data abstraction was developed as a solution to the software crisis. A crises that is just as present today as it was then. This was in 1968, the time when Dijkstra wrote the paper Go To Statement Considered Harmful. The problem with gotos is that it is difficult to know the context in which a statement is used.
Other important papers at the time were. Nicholaus Wirth's paper Program Development by Stepwise Refinement on 1971, about top-down design and David Parnas' paper Information Distribution Aspect of Design Methodology in which he stated.
The connections between the modules are the assumptions which the modules make about each other.
These assumptions are often much more than the simple interfaces that we see today. It includes the whole context in which the module is used.
Barbara then wrote a paper called A Design Methodology for Reliable Systems. The ideas from this paper was later reused in the context of programming. When seen from the outside it is apparent that the same technique she used when creating the Venus Operating System, Partition State, could be used when building programs but it was not at the time. Where do ideas come from? Perhaps the time is just right.
Other influential papers that are still valid today are: Hierarchical Program Structures by Dahl and Hoare and Protection in Programming Languages by Morris, introduced the early ideas of encapsulation and Global Variable Considered Harmful by Shaw and Wulf.
In 1973, the paper on Abstract Data Types was published and Liskov the realized her ideas in CLU. Its worth noting that CLU was way ahead of its time. It included features, like data encapsulation, exceptions, iterators via yield but no inheritance. She doesn't think that inheritance is very important and that it complicates things.
The Liskov Substitution Principle didn't appear until 1983, when she held a speech here at OOSLA, when she had noticed that inheritance was used for two different things that was not very well understood. It is used for:
- Implementation inheritance, which violates encapsulation.
- Type Hierarchy, and this was not very well understood.
She ended up with noting that modularity based on abstraction is the way things are done now. It wasn't at the time.
She also pointed some challenges that still exist:
- New abstraction mechanisms
- Massive Parallel Computers
- MapReduce?
- Transactional Memory?
- Internet Computer
- Storage and computation
- Semantics, reliability, availability, security
And she also made the point that
Readable programs are much more important than writable programs.
When the questions were opened, it was interesting to note that among the questioners were Phil Wadler (Haskell), Andrew Black (Traits), Guy Steele (Scheme, Fortress), Dave Ungar (Self) and Ralph Johnsson (GoF).
Flapjax, a Programming Language for Ajax Applications
After Liskov's keynote I watched a presentation of a research paper about Flapjax, a language designed for web applications. It is based on event streams and the language itself is reactive. Flapjax is a Javascript-based language that can be used as a library.
The language introduces two new concepts Behaviors and Event Streams.
A behavior is a value that changes over time. It can be created like this.
// A variable that changes over time, every 100ms. var nowB = timerB(100);
What is interesting is that the behavior is composable with normal Javascript functions. This is done by compiling or transforming the Javascript into Flapjax code.
If an expression is a behavior, all expressions whose values depend on it also become behaviors.
var nowB = timerB(1000);
var startTm = nowB.valueNow();
var clickTmsB = $E("reset", "click").snapshotE(nowB).startsWith(startTm);
var elapsedB = nowB - clickTmsB;
insertValueB(elapsedB, "curTime", "innerHTML");
Programming with event streams is a little different from programming with behaviors. A behavior masquerades as an ordinary JavaScript object whose content just happens to change automatically. In contrast, an event stream is a new kind of value, with new primitives for programming over it.
Event streams and behaviors offer complementary views of the world. It is easy, however, to overstate their differences. Given an initial value, every event stream can be converted into a behavior: the behavior always has the value of the last event to have arrived on the stream, starting with the specified initial value until the first event arrives. Likewise, every behavior can be converted into an event stream: when the behavior's value changes, send the new value as an event.
Thomas W. Malone, Keynote Onward, the Future of Collective Intelligence
MIT Center for Collective Intelligence
Collective intelligence - Groups of individuals doing things collectively that seem intelligent.
Collective Stupidity is also very much existent.
New examples of collectively intelligence are: Google, the Web, Wikipedia, Linux, Digg, YouTube, etc.
How can people and computers be connected so that collectively they act more intelligently than any person, or computer?
Thomas showed a video of a crowd of people flying an airplane by turning a reflective shield green or red.
What are the genomes of collective intelligence?
Every activity has to answer four questions, Who? What? How? Why?
- There are two Who?-genes, crowd and hierarchical.
- There are three Why?-genes, money, glory and love.
- There are two What?-genes, create and decide.
- There are four How?-genes, collection (contest), collaboration, group decision (voting, consensus, averaging, prediction markets) and individual decision (market, social network).
Failure to get motivational factors (thw why?) right is probably the single greatest cause of failure in collective intelligence experiments.
Interesting examples are: Climate Collaboratorium, TopCoder, Kasparov vs. the World, Amazon Mechanical Turk and TurKit
What's coming?
Human Brain is very much like Global Network.
- We have global moods?
Quotes from We are the Web, Wired 2005
There is only one time in the history of each planet when its inhabitants first wire up its innumerable parts to make one large Machine.
Three thousand years from now, when keen minds review the past, this will be recognized as the largest, most complex, and most surprising event on the planet.
The Machine provided a new way of thinking (perfect search, total recall) and a new mind for an old species. It was the Beginning.
Brion Vibber, Wikipedia, Making your people run as smoothly as your site
As the number of people involved in a project grows, key decision-makers often become bottlenecks, and community structure needs to change or a project can become stalled despite the best intentions of all participants.
Instead of having a single admin looking at a page to decide if it is garbage, a group can vote if they think it is garbage. This allows the admin to delete pages without checking them first if everyone votes for deletion.
- People have limited time and patience.
- Waiting on other people is slow.
- People want to do what interests them, not deal with process!
Get out of peoples' way and let them do stuff!
Onward!
The Commenting Practice of Open Source, Oliver Arafat
An analysis of 80GB of Open Source code. The average code density is one comment per five lines of code or 19%.
Average comment density is independent of code size.
Strong variation by programming languages.
- Java code has an average of 26%.
- Perl code has an average of 11%.
Successful open source projects follow consistent comment practices.
Comment Density by Commit Size * Smaller commits have higher comment density.
Polymorphic System Architecture, Jeffery E Bryson
Run-Time polymorphism (RTP) has been used in the software community for two decades to satisfy dynamic reconfiguration, plug-n-play, extensibility, and system redundancy requirements. RTP is also used to construct software systems of systems. System engineers now have the same requirements applied to large-scale system architecture.
A Polymorphic System Architecture (PSA) uses the same technology, by applying it to the system architecture. By defining specific polymorphic relationship within the system architecture the system architect can reduce the system complexity and satisfy functional requirement.
Polymorphism reduces the code size, but it also reduces understandability.
Value Added
- Extendable/Reusable System Designs
- Dynamic reconfiguration
- An architecture that matures over time instead of becoming absolute.
- OO and Refactoring.
Conclusion
All in all, this was a good day with the keynotes being the highlights. The Onward sessions were interesting, but most of them, were of very little use to me.
No comments:
Post a Comment