ADVERTISEMENT

Dialog Box

By Scott T Boyd, Editor

Failure of OO Revolution?

On 6/5/94, vollrath@vax.ox.ac.uk wrote [in STA-FORUM@qks.com]:

I have been interested in Dylan since I first heard about it, although I have had little solid information until recently. I hope it does well, and am reasonably confident that it will. I certainly agree with its goals. I saw that in a recent edition of Byte they said that the OO ‘revolution’ had failed, but sang the virtues of Visual Basic. It hasn’t failed, it just hasn’t really started yet! All that has happened is that people that wrote in C now right in a more complicated C. ‘Real’ dynamic-OOLs that provide a good and convincing alternative to this haven’t really been around. Now, STA is one, Eiffel is one, and I think Dylan will be one. ... portions deleted...

Most of you know that we have so enhanced and extended Smalltalk’s capabilities/design in our Smalltalk product (SmalltalkAgents (STA)) that it is really another generation of the Smalltalk language. Therefore, I will essentially punt on any Dylan commentary since I have been answering such questions (regarding QKS activity in this area) privately.

NOTES:

(1) Eiffel is not a (OODL) object oriented dynamic language and thus it suffers from some of the same problems as C++ (it is still better than C++ in many ways).

(2) Dylan is function-centric, not object-centric. In Dylan, objects are just structure, they do not have any inherent behavior. Modules (which contain methods/unlike classes in other languages) become the behavioral scope and the notions of OO such as inheritance are VERY different (i.e., sometimes they just don’t exist in the language proper :-). STA has combined both class and module style scope in our upcoming v1.2 release, thus libraries/projects can have both public (unscoped) and (scoped) private methods that shadow class/object methods for messages sent by methods in a library/project or one of its sublibraries.

(3) The STA-Forum now has a fair number of subscribers who do not own (or author in) SmalltalkAgents, but are on the forum to monitor technology trends.

(4) As most of you know, QKS’es Smalltalk (SmalltalkAgents) already has components and we are making them really sophisticated in our upcoming releases. We long ago committed to CIL/OpenDoc and will plug and play into other component systems through whatever host services are available (like SOM/DSOM).

I would like to make a few comments on the OO revolution failing: First, I think it is an absurd statement. Component technology can only be layered on top of an OO paradigm. What I mean by this is that components are like a 5GL given that I have a OO substrate to build them on (the 4GL piece). Components are just objects with a “well-known” messaging and data-interchange framework. For components to really become successful the industry has to tackle the much harder problems of extensible “framework” design, interaction, and validation.

I believe that componentization of system software and applications is just a natural evolution of object technology. Saying OO has failed, seems as absurd as saying that Ethernet/IP has failed now that we have Wide Area Networks and alternative transports (i.e., now that the mass media has discovered the internet).

Most “complete” OO languages provide a rich set of frameworks that already have a component based architecture. I think that it is really C++ with its non-dynamic architecture and complex semantics/grammar that is failing.

I have to wonder what the BYTE author’s real knowledge, experience, or awareness was to make such a public statement (in the corporate Smalltalk area alone, I wonder what they thought IBM/Digitalk PARTS were?). We all know that IBM has over 1.1 billion dollars of Smalltalk work on the books for 1994 (which they cannot find skilled people to fulfill).

The corporate marketplace is bailing on C++ and demanding Smalltalk, with real salaries for qualified corporate Smalltalk programmers typically ranging from $1000 to $2000 per day. We also know that IBM has committed to moving all their COBOL base onto Smalltalk - what does that tell you? OO really premiered with Smalltalk (not SIMULA as some folks would have you believe), and Smalltalk still epitomizes most if not all the OO principles (multiple inheritance excluded <== lack of it is an arguable ST weakness).

It seems irresponsible to tout Microsoft’s (market-saturation of) VisualBasic without carefully explaining the real issues of development today (which I think involve productivity (environments, visual-tools, self-authoring-agents), robustness, maintainability, scalable design, teams, and integration of independently authored bodies of code [frameworks, fragments, components, etc]). It is this kind of “promotion” that got us into the C++ mess in the first place...

The Windows/DOS world has been dominated so long by static C/C++ that when it got a taste of dynamic/interactive languages via VisualBasic it reacted like a starving person. It is really Microsoft who finally has begun to wake up to the problems of C++, you watch...

As has been mentioned by folks on this forum and elsewhere, the real change that is happening in software technology is that we are moving away from language issues and onto design (object/framework interaction) and productivity issues. In this evolving world, the capabilities of the development environments (integrated visual tools and packaging are crucial) and the frameworks they provide become the critical elements.

Building components in C++ is just as hard as building applications (talk to the folks who are trying to do it). The real problem at hand is managing complexity and capturing the design intent. The latter means that when I re-use or plug-in code (including components) from some outside source, how do I know how it will behave and how can I verify that it follows all my frameworks “rules”. All kinds of new issues arise, especially with regard to extensibility, negotion of services, access to attributes, etc. All these latter items are framework (message suite) issues.

In my opinion, software (environments) systems that automatically infer and retain design-intent as a natural and integrated part of the “authoring” process, and subsequently allow it to be formally managed in team development environments with minimal complexity are the new “holy-grail”.

Just my usual opinions ;-)

What do you other folks think?

- Dave Simmons

You Didn’t Need Those New Features Anyway, Did You?

Great magazine and great article on Drag & Drop in your June 94 issue - but I have a problem. Like many developers, I am using a third party’s class library to implement my applications (in my case, TCL).

It’s all very well for Apple to bring out (excellent) extensions to the OS like Drag & Drop, but if you are tied to a class library (whose destiny you don’t control) it may as well not exist. I looked at retrofitting D&D into TCL 1.1.3 and decided that I would have to override 30odd classes to provide D&D. It isn’t worth the effort. Firstly, it’s an incredible amount of work, and secondly I would effectively end up with my own version of TCL - which I would then have had to convert to TCL 2.0 and beyond! I note that TCL 2.0 still doesn’t support Drag & Drop.

In the future, can Apple apply some pressue (god knows how) on vendors of developer tools to incorporate these extensions into their class libraries so that they can be released concurrently? If these new extensions are taken up earlier by developers, it’s good business for Apple.

I have an application which screams for D&D right now, but I’ll have to work around that until Symantec gets TCL to support D&D.

- Craig McFarlane