On Wed, Jul 5, 2017 at 7:02 AM, Merlin Moncure <mmoncure@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
