
Clojure's n00b attraction problem - itistoday
http://gregslepak.posterous.com/clojures-n00b-attraction-problem
======
derefr
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.

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

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

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

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

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

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

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

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

~~~
dedward
"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.

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

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

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

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

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

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

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

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

------
d0m
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
> 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/>

~~~
DanielRibeiro
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)

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

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

------
joe_the_user
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
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
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
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?

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

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

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

------
sandGorgon
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...](http://stackoverflow.com/questions/3067261/how-does-one-model-data-
from-relational-databases-in-clojure)).

More than an IDE, there is a strong need to migrate _thinking_ from
Rails/Django, etc. to Clojure.

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

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

~~~
regularfry
I just use Rake :-)

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

~~~
cema
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
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>

~~~
cema
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!

------
c00p3r
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
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
Working with the code as the data - lisp code isn't a lists itself, and JVM
isn't a Lisp machine in general.

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

~~~
regularfry
> That is just a strings on the screen. What is the internal in-memory
> representation of this?
    
    
        user=> (class '(println 1))
        clojure.lang.PersistentList
    

A PersistentList is effectively a cons cell.

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

~~~
c00p3r
_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. ^_^

~~~
regularfry
Given that you've drifted completely off topic, I presume that you accept that
your initial comment was completely incorrect and needlessly inflammatory?

