🚀 go-pugleaf

   The following e-mail conversation recently took place, and I thought
   comp.lang.eiffel might like to consider some of the points raised...

   (Brad gave me permission to post his comments for contextual purposes)

  -------------------- begin transcribed e-mail conversation -------------

>From brad@SSD.CSD.HARRIS.COM (Brad Appleton):
> From wtwolfe@hubcap.clemson.edu (Bill Wolfe):
> > While I agree that Eiffel is not quite as elegant as it's hyped up
> > to be, and despite the fact that I personally would much sooner have
> > a concurrent object-based language (Ada, which actually has object-
> > oriented preprocessors such as Classic Ada anyhow) than a sequential 
> > object-oriented language (Eiffel), I don't think it's fair to say
> > that Eiffel should not at least be given serious consideration.
>  
> While it is true that Eiffel does not contain constructs for concurrency,
> there are a *large* number of programs which simply CANNOT make use of
> such beasts. In such a case, the "tasking" part of the langauge, seems 
> (IMHO) to be overkill. On the other hand, one cannot deny the usefulness
> of such a thing either.
>
> What I would like to see is some kind of add-on (or enable/disable switch?)
> to provide this extra functionality when needed. It would make things less
> expensive for the people who dont want the extra "baggage" while giving 
> those that "do" want it the chance to use it.

   A good compiler will notice any features that you don't use, and
   optimize away the object-code support for all such unused features.
   Therefore, assuming a mature compiler, software which does not use
   tasking will face no penalty.  The issue is therefore not whether
   the language design should include it, but whether the language's
   compilers are mature enough to deal with it correctly.  Some might
   argue that this would require too much compilation time, but the
   correct approach is to do the sophisticated optimizations only when
   compiling the final, production product.  Telesoft's Ada compilation
   system, for example, does some highly sophisticated inter-package
   optimizations when operated in its production-product mode, but does
   not waste time doing them when operated in default (development) mode. 

> If Eiffel "were" to have tasking added in to its syntax or as a class,
> would you still prefer Ada? Under what conditions? Would you argue 
> that it is better to add tasking to the language itself or via a 
> class library?
> 
> Example: Nahrain Gehani has developed Concurrent C which adds Ada-like
> constructs (task-spec, body, and rendez-vous facility) to C/C++. Bjarne
> Stroustrup feels that this is not the solution, that there should be (and 
> there is at AT&T) a task class to accomplish this.

   I think this is one of the stupidest ideas Bjarne has ever propagated,
   and in my opinion it will crush C++'s long-term prospects.  (Which, in
   my view, is a Very Good Thing anyway.)

   Now let me give you a reference: "Object-Oriented Development", edited
   by Dennis Tsichritais, Centre Universitaire d' Informatique, Universite'
   de Geneve.  Within this reference, the article "Concurrency Issues in
   Object-Oriented Programming Languages", by M. Papathomas.  In my view,
   both Eiffel and Ada should move toward becoming non-orthogonal, uniform,
   integrated concurrent object-oriented programming languages (in terms of
   the taxonomy developed in that article).  Here are the definitions:

      We will call orthogonal the category of languages where objects
      are unrelated to concurrency, and non-orthogonal the category of
      languages where objects have some predefined properties concerning
      concurrency.  [...] The non-orthogonal class has the advantage of
      preventing the problems that could occur by using "unprotected"
      objects in a concurrent environment.  Objects of sequential nature
      may be implemented in much the same way as in sequential languages.
      The mutually exclusive execution of the object's operations is 
      handled automatically by the language.   [Note: I differ slightly
      with this in that I think the automatic provision of mutually
      exclusive execution should be the default, as opposed to required;
      there is an entire field of study which covers ways to implement
      data abstractions in such a way that multiple processes can be
      active within the data structure simultaneously, while still having 
      complete safety.  These are extremely sophisticated implementations 
      which most programmers will not be inclined to go for, but in terms
      of a reuseable components industry perspective it is *tremendously*
      important that it be possible to express them within the language.]

      Languages in the uniform category support only one kind of object, 
      whereas languages in the non-uniform category split the object world 
      into two kinds of objects: those that serialize the execution of 
      their operations and those that do not.  [...] The distinction
      between different kinds of objects characterizing the non-uniform
      category presents some disadvantages compared to the uniform one.
      The programmer has to decide in advance if a certain object should
      be of the "protected" or "unprotected" type.  Type hierarchies of
      "protected" and "unprotected" objects are typically kept disjoint,
      therefore objects having similar behavior may have to be defined
      twice, introducing a certain redundancy in the class hierarchy.
 
      Concurrent execution may be expressed by explicitly creating new 
      threads of control, independently of objects, that communicate and 
      synchronize by invoking the operations of shared objects. Another 
      approach is to consider objects as active entities and express 
      concurrent execution and synchronization by the creation of objects
      and their interaction.  [...] For languages in the integrated category
      concurrent execution is expressed by interaction of objects whereas
      in the non-integrated category another concept like a process or
      activity is used for expressing concurrent execution.  [...] The
      integrated approach has the advantage that concurrent applications
      are structured in terms of objects which are the units of concurrent
      execution.  The communication and synchronization of objects is
      expressed at the object interface, which is clearly defined.
 
  Now if Eiffel were to include concurrency in the way I have described 
  above, I would be much more inclined to seriously consider using it
  as a production language.  However, there remain a large number of
  serious problems which Eiffel has not addressed.  For example: Meyer
  has been said to be quite excited about the potential for information
  systems applications.  But are there Eiffel compilers for IBM platforms?
  Are there bindings to CICS, DB2, etc.?  It is only just a few days ago
  that the Eiffel Consortium was proposed!!  What about compiler validation?
  Is the Consortium going to establish a compiler validation facility like
  the Ada Joint Program Office's ACVC?  Although we are hearing noises about
  standardizing Eiffel and getting it into a systematic, controlled revision
  cycle, up until now there has been chaotic, uncontrolled revision.  I even
  read in comp.lang.eiffel about people actually "hacking the compiler"!!!!!
  And where is the reuseable components industry Meyer cites as one of his
  important goals?  Ada *has* a reuseable components industry, here and now.

  Summary: Ada is far more mature than Eiffel, and there is a much larger 
  market for Ada compilers, tools, and components.  All the serious problems 
  I described above have already been addressed successfully by Ada.  Thus, I 
  think it will take a moderate amount of revision and a huge amount of money
  to get Eiffel to the point at which it is prepared to seriously challenge 
  Ada for the title of "Best Production Software Engineering Language".  

  I would strongly suggest that if Eiffel is indeed seriously concerned
  with this objective, then the Consortium should be sending representatives
  to Ada conferences (the Tri-Ada series, the Nth Annual National Conference
  on Ada Technology series, etc.) to take advantage of the problems Ada has
  encountered, and the solutions Ada has found, during its process of becoming
  a mature production programming language.  If this is not done, Eiffel will
  have some very, very tough lessons to learn the hard way as it grows up.   

> I know we have yet to come up with the UPL (ultimate programming langauge)
> but right now, Eiffel is at the top of my list. Ada used to be up there 
> too but It was so large (and *very* expensive to maintain a validated 
> compiler) and a wee-bit to strongly typed for my preference (although 
> only a little).

  English is an incredibly large language, but we seem to do okay with
  it nevertheless.  I think Ada will be simplified a bit as it continues
  to mature -- for example, merging the concepts of package and task into
  the integrated concept of an object would make things easier -- but it
  should also be kept in mind that studies have shown that very little can
  be trimmed from the Ada language without negatively impacting its basic
  capabilities.

  It should also be kept in mind that not only is Ada more mature, it is
  also exploiting the applied research done by Eiffel and C++ as it moves
  into the Ada 9X phase.  At the Eighth Annual National Conference on Ada
  Technology, the general in charge of SDI specifically listed inheritance
  as one of SDI's requirements for Ada 9X.  Right now, the provision of
  increased support for object-oriented programming is the single hottest 
  topic in the Ada 9X process.  Whether Eiffel should fragment the market
  for production software engineering languages by trying to challenge Ada, 
  as opposed to serving as a research vehicle for making Ada 9X, 0X, etc. a 
  better-integrated language, is an important question as well.  I don't
  know the answer, but I hope it will at least be thoughtfully considered.

  -------------------- end of transcribed e-mail conversation -------------

  Bill Wolfe, wtwolfe@hubcap.clemson.edu