<div dir="ltr">C# has <a href="https://msdn.microsoft.com/en-us/library/dd264741.aspx">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">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 class="HOEnZb"><div class="h5"><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>