My Bets on SQL

I intentionally separated my bets on SQL, the language, from my bets on relational databases. These two are well decoupled and that’s why I believe they will start evolving separately. Let me address the obvious first:

SQL will become the COBOL of the 21st century.

When I started learning programming in the mid/late 80’s, I heard of COBOL, but I never got to know anyone who was programming in it, nor had I seen any COBOL code. So I, like the majority of my generation, thought COBOL was something ancient that no longer existed. My perception of COBOL turned around in the late 90’s during the Y2K bug madness when large corporations, banks in particular, were recruiting COBOL programmers offering insane wages. It appeared that critical products written in COBOL existed and their customers were not looking to retire them. Now that more than 10 years have passed since then, I still keep hearing about organizations using mainframe computers and running software products written in COBOL.

Given that schools have not trained students how to program in COBOL for at least 20 years, I assume the wages offered to the “COBOL dinosaurs” who are still on the job have only gone up. SQL is slightly different – schools do teach it and developers are aware of its importance to customers, but for some unknown reason the majority of them choose to ignore it as a career path. One may argue that the number of qualified SQL developers is much larger than the number of qualified COBOL developers and therefore a shortage is unlikely. However, data acquisition and data processing are critical for every mid-size and large organization. As the volumes of data that organizations acquire and process grow, so does the need of innovation in this area – the software products that do that are constantly upgraded and refactored. My prediction is that the shortage of SQL developers 20 years from now will be bigger than the shortage of COBOL developers through this past decade. 

My second bet is on the form in which SQL will exist. I see SQL as an early branch in the evolution of functional languages. It is probably the most widely used language where the programmer specifies the desired result and not how to get to it. SQL’s concept is very simple – sets and set operations. If SQL was to be designed today, it would have about 20 operators. That’s what LINQ has. Unfortunately, when SQL was designed over 30 years ago, it was meant to be used by non-programmers. That’s why its operators are combined into a single, verbose, [SELECT] statement. Well, non-programmers never picked SQL. The uniqueness of its syntax made it difficult for programmers too. I admit that having actively programmed in SQL for the last 12 years, I still rarely get away without looking up the documentation. Lastly, each database vendor maintains its own dialect and it is even possible to mix standard and vendor-specific options in the same statement. Given the importance of data processing for our modern civilization, it is time to introduce a new generation of a data query language:

A true functional query language will get adopted by database vendors which database engines will implement natively.

The first keyword here is “functional”. Functional programming and functional languages have evolved dramatically ever since SQL branched off. So a functional language could easily be adapted to sets and set operations. The excitement among .NET programmers about LINQ confirms that. The problem with LINQ is that it is a small band-aid to a big wound – it is a client-side translation of functional expressions to plain old SQL statements. The database servers still expect loosely-typed textual queries. I’m predicting a disruptive change in database connectivity where database servers will expect compiled expressions that represent functional queries.