The Beauty of Clojure

http://owenrh.me.uk/blog/2015/08/24/

by erikcw • 11 years ago

217 170 11 years ago

owenrh.me.uk

bonobo30002• 11 years ago

For the OP - i've recently been programming in Scala, mostly spark jobs, nothing too complex, but damn its beautiful. I love how expressive the language is (certainly it can also be very complicated in large codebases, as you use more features, but I haven't encountered that yet). Heck just the simple 'scala' repl + JVM interop makes developing Java code so much easier. You seem to have tried Scala too - i'm wondering what you think of Clojure vs. Scala and what made you switch?

bad_user2• 11 years ago

I've been a Scala developer for the last 3 years and I'm in the camp that first played with Clojure and then switched to Scala. I'm still playing with Clojure from time to time, but I like Scala more.

The only difference one should care about is static typing versus dynamic typing and that's it. Of course it's not a binary black and white classification when looking at languages, for example Scala is less static than Haskell and Clojure is less dynamic than Ruby. But overall that's the biggest difference and that changes the style, the mentality you have, how the code looks like.

As an example you are much more likely to see in Scala the Maybe/Option monad, whereas in Clojure people prefer to work with null (nil). Rich Hickey said it himself that Option[T] only makes sense in a static language. In general in Scala you're more likely to see things like monads and functors being modeled explicitly. It's more natural to do that in Scala because it's all a matter of describing functions with certain signatures. And you know, when working with combinations of flatMap and map, it's much easier if you have the compiler telling you where you've fucked up. Which is why many people do use things like Scalaz or Cats or Shapeless. On the other hand in Clojure it's much easier to build things like transducers, because there's no type-system to stay in your way.

Clojure people work with lots of DSLs built over macros. You can see that in how Clojure exposes those channels in core.async and compare that to how asynchronous processing of events is done in Scala (e.g. Future, Iteratees, scalaz-stream, Rx, Akka actors, Reactive Streams, shameless plug: https://github.com/monifu/monifu). Of course, Scala has its own macros system, but like in other static languages, the macros in Scala are only being used by those that really know what they are doing. But because of that, in both languages you get features exposed as libraries instead of being special language features. For example here's Scala's equivalent for C#'s await/async exposed as a library: https://github.com/scala/async

Which one is better is actually dependent on the problems you're trying to solve. The problems I'm working on have a very complex business logic and are a better mix for static typing. This is why people will never agree on which one is better, because it actually depends on context.

sklogic17• 11 years ago

Scala got no macros. Which makes it infinitely less powerful than any language with macros, including even something like Clojure.

bonobo30002• 11 years ago

Similarly, Clojure got no types. Which makes it infinitely less runtime-safe then any language with types. Takes a more nuanced argument.

justthistime_8• 11 years ago

What makes you think that Scala has no macros?

dragonwriter• 11 years ago

Scala got no macros. Which makes it infinitely less powerful than any language with macros, including even something like Clojure.

Scala has macros since 2.10

http://docs.scala-lang.org/overviews/macros/overview.html

rjeli• 11 years ago

  (reduce + (map (comp inc inc) (range 10)))

is not analogous to (_ + 2). The more similar and idiomatic code is:

  (reduce + (map #(+ % 2) (range 10)))

pka• 11 years ago

Great! Now go for Haskell :)

jdeisenberg• 11 years ago

The first example could also be written as:

    (reduce + (map #(+ % 2) (range 10)))

which looks more like the Scala example, or, perhaps more readable, in the long form:

    (reduce + (map (fn [x] (+ x 2)) (range 10)))

edgyswingset• 11 years ago

I wonder why the author left the thread-first and thread-last macros as a footnote.

This:

    (reduce + (map (comp inc inc) (range 10)))

And this:

    (->>
       (range 10)
       (map (comp inc inc))
       (reduce +))

Are totally different from a readability standpoint. Yeah, there's some initial syntax to get used to, but in the long run I've noticed it to be the difference between immediately understanding what some code is doing and having my eyes glaze over.

huahaiy8• 11 years ago

For this code,

(reduce + (map (comp inc inc) (range 10)))

Clojure people would normally use thread macro, like so:

(->> (range 10) (map #(+ % 2)) (reduce +))

This would be similar to the Scala version in term of order.

fnordsensei2• 11 years ago

This reminds me that there really should be a reader macro for "partial" in Clojure.

numlocked• 11 years ago

This is very similar to my experience. There's definitely some friction getting started; the odd using/require macros for importing (which switched sometime in the last 2 years, which means a lot of out-of-date SO answers); the fact that most docs recommend using emacs which, if you aren't already a user, is not going to be easy to deal with; the parens.

But it's amazing. I do really miss types, but found that unit tests + Schema[0] serves my needs; they provide some type-ish enforcement, and do a terrific job documenting my code so that when I return to it months later, I have some idea of what's in all these map structures.

Another unsung feature is that emacs + paredit + s-exprs + repl means the actual mechanics of writing Clojure is wildly better than any other dev environment. The ability to operate confidently and consistently on semantic units of code vs. text is really amazing and I immediately miss it when I switch back to JS or Python. I'm sure other Clojurists felt they had already experienced something like FB's Prune when it was discussed here a few days ago.

Not to mention learning a Lisp really does increase your understanding of what's possible. I've seen others recommend holding off on playing with macros until you've become quite familiar with the language, but I couldn't disagree more. Play with them right away! I have perhaps ~200 hours of Clojure under my belt -- barely anything -- but I've hacked together a few useful macros. Though I barely understand how they work when revisiting them, it definitely increased my understanding of what's possible, and what's missing, in other languages.

So yeah...learn some Clojure. Just do it.

[0] https://github.com/Prismatic/schema

Mikera• 11 years ago

Note: you don't need to commit to Emacs to get the productivity benefits of Clojure.

Eclipse with the Counterclockwise plugin (and I believe IntelliJ with Cursive too) also give you comprehensive REPL, s-expr manipulation and paredit features.

huahaiy8• 11 years ago

vim with fireplace.vim and paredit.vim plugins are pretty nice as well.

ane• 11 years ago

The benefit of CIDER (the Clojure Emacs development environment) is that it now has a s-expr based debugger, whereas Cursive's debugger is still call stack based. So you can traverse the AST like in any other Lisp debugger and evaluate and manipulate s-exprs as you go.

dmichulke2• 11 years ago

I use clojure for 4 years now and I think I had to write macros only twice. In general, I'd advise against them and be wary of libraries that try to solve a lot of things with macros, the main reason being they are not easily composable and make things implicit that should be explicit.

The parens become less of a problem the more you know about clojure. You will find ways to traverse a map with very few parentheses that will make you grasp the code very efficiently. To this end I would recommend anyone starting clojure to do a few clojure koans each day and check their solution against the best solutions. www.4clojure.com

Finally, the tests (assertions via assert, :pre and :post) are indeed THE thing to use for both documentation and type checking and it allows to have kind of static typing where you want it. Of course, exceptions will only occur during run-time but your tests check for errors during run-time anyway, so why force someone to do type checking at compile time?

sklogic17• 11 years ago

In general, I'd advise against them

Why? Macros are the single most important productivity feature in Lisps.

Macros allow to implement eDSLs trivially, in the most robust way possible. Yes, you need to follow a certain discipline, but once you get it, you won't ever want to touch a language without macros.

agumonkey7• 11 years ago

I spend most of my time in emacs doing elisp and python, where everything is smooth, small and stupid. I just got back into Eclipse/Java. And the culture shock is so strong I had anger attacks for two days.

The Enterprise world is quite weird, they don't really care about the code, it's just an artefact, the IDEs reflect that, the 'UX' too. They don't really want you or understand how to manipulate code fast. It's loads of declarations that gets in the way of thinking, all inside ergonomically poor tools that are supposedly necessary to survive (Types are nice, but Generic OOP still feels like a burden compared to functions + HM). They want documentation, they want an asset, that's how they 'manage' complexity in the long run. All of this so you can mutate tiny bits of arrays... Crazy.

It also shows how language and standard library design matters. Python APIs are often tiny, everything is in this language, you rarely have to fight to remember, it falls down pretty nicely, and in case you have doubts you're one repl/dir/help away from finding out. Different culture.

Of course, in other paradigms, what is taking so much energy would be done in a 3rd or maybe less, so you don't need all the ceremony...

nanny• 11 years ago

Nice comment, especially your second paragraph. It's nearly exactly how I feel as well. What made you get back into Eclipse/Java?

pjmlp11• 11 years ago

Another unsung feature is that emacs + paredit + s-exprs + repl means the actual mechanics of writing Clojure is wildly better than any other dev environment.

Not if you take commercial Common Lisps devenvs into account.

agumonkey7• 11 years ago

Beside Franz who else is out there ?

escherize• 11 years ago

S-expressions have changed the way I think, and it's really great. With paredit (or some other structural editor) and hiccup[1] I can make html so quickly out of pure functions that it's truly a joy. Using Clojure's datastructures, along with all the functions made to alter those datastructures gives such an immense feeling of power.

[1] http://hiccup.space

pixie_2• 11 years ago

The line below looks a lot more readable than the closure version.

Enumerable.Range(1, 10).Select(i => i + 2).Sum()

huahaiy8• 11 years ago

It depends on whom you ask.

As a person who doesn't even know what language this is written in, I don't think it is readable at all. For example, this "Select(i => i + 2)" piece looks totally strange for me. What does it do?

After learned Lisp, I feel there's too much syntax to learn for non-lisp languages. Every language introduces some idiosyncratic syntax. Life is too short, I just don't want to learn syntax that someone else invented to just be able to say "this is different".

sheepmullet2• 11 years ago

In clojure you would typically write it as:

   (->>
       (range 10)
       (map #(+ % 2))
       (reduce +))

Which is just as readable as the .net equivalent.

Scarblac• 11 years ago

And I prefer

    sum(i + 2 for i in range(1, 10))

for readability. But we shouldn't judge languages on this sort of thing -- because then why don't we just write sum(range(3, 12)), or 63?

pixie_2• 11 years ago

In both those cases you have to read it backwards to see what it does.

_pmf_2• 11 years ago

I've asked on StackOverflow, got shut down violenty, so I try to ask here: how do developers in large(-ish) projects deal with the lack of tool assisted refactoring? (Renaming a field in Java, I am 100% sure that every call site is found, changed or otherwise the codebase does not compile. The catch-all clause of dynamically typed language users seems to be that the test suite should catch everything, but looking at most projects, it's outstanding to even see 40% test coverage.)

jarcane2• 11 years ago

I've never really needed it in Clojure. The code is that much more expressive that overall LoC is dramatically reduced (thus more easily viewed "in the whole"), and following a proper functional approach means good functions should be largely interchangeable and not dependent on any global state. So on the rare occasion I need to move something around, it's just meant a quick copy and paste and tweaking a few references.

Yes, Clojure is dynamically typed, but I think you're missing the gains you get from FP and expressiveness in terms of reducing labor.

eurekin4• 11 years ago

I was trying to find time for Clojure, but I had always had doubts - exactly as the grandparent commenter...

He touched upon what I think is essential. The biggest things to lose by giving up Java is the tooling. Using the IDE I have many possibilities to learn about code, without ever needing to run it. For example by using find usages/implementations. The types on methods often give out hints about the big picture. Like, if a method passes a JAXB context, than I know I'm in the infrastructure layer. If I'm looking for a business rule "how is the price calculated", I can very quickly cut off a large portion of code which does not do it. After few iterations, it's almost certain I will get to the relevant code part.

Then I typically launch an application and put a breakpoint, to test my assumptions. After that, I have a lot of confidence about how the application behaves in that spot, even If I saw it for the first time.

If anybody asks me "Tell me if we can extend the functionality of calculating user score to include expert rating", I can provide a good effort approximation, even in a never seen before application. I just know, that given the tooling, I can filter out unrelated code parts and concentrate only on the relevant one.

The above concerns only code comprehension of a large project. The tooling does give you also power to do macro level restructuring, like breaking a large monolith into smaller modules. The compile time errors are like a high accuracy automatically generated todo-list.

Since it takes so little effort to make large changes, you gain the ability to do it multiple times and refine. If I broke something into two modules and a dependency cycle came up, I see it right away and can do everything again, a little bit better with the extra knowledge I got.

I have never seen anybody doing the same in Ruby, maybe because I've been working only about two years commercially in it, but a lot of times I've seen something quite opposite: introducing more hacks decreasing code quality, just to work around some conceptual error. While working in Java, I have seen a lot of situations like "we'll doing a hack here and the real solution will come with the next big release" and really the solution does come.

High level changes typically break a lot. With tooling, you gain confidence you can fix them, without introducing a lot of regression bugs. In Ruby, I saw the people just give up and leave monkey patches around. Then they just leave the project for the next unfortunate programmer.

So, back to the topic. You say that the change name refactoring is very simple in Clojure, because the impact of change is local to the method. My question is: How does Clojure tooling aid You in changing a place with a global impact? Like, changing the argument list of a very often called method (e.g. the method to serialize a structure to string to require the caller to provide an explicit encoding)? Can You, right after doing the change, quickly estimate how much work is there to fix all affected places? Do You have confidence that the list you provide is complete and doesn't miss anything critical? How certain can you be without running the code, only analyzing?

lorddoig• 11 years ago

Cursive's[0] support for this kind of thing is quite good, and constantly improving.

    [0] https://cursiveclojure.com/

asmala• 11 years ago

Cursive, a Clojure IDE on top of IntelliJ, offers some semantic editing capabilities: https://cursiveclojure.com/userguide/editing.html (see e.g. the Rename section).

huahaiy8• 11 years ago

If working with emacs, clj-refactor in CIDER can do renaming of symbols.

Of course, renaming symbols in Clojure is not such a big requirement as in Java IDE, because most of the things are isolated within a single function in Clojure. Consequently, renaming symbols is just a convenience feature, not a must-have feature for Clojure development.

_pmf_2• 11 years ago

because most of the things are isolated within a single function in Clojure

I've seen a lot of Clojure code where keywords have project wide semantics.

Expez• 11 years ago

Check out https://github.com/clojure-emacs/clj-refactor.el

The intellij plugin for clojure called Cursive also has support for project wide renaming.

sklogic17• 11 years ago

Speaking about my experience only: I do not refactor that often. See no point in it, Lisp is not Java after all. My code is usually well localised, with only languages being passed in between modules (instead of APIs). And modules are small.

thom• 11 years ago

The tools exist for the low-level work of refactoring, i.e. emacs and clj-refactor. For larger structural changes, however, I've found core.typed has paid off. Obviously some people have a visceral reaction to type systems, but even if you don't use it at the outset, the ability to gradually add type information to existing code is great for paving the way for larger refactorings.

The workflow I have grown to love in clojure is an initial freewheeling, REPL-driven, dynamically typed phase in which you explore the problem you're working on, followed by a period of stabilisation that results in nicely factored, mostly-typed code. I personally think this can often give you the best of both worlds - quickly find the right design for a feature using clojure as a dynamic language, then robustly integrate it with the rest of your project using clojure more statically.

daxfohl5• 11 years ago

You don't. See my long comment on the actual post. I've tried and I've tried and I've finally given up. The only thing I haven't really tried is "plan stuff so thoroughly in advance that you'll never have to refactor". Though this seems completely antithetical to Clojure's raison d' anyway, that I doubt I'll ever get there.

I think it was on google groups somewhere but I can't find it offhand, but one of the early big contributors of prominent clojure libraries has since completely quit clojure specifically for that reason.

dkersten5• 11 years ago

The only one I can think of, the complaint was the contribution/review process (I think it was Zach Tellman who contributed some work only to have Rich rewrite the entire thing out of the blue 6 months later). Unless you're thinking of a different case?

dantiberian• 11 years ago

I can refactor a huge codebase in my IDE. Good luck trying that with Clojure.

Cursive Clojure, a plugin for IntelliJ has excellent refactoring support, especially considering how dynamic Clojure is. If you've come from a Java background, this gives you a lot of the refactoring and 'Where Used' functionality that you might be used to.

lewisl9029• 11 years ago

Yep, Cursive is definitely quite impressive.

Here's a very informative intro by Cursive's developer, complete with some very compelling demos:

https://www.youtube.com/watch?v=vt1y2FbWQMg

diego• 11 years ago

(comp inc inc) is weird. You'd normally use #(+ 2 %) or (partial + 2) instead.

zeekay2• 11 years ago

  (reduce + (map (partial + 2) (range 10)))

...reads great in my opinion. Surprised no one else has brought it up.

owen4d6• 11 years ago

Yeah, definitely. My bad. It's definitely not idiomatic.

I think was trying to avoid using the anonymous fn syntax, as I thought that was be more off-putting, and partial hadn't occurred to me at the time. In the end, I think I just confused the issue.

In retrospect, I should probably have used a totally different example, and avoided map and reduce as they are FP idioms. Live and learn, as they say.

nnq4• 11 years ago

I don't get it why Clojure and other Lisp tutorials throw things like this in face of beginners:

    (reduce + (map (comp inc inc) (range 10)))

instead of just using things like the "->" macro to make the damn thing just as in any other language:

    (-> (range 10)
        (map #(+ % 2))
        (sum))

...it's as if they purposely try to scare people away from Lisp! Some kind of smug superiority makes them wanna make sure no "lesser mortals" want to touch their beloved language. (The added benefit would be that later you can "blow their minds" but showing them how to write "->" themselves and instantly introduce them to the power of macros!)

This is almost close to showing a code snippet like this to someone trying to learn Haskell:

    fix$(<$>)<$>(:)<*>((<$>((:[{- thor's mother -}])<$>))(=<<)<$>(*)<$>(*2))$1

(it only prints the powers of 2, but it was enough to scare some people into calling Haskell “the Taliban version of ML”... http://www.theregister.co.uk/Print/2012/12/21/financial_soft...)

...really, people, stop scaring learners away!

agumonkey7• 11 years ago

First principles I guess, although I sure love `->` and its siblings.

nnq4• 11 years ago

If you start thinking along the lines of first principles you could just as well start with a NAND gate.

..because some people were even smart enough to pull this off: http://www.nand2tetris.org/ :)

hellofunk6• 11 years ago

Because -> is not a typical functional idiom, it's a macro specific to Clojure, and anything you can do with -> you can also do in the standard functional way, and beginners are better served by understanding the way a lisp works rather than only get taught syntactic sugars. Keep in mind that -> as a macro does not evaluate its arguments the way a function does, which complicates the understanding for a beginner tremendously, since Clojure is actually an eagerly-evaluated language.

alexott• 11 years ago

only in this case, it should be ->>, because -> inserts argument into first position, but you need it in the last... And you can omit parentheses around functions without additional arguments (sum in this case)

owen4d6• 11 years ago

Ha, yeah, I get where you're coming from. And I toyed with putting a threading macro example inline, and in the end put a footnote in instead.

My reasoning was that basically, regardless of the threading macros, you are going to have to learn to read/write s-expressions as-is for a couple of reasons:

1. The threading macros won't be the best way forward in all cases. 2. You're going to need to read other people's code, which wasn't using the macros.

Overall, I was trying to make the point that it is a real hurdle (at least that's how it felt for me), but worth getting over. As a week or so later, you can read s-expressions with relative ease. That it's worth making the effort, because they are pretty awesome. Maybe I just didn't communicate that very well.

fnordsensei2• 11 years ago

Good point. My code is littered with threading macros all over the place, and it can really reduce ))))))))))) to ). But I wouldn't have been able to use it effectively if I didn't know how s-expressions work.

logarhythm• 11 years ago

Totally agree with your point, but just a quick note: using the thread-first -> macro won't work in this case, instead you'd use the thread-last macro ->>. Also Clojure doesn't have a sum function, so you'd actually use (reduce +).

hohenheim• 11 years ago

This is subjective and dependent on the background. I, as a beginner, found the original expression easier to understand, whereas, the "->" macro rewrite seems puzzling. Specially (map #(+ % 2)) looks as if the values are summed and then % 2 is applies to it.

jffry• 11 years ago

For an introduction to absolute beginners it could be something like:

  (->> (range 10)
    (map (fn [x] (+ x 2)))
    (reduce +))

And then later on you can explain the #() shorthand

icebraining4• 11 years ago

As a Clojure/Lisp beginner, I can't say I agree. I don't know any language that works like your example, except maybe shell script with its pipes. Without variables, that expression just seems too "magical". Nested function calls, on the other hand, are common everywhere.

nnq4• 11 years ago

...that's how chaining method calls end up working in most OO languages (take the Scala example in OP's article). And also in Javascript (I can't remember if there is something like `range` in js right now...):

    [1,2,3,4,5,6,7,8,9,10]
      .map(function (x) { return x + 2 })
      .reduce(function (a, b) { return a + b })

so the "." in OOP ends up working like "->" or "->>". Heck, you can make the dot in OOP code behave like anything, even like monadic bind (`>>=` or `do` notation in Haskell), if you do OOP-style-monads in JS: https://www.youtube.com/watch?v=b0EF0VTs9Dc

(off-topic: this is also my main problem with OOP... the "." can actually end up meaning anything practically, as program logic is concerned, it's like some kind of "infinite operator overloading" :) )

grayrest2• 11 years ago

If it's particularly confusing you can always use swiss arrows[0] instead:

   (-<> (range 10)
        (map #(+ % 2) <>)
        (reduce + <>))

[0] https://github.com/rplevy/swiss-arrows

It's more common in functional languages and called a thrush or pipe operator.

F#:

    [|0..9|] |> Seq.map ((+) 2) |> Seq.sum

Javascript (Ramda):

    R.pipe(R.range(0,10), R.map(R.add(2)), R.sum)();

    //With slightly more magic
    let {pipe, range, map, add, sum} = R;
    pipe(range(0), map(add(2)), sum)(10);

VladimirGolovin• 11 years ago

I'm new to Clojure and I'm trying to parse this line:

  (reduce + (map (comp inc inc) (range 10)))

Is the following a correct Haskell equivalent?

  foldr1 (+) (map (succ.succ) [1..10])

tel3• 11 years ago

Yep!

vzcx• 11 years ago

Mostly, but I'm pretty sure Clojure's range gives the integers from 0 to 9.

platz• 11 years ago

pretty much almost all folds in strict languages can be assumed to be left folds.

nnq4• 11 years ago

EDIT: as observed by others, `->` should actually be `->>`, sorry for the typo, but unfortunately I can't edit the original comment anymore. Also forgot there's no "sum" already defined in Clojure, so replace that with `(reduce +)`

kazinator3• 11 years ago

Why other Lisp tutorials don't teach -> is, firstly, that other Lisp's don't have that, except as some add-on library feature. Secondly, it's a syntactic sugar that has quite a bit going on under the hood: implicit parameters, a lambda function being expressed as #(+ % 2) with this % thingy, and return values of forms being passed as arguments to other forms that are not syntactically enclosed. You have to understand that (range 10) is just called normally, but then its return value becomes an extra invisible argument to the (map ...) form.

Newcomers should learn the underlying ordinary evaluation first.

bad_user2• 11 years ago

As disclaimer, I've been a Scala zealot for the last 3 years. On Clojure vs Scala, usually comparisons are kind of unfair I think. As somebody interested in FP, I tried Clojure first. And FP being all about immutable data-structures, pure functions operating on immutable data-structures and dealing with side-effects explicitly by means of abstractions such as the I/O Monad, I expected to see that in Clojure, seeing how people describe it as being very FP.

And it was like a big WTF for me seeing how for example everything in Clojure is a Var that can be changed. And eventually I got it, I mean Clojure is a LISP and it's meant to be compiled by a REPL and the unit of compilation is not a file and this is in LISP's tradition and so on and so forth. But it's still a WTF given its usual characterization. Even in Java classes are completely immutable (until you start manipulating bytecode of course) and you've got "final" declarations. You have no "final" in Clojure. And this is actually a pity because it (probably) means that those persistent data-structures can't be implemented in Clojure, as "final" on top of the JVM comes with a pretty cool contract in the Java Memory Model that you need. And then instead of Scala's implicit parameters, that are actually very explicit and type-checked by the compiler, in Clojure you have package-wide vars or refs that people manipulate as a poor man's dependency injection mechanism. And state changes are usually done by mutating atoms. Well that's cool, in Scala people also do that, but in Scala you also have a mature implementation of the I/O monad and monad transformers if you want it, or various FRP libraries. And I'm sure that Clojure has plenty of libraries, but overall I feel that in Scala the ecosystem of design patterns borrowed-from-Haskell is more mature.

Scala provides mutable variants of its data-structures in the standard library. But that's not extra rope to hang yourself, because in Clojure the use cases still exist and people end up using Java's mutable data-structures instead. In Scala the blend of OOP and FP can sound overwhelming, but it's actually the healthiest blend of FP + OOP to ever come up in a programming language. And in Clojure, just because you can't declare a class, that doesn't mean that OOP doesn't exist. It does and the blend is not healthy. This is why "reify" and "proxy" exist and are used quite frequently. And things like clojure.lang.ISeq are a Java OOP interface and not a protocol. Basically Scala is trying to make the best of OOP, whereas Clojure considers it a necessary evil of the host platform that it can't get rid of. Pick your poison.

pjmlp11• 11 years ago

In Scala the blend of OOP and FP can sound overwhelming, but it's actually the healthiest blend of FP + OOP to ever come up in a programming language.

Have you tried OCaml or F#?

whateveracct2• 11 years ago

Scala is definitely a better blend of FP and OOP than either of those languages. It's also a heavier FP language that either of those.

hellofunk6• 11 years ago

Most Clojure devs (myself included) are not building projects right at the REPL and indeed we do typically write normal code files, each file is a namespace. The changing of a Var is not a typical Clojure idiom at all, and I don't think I've ever seen it done in any production code or the big Clojure libraries.

dkersten5• 11 years ago

Huh? Changing a var? That is very unidiomatic in Clojure and very strongly discouraged. You generally would (def ...) a var once and then it never changes. If you need mutable state, you use an atom, ref or similar, but redefining vars is quite rare in my experience.

This is why "reify" and "proxy" exist and are used quite frequently.

Not that frequently. I've only ever used reify for working with Om (and not touched since I switched to reagent). I think the last time I used proxy was 5 years ago. Of course, if you're directly interfacing with Java, you may need to use both, but for my own needs, almost all the Java I wanted to interface with already had Clojure wrappers (which I guess internally used reify/proxy and friends, but I did not have to know about this)

retrogradeorbit• 11 years ago

If you want to "redefine" a symbol in clojure you are better to create a new lexical scope via let with the new binding. But even then, why not just use a new symbol?

crimsonalucard2• 11 years ago

Which is more beautiful, haskell or clojure? This is a subjective question, so I'm hoping to read subjective and highly opinionated answers.

rtpg• 11 years ago

well that first example in the article would be

    foldl (+) 0 (map (+2) [1..10])

    sum $ map (+2) [1..10]

So... make up your own mind.

As someone who has written only small chunks of lisp but at many different points in life, I do find the whole parens game to be a bit disorienting, but usually I can counter it by using newlines.

I would write something like

    (reduce + (map (comp inc inc) (range 10)))

    (reduce +
            (map (comp inc inc)
                 (range 10)))

crimsonalucard2• 11 years ago

I deal with it by using an IDE or plugin for paren highlighting.

zeekay2• 11 years ago

Ranges are inclusive, so:

  sum $ map (+2) [0..9]

Nitpick, but it confused me for a second.

hellofunk6• 11 years ago

They are both beautiful in their own way. Haskell is more pure, certainly, and closer to mathematical beauty, definitely. But the extraordinary flexibility of a lisp, which Clojure does immensely well, makes it more powerful than any language I've experienced for quickly expressing or manipulating an idea. Any program written in Clojure could eventually be refactored into another language, but its strength as a dynamic lisp makes it possible to really get to the heart of a problem and work out its solution without anything else getting in the way.

daxfohl5• 11 years ago

Haskell was created to be beautiful. Clojure was created to be practical, with plenty of ugly pragmatism thrown in. If there's an argument over beauty, it should be Haskell vs Lisp (vs Prolog, vs Forth, and probably vs assembly).

wetmore• 11 years ago

Haskell was created to be beautiful. Clojure was created to be practical

Haskell was created to unify research in programming language theory under a common language, not to be beautiful.

pjmlp11• 11 years ago

I would like to try to use Clojure for mobile development.

Together with ClojureCLR, RoboVM and reader conditionals it would be a good mix, without having to deal with FFI headaches.

But currently it is too slow on Android and I don't know how well ClojureCLR, if at all, runs as Universal Windows App.

hellofunk6• 11 years ago

For mobile a lot of folks are now using Clojurescript. There have been several highly rated discussions on here about the breakthroughs in the Clojurescript community for getting it to operate very quickly on mobile devices.

pjmlp11• 11 years ago

Thanks, but that approach is not something I would enjoy.

I try to stay away from the JavaScript universe unless I have a customer requesting a webdev project.

For me mobile dev means only native code and not web widgets.

sanatgersappa• 11 years ago

Great post.

Most discussions on lispy languages focus on the syntax. The unsaid assumption is that the only diff between a lisp and a non-lisp is the syntax. However, using lisp actually makes you think differently about programming. It is that which for me personally, is the selling point of a lisp. The syntax itself is merely expression, and is honestly simpler to grok than most other languages thanks to its consistency.

skimpycompiler• 11 years ago

As much as I like Clojure the lack of static typing always made refactoring a pain. The lack of it makes this a beauty I just can't appreciate and see.

cranium• 11 years ago

Perfect description of the average Enterprise codebase!

tragic• 11 years ago

"FYI - there are better books to get started with [than the Joy of Clojure]."

FMI: what are they? :-)

emil0r• 11 years ago

Programming Clojure 2nd ed, Clojure for the Brave and True. Probably others as well :)

erichmond4• 11 years ago

+1 for clojure for the brave and true. Best overview book out there IMO.

akilism• 11 years ago

Living Clojure is really good also.

owen4d6• 11 years ago

Yeah, that footnote could have been more helpful!

I've replied to a comment on the post with my thoughts on books. Hope that helps.

infiniteseeker• 11 years ago

Is there a good online course for a beginning programmer who wants to learn Clojure? If not, a good book with exercises?

ianox• 11 years ago

I saw http://www.4clojure.com/ mentioned elsewhere in this thread. That'd be as good a place as any to start.

mateuszf3• 11 years ago

http://www.braveclojure.com/ is pretty good read.

owen4d6• 11 years ago

Clojure Koans, is similar to 4clojure, and also worth a look> http://clojurekoans.com/

Bookwise, I thought the following were pretty good: 'Clojure in Action' by Amit Rathore and 'Clojure Programming' by Chas Emerick are both solid intro Clojure books. 'Web Development with Clojure' by Dmitri Sotnikov is also a great book, which obviously comes with more of a web-slant.

And I'd give a second thumbs up for 'Clojure for the Brave and True'.

pron• 11 years ago

This post focuses on Clojure as a very pragmatic Lisp, but that, while great in itself, is not what makes Clojure so interesting. Clojure has proposed an interesting solution to the shared mutable state problem without trying to reduce it as much as possible like Erlang and without being pure functional -- and thus changing the whole concept of state and effects -- like Haskell (Clojure is imperative-functional). Clojure's solution is that all shared mutable state be transactional (or atomic, which is a special case of transactional). AFAIK, this is the first language to do that (again, without going down the pure-functional path). An imperative language that doesn't restrict global mutable state, but makes it transactional is a very interesting case study.

mseepgood• 11 years ago

Why is reading from left to right counter-intuitive? Don't we read f(x, y) from left to right as well? (f x y) has the same order, even the same amount of parentheses.

daxfohl5• 11 years ago

(< x y) is the main one I have trouble with. The alligator is eating them both!

erichmond4• 11 years ago

My couple of comments:

- Great write up, very approachable for who may be on the fence about toying clojure.

- Re: Enterprise, while our enterprise footprint isn't ubiquitous yet, there are a couple of big name companies using clojure pretty heavily. Amazon, Walmart and Two Sigma amongst them. Also, because clojure sits on the JVM, we have a good interop story with legacy java codebases.

- Re: Refactoring, you should checkout intellij + cursive clojure, it's made refactoring codebases much easier for myself.

erichmond4• 11 years ago

Also, anyone interested in seeing what a productive clojure workflow looks like should check out this screencast

http://www.parens-of-the-dead.com/e1.html

It's definitely "jaw on the floor" worthy, if you haven't seen something like this before.

owen4d6• 11 years ago

Thanks.

Re: Enterprise, I've seen a presentation about some of the work going on at Walmart. Would be great to hear more 'stories from the trenches' from larger scale developments. It would really help sell the language.

Re: Refactoring, yeah, I'm totally busted on that one, my wording was way too strong as I haven't tried either Cursive or clj-refactor. Plus in a way, it's an apples and pears comparison, between OO and FP refactoring.

zubairq• 11 years ago

Not, entirely true, there are some Clojure Frameworks like this one http://coils.cc/coils/a-framework.html

kazinator3• 11 years ago

The use of s-expressions and their resulting prefix notation is in many respects the secret sauce of Clojure. However, it requires you to read right-to-left3 and inside-out. This is counterintuitive to most of us, and takes some getting over. It is a very real barrier to entry for Lisps.

Author still doesn't get it. Lisp must, in fact, be read from the outside in, left to right --- in the same obvious direction in which it is evaluated. It is not very different from a nested f(x, y, ...) notation, except that the commas are gone, and the f ( exchange position to the ( f arrangement.

As a trivial example of why outside-in is wrong, is that if you follow that order, you might believe that (b c) is a function call in (defclass a () (b c)). The most important fact is that this is a class definition (in ANSI Common Lisp). The leftmost symbol in the outermost form, defclass, is the what McCarthy called the "main connective". It determines the entire meaning of the interior of the form and all of its subforms, so it behooves us to visit that first. When we recognize that, we then know that (b c) are slots, and not operator b applied to argument c.

The right-to-left part is completely bizarre. Why, as a matter of course, would you read the arguments of a form before the main connective symbol? If that, you want, languages for you, there are: Forth, PostScript.

owen4d6• 11 years ago

Ha, yeah, maybe. I guess what I meant is this, say you have some OO/Scala-like code like this:

mydata.doA(blah).doB().doC(blah2).etc()

You can read it left-to-right: I've got some data, I do something to it, I then do something else to that result, etc. Maybe it's just that I've been using Java, and the like, for years but this feels simpler to me than s-expressions. At least initially.

With s-expressions I get something like (ignoring threading macros):

(etc (doC blah2 (doB (doA blah mydata))))

So when reading, from a data perspective, you kind of read outwards from the inner s-expression (which seems right-to-left to me). Or keep a kind of mental stack, as you read inwards (left-to-right). No?

The Beauty of Clojure

Related Stories