"Study Functional Programming or Be Ignorant"(benhutchison.wordpress.com)
benhutchison.wordpress.com
"Study Functional Programming or Be Ignorant"
http://benhutchison.wordpress.com/2009/06/02/study-functional-programming-or-be-ignorant/
8 comments
Errr, I can deny the advantages of good OO design (OOSE specifically: http://en.wikipedia.org/wiki/Object-oriented_software_engine...).
There's no denying its power, and I'm sure it's superior for some applications, but the inherent mixing of persistent state and behavior in objects is pretty much irreconcilable with functional programming as I understand the latter.
For example, to me perhaps the single most useful OOSE artifact is the sequence diagram (UML version here: http://en.wikipedia.org/wiki/Sequence_diagram); in the non-side effecting functional programming world you have much less to keep track of in that manner.
There's no denying its power, and I'm sure it's superior for some applications, but the inherent mixing of persistent state and behavior in objects is pretty much irreconcilable with functional programming as I understand the latter.
For example, to me perhaps the single most useful OOSE artifact is the sequence diagram (UML version here: http://en.wikipedia.org/wiki/Sequence_diagram); in the non-side effecting functional programming world you have much less to keep track of in that manner.
What you said above is misleading. Mutability is not inherently tied to OOP. You can have immutable objects just as much as you can have functions that manipulate mutable state that they hide. I have heard that some people have even proposed in the past that one be allowed to access the variables a closure has a reference to outside of the body of the closure itself. How's that for mutable functional programming?
To me, the biggest advantages of OOP are composition and sub-typing. Check out PLT-Racket's concept of an iterable versus that of most OO languages (http://docs.racket-lang.org/reference/sequences.html#%28def....). In PLT-Racket you have to bundle together a list of functions, essentially rolling your own v-table from scratch. In an OO language you have this nice packaged concept of an Iterable interface, which is much easier to understand conceptually.
Underneath the hood, both are doing the same thing; both are performing operations according to a specified interface for some underlying data that the consumer knows nothing about. This is encapsulated message passing, which is at the heart of the OO. The same sort of thing can be done with immutable objects like functional data structures (http://code.google.com/p/pcollections/). OOP and functional programming need not contradict one another or be mutually exclusive.
As a final note, no one codes in lambda calculus any more than anyone codes in Turing machines. Real functional languages have mutable variables, and Haskell is the only language that I am aware of that tries to hide this fact as much as possible.
To me, the biggest advantages of OOP are composition and sub-typing. Check out PLT-Racket's concept of an iterable versus that of most OO languages (http://docs.racket-lang.org/reference/sequences.html#%28def....). In PLT-Racket you have to bundle together a list of functions, essentially rolling your own v-table from scratch. In an OO language you have this nice packaged concept of an Iterable interface, which is much easier to understand conceptually.
Underneath the hood, both are doing the same thing; both are performing operations according to a specified interface for some underlying data that the consumer knows nothing about. This is encapsulated message passing, which is at the heart of the OO. The same sort of thing can be done with immutable objects like functional data structures (http://code.google.com/p/pcollections/). OOP and functional programming need not contradict one another or be mutually exclusive.
As a final note, no one codes in lambda calculus any more than anyone codes in Turing machines. Real functional languages have mutable variables, and Haskell is the only language that I am aware of that tries to hide this fact as much as possible.
Functional may solve lots of problems, but you can't deny the advantages of a good OO design.
OO benefits tremendously from Functional programming. It's much, much easier to develop in a system where you can treat calling most of the methods on most objects as if they were stateless. A system that uses less state is more flexible and easily changed. A system that better encapsulates state is also more flexible and easily changed.
OO benefits tremendously from Functional programming. It's much, much easier to develop in a system where you can treat calling most of the methods on most objects as if they were stateless. A system that uses less state is more flexible and easily changed. A system that better encapsulates state is also more flexible and easily changed.
If Microsoft could pull it off, the ability to write both C# and F# inline in the same class, or at least the same file, would really be the best of both worlds. I'm not a languages guy, so I don't know if this idea is practical, but like everything else, it probably is "possible".
Wouldn't that be a lot like C#'s LINQ? The ability to drop complex, lazily-evaluated functional expressions into procedural C# is the closest example I've seen to blending the two methodologies. (Perhaps 'ideologies' would be a more accurate term?)
It is much less practical than adding FP capabilities to C# which is where C# is evolving anyway.
The world of programming will never agree in one thing, so if this would've happened, some people would love it and some would hate it.
There will be new "patterns" on how to use both features without shooting yourself in the foot. There will be new libraries written that exploit the awesomeness of both features. At the end of the day, there will be people benefited from that, and there will be more segmentation in the industry. People will have to be trained (wait... that no longer exist in our industry).
... and I... I will move on to a more managerial position so I can put to rest the learning of programming language for the sake of learning and swinging ego than for actually building things.
There will be new "patterns" on how to use both features without shooting yourself in the foot. There will be new libraries written that exploit the awesomeness of both features. At the end of the day, there will be people benefited from that, and there will be more segmentation in the industry. People will have to be trained (wait... that no longer exist in our industry).
... and I... I will move on to a more managerial position so I can put to rest the learning of programming language for the sake of learning and swinging ego than for actually building things.
I rather like that idea - allowing different languages at the method level would be rather cool.
thats actually a strawman, scheme and common lisp have some pretty awesome OO systems for those who want them. I in fact think that multimethods and related notions were first implemented in some of these scheme and CL systems.
http://en.wikipedia.org/wiki/Common_Lisp_Object_System is probably a good place to start
http://en.wikipedia.org/wiki/Common_Lisp_Object_System is probably a good place to start
[deleted]
I'm not so sure. What advantages does OOP have?
Every program is either a compiler, or an interpreter.
Compilers are just functions from input to output, so it is easy to write them in a functional way. For example code formatter, report generator, any program in which we are only interested in the final result, not in the intermediate steps, and nothing "new" can happen in the process of computation.
Interpreters are more imperative by nature, and it is more natural to write them in imperative way. For example real-time simulations (including games), interactive apps like offices suites, crud apps, etc.
In interpreters functional programming can be used in the small scale, to implement commands, but the result will be imperative interpreter with state and commands that modifies this state.
So oop is more suited to describe domain of most programs - users think about crud apps like this: "this button changes the name of selected student", "this button deletes student from base", "this button assigns student to course". Even if under the hood there is functional code, it is in reality interpreting imperative language and operating on state.
At least that's how I see it. YMMV.
Compilers are just functions from input to output, so it is easy to write them in a functional way. For example code formatter, report generator, any program in which we are only interested in the final result, not in the intermediate steps, and nothing "new" can happen in the process of computation.
Interpreters are more imperative by nature, and it is more natural to write them in imperative way. For example real-time simulations (including games), interactive apps like offices suites, crud apps, etc.
In interpreters functional programming can be used in the small scale, to implement commands, but the result will be imperative interpreter with state and commands that modifies this state.
So oop is more suited to describe domain of most programs - users think about crud apps like this: "this button changes the name of selected student", "this button deletes student from base", "this button assigns student to course". Even if under the hood there is functional code, it is in reality interpreting imperative language and operating on state.
At least that's how I see it. YMMV.
Mutable state does not necessarily mean OOP.
For instance, in Clojure I could write a multimethod that updates refs of type Student, and Course:
So to rephrase my question: what are the advantages of OOP when dealing with mutable state?
For instance, in Clojure I could write a multimethod that updates refs of type Student, and Course:
(defmethod assign [Student Course]
[student course]
(alter student update-in [:courses] conj course)
(alter course update-in [:students] conj student))
So to rephrase my question: what are the advantages of OOP when dealing with mutable state?
Every program is either a compiler, or an interpreter.
Great insight. Thanks for teaching me about this.
Great insight. Thanks for teaching me about this.
Not mine insight but I can't remember where i've read it.
Sorry, the compiler/interpreter division is nice but it's just one design pattern.
Works good till you reach a problem domain it's not appropriate for.
Models are great till you take them for reality.
Works good till you reach a problem domain it's not appropriate for.
Models are great till you take them for reality.
It's easy to be dismissive, but your criticism would probably be a good deal more constructive if you provided an example of an application where this division does not apply.
I've often thought that the recent emphasis on functional languages stems from the fact that webapps are where a great deal of innovation has been coming from lately. The design of the HTTP protocol makes it particularly straightforward to think about server-side code as a series of stateless (ignoring the database) transactions. The "model" of inherently* functional tasks as compilers and inherently procedural tasks as interpreters does a good job of crystallizing this idea.
(* When I say "inherently" functional or procedural here I mean tasks that lend themselves to being expressed cleanly one way or another.)
I've often thought that the recent emphasis on functional languages stems from the fact that webapps are where a great deal of innovation has been coming from lately. The design of the HTTP protocol makes it particularly straightforward to think about server-side code as a series of stateless (ignoring the database) transactions. The "model" of inherently* functional tasks as compilers and inherently procedural tasks as interpreters does a good job of crystallizing this idea.
(* When I say "inherently" functional or procedural here I mean tasks that lend themselves to being expressed cleanly one way or another.)
This is where Scala fits wonderfully.
"I still struggle to read most Haskell, and I certainly can’t use it to build anything"....but it's great; and, if you don't know all this cool esoteric stuff, you're ignorant.
Have heard/read similar posts from fans of other fringe languages: Lisp, Scheme, Prolog, ... There are grand claims of superiority, but with little practical evidence to bear out the claims.
I agree with other comments here -- the art of software design and programming is _generally_ independent of language. Languages, bad ones, inhibit good software engineering, and good ones enable if not encourage them (which is why good ones are typically minimal).
Have heard/read similar posts from fans of other fringe languages: Lisp, Scheme, Prolog, ... There are grand claims of superiority, but with little practical evidence to bear out the claims.
I agree with other comments here -- the art of software design and programming is _generally_ independent of language. Languages, bad ones, inhibit good software engineering, and good ones enable if not encourage them (which is why good ones are typically minimal).
Well, the title's a bit of a tautology, but it does seem that a bit of the glow has worn off of Java (to those that were captivated by it in the first place anyway). Functional programming seems to be trending upwards too.
I agree with the general assertion that hard core OO developers (Java and .Net folks) will need to start learning some new mental models of programming to keep adding relevance. I think we will start solving some harder problems that are intractable with traditional OO mechanisms.
I agree with the general assertion that hard core OO developers (Java and .Net folks) will need to start learning some new mental models of programming to keep adding relevance. I think we will start solving some harder problems that are intractable with traditional OO mechanisms.
Can you give some examples of the "harder problems that are intractable with traditional OO mechanisms"?
Yes, perhaps "are intractable" was too strong of an assertion.
I think as we migrate our data towards more flexible structures and look more towards asynchronous parallel processing, we may find that splitting out data and behavior serves us better than tightly binding them as OO methodology does.
I think ultimately we will treat our code and data as the same thing, just from different perspectives and levels of abstraction. I'm not sure most OO programming environments today support this notion easily.
I do think we will be solving harder problems, but what exactly they are falls into my unknown unknowns category.
I think as we migrate our data towards more flexible structures and look more towards asynchronous parallel processing, we may find that splitting out data and behavior serves us better than tightly binding them as OO methodology does.
I think ultimately we will treat our code and data as the same thing, just from different perspectives and levels of abstraction. I'm not sure most OO programming environments today support this notion easily.
I do think we will be solving harder problems, but what exactly they are falls into my unknown unknowns category.
[deleted]
Knowing functional programming surely makes you a better programmer, as knowing lisp do (even if you could never use in your projects).
But when I see post like this I always think to Fred Brooks' "There's no silver bullet" paper (http://en.wikipedia.org/wiki/No_Silver_Bullet).
But when I see post like this I always think to Fred Brooks' "There's no silver bullet" paper (http://en.wikipedia.org/wiki/No_Silver_Bullet).
Knowing something new will make you a better person.
If an OO programmer never knew functional programming, yeah, sure, he'll be a better programmer after learning LISP and I think the vice-versa is also true, a functional programmer who never bother learning OO because he thinks his paradigm is the silver bullet will benefit more knowledge if he decided to learn OO.
If an OO programmer never knew functional programming, yeah, sure, he'll be a better programmer after learning LISP and I think the vice-versa is also true, a functional programmer who never bother learning OO because he thinks his paradigm is the silver bullet will benefit more knowledge if he decided to learn OO.
Programming Language is like Software Development Methodology: it works well in certain area but doesn't fit well in generalization.
There are evangelists and purists in both world.
Here's a challenge for all evangelists and purists: you keep telling people that your thing is the right way to go, but when I ask you to learn my thing, you refuse like a mad man.
IT is a very funny industry, people keep telling you that we change the world, we have the power, we have the edge, we're the future or whatever. But at the end of the day, don't tell us to change ourselves.
There are evangelists and purists in both world.
Here's a challenge for all evangelists and purists: you keep telling people that your thing is the right way to go, but when I ask you to learn my thing, you refuse like a mad man.
IT is a very funny industry, people keep telling you that we change the world, we have the power, we have the edge, we're the future or whatever. But at the end of the day, don't tell us to change ourselves.
Maybe I don't get out enough, but I've never met a Haskell programmer with that mentality (LISPers, maybe). All the Haskellers I know are pragmatic people who will use another language (usually Python, I guess because iterators feel a lot like lazy lists) when it's the right tool for the job.
The most important parts of this article, IMHO:
The bit that stirs me up is that this “stuff” isn’t, repeat is not, Haskell-specific. Its rooted in the fabric of our reality, in our mathematics and our problem domains, and bits poke up like the tips of icebergs into mainstream OO languages, their true structure part-revealed. But rarely in the OO-world have I found such carefully abstracted and subtle techniques of programming in daily use.
Ideas from Haskell & Functional Programming will continue to flow into the mainstream over the next couple of decades.
This is why it's important to read about things like immutable data structures and higher-kinded polymorphism, even if your problem domain (or personal / corporate style) is utterly unsuited to existing functional programming languages. This stuff isn't just obscure tricks for maths nerds to obsess over, it's fundamental to how programming works.
If you want to understand LINQ, you need to understand higher-kinded polymorphism and monads. If you're writing a series of chained callbacks in Javascript and feel like there's some repetition you'd like to extract but can't quite put your finger on, you need to understand the continuation monad (I'm only about halfway there...) If you want to reason sensibly about concurrent updates to complex data structures, it helps a lot to know about immutable structure-sharing data structures.
The bit that stirs me up is that this “stuff” isn’t, repeat is not, Haskell-specific. Its rooted in the fabric of our reality, in our mathematics and our problem domains, and bits poke up like the tips of icebergs into mainstream OO languages, their true structure part-revealed. But rarely in the OO-world have I found such carefully abstracted and subtle techniques of programming in daily use.
Ideas from Haskell & Functional Programming will continue to flow into the mainstream over the next couple of decades.
This is why it's important to read about things like immutable data structures and higher-kinded polymorphism, even if your problem domain (or personal / corporate style) is utterly unsuited to existing functional programming languages. This stuff isn't just obscure tricks for maths nerds to obsess over, it's fundamental to how programming works.
If you want to understand LINQ, you need to understand higher-kinded polymorphism and monads. If you're writing a series of chained callbacks in Javascript and feel like there's some repetition you'd like to extract but can't quite put your finger on, you need to understand the continuation monad (I'm only about halfway there...) If you want to reason sensibly about concurrent updates to complex data structures, it helps a lot to know about immutable structure-sharing data structures.
Its a pretty bold statement to say that programmers who don't use your favorite language or style are ignorant of how a computer works.
I agree, so it's a good thing he didn't make that claim ;-)
Lots of languages are incorporating functional features, from dynamic languages like Python to even Java's support for closures. To really get your head around these features, it pays to play with a real functional language for a bit.
Lots of languages are incorporating functional features, from dynamic languages like Python to even Java's support for closures. To really get your head around these features, it pays to play with a real functional language for a bit.
You can be a good bricklayer without knowing much about structural engineering.
What happens when you want to build something taller than ten stories?
What happens when you want to program for more than ten CPU cores?
What happens when you want to program for more than ten CPU cores?
I find the assertion that the ONLY way to program for multiple cores or concurrency is to use functional programming annoying. It seems to be the default fall back of functional evangelists, as if there were no other way in the world to solve concurrency.
I recently took a course on concurrent programming, and the from what I learned, some problems are easier to deal with in erlang or something similar. But then again some aren't. And a lot of the time, they run an order of magnitude slower (though as my prof would say, correctness is sometimes more valuable than speed).
And granted my Erlang program for matrix multiplication was very concise. My MPI implementation ran WAY faster.
It seems to me, there are two schools of thought, and you can live in one, the other, or both. Certainly there are things to be learned in either.
I think all one can take away from articles like this is that it's good to keep learning.
I recently took a course on concurrent programming, and the from what I learned, some problems are easier to deal with in erlang or something similar. But then again some aren't. And a lot of the time, they run an order of magnitude slower (though as my prof would say, correctness is sometimes more valuable than speed).
And granted my Erlang program for matrix multiplication was very concise. My MPI implementation ran WAY faster.
It seems to me, there are two schools of thought, and you can live in one, the other, or both. Certainly there are things to be learned in either.
I think all one can take away from articles like this is that it's good to keep learning.
You seem to be confusing "Erlang" with "functional programming." They are not equivalent. Erlang is not what makes functional style good for concurrency — it takes advantage of some of the factors, but it is not the be-all-end-all. Erlang's actor-based green-threaded messaging is only one concurrency style.
I was using Erlang as an example as I am familiar with it. My point was more so that there are (as you say) many styles of concurrency, and that I hate it when functional programers use "Try programming concurrently in an imperative language" as their fall back argument for the merits of FP.
It is one of the few arguments that doesn't first require the other person to have a deep understanding of functional programming.
Try to convince someone of the value of immutability without mentioning concurrency.
Imperative and functional programming relate in the same way that arithmetic and algebra relate. It is hard to do deep reasoning in maths without algebra and it is impossible to evaluate the value of most algebraic expressions without arithmetic.
There is a reason that functional programming is at the forefront of concurrency research. In the long run, imperative only approaches will be unable to compete, and functional only approaches will remain on paper.
Try to convince someone of the value of immutability without mentioning concurrency.
Imperative and functional programming relate in the same way that arithmetic and algebra relate. It is hard to do deep reasoning in maths without algebra and it is impossible to evaluate the value of most algebraic expressions without arithmetic.
There is a reason that functional programming is at the forefront of concurrency research. In the long run, imperative only approaches will be unable to compete, and functional only approaches will remain on paper.
That's because support for concurrency is one of the most relevant strengths of functional programming. It's a buzzword right now, and a lot of the advice for how to do it well points toward functional programming practices, so they see that and say, "Hey, we should let people know that we already have all this stuff!"
Learning functional programming for a programmer is like learning programming for a non-programmer. Someone who is a logistics expert is valuable. A logistics expert who knows how to program is even more so.
OO programmers who understand functional programming have a big advantage over OO programmers who don't. Learning FP gives one the mental tools to do better encapsulation.
OO programmers who understand functional programming have a big advantage over OO programmers who don't. Learning FP gives one the mental tools to do better encapsulation.
I have written code for hundreds of cores. (can you say CUDA?) It was written entirely in C and ran very fast.
Thats great, but anecdotal evidence doesn't really prove anything. CUDA lets you write multi-core code for GPUs, but imagine writing C code for hundreds of cores over a datacenter cluster. C isn't the right tool for that job.
If I said on this thread "oh yeah, I'm a pro at functional programming -I use LINQ alllllll the time" how many heads would explode?
The best approach appears to me to be taking the best of both worlds. Functional may solve lots of problems, but you can't deny the advantages of a good OO design. Just devise your OO architecture for good reusability, flexibility, low coupling and high cohesion and then just use the best that functional programming has to offer.