<div dir="ltr">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 <a href="https://msdn.microsoft.com/en-us/library/bb397951.aspx">expression trees</a> 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.<div><br></div><div>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.</div><div><br></div><div>(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.)</div><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 6:24 PM, daniela florescu <span dir="ltr"><<a href="mailto:dflorescu@me.com" target="_blank">dflorescu@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Pavel,<div><br></div><div>I have to investigate further, but I’ve never heard that C# can treat JSON items as native C# objects.</div><div><br></div><div>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.</div><div><br></div><div>But let me read more, and I’ll reply to you when i am more informed.</div><div><br></div><div>As for schemas, that’s the entire point of semi-structured data.</div><div><br></div><div>Sometimes you have schemas, sometimes not.</div><div><br></div><div>Best regards</div><div>Dana</div><div><br></div><div>P.S. Even if C# would be “perfect”. It’s Microsoft. End of story. Business has other rules then technology.</div><div><div class="h5"><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On Jun 23, 2015, at 6:20 PM, Pavel Minaev <<a href="mailto:int19h@gmail.com" target="_blank">int19h@gmail.com</a>> wrote:</div><br><div><div dir="ltr">C# has <a href="https://msdn.microsoft.com/en-us/library/dd264741.aspx" target="_blank">optional dynamic typing</a>, actually. As you'd expect, it is very natural to <a href="http://www.newtonsoft.com/json/help/html/QueryJsonDynamic.htm" target="_blank">use with JSON</a> and similar unstructured data.<div><br></div><div>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.</div><div><br></div><div>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?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 6:14 PM, Pavel Minaev <span dir="ltr"><<a href="mailto:int19h@gmail.com" target="_blank">int19h@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. ~<div><br></div><div>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). <br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 6:04 PM, daniela florescu <span dir="ltr"><<a href="mailto:dflorescu@me.com" target="_blank">dflorescu@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Pavel,<br>
<span>><br>
><br>
><br>
> 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.<br>
<br>
<br>
</span>Huh !??? :-)<br>
<br>
You say your developers are not productive if they use a new language, but they’ll be OK with you limiting<br>
their beloved language that they used for millennia !?? :-)))<br>
<br>
I think it is theoretically possible, but psychologically not feasible.<br>
<br>
Once you give people some freedom to do something, it’s very hard to take it back. (and what about all<br>
the legacy code!?)<br>
<br>
Those “limits” have to be imposed directly in the language if you want faster improvements in the right direction….<br>
otherwise I’m going to retire before this happens…:-)<br>
<br>
Best regards<br>
Dana<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>