clive@drutx.ATT.COM (Clive Steward) (02/23/88)
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. Lightspeed C makes it fun to explore the Mac OS, and find out how to do the thing you'd like. Why not offer the same advantage to a whole new world, which happens to mesh beautifully with the Mac itself? This is only the beginning of reasons. Beauty and usefulness can define a market, I think. And later, I think there's ample reason to believe that C++ may well become the language of choice, perhaps even more than C is now, for many things. End of opinion. Will I get my wish? Anyway, thanks.
rs4u+@andrew.cmu.edu (Richard Siegel) (02/24/88)
One of the most common requests I heard while I was at THINK was a request for a C++ (or some object-oriented C) implementation in LightspeedC. >I've heard several ways that some influential person(s) at LightSpeed >may not feel a reason to support C++. I won't say that THINK's absolutely positively never ever going to do an object-oriented C for LightspeedC. In fact, I don't know anyone who will. What is much harder to say is *when*. --Rich =================================================================== Richard Siegel THINK Technologies, QA Technician (on leave) I'm not physically at THINK, so my information may be out of date. Be forewarned. Arpa: rs4u@andrew.cmu.edu UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rs4u ==================================================================
gillies@uiucdcsp.cs.uiuc.edu (02/25/88)
I believe that C++ was designed so it could be implemented with a preprocessor (a more sophisticated proprocessor than M4, which brings #include and #define to C programming). Maybe LighspeedC could support plugging in your own custom preprocessor. Slower performance would probably be o.k. But then I could plug in a C++ preprocessor to LighspeedC, and have LighspeedC++!!!
awd@dbase.UUCP (Alastair Dallas) (02/26/88)
I want to (breifly) agree completely with the previous posting--I am a huge Lightspeed C fan, but I'm dying to dive into C++ on the Mac, and I'll switch to Apple (MPW?) if I have to to get it. I hope Think hears our cry. As to why "the mind says its fun," the answer for me was best said by Bjarne Stroustrup. He said "first you create your world, then you live in it." That sums up why I love programming and why it's always seemed akin to model railroading, or architecture, or writing, at least to me. Alastair Dallas ASHTON-TATE Glendale
smethers@psu-cs.UUCP (Paul Smethers) (02/26/88)
In article <6815@drutx.ATT.COM> clive@drutx.ATT.COM (Clive Steward) writes: > >I've heard several ways that some influential person(s) at LightSpeed >may not feel a reason to support C++. > > [ Lot's of intellegent praise for C++ ] > [ Plead to THINK to make C++ version of LSC ] > DITTO. Paul Smethers SmethersBarnes
rbl@nitrex.UUCP ( Dr. Robin Lake ) (02/26/88)
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
blh@VLSI.CS.CMU.EDU (Bruce Horn) (02/27/88)
I have a lot of respect for the THINK people, including the people I met back in the early Mac days at Apple. LSC and LSP are beautiful systems that work extremely well. However, I have been pushing them to look at C++ and object-oriented extensions of C for over five years...and their response has basically been "We think object-oriented programming is a fad." I wonder if they've changed their minds yet. In their defense, they were waiting for the object-oriented extensions to settle down a little before they committed to a particular one. I think, regardless of its various pros and cons, that C++ will become the standard. I wouldn't be interested in a preprocessor to LSC for C++; it would turn a very fast environment into a slow one. It would be more work, but worth it to make LSC a direct C++ compiler. Besides, it would almost *have* to be if they want to build a source-level debugger for it. -- Bruce Horn, Carnegie Mellon CSD uucp: ...!seismo!cmucspt!cmu-cs-vlsi!blh ARPA: blh@vlsi.cs.cmu.edu
clive@drutx.ATT.COM (Clive Steward) (02/29/88)
From article <669@nitrex.UUCP>, by rbl@nitrex.UUCP ( Dr. Robin Lake ): > 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???) > -- > Rob Lake > {decvax,ihnp4!cbosgd}!mandrill!nitrex!rbl &Oh, my goodness, yes. We could get there from here, and in stages. &I hope Apple is listening well. &Clive Steward Meant to say too, of course, Think just as much. It's Sunday. I'm sure everyone has had these ideas. The thing is, it seems practical, though something to come over time. I seem to have heard that one thing holding up Apple C++ is connecting it to MacApp. Sounds good indeed. Clive
arbaugh@hqda-ai.UUCP (Bill Arbaugh) (03/04/88)
In article <76000138@uiucdcsp>, gillies@uiucdcsp.cs.uiuc.edu writes: > > I believe that C++ was designed so it could be implemented with a > preprocessor (a more sophisticated proprocessor than M4, which brings > #include and #define to C programming). The C++ by AT&T is somewhat like a preprocessor, but it also plays with the objects upon exit and etc. This is AT&T's software so if you want to use it be prepared to pay $$$. It would also be difficult to get running on a Mac (maybe with A/UX). GNU C++, on the other hand, is a complete compiler so you would not be in the LSC environment any longer. Again I think there may be problems porting it to the Mac. It certainly would be nice to have that capability! -- ========================================================== Bill Arbaugh Phone: (202) 697-7250 UUCP: *!uunet!cos!hqda-ai!arbaugh ARPA: ai02@hios-pent.arpa ==========================================================
rs4u+@andrew.cmu.edu (Richard Siegel) (03/04/88)
It's probably worth moving this discussion to comp.sys.mac.programmer. Far be it from be to comment on the appropriateness of postings in a newsgroup, but I think that programming discussions should go there. >Maybe LighspeedC could support plugging in your own custom >preprocessor. Definitely an intriguing idea. User-extensible software's a pet project of mine... --Rich =================================================================== Richard Siegel Confused Undergrad, Carnegie-Mellon University The opinions stated here do not represent the policies of Carnegie-Mellon University. Arpa: rich.siegel@andrew.cmu.edu UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rich.siegel ==================================================================
awd@dbase.UUCP (Alastair Dallas) (03/05/88)
Yes, Think should add object concepts to C. Yes, they should borrow heavily from the C extensions defined in AT & T's C++. But they should be integral--like the old Clascal language from Apple. There are a lot of reasons for this: symbolic debugging and a fast edit-compile-run cycle have already been mentioned. We need Lightspeed C++, not a version of C++ that works with Lightspeed. Alastair Dallas (These are my opinions, not my employer's)
clive@drutx.ATT.COM (Clive Steward) (03/06/88)
From article <702@hqda-ai.UUCP>, by arbaugh@hqda-ai.UUCP (Bill Arbaugh): > In article <76000138@uiucdcsp>, gillies@uiucdcsp.cs.uiuc.edu writes: >> >> I believe that C++ was designed so it could be implemented with a >> preprocessor (a more sophisticated proprocessor than M4, which brings >> #include and #define to C programming). > > The C++ by AT&T is somewhat like a preprocessor, but it also plays > with the objects upon exit and etc. Well, as I explained before, it's not so much to me, as a consultant. But I think that if you have a look at what the C++ compiler really does, you will be more than willing to call it a compiler. If you can get a look at source, you'll be the more sure. The size is about two times the size of the old C compiler, on Unix. This compiler implements all of the features of C++, which is a very large piece of work indeed. The result is some complex standard C, emitted as an intermediate level language. Any error reporting to the user comes straight from the C++ compiler; it passes on all constructs, including the old C ones. Once the C++ compile is successful, the old C compiler is used to reduce the ILL to assembler, which is assembled, and probably then linked for your executable. This makes the C++ compilation system pretty portable. I suppose the confusion comes from people compiling a small simple program, and observing that a dump of the ILL looks recognizably close to the original. Doesn't mean it always does, or that it was a simple matter to arrive at that place. That it's close at all, is a measure of the efficiency of the C++ implementation (and the abilities of the compiler), and its forming up of the desired object, overload, etc. relationships. Two other points. Old C doesn't use m4, it uses the cpp, a much simpler-minded tool. And yes, C++ in present form does play with the object code after the C compilation. The reason is that static constructors have to be initialized, and it's difficult to arrange a way for this to be done without the user worrying about it, when as usual there are many compiled files. So there's an extra editing step on the link module which ties all the constructors into a linked list to be actuated just before the user's main () routine executes. Clive Steward
viking@iuvax.cs.indiana.edu (03/08/88)
>>From article <702@hqda-ai.UUCP>, by arbaugh@hqda-ai.UUCP (Bill Arbaugh): >> In article <76000138@uiucdcsp>, gillies@uiucdcsp.cs.uiuc.edu writes: >>> I believe that C++ was designed so it could be implemented with a >>> preprocessor (a more sophisticated proprocessor than M4, which brings >>> #include and #define to C programming). >> The C++ by AT&T is somewhat like a preprocessor, but it also plays >> with the objects upon exit and etc. > But I think that if you have a look at what the C++ compiler really > does, you will be more than willing to call it a compiler. If you can > get a look at source, you'll be the more sure. Maybe so, but when Brian Kernighan lectured about C++ at Purdue University back in 1984, he described as a pre-processor too. --- Joni Backstrom "Yah sure...we gonna have fun, you bet!" Computer Science Department Indiana University ARPA: viking@iuvax.cs.indiana.edu Bloomington, IN 47405 UUCP: {pyramid,ihnp4,pur-ee,rutgers}!iuvax!viking