4 ms·

What are people's experiences in writing such dense functional code in a production environment? What does maintainability/debug-ability/bringing other function

by siavosh 15y ago

What are people's experiences in writing such dense functional code in a production environment? What does maintainability/debug-ability/bringing other functional folks up to speed like?

dustingetz 15y ago
http://janestreet.com/minsky_weeks-jfp_18.pdf http://janestreet.com/minsky_weeks-jfp_18.pdf
technomancy 15y ago
Maintainability is immeasurably boosted by referential transparency; most of the time you can look at a single function in isolation and understand everything that's going on rather than having it be affected by other pieces of the codebase. I find it's much easier to work on a large codebase in Clojure vs Ruby just because it encourages a clean separation of concerns. Of course in Clojure a 30k LOC project is considered very large. It's an open question whether this is due to Clojure's expressiveness vs the fact that it might not have been around long enough to spawn any massive projects. Debuggability is helped a fair bit by having access to the repl in production contexts, but for the most part needing an actual stepping debugger is very rare, precisely because of referential transparency. Bringing other folks up to speed is definitely the biggest problem. People who have experience with other FP languages usually don't know much about the JVM runtime and ecosystem, while people with Java backgrounds have a lot to learn about immutability and lisp.
michaelochurch 15y ago
Strongly positive. Maintainability? Good. Yes, functional code can get weird and unmaintainable, but it's less common for it to turn to garbage, and the interactive mode makes it easier to fix modules before they get into states of advanced failure. Average-case Java or C++ turns to shit as soon as there are two people on the project who don't know each other. With functional languages, REPLs, and a good code review process in place, that's far less likely. Most "bad" functional programs exist either because people apply FP ideology too strongly (i.e. eschewing mutable state on ideological grounds, despite the fact that it often makes programs better to model things that are semantically mutable with mutable state) or try to do things in a functional way when it's inappropriate (e.g. trying to beat C++ into functional-ness, generating code that's neither good C++ nor good FP). Debugging? Referential transparency is a huge win here. It's not even close here. In large Java projects, it often gets to a state where no one knows WTF is going on. Java also does a lot to discourage testing (such as the requirement by many Java build systems that tests live in a separate directory). With a properly-written functional program, it's easy to test individual pieces. Learning curve? Not an issue for smart people. Don't hire not-smart people. That said, studying Scala (and especially its message-passing concurrency) has opened my eyes up to the relationships between programming paradigms: functional programming and OOP shouldn't be conceived-of as opposites. They actually work really well together, for a reasonable definition of each. The default means of abstraction should be a referentially transparent function. Objects should be used for large mutable systems intended to communicate through message-passing. (When possible, avoid sharing mutable state among more than one object.) Where Java failed is by taking OOP too far, and forcing people to create objects and classes in places where those (more powerful) abstractions are inappropriate to the problem being solved.

by siavosh 15y ago

What are people's experiences in writing such dense functional code in a production environment? What does maintainability/debug-ability/bringing other functional folks up to speed like?

dustingetz 15y ago

http://janestreet.com/minsky_weeks-jfp_18.pdf http://janestreet.com/minsky_weeks-jfp_18.pdf

technomancy 15y ago

Maintainability is immeasurably boosted by referential transparency; most of the time you can look at a single function in isolation and understand everything that's going on rather than having it be affected by other pieces of the codebase. I find it's much easier to work on a large codebase in Clojure vs Ruby just because it encourages a clean separation of concerns. Of course in Clojure a 30k LOC project is considered very large. It's an open question whether this is due to Clojure's expressiveness vs the fact that it might not have been around long enough to spawn any massive projects. Debuggability is helped a fair bit by having access to the repl in production contexts, but for the most part needing an actual stepping debugger is very rare, precisely because of referential transparency. Bringing other folks up to speed is definitely the biggest problem. People who have experience with other FP languages usually don't know much about the JVM runtime and ecosystem, while people with Java backgrounds have a lot to learn about immutability and lisp.

michaelochurch 15y ago

Strongly positive. Maintainability? Good. Yes, functional code can get weird and unmaintainable, but it's less common for it to turn to garbage, and the interactive mode makes it easier to fix modules before they get into states of advanced failure. Average-case Java or C++ turns to shit as soon as there are two people on the project who don't know each other. With functional languages, REPLs, and a good code review process in place, that's far less likely. Most "bad" functional programs exist either because people apply FP ideology too strongly (i.e. eschewing mutable state on ideological grounds, despite the fact that it often makes programs better to model things that are semantically mutable with mutable state) or try to do things in a functional way when it's inappropriate (e.g. trying to beat C++ into functional-ness, generating code that's neither good C++ nor good FP). Debugging? Referential transparency is a huge win here. It's not even close here. In large Java projects, it often gets to a state where no one knows WTF is going on. Java also does a lot to discourage testing (such as the requirement by many Java build systems that tests live in a separate directory). With a properly-written functional program, it's easy to test individual pieces. Learning curve? Not an issue for smart people. Don't hire not-smart people. That said, studying Scala (and especially its message-passing concurrency) has opened my eyes up to the relationships between programming paradigms: functional programming and OOP shouldn't be conceived-of as opposites. They actually work really well together, for a reasonable definition of each. The default means of abstraction should be a referentially transparent function. Objects should be used for large mutable systems intended to communicate through message-passing. (When possible, avoid sharing mutable state among more than one object.) Where Java failed is by taking OOP too far, and forcing people to create objects and classes in places where those (more powerful) abstractions are inappropriate to the problem being solved.