Paste that link again...

http://warpedjavaguy.wordpress.com/2010/08/02/the-scala-is-too-complex-conspiracy-1/


On 3 August 2010 16:31, Kevin Wright <[email protected]> wrote:

> I heartily recommend that everyone read this article:
>
> Especially the comment at the end by Martin Odersky that he posted
> tomorrow!
> (seriously, today is August 3rd, but the comment says August 4th)
>
>
> On 3 August 2010 13:27, Wildam Martin <[email protected]> wrote:
>
>> On Tue, Aug 3, 2010 at 13:39, Kevin Wright <[email protected]>
>> wrote:
>> > On 3 August 2010 09:41, Wildam Martin <[email protected]> wrote:
>> >> 1. Strangely too many different possibly approaches to implement the
>> same thing.
>> >> I like to have options, but where it makes sense. I mean, I already
>> >> have two options to start a console program:
>> >>
>> >> object Main {
>> >>  def main(args: Array[String]) {
>> >> [...]
>> >>
>> >> and
>> >>
>> >> object somestuff extends Application {
>> >> [...]
>> >>
>> >> (I have seen 5 ways to write the same simple stuff in other cases
>> >> which I unfortunately can't recall now - just ridiculous it was!). It
>> >> is hard enough to read others code, but such things makes it worse.
>> > Guilty as charged... The Application trait is a sad moment in Scala's
>> > history, we try to forget about it...
>> > It's been show to be a Very Bad(tm) thing, and has long been deprecated.
>> > Your first example is the one true way :)
>>
>> But both are official examples from the Scala site! They should change
>> that.
>>
>>
>> >> 2. Readability
>> >> No, this is not (just to give one example):
>> >> val elems = args map Integer.parseInt
>> >>      println("The sum of my arguments is: " + elems.foldRight(0) (_ +
>> _))
>> > Ouch! That truly is an ugly way to handle such a simple concept.
>> > Try this version instead:
>> >   println("The sum of my arguments is: " +
>> args.map(Integer.parseInt).sum)
>>
>> Of course, your version is more clear and more readable.
>> But again, it is an official sample from the Scala site!
>> And this is only the tip of the iceberg. I have seen a lot of other
>> samples, but I was sure if I give you other examples everybody would
>> have told, that it is bad code.
>>
>> But I took official samples for this post and I get the same response...
>> I mean, if they don't get it right, who else?
>> And I begin to think that one reason why so much is re-implemented
>> rather than improved is, because everybody finds, only his version of
>> the code is the best (this is not against your corrections above - I
>> agree to all those).
>>
>>
>> >> 3. Functional approach
>> >> I could never get warm with functional programming, Scala does not
>> >> make a difference here.
>> >> YMMV.
>> > See my response to point 2.
>> > That solution wouldn't be possible without the ability to pass
>> > Integer.parseInt as a closure/function to the map method, this is the
>> > essence of functional programming
>>
>> I could implement a static map function in Java that takes an Object
>> something and Class mapTo and use that utility function - I mean this
>> is a small task, I do not consider such a feature as a big gain. Of
>> course, that would not be functional, but I don't care.
>>
>>
>> > There are some other (admittedly complex) backstage tricks to make the
>> magic
>> > happen; specifically, implicits and higher-kinded types
>> > but... these are all handled in the collections library, as an
>> end-user you
>> > can simply call sum on *any* collection of numbers
>> > It will "just work", and yield a number of the correct type
>> > (int/float/double/etc.)
>> > It's still statically-typed, but feels to the end-user very like a
>> dynamic
>> > language
>>
>> Oh, the programmer is already called the "end user". :-) - But of
>> course, you are right, somehow the programmer is the end user of the
>> compiler/language/IDE/...
>>
>> --
>> Martin Wildam
>> http://www.google.com/profiles/mwildam
>>
>> --
>> 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
>
>


-- 
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.

Reply via email to