Why IBM’s Stream Processing Language (SPL) is a good thing… for SQLstream

I have recently researched Infosphere Streams’ “Stream Processing Language” or SPL, after a pretty good talk at a recent SVForum SIG group meeting. As I understand it from the talk, early users of this technology have found that their Version 2.0 Stream Processing Application Declarative Engine (SPADE) programming language has been replaced by the IBM Streams Processing Language (SPL). It appears that this is a result of the productization of a customer software development project, undertaken for the US Government. Although this approach to product development is not uncommon across the industry. In our opinion the result is a cleaner language, yet still some way off being either a standard or SQL.

At SQLstream, from the very outset, we had a fundamental belief that our customers, partners, and end users, would need a familiar programming syntax and language that was standards-based, that is transferable skills and reusable analytics and applications. However, the main advantage of SQL is that it enables you to do all the sophisticated stuff automatically “under the covers” in a way that other technologies are unable to support. Our faith is SQL has been rewards as SQL is not the de facto language for big data stream processing and as well as analytics on static storage platforms such as Hadoop. NoSQL platforms were not SQL to begin with, but as the power and popularity of SQL remained pervasive, there has been a shift ever with NoSQL, from ‘not only’ SQL, to what is in effect, SQL.

So, as other stream processing vendors continue to grapple with their existing Java-based and proprietary language systems, we continue to view SQL as a great thing for our customers and partners.