Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 231 posts at DZone. You can read more from them at their website. View Full User Profile

Java, Scala, complexity and aardvarks

  • submit to reddit

This week saw another flame war from some of the Scala crowd. This time, it was toward Stephen Colebourne, the man behind Joda time.

The article in question can be found here, and Stephen’s answer here.

To be frank, I tend to agree to Stephen’s predicat but for very different reasons. Now, if you’re a Scala user, there are basically 2 options:

  • either you react like some did before, telling me I’m too stupid or too lazy to really learn the language and stop reading at this point. In this case, I’m afraid there’s nothing I can say apart from ‘Please, don’t harm me’ because it has a feeling of religion war coming from supposedly scientific-minded people.
  • Or you can read on and we’ll debate like educated people.

Truth is, I’m interested in Scala. I try to program in Scala for personal projects. So far, I’ve gotten the hold on traits (what I would do to have them in Java) and closures and I’ve understood some of the generics concepts (so long as it’s not too complex). I plan on diving in the Collections API to better use closures next.

I think that Scala, like EJB2, was designed by smart, even brilliant people, but with a different experience than mine.

In real life, projects are full of developpers of heterogeneous levels: good developers, average developers and bad developers. And please don’t blame it on the HR department, the CEO or the global strategy of the company: it’s just Gaussian distribution, just like in any population.

In effect, that makes Scala a no-go in most contexts. Take Java as an example. What did it make it so successful, even with all its lackings? The compile-once, run-everywhere motto? Perhaps, but IMHO, the first and foremost reason behind Java success is the change of responsibility in memory management, from developers (like in C/C++) to system administrators. Before, the worse the developer, the higher the probability of a bug in memory management but Java changed all this: it’s not perfect, but much simpler.

Like Freddy Mallet, I’m sure a technology has to be simple to become mainstream and Scala has not taken this road. As a consequence, it’s fated to stay in a niche market… Stating this should raise no reactions from anybody, it’s just a fact.

Note: aardvarks will be a point for a future blog post.



Published at DZone with permission of Nicolas Frankel, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Thomas Eichberger replied on Tue, 2011/12/06 - 2:04am

I totally agree with this article :-)

Jesper Nordenberg replied on Tue, 2011/12/06 - 4:00am

You and the Java enterprise world seem to live in the illusion that bad developers can write good code. Just because a developer can use a programming language doesn't mean that the code produced is useful. Java is good at hiding the real complexities of programming and introducing incidental ones.

Rob Dickens replied on Tue, 2011/12/06 - 4:13am

Writing tools/libraries/apis in Scala might well be the preserve of the top 20% of the distribution - those who understand nearly all of what's possible using Scala.

However, writing application code in Scala probably requires only 80% of that knowledge, which IMO is accessible to nearly all developers.

This is surely a win-win scenario: the tool-writers don't get frustrated, and the tool-users get better tools (such as the Scala collections library). 

Michael Duerig replied on Tue, 2011/12/06 - 4:15am in response to: Jesper Nordenberg

> Java is good at hiding the real complexities of programming and introducing incidental ones.

Wow, this pretty much sums it up...

Stephen Lindsey replied on Tue, 2011/12/06 - 7:24am

" Java is good at hiding the real complexities of programming "

 Surely this is a good thing, unless you're a technie snob, because we can concentrate on what most of us are paid to do - solve business problems. I started over 30 years ago with IBM 360 assembler so I'm pretty pleased that some of the "complexities" have gone. Java isn't perfect but having used it since '96 i find it quite productive.

 "and introducing incidental ones"

Sounds cute but what does this actually mean?



Francois Bertrand replied on Tue, 2011/12/06 - 8:13am

Just using only traits, closures and the cake and loan patterns, you can build enterprise application equivalent to "Java + EJB session bean" or "Java + a DI framework", but much easier.

Torsten Schmidt replied on Tue, 2011/12/06 - 8:15am

Scala has one great advantage. You can develope like a Java guy with a little knowledge of Scala, but you can improve your skills and writing more and more Scala-like code. It's not necessary to be one of the best developers, use only the things you want to understand. After switching to Scala it was always a pain for me to develop in pure Java again.

Dan Howard replied on Tue, 2011/12/06 - 9:06am

I agree mostly with this except that I would say that the primary reason for the success of Java is that is that it's read-friendly. This gives it the lowest TCO for long term maintenance over pretty much everything else out there.

 With Java I can get a new developer up and running in a few weeks - and they'd be productive within a couple of months. This is just not tenable with languages like Scala.

John J. Franey replied on Tue, 2011/12/06 - 9:56am

I came for the aardvarks and am fairly disappointed by the tease.

Jesper Nordenberg replied on Tue, 2011/12/06 - 11:19am in response to: Stephen Lindsey

@Stephen: With hiding the complexities I actually mean sweeping under the rug and pretend they don't exist, not that they are handled properly for you. For example, the let's ignores that this reference can be null and instead throw a NPE at runtime, let's ignore that arrays are actually invariant and instead throw a runtime exception when used incorrectly etc. With introducing incidental complexities I mean things like that's a PITA to declare a simple ADT, transform or filter a collection etc., i.e. basic tasks that are really simple but becomes unnecessary complex in Java.

Michael Duerig replied on Tue, 2011/12/06 - 11:36am in response to: Jesper Nordenberg

Also having to implement equals() manually in Java gives most developers more rope to hang themselves than they even realize...

Mateusz Dymczyk replied on Tue, 2011/12/06 - 12:39pm

"With Java I can get a new developer up and running in a few weeks - and they'd be productive within a couple of months. This is just not tenable with languages like Scala." Maybe because functional programming isn't that popular yet? I really find it hilarious when people say "we can find more Java devs than Scala ones" or "it's easier to train a guy in Java than Scala". Of course it is. Just like XX years ago it was easier to find an ASM dev than a C dev and then a C dev than a Java dev (I mean a real OO programmer, not some "I use Java syntax to write C/C++"). The thing is it is just a matter of time and not really an argument against the language. Scala has multiple problems (I've seen somewhere someone comparing it to Java when it was around 1.3 and I find it really accurate) but if they don't pull something ridiculous off then it should be fine. And the complexity? I think that universities just need to start learning functional programming along all the OO courses and that we will be fine.

Fabrizio Giudici replied on Tue, 2011/12/06 - 4:49pm

 First, I agree in general with the post.

@Michael Duerig. There's no need to write equals() manually. You can have it auto-generated by an IDE or just use the @EqualsAndHashCode annotation from Lombok. Perhaps when we compare something to Java we should target Java 6 at least, not Java from many years ago, right?

"and introducing incidental ones" Sounds cute but what does this actually mean?

Means nothing. Of course, it's true that there are lots of incidental complexities with Java. For instance, I've just seen a very curious performance bug that arose out from sorting a sublist. A contract was broken that the developer didn't know about. Contracts that you're unaware of, that's the most probable source of troubles due to incidental complexities. Now what's wrong in the quoted sentence is the false promise that with Scala there would not be incidental complexities. First, no language exists that brings zero incidental complexities. Of course, there could be more or less. C++ brought more incidental complexities because it was a richer language than Java. Scala is the same. The more powerful the language, the more incidental complexities. I can't find the reference now, but a criticism that arose from inside the Scala community (one of the developers if I'm not wrong) is that "every features is strictly related to each other" - and figure out how many incidental complexities may arise out of there.




Fabrizio Giudici replied on Tue, 2011/12/06 - 4:58pm in response to: Fabrizio Giudici


@Mateusz Interesting point about functional programming not being popular yet. But in your opinion, what could make FP popular? FP is a programming paradigm supported/favoured by some languages. What usually happens is not that a programming paradimg makes languages popular, it's rather the opposite. It wasn't OOP to push Pascal and C++: rather Pascal and C++ pushed OOP. Thus, I wouldn't expect that FP pushes Scala. Scala might eventually push FP, but it doesn't seem to be happening. On the other hand, there could be other ways to push FP, for instance other languages or Java 8 enhancements (depending on the specific language support, we can have more sophisticated or lighter FP). In any case, if the latter thing happens, other languages or Java 8 will become popular. In the end, only Scala can push itself, don't expect external actors (*).

(*) With the exception of business ones. Let's all recall that Java has been pushed a lot by Sun, when it was healthy, and C# has been pushed a lot by Microsoft. ObjC is being pushed by Apple and JS by the companies behind HTML 5. Chances are that these are the only popular languages, or those increasing in popularity (with the exception of legacy such as C and C++). Personally, I think that after the '90s it's rather unlikely that a new language becomes popular without a strong business push. I don't see major corporates pushing Scala, so far. This could make a real difference.

Mateusz Dymczyk replied on Tue, 2011/12/06 - 5:39pm

1) I wouldn't really recommend generating equals() or hashCode() with an IDE (or at least not with Eclipse, don't know how good IntelliJ/Netbeans is). They way they handle it is rather bad and every Java programmer should know how to do it (but most don't).
2) on FP popularity: you have some valid points (with which I completely agree) and to be perfectly honest I have no idea how can Scala or FP become really popular. I mean a huge company backing it up would obviously help but I don't see it coming any time soon. MS implemented some FP concepts into C# and they have F# but I don't see them promoting the latter too hard. Oracle is working on FP features for Java 8 but it will take years before people in the enterprise will start using it (hell my comapny is still stuck partially in 1.5...). And even if they were to speed things up those are only OO languages with some FP added where on the other hand Scala is more of a hybrid. I guess it is all up to mr. Odersky to make this thing popular and listen to the community in order to improve the language. Persoanally I wouldn't want to use Scala at work yet as it has too many problems (from the language itself to the tooling) but I find it very promising after those "few hours" I spent playing with it and I do not really see any competition.
A completely different matter is whether it was a wise choice to implement it for the JVM which is very limited and probably makes it harder for the creators of the language. From what I know it was also designed for the C# VM but I know completely nothing about it so I can't really say would using it instead would help.

Jesper Nordenberg replied on Wed, 2011/12/07 - 3:50am in response to: Fabrizio Giudici

@Fabrizio: You're missing my point. I'm not talking about complexities in the language (you can create a very simple language, see for example Brainfuck, but that doesn't mean that programs written in the language will be simple), but rather incidental complexity introduced in the implementation of a solution to a given problem. A Scala solution will in general have much less incidental complexity than a Java solution, because the language allows you to create a more straightforward implementation.

John David replied on Wed, 2012/01/25 - 7:05pm

Java is a powerful programming language and has lot of features and support. Hidding or encapsulation is so nicely done by the Java and it helps in modularity and pure OOP.

I like Java programming language the most. Although I have worked with other languages as well but found Java the best of all.

new java

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.