A lot of people ask me why I invented Kinetic Rule Language (KRL) instead of just using an existing language. There are a lot of answers to that question, but I want to get to some specifics.

Tools shape how we think and work. I learned long ago that the best way to think differently about a problem is to create a nomenclature that describes and illuminates the new domain. KRL is a rule-based language that is custom built for the domain of event-based applications that operate on real-time data in the cloud. KRL was designed from the ground up with events and the cloud in mind. KRL provides a number of familiar touch-points for users already accustomed to Web programming and JavaScript but provides a framework for making the most of an evented Web.

Let's start by exploring why anyone learns any new language. Programmers learn new languages for a variety of reasons:

1. The cool factor - some languages are just cool and people learn them because there is a cachet in them. They like the people who program in them. They like the conferences around them. Or they simply are the latest thing.
2. The money factor - some programmers learn a new language because they want to use it to solve a particular problem that the they'll get paid for. Often, your job requires using a particular language.
3. The opportunity factor - some languages are seen as important components of the future. The HTML markup language certainly seemed that way in 1993. Java was viewed similarly about the same time frame.
4. The platform factor - some languages are better for a particular purpose or platform. Lots of people learned BASIC back in the day (way back, in fact) because it was the only language available (other than machine language) on the PC, the TRS-80, and so on. More recently, people learned JavaScript because it is the language of the browser. Learn it or forget working on the browser.
5. The creative expression factor - some languages are more efficient for certain tasks. Some languages are more flexible. Programmers also learn new languages because they like how they look. They enjoy the shear beauty of the expression and the elegance of the code they can write.

Even though I think items (1-3) are important, I'm going to ignore them for now. I certainly think KRL is cool, that there is money to be made with it, and that it's an important language to know, but I want to focus on aspects of KRL that tie into points (4) and (5).

KRL offers developers three primary benefits over other languages:

1. KRL is uniquely positioned to support dynamic data streams and cloud-based service APIs. Web 2.0 was characterized by interactive Web sites that felt like applications. Behind those Web applications were big databases. Relatively static, these pools of data underly the functionality of any sophisticated Web site. We make queries against them when ever we interact with the site.

   In contrast, many modern Web sites--think Twitter, Facebook, and Foursquare--are characterized by streams of data. Real-time data is what makes these sites interesting. Sure there are databases behind them, but the functionality that users value is based on information in motion. RSS was the harbiger of this trend and is still a key piece of infrastructure. With protocols like PubSubHubBub, it participates fully in the real-time information movement.

   KRL is based on events--a notification or message that something happened--and has a sophisticated and robust event expression language built in. Think of this like regular expressions, but for information in motion. KRL rules are seleted based on patterns of events and represent a small chunk of functionality that the programmer has determined should take place when that event expression is satisfied (i.e. when a particular sequence of events have arrived).

   For example, the following event expression is satisfied when an RSS feed contains a story that includes a stock ticker symbol and the price of that same stock goes up by more than 2% within 10 minutes.

   select when rss item content #Stock Symbol: (\\w+)# 
                setting (symbol)
        before stocks price_rise ticker eq symbol && 
                                 percent > 2
     within 10 minutes
   

   This presumes that event streams for the RSS feed and stock data are available, but that's not hard to set up.

   This benefit falls into category (5) from above. KRL is an efficient and flexible way of handling real-time data streams and events. For a more complete explanation of event expressions, see Chapter 3 of my upcoming book The Live Web. I'm happy to share an early draft with you if you like--just contact me.

2. KRL makes building peronalized applications easy. Any application that supports more than rudimentary personalization has to allow for multiple tenants. This usually means creating an identity system, figuring out accounts, setting up login screens, and then keeping track of the entity information for each user. All of that is built into KRL. Creating an app that stores data for each user and behaves differently based on the user is trivial in KRL because there's nothing to do. It's all done lower down in the system.

   This benefit falls into category (5) from above. Building personalized applications in KRL is simply more efficient than in other languages. To see an example of a personalize browser app, install Personal Block List (PBL). PBL lets each user block search results on Google, Yahoo! and Bing. My list is different than your list and regardless of what computer I'm using I see my list. And yet, Ed Orcutt, who wrote PBL didn't have to create any of the infrastructure of code that makes that personalization possible. KRL took care of all of those details for him and even provided built-in persistent variables so that for this application no database was necessary.

3. KRL gives developers the ability to bust out of silos and work across multiple Web sites. More than that, KRL allows developers to bring other information and systems into the mix: voice, SMS, email, and almost anything else that can create a notification of some kind. Go install TomatoFlix which works on IMDB.com, Netflix.com, Redbox.com, and Fandango.com, to see an example of an application that has broken down the walls of the silo to give the user useful information in context.

   This benefit falls into category (4) from above. Writing applications that run on someone else's Web sites requires cross-browser support for the Javascript that runs on those sites and an extension for every browser you want to support. Writing cross-browser JavaScript requires picking the right libraries and using them correctly. KRL makes that problem go away by generating the right JavaScript for the job. More importantly, KBX, the univeral Kynetx Browser Extension works in Chrome, Firefox, and Safari (with support for IE on the way) without the developer writing a line of code.

I believe KRL solves an important class of problems better, more easily, and more flexibly than other languages. What better reasons could there be to learn something new?