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

Pavel Minaev int19h at gmail.com
Wed Jun 24 00:21:52 PDT 2015


Google is ultra-conservative in their approach to coding. It's not just the
FP stuff, their C++ coding standard is equally ridiculous for other
reasons. I suspect it's also why they use Java so much, and I expect that
they will ban lambdas there when they move on to Java 8. So I am inclined
to treat them as a more extreme case than normal. Perhaps they do have good
reasons to do things that way, but even if so, I don't think those reasons
apply to most.

For comparison, in my experience working at Microsoft, declarative
operations on sequences (either comprehensions, or just direct use of
map/filter/... or local equivalents thereof) are widely accepted and used
in production C# and Python code, and have been for at least six years. On
my team, for example, the use of an explicit loop where a comprehension
would suffice would generally be flagged in a code review right away. The
only objections that I've ever heard come from perf hawks, and that is
sometimes justifiable, but is really an implementation deficiency - there's
no reason why a compiler cannot optimize a comprehension to be as efficient
as a straight loop in most cases, and generally be better than it currently
is in all cases; it just wasn't a goal for the C# compiler guys (and of
course it's not a concern for Python at all).

Speaking of "hard to understand" and "not as performant" arguments popping
up... I remember that being quite frequent in the community back when all
this stuff was introduced into the language and the framework. Three years
later, it was already a distinctive, if still loud, minority. Now, you
still hear it occasionally, but most people just shrug at it, and lambdas
and LINQ are just part of idiomatic C#. Same thing happened with type
inference ("var") in C#, and lambdas in C++, and many other things. And I
think we are seeing a replay with lambdas in Java 8 (it's really funny to
read the disapproving blog posts about Java lambdas today; you could
s/Java/C#/ and they'd be word for word the same as what I've read back in
2008).

Thing is, programmers are a pragmatic bunch. If it really does work better
(= lets them be more productive; you don't need to be a scientist to gauge
that), they'll get used to it, and will eventually grow fond of it, so long
as you don't force them to go all in on it right away. A certain amount of
bickering is to be expected, and there will always be stalwart holdouts (I
mean, we still have people signing a petition to bring back VB6, 17 years
later!), but overall the industry moves on. I'd rather be an optimist on
account of the direction of that movement and its ultimate destination,
than a pessimist on account of its speed, or the occasional detour along
the way.

And it's not like all this is recent, either. Weren't there very similar
objections against structured programming back in the day? You know, why
complicate language with these new-fangled and hard to understand loops if
a simple conditional jump is just as expressive and can be hand-optimized
much better than even the fanciest compiler can manage? And yet, here we
are.



On Tue, Jun 23, 2015 at 11:29 PM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:

>
> On Tue, Jun 23, 2015 at 8:42 PM, Pavel Minaev <int19h at gmail.com> wrote:
>
>>
>> That's why I love the fact that functional and declarative stuff is
>> creeping into those mainstream imperative languages. It gradually gets me
>> to the point where I can write neat declarative code *in production*,
>> and no-one objects because they don't realize that it's radically different
>> from what they're used to! (and those who do, are generally in the same
>> boat as me and enjoy it the same). For them, it's just some new syntax that
>> got added to the language they know and use, and so obviously it's okay by
>> default.
>>
>>
> I don't think this is generally applicable.  For example look at Google's
> Python standards
>
> https://google-styleguide.googlecode.com/svn/trunk/pyguide.html
>
> Comprehensions are only allowed for "simple cases" otherwise use a loop.
> No mention of fold anywhere in the document which I interpret as meaning
> don't use it.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150624/3adc5ddb/attachment.html>


More information about the talk mailing list