This post originated from an RSS feed registered with Ruby Buzz
by Rick DeNatale.
Original Post: Initial Thoughts on Lion
Feed Title: Talk Like A Duck
Feed URL: http://talklikeaduck.denhaven2.com/articles.atom
Feed Description: Musings on Ruby, Rails, and other topics by an experienced object technologist.
So Lion has been downloaded from the App Store and waits to be installed on my personal MacBook Pro. I'm waiting a few days to see how much smoke appears on the horizon as early adopters run into issues.
There are some interesting aspects of Lion, some of which bring back old memories. This should be a quick top of the head article. But I may well follow up with one or more which go down some of these paths in more detail.
I don't want to come across as one of those old codgers, even though I probably am one, who think everything now has been done before. On the other hand, as they say "past is prologue."
I've been reading John Siracusa's excellent, as usual Ars Technica review of Lion. as I get into the technical details I can't help but think about some of my prior experiences
Lion's new Document and Versioning Model
Lion has a new take on saving documents and the lifecycle of applications. OS X 10.7 now keeps a trail of revisions to documents, provides a Time Machine like UI to view the history, and decouples saving documents from quitting the application. It also saves enough application state to make applications appear as if they never had stopped when they are restarted. All the same documents are re-opened in the state where the user left them, etc. Now where have I seen that before?
I've had the pleasure, well usually a pleasure, of working with a couple of programming language environments which worked like this to a large extent. The first of this was APL, another was Smalltalk. The usual implementation of these languages provides a workspace or image which holds not just the source code of programs, but the actual running state. In both you did need to save the image or workspace before quitting, but both would start up again just where you left things. This was more obvious in Smalltalk since it is a graphical environment so there's more visible state.
Another aspect of Smalltalk was that the source code was managed by having meta-information in the class and method objects in the image which simply pointed to the source code which actually 'lived' in a single file. Whenever a method was saved, or class definition was saved, the changes were simply appended to this 'change log' in chunks, which were just code fragments which could be compiled or evaluated. The browsers just used an index saved in say a method object to determine the offset of the methods source code in the change log.
Of course it wasn't long before people started to build tools to go back and look at, old versions of methods and class definitions. At IBM in the early days, we used a change log browser written by either Jerry Archbald or David N. Smith, actually probably by the pair.
Later things got more sophisticated, OTIs Envy developer provided concurrent access to what was effectively a shared change log and provided both version and configuration control to teams of Smalltalkers. Today Smalltalkers use tools like Monticello which looks to me to be the logical successor to Envy.
Today, many developers, including your humble author, use git as the weapon of choice for version control. A common thread is the use of a write only repository. A little bit more sophisticated than a single linear change log, but ...
Lion's document model appears at first blush to be related. I saw someone speculating on Google+ about whether Lion might be using git. Somehow I doubt it, but I'm sure it was an influence.
The UI in Lion for browsing the history of a document looks pretty cool. I wonder if something like that would work for git?
Garbage Collection
One of the exciting things I had heard about Lion was that it would be improving the recently added garbage collection in Objective-C. As I read the garbage collection section of the Ars Technica report, which comes right after the section on security which got me all excited, my excitement started to fade a bit.
As Siracusa explains it, the Objective-C "garbage collector", which is really called "Automatic Reference Counting" or ARC, looks more like automatic generation of the formerly manual retain and release pragmas used in Objective-C programs before ARC.
The problem with hybrid languages like Objective-C, or C++, which have both managed and non-managed memory objects, is that the garbage collector can't tell whether a 'pointer' in a non-managed memory block which happens to hold the address inside a managed object space, really references a managed object or not, it might just be an integer, or a consecutive run of bytes in a string.
The real memory kicker for me was when in this section Siracusa pointed to a a series of articles he has written for Ars over the years, calling for Apple to move from Objective-C to a language or languages with truly automatic memory management.
Siracusa uses Apple's Copland operating system project, as an example of failure partially caused by not having automatic memory management when it is called for.
The predecessor of Copland was Pink, which was to be the new Mac operating system written in C++, and providing an application API in the form of a framework. There were lots of such plans floating around the industry back then, Microsoft had a similar project, and IBM was looking at all of these, along with Steve Jobs NeXTStep. Because of what I was doing at the time, I found myself on a series of IBM corporate task forces, and I got to visit the Pink developer team, which was cool since they were living in the Bandley 3 building which had been occupied by the band of pirates put together by Steve Jobs to develop the original Macintosh. A lot of those goodies were still there, including the Bösendorfer grand piano.
I had some interesting meetings with lots of interesting people at that time, including Steve Jobs, and Bill Gates.
In talking with the Pink developers, it was obvious that they were suffering from a lack of GC, they talked about all the rules they had for using C++ constructors and destructors at method interfaces, which led to a lot of code bulk, and sub-optimal performance. That's a whole story in itself, but I totally agree with Siracusa here.
For what it's worth, Apple pushed Pink off onto a new joint venture with IBM called Taligent, with IBM investment and management. Taligent eventually failed. In the meantime, what was left of Pink at Apple morphed into Copland, only to be killed when Ellen Hancock, who I used to work under at IBM before she was lured away to National Semiconductor by Gil Amelio who then left his CEO job at National Semi to become CEO at Apple and lured her away again.
Hancock was hired to save Copland but decided it was hopeless, and started a search for a replacement. Eventually NeXTStep was chosen for the replacement bringing Jobs back to Apple.
NeXTStep, which was written in Objective-C is the main gene pool for today's OS X Cocoa.
Original article writen by Rick DeNatale and published on Talk Like A Duck | direct link to this article | If you are reading this article elsewhere than Talk Like A Duck, it has been illegally reproduced and without proper authorization.
Previous Topic
