QOTD: Mock Objects

Rich Hickey: "Your mock object is a joke; that object is mocking you. For needing it."

Good overview of Clojure. And probably the best introduction to a Lisp I've seen since Practical Common Lisp.

The upside of Clojure seem to be

  • It will run without having to make siginficant decisions on platforms (see the early parts of PCL as to why this matters). Via the JVM.
  • It has libraries targetted for programmers doing useful work. Via Java, but very un-CLOS like.
  • it's focused on concurrency/immutability in the language, as per Erlang. This only gets more important as we get sliced to death through having more and more cores. No locks.

The downside is that it's a Lisp. As a syntax, Lisp is a fail, which if you understand what Lisp syntax provides is a (the) great irony of programming. When you see how difficult it is for JRuby/Jython or even Groovy to break the syntax stranglehold Algol/C based languages have on the industry, you despair. Arguably, it loses out to those more syntactically appealing languages, who have a hard enough time knocking down the door. 

But I could see Clojure wangling it's way into Java shops. Like Groovy, it's syntax is lovely for things like DSLs, configuration or deployment, which are not at all well dealt with today in Java (notable exceptions aside). It should also be (and I'm guessing here) a good language for data pipelining or mapred style work. Incidentally Hickey says he doesn't need invokedynamic, and as I understand it, that translates to will run fast.

 

Tags:

    tags:

6 Comments


    We may be about to try out some clojurelets rsn. It'd nice to be able to drop self-contained clojure servlets into our webapp and see what sticks. Disagree wholly with the fail! Must have maximum programming power, and the programmers that can use it. Also, clojure isn't CL+CLOS. Maybe the problem in the past wasn't Lisp, just CL.


    It seems to be that Rich Hickey is very much _not_ making the same mistakes the Lisp community has been guilty of in the past, so I think there may be a chance of success. Maybe the time is ripe for a successful Lisp ...


    Invoke dynamic - yes, clojure uses java interfaces as well as multiple-argument dispatch, so invokedynamic would not seem to be able to play a big part.

    Let me get this straight, just as I am acclimating myself to groovy, the world is coming around to lisp? I'll believe that when I see it. But 10 years from now, I can imagine a programming community that thinks nothing of the (), which is exactly how one should feel about them.


    I've been playing around with clojure for a few months. Not used it to write any significant code yet, but have used it for a few support/diagnostic tools, where being able to make a few adhoc changes onsite is a big benefit over using compiled Java.

    The syntax is bound to put some people off, but maybe the familiarity with the Java libraries will offset the inital alien appearance of the syntax - which tbh only takes a few minutes to explain.

    I think the bigger stumbling block for java developers moving to clojure will be the functional nature of the language rather than the syntax.

    Lisp is nice for iterative development too, I've found it a lot of fun to be able to edit clojure functions in emacs, and with a couple of keypresses, having lisp-eval-last-sexp send the function redefiniton over a socket to a clojure repl in an app server without having to restart the server.


    Why do you think invokedynamic will be slow?


    Write a class Foo with method doBar() and print the stack trace in the method body.

    Now call it from Groovy, BeanShell, and Clojure. You'd be surprised! (agree withYou (I "its a fail))


Post a comment