On Tue, Aug 10, 2010 at 12:58 PM, Ben Schulz <[email protected]> wrote: > On 9 Aug., 21:23, Kevin Wright <[email protected]> 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 >
...or you do exactly like the Java-programmers, CMD+click on the method and at the site of the correct method you are. > > 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. > Definitely, but make sure you've taken a good look before making judgements based on perception. > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Viktor Klang, Code Connoisseur Work: www.akkasource.com Code: github.com/viktorklang Follow: twitter.com/viktorklang Read: klangism.tumbler.com -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
