I remember as a child playing with the remote control exploring what I can do to control a piece of electronics equipment, or reading through the manual of a calculator finding out what it can do. Humans have the desire to control and customise their experience.
From the earliest days of computing there was this idea that any user could control the computer. Programming languages were in fact a means for the user to communicate with the computer. From the beginning it was understood that computers would need to understand natural language for users to be able to control computers without learning a specialised language. Even in the 1950s languages like COBOL (Common Business-oriented Language) allowed users to write business logic in a more accessible language. In 1997 Gartner estimated that COBOL ran 80% of business applications (I suspect it is substantially less now).
Another great step forward in user programmable languages was the introduction of SQL in 1974. Short, user-readable statements could replace multiple lines of equivalent programming language code.
5 Generations of Programming Languages
Languages were defined in terms of generations:
- 1st generation language (1GL) — Machine code
- 2nd generation language (2GL) — Assembly language
- 3rd generation language (3GL) — e.g. Java, C, etc.
- 4th generation language(4GL) — SQL
- 5th generation language (5GL) — Natural language, Siri, Google
The generations are now a bit obsolete as they were defined in the 1960s, 70s, and 80s. But it provides an indication of the goal of programming language designers to one day make programming accessible to any user.
Customisable UI
Development environments took the idea further of not just allowing users to write code but also customise the UI.
Smalltalk (1972) allowed the user to edit running programs. They could edit both the code and the user interface. The Smalltalk programming language wasn’t as user friendly as COBOL or SQL.
HyperCard (1987) probably represents the pinnacle in user editable programs. HyperCard applications were called “Stacks” (i.e. stacks of cards), and users could enter an “edit” mode within HyperCard where they could edit a running app. The user could reposition UI elements, add new elements, etc. The user could also view scripts (in the very easy to read HyperTalk language) attached to UI elements and edit them to achieve a different purpose.
Allowing the user to edit applications has huge benefits:
- It allows the user to achieve what they want to achieve by writing minimal code. The alternative would be to build an entire duplication of the application from scratch.
- It allows more people to be involved with the application development process. Becoming a competent application developer these days is a huge commitment in learning. However, HyperCard was designed to allow users to peep under the curtains, and not be horrified by what they see (compare with “view source” on a web page). This is a very gentle introduction to software development. It also allows people from other specialties, for example music, medicine, etc, to work on apps without requiring the typical commitment in learning the complete application development process.
- It allows other application developers to collaborate. How many versions of a certain type of app have you seen on the app store? There are 1000s of hours wasted by developers duplicating exactly the same functionality to then only provide a small customisation in the experience. What if apps were more customisable and the majority of developers could work on customising existing apps rather than reinventing the wheel?
Open vs Closed Source
Allowing anyone to edit your app implies that at least part of the app is Open Source. However, it does not require for the entire app to be open source. Apps could be developed with two layers:
- A higher level UI layer where users can reposition UI elements and also edit UI scripts.
- A lower level logic layer which may have performance benefits and additional access to native features and provide a some level of security.
Developers should be encouraged to write their UI logic in the scripting language to allow users to edit their apps. They should also be encouraged to architect their apps so that the low level logic is accessible from the higher layer. AppleScript achieved this by exposing a “dictionary” from the lower layer to the higher layer.
Note that HyperCard allowed applications to be “locked” which would prevent users from any kind of editing to the application.
Peeling back Layers
For the user, the experience should be like peeling back the layers of an onion. The layers would be as follows:
- Using the app without any editing
- Editing the “look” of the UI
- Viewing and editing the scripts behind UI objects
- Ultimately the user could drop down to the lower layer and edit in the lower level language
- If this concept was also applied at the Operating System level the user could drop down even further and edit the operating system language (e.g. FORTH)
It’s Turtles all the way down.
Where are we today?
It’s interesting that HyperCard, which appeared in 1987, was the pinnacle of user programmable applications. Since then there has been a steady decline. Microsoft did a great job with Visual Basic and powerful Macro editing abilities in its Office application suite. However, the web largely replaced Visual Basic and Office. The web saw the meteoric rise of Java, which in many ways was a huge step backwards from the more user accessible COBOL language. The web also evolved rapidly intertwining convoluted standards like HTML, CSS, and JavaScript, none of which were designed to build business applications but are the predominant technologies for building them today.
For desktop and mobile applications, Java was initially popular in the 2000s before Apple made a strategic direction towards Objective-C and now Swift. Objective-C and Swift are brilliant languages but not user accessible, neither is the application architected to allow for user editing. In fact Apple banned early apps that allowed users to do any kind of programming within the app itself, completely going against the ideals of HyperCard. Microsoft uses C# and Android Java, which are both 3GL languages and not user accessible.
