We often get a question: why did we design our own language SPLASH?  Why did we not use an existing imperative language, like C, C++, Java, or C#? or a scripting language like Perl or Python? or an easily embeddable functional language like Lua?

Two requirements drove us to designing our own language: predictable latency and ease-of-use.

The first requirement comes from the expected applications.  Consider, for example, a trading application that receives streaming quotes.  The application must respond not just quickly, but predictably.  If it takes 1 millisecond to process a quote, it might be fast enough.  If it takes 100 milliseconds to process a quote, we probably need more hardware.  But if it takes between 1 and 100 milliseconds to process a quote, it's almost impossible to tune the application.  Should you buy more hardware?  How do you test?  What happens if the bad latencies occur during market stress points, as they almost assuredly will?  (For a related argument, see Edward Lee's fascinating article in the latest issue of the Communications of the ACM.  Lee takes the point further: for real-time applications, "time" should be an explicit part of the computational model.)

In many languages like Java, C#, and Lua, it's hard to control response time because of the need for garbage collection.  Our language SPLASH doesn't require full-blown garbage collection.  The language manages memory---the user doesn't have to, as in C or C++---but the language is designed so that memory can be managed with reference counting (no circular data structures, for instance).  That enables predictability, and doesn't require tuning a garbage-collection subsystem.

The second requirement is less technical: we wanted our users to be able to code within the CEP environment as much as possible.  With SPLASH, you don't need expert programmers to write code outside the CEP environment.  Anyone with some background in programming can write SPLASH with its familiar C-like syntax and data structures.  Anyone with a little background can tweak SPLASH code, all within the Studio; you don't need a compiler, an IDE or shell, and the expertise to use them.  SPLASH thus follows the "little language" tradition in Unix.  Of course, if you want to write complicated algorithms, you still have the flexibility of using external Java or C/C++ libraries.  We expect, though, that most specialized event-processing code can be written in SPLASH.

None of the languages that we examined at the time met the desiderata of predictable latency and ease-of-use, and so we designed our own.