Clojure's n00b attraction problem(gregslepak.posterous.com)
gregslepak.posterous.com
Clojure's n00b attraction problem
http://gregslepak.posterous.com/clojures-n00b-attraction-problem
22 comments
I totally agree with this. Forcing users to stay in the REPL, poking simple toy examples is just boring and useless.
Just telling, a lot of people got into python, because they wanted to solve a certain problem (I know of an RSS scraper and a state machine framework prototype), and these people just started with a book about python and NO knowledge and after around 3 days, they knew a large amount of python and were sold, because the problem was solved and the language 'felt very good'.
I think generally, programming language designers should stop assuming that their language is novel, or different or whatever and people will be clueless learning about the language.
If you know like Java, C#, Python or Ruby, NO object oriented language will present you with really large surprises (until you meet Javascript with prototypes, and things turn around a bit and common lisp with generic methods and things warp a bit, but still, the basic concepts behind the language are nothing surprisingly new, I still have my objects which receive objects and do things depending on the message receveid).
If you know something along ML, Haskell or some other functional language, it will be really, really hard to surprise you with a functional language. Cool, oCaml has references? Cool, Haskell has monads? That is true, those things might be a bit different, but the basic concepts of immutability, functions and recursion is all the same, no matter what happens.
So, tl;dr? You language is not novel, your language is not new, I have used a language which is similar to your language, I will just be bored if you throw me into Programming 101, because your language is new and I will probably just walk away.
Just telling, a lot of people got into python, because they wanted to solve a certain problem (I know of an RSS scraper and a state machine framework prototype), and these people just started with a book about python and NO knowledge and after around 3 days, they knew a large amount of python and were sold, because the problem was solved and the language 'felt very good'.
I think generally, programming language designers should stop assuming that their language is novel, or different or whatever and people will be clueless learning about the language.
If you know like Java, C#, Python or Ruby, NO object oriented language will present you with really large surprises (until you meet Javascript with prototypes, and things turn around a bit and common lisp with generic methods and things warp a bit, but still, the basic concepts behind the language are nothing surprisingly new, I still have my objects which receive objects and do things depending on the message receveid).
If you know something along ML, Haskell or some other functional language, it will be really, really hard to surprise you with a functional language. Cool, oCaml has references? Cool, Haskell has monads? That is true, those things might be a bit different, but the basic concepts of immutability, functions and recursion is all the same, no matter what happens.
So, tl;dr? You language is not novel, your language is not new, I have used a language which is similar to your language, I will just be bored if you throw me into Programming 101, because your language is new and I will probably just walk away.
I think this is actually something Microsoft did "right" in regards to C#. One of the first things I read on C# back in 2003 was "C# Programmer's Reference". It was available directly on MSDN, it was easy to get to, and it was a no-holds-barred, for-experienced-programmers-only, introduction to C#. It didn't go into any philosophical discussion on why you should like C#, why you should like its features, etc., it just assumed "you're here already, so you must have reasons for being interested, let's just get down to business." It didn't go into explain "what are integers" or "what are classes", it just assumed you knew what these common concepts were and explained their specific details as they related to C#. After reading that and working for a while, I then read the technical spec, which filled in the gaps around the edges. I was a competent debugger in a week, a competent developer in a month, and an expert in a year.
Mastering the .NET class library took a lot longer, but that is a different issue, and I'm actually rather glad it's a separate issue (but that's a story for another day).
With Lisp and Python, I've tried to take a similar approach. Some of the PLT Scheme documentation -- excuse me, it's "Racket" now -- was very clean and concise. I also tried concurrently reading the R6RS spec, which was productive, though not quite as much as I wanted. Python, unfortunately, has full-programming-noob intros and a technical spec. The spec isn't bad, but it's difficult to parse down into the most important features. I scan through the tutorials, skipping most of the text evangelizing the language. That seems to work for now, but it's taken a lot more conscious effort on my behalf to stick to it.
Mastering the .NET class library took a lot longer, but that is a different issue, and I'm actually rather glad it's a separate issue (but that's a story for another day).
With Lisp and Python, I've tried to take a similar approach. Some of the PLT Scheme documentation -- excuse me, it's "Racket" now -- was very clean and concise. I also tried concurrently reading the R6RS spec, which was productive, though not quite as much as I wanted. Python, unfortunately, has full-programming-noob intros and a technical spec. The spec isn't bad, but it's difficult to parse down into the most important features. I scan through the tutorials, skipping most of the text evangelizing the language. That seems to work for now, but it's taken a lot more conscious effort on my behalf to stick to it.
I don't think such an approach can work with Clojure since the concepts that you bring from other OO languages do not really apply. I originally tried learning on my own by just using the documentation that is there and what I already know. That did not work. I needed something like Programming Clojure to go over all of the basics because Clojure basics and C# basics are different. Without understanding the Clojure basics you cannot do much. Granted someone with more of a background in Lisp or other languages could get started quicker and jump right in.
My point is, everyone has a "standard model" in their head about how all programming languages work. Kind of like how the same system of DNA works in all species. We extrapolate that model based on our exposure to different languages. Being exposed to only OO languages can lead to false assumptions about the over-arching framework of language, but such is the same for strict functional, procedural, or declarative exposure. As exposure to new ideas increases, the underlying assumptions dissolve into a better understanding, and the knowledge helps inform the programmer not only on the new language but on the old languages as well.
For example, I started my journey into programmerdom with JavaScript. Going to C (strict C, not C++) was a major mind-f*, and I didn't make the transition well. When I went to Java, I became much more productive. Learning the finer details of how Java tracks references and performs parameter passing, I suddenly understood C a lot better. Once I knew C better, I realized a metric ton of flaws in my JavaScript. All because greater exposure to language informed my underlying assumptions about what language means. The jump from Java to C# enhanced my understanding of event-driven programming (merely because of how C# provides syntactical features for delegates separately from the class system). I then realized I understood WIN32 events in C a lot better. A similar experience followed my forays into F# (failed attempt into functional programming, but not unproductive), back into C#, into C++, back into Java (briefly), back into JavaScript (this time with the knowledge of first-class functions), and then into Scheme (finally a successful foray into functional programming).
A parallel can be drawn from almost any feature in one language to another feature or application of features in another. It's the essence of Turing completeness, we can emulate any system in any other system (yes, albeit not efficiently).
For example, I started my journey into programmerdom with JavaScript. Going to C (strict C, not C++) was a major mind-f*, and I didn't make the transition well. When I went to Java, I became much more productive. Learning the finer details of how Java tracks references and performs parameter passing, I suddenly understood C a lot better. Once I knew C better, I realized a metric ton of flaws in my JavaScript. All because greater exposure to language informed my underlying assumptions about what language means. The jump from Java to C# enhanced my understanding of event-driven programming (merely because of how C# provides syntactical features for delegates separately from the class system). I then realized I understood WIN32 events in C a lot better. A similar experience followed my forays into F# (failed attempt into functional programming, but not unproductive), back into C#, into C++, back into Java (briefly), back into JavaScript (this time with the knowledge of first-class functions), and then into Scheme (finally a successful foray into functional programming).
A parallel can be drawn from almost any feature in one language to another feature or application of features in another. It's the essence of Turing completeness, we can emulate any system in any other system (yes, albeit not efficiently).
The best thing I found so far is clojure-box: Clojure Box is an all-in-one installer for Clojure on Windows. It's inspired by the Lispbox: you simply install and run this one thing, and you get a REPL and all the syntax highlighting and editing goodies from clojure-mode and Slime, plus all the power of Emacs under the hood at http://clojure.bighugh.com/
BUT it is based on emacs, and unless you're familiar with emacs, its not going to be too friendly...
Then, if you want web-apps, you'll have to get your head around ring, compojure or some other library. If you want graphics, at this stage you are kind of limited to whatever java can provide, and there is no easy IDE inspector to show you what's available / defined at any given moment...
There are many ways to get around all of these, but they all seem to require a fair bit of digging around, google-fu and whatever else is needed to make it go.
Maybe what clojure needs is a simple executable wrapper that handles the java classpath requirements, provides a simple (but extendable) IDE, provides some common sample projects like a simple web app (blog), graphics (temp converter), maybe multi-threaded (the ants.clj example) all complete with good documentation.
I know that would have made my life a bit easier...
BUT it is based on emacs, and unless you're familiar with emacs, its not going to be too friendly...
Then, if you want web-apps, you'll have to get your head around ring, compojure or some other library. If you want graphics, at this stage you are kind of limited to whatever java can provide, and there is no easy IDE inspector to show you what's available / defined at any given moment...
There are many ways to get around all of these, but they all seem to require a fair bit of digging around, google-fu and whatever else is needed to make it go.
Maybe what clojure needs is a simple executable wrapper that handles the java classpath requirements, provides a simple (but extendable) IDE, provides some common sample projects like a simple web app (blog), graphics (temp converter), maybe multi-threaded (the ants.clj example) all complete with good documentation.
I know that would have made my life a bit easier...
This seems like an obvious and easily attainable goal, but in fact, it isn't. The article suggests Python and Ruby provide a better n00b experience and that is far from true. For instance, Ruby becomes a nightmare as soon as you start mixing your own gems with gems installed by the packaging system. That situation is hard to avoid, as distros usually only support outdated Rails gems and the n00b that thinks 'let me just grab the latest stable Rails version from github' is in for some nasty surprises concerning incompatible combinations of gems. We solved this by moving to Enterprise Ruby and keeping everything local and selfcontained, but it is definitely not very n00b-friendly either. With Python I've had similar experiences: when I was in need of a decent XPath library (mind you, this was over 4 years ago), the best one I could find (4Suite) needed to be installed manually, with all the usual problems of missing -dev libs, install paths and whatnot.
A summary of the problem is: the configurations people run are so diverse that it is hard to provide installation instructions that work for all, or even most, of them. As soon as someone wants something not covered by the simplest of tutorials, many of them will run into issues.
I think the only solution is documentation. The only thing that works is catalogueing all known problems people have encountered, so that others can easily find solutions to those problems. The largest problem of this solution is that n00bs need to understand their systems and they often don't.
A summary of the problem is: the configurations people run are so diverse that it is hard to provide installation instructions that work for all, or even most, of them. As soon as someone wants something not covered by the simplest of tutorials, many of them will run into issues.
I think the only solution is documentation. The only thing that works is catalogueing all known problems people have encountered, so that others can easily find solutions to those problems. The largest problem of this solution is that n00bs need to understand their systems and they often don't.
While that's true, I think you're misinterpreting the usage of "n00b" here. People who are new to the language will be developing something small from the start, not trying to mix-and-match bleeding-edge, custom, distro-provided and language-specific-installation-tool-provided packages to achieve large or complex goals. "As soon as someone wants something not covered by the simplest of tutorials", they'll have the confidence in the language required to attack the problem in full force.
Think of it like a school system: the required years of school (the problems that everyone has to deal with, starting off) should be streamlined and easily-digested, with a lot of thought and care put into the user experience. Secondary education (the problems that individuals have once they're doing something complicated and meaningful) is allowed to be more free-form, because the user now has a base of skills to fall back upon.
Think of it like a school system: the required years of school (the problems that everyone has to deal with, starting off) should be streamlined and easily-digested, with a lot of thought and care put into the user experience. Secondary education (the problems that individuals have once they're doing something complicated and meaningful) is allowed to be more free-form, because the user now has a base of skills to fall back upon.
While true - Clojure,with it's java dependencies, is a good few notches harder to figure out by brute force - or at least it feels that way.
I picked up Ruby basics in a weekend of hacking around. I know there are still some things to figure out re: gems and big project management... but none feel insurmountable.
Python - same deal.
Clojure, on the other hand - has all this buzz on the net, but it's just that-much-more-complex to make even a seasoned language n00b a bit put-off. (if you don't have your head firmly around the java build process and basic librarires, it's hard to get past the repl in clojure)
I picked up Ruby basics in a weekend of hacking around. I know there are still some things to figure out re: gems and big project management... but none feel insurmountable.
Python - same deal.
Clojure, on the other hand - has all this buzz on the net, but it's just that-much-more-complex to make even a seasoned language n00b a bit put-off. (if you don't have your head firmly around the java build process and basic librarires, it's hard to get past the repl in clojure)
"When teaching someone a programming language, your first goal should always be to get them to the point where they've made something real in a domain they understand"
There are steps before that! The user's first concern is how to run the damn thing. If they can't get past this stage, they will give up and never return. The user should be able to download, install, and copy/paste/run "Hello, World!" with no bullshit. No IDEs, no configurations, no REPL. You have time later to sell all of that. A programmer who can't run from a file is tethered to your tutorial, even if they want to write more permanent code. Give them that freedom immediately, and give them a win immediately.
After they can actually run a program, then give an interesting example or two, and provide live links to up-to-date tutorials. It's irritating to see "official" links that are three versions out-of-date, and I see it too often. Examples should include a little bit of magic from the language, so the curious programmer thinks "Hm, that's not familiar. I wonder how that works!"
There are steps before that! The user's first concern is how to run the damn thing. If they can't get past this stage, they will give up and never return. The user should be able to download, install, and copy/paste/run "Hello, World!" with no bullshit. No IDEs, no configurations, no REPL. You have time later to sell all of that. A programmer who can't run from a file is tethered to your tutorial, even if they want to write more permanent code. Give them that freedom immediately, and give them a win immediately.
After they can actually run a program, then give an interesting example or two, and provide live links to up-to-date tutorials. It's irritating to see "official" links that are three versions out-of-date, and I see it too often. Examples should include a little bit of magic from the language, so the curious programmer thinks "Hm, that's not familiar. I wonder how that works!"
This is something node.js has done very well. Anyone with basic javascript experience (and really, isn't that everyone?) can go from zero to fast, functional web server in 2 minutes. Then hit github and figure out which simple web framework to play with (the fragmentation is either a problem or benefit depending on your view) and voila, another 5 minutes later, a full, integrated, single language web stack. Very good for noobs.
[deleted]
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.
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.
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".
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.
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.
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.
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.
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.
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...
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...
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.
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.....
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.
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"}
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
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:
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.
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"]])
(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"]])
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 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.
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.
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.
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.
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.
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/
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:
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.
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)
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 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 :-)
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.
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.
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.
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...
[deleted]
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.
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.
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.
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.)
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 :)
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()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.
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.
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.
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.
I certainly had very similar issues when starting out with Clojure (and am still running into them now), and I'd had previous development experience with Java and used Emacs before Clojure.
That being said, I do believe the "noob experience" is improving, and the community Clojure fosters is inviting and welcoming to newbies, as far as I've seen.
I've begun work on a tutorial to get people up and running with Clojure, but I will be recommending Emacs in it. As someone in the comments on the blog noted, if someone's goal with Clojure is to crank out a web app in 24 hours, they've come to the wrong place. Emacs enriches the experience, and I truly don't think it is as daunting as it is often made out to be. Gaining basic productivity in Emacs, even if not excellent productivity, takes little time, and the benefits of using Emacs seem large to me.
Regardless, the sentiment expressed here is important to consider. There should be a sanctioned IDE for Clojure, and it shouldn't just be Emacs and clojure-mode.el + Lein, at least not to start. Along with clojure.jar, I'd like to see Leibke's clj script packaged and promoted. That way, like with python, irb and newlisp, you can download and immediately get started with a functional REPL to see if you like the language before investing the time in setting up the ultimate IDE.
And yes, documentation. Please, documentation. It's in the style of LISP to have little to none documentation in code, as the code should explain itself. And it certainly should, but a little exlanation here and there can only help to enlighten those not as familiar with the language and save the time of those in a hurry.
But now is an exciting tine for getting into Clojure. Don't let the initial challenge of getting into it deter you!
That being said, I do believe the "noob experience" is improving, and the community Clojure fosters is inviting and welcoming to newbies, as far as I've seen.
I've begun work on a tutorial to get people up and running with Clojure, but I will be recommending Emacs in it. As someone in the comments on the blog noted, if someone's goal with Clojure is to crank out a web app in 24 hours, they've come to the wrong place. Emacs enriches the experience, and I truly don't think it is as daunting as it is often made out to be. Gaining basic productivity in Emacs, even if not excellent productivity, takes little time, and the benefits of using Emacs seem large to me.
Regardless, the sentiment expressed here is important to consider. There should be a sanctioned IDE for Clojure, and it shouldn't just be Emacs and clojure-mode.el + Lein, at least not to start. Along with clojure.jar, I'd like to see Leibke's clj script packaged and promoted. That way, like with python, irb and newlisp, you can download and immediately get started with a functional REPL to see if you like the language before investing the time in setting up the ultimate IDE.
And yes, documentation. Please, documentation. It's in the style of LISP to have little to none documentation in code, as the code should explain itself. And it certainly should, but a little exlanation here and there can only help to enlighten those not as familiar with the language and save the time of those in a hurry.
But now is an exciting tine for getting into Clojure. Don't let the initial challenge of getting into it deter you!
It's in the style of LISP to have little to none documentation in code, as the code should explain itself
Nearly every Lisp data type and all special forms take docstrings; documentation that gets compiled into your code that can be queried at run time. Lisp was the model for online Unix manual pages; APROPOS and DOCUMENTATION and builtin Common Lisp functions. There is even a defacto commenting style for documenting code at various levels; file-wide, top-level form, and small inline documentation.
The typical "Lisp experience" is a fat abundant system that rivals its underlying OS and platform. It even has a function, ED, to invoke the builtin editor/IDE, and some Lisps even have that builtin.
Nearly every Lisp data type and all special forms take docstrings; documentation that gets compiled into your code that can be queried at run time. Lisp was the model for online Unix manual pages; APROPOS and DOCUMENTATION and builtin Common Lisp functions. There is even a defacto commenting style for documenting code at various levels; file-wide, top-level form, and small inline documentation.
The typical "Lisp experience" is a fat abundant system that rivals its underlying OS and platform. It even has a function, ED, to invoke the builtin editor/IDE, and some Lisps even have that builtin.
> That being said, I do believe the "noob experience" is improving, and the community Clojure fosters is inviting and welcoming to newbies, as far as I've seen.
Indeed, if anyone complains about the noob experience in Clojure, it's probably a good sign that they don't use IRC. =)
Indeed, if anyone complains about the noob experience in Clojure, it's probably a good sign that they don't use IRC. =)
> I've begun work on a tutorial to get people up and running with Clojure, but I will be recommending Emacs in it.
Oh no. I hope I do not come off as a troll but this is exactly why I never could get started with any of the lisps. I can't stand emacs or netbeans or eclipse. This a personal taste for me but a very strong one. They all just feel wrong to me. Associating a sanctioned ide with a language is a bad idea. It brings unnecessary baggage for a new user. By closely associating your language to an ide and by having every tutorial throw it in my face, your community is just creating an unnecessary entry barrier for me. Please consider making the tutorial ide independent.
Oh no. I hope I do not come off as a troll but this is exactly why I never could get started with any of the lisps. I can't stand emacs or netbeans or eclipse. This a personal taste for me but a very strong one. They all just feel wrong to me. Associating a sanctioned ide with a language is a bad idea. It brings unnecessary baggage for a new user. By closely associating your language to an ide and by having every tutorial throw it in my face, your community is just creating an unnecessary entry barrier for me. Please consider making the tutorial ide independent.
"I've begun work on a tutorial to get people up and running with Clojure, but I will be recommending Emacs in it."
I'd like to strongly encourage against that. Here's my story: take from it what you will.
2 years ago, I decided to get started with Lisp. I looked around, and the most "official" path seemed to be using "Lisp Box", which is Emacs based. I didn't have any experience with Emacs, but I did keep hearing about it, so I decided to jump in and learn it (I was, after all, in a learning mood).
Of course, learning Emacs isn't a one-day affair. Sure, I could learn enough to do some Lisp (and I did). But it feels like a waste. So I started to learn a bit more about Emacs. Then more. Eventually, I was spending so much energy learning Emacs, that I didn't have any time left to learn Lisp. To this day, I've never learned Lisp.
In contrast, with Python, I spent a day with the IDLE shell that comes packaged as part of Python. Then I moved on to working in files, with IDLE as an editor. Eventually, I moved on to looking for a good Python editor/IDE, a search I spent a lot of time on. But the point is, I didn't need to learn a completely new environment to use Python. Don't forget, a n00b only has so much time/energy to learn, you don't want them wasting it on the editor but on the language. The editor can always come later.
I'd like to strongly encourage against that. Here's my story: take from it what you will.
2 years ago, I decided to get started with Lisp. I looked around, and the most "official" path seemed to be using "Lisp Box", which is Emacs based. I didn't have any experience with Emacs, but I did keep hearing about it, so I decided to jump in and learn it (I was, after all, in a learning mood).
Of course, learning Emacs isn't a one-day affair. Sure, I could learn enough to do some Lisp (and I did). But it feels like a waste. So I started to learn a bit more about Emacs. Then more. Eventually, I was spending so much energy learning Emacs, that I didn't have any time left to learn Lisp. To this day, I've never learned Lisp.
In contrast, with Python, I spent a day with the IDLE shell that comes packaged as part of Python. Then I moved on to working in files, with IDLE as an editor. Eventually, I moved on to looking for a good Python editor/IDE, a search I spent a lot of time on. But the point is, I didn't need to learn a completely new environment to use Python. Don't forget, a n00b only has so much time/energy to learn, you don't want them wasting it on the editor but on the language. The editor can always come later.
"Along with clojure.jar, I'd like to see Leibke's clj script packaged and promoted."
This is the answer to so many of the concerns cited in this discussion, I'm shocked that it has not been more heavily cited in this thread.
http://github.com/liebke/clj
I haven't used it yet, but from the documentation it looks brilliant. Dead simple package management and REPL tied together in a single command line tool. A noob should be able to go far with just this plus text editor of choice.
This is the answer to so many of the concerns cited in this discussion, I'm shocked that it has not been more heavily cited in this thread.
http://github.com/liebke/clj
I haven't used it yet, but from the documentation it looks brilliant. Dead simple package management and REPL tied together in a single command line tool. A noob should be able to go far with just this plus text editor of choice.
I think the article is somewhat disingenuous.
The author complains that running Clojure per the simple instructions in the distribution is not a valid way to program, yet, then tears into the complexity of much more complex setups, which due to the fast-evolving nature of Clojure are often extremely fragile.
The command-line invocation of Clojure will work if you have a valid Java setup, and with the addition of jReadline, you have a decent, albeit bare-bones, environment for experimenting. Copy and pasting code and running it directly works, and once you figure out how to 'source' in a file, you can start building something modularized and significant.
I wrote about a 5000 line Clojure program, fairly early on, and ran development cross platform with just an SVN server at home on my mac, svn clients on mac and Windows, and notepad for Windows development, and TextMate on the mac. GUI design for Swing was done in NetBeans and could be loaded on the fly easily by Clojure.
Note the conspicuous absence of Vim, Emacs, Slime or any of the other fragile setups that people think they need.
Clojure has great facilities for modularization, and it's dead easy to use, but familiarity improves with practice in doing what actually happens instead of just pushing buttons in an IDE.
The author complains that running Clojure per the simple instructions in the distribution is not a valid way to program, yet, then tears into the complexity of much more complex setups, which due to the fast-evolving nature of Clojure are often extremely fragile.
The command-line invocation of Clojure will work if you have a valid Java setup, and with the addition of jReadline, you have a decent, albeit bare-bones, environment for experimenting. Copy and pasting code and running it directly works, and once you figure out how to 'source' in a file, you can start building something modularized and significant.
I wrote about a 5000 line Clojure program, fairly early on, and ran development cross platform with just an SVN server at home on my mac, svn clients on mac and Windows, and notepad for Windows development, and TextMate on the mac. GUI design for Swing was done in NetBeans and could be loaded on the fly easily by Clojure.
Note the conspicuous absence of Vim, Emacs, Slime or any of the other fragile setups that people think they need.
Clojure has great facilities for modularization, and it's dead easy to use, but familiarity improves with practice in doing what actually happens instead of just pushing buttons in an IDE.
From my own beginner experience, while it may become easy when you found your most suitable tools setup, it's not easy to discover it in the first place. Yes, it may be great and modular, but it takes effort to find all the pieces you need and put them together. And doing this usually involves reading a lot of grossly outdated blog posts and HOWTOs, because there is no Official Way(tm).
"The command-line invocation of Clojure will work if you have a valid Java setup, and with the addition of jReadline, you have a decent, albeit bare-bones, environment for experimenting. Copy and pasting code and running it directly works, and once you figure out how to 'source' in a file, you can start building something modularized and significant."
That's the really big "IF" that the article is trying to address, I think. If you already have your head firmly wrapped around java, then Clojure isn't a monster - but if you don't, you have to cover a lot of ground to actually produce production code with it.
That's the really big "IF" that the article is trying to address, I think. If you already have your head firmly wrapped around java, then Clojure isn't a monster - but if you don't, you have to cover a lot of ground to actually produce production code with it.
One of the things I did when I started was Project Euler problems, a simple clojure REPL, and I used Etherpad as the editor - simple, cross-platform, cross-computer programming made ridiculously simple. And it worked very well - it let me experiment with clojure in a rewarding way, didn't need anything complex to set it up, and all the help I wanted was essentially right there in the "editor." That, and automatic versioning as well...
Pity etherpad is gone now... so I can't retrieve my editing history, but there are a few clones there that do the same.
Pity etherpad is gone now... so I can't retrieve my editing history, but there are a few clones there that do the same.
> That's the really big "IF" that the article is trying to address, I think.
Seriously? Java comes with most modern operating systems and is easy to install on the remainders. The article is about getting a dev environment set up beyond the JDK.
Seriously? Java comes with most modern operating systems and is easy to install on the remainders. The article is about getting a dev environment set up beyond the JDK.
I certainly didn't have much Java experience. Just reading some articles, and programming this game in Java 1.1 of all things! It still runs, try it! http://jonathanwatmough.com/jplanetoid/ptoidApplet.html
My point is that I fail to see how adding Vim or Emacs or some other IDE or framework actually helps you get your head round Java.
It's only my opinion, but learning enough Java API to write serious Clojure programs involves hitting an O'Reilly reference, and having the Java class docs open in a web browser, with the absolute minimum of distractions from other sources.
It may be unique to me (hopefully not), but Clojure was a drop-in replacement for Perl in my sketching and prototyping workflow that I follow during planning and design. Clojure has access to all the Java APIs, and with pure Java goodies such as drivers for Oracle, SQLite, SQLServer, it's easy to write code that runs well across Mac, Windows and GNU/Linux. None of this stuff needs an IDE, since by and large, just dropping .class files into an appropriate folder is most of the battle in Java/Clojure.
My point is that I fail to see how adding Vim or Emacs or some other IDE or framework actually helps you get your head round Java.
It's only my opinion, but learning enough Java API to write serious Clojure programs involves hitting an O'Reilly reference, and having the Java class docs open in a web browser, with the absolute minimum of distractions from other sources.
It may be unique to me (hopefully not), but Clojure was a drop-in replacement for Perl in my sketching and prototyping workflow that I follow during planning and design. Clojure has access to all the Java APIs, and with pure Java goodies such as drivers for Oracle, SQLite, SQLServer, it's easy to write code that runs well across Mac, Windows and GNU/Linux. None of this stuff needs an IDE, since by and large, just dropping .class files into an appropriate folder is most of the battle in Java/Clojure.
No one's mentioned the revolutionary perspective of this story: learning a JVM language in its own right, without regard to the JVM, nor Java, its libraries nor infrastructure. Most JVM projects do have regard to Java, because: the developers know Java and indeed are using it; and access to Java libraries and infrastructure is a key selling point. But it doesn't need to be that way. You can treat the language like a clean abstraction: most python programmers don't worry about the C underneath; most C programmers don't worry about the assembly underneath; most assembly programmers don't worry about the hex underneath. This a different way of seeing a JVM language.
It seems that the problems mentioned are common to all JVM languages (I was especially struck by similarities with JRuby, recently on HN).
Ideas: (1) look at other JVM languages. Copy their solutions. (2) someone develop a "JVM language support environment". It might include eg. a java server, so startup times disappear. (the JVM is damn fast, once it's going. And, kinda freaky to witness, it gets perceptibly faster, through JIT). Oracle might even include subsume it into Java, should it serve their business interest.
It seems that the problems mentioned are common to all JVM languages (I was especially struck by similarities with JRuby, recently on HN).
Ideas: (1) look at other JVM languages. Copy their solutions. (2) someone develop a "JVM language support environment". It might include eg. a java server, so startup times disappear. (the JVM is damn fast, once it's going. And, kinda freaky to witness, it gets perceptibly faster, through JIT). Oracle might even include subsume it into Java, should it serve their business interest.
This article definitely speaks to my experience starting in Clojure. Lots of the Clojure pioneers seem to develop in Unix environment like Linux or OSX. A lot of times, their unix shell build scripts are not directly portable to Window's cygwin. Yikes.
That being said, with a lot of the Clojure IDE plugins and build system reaching usable maturity, the n00b experience has gotten a lot better than when I started a year ago. So, keep up the good works, guys....
That being said, with a lot of the Clojure IDE plugins and build system reaching usable maturity, the n00b experience has gotten a lot better than when I started a year ago. So, keep up the good works, guys....
Unix is the language of hackers. If you use a hacker language (Clojure), one should expect the natives to be 90%< unix.
I empathize with your pains, but you can't walk into a biker bar and ask for filet mignon.
I empathize with your pains, but you can't walk into a biker bar and ask for filet mignon.
The premier implementation of Common LISP today -SBCL - doesn't and apparently won't ever run on Windows. Not at release quality, anyway. Windows users should be pleased Clojure runs at all.
Well, Windows users should switch, but failing that, they should be pleased...
Well, Windows users should switch, but failing that, they should be pleased...
I only run Ubuntu these days but a language that can't make itself multiplatform is just advertising its non-functionality. Languages of value should be abstract and multipurpose.
Windows compatibility is hardly a trivial problem. I'd much rather see the limited resources available for Clojure and SBCL devoted to taking more steps forward than another sideways.
Besides, most Windows devs are allergic to anything that doesn't come on an MSDN disc anyway.
Besides, most Windows devs are allergic to anything that doesn't come on an MSDN disc anyway.
Almost every windows dev I know (and I know many, owing to being a .NET dev professionally prior to Django/Python) are ignorant of anything that doesn't come from Redmond.
It'd be wasted effort, and the communities are smart enough to know that.
It'd be wasted effort, and the communities are smart enough to know that.
POSIX compliance is itself multiplatform and multipurpose.
Well said, alnayyir. I eventually fixed the script, and also endded up running a dual boot Ubuntu install. But, my experience with other more mature languages like Java and Ruby do not involve that level of pain and time. Like joe_the_user said, getting Clojure to function easily in multiple-platform will only help Clojure's credibility.
(In some ways, the very expressiveness of LISP creates a this cacophony of ways to do things, but that's a post for another day....)
(In some ways, the very expressiveness of LISP creates a this cacophony of ways to do things, but that's a post for another day....)
> A lot of times, their unix shell build scripts are not directly portable to Window's cygwin. Yikes.
True fact: there aren't very many Windows users who are willing to help with portability issues. Of course there's a chicken and egg problem here to be sure, but if you'd like the situation to improve, you should volunteer.
(A great place to start would be by updating the .bat file that comes with Leiningen to work with version 1.2--hint, hint.)
True fact: there aren't very many Windows users who are willing to help with portability issues. Of course there's a chicken and egg problem here to be sure, but if you'd like the situation to improve, you should volunteer.
(A great place to start would be by updating the .bat file that comes with Leiningen to work with version 1.2--hint, hint.)
The article's right that Clojure doesn't have a great newbie experience yet. However, the language and community is still very young:
Clojure: 3 years old
PHP: 15
Java: 15
Ruby: 15
Python: 19
Objective-C: 24
I like how the newest language in your list was essentially created in the 60's and yet the oldest was created in the 80's. Makes my head hurt.
There're several twists.
While the syntax and theory has been around for a long time, a language still needs its own libraries, build/package management software, editor integration, etc.
But Clojure already came with a lot of functionality because it could interface with Java, and therefore its vast collection of code.
But, Clojure and Java styles are very different from each other, so using Java libraries can be noticeably different from using Clojure libraries.
While the syntax and theory has been around for a long time, a language still needs its own libraries, build/package management software, editor integration, etc.
But Clojure already came with a lot of functionality because it could interface with Java, and therefore its vast collection of code.
But, Clojure and Java styles are very different from each other, so using Java libraries can be noticeably different from using Clojure libraries.
I'm afraid clojure will not catch up just by getting older. Improving the installation experience should not be too difficult, but for a community supported language to have great documentation is a monumental task. Writing documentation is boring after all.
Your list suffers a little bit from selection bias. It doesn't include all the old languages that never caught on. There are of course many reasons why a language doesn't become popular and lack of good documentation and ease of getting started is probably not the most important one.
I mean, there's C++, the language that managed to become popular by doing everything wrong ;-)
Your list suffers a little bit from selection bias. It doesn't include all the old languages that never caught on. There are of course many reasons why a language doesn't become popular and lack of good documentation and ease of getting started is probably not the most important one.
I mean, there's C++, the language that managed to become popular by doing everything wrong ;-)
I don't think this is a good argument, because eg CPython was the reference implementation of Python since day 1.
In other words, since the very very first day of python, people could tell a new python user to grab that one very specific package from python.org and go ahead until he is able to judge the different implementations out there, which solves precisely the problem mentioned in the article.
Same goes to an extent for Java and PHP.
In other words, since the very very first day of python, people could tell a new python user to grab that one very specific package from python.org and go ahead until he is able to judge the different implementations out there, which solves precisely the problem mentioned in the article.
Same goes to an extent for Java and PHP.
I thought his point about the burden of having to choose a code editor was, well, not a good point. I mean, a Clojure source file is text. Open it in a frickin text editor and edit away! That technique is easy and has been working fine for decades now. Go with what you know: vi, TextMate, whatever. You don't truly need syntax highlighting or an IDE when you're just dipping your toe into the water. The bigger issue you have is learning the language and start slinging the code and seeing what happens. And that can be done just fine with a REPL and text editor.
Most of the other points were, at best, just pointing out things you'd expect with a new language and new ecosystem. It takes time to polish things.
Most of the other points were, at best, just pointing out things you'd expect with a new language and new ecosystem. It takes time to polish things.
I agree with your sentiment (I upvoted you), but I see noobs in #clojure ask about IDEs almost daily.
You can pry my preferred text editor from my cold dead hands, but not all developers think that way.
You can pry my preferred text editor from my cold dead hands, but not all developers think that way.
I guess this is some kind of modern cultural issue. I think, people have no "native" editor. They began to develop language X in IDE Y in their university. Now they shall develop language Z.
Someone like you goes "well, so what? I got trusty vi here. It might not be the ideal tool for the job, but it will work until I find something better". Others will go: Oh. I cannot use Y here. So, I need to finde another tool to develop Z. And since I have always used IDEs, this MUST be an IDE of course.
I'm unsure if I like this or not.
Someone like you goes "well, so what? I got trusty vi here. It might not be the ideal tool for the job, but it will work until I find something better". Others will go: Oh. I cannot use Y here. So, I need to finde another tool to develop Z. And since I have always used IDEs, this MUST be an IDE of course.
I'm unsure if I like this or not.
Getting started with clojure can be tricky but the real hurdle is the language itself. It's beautifully designed but it's founded on some powerful but difficult concepts. Functional programming, iteration via recursion, multimethods, concurrency, macros, sexprs, the whole java stack under the hood you really do have to understand.
I'm all for making it as easy on the noob as possible but clojure will never be blub. It makes the hard problems easier but the price is that the easy problems are harder.
I'm all for making it as easy on the noob as possible but clojure will never be blub. It makes the hard problems easier but the price is that the easy problems are harder.
You're absolutely right.
I don't think that Clojure isn't meant to be an easy language for newbies, like Java. Clojure is a master's tool, like Unix. Good tools require time to learn and for the user to develop a bond with them.
It's precisely the functional programming, multimethods, immutability, concurrency, macros, and sexprs that make up Clojure's value. There are enough blubs already.
I don't think that Clojure isn't meant to be an easy language for newbies, like Java. Clojure is a master's tool, like Unix. Good tools require time to learn and for the user to develop a bond with them.
It's precisely the functional programming, multimethods, immutability, concurrency, macros, and sexprs that make up Clojure's value. There are enough blubs already.
I also had trouble getting started with Clojure because I was distracted by the official getting started documentation. I had smooth sailing once I decided to develop Clojure code the same way I develop Python code:
- Edit code in plain Vim.
- Run Clojure from the command line.
I have a single directory where I download the appropriate jars. I ignore Ant, Maven, Leiningen and all that other fancy stuff.
- Edit code in plain Vim.
- Run Clojure from the command line.
I have a single directory where I download the appropriate jars. I ignore Ant, Maven, Leiningen and all that other fancy stuff.
I dove into Clojure for the first time a month ago or so and came to the exact same conclusion!
Then I wanted to play with Compojure and think I got sucked into involving Leiningen (bleh). (Actually, I want to meet the person who named that project Leiningen and slap them with a small fish. What an annoying name to type and pronounce!)
Then I wanted to play with Compojure and think I got sucked into involving Leiningen (bleh). (Actually, I want to meet the person who named that project Leiningen and slap them with a small fish. What an annoying name to type and pronounce!)
> I want to meet the person who named that project Leiningen [...]
Jokes just aren't as funny if you have to explain them: http://www.classicshorts.com/stories/lvta.html
Jokes just aren't as funny if you have to explain them: http://www.classicshorts.com/stories/lvta.html
Ok, now that I get it, that is a very funny name. (Perhaps even up there with Rinda!) I'm glad I don't have to use it, though.
thanks, I've heard of that story and the connection. the next time I release a public project I'm going to name it after a character in my favorite story, "The Tales of Xygujthivxyenssix", and I'll email you asking you to help hack on it. :)
just Googled around ... now I know where to direct this fish! :)
Noob -> Intermediate -> Good -> Expert. That's the only possible way. The easiest it is for a noob to start, the fastest he will become an intermediate programmer. I mean, when you've never used a language, why would you spend 3 hours trying to configure everything? That's the wrong order.. First, let me try the language and let me have fun with it, then I will try to become an expert in it.
That's where python, ruby and javascript clearly win over scheme and clojure. On the other side, C++ is weird. There exist a lot of "get started with C++" such as accelerated C++ but, in my experience, a true beginner won't understand it because the language is too complex.
That's where python, ruby and javascript clearly win over scheme and clojure. On the other side, C++ is weird. There exist a lot of "get started with C++" such as accelerated C++ but, in my experience, a true beginner won't understand it because the language is too complex.
> First, let me try the language and let me have fun with it, then I will try to become an expert in it.
http://www.try-clojure.org/
http://www.try-clojure.org/
Great! No link process install necessary at all! Doesn't get much more noob friendly than that.
And for first lines of code, you might try:
(map (fn [x] (+ 5 x)) [1 2 3])
which is equivalent to
(map #(+ 5 %1) [1 2 3])
Which oddly requires as much characters as Scala's:
List(1, 2, 3).map(_ +5)
And for first lines of code, you might try:
(map (fn [x] (+ 5 x)) [1 2 3])
which is equivalent to
(map #(+ 5 %1) [1 2 3])
Which oddly requires as much characters as Scala's:
List(1, 2, 3).map(_ +5)
A lot of this applies to other JVM languages, like Scala.
Although I think Scala does some of this stuff better, there are still a lot of pain points for the newbie when it comes to different build systems, java toolchain, classpath, library dependencies, binary compatibility issues etc.
On the one hand it's great that tonnes of toolchain options already exist for Java which can be used with these languages. On the other hand, when coming from (say) the Ruby or Python world you just want and expect there to be one main widely-used/well-documented way to do basic things within a language's ecosystem, like installing libraries and so forth.
Rather than first having to figure out how the java world works, then make some arbitrary-seeming choices of java tools without much guidance, and then figure out how to work with the new JVM language on top of those.
It's about making sure this new crop of JVM languages feel like first-class citizens, rather than just add-ons for a java ecosystem which you're implicitly expected to know a lot about.
Although I think Scala does some of this stuff better, there are still a lot of pain points for the newbie when it comes to different build systems, java toolchain, classpath, library dependencies, binary compatibility issues etc.
On the one hand it's great that tonnes of toolchain options already exist for Java which can be used with these languages. On the other hand, when coming from (say) the Ruby or Python world you just want and expect there to be one main widely-used/well-documented way to do basic things within a language's ecosystem, like installing libraries and so forth.
Rather than first having to figure out how the java world works, then make some arbitrary-seeming choices of java tools without much guidance, and then figure out how to work with the new JVM language on top of those.
It's about making sure this new crop of JVM languages feel like first-class citizens, rather than just add-ons for a java ecosystem which you're implicitly expected to know a lot about.
As someone moving into Scala, with previous work experience mainly in Python and a University grounding in Java (which only briefly touched on Ant, Maven etc.)., I could not agree more. Getting Scala up and running cleanly and figuring out how to properly lay out and start a new project has been somewhat nightmarish, especially on Windows.
That said, however, when I moved from Maven to sbt, everything became a lot easier.
That said, however, when I moved from Maven to sbt, everything became a lot easier.
Yep, sbt is nice. Hopefully it'll get official blessing at some point.
sbaz (their package management / repository system) was a bit of a disappointment, though, in that people aren't really using it (the last time I checked anyway).
And you end up having to learn maven anyway (or at least maven repositories?) in order to depend on other java or scala libraries that use it.
sbaz (their package management / repository system) was a bit of a disappointment, though, in that people aren't really using it (the last time I checked anyway).
And you end up having to learn maven anyway (or at least maven repositories?) in order to depend on other java or scala libraries that use it.
> And you end up having to learn maven anyway (or at least maven repositories?)
Minor nitpick, but there is a big difference between learning Maven vs learning how to use maven repositories.
Minor nitpick, but there is a big difference between learning Maven vs learning how to use maven repositories.
In my personal experience, there's a great way for beginners of clojure to get up and running. It's called labrepl, by Stuart Halloway:
http://github.com/relevance/labrepl
It's so good that I think the clojure website should be linking to it. Here's the summary from the above link:
Labrepl is an environment for exploring the Clojure language. It includes:
- a web application that presents a set of lab exercises with step-by-step instructions
- an interactive repl for working with the lab exercises
- solutions with passing tests
- up-to-date versions of Clojure, contrib, incanter, compojure and a bunch of other libraries to explore
See instructions below for getting started with NetBeans/Enclojure, Eclipse/Counterclockwise, Maven, Mac/Linux command line, Windows command line, IDEA/La Clojure, and Emacs.
http://github.com/relevance/labrepl
It's so good that I think the clojure website should be linking to it. Here's the summary from the above link:
Labrepl is an environment for exploring the Clojure language. It includes:
- a web application that presents a set of lab exercises with step-by-step instructions
- an interactive repl for working with the lab exercises
- solutions with passing tests
- up-to-date versions of Clojure, contrib, incanter, compojure and a bunch of other libraries to explore
See instructions below for getting started with NetBeans/Enclojure, Eclipse/Counterclockwise, Maven, Mac/Linux command line, Windows command line, IDEA/La Clojure, and Emacs.
You shouldn't underestimate the importance of example code.
A nice, compact hello world example would help. I didn't see any example on the parent (I'll admit I skimmed). A nice example of being able to something fairly complex in a clear, simple fashion would excite me.
The size of the Java hello world program made me nauseous every time I've looked at learning it.
There was a thread a while back about how much patience people doing BS activities. Not only do I have little patience with wasted, I tend to think that intelligence correlates with not wanting one's time wasted.
If you can show me a language which is clear and won't waste my time, I'll love. I love Ruby (though it's just too buggy to use for serious programming still).
A nice, compact hello world example would help. I didn't see any example on the parent (I'll admit I skimmed). A nice example of being able to something fairly complex in a clear, simple fashion would excite me.
The size of the Java hello world program made me nauseous every time I've looked at learning it.
There was a thread a while back about how much patience people doing BS activities. Not only do I have little patience with wasted, I tend to think that intelligence correlates with not wanting one's time wasted.
If you can show me a language which is clear and won't waste my time, I'll love. I love Ruby (though it's just too buggy to use for serious programming still).
99% of my work over the last several years has been with Ruby working within and without Rails in everything between FXRuby apps to Realtime Rails reporting systems.
Please provide an example of your case that Ruby is "just too buggy for serious programming".
thanks.
Please provide an example of your case that Ruby is "just too buggy for serious programming".
thanks.
OK, maybe buggy wasn't the right word.
Maybe, "sloppy and ill-defined" - the only Ruby spec is the implementation of Ruby.
Maybe, "main implementation problematic" - the main Ruby VM never gives allocated memory back to the system - it garbage collects and keeps it for further allocation. That means that if you copy a 1 gig file, your Ruby instance allocates a gig and keeps it forever (one of the Twitter people described to me his horror at discovering this - two years ago!). That's why its standard to kill Ruby instances after a while in most large Rails installations.
Tell me those problems and problem like them are solved and I'll look at Ruby again. It's a beautiful language, the nicest syntax and approach I've seen.
Maybe, "sloppy and ill-defined" - the only Ruby spec is the implementation of Ruby.
Maybe, "main implementation problematic" - the main Ruby VM never gives allocated memory back to the system - it garbage collects and keeps it for further allocation. That means that if you copy a 1 gig file, your Ruby instance allocates a gig and keeps it forever (one of the Twitter people described to me his horror at discovering this - two years ago!). That's why its standard to kill Ruby instances after a while in most large Rails installations.
Tell me those problems and problem like them are solved and I'll look at Ruby again. It's a beautiful language, the nicest syntax and approach I've seen.
Thanks for answering. Not sure how to address your concerns except that #1 is sort of pedantic.
#2 is an interesting issue. Is this true of all versions (jruby, rubinius included) or just the MRI?
#2 is an interesting issue. Is this true of all versions (jruby, rubinius included) or just the MRI?
I really don't like the word n00b in this article. I feel like this article would be much better if they replaced the word n00b with beginner. When I read the title I thought the article was going to be about Clojure attracting to many childish people.
Exactly. To me, clojure is anything but a language for n00bs.
I consider it best suited for people with extensive knowledge of the Java platform and at least good notions of FP, needing a way to write more powerful and concise code without throwing away a proven codebase or compromising performance.
Even if new to Clojure (or Lisp) I would not call these people n00bs.
I consider it best suited for people with extensive knowledge of the Java platform and at least good notions of FP, needing a way to write more powerful and concise code without throwing away a proven codebase or compromising performance.
Even if new to Clojure (or Lisp) I would not call these people n00bs.
I'm very glad somebody brought this issue up, in a carefully written essay. It is a real problem. I come to Clojure from a Common Lisp background and the issue there was exactly the same (in spite of how old the language is): developers had their systems carefully tuned and weren't interested in newbie experience, while setting up a new environment was a major barrier.
The good thing about Clojure is that there are people who care about these things — see for example the leiningen and clj projects on github. Leiningen is already way beyond anything that was available for Common Lisp, for example.
There's hope.
The good thing about Clojure is that there are people who care about these things — see for example the leiningen and clj projects on github. Leiningen is already way beyond anything that was available for Common Lisp, for example.
There's hope.
I'd say the number one best practice for a programming language's main website is to show actual code on the home page.
And the number two best practice would be to get the novice to the point of writing and running their own "Hello World" program, in that language, as fast and as easily as possible.
Almost everything else is gravy.
And the number two best practice would be to get the novice to the point of writing and running their own "Hello World" program, in that language, as fast and as easily as possible.
Almost everything else is gravy.
[deleted]
More than syntax, I think the bigger issue is "thinking in clojure".
There have been far too many tutorials about Clojure-for-Ruby-users, etc etc.
But the problem is that clojure _strongly_ eschews object-oriented programming. But ActiveRecord and Django ORM are (or pretend to be) object-oriented. Therefore, there is a strong mismatch conceptually (e.g. http://stackoverflow.com/questions/3067261/how-does-one-mode...).
More than an IDE, there is a strong need to migrate _thinking_ from Rails/Django, etc. to Clojure.
But the problem is that clojure _strongly_ eschews object-oriented programming. But ActiveRecord and Django ORM are (or pretend to be) object-oriented. Therefore, there is a strong mismatch conceptually (e.g. http://stackoverflow.com/questions/3067261/how-does-one-mode...).
More than an IDE, there is a strong need to migrate _thinking_ from Rails/Django, etc. to Clojure.
I agree with the spirit of the post, but not (many of) the actual points. Look at the list of languages the author points to in the first paragraph: PHP, Python, Ruby and Objective-C. Only one of these has anything remotely close to an "officially sanctioned experience" and that's because it's a proprietary system.
His first complaint is that getting started with Clojure involves starting a REPL and that this is not how actual development is done. Well, no, it isn't. It is however, where you will spend most of your time. Not only that, but the most accessible documentation on both the Ruby and Python official sites mostly involve using a REPL. Clojure's only problem is that running the REPL is slightly more involved. Also, Clojure 1.1 is not already outdated and I'm not sure where the author got this idea. 1.2 will have some great features, but AFAIK will be completely backwards compatible. I'm not sure where a beginner would even learn about 1.2 without some serious internet trolling.
Next the author complains about how difficult obtaining Clojure is difficult. There is a "Download" link right on the clojure.org homepage that lists zip files for both 1.1 and 1.0, both of which include the source. This is less difficult than getting Python or Ruby, which involves downloading and installing a pre-compiled binary or compiling it from source. Also, the author complains about 1.2 not being available, even though 1.2 has not been publicized and is still in beta; true beginners probably don't know that 1.2 even exists.
The author complains about the fact that there are a whopping three choices for IDEs for Clojure, despite the fact that each of these IDEs also have plugins for Ruby, Python and PHP. There are no fewer IDE choices for these languages. If you ask most Rubyist which IDE you should use many of them will tell you TextMate, and editor that is neither free nor cross-platform. The author then brings up Xcode; well, of course every Objective-C developer uses Xcode, they don't have much choice. Clojure's myriad of IDEs is not a problem unique to Clojure.
Build systems, again, I don't think this problem is unique to Clojure. Where is the great documenation for Rake? Or Buildr? What build system do Pythonistas even use? Seriously, I've been using Python for a while now and I have no idea if there exists a canonical build tool. Comparing these platforms to the likes of Objective-C and .NET in terms of tool support is just unfair, in my opinion.
Like I said, I agree with the spirit of the post. Clojure is not an easy language to get into, but it has very little to do with the points the author made. Much of the cognitive load involved in getting started with Clojure has to do with the fact that it's a Lisp and most programmers are used to ALGOL syntax and Object Oriented semantics. Another thing to keep in mind is that Clojure is an incredibly young language. Much, much, much younger than Python, Ruby, PHP, Objective-C or even Scala. Taking into account Clojure's youth it's amazing that it's as far as it is.
His first complaint is that getting started with Clojure involves starting a REPL and that this is not how actual development is done. Well, no, it isn't. It is however, where you will spend most of your time. Not only that, but the most accessible documentation on both the Ruby and Python official sites mostly involve using a REPL. Clojure's only problem is that running the REPL is slightly more involved. Also, Clojure 1.1 is not already outdated and I'm not sure where the author got this idea. 1.2 will have some great features, but AFAIK will be completely backwards compatible. I'm not sure where a beginner would even learn about 1.2 without some serious internet trolling.
Next the author complains about how difficult obtaining Clojure is difficult. There is a "Download" link right on the clojure.org homepage that lists zip files for both 1.1 and 1.0, both of which include the source. This is less difficult than getting Python or Ruby, which involves downloading and installing a pre-compiled binary or compiling it from source. Also, the author complains about 1.2 not being available, even though 1.2 has not been publicized and is still in beta; true beginners probably don't know that 1.2 even exists.
The author complains about the fact that there are a whopping three choices for IDEs for Clojure, despite the fact that each of these IDEs also have plugins for Ruby, Python and PHP. There are no fewer IDE choices for these languages. If you ask most Rubyist which IDE you should use many of them will tell you TextMate, and editor that is neither free nor cross-platform. The author then brings up Xcode; well, of course every Objective-C developer uses Xcode, they don't have much choice. Clojure's myriad of IDEs is not a problem unique to Clojure.
Build systems, again, I don't think this problem is unique to Clojure. Where is the great documenation for Rake? Or Buildr? What build system do Pythonistas even use? Seriously, I've been using Python for a while now and I have no idea if there exists a canonical build tool. Comparing these platforms to the likes of Objective-C and .NET in terms of tool support is just unfair, in my opinion.
Like I said, I agree with the spirit of the post. Clojure is not an easy language to get into, but it has very little to do with the points the author made. Much of the cognitive load involved in getting started with Clojure has to do with the fact that it's a Lisp and most programmers are used to ALGOL syntax and Object Oriented semantics. Another thing to keep in mind is that Clojure is an incredibly young language. Much, much, much younger than Python, Ruby, PHP, Objective-C or even Scala. Taking into account Clojure's youth it's amazing that it's as far as it is.
regarding your point about Python build tools: myself, I've never found the need to use a formal build tool. Shell scripts work just fine. The beauty of writing a shell script is that (1) it doesn't reinvent the wheel (you reuse all the other shell commands & userland tools you had available anyway), (2) it's as short and simple as you want, and (3) as long as you only have to build on fairly similar systems (Unixen, Linux distros) it's really not that hard to make it cross-platform enough for your needs. True you don't get fancy target/lazy/dependency resolution semantics: but so? It sometimes just doesn't matter. Plus CPU + disk are cheap these days, programmer time is still not cheap.
I just use Rake :-)
on Clojure being young: agreed. Criticism about Clojure lacking polish at this stage strikes me as somebody criticizing a toddler with, "Head too big. Bad balance. Can't feed himself yet."
If anyone's interested I can write up a blog post which walks one through setting up clojure + emacs + swank/slime + Leiningen on Ubuntu. It was quite a frustrating experience.
The first hit on Google for setting up a Clojure dev environment on Ubuntu is incorrect.
[Edit: removed link]
The first hit on Google for setting up a Clojure dev environment on Ubuntu is incorrect.
[Edit: removed link]
That guide is, sadly, very out of date and ironically linking to it probably makes it more likely to turn up first in Google search results.
Which parts did you find frustrating? Did you use ELPA? I ask because I've been using Clojure for so long now that I don't run into a lot of hurdles setting up new development environments.
Which parts did you find frustrating? Did you use ELPA? I ask because I've been using Clojure for so long now that I don't run into a lot of hurdles setting up new development environments.
I did use the ELPA. It's really a great system. That combined with lein makes clojure very easy to use.
Getting started was, as I mentioned, frustrating though. Nearly all guides recommend the old way.
Getting started was, as I mentioned, frustrating though. Nearly all guides recommend the old way.
Speaking of ELPA. For some reason, ELPA did not work for me on MacOsX. I have just bought a mac, have no prior experience with it (my latest experience with an Apple computer is from early 1990s), so that may partially explain it. ELPA on Ubuntu was a snap, however.
As technomancy said, there's no way to tell what the issue was without more info, but was the Mac behind a proxy, by any chance? That was the issue I ran into when I first tried to use ELPA. Solved by setting url-proxy-services in Emacs:
http://stackoverflow.com/questions/1595418/emacs-behind-http...
http://stackoverflow.com/questions/1595418/emacs-behind-http...
There's not really any way to tell without more details.
Perhaps you were using Aquamacs? Aquamacs is a fork of Emacs that is not very well-supported since it's not cross-platform; it's impossible for people like me to test on. GNU Emacs is much more compatible: http://emacsformacosx.com
Perhaps you were using Aquamacs? Aquamacs is a fork of Emacs that is not very well-supported since it's not cross-platform; it's impossible for people like me to test on. GNU Emacs is much more compatible: http://emacsformacosx.com
Thanks for the hint. I have not been asking for help (there are plenty of places better suited for this, the Clojure community is very supportive). I was simply sharing my experience which I thought would support the point of view expressed by the parent post. Thanks again!
There is no shortage of blog posts on the topic, but there is definitely the shortage of well-maintained and up-to-date guides.
This.
The #1 problem with people getting started with Clojure on Emacs is the huge number of blogs out there with "hey, I finally got Swank working; here's what worked for me" posts that are way out of date. The official documentation (http://github.com/technomancy/swank-clojure/blob/master/READ...) isn't stellar, but once people find it they generally get things figured out just fine.
The #1 problem with people getting started with Clojure on Emacs is the huge number of blogs out there with "hey, I finally got Swank working; here's what worked for me" posts that are way out of date. The official documentation (http://github.com/technomancy/swank-clojure/blob/master/READ...) isn't stellar, but once people find it they generally get things figured out just fine.
Tell me please, why people think that it is lisp while it is just lisp-like syntax translator? Suppose, someone will wrote some wrapper which will translate a lisp-like syntax in PHP's internal representation and the code will be able to run on its buggy (but veeery popular) runtime and use its chaotic collection of modules, would we call it new lisp? Isn't it just another buzzword, and attempt to keep relevant the 15 years old decaying ecosystem?
Why do you think it's not a Lisp? It has macros, it's homoiconic, and it's got lists as its first-class data structure. I'm struggling to see what's missing.
Working with the code as the data - lisp code isn't a lists itself, and JVM isn't a Lisp machine in general.
> Working with the code as the data - lisp code isn't a lists itself
> and JVM isn't a Lisp machine in general
Well, neither's the x86, but we do what we can.
$ script/repl
Clojure 1.2.0-master-SNAPSHOT
user=> '(println 1)
(println 1)
user=> (eval '(println 1))
1
nil
> and JVM isn't a Lisp machine in general
Well, neither's the x86, but we do what we can.
That is just a strings on the screen. What is the internal in-memory representation of this? The pointers to functions and agruments, as is should be?
Btw, there was a link here to a blog-post from a jruby developer who argued that JVM is a crap for a dynamic languages (read: for anything except what it is) Why would you think it is perfect for a Lisp?
Do we need to start again about bad-by-design FFI, rudimentary and inefficient network and disk support, and so on?
Yes, it is well situated to some in-house development, but not for everything.
I know, some people believe it is good even for things like Cassandra, but I cannot imagine database system without things like efficient and low-level implementation of network layer (epoll/kuqueue support, tunable buffers, intellectual error handlers) and especially disk routines (O_DIRECT, proper caching and the like).
Btw, there was a link here to a blog-post from a jruby developer who argued that JVM is a crap for a dynamic languages (read: for anything except what it is) Why would you think it is perfect for a Lisp?
Do we need to start again about bad-by-design FFI, rudimentary and inefficient network and disk support, and so on?
Yes, it is well situated to some in-house development, but not for everything.
I know, some people believe it is good even for things like Cassandra, but I cannot imagine database system without things like efficient and low-level implementation of network layer (epoll/kuqueue support, tunable buffers, intellectual error handlers) and especially disk routines (O_DIRECT, proper caching and the like).
> That is just a strings on the screen. What is the internal in-memory representation of this?
> The pointers to functions and agruments, as is should be?
Effectively, yes. What would you expect to be able to do with this in a "real lisp" that you can't do in clojure?
> Btw, there was a link here to a blog-post from a jruby developer who argued that JVM is a crap for a dynamic languages (read: for anything except what it is) Why would you think it is perfect for a Lisp?
I don't. It is demonstrably good enough, though.
> <Further irrelevant JVM rantings>
Meh.
user=> (class '(println 1))
clojure.lang.PersistentList
> The pointers to functions and agruments, as is should be?
Effectively, yes. What would you expect to be able to do with this in a "real lisp" that you can't do in clojure?
> Btw, there was a link here to a blog-post from a jruby developer who argued that JVM is a crap for a dynamic languages (read: for anything except what it is) Why would you think it is perfect for a Lisp?
I don't. It is demonstrably good enough, though.
> <Further irrelevant JVM rantings>
Meh.
irrelevant JVM rantings - it is just a calling names. ^_^
I can do it too - the widely used and popular implementation of an outdated, bureaucratic-designed concept which is situated well to simple and bureaucratic in-house application development and became bloated with badly-designed and poorly implemented so-called enterprise stuff which most people tent to reuse without thinking just because they heard (very good marketing) that everyone else did.
It have a fundamental problem being designed as an isolated from an OS blob (same as Flash, btw) which is proved to be dramatically inefficient for most of task other that very basic and general computation.
It was a complete failure as an in-browser technology, desktop-technology, and even server technology in the case of highly-loaded or low-latency systems. It is still in use because of almost parabolic increase in the x86 processors power and the same-curved decrease in the costs of CPUs and RAM. That is why projects like Cassandra are there - hardware is so fast and cheap that you can use even a bloated and crappy tools.
In the mobile segment - J2ME and Dalvik VM have no relations with JVM. ^_^
I can do it too - the widely used and popular implementation of an outdated, bureaucratic-designed concept which is situated well to simple and bureaucratic in-house application development and became bloated with badly-designed and poorly implemented so-called enterprise stuff which most people tent to reuse without thinking just because they heard (very good marketing) that everyone else did.
It have a fundamental problem being designed as an isolated from an OS blob (same as Flash, btw) which is proved to be dramatically inefficient for most of task other that very basic and general computation.
It was a complete failure as an in-browser technology, desktop-technology, and even server technology in the case of highly-loaded or low-latency systems. It is still in use because of almost parabolic increase in the x86 processors power and the same-curved decrease in the costs of CPUs and RAM. That is why projects like Cassandra are there - hardware is so fast and cheap that you can use even a bloated and crappy tools.
In the mobile segment - J2ME and Dalvik VM have no relations with JVM. ^_^
Given that you've drifted completely off topic, I presume that you accept that your initial comment was completely incorrect and needlessly inflammatory?
> A true noob should probably install java, download clojure and clojure-contrib, run the repl, and stay there for couple 2-3 weeks. No IDE, no web app dev, just functional and concurrent programming with clojure in a REPL. They'll be much better off in the long run because they'll either give up (and save time) or learn something truly outside their comfort zone (and understand the benefit of getting setup for real development).
When teaching someone a programming language, your first goal should always be to get them to the point where they've made something real in a domain they understand. Then, they can bootstrap that domain knowledge, and its application within the new language, and use it to "grow into" the rest of the language.
The best thing for Clojure would be something that lets you write web-apps (or games, or visualizations like Processing...) in it two minutes after clicking "Download"—because those users would be able to say they've done something in Clojure, be able to say they're sure of their knowledge (because if they weren't, the program wouldn't have worked, would it?) and be able to proceed to learn more with confidence. The worst thing would be to download Clojure and be stuck at a REPL invoking (defproto) to overload String methods with no goal in sight—because that kind of knowledge doesn't stick, and won't get you anywhere.