How Does A4 Compare To Squeak/Pharo?
A4 is an entirely separate implementation of Smalltalk, so there is unlikely to be any shared code (although it's possible that there is a little common ancestry in the codebase itself).
Features & Performance
All three systems are based on Smalltalk, so they're reasonably compatible.
All three systems feel very fast, and they're all quite efficient in their own ways.
Generally speaking, Squeak and Pharo excel in terms of language/library features and "hot loop" performance, whereas A4 excels in terms of portability/embedding features and multi-threaded performance.
A4 might also end up being the better choice for object databases, since it makes it easier to manage a large number of VMs/images in parallel, but this remains to be seen.
I'd like to work with the existing Sqeak/Pharo community and integrate these features into a larger whole, but ultimately there are a few issues that might make A4 continue as a separate project:
- I don't budge on intellectual property, I want A4 to be public domain in the long term (if others want to develop more traditionally-licensed open source versions, that's fine, but I prefer to avoid copyright in any form)
- At least in the short term, A4 will be sold as a commercial product (customers may be able to redistribute it or include parts in other products, but the "upstream" version will come at a price - it won't be an "open source" business model, you'll have to pay for the latest official sources)
- A4 will remain at least partly embeddable, it's designed for use in existing C/C++ applications and it won't become an "all-or-nothing" kind of kit
Other Smalltalk implementations are suitable for many kinds of applications, and will probably remain more suitable than A4 in many cases (due to better "hot loop" performance, larger community, more stability, full/free code availability, etc.). However, there may still be some reasons to choose A4 over other Smaltalk implementations.
A4's main advantages are the ability to embed it's core VM (and also extensions/libraries) in a larger aplication and to use multiple VMs/images within a single application (with the option of using shared memory between them).
Some potential use cases for these features include:
- Multicore C/C++ apps - if your app does a lot of CPU-bound work in C/C++, A4 might be a good choice for writing the "glue code" to manage the underlying algorithms, since it supports threading as well as having high-level language features
- Games - you can have the rendering and input managed from a core event loop, but keep game/level/physics/AI state in a separate VM in another thread, saving that VM to disk whenever necessary (i.e. single-player games get save/load/replay functionality with almost no additional code, but they also get control over it when necessary)
- Desktop applets or app plugins - if your system requires many small app-like programs with their own state, A4 might be a good choice for managing them (however, there is no sandboxing yet, so it's not safe to install plugins from untrusted sources with such a system - although I guess this is usually the case anyway for most plugin-driven apps?)
- Embeded devices - you can use the core VM to add high-level functionality to a device with relatively low overheads (e.g. this should work just about anywhere Linux works, and even in some places where Linux "won't fit" - it doesn't require a filesystem, dynamic linking or a multitasking OS)
In the future, A4 will probably be split into an expert build focusing on these kinds of use cases and one or more specialised builds focusing on specific use cases (e.g. education, indie gaming).
This will allow for a clearer "marketing message" behind each product.