🚀 go-pugleaf

In article <1992Sep9.124125.1555@count0.cmhnet.org> cgb@count0.cmhnet.org writes:
>In article <1992Sep8.164922.11325@u.washington.edu>  
>bungi@carson.u.washington.edu (Timothy J. Wood) writes:
>> ede978e@monu6.cc.monash.edu.au (Robert D. Nicholson) writes:
>>   Sure ... I will, however, keep my points to the realms of ObjC, C++, NeXT
>> and X since those are the OOPL/UIs that I am most familiar with.  All of
>> this is IMHO.  If your a C++/X lover, beware -- I'm not.  Those who wish to
>> correct me by stating that X is not a UI but a graphics protocol may
>> refrain from doing so.  I like Display Postscript anyway (which X is
>> attempting to use now ... snicker, snicker).
>> 
>> >Why would you rather develop a GUI application using OOP than using 
>> >a structured language like C?
>> 
>>   First, note that OOP doesn't exactly imply non-structured.
>
>This is to say that a REAL programmer can write FORTRAN programs in
>ANY Language.   :-)
 
  This is an inspired comment (not!).  Since when does the ENHANCEMENT
  of programming languages by the addition of object-orientation mean
  that we have to (or should) chuck 20 years of sound programming
  theory based on structure?  And what the hell is wrong with FORTRAN?
  Its not the language that gives it a bad reputation?  I wrote   
  "structured" FORTRAN programs for years (before the 88 standard
  added real structured features).  And now, with FORTRAN on the NeXT,
  you can even write object FORTRAN if you want.  I fail to see why
  structure and object-orientation are mutually exclusive.  
>
>[munch]
>> 
>> >What benefits/problems do you see in using OOP ?
>> 
>>   (1)  The obvious: reusability of code in terms of both subclassing them
>>   and being able to use them in lots of places due to the seperation
>>   between interface and implementation.  Seperation of client/server with
>>   no fuss.
>
>Second that.   Ok... Show of hands.   How many times have YOU (the net)
>written a Linked List handler? 

  Wrote it once in PL/I and once in C.  Reused it many times.

>  For me, there has usually been some reason
>to re-write it than to go and find the version that, almost, works like
>the one I need.   In reality, I used to simply re-write.   
 
  This is more inspiration (not).  The only reasons you re-write is because
  either you are an intellectually lazy or incredibly untalented programmer.
  Most likely the former.

  In the IBM mainframe world, using Assembler, we wrote tons of code
  that was reused (if for no other reason than rewriting it hundreds
  of times would have been temporal suicide).  For instance, we wrote
  a 3270 display stream screen handler which was used in well over 50
  different programs and applications.  We enhanced it a number of times
  to handle larger screens, color attributes, new function keys, etc.,
  but we never had to modify (except to fix minor bugs) the base code.
  It had a succinct API which was even able to adapt itself fairly
  easily to different formats of arguments (we used the concept of
  argument registration rather early in history).

  Would this have been easier with an OOP language?  ABSOLUTELY.  But
  was it possible in Assembler (the lowest of the low?)  DITTO.  I am
  constantly amazed at the number of programmers who use the excuse of
  what there own limited imaginations can perceive in a programming
  language as the excuse for sloppy or slothful programming.  The reason
  this is a serious issue is that object-oriented programming does not
  SOLVE the problem, it merely moves up the bar. 

In the OBJ-C
>would, LIST is a basic class,  I haven't written one since.    But this kind
>of re-usability is not restricted to "basic" classes.   I wrote (and sell) 
>a Serial Class for the NeXT, that keeps someone from having to learn the UNIX
>IOCTLS in order to use the Serial Port's.   I have testimonial letters from  
>people who are CLUELESS about UNIX, describing how they used the object.
>(High end video deck controllers and virtial lab instruments to name a few.)

  Our 3270 module was used in exactly the same way by many programmers,
  even some COBOL (uggh) programmers.  
>
>[munch]
>> 
>>   (4)  C++.  Yuck.  It doesn't even have an ANSI standard yet but everyone
>>   and their anteater is using it.  One might argue that ObjC isn't
>>   standardized yet either, but then again, you can describe the differences
>>   between ANSI-C and ObjC in 30 pages (this is how long the NeXT ObjC manual
>>   was under 1.x/2.x ... haven't seen the 3.0 one yet but they haven't added
>>   a whole lot).  In comparision, my copy of 'The Annotated C++ Reference
>>   Manual (ANSI Base Document)' (Ellis/Stroustrup) is 407 pages.  And these
>>   are all very *ugly* pages.  The 2nd Ed 'The C++ Programming Language'
>>   (Stroustrup) (*Why* is is using this title?  He is not a K nor an R, but
>>   an S!)  quite a bit easier to read, but at the expense of an even longer
>>   text.  Multiple inheritence is evil.  Protocols are *much* cleaner (NeXT
>>   ObjC under 3.0)  C++ doesn't have calltime binding of methods, or even a
>>   generic object type.  How could anyone expect to get much benifit from
>>   object polymorphism without calltime binding?  How many *compilers* (not
>>   C++ -> C front ends) are there?  One that I know of: g++.  And I doubt
>>   that even FSF implemented all the features of C++.  I haven't heard of a
>>   compiler *or* translater that implements templates.  Of course this is
>>   because they don't have a generic object type or calltime binding.
>>   I guess that's enough flagellation of the deceased equine.
>>     I'm very much relieved that FSF is finally getting their ObjC runtime
>>   ready.  Perhaps this will slow down (and even reverse??  Oh Please let it
>>   be!) the spread of C++.  At a minimum, it will force the C++ community to
>>   clean up their language (wash their mouths out with soap, we will!)
>>   Ok.  That's really enough now.  I think.  Maybe.
>
>No No, PLEASE continue, and don't forget "Operator Overloading" and "Multiple  
>Inhertiance"  Truly the "goto's" of the 90's. 

  HUH?  This is utter rubbish!

  Just think, now you can see a  
>statment like   A = B + C and not have the FAINTEST idea why it doesn't work  
>:-) or even what Class it belong's to.  There are several large programing  
>shops around here that use C++ but do NOT allow the use of either of these  
>"Features", since they don't feel that such code can be read or debugged.

  Now THIS is TRULY inspired.  You just got finished saying it is possible
  to misuse ANY language and now criticize C++ for people who misuse it.
  The purpose of overloading is to permit someone to express the same
  semantic action on many different data types without having to come
  up with new operators each time.  Functions are overloaded in Obj-C and
  no one seems to complain. A print method can be assigned to every
  object and no one seems to have a problem with that.  You can CERTAINLY
  misuse this feature of Obj-C. For instance, make the print method free
  the object instead of printing it and give it to people to use.  HAH!
  What fun!  They will have a hell of a time figuring out what happened.
  Does this make the concept of inherited and overridden methods a bad
  one?  Obviously not.  It just means the person who decided to make
  [... print] do something non-obvious was stupid.    
  
  The same applies to operator overloading in C++.  The beauty of 
  operator overloading is that I can make addition with the + operator
  work CORRECTLY for all kinds of datatypes like complex numbers, 
  imaginary numbers, degrees, radians, as well as ints and floats.
  And I don't have to remember all sorts of special rules like "when
  I add a complex number to a float, I have to use AddComplexToFloat(x,y)"
  instead of justing saying x+y.  You are saying that this is bad, whereas
  I am saying it is just idiotic if the person who writes the AddComplexTo
  Float overload of + makes it divide instead of add.  This isn't a bad
  feature of the language, just a stupid use of it.   

  Keep in mind that we already have operator overloading built right into
  most programming languages (except COBOL (uggh!)).  We take it for
  granted that we can easily add ints to floats in C, yet we probably
  never realize that this is just builtin operator overloading.

  So the fact that someone can make + perform something other than an
  "addition" operation does not, IMHO, make C++ operator overloading
  a bad thing.  It just makes the person who did that a poor programmer.
  Like most things, the problem is usually pilot error, not the plane.  
>
>Let's see if I inherit from an Elephant and a Rhino.. 
>I get an Elephino  :-)

  Again, a relatively dumb comment.  If elephants and rhinos don't
  share any inherited characteristics, using multiple inheritance
  to merge the two classes is dumb.  On the other hand, it is often
  that I need to inherit from Dogs and Pets to get Pet Dogs.  These
  are clearly two distinct classes (since I might also want Pet Cats
  or Pet Fish and possibly also Wild Cats and Wild Fish(???:-)).  Dogs
  Cats are Mammals, Fish are, well, Fish, while WildAnimals and PetAnimals
  have a whole different set of requirements.  I do not disagree that
  there are other ways to solve this problem as well in Obj-C, but this
  does not make multiple inheritance bad.
   
>The problems with C++ are legion, when it comes
>to doing truly object oriented programing. 

  We agree here, but almost solely on the issue of late binding and
  on the lack of a foundation class that is inherited by all objects
  so that you can pass any method to any object and get some kind of
  response (even "doesNotRespondToMethod").  C++'s requirement that
  all methods be resolved at compile time, at least with respect
  to perceived class hierarchy using virtual methods makes it very
  hard to implement container classes in a reasonable way.

  The other problem with C++, but unfortunately also with Obj-C, is
  that both, as extensions of C, treat basic data types differently
  than objects.  This means that I can't use the [... print] method
  on an integer or float unless I build a whole set of classes for
  basic data types and pay the performance penalty of using them
  that way (which can get pretty grungy at the low level).  Based
  on your distaste for C++, you can hardly consider Obj-C much better
  on this issue.  The obvious answer is a TRUE object-oriented language
  like Smalltalk which treats ALL data as objects.  But somehow I doubt
  you would agree with me.

   It is, however, good for
>doing operating system level stuff.  but then again so is 'C'

  And so is objective-C.
  
>> >How do you feel the use of a UIMS (IB) helps ?
>[munch]
>> 
>>   (3)  NO CODE!  If you wan't to change your interface five times a day, no
>>   problem.  It only took you two minutes to set it up in the first place.
>
>Yea, and NO CODE..  With ALL other platforms, what you really have is a "Screen  
>Painter"   When your done, it justs barfs out code and away you go.  OH, you
>need to change these buttons to check boxes?   Well, if you have already
>put your own code in to handle the buttons, you are screwed.  (You'll be
>doing it by hand from there on.)
 
  Again, you obviously don't have much experience with OTHER platforms.  
  Try using UIM/X on a Motif system.  UIM/X not only lets you write your
  code while giving you an automatic framework for your widgets, it lets
  you TEST YOUR CODE right inside the GUI builder environment.  Far 
  superior to IB, IMHO.  Unfortunately, it is built on a brain-dead GUI
  (Motif) which causes its own problems.  But don't suggest that NeXT is
  totally perfect on this one either.  

>With interface builder, you are archiving and unarchiving the REAL, LIVE object
>that you'll be using (You CAN'T do this with C++)   the "Target" of, say, a 
>button is where you put your own code (really you give the button the id
>of your object and the name of the method to call which Interface Builder  
>initializes when it un-archives the object.)   That way you can "dink" with
>the user interface all day, and as long as you don't "break" the connection to
>your object, you don't have to do anything, if you do break it you have
>to hold down the control key while you drag a line from the button to an icon  
>that represents your object.   Yes Boss, this is HARD WORK.... NOT.
>
>I used to try and convert C++ people to "The Way"  now I look on them with
>sadness and compassion, while I under bid them by 30% and eat THEIR lunch.

  Unfortunately, I have not found this to be true.  The problem, of course,
  is that while you can underbid them 30% on the development, they still
  have to buy NeXTs and this is not a trivial problem to solve (although,
  sigh, I wish it were).  The savings on 100 PeeCees over 100 NeXTs may
  just cause some unknowing soul to justify paying more on the development.

  And don't think this is a small amount.  You can put together a 386SX
  full color networked PC user workstation for something under $1500
  there days.  Color NeXTs are still over $5000 at a minimum.  Clearly
  the PC doesn't have the power of the NeXT, but if you are a company
  putting together a 100 workcenter order entry application, this may
  not matter.  In fact, this is what I have been saying for a long
  time.  NeXT needs a low-end "terminal workstation" (i.e., just enough
  power to be useful as the front end for user apps) in order to 
  deploy all the wonderful custom apps we can build with it.  I used
  to build custom apps using high-powered mainframes with neat program
  development oriented terminals but I had to deploy them on low-end
  terminals.  This has not changed, as far as I can see.

>They will evolve or become extinct as their lot has decreed.

  If you really believe that C++ is likely to become extinct, you are
  even LESS informed than much of your above post implies.  For better
  or for worse (and I agree that much of it is for the worse), C++
  has captured the minds of programmers and managers.  The number of 
  C++ books at Computer Literacy Bookstore is about 75 compared to
  the number of Obj-C which is about 3.  I generally consider this
  to be a good indicator of which way a market is going.  I HOPE THIS
  CHANGES.  I have no firm belief that it will.

  (BTW, much the same thing was said by PL/I programmers vis a vis
   COBOL and FORTRAN.  Yet COBOL and FORTRAN remain and the number
   of PL/I programmers has dwindled.)         

  Jon Rosen