Mario has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

Is Scala Complex? Yes ... and?

08.26.2010
| 9744 views |
  • submit to reddit

This article has been inspired by a thread that appeared on the Java Posse mailing list, that in turn was started as a comment to a blog post that tried to demonstrate how Scala could be less complex than Java.

In my opinion the provided example is too small and specific to be meaningful. It is not possible to generalize and infer a reliable comparison between two languages from such a trivial task, so it doesn't prove anything. At least as much as a Scala method declaration like:

def map[B, That](f: A => B)
(implicit bf: CanBuildFrom[Repr, B, That]): That

as discussed here, doesn't demonstrate that Scala is unbearably ununderstandable for mere mortals like us.

More generally, I think yes: Scala is more complex than Java. On the other side the same complexity is not vain since Scala derives its conciseness and power from it. I don't understand why people confuse conciseness with simplicity. Actually what is true is far more often the opposite: do more with less implies that the bigger thing you are doing in a lesser verbose way is achived with a more powerful and then more complex language.

To give an analogy, I remember one of the most difficult exam I did at university was theory of signals (I hope the translation of the exam's name from Italian is correct) and the book on which I studied hadn't more than 200 pages. In the same period my sister, who is a lawyer, was studying for an exam about ancient Roman right. She had 2 books with about 2000 pages each, but her exam went far more smoothly than mine. And I don't think (or I am too proud to admit :) ) that she is more intelligent than me. I hope it is clear what I mean to say.

So yes, Scala is less verbose and then more complex. And? Where is the problem with that? I am not scared of complexity and I think the biggest part of people doing our job aren't scared either. Actually I must admit I am fascinated by complexity, but of course I prefer when I can put my brain at work with a purpose. As with Scala: if I can trade simplicity with more power, less verbosity and in the end more productivity I am happy of that.

In the same mailing thread that I mentioned at the beginning of this article, Fabrizio Giudici pointed out that there are Java libraries like Lombok and lambdaj through which it is possible to make the Java code in the article that started this discussion almost as straightforward and concise as the Scala one. He underlined that a good Java developer should be aware of all the available tools and how to leverage them in order to make his job easier and more productive. I totally I agree with him, but unfortunately I cannot say the same when he said that the existence of these tools proves that Java has a "reasonable set of extension points to tailor it to people's needs". I don't know if that can be true for the wonderful project Lombok, but my personal experience as creator of lambdaj is not on the same page. I actually had to invent and implement literally tons of (sometimes awful) hacks and workarounds. And the final result of this effort is a library that works only on a (hopefully not small) subset of the cases I would had cover.

The current Java situation will probably get even worse with Java 7. I guess whoever is subscribed to the lambda-dev mailing list like me, or is following how the implementation of the new lambda expressions is coming along in some other ways, can easily understand, and possibly share, my fears. My personal opinion is that Java is going to become at least as complex as Scala but with only a small fraction of the Scala's expressiveness, power and conciseness. If that is true this is the worst scenario I can imagine: complexity + verbosity. This is the real unbearable complexity for me: the one that causes more problems than it solves.
Published at DZone with permission of its author, Mario Fusco.

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

Tags:

Comments

Andrew Spencer replied on Thu, 2010/08/26 - 2:46am

Good to see the issues discussed without obfuscation or exaggeration. I fear you are only too correct in the final paragraph.

Martin Wildam replied on Thu, 2010/08/26 - 3:20am

Finally someone sharing my opinion, which basically is, that new elements should be added to a programming language only very carefully.

I don't follow closures, lambda, lombok discussions or any of those - but if it is true, both languages might be too heavy to deal with for new programmers - I mean people really new to programming or doing programming only from time to time.

Most developers I see using Ruby, Python or even PHP have far less fundamental programming knowledge as every Java developer I met. Java should also be easy to use (and fortunately it is still easier than C++) but there seems to be a great barrier for new young programmers adopting Java.

Peter Veentjer replied on Thu, 2010/08/26 - 3:42am

Language complexity is only a small part of the big picture.

Increases language complexity (and therefor enhanced features) can reduce a lot of unwanted clutter. In Java you need to fiddle around with strategies even though you want to have a simple higher order function. So  even thoug the code itself is simpler, conceptually the Java code is more difficult to understand because the concepts are tucked away under clutter.

My problem with complexity in most cases is not on the language level, but on all kinds of application libraries, application servers, combination of technologies etc.

Personally I'm still focussing a lot on Java development because on the JVM Java is still best to get most out of the speed (at the cost of writting some 'strange' code and skipping certain constructs like a switch case on enums). And with Intel VTune you can even connection processor measurements to machine instructions, and machine instructions to the Java code. So you can see on instruction/statement/function level where expensive calls are done.  And in combination with some smart code generation (instead on heavy duty oo solutions) you can really push performance to the limit.

Java is the new c ;)

Peter Veentjer

Software Transactional Memory for Java

http://multiverse.codehaus.org

 

Fabrizio Giudici replied on Thu, 2010/08/26 - 4:50am

I actually had to invent and implement literally tons of (sometimes awful) hacks and workarounds.

This doesn't contradict my point: the burden of implementing lambdaj is up to you :-P the implementer, and doesn't necessarily reflect on me, the user. In fact, not only it's important to clearly distinguish powerfulness from complexity (and I totally agree with your example referring to signal processing, complexity is a matter of entropy), but also on the different perspectives of the provider of a tool/library/framework and its user. I've only looked at a few things about Lombok internals, and I don't know how hard is to develop it; I only know that, from the user's perspective, I just have to add some annotations with very simple and clear semantics.

This matters because we don't need millions of tool/library/frameworks developers, but a very smaller number (thousands), and the community is rich enough to provide them. On the contrary, for the success of a language/runtime/tool/library/ecosystem, they must make feel good millions of developers.

And the final result of this effort is a library that works only on a (hopefully not small) subset of the cases I would had cover.

This is a good objection to my statement, and clearly it's a matter of trade-offs and our personal mileages are different.

 

Flavio Baronti replied on Thu, 2010/08/26 - 5:22am

I am not scared of complexity and I think the biggest part of people doing our job aren't scared either.

I think you're being too optimistic here. This may be true in high-end environments, where you can find passionate and dedicated people. There are many programmers however who just don't do the effort to understand complex subjects, or even slightly out-of-ordinary subjects. In such situations, using advanced tools can quickly make a project completely unmaintainable, just because the programmers who are in charge of it are not willing to do the effort to understand complexity.

Fabrizio Giudici replied on Thu, 2010/08/26 - 5:56am in response to: Flavio Baronti

+1 to Fabio. I'd like to stress the "passion" thing: it's quite natural that in the blogosphere and at conferences passionate people gather together, giving the false impression that every developer in the world is passionate. The opposite is true!

Mario Fusco replied on Thu, 2010/08/26 - 6:01am

Martin Odersky just gave his opinion about the debate. His arguments look quite similar to mine, but he presented them in a less complex and verbose (and somewhat more enjoyable) way. Could you expect something less from the father of Scala? :)

Andrea Del Bene replied on Thu, 2010/08/26 - 7:20am in response to: Martin Wildam

+1 !

Andrew McVeigh replied on Thu, 2010/08/26 - 11:10am in response to: Mario Fusco

Martin Odersky just gave his opinion about the debate

martin's presentation is great - simple way to show simple versus complex ;-)

he also mentions Kojo, a scala-based programmer learning environment, a bit like logo.  it's awesome, check it out at: http://www.kogics.net/sf:kojo

 

 

Mario Fusco replied on Fri, 2010/08/27 - 2:45am

That's weird: I wrote a similar (pro Scala) article on TSS about one year ago and I received only tons of critics. At the moment I am seeing this article is getting 29 votes up and 0 down. Is something finally changing in developers feeling about Scala?

Byju Veedu replied on Fri, 2010/08/27 - 3:21am

  I assume the problem is most people from OO world are either new or not yet confortable with the idea of FP and they are getting scared seeing all these FP features in scala. Adding to this point many people picked up scala initially are very experienced programmers or academics and the examples they thrown in are filled with all these FP stuff .We really need simple tutorials and introductory sessions to start scala in step by step for poeple coming from java or other OO world.

Fabrizio Giudici replied on Fri, 2010/08/27 - 3:29am

I think that Odersky arguments are blatantly biased, as usual (*). Take the smartphone example. In the world the choice is not restricted to the two extrema, a morse equipment and a smartphone. There are many intermediate phones in the middle, such as those only with a set of fundamental set of features and a decluttered user interface.

Now, what's a phone for? To call people and speak. Compare two persons, one enjoying his smartphone and one enjoying his normal phone, and see them calling a friend. I don't see but marginal differences in how they place the call; after that, what matters is what they have to say to their friends (a metaphor for good architecture and design practices).

Of course, smart users will enjoy the many things that a smartphone offers. No doubt on that. But they are just a minority. Average users will instead be confused by the more complex user interface. My parents - and a lot of other people I know - find it very hard - if not impossible - to place a call with a smartphone.

Not to say that a big deal of people are buying a smartphone for fashion, and don't use but a fraction of the features it offers - a waste of complexity.

So, the smartphone example is perfect for my point: Scala is more powerful and fit for a minority of experienced programmers that can handle its complexity; Java is simpler, less powerful and fit for the average programmer.

(*) I find that one big issue with the Scala community is that - with exceptions of course - they present only biased discussions. While it's clear that everybody is biased, I think that it's smarter for one who want to push a new idea to play the devil's advocate and try to wear other people's clothes. Otherwise they won't gain any point - no big surprise Scala is still where it was years ago.

Clemens Eisserer replied on Fri, 2010/08/27 - 4:06am

I think java is at the point of becoming a typical legacy language, full of half-baked features that were added later to keep the language "hip" (and no, I don't think C# is any better in this regard). Please Oracle, leave Java alone.

Clemens Eisserer replied on Fri, 2010/08/27 - 4:09am

Fabrizio:Thats why everybody is free to choose the type of phone, that suits best his/her needs ;)

Mario Fusco replied on Fri, 2010/08/27 - 4:38am in response to: Fabrizio Giudici

Of course, smart users will enjoy the many things that a smartphone offers. No doubt on that. But they are just a minority. Average users will instead be confused by the more complex user interface. My parents - and a lot of other people I know - find it very hard - if not impossible - to place a call with a smartphone.

My dad is not able to use a smartphone either. But he retired almost ten years ago and I still keep his university thesis made of 2 boxes of Hollerith cards. Luckily the world goes forward and I am eager to learn new technologies at least until I will retire too.

Not to say that a big deal of people are buying a smartphone for fashion, and don't use but a fraction of the features it offers - a waste of complexity.

That's true. Sometimes I still discover new features of my smartphone as much as I discover new featuresof Scala. Of both things I use the features I like and forget the ones I don't find useful. I don't see anythinig wrong in that.

So, the smartphone example is perfect for my point: Scala is more powerful and fit for a minority of experienced programmers that can handle its complexity; Java is simpler, less powerful and fit for the average programmer.

This is the best adverising for Scala I can imagine. Like the biggest part of the developers, I am too proud to consider myself an average programmer. Let's spread the idea that Scala is for experienced (and then probably better payed and rewarded) programmers while Java is for average ones and you will see how many people will move from Java to Scala :-)

Giovanni Ruggiero replied on Fri, 2010/08/27 - 8:49am

 

So, the smartphone example is perfect for my point: Scala is more powerful and fit for a minority of experienced programmers that can handle its complexity; Java is simpler, less powerful and fit for the average programmer.

 On this point I agree with David Pollak, the author of Lift: a programmer needs to handle the complexity of Scala if he must write a framework o design an API, but if he is just a user of such artifacts, he gains a lot in power without much burden in complexity.

Just see the difference between the Lift source and the source of a web application using it.

Due to the fact that the majority of the average programmers are users, complexity will not be a big issue in his diffusion.

 Marketing will be the major one, not having any big industry behind.

 

 

Silvio Bierman replied on Fri, 2010/08/27 - 9:12am in response to: Mario Fusco

Hehe, that is just what I was thinking. Few programmers will admit that they are of average skills even if most of them are by definition.

I love Scala and will concur that AS A WHOLE it is a LOT more complex than Java. But that is totally irrelevant for beginning programmers since they never use a language as a whole, they are tought a small subset that suits the simple tasks they are assigned. This is how it should be and makes for a stupid reason for saying that a complete language has to be simple.

I was taught programming using Algol 68. This was at that time (~1985) one of the most complex languages in existence but we where taught a simple and usable subset of the language. Initially, no talk about ref types, procedures, unions, operator overloading and what else not the language was made of. Within a year we where using additional languages like Pascal, Modula2 and C and I never learned most of the rest of A68. Nonetheless it had been a very effective vehicle for learning programming.

The same is true for Scala. That Java-ish subset is MUCH easier and more consistent/orthogonal than Java itself. During time I have taught many people C, later C++ and not too long ago Java. I am certain they could have picked up that part of Scala just as easily. The fun thing about Scala is that there is plenty of additional stuff left to learn afterwards that is worth the effort.

Fabrizio Giudici replied on Fri, 2010/08/27 - 2:20pm in response to: Silvio Bierman

Guys, you really don't know the world if you think that "few programmers will admit that they are of average skills", thinking that this could be a positive challenge for them. Being average means also that you don't have to be in charge of too much responsibility, and that's what most people want. Sad, but true.

Ronald Miura replied on Fri, 2010/08/27 - 4:16pm

Let's spread the idea that Scala is for experienced (and then probably better payed and rewarded) programmers while Java is for average ones and you will see how many people will move from Java to Scala :-)
Many proud, experienced programmers will use it for their toy projects, and say out loud in their blogs and tweets how much they enjoy it. And they will still choose Java for their real-world projects, because they want their fellow average programmers to be able to code as well, even if it isn't that fun. :P

Gar Labs replied on Tue, 2011/08/23 - 11:40am in response to: Mario Fusco

So you think Scala isn't for average developers and only smart ones are learning it? -GAR Labs

Comment viewing options

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