So you like tabs…

…lots of them. Worse, Opera doesn’t cooperate particularly well when you have a gazillion of the darned things. If you’re like me, you know exactly what I’m talking about. Maybe you’re fed up with Firefox feeling sluggish with more than 100 tabs, you want to try something else, perhaps you don’t care much for Chrome, and you just heard that Opera 10 came out of beta/RC status. As a consequence, you’ve probably encountered this:

It looks awful, doesn’t it?

Don’t worry, I have a cure. It’s a little hidden in Opera’s appearance preferences, but once you figure out how the customization feature of the toolbars works, it isn’t so bad!

First, navigate to Tools > Appearance > click on “Toolbars” and enjoy mucking about with something that isn’t immediately intuitive. I promise, it isn’t. You would think there’d be a drop-down list somewhere that gives you an option. Maybe you’ve tried clicking on one of the buttons (and they highlight individually). But here’s what you do: First, click on a tab; the bar should now appear with a yellow highlight around it–maybe something like this:

See how my tab bar has a little bit of yellow around it? If you don’t have the same thing, click on a tab–literally on the tab. If you click to the side or on one of the various buttons surrounding Opera’s tabs, you’ll wind up selecting the button.

But, back to what we were doing, assuming you’ve gotten the whole how-the-heck-do-I-select-this-stupid-thing out of the way. Let’s, take a look at the appearance settings–you’ll see that the text next to “wrapping” in my screenshot is currently highlighted in blue. That’s important, because you’ll need to select show extender menu:

Once you select it and click OK, your Opera window will now look like this:

Much better! The only downside is that it appears you can’t use the scrollwheel to cycle through the list of tabs as in Firefox (not literally cycling tabs like Arora does; just the list of tabs!). Now it’s possible to go back to being a tab monger without winding up with zillions of 10-pixel-wide tabs and requiring sniper-like skills to click the exact one you want.

Oh, and for you browser devs who think no one in their right mind would use more than a hundred tabs, I’d like to offer a rebuttal. Take this as a use case to prove that there are some people out here insane enough to use much more than a hundred. In fact, try 400+:

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.