wtwolfe@hubcap.clemson.edu (Bill Wolfe) (03/12/90)
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