Pavel, 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 Dana 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 <[email protected]> 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 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > > > > > > > >
_______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
