Is Scala Really the Next C++?

5
May
2008

I’ve been turning that question over in my head for a few months now. It’s really a worthy thought. At face value, it’s incredibly derogatory and implicative of an over-bulked, poorly designed language. While I’m sure this is not how the concept was originally intended, it certainly comes across that way.

But the more I think about it, the more I realize that the parallels are uncanny. Consider the situation back in 1983, when C++ first got started. C had become the dominant language for serious developments. It was fast, commonly known and perhaps more importantly, structured. C had successfully applied the concepts shown in Pascal to systems programming, revolutionizing the industry and becoming the lingua franca of developers everywhere.

When C++ arrived, one of its main selling points was as a “better C”. It was possible to interoperate seamlessly between C++ and C, even to the point of compiling most C programs unmodified in C++. But despite its roots, it still managed to introduce a number of features drawn from Smalltalk et al. (such as classes and virtual member functions). It represented a paradigm shift in the way developers represented concepts. In fact, I think it’s safe to say that the popular object-oriented design principles that we all take for granted would never have evolved to this level without the introduction of C++. (yes, I’m aware of Objective-C and other such efforts, but C++ was the one which caught on)

So we’ve got a few catch-phrases here: “better C”, “seamless interop”, “backwards compatibility”, “paradigm shift”, etc. Sound familiar? (actually, it sounds a lot like Groovy) The truth is that Scala seems to occupy a very similar place in history (if six months ago can be considered “history”). Scala is almost an extension to Java. It brings to the language things like higher-order functions, type inference and a type system of frightening power. Scala represents a fundamental shift in the concepts and designs we use to model problems. I truly believe that whatever language we’re using in a decade’s time, it will borrow heavily from the concepts introduced in Scala (in the same way that Java borrowed from C++).

But if Scala and C++ are so similar in historical inception, shouldn’t we view the language with a certain amount of distrust? We all know what a mess C++ turned out to be, why should Scala be any different? I believe the answer has to do with Scala’s fundamental design principles. Specifically, Scala is not trying to be source-compatible with Java. You can’t just take Java sources and compile them with Scala.

This clean break with the progenitor language has a number of ramifications. Most importantly, Scala is able to smooth many of the rough edges in Java without breaking existing libraries. For example, Scala’s generics are far more consistent than Java’s, despite still being implemented using erasure. This snippet, for example, fails to compile:

def doSomething(ls:List) = {
  ...
}

All we have done is omit the generic type parameter. In Java, the equivalent would lead to a compiler warning at worst, because Java has to remain backwards compatible with code written before the introduction of generics. This “error vs warning” distinction seems a bit trivial at first, but the distinction has massive implications throughout the rest of the type system. Anyone who has ever tried to write a “generified” library in Java will know what I mean.

Scala represents a clean break from Java. This is in sharp contrast to C++, which was trying to remain fully backward compatible with C sources. This meant inheriting all of C’s weird wrinkles (pass-by-value, no forward referencing, etc). If C++ had just abandoned it’s C legacy, it would have been a much nicer language. Arguably, a language more like Java.

Perhaps the most important distinction between Scala and C++ is that Scala is being designed from the ground up with consistency in mind. All of the major problems in C++ can be traced back to inconsistencies in syntax, semantics or both. That’s not to say that the designers of C++ didn’t put a good deal of effort into keeping the language homogenous, but the truth is that they ultimately failed. Now we could argue until the cows come home about why they failed, but whatever the reasons, it’s done and it has given C++ a very bad reputation. Scala on the other hand is being built by a close-knit team of academics who have spent a lifetime thinking about how to properly design a language. I tend to think that they have a better chance of succeeding than the C++ folks did.

So the moral of this long and rambling post is that you shouldn’t be wary of the Scala language. It’s not going to become the next evil emperor of the language world. Far from it, Scala may just represent the next step forward into true programmatic enlightenment.

Filed in Scala | Comments (10)

The Plague of Polyglotism

28
Apr
2008

For those of you who don’t know, polyglotism is not some weird religion but actually a growing trend in the programming industry. In essence, it is the concept that one should not be confined to a single language for a given system or even a specific application. With polyglot programming, a single project could use dozens of different languages, each for a different task to which they are uniquely well-suited.

As a basic example, we could write a Wicket component which makes use of Ruby’s RedCloth library for working with Textile. Because of Scala’s flexible syntax, we can use it to perform the interop between Wicket and Ruby using an internal DSL:

class TextileLabel(id:String, model:IModel) extends WebComponent(id, model) with JRuby {
  require("textile_utils")
 
  override def onComponentTagBody(stream:MarkupStream, openTag:ComponentTag) {
    replaceComponentTagBody(markupStream, openTag, 
        'textilize(model.getObject().toString()))
  }
}

# textile_utils.rb
require 'redcloth'
 
def textilize(text)
  doc = RedCloth.new text
  doc.to_html
end

Warning: Untested code

We’re actually using three languages here, even though we only have source for two of them. The Wicket library itself is written in Java, our component is written in Scala and we work with the RedCloth library in Ruby. This is hardly the best example of polyglotism, but it suffices for a simple illustration. The general idea is that you would apply this concept to a more serious project and perform more significant tasks in each of the various languages.

The Bad News

This is all well and good, but there’s a glaring problem with this philosophy of design: not everyone knows every language. You may be a language aficionado, picking up everything from Scheme to Objective-C, but it’s only a very small percentage of developers who share that passion. Many projects are composed of developers without extensive knowledge of diverse languages. In fact, even with a really good sampling of talent, it’s doubtful you’ll have more than one or two people fluent in more than two languages. And unfortunately, there’s this pesky concern we all love called “maintainability”.

Let’s pretend that Slava Pestov comes into your project as a consultant and decides that he’s going to apply the polyglot programming philosophy. He writes a good portion of your application in Java, Lisp and some language called Factor, pockets his consultant’s fee and then moves on. Now the code he wrote may have been phenomenally well-designed and really perfect for the task, but you’re going to have a very hard time finding a developer who can maintain it. Let’s say that six months down the road, you decide that your widget really needs a red push button, rather than a green radio selector. Either you need a developer who knows Factor (hint: there aren’t very many), or you need a developer who’s willing to learn it. The thing is that most developers with the knowledge and motivation to learn a language have either already done so, or are familiar enough with the base concepts as to be capable of jumping right in. These developers fall into that limited group of people fluent in many different languages, and as such are a rare find.

Now I’m not picking on Factor in any way, it’s a very interesting language, but it still isn’t very widespread in terms of developer expertise. That’s really what this all comes down to: developer expertise. Every time you make a language choice, you limit the pool of developers who are even capable of groking your code. If I decide to build an application in Java, even assuming that’s the only language I use, I have still eliminated maybe 20% of all developers from ever touching the project. If I make the decision to use Ruby for some parts of the application, while still using Java for the others, I’ve now factored that 80% down to maybe 35% (developers who know Java and Ruby). Once I throw in Scala, that cuts it down still further (maybe at 15% now). If I add a fourth language - for example, Haskell - I’ve now narrowed the field so far, that it’s doubtful I’ll find anyone capable of handling all aspects within a reasonable price range. It’s the same problem as with framework choice, except that frameworks are much easier to learn than languages.

The polyglot ideal was really devised by a bunch of nerdy folks like me. I love languages and would like nothing better than to get paid to learn half a dozen new ones (assuming I’m coming into a project with a strange combination I haven’t seen before). However, as I understand the industry, that’s not a common sentiment. So a very loud minority of developers (/me waves) has managed to forge a very hot methodology, one which excludes almost all of the hard-working developer community. If I didn’t know better, I would be tempted to say that it was a self-serving industry ploy to foster exclusivity in the job market.

I want to work on multi-language projects as much as anyone, but I really don’t think it’s the best thing right now. I’m working on a project now which has an aspect for which Scala would be absolutely perfect, but since I’m the only developer on hand who is remotely familiar with the language, I’m probably going to end up recommending against its adoption. Consider carefully the ramifications of trying new languages on your own projects, you may not be doing future developers any favors by going down that path.

Filed in Java | Comments (10)

Universal Type Inference is a Bad Thing

9
Apr
2008

Recently, Scala has been wowing developers with its concise syntax and powerful capabilities, but perhaps its most impressive feature is local type inference. When the intended type for an element is obvious, the Scala compiler is able to make the inference and there is no need for any additional type annotations.

While this is extremely useful, it falls quite a bit short of the type inference mechanisms available in other languages such as Haskell and ML. Many people have pointed out that Scala doesn’t go as far as it could in its inference, forcing the use of type annotations when the type could easily be inferred by the compiler. To understand this claim, it’s necessary to consider an example from a language which does have such universal type inference. Consider the following function:

fun sum nil init = init 
 | sum (hd::tail) init = hd + (sum tail init)

For those of you not familiar with ML or its derivatives, this is a simple curried function which traverses a given list, adding the values together with an initial value given by init. Obviously, it’s a contrived example since we could easily accomplish the above using a fold, but bear with me.

The function has the following type signature: int list -> int -> int. That is to say, the ML compiler is able to infer the only possible type which satisfies this function. At no point do we actually annotate any specific nominal type. Clarity aside, this seems like a pretty nifty language feature. The ML compiler actually considers the whole function when inferring type, so its inferences can be that much more comprehensive. Scala of course has type inference, but far less universal. Consider the equivalent function to the above:

def sum(list:List[Int])(init:Int):Int = list match {
    case hd::tail => hd + sum(tail)(init)
    case Nil => init
  }

Obviously, this is a lot more verbose than the ML example. Scala’s type inference mechanism is local only, which means that it considers the inference on an expression-by-expression basis. Thus, the compiler has no way of inferring the type of the list parameter since it doesn’t consider the full context of the method. Note that the compiler really couldn’t say much about this method even if it did have universal type inference because (unlike ML) Scala allows overloaded methods and operators.

Because of the relative verbosity of the Scala example when compared to ML, it’s tempting to claim that ML’s type inference is superior. But while ML’s type inference may be more powerful than Scala’s, I think it is simultaneously more dangerous and less useful. Let’s assume that I was trying to write the sum function from above, but I accidentally swapped the + operator for a :: on the second line:

fun sum nil init = init 
 | sum (hd::tail) init = hd :: (sum tail init)

The ML compiler is perfectly happy with this function. Such a small distinction between the two, but in the case of the second (incorrect) function, the type signature will be inferred as the following: 'a list -> 'a list -> 'a list (the 'a notation is equivalent to the mathematical ). We’ve gone from a curried function taking an int list and an int returning an int value to a function taking two list values with arbitrary element types and returning a new list with the same type; and all we did was change two characters.

By contrast, the same mistake in Scala will lead to a compiler error:

def sum(list:List[Int])(init:Int):Int = list match {
    case hd::tail => hd :: sum(tail)(init)    // error
    case Nil => init
  }

The error given will be due to the fact that the right-associative cons operator (::) is not defined for type Int. In short, the compiler has figured out that we screwed up somewhere and throws an error. This is very important, especially for more complicated functions. I can’t tell you how many times I’ve sat and stared at a relatively short function in ML for literally hours before figuring out that the problem was in a simple typo, confusing the type inference. Of course, ML does allow type annotations just like Scala, but it’s considered to be better practice to just allow the compiler to infer things for itself.

ML’s type inference ensures consistency, while Scala’s type inference ensures correctness. Obviously, “correctness” is a word which gets bandied about with horrific flippancy, but I think in this case it’s merited. The only thing that the ML type inference will guarantee is that all of your types match. It will look through your function and ensure that everything is internally consistent. Since both the correct and incorrect versions of our sum function are consistent, ML is fine with the result. Scala on the other hand is more restrictive, which leads to better assurance at compile-time that what you just did was the “right thing”. I would argue that it’s part of the responsibility of the type checker to catch typos such as the one in the example, but languages with universal type inference just can’t do this.

Type inference can be an incredibly nice feature, and it is very tempting to just assume that “more is better” and jump whole-heartedly into languages like ML. The problem is languages which have such universal type inference don’t provide the same safety that languages with local or no type inference can provide. It’s just too easy to make a mistake and then not realize it until the compiler throws some (apparently) unrelated error in a completely different section of the code. In some sense, type inference weakens the type system by no longer providing the same assurance about a block of code. It’s important to realize where to draw the line as a language designer; to realize how far is too far, and when to step back.

Filed in Scala | Comments (9)

Groovy’s Performance is Not Subjective

31
Mar
2008

Ah, the saga of misinterpreted micro-benchmarks! Developers advocating one technology over another have long used micro-benchmarks and trivial examples to illustrate their point. This is most often seen in the area of language implementation, where performance is a critical (and often emotional) consideration. The Computer Language Benchmarks Game is a good example of this.

With the rise of the JVM as a platform for language development, we’ve been seeing a lot of benchmarks directly comparing some of these languages with each other and with Java itself. Actually, it seems that the popular trio (as far as benchmarking goes) are Scala, JRuby and Groovy. It’s been a bit of a favorite past-time of the blogosphere to create benchmarks for these languages and then spin up controversial posts about the results. Back in September, Darek Young wrote a post illustrating a ray tracer benchmark which really caught my eye:

Results
ray.java
12.89s
ray.scala
11.224s
ray.groovy
2h 31m 42s
I was expecting the Groovy code to run longer than the Scala code but was shocked at the actual difference. All three versions of the code produce identical images: (fullsize here)

Wow! I’ve seen these results dozens of times (looking back at the post), but they never cease to startle me. How could Groovy be that much slower than everything else? Granted it is very much a dynamic language, compared to Java and Scala which are peers in static-land. But still, this is a ray tracer we’re talking about! There’s no meta-programming involved to muddle the scene, so a halfway-decent optimizer should be able to at least squeeze that gradient down to maybe 5x as slow, rather than a factor of 830.

If this were an isolated incident, I would probably just blow it off as bad benchmarking, or perhaps an odd corner case that trips badness in the Groovy runtime. Then a week later, I read this post by Pete Knego:

Test Groovy Java Java vs Groovy (times faster)

Simple counter 8.450 150 56x

Binary tree building 19.500 2.580 7.6x

Binary tree traversing 2.530 76 33x

Prime numbers 43.270 1.170 37x

All [non-decimal] times are in milliseconds.
Well, this is really disappointing. I expected Groovy to be slower but not by that much. In order to understand where does such a performance hit come from we have to peek under the hood. The culprit of all this is of course Groovy’s dynamic nature, implemented as MOP. MOP is a way for Groovy to know which class elements (fields/properties, methods, interfaces, superclasses, etc..) are defined on an object and to have a way to alter that data or invoke it. The core of MOP are two methods defined on GroovyObject: get/setProperty() and invokeMethod(). This methods are called every time you access a field or call a method on a Groovy object and quite a lot of work is done behind the scenes. The internals of the MOP are listed in MetaClass interface and implemented in six different classes.

All of this is old news, so the question is: Why am I bringing this up now? Well, I recently saw a post on Groovy Zone by none-other-than Rick Ross, talking about this very subject. Rick’s post was in response to two posts (here and here), discussing ways to improve Groovy code performance by obfuscating code. Final result?

This text is being written as I was changing and trying things, I gained 20s from
minor changes of which I lost track. I am currently at 1m30s (down from the
original 4m and comparing with Java’s 4s).

I’m sorry, this is acceptable performance? This is someone who’s spent time trying to optimize Groovy, and by his own admission, Groovy is 23x slower than the equivalent Java code. Certainly this is a far cry from the 830x slower in the ray tracer benchmark, but in this case it’s simple string manipulation, rather than a mathematically intensive test.

Coming back to Rick’s entry, he looks at the conclusion and has this to say about it:

Language performance is highly overrated
Much is often made of the theoretical “performance” of a language based on benchmarks and arcane tests. There have even been cases where vendors have built cheats into their products specifically so they would score well on benchmarks. In the end, runtime execution speed is not as important a factor as a lot of people would think it is if they only read about performance comparisons. Other factors such as maintainability, interoperability, developer productivity and tool and library support are all very significant, too.

Wait a minute, that sounds a lot like something else I’ve read recently! Maybe something like this:

Is picking out the few performance weaknesses the right way to judge the
overall speed of Groovy?

To me the Groovy performance is absolutely sufficient because of the
easy integration with Java. If something’s too slow, I do it in Java.
And Java compared to Python is in most cases much faster.

I appreciate the efforts of the Groovy team to improve the performance,
but if they wouldn’t, this would be no real problem to me. Groovy is the
grooviest language with a development team always having the simplicity
and elegance of the language usage in mind - and that counts to me.

This is almost a mantra for the Groovy proponents: performance is irrelevant. What’s worse, is that the few times where they’ve been pinned down on a particular performance issue that’s obviously a problem, the response seems to be along the lines of: this test doesn’t really show anything, since micro-benchmarks are useless.

I’m sorry, but that’s a cop-out. Face up to it, Groovy’s performance is terrible. Anyone who claims otherwise is simply not looking at the evidence. Oh, and if you’re going to claim that this is just a function of shoe-horning a dynamic language onto the JVM, check out a direct comparison between JRuby and and Groovy. Groovy comes out ahead in only four of the tests.

What really bothers me about the Groovy performance debates is that most “Groovyists” seem to believe that performance is in the eye of the beholder. The thought is that it’s all just a subjective issue and so should be discounted almost completely from the language selection process. People who say this have obviously forgotten what it means to try to write a scalable non-trivial application which performs decently under load. When you start getting hundreds of thousands of hits an hour, you’ll be willing to sell your soul for every last millisecond.

The fact is that this is simply not the case. Performance is important and it must be considered when choosing a language for your next project. Now I’m not implying that it should be the sole consideration, after all, we don’t use Assembly much anymore. But we can’t just discard performance altogether as a means of evaluation. Developer productivity is important, but it means nothing if the end result doesn’t meet basic responsiveness standards.

It’s like the first time I tried Mingle (which is written using JRuby BTW) back when it was still in pre-beta. The application was amazing, but it took literally minutes to render the most basic of pages. The problem was closely related to the state of the JRuby interpreter at the time and its poor memory management with respect to Rails. In the end, the application was completely unusable. ThoughtWorks had produced an amazing piece of software in a remarkably short time span, but the cost was the use of a language and framework which (at the time) led to unredeemable performance. They spared the developers at the expense of the end-users.

Both Mingle and JRuby have come a long way since those first tests. Charles and the gang have put an intense amount of effort into optimizing the JRuby runtime and JIT compiler. They’ve gone from an implementation which was 5-10x slower than MRI 1.8.6 to a fully compatible implementation that is usually faster than the original. Obviously performance is achievable in a dynamic language on the JVM, so why is Groovy still so horrible?

The only answer I can think of is that the Groovy core team just doesn’t value performance. Why else would they consistently bury their heads in the sand, ignoring the issues even when the evidence is right in front of them? It’s as if they have repeated their own “performance is irrelevant” mantra so many times that they are actually starting to believe it. It’s unfortunate, because Groovy really is an interesting effort. I may not see any value for my needs, but I can understand how a lot of people would. It fills a nice syntactic niche that other languages (such as Ruby) just miss. But all of its benefits are for naught if it can’t deliver when it counts.

Filed in Java | Comments (41)

Interface "Wow" Factor

7
Mar
2008

I’ve been using Firefox 3.0 since b1 on my main development machine under Windows Vista and to be honest, I’ve been floored by all of the improvements the Firefox team has managed to squeeze into this release. For starters, performance is improved easily 10 fold over 2.0, especially when dealing with scads of tabs. That alone makes the upgrade worthwhile in my book.

Even beyond that though, the entire application just has a more polished “feel” about it. Beta 3 saw the introduction of an improved theme on all platforms. This new theme was most noticeable on Mac, where it made Firefox suddenly jump from a MacPorts-style outsider to running right alongside the “iApps” in terms of style. The improvement on Vista was a little more subtle, but none-the-less impressive:

It looks a little weird when you first examine it, but after using this UI for a while I’ve come to really appreciate it’s simple devotion to usability patterns. I’ve followed with passing interest the Firefox development cycle since v0.5, so I knew that they were spending a lot of time polishing the UI. I was actually one of those aware of new “keyhole” look long before beta1, so when it arrived I was somewhat non-plussed. Oh it’s certainly slick and a vastly more usable (and more attractive) UI than it’s super-power competitor, IE7. But let’s face it, slick only gets you so far these days. Windows Vista has about the slickest look of any operating system, and just look at how much people malign it.

Returning to Firefox though, I’ve been extremely happy with how well “put together” the whole app seems. It’s really become a coherant power application with a flair for the indulgent user. It’s come a long way since those early releases on Windows. I didn’t realize just how far it had come though until I installed 3.0b3 on my Ubuntu Linux virtual machine (click for larger shot).

My first reaction was, “Impressive, they finally managed to make it look like a real Gnome2 application.” Then I looked down.

I nearly wept when I saw these controls. GTK Linux has been without a browser which could do this literally since the beginning of time. I was certainly aware that the team was working on this, but I had no idea that it had been activated in 3.0. Native controls in HTML are incredibly important to the user perception of how well the browser integrates with the platform.

That’s what it really all comes down to: user perception. Jeff Atwood harps on about this constantly, but just because it’s oft-repeated doesn’t make it less true. It doesn’t matter what your application can do, just what your users think it can do. It’s all an elaborate illusion anyway, we just have to realize how complete that illusion really is. If a user looks at your application and thinks, “Wow! I don’t know what it is, but it looks powerful,” then you have succeeded as a developer. Your application could do nothing more than print “Hello, World!” an infinite number of times; so long as it is impressive looking, it will be a success (think iPhoto 1.0). Likewise, your application may desalinate water and hold the key to world peace, but if it looks wimpy, users will never give it a chance.

Now by “impressive looking” I certainly don’t mean just flashy. Anyone can Photoshop a fancy interface with lickable buttons and endlessly translucent animations, but that doesn’t mean the interface will “feel powerful”. The really important test is in those critical first seconds as the user makes his first few clicks through the application. The user needs to instantly understand the core functionality of the application and why it is better than the competition. Their eyes need to be draw to the critical areas and they need to be comfortable resting there for long periods at a time. They should feel an immediate sense of cooperation and team-spirit in the application. Things should progress as quickly as they can think (but no faster) and transition smoothly from state A to state B. Oh, and the application should look good.

Firefox on Gnome2 isn’t particularly flashy; it isn’t very lickable, and there’s no translucency. It does make a statement however, one which is immediate and unmistakably readable by the user: I can do whatever you need me to, and you’re going to like the way I do it.

Wow.

Filed in Linux | Comments (2)