David Portas (11/26/2009)
3. Developer productivity. SQL is a seriously deficient language for the 21st century when compared to other languages in the object-oriented world (C++, Java or C#). SQL’s 1980’s style type support, lack of type-inheritence and lack of relation types, relation variables or relation assignment are serious omissions that certainly cost development time and effort on practically every project. Incomplete support for set-based queries and the consequent need to rely on row-by-row processing are another feature of SQL. These defects are why abstraction layers that hide SQL complexity and limitations are so popular today.
This is pure insanity. C++ is probably the most abysmal pig's breakfast of a programming language in serious use today, and comparing SQL (whatever dialect) to C++ is like comparing the crown jewels to horse dung. Maybe if we introduced pointers and pointer arithmetic and coercions between arithmetic types and pointers into SQL you would think we had improved the language? Pure insanity probably wasn't strong enough!
None of C++, Java, and C# makes a decent stab at polymorphism or at inheritance, none of them has classes as first class objects in the language which would be the OO equivalent of SQL having relation variables, so you are barking up the wrong tree there. And C++ doesn't even provide type abstraction ("friend", anyone?).
Take a few examples. The need to eliminate duplicates from queries or from tables without keys are very common requests in forums that deal with SQL problems.
The need to elimate duplicates from queries is exactly the same in relational calculus as it is in SQL - or have you decided (unilaterally - even Date wouldn't agree with you) that we can make do with a subset of relational algebra that doesn't include projection?
Assignment and comparison of tables or sets of rows are two other very frequent SQL problems. Since SQL doesn’t have any straightforward syntax for table assignment or comparison the code has to be written again and again for each new project. RDBMS doesn’t suffer from any of these problems.
SQL has extremely straightforward syntax for adding a rowset to a table, so I don't understand your problem with either table assignment or rowset assignment. It's a pity in fact that rowset and table are considered different and that this is reflected in the syntax, but that's a problem that most relational calculi suffer from too. And yes, it would be nice to have the symmetric difference operator on row sets (or tables, doesn't matter which) in SQL - it would save me a whole line of code (yes, that's one single short line of code) every time I wanted to use it (actually the asymmetric difference would be more useful, but that would mean I had to use it twice to do comparison for equality, so the code saving in the single uncommon instance you have picked would be less).
Inability to support anything other than a few basic types also causes big challenges for developers who are forced to write or duplicate code to emulate native or user-defined types in other languages.
Try supporting Haskell values or even Hope+ values in C++. How do I represent a continuation or a monad or for that matter a table with 1,000,000 rows each about 10,000 bytes long in C++ or in Java or in C# without going down to incredibly detailed low level implementation that I wouldn't have to consider in some other languages (in SQL for the last object named)?
As a very conservative estimate I think it’s not unreasonable to assume a full-time developer writing complex SQL might save 1-2 days per month by using a more full-featured relational language instead. In other words it could be a 5-10% saving on development costs.
Any evidence for this, or is your "conservative estimate" just a number plucked from the top of your head?
If I seem to be confrontational here, that's intentional - David Portas' confrontational and unsubstantiated claim about defects in SQL compared to languages like C++ which contain far more defects deserves a confrontational response.
Tom