Live data from Hacker News

Getting Started With Clojure

jrheard.tumblr.com

71–80 of 113 posts

Re: Getting Started With Clojure

#71
post #53

I have been thinking about getting into Clojure, but time is precious. It doesn't seem like there are that many jobs out there, but I could be wrong. For those of you in the industry, why would I want to use Clojure? What would be a good project to try it on? A Web app? Why is it worth learning it?

This post is specially relevant for me, since last weekend I've decided to take a quick look at Clojure, as one of my personal goals this year is to get acquainted with a Lisp dialect. From my _very_ short experience (I've started coding a simple game), here are my two cents: - If your application is heavily dependent on state, which changes continuously and must be maintained during most of the execution time - like…

I'd like to contrast this: if your application is heavily dependent on state, especially state which is shared between threads, Clojure offers a concise, safe, and uniform way to understand and organize state transformations--at the cost of performance. Where fast mutability is required, it's easy to drop down to explicit locks, atomics, java.util.concurrent collections, et al.

I find the majority of my time in writing stateful programs goes towards reasoning about safety, and having access to STM lets me write correct code with less thinking. Then I focus on optimizing the parts where performance is critical.

Re: Getting Started With Clojure

#72
post #46
post #25

Earlier quoted context omitted.

The keyword syntax is transformed into a keyword instance by the reader, and keyword instances implement IFn as objects on the JVM, hence can be used as functions under clojure's evaluation rules. As I understand it, the roles which things like lists and functions play in a traditional lisp are replaced in Clojure by abstract datatypes corresponding to Java interfaces. Which on one hand is kinda neat because the core…

On the other hand it means the semantics become quite tied up in underlying JVM-related details and don't seem as clean/elegant as (say) Scheme. That's not very true. Instead, Clojure is defined in terms of specific abstractions. Whether those take the form of interfaces or protocols is irrelevant because it's the abstractions that count. If it were tied strictly to JVM-related details then ClojureScript would have b…

You have to use the java interop facilities if you want your own types to implement these abstractions though right?

I recall some debate about changing this so you can implement them using the native abstraction facilities in clojure (protocols), at which point I'd probably withdraw my point.

But yeah elegance is subjective. I use Clojure and broadly like it, JVM interop is really useful, but the lack of a crisp separation between clojure semantics and JVM semantics does still irk the purist in me a bit.

I guess I'd see Clojure and ClojureScript not as one language on two host platforms, but as one JVM language and another similar but not really source-compatible language on another platform which is influenced by it. Part of the philosophy seems to be to make pragmatic decisions which blur the boundary with the host platform, rather than try to abstract over the differences in APIs and runtime semantics.

Re: Getting Started With Clojure

#73
post #37

Earlier quoted context omitted.

You still need to install the JVM. Python/perl/ruby require installers because you need some platform-specific stuff for each. Running everything inside the JVM means you only need to ship what any arbitrary JVM library requires. In this case, its as simple as a .jar.

So Clojure has over (say) Ruby the feature that you don't have to install it. Yet you do have to install a JVM... How is installing a JVM better than installing any other interpreter or runtime?

"How is installing a JVM better than installing any other interpreter or runtime?"

Maybe, just maybe, the fact that Clojure isn't exactly the only program on earth running on the JVM and that, hence, there's a probability p far from zero that the JVM is already installed on your system / on your users' systems!?

Re: Getting Started With Clojure

#74
post #37

Earlier quoted context omitted.

You still need to install the JVM. Python/perl/ruby require installers because you need some platform-specific stuff for each. Running everything inside the JVM means you only need to ship what any arbitrary JVM library requires. In this case, its as simple as a .jar.

So Clojure has over (say) Ruby the feature that you don't have to install it. Yet you do have to install a JVM... How is installing a JVM better than installing any other interpreter or runtime?

This is the same advantage JRuby has in that Java developers don't have to convince someone in some chain of command about installing a new tool; it's just a jar file.

It's more of a plus if you already have a JVM in place.

Re: Getting Started With Clojure

#75
post #43

Earlier quoted context omitted.

I wanted to get Clojure on my secondary machine to do a little light fiddling, but as it turns out, Windows doesn't include wget or curl, and lein.bat requires those. So I have to download something that requires me to download something so I can download something that will let me install the thing I wanted in the first place. I think it could be a bit easier.

It certainly could be better, but none of the maintainers know Windows, and no Windows users have contributed improvements.

which makes me wonder if there is a simple java package to do that - probably not much to write a simple curl / wget for java so that on any machine with a JVM you can just lein your way to clojure...

Re: Getting Started With Clojure

#76
post #40
post #33

Earlier quoted context omitted.

True clojure assumes the existence of the JVM. However no other jvm language has gone with the language as library system which is a shame. Also, I don't think anything would preclude non jvm hosted languages from doing something similar. I think it is a better solution than say virtualenv from python.

matthavener wrote: "Running everything inside the JVM means you only need to ship what any arbitrary JVM library requires. In this case, its as simple as a .jar." Considering a .jar is a zipped directory tree, and a virtualenv is a directory tree, would you be happy if we zipped up virtualenvs and called them .par or something? I'm not sure what "language as library" will mean if you are not installing a VM or interp…

I think the important difference between virtualenv and lein is not the implementation detail of whether it is a zipped file or whatever, but in how you use them.

If you run a python program with virtualenv who decides weather to use python2.5 python2.7 or python3? Is it the author of the program? No, typically it is the user of the program who decides by symlinking /usr/bin/python

If you run a clojure program "lein run" who decides weather to use clojure1.3 clojure1.4 or clojure1.5. It is the author of the clojure program who decides by specifying in the project.clj file.

What I am saying is, I really prefer what seems to be the idomatic way of running clojure programs. This is totally possible with any programming language, but other jvm languages seem want to emulate the /usr/bin/runtime strategy. For instance the idomatic way to run a groovy script is to point /usr/bin/groovy --> ~/groovy-2.0/bin/groovy

and

$>groovy myscript.groovy

Re: Getting Started With Clojure

#78
post #34

> The reason that you won’t find yourself running `clj` often is that the REPL built into bare Clojure is pretty much garbage.... This is what rlwrap is for. Call `rlwrap clj` instead of `clj`, and you get all that and more (C-r, for reverse incremental search, etc). Works with every other REPL that doesn't bother to re-implement read-line.

Using a raw repl at all is painful compared to just selectively evaluating expressions from a buffer (say, in Emacs, VimClojure, or the Eclipse and IntelliJ plugins).

I agree! Anyone who ends up using Clojure more than a little bit will figure out how to use them, I'm sure.

But rlwrap is still a very useful tool because it works with every REPL. It will always be there, for those first sessions when you start learning a new language, or when you just need to answer some question about a language you rarely use, or when you write your own interpreter and don't want to also write read-line or an Emacs inferior-foo-mode.

Re: Getting Started With Clojure

#79
post #19

I didn't know about clojure-toolbox. That's pretty neat. One thing though, regarding this page, is that you don't need to install clojure with brew. Leiningen takes care of all that... clojure is just a jar that's included in your project, aka a dependency, and Leiningen manages that. This lets you tie a specific version of clojure to that project, which is handy for some legacy projects that aren't maintained anymor…

This is something that clojure got right before any other language I'm familiar with did. You do not "install" clojure. You depend on clojure just like you might log4j or joda-time

Did they pull this off before JRuby?

Re: Getting Started With Clojure

#80

Earlier quoted context omitted.

Please do. Good writers like yourself can make a big difference right now. There's also the Clojure Doc project - http://clojure-doc.org/

I am a mediocre-at-best Java developer, but somewhat better at writing. I'd like to learn Clojure and contribute to the community while doing so. Is the Clojure Doc project the best opportunity for someone like me?

Clojure Doc is easier since it doesn't require a CA.

IRC (#clojure and #clojure-doc on Freenode) is good for coordinating with other contributors.

Post reply on HN