Before I write about what implementation I have chosen, lets first examine Smalltalk systems I have looked at in the past. In the past when I have looked at Smalltalk, I never found any good alternatives for my grand plans. I had seriously considered creating a brand new implementation based on the Smalltalk-80 specs and details found in the Blue Book.
GNU Smalltalk is an open source Smalltalk that does not heavily focus on the GUI and integrated development environment, in fact they have a pun "The Smalltalk for those who can type." One of the great things I love about the Smalltalk-80 system was the GUI providing its own IDE in the run-time environment. Although being able to run in a headless or text only mode will probably be important while boot strapping an OS prior to having a GUI API available, the lack of a good GUI class library could hinder development once I get a graphical subsystem in place.
In addition GNU Smalltalk's GPL license on the VM would severally limit my licensing options through its viral nature. All though I love open source, I have come to dislike the GPL because of this viral nature. This is why we can't have nice things... ZFS on Linux? Sure there are ways around this, I am blogging from a Linux system running a tainted kernel with a ZFS root. It was a pain to setup, and because of license incompatibilities between the GPL (Linux kernel) and the CDDL (ZFS file-system from Sun) never the twain shall meet; unless someone decides to create a clean room implementation under the GPL. The GPL would be great, if all open source was written against the GPL. I want to borrow what I consider the best ideas from other libraries and systems, some of which may be incompatible with GPL. Most open source licenses are generally compatible with one another BSD, MIT, Apache, CDDL, MPL when it comes to linked binaries and API calls. Because of this I can not allow myself or the code to become tainted from GPL sources.
Another possibility would be Little Smalltalk. However Little Smalltalk is not a true Smalltalk-80 based system. The fact that it is small ( the interpreter is < 1800 lines of code ) would make the system easier to understand as a basis for building an OS on top of. Most links I can find for downloads appear to be broken and the parts I can find appear to be implemented on top of Java. I like Java, but I did not choose to build my system on a jvm, but rather on a Smalltalk-80 like core. This means that Little Smalltalk is not suitable for my needs.
Public Domain Smalltalk (PDST) is yet another implementation of Little Smalltalk. The license is great, having been released to the public domain, I can do what ever I want with it. Like Little Smalltalk, it is relatively small, which would make understanding the core system easier. Unfortunately it does not appear to be actively developed, and most links and references to it appear to be dead.
Squeak Smalltalk is an open source Smalltalk system that is nearly perfect for my needs. It is a self-hosted portable Smalltalk-80 implementation. In fact it is rumored that some of the object instances found in the image were from the original Xerox PARC system. This appears to be the legacy of those original developers of Smalltalk-80, it first went to Apple from Xerox, and eventually Apple released it under an open source license.
The portions of the Squeak code that came from Apple were originally released under the 'Squeak' license, and eventually re-licensed under the Apache License, Version 2.0. Those portions still carry copyright notices from both Xerox and Apple. The remainder is under the MIT License which is very open source license. Squeak is still being actively developed, improved, and used in the real world. There seems to be a good amount of documentation available.
So now my readers, if any, are probably assuming I decided to go with Squeak as my base development platform. That would be close, but no cigar. I had one last desire: an implementation that did not feel like a toy. Large portions of Squeak and its images focus around Etoys. Alan Kay continued working on development of Squeak as a platform for Etoys. Etoys is intended for child education, and is a great idea. I applaud Alan Kay for this work; however because of this Squeak eschews standard GUI interfaces, and feels unprofessional.
That covers most of the Open Source implementations of Smalltalk that I am aware of, so what else can I look at? There is one last free Smalltalk available, Smalltalk/X from Exept Software AG. Although it is not technically open source, it is freely licensed, with a few exceptions. Since I do not plan on making a military system, patenting food, animal, or human genomes, work with genetic-engineering or produce landmines I am free to make a commercial system with Smalltalk/X royalty free. Smalltalk/X includes the C source code and will run on Linux for bootstrapping my OS. The only real problem I have with it is that Exept is a German based company. Most of the documentation links I have found do not have an English page, or the English page is not properly linked. Some can be guessed by changing a portion of the URL /de/ to /en/. This lack of good English documentation is a show-stopper, and I am not even sure if Smalltalk/X is truly self-hosted.
What else is left? The only commercial Smalltalk system I have ever looked at is Cincom's Visualworks. In the past when I have played around with Smalltalk I have either used this or Squeak. Visualworks is a great commercial product. It has nice threading support, great system library and plugin support, one of the fastest and nicest implementations I have ever played with. The problem? It is commercial, the license, royalties and access to the low-level VM source code and internals (or lack thereof) make this a non-starter.
So what Smalltalk implementation did I decide to go with? One I have not mentioned up until now: Pharo. Pharo is a fork of Squeak. It is intended to be an enhancement of Squeak with implementation decisions focusing on agile software engineering practices. It currently uses the same enhanced Cog VM designed for Squeak, but feels like a much more professional system without all the Etoys GUI and design philosophy. These changes are based on differences in the image and source files between a Squeak image and a Pharo image. My understanding is that you can currently take a modern Squeak OR Pharo VM, and the only differentiating factor is what image snapshot is loaded. Down the road as Pharo evolves this backward's compatibility with Squeak may go away.
No comments:
Post a Comment