At last year’s ESUG conference, Esteban Lorenzano showed his progress on Mars, a framwork to implement native Cocoa interfaces in Pharo Smalltalk. His goal was and is to provide a way to build native Cocoa Apps without the need to build parts in Interface Builder and load NIBs etc. And I was very impressed by what he showed.
After ESUG, you couldn’t read or hear much about Mars and Deimos (a sub-project for iOS GUIs based on MARS). In his latest Blog post Esteban explains a bit of why that is: He faced a few technical problems that were hard nuts to crack, but it seems he’s back on Track and Mars is going to get real. And what’s even better: he found people to help on the project.
Cheers and Good luck to the team! We hope to code native Mac Apps in Pharo soon!
Objective-C and Cocoa are a nice environment to work in. The nicety of Cocoa comes from the fact that it is an object runtime system rather than a bunch of objects compiled into a running program. A Nib file (or xib file as they are called now) is nothing else than a saved snapshot of instantiated and configured GUI objects. So loading a nib is like loading a Smalltalk image: living objects are woken up and continue running at just the place they were when they were saved.
So Objective-C and Cocoa are very similar to a Smalltalk system. But still lightyears away from the real thing. Apple is doing their best to make it better and better and make it feel like a live object system. The just-released Xcode 4 IDE is a big step forward into this direction. (Side note: The eclipse community is also constantly moving into the object system direction by building something very similar to a Smalltalk image).
The next logical step after the achievements with using LLVM as an intermediate layer below Objective-C would be to get rid of the C heritage of Objective-C. Not only is the fact that you have to put Objective-C expressions into square brackets annoying, but also the fact that you need to convert from base types and structs into Objective-C objects and back a lot more often than a programmer would like.
Rumors of Apple working on a new fully dynamic programming language that runs on top of LLVM and reuses the Cocoa object model aren’t really new, but I think they make sense. And having used both Objective-C and Smalltalk, I sometimes think that Objective-C is quite good, if only their creators had gone one or two steps further and made it not only a poor man’s Smalltalk, but rather a real alternative to it. But back in the 90ies when CPU cycles were expensive, NeXT probably had not many alternatives to preprocess down to C and compile classic C code. Today, the C fundament is the weakest spot of the language, not only in my opinion.
So I hope there’s some truth behind the speculations about a new language. Apple has owned a Smalltalk implementation in the past (it’s now open-sourced and called Squeak), so the new language is probably not going to be Smalltalk, but I am sure it will be very much like it (because Cocoa and Objective-C are very similar to Smalltalk and have proven to be powerful): dynamically typed, a live object system (maybe even image based) and with a pure and easy syntax. Swimming on Apple’s wave of success, this could get very popular, and it will surely feel a lot like Smalltalk.
With LLVM and far over a decade of experience with NeXT Step, Cocoa and Xcode, Apple has all that’s needed to build a great programming language, IDE and object runtime system that’s far superior to what most people out there are using today.
Es gibt ein Leben ausserhalb des Smalltalk-Image. Auf dem Mac gibt es das sogar recht oft, denn ein Smalltalk mit nativer Oberfläche gibt es leider noch nicht, seit der Status von Ambrai ja ein sehr fragwürdiger ist.
Darum, und weil man einfach ab und an auch mal was in Java machen muss oder möchte, ist Eclipse immer mit an Bord.
Heute ist ja Galileo-Tag, d.h. die neuste Version von Eclipse wird heute als offizieller Download freigegeben. Neben vielen Verbesserungen in einigen Projekten, die man vielleicht auch nicht unbedingt braucht, gibt es aber insbesondere für Macies gute Nachrichten: SWT unterstützt nun Cocoa. Bisher wurde nur Carbon unterstützt, was nur unter 32 Bit und damit nicht mit Java 1.6 lief.
Ab sofort können also mit Eclipse und SWT echte Cocoa-Oberflächen gebaut werden, und das auch in 64 bit.
Damit ist meine spärliche Freizeit für die nächsten Tage also verplant, denn es warten ein paar kleinere Projekte auf ihre Cocoaisierung…