home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / eiffel / 1001 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  4.0 KB
  1. Path: sparky!uunet!eiffel!bertrand
  2. From: bertrand@eiffel.com (Bertrand Meyer)
  3. Newsgroups: comp.lang.eiffel
  4. Subject: Re: Intro. book on Eiffel Programming...?
  5. Message-ID: <105@eiffel.eiffel.com>
  6. Date: 28 Jul 92 15:49:25 GMT
  7. References: <Brssyv.Boo@news.cso.uiuc.edu> <pyhmn2d.nagle@netcom.com>
  8. Organization: Interactive Software Engineering, Santa Barbara CA
  9. Lines: 73
  10.  
  11. From <pyhmn2d.nagle@netcom.com> by nagle@netcom.com (John Nagle):
  12.  
  13.  
  14. >         Remember, programming in Eiffel is supposed to be HARD.  You have
  15. > to SUFFER for your art.  Eiffel is in the grand tradition of the the Hoare
  16. > "programming is not for everyone" school.  The formalism is not to be
  17. > avoided, but studied with dedication until it is mastered.  One can no
  18. > more program properly without mastery of the formal approach than one can
  19. > do physics without calculus.
  20. > 
  21. >         If you want OOP the easy way, use Smalltalk.
  22.  
  23. Another of Mr. Nagle's provocations. I can appreciate a good joke;
  24. still, it may be useful to mention once again that ease of
  25. learning and ease of use have always been major design goals for Eiffel.
  26.  
  27. Whether this goal has been reached or not is for others to
  28. judge (for me Eiffel is easy enough, thanks); but every time the
  29. question has come up on the net Eiffel users and teachers have posted
  30. loud and clear messages, especially those who had also used other
  31. object-oriented languages. I can dig up my archives if anyone is
  32. interested.
  33.  
  34. Mr. Nagle's mention of Hoare is highly unfair.
  35. Anyone familiar with the work of Tony Hoare and Hoare himself
  36. knows his lifelong quest for simplicity. He has an instinctive
  37. repulsion for anything that looks complicated, and will work on a
  38. problem over and again until he can explain the solution clearly
  39. and convincingly to any competent person. (Mr. Nagle would have had more
  40. of a point if he had been referring to E.W. Dijkstra. Although Eiffel,
  41. like all serious modern software engineering, has been heavily influenced
  42. by Dijkstra's work, I do not share EWD's somewhat ascetic view
  43. of software construction.)  
  44.  
  45. Coming back to Eiffel and the designer's conscious view (whether
  46. or not realized in the language, which is there for everyone
  47. to examine), please allow a self-quotation, from
  48. the book ``Eiffel: The Language'', Prentice Hall, 1991,
  49. page 504 (part of a section called ``Tolerance and discipline''):
  50.  
  51.     ====================== BEGIN QUOTE ================================
  52.  
  53.          A somewhat disciplinarian attitude is not  infrequent  in  the
  54.     software community. One commonly hears such phrases as ``preventing
  55.     the programmers from doing their  dirty  tricks''.   It  is  as  if
  56.     language  designers  were invested with a moral duty, and languages
  57.     were a rampart  against  the  threat  of  the  developers'  natural
  58.     uncleanliness.
  59.     
  60.          I disagree with this view.   (This  will  seem  surprising  to
  61.     those  who  have  heard  Eiffel  being categorized, I believe quite
  62.     wrongly, as a language  of  the  restrictive  school.)  Programming
  63.     language  designers  are  not in the chastity belt business.  Their
  64.     role, to repeat a comment which I first heard many years  ago  from
  65.     C.H.A.   Koster,  is  not  to  prevent  developers from writing bad
  66.     software (a hopeless endeavor anyway), but to enable them to  write
  67.     good software; and perhaps to make the task pleasurable as well.
  68.     
  69.          This must be applied together with the Principle of Uniqueness
  70.     stated  above [IN THE BOOK]. If you exclude a certain facility, be
  71.     it the goto or
  72.     function pointers, it is not to save humanity from some abomination
  73.     (although you may also be doing that) but because you are providing
  74.     elsewhere a better way to achieve  the  goals  which  the  excluded
  75.     constructs  purported to address. Loops and conditionals are better
  76.     than gotos, and dynamic binding under the control of static  typing
  77.     is better than function pointers.
  78.  
  79.     ====================== END   QUOTE ================================
  80. -- 
  81. -- Bertrand Meyer
  82. Interactive Software Engineering Inc., Santa Barbara
  83. bertrand@eiffel.com
  84.