cox@ppi.UUCP (Brad Cox) (10/19/87)
This is a reposting. My (numerous) earlier attempts to get this on the air failed because of Usenet/NFS gremlins too numerous to mention. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a (long!) reply from Brad Cox, the originator of Objective-C, in response to >> csrdi@its63b.ed.ac.uk (Rick Innis, CS4) >>... I'd also like C++ and may well end up porting that myself, but I've >> been told that Objective-C is a better language.... > > Doug Moen (U Waterloo CGL) replies > Strange...My understanding is that C++ is a better language. > ... > I'd be interested in seeing the opinions of people who have had > non-trivial experience with both languages ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ C++ is an ambitious programming language. Objective-C is the language component of an ambitious programming environment. The two languages have remarkably little in common except that some of their implementations invoke the native C compiler to assist in code generation. For example, our Objective-C Compiler does generate C code, but our Objective-C Interpreter does not; it implements Objective-C entirely on its own. C++ and Objective-C are different tools for different jobs and it is tough to compare them without being specific about the jobs you intend to use them for. > Objective-C is apparently C with Smalltalk code embedded using escape > sequences Objective-C language is a hybrid between C and Smalltalk in precisely the same sense that C++ is a hybrid between C and Simula. Their differences stem from the fact that we've focused our energies outwards, towards building a comprehensive programming environment, rather than inwards, towards building a more comprehensive programming language. > The problem with Objective-C is that you deal with two universes; the > C universe and the Smalltalk universe. Why is this a problem and not a virtue? Multiple tool universes seem necessary and desirable for activities as complex as production system-building. It is not a problem that the tools in my woodworking workshop `force' me to think in separate universes for drilling, sawing, and planing, or that Unix `forces' me to deal in a C universe for some things and a shell universe for others. On the contrary, each tool leaps to hand in a twinkling, and I can pick them up or lay them aside according to the job on hand. In Objective-C, I move smoothly between conventional C tools (functions, data, macros) for micro-granularity problems, classes and objects for ordinary work-a-day granularity, and other tools (lex, yacc, pipes and filters) for macro-granularity. Multiple tool universes also means that ambitious features can be added to support higher (object-oriented) levels without impacting lower levels. For example, we've implemented automatic garbage collection for the object-oriented level of the system while not impacting lower-level issues like ANSII standards and the predicatable fast response times of ordinary C. Although I like the integration of support that C++ provides for the small granularity problems of program-building, Objective-C focuses on providing better coarse-granularity support for large-scale system-building. C++ has made a number of compromises in the interest of efficiency that compromise system-building objectives, such as the lack of a central messager, not preserving information about types into the run-time environment, and a limited interpretation of dynamic binding, a vestiage of its Simula roots. What do I mean by `programming environment'? At present, we don't yet provide a fully iconic programming environment like Smalltalk's. But we're certainly building incrementally in that direction. The ICpak-201 discussion to follow should make this clear. Unix and its suite of reusable tools are an environment, and Objective-C's environment is presently of the Unix flavor. In addition to Unix tools, the Objective-C environment includes 1) Two implementations of the language, a compiler AND an interpreter. Only the compiler generates C code. The interpreter fully implements Objective-C language (and ALL of C) on its own. The interpreter supports the front end of the development process by allowing code to be developed, tested and repaired with instantaneous turnaround. The compiler supports the back end of the development process by building fast, compact code suitable for production system-building. The compiled and interpreted environments are compatible. My normal way of working is to develop totally inside the interpreter. Occasionally, to optimize execution speed, I compile the code thus developed, link the resulting code into the interpreter, then override it with interpreted code as I uncover bugs or make extensions. And my normal way of publishing compiled code so that others in my shop can use it is to distribute an interpreter with the code linked inside it along with relatively concise documents about how to explore the new code's facilities. This is a real improvement over the alternative; the conventional encyclopedic reference manual. My users can explore the code and learn it on their own, rather than having to absorb the information through a reference manual. Furthermore, the most recent version of the interpreter (which isn't available to me yet; Real Soon Now!) supports dynamic linking and checkpointing thus eliminating the need to periodically shut down and to link with compiled code. The lack of similar support for prototyping and debugging is a major shortcoming of C++. 2) Comprehensive and fully-supported foundation libraries: We think that radical improvements in programming technology (comparable to those that the silicon chip technology brought to the hardware industry) will not come from better programming languages, except insofar as those languages help to foster widespread code reusability and loosely-coupled cooperation between diverse developers. Our energies have been spent on building ambitious libraries. For example, our Object class implements the Objective-C memory model that all other classes inherit. This class implements two methods, storeOn:aFileDescriptor and readFrom:aFileDescriptor, that let any object convert itself from object-oriented form (reference-intensive) to packet-oriented form (value-intensive), and back again. This puts generic support for distributed and/or persistent object systems into every object, whether built by PPI or its customers, now or in the future. Furthermore Objective-C uses a central message function to dispatch messages between objects. This function is written in C and its source is automatically provided for customers to enhance as they choose; for example, by enlisting the storeOn:/readFrom: services in their own distributed or persistent object system. A comprehensive library of Collection classes is also provided. They are fully supported parts of the Objective-C environment because we felt that providing a conherent and stable foundation was essential to foster the loosely-coupled cooperation between diverse developers I alluded to before. 3) ICpak-201; iconic user interface library We have just announced an ambitious library of Software-ICs for building iconic user interfaces that are portable across diverse windowing environments including X-Windows, SunWindows, and others. This library is our first step towards creating a comprehensive program development environment for Objective-C analogous to Smalltalk, MacIntosh, etc. For details, see my article in Byte Magazine, August 1986, or Chapter 9 of my book, Object-oriented Programming, An Evolutionary Approach, Addison Wesley, 1986. 4) The Producer software that I recently released to net.sources.misc (August 1987) is also part of the environment. Producer is a tool for translating Smalltalk-80 code to Objective-C so that Smalltalk-80 can serve as an extension of the Objective-C programming environment in support of the rapid-prototyping end of the program development lifecycle. 5) Coming soon: automatic garbage collection, dynamic linking, multiple inheritance, more static binding, inline procedures, coroutining, distributed computation, persistent objects, exception handling, blocks, ProcessInspector, automated testing procedures, ... These are not pie-in-the-sky ideas. Nearly all of these are at least in advanced development and should begin releasing starting early next year. This is much too long already. Contact me directly for details. Brad Cox Vice President and Chief Technical Officer Productivity Products International 75 Glen Road Sandy Hook, CT 06482 (203) 426-1875
garl@nlm-mcs.arpa (Gary Letourneau) (11/01/88)
Now that Objective-C is being bundled with the NeXT machine, I would like to pose the following question: how does Objective-C compare with C++. I believe that this was discussed at great length in one of the newsgroups sometime in the last year or so, but because of this new development, it should prove beneficial to once again present a comparison. To try to reduce the ammount of traffic on this topic, if you mail to me at the email address below I'll post a summary. Gary Letourneau letourneau@mcs.nlm.nih.gov
david@beowulf.JPL.NASA.GOV (David Smyth) (11/01/88)
In article <8335@nlm-mcs.arpa> garl@nlm-mcs.arpa (Gary Letourneau) writes: > > Now that Objective-C is being bundled with the NeXT machine, I would like >to pose the following question: how does Objective-C compare with C++. This is going to cause some discussion, and I think that is what the net is for. Therefore, I'm posting to the net rather than e-mail as was suggested. At USENIX/C++, I said that C++ is too complex. Much recent net discussion has added support to this claim. C is basically simple (declarations and operator precedence are awful, of course). C++ is incredibly complex. The number of caveats which productive C++ programmers must grasp is simply too large: must have virtual destructors, can't have virtual constructors (makes sense, but it is obscure); when one must use [] on delete, and when they are not needed; only use multiple-inheritance when you have the source of all classes back to their roots because a client can introduce bugs which a C++ compliler won't catch; etc. etc. etc. I am not convinced that Objective-C is a good way to go: lack of strong typing for example. However, it is certainly a MUCH smaller addition to C than C++. Face it: the only reason we are talking about using C++ or Objective-C is because of a desire to be "upwardly compatible" with existing C code. Note, however, that C++ IS NOT "upwardly compatible" with C, rather C++ IS A DIFFERENT LANGUAGE! Just try including <sunview.h>, and you will see what I mean. Or any large C language program! It won't compile with a C++ compiler. The more recent enhancements to the language continue to widen, rather than narrow, the difference in semantics between C++ and C. Since people are willing to use C++ anyways, perhaps what we should REALLY do is create a new, GOOD object language, and call it, say, ++C, and use it instead. Besides, the name would then be semantically correct! :-) I think it was and is a good idea for any new language to generate C as an assembly language, like cfront does. True, a C compiler cannot make some optimizations which a C++ compiler can make, because some semanitcs are lost in the translation. This is usually not significant to early implementations based on a prototype language anyway.
ark@alice.UUCP (Andrew Koenig) (11/01/88)
In article <3438@jpl-devvax.JPL.NASA.GOV>, david@beowulf.JPL.NASA.GOV (David Smyth) writes: > Face it: the only reason we are talking about using C++ or Objective-C > is because of a desire to be "upwardly compatible" with existing C > code. Note, however, that C++ IS NOT "upwardly compatible" with C, > rather C++ IS A DIFFERENT LANGUAGE! Just try including <sunview.h>, > and you will see what I mean. Or any large C language program! C++ is programmer compatible with C. By this I mean the following: You can take a large project with a bunch of C programmers and have them writing working equivalent C++ programs in a day or less. You can convert your system from C to C++ a module at a time without having to throw the whole thing out and start over. You can write large systems that will compile in both C++ and ANSI C without change and do the same thing. A good C++ programmer can convert about 1,000 lines of old C an hour to C++. Converting ANSI C should be faster. > Since people are willing to use C++ anyways, perhaps what we should > REALLY do is create a new, GOOD object language, and call it, say, ++C, > and use it instead. Besides, the name would then be semantically > correct! :-) Cfront, the first implementation of C++, increments C and yields C as its output. Thus C++ is a more appropriate name than ++C. -- --Andrew Koenig ark@europa.att.com
cjosta@taux01.UUCP (Jonathan Sweedler) (11/01/88)
In article <8375@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: > >C++ is programmer compatible with C. By this I mean the following: > > You can take a large project with a bunch of C programmers > and have them writing working equivalent C++ programs in > a day or less. Big deal. I learned Pascal in a few hours after knowing C. Does this mean Pascal is "programmer compatible" with C? Well then so is Fortran, Cobal, etc... That doesn't change the fact that converting large, complex programs from one language to another is a large, complex task. Maybe converting from C to C++ is easier, but it is still a tedious, error prone task. > > A good C++ programmer can convert about 1,000 lines of > old C an hour to C++. Converting ANSI C should be faster. Yeah, right. An then how about debugging? The whole point about *compatability* is that you don't have to do this conversion that is NEVER as easy as it seems. And what do you mean by "good" C++ programmer? Certainly not the same programmer that learned C++ "in a day or less." Everything looks good in the best-case light. I don't think things are as easy in real life. > >Cfront, the first implementation of C++, increments C and yields >C as its output. Thus C++ is a more appropriate name than ++C. >-- A rose by any other name... :-} -- Jonathan Sweedler === National Semiconductor Israel UUCP: ...!{amdahl,hplabs,decwrl}!nsc!taux01!cjosta Domain: cjosta@taux01.nsc.com
cme@cloud9.UUCP (Carl Ellison) (11/01/88)
In article <3438@jpl-devvax.JPL.NASA.GOV>, david@beowulf.JPL.NASA.GOV (David Smyth) writes: > > True, a C compiler cannot make > some optimizations which a C++ compiler can make, because some > semanitcs are lost in the translation. This is usually not significant > to early implementations based on a prototype language anyway. (flame on) PLEASE -- I've heard this argument, in various flavors, for years. Prototype languages don't exist. They hang on -- because their code hangs on. Burt Sutherland, ex- of Lincoln Labs and Xerox PARC, once said: "Programs are like waffles -- you should always throw the first one out." Unfortunately, I've never seen anyone follow that maxim. (flame off) --Carl Ellison ...!harvard!anvil!es!cme (normal mail address) ...!ulowell!cloud9!cme (usenet news reading) (standard disclaimer)
leech@tlab1.cs.unc.edu (Jonathan Leech) (11/02/88)
In article <913@taux01.UUCP> cjosta@taux01.UUCP (Jonathan Sweedler) writes: >In article <8375@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >> A good C++ programmer can convert about 1,000 lines of >> old C an hour to C++. Converting ANSI C should be faster. >Yeah, right. An then how about debugging? The whole point about >*compatability* is that you don't have to do this conversion that >is NEVER as easy as it seems. And what do you mean by "good" C++ >programmer? Certainly not the same programmer that learned C++ >"in a day or less." Everything looks good in the best-case light. >I don't think things are as easy in real life. Just as a point of reference: I recently converted a screen editor which I maintain to be compilable under both C++ and C. It was ~25000 lines of C code, not very well designed, but highly portable. It took about 2 days. The major problems I encountered were: - lack of function prototypes. I modified lint to generate prototypes (these modifications should be on comp.sources.unix soon). - Old-C style declarations of formal arguments which cfront handled incorrectly. There were a few dozen of these and they were annoying to fix, but it is a cfront problem, not C++. - Functions that use unportable argument-passing conventions e.g. the old classic (written before varargs existed): int error(str, a1, a2, a3, a4, a5) char *str; { fprintf(stderr, str, a1, a2, a3, a4, a5); } the problem here was a clash between the C++ prototype required for such functions to be used as desired: extern int error(char * ...) and the actual declaration. Debugging time for the C++ version (after making it compile) was 0. It worked right off the bat. C++ uncovered some potential portability problems I had not seen with lint. True, I'd never encountered these problems on machines ranging from PCs to DG Eclipse to VAX/VMS etc... but I appreciated finding them anyway. I would be happier if AT&T fixed the annoying little cfront bugs and provided some way to not need prototypes so large, complex C programs could be more easily converted, but the amount of effort involved in this conversion was not unreasonable. -- Jon Leech (leech@cs.unc.edu) __@/ ``The law of gravitation is different from many of the others... there are many places where gravity has its practical applications as far as the Universe is concerned.'' - R. P. Feynman, _The Character of Physical Law_
mikhe@tragicomix.liu.se (Mike Henry) (11/02/88)
In article <3438@jpl-devvax.JPL.NASA.GOV> david@beowulf.JPL.NASA.GOV (David Smyth) writes: >... >REALLY do is create a new, GOOD object language, and call it, say, ++C, >and use it instead. Besides, the name would then be semantically >correct! :-) Does this imply that we should enhance C-language BEFORE using it?? Wow, thats what I call fast learning!! (or does THAT imply something else... B^) -Mike -- INET : mikhe@majestix.liu.se /// UUCP : {seismo,mcvax,munnari}!enea!liuida!majestix!mikhe /// ARPA : mikhe%majestix.{ida.liu.se,UUCP}@seismo.CSS.GOV \\\/// What SNAIL: Mike Henry, Alsattersg. 3C:20, S-582 51 Linkoping SWEDEN \XX/ Else??
nobody@tekecs.TEK.COM (-for inetd server command) (11/03/88)
>In article <3438@jpl-devvax.JPL.NASA.GOV> david@beowulf.JPL.NASA.GOV (David Smyth) writes: >>I am not convinced that Objective-C is a good way to go: lack of strong >>typing for example. However, it is certainly a MUCH smaller addition >>to C than C++. I received some recent information on Objective-C. Objective-C now appears to allow strong typing. Paul Scherf, Tektronix, Box 1000, MS 61-028, Wilsonville, OR, USA paulsc@orca.GWD.Tek.COM tektronix!orca!paulsc
jima@hplsla.HP.COM (Jim Adcock) (11/03/88)
> At USENIX/C++, I said that C++ is too complex. Much recent net > discussion has added support to this claim. C is basically simple > (declarations and operator precedence are awful, of course). C++ is > incredibly complex. The number of caveats which productive C++ > programmers must grasp is simply too large: must have virtual > destructors, can't have virtual constructors (makes sense, but it is > obscure); when one must use [] on delete, and when they are not needed; > only use multiple-inheritance when you have the source of all classes > back to their roots because a client can introduce bugs which a C++ > compliler won't catch; etc. etc. etc. > > I am not convinced that Objective-C is a good way to go: lack of strong > typing for example. However, it is certainly a MUCH smaller addition > to C than C++. Well, I programmed in ObjC for a couple years, and pretty much all your C++ gripes have their analogies in the ObjC language too, although one might not realize it until one starts trying to write serious code in ObjC. Additionally, ObjC is "simple" because it lacks the complete feature set that C++ is striving for that is needed to solve "all" common programming problems. But if you're writing serious code you still have to address these needs. In ObjC you have to do this by writing hack C code or assembly code based on an understanding of ObjC's underlying implementation in the C language. So you have to understand a hell of a lot of the implementation of ObjC in order to write serious programs in the language. Which in my experience makes ObjC much more complicated to deal with any time. Also, when things go wrong in your programming, C++'s failure modes come much closer to being C-like in nature -- "what you program is what you get." In ObjC its because the phyla tables get confused, or wrong code is generated or something, and all of a sudden your problem to be debugged has no apparent correspondence to the code you programmed. And among object oriented languages, only C++ seems to have the runtime efficiencies to make it viable for most commercially developed code. Certainly, anyone who intends to become shall we say "professional" at writing Object Oriented code is going to have to become proficient in a lot of "new" issues that don't come up as often in C code writing -- memory management schemes, garbage collection schemes, multiple inheritance, container schemes, try/recover schemes, constructors, destructors. Part of this difference comes from the C++ implied claim that there is not just one best way of doing these tasks -- that in more critical cases programmers are going to have to make informed choices as to what memory management schemes to use, whose libraries to use, or when to write their own libraries. So C++ allows these choices. And multiple vendors are writing compilers and libraries for C++ to support these choices. Whereas ObjC only gives you one choice. Some people who seem to be pretty happy working with ObjC are those people who are using ObjC to encapsulate window graphics routines written in C or assembly. In these cases most of the processing time is spend in the low level graphics routines so that the ObjC overhead is less of a problem. I think many "standard" programming tasks will prove to be too slow when written in ObjC unless one seriously hacks at ObjC's underlying implementation in C. This has been my experience. And this leads to some pretty gross code.
gregw@otc.oz (Greg Wilkins) (11/04/88)
In article <3438@jpl-devvax.JPL.NASA.GOV>, david@beowulf.JPL.NASA.GOV (David Smyth) writes: > Face it: the only reason we are talking about using C++ or Objective-C > is because of a desire to be "upwardly compatible" with existing C > code. Note, however, that C++ IS NOT "upwardly compatible" with C, > rather C++ IS A DIFFERENT LANGUAGE! Just try including <sunview.h>, > and you will see what I mean. Or any large C language program! Just try includeing <sunview.h> on any other C compiler, apart from the difference in function prototyping, there are many other objectionable things in <sunview.h> that many c compilers would baulk at!. Its full of comments like {we really must fix this sometime}. Code wise C++ is upwardly compatible with C. But if you want type checking between modules, then you have to add the function prototypes. You can't get something for Nothing!!. Greg Wilkins ACSnet: gregw@otc.oz UUCP: {uunet,mcvax}!otc.oz!gregw |||| OTC || Phone: (02) 287 4862 O/S: +612 287 2862 Fax: (02) 287 4990 Telex: OTCAA120591 Snail: GPO Box 7000, Sydney 2001, Australia
ok@quintus.uucp (Richard A. O'Keefe) (11/05/88)
In article <485@otc.oz> gregw@otc.oz (Greg Wilkins) writes: >In article <3438@jpl-devvax.JPL.NASA.GOV>, david@beowulf.JPL.NASA.GOV (David Smyth) writes: >> rather C++ IS A DIFFERENT LANGUAGE! Just try including <sunview.h>, If this means <suntool/sunview>, I note that some of the files in <suntool/_> have "#ifdef cplus" in them. Specifically, /usr/include/suntool/{ emptysw, fullscreen, gfxsw, menu, msgsw, selection, tool_struct, ttysw, ttytlsw }.h contain "#ifdef cplus" wrapped around function prototypes, as do /usr/include/sunwindow/{ pixwin, pw_util, rect, rectlist, win_{environ, input, struct} }.h Evidently *somebody* thinks that C++ works with these files... Mind you, the copies I looked at were dated 1984, perhaps C++ doesn't like them now.
fischer@iesd.uucp (Lars P. Fischer) (11/10/88)
In article <3438@jpl-devvax.JPL.NASA.GOV> david@beowulf.JPL.NASA.GOV (David Smyth) writes: >I think it was and is a good idea for any new language to generate C as >an assembly language, like cfront does. Making a compiler generate some high-level language is easier than making it generate machine code. If you're going to implement a compiler for some new or experimental language, this is an effective way to go. But please note that this has nothing to do with the language, it's an implementation technique. The AdaVantage Ada compiler for the Mac generates C. The GNU C++ compiler generates machine code. This is all up to the compiler writer, not the language designer. -- Lars Fischer, fischer@iesd.dk, {...}!mcvax!diku!iesd!fischer We must remove the TV-induced stupor that lies like a fog across the land. - T. H. Nelson