Why Scala matters (especially) under a business point of view

[Mario Fusco]

Hi all,

inspired by a discussion we started on this mailing list a few weeks
ago, I blogged my thoughts about why in my opinion the adoption of
Scala is a winning decision especially under a business point of view:

http://www.mate.it/en/component/content/article/84-perche-scala

I hope this could reopen that discussion by bringing new ideas and
clarifying the old ones.

Cheers,
Mario Fusco
http://twitter.com/mariofusco

[Cédric Beust ♔]

Hi Mario,

This list, and many others like it, is missing a critical part: liabilities.

It's a general rule when you are pitching something: if you only paint a rosy picture without any downside, at best, your audience will be skeptical, at worst, they will doubt either your honesty or whether you have a balanced view of the picture you are painting.

At this point, you have already wasted your time.

Thinking of the downsides of something you like is always a worthy exercise, even if you have no intention of pitching it to anyone.

For example, a big missing piece in your description is the poor IDE (and tooling in general) situation. You like Scala so you probably don't care, or you decided that the upsides of Scala were worth the pain in this particular area but try to put yourself in the shoes of someone who's interested but not as enthusiastic as yourself. Will these limitations be acceptable?

Some of your other points can also easily be countered by someone with a reasonable technical background. You don't need to be an expert in programming language for wondering if a reduction in lines of code is always a net gain (see Perl). Your point about readability is also very subjective (what will you respond if somebody picks a random commit from the Scalaz project and asks you if you really think this is readable code?).

You should avoid using subjective statements in pitches because they tend to polarize your audience: people sympathetic to your views will nod, people with a bit of skepticism will feel a stronger urge to object.

Your point about smarter people is a very dangerous one to make, not just because of the kind of attitude that it projects but because it's borderline insulting to the existing Java programmers in your company. You need them as allies in this battle, the last thing you want to do is alienate them with this kind of condescending (and largely unproven) claim

Also, be wary of claims that can be easily contradicted (e.g. "If LinkedIn uses Scala, how come they don't have any open positions for Scala developers?"). At least, spend the time to do the research that can be easily verified or people will just dismiss you as a fan who shouldn't be trusted for this kind of critical strategic decision.

Any CTO worth their salt will probably ask you to go over your list again and rewrite it with a more critical eye.

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Kevin Wright]

2011/7/4 Cédric Beust ♔ <ced...@beust.com>

Hi Mario,

This list, and many others like it, is missing a critical part: liabilities.

It's a general rule when you are pitching something: if you only paint a rosy picture without any downside, at best, your audience will be skeptical, at worst, they will doubt either your honesty or whether you have a balanced view of the picture you are painting.

At this point, you have already wasted your time.

Thinking of the downsides of something you like is always a worthy exercise, even if you have no intention of pitching it to anyone.

For example, a big missing piece in your description is the poor IDE (and tooling in general) situation. You like Scala so you probably don't care, or you decided that the upsides of Scala were worth the pain in this particular area but try to put yourself in the shoes of someone who's interested but not as enthusiastic as yourself. Will these limitations be acceptable?

Some of your other points can also easily be countered by someone with a reasonable technical background. You don't need to be an expert in programming language for wondering if a reduction in lines of code is always a net gain (see Perl). Your point about readability is also very subjective (what will you respond if somebody picks a random commit from the Scalaz project and asks you if you really think this is readable code?).

You should avoid using subjective statements in pitches because they tend to polarize your audience: people sympathetic to your views will nod, people with a bit of skepticism will feel a stronger urge to object.

Your point about smarter people is a very dangerous one to make, not just because of the kind of attitude that it projects but because it's borderline insulting to the existing Java programmers in your company. You need them as allies in this battle, the last thing you want to do is alienate them with this kind of condescending (and largely unproven) claim

Also, be wary of claims that can be easily contradicted (e.g. "If LinkedIn uses Scala, how come they don't have any open positions for Scala developers?"). At least, spend the time to do the research that can be easily verified or people will just dismiss you as a fan who shouldn't be trusted for this kind of critical strategic decision.

Any CTO worth their salt will probably ask you to go over your list again and rewrite it with a more critical eye.

-- 

Cédric

No doubt there's some room for improvement, but your response was perhaps a little too harsh here.  Let's try a small rewrite:

LESS CODE => LESS TIME => LESS MONEY

The important point here is reduction in verbosity, specifically in the boilerplate at which Java excels:

- multiple repetition when specifying types

- repetition of names in backing fields, getter methods, parameters to setter methods, maybe also constructor params

- the need to create a loop when performing a trivial mapping over some collection

- equals and hashCode methods

- SAM types

- poor choice of defaults (why isn't public final the norm unless otherwise specified?)

Scala specifically targets the areas of Java that are most verbose.

It's known that focusing too much on minimizing code can harm comprehension (Perl is repeatedly accused of easily degenerating into line noise), yet it's also possible to obfuscate with *too much* code and repetition.  Excess boilerplate and repetition leads to an over-reliance on tools for code generation, and the kind of tedious repetitive programming where mistakes are more likely to repeatedly happen.  If you doubt this, just imagine trying to write Java without an IDE.

By better enforcing the DRY principle and not obfuscating intent with repetition and boilerplate, code becomes easier to write, read and maintain.

HIRE SMARTER PEOPLE

Programmers with experience in multiple languages and paradigms are better able to so solve problems, they have a larger "mental toolbox" and a wider range of techniques to draw upon.  A Scala programmer is almost guaranteed to have experience with at least one other language, not so a pure Java programmer.  Many other languages will exhibit this effect of course, it's by no means unique to Scala.

As for LinkedIn... Speculation could go either direction.  Maybe they're doing all their Scala hiring by word-of-mouth and don't need to advertise (the community is strong enough for this to work), or maybe they found the productivity boost from Scala is enough that they can realise gains by simply cross-training their existing Java developers instead of having to grow headcount.

 

--
Kevin Wright

gtalk / msn : kev.lee...@gmail.com

mail: kevin....@scalatechnology.com

vibe / skype: kev.lee.wright

quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Jon Kiparsky]

"Almost 3 years ago I discovered the Scala language and that was the first time after a dozen years of Java programming that I felt it worth to move on and start learning a new language"

You lost me there. If you've only written Java, it's hard to see how you're in a position to usefully evaluate another language. And how is it that you write Java for a dozen years and never thought to learn a little something else? Maybe a little bit of python, just to see what the fuss is about, or some perl because it's so useful, or something? That's weird, really weird, to me.

[Josh Berry]

On Tue, Jul 5, 2011 at 12:24 AM, Jon Kiparsky <jon.ki...@gmail.com> wrote:
> "Almost 3 years ago I discovered the Scala language and that was the first
> time after a dozen years of Java programming that I felt it worth to move on
> and start learning a new language"
>
> You lost me there. If you've only written Java, it's hard to see how you're
> in a position to usefully evaluate another language. And how is it that you
> write Java for a dozen years and never thought to learn a little something
> else? Maybe a little bit of python, just to see what the fuss is about, or
> some perl because it's so useful, or something? That's weird, really weird,
> to me.

I think what stops a lot of folks from learning another language is
not always the language dynamics, but the chore of deploying a
solution in that language, as well. This is the big appeal of any new
jvm based language, deploying a solution should be the exact same as
if you deploying a java solution. There is something nice about that.

[Matthew Farwell]

+1 for mentioning the lack of downside.

Mario, 

People *know* that there are down sides to everything. To not admit it is a mistake. As Cedric says, the tooling isn't up to the level of Java (this isn't a criticism, just an observation). There is also the learning curve.

Up until now there have been 12453 'silver bullets' to fix all known problems in programming. I won't insult your intelligence by listing them all here :-) Don't promote any new technology/language as a silver bullet, because it's not.

One way to introduce a new language (especially Groovy or Scala) is through using it for testing. Also, to a lesser extent scripting. There were a couple of good talks Scala Days 2010 talk that could be useful for you:

Sneaking Scala Into Your Organization: David Copeland: http://days2010.scala-lang.org/node/138/169

Scala for Scripting: Michael Dürig: http://days2010.scala-lang.org/node/138/146

Matthew (Scala fan)

2011/7/4 Cédric Beust ♔ <ced...@beust.com>

[Fabrizio Giudici]

> 2011/7/4 Cédric Beust ♔ <ced...@beust.com <mailto:ced...@beust.com>>

>
> Your point about smarter people is a very dangerous one to make,
> not just because of the kind of attitude that it projects but
> because it's borderline insulting to the existing Java programmers
> in your company. You need them as allies in this battle, the last
> thing you want to do is alienate them with this kind of
> condescending (and largely unproven) claim
>

It's dangerous, but true and necessary. Mario should just rewrite the
reference in a way that the blame is not about people (for instance
referring the lack of training, etc.).

On 07/05/2011 12:51 AM, Kevin Wright wrote:
>
>
> No doubt there's some room for improvement, but your response was
> perhaps a little too harsh here. Let's try a small rewrite:
>
> LESS CODE => LESS TIME => LESS MONEY
>
> The important point here is reduction in verbosity, specifically in
> the boilerplate at which Java excels:
> - multiple repetition when specifying types

Yes. (*)

> - repetition of names in backing fields, getter methods, parameters to
> setter methods, maybe also constructor params

No.

> - the need to create a loop when performing a trivial mapping over
> some collection

Yes & no.

> - equals and hashCode methods

No.
> - SAM types
Please elaborate.

> - poor choice of defaults (why isn't public final the norm unless
> otherwise specified?)

Yes.

Points above marked with no: use Lombok and the verbosity is gone.
Lombok is not a trick, it's just an application of Java language and
tooling features and it's IDE-friendly. To me today people writing Java
code and blaming Java for that kind of boilerplate and not using Lombok
are just willing to hurt themselves.

(*) Lombok takes also care of the point marked with (*) by the 'val'
construct, but - while it works - I classify it into trickery, so I
don't use it and I understand people preferring not using it.

Point marked with yes & no: I'd rather say it's a library problem, not a
language problem. There are libraries offering collection with predicate
support; the objection would just be the verbosity of the predicate (no
closures).

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

[Casper Bang]

> Points above marked with no: use Lombok and the verbosity is gone.
> Lombok is not a trick, it's just an application of Java language and
> tooling features and it's IDE-friendly. To me today people writing Java
> code and blaming Java for that kind of boilerplate and not using Lombok
> are just willing to hurt themselves.

Lombok exists as a workaround layer, also called a hack, and has
indeed been characterized as such by venerable language designers
(listen to JavaPosse #279). While I can respect Lombok and the
problems it wants to solve (I am the one Alex Buckley refers to having
removed checked exceptions in my Java compiler) it is simply no
replacement for proper language constructs and idioms. I know that you
command Java the language, libraries, tools and everything in between
(AOP, byte-code weaving, anonymous proxies, Lombok...) - but can you
seriously see a new and upcoming programmer voluntarily setting foot
in this chaos?

[Kevin Wright]

I don't see Lombok as being significantly different from Scala here.  Both are alternative ways of emitting valid JVM bytecode that differ from "pure" Java, and both require support at both the IDE and compiler level.  In this sense, the change required to migrate from Java to Lombok is not significantly less than the change required to migrate from Java to Scala, is see both as occupying a middle ground - somewhere halfway between being just a library and being an entirely new language.

Groovy, JRuby, Clojure, Jaskell, Mirah, etc. all occupy the same space to varying degrees, with the following points (in no particular order):

Syntactically close to Java: Groovy, Lombok, Scala (if you want)

Statically typed: Mirah, Lombok, Scala

Minimal library dependencies: Mirah, Lombok

Good DSL support: Groovy, Scala, Mirah

In addition, Scala doesn't force you to stay close to canonical Java, you can transition all the way to Haskell-style pure functional code if you wish, complete with the IO Monad for controlling side-effects.  You can also stay *very* close to pure Java, using no more than the functionality that Lombok offers.

Scala is also notable for consciously choosing to remove features relative to Java, where the complexity cost in the specification and the potential for risk in such features doesn't justify the benefit. i.e. disjoint constructors (all Scala constructors must ultimately delegate to a single "primary" constructor).  In one sense, Scala can be seen as more complex simply because it allows you to do more complex things, but in practical usage Scala is simpler than Java because it removes much of the repetition, boilerplate, necessary workarounds and obfuscation that the language forces upon you.

As a case in point: there must be literally hundreds of SAM types currently used in production Java code; an interface with a method used simply as a wrapper to pass instances of of some function around.  For example: predicates and transformers in Apache collections and Google Guava, and the whole slew of event handlers in Swing.  Scala simplifies this mess by offering a single function type that's used throughout Swing, standard collections, etc. With syntactic sugar for making them trivial to define and use.

You also don't get the feeling that constructs like `val` are somehow trickery.  Type inference is a perfectly normal and expected part of the language.  You're more likely to get odd looks if you *don't* use type inference.

Yes, Lombok is a fantastic tool.  But I can't help feeling that if you're willing to migrate to Lombok anyway, then you're already taking on board the exact same risks that you would with a migration to Scala, but you're not getting the vast majority of extra benefits that Scala offers.  It's a simple cost/benefit equation.

[Fabrizio Giudici]

On 07/05/2011 11:21 AM, Kevin Wright wrote:
>
>
> I don't see Lombok as being significantly different from Scala here.
> Both are alternative ways of emitting valid JVM bytecode that differ
> from "pure" Java, and both require support at both the IDE and
> compiler level. In this sense, the change required to migrate from
> Java to Lombok is not significantly less than the change required to
> migrate from Java to Scala, is see both as occupying a middle ground -
> somewhere halfway between being just a library and being an entirely
> new language.

Also in response to Casper:

1. Lombok is not a hack. It's the use of a specific language element
(annotations) and related tools (annotation processor). Annotation are
the way Java has been designed to be extended (in a constrained way).
It's still "pure" Java, as pure as the other annotations (e.g.
@Transactional, etc...) are. Clearly, the extension scope is narrower
than the use of another language (e.g. no traits, no operator
overloading, etc... (*)).
2. Exactly because the extension scope is narrow, using annotations is
much simpler than moving to Scala.

(*) I know about people using annotations and annotation processors to
implement traits in Java. This is probably pushing annotations too much.

[Casper Bang]

> 1. Lombok is not a hack. It's the use of a specific language element
> (annotations) and related tools (annotation processor). Annotation are
> the way Java has been designed to be extended (in a constrained way).
> It's still "pure" Java, as pure as the other annotations (e.g.
> @Transactional, etc...) are. Clearly, the extension scope is narrower
> than the use of another language (e.g. no traits, no operator
> overloading, etc... (*)).

I call it a hack, because annotations were always about meta-data and
not as a facilitator for AST manipulations. JSR-308* states
"...annotations are not intended to change the run-time behavior of a
Java program...". Again, I understand and appreciate what it enables,
but it's still a hack in many people's book - and it certainly would
be to anyone presented with alternative languages, relying only on a
classic compiler setup (rather than special IDE plugins and annotation
post-processors).

* http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html

[steve]

I think the main problem is the sustained brain-drain Java is suffering for years now. Lots of brilliant and talented people have left and there aren't enough newcomers to fill the role. There is just no one there anymore who could push the Java language substantially forward (ignoring the technical reasons why it doesn't even make sense to pile further stuff on top of Java for now).

If we're lucky those people leaving Java just went to Scala, if not there talent is lost completely for the JVM world.

The remaining ones are now mostly defending their "10-year Java expert skills", unable or unwilling to discover something new, inventing byzantine requirements for other "candidate" languages or making up bizarre obstacles why this or that language can't be "the next Java".

At the moment there is a turning point where the decision will be made if every JVM developer might get an additional tool for his/her toolbox (Scala) in the future or if he/she will have no other choice than to use the existing ones for every task, regardless if appropriate or not.

I guess that's why some people decided to do some more "aggressive marketing" currently.

[Dick Wall]

On Monday, July 4, 2011 2:30:21 PM UTC-7, Cédric Beust ♔ wrote:

Also, be wary of cclaims that can be easily contradicted (e.g. "If LinkedIn uses Scala, how come they don't have any open positions for Scala developers?"). At least, spend the time to do the research that can be easily verified or people will just dismiss you as a fan who shouldn't be trusted for this kind of critical strategic decision.

Any CTO worth their salt will probably ask you to go over your list again and rewrite it with a more critical eye.

-- 

Cédric

But, Cedric, LinkedIn does use Scala, they host our monthly Scala meetings, and at each meeting they stand up and say that they are on the look out for more Scala developers. Also, after conversations with you in the past I have asked straight out whether LinkedIn is using Scala, or whether it is tailing off, and each person I ask says that Scala usage within LinkedIn is constantly increasing.

Dick

[Mario Fusco]

Thanks for all the feedback and constructive critiques. All of them
deserve a reply:

- I admit the post is quite biased in favor of Scala (but not that
much). I did it on purpose since its intention is clearly to promote
the Scala adoption, especially in Italy where for some reason almost
nobody is using it. When McDonald's tries to sell their double
cheeseburger with bacon they don't tell you they will make you fat and
possibly be the cause of an heart attack :-) Anyway I didn't want to
actually oversell Scala and I strongly believe in all the points of my
post. I know there are some open issues yet (and the most important
one, i.e. the lack of binary backward compatibiilty, hasn't been
mentioned) but I still think the advantages largely overcome them.

- Tooling, or more precisely lack of good IDE support, is still an
issue, but not so big as it was even just one year ago. At the moment
I am developing in Scala with Intellij Idea and I think it is already
quite good. I also expect very shortly big improvements on the Eclipse
plugin. I precised I was speaking about IDEs because there are other
tools in which Scala is already better than Java. An example above
all: I often use both maven and sbt and in my opinion the second one
is far easier to use, more flexible and configurable than the first.

- I didn't go in details with technical stuff (map instead of loops,
SAM types ...) because the target of my post weren't technical people.

- My point about "smarter people doing Scala" can be dangerous and for
sure is unpleasant, but that doesn't mean it is far from the truth.
Being curious and having the will to learn a new language at least
underline your passion about programming. Moreover I believe I have
become a better Java developer by studying Scala (that also pushed me
to develop lambdaj) as much as I am becoming a better Scala developer
by learning Haskell.

- Some of my points was actually subjective because based on my
experience: is that bad?

- Maybe reduction in number of LOCs is not so important, but one of
its side-effect actually is: have a bigger signal/noise ratio in your
code. That means you have a higher percentage of statements actually
related to the business logic of your code, instead of being written
just to, for instance, manipulate collection, or even worse merely
please the compiler.

- Scalaz is not so easy to read, even if very useful specially in some
specific context. My point wasn't that anyway: you can write cryptic
code in every language and Scala makes no exception. I wanted to
underline that, on the counter side, some features of Scala makes it
extremely suitable (far more than Java) to implement very readable and
elegant internal DSL. I hope my pet project Hammurabi
http://code.google.com/p/hammurabi/ (a very basic rule engine written
in Scala) could be a good example of that.

- I don't think Lombok is an hack (just a very useful tool) but I
don't see how it can be compared with Scala.

I hope this clarify my points of view.

Cheers,
Mario

[Cédric Beust ♔]

One more thought about:

> the need to create a loop when performing a trivial mapping over some collection

As you may or may not know, there is a pretty bad performance problem with for comprehensions in Scala at the moment, and it's 

severe to the point where the only workaround at the moment is to fall back to writing an imperative while loop.

This is the kind of tiny detail that can totally wipe your argument from several angles: 1) for comprehensions are great but you should avoid them if you need performance (so Scala's performance is not on par with Java's after all), 2) it shows the immaturity of the compiler (you claim both the compiler and the tools are mature) and 3) this is reminiscent of C++, which was riddled with this kind of weird behaviors resulting from the interaction of the crazy amount of features that the language supports.

-- 

Cédric

On Mon, Jul 4, 2011 at 11:33 AM, Mario Fusco <mario...@gmail.com> wrote:

[Cédric Beust ♔]

On Tue, Jul 5, 2011 at 5:58 AM, steve <steve....@googlemail.com> wrote:

I think the main problem is the sustained brain-drain Java is suffering for years now.

You'll probably be hard pressed to support this claim with data. A few highly visible people are experimenting with other languages, but that's what they do, and they are certainly not representative of the entire community. And even if they tinker with other technologies, I'm pretty sure that most of them are still using Java for their day job.

Every single dimension that you look at (language popularity, books, job market, college programs, etc...) is showing that Java is stronger than ever, and as I hinted in a previous message, if anything, I am seeing a recrudescence of new Java programmers, coming to Java mostly for Android.

 

If we're lucky those people leaving Java just went to Scala, if not there talent is lost completely for the JVM world.

Again, that's quite a generalization.

-- 

Cédric

[Cédric Beust ♔]

Hi Dick,

On Tue, Jul 5, 2011 at 6:45 AM, Dick Wall <dick...@gmail.com> wrote:

But, Cedric, LinkedIn does use Scala, they host our monthly Scala meetings, and at each meeting they stand up and say that they are on the look out for more Scala developers. Also, after conversations with you in the past I have asked straight out whether LinkedIn is using Scala, or whether it is tailing off, and each person I ask says that Scala usage within LinkedIn is constantly increasing.

FYI, LinkedIn doesn't have any open Scala position.

-- 

Cédric

[Kevin Wright]

Actually, it's much worse than simply not having any Scala position...

http://www.linkedin.com/jsearch/sh?keywords=jvm&company=LinkedIn&searchLocationType=Y&sortCriteria=R

Or perhaps they're simply finding enough people from the BASE meetings and internal cross training, without having to filter the inevitable junk applications that come from online advertising...

> position<http://www.linkedin.com/jsearch/sh?keywords=scala&company=LinkedIn&searchLocationType=Y&sortCriteria=R>
> .
>
> --
> Cédric

[Ricky Clarkson]

Regarding that for-comprehension problem, it's only bad for those for
comprehensions that could be written as a loop in Java, and even then
it's on the order of magnitude of "stuff that you wouldn't normally
notice".

2011/7/5 Cédric Beust ♔ <ced...@beust.com>:

[Dick Wall]

I do know that LinkedIn does indeed ping for people at the BASE meetings, they also sponsored ScalaDays 2011 (good sponsors too). All in all, they continue to be exemplary members of the Scala community. Thanks LinkedIn.

The BASE meeting is coming up on Monday (at LinkedIn), Cedric, why not come and check it out? It's fun stuff.

Dick

[Kevin Wright]

2011/7/5 Cédric Beust ♔ <ced...@beust.com>

One more thought about:

> the need to create a loop when performing a trivial mapping over some collection

As you may or may not know, there is a pretty bad performance problem with for comprehensions in Scala at the moment, and it's 

severe to the point where the only workaround at the moment is to fall back to writing an imperative while loop.

This is at best a misunderstanding of the problem and, at worse, active misinformation (a.k.a. FUD)

Just to make the point clear, this is NOT a bad performance problem with for comprehensions.  It's a bad problem with explicit return statements when used within a for-comprehension over a range - a much more specific (and rare!) combination of factors than your email implies.  The correct workaround is not to use a while loop, but to avoid the return statement. Not that big a deal, as return statements are typically considered bad form in Scala anyway.

I have absolutely no belief that any malice was intended here, and can understand *why* this misunderstanding would occur.  In older versions of Scala, using a comprehension over a range *would* be much slower than the equivalent loop, even without the return statement.  Martin was previously opposed to adding a special-case optimisation for this specific case, as ongoing virtualisation efforts can effectively solve it, and it adds a tax payable on all future work in the compiler.

There's also a performance enhancer available that's more potent than loops.  Scala can perform tail-call optimisation, so if the functionality had been written using recursion, then the emitted bytecode would use a simple jump and be even faster.  Better still, the technique can be combined with specialisation and to avoid the performance cost of boxing and unboxing in generic code.  This is a classic scenario in which Scala can readily outperform Java.

Ultimately, Martin bowed to community pressure, and the optimisation was quickly added.

For comparison, lets take some frequently demanded features for the Java language and see how Sun/Oracle responded to the community pressure.  These aren't mere slowdowns either, but real showstoppers that can fundamentally damage the expected behaviour of your code.

1. Unstable enum hashCode; The hashCode of an enum changes between JVM runs and on different machines.  This is a real killer if using hashed indexing alongside persistence, or in a shared cache.  Reported 2006, closed as low priority/will not fix: http://bugs.sun.com/view_bug.do?bug_id=6373406 (assuming the site isn't down again)

2. The definitions of equals and hashCode in the URL class make a DNS lookup call, they're defined in terms of the current state of the internet! This is a real classic, anyone who's found Eclipse hang on them when opening the update manager whilst not online... this was the reason.  To the best of my knowledge, this still hasn't been fixed in JDK 7:

http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html

3. Tail-Call optimisation, for which a *working patch* was submitted to the OpenJDK in 2009.  It may arrive in JDK8, but I wouldn't hold your breath: http://weblogs.java.net/blog/forax/archive/2009/12/18/tailcall-anyone

It's really starting to look as though Java isn't fundamentally any better than Scala, C++, or almost any other current mainstream language when it comes to being a standard bearer of suitability for enterprise use.

This is the kind of tiny detail that can totally wipe your argument from several angles: 1) for comprehensions are great but you should avoid them if you need performance (so Scala's performance is not on par with Java's after all), 2) it shows the immaturity of the compiler (you claim both the compiler and the tools are mature) and 3) this is reminiscent of C++, which was riddled with this kind of weird behaviors resulting from the interaction of the crazy amount of features that the language supports.

-- 

Cédric

On Mon, Jul 4, 2011 at 11:33 AM, Mario Fusco <mario...@gmail.com> wrote:

Hi all,

inspired by a discussion we started on this mailing list a few weeks
ago, I blogged my thoughts about why in my opinion the adoption of
Scala is a winning decision especially under a business point of view:

http://www.mate.it/en/component/content/article/84-perche-scala

I hope this could reopen that discussion by bringing new ideas and
clarifying the old ones.

Cheers,
Mario Fusco
http://twitter.com/mariofusco

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Kevin Wright

gtalk / msn : kev.lee...@gmail.com

google+: http://gplus.to/thecoda

[clay]

Is everyone simply using Scala as a more concise Java?

I love the conciseness, however, it seems that the stronger argument
for Scala over Java is the improved support for functional and
immutable programming.

[Kevin Wright]

Not to mention the (often overlooked) improved support for object oriented programming.  Static methods and primitives are a carry-over from C++, and aren't at all object-oriented.

 

[steve]

Nice try, but I don't think Cedric could find a single positive aspect of Scala, even if his live depended on it. :-)

[Ricky Clarkson]

> Nice try, but I don't think Cedric could find a single positive aspect of
> Scala, even if his live depended on it. :-)

He is the anti-Kevin.

[Kevin Wright]

Not really... We agree on tons of stuff.  Cedric hangs out on the #scala IRC channel a lot too, he's just playing devil's advocate :) 

[Cédric Beust ♔]

On Wed, Jul 6, 2011 at 1:14 AM, steve <steve....@googlemail.com> wrote:

Nice try, but I don't think Cedric could find a single positive aspect of Scala, even if his live depended on it. :-)

You are so wrong about this that I wonder if you ever took the time to actually read what I write.

-- 

Cédric

[clay]

On Jul 5, 4:54 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> Not to mention the (often overlooked) improved support for object oriented
> programming.  Static methods and primitives are a carry-over from C++, and
> aren't at all object-oriented.

Could you elaborate on the OO advantages of Scala?

Scala's approach of singletons is a nicer more elegant way of doing C+
+/Java/C# "static". Earlier, I asked, "Is everyone simply using Scala
as a more concise Java?" and this would seem to fall under that
category.

[Cédric Beust ♔]

On Wed, Jul 6, 2011 at 1:16 PM, clay <clayt...@gmail.com> wrote:

On Jul 5, 4:54 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> Not to mention the (often overlooked) improved support for object oriented
> programming.  Static methods and primitives are a carry-over from C++, and
> aren't at all object-oriented.

Could you elaborate on the OO advantages of Scala?

For me, traits and the ability to define abstract types and fields inside classes are really cool advantages that Scala has over Java.

The downside is that it's not always clear whether you should define an abstract type inside your class or just make it generic, but I like the flexibility.

-- 

Cédric

[Kevin Wright]

Overall the language just feels cleaner and less bogged down.  What really attracted me though was the FP support and the language's uncanny knack of allowing me to clearly express my thoughts without having to add all that padding simply for the benefit of the compiler.  The ease with which a DSL such as ScalaTest could be implemented was a real eye opener, and I'm absolutely finding maintainence to be much less of a chore.

This clearly goes a long way beyond a simple reduction in line/character count.  Conciseness may well be a force that drives people to look at the language, but I doubt it's the only reason why anyone has stuck with it.

As for the OO benefits, it's a hard thing to pin down.  Partly this is because OO is a cross-cutting paradigm that changes its nature as it spans the imperative/declarative divide (think of this less accurately as the procedural/functional divide, if you will).  Partly it's because the definition of OO has changed since the term was coined.

Originally, OO was conceived as a paradigm of message passing between entities (objects), this is closer to what we know think of as Actors or SEDA.  More recently, OO has come to mean a style in which all values are objects and all methods belong to some object.  Java (and C++) breach this paradigm in two important ways:

1) Primitive values are not objects, nor are simple operations such as + invocations of a method

2) Static methods don't belong to an object instance

Scala addresses both of these points:

1) Everything is an object (even numbers and functions).  To make this work, the language introduced the idea of infix notation for method calls. `1 + 2` is just alternate notation for `1.+(2)`  where `+` is just a method name and could as easily be implemented on any object for which it was appropriate (such as your own definition of a complex number or matrix). Alternatively, the method could have been named `plus` and invoked as `1 plus 2` or `1.plus(2)`

2) Instead of Static methods, Scala introduces the idea of companion objects.  A class can have a same-named singleton object which has the same privileged access rights as static members would.  The key difference is that this singleton is a true object, capable of implementing an interface and inheriting members from superclasses or traits.

[Blake]

On Jul 5, 8:58 am, steve <steve.mcjo...@googlemail.com> wrote:
> I think the main problem is the sustained brain-drain Java is suffering for
> years now. Lots of brilliant and talented people have left and there aren't
> enough newcomers to fill the role. There is just no one there anymore who
> could push the Java language substantially forward (ignoring the technical
> reasons why it doesn't even make sense to pile further stuff on top of Java
> for now).
>
> If we're lucky those people leaving Java just went to Scala, if not there
> talent is lost completely for the JVM world.
>

A data point of one here: I have previously been a programmer in
dynamic languages, primarily PHP, Python, and Perl, after I got my
start in BASIC dialects and C back in the 90s. I learned Java, but was
always unenthusiastic about it because of its more involved build and
deployment processes.

A project this spring required me to write in Java, and that brought
me to the JVM for the duration of that project, but I had no intention
of remaining there until I discovered Scala, which marries an interest
I'd previously had in functional programming with the pragmatism of a
hybrid language and the established JVM ecosystem.

I'm just a learner at the moment, but I think that beyond Scala
slowing brain-drain, it can *fuel* incoming interest where other
alternatives, perhaps, cannot. Note that I am not claiming brilliance,
by any means--but I am an example of a newcomer from an unusual
direction, perhaps.

[ScottHK]

Scala , F# and other functional languages are recently showing up in a
lot of programming job ads in the finance sector.
For relatively stand alone projects with a lot of complex formulaic
business logic it is a good solution if one can devote the time to
becoming fluent in using it, it is a better language and helps the
programmer write concise code and not make mistakes...sort of in the
same was as moving from C++ to Java meant less is more.

With Java however one has the ability to copy & paste standard Java
code from the web which saves hundreds of hours of time when one need
to do something such as using a complex API, add a GUI, or solve a
generic programming problem. I wouldn't choose Scala for a general
programming language yet unless the business logic comprises the
majority of your code.

I think Scala still needs a 'tipping point' application to generate
enough interest to build a broad code base out there.

btw, I don't understand why Actors are considered such a big
improvement over the standard Java producer-consumer pattern??

[Casper Bang]

On Jul 14, 8:11 am, ScottHK <sukosu...@gmail.com> wrote:
> Scala , F# and other functional languages are recently showing up in a
> lot of programming job ads in the finance sector.
> For relatively stand alone projects with a lot of complex formulaic
> business logic it is a good solution if one can devote the time to
> becoming fluent in using it, it is a better language and helps the
> programmer write concise code and not make mistakes...sort of in the
> same was as moving from C++ to Java meant less is more.

Except, AFAIK Scala does not support base-10 decimal literals, but
still relies on the clunky BigDecimal by which simple operations gets
real complex real fast. It's one of the most annoying things
recognized by people implementing in both Java and C#. Correct that in
Scala one still has to say val something = BigDecimal("3.1415") and
sprinkle MathContext's all over?

[Kevin Wright]

Wow!

It's a very brave man who'll not just admit to copy+paste programming, but will actually present it as a useful and even desirable practice.

If anything, I'd argue that the prevalance of such practices indicates one of Java's weaknesses, the language tends towards APIs that are complex to use and encourage this sort of approach.  Specific examples:

• use-site generics that force wildcards into client code
• lack of closures
• lack of named/default parameters
• intermixing of static/non-static methods
• poor support for internal DSLs and self-documenting APIs
• disjoint constructors
• limited switch statement
• strong bias towards mutable objects and programming with side effects

I'll admit that it's often very pragmatic to copy example code when trying to solve some problem, we've all done it, but my experience with Java has all to often been with APIs that represented simple concepts but were needlessly complicated, where such copying shouldn't be necessary in the first place.  Much of the swing API falls into this category, as do the I/O and Date/Calendar APIs

The tipping point for Scala isn't parallel programming, it's case classes, closures,  pattern matching and other core language features.  Easier concurrency then comes out of these basics as an emergent property; they also lead to far cleaner code, even if concurrency isn't of any interest to you.

Yes, concurrency is the next big challenge, and will continue to be a massive driver for adoption, but the tipping point on benefits from the language is reached long before you start working with concurrency.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Mario Fusco]

> With Java however one has the ability to copy & paste standard Java
> code from the web which saves hundreds of hours of time

I really hope I haven't understood well. Are you really saying that
you prefer Java because you can easily find code to copy & paste? If
so, I am sorry, but I am glad you don't work with me.

Mario

[Jeb Beich]

Come on guys, he probably just means that he's able to find samples to
common problems by search the web far more easily in Java than in
Scala. That's true, and one of the strengths of Java clearly.

> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>
>

--
Jeb Beich
http://www.jebbeich.com

[Kevin Wright]

On 14 July 2011 17:45, Jeb Beich <jebb...@gmail.com> wrote:

Come on guys, he probably just means that he's able to find samples to
common problems by search the web far more easily in Java than in
Scala. That's true, and one of the strengths of Java clearly.

http://blog.jetbrains.com/scala/files/2011/06/conversion-dialog.png

Enough said :)

Taken from a blog posting here: http://blog.jetbrains.com/scala/