Gustavo Lacerda

The standard answer seems to be that SQL was designed to be accessible to laypeople (i.e. like BASIC), but isn't it about time we had a standard database query language for real programmers?

Hey, I like abstruse mathematical formalisms as much as the next guy, but on behalf of everyone for whom a computer is a tool instead of a fascination, I'm mentally giving you the finger right now.

From:

I'm not anti-SQL. I just think we could use an alternative.

From:

I'm not pro-SQL. I just think that disdaining usability (which is how you come off) is asinine.

From:

ps thanks to the user-friendly interface of Google Earth, I've just given you the finger for real---through the crust and mantle of the earth! :-) enjoy

From:

far be it from me to disdain usability.

From:

where? I don't see it.

From:

oh snap!

From:

I agree that it's not really very accessible to laypeople... but it was reportedly designed to be.

My general opinion on this matter is that the kind of syntactic "sugar" seen in SQL is a bad way to address the fact that you don't have a programmer in front of the machine, and that teaching them logic is a good way.

Edited Date: 2009-06-03 09:00 pm (UTC)

From:

oh flip!

From:

hober.livejournal.com

What do you think of CouchDB?

From:

x77303066.livejournal.com

ORMs are a different usage pattern than most databases use. They also kind of suck; I wish there were some decent OODB systems out there. (There are a few but they cost a million dollares).

SQL is verbose but very powerful and quite adequate for writing relational queries. Typically you're not writing long scripts in it, by a programmer's standard, so I'm not sure what the need is for a new database language? Is there anything in particular you don't like, aside from the verbose syntax?

From:

roseandsigil.livejournal.com

Because database researchers aren't programming languages researchers.

Seriously, SQL comes out of academia, and db people are much more interested in things like query planning than language design.

From:

dachte.livejournal.com

SELECT login,uid,homedir FROM accounts WHERE uid IN (SELECT uid FROM finance WHERE balance < 50)

Seems like a pretty nice way to me to think about these things...

Why do you insist that it's not programming and/or it's not for programmers?

From:

wjl.livejournal.com

Because database researchers aren't programming languages researchers.

that's totally not true! I know at least two people who started out as PL researchers before moving into databases :P

From:

xuande.livejournal.com

I've never used CouchDB, but I like interacting with Erlang's Mnesia database. You essentially use a lambda calculus to do so.

From:

lo5an.livejournal.com

Have you read C. J. Date's criticisms of SQL? He's even gone so far as to stop using it for the bulk of his book An Introduction to Database Systems.

From:

puellavulnerata.livejournal.com

I know. SQL is 21st century COBOL.

From:

dachte.livejournal.com

I should note that there is a difference between Relational Algebra and Relational Calculus in SQL - in Relational Algebra you use joins to match things on multiple tables, while in Relational Calculus you describe the relationships you're trying to express - the "WHERE field IN (SUBQUERY)" above is the RC way of doing it.

I may be fishing to figure out if you actually meant anything sensible with the original post - it may be that you're more familiar with RA and have not seen RC in SQL. If so, this is probably because the most popular relational database software (MySQL) is crap and doesn't know how to optimise RC (among other misfeatures) - it tends to do perversely stupid, slow, and memory-hoggish things with RC. Other database engines don't have that problem, and a majority (although not everyone) of DB folk consider it best practice to use RC over RA whenever possible, because it's more clear, more optimisable, and more concise.

See also: Codd's Theorem

Edited Date: 2009-06-03 11:32 pm (UTC)

From:

What would a typed lambda calculus get you? One of the basic ideas of database theory is that queries have a lot of structure which can then be sliced, diced, and chunked in the name of optimization.

I'd think you'd be into that sort of union of theory and practice. SQL has mildly bad syntax because it was the 80s, but it mostly matches its problem domain. Even languages like python and haskell have special list comprehension syntax for doing similar sorts of operations. Those look more like SQL queries than the chain of zip and filter operations you'd do without them.

Possibly what you are really complaining about is the impedance mismatch between SQL and whatever glue language you're using. I don't know why people are happy with this.

From:

it's more that it makes a lot of sense to think of "SELECT" as a sequence of function applications: projections are functions, and so are filters.

(defun select (test l)
        (if (test (car l))
            (cons (car l) (select test (cdr l)))
            (select test (cdr l)))
         ))

From:

I almost said that! (I was thinking FORTRAN, but I avoid thinking about those languages)

From:

I mentioned in my earlier post, neatly anticipating your point, that most functional languages have found that is NOT a good way to think about select. It hides a lot of the structure that you care about, which typically makes it harder to reason about. Hence, as I said the existence of list comprehension syntax. The general idea behind select and database backends in general is to let the database be a database and the programming language be a programming language. This way, I can use whatever programming language I want with whatever crazy features and syntax and just have the database be a big machine for rapidly performing queries which can be performed rapidly. Is SQL perfect? No. But it makes sense.

That said, Microsoft has largely taken your approach with a C# feature called LINQ which basically encourages you to write queries in C# using chains of filters, which get turned into a combination of actual SQL and client side filters (I think at runtime).

From:

yes, of course, I want query optimization, etc.

Thanks for the LINQ example. It still allows a DB to be a DB and PL be a PL... they just make the syntax uniform (though probably confusing for those who are used to separate syntaxes).

I don't mind that LINQ gets turned into SQL, as long as I don't see the SQL (though it would be more efficient if it interfaced with the DB directly, it sounds like a lot of work).

Do you see anything wrong with LINQ?

From:

wjl.livejournal.com

there's a great deal of work into integrating "SQL-like" query languages into general-purpose programming languages, simply for the purpose of wanting to be able to build up queries in some sort of structured fashion that can be (at least dynamically) checked, as opposed to just consing up strings of SQL and sending them off to a database backend. Wadler's Links is in part about this, if i remember correctly.

i think i generally agree with akiva here, in that i think query languages are a different animal from programming languages, so it's sort of misguided to say something like "why don't we have something based on the lambda calculus?"

From:

Well LINQ is not something I know too much about so I may have the details wrong, but since you filter on an arbitrary C# predicate, I'd guess you can't do the filtering on the database side. Also, personally, I'd rather write something like

select a and b where bar and baz

then
Foo
.filter(x => bar x)
.filter(x => baz x)
.map(x => (x.a, x.b))

From:

well yeah, seems unnecessarily awkward (is that Haskell or ML?).
But I don't think FP has to be awkward in this way. Paul Graham wants to make Arc (partly) for that reason.

Edited Date: 2009-06-04 02:27 am (UTC)

From:

I should clarify that I don't think LINQ is an inherently bad idea. I think making it easier to generate good SQL queries from a higher level language is a good thing (tm), but that there's probably a lot more you can do if you don't start from an existing language.

From:

I like lambda calculus because it lets you express functions and predicates on the fly... something you can't do in imperative paradigms. (Tangentially, most traditional mathematical notation is similarly crippled)

From:

I'd never heard of it. Thanks!

From:

That is an approximation of C# based on what I remember given that I've never written a line of it.

This is already nicer in Haskell where you would write that like

map (\x -> (a x, b x)) $ filter baz $ filter bar $ Foo

but in haskell you'd actually could also do something like

[(a x, b x) | x <- Foo, baz . bar $ x]

which is way better, since it makes the components of the query (well list operation) clear (assuming you recognize the basic bits of syntax) using specially structured syntax.

The arc version, imo, would be most awkward of all, since, as a lisp it doesn't have syntax and so you end up with your usual lispy mess of nested parens.

From:

bhudson.livejournal.com

It bounced off the moho discontinuity.

From:

bhudson.livejournal.com

The little I've seen of LINQ is pretty sweet. As I understand it, there's language support for it, so it's not as dotty as you make it out to be. My friends love it.

It also allows you to do unbelievably insane things that I try to keep from infecting my brain.

From:

Ahhh, there is syntax, but for some reason most examples don't use it.

From:

wjl.livejournal.com

agreed -- first-class functions are great. but i don't think your giving SQL the benefit of the doubt by dismissing it as just another imperative language. if you think of it in terms of filters and maps, it's hiding some powerful features, as noted in akiva's discussion above regarding list comprehensions and whatnot.

i don't think SQL is really imperative *or* functional -- it's a different beast altogether, a query language.

From: