Hacker News Reader

Comment by roenxi | Hacker News Reader

One of the elephants in the room with SQL is that it is one of a small number of popular languages that doesn't use

    function(arg, arg, arg)

It is strange that "SELECT a, b, c FROM schema.table" keeps any aura of respectability. That is legitimately outdated syntax, people don't write languages that way any more. It was a 70s era experiment and what was learned from that experiment is that the style has no upside and comes with downsides. It should be 2 or 3 functions, with brackets.

With full knowledge of SQL, the successful languages that followed it were C/Python/Java/Javascript that use lots of functions and a smattering of special syntax for control structures.

View on HN

Comparing SQL to those other languages doesn't really make sense. Their purpose is different. For what SQL does, the syntax makes a lot of sense because it is a completely different paradigm. I think it's dismissive to refer to SQL as merely a 70s experiment. It is used so widely today still

I think SQL is amazing. There are few technologies within IT that has held up as well as it has. Skills you could gave learned 40 years ago still useful today. I think learning SQL well is one of the best investments you can do in yourself.

What advantages do you think

    SELECT a, b, c FROM d

has over even a trivial modernisation like, say,

    table(d) |> select(a, b, c)

?

Most of the weirdness with SELECT could be fixed by switching the syntax to FROM ... WHERE ... [ GROUP BY ... HAVING ] ... SELECT ... ORDER BY.

Shorter? No use of modifier keys? Just to name two. I think to do a meaningful comparison, more complex expressions should be used, that include joins, group by, order by etc...

There is pretty overwhelming evidence that using modifier keys is an advantage in this sort of thing. Pretty much every other language - possibly all of them - in common use make heavy use of modifier keys in describing what a computer should be doing. SQL is pretty much the dying breath of the attempts to do without them because the syntax is so bad in practice. Even configuration files typically make use of modifier keys.

Losing the explicit link between a function and its arguments is a big deal. Note that even the relational algebra model behind SQL doesn't try to make that sort of silly trade off.

The first statement is pretty close to a sentence in English. A non-programmer is somewhat likely to understand what the first statement means, but is not likely to understand the second without training.

The first example, you can read it and speak it in English.

readability, typeability

It makes formulating more complex queries easier when you can just say it out loud

LINQ in C# supports a function-based syntax for querying. E.g. instead of

   SELECT foo, bar FROM baz WHERE zig = 7

You can write

   db.baz.Where(baz => baz.zig == 7).Select(baz => new { baz.foo, baz.bar });

It does have some nice properties compared to SQL, but it also very quickly becomes incomprehensible. E.g. the join syntax in SQL:

   SELECT baz.foo, wawa.bar FROM baz JOIN wawa ON baz.id = wawa.baz_id

looks like:

   db.baz.GroupJoin(db.wawa, baz=>baz.id, wawa=>wawa.baz_id, (baz, wawa)=>new { baz.foo, wawa.bar} );

I don't think anybody would find this easier, and C# actually added additional custom syntax, so you could use more SQL-like syntax instead of the method-based syntax.

>When Ray and I were designing Sequel in 1974, we thought that the predominant use of the language would be for ad-hoc queries by planners and other professionals whose domain of expertise was not primarily data- base management. We wanted the language to be simple enough that ordinary people could ‘‘walk up and use it’’ with a minimum of training. https://ieeexplore.ieee.org/document/6359709

So they wanted it to be easy for non programmers, more natural language like, so functions and brackets are quite the opposite.

Mixfix syntax is not that weird. Objective-C is one well known language that uses it, for example.

Here is your function(arg, arg, arg)

    CREATE [OR REPLACE] FUNCTION function_name (arg, arg, arg)
        RETURN return_type
    IS
      ---
    END;

Then

    SELECT function_name (arg, arg, arg...) FROM dual;


    SELECT columns FROM xpt where xpt.id = function_name (arg, arg, arg...);

    IF function_name (arg, arg, arg...) = ... THEN ...

well, except "FROM dual" is an Oracle-ism because they require a FROM in a SELECT.

And? Using compiler extensions apparently doesn't bother C developers.

Reply on news.ycombinator.com