[xquery-talk] adding comprehension to imperative languages or vice-versa

Ihe Onwuka ihe.onwuka at gmail.com
Wed Jun 24 00:30:42 PDT 2015


On Wed, Jun 24, 2015 at 2:24 AM, daniela florescu <dflorescu at me.com> wrote:

>
> Erik Mejier says this is not enough.
>
>  https://queue.acm.org/detail.cfm?id=2611829
>
>
> Erik Meijer, while being an extremely smart person, is not God :-)
>
> And I don’t see anything in this article that proves that one cannot mix
> those: all the
> arguments he brings are for me just a reminder that, indeed, if you DO mix
> functional
> and imperative constructs or side-effects, you better know what you are
> doing at compilation
> and optimization time…..
>
>
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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150624/7f172509/attachment.html>


More information about the talk mailing list