The Object Network

Onex

Onex is a mobile app that will enable people to build their own apps directly on their devices.

It offers a new kind of visual programming language that makes building an app as easy as building a spreadsheet but as powerful as the complex native programming languages.

What's wrong with existing app-building programming languages?

Native programming languages like Java or Objective-C and scripting languages like Lua or Javascript are powerful, but not accessible for normal people to just jump in and start creating their own apps:

So app-builders generally offer visual approaches to enable people to more easily build their own apps, such as instruction or function blocks that are clicked or wired together, or "if this then that" event-action style rules:

However, these visual languages are simplistic: they lack the power to express and compose more complex custom applications due to their lacking the ability to modularise and layer the programs.

Further, all of these approaches make it hard to see what's going on with the actual 'stuff' that you're working with: your data. In other words, when programming in these visual languages, you can see the processing functions, the events and the actions, but not the data they work on. This is also true of all the native languages.

What about spreadsheets? You can see the data in them!

Spreadsheets don't have that problem, and are often used by non-coders to build certain kinds of apps. The data in a spreadsheet is the first thing you see, so you always feel in control. The formulae work 'behind the scenes', and can be edited when you enter a cell that happens to be generated that way:

However, spreadsheets are still very limited in their power to express complex applications in a clean and easily-managed way, for two related reasons.

Firstly, they have a continuous, 'infinite' grid into which all your work is placed, but there is no concept of a 'chunk' of related data. You may have it in your mind that this area of the spreadsheet is a cost lookup table, this area is the plan, and this the final costings. But the spreadsheet knows none of that, so can't help you manage those chunks.

It doesn't really know that this column header describes the data in this column: you could move all the data in the columns away from their corresponding headers, and right on top of the data of the lookup table, and the spreadsheet would happily let you.

Secondly the formulae, being embedded in each cell, can't be seen until you click on the cell to expose them, up in the formula bar. It's great that the data is so visible, but it comes at the expense of easily seeing the second most important thing: the functions.

Further, being inside each cell means that formulae are copied again and again as required. And if you want to change them, they have to be re-copied, hopefully into exactly the same places.

The lack of 'chunking' or understanding of the programmer's intended structure, plus the re-use of the hidden formulae by copying (instead of having them in just one place and visible at all times) makes it hard and error-prone to evolve and maintain your program. This is essentially the same issue the above apps had with scaling: inability to structure your more complex programs into modules and layers.

For all these reasons, spreadsheets aren't suited to enabling non-programmers to build complex, general purpose mobile apps.

So what's different about the Onex programming language?

Like spreadsheets, Onex also starts with your data. However unlike spreadsheets, it chunks up and isolates both your data and your formulae into separate 'objects'.

Data objects link up in a structured way, and go on to link to more objects that separately represent the formulae - the rules or the data dependencies.

In the same way that a spreadsheet formula describes how a cell value depends on another cell value, an Onex rule object describes how a data object depends on another data object.

In Onex, you build collections of objects for your data and link them up to each other. You then link data objects to rule objects. These rules describe how the values in those objects depend on the values of those linked.

Several data objects can all point or link to the same rule object, so you only need to change the rule once and all linked objects will now behave differently.

What does it actually look like, this language?

Well, here's a quick intro:

And here's a Todo app:

Will it have input controls, like buttons and date pickers?

Of course, but baby steps .. just being a better spreadsheet will come first!

Will it be able to access on-device data, like the automation apps you showed above?

Next on from this, Onex will allow programs based on your media, contacts, calendar events, sensor values, etc.

This is when the power of the approach starts to shine - opening up your device so you can see and control every aspect of it. Existing data and sensors will be represented by pre-existing objects in lists.

Next?

The next step after the above is to add peer-to-peer networking - direct from one device to another - so that people can both share and connect their Onex apps and write a whole new class of collaborative and multi-player programs.

You share both data objects and rule objects through links to them, so that all you need to do to wire your data together or use another person's rules, is to share a link to them.

You shouldn't stop there, then..

Onex is built from the ground up on a 3D technology, so the next feature will be to allow people create their own 3D games and worlds.

Indeed, at this stage, all the elements are in place to build an open "Metaverse" or global shared VR world, which will run directly between your devices, rather than being centrally owned and hosted.

Internet of Things?

Obviously, Onex would be a great language for everyone to be in full control of their smart home. Rather than conceding your private environment to a remote service, you'd be in full control of the programs running your house and over the data you alone should own. Of course, you can share (directly, peer-to-peer) with other friends and family, if you want.

The core or kernel of Onex is written in a compact and portable language (C) that can actually be run on the devices as an operating system and will be able to run your Onex programs directly on the device.

Surely you're not the only one thinking all these crazy ideas?

Oh no, there is a scattering of other eccentrics and dreamers like me. Here's a list of somewhat related projects with similar approaches and similar ambitions:

Eve - Chris Granger (commercial, funded)

Chris Granger's Eve programming environment has a similar data-first approach and goal of empowering non-coders.

Chorus - Jonathan Edwards (academic)

Jonathan Edwards' work has taken many turns, the latest of which is Chorus. Here's the video and the homepage.

Object Spreadsheets - Matt McCutchen (academic)

There's a university page, a paper and a video.

Kaya/Kayia - David Broderick (commercial?)

This appears to be a commercial product called Kayia, but was introduced in a video as Kaya and appears on GitHub.

Urbit - Curtis Yarvin (commercial, funded)

Watch this video - it describes the goals of their Urbit project, which are very similar to those of Onex.

I wouldn't go much further than that into Urbit, though, if you value your sanity.

When's Onex gonna be ready?

First useful app - with better spreadsheet functionality - will come out on the Play Store just the minute it's useful! Other than that, can't really say. You can watch the weekly progress of Onex on GitHub, though!

Duncan Cragg, 2017

Contact me and/or subscribe to my blog and/or follow me on Twitter.