15 ms·

While I can understand some of the benefits of functional programming within a single sub-system, or within academic research, I struggle to understand how pure

by mreome 8y ago

While I can understand some of the benefits of functional programming within a single sub-system, or within academic research, I struggle to understand how pure functional programming can address the need for the large amounts of state information and abstraction layers required for a large scale system. I work with systems where (large/numerous) sub components require very specialized domain knowledge to understand internally, so multiple levels of black-box abstraction are required to integrate/interact with the sub components. Additionally, both the client systems and the sub components may have huge amounts of persistent state information. Could you suggest any resources that might help me understand how this can be accomplished in a pure functional paradigm? Something that assumes only a casual understanding of functional programming would be especially helpful.

TheDong 8y ago
> Do you have anything that explains this complex topic? > Something that assumes I don't know anything about the pre-requisite topic would be helpful Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms. Me saying "Monads can help with state abstractions" doesn't help you. The fact that large non-trivial applications have been written in haskell should be enough evidence that this is possible. The fact that the majority of people involved in such endeavors have claimed that it made their code safer and easier to refactor and had relatively few bugs should be enough evidence that it's a good idea. The fact that those who decry it more often than not do not know the subject should give their criticisms no weight. I don't see why you need any more evidence that you should simply learn functional programming so that you may first-hand answer your own question.
- kbenson 8y ago
  > Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms. > I don't see why you need any more evidence that you should simply learn functional programming so that you may first-hand answer your own question. It is possible to interpret the GP comment as a request for good resources to learn FP. You seem like you could probably point one or two out. Since they've already expressed a desire to understand, that might be more beneficial for them than the equivalent of "just do it".
  - mreome 8y ago
    Thank you. Basically I was looking for the functional-programming equivalent to the OOP factory-equipment analogy, or asking if such an analogy does/can exist (if it can't, the why might also be a valuable explanation). That analogy can be used to explain the main ideas behind encapsulation, interfaces, and internal state, and why they are valuable, before having any understanding of how those are implemented in practice, and even without any programming knowledge at all. So far everything I've found on functional programming starts with implementation details and provides no initial framework for understanding the broad-strokes of organisation and value proposition.
    - lavayya 8y ago
      You might like Rich Hickey's talks, especially "The value of values", "The language of the System", and the 2018 conj key note. The Talk in transducers also has a nice analogy: the conveyor belt.
- mreome 8y ago
  Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms. If I didn't know what 'functional' was in this context, I'd be entirely convinced you were tying to convert me to your religion with that statement. This attitude from the functional-programming community is the main reason I have avoided learning more. I was asking a legitimate question and instead of providing something useful you decided to assume I don't know anything about the pre-requisite topic and spout verbose dogma at me that does nothing but attempt, and fail, to make you appear intelligent.
scns 8y ago
Maybe the blogpost "Functional architecture is ports and adapters" by Mark Seemann may be of help to you. "fsharp for fun and profit" by Scott Wlashin is really approachable. Cant post links since on mobile.
- mreome 8y ago
  Thanks, I will take look at both of those.
auganov 8y ago
Before you spend some time doing mostly functional it's easy to ignore just how much meaningless state you might have floating around. You're right that any non-trivial endeavour will necessitate quite a lot of information being kept around. But in my experience most of the state you produce in languages that don't support functional patterns isn't even related to the domain. You're often forced to put thing into variables, objects and all sorts of things that might not make a lot of sense.
- zbentley 8y ago
  The original article wasn't talking about issues caused by storing too much program state in in-memory structures (variables/objects) though. It was talking about issues introduced by interactions with an external stateful system--a database. Bugs related to in-memory state that gets out of whack are definitely a hassle--especially in multithreaded situations--but are, in my experience, only the tip of the iceberg. Once you have that kind of issue under control (either by choice of platform, discipline, linting, or unit testing) there is a huge category of problems that can arise from the remaining surface, categorized loosely as "as soon as your code leaves its own memory space, it's part of a distributed system, with all the hassles that entails". Proclaiming that FP techniques resolve or even significantly ease that category of issue seems debatable at best, and a false promise at worst.

by mreome 8y ago

TheDong 8y ago

> Do you have anything that explains this complex topic? > Something that assumes I don't know anything about the pre-requisite topic would be helpful Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms. Me saying "Monads can help with state abstractions" doesn't help you. The fact that large non-trivial applications have been written in haskell should be enough evidence that this is possible. The fact that the majority of people involved in such endeavors have claimed that it made their code safer and easier to refactor and had relatively few bugs should be enough evidence that it's a good idea. The fact that those who decry it more often than not do not know the subject should give their criticisms no weight. I don't see why you need any more evidence that you should simply learn functional programming so that you may first-hand answer your own question.

kbenson 8y ago
> Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms. > I don't see why you need any more evidence that you should simply learn functional programming so that you may first-hand answer your own question. It is possible to interpret the GP comment as a request for good resources to learn FP. You seem like you could probably point one or two out. Since they've already expressed a desire to understand, that might be more beneficial for them than the equivalent of "just do it".
- mreome 8y ago
  Thank you. Basically I was looking for the functional-programming equivalent to the OOP factory-equipment analogy, or asking if such an analogy does/can exist (if it can't, the why might also be a valuable explanation). That analogy can be used to explain the main ideas behind encapsulation, interfaces, and internal state, and why they are valuable, before having any understanding of how those are implemented in practice, and even without any programming knowledge at all. So far everything I've found on functional programming starts with implementation details and provides no initial framework for understanding the broad-strokes of organisation and value proposition.
  - lavayya 8y ago
    You might like Rich Hickey's talks, especially "The value of values", "The language of the System", and the 2018 conj key note. The Talk in transducers also has a nice analogy: the conveyor belt.
mreome 8y ago
Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms. If I didn't know what 'functional' was in this context, I'd be entirely convinced you were tying to convert me to your religion with that statement. This attitude from the functional-programming community is the main reason I have avoided learning more. I was asking a legitimate question and instead of providing something useful you decided to assume I don't know anything about the pre-requisite topic and spout verbose dogma at me that does nothing but attempt, and fail, to make you appear intelligent.

scns 8y ago

Maybe the blogpost "Functional architecture is ports and adapters" by Mark Seemann may be of help to you. "fsharp for fun and profit" by Scott Wlashin is really approachable. Cant post links since on mobile.

mreome 8y ago
Thanks, I will take look at both of those.

auganov 8y ago

Before you spend some time doing mostly functional it's easy to ignore just how much meaningless state you might have floating around. You're right that any non-trivial endeavour will necessitate quite a lot of information being kept around. But in my experience most of the state you produce in languages that don't support functional patterns isn't even related to the domain. You're often forced to put thing into variables, objects and all sorts of things that might not make a lot of sense.

zbentley 8y ago
The original article wasn't talking about issues caused by storing too much program state in in-memory structures (variables/objects) though. It was talking about issues introduced by interactions with an external stateful system--a database. Bugs related to in-memory state that gets out of whack are definitely a hassle--especially in multithreaded situations--but are, in my experience, only the tip of the iceberg. Once you have that kind of issue under control (either by choice of platform, discipline, linting, or unit testing) there is a huge category of problems that can arise from the remaining surface, categorized loosely as "as soon as your code leaves its own memory space, it's part of a distributed system, with all the hassles that entails". Proclaiming that FP techniques resolve or even significantly ease that category of issue seems debatable at best, and a false promise at worst.