back to article 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, …

  1. Ol'Peculier

    Maybe it's just me, or it's a bad example, but the sample shown looks far quicker and easier to understand as SQL than Logica?

    1. Rafael #872397


      It's not just you.

      I could be interested in seeing how a query with several outer joins would be represented, but not interested enough in googling it.

      I'd also like to be the first to XKCD this board:

    2. Anonymous Coward
      Anonymous Coward

      I would like to see a more complex example, also - and see how it really becomes more readable and "structured" than SQL.

      Also, why the "=="? Niklaus Wirth was right, you need to change the assignment operator, not the equality one.

      1. sgp

        And the ":-" ?

        1. Anonymous Coward

          I don't know why they decided to use the "penis" operator. Is not gender neutral.

          1. Anonymous Coward
            Anonymous Coward

            Penis operator

            My sentiment exactly, unbelievably insensitive towards e.g. penilewise challenged trans males and probably many other minorities yet to be discovered!!1!

            1. Anonymous Coward
              Anonymous Coward

              Re: Penis operator

              It's possible to laugh at a penis constructor without transphobia.

              Why so ashamed to put a handle to your hilarity? Because you know you're being a dick?

          2. deadlockvictim


            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...

            1. Juillen 1

              Re: {}

              Most of the women I know would be guffawing away and joining in the banter.

        2. Anonymous Coward

          :- is from Prolog. All of these languages descend from Prolog via Datalog I think (Datalog is pretty much Prolog without the Turing-completeness, or with less Turing-completeness, so queries are guaranteed to terminate).

          I'm not sure why this is more interesting than Datalog though.

          1. martinusher Silver badge

            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.

            1. Nick Ryan Silver badge

              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...

      2. Anonymous Coward

        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).

    4. AMBxx Silver badge

      Worse than that. What happens when you 'join' multiple bits together - you'll have no way of understanding the efficiency of the final SQL.

      1. PerlyKing

        Re: no way of understanding the efficiency of the final SQL

        Can you do that anyway without looking at the query plan?

        1. sofaspud

          Re: no way of understanding the efficiency of the final SQL

          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.

    5. John H Woods Silver badge

      i've seen a lot of languages in the last four decades ...

      ... and this could be one of the fugliest.

      They're having a laugh, right ... right?

      1. itsborken

        Re: i've seen a lot of languages in the last four decades ...

        I suspect Google wanted this released Apr 1st.

        1. Anonymous Coward
          Anonymous Coward

          Re: i've seen a lot of languages in the last four decades ...

          Is it the new Intercal?

    6. John70

      I was thinking the same thing.

      Also you don't need the semi-colon on the end for SQL.

      I thought Google was creating "flavour of the month" languages by dropping the semi-colon.

  2. Anonymous Coward
    Anonymous Coward

    Will post about this on Hangouts and Orkut

    Do bookies take bets on when Google will abandon yet another project? Asking for a friend.

    1. Korev Silver badge

      Re: Will post about this on Hangouts and Orkut

      I can't picture Google doing that, maybe I'll look in Picassa

    2. Anonymous Coward

      Re: Will post about this on Hangouts and Orkut

      This thing is explicitly a research project. For which mean 'they've already abandoned it'.

    3. itsborken

      Re: Will post about this on Hangouts and Orkut

      You meant abandon it but still take the R&D tax writeoff?

  3. Anonymous Coward

    Bring back QUEL

    Bring back QUEL, that's what I say!!

    1. Anonymous Coward
      Anonymous Coward

      Re: Bring back QUEL

      Is Logica a typo? Caligo (latin) is an actual description ... it's a messy mess.

    2. Charlie Clark Silver badge

      Re: Bring back QUEL

      Yes, returning to the fundamentals of relational calcula would have great advantages, especially as a "wire" protocol betweent the client language and the server.

    3. Peter Gathercole Silver badge

      Re: Bring back QUEL

      Damn. I was going to say exactly the same thing.

    4. Michael Wojcik Silver badge

      Re: Bring back QUEL

      To a first approximation, anything database-related that Michael Stonebraker worked on is worth a look.

      The QUEL article in Wikipedia suggests the language could use some enhancements (like a strict string-matching operator), but it's interesting.

  4. B83

    Is this a flash in the pan

    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))

    1. nematoad

      Re: Is this a flash in the pan

      "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.

      1. Disgusted Of Tunbridge Wells Silver badge

        Re: Is this a flash in the pan

        It looks awful in that example, but I'd like to see a more complex example.

        It might be better.

      2. Nick Ryan Silver badge

        Re: Is this a flash in the pan

        Set based data manipulation is quite different to procedural based data manipulation. This difference alone, and the fact that many don't even know or comprehend the difference, is the problem behind so much database code...

    2. Aladdin Sane

      Re: Is this a flash in the pan

      very messy quick fixes

      So you're the one!

  5. sgp

    To run Logica locally you need Python3


  6. tiggity Silver badge

    All depends on the author coding

    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

    1. Anonymous Coward
      Anonymous Coward

      Re: All depends on the author coding

      But we're not talking about stored procs here, we're talking about database queries. No stored proc in the world is going to address the readability of a query which is several hundred lines long and designed for speed.

      1. Doctor Syntax Silver badge

        Re: All depends on the author coding

        If it's several hundred lines long it needs to be designed for speed.

      2. tiggity Silver badge

        Re: All depends on the author coding

        A stored proc is a query....

        Performance advantage & code reuse as main advantages (plus having code under source control f you go that route on your SPs)

        1. Tom 7

          Re: All depends on the author coding

          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.

    2. Adelio

      Re: All depends on the author coding

      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.

      1. Martin Gregorie

        Re: All depends on the author coding

        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.

    3. Tom 7

      Re: All depends on the author coding

      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.

  7. Anonymous Coward
    Anonymous Coward

    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.

    1. Anonymous Coward
      Anonymous Coward

      Being in strings shouldn't prevent that, more a tooling problem. Not sure if I'm recalling correctly as I don't like the language, but didn't support inline xml that was treated pretty much as code rather than a string?

    2. Martin Gregorie

      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.

      1. Anonymous Coward
        Anonymous Coward

        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 ( {



        To jOOQ like:

        List<Thing> things =, 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.

        1. Michael Wojcik Silver badge

          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.

      2. Anonymous Coward
        Anonymous Coward

        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.

        1. tux_is_god

          "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."

          Seen this for real, dev's pulling data from database and using bubble sort to it in the order they want.

  8. Warm Braw

    SQL resists this workflow

    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"]

    1. Charlie Clark Silver badge

      Re: SQL resists this workflow

      Yes, but FWIW SQL is Turing complete.

    2. rnturn

      Re: SQL resists this workflow

      > "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".

  9. TimMaher Silver badge


    This just seems to be a 4GL a la the Eighties.

    Also, do CGI still own the Logica trademark?

    Rapport anyone?

    1. DrBobK

      Re: 4GL

      Probably the first code I wrote that was used by people other than me was in Fortran and Rapide - the query language for the Logica Rapport database. Easier to understand than Google's new thing.

  10. Steve Channell

    Little late for an April fool joke

    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;

    1. Charlie Clark Silver badge

      Re: Little late for an April fool joke

      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.

      1. Steve Channell

        Re: Little late for an April fool joke

        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

    2. James Anderson

      Re: Little late for an April fool joke

      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:

      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.

      1. Steve Channell

        Re: Little late for an April fool joke

        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.

  11. disgruntled yank


    Maybe someday someone will invent views to encapsulate complicated query logic. Or am I dreaming?

    1. yetanotheraoc Silver badge

      Re: Simplifications

      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.

    2. Michael Wojcik Silver badge

      Re: Simplifications

      Look, I already have a hammer. Stop telling me about this "screwdriver".

  12. Charlie Clark Silver badge

    Backticks for the fail

    Any programming language that requires backticks is doomed because they can be a real problem for non-ASCII keyboards and users.

    1. CrackedNoggin Bronze badge

      Re: Backticks for the fail

      Backticks are used in .MD files (markdown documentation) and Javascript.

      1. Gene Cash Silver badge

        Re: Backticks for the fail

        and LISP...

        1. runt row raggy

          Re: Backticks for the fail

          and difficult to avoid in golang, and ruby.

          1. Charlie Clark Silver badge

            Re: Backticks for the fail

            It's not as if I'm not familiar with them: ```code```, but than on my keyboard they also create è and many people I know consider them to be the same as apostrophes. This is one of the reasons why they were dropped from Python.

            1. Michael Wojcik Silver badge

              Re: Backticks for the fail

              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.)

              1. Charlie Clark Silver badge
                Thumb Up

                Re: Backticks for the fail

                Yes, imagine having to use APL for everything!

    2. Michael Wojcik Silver badge

      Re: Backticks for the fail

      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.

  13. Howard Sway Silver badge

    It should be called RSI

    17 punctuation characters in the simplest of queries, 9 of which require the use of the shift key.

    File alongside the hundred previous attempts to create a "better" query language that have all been worse than SQL.

    1. Anonymous Coward
      Anonymous Coward

      Re: It should be called RSI

      I suppose we should be grateful that whitespace is not significant, although I had hoped that all that died when we got past FORTRAN and into an Algol world .... though somebody did mention Python earlier...

      1. Michael Wojcik Silver badge

        Re: It should be called RSI

        I had hoped that all that died when we got past FORTRAN and into an Algol world

        If only. Consider the original make(1) (Stuart Feldman, 1976), in which the distinction between space and tab is significant. Still true of many of its descendants.

  14. Detective Emil

    Lawyer fodder?

    I suspect that CGI, which bought the venerable UK software outfit Logica in 2012, may still have a vague desire to hang onto its trademark.

    1. Anonymous Coward

      Re: Lawyer fodder?

      Yes, this was what I thought. Did they do any research before thinking of the name, like, I don't know, typing 'logica' into some search engine or other (perhaps they don't have access to a search engine, I don't know)?

  15. BinkyTheMagicPaperclip Silver badge

    'Designed to run on BigQuery'

    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.

  16. Plest Silver badge

    Another "next greatest thing", here we go again...

    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.

  17. druck Silver badge
    Thumb Down


    It uses backticks, smaller and more difficult to see than a single quote and needs two key presses on most Linux systems - just say no

    1. Gene Cash Silver badge

      Re: Backticks

      Two key presses?? My 1997-era Model M has it under the tilde, so it's one keypress.

      1. Michael Wojcik Silver badge

        Re: Backticks

        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.

        1. StuartMcL

          Re: Backticks

          So how much code (SQL or anything) is written on an Android device using an OSK?

  18. disgruntled yank

    Missed this the first time

    "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.

  19. rwill2

    Be real Google - Data scientists and most devs would rather use Pandas or SQL

    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;


    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!

    1. tux_is_god

      Re: Be real Google - Data scientists and most devs would rather use Pandas or SQL

      Don't do much (any) Paython, but can someone show me following in "Panda"

      select c.TXT from COMMENTS c, USERS u where c.USER_ID = u.ID and u.NAME = lower('joe.bloggs');

  20. Fruit and Nutcase Silver badge


    A quick scan down the above comments leads form the opinion...




  21. spireite Silver badge

    This is a joke right?

    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.......

  22. Ross 12

    No no no no no

    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.

    1. batfink

      Re: No no no no no

      Yeah agreed. All code should be able to be created by just finding bits on github and banging them together, instead of understanding what you're doing - right?

    2. alansingfield

      Re: No no no no no

      "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!

  23. Binraider Silver badge

    What the world really needs, is yet another language.

    LOLCODE comes highly recommended, or, for those that enjoy sadistic brain problems, the aptly named brainf*&# is worth a go.

  24. Eclectic Man Silver badge

    Who owns "Logica"?

    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"?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like