4 ms·

>Most of the time, when you are working using functional programming you are implementing the business vocabulary. >Here is where building a vocabulary that re

by r2dnb 9y ago

>Most of the time, when you are working using functional programming you are implementing the business vocabulary. >Here is where building a vocabulary that represents the business subjects pays off. Change now is a definition-change and, unless the business is pivoting, definitions rarely change; instead, they have constant adjustments. Functional shines in creating a vocabulary and having this adaptability. I tend to use the same arguments to make the case against FP for business modelling. I tend to say that FP is good at adding new operations to existing things, while OOP is good at adding new things to existing operations. However when Software Development is used to model a business - as it should be for reasons you accurately explained - the reality it meets is the one of the business world in which business needs evolve and requirements get added. You start by supporting local groceries and then you grow to support global supermarket chains. OOP is more suited to model business because you can naturally extend existing types and apply existing operations to them (ie. pass a supermarket everywhere a shop was expected + things such as polymorphism). In FP, every time you add a type, you need to add switch cases to your existing operations (at best), or redefine them create / new ones (at worse), since the ubiquitous assumption of FP development is immutability and known types. I'd be curious to know how you approach this conflict in a way that makes FP work in real world business modelling which needs to be extension-oriented. It seems to me that the more operations using a type you have, the more you will be screwed when you want to extend this type. The only reason I can see this wouldn't be the case would be to say that I approach FP with the wrong philosophy and that there is no such things as extending types in FP. But in this case I'd question if FP modelling really is the best tool to model real world business for which it is natural to define things as extensions of other things.

nonabelion 9y ago
>I tend to say that FP is good at adding new operations to existing things, while OOP is good at adding new things to existing operations. What you described is exactly the _expression problem_. And it has some solution. See https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...
- r2dnb 9y ago
  Thanks for the reference, this is indeed all about it. The solutions mentioned are unnatural patches to the respective shortcomings of FP and OOP. It's ok to patch corner cases to complete the last 15% of a job for which the tool was a perfect fit for the first 85%, however the first patch should be to use the right tool for the right job. The functional and strongly typed value proposition of FP is very appealing on paper but only shines when you have a level of certainty and knowledge on requirements that you typically do not have in real world software development. OOP by design embraces this uncertainty (but as a trade off is less assertive on correctness than FP). That being said, certain businesses do not have a high level of uncertainty in their developments while correctness is a big deal for them (banks, scientific researchers, etc...). It makes sense for them to reinvest this slack in correctness. However, for those iterating consumer facing products (which represents the majority of developments), OOP modelling usually is the way to go. Because of the expression problem (which should probably be called the expression dilemma to better highlight the fact that the assessment should be continuous and situational rather than ideological and/or philosophical)
jorgeleo 9y ago
What you are mentioning is one of the hardest things to do when moving into FP. "OOP is more suited to model business because you can naturally extend existing types and apply existing operations to them (ie. pass a supermarket everywhere a shop was expected + things such as polymorphism)" The reason why you feel is more suited is because you are thinking in an object oriented way. It is not a bad thing, but it is not functional. "... extend existing types and apply existing operations to them". This means you have things, and you do things to them. This is the OOP way, not the FP way. In FP the things are immutable, so you don't do things to them because they cannot change; instead, you create new things out of what you have. In OOP this is what you have, this is what it can do, and you put all the gears (or objects) together and you get your engine. In FP you have pipes, this is what I have and if I put it through this pipe it becomes something else. When a local shop there is a sale, there is a function that takes a bunch of arguments and produces something called a sale, Maybe is the total, maybe is a tuple with the different pieces of the sale. When you move that to a supermarket, then the question is: how what the shop owner calls a sale in the local shop is different from what the supermarket owner calls a sale? How my vocabulary changed? for a lot of things, you will see that the meaning is the same, just over more data; and also, there are new words that didn't exist in the smaller context. A sale is in both cases the sum of the quantity multiplied by the price of the groceries, apply the tax, spit out the result. But maybe the meaning of Tax changed, instead of been a fixed percent, it needs to be the lookup in a table depending on where the supermarket is. If you need to constantly add switch cases, then probably you are using a functional language using an OOP mentality. The way that I have introducing FP to people is using Excel. Think on this syntax: A1: 1 B1: 2 C1: A1 + B2 You don't need new cells, C1 does not mean the same thing and the formula have to change... the formula or is it the function? When you model the real world, you can focus on the objects, map them to types, and go from there. Or you can focus on the meaning of the words, then you need just a few types, see how those meanings compound, and go from there. "But in this case I'd question if FP modelling really is the best tool to model real world business for which it is natural to define things as extensions of other things." I agree, FP is bad at extending things... but it is not FP fault that you see the world as things that need to be extended. A middle step between what you are saying and FP will be Flow Programming (https://en.wikipedia.org/wiki/Flow-based_programming https://en.wikipedia.org/wiki/Flow-based_programming). It is not FP, nor OOP, but somewhere in between.

by r2dnb 9y ago

nonabelion 9y ago

>I tend to say that FP is good at adding new operations to existing things, while OOP is good at adding new things to existing operations. What you described is exactly the _expression problem_. And it has some solution. See https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...

r2dnb 9y ago
Thanks for the reference, this is indeed all about it. The solutions mentioned are unnatural patches to the respective shortcomings of FP and OOP. It's ok to patch corner cases to complete the last 15% of a job for which the tool was a perfect fit for the first 85%, however the first patch should be to use the right tool for the right job. The functional and strongly typed value proposition of FP is very appealing on paper but only shines when you have a level of certainty and knowledge on requirements that you typically do not have in real world software development. OOP by design embraces this uncertainty (but as a trade off is less assertive on correctness than FP). That being said, certain businesses do not have a high level of uncertainty in their developments while correctness is a big deal for them (banks, scientific researchers, etc...). It makes sense for them to reinvest this slack in correctness. However, for those iterating consumer facing products (which represents the majority of developments), OOP modelling usually is the way to go. Because of the expression problem (which should probably be called the expression dilemma to better highlight the fact that the assessment should be continuous and situational rather than ideological and/or philosophical)

jorgeleo 9y ago

What you are mentioning is one of the hardest things to do when moving into FP. "OOP is more suited to model business because you can naturally extend existing types and apply existing operations to them (ie. pass a supermarket everywhere a shop was expected + things such as polymorphism)" The reason why you feel is more suited is because you are thinking in an object oriented way. It is not a bad thing, but it is not functional. "... extend existing types and apply existing operations to them". This means you have things, and you do things to them. This is the OOP way, not the FP way. In FP the things are immutable, so you don't do things to them because they cannot change; instead, you create new things out of what you have. In OOP this is what you have, this is what it can do, and you put all the gears (or objects) together and you get your engine. In FP you have pipes, this is what I have and if I put it through this pipe it becomes something else. When a local shop there is a sale, there is a function that takes a bunch of arguments and produces something called a sale, Maybe is the total, maybe is a tuple with the different pieces of the sale. When you move that to a supermarket, then the question is: how what the shop owner calls a sale in the local shop is different from what the supermarket owner calls a sale? How my vocabulary changed? for a lot of things, you will see that the meaning is the same, just over more data; and also, there are new words that didn't exist in the smaller context. A sale is in both cases the sum of the quantity multiplied by the price of the groceries, apply the tax, spit out the result. But maybe the meaning of Tax changed, instead of been a fixed percent, it needs to be the lookup in a table depending on where the supermarket is. If you need to constantly add switch cases, then probably you are using a functional language using an OOP mentality. The way that I have introducing FP to people is using Excel. Think on this syntax: A1: 1 B1: 2 C1: A1 + B2 You don't need new cells, C1 does not mean the same thing and the formula have to change... the formula or is it the function? When you model the real world, you can focus on the objects, map them to types, and go from there. Or you can focus on the meaning of the words, then you need just a few types, see how those meanings compound, and go from there. "But in this case I'd question if FP modelling really is the best tool to model real world business for which it is natural to define things as extensions of other things." I agree, FP is bad at extending things... but it is not FP fault that you see the world as things that need to be extended. A middle step between what you are saying and FP will be Flow Programming (https://en.wikipedia.org/wiki/Flow-based_programming https://en.wikipedia.org/wiki/Flow-based_programming). It is not FP, nor OOP, but somewhere in between.