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 intera

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.