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]> 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]> > 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
