Hacker News Reader

Comment by mechanical_fish | Hacker News Reader

It may just be me - I have a really bad allergic reaction to Java at this point - but the notion of making your new language powerful really quickly by linking it directly to Java has always struck me as akin to learning to fly more quickly by handcuffing a B52 to your leg.

This article does little to relieve my suspicions. It sounds like the Clojure newb experience is still a superset of the Java newb experience and the Lisp newb experience.

View on HN

Which part of the Java experience did you hate?

1. Java the language? It has abominable syntax and execrable semantics. Clojure fixes this; interop makes even strongly Java-flavored code tolerable. With Clojure, even Swing sucks less.

2. The JVM? Honestly, the JVM is rather nice. Except for the startup time, it's refreshingly fast. With Clojure, you don't really need to restart the JVM very often.

3. Learning about the classpath? It's no worse than PYTHONPATH or GEM_PATH, and far more self-contained by default. This makes deployment much easier. Yes, you have to understand it up-front, but what is difficult about it? It's a list of libraries your app depends on. Clojure is one of those libraries. Unless you need to compile your Clojure code into .class files, that's it.

4. Ant? It's a poorly-designed monstrosity with horrific XML syntax. Don't use it. You don't need it.

5. Maven? Yes, it's a beast, and unfortunately, you need it. Luckily, the latest version of Leiningen wraps it very nicely, so you don't need to learn the details. You also don't need to look at its XML. You just make a project.clj file, put in your dependencies, and run "lein repl".

The part of Java that I hate is having to read a whole lot of documentation about features and libraries that I do not want to use, and will strive not to use, and that I may not even have to use, and that the best critics agree are ugly as sin and overdesigned and counterproductive, but which I still need to understand because they're the standards.

I don't want "alternatives" to Ant and Maven and Swing. I do not want to have to know what Ant, Maven, or Swing are. If they are so terrible why are they still around? Can't we throw them away?

Well, no. We can't. Java is mature. You cannot throw anything away because existing libraries and codebases have dependencies on the old stuff. And you cannot throw away the existing libraries and codebases because they are why you are using Java in the first place; the language's maturity is its strength, perhaps its only remaining strength now that other languages are targeting the JVM. So you can only bolt more stuff on. Which just makes the whole edifice even larger.

If Clojure is forever tied to Java then I don't think it will ever be friendly for newbs, because I don't think Java is very friendly for newbs. ;) And if Clojure is nearly independent of Java -- and some of the comments here give me renewed hope that this is the case -- my advice would be to forget about advertising it to newbs for the time being. Get the Java out. Get it all out. Until you can write a book, akin to the Pickaxe book for Ruby, which teaches a newbie programmer all about Clojure and never mentions Java at all. Then sell me that book.

Clojure-in-clojure will get rid of a lot of the java stuff. However, in the end you'll be tied to some platform if you want to use non-clojure-native libraries like swing or jetty.

There is of course Clojure CLR http://wiki.github.com/richhickey/clojure-clr/ which is clojure but on the CLR. And there are fundamental differences due to the underlying types (but this should change with clojure-in-clojure) and you're dealing with .net interop instead of java.

But the fundamental issue you bring up is that you can't do a production-ready tour based purely on clojure, and some of that is most likely due to the pragmatic nature of clojure - why write a complete web server when you can just provide a wrapper for jetty? I do think these will come in time, but they haven't had the chance to be as battle-tested as the java equivalents...

I share your sentiment to a degree, but you could say something similar about Python and its C/Unix roots. Not everything in the Python API is pretty or consistent and throwing everything out once in a while definately has advantages. But it also means you're losing a huge potential constituency. More importantly, the constituency loses a potential language. Some people must be compatible with the enterprise to do their work but don't want to use Java the language.

In any event, there are things that could and should simply be scrapped. I dont' see why maven is an integral part of the Java platform for instance. Maven is actually a very depressing example because it shows that the complexity culture of Java isn't limited to the bureaucratic enterprise types who gave us J2EE.

After venting my spleen, above, I tried to figure out why I don't have the same reaction to POSIX that I have to Java.

Part of it is that Unix has a rather different philosophy. Part of it is that Unix seems to be better designed.

But I think the deeper answer is: I'm ready and waiting to develop an allergy to POSIX, if and when a pragmatic alternative appears. There is plenty of fuel for its funeral pyre: Where do you think I honed my own platform-griping skills? By reading The Unix Haters Handbook, which is really old by now.

But the difference between Java and Unix is that there are alternatives to Java. I'm sufficiently pragmatic that, if compelled to solve a problem with nothing but a roll of barbed wire, I'll learn all about barbed wire. And if I didn't have alternative means to solve my problems I'd probably try to love Java as well.

Just that the philosophy behind Java and Posix (or as you say C/Unix roots) are completely different.

The part of Java that I hate is having to read a whole lot of documentation about features and libraries that I do not want to use, and will strive not to use, and that I may not even have to use, and that the best critics agree are ugly as sin and overdesigned and counterproductive, but which I still need to understand because they're the standards.

Which Java features and libraries do you need to learn how to use (even if you never need to use them) to get started in Clojure?

I ask this as someone who is completely unfamiliar with Clojure, not to be snarky. But from everything I've read, it has always sounded to me like you could get started in Clojure without knowing anything more about the Java environment other than the fact that your code is running of a JVM.

That's a great question, and one that it's hard to find a clear answer to - and it's exactly the kind of thing that deters n00b programmers from jumping on the language.

I want to learn clojure, I don't really grok Java, and I'm not sure where to start - I don't have a clear explanation of how my clojure project fits into the JVM and how to build everything.

I wish examples would start without the repl, and instead write a simple "Hello world", turn it into a jar, and then expand on that, and then introduce the concept of the repl for iterative programming.

A clear explanation of where Clojure libraries sit in relation to Java libraries would help too.....

To get started with Clojure you need to know much about the Java platform. The first parts of Java that you will brush up against are classpaths and dot-separated namespaces and I don't think these are overly difficult to understand. clojure.core and clojure.contrib expose most of the Java standard libraries in a Clojure-esque way.

"t's no worse than PYTHONPATH or GEM_PATH, and far more self-contained by default."

Yes it is worse. ruby is far easier to start with.

  $ gem install json
  $ irb
  ruby-1.9.1-p378 > require 'rubygems'
   => false 
  ruby-1.9.1-p378 > require 'json'
   => true 
  ruby-1.9.1-p378 > JSON.parse({'1' => '2'}.to_json)
   => {"1"=>"2"}

    $ lein new myproj
    Created new project in: myproj
    $ cd myproj
    $ lein deps
     [copy] Copying 2 files to myproj/lib
    $ lein repl
    Clojure 1.1.0
    user=> (use 'clojure.contrib.json.read 'clojure.contrib.json.write)
    nil
    user=> (read-json (json-str {"1" "2"}))
    {"1" "2"}

I admit I cheated a bit: clojure-contrib comes with a JSON parser, and lein automatically includes a dependency on clojure-contrib. If I needed a different library, I'd have edited project.clj to include the dependency.

You cheated in two ways. Ruby Gems comes with every version of ruby I've ever used. If I go to the clojure site where does it mention lein? How do I add another lib? Here's the ruby site on this topic, which is linked from the top of almost every page on the site.

http://www.ruby-lang.org/en/libraries/

It's amazing that you get voted up when you are clearly avoiding my point. Show an example without cheating! What if I wanted to talk to mysql instead of using json. My ruby example would be the same. gem instal ...; irb; require; use it

How do I add another lib? ... Show an example without cheating!

It's amazing that you get voted up when you clearly did not read my post. I wrote: "If I needed a different library, I'd have edited project.clj to include the dependency." Let me explain that in detail:

lein generates the following default project.clj:

    (defproject myproj "1.0.0-SNAPSHOT"
      :dependencies [[org.clojure/clojure "1.1.0"]
                     [org.clojure/clojure-contrib "1.1.0"]])

Then you change it to:

    (defproject myproj "1.0.0-SNAPSHOT"
      :dependencies [[org.clojure/clojure "1.1.0"]
                     [org.clojure/clojure-contrib "1.1.0"]
                     [mysql/mysql-connector-java "5.1.13"]])

To wit: you add a dependency by including it in the :dependencies vector. For example, Berkeley DB JE would be [com.sleepycat/je "4.0.92"]. Then you run "lein deps", which takes care of the rest.

I hope you aren't arguing that editing a text file to include a dependency is too difficult, so I'll address your other point: the Clojure site does not mention Leiningen. There's actually a good reason for it: it is not a core necessity for using the language; you don't have to use Leiningen to use Clojure. If you understand the classpath, you don't really need it. Leiningen is a convenience, not a necessity of life.

I'll readily agree that an overview of available development aids would make for a nice addition to clojure.org. No definitive "Beginner's Guide to Programming in Clojure" exists. It would ideally explain how to get started at the REPL, how to use SLIME and swank-clojure to work with Emacs, and how to use VimClojure to work with vi, how to handle packaging, and how to deal with dependencies. It would also explain why and how someone might want to use Ant, Maven, Ivy, Leiningen, and the clojars.org repository. I'm sure that someone will write this guide some day soon.

This still assumes a lot. It assumes the lib is in a maven rep, it assumes use of lien which isn't standard like gems at this point, and let's be honest, maven is a beast compared to gems.

You said that clojure is as easy as ruby for a noob. The simple fact is that it isn't, and you've essentially admitted as much.

You don't read my posts, but you're getting upvotes, and this story still has traction on HN. I apologize for continuing this discussion, but you are spreading FUD, and some people might getting the wrong impression.

It assumes the lib is in a maven rep

Gems assumes that the gem is available in a Gem repository. I see no practical difference.

it assumes use of lien [sic]

"rubygems" is a separate package from MRI in Ubuntu. Standard or not, you have to install it. You also have to install Leiningen. With time, Leiningen or a tool like it will become a de-facto standard. Your original post strongly implied that no good tools exist for Clojure package management. This is false, and I refuted this claim.

maven is a beast

Yes. I wrote that in my original post; I'm glad you at least read that part. Leiningen uses Maven repositories and dependency resolution under the hood, yes. My example, however, does not use Maven at all. Most projects which use Leiningen to manage dependencies do not need to worry about Maven's intricacies at all.

You said that clojure is as easy as ruby for a noob.

Nowhere in any post did I say that Clojure the language is as easy as Ruby. That would have been a meaningless statement.

I actually said that the Java classpath is no worse that PYTHONPATH or GEM_PATH. I meant exactly that. Dependency path management sucks in every environment I've ever seen. I said nothing at all about the Gem toolchain, or how well it helps mitigate the problem. It certainly has had several years to mature. That said, six month-old Leiningen is decently close to the simplicity that Gems provides.

me: "It assumes the lib is in a maven rep" you: "Gems assumes that the gem is available in a Gem repository. I see no practical difference."

Hm, I can't figure you out. Your statement is missing the point. I don't know if you see that point and are cherry picking on purpose or if you don't know both ecosystems. I've done a lot of ruby, a lot of java, and a fair amount of clojure. I frequently run into very common java libs that are not in a maven repo. It's a common occurrence. I can't think of any significant ruby lib that isn't in a gem repo. The two situations are not equivalent.

"Nowhere in any post did I say that Clojure the language is as easy as Ruby."

Again, this is literally correct, but I feel you've implied it. You're like the Karl Rove of comp sci. The original comment was complaining that the clojure noob experience appeared painful. You then said that the java classpath was no worse than gem_path.

This is both wrong (the need for class loaders is one example of why, and my highlighting of the ease of use of gems is another), but it's also clearly implying that using libs in clojure is as easy for a noob as it is in ruby land. You can claim that you weren't implying that, but if that's the case then your reply was meaningless. Again, this is Karl Rove style hair splitting on your part.

Let me be clear then. The noob experience in ruby is much better than in clojure. Do you disagree? I've taken your statements as implying that, but you claim to have never said it explicitly, so now I'm asking you outright.

Wow, someone needs to calm down. Stop calling people Karl Rove because they aren't seeing the same argument you are. Maybe it's deliberate, maybe it's not, in either case the accusation looks foolish.

After using both, the noob experience in Ruby is better than in Clojure. I've had cases where more "advanced" library/package management was easier in Clojure (really, Maven) due to system local vs. project local package lookup. It's entirely possible that says more about my knowledge on the subject than anything else.

If someone accuses me of spreading FUD, while they are intentionally cherry picking at best, then I'm going to respond. It's my nature to respond to personal attacks against me.

Oddly you don't find him foolish for the FUD comment, just me for responding to it.

When Ruby was the same age as Clojure I don't think it was as easy as using RubyGems - the first time I became aware of RubyGems was when this new fangled Rails thing started!

The main difference is that you can modify your $LOAD_PATH at runtime in Ruby, while on the JVM it's fixed at startup.

This is particularly ironic because it's a cultural norm in the Ruby community to launch lots and lots of short-lived ruby processes to run your tests, while in Lisp-land it's much more common to have very long-running repl sessions with uptimes often lasting in the days range.

The CLASSPATH can be modified at runtime by writing custom class loaders. It isn't trivial, but it is possible. I had to do it to implement Hierarchy:

http://www.whitemagicsoftware.com/software/java/hierarchy/

You could put a temporary directory on your class path, and then unzip any jars into it. You could then reload Clojure source files, although I'm not sure if you'd be able to do anything about Java class files without a custom class loader.

The part of java i DO hate in relation to this discussion about clojure is the very poor integration into the underlying operating system, be it windows or linux. You have no keys in hand way of configuring system wide libraries for example.

A very simple example would be, let's say i want to open mp3 files and get their metadata, in python and in clojure, from a clean fresh ubuntu install : The python way of doing this would be:

    $ apt-get install python-mutagen
    $ python
    >>> import mutagen
    >>> (proceed)

For clojure, i developped a whole website http://www.radiozerozero.com with clojure, and i wouldn't even know exactly where to start. It's totally dependent on your installation, whether you use emacs + swank-clojure, if you integrate with leiningen or not, etc. Granted if you are already fluent with leiningen and you know which library you're looking for, it could be fast. But that's the point, you have to KNOW what to look for and to know how to use it. Every programmer knows how to use apt-get. And if ubuntu doesn't have it, there is easy-install, with every python library you could possibly think of.

And honestly that's why i use linux for development. I don't have to care about those things.

Clojure is 10 times younger than python, and is very far from its level of stability, so it isn't a fair comparison. But when you start using clojure for real world projects, you'll have to do this comparison anyway.

Oh cool! Maybe you can help me here... The part I could not stand about java was getting tied up to an IDE. Every tutorial, book and "experienced" java programmer in college seemed to insist on one (mostly eclipse or netbeans). That just is a strcit no no for me. Btw, this is the same thing that's prevented me from getting on with the whole lisp family of languages. They all ask me to either work in some kind of a sandbox or learn emacs.

I want to get started in a way that allows me to code and ship a hello world program in vim/notepad (ie in a n IDE independent fashion) from day zero. I can handle complexity and steep learning curves. I cannot handle not knowing and fully understanding whatever it is that the IDE is simplifying for me. And I don't want to be treated like a kid. Tell me how to get my hello world app into production the same way people shipping code in that language do as soon as possible. Is there any way for me to shed my java and lisp newbieness?

I'm a Common Lisp (CL) zealot and use it through Emacs but I have always disagreed with the suggestion a lot of experienced Lispers make to newbies that to get started with CL you should use a commercial IDE, Emacs+Slime or at least some kind of Slime clone for Vim. I understand their reasoning but it is simply too big an obstacle if you just want to check a CL out.

I do suggest picking a CL implementation with Readline support on the REPL and that usually means CLISP (http://www.clisp.org/) since it offers just that on the most platforms without a hassle. Then you can just edit "whatever.lisp" in your favourite editor and go through the command history for reloading, evalling, etc.

You can even skip the Readline support and pick other implementations and just start your script from the commandline. Just check the commandline options and CLISP even has #!/usr/bin/clisp (hashbang?) support.

So you can do a hello world in an IDE independent fashion. Hope that helps, mail me otherwise :-)

The JVM requires unexpected tweaks. It's surprising to discover that it doesn't use the time zone files provided by the OS, or that it might not use the available memory on your awesome new server. It's scary to realize that a lot of applications are deployed and certified to run only on a specific JVM version, and that getting security/bugfix updates for that version will get increasingly harder as time goes by. Before long, you have a proliferation of different JVMs that all need to be maintained, along with the host OS itself. These problems are acute with Java, compared to other languages, at least where the n00b is concerned.

By "specific JVM version", do you mean a major release version, such as 1.3, 1.4, 5, and 6? Or do you mean 1.6.0_20?

While Java code is generally not backwards compatible, it is typically forward-compatible. Most 1.4 programs run fine on JVM 6. In fact, I don't think I've ever seen one that doesn't — but I'll take your word that they exist. Personally, I've had more trouble with OS distributions shipping Python 2.3, 2.4, 2.5, 2.6, 2.7, and 3.0. I've also had trouble with Ruby 1.8.6, 1.8.7, and 1.9.x. JVM applications have generally just worked for me, regardless of platform version number.

In any case, applications being certified to run on a particular platform is hardly unique to Java. Any application whose vendor wants to reduce support load will be certified for a particular set of supported platforms. The situation is hardly better in C, with versioned .so objects and incompatible libc implementations.

Back on topic: I somehow doubt that these questions seriously turn off beginners thinking about learning Clojure.

In general, I mean the major release version, although I have seen applications pinned to a specific minor release because an update introduces a critical bug (which is especially frustrating when you want the update for security reasons).

I'm not a beginner programmer, but I avoid languages built on Java or .NET for these reasons, among others.

Well, I know with Scala, the claim is "improved syntax" but the actual code I've seen is an abominable concatenation of colons and stuff to make the horrible Java stuff less horrible - but only relative to Java. If Clojure can stand on its own, it could be nicer. But if its a push-me/pull-you language that's a half-breed of another, horrible language, it is just not appealing.

Judging by your comment, you have not actually looked at Clojure. I'll assume from your karma score that you aren't just a troll, and respond.

1. Clojure and Scala have nothing in common with regard to syntax or language semantics. Clojure is a parenthesized, fully-prefix notation dynamically-typed language from the Lisp family. Scala is an infix object-based language with a tremendously complex static type system.

2. Clojure stands on its own well enough. It has a maturing CLR implementation. In the future, it will be reimplemented in itself, which will permit simpler implementations on platforms such as, e.g., LLVM. Google for Clojure-in-Clojure.

3. You can write plenty of Clojure code without touching Java interoperability at all. It all depends on your problem domain. The code will not look anything like Java.

Thank you...

The B52 is better than nothing.

I've encountered several interesting languages over the years and they would all have been really nice and painless to use only if it wasn't for their lack of standard libraries that are just there.

Good set of standard tools and libraries are more important for a language's success than the language itself. The language has to be quite bad in order to drive programmers away from good libraries.

It's the Python problem: I know the shortcomings of Python quite well and I would happily use some other language instead except that Python has almost everything and despite the shortcomings of the language itself, Python is by far the fastest way to code a quick program to solve some random, particular problem.

I don't like Java but in the case of Clojure, the heavy machinery in JRE is a critical life-saver. Sure the Java side is ugly but at least it's there for Clojure.

The world is full of lisps that you can't do anything with. Clojure isn't one of them.

Just curious, what for you are the shortcomings of Python?

By the way, I completely agree with your main point here. When programming in Clojure, the availability of the Java libs is a very useful thing and that makes Clojure itself useable for me.

Let me think. These are for 2.x line, I still haven't tried Python 3.x as it doesn't seem to be significantly leaner and more modern than Python 2.x. I'll go for Python 3 no later than when I absolutely have to.

1) Scoping: there's no nested lexical scoping but only function and global scope. Makes many unnecessary workarounds necessary. 2) Read-only closures: you have to use the list hack, you can't just assign to any closed-over vars. 3) No do-while. Surprisingly often needed and thus irritating. 4) Some shortcomings aren't inherent in Python: while I would always like to prefer generators over lists and list comprehensions, and consider iterators elegant, I started considering iterators and itertools as cumbersome and old-fashioned right after I saw lazy sequences in action in Clojure. 5) Various function and method names that I just never, ever recall without first rethinking it again. Like dict.setdefault() which is actually dict.get() but with a default value. There's probably a dozen of these, and each time I just wonder: why is it so difficult to properly rename a few functions and gradually deprecate the old ones. 6) Last, the classical "there are no proper anonymous functions": lambda doesn't cut it and having to specifically name "anonymous" functions is cumbersome. Combined with scoping limitations, even using a generic name like "_" for local functions to be passed as arguments can cause trouble.

There used to be more but I have done less and less with Python recently and much more with Clojure, so the irks are fading.

When I've needed to work with Java libraries from Clojure, I've continually felt that Clojure provides enough abstractions over Java's syntax/conventions to make it not an issue.

Java libraries are so numerous and prevalent that I'm growing to prefer that kind of availability. Coming from Python, I'm not uncomfortable at all with Clojure's java library use.

It really doesn't feel like I'm interfacing with Java. It feels like I'm interfacing with a library designed with OOP. (No more verbose or unwieldy than necessary, given an object-oriented library.)

The problem is that many Java libraries feel over-designed compared to similar libraries for other languages. Java is the only place where you will find a class like FrogNibbleAdapterFactoryFactory :)

Several of them are over-designed. But the biggest issue, IMHO, is that the lack of closures (which is planned to come in the next version) made a proliferation of classes that would have been removed. Just pass a closure instead. Lock api's from the concurrency package are full of examples of this.

I don't know if this works on clojure, but Jruby and Groovy solved this partially, by making closures convert into such interfaces automatically. This however, does not solve the problem of the multiplication of classes.

yep, and you might have to look in 3+ different files just to figure what's the actual class being returned at runtime. so fun to maintain!

True enough. In those cases, standard operating procedure is to hope that someone already wrote a nice Clojure wrapper for the library you want to use. Or, you read the javadocs once, then write the Clojure wrapper, and release it for other people to use.

whereas in Python:

  import frog
  frog.nibble()

This newcomer experience felt to me like someone trying too much too soon. I picked enclojure ide for netbeans, and started it in 10 minutes. If I did not have netbeans, I'd just have to install it, and add the plugin. Using the repl was as easy as right clicking and choosing from a menu.

Comparing to other newcommer experiences (on linux os):

- Python: $ python (it is installed by default)

- Ruby: $ irb (it is installed by default with high probability, if not apt-get install ruby first)

- Java: download eclipse/netbeans/intellij, create new project, that's it.

Newcommers don't need build tools (let it be rake, rubygems, sbt, gradle, ant, maven, ivy, sake, leiningen, etc).

Of course, I agree that a getting started guide should pick one tool (possibly an open source one, but on this case all of them are open source), and guide you with it. Also, installing clojure with a repl client easy executable as irb/python's on linux package management systems (with the proper java dependencies) would help tremendously.

Reply on news.ycombinator.com