[xquery-talk] Sequence comprehension WAS: SQL vs. XQuery (aka FOR vs FROM and RETURn vs. SELECT)

[Pavel Minaev]

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
effect.

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>
> wrote:
>
>> Pavel,
>> >
>> >
>> >
>> > 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
>> Dana
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150623/5aeaa84b/attachment.html>