More technology adoption curves

Akira Tanaka nicely extended my Mgram request by adding “Service Oriented” and “Enterprise architecture”:

@JBezivin How about this? http://goo.gl/374Sk—
Akira Tanaka (@atanaka) December 20, 2010

The lesson I draw from this data is that “model driven engineering” and “service engineering” are approximately following the same increase rate.

But I am also impressed by the important grow of the “enterprise architecture” subject.

Of course this is only one of the possible indicators of technology adoption, just only one.

Thanks Akira

Interpreting technology adoption curves

Interpreting technology adoption curves

Following the current Google Ngramming fashionable trend, I started to look at the evolution of references to some technological buzzwords. I started by drawing the comparative curves for « object oriented » and « model driven ». The result was quite interesting:

There are many interpretations of this curve.  I propose the following ones:

1. Object technology is now mainstream and thus explicit references are decreasing. Object technology started in 1980 and had an initial development until 1985, and then a much more rapid one until 1995, followed by a slower decrease.
2. Model driven engineering is gaining momentum since 1996 and steadily increasing its apparent impact.
3. The development rate of object technology between 1985 and 1995 was much more rapid (steep curve) than the later development of model driven engineering in the 1996 to 2006 decade.
4. So the two phenomenon are not comparable. Probably this is due to the fact that there were some obvious killer applications in object technology that triggered the rapid development just before 1985, while this is  not so obvious with model driven engineering.

I am interested by any other observation.

Objects have failed

Objects have failed

I was reading again today Richard Gabriel’s rant on Object Technology at OOPSLA 2002, emphasizing some of his strong points:

• The object-oriented approach does not adequately address the computing requirements of the future.
• Object-oriented languages have lost the simplicity —some would say purity— that made them special and which were the source of their expressive and development power.
• Powerful concepts like encapsulation were supposed to save people from themselves while developing software, but encapsulation fails for global properties or when software evolution and wholesale changes are needed. …
• Objects promised reuse, and we have not seen much success. …
• The over-optimism spawned by objects in the late 1990s led businesses to expect miracles that might have been possible with objects unpolluted by static thinking…
• Objects require programming by creating communicating entities, which means that programming is accomplished by building structures rather than by linguistic expression and description through form, and this often leads to a mismatch of language to problem domain.
• Object design is like creating a story in which objects talk and interact with each other, leading people to expect that learning object-oriented programming is easy, when in fact it is as hard as ever. Again, business was misled.
• People enthused by objects hogged the road, would not get out of the way, would not allow alternatives to be explored —not through malice but through exuberance— and now resources that could be used to move ahead are drying up. But sometimes this exuberance was out-and-out lying to push others out of the way.

At the time we naively and enthusiastically believed that, since functions, rules, events, parallel processes, etc. could be represented as objects, there was less need to concentrate on functional programming, logic programming, rule programming, event programming, etc.  There were for example several implementations of Prolog on top of Smalltalk ar PARC and with Smalltalk V. All these considerations were probably mistaken and hampered the development of alternative programming styles.