Sun has an interview of Victoria Livschitz a senior IT architect and Java Evangelist. In the interview Victoria discusses her opinions on the state of programming with respect to software complexity and how we deal with it. She has a lot of interesting strong opinions on the subject, including her thoughts on weaknesses of the OO approach.
"In object-oriented systems, "object" is the one and only basic abstraction. The universe always gets reduced to a set of pre-defined object classes, some of which are structural supersets of others. The simplicity of this model is both its blessing and its curse. Einstein once noted that an explanation should be as simple as possible, but no simpler. This is a remarkably subtle point that is often overlooked. Explaining the world through a collection of objects is just too simple! The world is richer than what can be expressed with object-oriented syntax.
Consider a few common concepts that people universally use to understand and describe all systems -- concepts that do not fit the object mold. The "before/after" paradigm, as well that of "cause/effect," and the notion of the "state of the system" are amongst the most vivid examples. Indeed, the process of "brewing coffee," or "assembling a vehicle," or "landing a rover on Mars" cannot be decomposed into simple objects. Yes, they are being treated that way in OO languages, but that's contrived and counter-intuitive. The sequence of the routine itself -- what comes before what under what conditions based on what causality -- simply has no meaningful representation in OO, because OO has no concept of sequencing, or state, or cause."
Her advice to us:
"Don't take everything you've been told about good software engineering as gospel truth. Don't be bamboozled. Maintain your sense of skepticism and look for more intuitive metaphors."
Read The Next Move in Programming: A Conversation with Sun's Victoria Livschitz
Also read Coding from Scratch: A Conversation with Virtual Reality Pioneer Jaron Lanier, Part One
, which Victoria talks about, and is interesting in its own right!
From the article:
"Those mechanisms breed complexity as they try to compensate for the inherent time-invariant deficiency in OO programming. Instead, the problem should be addressed at the root by allowing process-specific constructs, such as "before/after," "cause/effect," and, perhaps, "system state" to be a core part of the language."
The "process-specific constructs" she is talking about would seem to be addressed by AOP. Or is she talking about something different (other than cross cutting concerns)?
I found this article surprisingly good. It is comforting to know that Sun still has bright software people that can think above "Middleware is dead" level of complexity.
I think what Victoria is alluding to can be demonstrated if you consider evolution of, for example, Java or C#. In these modern OOP languages we have many language-level constructs that deal with things like threading, collections, events, metadata, parameterized types all the things that are not specifically OOP-related and taken almost for granted today but the things that were a lot more laborious to deal with 15-20 years ago. None of them are breakthroughs and some may be considered as a syntactic sugar but if done properly they do reduce the complexity thus leading to reduction of errors during design/implementation phases.
So I would agree with author that is rather natural to expect that we are going to see more such language-level constructs into OOP languages to further reduce complexity in certain areas.
xTier - Service Oriented Middleware
"The work so far has been promising." That certainly makes me curious: are these things being implemented? I'd surely want to see some early examples...!!
The article by Jaron Lanier is very exciting too: I always felt that the emergence of Linux as fresh new kid on the block in OS's was a bit of a letdown since Linux mostly reimplements the Unix notions ('everything is a file') that were innovative in the sixties. (See Eric Raymonds The Art of Unix Programming forhttp://www.catb.org/~esr/writings/taoup/html/ch20s03.html
>a list of problems in the design of Unix</a>.) So a radically new OS would be interesting. Ofcourse it would take years before it would reach a state where you could do anything useful with it since the whole stack would have to be redesigned from scratch.
The thing with Jaron's remarks is: are they being implemented?
I seem to recall that there was a hint that Bill Joy might be working on a clean slate rethinking of what an operating system is. If true that would also be eagerly awaited...
Very good article. I fear SUN would end up like Xerox PARC in creating exciting new technologies and some body else benefit from it..
Uhh... I think she's misunderstood object-orientation. I don't mean that OO is perfect or doesn't need "fixing" (I am after all part of the AOP movement) but saying that there is no way of modelling "casuality", dynamics or "system state" in OO languages seems very confused.
After all, oo languages doesn't only consists of a static structure where we model objects and their relationsships, it also consists of behaviour and a dynamic structure where the objects interact with eachother. Isn't this very thing that is often mentioned as the most powerful part of oo that you can modularize state *and* behaviour? (and, alas! also one of it's major deficits that AOP is trying to "fix")
That's strange, I blogged on Saturday, exactly the same subject matter:
Well I guess we have the same sources!
Very nice interview, thanks.
I agree with this article. Yes, we need a faster upgrade to the *language* itself and not always put more and more libraries. The integration of AspectJ in Java language would be the first step.
Anyway, it would be cool if I can have a Hierarchy and Network Collection class in Java, in which I can describe a hierarchy and network relationship easily. Until now I can only describe a simple relationship within a Collection. Is there any plan to add something like this? Or is there any Open Source implementations on this (Jakarta Common?).
I do agree that both state and sequence are totally lost on an object oriented system. However I don't think OO is the problem per se. I think that OO hasn't progressed in a considerable time.
Like the AspectJ concept of separation of concerns, OO has been split by patterns and J2EE in the same manner. There are objects that serve only to contain data. There are objects that serve only to act on data. Finally there are some in the middle. Some super-geek needs to define a system to manage this scenario as it happens all the time.
Something else along these lines is that certain functions should have a consistent mechanism to service calls. Such an example is how MS .NET class/method meta tags modify and reference class structures to perform web services, Unit testing, etc.
It makes me want to puke, but almost everything in .NET makes more sense. To some degree, Vitoria's article eludes to this concept of "intuitive" structure flow for programmers.
"It's not the prevention of bugs but the recovery -- the ability to gracefully exterminate them -- that counts." - quote from VLivschitz.
I totally disagree with this one. Martin Fowler makes a strong case for finding bugs early. When applied to her interview, the point here is that since you don't know state and sequence, testing up front to meet a contract is the way to go, and I've had great success with this. However the flip side is that OO needs a test oriented design system. There needs to be a mechanism to intuitively bind test methods with the target classes & methods, and the test class needs access to normally restricted methods & classes. In essence, test maintenance becomes a pain, especially when refactoring. Move a class to a different package, and you need to move test cases as well.
I sometimes wonder if SUN ever has contact to the real world of the day to day developer. It seems like their head is in the sand.
I think Victoria's interview is interesting and that the issues that she addresses are the ones that are most important in defining the future direction in software. I have a few comments -
1. Increased type safety does is not a neccessity for better code. A few years I worked on a large Smalltalk project and the problems were not type safety - even with most of the team having no experience of Smalltalk. One tradeoff for increased type safety is decreased polymorphism. I also have a strong suspicion - although I don't have the mathematical capability to prove it - that if you understand the parameters that cross the edges of your system you can 'typecheck' the entire system. However I do agree that exception handling as implemented in Java is an important new addition to the arsenal.
2. The primary problem in software development is the disconnect between requirements and implementation. We need a quicker route from requirements to design - we seem to have made some gains in code generation based on the more mundane elements of design - but we need more on encapsulating 'business logic' (for want of a better phrase). But this isn't just about understanding, time plays its part as well - the requirements in one year when you plan will not be those that are most important in the year when you deliver. You can plan around this by making risk assessments of those areas most likely to change and making part of your requirements the ability to ease/automate the process of change in these areas. By the way the requirements issue has not been adequately addressed in Architecture - which has been around for a lot longer than software - but there is at least a common language and perception that allows the consumer of an architects services to see the more obvious of the architects problems - for example if your house is nearly completed and you tell the architect that you'd like to move the stair - you will understand that your house will take quite a lot longer complete and be a fair bit more expensive. The counter situation arises in software where a client indicates (three days before delivery) that they'd actually like to base all their indexing on the customers phone number rather than their social security number - there is sometimes difficulty in explaining the consequences of this action to the client.
3. We also need the concept of 'tolerance' in software. At the moment you can buy a 10mm bolt in one place and a 10mm nut in another and the nut will fit on the bolt. May be not well but well enough to hold something together that doesn't have much strain on it. If you have a particularly stressed situation you may want to buy specialist nut/bolt pairs whose tolerance is guaranteed and which will fit together much more snugly and will be able to take the higher strain imposed. We don't yet have a notion of tolerance on our software interfaces - I think this is a problem that it will take some ingenuity to solve but I don't think that it's insoluble - quite simply because workable component-based systems will require this feature.
4. I share Victoria's view on languages. What surprises me at the moment is that after 20 years in the business for the first time I can't see the next new language on the horizon. Java is nearly everywhere (and COBOL is still virtually everywhere else!). Eiffel which promised to be the root language of component-based programming (as Smalltalk was for OO) does not appear to be influencing any contenders for component-based language of the future. When Smalltalk was around in the 80s and 90's before the OO-rush people understood and accepted the technical benefits of OO - their criticisms were based on performance, lack of trained staff , cost, application size etc but not the fundamental technology. At present we don't even seem to have a 'precursor' language that we can use as an Aunt Sally to bounce ideas off!
Personally I think that a partial solution might look something like the .NET, where you should be able to use many languages in the same projects easily. Of course this is does not help if the languages all look the same (like C++/C#/VB/Java). What I'm hoping is that someday somebody produces .NET versions of languages like Prolog or Lisp and I can write for example business logic in Prolog and webui related things with Java or C#.
IBM looked at this before - the VisualAge family of languages was to write to a common virtual machine - languages included Smalltalk, C++, Java (and I think COBOL!). As far as I know this did eventually work but when the VisualAge product line terminated I suspect this was canned.
Language interoperability is a great goal on paper but I suspect its like platform independence - everybody wants it but only a small minority actually end up using it.