Fwd: [OREO] Open Runtime Environment for Objects

Marcel Weiher marcel at metaobject.com
Mon Jun 19 09:17:03 UTC 2000


Hi folks,

just wanted to let everyone know about OREO, the Open Runtime  
Environment for Objects initiative.  The initiative was started out  
of dissatisfaction with the current state of interoperability between  
object oriented languages, to be more precise with the almost  
complete lack of interoperability between OO languages.  Isn't it  
kind of sad that although OO is about communicating objects, getting  
objects written in different languages to communicate/integrate is so  
much more difficult than in procedural languages such as  
C/Pascal/FORTRAN?

The origin of the initiative is the Objective-C community, but  
interest has been expressed from various parts of the Free Software  
and OpenSource communities, and I think that it would be wonderful  
for Squeak to be at least compatible with OREO once it emerges.

There is a mailing list at <oreo at cubiculum.com> with list archives  
kept at http://sferik.cubik.org/oreo/, and I'll leave the rest to the  
original poster:


> From: "Ronald C.F. Antony" <rcfa at cubiculum.com>
> Date: 2000-06-02 16:10:45 +0200
> To: oreo at cubiculum.com
> Subject: [OREO] Open Runtime Environment for Objects?
> x-mailer: Apple Mail (2.317)
> X-MIME-Autoconverted: from quoted-printable to 8bit by  
www.zuehlsdorf.de id
> QAA00617
> X-UIDL: 8fda20729ea5b6b5b6151fdd6b66d88c
>
> Hi,
>
> first off, please excuse the quasi-spam like cross-posting off  
this message.
> This is a one-time mailing to get a discussion going. I have set up an 
> alias here for people interested in the continuation of the discussion 
> on this topic: <oreo at cubiculum.com> Hence reply to that or to me in 
> person if you feel this is nothing that belongs on the lists to which 
> I cross-post this initial message.
> I have already added some people to the oreo alias, based on personal 
> conversations at the WWDC and based on e-mail messages on various
> lists, that led me to believe that these individuals might be  
interested
> in this topic. If anyone wants to be added to the alias, please send 
> me a message at rcfa at cubiculum.com or rcfa at mac dot com (if the
> former address should cause trouble...)
>
> Since this is going to lists and people with different interests,  
let me
> first start out with describing the situation:
> Anyone in the ObjC/GnuStep/OpenStep/MacOSX scene is by now probably 
> rather aware of all the FUD in regards to the future of ObjC, and
> many are probably tired of what they consider useless religious
> language wars.
> The rumors on the demise of ObjC at Apple, and thus on the (lack of) 
> future for the language originate, as we know now after WWDC, from 
> the fact that Apple essentially divorced WebObjects/EOF from Cocoa 
> and the rest of what was once called OpenStep, as well as from OSX. 
> Apple thus now has MacOSX, QuickTime and WebObjects/EOF as three
> almost unrelated software products, which each plot their future
> relatively independent of the rest.
> The WebObjects group has bent to delusional market forces which with 
> rather flawed, yet monetarily relevant arguments scream: "Java über 
> alles!" (The arguments are delusional, because they think the choice of 
> programming language matters in regards to finding good programmers, 
> particularly those who know OOP and the relevant frameworks...)
> Part of their strategy was pure Java on the client, and for the
> time being, that's the only viable solution. (More later)
> The other part was to spend/invest/waste the last two or so
> years on rewriting all of WO/EOF from scratch in pure Java,
> thus cutting support for ObjC and WebScript also on the
> server side. *This* is where the ObjC is dead rumors originated,
> however since the MacOSX/Cocoa group is essentially totally
> separate by now from the WebObjects group, ObjC is alive and
> kicking as far as Cocoa and MacOS X goes. So there is no need
> to fear its complete demise at all for the time being.
>
> So why does any of this matter, "religion" aside? After all,
> isn't Java "good enough"? Well, to put it this way: had Java
> been invented some 25 years ago, it would be a great language.
> Coming at the end of the 1990s however, it's a step backwards
> on what has been achieved already in the late 70s.
> Further, while in the short term WO and Cocoa may have little
> to do with each other, the key advantage the NeXTSTEP/OpenStep
> APIs had over any number of other existing frameworks is that
> they were designed to be consistent. It was thus possible
> to write an app that would dynamically publish 3D visualizations
> of musical data stored in a relational database and
> retrieved from an OODB projection thereof, all within a single,
> seamless API paradigm. Same calling conventions, naming
> conventions, syntax, etc. In other words, w/o any mental
> acrobatics and translation exercises, w/o foreign language
> interfaces and stubs, etc. it was possible to write such
> apps by reaping the benefits of the synergies existing between
> object frameworks such as ixKit, EOF, 3DKit, MusicKit, AppKit,
> FoundationKit, WOF, NetInfoKit, DriverKit, etc.
>
> Currently however Apple's APIs are split between
> eC++ (IOKit), C++ (AIAT), C (CF, OpenGL), ObjC (Cocoa), Java (WO/EOF). 
> Thus the benefits that led to the enthusiastic and dedicated
> following that NeXTSTEP/OpenStep APIs enjoyed, will be to a
> significant degree destroyed. If developers have already such
> a mixture of APIs, it will be difficult to convince developers
> why they should use Cocoa rather than say Metrowerks frameworks
> based on Carbon. Also, the lack of ObjC/Cocoa wrappers for a
> lot of the frameworks like QT and in the future possibly EOF will
> make it a lot harder to learn the environment. Within the seamless 
> OpenStep API programming environment, more often than not, it was
> possible to derive API by guessing, simply by applying the common
> naming conventions. With several languages and API styles, we're
> about as integrated as buying a slew of different 3rd party
> toolkits and using them all in conjunction.
> Further, the fact that Apple seems to have no clue as of now what
> to do with EOF for Cocoa apps, it is clear that maintaining an ObjC 
> and a Java version of EOF in parallel is a big problem (inconsistent 
> bugs/features, etc.)
>
> But there are more issues:
> Other issues we have is that the ObjC community is fragmented:
> we have the GNU and the Apple runtimes for the language.
> The Distributed Object facilities do not interoperate, because
> they are not compatible. Further, ObjC needs garbage collection,
> something the GNUStep project has already addressed in some
> incarnations, and name spaces. And lastly, ObjC isn't the only
> language on this planet, and while I like it, others may not.
> Some people may consider me an ObjC bigot, nothing is further
> from the truth. I merely consider ObjC the lowest I want to sink
> when choosing a programming language. There are a considerable
> number of languages I'd much rather use, if only they had any
> relevance in the context of a platform that has marketshare.
> Examples of such languages are CLOS, SmallTalk and in particular
> TOM.
>
> There are products that show that it's possible to do more
> that what Apple does now. One example is Joy, which Objectiv-ies
> all sorts of languages. Another is the ObjC-guile interface, etc.
>
> So what we really need is a solution different from what Apple
> is currently pursuing, and a solution that we could have today,
> if the two years had not been sunk into rewriting WebObjects
> but instead into a project like I hope to trigger with this
> discussion. What we need is a unified, open-source object
> runtime environment, that is within certain limits language
> independent. This satisfies the needs that led to the
> development of the pure Java WOF 5.0:
> 	- it affords the market a Java web application server
> 	  platform and easy integration with existing 3rd party
> 	  Java code
> 	- it get rid of the difficult to maintain Java-Bridge
> 	  which also is a performance bottleneck.
> 	- an open-source approach takes care of portability issues,
> 	  because Apple says it doesn't have the resources to
> 	  maintain an ObjC runtime on all the platforms for which
> 	  WOF might be sold for in the future.
> At the same time, however, we'd gain a lot:
> 	- Apple gains a strategic advantage, since MacOS X will
> 	  offer synergies as a WOF development and deployment
> 	  platform that go beyond what the other deployment
> 	  platforms can offer. While that may not matter for the
> 	  run-off-the-mill e-commerce apps, it is of relevance
> 	  for a whole new class of web apps that I bet we will see
> 	  now that WOF is affordable to more than just a few
> 	  corporate giants.
> 	- Apple gains more language choices for Cocoa and OSX
> 	  development, GC and name spaces for ObjC. In particular
> 	  Cocoa development could be done in Java w/o the need
> 	  for a slow bridge, which would make Cocoa more buzzword
> 	  compliant, yet Cocoa development could also be done in
> 	  more advanced languages such as SmallTalk and TOM, which
> 	  would be a boon for those of us who care about such things. 
> 	- GNUStep would gain Java support, as well as support
> 	  for other languages.
> 	- Everyone gains by having compatible DO and runtimes.
>
> So what is it that we need to get there?
> a) a unified Open Runtime Environment for Objects (OREO) that
>    implements a superset of the Java, ObjC, SmallTalk features.
>    People who know more than I about such things claim that it
>    should not be too difficult to do this, if properly funded,
>    given that the TOM runtime already almost fulfills these
>    requirements. (To those concerned about performance: I
>    have been told that the TOM runtime performs at least as
>    well as the various ObjC runtimes available, which means
>    despite its superior abilities, it's competitive from a
>    performance point of view.)
> b) a push to finish the Java front-end to gcc
> c) adoption of the new runtime by both Apple and GNU.
>
> Further it would be very helpful to have the following:
> d) an OSX/GNUStep TOM compiler and the relevant bindings
>    for the existing class libraries
> e) an inverse tool of what Apple already developed: a Java
>    to ObjC/TOM translator, to allow easy porting and adaptation
>    of some of the rather useful Java libraries. (This should be
>    much easier, since we're talking about going from an almost
>    subset to an almost superset, rather than the other way round
>    as is the case with the ObjC-to-Java tool).
> f) a virtual machine that is a strict superset of the JVM that is
>    open source and that is made available as a plug-in for all
>    major browsers and platforms, which allows execution of more
>    than just Java programs on the client side. IBM had once
>    such a thing, but the lack of SUN's cooperation killed that.
>    Apple on the other hand, being the only major player (in
>    terms of consumer-level platforms) to seriously push Java
>    would be in a position of power to make such a runtime a
>    success e.g. by including it as a standard component
>    with QuickTime.
>
> Thanks for having the patience to read until here. I hope we
> can start a meaningful discussion here, and get something
> going that benefits all and asserts that progress in computing
> doesn't have to lag some 40+ years behind the times, which
> will be the case if we just wait until Java follows the C++
> footsteps. We have to learn that choices do not imply an
> XOR operator. We can be compatible with Java and the lemmings
> yet still lead the innovation. It is not required that like
> the NeXT/Apple of the past we go the "right" way and are
> incompatible with everything else, but it's also not required
> that like the Apple WO strategy of now, we subscribe to the
> "good enough" theory of progress. For if we did, we could
> just all use Windows, couldn't we?
>
> If you have received this directly (i.e. not
> through a mailing list) and want to be removed from the
> alias, please let me know. If you received this through
> the mailing list, and want to be added to the alias, let me
> know, too. And please: keep this as flame-less as possible.
>
> Ronald
>
>
>  
==============================================================================  

> "The reasonable man adapts himself to the world; the unreasonable  
one persists
> in trying to adapt the world to himself. Therefore all progress  
depends on the
> unreasonable man."  G.B. Shaw   |   rcfa at cubiculum.com   |    
NeXT-mail welcome
>
>





More information about the Squeak-dev mailing list