Scala for Java Developers

A few weeks ago I was asked to review a book called "Scala for Java Developers". Being preparing some Scala lessons to share at work it made lots of sense to agree. Finding a good way to introduce Java and .NET developers to Scala is hard. If someone is interested in learning a new language it's easy, just give them the Programming in Scala book. The challenge I'm up against is making a case for actually spending time learning it at all. What caught my eye a few years ago was all the expressiveness and succinctness I could achieve by making the leap. My expectations were to find a book that explained how to translate all the Java knowledge into Scala while learning the interesting new features one could discover making such a transition. The books was not exactly what I expected but that is not a bad thing.

The first chapter introduces the reader to the Activator and drops them into the REPL. It shows good examples of how easy it is to declare classes, play around with collections and express basic stuff. That is what I expected to find but then it picks up speed. It continues on the next chapter by creating a Java web service and exemplifying how to migrate it to Scala piece by piece. Then it goes on to IDEs, SBT, mentions many useful SBT plugins, worksheets and even a writing a REST client. Followed by a tour of all the testing frameworks available on Scala land. Moving to Play Framework and then some debugging.

Halfway through the book most of what regular developer faces on a day to day basis has been touched upon. Scala syntax is explained almost by accident, just as a necessity to show what can be done. It doesn't teach the language but rather provides examples of interesting and most likely new and simpler ways to do stuff a Java developer is used to. The rest of the book continues on at full speed with databases, webservices, xml, json, CRUDs and concurrency. I was surprised it even tackles Iteratees to illustrate reactive web applications like chat rooms. It even mentions Scala.js!

Overall it shows many libraries and tools used in the Scala ecosystem. It takes on many of the common problems most people are trying to solve at work. I think it can appeal to Spring, JavaEE or Rails users and similar. It provides a bird's eye view of the frameworks available while forcing the reader to actually try stuff out immediately in the REPL. Readers will get a feeling for what Scala enables and will surely go out looking for more.

My conclusion is if you are already into Scala and learning on your own or with other books then it is not for you. I recommend the book as a teaser for programmers who don't know Scala at all or barely and want to discover what it is about skipping to the fun part. Also, for someone like me who is trying to get other people interested it provides many ideas and examples that are simple to setup and play with. Having more Scala resources is good and this book fills a spot that needed to be filled.

Automatic resources processing with caching in SBT

I just wrote an article on my game development blog titled Automatic texture packaging with Libgdx's TexturePacker. It talks about an SBT plugin I just published that does some automatic process and packaging of resources during the 'package' task.

I took advantage of SBT’s built in cache system. It’s possible to associate a task with a bunch of input files and cache the modification date. Same applies to the output files. That way the task only runs if something changed, otherwise it just does a no-op. This is extremely important when that task might take a long time.

I'm sure some people will find the source code useful to do something of their own and improve their sbt-fu. You can check it out here.

Please let me know what you think!

Abstractions in Scala

There is an ongoing discussion regarding abstraction in programming. Some people say "Always abstract it" and other people argument that you have to start doing something at some point, you can't keep thinking in the clouds, you must get something done. There is a very long thread in the Scala mailing list so I won't enter into details here.

I understand the pragmatism, i.e. "get it done" which is fair enough given we don't have unlimited time to ponder on the abstract and mathematics. The thing is most people are missing a really important detail: someone else has already done the abstractions for us!!!

By intuition an abstraction groups some stuff and generalizes it, the higher you go the less useful abstractions you are able to find, it's like a pyramid. An useful abstraction doesn't come up every week, the more abstractions we have, the harder it gets to create new ones and go up the pyramid one more step. All we have to do is learn the current known pyramid, *we* don't have to live and work on the abstract (unless we want to write scientific papers).

In the land of Scala we have Scalaz. At first it's daunting, the main problem is that even if you can look through the code there is so much stuff that you simply don't get the point of it or don't even know how you would use it. It's actually not hard to understand, honestly, you just have to learn the purpose behind the stuff in there.

From the point of view of a complete newbie in this high level stuff I found these the most useful, compact and simple resources on the matter:

Nick Partridge at the Melbourne Scala User Group: http://vimeo.com/10482466

In there we are shown in real time how to go from a method summing the elements of a List[Int] into folding any Monoid without using Scalaz and coding it on the fly and thus learning the thinking behind this library.

And finally, the holy grail, the Typeclassopedia, I don't know why people don't throw it to you on the face every time you ask about Monads, Arrows and other Typeclasses and get it done with. There you will understand the purpose of all the typeclasses in Scalaz. (Don't mind the Haskell, text is clear enough to get you going even if you don't fully understand the code)

After the minor effort of working through these you will begin to *see* abstractions, you don't have to abstract stuff away, you will only have to use the new tools you have which are already coded in Scalaz. You will not waste time, you will save time. And most importantly even if you don't use Scalaz you should start thinking different about code and will just get better at it.

Bottom line, you don't have to think how to make stuff more abstract, you just have to know that the stuff you are doing already has an abstraction done for you.

I'm too young

I learned the bases of programming at the age of 9 with a private (particular?) teacher who taught me with QBASIC. A few years later at the age of 14 I started learning ActionScript on my own after discovering that you could code in Flash, I didn't even know what an array was and I was really happy when I understood it just by reading code examples, I later bought a book by Colin Mock and understood OOP. At 16 I met a Software Engineer and he told I should learn Java so I went to a library, got a Java book, photocopied it (don't tell anyone!) and returned it. I began studying with a friend and over time we got really good. He got a job as a Java programmer and soon I was working there too both at the age of 19. I did mostly C work but still it was cool.

Two years ago I was at a point where I thought I was such good programmer and specially a Java programmer in particular. The thing was, after 5 years of learning Java, starting in 1.4 and seeing it through the Java 5 leap and 6 afterwards I pretty much knew whole standard library, some frameworks and the tools Netbeans and Eclipse. Having read a lot of Java books, knowing low level stuff, threads, watching the occasional advanced videos of talks online. Life was good. I knew there were a lot of people better than myself but I still thought I was doing good for my age at that time (21).

Until one day I bumped into a Scala presentation by Martin Odersky... (I can't seem to find it again)

It showed some neat stuff and the massive code reduction for some tasks, it also was totally inter operable with Java so it was a win-win situation. From then onwards I started learning Scala and as soon as the "official" book came out I bought it and I read it from cover to back in 4 afternoons after work, no kidding.

From then onwards my reality changed. I discovered I knew nothing at all, seriously. My whole world expanded enormously, I have been in a learning rampage ever since. Functional Programming, Actors, Monads, Continuations, Higher Kinds, etc. I even recently started learning Haskell and I'm planning on eventually going to Lisp.

I'm now willing to tackle more complex problems and really trying understanding all those concepts, my programming has changed a lot and not only because of using Scala, I ended up doing some trait like pattern with Templates in C++ code at work to solve multiple inheritance issues and making a really cool API.


As of today at the age of 23 I have not even finished the first year at University because working 40 hours a week doesn't leave much time to study so I'm not a Software Engineer (yet). Even still I love Scala and the complexity it forces me to face everyday that keeps pushing me to learn. I have matured so much in the last couple of years and I plan on doing so for a long time.

What's your excuse for not learning and dealing with new complex stuff?

Scala Considered Harmful For Large Projects? ... Not

I open this blog following a controversial topic :).

Scala is Bad:

I recently found this blog Scala considered harmful for large projects? please check it out. Now back to me. Now back to comments section in that blog. Now back to me.

After reading the post you might get an uneasy feeling that it might be right and Scala is not so cool and blah blah blah and then when reading the comment's you can see everyone offering a quite different point of view that the whole post falls apart.

Another similar interesting read is The next big JVM language.

And yet another misleading post Scala is not a better java.

It has some jewels like:

He says:

1. "Java is culturally opposed to these ideas: it is deliberately simple."
2. "This definition of a good programming practice is one that Scala vehemently opposes." followed by contradictory "Java was supposed to start small and grow"
3. "Java is proud of removing multiple inheritance. "
4. "If you're stuck with the JVM, I guess the question is: how much rope do you want to give your programmers? Scala is essentially the opposite answer to Java."

I say:

1. Java is not simple nowadays. People cried over generics and Collections aside it's still a pain to use them. Boxing - Unboxing. And several other problematic areas I don't care to list. Ok you don't trust me? Read "Effective Java" to really understand that there are tons of pitfalls and most likely we are guilty of several of those in our code we think is so good. Oh but wait, read "API Design" by Jaroslav Tulach en then you might also realize that designing software even in Java it's so god damn easy to get wrong. Then think about all those cool framework you probably use. Dependency Injection, Aspect Oriented Programming, external config XMLs and many other ways of making the code's context hard to understand.
2. Actually read the link. I dare you. My favorite lines that summarizes it perfectly "A true library does not change the rules of meaning for the language; it just adds new words." and "But the key point is that
   the new words defined by a library should look just like primitives of the language.". OMG it's exactly like Scala so Scala is actually what they tried to do back in 1998 according to this article.
3. Like every statement I found everywhere spelled like that I must say "Says who?" or like wikipedia "Need reference". Ok multiple inheritance is problematic if done wrong and that statement is probably true. But Scala doesn't have multiple inheritance. I don't see how Java is better than Scala in this aspect. Java avoided the problem altogether causing pain for the good developers, Scala solved it gracefully empowering even beginners with the inclusion of Traits.
4. "Stuck with the JVM" ok, deal-breaker, this guy hates Java and the JVM anyway I honestly don't trust his opinions regarding the JVM ecosystem.

Scala is Not Bad: 

A more reasonable explanation was written by Jim McBeath here Scala Pros and Cons check his "Other Posts" links too then please bookmark his blog and read it often.

Other good read is The Scala is too Complex Conspiracy but don't waste your time in the comments section (unless you Ctrl+F "Odersky" and read his comment, then close the window).

Scala is Good:  

An excellent read Scala == Effective Java ? clearly shows an example of how Scala is actually simpler than Java and removes a lot rope you could hang yourself with. The thing is we are so used to Java's problems that we think it's simple and deceive ourselves.

Another thing people tend to pick on are the operators. Java deliberately avoided operator overloading, it's a design choice. Scala solves it gracefully. It has just a simple rule, "a.method(b)" can also be written as "a method b", as an extra method's name can be made out of symbols like '+'. No surprises, everything is a method.

People tend to think operator overloading is a great chance to mess up your code because it's hard to tell what's happening. The imaginary problem is that a crazy programmers starts littering the code with unrecognizable operators making it hard to read. If I name a method that adds two number "fhwgads" it's pretty much same. If you can't trust in your team's ability to pick names you have bigger problems.

Then there is this whole thing about making a programming language so simple that nobody can get it wrong. But hey, we have reached a place where software is complex because it defines a complex reality, that's where languages are lacking. The problem is that complicated stuff becomes overly complicated to express. I can't understand why would anyone want a limited programming language nowadays, that is not where the world is going, check out the emerging languages in the last decade. No one wants or need a "stupid" language, there is a real need for an expressive language to help us convey a complex reality in elegant ways. Languages are converging to Lisp's features. The next main stream language is not one lacking the features every goddamn decent developer is craving for so stop looking for the "The Next Big Dumb JVM Language".

The thing is Scala IS simpler if used like Java. The novice programmer will find that simple tasks take less lines than Java and it's easier to not mess it up. They will also code algorithms imperatively and everything will work just as in Java. The only thing I'm sure they will miss are "continue" and "break" but are definitely going to love "match" vs the old "switch". Casting, if any is changed from "((Cast)variable)" to "variable.asInstanceOf[Cast]", albeit verbose it doesn't force you to add the almost always necessary enclosing parenthesis. You might also have to fix some number casting with a "num.toInt" or stuff like that.

Leaving "break" and "continue" aside all you Java code base can be translated to Scala without breaking a sweat.

Then as you get deeper into Scala you will discover the cool stuff that nobody forces you upon and you will like it. You will only have to work as a team to learn and improve. Read the Scala books. Talk about it, say "hey check out this cool way of doing x I discovered in Scala!" and that's it. All you need is a passionate team to go ahead and learn it together. As more people stop cowering behind their false sense of safety and leap in Scala the less we have to go around protecting the "dumb programmers", let's all break our ignorance and embrace self improvement, encourage it and even demand it.

Please check Odersky's opion on the different level programmers can have Scala levels: beginner to expert, application programmer to library designer and a great response to close this article of mine Critique of Odersky’s Scala levels.