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.
Let's start by exploring why anyone learns any new language. Programmers learn new languages for a variety of reasons:
- 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.
- 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.
- 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.
- 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:
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.
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.
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.
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?