Google proposes Logica data language for building more manageable SQL code Structured Query Language (SQL) at scale can lead to unstructured, unmaintainable database code - at least as far as Google is concerned - so boffins affiliated with the biz have devised an open source logical programming language to make SQL more amenable to maintenance. "Good programming is about creating small, …
LDS» I don't know why they decided to use the "penis" operator. Is not gender neutral.
They could mix it with Perl and make it more mixed.
I would've gone with an m-dash myself for the penis operator :–. (that's a period at the end, btw, nothing else)
And we wonder why there aren't more women in IT...
That was my first impression from the example -- it looks like Prolog.
The SQL it replaces is simple enough but then the query is trivial so maybe what's needed is a more complex example. This might lead to the insight that the problem isn't really the language the query is expressed in but rather the structure of the data and the way the query is presented. My experience taught me that many programmers expect a language to provide a solution rather than mechanize a solution -- they'll pose a problem that can't easily be mechanized and then blame the language for not delivering the solution for them.
Seeing as many databases appear to have been "designed" by a squadron of badly behaved monkeys who just weren't good enough to produce the works of shakespeare by randomly mashing keys on a keyboard, it doesn't matter what querying language is used as the usage and performance will be awful.
But then this utter lack of even the remotest bit of skill and technique in even passable database design seems to be the motivator behind most "no-SQL" movements, the majority of whose datasets could be expressed far better and more efficiently in a structured dataset. As for what falls out the end of most "entity" coding generated database and storage systems, it couldn't be get much worse really...
Oh it's better than that, it's much better than that.
They use '==' both for assignment and equality, depending on context.
So, you know, it's like people writing maths where you often lazily say 'f(x) = x^2' to mean 'I am defining the function f(x) to be x^2' and then 'sin(t) = t' to mean 'I am interested in the values of t for which sin(t) is equal to t' rather than 'I am defining sin(t) to be 0 for all t' (the answer to that one is 't=0' of course, which is again not defining t as 0'). Very occasionally people are more explicit but usually not.
Except for some fucked-up reason of their own they've chosen to use '==' for both things instead of being compatible with several hundred years of lazy mathematicians and using '='.
This language is ... not going anywhere, is it?
Yep it's a poor trivial example. Having written/maintained several SQL based reporting systems over the years, often querying unverified data, SQL can get very messy & very quickly as you add complexity. Much of my work was to manipulate the data at the right point in the process to simplify the process, validate the data and end up with optimised queries that ran at acceptable speeds.
So Logica might be a good thing if it significantly reduces the work necessary to do the above but is impossible to tell from this article.
On the other hand, one of SQL's big advantages is that a non-coder can build their own simple (and not so simple sometimes) queries to help them do their job and something like Logica could maybe exclude those users if the SQL interface was walled off.
But I presume Google are looking at this from a perspective of multiple magnitudes of complexity higher than anything I've ever done and I can see that at that level it makes sense to use code that is much more powerful and maintainable (if that actually is the case with Logica).
Short answer? Usually yes.
Rarely are you writing a query in a vacuum. Typically you'll know something about the underlying data, especially when joining -- and you can structure your join logic to avoid inefficiencies. Is my join a simple lookup? Are the underlying columns indexed? If not, which table contains more rows? Am I better off sub-querying first to constrain the comparison set? All these things give you insight into what SQL is going to do to retrieve your results.
My assumption is the Goog thinks Logica is more maintainable because its code structure is more amenable to automated processing than SQL syntax. I... can kind of see the logic there, but only by further assuming that their goal is for automated maintenance rather than human eyeballs.
My first thought was 'how long will this last. I'm not knocking it as I primarily write in SQL and have seen, written long bits of code**, I just want others to give their views on how realistic this is and could it take off.
Basically, is it worth learning?
**Projects often dictate how fast you have to go and this leads to very messy quick fixes just to get a result (thats my defense and I'm sticking to if(haha))
"Is this a flash in the pan"
No, more like a "floater"
Now I can't code my way out of a wet paper bag but I did learn SQL.
For some reason it just made sense. I think it was the "English" style of expression that helped me overcome my mental block on anything resembling maths or logic. The same with Cobol which I also had to learn. As others here have said the example looks to me like the SQL version is more comprehensible. The Logica one has more of a feel of a high level programming language so my mental block comes into play and it all looks very confusing. I would hate to have to work through a more complicated example.
Still having said all that I am not in the target audience for this so others may find it easier to use.
A complex SQL stored proc (SP) can be nice and readable, using lots of other SPs or functions.
This fits with the idea of "small, understandable, reusable pieces of logic that can be tested, given names"
And obviously the use of parameters / named variables.
However there's nothing to stop someone writing a 1000+ line monster SP
Unless logica in some magic way stops that, readability will still depend on the authors coding style
I normally use them heavily, though I did nearly go insane when doing something really easy on Postgres because I didnt realise it allowed SP overloading so you could have lots of SPs with the same name but different arguments so as you were developing and modifying the DB and associated code weird things would happen even though I could swear the code was right. It wasn't until I found out the SQL to list all the SPs that I laughed long and loud and scared the whole office.
Although for me anything ORACLE should normally be avoided, the one thing I DID like about ORACLE SQL was the fact you could have a single package with multiple methods, functions, some public others private. Easier to keep things all together. SQL server the same thing could have 10's of seperate SQL stored procs and functions. Makes to code base a bit more messy.
And yes, once you get over a hundred lines it can become a paid to read. Not really designed to do lots of complicated stuff easilly.
having 16 joins or more in a SQL is a Pain.....
having people design tables without knowing what they are doinf and they having to deal with the consquences afterwards is also a real pain. Not everyone has the option of refactoring a database (OR part of it) to make it more meaningful.
Experience as a sometime DBA stongly suggests that a major source of poor RDBMS performance is that the system designers have no idea of which queries will be the most frequently used and that this information is seldom available to the DBA. This isn't really their fault since very often the system's sponsors and future users don't know this either. The result is that all too often a well-designed RDBMS schema generates a database that runs like a lobotomised snail.
Very often its performance can be hugely improved by merely adding indexes that actually support the queries that the application's logic needs to do its designed task and.or reorder the columns within indexes so the queries return rows in the required sequence without needing to sort then as they are extracted from the database.
Its quite remarkable how much a star schema can be sped up by merely reordering columns in the prime indexes and, of course, this sort of fix doesn't require any of the SQL queries or the code calling them to be rewritten.
Whats needed to improve the average RDBMS performance or maintainability is not a sexy new way of writing queries: instead all that's needed is an SQL interface with an EXPLAIN capability to analyse how any given query will interact with the RDBMS content, structure and query mix plus a DBA who is well enough trained to use the EXPLAIN output to better match the database's physical structure to the queries executed against it.
I've always used SPs for web access - you can normally secure a DB so the web user can only run SPs and not random queries - initially a a security step but it quickly became apparent you could actually write really complicated code by breaking it down into well chosen SPs and objects and end up with libraries of SPs and functions that made life really easy for yourself and isolate the DB structure from the user (or web user) and make quite major changes without fucking up the web interface or the three hundred random copies of excel about the office.
I do wonder whether Logica is another one of these inventions by someone who hasn't read the SQL manual to the end.
They seem to be missing the real reason SQL becomes a problem in large systems - which is that it's usually embedded in a general purpose programming language as strings that can't be analysed and refactored.
The solution is something like jOOQ, which provides an API that has type safety, compile time checking and the possibility of refactoring. I'm sure similar solutions exist for other general purpose programming languages.
Thats what ODBC helps with and JDBC fixes almost entirely, because both generally return columns in the programming language's nearest match to a particular column's data type.
Of course, if the database was "designed" by the sort of numpty who thinks integer values should be stored as character strings, then all you can do is light the blue touch paper and run.
I'm not familiar with ODBC, but JDBC does not solve the "queries as opaque strings" problem, nor does it offer type safety. Something like jOOQ generates mappings by querying the schema, so you go from JDBC like:
ResultSet rs = statement.executeQuery("SELECT foo, bar FROM baz");
while (rs.next()) {
...
}
To jOOQ like:
List<Thing> things = context.select(BAZ.FOO, BAZ.BAR).from(BAZ).fetch(mapper);
Both the query and mapper work in a type safe, compile time checked, manner. If the underlying DB schema changes, it's caught at compile time.
C#'s LINQ uses a similar approach: a programmatic generic query language that can be applied to any backing store that supports it.
Embedded SQL is one of those things that was a neat idea decades ago and has become a maintenance nightmare, particularly when it's coupled with dynamic modification using string concatenation and interpolation, as beloved by PHP coders.
IME, all too often ODBC is used to vacuum data into the application which then does sorting and analysis that should have lived in a SQL query.
I always imagine that the coders that do that must get really frustrated at having to use a database for storage. A database must seem completely pointless if you just think it's a fancy storage place.
It may be the case that:
Good programming is about creating small, understandable, reusable pieces of logic
But you don't (shouldn't) write entire programs in SQL. You can talk about operations on a relational database in terms of algebra (which has some implicit notion of procedure and order) or in terms of calculus (where you define the transformation rather than individual steps). Most people would find it easier to conceive of what is going on in procedural terms and SQL is an expression of that form (firstly JOIN this to that then secondly SELECT a subset WHERE come condition applies) but in practical databases the query optimiser may well reorder the operations to get the best performance so SQL is in reality only an expression of the desired outcome.
Again, in a practical system, you might need to chain some small number of operations together in a transaction to achieve some specific purpose and you might create a stored procedure for convenience, but if it isn't small, understandable and reusable you're doing it wrong.
In any case, given that SQL is just a specific syntax for expressing the basic maths, I'm not sure that simply inventing a new syntax to express the same concepts is going to help the cause of understanding especially if you have users determined to "learn by experience, rather than reading". I can see nothing about:
MagicComment(comment_text:) :-
`comments`(user_id:, comment_text:),
user_id == 5;
with its magic punctuation that is inherently clearer than (note that the CAPS-lock is typically optional):
select comment_text from comments where user_id = 5
[Edit: sorry, it looks like this has all been said already - phone call intervened before "submit"]
> "note that the CAPS-lock is typically optional"
I haven't encountered any RDBMS that insisted on uppercase SQL statements. Most people I know who generate SQL simply use uppercase as a convention to help in distinguishing the SQL from column/table names.
Google's research labs are far from the only culprits coming up with strange and, frankly, questionable "innovations". The trend lately seems to be that "new and improved" replacement utilities are needed that take what has been a fairly easy to read and understand command syntax and transform it from a single line into something that requires multiple lines, braces, odd punctuation which, frankly, hides its purpose behind the new, obtuse syntax. It's hard to escape the feeling that all this seems to be getting done not because the current way of performing function X is broken in some way but, rather, just because it's "old".
the whole point of SQL is that it is easy (quick) to parser and optimise on the server side, relative to the time taken to execute.
For further optimisation, a hash indexed cache of execution-plans and cursor handles avoids most of the actual parsing.
where things can be improved is in the area of mapping (to classes), and client side syntax checking.. where C# LINQ has basically got it nailed
from c in database.Customers where c.Id == 5 select c;
=>
select c.* from customers where c.Id = 5;
For repetitive queries, where the parameters are passed separately, parsing time is not relevant.
SQL wasn't developed for the server but as the client interface for non-programmers. It was then more or less deliberately knobbled by vendors who wanted to be able to push their own proprietary solutions.
SQL was designed for System/R and copied for DB" and by Oracle. Even in DB2/MVS embedded SQL, the SQL was still sent (and stored) on the database server during bind.
Nobody loves it, but at least you don't have to explain "void" in Java or { } ({ and } were originally to save space versus begin/end or do/end
SQL is a nightmare to parse!
Large numbers of keywords to support.
Inconsistent grammar (sometimes "var = x " sometimes "(var1, var2) (x, y)"
Massively recursive you can place another "select" almost anywhere.
Really inconsistent as in you cannot place another "select" just anywhere.
It can also be tedious to write matching lists of variables to lists of parameters or values is just plain error prone.
Codd hated SQL! It took the beautiful mathematically provable relational algebra and turned it into a messy natural language with all its ambiguities and opportunities for misunderstanding.
Here are a few examples of SQL parsers:
https://github.com/antlr/grammars-v4/tree/master/sql
Most of these come in at 2000 plus line of ANTLR code compared with a language like smalltalk with comes in at 104 lines of code.
The grammar is large because of the number of keywords, but those keywords enable it to be single-pass. I don't particularly like it, but I do like the fact that I can use any parser engine from yacc to antlr to parsec, and haven’t had to re-learn it for different engines. (I’d change the verb order to match LINQ but only because I like intelisense, and add lambda functions)
It was inspired by DL1, but it works.
Views! Was going to post exactly this. An RDBMS already has all the moving parts needed to make modules. Stored procedures and packages are discussed above.
SQL is complicated because the tables and columns are domain-specific. By trying to turn SQL from a declarative language into a procedural language, Logica is just going to require that a database become a collection of generic tables with cookie-cutter columns. See for example SharePoint lists. Otherwise I don't see how Logica could even work. But hey, at least they can save their database in Github.
I'm not a fan of excessive use of punctuation and line-noise languages. That's actually one of the things I like about COBOL; now that the Great Character Shortage is over, we can actually write things rather than expressing everything in half-assed ad hoc symbolic notation.
Symbolic notation has its place, of course. Mathematics would be dreadful without it (a point Beckmann makes nicely in A History of Pi). But programming is not mathematics, and in most problem domains only rarely involves much in the way of mathematical expression. A great many of the punctuation-constructed operators in popular programming languages would be more readable, and as you say easier for many people to use, if they were expressed using words.
However, these facts have yet to discourage the punctuation diarrhea that affects language designers.
(On a marginally related note, there's a fascinating article in a recent CACM about the design of the new French keyboard layout. The designers included programming as one of their use-case domains. The piece is really worth reading, though; it covers everything from usability studies to QAP optimization.)
I assume this is the usual IT-opinion meaning of "doomed", i.e. "I don't like it but it will persist for decades after I am long gone".
FORTRAN, COBOL, assembly, all 3GLs, mainframes, UNIX, command lines ... why, some days it seems everything in IT is doomed. Or so we've been told. We're surrounded by the technological walking dead.
And yet they continue to shuffle along.
Wake me when it runs on MSSQL, PostgreSQL, and even SQLLite
A research project with no manual, a few examples only some of which appear to be better expressed in Logica than SQL is not entirely enticing.
SQL can be a real pain to write at times, but I'm not immediately seeing this as the solution.
Why do we have twist SQL like this? Just so some developer can masturbate over making their mark. Sorry but very few people will ever get to invent a computer language that will go the distance, most will simply die out. Right now the main front runners are Rust, Go and Python, they've got enough to have kept them alive for the last 15 off years. Prior to that you have the old guard of C, C++ and Java ( and their bastard offspring C# ! ) , there are a few others but apart from those primary 6 most languages are dying off slowly. Here's the thing, Rust, Go and Python only work so well 'cos they learned from C, C++ and Java! Take Perl, once the golden boy of scripted langauges, now floundering while it's governing council loses people and can't stop in-fighting and itself fights to remain relevant in modern times.
So we come to someone trying to slap make-up on the SQL pig. SQL is not perfect but it works, simple easy to learn syntax, it has worked fine for decades and with a few adjustments still more or less does the job but someone feels they want to make their mark. Mark my words, this project will be dead with 2 years and will simply be yet another small mention in computing history if it's really lucky. Hell, even "brainfuck" will most like make more of a mark on computing history than this.
Most Linux systems are Android, and most Android devices use on-screen keyboards, and probably most of those don't make backquote available with a single (short) keypress.
But, yeah, standard US-ASCII keyboard layout has backquote as an unshifted key, and US-ASCII doesn't have dead keys, so it's just one keypress for those of us using one of those.
"This inherent resistance to decomposition of logic into bite-sized pieces is what leads into the contrived, lengthy queries, the copy-pasted chunks of code and, eventually, unmaintainable, unstructured (note the irony) SQL codebases"
I should have said what leads into contrived, lengthy queries is the real-world complexity that one has to model. If you can stick to C.J. Date's parts-suppliers or parts-suppliers-warehouses tables in Introduction to Database Systems, the queries will be only so long.
I mean common which one would you prefer? And less typing
--Google new crap with :- ==
MagicComment(comment_text:) :-
`comments`(user_id:, comment_text:),
user_id == 5;
--SQL
SELECT comment_text FROM comments WHERE user_id = 5;
# Pandas
comments[comments["user_id "] == 5]
SQL still has a place for quick queries, join and reporting but Python has full functions, classes, unit testing available!
Maybe I'm long in the tooth - no, I AM long in the tooth, but I don't understand a bit of this new Google thing.
It makes no sense, where the SQL does....
SQL is not going to die..... comments about long obtuse SQL statement (and I work with plenty) are valid, but then that's why you have things like CTEs in MSSQL to help break it out, without abstracting death with nested views. (USE WITH CAUTION MIND!)
Whatever you code in, you WILL have to tailor to nuances to get maximum performance out of a query.
This 'Logica' is a solution looking for a problem, and it's doomed from the beginning.......
The 'problem' they seem to be trying to fix isn't SQL's readability but how it's not componentised. If you want a big reporting query for example, generally a single dev will have to write the whole thing because you can't just re-use little snippets (unless you have a really well designed database and you really know what you're doing).
It seems to me that they want devs to be able to pre-define little bits of logic that other devs can then collaboratively drag and drop into a big query without having to actually understand what they're doing.
Because, you know, having to actually understand what you're doing with code and data is /hard/ and all code should be able to be worked on by all devs *shrug*
As for comparing the two languages, I despair. SQL *is* arcane, old-fashioned, and can feel intimidating and restrictive at first. But bloody hell it's actually easy to follow and is amazingly powerful - well beyond what you expect from first impressions.
"pre-define little bits of logic" - congratulations, you've just invented the CREATE VIEW statement...
Once you realise a VIEW is just a macro, a lot of things suddenly make sense about SQL. Devs can boil all the complex logic and joins into views, then business users get flat "tables" of exactly what they need.
When you start digging deeper into SQL, it is a testament to how right Messrs Boyce and Codd were when they designed the relational model back in the early 70s. IIRC however, Boyce and Codd thought SQL was an abomination and were proposing a query language more like this Logica (but with ALGOL-style unkeyboardable operators). I'm glad they lost that argument!
Logica used to be a UK IT company.
I visited the Logica CESG Licensed Evaluation Facility (CLEF) once and got a free mug.
Later they offered me a job, but I didn't want to sign away my rights under the working time directive, and disliked the clause that said I could be dismissed immediately with no compensation were I ever to be detained under section 7 of the UK's mental health act.
Seriously, though, who owns the rights to the name "Logica"?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
