Today marked my progress through chapters 2, 3, and a small part of 4 (more on that next time; it’s about stuff I largely already know but adds some of Scala’s own twist to classes and the likes). So far, the biggest hurdle is the syntax. It’s like a strange mix between Java, Python, and even a little BASIC (because of the array indices). I can certainly feel the influences other languages have had on Scala already!

The unusual thing is that I’m starting to catch on to the more fundamental principle behind functional languages: Functions should have no side effects. Really, it makes far more sense. When performing a replace operation on a string, for example, the original object should not be modified; instead, a new object is returned with the replacements applied and the original object remains untouched.

It is no surprise then that Scala includes data structures that fall into two categories: mutable and immutable. Near as I can gather at this point, the former is intended for imperative-style writing while the latter is preferred for functional. But, that’s simply where the fascinating bits start. Let’s take a look at tuples.

The Tuple

Like Python (and a few other languages), Scala has a tuple construct that provides an array-like immutable data structure that can be used as keys, key/value pairs, and so forth. The biggest difference, as I can tell, is that Scala tuples aren’t exactly like Python tuples; you can’t use array-like indices to reference a tuple offset. Instead, it appears that you really need to know the structure of the tuple ahead of time. Mind you, that’s not a big deal as Scala provides many other data structures that could be used as a Python tuple might.

You can build things with tuples, but let’s explore objects

I’m really excited about some of the things I’ve learned related to tuples. For the sake of clarity, however, I really need to discuss one of the more interesting things I learned related to objects in Scala. As such, I hope that you’ll forgive me for the brief digression. I have a lot of things to cover, so backtracking is sometimes a necessary evil!

Speaking of backtracking, I suspect this post will work roughly like our memories. To illustrate, think of a time when you were walking along a sidewalk on a beautiful day. Beams of sunlight were streaming between the trees as the shadows of birds scaled their way up the hill before you. The birds almost immediately enter your field of view and then you encounter an incredibly perfume floating about on the air. You turn and notice a handful of flowers sprouting among the bushes to your left, and then you remember a particular chore you still had to take care of–such as delivering flowers to your girlfriend, mother, or what have you.

Then a neighborhood dog barks and instantly shatters the serenity of this landscape into a million pieces. The birds are a distant memory, the fragrance of flowers have been blown away on the brisk morning air, and the only thing in your mind is a vague sense of frustration. That damned dog ruined it all.

Next, some random idiot comes careening passed you on his bicycle–nearly hitting you. You spit in anger briefly as the rush of air blows by. You notice that a magazine in his book back flies out across the sidewalk and blows onto the road. Glancing at the rolled up paper briefly, you wonder if the approaching car is fated to hit it. You smirk wryly, maybe even consider what a joy karma is in moments like these, and then the vehicle swerves away from the magazine. That moron on the bike apparently noticed that his bag had come loose and sent a few of his things flying into the air like a swarm of stirred up bees. He sheepishly walks his bike passed you.

As you glance at the man, you start to think back on what that chore was you so wished you could remember. Birds? Maybe it was chicken. No, wait, we fixed chicken for dinner last night. Hmmm…

And then you think about it for a few minutes more. You even consider for a moment the prospect of retracing your steps from earlier in the morning. Those flowers smelled so wonderful… EUREKA!

Then it hits you.

That’s sort of what the purpose of my backtracking is. It serves to both jog my memory as well as grant me an excuse to make up a story to share.

The world of objects in Scala

Scala, like Python, is what I would call a “pure” object-oriented programming language. Everything is an object. Operations call methods on each object (including integers). However, unlike Python, there are no true operations. +, -, /, and * are all individual methods; in Python, the + operator calls the object’s __add__ method whereas in Scala, there exists a method called, quite literally, +. That’s it. Thus, in Scala, addition can be written in two ways:

// Addition using "standard" syntax:
var added = 1 + 2
 
// Addition using method calls:
var added = (1).+(2)
 
// ...which could also be written as:
var added = 1.+(2)

Isn’t that interesting? What’s more, every single operator in Scala is a method. This works because methods in Scala that except a single argument can be written without parenthesis. Therefore, the standard 1 + 2 operation works as well.

Let’s talk again about loops

Now, I really do want to get back to tuples. They excited me. First, I need to illustrate further this notion of “everything as an object” (or method). Remember how in my first post, I discussed the .foreach() method of looping through an array? Guess what? There’s another way to do it using the range method. Here’s an example:

val sometext = Array("This", "is", "an", "example!")
for (i <- 0 to sometext.length-1) {
    println(blargh(i))
}

This prints:

This
is
an
example!

As in addition, this translates into two things. First, the <- operator can be read as “in.” I’m not sure if this is an actual method that is created or whether this is a genuine Scala operator. I imagine this will come clear in a few chapters. Second, the part that reads 0 to sometext.length-1 creates a range between the values of 0 and sometext.length minus one. This could also be written as: (0).to(sometext.length - 1). Or, if you really wanted additional verbosity: (0).to(sometext.length.-(1)).

So what’s this got to do with tuples?

Well, nothing much, really. (I’ll explain shortly.) Tuples, as I mentioned earlier, are simple data structures. Here’s an example of a tuple containing multiple data types as well as Scala’s output (I’m using the command line interpreter):

scala> val tup = (1, "one")
tup: (Int, java.lang.String) = (1,one)

Notice that Scala creates a tuple object containing the data types Int and java.lang.String (all data types in the JVM-version of Scala are just Java data types with some wrappers). This is handy; it’s also important to know that there exists another method: ->. Here’s the -> method at work:

scala> var tup = 1 -> "one"
tup: (Int, java.lang.String) = (1,one)

Notice that the -> operator created a tuple? Remember, too, that there is another way to write this:

scala> (1).->("one")
res41: (Int, java.lang.String) = (1,one)

(Don’t use 1.->("one") or it’ll use a Double instead of an Int.)

Here’s why this is important.

Maps use tuples. True story!

To create a Map or a HashMap in Scala, you might do something like the following:

scala> var numbers = Map[Int, String]()
numbers: scala.collection.immutable.Map[Int,String] = Map()
 
scala> numbers += 1 -> "one"
 
scala> numbers += 2 -> "two"
 
scala> numbers += 3 -> "three"
 
scala> numbers
res4: scala.collection.immutable.Map[Int,String] = Map(1 -> one, 2 -> two, 3 -> three)

See how I used the -> operator here? That’s because maps use tuples to “map” values internally. More importantly, the += operator is just a method; by default, this method will create a new map containing both the existing values and the new value (the default maps are immutable). However, if you were to type this before any of the example code (above), import scala.collection.mutable.Map, you’d wind up with a mutable version of Map in which += appends a new item to the map. Thus, here’s what the code above might look like when we’re adding new items to the map:

numbers.+=((1).->"one")

Which could also be written as:

numbers.+=((1, "one"))

And if you’re really adventurous, you could also write this to avoid having to give the compiler hints about the data types (that’s the cruft in square brackets):

var numbers = Map((1, "one"), (2 -> "two"), (3).->("three"))

That’ll cover nearly all bases! Isn’t it amazing?

A thought to leave

I’ll leave you with some thoughts for this evening. I’m very impressed with Scala so far. The syntax is a little difficult to learn for anyone coming from an imperative programming background, but the shear expressive power of Scala is dumbfounding. I’m incredibly excited by the language already, and I haven’t even touched but a small fragment of code in Programming in Scala. What’s strange is that it hasn’t been as difficult to pick up as I imagined. While I’ve run into errors, naturally, while playing around in the interactive interpreter, the errors I have created for myself are few and far between. I can’t wait to get into the Actors model of multiprocessing. I think that’s where Scala is going to truly shine. Plus, I’m intending to try it out by writing an MD5-sum generator of files on a file system (that seems to be my generic “Hello, world!” application of choice–strange!).

Anyway, I may not have another entry in this section for a couple of days. The weekend is coming up, and I have to cook for the folks as they have some guests stopping by. I’ll try an squeeze in another one on Sunday if I can’t make it Saturday. Oh, and I’ve decided that I might just skip Links of the Week this week. I know some of you really enjoy that section, so I’ll try and get something for you!

I received the book Programming in Scala today. It’s an impressive text that, while weighing in at “only” 730 some-odd-pages, is chock full of examples and 33 chapters (yes, 33!). It contains about half as many pages as Programming Python and Programming Perl but don’t be fooled–the text is well written, thorough, and concise. While it may lack some of the easier to digest fluff of introductory texts, it is already proving its worth as reference material. A word of warning: This book isn’t something new programmers should consider purchasing, but if you already have another programming language under your belt it’d be a great start. Thus far, I’ve managed to make it through the introduction and the first chapter-and-a-half. Unfortunately, the prospect of writing my first post on Learning Scala was much too appealing to resist.

A couple of thoughts

First, I’d like to point out that Programming in Scala is by far one of the best programming texts I’ve encountered. It’s published by Artima Press and is written by Martin Odersky (the same guy who devised Scala), Lex Spoon, and Bill Venners. These three have created a masterful work of art. I never thought I’d say that about a programming text; really, it truly is a work of art. Suffice it to say, I’m duly impressed.

The writing style of Programming in Scala is notably academic and this is a good thing. It meshes well with one’s expectations of an instructive work and speaks to the reader in a much higher tone than other introductory texts, particularly those written by publishers who probably shouldn’t be named. More importantly, especially to the budget-conscious programmer, the book is pressed in black and white which keeps both background noise and purchase price low. There’s no fancy coloring nor flashy graphics to distract the reader from the task of learning and lots and lots of code. The book does contain some flow charts and diagrams as I’ve noticed during quick thumb-throughs after my initial excitement of opening the text (including at least one screen shot of a browser window) but it is tastefully included and most certainly not over done. This book does lack one thing in particular that many publishers seem keen on including: Obnoxious bulleted points that detract from the learning process, usually containing drawn caricatures, targeted toward individuals who would much rather be entertained than learn.

Trust me, the exclusion of flashy graphics is a good thing! I just wish that other publishers would follow the lead of Artima and O’Reilly (another great publishing house for technical works). If I ever have to suffer through another book like Java, How to Program, I think I’ll stab myself in the eye with a screw driver. Honestly, if you’re publishing a book about programming, you don’t turn it into an art studio of your favorite bee-things. It’s insulting to those of us who genuinely want to learn. Please, take a lesson from Artima and concern yourselves with content not presentation^[1]. It worked well when my dad went to college. His books were text only.

Programming in Scala gives the reader exactly what they asked for: Instructions on learning how to program–in Scala. It’s amazing. Rather than wasting away pages and pages of text explaining things entirely unrelated to the language, the book dives right in. (To be fair, the first chapter gives some history and a whirlwind tour of Scala’s capabilities, and I really wish this was an idea other programming texts would borrow–they generally don’t.) While I wouldn’t recommend this book to first timers, I can most certainly see the utility in referencing this text if you’re already familiar with at least one other language (especially Java).

In case I didn’t make it clear

Programming in Scala is a superb book. I’d recommend it to anyone, and I’m only on page 33. The style of prose used in the work is outstanding. Oh, and there’s plenty of examples. If you want to learn Scala, do yourself a favor and purchase this book. You certainly won’t regret it.

Now that that’s out of the way…

Let’s talk about my initial impressions. First, I’m impressed. Scala appears to bring to the table some ideas that have been sorely lacking in a JVM-hosted language. It also appears to bind together the worlds of functional and imperative programming with object-oriented design; most importantly, everything is an object in Scala, including literals like 1. Operators aren’t implemented as a core language construct. Instead, an operator like + exists as a method implemented by the object it is applied to. So, for example, adding two numbers such as 4 + 10 will call the addition method on 4, adding 10 to its value and returning it. (The return value is also an object.)

Functions are also objects, similar in nature to Python. There is one exception, however; functions are first class citizens of the language and may be passed as arguments to other functions. It’s difficult to wrap your head around this particular concept–and I’m struggling with this bit, more on that in a moment–but think of it like this: When you’re calling a looping method on an object, you can pass in a function to that method. That function is then called, with each value passed into the function, and the call is performed. The best example I have is from page 33:

args.foreach(println)

This actually expands to:

args.foreach((arg: String) => println(arg))

Which means, roughly, “for each value of the String array args, pass it to the function println.” In the imperative world, as Programming points out on page 32, this would translate to:

var i = 0
while (i < args.length) {
    if (i != 0)
        print(" ")
    print(args(i))
    i += 1
}
println()

Clearly, the functional methods are much shorter. To the trained eye, I’m also certain they’re much clearer. The trouble is…

Functional is hard for imperative minds

The fact that functional thinking operates a bit differently from the imperative style forces a barrier upon those of us who were brought up in the imperative world. We’re used to functions doing something (also called creating “side effects” in the functional world). We’re told that if you need to loop through an array of strings, you use a language construct to assist–like foreach. Or maybe you keep track of the current offset using an index. In either case, the notion of using functions as a looping construct is almost unsettling.

I suspect this is the notion I will have the most difficulty swallowing. It certainly looks easy, but looks are deceptive. Functional languages like Erlang have a great deal of expressiveness at the cost of readability to anyone not well versed in the dark arts brought into the world by the cult of lambda calculus. I haven’t any idea what it takes to be initiated into such a cult. However, I will bet real money that I’ll be thinking about this for the first couple of weeks. It might even feel about right, too.

There’s always a light at the end of the tunnel…

The plus side is that Scala looks like a great introduction to the world of functional programming. It isn’t because the language borrows so much from Java (it does, but…), it’s because the language borrows so many great ideas from everywhere. It really does. I look forward to the “actors” model borrowed from Erlang for concurrency. It reminds me a bit of Stackless Python; message passing is an alternative solution to the multiprocessing problem. Rather than running multiple threads of execution, message passing works by allowing different actors in the same application to pass data back and forth while performing other duties. For example, if one particular actor requires inputs from three different sources, each of those sources can collect the necessary data, send it, and then go about their business to collect more. Meanwhile, the actor receiving the data blocks until it receives all three, does its processing, and then passes on the result. The collection actors have no obligation to wait until their chunk is seen to as would be the case in a single-threaded imperative language.

Of course, Java threads are available to Scala, too, so there’s quite literally a wide variety of design choices the developer can make!

…but sometimes that light is a little obscured

Scala does use some strange syntax that will definitely take some getting used to. First, variable declarations are backwards from most popular languages like Java, C, C++, Python, and Ruby. (This isn’t exactly applicable to the latter two since they’re not statically typed.) Rather than the declaration of type variable = value, Scala uses the syntax: variable:type = value. This also applies to functions which are defined as:

def functionName (arg:type, arg2:type ... argN:type):returnType = { /* function block */ }

Notice, too, that the function block occurs after an equal sign. It makes a little bit of sense in a round about way–you’re setting the function “equal” to something (its code block). To this extent, I think some syntax won’t be too difficult to follow.

Scala does have some other oddities that are simply minor aesthetic changes, though they might be familiar to those who have programmed in languages like BASIC. As in BASIC, Scala array indices are accessed via parenthesis not square brackets. Thus:

print myArray(0)

Would be valid, whereas:

print myArray[0]

Would not.

Furthermore, generics (type-hints for the compiler when declaring arrays) use square brackets instead of angled brackets. Thus, the generic (in C#):

List myList = new List<string>();

Would possibly be declared as:

var myList = List[String]()

Or even:

var myList:List[String] = List()

(I have no idea if there’s a list type, but it’s an analog that came to mind as I was typing this.)

I think this journey is going to be a fun one.

Footnotes

1: The excuse I’ve heard parroted most often is that the How to Program series are “introductory text(s).” It doesn’t really hold a lot of water for me, because I know a number of my peers who absolutely hated the stupid thing. The damn cartoons interspersed throughout Java, How to Program are insulting. There are obvious tags plastered around the book (with a bee pointing at it) that cover topics often so obvious that I know of a particular famous captain who might be looking for a new line of work.

That reminds me of a brief story related to this particular series. When I first started in the IS program at NMSU, I had the misfortune of having to purchase the sixth edition of Java, How to Program. Thankfully, I managed to used it for several of my classes. That may have mitigated much of the cost but it did little to sooth my annoyances with the cover. There, in full-color glory, was the caricature of a stereotypical college student (albeit as a bee), clearly running late, with his aunt pointing hurriedly at her wrist watch. Granted, if (IF!) you can manage to stomach the cover without succumbing to the feeling that the authors clearly think you’re too inept to read real books, the actual content isn’t bad. Although, I most certainly cannot justify full color printing for a book that’s over 1600 pages. Seriously, if you want syntax highlighting, I can think of a few solutions that happen to be free.

I confess that the work is reasonably decent for those who aren’t familiar with any programming languages. However, please realize that some college students aren’t empty headed dimwits who think computers are those funny boxes you play video games on. Some of us may have written code before. Some of us may have even had jobs. Some of us were probably a few years out of high school before we could afford to go to university. Seriously, do what a real publisher (again, like Artima and O’Reilly) does: press and publish books that actually treat the reader like a human being. Heck, even the Head First introductory series do exactly this without insulting the intelligence of the reader. Damn, even the Dummies guides manage the same thing IN SPITE OF THEIR TITLE.

Rant off.

Borrowing an idea from Will, I’ve decided that I will be detailing the progress I make as I teach myself a new programming language: Scala. I’ve heard nothing but good things about it and have toyed around with a couple of (simple!) tutorials. I’m impressed enough to have ordered a book which I expect to receive sometime toward the end of this week. While this is simply a prologue to the actual play, I would like to discuss my motivation for sharing this.

First, I don’t have a particularly good recollection of my first steps taken with any programming language early on in my education or life. The first one I learned–contrary to popular belief–was not PHP; it was Perl. It’s almost embarrassing to admit, not so much because I find Perl to be a terrible language (although it is something of a write-once language), but because most hackers cut their teeth on languages closer to bare metal like C. I’m sure I still have some of my first Perl programs available, and I’d be hard pressed not to blush were I to browse them, all while wondering who the idiot was writing such awful code! I wish I had written a journal during those early days to record my first few steps. Though my memory of that particular time period isn’t great, I do recall some months of playing with Perl and CGI all to print random quotes to a web page. That’s what fascinated me most, and I think that was what spawned my love affair with web application development.

Second, I’d like to record mostly for my own future reference my steps through a language that differs significantly from the ones I currently know. I have quite a few under my belt (Python, PHP, Java, Perl, C#, and VB.NET–though the latter two are virtually identical thanks to the CLR with only syntax placing a wall between them) these days, and I think it’s generally a wonderful idea to have a history available for reference, either for personal fulfillment or as a utility available to others. Since hindsight is often viewed through rose-colored glasses, it should be interesting both to myself and anyone else reading this future work (even years from now) to peruse the sorts of “gotchas” I encounter–and what I find easiest to grasp. If nothing else, it might equip future Scala coders with some tools to combat the inevitable stumbling blocks they’re bound to encounter.

Third, I think this might be a great way to encapsulate my own thoughts on the learning process. Perhaps I could grant some insight on what happens inside a developer’s mind as they learn a new language especially one that exists outside their comfort zone. Scala combines the worlds of OOP and functional programming offering features I’m certain I have yet to understand. I’ve never delved into a functional language before (Python borrows some ideas from functional programming, mind you), and I expect to get caught by a hitch or two along the way. For current Java programmers, my work here may offer some clues as to the sorts of things you should expect to both enjoy and suffer along the road. Not that I wish to imply you’ll suffer through the language; rather, I’d like to hint that there are certain things that might not immediately seem intuitive to the Java developer. Nevertheless, being a JVM-hosted language, Scala presents us with some distinct advantages. There is also a .NET CLR-hosted port of Scala, too, for those of you living in the kingdom of Microsoft. Suffice it to say that there’s a little something for everyone.

Finally, I’d like to offer this as an analog to Will’s project I mentioned earlier. He came up with this idea some months back (it’s still on his blog, in fact), and I commended him on the utility of the notion. It’s such a great idea, I’d like to present my own implementation of it–but from a different perspective. Indeed, this project in particular–this recording of my own experiences–might serve itself to him as a guidebook of should he choose to do any sort of programming and more importantly extend that programming into other languages. Programmers these days don’t get by with a single language alone. I’ve read from sources too numerous to list that the average programmer should take the time to learn at least one language per year during their career. No, they won’t jumble themselves together–though you might notice a couple of conflicts (indented formatting habits while switching from Python to PHP or terminating lines with semi-colons while switching from Java to Python).

Along these lines, it’s important to point out that once you learn a language, the general rule of thumb is that it gets easier to learn others. Perhaps this has something to do with the formation of synapses that make the learning process more streamlined rather than establishing a particular bias toward certain constructs, syntaxes, and idea abstraction. This holds true, I think, for both natural (spoken) language and programming. Those in my circle of peers who know at least one language other than their native tongue have a much easier time grasping new ones, and I certainly know from experience, personal and otherwise, that learning programming languages becomes easier as more and more make their way into one’s skill set.

Scala looks to be a great general purpose language. It even has a web framework called Lift that can operate on any fairly modern servlet container (like Tomcat), so there’s some utility to be had from it outside the domain of generic applications. Its allure to me lies in its management of higher concurrency, which is something that still seems slightly awkward in languages like Python and Java. (To be fair, C# has advantages over Java mostly because it is newer, but there are still other things I like most about Java’s model–many of which Python borrows.) If nothing else, perhaps this coming project of mine will make (or break) your decision to adopt Scala.

Don’t expect this writing style to be formative for my future narration on this topic. Academic-speak and structure is something I enjoy, but I also enjoy writing entertaining works of literature. Thus, when I actually write the Real Thing, I hope it’ll be fun. You may grow to love or hate it. It may even take a month or two–maybe longer–to write in its entirety, but the results will be worth it. I promise.

Until then, stay tuned for the Links of the Week coming Wednesday or later. I have a few things in the queue for this week, so LotW might be delayed. If so, I apologize ahead of time.

Update Links of the Week will probably wait ’til Friday. I’ve been pretty busy, and I’m going to be putting together a tutorial on vBulletin tutorials for my own purposes. I know Will really finds the LotW entertaining; I apologize ahead of time, but I’ve really been a little busy.

Also, I’ve fixed some mistakes in this post and rephrased a few parts to make clear some of my original intent. It still isn’t perfect. I couldn’t finish my updates in Firefox due to persistent crashes, and if there’s something missing, I’ve noticed that Chrome didn’t open the original version of the document when I went to edit it. Weird.