Steve Yegge's main idea, that "Clojure needs to start saying yes," is
true on multiple levels. I'd like to focus the community's attention
on a neglected area that I believe is extremely important to Clojure's
success. I'll do so by restating Steve's main idea in slightly
different words:
Clojure needs to start saying yes...to newcomers.
That's a pretty self-evident statement to make, isn't it? If curious
programmers have a bad initial experience with Clojure, they'll just
leave. And I think this is happening. A lot.
Much of the "saying yes" discussion (see the discussions pointed to in
Tim Washington's post on 5/16/11) has to do with language and
implementation problems that lead to bad initial experiences with
Clojure. I want to focus on how the majority of the Clojure community
is contributing to bad initial experiences. To say it in the plainest
terms possible:
The Clojure community is, overall, newcomer-hostile.
The attitude that oozes from the words that are actually said sound
something like this: "We're smarter than you, and it shows in
everything we do. If you can't keep up, too bad. If you don't do
things the proper way--that is, the way *we* do them--you're not
welcome here."
Let me give you some examples.
EXAMPLE 1: clojure.org
Clojure.org is probably many newcomers' first exposure to the
language. On the "Functional Programming" page, the second page with
actual code in it, the reader is introduced to the defn keyword as
follows:
-----
defn is a macro that makes defining functions a little simpler.
Clojure supports arity overloading in a single function object,
self-reference, and variable-arity functions using &:
(defn argcount
([] 0)
([x] 1)
([x y] 2)
([x y & more] (+ (argcount x y) (count more))))
-> #'user/argcount
(argcount)
-> 0
(argcount 1)
-> 1
(argcount 1 2)
-> 2
(argcount 1 2 3 4 5)
-> 5
-----
And that's all it says.
Imagine being a newcomer to the language, probably someone who is
unfamiliar with any version of Lisp. Look at the terminology. What is
"arity overloading"? What is a "single function object"? What does
"self-reference" refer to? What does "using &" mean? And how does the
code sample work? If you've never seen Clojure code before, how could
you possibly expect this code snippet to make any sense, given this
*and nothing more* ?
Let's say the newcomer is lucky enough to get a REPL working. He
decides to use the built-in help system to find out more about defn:
-----
user> (doc defn)
-------------------------
clojure.core/defn
([name doc-string? attr-map? [params*] body] [name doc-string?
attr-map? ([params*] body) + attr-map?])
Macro
Same as (def name (fn [params* ] exprs*)) or (def
name (fn ([params* ] exprs*)+)) with any doc-string or attrs
added
to the var metadata
nil
user>
-----
Now imagine you're the newcomer who's used to looking at Java code.
Look at "([name doc-string? attr-map? [params*] body] [name doc-
string? attr-map? ([params*] body) + attr-map?])".
Which of these characters are actually something you'd type, and which
are notations that you *don't* type? What's an "attr-map"? What's the
format for a "doc-string"? There's *nowhere* on the clojure.com site
that tells you--or even give you hints on--how to make sense of this.
I still don't know how to read it, and I've been studying Clojure for
1 1/2 years! (And by the way, I do understand a lot about Clojure; I
wrote this article: http://pragprog.com/magazines/2010-11/getting-clojure.)
The problem is that the entire contents of the clojure.org site is
written by an expert, for experts. To a newcomer, it says, "This is a
language for Very Smart People, who don't need any more explanation
than this. If you don't understand--well then, this language is not
for the likes of you."
EXAMPLE 2: Cryptic code
Rich Hickey likes to use single-character variables, and code in
bloggers' articles often shows off Clojure's elegance through brevity
and minimalism. Such code may be praiseworthy when buried deep inside
a running application. However, it hurts the cause of greater Clojure
adoption when it's shown with little or no explanation in a blog
article. The result, unintentional as it may be, is that a beginner
thinks, "Yikes, how am I to make sense of this? They don't even bother
to give me any hint as to what is going on. Why bother even trying?"
Take, for example, the code below from one Clojure blogger. (I mean no
disrespect; this blogger has been most generous by sharing his
considerable skill with the community. My point simply is code like
this is easy to find.)
-----
(let [scoreboard {"Allison" [10 11 12 1e3]
"Franky" [5 2.34 1/4]
"John" nil}
scores (for [[player scores] scoreboard, score scores]
score)]
(/ (reduce + scores) (count scores)))
-----
Take a look at lines 4 and 5--there's a lot going on there, and it's
cryptic. It doesn't help that:
* the author uses very similar symbol names ("score", "scores", and
"scoreboard")
* the author uses the symbol "scores" to mean two different things
* in the surrounding text, the author doesn't even mention what the
code is supposed to do
I find this last point a lot in blog entries, sometimes even in
Clojure tutorial books: the author leaves several steps of learning
implicit and assumes the reader will infer them from the code itself.
Again, the message to the newcomer is, "We're writing for experts like
us. Find your own way in, if you want it bad enough."
* * * * * * * *
In conclusion, the Clojure community is unintentionally saying "no" to
beginners. It is doing so through its websites, its official
documentation, its community ambassadors (bloggers), and a lot of its
everyday conversation (Google groups, Hacker News, etc.).
I hope you can see that I'm saying these things only because I *want*
to see Clojure succeed. The community's "we're-all-experts-here"
mindset is driving newcomers away. (By all right, I should have been
one of them--but I'm an extremely stubborn cuss.)
Here's what will happen: Newcomers will walk out the door if we don't
give them every encouragement to stay, if we don't actively help them
with whatever problems they experience themselves as having. Clojure
will remain this quirky little fringe language with a small oddball
(but very smart!) following, less important than R or Lua or any
number of niche languages that have reached out to the larger
programming community.
Or...
*You* can decide to put some effort into Clojure's *social*
excellence, as well as its technical excellence. Talk to newcomers on
*their* terms; make them feel welcome. Remember that you once had
trouble understanding things about Clojure, and frame your answers in
ways that would help the old "newcomer" you. Spend just a little time
taking one newcomer under your wing. Show them code that promotes
their understanding, right now; once they understand, show them how to
"collapse it down" into the code that dazzles.
In the movie "Annie Hall," Woody Allen said something like, "A
relationship is like a shark. It has to be constantly moving forward
or it dies." I think this is true for a programming language as well,
and I think that "moving forward" means "growing the user base."
I've *been* saying yes to newcomers--go to http://www.GettingClojure.com
--but I need your help.
Are you ready to say yes...to newcomers?
Gregg Williams
manager, http://www.GettingClojure.com
On May 16, 7:33 pm, Timothy Washington <twash...@gmail.com> wrote:
> This is an interesting discussion. Rich Hickey and Steve Yegge recently
> weighed in on the Seajure discussion group (and later discussed on HN).
> Yegge basically takes Laszlo's position (clojure needs to start saying yes),
> while Hickey takes Nick's position.
>
> -http://groups.google.com/group/seajure/msg/2d2ec7ac9f2b4713
> -http://news.ycombinator.com/item?id=2466731
> -https://groups.google.com/group/seajure/msg/daa02d326a9ec69a
>
> I think it's an interesting point of contention. Hickey has done a brilliant
> job of building a very elegant functional language. But should we dismiss
> Yegge's point altogether? He's not the only one making it. Technomancy has
> complained that...
> *> Many patches etc run afoul of that because they don't meet that
> standard.*
> *The problem is not that they aren't applied, it's that they are ignored
> without discussion of their faults*
>
> Now, I don't want to reduce the conversation to gossip. But what IS the
> right balance between proper idiomatic code, and tools and training wheels
> for broader acceptance?
>
> Tim Washington
> twash...@gmail.com
> 416.843.9060
>
>
>
> On Mon, May 16, 2011 at 5:46 AM, Nick Zbinden <nick...@gmail.com> wrote:
> > Coming up with a clojure stack is not really clojury. I think clojure
> > does not really lack far behind scala/akka and its much simpler.
>
> > I don't really know about IDEs I can see how that could be a problem.
>
> > --
> > 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
--
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
