1
2

scala> 1.2 - 1.0
res1: Double = 0.19999999999999996

Oops. Shouldn’t that be 0.2? Yes it should, but since the number 0.2 cannot be represented exactly in binary form, the result is a little bit less. This problem becomes annoying when Floats or Double values are used to represent money. It gets worse when multiplication or division operations magnify the error, as for example in the case of interest calculations. Simply put, you can’t guarantee the exactness of calculations down to the cent when you represent monetary amounts as floating point values. The Java language has a type called BigDecimal which solves this problem. It offers arbitrary scale fixed point arithmetics that allows precise financial calculations. Unfortunately, Java’s BigDecimal class has a rather unwieldy API which is a pain to use. No problem, you may think, because Scala offers a wrapper for BigDecimal that lets you use it like a normal number. That is true, but try this out:

1
2
3

scala> val b: BigDecimal = 0.1
b: BigDecimal =
  0.1000000000000000055511151231257827021181583404541015625

Oops again. This doesn’t look much better. What is more, the BigDecimal wrapper class in Scala has abstracted away the control over rounding behaviour and precision offered by the Java API. Of course, you could follow another approach and use Long values to represent money and scale them to the required precision, say one ten thousands of a Dollar. However, there are a number of problems with this approach. First, the value range is limited by MAX_LONG/scale. Second, you have to do complex formatting every time you print the values. Third, you have to code rounding manually because remainders are discarded in integer arithmetics:

1
2

scala> 59L / 10L
res2: Long = 5

With this in mind, I have created a Scala currency type that offers arbitrary precision fixed point arithmetics with an easy-to-use API. It is based on the Java’s BigDecimal type - why reinvent the wheel? Let’s repeat the first arithmetic operation using the currency type:

1
2

scala> Currency(1.2) - Currency(1.0)
res3: Currency = 0.20

This time the result is correct. It is correct, because the currency type automatically takes care of rounding. By default, the result is rounded to the second decimal place using the ROUND_HALF_UP rounding mode, which means that 1.555 is rounded to 1.56 and -1.555 is rounded to -1.56. Unlike the rounding for Float and Double values, the rounding is symmetric, which is standard in most financial calculations. If you need a different rounding behaviour – no problem. With the currency type, you have complete control over precision and rounding behaviour.

1
2
3
4
5
6
7
8
9

scala> val c = Currency("1234.56789", 4)
c: Currency = 1234.5679
 
scala> val d = Currency(0.1, 20)
d: Currency = 0.10000000000000000000
 
scala> import Currency.RoundingMode._
scala> val e = Currency(22.78, 2, ROUND_DOWN)
e: Currency = 22.78

The first expression creates a currency value with a precision of 1/10000 (= four places right of the decimal point) from a string argument where the fifth decimal place is rounded up in construction. The second expression creates a value of 0.1 (10 cents) with a precision of 10^-20 or 20 places after the decimal point. The third expression constructs a value of 22.78 with a special rounding mode that stipulates that values should always be rounded down. The effect can be seen when performing an arithmetic operation:

1
2
3
4
5
6
7
8
9
10
11

scala> e * 1.1
res4: Currency = 25.05
 
scala> val f = Currency(22.78, 2, ROUND_UP)
f: Currency = 22.78
 
scala> e == f
res5: Boolean = true
 
scala> f * 1.1
res6: Currency = 25.06

In this example, the first operation e * 1.1 yields 25.05. We create another currency object with the same value, however with a different rounding mode. When performing the same operation on the second value f, the result differs by one cent from the first because it was rounded differently. This means that arithmetic operations with currency values that have different precision and/or rounding modes are not transitive. This is of course intended behaviour.

The above examples show simple calculations with non-specific currency values. In addition to the numeric amount, the currency type optionally takes a currency designation in the form of an ISO 4217 three-letter code. For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

scala> val salary = Currency(4789.90, "USD")
salary: Currency = 4789.90 USD
 
scala> val bonus = Currency(500, "USD")
bonus: Currency = 500.00 USD
 
scala> val holidayInEurope = Currency(2400, "EUR")
holidayInEurope: Currency = 2400.00 EUR
 
scala> salary + bonus
res7: Currency = 5289.90 USD
 
scala> salary + holidayInEurope
MismatchedCurrencyException

You can add, subtract and compare amounts in the same currency (or of a non-specific currency value), but when you try to add two different currency values, you get an exception. Alternatively, different currencies could be implemented as different subtypes, as suggested in Ch.20, Programming in Scala (Odersky, Spoon, Venners). This has the advantage that currency mismatches can be detected at compile time. However, it complicates the design and makes mapping the currency type to a database rather awkward. I think that the disadvantages outweigh the benefits, so I implemented the currency type as a “monolithic” class that knows about all currencies. With this design, it becomes easy to format currency values for output.

1
2
3
4
5
6
7
8
9
10
11
12

scala> salary.format
res8: String = $4,789.90
 
scala> import java.util.Locale
scala> holidayInEurope.format(new Locale("de", "DE"))
res9: String = 2.400,00 €
 
scala> holidayInEurope.format(new Locale("fr", "CH"))
res10: String = € 2'400.00
 
scala> salary.format("\u00A4 #,##0.0000")
res11: String = $ 4,789.9000

The currency class offers a severalfold overloaded format method that formats currency amounts according to either the default locale or a chosen locale. Alternatively, you can specify a formatting pattern and/or symbols to use, or you can use Java’s DecimalFormat class for formatting. Thus you have total control over the formatted output. The currency class can also verbalise amounts in four languages.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

scala> salary.say
res12: String =
  four thousand seven hundred eighty nine Dollars ninety Cents
 
scala> salary.sayNumber
res13: String =
  four thousand seven hundred eighty nine 90/100
 
scala> val pesos = Currency("1538.20", "MXN")
pesos: Currency = 1538.20 MXN
 
scala> pesos.say(new Locale("es"))
res14: String =
  mil cincocientos treinta y ocho Mexican Peso veinte Centavo
 
scala> pesos.sayNumber(new Locale("es"))
res15: String = mil cincocientos treinta y ocho 20/100

Finally, the currency class provides a number of convenience methods, such as percentage(), setDecimals(), abs(), fraction(), integral(), pow(), symbol(), getAllCurrencies(), etc., and a number of factory methods and conversion methods to simplify programming with currency values.

View Source Code.
Download source code and API documentation.

I should have said “almost all” hardware. Unfortunately one piece of hardware refused cooperation with Linux, namely my Novatel USB modem. Since I’ve come to rely on 3G mobile Internet, this is a knockout criterion. No modem, no Internet. After hours of scouring the Web for possible solutions and  trying out various settings, I gave up in frustration. There wasn’t anything I could do except zapping the Linux partition and installing old friend XP. To attenuate my disappointment, I will make it a dual boot machine, though. Note to hardware vendors: please take Linux seriously and provide drivers for your nifty electronics. That would make life much easier. I guess I have to postpone my switch-over to Linux for another year. Hopefully I will be able to resist the urge to buy another piece of exotic hardware in the meantime.

I am not sure whether this is good news. While it was apparent to most observers that Sun was past its zenith, one wonders what will happen to its employees and its innovations. Granted, an acquisition by IBM would have tipped the scales even more in favour of Big Blue’s dominance in the enterprise market and that might have distorted competition. But one may doubt that Oracle will uphold Sun’s commitment to the open source community. Sun’s market was driven by innovation and open source products. Oracle’s market is clearly not.

In particular, one wonders what will happen to MySQL which was bought by Sun earlier last year and which competes with Oracle’s core products. Pessimistic observers have already called it MyToast. Will Larry Ellison allow MySQL to compete in the enterprise market? Probably not. Other items in Sun’s portfolio once considered crown jewels, such Solaris and Glassfish, might also be on the endangered list. But that is pure speculation at this moment. Whether this acquisition will turn out to be a good move for Oracle is currently debated by the industry experts. Whether it is a positive turn for open source community may be reasonably doubted. Time will show.

The study of C led me to Unix. I began writing clones of Unix tools and utilities for my own use. This was the late 80s before the GNU and Linux phenomena appeared. One such project was a text editor that I enhanced with optimised scrolling routines in 386 Assembler language. I wrote the editor after I had exchanged my Atari computer for a PC. After a few months I had a number of common Unix tools and a nice text editor at my disposal which I could use under MS-DOS. Then I read Andrew Tanenbaum’s Minix book and I got into system programming. I wrote a micro-kernel task scheduler for the 386 in Assembler. Multi-tasking was a fascinating thing that seemed to be out of reach for an average personal computer. At the time, I briefly considered expanding the micro-kernel into a more complete OS by adding memory management and file management. However, I soon realised the immensity of this task. I had just started studying informatics, and I figured that I wouldn’t be able to accomplish it while still visiting lectures and doing homework. At university, we were taught Pascal as a “first” programming language and Lisp as a second. Pascal was very easy, of course; it seemed like a verbose dialect of C. - Lisp, on the other hand, I found quite repulsive. - I could appreciate the underlying mathematical idea, the lambda calculus, but the syntax was just awful. I believe it was  IEEE Scheme. The language seemed great for graph-theoretical problems, but unsuitable to express common algorithms in a natural way. In other words, I found it to be a language for eggheads.

At the time, the imperative programming paradigm was predominant. It seemed the best way to get things done, as development tools and libraries for imperative procedural languages were readily available. The next language I learned at the university was Modula 2. I thought of it as an elaboration of Pascal with emphasis on data abstraction and encapsulation. From Modula 2 I learned the importance of encapsulation. Although I didn’t use Modula 2 for practical applications, I was able to apply the conceptual foundation in my work that revolved around C  programming. After university, I worked in systems programming. I designed and implemented drivers for a company that manufactured proprietary hardware. Then I changed to work with another company in the field of machine translation and computer based training. After 5 years of coding in C, I thought it was time for a change. This was the early nineties, so I turned my attention to application programming with RAD tools which had just hit the market. I learned SQL inside out and created data-driven programs. Visual Basic 3.0 was the killer application in 1993, as it made the construction of Windows GUIs extremely easy. I was able to tie in with my prior Basic experience. Customers liked the productivity that comes with RAD. After about a year, I dropped VB in favour of Delphi, which was superior for this purpose. Likewise, I could tie in with my previous Pascal experience. I learned the rudiments of object oriented programming with Object Pascal, which is odd given that C++ would have been the more natural path to object orientation after having programmed in C for many years. However, Object Pascal taught me proper componentisation.

This was the mid-nineties and a lot of amazing things happened in the IT industry. The most important change was the commercial breakthrough of the Internet. Almost simultaneously, the Linux phenomenon happened. The IT industry boomed and technological progress was fast-paced. The Internet connected everybody everywhere and Linux brought corporate computing horsepower to the desktop. As a result of these changes, I began coding HTML in 1996 and I learned JavaScript and Perl in 1997. The next year brought even more changes, as I decided to gear my business towards web development. Perl seemed like an idiosyncratic Unix solution born out of necessity. It was certainly practical for server side programming, but it was also rather painful and hackish. Fortunately, PHP appeared at around the same time and it offered a much cleaner solution for server programming. Soon I found myself programming web applications in PHP most of the time. LAMP-based applications literally exploded on the Internet between 1998 and 2003. During this period, I also learned the rudiments of Java, C++, and C#. I was responsible for the management of projects implemented in all of these languages. Object-oriented programming had become the mainstream paradigm in the late nineties. I decided that I needed to take on one of these languages more seriously. The obvious choice was Java, since it was general purpose, but still very strong in the field of web development.

So I fully immersed myself in Java when the language made the transition from 1.4 to 1.5. At that point, Java was already mature and mainstream. As a latecomer to Java, the platform seemed huge to me, certainly larger than anything I had looked at before, including .NET. The sheer number of APIs was just unbelievable. It required a sustained effort of two years during which I read a shelf of Java books and began moving from trivial programming exercises to small projects and then to larger projects. Since the mid-2000s, Java has become my mainstay. There are two reasons why I like Java. First, there is a fantastic eco-system connected to the platform. It ranges from best-of-breed IDEs, VMs, and app-servers to a gazillion libraries and frameworks, and (almost) everything is free. Second, Java is extremely scalable and robust. It is not the purest object-oriented language, neither the richest, but Java is probably the one language that transforms average programmers into software engineers. I argue that this is so, because of the high level of standardisation and best practices endorsement in the Java community. I know that there are quite a few people who debate that. However, there’s a reason why universities teach Java to freshmen and why corporations use Java for enterprise development. It offers the largest and possibly the most robust platform for developing industrial-strength software.

Of course, not everything is hunky-dory in the Java department. I perceive that the main problem is the language itself. - It’s aging. - Although (or perhaps because) it forces programmers to write tidy code and relinquish dirty C tricks, it tends to be tedious, as it involves generous amounts of boilerplate code. It also lacks good paradigms for fine-grained concurrency control. Fortunately, with the Scala language I discovered a possible solution for these problems. At this point -early 2009- I haven’t yet done any larger projects in Scala, but my eagerness to do so is growing. Adding the functional paradigm to my programming instruments is very beneficial. It even flows over into my Java work, since it has changed the way I phrase algorithms in Java. The only negative effect is that by learning Scala, the limitations of the Java language became more evident and thus more painful. While functional programming will probably grow in the near future, Java has such a strong position that it won’t just fade away. Many large systems have been created in Java, so there will be maintenance work for decades to come. Meanwhile, it will be interesting to see how fast the industry embraces functional programming.

I like RAD tools ever since I worked with Delphi more than a decade ago. In many ways, Delphi was the perfect solution for creating Windows GUI applications. It allowed me to create high-performance apps with great ease and tremendous productivity. When I first came across JSF, I realised it holds a similar promise for the field of web development. In my view, RAD is the most attractive way to create applications. It many not be the best choice for every type of application, but I am sure it is the best choice for a large percentage of run-of-the-mill commercial apps.

The UI-centred approach of RAD tools makes prototyping very easy and it gives development projects a certain “users first” bent which I always found useful in project management. When communicating with customers, a quick mock up screen always beats a bunch of UML diagrams. In addition, I  like the idea of high-level encapsulation offered by the visual component concept that RAD tools are known for. This high-level encapsulation, if properly implemented, should be able to be extended  to non-visual components, so that business logic might benefit from the same mechanism. Of course, in Java all you need are Java Beans (POJOs) for this purpose.

JFS is the attempt to apply a GUI-like component model to web applications. It has an extensible set of visual components, such as text boxes, list boxes, tabs, AJAX widgets, and data-aware widgets. Strictly speaking, the widgets themselves sit on top of JSF. JSF defines the component architecture and an application framework that includes things such as validators, converters, events, listeners and navigation rules. Like GUI widgets, JSF widgets are stateful. The JSF architecture makes this completely transparent to the application. This means, the application is oblivious of the stateless HTTP protocol, or whatever other protocol might be used. It doesn’t need to take care of preserving and/or restoring state. Sounds a bit like magic, doesn’t it?

If you look into the internals of JFS, however, it becomes clear that this magic is created at a heavy cost. The first thing to look at is the 6-phase JSF request lifecycle:

1. Restore View
2. Apply Request Values
3. Process Validations
4. Update Model Values
5. Invoke Application
6. Render Response

Most of these phases do event processing. Quite a bit of additional processing compared to an average web app. But that is not the problem. The problem is in the first phase called “restore view”. This implies that the server maintains an internal representation of the view. When the view is restored, JSF creates a component tree in memory that represents the client view. If you think, this might be a bit memory-intensive, you are probably right. Unfortunately, JSF doesn’t stop there. Component state is typically stored in what is called managed beans. A managed bean is merely an conceptual extension of a JSP backing bean. “Managed” means that the bean is declared in an XML file and that it is allocated automatically when needed by the JSF framework. However, it is not automatically deallocated, unless it is in page or request scope.

Sounds like a memory eater? To me it does. Since managed beans are typically allocated in session scope, I imagine that a single client can quickly gobble up a few hundred kilobytes or more on the server. Of course you need session scope data in any web app. In this regard, JSF isn’t different from other web apps. However, with dozens of beans floating around in session memory and new ones being added without direct application intervention, I’d argue that the programmer loses fine-grained control over memory requirements. I can’t help asking: does JSF scale? Many people think it doesn’t. One might even ask further, whether replicating client state on the server is scalable at all. Is it the right approach?

I can’t answer that question, but I’ll think twice about using JSF in future projects. Probably one doesn’t need to be concerned about applications that don’t go beyond the departmental level with a few dozen concurrent users. But what about a few hundred or a few thousand concurrent users? Even if you create an application for small scale use, it’s not an attractive choice to use a non-scalable architecture. Who knows how the application will eventually evolve and who will use it? As things stand now, JSF seems like a trade-off to me. You get RAD productivity at the expense of scalability. Or isn’t this the case? I think the burden of proof is with the JSF camp.

The meaning of these identifiers doesn’t quite correspond to what an English speaker would expect them to mean, which is rather confusing. Yet, if you look up these terms in a dictionary, you find that all of them, with exception of divisionArea, are valid translations of the original German term. This is one example where it would have been better to use German identifiers instead. These terms appeared in source code that had English identifiers and German JavaDoc comments. Perhaps as a rule of thumb, it’s better not to use English identifiers if the team is not comfortable with English documentation as well. Again, in an international environment this may not be an option. Therefore, it might be worthwhile to have an English speaker refactor code written by non-native speakers for the sake of clarity.

Another aspect that pertains to language conventions is grammar. You might think that I am nitpicking when mentioning grammar in computer programs. The point is that proper grammar facilitates understanding. This is true for natural language as well as program code. The grammatical rules for identifier names are few and simple. Use nouns for class names and object references, because classes and objects abstract real world objects. In some cases, objects directly correspond to entities of the problem domain, such as Customer, Order, Department, User, etc. In other cases they do not. It is important to qualify class names further if a single noun does not describe it sufficiently. Examples of qualified nouns are TransferredFunds, AppraisalStatistics, AvailableOptions. Use verbs for methods and functions, because methods abstract behaviour. Good examples for method names are addTax(), computeCRC(), checkAvailability(), getDepartment(). Avoid using nouns as method identifiers, such as department() instead of getDepartment() or adjectives such as available() instead of getAvailability(). An exception to this rule would be languages where methods directly represent properties, because property names should be either adjectives or nouns. Likewise, interfaces should be nouns, or in some special cases adjectives, such as Triangular, Centred, Deductible, etc. depending on their purpose. In the latter case, the adjective is derived from the verb deduct and by convention the interface defines a method with the same name, i.e. deduct(). Other examples for similarly named interfaces are Readable, Comparable, or Sortable. Finally, we have identifiers for local variables, parameters, and fields. What should these look like? There are no hard rules for these program elements, since local variables, parameters and fields can represent anything from objects to properties, primitives, and even methods. It’s best if grammar conventions follow those of the type the identifier refers to.

Next I want to talk about identifier naming schemes. These are fixed sets of conventions for assigning names. Two widely used schemes are positional notation and Hungarian notation. Positional notation is typically used in legacy languages where identifier names are very short, as for example in older Fortran and Cobol programs. Another example is the 8.3 notation of MS-DOS file system. Identifiers that use positional notation are usually unintelligible without a key. An example would be APRPOCTT, where the first two characters AP stand for the main program module “Accounts Payable”, RP stands for the sub-module “reporting” and OCT1 means “operating costs total 1”. Needless to say that this notation defies easy readability and should not be used unless absolutely necessary. A more widely used scheme is Hungarian notation. Hungarian notation is characterised by prefixes, and sometimes postfixes, which are added to the variable name and which carry type information. For example, in the original Hungarian notation suggested by Charles Simonyi for the C language, b stands for boolean, i for integer, p for pointer, sz for zero-terminated strings, and so on. These prefixes can be combined. The name arrpszMessages, for example, refers to an array of pointers to zero-terminated strings. Sometimes Hungarian notation is applied to conceptual types rather than implementation types. For instance, the identifier arrstrMessages refers to an array of strings without saying anything about pointers or zero-termination.

Hungarian notation is still used today with certain languages, such as C, C++ and Delphi. In C++ the following prefixes are often used to denote scope: g_ for global, m_ for class members (fields), s_ for static members, and _ for local variables. Delphi is unusual in the sense that Hungarian notation denote object types. The type names themselves are always prefixed with the letter T in Delphi, so a button class would be defined as TButton and an instance of that type would be prefixed with Btn or something similar, such as BtnOK, BtnCancel, BtnRetry, etc. There is a lot of debate whether Hungarian notation is generally useful or not. The main criticism is that implementation types are somewhat irrelevant for the programmer writing code in a statically typed language, since types are checked by the compiler. When the programmer needs to know about the type of a variable or an object, modern IDEs can usually resolve it automatically. In this case, the prefixes just add unnecessary visual clutter. Hungarian notation still has its place in C, but it’s definitely not that useful with contemporary languages and development tools. The same can be said in principle about most other identifier naming schemes. Naming schemes generally attempt to add metadata to identifiers, or create artificial namespaces. Most modern languages provide better means to both ends. For example, the Java language has annotations for metadata and packages for namespaces. There is usually no need to employ naming schemes with most modern languages. It’s probably more worthwhile to spent effort on finding intelligible and descriptive names rather than inventing clever naming schemes.

Next time I will talk about the practical considerations in choosing good identifier names and provide some examples to illustrate best practices.

Identifier names are a crucial part of any program. They provide clues about semantics and program logic. They make or break code readability. They determine whether code is self-documenting or not. So, the old Latin proverb “nomen est omen” can be applied as follows: If you read through a piece of code for the first time and you have no idea what the variables are supposed to represent, or what the methods are supposed to accomplish, then this is a bad omen. It suggests that the author was not quite sure how to formulate the problem (or didn’t care) and it can be expected that the other aspects of the program are at least as confusing. If you read through a piece of code and the identifier names are easily comprehensible and fit together like the pieces of a jigsaw puzzle, then this is a good omen. It suggests that the author had a clear idea of the task at hand. Naturally, there are many intermediate levels between these two opposites.

While contemporary code editors and IDEs are very powerful, identifier naming is one of the things that cannot currently be automated by these tools. It is up to the programmer to choose identifier names. Since good naming practice is essential for code maintainability, we will first define what makes a good naming practice and then look at some concrete examples of good and bad strategies. There are three basic ingredients for a good naming practice: (1) semantic precision, (2) consistency, (3) the right amount of verbosity. The first aspect is by far the hardest to get right. Semantic precision means that the chosen name is appropriate, unambiguous, well defined, and compliant with conventions. Consistency means that names are formed according to common patterns and that terms are used consistently throughout the program. The right amount of verbosity relates to identifier length. It means that names do not leave anything open to guesswork while avoiding redundancy.

An identifier usually consists of a single word or a combination of words. In case of the latter, the individual words are often set apart by using CamelCase or the “_” underscore character. One of the most commonly found questionable practice is the use of abbreviations instead of written out words, for example rptCount instead of repeatCount. The word count indicates that this variable is a counter, but what is counted? Repetitions, receptors, recipients, red points, or something else? Reptiles perhaps? By adding a mere three characters and writing out the first word, the ambiguity is eliminated. This doesn’t mean that abbreviations are always bad. For example, nothing speaks against widely used acronyms like URI for UniqueResourceIdentifier, or LCD instead of LiquidCrystalDisplay. Likewise, domain-specific abbreviations are acceptable, if the program is written within that domain, for example FOB (free on board) in the shipping domain, or VAT (value added tax) in the accounting domain. By definition this also includes acronyms in the software domain, such as i18n for internationalisation, or ftp for file transfer protocol. In addition, there are a number of  pre- and postfixes used ubiquitously in programming, such as min, max, fmt, pos, len, num, cnt, etc. which every programmer understands. Generally speaking, abbreviations and acronyms should be used sparingly and only when they are common and free of ambiguity.

This also means that one-letter or two-letter variable names, such as a, b, c, f1, x2, etc. are generally a bad idea, because they say nothing about the content of the variable. There is one exception to this rule: loop indices. Since loop indices (or iterator variables) are only used to to iterate through a collection of values, they don’t have any intrinsic meaning. So one might as well give them one-letter names. By convention, the letters i, j, k, etc. are used, whereas the alphabetic order corresponds to the loop nesting level. This mean i is used for the outermost loop, j for the second nested loop, k for the third, and so on. This is standard practice for loop indices, but in other cases, index position corresponds to certain semantics. In this case, indices do have meaning. For example, one might define an array of counters, where counter[0] contains the number of students, counter[1] contains the number of passed tests and counter[2] contains the number of failed tests. Since the index numbers themselves don’t communicate any meaning, it is appropriate to define an enumerable type or a set of integer constants that conveys this meaning, for example STUDENTS=0, PASSED_TESTS=1, FAILED_TESTS=2, and so on.

This is all pretty much standard programming practice. Next time we will look at common identifier naming schemes, their merits and demerits, as well as language conventions.

(x: Int) => x - 1

A function literal is simply a function without a name. You can assign this expression to an ordinary variable and then use it later to execute the function:

1
2

var decrease = (x: Int) => x - 1
decrease(11)

You can probably guess what the value of decrease(11) is. Up to this point, this isn’t very exiting. However, because decrease is a var and not a val, you can reassign it a different function literal later on depending on some condition. Or you could pass it as an argument to another function. You might begin to see the possibilities behind the first class function concept. Instead of the trivial example above you can use this capability with more complex methods. For example, you could use it for callback methods, or for wrapping methods in an API and facilitating common OOP patterns, such as the facade and adapter patterns. All of this can be done, unlike in Java, with a minimum of syntactical fuss.

But it gets even better. Functions in Scala are not limited to use simple parameters as in the above example. For example, you could write something like this:

var decrease = (x: Int) => x – something

Obviously, the variable something, which is subtracted from x is not defined in this expression. The assignment is still syntactically valid. This means the variable decrease is properly defined, but it cannot be applied. In other words, to apply a value or to execute the function meaningfully, it must be executed in a context where something is defined. The above expression is an “open term” and something is called a “free variable”. An open term is the principal ingredient of a closure. Simply put, a closure closes an open term by providing the necessary context. This is an example of a closure:

1
2

something = 10
decrease(100)

The first line defines the free variable something. The second line therefore produces a meaningful value. That’s the closure. In terms of computer science, a closure is a function that is evaluated and whose result depend on an outer context. It’s like an inner class in Java that references variables of its outer class. However, the Scala construct is more powerful and much easier to write. It can be useful in a number of situations where the place where behaviour is defined is removed from the place where the behaviour is applied.

While closures are supported by languages that one wouldn’t consider functional programming languages, higher-order functions are a hallmark of the functional paradigm. The concept is simple enough. A higher-order function is a function that either takes one or more function parameters or returns a function, or both. The prime example would be the map function. The map function takes an list as input and produces an output list using a specific algorithm. The algorithm is of course represented by another function that is passed as a parameter to the map function. In Java, this would typically require a the use of a for loop or an iterator. In Scala, the mapping can be expressed succinctly with a single line. Here are some examples:

1
2
3
4
5
6
7
8
9
10

scala> List("alpha", "beta", "crash").map(
  p => p.substring(0,1))
res0: List[java.lang.String] = List(a, b, c)
 
scala> List(1, 2, 3) map (_ * 2)
res1: List[Int] = List(2, 4, 6)
 
scala> List("Tango", "Mango", "Bobo", "Gogo")
    map (_.endsWith("go"))
res2: List[Boolean] = List(true, true, false, true)

These examples are quite trivial, but they illustrate the basic idea of higher-order functions. The first line maps a list of strings to another list of strings. The result elements retain only the first characters. The second line is produced by the interactive Scala Interpreter; it displays the result of the expression. A function literal is used as the parameter of the map function in line 1. Line 5 and 9 make use of the underscore notation which is a placeholder for the bound variable, which is the list element parameter in this case. Thus (_*2) is equivalent to (i => i * 2).

Higher-order functions are not just a succinct form of control abstraction. They are also very useful for reducing code duplication and redundancy. The typical use case is abstracting behaviour. There are a number of design patterns for abstracting behaviour which are popular in languages like C++ or Java, such as the strategy pattern. Consider the following Java example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

import java.io.*;
import java.util.*;
 
interface FileNameMatcher {
  boolean matchFileName(String fileName, String query);
}
 
class FileNameMatcherEnding implements FileNameMatcher {
  public boolean matchFileName(String fileName,
    String query) {
    return fileName.endsWith(query);
  }
}
 
class FileNameMatcherContaining implements FileNameMatcher {
  public boolean matchFileName(String fileName,
    String query) {
    return fileName.contains(query);
  }
}
 
class FileNameMatcherRegex implements FileNameMatcher {
  public boolean matchFileName(String fileName,
    String query) {
    return fileName.matches(query);
  }
}
 
public class FileMatcher {
 
  public static String[] filesMatching(FileNameMatcher
    fileNameMatcher, String query) {
    File[] files = new File(".").listFiles();
    List<string> matchResult = new ArrayList<string>();
    for (File thisFile : files) {
      if(fileNameMatcher.matchFileName(
        thisFile.toString(), query))
        matchResult.add(thisFile.toString());
    }
    return matchResult.toArray(new String[] {});
  }
 
  public static void main(String[] args) {
    String query = args[0];
    String[] matchingFiles;
    matchingFiles = filesMatching(
      new FileNameMatcherEnding(), query);
    matchingFiles = filesMatching(
      new FileNameMatcherContaining(), query);
    matchingFiles = filesMatching(
      new FileNameMatcherRegex(), query);
  }
 
}

This is a classic example of the strategy pattern. The core piece of this code is the one-method interface named FileNameMatcher. This interface abstracts different ways to match a file name. The three implementing methods match a file name either by looking whether a file name ends with a given string, whether it contains a given string, or whether it matches a regular expression. The filesMatching() method of the FileMatcher class takes a strategy implementation and applies it to a list that contains all files in the current directory. Finally, the main() function calls the FileMatcher with the three different strategy objects that were defined earlier. All together that’s 55 lines of Java code. Compare this to the Scala equivalent which appears in the book Programming in Scala by Odersky, Spoon and Venners (page 199):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

object FileMatcher {
 
  private val filesHere=(new java.io.File(".")).listFiles
 
  private def filesMatching(matcher: String => Boolean)=
    for (file <- filesHere; if matcher(file.getName))
      yield file
 
  def filesEnding(query: String)=
    filesMatching(_.endsWith(query))
  def filesContaining(query: String)=
    filesMatching(_.contains(query))
  def filesRegex(query: String)=
    filesMatching(_.matches(query))
}
 
object Main {
  def main(args: Array[String]) {
    val query = args(0);
    var matchingFiles = FileMatcher.filesEnding(query)
    matchingFiles = FileMatcher.filesContaining(query)
    matchingFiles = FileMatcher.filesRegex(query)
  }
}

Brevity is the soul of wit. Obviously, there is no need to create strategy objects in Scala. With higher-order functions, the strategy pattern simply evaporates. This is one of the areas where Scala’s powerful language constructs eliminate the need for patterns. Critical voices have said that design patterns are crutches for weaknesses in certain programming languages. Although I don’t fully agree with this statement, it seems to hold true in case of the strategy pattern. The above Scala example is actually more verbose than necessary. One could make the filesMatching() method public and call it directly with a function parameter from outside the FileMatcher object. At the cost of full encapsulation, this would make the code three lines shorter.