<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 24, 2015 at 2:24 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Erik Mejier says this is not enough.</div><div><br></div><div> <a href="https://queue.acm.org/detail.cfm?id=2611829" target="_blank">https://queue.acm.org/detail.cfm?id=2611829</a></div></div></div></div></div></blockquote><br></div></span><div>Erik Meijer, while being an extremely smart person, is not God :-)</div><div><br></div><div>And I don’t see anything in this article that proves that one cannot mix those: all the </div><div>arguments he brings are for me just a reminder that, indeed, if you DO mix functional</div><div>and imperative constructs or side-effects, you better know what you are doing at compilation</div><div>and optimization time…..</div><div><div><br></div></div></div></blockquote><div><br></div><div>I'm not pretending to understand much of what he was going on about but the headline of his article is right for an entirely different reason.</div><div><br></div><div>Let's step back a moment and consider what actually happens wen an imperative language adds functional constructs - and I am not sure whether these are intended consequences or not.</div><div><br></div><div>1. It puts a break on agitation to migrate to a proper functional language.  Both sides are sort of happy. The imperative people will say no need to go to Scala/Clojure, you can do FP in Java 8. No need to go to F# you can do FP in C# and the functional people are allowed the illusion that they will be able to write functional code in these languages. They won't really because the coding standards and need to conform will always be biased towards the imperative perspective but they allow themselves to think that they will and they do get small wins here and there.</div><div><br></div><div>2. Basically people carry on coding as they always have. It is not sufficient to introduce functional constructs, to get people to use them you have to rewire the way they think and the way they design programs.  People who do not know what mathematical induction is will not adapt to a programming style and language constructs that requires them to think inductively. If they have been bred to believe that recursion is inefficient (because of languages that don't optimise tail-calls) they will not adapt to a style of programming where that is the primary means of effecting iteration.</div><div><br></div><div>So ultimately not only. do you not get anywhere near half your 95% target (and I bet that also applies to Scala) you also stifle progress towards migrating to a functional programming environment. Rather what you end up with can be summarised from the Google Python coding standards. A smattering of map and filters, some trivial list comprehensions otherwise it's business as usual.</div><div> </div></div></div></div>