Scala and IntelliJ IDEA

I’ve played around with the latest Scala plugin for IntelliJ IDEA and I consider it alpha quality at best. It’s hard to get compilation going and it gets often confused with parsing (for very basic files, 10 lines of Scala with annotations for Jersey this time). It feels like Eclipse which will also present errors which are none (for Java!) and after inserting a blank line and saving again, the errors go away.

Scala is harder to parse (type inference, implicits, …) than Java, but this needs to get better to be usable. They hinted that it’s too far behind to get into 8.0, I hope not to far.

But kudos for supporting Groovy, JRuby and Scala and doing their best.

Update: I have the nagging thought in the back of my head and a eerie feeling in my stomach that IDEA can’t to better for Scala than for Groovy because of implicits etc. Hope I’m wrong :-)

Update 2: An update to the Scala plugin destroyed my IDE, it is no longer able to start. It says I should remove the plugin, but doesn’t tell me where it is.

“For” hack with Option monad in Java

There has been some discussion going on in the blogosphere about monads, and especially about the Haskell Maybe monad or the Scala option class. Those are ways to prevent problems with NULL and NPEs that Java lacks. Java returns NULL form many methods to indicate failure or no result. Suppose we have a method which returns a name:

The problem with this method is that we don’t know if it returns null. So the developers needs to deal with length == null, though the compiler doesn’t force the developer to deal with the returned NULL. A lazy developer then leads to null pointer exceptions. Other languages deal in different ways with this problem. Groovy has safe operators and Nice has option types.

Some posts like the one from James show how to use options in Java. All have the problem that you need to unwrap the value inside the option / maybe. Scala ans Haskell do that automatically for you, with the case classes in Scala for example.

But there is a construct with syntactic sugar in Java which unwraps the value from inside another class: the for loop from Java 1.5.

To make this work we need our option class to implement Iterable.

And the None and Some sub classes to return an empty iterator

or an iterator with one item.

Then voila Java does the unwrapping for us and instead of

we can write (sacrificing the else):

Thanks for listening.

Update: Completely ignoring the point of this post, Euxx posted a correction for the single element list creation I did.

Happens all the time in IT, people missing the point but nitpicking on something irrelevant. Other than that, if we start arguing performance, “The java.util.Collections class also have number of other utility methods that allow to shorten code like this and help to improve performance of your application.” I’d write (or reuse) a OneElementIterator something like this (could probably be optimized with some further thinking)

(Or again using google collections)

“I can’t not notice the ugly use of ArrayList to create collection with a single element, but what made matter worse, is that author suggested to use 3rd party library to replace those 3 lines of code.”

As far as I know, the JDK does not help you very much with Iterators or Iterables as third party libraries do. So, yes, I’d suggest using a third party library to implement an Iterator/Iterable for Option.

No future for functional programming in 2008 – Scala, F# and Nu

On Lambda the ultimte there is a recent post with a language prediction for 2008, which mainly predicts the rise of functional programming and the rise of Scala in particular: “My prediction is a little bit more conservative, but I predict Scala will gain momentum, and at least one high visibility project will use Scala”. Brandon chimes in with “The most important thing to emerge from the discussion is the larger role functional programming will play. It seems like a safe bet.” A safe bet, really? I more sceptical, as written in my post about Qi4j and Scala.

The blogosphere is full of functional programming language advocates and the coming rise of functional programming in application development. But has anything changed since Lisp was invented in 1958? Functional programming languages have existed for more than 50 years now, and didn’t make any inroads into application development. What happend to the acclaimed golden age of functional programing, about which Peter Christensen writes? Will it come back? I dispute in a comment to that post that there ever was a golden age of functional programming, it was a fringe language from the beginning. There was a golden age of Fortran.

John McCarthy – no not THAT McCarthy – invented Lisp back in 1958. From there functional programming gained much appeal to programmers because of it’s clean and consistent style. Everything in Lisp is a list. Even the program itself. Because good programmers have a feel for aesthetics in programming style, they have a warm feeling for Lisp. Functional programming is also a powerful tool for software development. And developers like power. As Paul Graham writes in “Revenge of the Nerds” about power in languages with the aim to praise Lisp:

As an illustration of what I mean about the relative power of programming languages, consider the following problem. We want to write a function that generates accumulators– a function that takes a number n, and returns a function that takes another number i and returns n incremented by i.

He cites an example in Lisp, that implements an accumulator in a nice and pure way:

Functional languages excel at mathematical and list processing problems. Most problems to solve in the enterprise are of a different type though. When moving to real problems then, functional programming languages get ugly as an ugly duck. With no swan in sight. Looking at examples from Implementing a blog in Common Lisp: Part 1, we see how ugly it can get. In Java land people a frustrated about XML, but see the brace chaos in Lisp, just to open a database:

And defining a blog domain object doesn’t look very readable either:

compared to a Groovy example:

or a Java one in Qi4j:

Another example from nu, the rising functional star for Macos X. This time with the famous Currency converter example which creates a window:

With an equivalent example in Groovy to build a Swing UI:

Mostly equivalent with the Groovy example which is still slightly easier to read and understand, even by someone who doesn’t know Groovy. Mainly because Groovy is more expressive and not everything has to be pressed into a list (though the nu example contains more than lists as nu aims for object orientation).

In a discussion about Arc, a functional language, stevecooperorg writes about Lisp and the use of Emacs/Slime:

I’d like to write the next Viaweb, and I’d like to write it in Lisp. But if the basic language is inviting, the rest of the environment is sorta hostile; a shangri-la in a swamp.

That’s another problem of most fringe languages. People – the enterprise? – need to know too much beside the language. Using a fringe editor which most people abandoned in the 80s and “a decent knowledge of system administration” is too high a barrier.

Power is a good thing it seems. From my experience most developers can’t handle power. They misuse it. If your development team is less than 5 developers the chance is high that all of them are alpha developers. And your interviewing process was rigorous of course. Above ten and the chances are high that there won’t be only alpha coders. Power is a dangerous feature of a language then.

Do powerful languages scale? Do dynamical type reference languages, which most functional languages are, scale? Scaling in time and organisation? Does it scale from 6 months to 10 years and does it scale from 2 people to 50? I have my doubts for years and still ask anyone to show me how those languages scale. I really want to know. Others too. Manageability writes about Python and Chandler:

What I find interesting is that Chandler started as a Python project with bold claims such as “Python programs are both concise and readable, this makes it excellent for rapid development by a distributed team” and “Chandler design goals: … design a platform that supports an extensible modular architecture”. I was hoping to see this project as a testament to Python’s viability to large scale development.

The jury is still out, but I wouldn’t bet on scalability. As a project manager during the 90s two of my projects didn’t scale and had to be rewritten, one in Python and one in Perl. But it could just be me.

What happend to Haskell and Erlang, the functional hypes of 2006 and 2007? The Blogosphere has mainly lost interest in those lately. Scala and F# seem to be en vogue in our days. Arc perhaps is next in line to be en vogue. Certainly after Scala, which is next the next thing after Java as Bruce Eckel claims. What has changed from the days of Lisp 50 years ago I asked. Scala and F# are different from Haskell, Erlang – and Lisp. They build on an a proven plattform, on libraries that people know. Scala mostly on the JDK and Java ecosphere, F# on the Microsoft universe and .NET. They both are the most promising functional candidates when it gets to momentum. The transit for C# and Java developers seems to be easiest compared to other languages. Will that be enough for them breaking through into the mainstream?

Will the release of Arc, written as a pet project by Paul Graham the greatest functional rock star, help with functional programming? No, certainly not. Arc lost it’s appeal even before it was released. While waiting for the Arc blessing, people moved on to Scala, Erlang or F#.

Don’t kid yourself. There will be no rise for application and especially enterprise development in functional programming (See what happens when you use a Perl script to do your billing, not that I haven’t screwed up in the past with Java ;-) Which doesn’t mean to stop using functional programming languages. It’s fun, keep going.

Thanks for listening.