Hacker News Reader

Comment by pron | Hacker News Reader

I'm a Clojure newbie, but what impresses me about Clojure is the restraint and good taste in introducing new features to the language and core libraries. The language continues to be simple, extremely elegant and fun, but most of all, there is a strong sense of good design. APIs are considered carefully and not introduced into the core unless they solve a major problem, and solve it cleanly and well.

What is missing from Clojure, I think, is better support – either at the language level or as common practice – for large software composition, or programming-in-the-large. This is probably the opposite problem from to of Erlang, the other language that tackles the huge problem of state management well. Clojure is terrific when it comes to implementing computation, but how to best assemble various components into a large, maintainable program is not so clear.

View on HN

You've obviously given this quite a bit of thought, given your work on the Pulsar library:

https://github.com/puniverse/pulsar

Your comment below this one focuses more on 'established practices' for large programs rather than 'is there a library that has this feature?'. I think that's just a reflection of both the state of functional programming and Clojure. They are growing and on there way to being commonly used in large systems, but not there yet (and so the practices don't exist).

For a completely different way of thinking about the problem of software composition that is more functional (although not for Newbies, not that you are) - there is lots of work going on with Monads in Clojure.

You can read about Monads in Clojure on Leonardo Borge's blog entry "Monads in Small Bites". This has some nice parallels by comparing Haskell and Clojure usage patterns.

http://www.leonardoborges.com/writings/2012/11/30/monads-in-...

Jim Duey has put lots of work into explaining Monads in Clojure in his talk at Clojure West. The way he builds up the venn diagram is a great visual explanation (some say the addition of arrows wasn't helpful).

https://github.com/strangeloop/2011-slides/blob/master/Duey-...

In addition the Fluokitten library in Clojure has lots of building blocks for Monads in Clojure. You can read about it on this blog entry "Functors, Applicatives and Monads in Pictures - in Clojure". The great thing about this is the focus on boxing. http://fluokitten.uncomplicate.org/articles/functors_applica...

I also saw my first Free Monad in Clojure in the wild this year:

http://stackoverflow.com/questions/20171057/is-it-possible-t...

One of the things I like about Clojure is that it doesn't tout itself as a "functional language", even though in many senses it is. The reason is that outside the enthusiast circles, i.e. in pretty much every enterprise, the term "functional language" is considered almost toxic; the term "monad" is highly toxic. Because Clojure has always been careful to put a lot of emphasis on practice over theory, if any monad-based approach to program composition is to be taken, a different name must be found for it. I think monads (not that I understand exactly what they are - I used to, but I forgot :)) are mostly useful for language designers. It is a very high-level abstraction, and the developer does not need to understand it in order to use a particular application of monads. In any case, anything with that even mentions the word monad can forget about widespread adoption. You can use them to build a specific API and then give it a different name, just don't mention the word.

Yes - I recall Simon Peyton Jones (one of the Haskell designers) commented on this in a talk when he came to town. He said, "The biggest mistake we made was calling them Monads. That's a big scary word."

Re naming and specific APIs - there is a comment along these lines on this blog entry:

"As you may have noticed, I reused list concatenation as monoid addition, but this makes a lot of sense, as list concatenation satisfies all the monoid laws, and no other laws. A more accessible way of saying that a type is a monoid is to say that it is combinable, addable, appendable or summable."

http://tailcalled.wordpress.com/2012/04/03/translation-of-mo...

I reckon 'addable' is what you were getting at with "build a specific API and then give it a different name."

I'd highly recommend checking out Stuart Sierra's component library. It's helps define your application into components that manage state and gives you lifecycle control of those components. basically dependency injection for clojure.

https://github.com/stuartsierra/component

And his talk on the subject of larger scale clojure programs:

http://www.infoq.com/presentations/Clojure-Large-scale-patte...

These aren't established practices yet. There don't seem to be any. This is not serious criticism, as I'm sure practices will evolve, but I think that currently it is a deficiency in the Clojure ecosystem. Making namespaces more like modules (that can be instantiated and parametrized) might help at the language level.

I'd agree with namespaces-as-modules, it's something that'd make program composition a lot nicer in my opinion.

Take a look at EDN, fressian and especially core.async. You can do pretty similar things to Erlang.

Yes, and my own Pulsar[1] brings you even closer, but that's not what I was talking about. I was talking about large-scale program organization.

[1]: https://github.com/puniverse/pulsar

Here is a pretty good web app tutorial, albeit a year old, that I'm almost done watching: https://www.youtube.com/watch?v=VVd4ow-ZcX0

Reply on news.ycombinator.com