Racket vs Clojure (it's all about the data structures)

http://programming-puzzler.blogspot.com/2010/08/racket-vs-clojure.html

by swannodette • 16 years ago

104 27 16 years ago

programming-puzzler.blogspot.com

c00p3r• 16 years ago

Some people love Clojure specifically because it sits on top of Java and gives them access to their favorite Java libraries. Frankly, I have yet to find a Java library I'd actually want to use. Something about Java seems to turn every library into an insanely complex explosion of classes, and Java programmers mistakenly seem to think that JavaDoc-produced lists of every single class and method constitutes "good documentation".

Amen!

kunley2• 16 years ago

I was going to cite exactly the same paragraph here :))

francoisdevlin• 16 years ago

It's more the ability to deploy my apps into a Java environment that we like. Yes, it is possible to deploy CL/Scheme in production, and lots of smart people have done it successfully. With Clojure, I can build my app into a .JAR, and deploy it on most desktops. Also, a typical enterprise sysadmin will have no problem putting this into a J2EE (pays the bills) technology stack.

tmountain• 16 years ago

Love it or hate it, Java's back catalog of libraries is gargantuan. One of the biggest obstacles in getting a new language adopted is library support. The fact that Clojure gets all that for free is a way to get people using the language now. As Clojure matures, I'm certain more and more native libraries will emerge negating a lot of the need for Java.

kunley2• 16 years ago

quantity != quality

technomancy• 16 years ago

> Frankly, I have yet to find a Java library I'd actually want to use.

http://en.wikipedia.org/wiki/Sturgeon%27s_Law says "90% of everything is crap".

On the JVM that number might be a bit higher, but there are some excellent gems in there too. Lucene comes to mind especially; there's nothing like it on any other platform.

KirinDave• 16 years ago

True, and eff-you-forever Taligent for unleashing this stylistic horror on the world.

But the flipside of this is positive. It feels incredibly good to take a Java library down into your mad scientist workshop and come back out with a beautiful, functional, efficient, and useful interface to a previously ugly library interface. A great example of this is how most Clojure programmers use Jetty. Just pass in a lambda!

briancarper• 16 years ago

Many huge Java frameworks are painfully over-complex, but personally I make good use of a lot of "tiny" Java libraries. e.g. if I want to calculate an MD5 checksum or pluralize a word, there's usually a bit of Java out there for that already. Joda-Time is a good example of a clean Java library that's fairly painless to use from Clojure.

And then sometimes people have written Clojure wrappers around Java frameworks. Ring/Compojure as a thin layer over Java servlets is a good example. clojure.contrib.sql is a thin wrapper around JDBC, so that Clojure can already talk to a wide variety of databases.

In that case you get the benefit of a solid codebase as well as the benefit of a clean Lispy interface. Not sure how much more you could ask for. It would likely take years to reproduce all of that work in pure Clojure.

Raphael_Amiard• 16 years ago

Very interesting perspective. I never thought about it that way, but it's true that one of my principal pleasures working with Clojure was about the data structures, and their very nice integration into the language.

The concurrency features sounded exciting but were never of any use to me. But the consistent and extremely powerful data structures and associated libraries were my main subject of wonder, even if i didn't really notice it.

Now that i'm working with python all day, even though i really really like this language, i can't help but hate the inconsistent way data structure works (and the fact that they are mutable, and that mutable and immutable operations are mixed up in the API without a clue). And i used to consider python as being quite nice data-structures wise.

sreque• 16 years ago

I actually have very similar thoughts on clojure versus racket. I admire both languges for different reasons, but if I were to pick one to get the job done it would be Clojure. I cry every time I see the idiomatic construct in any Scheme of converting a vector or string into a list just so you can do the normal core operations on it, and then converting it back to a vector or string, but this kind of code is quite common due to the design of almost every Lisp.

Another issue I have with racket, which the article touched on a little, is the overall lack of cohesion between different libraries and language features. I believe this is an unfortunate consequence of starting out with such a simple core language as all Scheme's do. Everything that is built has a different style to it and doesn't necessarily interoperate well with other parts of the language.

For example, structures are entirely orthogonal to objects and the class and interface system are entirely orthogonal to units, even though these two pairs of features can heavily overlap in their use cases.

When it comes down to it, if I want to get something done in Clojure I feel like I have a clear path as to how to go about it, but in Racket it seems much easier to get lost inside the language for the reasons mentioned in the article.

Xurinos2• 16 years ago

> this kind of code is quite common due to the design of almost every Lisp

Scheme != Lisp (maybe a "lisp")

I was trying to figure out what you mean from a Common Lisp perspective. Are you referring to the author's example?

  All of Clojure's collections can be treated as if they 
  were a list, and you can write algorithms to traverse 
  them using the same pattern of empty?/first/rest that 
  you'd use on a list. This means that all the powerful 
  higher-order functions like map/filter/reduce work just 
  as well on a vector as a list.

Just off the top of my head, CL's map and reduce can operate on lists or vectors. Pretty much anywhere you see the word "sequence" in the spec, you can work with a vector or a list (and several other types). I can understand the point that it might be awkward in Racket; does it get awkward in CL?

I cannot speak for Racket/Scheme's limitations, but I am looking to see where Clojure might be a better choice for me than CL other than interoperability with Java. I have not seen a good data structures argument yet.

rw• 16 years ago

In Scheme (vs. Common Lisp) sequence operations are typically defined in terms of cdr, which operates on [singly-linked] lists.

sedachv2• 16 years ago

CL ostensibly comes with a built-in sequence class. The problem is none of the various utility methods that are included are generic functions, so in practice it doesn't do much good. Christophe Rhodes worked on an extensible sequence standard:

http://www.doc.gold.ac.uk/~mas01cr/talks/2007-04-03%20Cambri...

It's implemented in SBCL, I think there may be ports to other implementations.

This is the sort of thing the CDR (http://cdr.eurolisp.org) process is supposed to address. Right now they only have proposals for a generic hash table interface (http://cdr.eurolisp.org/document/2/index.html - not integrated with sequences!), and fixes to concatenate-sequence (http://cdr.eurolisp.org/document/3/index.html).

In summary: CL comes with some nicer datastructures than Scheme (hash tables, multidimensional and adjustable arrays), but other than that it has the same problems.

gruseom2• 16 years ago

This guy puts his finger on precisely the thing that might get me to switch from Common Lisp to Clojure someday. The Java interop aspect is vastly overrated on a technical level. (That's not to say it is overrated in general; it's a marketing master stroke without which the language would have been stillborn.) The concurrency innovations are at best experimental, seem kitchen-sinky, and don't attract me much. But boy do I envy those data structures.

macmac• 16 years ago

> The concurrency innovations are at best experimental, seem kitchen-sinky,

Could you expand on that statement. I don't think there is anything experimental about Clojure's concurrency features. They are quite robust and build on proven technology.

gruseom2• 16 years ago

What I had in mind is close to what the OP says:

Clojure has a number of cool new ideas, but many of them are unproven, and only time will tell whether they are truly valuable.

We don't know yet what will become the dominant concurrent programming style(s). For all the talk about the multicore future, nothing has yet emerged that's compellingly better than traditional approaches. Or maybe it has and it just hasn't made its way through the noise into general consciousness; I don't know. Clojure's approach here strikes me as a sort of experimental groping: add several different new concurrency primitives and see what sticks. That aspect seems quite different from the improvements Clojure offers that came from years of experience programming Common Lisp and a resultingly deep intuition about what constructs would make it more comfortable.

Perhaps Clojure has hit the concurrency jackpot and come up with a better way of writing parallel programs. That would be significant. It would even be significant if it offered a better way of writing a particular class of parallel programs. So far, though, I haven't seen convincing evidence of that. I'm more excited about Clojure being an incremental improvement over Common Lisp that is winning over a new audience of hackers.

singular• 16 years ago

I had horrific experiences trying to get Racket namespaces to work correctly (in Racket, a namespace is a value rather than simply a name). I found I couldn't get files to use the same namespace no matter how hard I tried, and without a specific namespace some code I was eval-ing simply refused to work.

I suspect Clojure lacks this 'feature' :-)

It's frustrating because I'm sure Racket has a lot to offer but not being able to do something really simple (even after hours and hours of trying) completely put me off.

gcv• 16 years ago

While this is a decent article in its core argument, it's a bit misleading in some of the details.

Methods are not true closures, and can't be passed directly to higher-order functions.

You can trivially wrap a Java method in a fn, and Clojure has syntactic sugar (the #() notation for anonymous function literals) to help with this.

Slow numeric performance.

This is true in the 1.2 release, but the next version of Clojure addresses this problem in (IMO) a very elegant way. Search on the mailing list for discussion of the num branch for more information. If numeric performance concerns your problem domains, please use the branches that resolve this.

Slow startup time.

Yes, the JVM starts slowly. I restart Clojure REPLs about once a week. I don't exactly notice this problem. Clojure isn't like Python or Ruby or Perl, where you start new interpreters all the time.

zephjc• 16 years ago

"Frankly, I have yet to find a Java library I'd actually want to use."

HyperGraphDB, and the Google App Engine jars, for starters.

evanrmurphy2• 16 years ago

Racket's hygienic macro system seems to be a heavier cognitive load as well (although it certainly has its own benefits, and some would say it's essential). I really like in Clojure and Arc how easy it is to pound out a macro when you need one.

I have less experience in CL and Racket. I would think that since CL's macros are unhygienic, they would be easy to write as they are in Clojure. It could be that I just haven't gotten the hang of Racket's macros yet, and that once you do they aren't any harder. Let me know if this is the case.

waterhouse• 16 years ago

For purposes of writing macros, CL seems to be identical to Arc, other than the name for the macro-defining construct ("defmacro" instead of "mac"). Which, of course, can be fixed with a macro.

There are three "things" about Racket's macro system: hygiene, pattern-matching, and phases. The sort of built-for-you way to do things (define-syntax with syntax-rules or syntax-case) is both hygienic and pattern-matching-based. But you can also make something that is hygienic but not pattern-based, or pattern-based but not hygienic, or neither; this last one is done for you in the library "mzlib/defmacro".

However, what you can't do, at least not without doing something like creating a new file and inserting (require (for-meta 2 <new file>)), is define a macro that you use in a macro body. For example, if you wanted to define "w/uniq", so that you could write

  (define-macro (swap a b)
    (w/uniq tmp           ;instead of (let ((tmp (gensym)))
      `(let ((,tmp ,a))
          ...etc

Simply writing (define-macro (w/uniq var . body) ...) will not work; a macro must be defined at phase level 2 for it to be used by a macro that is defined at phase level 1 (which is when macros are normally defined). And I have not succeeded in finding any way to make this work other than, as I said, creating another file and requiring it. (And, of course, if you want to use anything that isn't base Racket when defining 'w/uniq or whatever, you'll have to require that somehow, or do without.) This might be a minor complaint, but it does annoy me.

samth• 16 years ago

First, you don't need `w/uniq' in Racket - hygenic macros do that for you automatically. Here's `swap' in Racket:

  (define-syntax-rule (swap a b)
    (let ([tmp a]) (set! a b) (set! b tmp)))

But if you wanted to implement it, here's an easy way to do it in the same module

  (define-syntax (swap stx)
    (define-syntax (w/uniq stx) ...)
    (syntax-parse stx
      [(swap a b) ...]))

That said, the fact that you can't define macros to be used in macros in the same file can be annoying, and is something that we plan to add to the language.

vdm• 16 years ago

Where Racket has a clear edge on Clojure is learning about it. http://racket-lang.org/ is very good, and the included IDE means you can hit the ground running and start typing code from a tutorial within minutes.

Clojure by comparison is like moving to a new city and trying to make friends (with emacs).

evanrmurphy2• 16 years ago

Racket is good that way, but you can get immediate gratification from things like Try Clojure too.

And of course, the Clojure setup is actually attractive if you're already using Emacs, especially since it offers integration with SLIME. No one has been able to do that with Arc yet, as far as I know. (With Racket, I'm not sure.)

Racket vs Clojure (it's all about the data structures)

Related Stories