Clojure: Doesn't the ability to use Java objects with state defy the whole idea of functional P?

Question

I thought the whole idea was to have only computation with NO state and NO side effects. Now if a Clojure app(or even worse, a reusable Clojure library ) can use and create any Java object, how can I be sure I don't get side effects or state ?

Answer 1

You cannot be sure, apart from consulting documentation or using a java decompiler(?). This ability certainly defies the idea of pure functional programming, but the real world is not a particularly pure place and purely functional languages can't get much traction against it. Witness all the contortionism with monads in Haskell. Besides, mutable state is very powerful computationally — many algorithms become much faster and much more economical of memory when implemented with mutable state.

Answer 2

FP is a paradigm, a concept, but not necessarily a dogma. Clojure trusts the programmer to make thoughtful decisions about where he'll depart from FP. In exchange, Clojure offers the staggering cornucopia of code that is available in the form of Java libraries. This makes it relatively easy and painless to write a GUI app in Clojure, say, or a Web server or any of the things covered by Java library code.

Note that the Java "hole" is not the only escape hatch Clojure offers from FP: References and atoms hold state and Clojure offers functions to change it under controlled conditions. I think this pragmatic approach makes Clojure useful and will help make it popular.

Answer 3

Clojure is not a pure functional programming language. What you said would stand in Haskell, but not in Clojure. Clojure encourages functional programming, but it doesn't force it. Clojure is built to help you program in a functional style, but also to allow you to actually get stuff done. Clojure makes sure that when you use state, you have to be explicit about it. If you want to be sure that you're programming purely functional, you have to make sure yourself. Clojure isn't pure, so it doesn't promise purity.

Answer 4

Because Clojure is meant for the real world it makes compromises, and therefore it isn't a pure functional language.

Haskell was made as a proof that it was even possible to make a pure functional programming language that could work in the real world, so if pureness is what you desire, your journey should take you there.

Answer 5

Referential transparency (which is a consequence of the lack of side effect) isn't the only motivation for functional programming. The concept of lazy evaluation is thought to be one of the central features of the functional style since it allows you to modularly construct programs.

In other words functional programming is at least as much about generic programming as it is about providing static safety guarantees. I'm pretty sure you already knew this, but I thought it might be appropriate to articulate the idea.

Allowing side effects is a bit of a trade-off which you need to justify for yourself. Many applications do need to deal with quite a lot of stateful computation, some languages are just more strict about dealing with this than others.