There has been a great deal of buzz about Scala in the last year or so, and as we all know, buzz is always followed closely by the buzz-killers. Recently there have indeed been quite a few criticismsm of the language, including complaints ranging from wimpers about how “IDE support simply isn’t there” to cries from others that “the language is hard to understand and maintain”.

Perhaps the Scala nay-sayers should take the advice Neal Ford had to offer in a recent podcast on the topic of language reachability where he states “In what profession in the world is ‘it is too hard’ a valid reason not to do it... true professionals learn  to do hard things”

When it comes right down to it, there seems to be some common thinking and fallacies found amongst those who disparage the Scala language. Read the full article as Craig Tataryn addresses the Scala FUD:

Addressing the Scala FUD

Craig Tataryn will be presenting two sessions at TSSJS 2011, covering the ins and outs of Wicket and Scala. TheServerSide Java Symposium is less than two weeks away, so register now and join us all on the 16th!

Register for TSSJS 2011

Since both (java and scala) languages are turing complete, why should I buy a Scala book? Typing less characters is not a valid reason because people don't type too much using java on eclipse because of auto-completion. IMO, innovation should be done at the framework/library level because it is targeted and optimized at a specific domain. Scala is just more of the same. And java is a good enough foundation for further innovation.

Well, just because you *can* do things in both languages doesn't mean that there aren't strengths inherent in both languages that aren't shared.

IMO, Java's "simpler" than Scala, it's certainly got an easier learning curve for most people. That said, Scala does a lot of things to nudge people to writing things that scale better.

Neither one is a perfect weapon for all tasks. But both are incredibly valuable.

Since both (java and scala) languages are turing complete, why should I buy a Scala book?

Excellent question, and really you don't even have to buy a Scala book if you don't want.  Yes Java is Turing complete, but actually if you give this video a look, at 11:51 he addresses pretty much this question.

I guess my question to you might be, why not try and learn a new language?  I personally love learning, I think it's the human nature of "keeping the old ratty shirt your wife hates" mentality which is what keeps people from exploring.  You perhaps have known Java for a long time, it is just too comfortable for you to try on a new language.

I'm only just getting into Functional Programming and already I can feel my problem solving abilities evolving.  Its a very interesting way at looking at problems, but I believe it takes much more investment in learning a Functional language; but perhaps no more of an investment than learning a huge framework like Spring.

It's not about learning a new language (I've been studying scala), it's about evolution. It makes sense to go from Assembly to C to Java because there are ganuine simplifications and abstraction of things that shouldn't matter to most programmers like manual memory allocation. Now, going from Java to Scala is not evolution, it's syntatic sugar. You can write "() => { System.getProperty("user.dir") }" instead of "new Runnable() { public void run() {System.getProperty("user.dir");} }", that's good until you realize you can write the java version in eclipse with "run" -> Ctrl+Space.

Another problem is maintainability, it's easier to change a library than changing a language, you can do some functional programming in java with Google Guava collection classes and other libraries and you are not limited by language constructs like yield. Now, if everytime someone finds a nicer way of writing something, they write another general purpose language than we start to run in circles instead of solving new problems.

It's not about learning a new language (I've been studying scala), it's about evolution. It makes sense to go from Assembly to C to Java because there are ganuine simplifications and abstraction of things that shouldn't matter to most programmers like manual memory allocation. Now, going from Java to Scala is not evolution, it's syntatic sugar. You can write "() => { System.getProperty("user.dir") }" instead of "new Runnable() { public void run() {System.getProperty("user.dir");} }", that's good until you realize you can write the java version in eclipse with "run" -> Ctrl+Space.

 

So the majority of the arguments I'm seeing is that the Scala has a crappy plugin that can never be fixed. I think that's a textbook definition of a straw-man argument.

Scala's problem is that it tries to become too powerful in the language itself instead of building functionality in libraries as you say. I will agree with that.

Some of the FUD just borders on the lines of zealotry.

"I hate implicits". You don't have to use implicits in your code.

"I hate the syntactic sugar". OK, there is some merit in that statement because people go over board with operator loading. Again, not necessarily the languages fault.

It's funny, because when Java first came out, a lot of the same arguments were smeared against Java as a language. "Getters/Setters are Evil". Visual Age sucks. "No multiple inheritance". "No operator overloading" etc,etc.

Until the imperative programming crowd gets more comfortable with FP, we will hear all the new rants which seem to be the same as the old rants.

Please stop abusing the term "FUD".

Just because somebody doesn't like something that you like doesn't mean they are spreading FUD. They are simply disliking something you like. Accept it. You can disagree with them without insulting them.

And besides, how can you even get angry at a subjective statement such as "I don't like implicits?". It's a matter of taste and personal experience, there is no right and wrong.

 

 

Please stop abusing the term "FUD".

Just because somebody doesn't like something that you like doesn't mean they are spreading FUD. They are simply disliking something you like. Accept it. You can disagree with them without insulting them.

And besides, how can you even get angry at a subjective statement such as "I don't like implicits?". It's a matter of taste and personal experience, there is no right and wrong.

 

Easy there chief. I used FUD because that was the theme(explicity in the title) of this post and I wasn't angry. It's a friggin language discussion -- been doing this for 20+ years and Scala/Fantom/Java whatever are not the last languages I will explore. It seems that the anectodal evidence as to why Scala is bad seemed to center around(from your own anectodal links on your blog):

1) A crappy plugin. Which I agree to the point. It reduces productivity. I believe Martin O. should be given the opportunity to beef it up. Or are you saying that even if the tools evolve, Scala should be discarded.

2) And the reference on your blog of a guy who started down the Scala path and came back to java which wasn't entirely true. He went to Stratego/XT which is a meta code generator that happened to generate java. Not sure that is vindication of java. Maybe combinatorial parsers were too much to handle. They are incredibly complex and esoteric to say the least and he did the right thing and used a tool that met his needs.

If you read my other statements, they read exactly as you state. My point was you don't have to use language features if they don't suit you or you feel uncomfortable with them. Those features are not mandatory to use the language. And they definitely don't negate a lot of positives Scala brings with regards to FP(or at least the OO/FP superset it promotes). As stated, I think Scala tries to do too much in the language itself which leads to some of the arcane baggage in the syntax and is leading to the queasiness of developers to switch.

As far as implicits, you are way out of line. I agree with you on almost all of your contentions with implicits and I have commented so on your own blog. So please don't condescend. You seem to be the one getting mad at those who don't think implicits are a bad thing or agree with your world view of Scala.

 

 

Now, going from Java to Scala is not evolution, it's syntatic sugar. You can write "() => { System.getProperty("user.dir") }" instead of "new Runnable() { public void run() {System.getProperty("user.dir");} }", that's good until you realize you can write the java version in eclipse with "run" -> Ctrl+Space.

I'm not sure that syntatic sugar is only syntatic sugar. There is also expressiveness.

More expressive languages are easier to mantain in the long period

Çini Silimi ve Karo Silimi i?lerine yo?unla?an firmamiz sizin için mermer ve zemin silimi i?lemlerini de yapmaktadir. Dizayn Restorasyon, Restorasyon Çini bak?m?, temizli?i ve beyazlat?lmasi i?lemleri yapilmaktadir.

Scala is a more complex language than Java, period.

But having a more complex language available, can make your code less complex. So what is lost on one end, is gained on the other. I have seen way too much Java code that could not carry its weight and would be far easier to do with Scala (e.g. interfaces with a single method to make method passing easier).

Scala as a languges is simpler than Java (it's spec is shorter, less keywords). The percieved complexity comes from FP support that 95% of the developers are not familiar with. To dismiss Scala as a mere syntactic sugar over Java is a borderline idiocy (sorry for the hard language). It's like saying that a modern car is a mere convenience over the tri-cycle. Yeah, sure...

We at GridGain actually have real-life experience of working on a large & complex project with Java and Scala - and I can say (not from reading a book and writing cute 10 lines of code) but from the real experience that productivity gains you are getting with Scala are dramatic and worth every "penny" you spend on getting up to speed with it.

I'm getting somewhat tired of people half-assing one book (of few blogs), putting together few lines of code in RELP and porfessing their musings that the thing "is just too complex"... Neal Ford is right here - many of us crippled forever with Basic, PHP and Perl type of programming and can hardly see beyond that.

 

Nikita.

We at GridGain actually have real-life experience of working on a large & complex project with Java and Scala - and I can say (not from reading a book and writing cute 10 lines of code) but from the real experience that productivity gains you are getting with Scala are dramatic and worth every "penny" you spend on getting up to speed with it.

Do you think you could expand on these gains a little? Or have you written about it somewhere else? Just curious where you found out that it helped, and perhaps anecdotes on it.

Spec size? Really?

By this standard, Malbolge and Brainfuck are the easiest languages on the planet.

Besides, if the Scala spec had to go through the same rigorous process that the Java spec had to go through, you can be sure that the sizes would be about the same (Scala's would be bigger, I bet).

Anyway, feel free to bury your head in the sand and pretend that all these people who say that Scala is complicated are idiots who just "don't get it". You're one of the illuminated few for whom Scala is dead easy. Good for you.

 

 

 

Anyway, feel free to bury your head in the sand and pretend that all these people who say that Scala is complicated are idiots who just "don't get it". You're one of the illuminated few for whom Scala is dead easy. Good for you.

Just to clarify, I'm not saying people are idiots for not "getting" Scala (perhaps others are though).  I'd have to agree Scala is *more complex* for the simple fact it has a lot more features (implicits, mixins, pass by-name, higher order functions, functions as types, etc...).

But you also can't deny the initial reaction to Scala for a Java person is typically "WTF?".  The problem is those reactions get blogged about.  It's the person that says "I don't get it, therefore I'm going to try and convince you why you shouldn't either" is what  I take issue with.

... (perhaps others are though). 

s/are/are saying that/

 

<!-- p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica} p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px} span.s1 {letter-spacing: 0.0px} -->

Cedric,

 We all know that the only language worth mentioning is Fantom... It probably takes only 5 minutes to learn it fully, top-notch IDE support, etc. etc :)

Yes, I don't believe that Scala is more complex than Java. Being multi-paradigm language many folks confuse unfamiliarity with FP with general complexness of the language - and I’d argue that in 90% of the cases that’s exactly the source of “oh my god - it’s so complex” reactions…

You rail against implicits in Scala, for example. But I view it (Odersky, etc.) as a deliberate engineering compromise between human readability of the code and the enormous power the implicits give to frameworks developers. That’s what I like the most in Scala - it’s extremely pragmatic and developer-oriented language (which is a big surprise for something that still has live umbilical Academic cord).

And I repeat it again - I’m tired of monday morning quarterbacking by people who read a few blogs, may be a book, wrote a few lines in REPL and profess about their displeasures as if they developed anything beyond few dozens lines. As with any language it takes longer than that to come to any valid conclusions.  

 

Nikita.

 

I agree with Cedric B.

I've tried Scala several times and the syntax just doesn't do it for me. It has nothing to do with not wanting to try hard. Nothing to do with not being smart enough to get it. The complexity is in the wrong place.

I love FP. Always have. I love Clojure. It's incredible powerful and expressive. But it's not always easy. However the complexity is certainly not in its syntax.

I don't have anything against people who like Scala. I know people who can't stand the syntax of Clojure because it is a Lisp. I can respect that.

That's the key. Respect the decision. Stop whining that it is FUD. Stop trying to convince me. I get it. I get FP. I still don't like Scala, and it's not because I'm not "illuminated".

 

Curing cancer is hard. So is doing my taxes with an abacus.

People want to see a real purpose before investing effort into Scala.

So is doing my taxes with an abacus

That's often how I feel developing in Java. Note that I'm saying that from the language perspective only - because from the library/framework point of view both languages can use the same tooling...

Nikita.

... Scala and Vaadin. I should try both of them them :)

If other big names like Gavin King, Reza, Bill Burke, Cameron 'Peace' Purdy, Dan Allen ... (not in any particular order) say they like them too, I'll try them with weekend instead of going on my vacation :)

We at GridGain use both Scala and Vaading. 

 

Nikita.

These guy at GridGain post only to promote themselves, don't listen to them.

Here is some evidence: http://www.dzone.com/links/ehcache_24_with_the_new_search_feature_is_out.html

I'll take them seriously when they post without referencing GridGain in some way and with some solid arguments instead of yelling like little girls "No, You don't get it! It's good because it simply is!".

For the sensitive souls like you, Leandro, I don't even put my company name in my signature to make sure that innocent by bystanders like yourself don't get their feelings hurt...

Seriously, dude, re-read my comments above. 

Nikita.

Far from it.

Instead of abstract discussions he has real-life experience with both Scala and Java coding for large, performance-critical application.

I'm a Java EE developer and I have a quite rich experience with large enterprise projects. I also participated in Scala development for open source project. I can say that learning Scala is not so easy (but on the other side it's not SO hard for Java developer, considering that many excellent books and other resources exist), it takes time, but it worth your efforts. You will then write very expressive and concise code and have many features that Scala language has (and Java lacks) at your disposal. I also can't agree about libraries, have you worked with XML and Actors in Scala? There are many excellent libraries, tools and frameworks exist: LiftWeb, Akka, scalaz, SBT to name a few. 

I suggest you to read some good book, to develop some code and make conclusion only afterwards. Otherwise it looks like: "I haven't read about it, but I against it". (c)

I personally did not compare Scala against Java. I compared it against Groovy. I know... static vs. dynamic. But I felt that I got most of the productivity benefits from Groovy at a very low learning cost. Both integrate well with Java.

About 10 years ago, I learned Python. It was immediately clear to me of how it was going to help me. I breezed through the docs enthusiastically in a couple of days. With Scala, not all features are obvious in their benefit. So, I had less of a drive to invest enough time to get familiar. Perhaps, this should be made more clear with more illustrative scenarios.

I never evaluate languages in isolation. I always consider them in conjunction with the tools available. Having a good Scala IDE would at least have encouraged me to use the Java subset of its features at least and gradually get more and more familiar with other features (It’s better now than before, of course). But having to work with API designed with Java in mind (verbose, since Java lacks convenience features) from Scala often felt less productive than using Java directly, except in cases where Scala does shine (less, early on). I don't demand a feature-rich IDE outside JVM languages. It has to do with its over-engineering culture among Java APIs which makes it non-viable without good tooling for me.

On the other hand, I am more likely to use Scala in the future than the more classical statically-typed functional languages like Haskell and ML, which I also explored.

I am being vague here. I felt that I could not grasp a quintessential spirit of the language as trivially as I could with the more successful languages. And I place this responsibility on language designers rather than myself. I am a user. It is the designer’s job to make it user-friendly. I don’t have a tough engineer mentality.

Of all these, I find the state of its IDE as the biggest concern (Mock this if you like. But I am being practical). I am willing to put effort into the rest.

P.S: I read Scala docs on the site and some web articles, but not any books. That may have had something to do as well.

I agree that Groovy has syntax very close to Java.

I also began to learn Groovy after I had felt that I need FP features that lack in Java. After I had learned language basics I heart about Scala and short period of time I read about both. But very fast I understood that Scala is much more prospective language and switch my attention to it.

Btw, the creator of Groovy, James Strachan wrote in his blog: "Though my tip though for the long term replacement of javac is Scala. I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html

 

Then I am glad he did not look at the Scala Book until too late:-)

> I agree that Groovy has syntax very close to Java.

The issue is not syntax; it’s the semantics. It's not what it looks like; it's what it takes to distill its core design principles to personal coherence and attain an intuitive feel for its soul.

> I understood that Scala is much more prospective language and switch my attention to it.

I get that it is a more ambitious attempt too. It has advanced features that Groovy cannot provide; but they do not seem to yield proportional benefits in practice (with a few exceptions); or I at least I have not understood how to leverage its advanced features pervasively, so far.

I am personally impressed by Groovy++. I am also not sure how much momentum the project has. But it seems to preserve the simplicity and practicality of Groovy, while adding benefits of static typing, retaining the dynamic typing option, adding the proven core of features of functional languages, without getting too clever for its own good. This elegant blend of typing reminds me of Boo for .NET, which I enjoyed using in the past.

In any case, I will retain Scala in my toolbox. I won't write the bulk of the programs in it until tooling matures; but can always use it for those special cases where its features do matter. I have similar attitude towards Clojure. The trouble is, it has not been a learn-once-and-remember-forever language, since I did not yet develop a succinct and coherent feel for it. Without routine use, my modest proficiency seems to be on a faster path to atrophy than would be with other languages in such a context.

The single biggest problem w/Scala today. Current IDEA plugin is broken, Eclipse side is laughable... Odersky and co. are Emacs/Ensime users and just starting to pay attention to IDEs (Eclipse in specific). JetBrains apparently has one guy working (part-time?) on Scala plugin.

So, yes, solid IDE support is few years away. 

Nikita.

IDEA right now is OK. If you don't use implicits and/or weird uber-complex types, it'll work just fine.

And what other features I should stay clear off? I mean, c'mon... 

I love IDEA but the Scala support is experimental at best right now. I would accept lack of features but having broken error highlighting is simply unacceptable. I successfully re-build the entire project, and I still have red highlights in my files. We are forced to do demos with broken plugin and explain to the audience that this is a IDEA's f&*-up.

It least it compiles....

I've bounced around a little while learning and working with Scala, but I find the combination of emacs/ensime and sbt to be productive (I always use emacs keymappings, anyway, even when I'm using an IDE).  The Netbeans Scala plugin is usable, too, although it's not up to the same standard you'd be used to when using Netbeans for Java coding.

You graduate students have too much time.

I' m learning the AKM with my time.

Can learning a new source language teach you more than ruby? i.e JRuby in your case.

What more than closures do you need?  Please don't note syntactic sugar.

 

Can learning a new source language teach you more than ruby? i.e JRuby in your case.

My opinion is: yes.  There actually seems to be a lot of interest in Scala from Ruby developers, even in light of the fact that JRuby exists and is their most direct path to the JVM.

 

After all, Duplo is clearly far "simpler" than Lego Technic.

Now... go and build me a robust and structurally sound model of the Eiffel Tower please, a nice simple task with no moving parts.

At some level, all turing complete languages are "the same", so that's not really a helpful metric.

The expressivity of a language is a difficult concept to pin down. It’s something that anyone who’s used more than one language will develop an intuition for, but how do you explain why one language is more expressive than another? I’ve recently convinced myself that it boils down to the scale at which a language makes it convenient to use a particular type of abstraction.

I blogged about this here:

http://www.paulbutcher.com/2010/11/language-expressivity-is-all-about-scale/

I am surprised where this discussion has headed. Some people here stress the point that Scala is heavy on syntactic sugar and does things in the language that could be done better in the libraries. Nothing could be further from the truth. No matter whether you count keywords, or syntax rules, Scala is a smaller language than Java 7 and a much, much smaller language than C#, F#, or C++. It is foremost a library-centric language that removes language-sepcific sugar by library abstractions. Want examples?

- No enums, there's just an Enumeration object in the standard library

- No primitive operators, they are methods

- No separate rules for annotations, they are constructors

- No syntax for asserts, they are methods

- No complicated rules for statics, they are objects

- No autoboxing, implicits do that job for you

- No numeric conversion rules, implicits to that also

- No collection literals as in Groovy, Clojure and future Java, it's just objects and method calls

In every case Scala throws out a language construct and replaces it by a library construct.

Now, people might disagree with these choices (for instance it has been argued that java enumerations allow more use cases than Scala's). But it's simply wrong to say that Scala is heavy on the syntactic sugar and Java isn't - the opposite is true.

On the other hand, if people think that "library" means truckloads of XML configurations and semantics-changing annotations, then it's true Scala reiies much less on those than Java does, because the composition mechanisms in the language itself are stronger.

Regarding decent IDE support, I believe it will happen much faster than people here predict.

 

- Two ways to return from a method (implicitly or explicitly using "return")

- Four ways to call a method (using ".", using space, with and without parentheses)

No syntatic sugar?

> - Two ways to return from a method (implicitly or explicitly using "return")

 

The rhs of a method is an expression in Scala, so no return is needed. Return is still useful if you want to return prematurely. Overall, the unification of statements and expressions is a huge simplifcation, e.g. no ternary ..?..:.. operator needed.

 

> - Four ways to call a method (using ".", using space, with and without parentheses)

 

The space replaces all uses of operators in Java. Being able to drop the parentheses gives you the uniform access principle. It avoids embarrassments like it's array.length, but str.length().

 

> No syntatic sugar?

 

No syntactic sugar here. Of course, if you ask me hard whether we can simplify further, I'd say yes (and I have stated this publicly.) But overall, Scala tries hard to replace special language cases with general abstractions and library constructs.

Addressing on the order of scala is awesome.

James Stuckey