|
I don't believe it, because I use SQL every day, and I need to tell it which rows to lock when reading, whether to read them in share mode or fully, sometimes I need to help it figure out which indexes to use (of course I also have to manually set up the indexes too), when doing transactions I need to tell it how exactly to isolate the transaction, and I need to be very careful how I order my queries in order to avoid deadlocks. SQL is declarative only when you don't care about data integrity and performance. Maybe a bit better example for this kind of behavior are compilers. They're pretty "declarative" these days. You write what code you want to compile, and the compiler will pass it through a thousand transformation stages, deciding which trick to apply at every instruction, which code isn't really needed and so on. Of course, then you also need to deal with compilers getting it wrong too, so you start tweaking your code with special words like "volatile" and "restricted", mess with compiler options, and sometimes even disassemble code to see why turning the "fast" options makes your code slow. But in general, high quality compilers do this dance way better than SQL. So what's the moral here? Two things. First, calling something "declarative" doesn't really mean anything. It means the language is built on a very thick abstraction that lets the computer do more work than usual, so you can do less work. Second, thick abstractions are leaky. Works for basic cases, past that you'll still end up doing a lot of work, but now you have to fight your computer while doing it, as well. The Z3 Theorem Prover is an interesting toy, but I wouldn't trust it to do anything right in the real world. Much like most Microsoft Research projects, unfortunately. |
If you have never tried it out you should, maybe you will like declarative languages a little bit more afterwards.
[1] http://en.wikipedia.org/wiki/Resolution_%28logic%29