Editorial Radar: Functional languages

The benefits of functional languages and functional language techniques.

Functional Languages are driving a broader set of choices for programmers. O’Reilly editors Mike Loukides and Mike Hendrickson sat down recently to talk about the advantages of functional programming languages and how functional language techniques can be deployed with almost any language. (The full conversation is embedded below.)

Andy Hunt and Dave Thomas have long recommend learning a new language each year, especially those languages that teach new concepts [discussed at the 02:02 mark]. Functional languages have made that easier. They behave in a different way than the languages many of us grew up on — procedural like C or languages derived from C. Plus, the polyglot programming movement has driven the interest in functional languages as one of the languages you might want to learn.

Programmers need to understanding the advantages of using a functional language, such as productivity, power of expressiveness, reliability, stateful objects, concurrency, natural concurrency, modularity, and composability [05:37]. Though a search still exists for a magic bullet [06:29] to make it easier for programers to better solve the problem of concurrency. CPU speeds have been stuck at roughly the same level for the last four to five years. Programmers have been given is more transistors on a chip, hence more CPUs and more cores to work with making concurrency one of the most difficult issues facing computer scientists today. Enter functional programming with improved debugging and the ability to write more reliable code in a concurrent environment.

Additional highlights from this conversation include:

  • Print book sales of functional languages are growing, especially books on R programming. And while Loukides doesn’t consider R to be a functional language, some debate exists about its classification. Though it’s clear the data science movement has driven the use of R because it’s well designed for statistics and dealing with data. [Discussed at the 00:29 mark]
  • We’ll see F# grow in the Microsoft development environment while Scala and Clojure are dominating the open source space. Erlang will also be around for a long time for building highly reliable concurrent systems. [Discussed at the 03:01 mark]
  • Since the publication of Doug Crockford’s JavaScript: The Good Parts, coders have discovered the functional language abilities of JavaScript and Java. Google’s release of Maps and Gmail revolutionized how JavaScript is used. Some of today’s best examples include Node for high-performance websites and D3 for creating exotic and beautiful data visualizations. [Discussed at the 08:15 mark]
  • While JavaScript isn’t a functional language, it’s designed loosely, so it’s easy to use as a functional language. You might also be interested in how functional programming techniques can be used in C++ — a blog post written by John Carmack. [Discussed at the 10:36 mark]
  • Java isn’t intended as a functional language. Though Dean Wampler’s Functional Programming for Java Developers provides an approachable introduction to functional programming for anyone using an object-oriented language. [Discussed at the 11:41 mark]
  • The use of a functional language or functional language techniques can make your code more robust and easier to debug. [Discussed at the 12:09 mark]

You can view the entire conversation in the following video:

Tune in next month for a discussion of NoSQL and web databases.

Fluent Conference: JavaScript & Beyond — Explore the changing worlds of JavaScript & HTML5 at the O’Reilly Fluent Conference (May 29 – 31 in San Francisco, Calif.).

Save 20% on registration with the code RADAR20

Related:

tags: , , , , , , , , , ,

Get the O’Reilly Programming Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • http://www.typhonrt.org/ Mike Leahy

    Nice discussion; I am interested to follow the continued adoption curve of Scala vs Clojure. I’ll also have to pick up the functional Java book and check it out. My Java framework efforts are inspired by a general functional approach that focuses on implicit composition vs the more traditional OO approach of inheritance and explicit composition. This certainly has greatly aided modularization in my efforts and provided flexibility for the general case (dare I say magic bullet!) particularly with game dev / entity systems and providing a middleware runtime that treats for instance the entire Android ecosystem across all API levels in a holistic manner vs “test your app at each API level” which is the general advice / answer one gets from the Android team regarding the Java Android SDK. As a poster mentions in the blog post below the Android SDK is “brutally based on implementation inheritance”. This rings true in an examination of the SDK source and is a main contributor to the rigidity of the Java Android SDK.

    Folks that want a bit more discussion should check out this recent post:
    http://skipoleschris.blogspot.com/2012/04/life-without-objects.html