On Sep 16, 6:22 am, Sean Griffin <[email protected]> wrote:
> 1. People say Scala is complex, but the actual examples that attempt
> to prove this complexity are rare.

No they aren't.

> Features that support *writing*
> DSLs are often used as those examples.  I've done a fair amount of
> Scala development.  I have yet to write a DSL.

You've written in DSL plenty of times already. Ever omitted the 'dot'
when dereferencing? Ever decided not append "()" to a method call that
doesn't require any arguments? You're a winner already! The DSL nature
of scala does in fact leak out more during using a library intended to
be used that way than vice versa. Operator overloading, omission of
dot for dereference, omission of parens, the underscore shortcut when
inline-specifying a closure, these are what are meant (or at least,
what I mean) when I refer to scala's DSL features, and these are ALL
things that are to be typed by the USER of a library, not the writer
of one. Unlike e.g. generics wildcards which casual use of a library
won't ever bother you with.

> 2. Capabilities that currently exist in Java are simpler in their
> Scala equivalent
>

You keep using that word, "simpler". This discussion is a lot more
nuanced than that, unfortunately. What you keep calling "simpler" I
tend to consider more complicated. And yes, I've used scala, rather a
lot even. I'm not equating "simpler" with "doesn't look familiar".
Until you define what you mean with simpler, I don't think this is
going to get past the "he said, she said" phase.

>
> I won't be able to use Java 7 for probably 4 more years.  I can't even
> use Java 6 yet because I have to remain compatible with a Java 5 JRE.

But staying cutting edge on scala is legit? Talk about using two
yardsticks. You're actually going with "scala is better because its
more stable"? Good luck with that argument.

> Lombok could give me easier data classes but wouldn't allow me to use
> them in pattern matches.

Ah, yes, just keep moving the goalposts, I forgot.

> only that it's worth a serious look.

In contrast to, let's say, groovy, jruby, or jython? Are those not
worth serious looks?

>
> Finally, the whole "drastic as switching to an entirely new language"
> argument doesn't hold much water with me.  Learning the language is a
> one time thing.

Of course it isn't. That's ridiculous. Scala revs fast (an argument
being used by e.g. Kevin to convince people to switch, no less!). I
need only point at scala 2.8 which is a massive update, for example.
Even if scala didn't rev like its a fairly new language, there's the
community. They release new, major libraries all the time. Styles
change, too. Even java has this quirk: 5 years ago, the builder
pattern wasn't all that famous and methods returning self so they
could be changed where quite rare. Now you see them everywhere. joda-
time and guava are used in lots of places, but they didn't exist 5
years ago. Somebody's kicking the tires on the web framework world
every other year, it seems. Scala is of course no different.

Long story short: Claiming that learning a language is a one-time
investment is a falsehood.

This isn't a bad thing, but it does highlight yet again what I keep
saying: If you're going to switch to scala, then switch. Going halfway
is not a good idea.

Any product you can write in scala, you could write in java, and vice
versa with no more than a ~25% productivity loss, and that's in rare
and extreme cases. The "right tool for the job" is not useful in such
a scenario. The effort in keeping up to date at two languages costs
you more in total productivity loss using either language than what
you gain by being able to switch to the one that's better suited at
the job. No, if you're going to go down this path, you should learn
javascript (because html+web is something completely new from giving
people a swing app to download, for example), or javafx (because
writing certain GUIs in javaFX is easily 2 to 3x faster than doing so
in swing), or a new web framework, or something like haskell (more to
learn more about writing code in java/scala than actually add a tool,
but that's good too!)

> Learning each new library's API or framework,
> regardless of the language, is a continual thing and we never question
> that!

Scala, by for example replacing the collections library, means you
need to not just learn a new language, no, you've got to learn an
entirely new API too. Yes, you can interop with java's libraries, but
then you're on your own. The vast majority of java programmers can't
read your stuff very well because its scala, but the vast majority of
scala users don't really want to mess with your code because its using
non-standard libraries. This doesn't work. You need to switch over
completely, as I keep saying.

Technically the idea of a java clone that just cleans up a few issues
may even work (I doubt it'll be compelling enough to cause many people
to switch), but at the very least such a language will not introduce a
significant amount of new API. Scala is not that language. Scala is a
major change from java. Most actually prefer it that way.

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