7 reasons Scala is better than Java...

[joet...@gmail.com]

Wrote a piece on it over at developers.hp.com:

https://developers.hp.com/public/blog/7-reasons-scala-better-java-so-why-java-winning

Would love to hear your feedback!

[Dennis Haupt]

java is still winning because many people do not seek to improve themselves or their tools. they shy away from investments and don't want to divert from the main stream. there are many, many alternatives which, imho, have beaten java (at least < 8) by a large margin, but none of them were adopted by the majority.

just like how people tend to not change their religion or ide, they tend to stick to the language they learned first unless forced to do otherwise.

as for the reasons, i would cite the language features itself that 

* allow writing more concise code

* make it easier to write functional code which leads to less bugs

* better type system

* features that eliminate the need for code duplication/explicity writing the same code again and again (case class -> hashcode/equals, pattern matching)

* less but more powerful concepts

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Russ P.]

If you really want to start with the basics, I think it is worth mentioning that Scala eliminates the need for getters, setters, and constructors (other than the main class body). I have seen Java code where this stuff goes on for pages and pages and is all completely unnecessary in Scala.

[Russ P.]

Oh, I forgot to mention default arguments and argument passing by keyword. I recently had the misfortune of having to write some Java code to integrate my Scala application with a Java application. I was unpleasantly reminded that Java still doesn't have these basic conveniences. As far as I am concerned, that omission is utterly inexcusable at this point in time. 

[Rex Kerr]

I think it's pretty good.  The points are fair, and delivered without hysteria.

I'm not sure the premise is quite correct--is it true that people move from Scala to Java more than the other way?  My impression is that Scala is gaining ground, and you can't tell who will ultimately win when there's such a big difference in inertia.

But regardless of how you frame the context, the article seems pretty good to me.

  --Rex

--

[Juha Heljoranta]

Nice write up :)

Although, got me thinking. Is it good that Play is a full stack framework? I
mean, just look at ecosystem around Java Servlet API. It's gloorious.
Frameworks after frameworks. Which is nice from consumer perspective.

Which leads to another observation: I find my self rarely'ish coding against
interface in Scala. Or at least in same sense as in Java, that is. Most of the
interfaces tend to be sealed traits. Any thoughts?

Cheers,
Juha

[Dennis Haupt]

the getter/setter argument is the only one i can't follow. you also don't need one if your field is public. what's better about the scala version of doing it?

--

[ARKBAN]

> Reason 2. Play Framework

Personally I think Akka is a more compelling reason than Play. Play is good but on the surface its yet-another-web-framework. Not immediately enticing, but Akka is weird, different and has no well known parallel in the Java space.

> The Learning Curve

My company has found its sometimes harder for the senior developers since they've had more time to cement their imperative thinking. (I say this as one of those senior developers who joined the company so I could start doing Scala.)

> Scala coders hard to find

My company is a Scala company, has been for 4+ years in the Washington DC area. We just hire good developers, mostly from Java but a few from Python, C#, Ruby, Python.

Scala coders hard to find

Scala coders hard to find

Scala coders hard to find

Patrick

[Russ P.]

On Friday, February 19, 2016 at 12:36:15 PM UTC-8, Dennis Haupt wrote:

the getter/setter argument is the only one i can't follow. you also don't need one if your field is public. what's better about the scala version of doing it?

In Java you need explicit getters and setters if you want to keep the interface separate from the implementation, which is considered good practice in general. Suppose I have a public field that I later decide needs to be computed in a method. In Java, without getters/setters I have to force callers/clients to change their code just because my implementation changed (but not the interface). That's not good. Had I used getters and setters I would not have that problem, but they are a nuisance to read/write, and they clutter the code. Scala automatically generates them under the hood so you don't need to write them, and your code stays leaner and cleaner. This should not be confused with an IDE that writes them for you but still clutters your code with them. That's my understanding anyway.

[Russ P.]

On Friday, February 19, 2016 at 6:38:43 PM UTC-8, Russ P. wrote:

On Friday, February 19, 2016 at 12:36:15 PM UTC-8, Dennis Haupt wrote:

the getter/setter argument is the only one i can't follow. you also don't need one if your field is public. what's better about the scala version of doing it?

In Java you need explicit getters and setters if you want to keep the interface separate from the implementation, which is considered good practice in general. Suppose I have a public field that I later decide needs to be computed in a method. In Java, without getters/setters I have to force callers/clients to change their code just because my implementation changed (but not the interface). That's not good. Had I used getters and setters I would not have that problem, but they are a nuisance to read/write, and they clutter the code. Scala automatically generates them under the hood so you don't need to write them, and your code stays leaner and cleaner. This should not be confused with an IDE that writes them for you but still clutters your code with them. That's my understanding anyway.

See section 18.2 of Programming in Scala, 2nd edition for more information on the automatic getters and setters in Scala.

This is a huge gain over Java that is often overlooked because it is so basic.

[Naftoli Gugenheim]

I think the term is "uniform access principle."

[Russ P.]

On Saturday, February 20, 2016 at 5:45:12 PM UTC-8, nafg wrote:

I think the term is "uniform access principle."

Yes, thanks. I had forgotten that name. It's a great idea that simplifies life for Scala programmers and makes me glad that I'm not a Java programmer.

[cra...@tataryn.net]

On Friday, February 19, 2016 at 2:36:15 PM UTC-6, Dennis Haupt wrote:

the getter/setter argument is the only one i can't follow. you also don't need one if your field is public. what's better about the scala version of doing it?

If at some point you needed to add some logic to your getter/setter without breaking the way the user of your class accessed it, then in Java you'd be pooched if the solution from the start was to make an instance field public.  Whereas in Scala you can override the getter/setter that was provided to you by the language with your own version without changing the way in which the user accesses that field.

Craig.

[Dennis Haupt]

this is not an argument in my case. i use intellij idea and can just say "wrap field access with getter method"

it only makes a difference for libraries

[Craig Tataryn]

:eyeroll: