tags:

views:

1597

answers:

6

I just started exploring Scala in my free time.

I have to say that so far I'm very impressed. Scala sits on top of the JVM, seamlessly integrates with existing Java code and has many features that Java doesn't.

Beyond learning a new language, what's the downside to switching over to Scala?

+3  A: 

I don't think there are no downsides. Actually learning new language is very helpful for broadening your programming knowledge. You might gain from Scala such things as generic classes, variance annotations, upper and lower type bounds, inner classes and abstract types as object members, compound types, explicitly typed self references, views, and polymorphic methods.

Roman Kagan
+2  A: 

It consistently breaks backwards compatibilty. Community size is small. IDE support isn't there yet.

Otherwise its fine.
It is just a young language, it will get there eventually. Great for hobbyists, not ready for enterprise.

windfinder
Someone needs to tell EDF, twitter and, erm, me that it isn't ready for the enterprise
oxbow_lakes
I don't think that its scalibility is the issue, but I also don't begrudge them the work it takes to maintain something that isn't backwards compatible.
windfinder
What oxbow_lakes said.
Rayne
@Rayne, hover your mouse to the left if oxbow_lakes' comment, a little up arrow will appear. Pressing it will say what you just said more concisely. And isn't Scala is much about terse code ;-)
Elazar Leibovich
+2  A: 

I'll tell you my little personal experience, and how I found that it wasn't so easy to integrate Scala with existing Java libraries:

I wanted to get started with something easy, and as I thought that Scala was very well suited for scientific computation I wanted to do a little wrapper around JAMA (Java Matrix library)... My initial approach was to extend the Matrix type with a Scala class and then overload the arithmetic operators and call the Java native methods, but:

  • The Matrix class doesn't provide a default constructor (without arguments)
  • The Scala class needs one primary constructor
  • I thought one good primary constructor could be the one accepting an Array[Array[Double]] (first thing that sucks, that syntax is much more verbose and hard to read than Double[][])
  • As far as I know by reading the manuals, the parameters of the primary constructor are also implicitly fields of the class, so I would end with one Array[Array[Double]] in the Scala subclass and another double[][] in the Java superclass, which is pretty redundant.

I think I could have used an empty primary constructor that initialized the superclass with some default values (for example, a [[0]]), or just make an adapter class that used the Jama.Matrix as a delegate, but if a language is supposed to be elegant and seamless integrated with another, that kind of things shouldn't happen.

Those are my two cents.

fortran
Please take a look at my blog (http://dcsobral.blogspot.com), where I look at and address these very issues. For one such case, you either would declare a private constructor receiving a Matrix, and base the others on that, or have no parameters in the private constructor at all. There are very good reasons for these features that bothered you, as well as ways to get around them.
Daniel
Inheritance isn't the only way to implement a wrapper! You can just include an instance of the Matrix type in your own class.
Seun Osewa
@Seun I already stated _or just make an adapter class that used the Jama.Matrix as a delegate_ But then I wouldn't be able to use the Scala wrapper back in Java as if it was a regular jama.Matrix...
fortran
@fortran, if you're making an adapter class, you can use implicit conversion to use that back in Java functions.
Elazar Leibovich
@Elazar could yo please elaborate a little bit more on that (or provide a link with further information)?
fortran
@fortran, to make a long story short, adding to the scope a function `implicit adapter2matrix(a:Adapter):Matrix = a.innerMatrix` would cause scala to automatically convert call to `INeedJavaMatrix(AdaptorClass)` to `INeedJavaMatrix(adapter2matrix(AdaptorClass)` see http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-6
Elazar Leibovich
@Elazar very interesting... thanks, I'll take a more in depth look :-)
fortran
+13  A: 

Well, the downside is that you have to be prepared for Scala to be a bit rough around the edges:

  • you'll get the odd cryptic Scala compiler internal error
  • the IDE support isn't quite as good as Java (neither is the debugging support)
  • there will be breaks to backwards compatibility in future releases (although these will be limited)

You also have to take some risk that Scala as a language will fizzle out.

That said, I don't think you'll look back! My experiences are positive overall; the IDE's are useable, you get used to what the cryptic compiler errors mean and, whilst your Scala codebase is small, a backwards-compatibility break is not a major hassle.

It's worth it for Option, the monad functionality of the collections, closures, the actors model, extractors, covariant types etc. It's an awesome language.

It's also of great personal benefit to be able to approach problems from a different angle, something that the above constructs allow and encourage.

oxbow_lakes
Is there a recommended free IDE?
Liran Orevi
Miles Sabin gave a talk at the London Scala Users Group recently where he said that the next version of the Eclipse plugin (to be released at the same time as Scala 2.8) will be *much* more stable, quicker and better than the current version.
oxbow_lakes
I've been using NetBeans 6.7 with the Scala plugin and it's been pretty nice so far.
cdmckay
+8  A: 

Some of the downsides of Scala are not related at all to the relative youth of the language. After all, Scala, has about 5 years of age, and Java was very different 5 years into its own lifespan.

In particular, because Scala does not have the backing of an enterprise which considers it a strategic priority, so the support resources for it are rather lacking. For example:

  • Lack of extensive tutorials
  • Inferior quality of the documentation
  • Non-existing localization of documentation
  • Native libraries (Scala uses Java or .Net libraries as base for their own)

Another important difference is due to how Sun saw Java and EPFL sees Scala. Sun saw Java as a product to get enterprise customers. EPFL sees Scala as a language intended to be a better language than existing ones, in some particular respects (OOxFunctional integration, and type system design, mostly).

As a consequence, where Sun made JVM glacially-stable, and Java fully backward compatible, with very slow deprecation and removal of features (actually, removal?), JAR files generated with one version of Scala won't work at all with other versions (a serious problem for third party libraries), and the language is constantly getting new features as well as actually removing deprecated ones, and so is Scala's library. The revision history for Scala 2.x, which I think is barely 3 years old, is impressive.

Finally, because of all of the above, third party support for Scala is incipient. But it's important to note, though, that IntelliJ, which makes money out of selling an IDE, has supported Scala for quite some time, and keeps improving it's support. That means, to me, that there is demand for third party support, and support is bound to increase.

I point to the book situation. One year ago there was no Scala book on the market. Right now there are two or three introductory Scala books on the market, about the same number of books should be out before the end of the year, and there is a book about a very important web framework based on Scala, Lift.

I bet we'll see a book about ESME not too far in the future, as well as books about Scala and concurrency. The publishing market has apparently reached the tipping point. Once that happens, enterprise will follow.

Daniel
I think that there are some very interesting blogs about what the future of Scala is likely to hold in terms of "enterprise" takeup. Unfortunately they haven't been written yet :-(
oxbow_lakes
You're right, there's only like 4 books being written about it. How would one ever learn it?
Rayne
Rayne, I think you missed my point. It was my intent to show that the market for Scala books is growing explosively, jumping from 0 to 5 or 6 within a single year.
Daniel
+10  A: 

I was unshackled from the J2EE leash last year wanted to do something new after 12 years of Java in the enterprise building very large system for some of the worlds biggest companies.

I had tried Ruby on Rails in the past. After building a few sample apps I did not like the feel of it or the fact that I would have to write a ton of unit tests to cover stuff that is normally done by a compiler.

Groovy on Grails was my next port of call. I have to say I do like this but it suffers from the same dynamic typing problems as ROR. Don't get me wrong I am not putting Grails down as it is an excellent framework and I will still use it. Each has its own place IMO.

I then jumped on Scala and have now built a hybrid application based on Scala and Spring MVC. At first working with Scala is difficult but it gets easier and more productive the more time you put into it. I've reached a tipping point where I now want to invest time in Lift as well.

The combination of "Programming in Scala" and David Pollak's "Beginning Scala" books is good for learning the language, the latter with a less academic bent.

Scala is still young and has some way to go. I think it has a bright future and I see momentum is already picking up. Recently one of the creators of the Groovy language said in a blog post he would never have bothered designing Groovy if Scala had been around at the time.

I think some more work on better Java API integration/wrapping will give Scala the boost it needs to win more followers. The basic integration is there already but I think its could be polished a bit more.

Yes IDE support is there but it is basic at the moment. The powerfully refactoring support of Intellij is not there yet and I miss that a lot. The compiler + IDE support with a mix of of other plugins is not mature yet. I sometimes get very weird internal compiler errors caused by how Scala sits with JDO enhancement for the Goggle app engine. However these are little things that can be easily fixed. Early adaptation of new technologies and languages always comes with a little pain. But this bit of pain can produce great pleasure in the future.

If I look at the capabilities of Scala compared to early Java its miles ahead. When I moved from C++ to Java the JVM was not ready yet regarding scalability. There used to be lots of weird crash and burn JVM core dumps on various OSes. All of this has now been fixed in Java and the JVM is rock solid. Scals runs in the JVM so it has been given a massive head start on native platform integration. Its standing on the shoulders of giants!

After years of building and supporting enterprise applications my vote is for a language where a compiler can catch most of the non functional bugs before even unit tests are built. I love the type checking mixed with the power of functional programming. I like the fact that I am doing OO++.

I think the development community will decide if Scala is the future or not. The downside of adopting Scala now would be if it did not pick up momentum and adaptation. It would be very difficult to maintain an Scala code base with very few Scala developers around. However I watched Java come from the skunk works into the enterprise to replace C++ and it was all pushed from the bottom up by the developer community. Time will tell for Scala but currently it has my vote.

Feargal