12 ms·

Clojure's n00b attraction problem

186 points by itistoday 16y ago

mindblink 16y ago
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....
- alnayyir 16y ago
  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.
  - WildUtah 16y ago
    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...
    - joe_the_user 16y ago
      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.
      - cageface 16y ago
        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.
      - alnayyir 16y ago
        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.
      - alnayyir 16y ago
        POSIX compliance is itself multiplatform and multipurpose.
  - mindblink 16y ago
    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....)
- technomancy 16y ago
  > 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.)
mkramlich 16y ago
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.
- arohner 16y ago
  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.
  - tetha 16y ago
    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.
watmough 16y ago
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.
- obiterdictum 16y ago
  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).
- dedward 16y ago
  "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.
ihodes 16y ago
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!
- mahmud 16y ago
  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.
- technomancy 16y ago
deleted 16y ago
[deleted]
mechanical_fish 16y ago
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.
- gcv 16y ago
  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".
  - deleted 16y ago
    [deleted]
  - qjz 16y ago
    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.
tkahn6 16y ago
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]
- devonrt 16y ago
  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.
  - tkahn6 16y ago
    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.
  - cema 16y ago
    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.
    - technomancy 16y ago
      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 http://emacsformacosx.com
      - cema 16y ago
mjw 16y ago
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.
- frio 16y ago
  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.
  - mjw 16y ago
    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.
    - technomancy 16y ago
      > 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.
frognibble 16y ago
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.
- mkramlich 16y ago
  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!)
  - technomancy 16y ago
    > 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 http://www.classicshorts.com/stories/lvta.html
    - mkramlich 16y ago
      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. :)
    - mkramlich 16y ago
      just Googled around ... now I know where to direct this fish! :)
    - gruseom 16y ago
      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.
cageface 16y ago
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.
- yason 16y ago
  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.
devonrt 16y ago
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.
derefr 16y ago
Now this is exactly the sort of thing we should be taking issue with (from the comments): > 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.
- tetha 16y ago
  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.
joe_the_user 16y ago
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).
- pjonesdotca 16y ago
  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.
  - joe_the_user 16y ago
    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.
    - pjonesdotca 16y ago
      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?
d0m 16y ago
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.
- technomancy 16y ago
  > 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/
  - DanielRibeiro 16y ago
    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)
10ren 16y ago
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.
jkkramer 16y ago
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 think the fact that there are so many coders that want to try Clojure despite its young age speaks to how compelling and powerful it is. The slick user experience will catch up soon.
- mkramlich 16y ago
  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.
  - Scriptor 16y ago
    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.
- fauigerzigerk 16y ago
  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 ;-)
- tetha 16y ago
  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.
csmeder 16y ago
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.
- pacoverdi 16y ago
  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.
mkramlich 16y ago
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.
c00p3r 16y ago
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?
- regularfry 16y ago
  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.
  - c00p3r 16y ago
    Working with the code as the data - lisp code isn't a lists itself, and JVM isn't a Lisp machine in general.
    - regularfry 16y ago
      > Working with the code as the data - lisp code isn't a lists itself $ script/repl Clojure 1.2.0-master-SNAPSHOT user=> '(println 1) (println 1) user=> (eval '(println 1)) 1 nil I don't understand what about this says "lisp code isn't a list itself" > and JVM isn't a Lisp machine in general Well, neither's the x86, but we do what we can.
      - c00p3r 16y ago
        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).
sandGorgon 16y ago
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-model-data-from-relational-databases-in-clojure 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.
jwr 16y ago
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.
daveungerer 16y ago
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 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.

186 points by itistoday 16y ago

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....

alnayyir 16y ago
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.
- WildUtah 16y ago
  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...
  - joe_the_user 16y ago
    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.
    - cageface 16y ago
      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.
    - alnayyir 16y ago
      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.
    - alnayyir 16y ago
      POSIX compliance is itself multiplatform and multipurpose.
- mindblink 16y ago
  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....)
technomancy 16y ago
> 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.)

mkramlich 16y ago

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.

arohner 16y ago
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.
- tetha 16y ago
  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.

watmough 16y ago

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.

obiterdictum 16y ago
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).
dedward 16y ago
"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.

ihodes 16y ago

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!

mahmud 16y ago
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.
technomancy 16y ago

deleted 16y ago

[deleted]

mechanical_fish 16y ago

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.

gcv 16y ago
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".
- deleted 16y ago
  [deleted]
- qjz 16y ago
  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.

tkahn6 16y ago

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]

devonrt 16y ago
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.
- tkahn6 16y ago
  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.
- cema 16y ago
  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.
  - technomancy 16y ago
    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 http://emacsformacosx.com
    - cema 16y ago

mjw 16y ago

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.

frio 16y ago
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.
- mjw 16y ago
  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.
  - technomancy 16y ago
    > 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.

frognibble 16y ago

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.

mkramlich 16y ago
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!)
- technomancy 16y ago
  > 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 http://www.classicshorts.com/stories/lvta.html
  - mkramlich 16y ago
    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. :)
  - mkramlich 16y ago
    just Googled around ... now I know where to direct this fish! :)
  - gruseom 16y ago
    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.

cageface 16y ago

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.

yason 16y ago
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.

devonrt 16y ago

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.

derefr 16y ago

Now this is exactly the sort of thing we should be taking issue with (from the comments): > 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.

tetha 16y ago
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.

joe_the_user 16y ago

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).

pjonesdotca 16y ago
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.
- joe_the_user 16y ago
  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.
  - pjonesdotca 16y ago
    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?

d0m 16y ago

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.

technomancy 16y ago
> 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/
- DanielRibeiro 16y ago
  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)

10ren 16y ago

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.

jkkramer 16y ago

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 think the fact that there are so many coders that want to try Clojure despite its young age speaks to how compelling and powerful it is. The slick user experience will catch up soon.

mkramlich 16y ago
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.
- Scriptor 16y ago
  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.
fauigerzigerk 16y ago
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 ;-)
tetha 16y ago
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.

csmeder 16y ago

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.

pacoverdi 16y ago
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.

mkramlich 16y ago

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.

c00p3r 16y ago

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?

regularfry 16y ago
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.
- c00p3r 16y ago
  Working with the code as the data - lisp code isn't a lists itself, and JVM isn't a Lisp machine in general.
  - regularfry 16y ago
    > Working with the code as the data - lisp code isn't a lists itself $ script/repl Clojure 1.2.0-master-SNAPSHOT user=> '(println 1) (println 1) user=> (eval '(println 1)) 1 nil I don't understand what about this says "lisp code isn't a list itself" > and JVM isn't a Lisp machine in general Well, neither's the x86, but we do what we can.
    - c00p3r 16y ago
      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).

sandGorgon 16y ago

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-model-data-from-relational-databases-in-clojure 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.

jwr 16y ago

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.

daveungerer 16y ago

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 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.