Functional programming is experiencing another renaissance and you should understand why.

To see why functional programming may finally be here to stay, you need to understand some history of application programming interfaces (APIs) and the top successful programming languages.

Until computers in the 60s, things were simpler but very specific to each type of machine. Then machine services became abstracted into an operating system (OS) layer. So as long as you were on the same operating system you could port your software between machines; operating systems were the first API. Before portable operating systems, software sold with a specific machine. This is when software could scale into a business.

The advent of portable operating systems created the software market.

Something similar happened with networking with the real rise of the Internet, happening once standards and standard calls for networking services became broadly available and understood. Read about the ISO OSI layer model to see such an abstraction.

Those layers are real and mean something to developers needing to get something done. But the various OSes offer different APIs into their networking services and they do not cleanly reflect the structure of that tidy model. There are exceptions all over the place like a 'ping' which tells you if a machine might be online. Does 'ping' operate at the network layer, the session layer, or the application layer? I asked an expert once to check myself and he got muddled too.

Or consider the Simple Object Access Protocol (SOAP). SOAP operates over http/s, an application layer protocol, which has been repurposed into a transport layer protocol because most firewalls let it through so people can browse the web. This is one of many examples of exceptions to the leaky abstractions that populate our APIs.

Developers need a sythesis of OS and cloud APIs.

The first company that does this will quickly gain developers. But they have to be totally ruthless about hewing to their clear synthesis, and selfless about opening their standard. Meanwhile, projects have to be delivered and developers need something to patch that "hole" in their software right now.

It is a pity academics are not more practically grounded because this synthesis needs their independence and rigor. More on this at the end.

Programming languages are the tool developers use to access computer and cloud APIs. The future of APIs and programming languages are intertwined as a result.

If there is anything more controversial than your API, it is your programming language.

Every developer has a personal list of essential general-purpose programming languages. This list changes with increasing experience. Here are my highlights^†:

• C - close to the hardware and runs everywhere but is prone to run-time errors/crashes when used by mere mortals.

• Java - reduces the number of crashes due to poor memory management and runs on many machines but is large and very wordy to write. That the Java brand and much else about the language is controlled by Oracle is see as a negative by some.

• C# - like Java in addressing memory-related bugs and originating from a single company but less wordy. Microsoft, the patron, has become a quite good corporate partner.

• Python - eventually beat out Perl because of its readable syntax, scriptability, and C-based compiler allowing it to port and run everywhere C does (everywhere). Python is very readable because part of the language specification requires you indent your code in a defined way for the compiler to accept it (!). The motto of Python is "there's only one right way to do it". That helps with the API problem - except you have to find the tool in the library that lets you do that one right way. Perl had the bigger library but now only has the better library (Perl's library is very good and well-documented). For years Python did not have threading, meaning long tasks would stop the program. There were work-arounds that relied on the operating system and this was a problem for decades, but recently Python has finally added threading.

• Javascript - the language that runs in every web browser. That means every desktop machine and most phones use Javascript to deliver information to users along with HTML, CSS and a server. Servers are starting to use Javascript too (NodeJS and AngularJS) because it means your front-end developers can also code back-end server-side services. This list of 10 problems with Javascript - very inside baseball if you are not a developer), mostly can be understood by the layperson to be saying that Javascript has no core truth but leaks through its abstraction of the machine with lots of surprises even for experienced developers. By the way, Javascript is not related to Java except by name; a marketing trick made two decades ago.

People will bang on about LISP or Scheme because these languages have a core abstraction that everything is a function. But it takes a lot of experience to code in them well and their syntax takes getting used to. I developed for years in both and I was only moderately skilled in the end, because there were not enough mentors from whom to learn.

Around the 1990s and early 2000s there was a fascination with loosely-typed scripting languages because you spent less time fighting compiler errors. But it turned out you spent more time debugging run-time errors. Now compiled languages have seen a resurgence because developers increasingly realize the compiler is helping you avoid errors with less testing (yes it was obvious but you couldn't be heard over the fan-boys).

The next advance may come from increasing familiarity with Hindley-Milner (HM) type systems coupled with immutable values.

Making a functional program's context include HM-typed OS and Cloud APIs increase the likelihood that a programmers misuse is caught at compile-time. Here the work of Thomas Petricek, Dominic Orchard, and Alan Mycroft on coeffects ^‡ seems promising in that it expands the type system to include the "context" in which the program runs.

Hindley-Milner typing allows the compiler to help the developer avoid errors of omission in conditional branches and immutability avoids many program state errors. However, coding in these languages requires considerable developer skill and the documentation is still poor but the community is excellent - a huge plus.

If you want to get something built right now there is no one best answer. I have chosen the .NET platform because it is versatile, broadly supported, has many installed seats offering many potential customers, and seems likely to grow for the rest of my professional life. Also the tools in this ecosystem are expanding to include well-supported free editor called Visual Studio Code and a fully compatible and very flexible functional language in F#.

Most importantly, Microsoft seems willing to to collaborate and leave money on the table for developers to create an ecosystem around their tools.

But the ability to develop a .NET mobile solution has been less clear than desktop, server, or cloud. It seems that .NET's mobile solution, Xamarin Forms will become .NET's preferred cross-platform user-interface solution. This means if you develop a Xamarin Forms mobile product those skills might carry through to the desktop in late-2021 and 2022.

If you feel like being an explorer take a look at Fabulous which uses F# to deliver a mobile or desktop solution:

1. A fan's perspective on Fabulous
2. Some realism, do note the Fabulous pitfalls secton
3. ... and a simple Fabulous example.

It is very up-to-the minute...for industry.

I do not know if Fabulous will be a practical solution, but I think F# has a good shot. Mostly I include Fabulous to help see around corners.

Footnotes
* - The title is borrowed from the H.G. Wells book "The Shape of Things to Come"
† - There are many more programming languages, among them SQL, Smalltalk, Ruby, Erlang, OCaml, FORTRAN, Clojure, Objective-C, Eiffel, Ada, Prolog, with important attributes and roles.
‡ - The Univeristy of Kent archive also has a copy of this paper on coeffects.