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].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
