Monday, April 20, 2009

What does a Scala program looks like?

I'm worried.

So, last Friday, as the daylight slowly disappeared, much in the same way and same rate as the people in the immense building that someone somehow thought was fit to be called a workplace -- and, worse yet, be used as such -- I was engaged in a deep conversation about miscellaneous subjects with a colleague. Or, as someone else might rudely put it, I was chit chatting.

At some point, the conversation turned to Java, Ruby on Rails, money, and, finally Scala. My colleague was ignorant of the ways of Rails, and I was telling him how mind blowing it was when it came to creating web sites. I mistakenly mentioned to him having seen a weblog being created in just 25 minutes on a screencast (it's actually 15 minutes -- first screencast here). I urged him to look it up.

Anyway, the conversation briefly turned into Java, and how it came to be because it was basically the only game in town for webapps at the beginning, and how, basically, everything was better than Java. But don't take this too literally -- I was chit chatting... Anyway, the conversation gave a final turn towards Scala at this point.

As my colleague was leaving, he asked me if Scala really was that good, whether it was compiled or interpreted, etc. I told him yes, it was that good, compiled, but with an "interpreter" available, that it produced JAR which could be decompiled by cavaj into readable Java, and then invited him into taking a look into a small program I have to check lottery results.

So, this is a small program I did mainly as a learning experiment. I have one written in Perl, which could have been easily ported to Scala, but I was interested into how a Scala programmer might have gone about it. My present solution is rather functional in style, though I'm considering a couple of case classes for it.

At any rate, I gave a brief overview on some concepts, such as val, def, extending Application, access to Java types and library, explained a few helping functions, and then got to the meat of the program, which I post below.


val prizes = lines.
dropWhile(!_.startsWith("1 ")). // Remove header
map(_.stripLineEnd.split(" ")). // Tokenize line
takeWhile(s => isInt(s(0))). // Remove trailer
map(s => readGame(s)). // Turn list into tuple
map(s => (s, ticketPrizes(s._3, tickets))). // Compute winning tickets
filter(s => s._2.size > 0) // Remove losing games

There's actually a lot of stuff going on there, but the point of that code was figuring out what an elegant Scala program might look like. Now, it does take advantage of some of Scala's power, but there's a lot it doesn't take advantage of. In particular, it doesn't take advantage of anything in Scala's type system or class system.

With that in mind, I started to tell my colleague this was written in a functional style, but you can have OO style as well. Before I finished, though, he inquired about Scala's usual style. Which, finally, led to my present worry.

I do not claim to have seen tons of Scala code, but I have been reading pretty much any blog posting about Scala and I haven't seen any common style.

Now, when Java came to be, some effort went into defining the style a proper Java program ought to be written in. I do claim to have seen a lot of Java code, both ugly and elegant, and all of it looked the same. Whenever a beginner broke with Java style, it came across in stark contrast -- and was a sign of programmer's inexperience.

Now, as for Scala, there's really very little emphasis on style being done. In fact, Scala's emphasis on not dictating how to solve a problem seems to be spilling into not dictating a coding style. And, as all of this went through my head in the space of a few seconds (I hope!), I realized something about Java's emphasis on style. It was comforting.

Let's put that thought on hold for a second, while I digress a bit. I have been programming for 26 years now. I started with BASIC, did some assembler (Z-80 mostly, but also 8080 and 6502), then learned Forth, because a FIG member, and then... C, Logo, MUMPS, LISP, APL, and anything I could put my hands on. I don't recall what languages I have once learned, but every now and then someone will mention an obscure language, such as Oberon, and I'll remember having learned it.

Forth, in particular, is a language whose main intent seems to be modifying the language. Something I did with much gusto. So it's not like I'm a conservative guy when it comes to languages.

Now, back to the comfort of Java's uniform style, the thing is... it's easier on my mind that every piece of Java code I lay my eyes on follows it. And, as I realized that, I was sure as hell that was also the case for the huge mass of average programmers that abound in the Enterprise world. The uniform style makes the code look professional, no matter how messy it actually is.

And, then, back to Scala, I answered my friend: "Scala doesn't have a style right now. It might develop one." Well, actually, it has dozens of style, but you get my drift.

And this, my friends, worries me. I can't see Scala going mainstream if a consistent style doesn't start showing up. Right now, everyone seems to be playing with it, figuring out what works and what doesn't. Scala is so powerful that people are actively trying to push the envelope, to test its limits in concision and expressiveness. It might take a while for its best practices to develop.

Hopefully, it won't be too late.



1 comment:

  1. I am mainly an OCaml programmer and this "no standard style" pattern seems familiar to me.

    It's both a relief (not always the same bureaucratic code) and a plea. The worst side of it is fellow programmers telling your style is "hideous" because theirs is (possibly radically) different.

    This is not related to functional programming but rather to the multiparadigm approach. If you are an Haskell programmer then there is a "right way" of doing things. In Haskell what may vary is the abstraction level, yet the basic syntax flow seems rather consistent. With OCaml there are several ways of doing things plus an unrestricted freedom to mix the styles.

    About the convergence.
    Will some superior style finally emerge ?
    Definitely not. Never ever.
    Scala and OCaml are about types, variety of styles comes from the richness of the type system.
    Thus there is no superior styles because there is no inferior type.
    The more consistent Haskell style comes from harsh decisions (POO is bad, mutability is evil,...) that Scala programmers will never even consider.
    You have just to live with that plurality.
    Unfortunately i agree it basically means Scala will never conquer industry, because the more you learn and experiment the less other competent programmers can understand your code at first sight. No matter how legible your code actually is, it seems obsfucated because it uses code patterns that are unknown to them.
    That is a no-no for the software industry because most of the employers want you to be easily removable. They want any beginner to say "i can grasp this code" and let him live on and ruin the quality asset you have patiently build. Or at least they want you to believe they could do it.
    Functional programming is quite different: if you touch a masterpiece code without knowing then you have to survive a massive attack of hard to decypher typing errors and the developpement is like frozen forever. Employers simply don't want good code that defend itself against the unattentive coders. Employers don't want you to code, they want you to type, and Java is excellent at that.

    ReplyDelete