cox@stpstn.UUCP (Brad Cox) (04/10/90)
In article <10639@portia.Stanford.EDU> grd@portia.Stanford.EDU (Glendon Diener) writes: >What can Smalltalk do that Objective-C can't? Incrementally compile. >IMHO, fast, incremental compilation is a *must* for exploratory >programming, and exploratory programming is a *must* for navigating >through extensive class libraries like the appkit. Let me explain. > Objective-C was never designed as a panacea, but as a tool. It was never intended to 'compete' with Smalltalk (IMHO, tools *never* compete, they just sit around peaceably coexisting, awaiting their intended job. Tool proponents, however, behave differently). Kurt Schmucker and I coauthored a paper for OOPSLA a few years ago titled 'Producer: Translating Prototypes to Production' or something similar, that describes a semiautomatic translation program that converts Smalltalk applications to Objective-C. The idea is to use Smalltalk for prototyping and then automatically convert the code to Objective-C for production. The translation tool, Producer, was released to the public domain via net.sources.misc, and presumably still lives on an archive somewhere. Note that the program is *not* supported, and in my opinion, needs and *DESERVES* further attention to extend it from the proof of feasibility stage where I left it and make it a robust production programming tool.
grd@cm-next-9.Stanford.EDU (glen diener) (04/10/90)
In article <4470@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: >In article <10639@portia.Stanford.EDU> grd@portia.Stanford.EDU (Glendon Diener) writes: >>What can Smalltalk do that Objective-C can't? Incrementally compile. >>IMHO, fast, incremental compilation is a *must* for exploratory >>programming ---stuff deleted--- >Objective-C was never designed as a panacea, but as a tool. It was never >intended to 'compete' with Smalltalk (IMHO, tools *never* compete, --stuff deleted-- Yes, but incrementally compiling ObjC is possible already...the proof: Common Lisp can do it already, through its ObjC interface and foreign loading function. I've hacked together an ObjC app which is foreign-loaded into a lisp image, then launched from lisp. The app then launches a text window and, on command, writes the text to a .m file, creates the .h file automatically (a 7 line awk script), and sends the .m off to cc to make the .o. Finally, a simple lisp call foreign-loads the .o into the currently executing image. One can define and redefine classes at will, on the fly. There are, however, several problems with it, chiefly: - there is no way to remove an already linked class: NeXT has supplied run-time functions to add classes and methods, but none to remove them. If one redefines a class, all objects created from that time on are instances of the redefined class, but the old class lives on, and all previously created objects are still instances of it. (It is possible to go through these old objects and redirect their 'isa' pointers to the new class, but I haven't figured out what pointers to change in order to redefine a class somewhere up the superclass chain of one of these objects--any suggestions?). - the application is tied to lisp. This has its pros and cons, but I find the greatest disadvantage is that I can't run the monster into gdb. Anyway, given that Franz have proven incremental compilation of ObjC is `do-able', wouldn't you like to see the efficiency of ObjC delivered in a Smalltalk-80 or LISP flavors-style environment? That's the tool I'd like to have. -glen diener grd@cm-next-9.stanford.edu