7 ms·
Functional Programming Isn't the Answer (2014)
- smt88 10y agoTitle is a bit bait-y. A better title might be, "Functional Programming isn't enough". tl;dr He says that FP is good, but you can still write bad functional code (which is fairly obvious).
- catnaroek 10y agoAnd you can write good non-functional code as well.
- deleted 10y ago[deleted]
- hcs 10y agoOr "Functional Programming isn't the Question". His later discussion of Free monad is pretty interesting: http://degoes.net/articles/modern-fp http://degoes.net/articles/modern-fp
- deleted 10y ago[deleted]
- Noseshine 10y agoOverall though it's a good article making a good point and doing so quite well IMHO. It's like science research: The point of individual studies or here, articles about something, isn't to finish the topic once and for all in one stroke. The criticism of either (studies or articles) often seems to be based on attempts to find what a study/article does not provide instead of looking at what it does. Obviously, the stuff not in it far exceeds the stuff that is, so I see a lot of such criticism missing the mark.
- nilved 10y agoI don't understand this post. "With that said, brace yourself, and take a look at my contrived, deliberately-obtuse strawman implementation of Quick Sort:"
- Noseshine 10y ago> I don't understand this post. The point is, as the author states quite clearly, that it's not enough to say "I wrote it in FP".
- cwyers 10y agoWell, he really showed all those strawmen, didn't he.
- AnimalMuppet 10y agoI don't think that "FP as religion" is a total strawman. I've seen people who seemed to have pretty much a religious fervor for FP. On this site, even. "Writing it in a functional language means it's FP" might be a bit more of a strawman, however.
- KirinDave 10y agoIt is a common conversational tactic to dismiss profession interest and enthusiasm as "religion." I doubt Degoes would appreciate the phrase "religion" used as a disparagement to defend his work by the way. He's shown he's willing to take a lot of flack to defend religious people's dignity and needs.
- twblalock 10y agoWell then, it's a good thing that the author of the article did not simply dismiss it, but rather engaged with it and provided examples and argumentation.
- AnimalMuppet 10y ago
- catnaroek 10y ago“Strong types” (a term that hardly means anything, now that everyone and their dog claims their favorite language is “strongly typed”) don't have anything to do with functional programming. And the fact that algebraic data types were originally used in functional languages is just a historical accident.
- danbruc 10y agoStrongly typed was never really a useful description of any language. Eric Lippert nicely points out [1] that descriptions like statically typed, type safe and memory safe are a lot more useful when one wants to compare programming languages than those fuzzy terms strongly and weakly typed. [1] https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language/ https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-...
- catnaroek 10y agoA more useful term is “sound”: does the type system protect the language's basic abstractions? (0) Standard ML: Yes. (1) Java: No, but dynamic checks are used to patch the type soundness holes. (2) C: No, and if you do anything wrong, may God help you.
- danbruc 10y agoIf you don't use casts, then you should come pretty close to soundness, at least in Java. Array covariance is really the only exception I can ad hoc think of. I am not really sure of C without casts.
- wcrichton 10y agoI also find it strongly problematic that functional languages with customizable infix operators (e.g. Haskell and OCaml) have lines of code like this: whileM ((<=) <$> readLeftIdx <*> readRightIdx) $ do And, from what I've seen in a few Haskell codebases, this isn't all that uncommon. I refuse to believe that there's not a better way to express these kinds of programming patterns. I recognize that applicatives, functors, etc. have their value in creating well-engineered interfaces, but when they manifest themselves in obscure operators, it feels self-defeating.
- nilkn 10y agoWhile Haskell does have customizable infix operators which can be overused and abused, that line isn't a good example of the problem in my opinion. The three infix operators there ($, <$>, and <*>) are all extremely common in Haskell code and are built-in to the language. Every competent Haskell programmer will be intimately familiar with those three operators. The problem arises when new libraries introduce new infix operators. I find this highly annoying and almost always consider it a code-smell. So honestly we're in agreement in general, just not with that particular example. I consider those to be basically the "arithmetic operations" of function application. Considering the entire language is based on function composition and application, I don't think it's a bad thing for an economical notation to be used.
- bweitzman 10y agoWhile they may be common, they're not actually built into the language. They're just regular functions.
- deleted 10y ago[deleted]
- chadaustin 10y agoSure, they're library functions, but they're also specified in the haskell 2010 spec. That makes them built-in from a practical perspective.
- 10y ago
- tracker1 10y agotl;dr - You can write bad, hard to understand code in any paradigm (or language). That said, I tend to prefer functional patterns over OO... there are times where OO/classes as a syntax expression is easier, I would say in most cases, it isn't. It really depends on what you're trying to create, where and how.
- lelf 10y agoSorry for trolling, but sometimes I just have to. “Look at my intentionally non-thread-safe, spaghetti imperative implementation. It sucks! So FP sucks.”
- twblalock 10y agoYou're missing the point. The author used that example to demonstrate that just using FP languages is not enough to ensure good code, because it is possible to write bad code in FP languages. Therefore, FP programming languages are not going to guarantee you good code by themselves. They will only get you good code if you use them to write good code. By the way, the author never said "FP sucks," and that's a very uncharitable and unreasonable interpretation of the argument. From the article: > My view is that although FP makes it easier to write good code, just because something’s functional, or even “purely functional”, doesn’t necessarily mean it’s any good. Stated differently, as software engineers trying to improve our craft, we shouldn’t latch onto or defend something just because it’s “functional” or “purely functional”. Although it’s possible to write good code using techniques from functional programming, it’s also possible to write bad code. FP doesn’t protect us. We need a different measure for “good code” than just “functional”. You may think that "FP guarantees good code" is a strawman argument, but it isn't. A quick search of this site will turn up people who make that very argument. It's useful to have a realistic corrective to the pseudo-religious fervor of some FP proponents, and this article provides that.
- the_af 10y agoBut isn't that arguing against a strawman? Nobody is arguing that FP code is automatically good by virtue of being written in an FP-oriented language. For example, you can write a beautiful algorithm that solves the wrong problem. No language will help you with that. Or you can write a program in language X that ignores every convention or practice -- you can write code that makes an extraordinary effort at subverting the type system, for example -- but that's more of an argument against your understanding of X. I do agree with the author that FP, good as it is, is not enough. That's not an argument against FP, it's an argument in favor of devising even better tools, practices and the theoretical underpinnings for building correct software.
- RcouF1uZ4gsC 10y agoI love how the author gives comprehension and composability as goals for code over adherence to any dogma. One interesting note is that the quicksort code in Haskel illustrates a very important point about code evolution. Suppose you wanted to avoid the worst case quadratic behavior. There is not a good evolution strategy that goes through median of 3 pivot, median of 3 pivot with randomization, and introsort. With the equivalent imperative code, the evolution strategy is pretty easy by just adding a few if statements.
- smt88 10y agoComprehension and composability are dogmatic. There are people who criticize code that isn't concise enough, even if being concise would make it harder to comprehend. Using lots of magic or overly-terse languages are also valued by some people and not by others. Composability is also something that is totally alien to large sections of the OOP community. If you've ever dealt with a legacy PHP or Java framework, you'll know what I mean. They heavily use inheritance over composability.
- p4wnc6 10y agoI read the title and I think, "OK, FP's not the answer ... what's the problem it's not the answer to?" I think the problem is dysfunctional workplaces in general -- things like open plan office dogma, "full stack" destroying the value held in specialization of labor and compartmentalization, everyone trying to data mine "insights" that are really serving political agendas instead of customers, users, clients, or really even shareholders, and so on. Writing good software systems inside a bureaucratic system constantly throwing wrenches into the gears is really hard, and just changing the language paradigm, even if the paradigm comes with really great tools for correctness and quality enforcement, generally isn't enough to overcome badly structured, uncreative, un-turn-off-ably oversaturated with "collaboration" working environments. I love FP and hope I get to use it more in the future. I also love simpler OO or even module-oriented programming with lots of mutation. You can write great software in any of these paradigms, and you can have great teams. But I think first we all have to unite and utterly refuse the horrible working conditions pervading the industry. Put our debates about language or tool superiority to the side and see if we can improve functionality and basic humanity-affirming healthiness of workplaces and team structures.
- ivanjr0 10y agoQuestion: I totally agree that the second version is much cleaner. But, how does the performance of the two compare in Haskell? "Premature optimization is the root of all evil" and all that. But, a sorting routine is something everyone would expect to be as efficient as possible, right? (Maybe it was just for the sake of the example?) I heard 1 or 2 things about Haskell being lazy, etc. Does it makes the second version less inefficient than it looks?
- supercarrot 10y agosecond version is super slow. it's always quadratic, no matter what input it is. http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort http://stackoverflow.com/questions/7717691/why-is-the-minima...
- deleted 10y ago[deleted]
- abc_lisper 10y agoThat rouge FP implementation would get negative credits in a good FP class. At least, that's what our TA used to do.
- ridiculous_fish 10y ago> well, filter should really be replaced by partition, because filter destroys information; use of filter requires manual negation of the boolean predicate < p, which represents duplicated information content More seriously, `>=` is not the correct negation of `<` due to NaNs. The code as written will return a list with all NaNs removed, because NaNs are neither greater than nor less than any other number. It's interesting that an in-place sort that uses only comparisons and swaps cannot have bugs like duplicated or removed elements, regardless of any bugs in the algorithm or comparison predicate. The "shuffle via sort by random" approach [1] is a nicely insane test case. [1] http://javascript.about.com/library/blsort2.htm http://javascript.about.com/library/blsort2.htm
- wereHamster 10y agoYou only have to deal with NaNs if they are valid values of the type the array is made out of. In Haskell an 'Int' can not be NaN. Only types of the 'RealFloat' class can be NaN.
- hughw 10y agoTo make your case, please don't set up one side as a "religion".
- LeanderK 10y agoWhile i could criticise some points and recognise others, i want to add the following: Function Programming is fun (mostly ;)) and i think even in corporate setting that is a valid argument. It may not the the most important, but it is one nonetheless. Happy developers are more productive in my experience.
- dhab 10y agoI agree with the author that blind religious devotion to a paradigm in not healthy. I see FP and imperative as complimentary and we also see that manifesting by FP idioms being baked into traditionally imperative languages. Use the tool where it shines. Here is a doc that I have bookmarked for Haskell: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md https://github.com/Gabriel439/post-rfc/blob/master/sotu.md
- gtf21 10y agoDespite the (somewhat heated) discussion below, this article is actually quite pointless. Having good tools does not make you a good craftsman, I'm not sure this is contentious. I don't think that anyone would argue that (good tools => good craftsman) is valid. This isn't an argument against FP, just the statement that FP cannot transmute a bad programmer into a good one.
- icalc 10y agoIt's simple and effective. It's not design to answer everything.
- threatofrain 10y agoI think it's a bit of a mismatch when people talk about maintainability and comprehensibility, but only on very local levels, and the examples they bring up are also very local. System maintainability and comprehensibility owe more to architecture than to local readability. It doesn't matter if local code is completely functional, or if Scala secretly uses imperative algorithms underneath. What matters is if the code module / division / unit is keeping its contract or API with respect to the rest of the system, because if it is, then you can actually hope to comprehend your system at a useful level of abstraction. Local vs system comprehensibility are not in tension, but an unfair amount of focus has been placed on local clarity. So a question I'd have is what architectural solutions to some problem domain are natural and special to the functional style. To that end, it's more interesting to see a skeleton project tackling a generic problem, as an inspiration for a generic architecture, than to talk about whether it's possible to write locally bad code with an FP language.
- deleted 10y ago[deleted]