11 ms·

I think it's great that Keli is designed with IDE support in mind. However I believe that this is only half of the reason why FP still doesn't really break thro

I think it's great that Keli is designed with IDE support in mind. However I believe that this is only half of the reason why FP still doesn't really break through in the corporate world. The other reason is that many FP users are too enthusiastic about creating abstractions. This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. Maybe there should be a new edition of Clean Code written specifically for FP, to address this anti pattern. By the way this problem is not unique for FP, OOP suffered the same problem in the past. But the OOP community learned from its mistakes and now most developers know to 'prefer composition over inheritance', for instance.

bcrosby95 6y ago
I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to. Imperative languages have slowly been adopting some of these. 20 years ago you had people talking about how things like map and filter are confusing but nowadays most imperative languages have a version of it so obviously it isn't that confusing.
- mrkeen 6y ago
  I don't know if this counts as irony, but here goes: The killer feature of programming with pure functions is that you can guarantee the same output for the same input. If I were pushing this idea 5+ years ago, I would have said "Unfortunately you have to give up your comfortable for-loops and mutable variables* and learn about these weird maps and folds instead, but it's well worth the trade!" Fast-forward a few years and now maps and folds are everywhere in the mainstream (it's even recommended to use them over for-loops in many cases.) But we never got the same-input-same-output guarantee which was my reason for switching in the first place! * Even that's being too pessimistic. You can have your mutable cake and keep your guarantees, too: https://wiki.haskell.org/Monad/ST#A_few_simple_examples https://wiki.haskell.org/Monad/ST#A_few_simple_examples
- codygman 6y ago
  > I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to. What you describe as a problem sounds like a solution to me :) I'm curious whether you think there are imperative abstractions that could be used over the commonly used FP abstractions. That avenue of discussion sounds potentially valuable and fun to me :)
pgustafs 6y ago
The funny thing (that I'm sure you're aware of) is that 'prefer composition over inheritance' is an instance of 'prefer referential transparency', an idea from FP that you should always know what a variable is referencing. In OOP, this means that inheritance is bad because it's not always clear what functions are inherited and/or overloaded.
- nybble41 6y ago
  > an instance of 'prefer referential transparency', an idea from FP that you should always know what a variable is referencing. The idea of "referential transparency" is that you should always be able to substitute a reference for its definition, or vice-versa, without changing the behavior of the program. This implies both immutability (so that duplicating a value doesn't change the result) and purity (so producing the value has no side effects and gives the same result no matter how many times you do it). It has nothing to do with knowing what a variable is referencing. If anything, functional programming encourages the use of generic functions which don't know or care what their variables are referencing (parametric polymorphism).
pjmlp 6y ago
There is plenty of FP in the corporate world, the mistake that many FP advocates make is to make it a war of FP vs anything else. Meanwhile multiple paradigm languages keep getting most of the features that actually matter to Joe/Jane developer.
- DonaldPShimoda 6y ago
  > the mistake that many FP advocates make is to make it a war of FP vs anything else. I don't disagree with this (goodness knows there are plenty of functional purists who come across as religious zealots), but I think it's also worth mentioning that there's an opposing camp of people who are hard-set against ever considering FP for anything at all because they've bought fully into object orientation and stateful computation. Both solutions are well-suited to certain kinds of problems, and this opposition is well summarized by study of what is called the Expression Problem[0]. A good developer should know both paradigms (in addition to others!) and use each where it is best suited. [0] There are other issues than those discussed by the EP, but the EP is, I think, the most simple perspective of the distinction between OOP and FP. Edit: TIL you cannot escape an asterisk on HN. That's a bummer.
  - dashwav 6y ago
    In my experience, I have seen much less of the OOP-only group, especially in recent years. The general feel I have seen when communicating with other developers about this is that OOP is a tool and it's probably not the best one, but they are comfortable with it and it's problems. In general it feels like the overall feeling to FP is either "I don't have time to learn a new paradigm when my current one is working good enough to make the company money" or "I love using FP ideas in my code when it makes sense" I really feel like this is the ideal state for Software Development, as either side "winning" will only hurt the robustness of the environment.
    - DonaldPShimoda 6y ago
      Oh, sure! I didn't mean to suggest that there were as many as the only-pure-FP crowd, though I can see how my phrasing may have suggested as much. I just meant to bring up that there are people like that, who refuse to (consciously) adopt any amount of FP in their development. I have interacted with some myself. Most of them make arguments about, like, "People think in terms of state so FP is inherently a bad user experience" or something to that effect.
smithza 6y ago
I don't see a reason why some FP languages (e.g. lisp, or elisp) aren't IDE friendly. It might well be because where there is unpopularity, there is less effort to integrate, promote and maintain. If everything is a function and functions have positional parameters and everything named can be in a symbol table, why can't IDEs support (at least the basics of) FP languages?
- garmaine 6y ago
  Read the OP link.
- simias 6y ago
  I don't know much about modern IDEs because I don't use them, but I suspect that the very powerful lisp macro system can be an issue for good IDE integration. Think of something like the "loop" construct in Common Lisp: http://cl-cookbook.sourceforge.net/loop.html http://cl-cookbook.sourceforge.net/loop.html That's related with the problem the parent is talking about: it's very easy to create DSLs in in languages like Common Lisp, so people use them a lot. But for an IDE's parser, or even for a new coder discovering the codebase, it's pretty tricky to figure out what the code does. If somebody is ultra-familiar with Common Lisp but for some reason never learned how the loop construct worked they might be stumped when they encounter the following code: (loop for x in '(foo 2) thereis (numberp x)) What does that do exactly? What will it evaluate? What will it return? Which one of these symbols are special keywords and which one just refer to variables or functions? Meanwhile if you code in, say, C, the macro system is so crappy and clunky that you basically avoid it for anything complicated. Writing a similar LOOP macro in C would be an absolute shitshow (not that it prevented people from trying). As such C code tends to be much more verbose, but also much easier to follow if you know the core rules of the language.
  - smithza 6y ago
    Perhaps if Macros where not such a mainstay and powerful element of some FP langs (I am not arguing against them), this argument would not be so strong. Macros in C/C++ are difficult for IDEs to deal with too, save for constants. Seeing though that macros are near fundamental to some FP langs, I understand better the driver for the design of Keli.
cannabis_sam 6y ago
> An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. Do you have a code example? It would be interesting to see what this kind of code looks like. Personally, I find complaining about a ”fold over a monad” to be equivalent to complaining about an ”integer indexed loop over an array”. It’s a pretty straightforward implementation detail that have very little to do with your business logic. And business logic is far, far easier to model using ADTs (it’s literally just AND and OR, applied to data structures) than confounding object inheritance hierarchies. In fact, I’ve seen a lot more unnecessarily abstracted garbage (usually “design pattern” workarounds to limitations in the object model) in just about every oop based web framework I’ve worked with.
- scarmig 6y ago
  Well, we're used to the AbstractBeanHandlerFactoryFactories already. A slight discomfort of learning something new can seem much bigger when you're already acclimated to abuse.
  - strbean 6y ago
    Posting to name-drop SimpleBeanFactoryAwareAspectInstanceFactory
    - robocat 6y ago
      For details of the interfaces that the class inherits from, see: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/BeanFactoryAware.html https://docs.spring.io/spring-framework/docs/current/javadoc... https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/aop/aspectj/AspectInstanceFactory.html https://docs.spring.io/spring-framework/docs/current/javadoc...
dkarl 6y ago
> By the way this problem is not unique for FP, OOP suffered the same problem in the past. But the OOP community learned from its mistakes and now most developers know to 'prefer composition over inheritance', for instance. This is a great point. I think there are a lot of open questions about basic questions such as how ergonomic effect systems can become and which functional programming abstractions become intuitive through enough practice versus always feeling confusing. I think that stuff will shake out in a decade or two, and we will end up with much better styles to choose from. Who wants to program in 1990s/early 2000s Java style anymore? (Well, okay, a lot of people, but ignore them.) Nobody would judge OOP negatively based on that mess, because we know it can be done a lot better, and languages have evolved to cater to what we've learned. I think functional programming has a lot of evolution to come that will make it more ergonomic and more practical. It will be especially interesting to see what the cohort of programmers introduced to functional programming via modern front-end Javascript will do as some of them transition to the back end and look for statically typed languages that are better than Typescript.
- albertsondev 6y ago
  C#, mostly.
agumonkey 6y ago
FP abuse can lead to abstractitis which is sad but nothing the Corporate World doesn't like ... it was the land of J2EE after all.
bauerd 6y ago
>The other reason is that many FP users are too enthusiastic about creating abstractions. Elm lacks typeclasses, yet I've found this lack is what keeps a lot of libraries at bay that would have otherwise turned out overly abstract (see any mainstream Haskell library, really). It's the same reasoning behind Go: With great power comes great responsibility. At large, programmers shoot their own feet with powerful languages. Therefore, take away their guns, ie make languages less powerful. I still wish there was something like Elm, but tailored for backend/network programming: https://news.ycombinator.com/item?id=21909087 https://news.ycombinator.com/item?id=21909087
- 1-more 6y ago
  I started with Elm, then I started working through Learn You a Haskell. At first I thought the lack of typeclasses in Elm was a big missing piece, but now I see the potential for me to turn a programming problem into a little-too-philosophical debate about the nature of truth in the universe or some such. In other words leaving out typeclasses may help but not guarantee that I keep my eyes on the screen and off of my navel.
  - ghayes 6y ago
    The hard part with Elm’s lack of typeclasses is the lack of do notation. It’s pretty easy to end up in Elm’s version of “callback hell” where you’re nested several `andThen`s deep. And that’s for a language that doesn’t have `IO`. That said, I would love to try an “Elm on the backend” that specifically lacks features compared to Haskell.
    - krab 6y ago
      Scala seems quite close. It has a lot of features. But it's flexible enough that it doesn't "hurt" as much as writing production code in Haskell.
  - codygman 6y ago
    The advantage (or potential problem as you see it) is typeclasses encourage thinking about the meaning and behavior of what you are doing. For simple cases, the end result of no typeclasses can be compelling sometimes. For larger cases, taking away that useful tool to wrangle inherent complexity usually results in more complexity taking the form of gobs more simple code that obsfucates the task at hand.
solomonb 6y ago
Fold Over a Monad? You mean like: ``` ourReportAccumulatorFunc :: Monad m => m a -> m a -> m a ourReportAccumulatorFunc = blah ourFunc :: (Foldable t, Monad m) => t (m a) -> m a ourFunc = foldr ourReportAccumulatorFunc someUnitValue ``` Why do you think a fold would be hundreds of lines outside of the business logic?
- kitd 6y ago
  Quick tip: indent 4 spaces to get code formatting.
  - a1369209993 6y ago
    Actually it's only 2 spaces. Like this. Not this.
platz 6y ago
The reason why FP still doesn't really break through in the corporate world is a marketing failure, in the strictest sense of the word marketing, which means prioritizing the right features to target the right market. A large proportion of this talk is based on the book “Crossing the Chasm". The book was originally written for startups, and this talk adopts the book to an open source audience, especially Haskell developers. Gabriel Gonzalez – How to market Haskell to a mainstream programmer: https://www.youtube.com/watch?v=fNpsgTIpODA https://www.youtube.com/watch?v=fNpsgTIpODA
sfvisser 6y ago
> It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. This feels backwards to me. If I‘m new and join your team I’m much more likely to understand what a monad and a fold are than to understand your domain specific business objects. So if we are working for an insurance company and see the ‘Insurance’ type is an instance of Monad I now know a great deal about combing different insurance products into new derived ones. By reading a single word of code!
achr2 6y ago
I think the word abstraction here is overloaded. OOP is also fundamentally driven by abstractions. The difference is that FP abstractions are mathematical abstractions, while OOP starts with human-centric conceptual abstractions - the kind every two year old is taught. These are not the same in terms of cognitive understanding. I also use FP approaches all the time in OO languages (like C#), which I believe is more aligned with where the general purpose language world is moving.
- talaketu 6y ago
  Abstractions are drawn along different axes in both OOP and FP. The showcase example "Circle, Square, Rectangles are kinds of Shapes that have area" represents an abstraction that is present in the conceptual schema (aka Domain Model, aka Universe of Discourse, aka "problem space"), regardless of implementation style. Likewise, what you call "mathematical abstraction" (and I'd prefer to call a "implementation model") is present both in OOP (eg "visitor pattern, inheritance, facade") and in FP (eg "fold, pattern match, monad"). I don't really think the difficulty in groking "visitor" is much different from groking "fold".
adamkl 6y ago
> Maybe there should be a new edition of Clean Code written specifically for FP I’ve posted links to this work-in-progress book a few times in the past, but I’m going to do it again because I think it fits the description perfectly. Grokking Simplicity by Eric Normand [0] is a great book for introducing the premise behind FP in a pragmatic fashion. It doesn’t get bogged down in monads and type theory, just the benefits of pure functions and modeling applications as flows of data. All the code examples are in JavaScript, so it requires no prior knowledge of functional programming, and it does a great job of building things up from first principals while highlighting the benefits vs a more object oriented approach. It’s only half complete, with a nebulous completion date, but I’ve already purchased a copy, and it would the first book I’d recommend for any newcomer to FP (it’s already worth it just from the first half as far as I’m concerned). [0] https://www.manning.com/books/grokking-simplicity https://www.manning.com/books/grokking-simplicity
specialist 6y ago
"... too enthusiastic about creating abstractions." Like others, I'm eager to hear more of your thoughts. I also have a theory. A bit of a riff on Rob Pike's observation (IIRC): "Show me your data and I'll understand your code". Enterprise-y (corp IT) projects are data centric. Functional programming emphasizes flow-of-control over the data flow. Even more so than functional decompensation (imperative programming) and object-oriented. Donald Norman's notion of "affordances" applies. Any one can certainly "do COBOL" in Scheme, but pushing that rope requires uncommon insight and intention.

bcrosby95 6y ago

I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to. Imperative languages have slowly been adopting some of these. 20 years ago you had people talking about how things like map and filter are confusing but nowadays most imperative languages have a version of it so obviously it isn't that confusing.

mrkeen 6y ago
I don't know if this counts as irony, but here goes: The killer feature of programming with pure functions is that you can guarantee the same output for the same input. If I were pushing this idea 5+ years ago, I would have said "Unfortunately you have to give up your comfortable for-loops and mutable variables* and learn about these weird maps and folds instead, but it's well worth the trade!" Fast-forward a few years and now maps and folds are everywhere in the mainstream (it's even recommended to use them over for-loops in many cases.) But we never got the same-input-same-output guarantee which was my reason for switching in the first place! * Even that's being too pessimistic. You can have your mutable cake and keep your guarantees, too: https://wiki.haskell.org/Monad/ST#A_few_simple_examples https://wiki.haskell.org/Monad/ST#A_few_simple_examples
codygman 6y ago
> I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to. What you describe as a problem sounds like a solution to me :) I'm curious whether you think there are imperative abstractions that could be used over the commonly used FP abstractions. That avenue of discussion sounds potentially valuable and fun to me :)

pgustafs 6y ago

The funny thing (that I'm sure you're aware of) is that 'prefer composition over inheritance' is an instance of 'prefer referential transparency', an idea from FP that you should always know what a variable is referencing. In OOP, this means that inheritance is bad because it's not always clear what functions are inherited and/or overloaded.

nybble41 6y ago
> an instance of 'prefer referential transparency', an idea from FP that you should always know what a variable is referencing. The idea of "referential transparency" is that you should always be able to substitute a reference for its definition, or vice-versa, without changing the behavior of the program. This implies both immutability (so that duplicating a value doesn't change the result) and purity (so producing the value has no side effects and gives the same result no matter how many times you do it). It has nothing to do with knowing what a variable is referencing. If anything, functional programming encourages the use of generic functions which don't know or care what their variables are referencing (parametric polymorphism).

pjmlp 6y ago

There is plenty of FP in the corporate world, the mistake that many FP advocates make is to make it a war of FP vs anything else. Meanwhile multiple paradigm languages keep getting most of the features that actually matter to Joe/Jane developer.

DonaldPShimoda 6y ago
> the mistake that many FP advocates make is to make it a war of FP vs anything else. I don't disagree with this (goodness knows there are plenty of functional purists who come across as religious zealots), but I think it's also worth mentioning that there's an opposing camp of people who are hard-set against ever considering FP for anything at all because they've bought fully into object orientation and stateful computation. Both solutions are well-suited to certain kinds of problems, and this opposition is well summarized by study of what is called the Expression Problem[0]. A good developer should know both paradigms (in addition to others!) and use each where it is best suited. [0] There are other issues than those discussed by the EP, but the EP is, I think, the most simple perspective of the distinction between OOP and FP. Edit: TIL you cannot escape an asterisk on HN. That's a bummer.
- dashwav 6y ago
  In my experience, I have seen much less of the OOP-only group, especially in recent years. The general feel I have seen when communicating with other developers about this is that OOP is a tool and it's probably not the best one, but they are comfortable with it and it's problems. In general it feels like the overall feeling to FP is either "I don't have time to learn a new paradigm when my current one is working good enough to make the company money" or "I love using FP ideas in my code when it makes sense" I really feel like this is the ideal state for Software Development, as either side "winning" will only hurt the robustness of the environment.
  - DonaldPShimoda 6y ago
    Oh, sure! I didn't mean to suggest that there were as many as the only-pure-FP crowd, though I can see how my phrasing may have suggested as much. I just meant to bring up that there are people like that, who refuse to (consciously) adopt any amount of FP in their development. I have interacted with some myself. Most of them make arguments about, like, "People think in terms of state so FP is inherently a bad user experience" or something to that effect.

smithza 6y ago

I don't see a reason why some FP languages (e.g. lisp, or elisp) aren't IDE friendly. It might well be because where there is unpopularity, there is less effort to integrate, promote and maintain. If everything is a function and functions have positional parameters and everything named can be in a symbol table, why can't IDEs support (at least the basics of) FP languages?

garmaine 6y ago
Read the OP link.
simias 6y ago
I don't know much about modern IDEs because I don't use them, but I suspect that the very powerful lisp macro system can be an issue for good IDE integration. Think of something like the "loop" construct in Common Lisp: http://cl-cookbook.sourceforge.net/loop.html http://cl-cookbook.sourceforge.net/loop.html That's related with the problem the parent is talking about: it's very easy to create DSLs in in languages like Common Lisp, so people use them a lot. But for an IDE's parser, or even for a new coder discovering the codebase, it's pretty tricky to figure out what the code does. If somebody is ultra-familiar with Common Lisp but for some reason never learned how the loop construct worked they might be stumped when they encounter the following code: (loop for x in '(foo 2) thereis (numberp x)) What does that do exactly? What will it evaluate? What will it return? Which one of these symbols are special keywords and which one just refer to variables or functions? Meanwhile if you code in, say, C, the macro system is so crappy and clunky that you basically avoid it for anything complicated. Writing a similar LOOP macro in C would be an absolute shitshow (not that it prevented people from trying). As such C code tends to be much more verbose, but also much easier to follow if you know the core rules of the language.
- smithza 6y ago
  Perhaps if Macros where not such a mainstay and powerful element of some FP langs (I am not arguing against them), this argument would not be so strong. Macros in C/C++ are difficult for IDEs to deal with too, save for constants. Seeing though that macros are near fundamental to some FP langs, I understand better the driver for the design of Keli.

cannabis_sam 6y ago

> An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. Do you have a code example? It would be interesting to see what this kind of code looks like. Personally, I find complaining about a ”fold over a monad” to be equivalent to complaining about an ”integer indexed loop over an array”. It’s a pretty straightforward implementation detail that have very little to do with your business logic. And business logic is far, far easier to model using ADTs (it’s literally just AND and OR, applied to data structures) than confounding object inheritance hierarchies. In fact, I’ve seen a lot more unnecessarily abstracted garbage (usually “design pattern” workarounds to limitations in the object model) in just about every oop based web framework I’ve worked with.

scarmig 6y ago
Well, we're used to the AbstractBeanHandlerFactoryFactories already. A slight discomfort of learning something new can seem much bigger when you're already acclimated to abuse.
- strbean 6y ago
  Posting to name-drop SimpleBeanFactoryAwareAspectInstanceFactory
  - robocat 6y ago
    For details of the interfaces that the class inherits from, see: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/BeanFactoryAware.html https://docs.spring.io/spring-framework/docs/current/javadoc... https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/aop/aspectj/AspectInstanceFactory.html https://docs.spring.io/spring-framework/docs/current/javadoc...

dkarl 6y ago

> By the way this problem is not unique for FP, OOP suffered the same problem in the past. But the OOP community learned from its mistakes and now most developers know to 'prefer composition over inheritance', for instance. This is a great point. I think there are a lot of open questions about basic questions such as how ergonomic effect systems can become and which functional programming abstractions become intuitive through enough practice versus always feeling confusing. I think that stuff will shake out in a decade or two, and we will end up with much better styles to choose from. Who wants to program in 1990s/early 2000s Java style anymore? (Well, okay, a lot of people, but ignore them.) Nobody would judge OOP negatively based on that mess, because we know it can be done a lot better, and languages have evolved to cater to what we've learned. I think functional programming has a lot of evolution to come that will make it more ergonomic and more practical. It will be especially interesting to see what the cohort of programmers introduced to functional programming via modern front-end Javascript will do as some of them transition to the back end and look for statically typed languages that are better than Typescript.

albertsondev 6y ago
C#, mostly.

agumonkey 6y ago

FP abuse can lead to abstractitis which is sad but nothing the Corporate World doesn't like ... it was the land of J2EE after all.

bauerd 6y ago

>The other reason is that many FP users are too enthusiastic about creating abstractions. Elm lacks typeclasses, yet I've found this lack is what keeps a lot of libraries at bay that would have otherwise turned out overly abstract (see any mainstream Haskell library, really). It's the same reasoning behind Go: With great power comes great responsibility. At large, programmers shoot their own feet with powerful languages. Therefore, take away their guns, ie make languages less powerful. I still wish there was something like Elm, but tailored for backend/network programming: https://news.ycombinator.com/item?id=21909087 https://news.ycombinator.com/item?id=21909087

1-more 6y ago
I started with Elm, then I started working through Learn You a Haskell. At first I thought the lack of typeclasses in Elm was a big missing piece, but now I see the potential for me to turn a programming problem into a little-too-philosophical debate about the nature of truth in the universe or some such. In other words leaving out typeclasses may help but not guarantee that I keep my eyes on the screen and off of my navel.
- ghayes 6y ago
  The hard part with Elm’s lack of typeclasses is the lack of do notation. It’s pretty easy to end up in Elm’s version of “callback hell” where you’re nested several `andThen`s deep. And that’s for a language that doesn’t have `IO`. That said, I would love to try an “Elm on the backend” that specifically lacks features compared to Haskell.
  - krab 6y ago
    Scala seems quite close. It has a lot of features. But it's flexible enough that it doesn't "hurt" as much as writing production code in Haskell.
- codygman 6y ago
  The advantage (or potential problem as you see it) is typeclasses encourage thinking about the meaning and behavior of what you are doing. For simple cases, the end result of no typeclasses can be compelling sometimes. For larger cases, taking away that useful tool to wrangle inherent complexity usually results in more complexity taking the form of gobs more simple code that obsfucates the task at hand.

solomonb 6y ago

Fold Over a Monad? You mean like: ``` ourReportAccumulatorFunc :: Monad m => m a -> m a -> m a ourReportAccumulatorFunc = blah ourFunc :: (Foldable t, Monad m) => t (m a) -> m a ourFunc = foldr ourReportAccumulatorFunc someUnitValue ``` Why do you think a fold would be hundreds of lines outside of the business logic?

kitd 6y ago
Quick tip: indent 4 spaces to get code formatting.
- a1369209993 6y ago
  Actually it's only 2 spaces. Like this. Not this.

platz 6y ago

The reason why FP still doesn't really break through in the corporate world is a marketing failure, in the strictest sense of the word marketing, which means prioritizing the right features to target the right market. A large proportion of this talk is based on the book “Crossing the Chasm". The book was originally written for startups, and this talk adopts the book to an open source audience, especially Haskell developers. Gabriel Gonzalez – How to market Haskell to a mainstream programmer: https://www.youtube.com/watch?v=fNpsgTIpODA https://www.youtube.com/watch?v=fNpsgTIpODA

sfvisser 6y ago

> It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. This feels backwards to me. If I‘m new and join your team I’m much more likely to understand what a monad and a fold are than to understand your domain specific business objects. So if we are working for an insurance company and see the ‘Insurance’ type is an instance of Monad I now know a great deal about combing different insurance products into new derived ones. By reading a single word of code!

achr2 6y ago

I think the word abstraction here is overloaded. OOP is also fundamentally driven by abstractions. The difference is that FP abstractions are mathematical abstractions, while OOP starts with human-centric conceptual abstractions - the kind every two year old is taught. These are not the same in terms of cognitive understanding. I also use FP approaches all the time in OO languages (like C#), which I believe is more aligned with where the general purpose language world is moving.

talaketu 6y ago
Abstractions are drawn along different axes in both OOP and FP. The showcase example "Circle, Square, Rectangles are kinds of Shapes that have area" represents an abstraction that is present in the conceptual schema (aka Domain Model, aka Universe of Discourse, aka "problem space"), regardless of implementation style. Likewise, what you call "mathematical abstraction" (and I'd prefer to call a "implementation model") is present both in OOP (eg "visitor pattern, inheritance, facade") and in FP (eg "fold, pattern match, monad"). I don't really think the difficulty in groking "visitor" is much different from groking "fold".

adamkl 6y ago

> Maybe there should be a new edition of Clean Code written specifically for FP I’ve posted links to this work-in-progress book a few times in the past, but I’m going to do it again because I think it fits the description perfectly. Grokking Simplicity by Eric Normand [0] is a great book for introducing the premise behind FP in a pragmatic fashion. It doesn’t get bogged down in monads and type theory, just the benefits of pure functions and modeling applications as flows of data. All the code examples are in JavaScript, so it requires no prior knowledge of functional programming, and it does a great job of building things up from first principals while highlighting the benefits vs a more object oriented approach. It’s only half complete, with a nebulous completion date, but I’ve already purchased a copy, and it would the first book I’d recommend for any newcomer to FP (it’s already worth it just from the first half as far as I’m concerned). [0] https://www.manning.com/books/grokking-simplicity https://www.manning.com/books/grokking-simplicity

specialist 6y ago

"... too enthusiastic about creating abstractions." Like others, I'm eager to hear more of your thoughts. I also have a theory. A bit of a riff on Rob Pike's observation (IIRC): "Show me your data and I'll understand your code". Enterprise-y (corp IT) projects are data centric. Functional programming emphasizes flow-of-control over the data flow. Even more so than functional decompensation (imperative programming) and object-oriented. Donald Norman's notion of "affordances" applies. Any one can certainly "do COBOL" in Scheme, but pushing that rope requires uncommon insight and intention.