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.

Can it work?

As I desperately typed away at the computer, a deadline hanging over my head, I witnessed a strange conversation.

"Choose five letters," my friend was saying. Repeatedly, in fact, as the other guy tried to make sense of this non-sequitur. Now, I can lay back and watch the world go by most of the time, but when I'm in frantic mode and someone is being, well, slow, I get this urge to either slap them senseless or just doing their job for them.

Fortunately for my friend's interlocutor I was typing, not talking on the phone. Unfortunately, for me, my own answer went unheeded. See, my friend was trying to make a point. When he wants to prove something to someone, he tries to engage them in the proof. I sometimes wonder if he realizes this go over the head of most people, who just nod and make sympathetic noises in the hope he will quickly finish his explanation and give the answer they are waiting for. People don't go to restaurants to receive fishing lessons, if you get my drift.

At any rate, this time my friend really made a point. Not the point he wanted to make, but a point nonetheless. That's because the other guy finally realized that, non-sequitur or not, he wasn't going to get his answer until he complied with the request. Thus, the following dialog ensued:

- Choose five letters.

- 1, 2, 3, 4, 5.

- Do you work at Brave Programmers(*)?

- Huh? Yes...

- So, now choose five numbers.

<...>

It's all the rage, these days, to outsource IT work. Well, it's been all the rage for quite a while, but I digress. On paper, it looks terrific. You get real IT experts to do the IT work, and just concentrate on your business. You set all kinds of benchmarks, contract penalties, service level agreements and such, to ensure you make a good deal.

In real life, though, you get someone who cannot choose five letters. It's not that this guy doesn't know what a letter is, of course. He just didn't care enough to pay attention to what was being discussed.

He didn't want to understand what my friend was explaining -- he isn't paid to understand anything -- he just wanted to do the minimum required to accomplish his job. If that meant wasting a whole week playing chinese whispers instead of solving the problem in one hour, so be it.

While I have seen exceptions to it, most outsourcing companies I have worked with do the minimum required by contract. Or, using an analogy, they deliver Notepad, not Word, and they do it charging as much for it as they possibly can.

So I really wonder if outsourcing can ever work. It does look good on paper.

(*) Not the real name, of course.