Perks of software development

The past year has been quite different for me. It has had little to do with engineering sciences or public services, but everything to do with things enterprisey; thus, I may have a particular bias that I would not have otherwise. To get us going, let me first list some of the issues we encounter in software development, in decreasing order of importance:

Incorrect programs.

A Superb Programmer Ninja writes bug-free C code with cat, but the rest of us will gladly accept all of the help that the tools and the language can offer us.

Complexity.

Software systems are becoming increasingly large, which emphasizes the importance of proper abstraction levels in programming languages — you would not write Civilization V in an assembly language.

Lack of proper infrastructure.

A perfect language with equal implementation is not enough if you lack the tools with which to write the code, analyze the code, write unit tests, and most importantly, develop new software quickly. The latter requires comprehensive language libraries, so that you don’t need to reinvent the wheel each time.

Performance.

CPU speed has increased very little over the last 5 years. In the near future, a commodity PC will have at least 16 cores; at the same time, software development will become an order of magnitude harder with parallel processing and shared state.

Deployment hassles.

With self-hosted services, this is not too much of a problem, but for standalone products, having to install tens of language libraries, several system libraries and/or runtimes, which the former depend on, and manage all of the versions with different installations quickly becomes a velocity drag you wish you didn’t have.

Pulling the curtain a bit

Any language likely to become a hit tomorrow must have been developed quite a long time ago in order to reach sufficient maturity, with accompanying libraries and tools. That leaves out many of the good candidates (sorry, Falcon fans). And with respect to correctness and complexity (which are given 1st and 2nd priority on my list) a paradigm already exists that offers the following benefits:

• Given a variable (symbol) in some scope, the attached value never differs. Remember how in math class x = y+2 always meant precisely that, meaning that such ill tricks as x = "bar" ; x = 7*86400 are never legal. Every “variable” is actually a constant!
• All function calls produce the same output when the input is the same. This is an immense help when it comes to debugging.
• Given two function calls with no common dependency, the computation can automatically be performed in parallel . This is possible because the function outcome is only affected by the function body itself and its inputs.
  High-level abstractions avoid the need to manually code such meager things as iterating a loop, selectively mapping a set of values to something else, reducing a list of things to a single item, and so forth.

Now, I would have lied in the first three sections unless we define a function to be a pure function. And the paradigm is of course functional programming, and unless you have lived in the closet for the last 50 years, it is nothing new. Actually the first such language, Lisp, was created about 50 years(!) ago, and it remains as modern/timeless as any other language. The reason why FP is once again starting to gain momentum is probably due to several factors: first, there are concurrency issues using an imperative model due to shared state. Second, many popular languages include at least partial support for the FP style development, such as list comprehensions, map/reduce, and functions/methods as first class objects, thus making the FP model more reachable for the masses. But mostly, I believe the main reason for the increased popularity is that while reliable parallel, distributed programs are certainly possible with imperative languages, building such systems with reasonable quality requirements in time and on budget is not something that the majority of software developers are cap^h^h^hwilling to do.

I kind of really wanted Scala to be the Next Big Thing. It supports FP quite well. It offers immutable variables, pattern matching, higher order functions, enough infrastructure, and already even the potential Killer App (Lift). Heck, even Twitter chose it after realizing that Ruby on Rails was not going to cut it.

But Scala does not have pure functions. It does not enforce or encourage the user to avoid state manipulation or doing many things at once at the syntax level. And the syntax is far from simple. Scala makes it easier to switch to FP, as you can always resort back to the familiar imperative style, but the downside is that as a hybrid language, it has syntax and structures for both OOP and FP, and many of the benefits of FP are lost as a result of that freedom.
And one thing that I have recently learned is that voluntary, carefully designed, self-posed constraints are often a good thing and with FP, very much so.

Then there’s a language called Haskell that has pure functions. You cannot mutate state in a function, even if you wanted to. To do so, you must wrap your values in monads, which differ in syntax and are identified as non-functions by the compiler, statically in compile time. It strongly encourages programmers to encapsulate all business logic in pure functions and to make only necessary state changes in the monadic parts. That’s Separation of Concerns baked right into the language itself. It has static type inference, meaning that the compiler can see if the functions and their arguments are valid during compilation (ie. any editor that is able to interprete Haskell code can identify whether a function call has valid signature). It has software transactional memory, lazy evaluation, and pattern matching. Haskell can be run both interactively and compiled to binary, the latter being a nice benefit when distributing the software, not to mention the performance gain compared with interpreted languages. It is easy to debug: if a function produces wrong results with some input, you know that the problem cannot be in the state of the program but it must be in the function itself. There are no classes (as with objects), but there are type classes, which practically provide something analogous to generic interfaces in OOP parlance. Testing and code coverage tools are included in the standard distribution package. It is very concise without being obscure. It really comes with batteries included.

And there’s a lot of Magical Pixie Dust.

Whetting the appetite

Functional languages are excellent tools with which to create really usable modules: with a functional paradigm, you get a uniform programming model. Because everything is either a thing or a list of things, currying (partial function application) and function composition offer an extremely versatile toolset with which to create complex software from simpler components, which are composed of even simpler components — all without being tied to the details of the data. A good example from Real World Haskell:

We have a method words, which returns a list of words in a string:
words :: String -> [String]

From Data.Char, we get the method isUpper :: Char -> Bool in order to determine whether a char is an uppercase letter. How to count the number of uppercase words in a string? The expression

capCount = length . filter (isUpper . head) . words

does the job. But what if you wish to use the ability to detect if a word starts with a capital letter elsewhere? Well, thanks to currying, you can just bind a symbol to the new function (dot means function composition — in Haskell, f . g is practically the same as f(g(x)) in mathematics):

let capWord = isUpper . head

It works because strings are actually just character lists, and the head returns the first character in a string. Due to currying, the composed function still requires one argument (string) before it can be referred to as a list of characters. This can be seen by inspecting the type:

capWord :: [Char] -> Bool

After that definition, we can use the function above, with the original code simplified to

let capCount = length . filter capWord . words

Did you notice that there are no arguments to function definition? We could have written

let capCount string = length . filter capWord . Words $ string

but that is not common practice among Haskell programmers. The string does not add information to the function definition, just noise. We want to express what kind of function we are defining, and Haskell afficionados prefer to express only the absolutely essential. Thus we have bound the function capCount to equal the right hand-side of the definition, meaning that the symbol can be replaced with (length . filter capWord . Words $ string) anywhere, always. And vice versa.

Partial application is very common in Haskell. All Haskell functions are unary, accepting only a single argument. The function add

let add x y = x + y

actually accepts only one numeric argument, then it returns a function that takes one numeric argument and returns a number. You can then create a one-incrementor with

let incr = add 1
incr 41 -- returns The Answer (42)


Reusability is also easier to achieve, as it is often the algorithms, rather than the data types that repeat in different projects and thus should be easily reused. The problem with OOP is that the methods are tied to the data, and without careful design, the data often ends up strongly coupled to the algorithms using it. Designing programs is not about the data per se, but rather about the flow of data and the operations performed on the data. It’s all about functions; how to transform input and/or current state into output (or another state).

The claim

So, I believe that Haskell is the Next Big Thing for several reasons:

• FP is the future. Programming mission-critical, complex systems in a 64-core system with imperative languages just doesn’t cut it.
• It is simple enough. Ok, the Haskell learning curve can be steep, but mainly for the FP paradigm itself. Monads are much simpler to use and understand than they are to explain — though it may require reading an article or two in order to grasp them. But Haskell does not have anything like the syntactic jungle of C++ or Scala that must be learned.
• Library and editor support is available and has been for over 15 years. It’s far from immature.
  Haskell has received a great deal of positive press lately among common programming blogs, and most importantly…
• …it is favored by many Alpha Geek Programmers. Blame me if Haskell isn’t at least where Ruby was in 2007 by the year 2016.

Naturally, there are other languages that fit rather well here, one of which is Clojure, a JVM-based, Lisp-like language, also largely influenced by ML and Haskell. Released to the public in 2007, it is not yet all that mature at this stage, but still, it has received a lot buzz recently and for a reason.

I’m still a Haskell novice. In spite of the fact that I have just started to really learn FP and Haskell, I often run into a situation in which I am coding some function and I think that I am about halfway through figuring out a solution or that perhaps another third is missing from the working solution. Suddenly, I realize that I have the complete solution right before me, after, for example, adding a method call or two to some handy chain of composed function calls. Most of the time, I end up wondering how my mediocre creations can accomplish so much in so little, while lacking the finesse and elegance common among more seasoned Haskell veterans.

Luckily here at Leonidas, I’m surrounded by much smarter people, and I know that I will learn a great deal in the near future. There’s a nice surprise around the corner.. . Stay tuned!

Credits to Alexandre Duret-Lutz for the Goedel, Escher, Bach photograph.

Nature of Software Quality

Software quality is still one of the great challenges in the industry. Due to the inherent and unique nature of computer programs, there are no universally accepted methods for ensuring apparent program quality and even fewer practical methods for program verification. However, both of these are not only very important, but also are related. Furthermore, final product quality takes much more than ensuring good source code quality: there is the user interface and overall user experience, documentation, etc. Quality has to permeate the whole project, not just the software and implicit byproducts. There is requirement analysis, customer communication, project management, support. Customers are not seeking quality software tools for their problems—what they really want is quality solutions to their problems. That aside, my scope here is limited to the source code quality.

Curiously enough, many professional developers seem to be able to distinguish intuitively between a poorly written program and a quality one. Yet most tools capable of producing comparable, numeric values somehow denoting a specific, qualitative aspect of source code are frowned upon. This is not because such tools are useless; the problem is that it takes more than a glance at the final aggregated figure(s) to really benefit from them. In particular, static source code analysis takes you only so far. Many important aspects in the source code do not deal with syntax but with semantics, something of which our computers are blissfully ignorant.

The Principle

I have often pondered a question that an apprentice programmer might pose: What is the single most important thing I should learn to become a Good Programmer? Recently, I think I have found the answer. It is the principle known as Separation of Concerns (SoC). It seems that I am not alone. To put it loosely, SoC means that a module, class, function, or method in a computer program should deal with only one thing, with no functional overlap with others. It is closely tied to the concept of loose coupling, and is considered so important that most programming paradigms aim to help developers achieve SoC.

All design patterns separate the specific composition of objects and functionality as a whole (the pattern) from the objects’ individual, domain-specific functionality. Procedural programming helps achieve SoC by separating concerns into procedures, whereas object-oriented programming uses objects for the very same purpose. The famous MVC pattern is based on the very core idea of SoC by separating the actual logic (model) from the user interface (view and controller). Functional programming allows complex composition of functions irrespective of function arguments, thus separating actual data structures from program flow. Splitting methods to smaller pieces by level of abstraction is applying SoC.

Many other ideas derive from or result in SoC as a direct consequence, such as “A class should have one and only one reason to change.”

Impact on software

The benefits of SoC are numerous. First of all, it helps us understand any given computation unit (module, class, method or function) because it deals with only one “thing.” Second, it makes encapsulation and hiding easier, as a change in one unit usually does not require changes in other units. Third, it makes automated testing much easier, as both the state set-up for the test and testing the outcome are simple: given this input, expect this output (or state change, but not both). As such, SoC is one of the core tools in managing software complexity. [1]

What about performance and reusability? Because SoC leads to indirection and due to extra instantiation and chained method calls, performance does suffer a bit, at least in principle. But the benefits far outweigh the incurred costs, as it allows for very aggressive local optimization without fear of breaking other parts of the system. Increased orthogonality and tightly restricted functionality lead to more reusable components as well.

However, sometimes applying SoC is very difficult. There might be pervasive features such as logging and security that are used throughout the project. Maintaining loose coupling and avoiding repetition could amount to anything between trivial design issues to very difficult ones, depending on the language and/or supporting libraries. For example, the Ruby language makes it relatively simple to, say, decorate certain types of calls with custom callbacks without modifying the source code of affected computation units. This is because Ruby has very powerful metaprogramming facilities such as dynamic method definition, re-openable as well as executable class definitions and method introspection. On the other hand, programs written in Java usually require AOP-style extensions such as AspectJ to achieve similar results, adding extraneous dependencies and new syntax to learn.

The point is that if SoC is so crucial, then surely the programming language should help the developer in achieving it, even coerce the developer to that direction. On the next part, we’ll see what kind of programming language would be ideal from this point of view.

References

[1] http://www.cs.au.dk/~eernst/papers/splat03.pdf