We will discuss language selection approaches in the Language selection section but beyond that decision is the pivotal question of where to first trial a functional language within your organisation.
As a general rule, start small. Starting small helps minimize the risk of the adoption. Starting small usually means working on a small piece of software or a small part of a larger piece of software. For many organisations, this is easier said than done. Although there are prevailing trends towards building large solutions as a collection of smaller independent services, many solutions are still built and deployed from a single monolithic codebase. Typically this codebase is written in a single language and executed by a single homogenous process. In this type of environment, choosing to adopt a new language for a piece of the solution presents these choices:
- Extract some existing functionality into a separate module and re-implement it in the new language. In this context “separate module” needs to be independent from the main codebase at least in terms of development language. On the JVM, a Clojure or Scala module can be developed independently and then deployed as part of the larger single application if needed. In practice, building this new module as a separately deployable service will provide additional benefits to your architecture.
- Create a separate module for a new piece of functionality and implement it in the new language. This is applying the above thinking to new functionality rather than existing logic.
- Look for an area of non-production code where adoption experiments can be carried out in an isolated manner. Developer or tester tooling or in-house monitoring tools are all potential places where new languages can be applied.
Not surprisingly, greenfield development provides the most opportunities to choose new languages for all or part of the solution. In the case of a recent experience we had with a client in the US (http://bit.ly/1fYwbZQ), Clojure was used to build a custom CMS forming part of a larger solution.
Irrespective of whether you have a driving need or desire to adopt functional languages within your organisation, making the changes necessary to allow this sort of adoption is beneficial for other reasons, best expressed by this quote: “The recurring theme is ‘the right tool for the job’ … the most important lessons in our experience are how to lower the barriers to choosing the right tool” (http://bit.ly/NsF0iR)
Most experienced IT people admit (sometimes reluctantly) that choice of technology has a relatively low level of influence on the success or failure of a project or product. These people do generally agree that focusing on softer issues like team capability, culture, customer involvement and effective project management are far more likely to influence the outcome. However, there is a very important connection between programming language choice and these key success factors.
Organisations strive to build teams that harness the latent power of technology to provide innovative solutions to their customers. Building these teams requires people with a strong passion in technology and desire to work in productive environments. Harnessing the surge in interest in functional programming can help position your organisation as a destination employer for these types of developer. This will provide short-term benefits through the application of functional programming as well as longer-term advantages of building highly competent development teams.
Indeed, a growing number of developers are investing more and more of their own time in learning and honing their functional skills. These developers see the benefits in this style of development and appreciate how better tools help them serve their employers.
This is the same type of thinking that led to some developers seeing the benefit of a simple, new C-like language without the overhead of explicit memory management in the mid-late 1990s. This was the first wave of developer to adopt Java.
This is the same type of thinking that led to some developers seeing the benefit dynamic languages brought in terms of expressiveness and development speed over their statically typed cousins and surfed the Ruby/Ruby on Rails wave from the mid 2000s.
This is the same type of thinking that will lead to some developers becoming early adopters of the next waves of software development languages and approaches in the years to come.
These types of developer keep a keen eye on what is evolving on the horizon of their industry. They spend considerable (personal) time researching the topics that interest them. They are likely to be well connected into a network of similarly minded people, either through community user groups or common employers. They often move in groups from destination employer to destination employer as they spot environments that value their presence. They are likely to be energetic contributors to open source software and/or have active GitHub accounts.
In short, these types of developer are highly sought after hires for an employer. It is true that there will be a smaller pool to choose from than for Java or C# developers, but the quality of developer will be much higher.
If your development group is keen to trial functional programming, there are two broad approaches they can take in the selection of the language. These choices are similar to popular models for spoken language learning in use the world over.
Approach A: Dipping your toes in
Approach B: Immersion
|For an existing enterprise development group, an obvious decision might be to stay aligned with the language platform you are currently using and pick a functional language which fits neatly into that platform (e.g., Scala for a Java shop, F# for a Microsoft shop).
There can be downsides to this approach with Scala as it’s very easy for experienced Java developers to continue writing Java code with the occasional Scala idiom for good measure. The easy blend between core Java syntax and Scala’s myriad extensions can actually increase the difficulty in unlearning many of the lessons of an imperative object-oriented background and fully embrace functional thinking.
|In this world, you deliberately choose a language that is syntactically separate from any the current development team has used. The alien syntax is a constant reminder that the mental approach needed for this language is different. Examples of languages that could be used in this case include any of the LISP variants (with Clojure being a good choice for Java environments), Haskell or Erlang.|
Each approach has its own merits. Approach A will provide the most immediate benefit in terms of adoption with a longer-term risk that the full power of a functional approach may never be reached because of the ever-present temptation to fall back on old habits. Approach B will include a steeper initial learning curve but should result in developers that have a clearer and deeper understanding of functional programming.
When adopting a new language, it also makes sense to think about how the adoption should be evaluated.
An excellent presentation discussing the issues surrounding language choice is “Nobody Ever Got Fired for Picking Java” (http://bit.ly/OAkv4O) by Alex Payne and he spends a lot of time discussing the difficulty in choosing objective criteria on which to fairly evaluate a number of potential languages. Alex concludes by recommending using a weighted decision matrix to capture the criteria used for the evaluation.
In 2013, ThoughtWorks used a number of criteria to help with language selection with an Australian-based client in the wealth management industry (see http://bit.ly/1gz2c66 for a presentation on this evaluation). The team spent three weeks doing cross-evaluation of Java, Scala and Clojure, taking regular measurements of the three languages using a combination of objective and subjective criteria. See below for a set of graphs showing one of the objective criteria being measured; the amount of time spent in minutes (y-axis) between production code, test code, tool management and library management per day (x-axis).
The team also used weightings to balance out seven criteria between short-term (i.e., project) and long-term horizons. These criteria appear on the left hand side of the tables below. On the right hand side are subjective evaluations by the team members on how well they thought Clojure (the selected language) would satisfy each of those criteria. Note that the “Ease of maintenance” scores were based on a “throw it over the wall” support model – the team decided to mitigate this risk by rotating the support developers through the development team on a regular basis.
This approach is by no means the definitive way to evaluate language selection, but it does highlight some areas you may want to consider. Using weighted criteria during evaluation will also help people involved in the evaluation decide on the critical aspects of the experiment.