April 22, 2009
I’ve been toying with Scala for some months now, one thing I’ve struggled with coming from Java are constructors in Scala. They are comparable to Java, but the syntax is different.
To help get you going faster in Scala, the top 5 things to know about constructors. Here we go:
- How to do constructors with a parameter
public class Foo() {
public Bar bar;
public Foo(Bar bar) {
this.bar = bar;
}
}
Looks in Scala like this:
class Foo(val bar:Bar)
In this case val creates an immutable final public field, using var would create a mutable public field.
- How to have private fields
public class Foo() {
private final Bar bar;
public Foo(Bar bar) {
this.bar = bar;
}
}
Looks in Scala like this:
class Foo(private val bar: Bar)
Update: Changed due to comments. Thanks for the commentors to point this out
Private fields are not as necessary as in Java, you can have public fields for attributes and change them to a method (def) later - without changing your clients.
- How to use super() ?
public class Foo() extends SuperFoo {
public Foo(Bar bar) {
super(bar);
}
}
Looks in Scala like this:
class Foo(bar:Bar) extends SuperFoo(bar)
- How to have more than one constructor?
public class Foo {
public Bar bar;
public Foo() {
this(new Bar());
}
public Foo(Bar bar) {
this. bar = bar;
}
}
Looks in Scala like this:
class Foo(val bar:Bar) {
def this() = this(new Bar)
}
Secondary constructors like this() need to delegate to another constructor to work (Thanks @Synesso).
- How to get bean style setters and getters?
public class Foo() {
private Bar bar;
public Foo(Bar bar) {
this.bar = bar;
}
public Bar getBar() {
return bar;
}
public void setBar(Bar bar) {
this.bar = bar;
}
}
Looks in Scala like this:
class Foo(@BeanProperty var bar:Bar)
The attribute bar will still be public, which is not a big issue (see above) in Scala. But @BeanProperty helps when working with Java libraries and you need Bean conventions for the libraries to work.
To add getBar and setBar but not a public field you need to:
class Foo(aBar:Bar) {
@BeanProperty
private var bar = aBar
}
Update: Changed to var, thanks to @eivindw.
Hope this helps you, if you have something to add, leave a comment. Should you struggle with the limited this() syntax (only one expression), then perhaps your constructors are doing too much. Consider the factory or better builder pattern instead.
Additional tip: use @Serializable to make your Scala classes serializable.
Nice coding in #Scala.
February 4, 2009
Uploaded a presentation on “Better Null Handling Strategies for Java” to SlideShare. Enjoy.
January 23, 2009
Many people object to ScrumMaster certifications:
- It’s a money making machine
- Scrum Masters do not learn anything during classes
- The certification is nothing worth - because nothing is certified
I have been a Certified ScrumMaster (CSM) and a Scrum practioner for some years. People who object to the certification do see it from the wrong angle. You need to understand Zen to understand the goodness in CSMs.
photo credit: darkpatator
Certification is a Zen joke, because the role of a ScrumMaster cannot be certified. It’s not about knowing some technical questions. What should a trainer certify in such a class? That you can lead an agile Scrum team as a ScrumMaster? No one can certify the fact that you’re a leader, catalyst and enabler. You either are or you aren’t. Zen masters (ha, another master without a master!) would laugh at the fun in the ScrumMaster certification. They laugh about the idea of certifying enlightenment.
Scrum without ScrumMasters
As another parallel, both in Scrum and in Zen, masters are only enablers. They are not needed after the act of enabling Zen/Scrum. My Scrum trainer told me, the goal of a ScrumMaster is to make himself obsolete. There is a Zen koan which goes like this:
If you meet the Buddha, kill him.
— Linji
If you see a ScrumMaster, kill him. Zen tells you:
If you are thinking about Buddha, this is thinking and delusion, not awakening. One must destroy preconceptions of the Buddha. Zen master Shunryu Suzuki wrote in Zen Mind, Beginner’s Mind during an introduction to Zazen, “Kill the Buddha if the Buddha exists somewhere else. Kill the Buddha, because you should resume your own Buddha nature.”
If you think the ScrumMaster is Scrum, you’re delusioning yourself. In Scrum the product owner and the scrum team can, and should from my view, act by themselves, without the need of a ScrumMaster. The ScrumMaster helps them achieve their Scrum. Helps them overcoming initial obstacles in their productivity.
Kick your ScrumMaster
If the ScrumMaster is not good enough for them, certification and coaching inside the company hasn’t helped, the Scrum team has always the right to kick their SM if he isn’t good enough for them. And they should do so. If in Zen a master isn’t good, pupils will just leave him. This might lead to problems within the organization, especially if the ScrumMaster is their boss, but that should be the problem of the organization, not a team problem.
Practitioner certification
There are many more certifications from the Scrum alliance. If you dig deeper, the real fun part is that CSM doesn’t mean anything, practitioner means much more:
The practitioner level of certification (CSP) is only offered to those CSMs who have hands-on experience using Scrum. Applicants must complete an extensive questionnaire with probing questions that focus on applicants’ real-world experience using Scrum on software development projects. Their application is reviewed for answers demonstrating competence and comprehension of principles that can only result from hands-on work. The applicant may be questioned to determine eligibility. To maintain CSP status, you must submit a new application every two years.
Is the certification any use?
Yes. The Certified Scrum Master training has several merits:
- Calling the Scrum training “Certified” guaranties the quality of the trainer
- It motivates the Scrum master to think in Scrum
- If managers take part, it helps the organisation adopt a “we can do it” view about Scrum
- Certification (CSM) seems to be one of the main reasons for Scrum success in the enterprise. The certification makes Scrum compatible for managment.
The view about acceptance is shared by Peter Stevens:
It is also about branding, and has been quite successful. The acceptance of the CSM program is high (especially from corporate customers, and this is where the money is). I believe the CSM program is an important reason why Scrum is better accepted than say, XP, in corporate management circles.
Scrum is successful. I’ve seen it help development departments gain productivity. If you do not scrum yet, go for it.
November 27, 2008
I wish Scala would have native support for types. Currently in Scala you need to write classOf[Person] for the Java Person.class expression.
It would be nice to have something easier than the noisy classOf e.g. when using Google Guice. Because using Guice with Scala looks ugly. I know I could do DI without Guice/Spring in Scala, but for varios reasons I don’t want to follow Jonas approach for now.
I think Groovy can just use Person for referencing types, but something like #Person would be ok too.
November 23, 2008
In January this year I’ve written about the future of functional programming in 2008, specifically about Scala and F#. Now that the end of the year nears, I’m going to look at my predictions and see how I fare.
In 2007 lots of people claimed that this year would be the year of functional programming languages. One quote I used in my post was from the website lambda the ultimate:
“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”.
I was more than sceptical
A safe bet, really? [...] Don’t kid yourself. There will be no rise for application and especially enterprise development in functional programming.
mostly because I’ve seen the shift for languages taking a very long time. It took decades for people to move from C-style procedural code to object orientation. And though functional languages have been around forever, they haven’t started their ascend into the mainstream yet. But there was also a curious and hopeful tone in my post nevertheless:
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.
After nearly 12 months have passed, now let’s see what 2008 brought us concerning functional programming, especially Scala - as I specifically mentioned Scala in my post and because I know most about Scala from the bunch of functional languages.
A lot has happend to Scala in 2008 for sure. Even CIO.com mentions Scala in a Scripting Language comparison:
Scala is particularly attractive to Java developers.
(not sure why they call Scala a scripting language ;-)
Some real examples have shown up. Those include the real world Scala examples by Jonas Boner and Twitter. This matches with the “a high visibility project will use Scala” prediction. Some droped Scala in their development though. What hasn’t happen in 2008 is that greater numbers of developers moved from Java to Scala or bigger numbers of developers moved to Scala from other languages. As The Disco Blog writes in a comparison between Scala and Clojure:
What remains to be seen is if they can compellingly convince the Java market to learn their way of programming rather than leveraging what’s home (i.e. the Java language) for the majority of their respective target audiences.
Books
Often books are cited as one indicator for momentum in programming languages, which sometimes is problematic as I’ve written before. Scala has been quite successful 2008 with books. There are three, one released and two announced for 2009:
Growing pains - syntax debates
Guido van Rossum, the Python inventor, had some troubling words to say about Scala:
Perhaps my biggest disappointment in Scala is that they have so many rules to make it possible to write code that looks straightforward, while being anything but — these rules all seem to have innumerable exceptions, making it hard to know when writing simple code will work and when not.
Following one debate about Guidos post on the Scala debate list, there are many counter points raised. Sadly the bigger number of commentators want the language to stay the way it is. It seems only David R. MacIver wants to change the language to make it easier. I strongly agree with him and Guido that there are parts which are inconsistent, which need to be changed to get Scala into the mainstream.
What bothers me personally with Scala? It’s not that well integrated with Java as it could be. In my post on Clojure vs Scala I mentioned that already:
But the idea of Clojure - tight integration with Java through Iterable and Iterator, implementing Java interfaces, but keeping immutable structures, compared to Scala which creates it’s own incompatible versions, should prove much more successful. I like that definitely way better, Scala should adopt that approach.
And they should drop .NET support. It looks like nobody uses it and it hampers Java integration. Drop it.
But Guidos post has some hope in it too. Alex Paynes comment to Guidos post says:
I’m seeing more and more programmers getting real work with Scala, not musing about its theoretical possibilities. I find that pragmatism encouraging.
Competitors
The success of functional programming - in this case Scala - depends on competitors. How did they do in 2008?
I see two competitors to Scala. They mainly arise from the notion of Scala as a Java successor - which is the main market for Scala I think. Not much people will come from the dynamic language camp (some who might be fed up with large Rails code bases), not much from functional programming. Most are current or former Java developers.
The first competitor is Clojure. Why? It has a big momentum and a lot of buzz. Rich Hickey seems to be an approachable, knowledgable guy who can give good speeches. He does a lot of things right. But Clojure is mainly a Lisp style language. And lots of people don’t like S-Expressions because they find them unreadable in quantities. It’s also not focusing on OO style development, when most people today agree that OO is a good way to model business problems. Scala will win over Clojure I guess.
The second, and more important competitor, is Groovy. It’s been in this space for quite some time, but with the recent aquisition of G2One by SpringSource I guess it will make a big jump into the enterprise. SpringSource has a lot of good speakers at conferences who are also quite good sales people. Groovy had some problems, but mostly adapted, made it’s syntax easier, added powerful features and got faster. The Groovy vs. Scala debate might be more about dynamic vs. static typing (see last comments by Paul and James) and might be decided by the type issue.
All in all the competitors seem to have done better in 2008, with Clojure getting momentum and mentioned pratically everywhere and Groovy with the G2One takeover.
Killer applications
There is still no killer application in 2008 for Scala. Ruby took a decade to get momentum. There was some momentum when I developed in Ruby at the end of the 90s (mostly by Java people who were agile and fed up with Java), but this momentum got Ruby nowhere. Rails as a killer application for Ruby let the number of Ruby developers explode. In a way that today Rails and Ruby are synonymous, very few people use Ruby without Rails.
What could a killer application for Scala look like? A Rails clone? David Pollaks Lift didn’t make it. Perhaps it’s actors or a application server build on actors (comet friendly, scalable) is the killer application for Scala. Other ideas? Mainly the lack of such an application explains the slow growth of Scala in 2008.
Conclusion
And in the end? I’m more optimistic about functional programming than at the beginning of 2008, although the TIOBE index for 2008 doesn’t look that promising for functional languages.
Object-Oriented Languages 57.9% +1.6%
Functional Languages 2.6% +0.4%
I mostly think now OO and Functional Programming will work together in the future to write good software, and OO languages will borrow more things from functional languages. I’ll write a deeper post about how OO and Functional Programming fit together for sure.
This was a post mostly about the future and state of Scala. Wasn’t it supposed to be about functional programming? Following blogs and debates it seemed to me that other functional languages didn’t move in 2008. Erlang had some hype during the summer, which ebbed too soon. Haskell didn’t move, it’s still the promising functional language it had been for years. F# did move, but beside the promises by Microsoft I didn’t see any breaktthroughs in 2008 (perhaps I haven’t looked in the right places).
Thanks for listening. As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled).
Update: See the impressive comment by Don Stewart about the growth in Haskell this year. Looks like real momentum, contrary to my (obviously wrong) perception ” Haskell didn’t move, it’s still the promising functional language it had been for years.”
Update 2: Good points made in comments: IDE support got much better 2008 in Eclipse, Netbeans, Intellij. Bad points: High profile googlers seem not to like Scala.
November 20, 2008
Looked at the current November 2008 TIOBE programming language index, found via Cedrics Twitter. Java still on top, very slow slide, Ruby down by 2 places, no longer under the Top 10, C++, C# and especially Python up, PHP still 5th, Erlang at 31st, Scala at 43rd ;-) F# not listed in Top 100.
Other interesting tidbits:
“The object-oriented paradigm is at an all time high with 57.9%. The popularity of dynamically typed languages seems to be stabilizing.”
Object-Oriented Languages 57.9% +1.6%
Functional Languages 2.6% +0.4%
Statically Typed Languages 60.0% +1.2%
Dynamically Typed Languages 40.0% -1.2%
(after some big increases for dynamically typed languages since 2002)
October 19, 2008
According to this blog post:
“In the recent event Google Developers Day, Bangalore, the Keynote speaker Prasad Ram said that Google Appengine will now support Java. [...] “Java”, said the other speaker, “was chosen based on the community feedback.”
Splendid! I hope this includes Scala somehow. This would at last be an easy way to deploy Java web applications, one thing up to now only PHP could claim (and to a lesser amount Ruby and Python).
October 12, 2008
Tim Dysinger wrote some time ago about his unpleasant experiences in a Scala chat channel. My experiences with the Scala community has been nicer. There sometimes is a little bit of FP zealotry but mostly people are willing to help. Perhaps it was his attitude towards the language with “the syntax is verbose, ugly and robotic.” when entering the chat which lead to his unpleasant welcome. Perhaps it was something else. The comments are closed on his post, so people couldn’t reply and the context is lost. I often write provoking things, at least I keep the comments open and get my share of ugly replies.
Being arrogant and insulting: “Notice that comments aren’t enabled, Scala nerds. Go comment somewhere else.”
I’m so very happy to not be part of the Ruby community. It was nice in 1998 and went downhill from there.
Update: Thanks to the comment, you do not need to google: Academics and Ergomaniacs
Update 2: No need to read the IRC log
(10:09:30 AM) DRMacIver: So, just for the record, I looked up the source code for Object.equals
(10:09:49 AM) DRMacIver: public boolean equals(Object obj) {
(10:09:49 AM) DRMacIver: return (this == obj);
[...]
(10:11:54 AM) dysinger: fuck you guys
[...]
(10:13:11 AM) dysinger: fuck you drmaciver - you and I have debated endlessly on other topics.
[...]
(10:14:37 AM) dysinger: eat a dick egomanics
[...]
(10:14:58 AM) dysinger left the room (Kicked by DRMacIver (I've already told you you're not my type.)).
To be honest I would have kicked him out after the first “fuck”.
And from the comments “dysinger said… So in the end it’s not about the code. We are all smart people [...]“.
Sorry. Nope.
“I shouldn’t have swore. That was bad on my part. [...] David MacIver can still bite my ass. [...] WTF?!”
Talk about idiocy.
After reading the IRC log: I’m so so very happy to not be part of the Ruby community.
PS: I’m sorry to use the word ghetto.
October 8, 2008
Scala has native support for xml in the language via scala.xml.Node
val message = <message>Hello world</message>
There is an excellent book called scala.xml on XML and Scala so this post won’t go into more detail.
Using the XML support in Scala makes it easy to write REST applications with Jersey. I’ve shown how to create JSON with a JsonBuilder in Scala before.
We need a Resource to handle our REST requests. As a response to a GET request on /helloWorld/xml we create a Scala XML node:
@Path("/helloWorld")
class HelloWorld {
@Path("/xml")
@GET
@Produces(Array("text/xml"))
def helloWorld() = {
Hello World
}
}
Jersey needs to know how to translate an object of scala.xml.Node to a HTTP response. This is usually done by implementing a MessageBodyWriter that maps an object and a mime type - scala.xml.Node and text/xml in this case - to a response.
@Provider
@Produces(Array("text/xml"))
class ScalaNodeAdapter extends MessageBodyWriter[scala.xml.Node] {
def isWriteable(dataType:java.lang.Class[_],
typ:Type,
annotations:Array[Annotation]) = {
classOf[scala.xml.Node].isAssignableFrom(dataType);
}
def writeTo(node:scala.xml.Node, writer:Writer) {
writer.write(node.toString)
}
def getSize(node:scala.xml.Node) = -1L
def writeTo(node:scala.xml.Node, aClass:java.lang.Class[_],
typ:Type,
annotations:Array[Annotation],
mediaType:MediaType,
stringObjectMultivaluedMap:MultivaluedMap[String,Object],
outputStream:OutputStream) {
val writer = new OutputStreamWriter(outputStream);
writeTo(node, writer)
writer.close()
}
}
Voila, we now get <message>Hello world</message> when calling /helloWorld/xml.
Thanks for listening.
There is a lot of holladi about DSLs (in Ruby and Scala and everywhere). The secret problem with DSLs that nobody talks about is easy to explain: Growing and designing a language has been shown to be hard. Most people who think they could solve a problem with a DSL are not good language designers => disaster.
(Following the blogosphere there are lots of proposed DSLs which are ugly, inconsistent, hard to read and not useful)
October 2, 2008
There are some discussions about Scala vs. Clojure - which one could replace Java on the VM.
I think the object oriented features of Scala make the language more usable for real world applications.
But the idea of Clojure - tight integration with Java through Iterable and Iterator, implementing Java interfaces, but keeping immutable structures, compared to Scala which creates it’s own incompatible versions, should prove much more successful. I like that definitely way better, Scala should adopt that approach. And of course implementing STM in Clojure is genius - lots of people talk about STM and it could be the next big thing for sharing state in distributed applications.
Thanks for listening.
Update: Sequences in Clojure http://blip.tv/file/734409
September 18, 2008
How to generate Json for REST? If you’re suspicious of automatic generation like me?* I’ve created a markup builder which can be used with Json and made a look into the future in my post “The best Markup Builder I could build in Java”:
“Closures in Java 7 will make it much easier to write a MarkupBuilder. The Action and Loop inner classes will go away and the code will be more Groovy like.”
* For a discussion on why you might not want to use JAXB and XStream see the comments on “REST: Lean JSON and XML from the same code”
Let’s have a look at this quote again. I didn’t use Groovy but with some interest in Scala - because it might be more maintainable than Java after 5-years project life time as it is more concise but not riddled with the Ruby-problems or unreadable for most as Haskell is - I looked at my JsonBuilder code and tried it with Scala.
I went back to the “Experiments to nicely generation JSON” post and did adapt it to Scala.
@Path("/hello")
class HelloWorldResource {
@GET
@ProduceMime(Array("text/html"))
def hello() = "Hello"
@Path("/world")
@GET
@ProduceMime(Array("text/html"))
def helloWorld = $(
$("id", 128),
$("name", "stephan"),
$("roles", roles.map(r => $("name", r.name))),
$("adress", $(
$("street", "mine!"),
$("city", "Berlin")
))
)
}
The generating code looks the same as in Java, with the possibility to include functions for generating nodes. My Java code did need anonymous inner classes to achieve the same - with more noise and less power. The methods are shorter and the focus lies more on generating the JSON data, not the method boilerplate code. Next will be WebBeans or Guice integration.
Ive struggled with some Scala constructs, the JsonAdapter which implements MessageBodyWriter was a little hard to write, especially:
def writeTo(node:Node, aClass:java.lang.Class[_],
typ:Type,
annotations:Array[Annotation],
mediaType:MediaType,
stringObjectMultivaluedMap:MultivaluedMap[String,Object],
outputStream:OutputStream):Unit = {
val writer = new OutputStreamWriter(outputStream);
writeTo(node, writer)
writer.close()
}
[...]
def isWriteable(dataType:java.lang.Class[_], typ:Type, annotations:Array[Annotation]) = {
classOf[json.Node].isAssignableFrom(dataType);
}
But everything works now and I can move on to adapt and learn how to do it better in Scala.
The migration wasn’t that hard, some problems exists and my Scala code looks more like Java than Scala, but it’s a beginning. One of my fears is to translate between Seqs, Lists, Arrays and Java Lists and Iterators all the time when interfacing with Java libraries. Not sure yet how to fix that, perhaps with some wrappers. Scalaz might help too. We’ll see in my future adventures into Scala.
Thanks for listening.
September 17, 2008
Compared to my IntelliJ IDEA experience, Netbeans works much better with Scala (but worse with Maven). Netbeans does recognize correct code compared to IDEA - but recognizes illegal code as legal too. For example it doesn’t tell you if you implement all methods from an abstract class. And lots of other things are missing from what we are used to in Java. My guess Scala IDEs are 5 years behind Java. Hope they catch up soon.
September 15, 2008
As a small side note, I’ve got
import javax.ws.rs.{Path, GET, ProduceMime}
@Path("/hello")
class HelloResource {
@GET
@ProduceMime(Array("text/html"))
def hello() = "Hello World"
}
working with Maven2, Jetty and Jersey. Took some time but was interesting. Any ideas for Array("text/html") (Scala does’t support varags the same as Java does) Perhaps a clever implicit? Need to think more.
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.
August 6, 2008
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:
String name = getName("hello");
int length = name.length();
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.
Option[String] option = getName("hello");
for (String name: option) {
// do something with name
}
To make this work we need our option class to implement Iterable.
public abstract class Option[T] implements Iterable[T] {
}
And the None and Some sub classes to return an empty iterator
public abstract class None[T] extends Option[T] {
public Itertator[T] iterator() { return EMPTY_ITERATOR; }
}
or an iterator with one item.
public abstract class Some[T] extends Option[T] {
public Itertator[T] iterator() {
// or better use google-collections
List[T] list = new ArrayList[T]();
list.add(this.value);
return list.iterator();
}
Then voila Java does the unwrapping for us and instead of
Option[String] option = getName("hello");
if (option instance of Some) {
String name = ((Some) option).value();
} else { ... }
we can write (sacrificing the else):
for (String name: getName("hello")) {
// do something with name
}
Thanks for listening.
Update: Completely ignoring the point of this post, Euxx posted a correction for the single element list creation I did.
return Collections.singletonList(this.value).iterator();
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)
public class OneElementIterator[T] implements Iterator[T] {
private boolean done = false;
private T element;
public OneElementIterator(T element) {
this.element = element;
}
public boolean hasNext() {
return ! done;
}
public T next() {
done = true;
return element;
}
public void remove() {
// not supported, throw exception;
}
}
(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.
January 21, 2008
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:
(defun foo (n) (lambda (i) (incf n i)))
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:
; Open the store where our data is stored
(defvar *elephant-store*
(open-store '(:clsql (:sqlite3 "/tmp/blog.db"))))
And defining a blog domain object doesn’t look very readable either:
(defclass blog-post ()
((title :initarg :title
:accessor title)
(body :initarg :body
:accessor body)
(timestamp :initarg :timestamp
:accessor timestamp
:initform (get-universal-time)))
(:metaclass persistent-metaclass))
compared to a Groovy example:
@Entity
class BlogPost {
String title
String body
TimeStamp timeStamp = now
}
or a Java one in Qi4j:
public class BlogPost {
Property<String> title;
Property<String> body;
Property<TimeStamp> timeStamp = now();
}
Another example from nu, the rising functional star for Macos X. This time with the famous Currency converter example which creates a window:
(set @window ((NSWindow alloc)
initWithContentRect:'(125 513 383 175)
styleMask:(+ NSTitledWindowMask NSClosableWindowMask NSMiniaturizableWindowMask)
backing:NSBackingStoreBuffered
defer:0))
(@window setTitle:"Currency Converter")
With an equivalent example in Groovy to build a Swing UI:
def frame =
swing.frame(title:'Frame', size:[300,300]) {
borderLayout()
textlabel = label(text:"Clicked ${count} time(s).",
constraints: BorderLayout.NORTH)
button(text:'Click Me',
actionPerformed: {count++; textlabel.text = "Clicked ${count} time(s)."; println "clicked"},
constraints:BorderLayout.SOUTH)
}
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.
