On 29 June 2010 06:11, cageface <milese...@gmail.com> wrote:
> On Jun 28, 9:14 pm, Michael Richter <ttmrich...@gmail.com> wrote:
>> Ah.  The Clojure community has already started down the road to Common
>> Lisp-style, smugness-generated obscurity and disdain.  Bravo!  Well-played!
>
> Not at all. Nothing would make me happier than "Clojure for Dummies"
> and Wrox Professional Clojure books on the shelves of every Barnes &
> Noble programming section. It's pained me to watch Python and Ruby far
> outpace the growth of any functional language in the last ten years.
> I'd love to stop looking for excuses to sneak things like Clojure
> under the radar at work and actually have a management mandate to use
> them.

It is very, very hard to get a decent characterisation of "newbies".
It's too wide a range. You've lumped at least three different
possibilities in the paragraph above alone:

- Completely new programmers ("Clojure for dummies") who need to learn
things like "what is recursion", "how do I do the same thing 10
times", etc.
- Experienced programmers in a scripting language (Python/Ruby) who
know how to program and need to know how Clojure differs (and there's
a whole subrange in here).
- People who work in a "Java Shop" ("sneak things like Clojure under
the radar" - I'm making assumptions here) and who work with the JVM
regularly, but maybe have little or no experience with
"non-traditional" languages.

And by my own argument, there are many more possibilities. Each of
these groups will want something different (or more likely, look for
the "best fit" in what they can find, and ignore the bits they don't
need).

It's important to look at what people are actually asking for in each
case, and not offer a single generic response to everyone (you'd
offend me if you suggested I need "Clojure for Dummies", but on the
other hand, you'd look "elitist" to someone who had never programmed
before if you launched straight into recursion or the advantages of
immutability when a new programmer asked for help getting his "Hello,
World" program to write its output 10 times...)

> The fact remains though that Clojure trades in heavy concepts. The
> syntax alone will simply be a non-starter for at least half the
> potential audience. Toss in concurrency and non-mutability and
> ubiquitous recursion which are tricky concepts no matter how cleanly
> exposed in the language.

Only for certain audiences. And anyone can learn given a sympathetic
teacher. What I wouldn't do is expect people to have to pick up
multiple things at once. That's why, for people who are new to the
language concepts in Clojure, I'd say you want a "fast start"
environment which lets them get straight to writing (simple) code.
Writing a "hello world" program, or your first recursive factorial,
shouldn't be hard.

"java -cp clojure.jar clojure.main myprog.clj" isn't hard, but a
trivial script that wraps that as "clj myprog.clj" is a little less
intimidating (and as a bonus, matches the expectations of people who
have seen Python, Ruby, or any one of many others). And a
straightforward "if you like IDEs like Visual Studio, grab this
package for now and you're off" will help people who prefer an IDE.
(They can make their own choice from the various options later, when
they have more experience).

> As many posters have said in this thread, you
> really do have to have a decent grasp on Java to do real work in
> Clojure so you're already on the hook for two languages, one of which
> is a baroque and provincial monster.

OK, that's a good point. For people who won't have an issue with
Clojure's concepts (e.g. Lisp users, people with a wider range of
programming experience, etc) this means the message is "you want to
learn Clojure - presumably because it's a high-level, sophisticated
language - so you also need to learn Java" (which, frankly, is pretty
much the antithesis of a "sophisticated language" in many such
people's minds).

Maybe JVM experience can't be avoided. But it's a bitter pill to
swallow for a certain class of newbies (and this is where I'd place
myself) so why not try to make it easier? As some examples of what
could be done:

- Build a page of "JVM concepts for non-Java programmers"
- Collect links to tutorial information on the key JVM concepts,
looking particularly for material which is as language-agnostic as
possible. The Jython, JRuby, Groovy, Scala people presumably also have
this problem - why not share any generic links with them?
- Promote clojure-like alternatives to Java tools (Leiningen vs Maven)
for people with non-Java background. Work with such people to pick out
places where the documentation of such tools assumes too much
knowledge, and work to improve it (I'll help here!)
- Give examples of how to use the more obvious benefits of the
JVM-hosted environment:
  * How to find and use some of the huge range of 3rd party Java code
out there (not interop, but finding things on the net, referencing
them in your project, etc etc).
  * How to use the scalability of the JVM (hosting a Clojure app in a
J2EE container, using standardised logging or resilience stuff, that
sort of thing).

Also, how about some examples of "best practices" for building a
larger Clojure project? I imagine that Java best practices fit in here
as well (for example, I recall recently seeing a comment to the effect
that the Maven approach of pulling external dependencies in from
public repositories, rather than maintaining local copies, was "the
right way to go" - that's a very unusual approach, from my non-Java
perspective...) Again, pointers to existing documents is fine here -
even non-Clojure examples, just if possible presented in a relatively
language agnostic form.

> Like any engineering problem,
> language design is about tradeoffs. Obviously Rich has worked hard to
> make Clojure as approachable as possible but you can't simultaneously
> emphasize tackling the really hard problems in software engineering
> and making CRUDDY webapps as painless as possible for the average
> programmer.
>
> Believe that Lisp, perhaps this time in the guise of Clojure, will
> conquer the world some day if you wish. There was a time when I wanted
> to think so too. As it is, I'd be happy if Clojure becomes acceptable
> enough for "hard problem" work that I'm not forced to use a soft fuzzy
> tool like Java or Python instead.

>From an outsider's point of view, a lot of the Java infrastructure
(J2EE, things like that) is over-engineered and/or more complex than
necessary. That's not to say that there aren't reasons for the
complexity, more that I don't see the benefits. And that may not even
be because I don't *need* the benefits, just that I'm not aware that
the Java way might help! So I'm open to someone showing me how I could
benefit - as long as the explanation isn't going to assume that I'm
aiming at a "cruddy webapp", but at least assumes that I hadn't
noticed the limitations of what I'm currently doing!

Paul.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to