Well that worked out pretty well: I have a 3D environment on Android programmed in a simple but powerful declarative language which I've called "Cyrus".
Cyrus basically uses JSON all the way through: from user interface and scene graph to rewrite rules, on the wire and on disk. The Cyrus programming language is essentially JSON itself, as JSON rewrite rules. I've reduced the noise of JSON in Cyrus by taking out redundant double-quotes, square brackets and commas. It looks very nice to me. ...
Well that worked out pretty well: I have a 3D environment on Android programmed in a simple but powerful declarative language which I've called "Cyrus".
Cyrus basically uses JSON all the way through: from user interface and scene graph to rewrite rules, on the wire and on disk. The Cyrus programming language is essentially JSON itself, as JSON rewrite rules. I've reduced the noise of JSON in Cyrus by taking out redundant double-quotes, square brackets and commas. It looks very nice to me.
The Name Cyrus
Now, probably to everyone's confusion and annoyance, I'm always thinking of multiple names for the many things I create around the core principles I'm evangelising. And then changing them all the time!
So I decided to choose a single new name, "Cyrus", for everything, and will endeavour to stick with it this time... I got the name from playing around with the letters of 'cyberspace rules', but will probably claim it stands for "cyberspace rules updating state" or something, because that sounds more impressive.
One advantage of this name is that both academics and regular folk should be able to spell it!
So now NetMash and Fjord are the "Cyrus app" and the "Cyrus programming language" respectively; the Object Network is now just the Cyrus network - a Web of JSON.
Once I have rough consensus and running code, it'll all be exchanging data via the Cyrus Media Type - probably "text/cyrus" for the simplified form and "application/cyrus+json" for the noisy one.
The basic underlying model and architecture implemented in Cyrus are still called "Functional Observer" and FOREST, however.
The Future of Programming
Edd Dumbill has recently described how he sees the Future of Programming.
In that article, Edd offers five categories that he sees as forces driving this, which I'd paraphrase as: concurrency within and between machines; embedded and mobile hardware; data-oriented programming; end-user programming; simplifying the software stack.
I was pretty excited to read this, because it accurately describes the drivers behind Cyrus.
Cyrus in 2013
So I'm now going to spend 2013 explaining to everyone why Cyrus is the next programming language they should try out. And, like I said before, I mean everyone - from kids to grannies, via Business Analysts.
Cyrus is, of course, very new, but even while it's maturing this year, it will still be good for non-critical uses, such as prototyping - especially mobile or distributed apps and sketching out business rules - and for making little fun apps, maybe while learning to program.
Do join the Cyrus Google Group if you want to get involved in any way, or just post a comment below.
If you also think that hacking up 3D worlds on Android could be fun, then join me! Stuff you should expect to play with if you want to get involved includes Java, Android, OpenGL ES 2.0, 3D model creation, hyperlinked JSON and JSON rewrite rules. Creatives, evangelists and inspirers are also very welcome to get involved!
The idea is to make an app (NetMash) that lets people build, mash up, animate and program 3D worlds, shared online and all linked-up, Web-like.
Like creative-mode Minecraft, but adding easy in-world programming and shared online by default. Or maybe a bit like an open, distributed, generic, mobile Kodu (or here), for adults as well as children.
NetMash is intended to deliver creative empowerment to ordinary people. We professional software folk often get stereotyped as geeks, and the creative fun we often have dismissed as in some way unusual. That's a real shame, because such prejudice means that the other 99.9% of the world are simply missing out on the joy of experiencing the most creative and empowering activities humankind has yet invented. ...
If you also think that hacking up 3D worlds on Android could be fun, then join me! Stuff you should expect to play with if you want to get involved includes Java, Android, OpenGL ES 2.0, 3D model creation, hyperlinked JSON and JSON rewrite rules. Creatives, evangelists and inspirers are also very welcome to get involved!
The idea is to make an app (NetMash) that lets people build, mash up, animate and program 3D worlds, shared online and all linked-up, Web-like.
Like creative-mode Minecraft, but adding easy in-world programming and shared online by default. Or maybe a bit like an open, distributed, generic, mobile Kodu (or here), for adults as well as children.
NetMash is intended to deliver creative empowerment to ordinary people. We professional software folk often get stereotyped as geeks, and the creative fun we often have dismissed as in some way unusual. That's a real shame, because such prejudice means that the other 99.9% of the world are simply missing out on the joy of experiencing the most creative and empowering activities humankind has yet invented.
Empowering Families
So, success for NetMash will be measured not just by the fun we're having building it, but more strictly by its first users: which will include my 10-year old daughter, my 13-year old daughter who has Williams Syndrome, their granny and their mum! My wife runs Relax Kids classes in primary schools, so maybe there's an opportunity there to introduce the creative joys of programming to a wider group.
That's my own little world, but I'd also like NetMash to reach people globally that would not normally get access to the creative empowerment of programming.
Empowering the Disenfranchised
Maybe Thoughtworks would be interested in using NetMash in schools that we have contacts with, maybe in a non-Western country where technology and education are often less freely available.
Mobile is already changing the lives of the hitherto disenfranchised, through greater access to communications, finance and healthcare. Before long, the inevitable arrival of super-cheap Android devices means fully global access to advanced, connected technology, and a global demand for all the opportunity that this brings.
I'd like NetMash to be a part of all that, whether it's for a boy in a one-room wooden school, or a girl in the school down the road. Or her granny.
I just re-read my article on the Universe Web. I think it's pretty good. Indeed, to be honest, "programming as Cyberspace building" is where my heart has always been, and I'm all about following my heart this year. Especially if it's more fun, for both myself and others! Or if it opens up new worlds to new people.
In contrast, I don't see "fun" in W3C or IETF activities. Indeed, there's recently been a number of examples of tension in that world, between stabilisation and innovation, idealism and pragmatism, Enterprisey and Webby. Interestingly, all those examples have a "2.0" flavour: HTML5 (Web 2.0), HTTP 2.0 and OAuth 2.0.
My own interests are rough consensus and running code; innovation and pragmatism. Webbiness not in the W3C sense - "Web" Services, Semantic "Web", "Web" Sockets, etc. - but in the sense of "the simplest thing that works". Which is the Web of HTTP (1.1), URLs, JSON and REST, or specifically my FOREST interpretation.
I crave the simple and powerful, the cool and the fun. Which ultimately leads to the kind of thing I was describing as the Universe Web. And to be honest, I'd like to write and code for me, not for my peers and colleagues or for my career.
So, to the pursuit of pure joy in place of compromise, I'll now be focusing my energies on the journey of evolving the NetMash Java server and Android app towards an online, open, hyperlinked virtual world that is programmable in-world by users using simple rules.
Stay tuned!
I just re-read my article on the Universe Web. I think it's pretty good. Indeed, to be honest, "programming as Cyberspace building" is where my heart has always been, and I'm all about following my heart this year. Especially if it's more fun, for both myself and others! Or if it opens up new worlds to new people.
In contrast, I don't see "fun" in W3C or IETF activities. Indeed, there's recently been a number of examples of tension in that world, between stabilisation and innovation, idealism and pragmatism, Enterprisey and Webby. Interestingly, all those examples have a "2.0" flavour: HTML5 (Web 2.0), HTTP 2.0 and OAuth 2.0.
My own interests are rough consensus and running code; innovation and pragmatism. Webbiness not in the W3C sense - "Web" Services, Semantic "Web", "Web" Sockets, etc. - but in the sense of "the simplest thing that works". Which is the Web of HTTP (1.1), URLs, JSON and REST, or specifically my FOREST interpretation.
I crave the simple and powerful, the cool and the fun. Which ultimately leads to the kind of thing I was describing as the Universe Web. And to be honest, I'd like to write and code for me, not for my peers and colleagues or for my career.
So, to the pursuit of pure joy in place of compromise, I'll now be focusing my energies on the journey of evolving the NetMash Java server and Android app towards an online, open, hyperlinked virtual world that is programmable in-world by users using simple rules.
Stay tuned!
Since the announcement by IBM and Linden Lab that OpenSim can talk to Second Life, I've been thinking again about RESTful Virtual Reality.
I'm not the first, of course. Others have been motivated by the same goal: To bring the Web's scalability, linkability and interoperability into Virtual World platforms.
Ultimately, how to use the same techniques as the Web to link Virtual Worlds together into a single, massive 'Virtual Universe'.
Here's how I would architect the Universe Web... ...
Since the announcement by IBM and Linden Lab that OpenSim can talk to Second Life, I've been thinking again about RESTful Virtual Reality.
I'm not the first, of course. Others have been motivated by the same goal: To bring the Web's scalability, linkability and interoperability into Virtual World platforms.
Ultimately, how to use the same techniques as the Web to link Virtual Worlds together into a single, massive 'Virtual Universe'.
Here's how I would architect the Universe Web...
Entities
The Universe Web needs Entities. (I'm going to be capitalising Significant Things a lot here to help the Web comparison - hope you don't mind). There's no need to make the Entity list too complicated since we're not doing online games yet - just a world like Second Life.
Here's a list of different kinds of Entity:
State, Links and animation
Entities aren't exactly the Objects of Object-Oriented programming: they have lots of public State. In a Virtual World, you can directly experience their colour, position, orientation, physical relation to each other, etc., thanks to the local render engine.
The basic structure of the Universe Web is made up of Linked Entities. A tree is Linked to its ground which is Linked to a building which is Linked to its occupants which are Linked to their clothing. Kneebones may even be Linked to thighbones.
Entities are often animated. Actually, Places are generally static, and People generally animate themselves. So, when talking in general, we should look at the animation of Things, like trees, books, birds and clocks.
There are two ways an Entity's animation can be guided: by Laws and by Rules.
Laws
Springiness is a handy Law. For example, tree branches, pages in a book and birds' wings and legs can all have springiness. We can declare a mid-air location in a bird's State and a springiness in its legs, then if the bird lands on a branch, the springiness can trigger the bird and branch waving gently to a halt.
We could even allow a single bird to become part of a flock Entity, where the flock only knows how many birds it has and the coordinates of its centre. Each bird will then be animated by global flock Laws.
The book can have a State of open or closed. If bookness was elevated to a global Law, then a book deciding that its State was now simply closed could trigger the elaborate, springy closing of its pages with a nice 'shlump' sound at the end.
The clock's current time may be set by the clock Entity itself, then the Law of time take over in between the clock updating its own time directly.
A Law can be invoked over an Entity's animation by simply adding the Law's name and parameters to its State. Such Laws can be handled by the physics engine in the same way surface texture is handled by the render engine: States such as 'red' need global meaning, Law applications such as 'springy' need global meaning.
Rules
When a clock reaches its alarm time, it rings. When its wizard master approaches, a magic book may glow and open. Birds fly away from danger (if a fox is too close, fly away from it). In between danger, birds and foxes look for food (if a bird is close, run towards it).
These are Rules. Rules are driven by the Observation of one Entity by another. The fox Observes the bird, the book Observes the wizard. Rules apply to Entity types: fox Rules, bird Rules, book Rules, etc. Rules can guide the animation of an Entity by evolving its State.
State evolution depends on the current State plus the States of the Observed Entities: Rules make an Entity change from one State to the next by taking the Entity's own State, Observing the States of the Entities around that it cares about, then deciding what the next, new State should be. If an Entity changes State, those Entities Observing it may themselves change State according to their own Rules, and so-on.
Links are part of an Entity's State, and Links may therefore change on the application of Rules. In other words, the virtual world may restructure when a Rule is run.
An Entity may either Observe another Entity, or Link to it, or both. An Entity that Links to another needn't Observe it. Trees don't bother to Observe the ground they grow from. Conversely, an Entity that Observes another needn't Link to it. A fox would only Link to a bird if she was lucky enough to catch it. Meanwhile, it is true that there's probably a chain of Links to everything that's Observed.
Unlike Laws, Rules can't or shouldn't be second-guessed, so have to be run 'at source' or 'inside the Entity', then the new State distributed to both the Observing Entities and to all the render engines.
But render engines are actually Observing People Entities..
People are First Class
In Virtual Worlds, we have People avatars: People are first class Entities. People can Observe and can change State, but it's a real user doing the animation, not a set of Rules. Observation and State change by a Person is implemented through the render engine.
Although self-animated, People can still make use of Laws. For example Laws can be invoked to allow gestures to be easier to make and to look better, and to allow People to 'run forward' rather than putting their 'left foot forward, ..'. Avatar skills become global Laws which can be triggered by an avatar's State animated by a user.
The Universe Wide Web
The Universe Web I've just described is a lot like the World Wide Web:
A crucial difference between the Resource Web and the Entity Web is that, here it's another Entity doing the Observation. One Entity transfers its State to another.
It's as if the GET or POST has another Entity 'at the client end'. GET is like an Entity subscribing or Observing; POST is like an Entity publishing or notifying its State to another (an HTML form has a content type, too).
People are just examples of that Entity 'at the client end'. Instead of a user hidden behind a client browser, we have first-class People Entities doing 'GET's and 'POST's: Observing the Virtual World and acting (i.e., changing State) within it. Other examples are foxes and clocks.
Notation and Protocol
There are two open standards we need to have in progress while implementing the Universe Web: the notation and the protocol (our HTML/URI and HTTP).
Firstly, we have to define the notation for Entities and their Rules. Both the State of Entities and the Rules that animate them will be written in the same notation: a Rule talks directly about State. To me, basing that on JSON (rather than XML) is a clear choice. Add inter-JSON Entity Links (essentially UUIDs), then work out a simple JSON Rule language. We will then need to define JSON 'schemas' for the kinds of Entity we would model. These can be written in the Rule language itself.
Secondly, to define the protocol for Entities to Observe or subscribe to one another. It will be a 'symmetric, asynchronous HTTP' - a Peer-to-Peer, Publish-Subscribe protocol. UDP and Multicast stand out for this kind of interaction. A packet will subscribe, a packet will return current State, a subsequent packet will multicast State updates. We can re-use all the HTTP cache headers, only now we can push updates into caches and into render programs. Packets will inevitably end up tunnelled through TCP and HTTP, mind...
This lighter notation, which also breaks the data up into smaller pieces, and this multicast pushing of State change into caches, along with P2P-style operation, will mean the Universe Web scales even better than its parent.
Also, programming declaratively using Rules is both highly productive and further cleanly scalable through parallel processing.
Of course, it will be pretty trivial to allow inter-Web cross-over such as referring to PNG texture images via URL and pulling Universe Web Entities into a Javascript application that subscribes to them via Comet.
Building the Universe Web
So that's my Universe Web. It's basically the same as the World Wide Web and thus as scalable, linkable and interoperable. It comes with added symmetry: Entities, including People as avatars, exchange State in each direction.
It's a two-way data Web, not a one-way document Web.
I've started work on the Universe Web: the notation, the protocol and the implementation (in C, for portability across platforms, including mobile). Contact me if you want to help!
What do all the MAJOR Web 2.0 technologies of 2007 have in common?
Let me list them first:
M.icroformats (including tags) A.jax (including Comet) J.SON (plus YAML) O.penID (plus SXIP, LID, Yadis) R.EST (including Atom, APP)
What these technologies have in common is that they're all lighter than their competitors:
Microformats | Lighter than the Semantic Web |
Ajax | Lighter than Fat Client (!) |
JSON | Lighter than XML |
OpenID | Lighter than SAML/Liberty Alliance |
REST | Lighter than SOA |
...
What do all the MAJOR Web 2.0 technologies of 2007 have in common?
Let me list them first:
M.icroformats (including tags) A.jax (including Comet) J.SON (plus YAML) O.penID (plus SXIP, LID, Yadis) R.EST (including Atom, APP)
What these technologies have in common is that they're all lighter than their competitors:
Microformats | Lighter than the Semantic Web |
Ajax | Lighter than Fat Client (!) |
JSON | Lighter than XML |
OpenID | Lighter than SAML/Liberty Alliance |
REST | Lighter than SOA |
I'm reminded of Tim Bray's Technology Predictor Success Matrix and his appreciation of the 80:20 phenomenon. If hitting the sweet spot of achieving a lot with only a little is the main test of potential, then these five Web 2.0 technologies are all set for success.
So it's no surprise to see Tim supporting Microformats once or twice and even JSON, in spite of his, um, XML background. He also understands and uses Ajax and backs REST (in particular via Atom). Tim has not yet mentioned OpenID, instead referring to SAML and Liberty Alliance (please don't be crass by leaving a comment speculating on the reason for this...).
These MAJOR Web 2.0 technologies should form the basis of the two-way, interactive data Web or the Web-as-a-platform vision that we've all been promised.
However, they will need taking a little further this year, in order to bring them closer together and to make this vision happen in a seamless way.
A synergy between these 80:20 technologies can potentially produce much more than just the 'next version of the Web', if engineered well.
I have already discussed the Subversive Microformat, I've promoted Declarative Ajax and currently I'm slowly working up to Symmetric REST.
Next up, I'll be asking you to consider a web of JSON Microformats and ways to merge hCard and OpenID into active user personas - even avatars...
I'll tag this acronym as 'rajmo' instead of 'major', for obvious reasons.