4 ms·

"I agree. I haven't been much of a fan of the NeXTstep class library since seeing a review in [a prominent publication of the period] several months ago. I ha

by nrr 17y ago

"I agree. I haven't been much of a fan of the NeXTstep class library since seeing a review in [a prominent publication of the period] several months ago. I have just never been sure what the point of a language written on top of C is... "To be fair, I give all the credit in the world to the NeXT guys, but charging $3500 for a microcomputer without a vast application library and that really has no broad adoption is just not worth it." That said, here's how I see things. (1) 280 North took a broken environment and tried to apply a not-entirely-broken substrate atop it. Is it going to be slow? Sure, but consider also that Javascript is inherently slow to begin with. (Slow begets slower, blah blah, I don't want to hear it. I don't care.) (2) It's a start, and when it comes to 280 North's business practices, I'd be willing to bet that there might very well be a standalone compiler for Objective-J at some point if enough people ask for it. ... if I don't beat them to it first. It's getting close to the point where I'm considering just hacking something together in OCaml to scratch my own itch in this vein. (3) The 280 North guys are smart guys. They listen. Complain. Send them mail.

boucher 17y ago
On point number 2, the compiler ships with the open source project. It's written in Javascript. It runs in the browser, or on the command line. We are planning on getting a new compiler in 2010, and it will still do all those things. It will also be more robust, introduce some sorely needed new features, and with any luck be faster to boot. With respect to point one, I'm not sure anyone commenting in this thread really understands the complexity of optimizing application performance in the browser. On an absolute level, message passing is slower than function calling. But taken in context, that's a small percentage of what happens in an application. Cappuccino, because its an application framework, can make certain assumptions to dramatically improve performance. Assumptions that can not be made here and there by individual app developers. For example, coalescing DOM updates and drawing events on the run loop. Combining timers together to minimize overhead. Delegating events from the document level to prevent unnecessary build up of event handlers. On the tools front, we can strip some dead code from projects, automate spriting of all app resources, target different code paths to different browsers automatically, and a slew of other things. Performance is complicated.

by nrr 17y ago

boucher 17y ago

On point number 2, the compiler ships with the open source project. It's written in Javascript. It runs in the browser, or on the command line. We are planning on getting a new compiler in 2010, and it will still do all those things. It will also be more robust, introduce some sorely needed new features, and with any luck be faster to boot. With respect to point one, I'm not sure anyone commenting in this thread really understands the complexity of optimizing application performance in the browser. On an absolute level, message passing is slower than function calling. But taken in context, that's a small percentage of what happens in an application. Cappuccino, because its an application framework, can make certain assumptions to dramatically improve performance. Assumptions that can not be made here and there by individual app developers. For example, coalescing DOM updates and drawing events on the run loop. Combining timers together to minimize overhead. Delegating events from the document level to prevent unnecessary build up of event handlers. On the tools front, we can strip some dead code from projects, automate spriting of all app resources, target different code paths to different browsers automatically, and a slew of other things. Performance is complicated.