To read all comments associated with this story, please click here.
I started programming in 1975 with BASIC and COMAL and then later Pascal, FORTRAN, COBOL and assembly language at university. On the third year of university, I was taught LISP and was immediately sold. I have also used C, Java, Scheme, ML, Haskell and a dozen less known languages. I tend to use mainly Standard ML. Though it is not purely functional and rather less advanced than Haskell, I like its simplicity: I find that Haskell has evolved to a testbench for weird language and type features so people can write extremely generic programs that you need a PhD to understand.
Standard ML is, however, rather dated. Some attempts at revising it has been made, but they have, IMO, failed mainly by trying to add too many new features to the language. Then there are what I would call misguided derivatives (O'Caml and F#) that add object-oriented features to the language. I would rather see a minimal update that solves some of the more pressing problems (such as lack of Unicode support) and a more modern standard library. And parallelism, of course.
The functional programming is going to be just another tool of multi-paradigm programming languages, I think.
From my enterprise experience I think functional programming has more chances of success by being integrated into mainstream languages (C#, Scala, ...) as pure functional only.
People finally discovered that single paradigm languages are not a good idea.
I disagree. Maintaining a clear, precise focus is a Very Good Thing (see: Coupling and Cohesion 101). You never see a joiner using the same tool to do everything from slice wood to turn screws to drive nails to apply varnish. There's a reason for that.
I think the real problem is developers not being able to hop quickly and effortlessly between different languages within a project. That may be partly down to bridging and tools not being good enough to allow seamless mixing and matching. But I suspect the biggest barrier is developers themselves lacking the mental agility to switch between languages and idioms. That, compounded by a self-indulgent fondness for inventing complex solutions using tools they already know rather than seeking out simple solutions involving tools they don't. The modern trend for Computer Science courses to silently retool as Software Engineering, and from there to lowest-common-denominator Java diploma mills, probably doesn't help either; but that's another debate.
Agreed. Over the years, I've found very little value in purely-functional languages - but I find a *lot* of value in having functional elements within more traditional procedural or OO languages.
I would disagree here. The problem is that it only takes one mutable piece of data or one function with a side effect to ruin an entire call chain. Mixing and matching pure FP with anything else renders your code non-pure and thus you may as well not have written in an FP style at all.
Less seriously, it forces users to think multiple ways. I saw many java developers complain vehemently about the upcoming lambdas in Java 8. So one developer might write code in an OO style, and another in an FP style, and now everybody has to learn both ways of doing it.
Carmack had a (imo) interesting blog post on functional programming from a C++ perspective:
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-...
I love functional programming.
But imperative programming more matches the way that people actually think. People think in concrete, step-by-step terms: I get out of bed, I take a shower, I brush my teeh, I comb my hair, I get dressed, I eat breakfast, I leave the house, I go to work, I park my car, I walk into the office, I etc, etc, etc. In order to achieve a particular goal, people do each step in a particular order.
Functional (and logic) programming, is more atuned to abstract/mathematical thinking (and the more declarative the programming is, the more it becomes like math). Most people are not adept at that.
If that was how OO programs are written the world would be better. Most programs (and toolkits) look more like this:
"[You,] get out of bed! Take shower! Brush teeth! Comb your hair!"
or even:
"take a comb, raise your hand, do {stroke your hair} until (enough)".
Calling other object's "doSomething" or "setSomething" methods is modern equivalent of calling "goto". A single setter may look innocent but try to sequence a number of them and you will have to deal with all the complexity (structure, sequencing, side effects) that leaked out from the object. That's because the control is no longer inside the object but in a caller of the method.





Member since:
2011-10-10
I do hope that functional programming languages undergoes a renaissance. However, in my opinion, imperative style languages have made it harder for people to think that way if they have been coding in an imperative style for too long. The thought process requires a radical shift which takes time. For me, it became relatively easy to pick up a new OO or imperative style language. However, it took me several months of wracking my brain to even begin to program in a functional style.
immutable vs. mutable data
recursion vs. iteration
closures vs. objects
method dispatch vs. polymorphism
pattern matching vs. switches
composition of functions vs. aggregation of objects
Macros vs. DSLs
Continuations vs. Exceptions/goto/setjmp
But once you do figure out, it just becomes more elegant. I don't know how software is going to get faster with multi-cores unless people switch to functional languages. Lock-based concurrency is just really hard to get right.
If you don't believe me, read Bartosz Milewski's post on why he switched to FP (and if you don't know who Bartosz is, just google him).
http://fpcomplete.com/the-downfall-of-imperative-programming/
My own dabble with functional languages has been mostly clojure and scheme based. Next on my list to learn is haskell. I tried Scala and didn't like it much (personal choice, it reminded me of perl's TIMTOWTDI and it wasn't really all that functional to which Odersky himself agreed). Clojure is nice, and it's way more readable than lisp/schemes since it also has [] for vectors and {} for maps. That little change makes clojure way more readable. That being said, being hosted on the JVM sucks for system programming. So that's why I've been learning scheme and next on my list is haskell.