Ground floor

Do you ever get the feeling like you're in on the ground floor of a technology that is going to make a significant impact? It doesn't have to necessarily be the absolute birth of that technology, though that's probably the easiest time to climb on board. Rather it's when the technology is on the cusp of something great. Whether it be something obvious like a lot of attention suddenly being paid to it, or more subdued like the gradual buildup of industry support, or even when the technology is still undiscovered but answers and solves a difficult problem, the cusp is that point just before rapid growth.

I've been in the right place at the right time to have caught two rising trends as I saw them about to take off. The first was Java back when it was still very new and just gaining momentum. I sometimes wonder what I'd be doing now if I had grabbed hold of that rocket back then. When I entered the industry later, I tried to recreate that sort of energy with Perl, but with the sudden impact of Python and Ruby, Perl's dominance waned.

The second rising trend that I spotted and considered jumping aboard was XML. This was a technology that, unlike Java, didn't do anything. You had to write programs to do anything with XML data. It was just data! I lacked the foresight at that time to really see what XML was all about and the possibilities that it had through the ability to write powerful frameworks to make the most of that data just because the markup was so simple.

Now, at UIEvolution, I believe the technology we've got is something huge. The language itself is up to version 2.0, but there is very little noise about it so far. Being in the cusp is full of energy but not much volume. That in itself doesn't mean that UJML and the UIPlayer are on the cusp, of course, it isn't even really an indicator of such.

What excites me about UJML and UIPlayer is its ability to solve a very common problem elegantly. It allows for the development of GUI applications very rapidly for memory-constrained devices that typically do not have GUI RAD tools. It is a lot like HTML in that much of the language is dedicated to showing things on the screen, but unlike HTML and other static markup languages, UJML is a real programming language with the capabilities you'd expect of one.

The biggest benefit is the introduction of states as first class language constructs. Instead of thinking about your embedded program as a series of flowcharts or object diagrams, you can instead think of it as a set of distinct states and state transitions.

First, this type of state-based thinking allows you to easily design an application. Simply define the screens you expect to show the user. Each screen will support a few selected events which will then transition the screen to either a new state or to a new screen altogether. With the visual element display support, UJML makes drawing your ideas very simple and turning them into active programs simpler still.

Second, since states may be stacked above each other, it is possible to generate a level of polymorphism in an application which is difficult in another programming paradigm. The application itself is one single active object intercepting events. You don't have to have separate active objects waiting for certain events, the UIPlayer will act as a sieve and pass an event to the appropriate state machine or disregard it completely if no state is requesting it. Since this also means that states may overlap each other's handling, certain state machines may be designed to act as "base behavior" while other state machines may override that behavior when they become active. It's quite different thinking than most other paradigms, but it is also very intuitive once you get past the initial awkwardness of trying to implement standard programming paradigms in this language.

The UJML language and the UIPlayer are designed to solve a very common problem. How can I quickly create a program that implements multiple layers of functionality and is also portable across multiple platforms? Competing solutions are Flash, AJAX, and Java, but those also come with different sets of issues and learning curves. Their approach to solving this problem space is different, but the results are similar. What UJML lacks is an IDE which makes writing the code a breeze and also a visual editor which makes laying visual elements out easier. Once those are in place, it is only a matter of getting enough industry attention to push this technology over the edge of the cusp. Whether that will be possible is still to be seen.