kearns@read.columbia.edu (Steve Kearns) (09/13/89)
I am very disappointed with Lightspeed's Pseudo object oriented extensions. I have used C++ heavily; it is a great language which is certainly going to be the next standard. LSC 4.0 is an unfortunate detour along the way. An indepth discussion pointing out the failings of LSC's object system would require much space and effort. Suffice to say that it is a kludge compared to the elegance and thought put into C++. I fear that Think has sentenced themselves to supporting a kludgy variant of C for years to come, even after they eventually support C++, which is inevitable. Note that Lightspeed's set of predefined classes may be nicely designed (I have not studied them closely). However, they would certainly be better in C++. The bottom line is: no serious developer should write code that uses the new Think C 4.0 object oriented extensions. The resulting code will not be portable across platforms, and the code will probably be rewritten for C++ someday anyway. -steve
bertil@milou.cd.chalmers.se. (Bertil Jonell) (09/13/89)
In article <6494@columbia.edu> kearns@cs.columbia.edu writes: >The bottom line is: no serious developer should write code that uses the >new Think C 4.0 object oriented extensions. The resulting code will not >be portable across platforms, and the code will probably be rewritten for >C++ someday anyway. *is* there any real C++ for the mac (other than inhouse apple stuff) available now? Bertil K K Jonell @ Chalmers University of Technology, Gothenburg NET: bertil@cd.chalmers.se VOICE: +46 31 723971 / +46 300 61004 "Don`t worry,I`ve got Pilot-7" SNAILMAIL: Box 154,S-43900 Onsala,SWEDEN (Famous last words)
drs@bnlux0.bnl.gov (David R. Stampf) (09/13/89)
In article <6494@columbia.edu> kearns@cs.columbia.edu writes: >I am very disappointed with Lightspeed's Pseudo object oriented >extensions. I have used C++ heavily; it is a great language which >is certainly going to be the next standard. LSC 4.0 is an >unfortunate detour along the way. > >An indepth discussion pointing out the failings of LSC's object system >would require much space and effort. Suffice to say that it is a kludge >compared to the elegance and thought put into C++. ... This is a copout. There are features of both languages which the other could benefit from. Besides, the smalltalk/Eiffel/Object C camps would probably like to differ with you. I actually find the LSC approach to be a) simpler b) cleaner and c) more intuitive than many things in C++, which make it accessible to a much larger class of programmers. I would hope that LSC would produce a PC version next. I have seen virtually *no* transfer of programs between the non-mac and the mac world, so a "detour" is not such a problem. The mac is a detour in the inevitable march of mediocre computers. > >Note that Lightspeed's set of predefined classes may be nicely designed >(I have not studied them closely). However, they would certainly be >better in C++. > They are nicely designed, and the purpose of a well design collection of classes is that the implementation is unimportant. I don't understand why having them written in C++ is of any value whatsoever. >The bottom line is: no serious developer should write code that uses the >new Think C 4.0 object oriented extensions. The resulting code will not >be portable across platforms, and the code will probably be rewritten for >C++ someday anyway. Get real. The LSC extensions are a powerful tool for using the mac. Since mac code is inherently non-portable anyway, I don't see that it matters. >-steve < dave
kearns@read.columbia.edu (Steve Kearns) (09/14/89)
In article <1478@bnlux0.bnl.gov> drs@bnlux0.UUCP (David R. Stampf) writes: > >I have seen virtually *no* transfer of programs between the non-mac and >the mac world, so a "detour" is not such a problem. The mac is a detour >in the inevitable march of mediocre computers. ....... > Get real. The LSC extensions are a powerful tool for using the >mac. Since mac code is inherently non-portable anyway, I don't see that >it matters. > > < dave Read the trade journals and you will be aware of many programs which are cohabiting both IBM and MAC. Wingz will soon be on both, Microsoft Word shares much, Microsoft Excel, Lotus 123 for the mac is coming, many dbase clones, etc... Several years ago I wrote a sophisticated DRAW program which ported rather easily to Windows. In other words, more and more programs exist on both machines, in order to serve organizations which have both machines. -steve
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (09/14/89)
In article <1478@bnlux0.bnl.gov> drs@bnlux0.UUCP (David R. Stampf) writes: >In article <6494@columbia.edu> kearns@cs.columbia.edu writes: > >>The bottom line is: no serious developer should write code that uses the >>new Think C 4.0 object oriented extensions. The resulting code will not >>be portable across platforms, and the code will probably be rewritten for >>C++ someday anyway. > > Get real. The LSC extensions are a powerful tool for using the >mac. Since mac code is inherently non-portable anyway, I don't see that >it matters. > I absolutely agree. Although there are features of C++ (operator overloading, for one) that I would very much like to have at my disposal, it doesn't really matter to me one way or the other HOW a functional class library is implemented, just that it's usable. I don't see C++ being a speedy development environment, or a stable (and proven) one, on the Mac -- not for at least a year after the initial release (which will be cfront, I am lead to believe) from APDA. Furthermore, the MacApp licensing fee disgusts me, and MacApp will be the C++ class library ... NOT EVEN WRITTEN IN C++. The THINK C language is far from ideal, but I don't think C++ is perfect either. The implementation of OOP environments has a long way to go yet. Right now, I'm enjoying using the THINK Class Library, and appreciate both the presence of source code (NeXT Step == no source) and the licensing fee ($0 per year). Porting a TCL application to C++ will be nontrivial, I admit, but it might not even be worth the effort for years. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
bhamlin@farcomp.UUCP (Brian Hamlin) (09/14/89)
In article <817@mathrt0.math.chalmers.se> bertil@milou.cd.chalmers.se () writes: >In article <6494@columbia.edu> kearns@cs.columbia.edu writes: >>The bottom line is: no serious developer should write code that uses the >>new Think C 4.0 object oriented extensions. The resulting code will not >>be portable across platforms, and the code will probably be rewritten for >>C++ someday anyway. > I'm not sure what this person is getting at - a 'serious' developer on the Mac I would suspect would be writing code adapted and optimized to make use of the extensive and proprietary Macintosh system services. The Object extensions to LS_C are quite minimal - it is the extensive object libraries which are the meat of the new release, and in my experience, have proven to be some of the best application library routines I've seen around. It's limited, but clean, quick and well designed. Perhaps others have had experience with this new system ? I've done extensive work in the environment, and I remain impressed. >*is* there any real C++ for the mac (other than inhouse apple stuff) >available now? >Bertil K K Jonell @ Chalmers University of Technology, Gothenburg >NET: bertil@cd.chalmers.se >VOICE: +46 31 723971 / +46 300 61004 "Don`t worry,I`ve got Pilot-7" >SNAILMAIL: Box 154,S-43900 Onsala,SWEDEN (Famous last words) There has been ongoing dialog concerning the C++ efforts on the Mac - see previous postings in this newsgroup.
macgyver@banana.cis.ohio-state.edu (wilson m liaw) (09/14/89)
In article <3949@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: >In article <1478@bnlux0.bnl.gov> drs@bnlux0.UUCP (David R. Stampf) writes: [....] >I don't see C++ being a speedy development environment, or a stable (and >proven) one, on the Mac -- not for at least a year after the initial release >(which will be cfront, I am lead to believe) from APDA. Furthermore, the >MacApp licensing fee disgusts me, and MacApp will be the C++ class library >... NOT EVEN WRITTEN IN C++. What difference does it make if the class library is written in C++ or not? I know the licensing fee is dumb [IMHO]. But as long as you can use the library from c++, it doesn't matter what lang. the library is in. Mac -=- Wilson Mac Liaw $ Two sure ways to tell a sexy male; Internet : macgyver@cis.ohio-state.edu $ the first is, he has a bad memory. CompuServe : 71310,1653 $ I forget the second :) GEnie : W.Liaw $
siegel@endor.harvard.edu (Rich Siegel) (09/14/89)
In article <6494@columbia.edu> kearns@cs.columbia.edu writes: >I am very disappointed with Lightspeed's Pseudo object oriented >extensions. I have used C++ heavily; it is a great language which >is certainly going to be the next standard. LSC 4.0 is an >unfortunate detour along the way. Factual Error #1: "pseudo" is incorrect: THINK C's object extensions support paradigms which are fundamental to object orientation: runtime binding, and inhertiance. Factual Error #2: ANSI C is the next standard, not C++. >An indepth discussion pointing out the failings of LSC's object system >would require much space and effort. Suffice to say that it is a kludge >compared to the elegance and thought put into C++. I fear that I see. So what you're saying is that you're content to bash something you don't like, but you're not prepared to expend the effort to defend your views. So: why do you think it's a kludge? Why do you think that C++ is so elegant? In my opinion, C++ is a kitchen-sink language, some features of which are very useful, but many others of which are just in there because they seemed like the right thing to have. "Typesafe linkage"? So that the wrong routine gets called just because I pass the wrong number of parameters? "Default parameters"? Just because I'm too lazy to pass the right number of parameters? >Note that Lightspeed's set of predefined classes may be nicely designed >(I have not studied them closely). However, they would certainly be >better in C++. How do you know this, since by your own statement you haven't even looked at them? >The bottom line is: no serious developer should write code that uses the >new Think C 4.0 object oriented extensions. The resulting code will not >be portable across platforms, and the code will probably be rewritten for >C++ someday anyway. Oh my god! I guess I should throw away that code I'm working on, and tell the other major developers who are using Object C to do the same. :-) I'm sorry, net, but I've spent weeks with my head in a tokenizer, and there's only so much I can take. :-| R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "There is no personal problem which cannot be solved by sufficient application of high explosives." ~~~~~~~~~~~~~~~
salzman@randvax.UUCP (Isaac Salzman) (09/14/89)
In article <6494@columbia.edu> kearns@cs.columbia.edu writes: >I am very disappointed with Lightspeed's Pseudo object oriented >extensions. I have used C++ heavily; it is a great language which >is certainly going to be the next standard. LSC 4.0 is an >unfortunate detour along the way. > >An indepth discussion pointing out the failings of LSC's object system >would require much space and effort. Suffice to say that it is a kludge >compared to the elegance and thought put into C++. I fear that >Think has sentenced themselves to supporting a kludgy variant of >C for years to come, even after they eventually support C++, which >is inevitable. i don't believe i'm reading this. C++ is a great language? how many other OOPL's have you used? granted, C++ may very well become "a standard" of sorts (though no programming language has ever, or will ever be deemed the "standard" programming language), but it is surely not because it is great, ellegant, etc. "elegance and thought put into C++"??!! hah!! C++ has to be one of the biggest kludges that exists!!!! it was designed to be a superset of C with classes and inheritance, while still allowing you to do things like messing with pointers and all sorts of type casting that takes away from being truly object oriented. and it's added additional complexity on top of that, and even more ways to hang yourself -- like introducing reference parameters. if you want to use a good clean, simple OOPL, one that really does implement the paradigm properly, look at Eiffel. but I do use C++ -- because it's more available right now for me on more platforms (we are getting Eiffel though for our Sun's), and i like writing obscure code (hey, i'm a C programmer, what can I say :-) and it's fast (GNU C++ on a sparcstation). but I don't use it because it's a great language. far from it. how can you get on THINK C for making what I consider to be a very worthy attempt at bringing OOP to the Mac for C programmers. they've managed to keep things simple and have added just enough to implement some of the important features of C++ (or any OOPL). as far as I'm concerned, THINK C objects are much closer to what C++ should've been, and if you want a comletely OOP langague, write one from scratch. i'm not going to sit around and wait another 6 mo's for APDA to get MPW C++ out there, and to get MacApp headers for C++ another 6 mo's after that. i want to do OOP on my Mac now! >The bottom line is: no serious developer should write code that uses the >new Think C 4.0 object oriented extensions. The resulting code will not >be portable across platforms, and the code will probably be rewritten for >C++ someday anyway. that's a crock. you just lack creativity! :-) i've written a set of macros which i've been using to develop what will be a very serious chunk of code -- that allow me to compile the UN-MODIFIED source in both C++ and THINK C 4.0. so far it's been an extremely successful venture. while i have to constrain myself a little to make up for the lack of function overloading in THINK C (and other minor language differences), the gains far exceed the losses. i just keep my source code out on one of our Sun file servers, mount it on my Mac with Appleshare/AUFS -- and compile it concurrently on both systems with g++ and THINK C. both executables produce the exact same output. and it's no micky mouse piece of code either -- it fully excercizes the inheritance mechanisms and the dynamic binding (virtual functions and such -- everything being virtual in THINK C, which really should've been the case in C++). if anyone's interested, i'd be more than happy to send you a copy of the macros -- or post them to this newsgroup. but no real magic going on here. you'll look at them and realize that it's altogether pretty trivial and that anyone could write this stuff -- a 50 line .h file, that's it. of course an example program and a bit of documentation would be included. it can probably use a little refinement as well.... so hey, if you don't like THINK C, no one's forcing you to use it! just write C code if you want to be portable. or write some macros and write C++ and THINK C compatable code. or use my macros, but you'll probably tell me they're kludgy, so you'll probably want to write your own. and if you're *seriously* interested in OOP, check out Eiffel. -- * Isaac J. Salzman ---- * The RAND Corporation - Information Sciences Dept. /o o/ / * 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138 | v | | * AT&T : +1 213-393-0411 x6421 or x7923 (ISL lab) _| |_/ * Internet: salzman@rand.org / | | * UUCP : !uunet!rand.org!salzman | | | "Object Oriented Programming: Programs With Class!"
mce@tc.fluke.COM (Brian McElhinney) (09/15/89)
In article <60557@tut.cis.ohio-state.edu> wilson m liaw <macgyver@cis.ohio-state.edu> writes: > > What difference does it make if the class library is written in C++ >or not? I know the licensing fee is dumb [IMHO]. But as long as you can use >the library from c++, it doesn't matter what lang. the library is in. Because you can't write a non-trivial application unless you spend a *large* amount of time studying the MacApp source code. It is certainly possible to switch back in forth between languages, but at the intimate level of inheritance it is not much fun. Prepackaged class libraries are great, but you can rarely ignore what you are inheriting from. If you don't need to inherit from a class *then* you can ignore the implementation. Inheriting is much different from simply using a class (such as a matrix class). Brian McElhinney mce@tc.fluke.com
steve@hp-ptp.HP.COM (Steve_Witten) (09/20/89)
/ hp-ptp:comp.sys.mac.programmer / sxe@beta.lanl.gov (Stephen Eubank) / 7:33 pm Sep 17, 1989 / >I've heard a rumor that Apple had patched cfront to >generate Cray compatible C. Can anyone tell me whether this >is true, and if so, whether the MPW version will have this >feature? Or hey, maybe just a Cray cross-compiler :-). >1200 baud -> dislike of cute signatures. Stephen Eubank ---------- This is not tuff to do. As early as v1.1, cfront supported a "+x file" option that told it to read a file of types, sizes and alignments for the various C types for a target machine. Soooo.... all you have to do is type (pardon my Unix here) $ CC +x Craytypes -Fc source.C to produce a file "source.c" that will compile on a Cray. =============================================================================== Steve Witten steve%hp-ptp@hplabs.HP.COM Industrial Applications Center {ucbvax, hplabs}!hpda!hp-ptp!steve Hewlett-Packard Co. steve@hp-ptp "...I'm no fool! Nosirree!..." -- J. Cricket