Survivors' Breakfast
The
previous post covered some thoughts on the future-looking programming themes present at OSCON 2014.
Following that wonderful conference, long-time Open Source advocate, Pythonista, and instructor
Steve Holden, was kind enough to host his third annual "OSCON Survivors' Breakfast" with tens of esteemed attendees, speakers, and organizers enjoying great company and conversation, relaxing together after the flurry of conference activity, planning a leisurely day in Portland, and -- most immediately -- having some much-needed breakfast.
The view from the 23rd floor was quite an eyeful, and the conversation ranged across equally panoramic topics. Sitting with
Alex Martelli,
Anna Ravenscroft, and
Katie Miller, the conversation inevitably turned to thoughts programmatical. One thread of the discussion was so compelling that it helped crystallize this series of blog posts. That was kicked off with Katie's question:
Why [have some large companies] not embraced functional programming to the extent that other large ones have?
Multiple points of discussion spawned from this, some of which still continue. The rest of this post explores these.
Large Companies?
What constitutes a large company? We settled on discussing Fortune 500 companies, which, by definition are:
- U.S. Companies
- Ranked by gross revenue (after adjustments for excise taxes).
Afterwards, I looked up the 2013 top
25 tech companies in the Fortune 500. I've listed them below; in parentheses is the Fortune 500 ranking. After the dash are the functional programming languages used on various company projects -- these are listed only if I have talked to someone who has worked on a project (or interviewed for a job that used the language), or if I have read an article by an employee who has stated that they use the listed language(s)
[1].
- Apple (6) - Swift, Clojure, Scala
- AT&T (11) - Haskell
- HP (15) - F#, Scala
- Verizon Communications (16) - Scala
- IBM (20) - Scala
- Microsoft (35) - F#, F*
- Comcast (46) - Scala
- Amazon (49) - Haskell, Scala, Erlang
- Dell (51) - Erlang, Scala
- Intel (54) - Haskell, SML, PLT Scheme
- Google (55) - Haskell [2]
- Cisco (60) - Scala
- Ingram Micro (76) - ?
- Oracle (80) - Scala
- Avnet (117) - ?
- Tech Data (119) - ?
- Emerson Electric (123) - ?
- Xerox (131) - Scala
- EMC (133) - Scala
- Arrow Electronics (141) - ?
- Century Link (150) - ?
- Computer Sciences Corp. (176) - ?
- eBay (196) - Scala
- TI (218) - ?
- Western Digital (222) - ?
The companies which have committed to projects guessed to be of significant business value written in FP languages include: Apple, HP, and eBay. Possibly also Oracle and Intel. So, a rough estimate of between 3 to 5 of the top 25 U.S. tech companies have made a significant investment in FP.
Why not Google?
The next two sections offer summaries of some views on this.
Ideal Use Case?
Is an FP language suitable for large organisations? Are smaller companies better served by them? During breakfast, It was postulated that dealing with such things as immutable data, handling I/O in pure FP languages, and creating/using higher order functions is easier for small startups due to the shorter amount of time required to hire or train a critical mass of skilled programmers.
It is certainly true that it will take larger organisations longer to train its personnel simply due to sheer numbers and, even with enough trainers, logistics. But this argument can be made for any corporate level of instruction; in my book, this cancels out on both sides and is not an argument unique to hard topics, even less, specifically pertinent to FP adoption.
Brain Fit?
I've heard this one a bit: "Some people just don't think in FP terms." They need loops and iteration, not higher order functions and recursion. Joel Spolsky makes reference to this in his article
The Guerrilla Guide to Interviewing. In particular, he says that "For some reason most people seem to be born without the part of the brain that understands pointers." This has been applied to topics in FP as well as C.
To be fair, Joel's comment was probably made with a bit of lightness and not meant to be a statement on the nature of mind or a theory of cognition. The context of the article is a very practical one: hiring. When trying to identify whether a programmer would be an asset for your team, you're not living in the space of cognitive theory, rather you inhabit the realm of quick approximations, gut instincts, and fast, economical decisions.
Regardless, I find this perspective -- Type Physicalism
[3] -- fairly objectionable. This is because I see it as a kind of intellectual "racism." Early social sciences utilized this form of reasoning to justify all sorts of discriminatory thinking in the name of "science", reinforcing a rigid mentality of "us" vs. "them." In my own experience, I've seen this sort of approach used to shutdown exploration, to enforce elitism, and dismiss ideas that threaten the authority of the status quo.
Rather than seeing the problem of comprehending FP as a physical limitation of the individual, I see instructional failure as the obstacle to overcome. If we start with the
proposition that certain brains are deficient, we are essentially
abandoning education. It is the responsibility of the instructor to engage creatively with each student's learning style. When adhering to the idea that certain brains are limited, one discards creative engagement; one doesn't even consider working with the students and their learning styles. This is a view that, however implicitly, can be used to shun diversity and dismiss potential.
I believe the essence of what Joel was shooting for can be approached in a much kinder fashion (adapted for an FP discussion):
None of us was born knowing GOTO statements, global state, mutable data, or for loops. There are many programmers alive, though, whose first contact with programming involved one or more of these. That's their "home town", as it were; their programmatic birth place. Having utilized -- as well as taught -- imperative, OOP, and functional styles of programming, I do not feel that one is intrinsically any harder than another. However, they are sometimes so vastly different from each other in style or syntax or semantics that once a student has solidified around the concepts of a particular paradigm, it can be a challenge retraining to work easily in another.
Why the Objections?
If both "ideal use case" and "brain fit" are given as arguments against adopting FP (or any other new paradigm) in large organisations, and neither are considered logically or philosophically valid, what's at the root of the resistance?
It is not uncommon for changes in an industry or field of study to be met with resistance. The bigger or more different the change from the status quo, very often is proportional to the amount of resistance. I suspect that this is really what we're seeing when companies take a stance against FP. There are very often valid business concerns: "we've made an investment in OOP" or "it will cost too much to train/hire/migrate to FP."
I would remind those company leaders, though, that new sources of revenue, that product innovation and changes in market adoption do not often come from maintaining or enforcing the current state. Instead, that is an identifying characteristic of companies whose relevance is fading.
Even if your company has market dominance or is a monopoly, there is still a good incentive for exploring alternative paradigms. At the very least, one can uncover inefficiencies and apply new knowledge to remove duplication of efforts, increase margins, etc.
Careers
As a manager, I have found that about half of the senior engineers up for promotion have very little to no interest in taking on different (new to them) programmatic paradigms. They consider current burdens sufficient (or too much) and would rather spend what little free time they have available to them in improving existing systems.
Senior engineers who have a more academic or research bent (or are easily bored) are much more likely to embrace this sort of change. Interestingly, senior engineers who have little to no competitive drive will more readily pick up something new if the need arises. This may be due to such things as not perceiving accumulated knowledge as territory to defend, for example.
Younger engineers with less experience (and less of an investment made in a particular school of thought) are much more willing to take on new challenges. I believe there are many reasons for this, one of which may include an interest in becoming more professionally competitive with their peers.
Junior or senior, I have found that programmers who are currently looking to find new employment are nearly invariably not only willing to take on the challenge of learning different paradigms, but are usually going about that proactively and engaging in self-study.
I want to work with
programmers who can take on any problem space in any paradigm and find
creative solutions, contributing as valued members of a team. This is
certainly an ideal set of characteristics, but one that I have seen in
the wilds of the workplace on multiple occasions. It has nothing to do
with FP or OOP paradigms, but rather with the people themselves.
Even if a company is locked into well-established processes and views on programming, they may find it in their best interests to provide a more open-minded approach with their employees who would enjoy that. Their retention rates could very well increase dramatically.
Do We Need To?
Philosophy and hiring strategies aside, do we -- as programmers, software projects, or organizations that support programming -- need to take on the burden of learning or adopting functional programming? Quite possibly not.
If Google's plans around Go involve building a new operating system (in the spirit of 1970s C and UNIX), the systems programmers may find pure functions too cumbersome to work with. FP may be too burdensome a fit for that type of work.
If one is not tied to a historical analogy with UNIX, as Mozilla is not with Rust, doing something like creating a new browser engine (or running a remote services company) may be a good fit for FP, especially if one has data showing reduced error counts when using type systems.
As we shall see illustrated in the next post, the usual advice continues to apply: the decision of which paradigm to employ for any given project should be dictated by the best fit and not ideological inflexibility. The bearing this has on programming is innovation: it is the early adopters who have the best chance of leading us into the future.
Footnotes
[1] If anyone has additional information as to which FP languages are used by these top 25 companies, please let me know, and I will include that
information. Bonus points for knowing of business-critical applications.
[2] Google Switzerland are using Haskell.
EOSDIS
