Haskell, guarantees and pusillanimity
Many times in the course of my Haskell apprenticeship, I've had conversations of the following form:
Me: I want to do X in Haskell, but the obvious thing doesn't work. How do I do it?
Sensei (usually Duncan or totherme): Oh no, you can't do that! If you could do that, then you could have a transperambic Papadopolous twisted asiatic sine-curve ( Read more... )
Me: I want to do X in Haskell, but the obvious thing doesn't work. How do I do it?
Sensei (usually Duncan or totherme): Oh no, you can't do that! If you could do that, then you could have a transperambic Papadopolous twisted asiatic sine-curve ( Read more... )
Peronally, the problems I think I've had most with SQL don't stem from its lack of expressivity as from its poor integration with the rest of the programming system... Getting no compile time checking over SQL which was all in strings in a java programme really sucked. Also, dumping java data into BLOBs, which are totally inaccessible to SQL queries was annoying....
The usual complaint about SQL is that you can't search for a substring, or a regex within a value. This is annoying, it's true - I don't understand what the reason for those original restrictions were and it's probably the case by now that a database could provide this functionality and still provide the guarantees that make the database worth using - but let's pretend for a moment that they couldn't. In that case, you have to pull everything out of the DB, and do the substring check in your general purpose langauge. Would you be better off without the database? If so, why are you using a database in the first place? It seems likely to me that you're actually gaining a lot from having the DB there, probably as a result of some guarantees it can give you (about concurrency, or guarantees allowing performance optimisations or whatever) - otherwise you wouldn't be using it. If that's the case, then you're not complaining that SQL restricts what you can do (relative to your general purpose language), you're complaining that it doesn't extend what you can do far enough. If the language can be made more expressive without sacrificing those guarantees, then that's great. But if allowing a substring match meant that concurrency didn't work any more, and the database was as slow and memory hungry as your general purpose language - what would be the point?
In the limit case, of course, it leads you to prefer the guarantee of program termination to the expressiveness of Turing-equivalence :-)
If the scale we're thinking of is the one that stretches from 0 guarantees to infinite guarantees (presumably some kind of constant statement, or something?), then I don't think limit case analysis is particularly useful. If guarantees were all I cared about, I'd bury the computer in my back garden - possibly after burning all the bits that would burn. Then I'd be absolutely sure that no bad things were going to happen. If I wanted no guarantees at all, I'd programme with "cat /dev/random > a.out"
The interesting thing about language design is finding sweet spots, where you have the guarantees you want, and the expressiveness you want (and it's not necessarily always a simple trade off between the two).
Reply
I've been having a look, and can't find the specific problem that I'm thinking of - it was some feature that Mat wanted to add to Moblog (I think it was "Comments posted on (posts that you've commented on) since you last logged in") that we found we simply couldn't do in SQL. He had to set up a cron job to create an intermediate table. Possibly this was just a problem with MySQL (which at the time didn't support nested subqueries), but it was pretty lame.
Reply
Leave a comment