It seems a very curious statement that you feel as though you've lost control with Scala.
How exactly do you even define "control" in this sense? Is control having to use plus instead of + when adding BigIntegers? or is it explicitly using a SAM type instead of just passing a function that compares values, when you want to sort a list perhaps control is knowing to use == for primitives but not for objects or maybe having to catch an exception in the finally block of another exception handler when closing a file or is control about laboriously picking through stack traces to identify a deadlock, after you controlled the program by using `synchronized` or not having an easy way to extend an existing class with a new operation that's very obvious to have in your domain how about having to generate reams of boilerplate via your IDE, then being able to modify that inconsistently and causing an obscure error. Is that control? Where is the control really? Are you in control when you're in a straight-jacket? or are you in control when you cross the road and have the option to not check for oncoming traffic? Run across a busy road without looking and you may get hit by a car, but is that the fault of the car or the road? Clearly it wouldn't have happened if you were in a padded cell. On 10 August 2010 11:58, 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 > > 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 [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. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- 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.
