“Mostly functional” programming does not work
queue.acm.org
“Mostly functional” programming does not work
1–10 of 58 posts
Re: “Mostly functional” programming does not work
#2Another monad introduction.
Re: “Mostly functional” programming does not work
#3The 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.
Re: “Mostly functional” programming does not work
#4"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.
Re: “Mostly functional” programming does not work
#5To 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.
Re: “Mostly functional” programming does not work
#6Evidently "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.
Re: “Mostly functional” programming does not work
#7The 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?
Re: “Mostly functional” programming does not work
#8His 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-abou...
Re: “Mostly functional” programming does not work
#9To 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 promo…
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.
Re: “Mostly functional” programming does not work
#10Another monad introduction.
[deleted]