BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Why Are You Not Using Functional Languages?

by Werner Schuster on Oct 30, 2012 |

Functional programming promises to raise the abstraction of code and to help to escape the micromanaging prevalent in imperative programming. Concepts like Immutability are essential to many functional languages and promise to remove whole classes of bugs (race conditions, etc), improve scalability (locking becomes unnecessary) and bring new capabilities (versioning stores over destructive ones). A recent example is Datomic which was created in Clojure and, as Rich Hickey explains in "Writing Datomic in Clojure", benefits from functional concepts.

But where is functional programming in the industry and particularly the enterprise? Java and other languages still reign in the enterprise. 

What keeps developers, teams and companies from adopting functional languages?

In order to find out, InfoQ would like to hear from you, in particular if you have

  • tried to get your team or company to adopt a functional language but found problems or failed to convince the developers or other decision makers.
  • assessed functional languages but found them wanting.
  • created or taken over a codebase in a functional language but have run into problems (maintenance, scaling, or other)

 

 

 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Its hard to convince OO developers to move to functional by Faisal Waris

There are pockets of FP (mainly LISP and F#).

I am finding that people are not ready to move out of the 'comfort zone' of Java and C#, in droves. After several internal presentations, demos and papers, I can see that there is definite interest but very little actual movement.

Most apps are still very traditional enterprise, Web 1.0 variety so there is no great incentive.

With our first few cloud apps, I have started to see an inkling of interest in FP mainly because of better asychronous support (Actors, Agents, etc.).

Re: Its hard to convince OO developers to move to functional by Paul Umbers

I would agree with this. There is certainly a lot of interest from my colleagues and clients in functional languages, primarily Scala & Clojure, and new concepts such as Actors, but these languages, tools & techniques are well outside most people's comfort zone and so the risk vs reward ratio is seen as too high when budgets & deadlines are part of the project plan.

Some things help, such as the ability to use Play & Akka from Java as well as Scala - this means the frameworks & architecture can be used with a familiar language, making the leap not quite so big. Clojure/Ring/Compojure are just too different for most people in a work context, and it takes a manager with guts to approve their use in a project with any significant budget.

For the moment, guerilla tactics are needed to get developers familiar with working functionally without risk. Small projects, non-crtitical software.

Missing choice by Mark N

Where do i click "I don't need it/haven't needed it yet" ?

Re: Missing choice by Joshua Ewer

I would have clicked on "a critical mass of teammates don't think they need it and refuse to allow themselves to be convinced otherwise."

Re: Missing choice by Serge Bureau

Your comment is like a blind talking about color.

But I certainly agree with you that many would take that choice, it is embarassing for the software industry.

I am taking the class from Martin Odersky and it is quite an eye opener.
And I like Scala because while it gives me functional facilities it also keeps the object side and much better than all other object oriented language.

Re: Its hard to convince OO developers to move to functional by bruce b

Learning FP is very difficult, in my opinion. I'm in the "Functional Programming with Scala" course from Coursera, and I have never agonized more over solving one liner code problems before. Wrapping your head around immutable data structures is tough. Granted, this class is doing nearly pure FP with no mutable state, whereas mixing in functional techniques is not as difficult to grasp, in languages that support lambdas or closures.

My concern is that many OO programmers will start using FP techniques without really understanding the fundamentals, and the only benefit might be a reduction of some boiler plate imperative code. My experience has been that if you don't deeply understand recursion, higher order functions, currying, etc, you'll hit a wall of confusion pretty quickly. And I'm not saying this as some FP purist who thinks Java developers are idiots, but as a typical Java developer trying to move past limitations of imperative OO style programming.

User of a cross-paradigm language (Scala) in a heavily functional style by Kris Nuttycombe

Hi, all,

My company, precog.com uses Scala extensively, in a heavily functional style (liberal use of scalaz, etc.) and so while I certainly don't fall into the "not yet using FP" camp, I can speak to a degree with respect to challenges that companies can expect in adopting a functional style of programming and/or a functional language.

In short, our experience has been that *new* developers (for example, a mathematician we hired with very little programming experience in general) have no difficulty at all in adopting functional programming idioms, whereas those who come from a strongly mutation-oriented programming background tend to struggle with understanding the utility of the novel abstractions that FP exposes in the context of their existing knowledge. Basically, programmers who have grown up around mutation-oriented approaches have an idea of how to solve problems, and can't readily see the potential errors that those approaches introduce because they've learned to automatically sidestep them, so the possibility of excluding those errors at the type level (I'm biased towards strongly-typed FP) doesn't initially seem to provide much value. This ability to sidestep breaks down when you've got a number of people working on the same codebase, though; mutation-oriented APIs require that you call them in a certain order, which must be documented extensively and require the documentation to be carefully observed. Functional programming lowers this burden, because your APIs tend to exclude the possibility of using them in "the wrong way." It does this, however, at the cost of learning some new abstractions, and for some this learning is difficult because you can no longer think in terms of the traditional nouns and verbs; instead FP requires lots of thinking in terms of layered abstractions that are frankly hard to describe in English (or, indeed, most natural languages.)

Kris

Inertia by Charles McKnight

The biggest problem to date seems to be existing investment in legacy systems, languages, etc. Having made the investment in learning a particular system, most enterprise developers seem reluctant to learn/do anything that moves them outside of that comfort zone.

Bureaucratic view of software development by Luc Prefontaine

I recently had an interview with a big corporation. I have a few years behind me of
Clojure with a product deployed in production since 2009. I have around 30 years
of dev and production support behind me.

The person I was talking with his the chief technologist. I got a couple of comments
from him that supports the opinion I have about corporations and the job market.

A) we want to hire "formatted" resources
B) not everyone can learn a functional language
C) incremental improvements can be done without changing anything
technology wise

I was not dealing with an HR person here, the guy is suppose to give directions
about technology.

Yet it was obvious that he did not even look at the gains of using a dynamic and
more expressive language to speed up things. He was just waiting in hope that
some minute changes would change the horizon.

It was out of the question to switch the entire shop away from its current environment,
I was pushing the idea of improving tooling to increase productivity not turning the
shop away from what it was using already.

He was clearly against it. He was in favor of status quo, even looking at it innovative
tools was forbidden. Possibly the idea made him uneasy, I suspect he feared to
be left behind (remark B).

Most of the reasons invoked in this survey are excuses, not real reasons to avoid
functional languages.

HR managed to make software creation a bureaucratic process in
corporations. This mentality is now even prevalent in the mind of
people managing software development.

Creation involves creativity and HR people have always been uneasy with creative
people. Hence all the job slots these days. Neurology tells us that our brain can
still adapt even at an advanced age. HR as made the IT world believe that if
you learn one technology then you cannot learn anything else without
calling it a career transition that has to be prepared years before it happens..

Bureaucracy killed improvement and innovation in software, the only hope
remaining is in startups and a few big corporations that learned how to deal
with creativity.

Non sense, this field is dying by the lack of adoption of innovative
solutions. We will have to wait two generations at least before we can make
any progress. Presently the field is crippled by narrow minded management
and urban legends.

Luc P

Re: Its hard to convince OO developers to move to functional by Faisal Waris

It was the same when we were all moving to OO.

I started with Smalltalk. It was considered too offbeat for COBOL and C programmers. Finally, with Java (and curly braces) and the development of C++ and C#, OO became accepted as the mainstream paradigm.

For FP (as it was for OO) there is unlearning/relearning involved and it requires investment and effort.

There is a payoff for all that investment. Using FP, the code I write is much shorter, more readable and more declarative (less chances of making mistakes). I believe that hybrid Functional-OO langauges (Scala, F#, Closure, etc.) will slowly take hold, especially as we move to more asychronous programming styles and cloud computing.

Java has fallen *way* behind and its too late to make it right. C# on the other hand has kept up - with lambdas, LINQ and async, etc.

Re: Its hard to convince OO developers to move to functional by Luc Prefontaine

The prototype of our product was entirely in Java with all the usual companions to help the crippled to walk
(Spring, Hibernate, ...). The first production version used some Clojure in it because of time constraints.
We also saw potential concurrency benefits in the next couple of years.

Last year, I was fed up about our legacy code. We had to patch some of the generated
code (Hibernate mappings, ...), XML was crippling our efficiency, we had a better understanding of the
business and we attempted to extend some stuff done in Java
but it would have required an army of people to implement and support.

I created a road path and now I am an expert at dragon slaying.

In our next release near Xmas, the product core will have shrunk
from around 275000 loc to around 18000. Exit Spring, Hibernate, Terracotta ...
We removed all java mutable code but use a slew of external Java libraries.
A quarter of the new code are definitions made with a DSL of our own.

In our case code generated by wizards proved to be toxic. It was buggy in many instances.

We now realize that our new model implemented in software cannot be done in Java.
It's more scalable, it's dynamic (we can load plugins on the fly based on configuration changes),
it's easier to maintain, extend and much more easier to test.

I was even willing to drill in our code base with the architect I mentionned in my previous post.
Not even interested to look at it.

I worked in Java since 2001. The above experiment should be useful to others assuming that they maintain
an open mind and are willing to sweat a bit.

The greatest challenge I met (I already knew Lisp) was immutability. Lazyness was the second one, especially
while debugging. We are so polluted with right-left assignments, it's hard to believe that you rarely need
mutation in your code.

Luc P

Re: Its hard to convince OO developers to move to functional by Kit Davies

I think a good first step is examining and writing code that uses those Java libraries that encourage functional thinking, eg executors, atomic field updaters, Spring's JDBCTemplate, etc. Using anonymous classes may look like a mess at first to non-FP OO coders, but when the brain comprehends an anonymous block of code as a first-class object, a big leap has been made. High-order functions & currying can follow from that.

Re: Its hard to convince OO developers to move to functional by Paul Umbers

Definitely the case. I remember moving from Visual Basic to Java many years ago and getting headaches from trying to understand some of the concepts around OOP which are second nature to me now. Learning FP has the same affect and makes me want to drink more ... but both are worth it.

Not allowed by customers by Paulo Pinto

I work in the enterprise world far away from the shiny world of startups.

We only do boring Fortune 500 enterprise projects, where the customers require Java and C# as main languages (C++ is viewed as legacy), due to easiness of hiring developers as replaceable parts.

However the future seems to be multi-paradigm.

I already do quite some FP programming when allowed to use C# 4.0.

Most programs are about manipulating state, and pure FP makes it difficult. by Achilleas Margaritis

In most applications I have worked on, most of the program code is about manipulating state, which is especially difficult in pure code.

Things that are trivial in imperative code, like trees with parent/children node pointers, become very complex puzzles in pure fp code.

Chicken & Egg problem by Dmitry Tsygankov

Developers are afraid to move to FP, since there is no demand for these skills. Managers are afraid to move to FP, because there is no supply of these skills. The entire industry is in a "local maximum" state. The existing solutions are not optimal, but the (perceived?) cost of switching is high. It is for mostly the same reasons, that dictatorships exist.

Re: Most programs are about manipulating state, and pure FP makes it diffic by Dmitry Tsygankov

I don't think trees with parent/children node pointers are such a huge problem in _lazy_ functional languages (Haskell), which allow things like 'ones = 1 : ones' (that produces an infinite list of ones: 1, 1, 1, ...).

Re: Most programs are about manipulating state, and pure FP makes it diffic by Paul Beckford

State is evil, but I agree avoiding it is near impossible in many situations. This doesn't mean that we shouldn't avoid state as much as we can though. Smalltalk has most of the FP paraphernalia that people tend to associate with functional languages whilst promoting an OO style. The goal should be to minimise state where possible (FP), and encapsulate state when not (OO). The problem is most OO programmers haven't been exposed to functional concepts, only knowing dumbed down supposedly 'OO' languages like C++ and Java. Smalltalk, Ruby and Lisp for example have supported functional concepts all along. A function is an object too :)

Where things get interesting is with Pure Functional languages where state is not permitted. I must admit I have no real world experience using a pure functional style, but from what I can tell, Pure FP is more of an academic exercise then anything else. Until the Pure FP guys come up with checkers that can guarantee correctness, then the best checker is still the programmer. I worry that a pure functional style makes it more difficult for people to reason about the correctness of programs. Whilst Pure Functional code can be extremely terse, I wouldn't say that terseness in itself makes a program more readable, or maintainable.

I'm interested in hearing arguments to the contrary.

Re: Most programs are about manipulating state, and pure FP makes it diffic by Luc Prefontaine

I can tell you that I rarely write loops explicitly :) no data typing either. I got fed up of data types.
There is no boiler code, no repetitive loops with iterators, no repetitive tests for null....
The syntax is very simple.

I avoid mutation in most of my code. Pure functions are not an academic concept. It's much more easier
to write tests. Side effects are circumvented to mostly external entities like databases and faking these is
also easier.

Handling values is less trouble than mutable objects. Then it's a matter of composing functions together
to produce the desired result.

In terms of correctness, the lack of data typing may make you think that it makes life harder but it's not.
Most of the data structures implement higher abstractions,, you can use the same function over
different data structures (like iterating, item access in collections, ...).
This allied to immutability made my life much more easier.

I agree that immutability requires a fresh mind set, it feels like if you were missing a limb or two when you
start coding,
It took me roughly three months to feel more at ease while writing production code 10 hours a day.

Dynamic interaction with a REPL is a better way to prototype and test. I almost never restart the JVM where my code
runs while editing it/testing it. It brings the restart/test/kill/edit, .... cycle time to nearly zero.

If you are an advocate of TDD, you can also design this way, interactively... I prefer to write the core and then
add tests later but it's up to you.

You can call Java dynamically. Quite useful when you are strugling with a library API you do not yet master.

You can extend any class (including Java ones that you do not own) with new
behaviors on the fly. It allows you to provide abstractions with different implementations to bridge the
gap between different data types. This translates to less conditional tests to swith to different code branches.
You can unify various data types so that at the end they behave like good citizens.

It's worth trying and it will influence how you will write code in any Algol type language. You will want to avoid
side-effects.

Luc P.

Re: Its hard to convince OO developers to move to functional by Paul Beckford

Hi Luc,

I never us loops with Smalltalk or Ruby either, and I dear say most Lisp programmers never use loops either (and probably many good C# programmers, anyone who uses a language that allows you to avoid them!). Maps filters and list comprehensions are all possible in these languages. What I'm talking about is Haskell and isolating "non-pure" code using Monads.

I agree with you, that keeping your code as "pure as possible" is a good thing, which is why I said avoid state where you can, incapsulate state where you can't.

Are you advocating eliminating state entirely?

If so please explain why. I am genuinely interested if this is indeed your point of view.

Re: Its hard to convince OO developers to move to functional by Faisal Waris

Haskell is an excellent language for learning / teaching FP. For practical purposes, we need FP languages that run atop the JVM or .Net. This will allow us to move to FP incrementally and take advantage of existing code bases and libraries.

I believe in some cases we do need mutability but mutability should not be the default. A large swath of code does not need mutability. A key concept is 'persistent collections'. In OO you don't want to share collections because an external object can modify your internal state. In extreme case an object may hand out copies of its collections. With persistent collections you don't worry about changes as each holder has a 'persistent view' of the shared collection.

My F# code almost never has loops. I use recursion or maps, filters, etc. Note that F# and Scala compilers convert simple tail recursive calls to loops. For more complex cases the CLR has built-in support for tail calls; the JVM does not but Scala does something to compensate.

But there are many other concepts that traditional OO programmers and not attuned to:

- Strong type inference: In F# explicit type information is lightly 'sprinkled' through the code. The strong type inference makes F# feel like a dynamically typed language.

- Pattern Matching: F# and Scala have very strong pattern matching which is an excellent way of solving some problems. Most OO programmers don't have a concept of this.

- Agents, Actors and Asynchronous Programming - In F# there is the async monad (now C# 5.0 has the async/await syntax) which makes asynchronous programming look like synchronous programming. There is no 'inversion of control'. See www.infoq.com/presentations/Asynchronous-Progra....

- DSLs and Meta Programming - Both Clojure and F# have built-in meta programming capabilities (Scala is adding some capabilities in the compiler). For Java you need large external frameworks such as XText.

- Partial Application - can't go into details but the support for partial application (or currying) is essential for true FP programming.

Readability is something that you strive for in both OO and FP.

Some examples of stateful programs that are easier in imperative languages. by Achilleas Margaritis

1) Parent/child nodes.

Imperative code:


class Node {
Node parent;
List<Node> children;
int data;

void addChild(Node child) {
child.parent = this;
children.add(child);
}
}

void printTree(Node node) {
print(node.data);
for(Node child : node.children) {
printTree(child);
}
}



In pure code (I am using C-like syntax for readability):


class Node {
int data;
}

class Tree {
HashMap<Node, Node> parent_to_child;
HashMap<Node, Node> child_to_parent;
}


Tree addChild(Node parent, Node child) {
return new Tree(
parent_to_child.add(parent, child),
child_to_parent.add(child, parent));
}

void printTree(Tree tree, Node node) {
print(node.data);
tree.parent_to_children.filter(node, void (Node child) {
printTree(child);
});
}


In the pure example, new tree and hash map structures are created in order to keep the new relations of the parent-child nodes. Having a pointer to a node is no longer sufficient in pure code to traverse the tree; one needs a Tree instance as well, which keeps all the parent-child relationships.

Re: Some examples of stateful programs that are easier in imperative langua by Faisal Waris

As I posted earlier, occasionally you do need mutability but mutability should not be the default.

Many tree operations require traversal so by the time you traverse down to a child you already have a list of parents.

In the example above, you are using mutable collections so it is not ‘pure’. To see an example of a pure implementation of AVL Trees (balanced trees) please see: bitbucket.org/stasyan/f-data-structures/src/359...

It is easier to reason with pure structures because you know that some other piece of code in another thread cannot affect the data structures you are working with right now.

In OO everything is mutable by default and changes can propagate through the object graph via events or other operations. After some level of complexity you just can't keep track of how the graph will change.

Re: Some examples of stateful programs that are easier in imperative langua by Achilleas Margaritis

I don't doubt that it's easier to reason with pure programs. It may be easier to reason with them, but they are much more difficult to write and scale to complexity.

I've written a blog post here, with a more detailed example.

Re: Some examples of stateful programs that are easier in imperative langua by Luc Prefontaine

I see two places were mutability is needed:

A) you need to store the new state computed somewhere

B) you have a performance issue in a very small scope and no algorithm based on immutability can
beat mutation. Mutation should be confined to a very small set of functions, if possible restricted to
a single one. You can still write a pure function that uses mutation internaly without external side
effects to get speed benefits. This what happens when we call Java libraries from Clojure.
They use mutation but we make sure we stick to immutability as soon as we get out of the Clojure
function. We sometimes keep a handle on some Java objects but we restrict mutation to these objects.
It never leaks out.

In A), your new state has to be stored somewhere obviously, session object, persistent storage,...
However, why would you need mutation to get from state x to y ? Does it help ?
The answer is no, going from x to y is a computation. Your system may have a series of state changes
to achieve its goal but it should be clear from your code were you mutate something to persist each of
these new states.

In our product we have persistent queues were different states are stored, messages get marshalled between these
persistent steps. Eventually at the end some state information will be stored in a couple of databases.

There his little or no mutability in each step leading to a state change. Mutation of the external world is of
course needed but it does not have to clutter your code everywhere.

There's a urban legend that says that you cannot achieve anything with immutable data. That's not true.
You can avoid mutation in the computation of this myriad of objects which makes debugging and concurrency
a pain in the ...

There is a new generation of persistent storage around the corner that never forget any facts
you store in them. You change your phone number 20 times in be last 15 years ? We can retrieve them
at any point in time. You did not erase the previous one, you added a new fact.

You can avoid bashing the same memory area with new values overwriting the previous one.
Your brain works the same way, you do not forget your previous phone number, why would software should
implement a crippled behaviour and zap previuos values ? With today's hardware capabilities, it's nonsense.

Sadly the most popular programming languages are nroken in this regard.

Hope this helps.

Luc

Re: Its hard to convince OO developers to move to functional by Paul Beckford

I totally agree with your gist, especially the idea of being immutable by default (Newspeak supports this idea)


But there are many other concepts that traditional OO programmers and not attuned to:


Well it depends what you see as "traditional". Like I say Smalltalk and CLOS programmers have been doing functional things for years (including currying), and they see themselves as "traditional OO".

Paul.

Re: Most programs are about manipulating state, and pure FP makes it diffic by Dmitry Tsygankov

"Until the Pure FP guys come up with checkers that can guarantee correctness" - Agda, Coq? They're already there. I would not say these languages are something you would enjoy programming in - 100% correctness comes at a price. But, then, there is Haskell, which provides much stronger typing guarantees than any of the mainstream languages, and it is not at all difficult to code in.

"I worry that a pure functional style makes it more difficult for people to reason about the correctness of programs" - quite to the contrary. There is common wisdom in OO world, that you do not use globals, you do not reuse a local variable for several different purposes, you limit the scope of a variable as much as possible, you do not write a get-method that changes things. Good OO programmers do not violate these principles, but, when you are looking at the code, how do you know if it was written by a good programmer? Functional languages (especially Haskell) provide you a guarantee that these principles are not violated, and when they are, you'll see it immediately.

"I wouldn't say that terseness in itself makes a program more readable, or maintainable" - that is true, writing readable code, in any language, is an art. Certain functional languages (Lisp family and Haskell) just seem to provide more powerful tools at your disposal, to express your intent more clearly. It is up to you if you misuse them, or use them properly.

"State is evil, but I agree avoiding it is near impossible in many situations" - you could see some of the Rich Hickey's presentations here. His Datomic project is amazing, and, in one of the presentations, he is explaining how it is possible to design an application with just a single mutable variable.

Re: Inertia by David Biesack

1+

This survey omits a key reason: "Cost/time for retraining".

"Couldn't find developers" does not cover this. Companies are not going to hire new folks to just to adopt a functional language when they already have developers on staff. If teams feel productive in OO or procedural languages, they must perform a cost/benefit analysis for switching to functional languages.

Re: Its hard to convince OO developers to move to functional by Michael Swierczek

"Learning FP is very difficult, in my opinion. I'm in the "Functional Programming with Scala" course from Coursera, and I have never agonized more over solving one liner code problems before. Wrapping your head around immutable data structures is tough. Granted, this class is doing nearly pure FP with no mutable state, whereas mixing in functional techniques is not as difficult to grasp, in languages that support lambdas or closures."

I'm in the same Coursera class. One of the things the class demonstrated to me is that if you can get the types correct, your code is likely to pass all of your tests. In Java I'm accustomed to getting my code to compile immediately and then spending the next few hours getting it to work properly. In Scala used in a purely functional way, it's my experience that if you get the types correct the program is probably very close to correct already. But I'm a functional programming newbie, it's more important to note that many Scala and Haskell experts make the same assertion.

That doesn't address all of your concerns, but it addresses that one.

Mostly Marketing by Arturo Hernandez

Programmers claim to be completely pragmatic, and therefore we try to argue rationally about the lack of adoption of great technologies. My belief, since I can't really prove it is that programmers are often as emotional and biased about technology choices as any other mortal. Many times we are good at solving clear smaller context problems. But language/technology choice is extremely complex.

Clearly, I and many other functional language advocates don't think functional languages do everything better. In some aspects imperative languages are better, but the trade-off in most cases favors functional languages. It is really about convincing others that the trade-off is there. And that convincing task is mostly marketing. There are programming groups with leaders, those opinion leaders have influence over other programmers. If they say OO is still better, guess what the rest will think. If those leaders thought functional languages were ready. It would be a different story.

BTW. The chicken and egg discussions are not really fruitful, because clearly there has to be early adopters. Unless we did not think the trade-off in favor of functional languages was not there.

One thing that could be really beneficial is even better book/blog writers. If there were tons of good examples on how the same functionality is implemented on either language, that would help. Taking into account that is not apples to apples, the thought process is different.

Here is one of my favorite analogies. Think about learning how to drive a car and learning math. Almost nobody thinks that they can't learn how to drive, even when some truly can't. But there are plenty of people that think that they cannot learn math. And I am yet to hear about a really bad math accident. I think of all the reasons of why people are convinced they can learn how to drive as really good marketing.

A technology advance may be the tie breaker by Arturo Hernandez

Another way to look at the adoption problem. Is just to make FP better. I've read the clojure books and I like it. I like scheme and lisp. But what I am still frustrated about is how close to the metal OO and functional languages still are. I know there is a performance issue here. Being closer to the metal allows for faster programs. But I want a language that takes a specification and perhaps some execution hints, and turns my program into something truly efficient. SQL has that benefit, the optimizations that happen behind the scenes are incredible. And the fact that is not imperative facilitates those optimizations, most SQL users don't know what an LRU cache is. I know Rick Hickey did a parallelizing version of clojure vs the lazy eval version. That is great but there should be more of that coming. How about an automatic code analysis that picked the right run-time (parallel or lazy) for my particular program?

Functional libraries should be better (do more), than any other library. I know we think they are better because we do better programs. But I am talking about more complex things. It's not enougth to take a html templating library and recreate it in a functional language, although it may be a great way to learn.

How about a better (do more) mapping between algorithms and data, not just the language facilities but actual libraries?

Re: Missing choice by Andy Dent

Ditto except adding managent into that critical mass. We have Fortran and C++ as primary languages with TCL and Java used around the fringes for some home-grown UI.

The voting part sucks by Raul Guerrero

I'm already authenticated to infoQ but still I have to login using some other social crap account?, I don't really use social networks and also I can't use them because of work proxy policies, using the infoQ account should be enough

hard to convince OO developers to move to functional languages by Spencer Cathey

What kind of poll is this? Where is the button for "I use functional languages"? Or how about a button that says "I'll use any language, because I write meta-code and target compile to whatever target language"? Or how about the button that says "if my manager doesn't know it, they can't manage it"? Or my personal favorite, "I don't actually program, I repeat magic spells"?

Re: Its hard to convince OO developers to move to functional by Andras Ludanyi

The problem is somewhat more complex. It isn't easy to find good and skillful developers for any programming language, but it is quite easy to find bad/weak Java or C# developers (and lets face it, the bell curve (Gaussian distribution) is a inescapable "force" and consequently most developers are not so great). The "problem" is that THERE IS NO such thing as a bad functional language developer (only the top 5% of the Gaussian distribution curve of developers can understand functional programming). In other words, the reason why most people don't use functional languages is because it requires a much higher IQ and understanding of programming concepts than in a case of Java or C#, most of the other "excuses" are just a way to feel better about ourselves ;)

Re: Its hard to convince OO developers to move to functional by Jeryl Cook

"risk vs reward ratio is seen as too high when budgets & deadlines are part of the project plan."

100% agree with the risk vs. reward, I believe that experienced programmers in the 'field' just think "Ain't Nobody Got Time For That!" in regards to building using FP language.

Also, the number of developers using/knowing FP languages currently are significantly smaller than OO developers.

Re: User of a cross-paradigm language (Scala) in a heavily functional style by Marko Milicevic

@Kris >> It does this, however, at the cost of learning some new abstractions, and for some this learning is difficult because you can no longer think in terms of the traditional nouns and verbs; instead FP requires lots of thinking in terms of layered abstractions that are frankly hard to describe in English (or, indeed, most natural languages.)

I have found much success with multi-paradigm, default immutability (with option to mutate), closures, more abstract functional styled collection manipulation (map,filters,folds,...), etc...

But @Kris hits a real problem for me when considering pure-functional, which is possible sacrifices with language modeling. For me, complex programming is largely an exercise in modeling concepts (nouns), the relationships between the concepts, their and responsibilities (verbs). When i design, I'm trying to model a domain "language" that allows all stakeholders (not just devs) to reasoning about the system. This conceptual domain model also forms the basis of more abstract implementation DSL's.

OO is a natural fit for this style, and though i'm no functional expert, my experiments make me feel like pure-functional will lead to a loss of modeling expression.

Secondary concerns are possible performance challenges (eg. large data manipulation), the difficulty in reasoning about non-trivial pure-functional implementations.

If pure-functional is not the objective, almost all modern languages offer varying degrees of support for functional concepts.

What a stupid survey! by Dhiraj Bhandari

I dont agree with any of the options. So I dont get to vote?

Re: What a stupid survey! by Werner Schuster

Read the last sentence in the text: "Please vote for the fitting items below - if none fits, tell us your experience in the comments."

Re: User of a cross-paradigm language (Scala) in a heavily functional style by Eric Smith

This is very well stated, and it reflects the experience in our company. We use Scala. It allows us to exert a pressure over time toward more functional idioms & patterns without having to commit early in its adoption.

It's not only up to the developer(s) by Jurjen Vorhauer

The biggest obstacle is the lack of customers/clients/users that want to switch from 'safe' (in their perception) platforms like C#, ASP.NET, Spring and JEE that prohibit a massive switch from OO (or worse) to Functional.
There is always the fear that your beautiful and expensive (web)application cannot be maintained after a couple of months. This is basically a chicken-vs-egg problem: not enough developers, so not enough projects, so not enough developers, etc.
All of the mainstream languages like Java, C++, C#, PHP, Ruby, Perl, Python, etc. must have started once in the same situation. We should try to find out WHY these languages took up and try to move in a direction where the FP languages can make the same move.

In short: get developers, but more importantly, clients out of their comfort zone!

Why I Am Not Using Functional Languages? by John Carter


  • I would if there was one suited to resource constrained real time embedded systems on odd ball CPU's.
  • I tend to program in as Functional manner in C as it permits.
  • Real Time GC is a hard, but not unresolvable problem.

Re: Bureaucratic view of software development by Khalid Jebbari

@Luc P : Brillant. I should offer you a drink and transfer your reply to the many companies I worked for, including the current one.

business people are the reason by John Broderick

this is based on my experience only. Moving to a functional language is being seen as a costly and high risk move. The decision is normally controlled by a person that is either non-technical, or far removed from using a programming language. From their point of view why make such a drastic change for what would be little perceived benefit? Just like no-one would get fired for picking IBM, no-one would get fired for picking Java / C#.

I hope the change will happen, but we shouldn't be surprised that uptake will be slow.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

44 Discuss
General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT