Very interesting article. As a primarily OO programmer that's been playing more and more with functional concepts due to javascript, I definitely see the theoretical advantages mentioned in the article.
However, I also see that there are very hard parts to purely functional as well. For instance, to be entirely side-effect free your language has to be able to enforce immutability (which JS lacks). It's also hard (or at least not obvious) how to do certain types of logic flows in a purely functional.
For small domain spaces I can visualize how purely functional bottom-up programming effectively causes you to write a DSL for your problem.
However I don't have the experience/wisdom to understand if this holds true as the size of the domain increases. Basically, I have concerns that purely functional solutions don't scale (not from a performance perspective, but from an organizational/architectural one).
My experience with complex business logic makes me worried that complex new business rules would be difficult to implement in purely functional way and would cause frequent, painful refactoring.
I would love to hear from someone that's done a purely functional application with a large surface area that has been subjected to a real-world business environment to comment on the subject.
> I would love to hear from someone that's done a purely functional application with a large surface area that has been subjected to a real-world business environment to comment on the subject.
I worked at a betting exchange where the backend was written entirely in erlang. There were a lot of areas in the code where we had to deal with incredibly complicated business rules.
For example, we were not allowed to allow customers to gamble money they didn't have in their account but we did want to allow them to sell out of a position. This meant keeping track their minimum possible gains from all their current positions to figure out how much money they could safely be allowed to use. Money laundering regulations meant we also had to keep track of where different pools of money came from (eg different bank accounts, paypal etc) and these pools could not be allowed to mix (eg you can't deposit money into the site using paypal and then withdraw it into your bank account). Users are allowed to pick their own odds so we always had to be very careful whether money gets rounded up or down. And then there were promotions giving extra money for new members or for large deposits and any bets had to be taken from bonus pools before other money pools.
Functional programming is a very overloaded term so I will talk about specific things that made this easier. I personally find it much easier to construct complex data structures and maintain invariants on them when using algebraic types + pattern matching rather than objects. The use of immutable data structures made it much easier to verify that no operation ever changed the total amount of money in the system and to safely implement highly concurrent systems. First class functions were used throughout the code but we probably could have replaced most uses by objects with little change to the overall structure.
I think that in general OO conflates the management of code and the management of runtime state. In erlang modules are the unit of code management and processes the unit of state management. I would also point out that an entirely purely functional program is impractical with current software and probably not desirable in general.
Bear in mind that most of the advocacy for functional programming tends to from people who have only just encountered the idea and are extremely excited. There are much more nuanced viewpoints available if you dig a little eg Rich Hickey's ideas on the separation of state and identity: http://wiki.jvmlangsummit.com/images/a/ab/HickeyJVMSummit200...
I would love to read more about that system and its implementation. I think it would make an excellent blog post - although I know you may not be allowed to talk more about it.
I don't work there any more so its pretty hard to write about it without the code in front of me. They were intending to open-source some of the more generic systems if they ever got time. Maybe if you gave them a nudge they would at least write about some of it: https://smarkets.com/about/contact/
I did write some vaguely related stuff about the benefits of their declarative web framework here: http://scattered-thoughts.net/one/1280/511009/453845. I may also ask if I can open source the transactional actors library I wrote there. That would probably be worth writing about.
Unix pipes aren't functional programming (which emphasizes immutability and referential transparency) - they're more like the actor model, which creates a system out of lots of small programs communicating via message passing. And yes, they do scale very well, conceptually.
Erlang does both, maybe that's where the confusion is coming from. They're very complementary, though: having separate, concurrent processes seems to be an excellent pressure release for difficulties that can build up doing pure functional programming.
Also, Erlang has an novel (and extremely effective!) error-handling system for the actors, while error handling for Unix pipelines (or asynch/event-loop systems!) can be tricky.
>Unix pipes aren't functional programming (which emphasizes immutability and referential transparency) - they're more like the actor model, which creates a system out of lots of small programs communicating via message passing.
Unix pipes are lazy lists.
Operations on lazy lists allow you to use Mealy machine [1] created from pure functions. Mealy machine uses pure functions that transforms input and previous state to output and next state, which state then goes back on the next cycle.
And then you suddently have Turing completeness (because of arbitrary state).
My argument is supported by the fact that Unix pipes could not change the topology of computation structure, so do lazy lists, while actors could.
However, I also see that there are very hard parts to purely functional as well. For instance, to be entirely side-effect free your language has to be able to enforce immutability (which JS lacks). It's also hard (or at least not obvious) how to do certain types of logic flows in a purely functional.
For small domain spaces I can visualize how purely functional bottom-up programming effectively causes you to write a DSL for your problem.
However I don't have the experience/wisdom to understand if this holds true as the size of the domain increases. Basically, I have concerns that purely functional solutions don't scale (not from a performance perspective, but from an organizational/architectural one).
My experience with complex business logic makes me worried that complex new business rules would be difficult to implement in purely functional way and would cause frequent, painful refactoring.
I would love to hear from someone that's done a purely functional application with a large surface area that has been subjected to a real-world business environment to comment on the subject.