Amit Rathore

I agree. Reading the Scheme books helps much more with getting used to and grokking the functional style.

Scala does espouse a functional style, but unfortunately core data-structures aren't all immutable. So you have to use libraries that offer immutable ones, and it then becomes a programmer-discipline issue of always using them. In Clojure, there are no other options, so this discipline is enforced for free.

Same thing with the STM system - clojure has one built-in, and thus all state-management functions use it. In Scala, you have to pick a library, and then hope that everyone uses it right, and so on.

These issues are deal-breakers for me - even before getting into Scala's overwhelming syntax. And obviously, Scala doesn't have a macro system.

My point wasn't that one size fits all, but that the functional paradigm transcends, say OO. I also wanted to point out that it is so flexible, that you can "simulate" OO in just a few lines of code, not that you would, because that would be like saying a rifle isn't arrow-oriented.

To answer your modeling question, for instance: the functional paradigm can be applied to modeling business processes without modeling the actors (as OO does) but modeling the actions itself (functions). There's a lot more to it, of course, but it just involves a mind-shift and some practice. After all, people were building systems before OO.

Instead of attempting to write code here, check this page: Java Interop. Specifically look under "Implementing Interfaces and Extending Classes" and the proxy macro.

No worries, let me know if there are other questions I can answer!

Hi John,

Runa is a SaaS for online merchants. We collect the complete click-stream of any customer that browses a merchant website. This data is continuously analyzed to maintain an running understanding of the traffics conversion behavior and patterns. Then, in real-time, Runa makes offers to likely abandoners - it could be a price-discount, free-shipping, bundling, etc.

As you can imagine, this involves large amounts of data, processing of that data, real-time web-services, etc.

Our stack is Clojure for web-services, and all the data-processing logic. The system is built as a family of DSLs that are used by our engineers, support-staff, and the merchants themselves. Data is stored in HBase for long-term storage, and in Redis for session-related information.

There was no real challenge per se about using Clojure. A couple of engineers needed to transition from Ruby to Clojure, but with pair-programming, they were able to do so within a couple of months. Mastery, of course, takes longer. We've been in production with Clojure for nearly three years now, and we've been extremely satisfied every minute of that time. As far as I'm concerned, Clojure is the language to use on all new projects, and for all new functionality on existing projects.

I've responded to another thread which may help answer some part of this question: https://coderanch.com/forums/posts/list/539123#2446065

First of all, let me (respectfully) challenge your differentiation of the two paradigms. Consider this blog post: A Silly Object System for Clojure

It shows most of Java's OO mechanisms implemented in about 40 lines of Clojure.

Functional programming, especially with LISP (or Clojure) transcends Object Oriented programming. When you take Clojure's lexical closures, multi-methods, first-class functions, the macro system, immutable data-structures and the STM, you can write code that doesn't suffer from a lot of problems actually caused by typical implementations of "object-oriented" languages. I like to think of this quote by Alan Kay - "I invented the term Object-Oriented and I can tell you I did not have C++ in mind".

In short, OO is probably not what most people think it is... and the functional paradigm, especially when combined with all the other features of a language such as Clojure, actually delivers a lot more capability.

One of the many insights, for me personally, was the fact that a program that interprets other programs is itself just a program. The idea of DSLs became less "cool" and "magical" when I realized that, and LISP and Clojure programmers design systems naturally in such metalinguistic abstractions. It is just a normal way of doing things.

The other thing I found was that bottom-up design was much more natural in a functional programming language such a Clojure, and being a LISP, it became an even better vehicle for it.

I'm sure other folks have had other or similar revelations!

Well, for one thing, all core data-structures in Clojure are immutable, which is not true of CL.

Further, Clojure has a built-in STM system which allow for safe state management (be it of a single thing at a time or for multiple things in a coordinated transaction). This doesn't exist in CL, unless you use one of several STM libraries out there. Even then, it isn't automatic, and requires careful discipline from the programmer.

Clojure was designed from ground-up to support safe multithreading.

I believe that the answer is yes.

Some folks will need to unlearn a lot more than others, but in the end, as long as folks see the underlying design principles and appreciate the reasons for them being there, they can gain mastery of Clojure programming. Patience is the only thing I advocate (patience to get past the first few days that it will take to get over the parentheses!)

It absolutely is.

Take a look at this: How to design programs and also Structure and Interpretation of Computer Programs. Both are meant as entry-level programming courses, and indeed, folks that have worked through those two books have been enlightened in ways that make them better programmers for the rest of their careers. Both those use Scheme as the programming language.

Clojure is right there with such languages; in fact, it is a modern LISP, designed with abstractions (Java interfaces, for instance), and is functional (with all core data-structures being immutable). It has concurrency support with an efficient implementation of STM (software transactional memory), resulting in a great choice for (safe!) multithreaded programming.

It certainly teaches all the right concepts!

Clojure's design draws heaviliy from several amazing languages - haskell, ocaml, erlang, common lisp, scheme, etc.

I haven't personally used Haskell in any real project, so I can't comment directly. However, I do believe that Clojure's macro system has advantages that other languages don't have, and can't provide in the same easy way.

What I mean by that is that in Clojure, being a LISP, building mini-languages (DSLs) on top of the core is a natural design pattern. There is language-level support for this, with the macro system. Also, being functional in nature, designing systems in a bottom-up manner is far more natural and results in more expressive and elegant code.

Further, Clojure has explicit support for state-management (safe from multithreading issues). These constructs are much easier to understand and use than, say monads in Haskell.

I do believe Clojure is more suitable to those programmers that want to (or need to) build dynamic systems.

Dynamic systems are those that need to adapt to changing requirements constantly, both at design (development time) as well as during run-time. For example, at Runa, our system is mostly written in Clojure (about 90%) and is composed of a family of DSLs for various pieces. It allows even our customers to completely re-wire things according to their own business rules. We allow this extreme level of customizability for two reasons: 1. every merchant is different, and 2. we ourselves don't know what and how the system will *really* be used in the field.

This way, we build the core concepts, and allow our customers to essentially wire things together as they please. Our support staff speaks this DSL, and can help customers as needed. We also have a DSL which allows us to debug and get more diagnostics out of the system. And none of the DSL changes needs us to restart anything - it all just works at run-time.

So to answer your question, it's less a question of temperament, and more about the requirements and demand for flexibility. However, Java programmers that are interested in other JVM-based languages such as JRuby, jython, and Groovy will find the transition easier. However, I know a lot of folks who have gone straight from Java to Clojure, and some who went to Scala first, and then to Clojure.

See you guys on the other threads!