[xquery-talk] Sequence comprehension WAS: SQL vs. XQuery (aka FOR vs FROM and RETURn vs. SELECT)
int19h at gmail.com
Tue Jun 23 18:14:18 PDT 2015
The beauty of a subset is that it doesn't have to be applied universally. A
single method that is responsible for querying the data (and its
dependencies), for example, can be written in such a subset, while the rest
of it remains the same (which also covers the legacy code angle).
Gradually, as isolated pieces of code are rewritten by new or more educated
developers with the new skills, they will also migrate. Obviously, if you
were to write it declaratively from the get go, you might have a very
different arrangement of pieces and interfaces between them in the first
place, so the result is less than perfect... but I'll take that over
writing for-loops for eternity. ~
And yes, it is easier. A C# developer doesn't need to be taught any new
syntax to use the subset - they only need to be broadly told what things to
avoid, and the compiler can trivially enforce it. With a new language, they
would need to start with a completely new syntax, and live with the
heretofore familiar concepts being utilized in utterly new ways (the vastly
different meaning of "return" is a very good example, actually).
On Tue, Jun 23, 2015 at 6:04 PM, daniela florescu <dflorescu at me.com> wrote:
> > Also, correct me if I'm wrong, but it would seem that imperative
> patterns (variable assignments etc) can be optimized perfectly well so long
> as they're constrained (e.g. if the variable is local and no aliases are
> ever leaked). Basically, so long as you can clearly contain state changes,
> you can rewrite the whole thing as a purely functional monad, and that can
> be analyzed and optimized same as any other declarative data flow.
> Huh !??? :-)
> You say your developers are not productive if they use a new language, but
> they’ll be OK with you limiting
> their beloved language that they used for millennia !?? :-)))
> I think it is theoretically possible, but psychologically not feasible.
> Once you give people some freedom to do something, it’s very hard to take
> it back. (and what about all
> the legacy code!?)
> Those “limits” have to be imposed directly in the language if you want
> faster improvements in the right direction….
> otherwise I’m going to retire before this happens…:-)
> Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk