Re: Imperative Query Languages

On Wed, Jul 5, 2017 at 7:02 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> Downthread, Tom mentions CODASYL, etc, but could have mentioned the
> big daddy, ISAM, and all it's various flavors. Virtually all business
> code was written using it (and much of it still is) leading into the
> SQL era. Code generally looked exactly like your example, except it
> was much more stupid looking being written in (generally) COBOL, and
> added in error handling, which is where the technique tends to break
> down. SQL came about because some particularly smart people realized
> that programmers were writing the same boiler plate code over and over
> again and that perhaps access to data could be generalized and focused
> down to the real problem being solved. This fortunately came about
> before "enterprise developers" and "enterprise tool vendors" were as
> organized as they are today and so was able to germinate into
> something incredibly useful...

To state the very obvious: If you assume for the sake of discussion
that the programmer of a hypothetical imperative query language is
infinitely capable and dedicated, and so is at least as capable as any
possible query optimizer, the optimizer still comes out ahead, because
it is capable of producing a different, better query plan as the
underlying data changes. Of course, it's also true that it's very hard
to beat the query optimizer under ideal conditions.

However, the OP seemed to be describing something that maps imperative
code to a declarative SQL query or something equivalent, which isn't
quite the same thing. The declarative nature of SQL feels restrictive
or at least unfamiliar to many programmers. What is often somehow
missed is that it's restrictive in a way that's consistent with how
the relational model is supposed to work. It seems hard to some
programmers because you have to formulate your query in terms of an
outcome, not in terms of a series of steps that can be added to
iteratively, as a snippet of code is written. It's very different to
something like bash, because it requires a little bit of up-front,
deliberate mental effort. And, because performance with many different
possible outputs matters rather a lot.

IMV, what the OP describes wouldn't work well because it would
superficially *appear* to not be restrictive in the way that some
people dislike, but actually would be just as restrictive. The only
way you could write it is by imagining what the SQL it produced looks
like. Or, if I've misunderstood his point, then it wouldn't work
because of the same reason that things like CODASYL are obsolete.

Some developers don't like SQL because they don't have a good
intuition for how the relational model works. While SQL does have some
cruft -- incidental complexity that's a legacy of the past -- any
language that corrected SQL's shortcomings wouldn't be all that
different to SQL, and so wouldn't help with this general problem. Quel
wasn't successful because it was only somewhat better than SQL was at
the time.

This is a conversation that I had a few times when I worked for
Heroku, with coworkers that weren't on the database team. They asked
similar questions. It took me a while to piece this together.

--
Peter Geoghegan