On 9 Aug., 21:23, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> My goodness, what a tangled web you weave...
> You're mutating an object AND using the return value at the same time
> and you're doing it twice, in the same expression!

It still disproves your statement.

> Then to add insult to injury, you now propose to add an implicit conversion
> to the mix.
> An implicit conversion that, itself, has side effects.

You will notice I remarked on that myself before.

> Do please feel free to try it for yourself, but you truly deserve whatever
> results you get from such an attempt!
>
> You're right, I truly have no idea what the relative order of execution is
> for the implicits and the mutations and the ::
> Then again, this sort of thing really shouldn't come up in a production
> system.
> If it did then I'd be asking some far more serious questions about code
> quality.
> It certainly wouldn't pass a review, and at first sight of such code I'd
> engage in a refactoring or two, as this is just plain Bad Design(tm)
>
> Such a mix of implicit conversions and mutability really is imperative
> programming at its worst, and captures EXACTLY the kind of mess that
> functional programming seeks to avoid.
>
> In the sort of idiomatic good design that Scala encourages:
>
>    - You just don't combine mutation and returning a value, as ++ does
>    - Wherever possible, functions should be pure.  For the same input they
>    will *always* produce the same output, so order of execution isn't relevant
>
> You are quite right in stating that astonishing behaviour can result from a
> truly abysmal design.
> But isn't that true of any programming language?

Absolutely, and it holds true for Java as well. Java is surprisingly
simple if you only write good code. For instance there's 30 pages in
the specification for determining the method to be called. I doubt
even 1% of Java developers could recite them, yet they constantly and
correctly determine this themselves. In Scala they would not get away
with that, they'd have to understand (among other things):
- higher-kinded types
- implicit conversions
- implicits/views/view-bounds
- inference rules for anonymous functions

That's a lot of complexity beyond that of Java. And it's the scary
kind, the one you have to grasp in order to use the language and not
the one that sneaks up on you once in a blue moon and you can shrug
off as "one of those things". Java developers /feel/ like they
understand the language even if they don't, it's hard to feel the same
about Scala. It's also hard to go to work each day feeling
uncomfortable because you don't feel in control. That's why /
perceived/ complexity wins the day.

With kind regards
Ben

-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to