Xref: utzoo comp.lang.eiffel:234 comp.lang.c++:3560 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!husc6!bunny!jwg1 From: jwg1@bunny.gte.com (James W. Gish) Newsgroups: comp.lang.eiffel,comp.lang.c++ Subject: Re: Eiffel vs. C++ Message-ID: Date: 6 Jun 89 15:36:38 GMT References: <2689@ssc-vax.UUCP> <150@eiffel.UUCP> Sender: jwg1@GTE.COM Followup-To: comp.lang.eiffel Organization: GTE Laboratories Incorporated, Waltham, MA Lines: 95 In-reply-to: bertrand@eiffel.UUCP's message of 4 Jun 89 23:48:27 GMT In article <150@eiffel.UUCP> Bertrand Meyer writes: > C++ is obviously very compatible with C. But in Eiffel too you can >easily communicate with C software; both call-in and call-out are >provided. This makes it possible to reuse existing software easily. >The need for such communication was not, however, deemed to be a good >argument for impairing the consistency of the language itself. > I believe this should be qualified somewhat. You indeed can make calls to C routines from Eiffel and vice versa. But life is rarely that simple. You have to map Eiffel objects to C structures and vice versa. This is tedious but can be done in some/most(?) cases. One of the biggest problems that keeps calls from Eiffel to C non-trivial is the inability to use C include files within Eiffel for the definition of types on the Eiffel side. This is a serious obstacle to making use of much C code. A case in point is the use of X. (There are other problems here such as callbacks, but I don't want to go into that here). Much of the X stuff is defined in C header files. To make use of these header files within Eiffel requires either a manual or user-defined automatic translation mechanism. I don't expect miracles here and I don't expect ISE to come up with solutions to the problems generated by C language design sins or the poor coding practice of some C programmers, I just want to point out that the statement "...in Eiffel too you can easily communicate with C software; both call-in and call-out are provided" does not tell the whole story. Also, with respect to reusing existing software easily, it definitely is NOT easy to make use of existing X code, particulary existing widgets. We've made a serious attempt at it and can do it with some success, but it is not fun or easy. And please correct me if I'm wrong, but having the X-based graphics classes will not make it any easier to (re)use existing widget sets either. > >Simplicity and ease of learning > > Much of the plea for C++ is based on the observation that it provides >an easy transition from C, which (for better or worse) is the language >many programmers know nowadays. Using Dr. Brad Cox's expression (meant >for Objective-C), this supports an ``evolutionary'' approach. > > I can certainly respect this view and its appeal to software managers >in industry. But I believe that by considering it more closely one will >find it short-sighted and ill-founded. > > Learning a new language such as Eiffel is nothing for a >competent programmer. For Eiffel, which is small and simple, >the learning process typically lasts a few days at most. >Nobody has ever told us that Eiffel was difficult to learn. >(If you read this, have tried to learn Eiffel, >and found otherwise, please respond!) I believe that the process of >going to Eiffel is in fact much smoother, as you don't have to use >a confusing mix of old and new concepts. >In a language that you master totally, you feel >confident and you can concentrate on your job rather than on >the language intricacies. I agree that learning a new language is nothing for a competent programmer. However to learn to program effectively and efficiently in a new language takes much more than a few days, especially if one is switching paradigms. Learning to use the language fully and understand its subtleties is a long term affair. I have been using Eiffel for several months and still don't feel like an expert - nor did I expect that I would. One of the obstacles to learning is the lack of a comprehensive language reference manual. I was pleased to read that one is forthcoming. Another obstacle, which I believe another poster already stated, is the lack of thorough documentation for the library classes. At times, I have had to write test programs or actually look at the source code for the classes to figure out how to use them. A case in point is the class H_TABLE. I wanted to dump the non-null entries of a an H_TABLE that I created. I thought that I could loop through it using entry(i) with i going from 0 to nb_elements-1. Unfortunately, it wasn't that simple, since entry(i) doesn't return the non-null entries like I expected it would. Better documentation would have prevented me from making this mistake. Examples in the documentation could alleviate some of the confusion. > > Also, the brief initial shock produced by the realization that you >cannot easily write your programs in a traditional way any more is, >in the experience reported by Eiffel users, highly salutary. > But still requires a considerable realignment of ones neurons :-) -- Jim Gish GTE Laboratories, Inc., Waltham, MA CSNET: jgish@gte.com UUCP: ..!harvard!bunny!jwg1