F# and functional computing languages: Out of the lab and into your business

F# and functional computing languages: Out of the lab and into your business

Summary: Functional languages are here to stay. So are you ready to completely change the way you code?

SHARE:
programming
As the IT world changes, so too do the programming languages we use. Image: Shutterstock

The sands of the IT world are shifting, as the cloud and mobile move from being secondary to the old n-tier+web model that's dominated for much of the last decade. That sea change is shifting the languages and tools we use, away from the C family of languages (such as C++, C#, and Java) to one that descends from more formal languages such as Lisp.

Functional programming languages were, until recently, languages for computer science. Based on a pure mathematical approach to programming, they were the basis of much modern computer science research, with languages such as ML, Haskell, and oCaml. One of the first commercialised functional programming languages was Erlang, developed to reduce the risk of errors in telephone networks. But now they're shifting to the desktop — and, more importantly — to mobile devices, as well as programming cloud hosted PaaS platforms. 

It's important to understand the difference between traditional imperative programming techniques and functional programming. Functional programming is stateless, with mathematical functions at the heart of its operation. A function will always give the same result for the same inputs; it's never dependent on results from another function. That makes it easier to understand how a program will behave, something that's important when you're working with a range of external inputs — especially if you're working with streamed or asynchronous cloud data.

That does mean that programming with functional languages isn't as easy as it is with traditional programming tools, as you'll need to understand some very different concepts. A more mathematical approach to programming means you'll need to rethink some common programming structures and methods, especially where you need to manage state.

Apple's Swift, with its roots in Objective C's Lisp heritage, is helping take functional programming out of the classroom and into the real world. While it's designed to be familiar to C programmers, its programming structures owe much to languages such as OCaml.

It's interesting to see Apple focusing on a functional language as its new programming platform for mobile devices, and even more interesting to see it being wrapped in a way that makes it easier for C-family developers to pick up. Swift isn't a pure functional language, it's more like Clojure, with structures that can handle state directly. However, it does give you many of the features of a functional language, and as such will be easy to learn.

Microsoft too is moving much of its language focus to functional programming, as it builds on the work of the MSR programming group. Part of that work has led to the release — and now the open sourcing — of F#, another language that owes much to ML and OCaml. It's also added functional programming features to its C# language.

As F# is a .Net language, it's not surprising that Xamarin has recently added F# support to its tools in response to strong demand from the financial services industry. But F#, like Swift, is ideal for building the smart endpoints that we need for effective cloud apps. The cloud is a powerful tool for processing large amounts of information, but it needs tools to extract and manage that information effectively — tools that need to work effectively with asynchronous data sources, and that can be trusted to give the correct responses.

There's a lot that's interesting in F#. For one thing, it uses type inference to handle strong-typing when your program is compiled. You don't need to declare a variable type; the first time it's used, it'll be set appropriately — though you can set types for your own reference, making your code easier to read.

One area where languages like F# simplify working with data sent back from cloud services is in how they work with tuples, records and lists. If you're always getting back the same number of results in a call, then you can use a tuple to store the data. Alternatively, if (for example) you're working with a name/value NoSQL source, you can use named records to handle writing and reading data from the source in an easy to understand way.

Where F# really works well for cloud endpoints, especially for apps that are consuming multiple APIs at once, is with its support for asynchronous and parallel programming structures. Asynchronous workflows are easy to construct, giving you the tools to build callbacks that work with data that can be delivered at any time after a request. There's also the option to run several asynchronous blocks of code in parallel (code that can be run on GPUs as well as using the standard Windows threading models).

F# has become a first class language in Visual Studio, and there's support for working with common Windows toolkits and APIs, including .NET classes. This means that you can write Windows Forms aps in F#, as well as working with Microsoft's LINQ in-line data tools. To get a feel for working with F# and functional programming, Microsoft Research runs an online F# interactive tutorial, where you can write code without leaving your browser.

Functional programming is a powerful technology, and one that's finally making its way from the research lab into your favourite IDE. You're probably using apps written using these languages already, as they're running the back ends of many major cloud services, as well as running complex financial systems — and social games. But it's in our pockets that it's going to make a difference, giving developers tools to write reliable, and predictable, code that copes with the complexities of the modern mobile network.

Further reading

Topics: Enterprise Software, Software Development, Web development

Simon Bisson

About Simon Bisson

Simon Bisson is a freelance technology journalist. He specialises in architecture and enterprise IT. He ran one of the UK's first national ISPs and moved to writing around the time of the collapse of the first dotcom boom. He still writes code.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

5 comments
Log in or register to join the discussion
  • Again?

    The functional language revolution hype is starting up yet again? It's as bad as the scripting language hype.
    Buster Friendly
  • Hmm

    I was debating raising the pedantic point about Erlang was first written in Prolog, but that might have been a "so what" point.

    But — quoting — "Apple's Swift, with its roots in Objective C's Lisp..." is off the mark. Objective C is C plus SmallTalk. SmallTalk has some Apple copyrights in its provenance. There is a map-like bit of syntactical sugar in SmallTalk, but Objective-C left it behind.

    As Objective-C was being massaged over the past few years, it received a syntax for elevating functions into first class objects, but then, independently, so did other C-family languages. Objective-C's syntactic sugar for the concept was clunky as is typical with a language designed for one paradigm and then retro-fitted for another. I have no doubt that simplifying the syntax was an early goal for Chris Lattner.

    Clojure is a Lisp. Clojure has lazy evaluation. Swift does not (though I believe there is a lazy keyword to activate lazy evaluation.) I had an Objective-C project to push out, so I haven't gotten very far in the Swift book, still, Rich Hickey's unification of arrays and lists as sequences apparently influenced the Swift designers. Strings are immutable lists of characters, which is a Lisp/Haskell approach also found in Clojure. If one has looked into Clojure, one sees familiar faces in Swift, but it is not like Clojure.

    Was that a moment of clumsy construction or something you believe? Does it matter? I don't know.

    One thing about Swift, the programmer has to pay attention to release/retain deadlocks or they'll leak the first-class functions. This will be a key gotcha for the FP veteran to grok, as we are used to garbage collecting runtimes (F#, Clojure and Scala) or simplified Abstract Syntax Trees (ASTs) from the Lisp family languages.

    While discussing functional languages it must be remembered, i/o is a side effect. (With the same input, the result may differ. For instance, starting a command line read when a plug gets pulled. Output changes the world and that breaks the prime directive for a black box function.) This means every functional language has to have the capacity to do non-functional things.

    State is decidedly non-pure-functional, unless one jumps through hoops by using a fold and passing each recursion or iteration a long tuple with the current object and all possible state bindings. With OOP, as an object is the primary controller of its state as per correct encapsulation, o.f(x) may return different results for the same x, depending on o's internal state.

    Once the discussion turned to F#, the quality of today's post improved markedly.

    At the risk of taking my turn for saying something dim, imperative requires the programmer to have a correct mental model of when things happen in the processor. In today's parallel and distributed world that has gotten difficult. OOP is about templating state. Functional is about templating behavior. No approach solves all problems with minimal work. It is still true, there are no silver bullets.
    DannyO_0x98
  • I hope the author didn't get paid for this drivel

    A brain dead monkey randomly bashing keys could have come up with something better.

    "That sea change is shifting the languages and tools we use"

    No, it's not, but feel free to just MAKE STUFF UP.

    "There's a lot that's interesting in F#. For one thing, it uses type inference to handle strong-typing when your program is compiled."

    Seriously? That's interesting???

    "This means that you can write Windows Forms aps in F#, as well as working with Microsoft's LINQ in-line data tools."

    LINQ in-line data tools??? You might as well admit you're a clueless hack who is just slapping words together.

    Here's a suggestion to ZDNET... If you wish to include articles on programming, hire an actual programmer to write them.
    jackbond
  • Debating the minutiae misses the point

    Good article - with some passionate responses... I can't help feeling some smart commenters have grabbed hold of a subjective technicality and missed the point

    In my 25 year career as a software engineer, advancements in language, API, frameworks, distributed computing, HPC have all been exciting, but they have done nothing to simplify our industry. Yes, they have been valuable, but their advancement has been focussed on our ability to model and execute solutions to problems with more complexity that simplicity

    The PaaS cloud is a great opportunity for us to realise true service encapsulation and abstraction, without the temptation to peel back the covers of that API, framework or Web Service. With well defined cloud services, client side functional languages should help us get to solutions faster and more importantly with greater simplicity. The industry I work in (Capital Markets) is crying out for simplicity, the trends laid out by the author are real in this sector.
    Leon Rees
  • OO was a cul de sac. It's time to move on folks.

    "advancements in language ... have all been exciting, but they have done nothing to simplify our industry"

    The point of functional programming is to simplify applications by making them easier to read, write and test. When I say 'easier' I mean for programmers who get the idioms and conventions of functional programming and know why they need to give up on OO. OO was a cul de sac. It's time to move on folks.
    mark4asp