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