I am software Developer with 2 yrs of experience in Java.
Can you please guide why should a developer shift from Java to Scala?
Also, as they say Scala will the next big Thing after Java, i am a bit curious
I'd like to hear a lot more why Scala is much better. One of the coders for Openstudy.com uses Scala and was telling me how horrible Java is and it has "Boilerpoint code" and all this and that, but the thing is, how much better is it?
I agree that there are way less Scala coders, so that can be an adventage, but is it an advantage when no companies actually use Scala?
Also what is it a replacement for? Java EE since it's back end? What about FX, and Mobile? Is Scala only good for the back end, or can it be used for applications on the client side or client-server?
Jay Orsaw wrote:I'd like to hear a lot more why Scala is much better. ... Is Scala only good for the back end, or can it be used for applications on the client side or client-server?
As with any programming language, it depends on your definition of "better". I haven't had the chance to use Scala or functional programming for real-world work yet myself, but there seem to be some common themes raised by people who have made this transition. There's also some discussion of the advantages of Scala on this thread, but some of the common perceived benefits appear to include:
Scalability e.g through the use of Actors for (asynchronous) concurrency instead of threads, or through greater use of immutable data, functional programming etc.
Maintainability e.g. Scala code is often much more concise than Java (with all that boilerplate) and fewer LOC often means fewer places to screw up and less maintenance in the longer term.
Scala's case classes and pattern-matching make for very clean code, for example, and Scala traits (like interfaces with implemented methods) can be a very powerful and simple way to "inherit" behaviour without the pain of OO inheritance.
Scala's powerful type inference also combines the benefits of a strictly typed language with some of the benefits of dynamic typing in terms of having to write less code yourself.
Access to great Scala libraries e.g. for Collections, as well as to Java's existing libraries.
Ability to adopt functional programming techniques which many people claim can offer greater scalability, maintainability (e.g. no more awkward anonymous/inner classes just to provide a simple function) and flexibility than imperative OOP.
Scala's hybrid ability to take advantage of FP and/or OOP as required for the task in hand.
From what I've seen, most people are using Scala on the server, because that's where you can gain the benefit of its scalability, for example. Obviously, you can mix Scala with Java on a JVM server, and use your preferred client-side technology for browser interfaces etc. Scala is also the basis for version 2 of the lightweight Play! framework for web applications (although my understanding is that version 2.x is not currently Java EE compatible). My impression is that there is a growing trend towards looking at using the right language for specific purposes rather than a monolithic "one size fits all" approach e.g. the excellent book The Well-Grounded Java Developer devotes almost half its content to topics relating to polyglot programming on the JVM
Finally, the best way to find out what a language can do for you is probably to try it out, and there's still time to sign up and learn about Functional Programming Principles In Scala from the language's creator Martin Odersky of EPFL at Coursera. This free course starts on 25 March and I can highly recommend it.
I am curious about this myself. As a Java developer, how do I know that Scala isn't just another bandwagon for disgruntled Java developers to jump on right now? In my view, a lot of the "problems" of Java development really come down to bad Java developers. I mean, how many times have we all opened up a code base from a client to get to work on a new project and found that what is there is clueless to good OO design, design patterns, and so forth. Or from code delivered from another vendor in the past. I can't count the number of times on my fingers. Ruby on Rails is another example of one of these bandwagons. A number of people over the last few years jumped on that technology for web development because of the ideas that it would be faster, easier, etc. But now that it has been there a few years, you have books coming out like Practical Object-Oriented Design with Ruby where the publisher's description literally reads as: "Ruby’s widely admired ease of use has a downside: Too many Ruby and Rails applications have been created without concern for their long-term maintenance or evolution. The Web is awash in Ruby code that is now virtually impossible to change or extend." Maybe these developers should have just stuck with Java and learned OO design already.
Well, that's a fair question, Scott, and I'm not in a position to "compare and contrast" successful Java and Scala projects. If you were seriously considering whether to use Scala instead of Java, then it would be a good idea to look at the experiences of people who've gone the same route, perhaps starting with the examples given above.
I don't know enough about Ruby to judge whether any project would be better implemented in Java or Ruby. But it's always worth remembering Sturgeon's law i.e. 90% of everything is crap. Given the challenges you have pointed out in implementing good OO design, there's a fair chance that some of the poorly implemented Ruby projects you mention would have been just as bad or even worse in Java. And given the cost of Java development, it may be that people actually got a working (if flawed) Ruby system for a reasonable budget, instead of spending vastly more money and still getting a useless Java system. I know I've seen some projects totally crippled by the cost and incidental complexity of using "enterprise" Java, producing brand new legacy systems that are unmaintainable, barely functional and cost a fortune, and I believe some of these projects might have been far more successful if they'd chosen a different approach, a different platform or a different language.
As an aside, it has been argued that OO design patterns are not so much evidence of good OO design, but are actually a symptom of failures in the OO approach or of missing features in OO languages, and that many such patterns become redundant if you use a dynamic functional language instead. I'm not really in a position to judge this, but it's certainly true that some things can be much harder to implement in an idiomatic OO style than in functional style.
In any case, the fact is that Java is hard and full of cruft, and the language is showing its age and carrying a lot of historical baggage that is no longer especially helpful. There is no sense in taking a macho stand and insisting that people should program better in Java, because the same can be argued about any language: is Java just a refuge for people who couldn't hack it as C programmers? If there are alternatives available that might allow people to implement their systems more easily, quickly and cheaply without sacrificing quality, then what's wrong with exploring those alternatives? For example, there is no reason to waste time and money trying to get hand-crafted threads working if you can implement your concurrency more easily and robustly using Akka. Scala or some other language may indeed be a better option in some cases, and not in others. The point is not to be hamstrung by past decisions - and choosing an alternative JVM language still leaves you with room to change track later on if you need to.
Of course, if Java represented the pinnacle of programming language perfection, then there might indeed be no reason to change to some other language. But programming languages are tools that are changing all the time, and it makes sense to pick the right tool for the job today, rather than sticking with an obsolete or unsuitable tool, simply because "a flint hand-axe was good enough for my grandpappy". After all, I remember plenty of C/C++ programmers expressing similar doubts about that new-fangled Java language back in the day!
I have always worked for large companies, in which in my case the developer is not deciding what would be the best language to use to solve the problem. Which also plays back into what I saw as the move from C/C++ to Java. Java's "build once, run anywhere" motto got it adopted by management. Who in turn told the developers to use it.
Please ignore post, I have no idea what I am talking about.