Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!mandrill!nitrex!rbl
From: rbl@nitrex.UUCP ( Dr. Robin Lake )
Newsgroups: comp.sys.mac
Subject: Re: LightSpeed C, and C++
Message-ID: <669@nitrex.UUCP>
Date: 26 Feb 88 14:32:22 GMT
References: <6813@drutx.ATT.COM> <6815@drutx.ATT.COM>
Reply-To: rbl@nitrex.UUCP ( Dr. Robin Lake )
Organization: The Standard Oil Co., Cleveland
Lines: 69
Summary: SoapBox Time!

In article <6815@drutx.ATT.COM> clive@drutx.ATT.COM (Clive Steward) writes:
>
>After this last runthrough, may I take a moment for a comment.
>
>I like LightSpeed C very, very well.  In addition to Mac work, I've
>ported a considerable amount of truly hairy Unix code to it.  Always a 
>pleasure, and wish there was _any_ environment like this for Unix.
>
>However.
>
>I've heard several ways that some influential person(s) at LightSpeed 
>may not feel a reason to support C++.
>
>
>Let me say that a very large bet indeed is likely to be missed here.
>
>
>Opinion.  C++ is as big a leap over present 'structured programming'
>languages as these were over 'stream-of-conciousness' code.
>
>I'm sure most of us 'feel' the mathematical consistency that 'structured 
>code' guides.  C makes this liveable.  And in use, the structure also
>gives a feeling of freedom; we 'know' the units we break a problem
>into, and like the way they work together.  It's fun, says the mind.
>
>C++ goes very much farther, by offering new kinds of 'meaning units'.
>Discover them for yourself.  But the 'fun' emotion, after doing some
>largish projects with it, says this is really a way to go.  And the
>code has essentially no performance difference from older C.
>
>Yes, Apple is going to support it, and I am going to buy it there, I guess.
>But how much better it would be to have an alternative to the long
>process of coding/compiling.
>
>And how especially better for all those trying to get up to speed.
>
>Because, the end results of designing a set of C++ objects is very easy
>to use, but the process of getting there is hard.  Needs experimentation.
>
[Let me unfold the olde soapbox, 'cause I've taught C and Software Toolsmithing
for a loooong time...].

C++ IS, indeed, an elegant and powerful approach to building a variety of
software systems.  However, as you say, designing and correctly implementing
a set of C++ objects is not for the faint of heart  ---  nor is it for those of us
who find that Fast Prototyping is the most convenient way to (A) get something
done and (B) convince the client that 'this is what you asked for;  is this
what you meant?'.

HyperCard is a blessing for fast prototyping  --- even tho the current versions
are unpolished.

Now, suppose Apple stepped back, looked at what HyperCard does (takes user
'commands', builds code, and immediately interprets that code so the user/client
can see if that's what's really needed)  ---  then built a similar application
that served as a C++ object workbench.  (It seems that something like this was
in place for Smalltalk once upon a timeO???)

This would allow easy definition of messages, message actions, classes and
heirarchies.
Then, one might be tempted to assign an icon to each C++ object, invoke an
"editor", draw the message paths between object icons, and thereby "build"
an object-oriented software system.

Ideas are worth just what you pay for them  ---  and this one is free!!

-- 
Rob Lake
{decvax,ihnp4!cbosgd}!mandrill!nitrex!rbl