An Interactive Quine in Clojure | Hacker News Reader

An Interactive Quine in Clojure

blog.klipse.tech

47 pointstosh8 comments

I think that using any kind of self-referential technique in a quine is cheating.

If you learn how to write a quine in an 'ordinary' language, then the same technique works in Clojure or anything else.

SPOILER

There is basically a pattern to how it works. The program consists of a Start and a Finish section. In the middle are two arrays of strings. The first array is the strings of the code of the Start section, and the second array is the Finish section.

The Start and/or Finish section are the mechanics that prints out the two arrays of strings.

First print out the first array, eg, the Start section.

Next print out the first array again, but 'quoted' in a way that it actually forms the code that initializes the first array.

Next print out the second array in the same quoted way that it actually forms the code initializing the second array.

Last, print out the second array.

I quite like Quines :) Here's a bunch more of them: http://wiki.c2.com/?QuineProgram

Clojure is a great language on its own, like many articles show. But it feels like a big chore when you are doing business apps. You are between these two worlds, debugging imperative java code/libs and debugging clojure functional code/libs at the same time.

I have to respectfully disagree. I find that Clojure makes dealing with Java pretty straightforward, and in fact is (in some ways) a "nicer Java than Java", especially if you don't mind paying the cost of runtime reflection.

For example, the way you call a method is by using the (.myMethod args) syntax. Imagine we have something like this:

    (defn myCoolFunction [myarg]
        (.myMethod myarg "some argument"))

This effectively gives us a level of structured typing...I don't particularly care what myarg is, as long as it has myMethod defined.

There are other features that make interop with Java pretty pleasant. The `doto` macro allows you to have a nice encapsulated system when you have to do a bunch of property setting methods.

   (doto (MyClass.)
     (.setSomething 1)
     (.setSomethingElse 2)
     (.setSomethingElse 3))

Or, for that matter, the ability to directly compose methods and functions together without intermediate variables with the threading macros

    (-> myObject
        (.myMethod 1)
        (.myOtherMethod 2)
        (some-regular-function 3)
        (.anotherMethod 4))

My point is not to be a salesman for Clojure (even though I love the language), but rather to point out that the interop with Java tends to work very well, at least in my experience.

If you're using Clojure, you do end up using a lot of Java libraries, but that has more to do with how gigantic the Java library ecosystem is (indeed, this is one of the reasons behind the decision to host Clojure on the JVM) than how small the Clojure library ecosystem is (subjectively to me, it seems at least as big as the average for what you'd expect of a programming language of its size, and definitely higher in average quality).

Most of the time you use a wrapper that someone wrote and forget about it. If it's a itch you write your own.

Curiously, lots of wrappers are 1-4 years old and still work out of the box, which is a contrast with some other packages from other ecosystems (ahem node/js)

Have you actually used Clojure? Or you deduced that purely from reading articles about it?

Clojure tames Java and Javascript to the point that you don't even realize that you're working with them.

Is that "quine" not similar to the y combinator?

Reply on news.ycombinator.com