Barbara Liskov came to give her Turing Award lecture today and maybe its just me, but I thought she was awesome. If she somehow winds up reading this:
Thank you for coming and
thank you for speaking with me after
I was the guy with the striped button up and the horrible facial hair.
She said a lot of things with what seemed to me a lot of merit but I wanted to pick a couple of them out here so I don' forget them. Before I do though, remember that these are my words and while they are based on what (I remember) she said:
I could be misrepresenting her.
That being said, here we go!
Failure exceptions!
There are two main kinds of exceptions:
- Exceptions that are handled (recovery actions are taken)
- Exceptions that are propagated (exception is thrown up the stack)
But there is also a 3rd class of exceptions: those that are
unexpected. Programs need to be able to recover from these exceptions and often, in more traditional exception systems, doing so is either ugly or impossible.
By grouping all unexpected exceptions together under a
failure exception a language can be designed to handle execution failure gracefully.
Inheritance is not Useful
In the middle of the talk she made the interesting statement that she didn't think that inheritance was very useful or interesting. After the talk I asked her why and while I can't recall her reasoning at the moment she did respond with roughly the following:
"
Instead of having inheritance, give the object a pointer to a different object which has the methods you wish to inherit."
I'm not entirely clear on her meaning and rational here and was unable to clarify with respect for the questions that others had but
I think it came down to two things:
- Preservation of Object Encapsulation
- Clear separation from Type Hierarchies
Inheritance tends to mix code reuse and type hierarchies together in ways that can work counter to expectations; particularly when you allow method overriding (I'm sure she had other things in mind). Additionally, through this indirection, I think that she intended that encapsulation of the "component" objects be preserved. She was very consistent that she believed encapsulation should not be broken for any reason and that doing so likely introduced flaws and side effects.
Type Hierarchies Are Useful
On the other hand, she believes that type hierarchies are very useful in allowing abstraction of types on the programming level as well. This came up several times in her talk and she stuck to her guns.
After the talk she pointed to Java Interfaces as an example (perhaps not the ideal one though) of type hierarchies as separate from inheritance and code reuse and reaffirmed that she believed this separation to be quite important.
Reflection is Considered a Shortfall
The subjects of duck typing and programming by convention came up after the talk and she flat out called reflection as horrible. Reflection breaks the encapsulation of the objects and using it represents a shortcoming of the language that you are programming in. This said in the sense that if the language were properly designed to do what you are trying to do, reflection would be substituted for a more robust typing system.
Instead of reflected at runtime, such duck typing should be statically determined through explicit type hierarchies.These static type hierarchies can be resolved at compile time with static analysis, which she believe to be a fundamental advantage as well.
I have some reservations regarding this point. Mostly because I can't figure out how a language could be designed to allow me to, for example, call all methods of a given object that begin with test**********. On the other hand, maybe it can't be done and it instead reflects poor program design. Hrm.
Syntactic Change Considered Harmful
Simply put: Ease of reading programs must take precedence over ease of writing programs. It therefore follows that in order for reading to be easy, syntax must be consistent. In appearance, but more importantly in meaning. She believes that while being able to change the syntax of the language you are programming in while you are programming it maybe seductive, you will almost always regret it later. Certainly others who read your code will.
Wrapping it up
So anyway, I found her perspective quite thought provoking and talking with her after gave me some new perspectives. I'm unsure on my own opinions regarding some of her statements but I am glad that she came to RPI and shared them with me.
Processing turned the 1000 files into about 4200 documents with an average processing time of ~13 milliseconds per file and ~3 milliseconds per document. Its should be noted that this is on my VBox with 700MB general memory while running Eclipse and Firefox. In general, these averages are skewed high by several outliers; all documents with long, many page texts. Such expansive texts appear to create significant bottlenecks in the XML parsing.
