Learning Scala: Performance Impact of Implicit Conversions

Scala’s implicit conversions are a great tool for enhancing classes coming from libraries that you can’t just change yourself. I went into details on how it works a few weeks ago. With implicit conversions it can be made to appear that methods you have written exist as part of some objects that actually remain unchanged. You usually do this by creating (1) a wrapper class that takes the original object as it’s single parameter and (2) an implicit function that converts the original to the wrapped type by instantiating and returning the wrapper. If such an implicit is in a given scope, then in that scope the wrapper type’s methods can be called as if they were part of the wrapped class. For example, see the code below (note: the syntax highlighting is not perfect because it’s using Java rules — if anyone knows an easy way to add Scala highlighting support to a wordpress.com blog, please let me know in the comments):

case class ImmutableRichLong(x: Long) {
  // returns the predecessor of the wrapped object
  def pred = x - 1
}

implicit def long2immutableRichLong(x: Long) = ImmutableRichLong(x)

20L.pred // returns 19

Other languages have ways of doing similar things. JavaScript and Ruby actually let you add methods to existing objects, and these methods will then work everywhere else where those objects are used, which is not always good. A badly behaving piece of code could easily screw things up for everyone that way. Extension methods in C# are more similar to Scala’s implicit conversion, but they don’t require actual creation of new objects — they are just a mechanism for invoking static methods as if they were members of their first parameter. I’m not sure what to think about that. I guess it might be preferable to just calling the method normally, in some DSL scenario. Continue reading

Will Java change, stay the same or be replaced?

Disclaimer: my opinions on programming languages are based on intuition and casual observations more often than on deep knowledge and experience, so please take everything said below with a grain of salt.

I think Java is definitely the programming language and platform for most applications right now, be it server, desktop or mobile. C#/.NET is comparable and C# as a language may actually be a bit better when it comes to features, but as long as it’s controlled by Microsoft and at the same time Java is more open, less controlled, and the JRE has many implementations, most people and organizations will (or should) choose Java.

All the other more or less popular languages certainly have their place as well. C and C++ are good for writing efficient and close to hardware programs — Java may actually be faster than C++ in some rare cases, but it will always have some overhead simply because it runs in a VM and is managed. JavaScript, Perl, PHP, Python, Ruby etc. are either well suited for some tastes or have some specific advantages for certain applications or development styles. Functional languages and more specialized languages will not go anywhere either, they are needed too.

But Java is the general purpose language that can satisfy almost any requirements and scale in most directions (if not quite down to scripting).

However, Java has problems as well.

Continue reading

Learning Scala: Compiler Surprises

Scala seems to be getting a lot of publicity lately. I’m glad for that, because the more I learn about it, the more I realize that it’s a really great language and needs more attention. Some other bloggers have already written introductory articles and talked about various aspects of Scala, but maybe I’ll have something to add. I’m planning on using Scala alongside Java in personal projects, but at the moment I’m just learning and experimenting, writing short pieces of code to try out the various language features.

Coming from Java programming, even after learning the basics and perhaps some of the advanced concepts of Scala, one can run into some really surprising compiler error messages because of the way Scala works. I ran into one of these issues and thought this would be an interesting way to illustrate some features of Scala. Note: for clarity, I’m using type annotations in this blog entry where I would normally leave them out.

After executing the following code, it’s natural to expect that i will have the value 13, as we’re used to in Java, C++ and other languages:

var i: Int = 1
i += 10 + 2

In Scala, the above code will actually produce a compiler error:

error: type mismatch;
found : Int(2)
required: String
Continue reading

Scala, DSLs, Behavior Driven Development?

I’ve started looking at Scala recently because it seems exactly the kind of language I would like to use as a complement to Java on the JVM: it’s similar to Java, but is a “pure” object oriented language and supports a shorter syntax, annotations, generics, closures, a functional programming style and mix-ins. Oh, and it’s fast, or at least seems to be from the little information that is available.

The fact that it’s statically typed is a huge plus in my eyes — I spent two and a half years as a PHP programmer before moving to Java, but think that dynamically typed languages are not for every task. Maybe I’m overgeneralizing, maybe.

Since Scala is rather new and doesn’t have many libraries yet, I’m sure there are plenty of exciting things that can and will be done in it, but I think there are a few areas where Scala should be especially useful. I’m talking about DSLs! Especially DSLs interacting with Java code (and preferably one way).

Continue reading