Opinion: Is Scala the new EJB 2?

by Alex Blewitt on Nov 22, 2011 |

Stephen Colebourne, developer of the Joda Time library and spec lead for the JSR 310 date time improvements to the Java language, has posted a thought-provoking piece on the applicability of the Scala language. He compares it to EJB 2, which he said was the nadir of the Java EE specification:

… where huge amounts of boilerplate, XML and general complexity were foisted onto the Java industry. The spec was widely adopted, but adoption was followed by criticism. Developers found that while EJB 2 sought to reduce complexity in building an enterprise application through an abstracted higher level API, in reality it added more complexity without providing the expected gains.

Although he notes he prefers the Fantom language – but is also open to other languages like Kotlin, Groovy and Ceylon – he thinks that Scala is not suitable for the future.

One of his objections is that Scala doesn't provide a suitable module system. He notes that Java didn't initially provide a module system (and currently still doesn't, though at least now it's an acknowledged need) and had to have others such as Maven, Ivy and OSGi add onto the basics. However, those who choose to ignore module systems can still cause problems for those who want to modularise; and when working with large systems, modularisation is an important maintenance tool to have.

Stephen also suggests that had Java had modules, it would be possible to ship a JVM without CORBA support, a legacy technology that is now rarely used outside of RMI in the Java landscape (and generally has been superseded by either SOAP or REST for inter-server communication).

In fact, there was a proposal for modularity over two years ago, which was quickly canned. There was severe resistance to cater for versions or modules (upon which every module system needs in order to operate). At the time, Scala was not enterprise ready and over two years later, is still in the same situation.

Stephen also identifies the type system as being overly complex, agreeing with Steve Yegge's views:

The... the the the... the language spec... oh, my god. I've gotta blog about this. It's, like, ninety percent [about the type system]. It's the biggest type system you've ever seen in your life, by 5x. Not by an order of magnitude, but man! There are type types, and type type types; there's complexity...

They have this concept called complexity complexity<T> Meaning it's not just complexity; it's not just complexity-complexity: it's parameterized complexity-complexity. ... I mean, this thing has types on its types on its types. It's gnarly

Stephen also highlights the fact that the type signatures – initially used to demonstrate that a method compiles correctly – have effectively become meaningless, even before the Unicode method support is used. He gives the following method signature, from the Scala core libraries, and challenges those to describe what it does:

def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

In fact, Stephen argues that the use of static typing is giving static typing a bad name:

Oh, and by the way, I do get the idea that the humongous type system is there to prevent compile errors and pre-check your code. But applying that logic in the opposite direction would imply that no-one gets any real work done in languages with dynamic type systems. For me, Scala's type system is way way beyond the point of sensible returns for a language feature.

In essence, Scala's type system is giving static typing in general a bad name.

These are not particularly new views. Ceki Gülcü, creator of the Log4J and SLF4J projects, asks if Scala is worthy of your trust, noting that the language has evolved and broken backward compatibility so many times (with no views to the future of fixing it) that it cannot be used:

However, there is one aspect to the Scala language which I find deeply annoying. Scala keeps breaking binary compatibility with every new release. In spite of previous promises, compatibility was broken in release 2.7, broken again in release 2.8 and broken yet again in 2.9. As I understand it, Scala language designers are forced to breaking compatibility whenever Scala library traits change in an incompatible way

To expand on Ceki's point, it is broadly the case that before Java came along, compiling from source was the way that portability was achieved between different operating systems and different versions. It wasn't until a standard C ABI was created that binaries could be made available and then used for different versions of the same operating system, ultimately leading to binary distributions like Debian, RedHat and Ubuntu. It was a lack of these ABIs that prevented companies from shipping binary versions of their commercial products (and they certainly didn't want to share the source) in the earlier 1.x releases of the Linux kernel and operating system.

Ceki further makes the point that "Competing languages will eventually close the gap, and Scala will stop being cool."  Scala had a chance, when it was new, to capture the imagination of a large set of Java programmers. It still initially tempts those who want to learn about functional programming aspects and to provide concise code. But by consistently ignoring what makes a language stable over time, and following the same path of bloat that Java had done years before (whilst ignoring Java's compatibility between releases) has kept Scala in the sidelines of major enterprise projects. Yes, there are some success stories of teams adopting it initially, but there are no success stories of teams successfully maintaining that codebase a year or two later.

And now, we have a raft of other JVM based languages that provide a similar avenue of exploration, from Fantom to Xtend, which are stepping up to take their place. Even Java is providing both modules and lambdas in the next release; and even though it's been delayed a further year, is still likely to bring functional programming to the Java masses far quicker than Scala will stabilise. It may be too late for Scala to put its house in order before Java overtakes it.

Related Editorial

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Just don't use it then... by Neil Bartlett

I'm not a Scala user, and I have no plans to use it.

However I find it sad that Stephen spends so much of his time attacking a language that competes with his own favourite (Fantom) rather than pointing to the benefits of Fantom. Likewise Gavin King seems more keen to go on the attack than to talk about what might be great in Ceylon.

This is such a negative way to make an argument; I think I would have more respect for Stephen and perhaps even take Fantom seriously if he simply stated that he doesn't like Scala and won't be using it. There is no call for continually berating those people who do choose to use it.

Just sad by Steve McJones

While the rest of the world evolves at a huge rate (just look at F#, CoffeeScript, Haskell, Perl, C#) Java experts seem to be stuck in some kind of loop, fighting against every sign of progress.

This is sad, because in the past the Java community was proud that they had a rapidly independent evolving ecosystem and often criticized .NET developers for their "we ignore everything not coming from Microsoft" stance.

I cannot understand why there is so much hate targeted at ... programming languages. Seriously, nothing better to do?

Let's consider a world where one of those "new" languages would provide some benefit over Scala. Would you really agree to wait yet another decade for those languages to reach the level of maturity and stability Scala currently has?

These FUD spreaders really make the Java ecosystem look bad.

Re: Just don't use it then... by Jesse Kuhnert

There is no call for continually berating those people who do choose to use it.


There certainly is a good reason to share his opinions, namely that I've also found many of them ring true after using scala on a fairly large project and the "good human" thing to do when you discover things like this is to share the experience with your fellow developer community in case it saves them time or just lets them know they aren't crazy.

People getting angry and saying "just don't use it then" makes scala sound all the more suspicious. not less so. It has some ugly warts, and it also has some pretty cool things but the warts I noticed much more than the cool things.

Re: Just don't use it then... by Gavin King

Likewise Gavin King seems more keen to go on the attack than to talk about what might be great in Ceylon.



When news of Ceylon first leaked out here, quite a number of people asked "why not Scala?"

At first I thought it would be a good idea to respond to the question by pointing out some general areas where I thought that Scala did not provide what I'm looking for in a programming language (without getting into too much technical detail). The alternative course of action was to leave the question unanswered.

Now I know that this was a mistake. It made me look negative, and made me a target for personal attacks. I'm now adopting a very strict policy of leaving the question unanswered. Happy?

Re: Just don't use it then... by Russell Leggett

When I go to amazon to buy a product, it's great to see a lot of high reviews, but after looking at a couple, I go straight for the 1 star reviews, to see what people hate about it. You can't make an informed opinion on something unless you hear out the naysayers. Ultimately, yes, the answer is not to use it if you don't like it, but I think there is a place for negative commentary.

There is also a difference between critical and cruel. Personal attacks and unsupported claims should be left at the door, but as long as it sticks to technical merit, I say fair game. I would rather read about a showstopping problem somebody else has experienced than experience it myself. Others capable of reasoning out their own opinions can read and determine if the problems outweigh the benefits.

I like Scala by Brian Schlining

I've been using Scala with various projects and have had very, very good experiences with it. I think the language design is brilliant. Sure that method signature presented above looks intimidating ... but that comes from the fact that many of the language 'constructs' are provided as libraries rather than built into the language itself. This makes for a very flexible and extensible language. The down-side is that developers get to see details that, in most languages, are buried inside the language runtime. That method just adds two collections together in a type-safe way AND returns the appropriate type of the collection (List, Seq, etc). Here's an example:

// concatenate 2 lists of integers; return a list of Ints
scala> List(1, 2, 3) ++ List(4, 5, 6)
res0: List[Int] = List(1, 2, 3, 4, 5, 6)

// concatenate a list of integers with a list of Strings; return a list of Any (i.e. Object)
scala> List(1, 2, 3) ++ List("A", "B", "C")
res1: List[Any] = List(1, 2, 3, A, B, C)

// Concatenate a Seq with a List; return a Seq
scala> List(1, 2, 3).toSeq ++ List(4, 5, 6)
res2: scala.collection.immutable.Seq[Int] = List(1, 2, 3, 4, 5, 6)

Not very strong arguments. by Serge Bureau

True Scala does not have yet a true modular api.

But with the way the Package class work compare to Java, it is much less likely to have modularity issues.
Also the fact that the Scala code is between 3 to 5 times smaller than Java code, again much less modularity issue.

Also I look at Fantom, granted it looks better than Java, except for a very important issue, mixing Dynamic with Strongly type, means you never really are "strongly typed"
Not strongly typed means, keep it out of enterprise exempt for little projects.

Anad also the "complex Scala type system": first get informed.
Most complex type system are for tools designer not everyday code design. If needed it is there.

Now for the too numerous advantage of Scala over "Fantom":
Generics that works,
Much better actor support,
Much better type system,
Totally strongly typed,
implicit conversions.
cascading traits,
amazing DSL capabilities (while staying strongly typed),
tuples,
named arguments ,
pattern matching,
sensible exception handling,
...

Re: Just don't use it then... by Diego Fernandez

Likewise Gavin King seems more keen to go on the attack than to talk about what might be great in Ceylon.


I think that in fact were the readers of the early -unplanned- Ceylon announce who attacked Gavin.
And I have to admit that I was one of the ones saying "Why not Scala?".

To me the answer is "just because you can create a new language", and that's fine :) The only thing that bothers me of the new JVM language announcements is that they don't have anything fundamentally new, and that is the problem of working with a common platform like the JVM or CLR: you gain compatibility but you loose innovation.

In the end people is going to choose one tool over another because of a lot of factors -not only the technical merits-.

I think that Stephen over reacted against Scala. The problems about Modularity and Concurrency are not specific to Scala. The first has it's roots in the JVM, and the second is a general problem of any operational language.

But I agree over the type signatures and the cryptic syntax. You can work without using that cryptic syntax, so I don't see that as an "intrinsic" Scala problem.
Most of the Scala frameworks out there chosen to embrace those ugly syntax "shortcuts", and to overuse pattern matching and case classes for things that can be resolved in other way.

As an example why not everything has to do with the "language merits":
Compared to Scala, Groovy is messy (is like the Cathedral and the Bazaar). But is well supported by the mayor IDEs and is really easy to mix with Java code. Which makes it a pleasure to work with. Yes it's inferior in some language features, but working with the AST transformations (like @Immutable or @Canonical) makes writing usual "business Java code" really fast. So if I have to convince a team of "usual business" Java devs to use Groovy or Scala, I think that I have more chances in favor of Groovy.

Nothing is perfect and every programmer must choose its language based on d by jean-simon Larochelle

Yes it is true that Scala can be complex. However I think that for most of the application code a programmer routinely writes it is not so bad. The example given is a very powerful example and what's more it involves something that programmers would/should not use on a routine basis: operator overloading. I don't like operator overloading when it is used for collections. I think operator overloading should be used for math almost exclusively. For that it is really nice to have something like Scala that allows you to define addition for complex numbers (for example) and then execute at a reasonable speed (very close to Java). Scala is the only language that allows that.
Sure, Groovy allows operator overloading. However it is so slow that writing any kind of demanding math application using it simply does not work. So, yes with Scala you might have to write more complicated code once in a while but you will very rarely get stuck not being able to express something which is not the case with something like Fantom and its half bake (last time I looked) generic support and mix model.
For me right now the most interesting alternate JVM language are Scala and Clojure. They are interesting because they both are different enough from Java (offer something other than lambda and loosing type information) and execute at reasonable speed (speed is required in my application domain).

another effort to confuse people by nicolae caralicea

This is just another effort to confuse people about Scala.

Fortunately there are many developers who love and see the power of Scala and nothing will stop others to join them, too.

Learning Scala it's like "reading", hard at the beginning and natural after.
We should all accept that we need to start by learning the "whole alphabet" that Scala is giving us, otherwise we'll just keep on doing over and over the same wild programming we got used to.
How come James Strachan the author of Groovy has such a different point of view?
macstrac.blogspot.com/2009/04/scala-as-long-ter...

It's really sad that it's coming from someone who should also see it.

Scala maybe hard but its a worthwhile investment by Faisal Waris

Scala is quite feature rich so it will take a while to master but the payoff is worth the effort. I can relate to this statement based on my experience learning F#. In the end I am very glad that I did it.

Recently Google did a benchmark of 4 languages (Java, Scala, C++ and Go) by asking the experts in each to implement the same algorithm. Scala code was 1/3rd the size of Java code (and Scala was faster too on the same jvm).

Clearly there is widespread dissatisfaction with Java and hence the advent of so many new jvm languages. I don't think that you can fix Java without really turning it into a new language. Scala has the most momentum out of the non-Java jvm languages.

I believe that actual user code will be much simpler in Scala than the 'infrastructure' code example of "++" operator overloading shown above.

Re: another effort to confuse people by peter lin

I my bias opinion, "wild programming" is primarily the result of the programmer and not the language. I used to think Perl is un-maintainable due to first hand experience in the 90's. After I saw a great piece of perl code that was well written, and documented, it became clear my own crappy perl was due to laziness. I took too many short cuts and wrote stuff in a terse manner that made it hard to maintain. The same thing happens with every single programming language.
I've seen great Java code and really aweful java code. I've seen really bad C# code and really good C# code.
Arguing over which language is best is really a pointless activity in my bias opinion. Language selection is really a personal preference and has very little to do with the merits of the language. If language elegance was key, everyone would be using Prolog/Lisp.

Clearly, history has shown that developers go with what feels comfortable. If a language is too hard to grasp in a short amount of time, a developer may decide to look some where else. For the record I love LISP, but I don't go around telling the world it's better than sliced bread. People who hype new languages like it's sliced bread are asking for criticism. Only way to avoid criticism is to keep the language to yourself and never let others use it. Once it's out "in the wild", you have to take the good with the bad.

Re: another effort to confuse people by Serge Bureau

I my bias opinion, "wild programming" is primarily the result of the programmer and not the language.


This is only partly true.

Java protected against going against array index bounds, it also protect pretty well against memory pointer to unsafe area.

Without this kind of compiler protection, even the best programmers will encounter those errors.

So definitely the language can help a lot to have good code, granted it cannot protect against everything. This is also why strongly typed language are much safer than dynamic ones.

As far as elegance, Prolog and Lisp ? Give me a break

Re: another effort to confuse people by Samuel Vincent Paal

As far as elegance, Prolog and Lisp ? Give me a break


Well, let's take some lisp family member core language spec and compare it to any other language spec. Let's say in terms of number of pages. There it is. Instead of hundreds of pages syntax definition, weird inheritance rules and the whole shebang that makes up a modern mainstream language, there are few simple concepts and syntax rules, that define the language. That's it. After half an hour you're ready to start writing code. If that is not elegance, then what is? Will the elegance make developer more productive? It's a totally different issue.

Re: another effort to confuse people by peter lin

Like I said, my bias opinion. I love LISP and s-expression syntax. Languages can definitely make things easier and safer. A language can only go so far towards encouraging "best practices". It's not just junior developers either. Clif Click had a recent entry about java's final and how people use it. Even developers with lots of experience do things that "could" be considered "wild" or "crazy".

I'm sure those that love C and hate OO think Java and C# suck. programming languages don't live in a bubble. it is always perceived through the eyes of a developer.

Re: another effort to confuse people by Serge Bureau

Lisp is in a way elegant and lean.
Be there is lean and anemic, the proof is in the usage. It is barely used.

Plus a syntax with zillions of parenthesis is not elegant at all, in fact it is unreadable.
A language that can modify itself without static typing is dangerous to use.

Plus you cannot have elegant DSL written in Lisp (as far as I know)

As for Prolog, go ask the Japanese that had a futuristic project decades ago to use it everywhere, they soon met a lot of limitations and they totally dropped it. Once again, it was elegant but mainly anemic.

Re: another effort to confuse people by peter lin

Lots of people hate "all those parenthesis". Just because I like it, doesn't mean it is elegant. It only means I feel it is elegant. Every language has ugly warts and beautiful features. The bigger challenge with LISP/Prolog being widely used is S-expression. It is just too weird for most people and many people have a hard time thinking in "S-expression".

Having positive and negative feedback about a language is a good thing to me. It "helps" to keep developers grounded. It is far too easy to get stuck in one language and think it's the "be all/end all" of programming languages.

Re: another effort to confuse people by Faisal Waris

In my biased opinion the most 'beautiful' language is Haskell - bar none.

When I look at Haskell code I cannot but admire its beauty (even though I sometimes don't understand what it's doing)

Haskell is like the 'click' language of Kalahari Bushmen; a few dots, some symbols and words, and you are done.

Re: another effort to confuse people by Serge Bureau

True it is quite clean.

But being purely functional is not practical.
For this reason I find Scala more practical.

Even if I am not an expert at any of them, I understand Scala better.
And loosing the "Object" side is too much of a loss to consider Haskell as more than academic.

Will the new mainstream language based on JVM for sure? by Adam Nemeth

We're frustrated by Java, that's for sure. We had enough of it.

But will its successor be JVM based? Or the only real solution will be that we throw out everything and start from scratch?

Also, what's the problem with Java? Why do we hate it that much?

I think, that problem is static typing, or rather, explicit typing: that the code is full of type-information. A new static-typed language won't help that.

We entered into the era of trace-based compilers. This is the way Google Chrome and other browsers build real classes in javascript at runtime. But lints ("syntax checkers" for dynamic languages) could also be trace-based, and they could provide "compile-time" type safety, with all the benefits of dynamic typing.

Also, a general notion is that the Next Big Thing should be a functional language.

Fine, but will it be such a radical language as Scala? Scala is really coming from the deep veins of functional languages: true lisp-style functional language, with all these "int -> int -> int" kind of declarations.

What did history taught us?

History taught us so far that the next language will never be a radical change.

C wasn't a radical change compared to ALGOL or any other contemporary languages.

In the 80s, OOP languages were pouring from the tap, yet none of them got widespread.

C++ became widespread as it was a minor modification on top of C, and Delphi got widespread as it was a minor modification on top of Pascal.

The 90s were dominated by C++ and Delphi. Then we went to the era of "multiplatform" and "true OOP", interpreted languages. Was Java the only contestant? Far from it: Python and its friends are not much younger than Java.

Yet Java won, as it was a minor modification on top of C++.

The 2000s were dominated by Java.

Also, why is a decade dominated by a language?

Because it gets into higher education. I guess it's a big drive in both Java's and Delphi's (former) popularity, that we have a whole lot of developers, trained mainly in this language. Perhaps, if they had learnt python or php all the way, they'd do that instead.

What'll be the next? I'm not sure. I don't think JVM is an issue, in the age of web services. But non-radical change and education surely is. So the question is:

Are there any contestants less radical than Scala?

Re: Will the new mainstream language based on JVM for sure? by Serge Bureau

I do not hate Java, and I do not think people hate Java.

But it is in a state where evolving it is difficult.
Scala seems to offer the best alternative (but not the only one) to preserve what you have with Java while moving to better productivity and power.

Starting from scratch is not thinkable, there are billions of dollars involved.

The JVM is a great thing, I am sure it can be improved but it is a great common denominator for numerous language and very good way to exchange code almost transparently.

So I bet on JVM based language for the foreseeable future.

Re: Will the new mainstream language based on JVM for sure? by Faisal Waris

Scala actually traces its roots to ML family of languages (via Haskell); OCaml and F# are part of the same tree.

ML combines 'functional' aspects of LISP and adds strong typing with type inference (LISP itself is dynamically typed).

Type inferencing makes statically typed languages feel like dynamically typed ones. For example F# code is as succint as say Pyhton's but provides compile type error checking and much better performance.

Languages such as Scala and F# are multi-paradigm; they support OOP, Functional and Actor programming paradigms (missing is Logic programming; a la Prolog).

I believe that a modern language should be a multi-paradigm language. For example, Google's new language Dart also supports OOP, Functional and Actor programming models.

I think that the JVM and .Net ecosystems are important (at least for now). The web ecosystem is another one that needs to be supported well. There is room for both statically and dynamcially typed languages but we are starting to see overlap in type systems. Scala certainly is a worthy contender in this mix.

Re: Will the new mainstream language based on JVM for sure? by Steve McJones

I'm pretty sure you are mixing things up a bit here.


> I think, that problem is static typing, or rather, explicit typing: that the code is full of type-information. A new static-typed language won't help that.

You got it right, that the problem is not static typing, but the requirement to put type information everywhere. Most statically-typed languages actually use type-inference and only seldom (if at all) require explicit annotations. So, yes, a statically-typed language can perfectly solve this.


> [...] JavaScript [...] dynamic typing [...]

There are no benefits in dynamic typing and while compilers get better to solve the problems dynamic (or unityped) languages cause, there will always be a performance penalty compared to statically typed languages.


> Fine, but will it be such a radical language as Scala? Scala is really coming from the deep veins of functional languages: true lisp-style functional language, with all these "int -> int -> int" kind of declarations.

That's pretty much wrong. If Scala is radical, then on the object-oriented side of the language. The functional parts are pretty much standard, nothing exciting or new.


> History taught us so far that the next language will never be a radical change.

Scala provides a very painless introduction to Java developers, heck ... you can even just paste Java code into a Scala file with IntelliJ and get it automatically converted.


> Are there any contestants less radical than Scala?

There might be, but the problem is that they have neither the mindshare, support, documentation, maturity, stability, ecosystem, IDE support, commercial backing and libraries. They are just not there (yet).

Looking at Fantom, Ceylon, Kotlin ... they pretty much promise (they haven't actually delivered anything usable yet) that they will come up with solutions for today's problems, but a decade too late.

Imagine how long it will take for these languages to be even remotely at Scala's level of development. Then look at Oracle's roadmap for Java 8, Java 9, Java 10. When the “contenders” arrive in a few years they have not to compete against the current state of the art, they have to show how they improve on Java 8, Java 9, Java 10 and Scala 2.16 or Scala 3.4.

Scala is years ahead of that. Java's road map pretty much contains the stuff Scala is testing right _now_.

Re: another effort to confuse people by Cedric Beust


Well, let's take some lisp family member core language spec and compare it to any other language spec. Let's say in terms of number of pages.

The Brainfuck specification fits in one page.

Re: another effort to confuse people by Serge Bureau

By the way Forth has even a smaller definition. And much more efficient than Lisp.

They are simple, but anemic by todays standard.

the way forward by Fernando Racca

Despite the original authors comment, Scala, or better said, the proposals that Scala brings to the table are the way forward, because Java 8 will adopt much of it. Scala makes you a better programmer because it puts so much emphasis on functional programming, and opens your mind to better abstractions. Despite the derogative comments about the type system, Scala can be simple and far more powerful than any other language (except Haskell). That simplicity comes from immutability, excellent collections, and composing reusable building blocks.
High order, abstract types are advanced features, mainly intended for library writers (ScalaZ is an example ) but you can write really simple to understand code without ever needing it.

The original article likens Scala to EJB2, but some of the claims are really without a proper argument. Scala does not provide good modularisation support? package objects are far better than anything than java along can offer. why is this a problem that scala needs to solve? The comparisons with Fantom matter as much as if they were about Kotlin. You don't need to reinvent the wheel. Scala is mature and increasingly more used.

If anything, the only valid point is been made by Ceki Gülcü, regarding binary compatibility.

Alternatives by Joao Pedrosa

If you don't like Java or the JVM there are plenty of alternatives nowadays. Let's list some:
* C# or .NET
* Google Go
* Javascript or Browser
* Python, Ruby
* Google Dart is in the works

Making developer tools is tough. Many come around, few break out of niches. No matter how statically typed they are.

The article touches on some issues. Modularity. Challenges from new hardwares with different form factors and numbers of CPUs.

Scala not being a silver bullet doesn't really count against it as there are no silver bullets to begin with. What counts against it is things like the article said, the dependency on the JVM, the slower compiling times...

The really ugly code sometimes users make use of can make any programming language to look bad. To write ugly code yourself while having to keep up with so many issues must suck and you may enter into denial.

suggestive quote by Joost de Vries

That's a very crafty slur, I must admit: "Scala, the EJB 2 of languages".
Also the quote about the size of the language specification sounds very damning.

I've been following Scala for 6 years. Waiting to be able to use it at work. (business information systems)
And I'm not ready yet to run with the lemmings and the über-alpha-geeks to the next shiny thing.

The improvements of type inferencing and functional programming on top of the JVM in an enterprise environment is what I've been looking for since the .Net runtime came out.

And the Typesafe stack seems to be the much needed commercial momentum.

How much easier to write Joda Time in Scala ? by Serge Bureau

Ask M Colebourne, how much easier it would have been to write Joda Time in Scala ?

Then come back to say Scala is the new EJB2

Joda Time is a nice library, it would be smaller, more extensible and much easier to write and use in Scala.

Typical by Dan Tines

Well you knew the Scala fanboys were going to get their panties in a bunch on this one;) Personally I don't have a problem with Scala's complexity. I don't think you have to mess around with higher-kinded types and stuff like that if you don't want to. Actually, you can just use Scala as a terser and more readable Java. Frankly, Scala's traits interest me more than its functional qualities. Single inheritance has problems in modeling domains effectively.

By the way, there seems to be an underlying premise in many of these discussions that it's a zero sum game among mind-share of alternative JVM languages. I don't buy that. If Kotlin takes off (which I believe it will), it should mean more of an uptake for Scala.

Re: Typical by Serge Bureau

Actually, you can just use Scala as a terser and more readable Java


That is really a simplistic and limited view.

As far as "fanboys", I do prefer somebody that is a fanboy of something instead of supposedly "neutral".
To me being neutral is to have no real opinions, boring.

Re: Typical by Dan Tines

That is really a simplistic and limited view.


Actually, the counter-argument that is generally given to "OMG, it's looks like APL puke with all the operators" is you don't have to write code that way if you don't want to.

As far as "fanboys", I do prefer somebody that is a fanboy of something instead of supposedly "neutral".
To me being neutral is to have no real opinions, boring.


And that's your problem Serge. It reminds me of the "good 'ol days" over at Javalobby where you would throw a fit everytime some Ruby article would come up. Then you came around to Groovy for a while, and now you're in full Scala fanboy mode.

Some of us would rather be more objective than fanboyish. At some point in time you have to look at the bigger picture, especially when making decisions for a team.

Re: Typical by Serge Bureau

Actually, you can just use Scala as a terser and more readable Java


I was commenting this affirmation of yours and I said it was a simplistic and limited view.
You where not in agreement, so lets see a few points we would leave out of Scala if we followed your advice:
- All the functional part !!!!
- Pattern matching
- Named parameters
- Implicits
- Closures
- Case class
- Continuations
- All the abstraction of the type system
- Raw strings
- Traits !!!
- Actors !!!
- Package
- Path dependent type
- Tuples
- ...

So I hope you see why I think it is simplistic and not a good advice at all.
Of course you can learn any of those things by step, but it would be a huge mistake to use Scala only as a keystroke saver over Java ?


And that's your problem Serge. It reminds me of the "good 'ol days" over at Javalobby where you would throw a fit everytime some Ruby article would come up. Then you came around to Groovy for a while, and now you're in full Scala fanboy mode.

Some of us would rather be more objective than fanboyish. At some point in time you have to look at the bigger picture, especially when making decisions for a team.


I stand by what I stated.
I am not a fan of dynamic languages because it is never really safe, but I preferred Groovy to Ruby because of the better integration with Java and the syntax.

Now go read the article where the Groovy inventor said he would not have come with Groovy if he had known that Scala was coming. And Gosling would choose Scala if he was to choose a language now.

People that make decisions for a team the way you do would have kept us to the waterfall model and we would still use Fortran

Re: Typical by Dan Tines

So I hope you see why I think it is simplistic and not a good advice at all.
Of course you can learn any of those things by step, but it would be a huge mistake to use Scala only as a keystroke saver over Java ?


No


Now go read the article where the Groovy inventor said he would not have come with Groovy if he had known that Scala was coming. And Gosling would choose Scala if he was to choose a language now.


It's irrelevant what they say

People that make decisions for a team the way you do would have kept us to the waterfall model and we would still use Fortran


Serge, people that make decisions the way you do would have us programming in COBOL and GW-BASIC

Re: Typical by Serge Bureau

It's irrelevant what they say


;-) ;-) ;-)

I won't qualify your reply.

Best of luck

Re: Typical by Dan Tines



Best of luck


You're going to need it, that's for sure;)

Re: Just don't use it then... by Richard Hightower

Gavin it is like this. The only people who get criticized are the ones that are doing something. You just happen to do a lot. I happen to agree with a lot of your points about Scala (at the time I read them). My opinion has drifted since.... Any way... A lot of people value your opinion. Please keep answering. Critics be damned.

A couple of brief comments... by Richard Hightower

There was an article that discussed Scala recently as well. After writing the article David Pollak and Dick Wall Discuss Barriers to Scala Adoption, I am much more open minded about Scala. It is on my list of things I want to learn (sadly the list wraps around the world several times).

Also let's not make Gavin King the poster boy for the anti-Scala movement. Just because you want to write a new JVM language does not mean you are anti-Scala. I am quite happy to see new languages. Dart, Ceylon, Groovy, Scala, Kotlin, Clojure, etc. I have never learned a new programming language that did not improve my programming skills and improve the way I think about programming.

Re: A couple of brief comments... by Serge Bureau

I am not as open as you are.

I want some choices, but it is getting ridiculous.
About half the ones you named do not bring anything.

And no, not all language improves your programming skills.

I do not need 500 word processors ? The same for languages.

Tools are making it easier to create new languages, but the reason to create one should not only be that you can.

And with DSL capabilities in many languages, the need for brand new ones should be much less (not more)

Re: A couple of brief comments... by Richard Hightower


RE: I am not as open as you are.



You win. Good catch.


RE: I want some choices, but it is getting ridiculous. About half the ones you named do not bring anything.


Good point. I'll let everyone know that a perfect language has been created and we don't want anymore.


RE: And no, not all language improves your programming skills.


Good point. Since I was speaking of personal experience and you know me much better than I know myself... I can only assume that you are again correct.


RE: I do not need 500 word processors ? The same for languages.



Great analogy. Your skills at debate far exceed mine. You are the clear winner of this Internet argument.


RE: Tools are making it easier to create new languages, but the reason to create one should not only be that you can.


I'll put the word out. No more computer languages no matter how easy it is.

Thank you for setting me straight.


RE: And with DSL capabilities in many languages, the need for brand new ones should be much less (not more)



Good points.

Thanks again. I'll let Google know they can stop developing Dart and everyone can stop with other languages.
Serge says so.

Re: A couple of brief comments... by Serge Bureau


RE: And with DSL capabilities in many languages, the need for brand new ones should be much less (not more)



Good points.

Thanks again. I'll let Google know they can stop developing Dart and everyone can stop with other languages.
Serge says so.


I thought I mentioned that I was in favor of choices if they bring something new ?

That does not mean no more languages ?

You do not answer our argue, just mock.

I am guilty often of it myself, but most people put messages but no justifications or explanations.
Many respectable people write here and I value their experience which is very often much more than mine.

But if I am wrong I want to see why, not just take any affirmation as cash.

I like debate, so that something come up from it. I an sorry you don't

Re: A couple of brief comments... by Richard Hightower


You do not answer or argue, just mock.



Yes. I know. You troll, and I mock your trolling.
Mostly due to apathy and disinterest. Also, I believe I have debated enough on this subject in the past. I'd rather see what other people have to say on the topic and learn. You seem apt to argue and make statements that are fairly over the top. It is not really that much fun to argue with you online. I ceed the victory to you and continue to do something else.... anything else.

Accept Scala for what it is good for, but don't proclaim it's perfect by Alex Blewitt

Scala has (had?) a lot of things to like about it. But just because it has a lot of things to like about doesn't mean it's perfect. Any system is going to have trade-offs which are required in order to move forwards.

One of those is the fact that Scala doesn't favour immutability, because the underlying Java runtime is mostly set up for read-write behaviour. That's OK - it's a trade-off for convenience with compatibility with other Java APIs. But it's not worth the level of ad hominem attacks or screams of FUD.

As long as you know what the limits of the system are, you can take a reasoned judgement call as to whether it's important for your use case. Other languages provide an immutable view; for example, 'true' functional languages like ML and declarative languages like Prolog are all about immutable data; and others, like Erlang, are set up to deal with process-based actor concurrency in an immutable fashion.

But it's also true that Scala has no interest in either backward compatibility across minor versions, and therefore of providing either a modular system or modularising the core libraries. Java made the mistake of not having a modular system when it was created - and we're now in the hell of trying to unpick the weird dependencies in the JDK which wouldn't have happened if it was properly modular in the first place.

In Java, for example, java.beans depends on java.applet and thus transitively on to java.awt. So if you want to implement PropertyChangeListener, you end up bringing in the AWT into your runtime even if it's a headless app. (This is also why some apps need to have -Dawt.headless=true, just to disable AWT if it's brought in accidentally).

The backwards compatibility is ultimately going to be Scala's downfall. Again, don't argue against the person, argue against the facts. Code compiled against Scala 2.8 isn't compatible with code compiled against Scala 2.9. Yes, so code compiled with Scala 2.9.0 is compatible with Scala 2.9.1 - but that should be a given, not something to proclaim about. What's worse, there is no public statement to give faith that Scala 2.10 (or 3.0, whatever it will be called) will address this issue in any significant or meaningful way.

This doesn't have an impact if you're just learning Scala, or even starting the first Scala project. You just pick the Latest and Greatest and start from there. It's only when Scala 2.9++ comes out that you have a choice of whether to move forwards or stay where you are; and if you stay, what the library support will be like going forward for older versions. (Having a build system which can cross-compile against different versions of Scala is a plaster that is treating the symptom rather than the underlying cause.)

Finally, if you are heading a Scala project and no-one else is currently using it in your world, it's easy to sell the benefits and treat backwards compatibility as a nice-to-have. If you're in control of your world, you can just recompile everything. But it's rare that you can upgrade two projects at the same time, or three, or four. If you're dealing with a large set of interoperable Scala libraries, the fact that you can't seamlessly move (binary) code from one version to another severely limits whether you can upgrade at all.

So Scala may be a fun language to learn, and it may be easy to demonstrate a shorter line-of-code count than other comparable languages. But it's telling that whilst there are a few high-profile cases where Scala has been adopted (Guardian, Twitter), there's virtually no success stories that say how easy it is to migrate from one version of Scala to another. That is the key takeaway of the article and links above; not that you shouldn't use it, but that you should be aware of these issues and determine whether they are relevant to you or not.

Re: Just sad by Bruce Fancher

Or instead of waiting ten years, you could just use Clojure . . . right now.

Java not "enterprise ready"? by Steven Shaw

Since Java still lacks modularity, are you saying that it (still) isn't enterprise ready?

Should we all be using C#/.NET because of the better modularity story?

Fix the JVM, copy C# by Yizhuo Wang

I wonder if anyone used C# (3.5 and later) with Linq. I was forced to use C# and was completely blown away by the language features. IMHO, C# is the static type programming language done right. Simple, clean and not too verbose.

Let me just list down some features amazed me, and I feel really can boost productivity
- type system actually working (without type erasure)
- type inference and var keyword
- functional nearly everyplace (thanks to Linq and extension method)
- #region and #endregion (this makes organize methods and fields so much easier)
- property (make getter and setter really transparent)
- delegate (no more anonymous inner class)


It is true that VS2010 is not as polished as Eclipse, in terms of refactoring support (even with ReSharper) and plugins. And the ecosystem of .net is no way near to the JVM world. However, as a language-to-language comparison, I will choose C# all the time, even though I have 4 years solid experience in Java and only 1 month experience in C#.

I know the root cause of Java's problem lies in JVM have no type information, and it is due to backward-compatibility to JVM 1.4 and prior version. But it is coming to 2012, and this needs to be fixed to keep Java a competitive language.

Re: Fix the JVM, copy C# by Yizhuo Wang

BTW, I am not saying C# is as powerful as Scala. It cannot create a DSL or pattern matching as easy as in Scala, neither it can build an Actor framework. (base on my one-month experience of C#). But it just make my day-to-day programming more enjoyable (Linq is just addictive), and save people's time solving common problems.

A fair comparison will be Java vs C#, and Scala vs F#. And Scala is too complicated to become a common programming language IMHO, but C# is just right for most common programmers.

Re: Fix the JVM, copy C# by Steve McJones

C# is actually magnitudes more complex than Scala.

- If and how much types Scala erases depends on the backend. Being a good citizen, it erases more types when targeting the JVM and less types when targeting the CLR. Still, Scala's erased Generics are a considerable improvement over Java's erased Generics.

- Scala provides much better type inference then C#. Additionally it doesn't punish the use of immutable references (val vs. var).

- Functional paradigms were considered from the start and not as late add-on features like in C#.

- Sounds more like a IDE feature ...

- Where C# provides fields, getters/setters and properties, Scala provides one uniform way which doesn't break compatibility like in C# when moving from fields to properties.

- Once again, where C# provides multiple and sometimes incompatible ways of doing things (Action vs. Func, delegates vs. Lambdas, ...) and even more syntactical alternatives Scala provides one uniform way.

That's why even some C# devs like Scala as some sort of cleaned-up C#.

Scala can provide Linq-like syntax (and better functionality) without all the special exceptions the developers of C# invented for themselves.
Scala's “Linq for strict and lazy sequential collections” since 2.8, “Linq for parallel collections” since 2.9, “Linq for GPUs” is a third-party plugin and “Linq for databases” is currently in work.

Re: Fix the JVM, copy C# by Alex Blewitt

There's a few things in the JVM that can't be fixed easily, such as non-erased generic types. If that weren't the case, then they would have been added at the time or shortly afterwards. In addition, the CLR has a much better story when it comes to object interoperability (which they needed to support the other use cases of C#) whereas the JVM mostly has focussed on just Java in the past.

However, the invokedynamic keyword, available now in JDK 7, isn't really of significant benefit to Java (since it doesn't call it). However, code which has been compiled with other compilers that can take advantage of invokedynamic (such as JRuby) have seen significant performance gains. Furthermore, the upcoming lambda spec (see www.infoq.com/news/2011/12/state-lambda) introduces a means to refer to methods as first-order elements in a Java source file, with a corresponding MethodHandle that may be used under the covers. This too can help other non-Java languages for quicker invocation and better JIT code.

With regards the Lambda piece, this will bring lambdas to a much wider audience than Scala has - if only because of Java's existing place (e.g. #1 TIOBE language for the last decade). Scala still has more things on top of it (case classes, general DSL) but we'll start to see the basics of FP including type inference in the Java layer in JDK8. And then who knows, the foundations are laid for other things to be built, like LINQ.

Re: Java not enterprise ready by Alex Blewitt

Actually, Java has a pretty good modularity story, even if it could be better. You only have to look at Maven central to see how it has grown (also known as 'the internet') - each one of those JARs is a module with well defined dependencies (albeit external, in the associated POM) and versions. Maven can even support version ranges, though you don't see it that often. And almost every JAR in Maven central follows the semantic versioning guidelines which Scala wilfully ignores.

All of this is possible because by and large, Java is backwards compatible with previous releases. This enables bundles written long ago (e.g. log4j) to still be used on today's JVMs. OK, so there are better implementations than log4j but the point is it will still work if you are stuck with a codebase that depends on it and don't have the engineering resources to recompile from scratch every time.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

50 comments

Educational Content

General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy