Comparison of existing platforms

The goal of zells is to enable Software Literacy by providing a software platform without the incidental complications found in current platforms. The [manifesto] describes these complications in details, although in a rather abstract manner. The purpose of this document is to look at a selection of current platforms more closely and how certain complications materialize in them.

Restricted by my own knowledge, the list of platforms is all but complete and not every complication is discussed for every platform. If you find something missing, wrong or imprecise, please help improving this document. Any form of contribution or feedback will be appreciated.

For an up-to-date list and descriptions of identified complications and how they are avoided in zells, please refer to the manifesto.

Platforms

This list contains a variety of software products and protocols which I all consider to be platforms, since they allow users to create, run and share their own software.

The categories are protocols for platforms that are defined by standards rather than an implementation, operating systems for everything which is located directly between user and hardware, virtual machines for things that could be called programming languages and everything else is considered an application.

The lines between these categories are fluent since it could be argued that some virtual machines behave like operating systems or have well defined protocols and some applications behave like virtual machines.

Complications

Set-Up

Getting from zero to developing, knowledge assumed

Usually no set-up required and free download without installation
Free download and simple installation or wide-spread availability
Not free or cumbersome installation
Costly to acquire or complicated to install
 Syntax

Burden of learning a specific syntax

Wide range or interchangable syntaxes available
Multiple syntaxes available
Single, but simple syntax
Single syntax
 Interactivity

Level of direct and immediate interaction with pieces of software

All parts of running system can be directly inspected and manipulated
Easy inspection and more or less direct manipulation
Indirect manipulation but quick feedback or complicated or non-persistent more direct manipulation
Only very indirect manipulation with slow feedback
 Discoverability

Finding useful third-party services

Built-in discovery of service functionality and usage, and new services
In-context discovery of functionality and usage common, good documentation of existing services
Context switch for discovery usually necessary
Very difficult to discover anything
 Dependencies

Using third-party services

Services can be directly accessed without installation or authentication
Direct access without installation but usually requires authentication
Services must be downloaded and managed but tool support is common
Manual download and management necessary
 Serialization

Need for and ease of serialization

Serialization completely automated
Little serialization neccessary, usually automated
Good tool support for serialization, standardized formats exist
Complicated serialization causing much frustration
 Data Safety

Risk of losing software (program or data)

Almost impossible to lose data
Built-in tools for data safety
Third-party tools available and common
Manual data management, tools uncommon
 Segregation

Difference between environments of creating and using software

Software is written and used in the same environment
Software can always be modified with an easy switch in environments
Modification possible but switch is complicated
Writing and running software completely segregated
 Sharing

Giving access to your software to somebody else

Extremely likely that any receipient can access software with almost no trouble
Very likely to access and well-defined group
Receipient must meet certain criteria and expand some effort
Very unlikely to access without considerable effort
 Autonomy

Dependencies on others

No permission required, not controlled by anyone
Controlled by public authority, permission always granted
Controlled by private authority, permission likely to be granted
Depends completely on single, private authority
 Security

Protection of identity and information

Very secure against technological and social attacks, no single point of failure
Effective security, very rare breaks
Unreliable security, breaks are common
No built-in security measures
 Universality

Range of problems that can be solved

No limits of applicability
Very wide range of applicability
Limited applicability
Very limited in usefulness
Virtual Machines
Smalltalk Just download an run the image. Bein a very pure language, the syntax is quite elegant. Every object can be inspected and changed live with immediate effect. Objects are self-documenting, explorable and can be found by text- or example-based search. Third-party modules must be downloaded manually or from a repository. Objects live in the image, no need to serialize them ever. All changes of the image are tracked and can be reverted. The image can get lost or corrupted though. Everything happens in the image Modules need to be filed-out or exported to a repository. Alternatively, the whole image can be shared. Once the image is obtained, accessing the software is very easy. There are many open-source implementations with high compatibility. I'm not aware of built-in security mechanisms. It's only as secure as the operating system it runs on. I'm not aware of any limits. Operating systems, embedded systems and even Smalltalk itself can be written in Smalltalk.
JavaScript All you need is a browser and they're almost everywhere. Many many languages can be compiled to JavaScript these days. While some browser allow pretty good inspection into objects, changes are not persistent. Even experienced JavaScript programmers need to look up every second function name and signature. There are a million package managers but it gets really messy really quickly (left-pad, anyone?). Almost anything keep-worthy must be serialized. But the native JSON format is basically the de-facto standard on the web. Nothing buil-in but easy to integrate with any version control system. JavaScript programs are almost always delivered in source code so how every you run them is not too far away from how you edit them. Just send the files. Everybody has a browser and there are tons of libraries to enhance compatibility. Many open-source implementations are available. The code has full access to the page it's running on. Most security comes from the virtual machine being sand-boxed in a browser. Depends on the interpreter but very wide applicability nowadays.
Python Depends very much on your operating system. There are also packages to ease set-up but it's usually a hassle. Only one syntax but a rather clean one (if you like significant whitespace). There are debuggers which allow to inspect a running system but not make changes to it on-the-fly. Also, the use of a debugger is not very common. Objects are self-documenting and can be dynamically explored in the REPL. Installing packages for Python is too many times very painful. Necessary for persistence but good native support. Version control system adviced but not commonly used, at least in the scientific community. Python programs are usually run as applications which is far away from the editor to change them. If used as script segregation is less. Few people who are not on Linux have Python installed and even if, it might be the wrong version. Putting a module in a completely self-contained package is very tricky. The language itself is open-source and many open-source implemenations available. Only as good as the operating system that runs it. Python can be used for virtually anything.
unison
LiveCode
JVM Download and install the Java development kit (JDK). Many languages can be compiled to the bytecode of the JVM. Programs are usually distributed as bytecode and run as applications. As a typed language, support for capability discovery is usually good but requires IDE. Usage of dependency manager is not common. Object databases are available must most information must be serialized without any good native support. XML is wide-spread and at all times present. Version control system advised. Programs are usually discributed as bytecode and run as applications. Chances that a Java runtime environment (JRE) is installed are good and it's easy to install if not. There are open-source implemenations but Java is still controlled by a single company. Access to the system can be restricted. Java runs everywhere.
Applications
Etoys Just download and run the image. Tile-based is default but can be switched to textual programming as well. Every object can be inspected and changed while running the program. Objects are self-documenting. Help and an object catalogue are included in the environment. Actually I've never come across instructions of how to access third-party software. Everything lives in the image. Only external data must be de-/serialized. Everything is automatically persisted in the image. Recovering old state is difficult though. Writing and running a program happens in the same environment and mode. Projects can be saved as files. The receiver needs to download Etoys and import the project. I'm only aware of a single open-source implementation. Only as secure as the operating system it's running on. Considered an learning environment. Not meant for the creation of complex systems although could be used for anything since it's stil Smalltalk.
Scratch Just open the webpage. Only a single tile-based langauge available. Objects can be manipulated easily while the program is running. Inspectors make it easy to discover capabilities of objects and there is a catalogue for existing software. I don't know if it's possible to access third-party software. Very rarely necessary but very difficult if. Automatic saving but no control over history. Writing and running programs happens in the same environment. By sending a URL. Complete dependency on MIT. Secure through limitation. Very limited usage. Mostly animations and very simple games.
Spreadsheet Requires download and installation. Limited but very simple. Values can be directly modified with immediate effect. Auto-complete for function names and signature. Further information must be obtained from help file. Very difficult to use third-party spreadsheets. Usually no serialization neccessary. If so, CSV is very wide-spread. Manual saving required and difficult to integrate with VCS. No segregation possible. Most users have a spreadsheet application installed. Some compatibility issues are common. Open-source implementations available, but dominated by Microsoft. No security measures provided. As secure as the operating system. Very limited in use cases and permittable complexity.
Eve
Matlab Very expensive licence. Optimized for matrix notation. Sequential debugger, values can be inspected and manipulated. Must be manually managed. REPL history kept for a while. Integration with VCS possible but not common. Software is usually created and run in the same environment Very difficult to package all dependencies. Completely dependent on MathWorks Very restricted use cases but extensions are available.
Flash Download and install application but requires licence. Single syntax available. Objects can be mostly modified directly with immediate effect. Usage of help file and external documentation neccessary, albeit well structured. Very difficult to use third-party software. Necessary to persist data, very painful. Manual saving required and difficult to integrate with VCS. Programs are run with a completely different environment than they are written. Flash players used to be very wide-spread but are decreasing in popularity. Completely dependent on Adobe. Some built-in security mechanisms are provided. Programs are quite restricted in their capabilities.
Operating Systems
Linux Installation process is improving but still a major hurdle. Different interpreters and compilers available. Memory and disk contents can be directly inspected and manipulated but only in a unstructured way. Man pages allow to discover functionality on-line. New tools must be searched externally. Package managers exist but changes are often time irreversible. Data must always be serialized for persistence and exchange. Little standardization of formats. Few mechanisms to guard against irreversible operations. Source code of much software is available and can be edited and executed in terminal. Incompatibilities between distributions and difficult to package all dependencies.
Macintosh
Windows
Android
iOS
Protocols
WWW Web browsers are installed on almost every consumer computer. Wide range available for describing dynamic behaviour but limited for layout description. Elements can inspected and manipulated directly, not persistently though. Functionality of web application can be discovered easily by humans but not by machines. Available resources can easily be used but sometimes require complicated authentication. Everything must be serialized for communication. Standardized formats are available. Not meant to be persistent. Persistence is fragile and must be implemented by application. Software is created and executed in two completely different environments. Just pass along the URL. Theoretically no dependencies exist but in reality host space and domain names are needed. Computer is protected by browser but data in the web is prone to many different attacks. Not suitable for very interactive or time-critical applications.