7 ms·

“Mostly functional” programming does not work

51 points by lisptime 12y ago

mbenjaminsmith 12y ago
I think the real failure of FP has been demonstrating its advantages in practical terms. While deferring impurity is admittedly interesting (if you care about the theoretical underpinnings of programming at all) what do I gain as a programmer? I'll try to illustrate my point: In programming we often have to do something more than once. In terms of mental complexity, I'd rank our options like so, from easy to hard: Loop -> Recursion -> Fixed Point Iteration We can do the same thing with all of them. Recursion in some cases can lead to a stack overflow and any fixed point iteration has the disadvantage of, well, being f-ing hard to understand. A beginner can get a `while` or a `for` loop in seconds. They're very, very intuitive. Once you figure out solving problems in software often requires doing things repeatedly, loops open up a lot of power. Recursion is more difficult once you throw in conditionals and return values. They're harder to reason about. Loops are simple. So why bother with recursion? I learned recursion because it exists and I love learning. Could I have written just as much software without it? Yes. Would it have been just as functionally correct, maintainable, easy to read? Yes. I know very little about fixed point iteration. Why? Well, because I have loops and if I'm feeling jaunty, recursion. Having said that, I recently came across this article about the Y combinator: http://matt.might.net/articles/implementation-of-recursive-fixed-point-y-combinator-in-javascript-for-memoization/ http://matt.might.net/articles/implementation-of-recursive-f... I recommend that article for everyone. But the most important part is the section "Exploiting the Y combinator". > This formulation still has exponential complexity, but we can change it to linear time just by changing the fixed-point combinator. The memoizing Y combinator, Ymem, keeps a cache of computed results, and returns the pre-computed result if available: The author is talking about his algorithm for calculating Fibonacci numbers. While the naive recursive approach is limited due to its computation complexity, by caching intermediate results we can short-circuit the calculations made. > The end result is that the 100th Fibonacci number is computed instantly, whereas the naive version (or the version using the ordinary Y combinator) would take well beyond the estimated lifetime of the universe. I don't know enough about what's being done here to say that this optimization couldn't have been made with a loop (I believe Turing equivalence proves that it could have been) but at least I get to see some of the magic that fixed point iteration gives us. Haskell, as a functional language, offers a lot (purity! type safety!) but the community hasn't really shown how these things are valuable. Type safety is great, but is Haskell materially better than Objective-C (my primary language) in that regard? Pure functions are trivial to test, but in a language with a reasonable amount of type safety, how many individual functions are getting tested anyway? Of course I can write pure functions in an imperative language and often do. And I can do so without painfully abstract concepts like the dreaded monad if I want to do something as pedestrian as generate a random number. The reality is writing software for most people is about the platform they're targeting, available libraries, ease of use and techniques for dealing with long-term complexity. I have yet to find a reason to use Haskell even though I would love to -- more accurately, I have yet to find a situation where I could justify using Haskell.
lispm 12y ago
Another monad introduction.
- deleted 12y ago
  [deleted]
kristopolous 12y ago
The author needs to be less aggressive in the accusations. This current trend which supposedly "doesn't work" actually runs the vast majority of the modern web consistently and reliably. Placing onerous restrictions on what someone is permitted to do in order to satisfy some formal abstract programming model - that is the thing that really doesn't work too well. This makes arbitrary programming arbitrarily difficult: many simple concepts are completely prohibited. Fanciful convoluted ways that don't violate the formalism have to be fabricated...because we can't violate our arbitrary formalism! No! Not in the name of instructing a computer to do something. /me adjusts his english headmaster cap.
- hugofirth 12y ago
  There are advantages to both methodologies, but I must say I agree with you. The accepted academic practice is to find/develop the right formalism and then implement from there. Despite this being akin to heresy, I much prefer to implement, then formalise later. I find it easier to "get the job done" that way.
- tinco 12y ago
  You need to better learn what you are talking about. Passing data by pointer is perfectly allowable in functional programming, how do you imagine passing something by pointer has side effects? Data.ByteString is basically a pointer to a byte array, and it's one of the most common datastructures in Haskell. Even more importantly, the optimizations the Haskell VM is allowed to do because of the immutability and purity constraints means that even naieve and trivial solutions using Data.ByteString on general I/O problems like webservers perform in the best of class amongst native competitors like Nginx. edit: And the majority of the web is ran consistently and reliably? You mean apart from it being threatened by huge security vulnerabilities almost every month for the past 20 years? With so much insecure systems still connected that DDOS attacks are a day to day concern for system administrators?
  - kristopolous 12y ago
    I didn't say Haskell. There are numerous programmings languages which only permit pass by value (and no referencing) for "I'm-such-a-smartypants" reasons. I was really bashing the single-paradigm purist approach in general. It's much too rigid and difficult for anyone who isn't a card carrying mensa member.
sqrt17 12y ago
"Mostly functional", in my eyes, works as well as contract-based specification of interfaces works. The property of being free of (surprising/undesirable) side effects is part of a contract that can, but should not be violated by an implementation. To me Meijer's argument sounds like a strawman, since the alternatives to encapsulating side-effects in the terms of a (informal, software) contract are all not very appealing. Declarative sublanguages such as LINQ work precisely because of this "contract" of being mostly-functional, even if the work behind the scenes (database accesses etc.) certainly changes the state of the world.
btmorex 12y ago
To play devil's advocate for a minute: Nearly all useful, reusable software today is written in a mostly or entirely imperative language. This is despite the fact that functional programming has been around for at least 20-30 years. So, my basic question is, if functional programming is so much better, why isn't more software written in a functional language? Or put another way, why are there so many blog posts promoting functional programming when it clearly hasn't produced results.
- rjknight 12y ago
  I have a suspicion that it's due to the "unreasonable effectiveness of software", to paraphrase Eugene Wigner. The ability to do large amounts of computation quickly and cheaply is just so powerful that we can get away with doing it relatively badly and still create a lot of value. Functional programming might well produce better software, for some criteria of "better", but these quality-based criteria are dominated by the "is it cheaper and more effective than paying a person to do this" criterion employed in industry. This isn't necessarily a bad thing - if even the "worst" imperative software is value-creating, then there's a lot of scope for superior functional software to create even more value, there just isn't a lot of pressure to do this within industry because imperative programs are good enough for most use cases. There are other factors, such as path-dependency issues relating to developer skill-sets and toolchains, which give an advantage to imperative programming too. It seems likely to me that functional languages will close at least part of this gap, and perhaps Erik Meijer is underestimating the importance of "mostly functional" programming as a stepping-stone to "totally functional". Dijkstra was wrong when he claimed that learning BASIC was a mental mutilation preventing a person from ever understanding programming, and by the same token I suspect that we'll see plenty of people becoming good functional programmers who first encountered FP in passing callback handlers around in JavaScript.
- JeanPierre 12y ago
  That's a red herring: You're asking why the majority of software is written in imperative languages instead of functional ones, which is a very complex question with very many factors. It is not an argument which invalidates nor counters the author's claim: Namely that "mostly functional languages" is unfeasible and only increases the bugs caused by side effects.
matthewmacleod 12y ago
Evidently "mostly functional" programming does work, as does imperative programming, because we've got loads of successful software written using these paradigms. I'm absolutely all behind the idea of looking at what the future of programming languages is going to be, and how we're going to cope with diverse, highly parallel systems, and how we can reduce errors, bugs and failures. But it will be a while until we figure that out.
vertex-four 12y ago
The author never explicitly specifies what "does not work" actually means. Does it mean the code doesn't run? Is riddled with bugs? Certain types of reasoning aren't possible? Certain compiler optimisations aren't possible? The design of such languages is more inconsistent than they'd like?
danieldk 12y ago
His argument is that concepts such as laziness lead to unexpected results in imperative languages. However, such problems also occur in pure functional languages: http://stackoverflow.com/questions/5892653/whats-so-bad-about-lazy-i-o http://stackoverflow.com/questions/5892653/whats-so-bad-abou...
- yvdriess 12y ago
  I would like to point out that there are classes of laziness. Haskell's laziness guarantees that an expression will not be evaluated if it is not used. e.g. take_first(42, 42/0) will not return an error. This enables you to construct infinite lists of primes and such. Some classes of functional languages had lenient evaluation, evaluation is still lazy, but all expressions will be evaluated at some point in the program. You cannot do the infinity tricks, but you can still write the nice recursive functions, those that are used to show off the benefit of laziness. The Haskell type of laziness bites you in the ass when trying to do parallel evaluation, which is why you need the rpar/rseq constructs to avoid opening the nasty trapdoors that regular evaluation will not hit. Even besides I/O and parallelism the laziness can bite you. Mainly, it can make it hard to predict memory/processing use, unless you are intimately acquainted with the innards of Haskell.
rtpg 12y ago
OK, this points out a couple of things that "do not work" in these sorts of situations: - lazy evaluation with side effects - replacement optimisations based off of referential transparency when there are side effects - general side-effectiness This is basically saying that functional programming doesn't work when it isn't functional... but we can still have functional "chunks", and monads _are_ an effect system. I don't really understanding what he's trying to prove, of course purely functional semantics fall apart when side effects are introduced.
Jweb_Guru 12y ago
This would be a better article if it didn't implicitly assume mutable state was always bad. For example, locally mutable state (that doesn't escape) is highly unlikely to bite either you or the compiler.
sillysaurus3 12y ago
Lisp is mostly functional. Arc isn't purely functional, and it works quite well.
cm2187 12y ago
All I get is a 403 Forbidden error on this link
auggierose 12y ago
I use Scala for "mostly functional" programming, and it works very well. Sorry, Erik, you are just not where it's at anymore.
- deleted 12y ago
  [deleted]
- hbogert 12y ago
  Happens to be that Scala is Erik's favorite as well. I must say that the article has a completely different tone than when you'd talk to him personally, though he likes to talk in extremes and only afterwards talks about what is practical yet not in a diminished importance kind of way. I interpret the article just as a big indicator to a fundamental problem how we can express stuff in language and their accompanying downsides.
  - emsy 12y ago
    Talking in extremes is practical, if you want to be heard and/or start a discussion. See this very submission :)
radicalbyte 12y ago
Erik's example of the using statement is a straw-man: you get exactly the same problems if you do this: using(var file = File.Open(path)) { _someField = file; } ..and then use _someField in another method. It's not so much a problem with understanding closures, but of the limitations of IDisposable.
otikik 12y ago
The article should start by defining what he means by "work". I see mostly functional programming working every day. I even see non-functional programming (grasp!) working every day.
acqq 12y ago
I don' understand where he sees the problem in the first C# example? I believe it actually works, the interleaving is OK to happen IMHO. I guess in Haskell it would also happen, as it's also lazy. What am I missing?
creyer 12y ago
"It is impossible to make imperative programming languages safer by only partially removing implicit side effects" So when we can call a program safe? My personal definition is that a program is safe when it always gives the right output for the input it was designed for. Of course if you put water in your car won't make it run, the same way if you provide the wrong input to a program might end up in a wrong output. Getting back I do believe in the middle way.
tinco 12y ago
It's a shame he's put an introduction to monads smack down in the middle of this otherwise nice argument. If there was ever any objection to pure functional programming it would be that monads are complex and hard to learn and reason about. Putting an explanation of them with all sorts of mathematical terms is not helping the cause. Not only are monads not the only solution to doing I/O in a pure programming language (stream based I/O or functional reactive being another), they need not such a mathematical explanation. An I/O monad is a simple class modelling a box. There's two functions for it, one puts something that's not in a box in a box. The other function allows you to give it a function that is applied over the function in the box, without taking it out of the box (this is called a 'bind' operation). Note that there's no function to take the value out of the box. The trick is that the only thing that knows how to get the value out of the box is the VM itself. So its task is to at the end of your function, execute whatever function created your monad, and then execute all functions you gave it using the 'bind' functions sequentially over the returned value (which might include unwrapping more i/o monads). Since every bind function relies on the previous value of the monad, it can naturally only be executed sequentially. Note that this explanation does not explain monads either in full or very accurately, it's just one of the patterns that monads are used in, and hopefully gives you an idea about how it is that monads are used to enforce encapsulation and sequential execution of effectful functions.
mathenk2 12y ago
I must say that in all of my years, most every piece of source I've ever seen has been mostly [insert paradigm here]. OOP is "mostly" more times than not, same goes for FP. I would argue that "mostly" does work, and thankfully so, because nearly every service that you use throughout your day is a "mostly".
louthy 12y ago
"Computation is not just about functions, if computation was just about functions then quicksort and bubblesort would be the same because they're computing the same function. A computing device is something that goes through a sequence of states. What an assignment statement is doing is it is telling you "here is a new state". Functions alone don't solve the problems of programming because programs (on the whole) are non-deterministic; on the other hand, imperative programs are using assignment statements to compute functions, and that's silly." That exact phrase was said to Erik Meijer by Leslie Lamport when Erik interviewed Leslie. [1] It seems clear (if you take Leslie's word as gospel) that there is room for 'Mostly Functional'. That is, accept that your program goes through a series of states, but use pure functions to calculate those states. However, as an imperative programmer who's found Haskell over the past few years (thanks, in a large part to Erik Meijer), I happen to think that Haskell has it just about right. [1] http://channel9.msdn.com/Shows/Going+Deep/E2E-Erik-Meijer-and-Leslie-Lamport-Mathematical-Reasoning-and-Distributed-Systems http://channel9.msdn.com/Shows/Going+Deep/E2E-Erik-Meijer-an...

51 points by lisptime 12y ago

I think the real failure of FP has been demonstrating its advantages in practical terms. While deferring impurity is admittedly interesting (if you care about the theoretical underpinnings of programming at all) what do I gain as a programmer? I'll try to illustrate my point: In programming we often have to do something more than once. In terms of mental complexity, I'd rank our options like so, from easy to hard: Loop -> Recursion -> Fixed Point Iteration We can do the same thing with all of them. Recursion in some cases can lead to a stack overflow and any fixed point iteration has the disadvantage of, well, being f-ing hard to understand. A beginner can get a `while` or a `for` loop in seconds. They're very, very intuitive. Once you figure out solving problems in software often requires doing things repeatedly, loops open up a lot of power. Recursion is more difficult once you throw in conditionals and return values. They're harder to reason about. Loops are simple. So why bother with recursion? I learned recursion because it exists and I love learning. Could I have written just as much software without it? Yes. Would it have been just as functionally correct, maintainable, easy to read? Yes. I know very little about fixed point iteration. Why? Well, because I have loops and if I'm feeling jaunty, recursion. Having said that, I recently came across this article about the Y combinator: http://matt.might.net/articles/implementation-of-recursive-fixed-point-y-combinator-in-javascript-for-memoization/ http://matt.might.net/articles/implementation-of-recursive-f... I recommend that article for everyone. But the most important part is the section "Exploiting the Y combinator". > This formulation still has exponential complexity, but we can change it to linear time just by changing the fixed-point combinator. The memoizing Y combinator, Ymem, keeps a cache of computed results, and returns the pre-computed result if available: The author is talking about his algorithm for calculating Fibonacci numbers. While the naive recursive approach is limited due to its computation complexity, by caching intermediate results we can short-circuit the calculations made. > The end result is that the 100th Fibonacci number is computed instantly, whereas the naive version (or the version using the ordinary Y combinator) would take well beyond the estimated lifetime of the universe. I don't know enough about what's being done here to say that this optimization couldn't have been made with a loop (I believe Turing equivalence proves that it could have been) but at least I get to see some of the magic that fixed point iteration gives us. Haskell, as a functional language, offers a lot (purity! type safety!) but the community hasn't really shown how these things are valuable. Type safety is great, but is Haskell materially better than Objective-C (my primary language) in that regard? Pure functions are trivial to test, but in a language with a reasonable amount of type safety, how many individual functions are getting tested anyway? Of course I can write pure functions in an imperative language and often do. And I can do so without painfully abstract concepts like the dreaded monad if I want to do something as pedestrian as generate a random number. The reality is writing software for most people is about the platform they're targeting, available libraries, ease of use and techniques for dealing with long-term complexity. I have yet to find a reason to use Haskell even though I would love to -- more accurately, I have yet to find a situation where I could justify using Haskell.

lispm 12y ago

Another monad introduction.

deleted 12y ago
[deleted]

kristopolous 12y ago

The author needs to be less aggressive in the accusations. This current trend which supposedly "doesn't work" actually runs the vast majority of the modern web consistently and reliably. Placing onerous restrictions on what someone is permitted to do in order to satisfy some formal abstract programming model - that is the thing that really doesn't work too well. This makes arbitrary programming arbitrarily difficult: many simple concepts are completely prohibited. Fanciful convoluted ways that don't violate the formalism have to be fabricated...because we can't violate our arbitrary formalism! No! Not in the name of instructing a computer to do something. /me adjusts his english headmaster cap.

hugofirth 12y ago
There are advantages to both methodologies, but I must say I agree with you. The accepted academic practice is to find/develop the right formalism and then implement from there. Despite this being akin to heresy, I much prefer to implement, then formalise later. I find it easier to "get the job done" that way.
tinco 12y ago
You need to better learn what you are talking about. Passing data by pointer is perfectly allowable in functional programming, how do you imagine passing something by pointer has side effects? Data.ByteString is basically a pointer to a byte array, and it's one of the most common datastructures in Haskell. Even more importantly, the optimizations the Haskell VM is allowed to do because of the immutability and purity constraints means that even naieve and trivial solutions using Data.ByteString on general I/O problems like webservers perform in the best of class amongst native competitors like Nginx. edit: And the majority of the web is ran consistently and reliably? You mean apart from it being threatened by huge security vulnerabilities almost every month for the past 20 years? With so much insecure systems still connected that DDOS attacks are a day to day concern for system administrators?
- kristopolous 12y ago
  I didn't say Haskell. There are numerous programmings languages which only permit pass by value (and no referencing) for "I'm-such-a-smartypants" reasons. I was really bashing the single-paradigm purist approach in general. It's much too rigid and difficult for anyone who isn't a card carrying mensa member.

sqrt17 12y ago

"Mostly functional", in my eyes, works as well as contract-based specification of interfaces works. The property of being free of (surprising/undesirable) side effects is part of a contract that can, but should not be violated by an implementation. To me Meijer's argument sounds like a strawman, since the alternatives to encapsulating side-effects in the terms of a (informal, software) contract are all not very appealing. Declarative sublanguages such as LINQ work precisely because of this "contract" of being mostly-functional, even if the work behind the scenes (database accesses etc.) certainly changes the state of the world.

btmorex 12y ago

To play devil's advocate for a minute: Nearly all useful, reusable software today is written in a mostly or entirely imperative language. This is despite the fact that functional programming has been around for at least 20-30 years. So, my basic question is, if functional programming is so much better, why isn't more software written in a functional language? Or put another way, why are there so many blog posts promoting functional programming when it clearly hasn't produced results.

rjknight 12y ago
I have a suspicion that it's due to the "unreasonable effectiveness of software", to paraphrase Eugene Wigner. The ability to do large amounts of computation quickly and cheaply is just so powerful that we can get away with doing it relatively badly and still create a lot of value. Functional programming might well produce better software, for some criteria of "better", but these quality-based criteria are dominated by the "is it cheaper and more effective than paying a person to do this" criterion employed in industry. This isn't necessarily a bad thing - if even the "worst" imperative software is value-creating, then there's a lot of scope for superior functional software to create even more value, there just isn't a lot of pressure to do this within industry because imperative programs are good enough for most use cases. There are other factors, such as path-dependency issues relating to developer skill-sets and toolchains, which give an advantage to imperative programming too. It seems likely to me that functional languages will close at least part of this gap, and perhaps Erik Meijer is underestimating the importance of "mostly functional" programming as a stepping-stone to "totally functional". Dijkstra was wrong when he claimed that learning BASIC was a mental mutilation preventing a person from ever understanding programming, and by the same token I suspect that we'll see plenty of people becoming good functional programmers who first encountered FP in passing callback handlers around in JavaScript.
JeanPierre 12y ago
That's a red herring: You're asking why the majority of software is written in imperative languages instead of functional ones, which is a very complex question with very many factors. It is not an argument which invalidates nor counters the author's claim: Namely that "mostly functional languages" is unfeasible and only increases the bugs caused by side effects.

matthewmacleod 12y ago

Evidently "mostly functional" programming does work, as does imperative programming, because we've got loads of successful software written using these paradigms. I'm absolutely all behind the idea of looking at what the future of programming languages is going to be, and how we're going to cope with diverse, highly parallel systems, and how we can reduce errors, bugs and failures. But it will be a while until we figure that out.

vertex-four 12y ago

The author never explicitly specifies what "does not work" actually means. Does it mean the code doesn't run? Is riddled with bugs? Certain types of reasoning aren't possible? Certain compiler optimisations aren't possible? The design of such languages is more inconsistent than they'd like?

danieldk 12y ago

His argument is that concepts such as laziness lead to unexpected results in imperative languages. However, such problems also occur in pure functional languages: http://stackoverflow.com/questions/5892653/whats-so-bad-about-lazy-i-o http://stackoverflow.com/questions/5892653/whats-so-bad-abou...

yvdriess 12y ago
I would like to point out that there are classes of laziness. Haskell's laziness guarantees that an expression will not be evaluated if it is not used. e.g. take_first(42, 42/0) will not return an error. This enables you to construct infinite lists of primes and such. Some classes of functional languages had lenient evaluation, evaluation is still lazy, but all expressions will be evaluated at some point in the program. You cannot do the infinity tricks, but you can still write the nice recursive functions, those that are used to show off the benefit of laziness. The Haskell type of laziness bites you in the ass when trying to do parallel evaluation, which is why you need the rpar/rseq constructs to avoid opening the nasty trapdoors that regular evaluation will not hit. Even besides I/O and parallelism the laziness can bite you. Mainly, it can make it hard to predict memory/processing use, unless you are intimately acquainted with the innards of Haskell.

rtpg 12y ago

OK, this points out a couple of things that "do not work" in these sorts of situations: - lazy evaluation with side effects - replacement optimisations based off of referential transparency when there are side effects - general side-effectiness This is basically saying that functional programming doesn't work when it isn't functional... but we can still have functional "chunks", and monads _are_ an effect system. I don't really understanding what he's trying to prove, of course purely functional semantics fall apart when side effects are introduced.

Jweb_Guru 12y ago

This would be a better article if it didn't implicitly assume mutable state was always bad. For example, locally mutable state (that doesn't escape) is highly unlikely to bite either you or the compiler.

sillysaurus3 12y ago

Lisp is mostly functional. Arc isn't purely functional, and it works quite well.

cm2187 12y ago

All I get is a 403 Forbidden error on this link

auggierose 12y ago

I use Scala for "mostly functional" programming, and it works very well. Sorry, Erik, you are just not where it's at anymore.

deleted 12y ago
[deleted]
hbogert 12y ago
Happens to be that Scala is Erik's favorite as well. I must say that the article has a completely different tone than when you'd talk to him personally, though he likes to talk in extremes and only afterwards talks about what is practical yet not in a diminished importance kind of way. I interpret the article just as a big indicator to a fundamental problem how we can express stuff in language and their accompanying downsides.
- emsy 12y ago
  Talking in extremes is practical, if you want to be heard and/or start a discussion. See this very submission :)

radicalbyte 12y ago

Erik's example of the using statement is a straw-man: you get exactly the same problems if you do this: using(var file = File.Open(path)) { _someField = file; } ..and then use _someField in another method. It's not so much a problem with understanding closures, but of the limitations of IDisposable.

otikik 12y ago

The article should start by defining what he means by "work". I see mostly functional programming working every day. I even see non-functional programming (grasp!) working every day.

acqq 12y ago

I don' understand where he sees the problem in the first C# example? I believe it actually works, the interleaving is OK to happen IMHO. I guess in Haskell it would also happen, as it's also lazy. What am I missing?

creyer 12y ago

"It is impossible to make imperative programming languages safer by only partially removing implicit side effects" So when we can call a program safe? My personal definition is that a program is safe when it always gives the right output for the input it was designed for. Of course if you put water in your car won't make it run, the same way if you provide the wrong input to a program might end up in a wrong output. Getting back I do believe in the middle way.

tinco 12y ago

It's a shame he's put an introduction to monads smack down in the middle of this otherwise nice argument. If there was ever any objection to pure functional programming it would be that monads are complex and hard to learn and reason about. Putting an explanation of them with all sorts of mathematical terms is not helping the cause. Not only are monads not the only solution to doing I/O in a pure programming language (stream based I/O or functional reactive being another), they need not such a mathematical explanation. An I/O monad is a simple class modelling a box. There's two functions for it, one puts something that's not in a box in a box. The other function allows you to give it a function that is applied over the function in the box, without taking it out of the box (this is called a 'bind' operation). Note that there's no function to take the value out of the box. The trick is that the only thing that knows how to get the value out of the box is the VM itself. So its task is to at the end of your function, execute whatever function created your monad, and then execute all functions you gave it using the 'bind' functions sequentially over the returned value (which might include unwrapping more i/o monads). Since every bind function relies on the previous value of the monad, it can naturally only be executed sequentially. Note that this explanation does not explain monads either in full or very accurately, it's just one of the patterns that monads are used in, and hopefully gives you an idea about how it is that monads are used to enforce encapsulation and sequential execution of effectful functions.

mathenk2 12y ago

I must say that in all of my years, most every piece of source I've ever seen has been mostly [insert paradigm here]. OOP is "mostly" more times than not, same goes for FP. I would argue that "mostly" does work, and thankfully so, because nearly every service that you use throughout your day is a "mostly".

louthy 12y ago

"Computation is not just about functions, if computation was just about functions then quicksort and bubblesort would be the same because they're computing the same function. A computing device is something that goes through a sequence of states. What an assignment statement is doing is it is telling you "here is a new state". Functions alone don't solve the problems of programming because programs (on the whole) are non-deterministic; on the other hand, imperative programs are using assignment statements to compute functions, and that's silly." That exact phrase was said to Erik Meijer by Leslie Lamport when Erik interviewed Leslie. [1] It seems clear (if you take Leslie's word as gospel) that there is room for 'Mostly Functional'. That is, accept that your program goes through a series of states, but use pure functions to calculate those states. However, as an imperative programmer who's found Haskell over the past few years (thanks, in a large part to Erik Meijer), I happen to think that Haskell has it just about right. [1] http://channel9.msdn.com/Shows/Going+Deep/E2E-Erik-Meijer-and-Leslie-Lamport-Mathematical-Reasoning-and-Distributed-Systems http://channel9.msdn.com/Shows/Going+Deep/E2E-Erik-Meijer-an...