Functional Programming languages seem to be an increasingly popular topic. Why? What do FP languages teach or do for us?

Venkat Functional Programming has been around for a long time. Programmers are taking the time over the past few decades to rediscover it.

A few decades ago low level languages like Assembly and C were popular. As OOP and C++ because prominent, it became increasingly clear that memory management is quite unmanageable. We raised the bar, let the platform deal with memory management and garbage collection. We figured that by relying on a higher level of abstraction we can focus our effort, for better, on application development rather than memory management. This, among other things, brought languages like Java and C# to prominence. When programming in these languages, we don't have to worry any more about memory management.

As we moved on to create highly responsive applications, we began to realize that dealing with threading and concurrency is another real pain. As soon as you learn how to create a thread, the next thing you learn is how to limit and control it. Multithreaded applications are plagued with issues related to contention, deadlocks, correctness, and complexity of the low level APIs. The gaining availability of multi core processors and multiprocessors is only exasperating these concern. We're eager to put an end to the concurrency issues like we took care of memory management. This is where functional programming comes in.

Functional Programming advocates assignment-less programming and higher order functions with no side effect. By higher order functions, we mean functions that accept functions as parameters. You pass functions, return functions, and nest functions. Furthermore, these functions solely rely on the input you send them. They're not influenced by any external shared state, and, in turn, do not affect any external shared state. They promote immutability. This eliminates the concern of contention and the need for synchronization. It makes it easier to understand and verify behavior of such functions. However, threads still need to communicate and exchange information. Functional Programming languages like Scala provide an actor based message passing model to realize this.

What makes Scala the right FP language for people to pick up?

Venkat Scala is a relatively new language. Other prominent FP languages have come before it. However, quite a few things make Scala special and attractive. It is by far the most powerful statically typed, highly expressive, yet concise language that runs on the Java Virtual Machine (JVM). Scala is fully object oriented, intermixes with Java seamlessly, and provides very strong static typing but without the ceremony that Java adds. Though Scala is entirely a new language, for a moment entertain the thought that Scala is a refactored version of Java, stripped out of its ceremony and threading API, then enhanced with sensible type inference and actor based concurrency model. If Java were to be redesigned in 21st century, it may look a lot like Scala. So, if you are programming on the JVM, and are interested in taking advantage of functional programming capabilities, Scala is a great choice.

Why is the JVM a good platform for Scala and FP?

Venkat Or should we pose the question the other way around, asking why is Scala and FP a good choice on the JVM? I think these two questions go hand in hand.

The real strength of Java is not the language but the platform, the JVM. There are three things going for it. First, the capability of the virtual machine itself is superb in terms of performance and scalability. It did not start out that way, however, we've seen tremendous improvements over the past few years. Second, a rich set of libraries and frameworks are available for various tasks that enterprise applications demand. Name it, and there is something available already for you (the concern often in this space is availability of too many options, not too little!). Third, influenced by the two above factors, a significant number of enterprise applications already run on the JVM platform.

Some developers have the luxury of starting out on green field projects and do not have to integrate with other existing applications and components. They have the ability to choose any language and style they desire.

However, a large number of developers don't have that choice. They develop applications that run and integrate with things on the JVM. Emigrating to another language or another platform to enjoy the benefits of functional programming is really not an option for them. Scala provides a tremendous opportunity here. They can stay right on the powerful platform they're on, continue to developer and maintain their existing Java applications, and at the same time take advantage of functional programming and other related benefits that Scala bring to the platform.

Since Scala code compiles down to bytecode and integrates seamlessly with Java, you can take advantage of Scala to the extent you desire and makes sense of the project. You can have a small part of your application written in Scala and the rest of the application in Java. As you get comfortable and make the paradigm shift, more and more code and even entire applications can be in Scala. At this point, you can continue to integrate and utilize other components and services running on the JVM. So, the JVM is not simply a good platform. It is a compelling platform to utilize and benefit from functional style of programming.

What kinds of problems are a good fit for Scala?

Scala's strengths are strong sensible typing, conciseness, pattern matching, and functional style. The first three strengths can help with your traditional programming needs. It will take you less code to achieve your day to day tasks like working with XML, parsing data, manipulating collections of data, ... Scala can help you do the heavy weight lifting with lesser effort. The last strength I mentioned along with the actor based model will help you develop highly concurrent applications without the pain and perils of thread synchronization. On one hand, your concurrent application will be smaller in size. On the other hand, it is devoid of the uncertainty of program correctness due to state contention and deadlocking.

Design patterns and algorithms look differently when implemented in different languages. Can you give us some examples of elegant patterns or algorithms in Scala?

The language idioms have a great influence on the design. There are a number of patterns that are easier to implement in Java compared to C++. Similarly, languages that support closures and provide conciseness make lots of things easier and elegant.

Let's explore one example.

You are asked to total values in a range from 1 to a given number. You can write a simple loop to do this. Now, you are asked to total only select values, say only even numbers. You could duplicate the code that totals and put a condition statement in it. Now, you are asked to support different criteria, select even number, or select odd numbers, or prime numbers, etc. Spend a few minutes thinking about how you can achieve this in Java.

I can think of two ways to implement this in Java.

Approach 1:

Create an abstract class with an abstract method that will evaluate the selection of a value. Use this abstract method in determining the total. This follows the factory method pattern. Here is the code

In this case you don't have to create a separate class to derive from TotalHelper, however, you do have to create (inner) classes that implement the OKToUse interface. Here you are using the strategy pattern to solve the problem.

While both of the above approaches will work, it is a lot of work to implement either approach. You can use IDEs to help generate quite a bit of that code, but that is still a lot of code that you have to look at and maintain.

Let's see how you can solve the above problem in Scala. We will follow along the lines of the second approach above, but without the interface. Since you can pass functions to functions, the code will be a lot simpler to write. At the same time, since Scala is statically typed, you have compile time type checking to ensure you are dealing with the right types in your code. Let's take a look:

The totalSelectValuesInRange() function takes two parameters. The first one is the upper limit for the range you want to work with. The second parameter is a function which accepts an Int and returns a Boolean. Within the totalSelectValuesInRange() function, you create a range and for each element in the range, you include the element in the sum if it passes the criteria evaluated by the function given in the parameter.

>scala totalExample.scala
Total of even numbers from 1 to 10 is 30
Total of odd numbers from 1 to 10 is 25

When looking at the above example, don't focus on the syntax. Instead focus on the semantics. You can't program any language without understanding the syntax. At the same time, once you get a grasp of the syntax, you navigate at the speed possible. This is when the language conciseness will help. There are quite a few interesting things to observe from the above example.

The code is very concise.

You did not spend time creating interfaces. Instead you passed functions around.

You did not specify the type repeatedly. When you called the totalSelectValuesInRange, Scala verified that the operation you perform on the parameter to the function (represented by the underscore) is valid operation on an int. For example, if you wrote

totalSelectValuesInRange(10, _.length() > 0)

Scala will give you a compile time error as shown below:

>scala totalExample.scala
(fragment of totalExample.scala):15: error: value length is not a member of Int
totalSelectValuesInRange(10, _.length() > 0)
^
one error found
!!!
discarding <script preamble>

Notice how it recognized that the parameter represented by _ is an Int.

You did not perform a single assignment (val represents immutable data, you can't change or assign to it once you create it). In the Java example you initialized sum to 0 and then continued to update it. In the Scala example, however, you did not assign a value to any variable at all. This last feature comes in very handy when dealing with concurrency.

Imagine for a minute that the numbers you like to total are your asset values in stock investment. You can write a little code that concurrently fetches the stock prices from the web and determine the total value you have invested in it. You can then total these values without any issues of concurrency. And you'd be surprised, you can do that in about two dozen lines of code in Scala, as shown below.

The actor helped you to dispatch separate concurrent calls to the yahoo web service to fetch the price for the symbols you hold. You multiplied the response you got with the number of units to determine the total value. Finally you messaged that back to the calling actor. In the totalWorth() method you received the response from those calls using the receiveWithin() method and added them up.

Tuesday, March 17, 2009

There are several good looking Scala books on their way to market. I'd like to help you get an early look at the books and their authors, so I'm working on a series of Scala author interviews for the FP side of On Ruby. Here's the second of several interviews.

Functional Programming languages seem to be an increasingly popular topic. Why? What do FP languages teach or do for us?

Alex FP forces you to think differently about solving problems in code, and in a highly structured way. If object-oriented and procedural languages offer a more linguistic approach to programming, functional programming suggests a more mathematical approach. Once you wrap your head around the functional approach to handling collections of data, you'll never think about programming quite the same way. That's the reason that MapReduce, a combination of two fairly simple functional programming concepts, is so essential to what Google does. FP is rich in these powerful abstractions.

Dean It seems that every "paradigm" that goes mainstream lurks in the background until some "killer app" comes along for which the paradigm seems tailor made. GUI's did that for OOP. Now, it seems that growing concerns about pervasive concurrency, sometimes called the "multi-core problem", are driving interest in functional programming.

FP is a promising approach for concurrent programming because in pure FP, variables are immutable and functions have no side effects. If you have immutable variables, no synchronization is required for shared access. All the hard, error-prone programming problems in multithreaded code involve synchronizing access to shared, mutable state. If you get rid of mutable state, those problems just go away.

Another hallmark of FP is that functions are side-effect free — they don't change any global or object state. Such functions are inherently simpler to reason about, test, invoke concurrently, you name it.

Even if you don't care about concurrency (rare, these days), immutable state and side-effect free functions improve code quality, in general. For example, if I have an immutable object "graph", I don't have to worry about passing it to a client that wants to read it. If it's mutable, I have to worry that the client will screw it up in some way. I'd rather screw it up myself, thank you very much!

What makes Scala the right FP language for people to pick up?

Dean When I decided to learn an FP language, I picked Scala for very practical reasons; it seemed to be a very good candidate for widespread adoption. Because it runs on the JVM and because Scala code interoperates with Java code so seamlessly, I felt that a lot of Java developers would eventually migrate to Scala, first as a "better Java" and then later as a hybrid object-functional language, all without losing their existing investment in Java technology.

Alex It's worth clarifying that Scala is a hybrid Object-Oriented/Functional language. It's the best of both worlds: the power of FP with the familiarity of OOP. That familiarity makes Scala is a great first step into FP for programmers who haven't yet tried a functional language. For those who have, the practicality of doing domain modeling with OOP and interfacing with other JVM languages makes Scala a compelling alternative to strictly functional languages like Haskell and Lisp. All languages seem to gravitate towards an object model over time; see the Common Lisp Object System and the myriad efforts to turn JavaScript's prototyping into more traditional OOP. Why not pick a functional language that already has a mature object model baked in?

Why is the JVM a good platform for Scala and FP?

Alex The JVM is a great platform for any language for two reasons: maturity and community. It's widely acknowledged that the JVM isn't just the most mature VMs out there, it's simply one of the most mature of pieces of software out there, on par with the Linux kernel in terms of its history and extensive deployment. The JVM can be tuned, instrumented, profiled, and debugged using a variety of seasoned tools on a multitude of platforms. What's more, there's over a decade's worth of libraries for most any programming task available for the JVM, readily accessible from Scala with essentially no performance penalty. The Java community has already been through the process of producing code to tackle big-time, big-money problems, and that's value you can put to work immediately with Scala.

Scala's author had a hand in more than one functional programming language for the JVM before embarking on Scala. Coincidentally, he's also responsible for many of the performance gains the JVM has made over the years. Other big FP brains like Clojure's author have found the JVM to be a great host for functional languages. It still has a way to go before it's friendlier to dynamic languages, but the JVM's support for strong typing is a good fit for the FP paradigm.

Dean The JVM is arguably the most powerful VM in the world. The global, runtime optimizations it performs are quite extraordinary, doing things a compiler can never do, since it has to rely on static analysis of the code. Of course, the Java ecosystem is also rich with libraries and tools for almost every possible need. Hence, the JVM is great platform to build upon.

That's not to say that the JVM is perfect. It has a number of limitations that make FP harder, like functions are not "first-class" citizens (usable as values, arguments to other functions, and able to stand alone, without being a member of a type). Also, the JVM doesn't do tail-call optimization, which is very useful for recursive functions, which are more common in FP. However, language designers have found ways around these limitations and the JVM is definitely going to address these issues in the future.

By the way, Scala also compiles to .NET byte code, so the .NET community can enjoy Scala goodness, too.

What is the status of Scala on the CLR? Do you know anything about it's performance?

Alex Personally, I haven't worked with Scala on the CLR. My understanding is that CLR support is a lower priority for the developers working on Scala's implementation, and that support may not be complete at this time.

Dean I haven't worked with the CLR version, either. I have heard that Microsoft has given a grant to Martin Odersky's team to keep the .NET support current with the Java support.

With the upcoming changes to the JVM (tail call optimization and first class functions among others), will there be changes to Scala?

Alex I can't speak for the language's authors, but my understanding is that they track changes to the JVM closely to wring as much performance as they can out of Scala's implementation. As the JVM evolves to embrace its newfound role as host to myriad languages, I'm sure Scala will take advantage of those changes. No other language on the JVM has a team that's as capable of doing so.

Dean I've read some detailed blog posts by Charlie Nutter, the JRuby project lead, on the issues they have encountered supporting Ruby features on the JVM. One area of inefficiency is the need to wrap "blocks" (loosely speaking, "bare" functions) in little classes, consuming lots of resources. Some of the features planned for the JVM will certain benefit Scala by eliminating such workarounds.

What kinds of problems are a good fit for Scala?

Dean Scala's flexible syntax is surprising good for defining "internal" DSL's, for which Ruby is justly famous. If you need an "external" DSL, then the combinator parser library will probably be all you need to build a custom parser. This flexibility also allows Scala to provide some very elegant built-in API's for manipulating XML, building thick-client interfaces with Swing, etc.

I can't think of another language that has quite the flexibility for small to large scale problems.

Alex Scala's name is a shortening of "scaleable language". The goal of its creators was to design a language that scaled from small scripting tasks to desktop GUI applications and all the way up to huge enterprise systems. While Scala is certainly capable of all that, its sweet spot seems to be in producing maintainable back-end systems, particularly those that require non-trivial concurrency. Essentially, it's good for the things that languages like Java and C++ are good for, but without suffering the pains and hassles that often come with those languages.

That said, I really do believe that Scala scales from scripts on up. I've written tiny scripts that rip through giant XML files that are just as terse as anything I've written in Ruby and many, many times faster (even accounting for the JVM startup time). I've written a small blogging system of the sort that people usually write in Perl, Python, or PHP and found the code far more maintainable. At Twitter, we're using Scala for critical parts of our service's infrastructure, such as our message queue. I certainly believe in the right language for the right problem, but there's not much I wouldn't at least attempt to solve in Scala.

If you were putting together a development team for a scala project, what are some things you'd look for in the candidates?

Alex We're actively hiring engineers at Twitter, and this is definitely something we've had to think about when it comes to Scala experience, or lack thereof. We know the Scala community is small, and that hiring someone with prior Scala is unlikely today. I think that in a couple years, that's going to be a very different story.

Generally, in-depth experience with OOP, dynamic languages, and a smidge of functional language experience means that a programmer can get up to speed with Scala quickly. If a candidate can tell me what a closure is, or what a combinator is, or describe some basics of type theory, they're going to do fine with Scala. If they can't, though, chances are that they've used those features in other languages and just aren't familiar with the terminology.

The more experience with the Java SDK a programmer has, the easier it'll be to navigate the landscape of classes that Scala is built on. That's hardly a prerequisite, though, and I can say that from personal experience. I've mostly avoided Java over the past five year of my programming career, and it hasn't taken long to come up to speed with "Javaland" by way of Scala. When I need it, it's there. When I don't (which is most of the time), it's not.

I think the ideal Scala programmer is passionate about the language she works with every day. You can write perfectly passable code in Scala if you treat as just another tool, but if you really explore its rich set of features, there's so much to take advantage of. It's been great to see our engineers go from zero familiarity with Scala to writing code that uses the language's most advanced features, like parser combinators and actors.

Dean Over the years, I've found that really good developers tend to be very curious about other languages. So, even if they have no prior exposure to Scala, they have probably seen variations of its features in other languages. In my "day job", I train and mentor teams trying to adopt agile methods, like the XP practices (TDD, pair programming, etc.). I see so much damage in teams that lack these practices that I would also want my Scala new hires to be good at XP!

It seems a bit strange to talk about so much about a language without showing it off a bit. Could one of you provide a small program that shows Scala off a bit?

In it, you can see Scala's support for Domain Specific Languages (via use of the Specs BDD library), anonymous functions, and the clarity and fluidity of Scala's syntax. Given how much time a programmer spends (or should be spending!) writing tests, I think this beautiful test code really shows off what Scala can do in just a few lines.

Dean Scala's support for building nice DSL's doesn't get enough attention, IMHO. It's a killer feature, for the same reason it's so seductive in Ruby. Here's another DSL example, a snippet of code for a build tool I've been working on.

It's inspired by Ruby's "rake". You specify targets, named with Scala symbols (e.g., 'compile) and there are built in functions for invoking the compiler, manipulating files and directories, etc.

By the way, it seems to be an unofficial Scala community requirement that when you do a project to learn Scala, it must either be a build tool or a Twitter client...

Design patterns and algorithms look differently when implemented in different languages. Can you give us some examples of elegant patterns or algorithms in Scala?

Alex Scala's implementation of inheritable, extensible cross-cutting concerns in the form of Traits is one of the language's best features. Imagine Ruby modules on steroids and you're getting there. That's a difficult problem for most languages to handle well, and Scala does a great job at it.

Scala's Actor library is another superbly-implemented part of the language. While Actors in Scala feel "baked in" to the language, in actuality it's a completely self-contained library. The Actor model can be found in Erlang, Io, and a number of other experimental languages, but it feels solid and right at home in Scala.

Dean Indeed, the Actor library is another example of the flexible support for building internal DSL's.

Just for emphasis, let me echo what Alex said about Traits. It's one of the scalability features (in terms of application size and complexity) that I'm most excited about. Here's another way to describe traits; it is Scala's mechanism for supporting "mixin"-style composition, originally made famous in Lisp and more recently in the form of Ruby modules. You have your main class hierarchy (single inheritance, like Java), but you can mix in abstractions and implementations in a modular way, defined as traits. With Java, you can only "mixin" the abstraction part as interfaces. You have to resort to ad-hoc hacks to add implementations. This composition mechanism solves some of the issues that Java users turn to Aspect-Oriented Programming to solve and it promises to encourage more modular designs that will grow gracefully over time.

The question of Design Patterns is an interesting one right now. Patterns are getting a lot of bad mouthing from some reputable (and not so reputable) people. Without rehashing the arguments, let's just say that the central argument seems to be that patterns are just workarounds for language deficiencies. I think that misses the point that a good pattern stands on its own merits. If a language supports it "natively", then so much the better!

Because of Scala's support for FP, especially closures, some design patterns just aren't as important as they are in Java. (I'm looking at you, Visitor!) Rather, API designers can build in elegant hooks for clients to pass in closures to customize behavior, etc.

Also, traits make patterns like Observer very elegant. I've heard there are some good examples of Observer in a Scala book O'Reilly is publishing, available now as a Rough Cut!!

Thursday, March 12, 2009

There are several good looking Scala books on their way to market. I'd like to help you get an early look at the books and their authors, so I'm working on a series of Scala author interviews for the FP side of On Ruby. Here's the first of several interviews.

Functional Programming languages seem to be an increasingly popular topic. Why? What do FP languages teach or do for us?

David I came to Scala via Ruby. I was doing some Ruby and some Java coding (I've been doing Java since 1996). My Java code started taking on a "Ruby Flavor" in that I was passing around a lot of code blocks. In Ruby, passing code block, lambdas, etc. is super-simple. In Java, I was creating lots of anonymous inner classes and passing them around... it was a syntactic disaster.

In Scala, passing a function, a block of code, as a parameter is as easy and syntactically pleasing as it is in Ruby (or nearly so... Charlie Nutter has been barfing all over Scala's syntax lately.) This is the first part of what I understand FP to be. So, in a way, Ruby is a functional language.

In addition to the simple ability to pass code blocks as parameters, other touch-stones of FP style coding are:

Immutable data structures

Pattern Matching

Optionally, a math-driven type system

Optionally, lazy evaluation

Scala's default collections classes are immutable. Once an instance has been created, the value of that instance, whether is be a List, a Map (dictionary), etc. never changes. This is familiar to Java programmers. Java's String class is immutable. Once you create a String, you can never change it. Python requires immutable data structures for keys to dictionaries. Immutability introduces a new way of approaching a program. One thinks about methods as things that take input and return output and will always return the same output given the same input. In Ruby, String is mutable and there have been many a bug in my programs because some other method changed the value of a String out from under me.

Pattern matching provides a powerful way to use declarative syntax to express business logic. I'm include an example in the idomatic section of intercepting an incoming HTTP request using pattern matching.

Scala has a very powerful type system including a type inferencer. What that means is that you can define very powerful rules (e.g, when building a query, you can only pass a String into a column that is a VARCHAR) in the library, but the end-user gets the syntactic simplicity of Ruby.

Scala supports lazy evaluation at the language level and in the libraries. This means that only elements that are actually accessed are computed.

Functional languages teach us how to think in terms of transformation rather than getting/setting. Functional programming focuses the developer's eyes and mind on the business logic rather than the boilerplate of flow of control. Functional programming gives us different kinds of abstractions to compose than objects. Composing functions and performing operations on collections just as easily as performing operations on single items changes the focus of development to logic rather than mechanisms.

What makes Scala the right FP language for people to pick up?

David Scala along with OCaml and F# are the "practical" functional languages. You can get things done out of the gate with any of these languages. You don't have to learn a lot of theory to get things done with Scala, OCaml or F#. With these languages, you can dip your toe in the functional waters without having to take an immediate plunge. Neither of these things is true of Haskell or Erlang.

Scala and F# have the Java and CLR libraries immediately available which is a killer reason to choose either of these languages.

Scala has better OO abstractions than does F# or any other language. Scala seems to have integrated OO and a Type System in a way that no other language has.

Why is your book the right one for people to pick up and learn about Scala?

David I take a very simple approach to Scala. There's very little theory and a whole lot of simple examples and idioms. I've tried to make sure that the code is oriented toward practical users of Java as well as practical users of Ruby. The chapters are short and to the point. More of the code examples can be typed into the REPL (like irb) so the reader can get immediate feedback on the example and the language as a whole.

Why is the JVM a good platform for Scala and FP?

David:

It just works

It's very, very fast

Excellent integration with existing Java libraries

The ability to intermix Java and Scala (and Groovy and JRuby) in a single project

The JVM is everywhere and it's well tuned everywhere

What kinds of problems are a good fit for Scala?

David Heh... everything from simple scripting on up to extremely complex systems. With the exception of Erlang's distributed capabilities and C's native device capabilities, I think that every other problem is well solved with Scala. But, I'm biased. :-)

Design patterns and algorithms look differently when implemented in different languages. Can you give us some examples of elegant patterns or algorithms in Scala?

David A BDD Test:

object BoxSpec extends Specification {
"A Box" can {
"be created from a Option. It is Empty if the option is None" in {
Box(None) mustBe Empty
}
"be created from a Option. It is Full(x) if the option is Some(x)" in {
Box(Some(1)) must_== Full(1)
}

One more very nice piece of code... find all the classes used by <p&gt tags in an HTML document:

for {p

What tricks or tools do you suggest someone beginning to read Scala use?

David Don't just read, but use. Open the Scala REPL and start typing. Start playing. Start exploring. Try to understand the actual thing that happens when certain constructs are used. In this way, it's 100% the same as a newbie exploring Ruby. Type a line... see what happens... type another... see what happens. Touch, feel, play.

When he couldn't get the performance he was looking for with Revactor, he started working on a new Ruby inspired language on the Erlang VM — Reia. Tony was kind enough to sit down and spend some time with me doing an interview about his new project.

Besides yourself, who's using or working on Reia?

Tony A number of people have made minor contributions. One of the main people involved is Phil Pirozhkov, who is working on a web framework for Reia called Ryan.

Tony Anyone interested in using dynamic languages to develop web or other network services, particularly people with a background in object oriented languages but not a lot of background in functional languages.

Other than web and network programming, what problem domains do you think Reia will do well in?

Tony Most of the areas I think it will stand out will be subsets of web or network programming, but perhaps I can go into some of those more specifically.

I think Reia will be good at the sorts of interfacing and automation tasks that Ruby has become incredibly successful at, but will carry with it all the distributed computing power offered by the Erlang/OTP framework. In that regard I think Reia will do well at automating tasks on distributed systems, particularly in regard to handling failures.

Cloud computing services offer a great platform for building distributed systems for automating tasks. I think Reia will do quite well there. It's the same problem domain that EngineYard is trying to address with Vertebra, but with Reia I hope the solution offered can be accomplished using one language rather than two (Erlang and Ruby in the case of Vertebra). I also expect Reia could work quite well in conjunction with the Erlangy parts of Vertebra.

I also think Reia could work quite well as a language for Erlang testing as it has full access to the Erlang runtime and excellent Erlang interfacing. I have strong hopes of seeing a tool like RSpec implemented in Reia and being able to use it for Erlang testing. RSpec has seen great success in the Ruby community and I hope I can bring it to the Erlang world.

Tony No, and for that reason Reia also has processes and the full power of Erlang's actor model exposed at the language level.

Objects are there for cases that can be solved primarily with RPCs.

What about the FP claims that idempotency and freedom from side effects are the high road to concurrency?

Tony While Reia has a number of side effects not present in Erlang, great care is taken to localize side effects. All operations with side effects use copy on update semantics, and side effects are actually manifest in the form of destructive rebinding (which is in turn compiled to a pure functional form with single assignment). In most cases the side effects are completely localized to the function they occur in.

What is typing like in Reia — Static or Dynamic, Strong or Weak? Why?

Tony Reia has strong dynamic typing. This is largely inherited from Erlang which also has strong dynamic typing, although Reia does add automatic type coercion in a few places (e.g. interpolated strings)

I'm a fan of dynamic languages in general and this is one of the characteristics which drew me to Erlang in the first place. I find dynamic typing less obtrusive than static typing and believe it helps programmers develop more quickly.

How are you managing the differences between types in Reia and the Erlang VM?

Tony Reia's built-in types which do not have direct Erlang equivalents, such as strings and regexes, are represented internally as tagged tuples. Reia tuples are also tagged to distinguish them from the other types.

Calling out to Reia from Erlang is done through a "reia" module which automatically converts types which have direct equivalents, however types which can't be natively represented in Erlang such as regexes and tuples are left untouched.

Reia has first class syntax for calling out to Erlang which also automatically handles type conversions.

Tony Problems which are intrinsically tied to a central shared state are difficult to address in Erlang (and by virtue of that, Reia as well), because Erlang bends over backwards to avoid shared state. There are tools like ETS and Mnesia to model shared state, but solutions offered in Erlang are generally going to be much slower than solutions which can concurrently operate on the same state with tools like STM.

It would be difficult to add Erlang-style fault tolerance to a system which uses STM (and for that reason it would be difficult to add STM to Erlang). Erlang isolates state per process, so when errors occur the process can simply crash and get restarted in a clean state by its supervisor. With STM unless you're able to completely blow away the shared state and start over in the event of a fault, you're left with trying to handle the error and roll back to a clean state, which is a far more difficult problem than Erlang's "just crash and start over clean" approach to fault tolerance.

Problems with a strong sense of time and a need for global synchronization are probably ill-suited for Erlang/Reia and better addressed by a dataflow language. Erlang/Reia are inherently asynchronous and designed with a work-at-your-own-pace approach in mind, using mailboxes to synchronize execution. If you want all processes to work in sync with a global clock your best bet would be to look elsewhere.

Numerical computing is another area where Erlang is somewhat weak, although Erlang/HiPE actually does significantly better at this than many other languages, like Perl, PHP, Python, or Ruby. As I intend to add various degrees of operator overloading to Reia it is only going to get worse in this regard.

All that said, the core Erlang developers are largely focused on making the existing model work better and not particularly willing to try to incorporate other concurrency paradigms like STM into the language. I'm quite happy they're doing that and are focused on the problem of improving this like the SMP scheduler. However, I'm much more open to experimenting with other approaches to concurrency in Reia. I would love to see a hybrid STM/actor system and may eventually try to pursue that with Reia.

What resources (books, blog posts, papers, etc.) are you looking at as you design/build Reia?

Tony Other people have been my biggest resource. I'm constantly soliciting feedback on IRC, mailing lists, and elsewhere. Some of the best feedback I've received has come from big names in the Erlang community like Joe Armstrong, Ulf Wiger (@uwiger), and Robert Virding (@rvirding).

This is a particulary interesting set of questions I went through and tried to make sure I had decent answers for. I've thought about trying to put together a blog post answering some of the questions from the lightweight languages list.

If someone wants to get involved with Reia development, where should they start?

Tony Signing up for the Google group and asking that same question would be a great place to start.

Three areas where contribution from outside developers would be most welcome are: testing, built-in types, and the standard library. All of these are largely self-hosted in Reia. Just writing simple tests for presently untested parts of the language would be immensely helpful. In addition, the built-in types still lack a lot of the functionality present in Ruby and Python. Dive in, look for a feature from your favorite language which seems to be missing, and add it.

Most people don't try to develop 'the one true language'. What are your goals with Reia? How will you know if you've succeeded?

Tony Reia is certainly intended to be a niche language. If there's one area I'd like to see it succeed in it would be web application development, particularly for cloud computing applications. While I think Erlang's process model should make it immensely successful in the area of rendering web pages glued together from a variety of backend services (e.g. memcache, db, search index, queues) Erlang has struggled to succeed in this area. A number of frameworks are available but none of them have gained widespread adoption. I don't think anyone sees Erlang as becoming a language recognized for web development any time in the near future.

If a web framework for Reia were to become as popular as Rails I'd certainly regard that as a success :)

This book has been a long time coming, how does it feel to see it finally hitting the book shelves?

Jeremy I don't think I can explain the feeling. I imagine it's similar to having a child, except mine is made of paper. So...awkward.

If you had a chance to start it today, what are the big things you'd want to address?

Jeremy I'd definitely want to look a little more at JRuby. It's risen up to be a serious force in enterprise development. But then again, it's a bit of a different beast, so perhaps it's left better to its own books.

What would you drop?

Jeremy I don't know that I'd drop anything. I feel like we've covered a lot of good ground, but if I could drop anything, it would probably be the Rails chapter. It's a good chapter with some good techniques, but there's no saying it won't be out of date by the time it hits the shelves.

What's the most exciting thing happening in Ruby and it's community today?

Jeremy Man, I'll say it again: Adhearsion. I don't think a lot of people have given it a serious look yet, but once you do, you'll see how awesome it is. I'd also say Rhodes could be a really cool thing (but I haven't had a chance to use it yet so I won't declare it awesome just yet :)).

What's next for you?

Jeremy I'm going to keep writing. My next project will be updating the Humble Little Ruby Book for 1.9 to be published on No Starch. I'm also writing some commercial software, more open source, and who knows what else?

Other than the fact that you're both great guys, why should Rubyists run out and shell out their hard earned money for this book?

Jeremy There has been a big knowledge gap for people who aren't in "Ruby jobs." They learn the language, they get excited, they dig what they're seeing, but they reach a point where they feel helpless. They don't really know what they can do with Ruby, how to do it, or if they figure it out, if they're doing it right. I think Ruby in Practice is a really solid collection of information that solves that problem, and I'm really happy to fill that gap.

Assaf got his answers back to me first, and I liked them so much I decided to post them as a stand alone interview. Look for Jeremy's responses soon. Until then, enjoy Assaf's!

This book has been a long time coming, how does it feel to see it finally hitting the book shelves?

Assaf Like sitting down for a cup of water after a long run.

If you had a chance to start it today, what are the big things you'd want to address?

Assaf Talk more about BDD. I liked RSpec since I first started using it, but the latest releases are such a leap in making specs easier to write and maintain. That and Cucumber which I'm now getting into. It works at a higher level, describing scenarios or features, and it means that you can drive tests directly from the design, and have that design be part of the source code, not in a separate unmaintained file.

Background processing is something I missed when I first got into Ruby. With Java I had more options for queuing, scheduling and batching. That changed and now when I'm evaluating for a new project I'm working on and there are a lot of good options to choose from. That would make great material for a chapter in the book.

Ruby recently got a serious kick in the XML pants. First libxml came back from the dead with renewed force, then nokogiri showing up from nowhere, hpricot made huge strides. I know people who look at Ruby before, looked at REXML, and decided to go elsewhere. It's time to reconsider Ruby.

I really like where ActiveRecord is going, and I'm always very cautious around ORM because of their tendency to turn relational databases into dumb object stores. I'm using relational databases because they're relational, and I'd rather see the language take on some of these relational aspects. I think Ruby can do interesting things because it's not so OO dogmatic and much more malleable. I use ActiveRecord outside Rails a lot, and that shows in the book, where we just use ActiveRecord when we need to use a database in a context other than the database chapter. I think a chapter about advance ActiveRecord techniques would be great.

Not entirely related to Ruby, but I think this will interest a lot of people: the development workflow. We talk about specs and testing and how to use these as starting point to build and refactor code. Git hit the soft spot with Ruby developer, and there are some practices worth talking about. Also the different tools you would use to take code from development through testing, staging and finally production deployment.

Phusion Passenger. We had to wrap up the book before we could cover it.

What would you drop?

Assaf Tough. We tried to cover things that other books don't talk about, so I'll have to take a look at books that just come out before I can answer that, but if there's a good book on the subject, I would drop that subject.

Except for testing/BDD. The RSpec book is coming out soon and I would recommend it, but I would still have a chapter devoted to testing. I think testing should be talked about more often, and take every opportunity to introduce people to BDD as a better way to design and build your application.

What's the most exciting thing happening in Ruby and it's community today?

Assaf For me, Rails 2.3, which is coming out soon. For the apps I'm working on, 2.3 is a major step forward in smoothing out the rough bumps of previous releases. I'm continually amazed by the things that are happening around Rails. By intentionally not solving all the world's problems, it's leading to an amazing eco-systems of adds and plugins. My latest favorite is Scrooge which inspects your queries and what you do with the results, builds a profile out of that and uses it to optimize your code.

Testing. Manual testing sucks the life out of me, so do bad test frameworks. I love what you can do with Ruby, and even the prospect of using Ruby code to test Java applications. I mentioned RSpec and Cucumber, there's also Should and Webrat, and just a lot of continuous improvement that keep making my life easier.

Ruby 1.9. Faster, better, but not entirely backwards compatible, so that's still work in progress waiting for all the libraries to catch up.

Github. It's a fabulous service that puts all others to shame. It's a social network built around sharing code, and a great tool when working in teams, open source or not. It's also an amazing resource. Sourceforge and even more modern services like Google Code force you to make multiple mouse clicks before you can see the first line of code. Github puts it right there in front of you on the welcome page. It's telling you "come, look at the code, learn from the knowledge of others".

What's next for you?

Assaf Two projects I'm currently involved with which are taking Ruby in interesting directions.

The first is Singleshot, it's a task manager, of if you prefer the workflow term, a worklist manager. It gives you a task list that you can manage, allows you to delegate, and also allows various applications to delegate tasks to you. It's classical enterprise technology and we're trying to make something that has usability at its forefront. That and being a test case for a Web API that takes hypermedia seriously.

The other one is Buildr, a build system that we're using for large applications that have a build cycle. So yes, we're using Ruby code to build applications written mostly in languages like Java, Scala and Flex. Ruby is ideal here because you can use it declaratively, at the level of defining what a project is, but also do grunt work like moving files around or calling command line tools. It's the first project that's strictly Ruby going on at Apache.

Other than the fact that you're both great guys, why should Rubyists run out and shell out their hard earned money for this book?

Assaf Because they're lazy. I know a lot of people who come to Ruby with a strong background in Java and the mentality that you need big APIs, big frameworks, dependency injection, XML configuration, scalable failover containers, and a thousand lines of code later you managed to read a list of names from a file and sort them alphabetically.

Complexity kills, so one thing I tried to show in the book is how you can size the complexity of the solution to the complexity of the problem. Maybe, instead of setting up an ESB with connectors on each side an pipeline in the middle, you can write a few lines of Ruby script, get the same job done in 1/10th the time. Even when, and this is one of my favorite examples, the job requires moving XML messages from WebSphere MQ to Salesforce. Ruby will get you there faster and cheaper than big architecture tooling.

I've written a number of reviews and author/editor interviews about Ruby books over the years. Since it can be hard to find them, or to sort out the really good stuff, I thought it would be good to pull them all together into a single place. This should to find the best stuff about the best books. I'm hoping it will make it easy for me to keep this page up to date as well.

I'm sure I missed some, what other posts do you think belong here? What other Ruby books should I be looking at? I'll be keeping an eye on the comments, and will come up with a fun way to reward contributors.

Tuesday, March 03, 2009

This will be the last mini-interview before MWRC 2009. Philippe Hanrigou (@ph7) has been kind enough to answer a few questions on the topic of his presentation — "What The Ruby Craftsman Can Learn From The Smalltalk Master". Read on to get a taste of what Philippe will be covering in just ten more days. Oh, and if you haven't registered yet, there are just 4 more days and about 40 more seats. Don't wait any longer, go register now!

Your talk at last year's MWRC was pretty incredible. How are you going to top it this year?

Philippe Well, first thank you. Every presentation is a new experience, and I believe people will end up quite excited about this one since

The subject should appeal to a wider audience — it touches the core of our craft: software design.

I am standing on the shoulders on giants. In my mind Kent Beck is one of the software grand masters with the most comprehensive, genuine, and inspiring understanding of the software craft. So simply relaying some of his wisdom as it applies to Ruby should be quite incredible in its own way already.

Rubyists seem to spend a lot of time looking up to the Smalltalk masters, why?

Philippe Smalltalkers were writing Object-Oriented software in a dynamic, interpreted duck typed language 20 years ago. It would be amazing if there wasn't something to learn.

It is also quite notable that the Smalltalk community has been incredibly talented, innovative and creative in pushing the software craft to the next level. Most of the best techniques we use today to develop software are rooted in the Smalltalk community: test-driven development, refactoring, design patterns, core object-oriented principles, pair-programming, emphasis on short an efficient feedback cycles, ... just to name a few! So any sensible software developer would look up to the Smalltalk community, whatever programming language or platform he/she is using.

I actually believe that we do not learn enough from the experience, errors and innovations of the programmer generations and communities that preceded ours — even the Ruby community, which is better than most in this regard. Unfortunately the "Not Invented Here" syndrome, does not just apply to our code, it also applies to ours practices. We have a tendency to "rediscover" the same errors and bad practices over an over again. Rails' original take at testing and test data management is a good example in this regard. So looking up to the best software masters is a great and healthy thing!

What other language's practitioners should we be learning from?

Philippe We can learn from countless people, fields and languages. For instance, there is a lot to learn from the LISP community, especially in terms of elegance, meta-programming and its unsurpassed emphasis on "programmable programming language".

Nevertheless, programming is before all, an exercise in communication, creativity and human interaction. So some of the most interesting things to discover are probably to be learned from communities that do not write any software at all: either from communities facing similar challenges (artists, designers) or from communities that have been studying these topics from a different angle (ethnologists, sociologists, historians). Brian Marick gave a wonderful piece of advice on how we could approach this learning experience in one of his recent blog entries:

"It seems to me that I’m not so much someone who’s come up with any great new ideas as someone who’s good at looking at the familiar from an odd perspective. I get that odd perspective from reading odd things, such as sociology of science or literary theory, and asking “Suppose this point of view were true: what would it mean for building software?"

Sometimes, it seems like our interest isn't reciprocated. What can rubyists teach smalltalkers?

Philippe The sad part about Smalltalk is that its most prominent leaders have been programming in Java for the last ten years. The main thing we can teach smalltalkers is a message of hope. Dynamic languages are coming back in the front scene and this will benefit all of us! Thanks to Ruby marketing and promotion, dynamic languages are now perceived as as a competitive advantage not only by programmers, but also by CEOs! Ruby has an impactful story that extends beyond its technical merits and also appeals to decision makers — In great part due to David Heinemeier Hansson's marketing genius and his emphasis on the productivity message, which makes sense to business people too.

I believe smalltalkers could also benefit by keeping an open mind and using Ruby as a way to challenge some aspects of Smalltalk design that they love so much, like radical language symmetry.

New programming languages or platforms have almost no features that, in isolation, are really new. It is a lot more about picking the right set of features and mixing the right blend. This is an art in which Matz is especially talented, and which gives Ruby a feel that appeals to a much broader audience:

Some may say Ruby is a bad rip-off of Lisp or Smalltalk, and I admit that. But it is nicer to ordinary people.

Consequently Ruby and Smalltalk have very different tradeoffs in terms of naturalness versus symmetry, or in terms of beauty versus expressiveness.

To be honest, I do not expect smalltakers to let go of their radical commitment to minimalism and symmetry: it is too much core to their culture and one man's expressive code is another man's nightmare. Nevertheless, there is something to be learned from a different set of tradeoffs and Matz's pragmatic approach to language design. I personally find Ruby even more expressive than Smalltalk, a characteristic I directly attribute to Ruby's decreased emphasis on keeping everything "pure" and symmetrical, as well as reaching a better tension point between functional and object-oriented programming.

What do you think makes MWRC a good place for Rubyists to gather?

Philippe Last year was my first time attending MountainWest RubyConf and I was blown away by the high quality of talks and corridor chats, the organizers' kindness, the flawless program execution, and even more importantly, the conference's strong and engaging human dimension.

So if you are into expanding your mind and knowledge, meeting great people, or passionate debates on Ruby and software, MountainWest RubyConf will blow you mind. Huge kudos to all the MountainWest organizers for making it happen!