4 ms·

Mutation is a problem that every program must deal with. Map/filter/reduce and company are just a good way to isolate mutation. Your entire application doesn't

by Touche 12y ago

Mutation is a problem that every program must deal with. Map/filter/reduce and company are just a good way to isolate mutation. Your entire application doesn't need be functional to benefit from some functional behavior. Likewise, composability improves readability and isolates code into small parts that can be assembled. This is beneficial to large applications as well. You seem to indicate that concurrency is the only problem worth investing in with large applications but they are not mutational exclusive. Erlang does a good job of both, for example.

AnimalMuppet 12y ago
I never said that concurrency was the only problem with large applications. I never even meant to imply it. For example, one of the big problems is circular dependencies. Go solves this by explicitly prohibiting it - your dependencies must form a directed acyclic graph. You therefore have to work out a solution the moment you would want to introduce a circular dependency. You can't introduce even the first one. That means that you can never build up the kind of nightmarish hairball that large projects often turn into. Is it painful to have to prevent circular dependencies all along the line? Certainly. But it prevents more pain later. Now: Do I know that functional programming, map/filter/reduce, and avoiding mutation cause problems at scale? No, I don't. On the other hand, I doubt many projects have been built using FP at this scale, so one can't assert that FP will scale this far.
- MichaelGG 12y ago
  What are some other things? Having no circular dependencies doesn't seem very novel or something that requires much of a tradeoff. Although I will admit I am more of a fan of it after having used it (F#, which requires tight opt-in to mutual references), than before having used it (at which point I would have said "just don't do that").

by Touche 12y ago

AnimalMuppet 12y ago

I never said that concurrency was the only problem with large applications. I never even meant to imply it. For example, one of the big problems is circular dependencies. Go solves this by explicitly prohibiting it - your dependencies must form a directed acyclic graph. You therefore have to work out a solution the moment you would want to introduce a circular dependency. You can't introduce even the first one. That means that you can never build up the kind of nightmarish hairball that large projects often turn into. Is it painful to have to prevent circular dependencies all along the line? Certainly. But it prevents more pain later. Now: Do I know that functional programming, map/filter/reduce, and avoiding mutation cause problems at scale? No, I don't. On the other hand, I doubt many projects have been built using FP at this scale, so one can't assert that FP will scale this far.

MichaelGG 12y ago
What are some other things? Having no circular dependencies doesn't seem very novel or something that requires much of a tradeoff. Although I will admit I am more of a fan of it after having used it (F#, which requires tight opt-in to mutual references), than before having used it (at which point I would have said "just don't do that").