[xquery-talk] Sequence comprehension WAS: SQL vs. XQuery (aka FOR vs FROM and RETURn vs. SELECT)
int19h at gmail.com
Tue Jun 23 18:50:38 PDT 2015
C# by itself doesn't have any optimizations for groupby (or any other
sequence operations, for that matter). They're all just syntactic sugar for
method calls. But because those methods can capture any lambdas passed to
them as expression trees
<https://msdn.microsoft.com/en-us/library/bb397951.aspx> instead of opaque
functions, in the end you can actually get a single tree of all operations
that constitute a query, including all the invoked functions etc with a
little effort. "dynamic" is largely orthogonal to all this, except that it
basically disables the type checks to shut up the compiler and let you use
arbitrary operands for the operators - the exact semantics of your entire
query is ultimately controlled by whatever will be interpreting the
expression tree, not by the language spec.
In any case, I'm not arguing that C# is perfect in that (or any other)
respect. It merely serves as a useful example, that I am personally very
familiar with, of how far a Java-like language can be pushed if there's
desire and demand, and how an existing community of users of such a
language can eagerly adopt all those new things if they are presented in a
familiar coating. There may well be other examples, probably better ones
(Scala?), though probably none quite so popular - but I'm just using this
one because I can give you references to various features that I bring up
in this discussion off the top of my head.
(I'm also not sure why it being MSFT matters all that much these days - the
spec is published, and the reference implementation for both the compiler
and the underlying platform is now fully portable and open source under a
sane license. It's basically in the same boat as any other
non-committee-owned but otherwise open language now.)
On Tue, Jun 23, 2015 at 6:24 PM, daniela florescu <dflorescu at me.com> wrote:
> I have to investigate further, but I’ve never heard that C# can treat JSON
> items as native C# objects.
> I don’t recall anywhere a description of what C# does when it has to
> grouby and the set of values are all over the map.
> But let me read more, and I’ll reply to you when i am more informed.
> As for schemas, that’s the entire point of semi-structured data.
> Sometimes you have schemas, sometimes not.
> Best regards
> P.S. Even if C# would be “perfect”. It’s Microsoft. End of story. Business
> has other rules then technology.
> On Jun 23, 2015, at 6:20 PM, Pavel Minaev <int19h at gmail.com> wrote:
> C# has optional dynamic typing
> <https://msdn.microsoft.com/en-us/library/dd264741.aspx>, actually. As
> you'd expect, it is very natural to use with JSON
> <http://www.newtonsoft.com/json/help/html/QueryJsonDynamic.htm> and
> similar unstructured data.
> I find this to be a good compromise, because most of the time I'm working
> with data that has at least a partial schema. So I want types to be
> enforced where possible, but when I need the laxity of dynamic typing, the
> door is right there - and once it's opened, everything on the other side is
> wonderfully dynamic without the need of any further reminders to that
> As I recall, F# also has something similar, though I'm not familiar enough
> with it to comment. I believe there were some considerations of adding a
> similar feature to Java, as well?
> On Tue, Jun 23, 2015 at 6:14 PM, Pavel Minaev <int19h at gmail.com> wrote:
>> 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>
>>> > 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