Steve Yegge v. Rich Hickey re: "Clojure just needs to start saying Yes"

One of my favorite things about Clojure is the things it's said "yes" to, as first-class language builtins: char, vector, set, and map notation; first class "vars" (actually thread locals), ways to manage and dereference state, Java interop that doesn't set your hair on fire, namespaces, keywords and namespaced keywords, and a whole bunch of features I'm probably forgetting.<p>Instead, Steve Yegge is asking for things that don't seem terribly important to me. Excluding loops from the language core is obvious; Clojure makes it really easy to use the functional style instead and loops would serve as a newbie trap. For the last two weeks I've been programming Clojure full-time and haven't used a single loop macro or loop-recur. He complains about the lack of circular dependencies; but no circular dependencies across namespaces is A Good Thing just as you shouldn't have circular dependencies across Java packages or C++ libraries. The guy he cites who declared macros evil is obviously not a part of 'mainstream' Clojure culture, and maybe someone can explain Yegge's anger about single-pass compilation, because I don't get it.<p>And of course, Clojure is a highly extensible language that has <i>implicitly</i> said Yes to a vast ideascape.

I don't know much about Clojure, but I know an argument from authority when I see it, and Yegge is making an argument from authority. He does a lot of, "You need users and you don't know anything about language marketing and building an ecosystem." With the implication being that Yegge <i>does</i> know all about language marketing. I'm disappointed Yegge would go there...he's a smart guy. But, we all have bad days.<p>Unfortunately for Yegge's argument, he's never built a sizable language ecosystem from scratch, while Hickey <i>has</i>. So, he's making an argument based on authority that he doesn't have and the person he's arguing with <i>does</i>.<p>Hickey has done a brilliant job stripping off all the "I know better than you" bits of Yegge's comments, and brings it back down to the discussion of the language and nothing else. Frankly, it was pretty devastating, and I'm surprised Yegge walked so cockily into it. If I had any dogs in this fight, I know whose side I'd be taking.

Good discussion. I agree with Rich in principle: a language's design should not say "yes" to everything, but I agree with Steve in some of the particulars.<p>After programming in Clojure for two weeks, I had a list of complaints about the language. It has now been two years, and nearly all of my objections went away as the language evolved and as I adapted to using it. Two years later, I just have two notable things to grumble about. Coincidentally, they seem to be closely related to Steve Yegge's concerns.<p>1. No condition system. This is a big deal. Clojure piggy-backs on Java's exceptions, and currently lacks a good mechanism for user-defined error handling. Unfortunately, Java exception handling also happens to suck, since it throws away data in all stack frames from the throw to the catch. Implementing better error handling is under discussion on the Clojure development page (<a href="http://dev.clojure.org/display/design/Error+Handling" rel="nofollow">http://dev.clojure.org/display/design/Error+Handling</a>). (Steve complains about the lack of non-local transfer of control, and he has a point: it could be used to make an arbitrarily powerful condition system, see <a href="http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html" rel="nofollow">http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h...</a>).<p>2. No built-in debugger. The way CL code doesn't just crash and throw away stack information is amazing. The lack of this feature in other languages is appalling.<p>In addition, I sort of agree that being forced to forward-declare things is annoying. I got used to it, but I don't really like the restriction. I do understand the reason behind it, though: auto-interning symbols in the reader (as Common Lisp does) can be confusing and occasionally problematic.

This is a fascinating case study. I got sucked into reading the entire thread. Steve Yegge is talking about cultural and marketing issues that seem obvious to me. The responses on the list may not be representative of the community, but assuming they are, one can hazard a guess about the long-term trend: there's a clear failure to connect with what Yegge is saying. (Edit: I deleted an unnecessarily personal example here.)<p>Yegge isn't arguing for the abandonment of taste and rigour in a race to incorporate every kitchen appliance into the language. He's arguing that languages and communities that take a prescriptive (someone said "paternalistic") stance end up marginalizing themselves by their own rigidity, and that the antidote for this -- as well as the passageway toward wider adoption -- is to actively listen to and court new users. I couldn't agree more.<p>(Side note, this is why I like Common Lisp. Its loosey-goosey flexibility that always assumes the programmer knows best leads to an awesome fluidity that finds its around any obstacle. CL is unpopular, but not because of its pluralism. Qua language it has a deep respect for the user.)<p>There's another point here. Whether you're a fan of Steve Yegge or not (I didn't use to be, but after nodding with everything he said here I am now), he has a proven ability to mobilize a significant body of programmer opinion. To ignore what this guy says about the marketing of programming languages itself already displays a foolish disregard for the market.

I'm not sure why Yegge is talking about the Shangri-la of non-local exits, but... He is right that the culture of Clojure has some issues and often rejects ideas even when they're obvious, and it's not clear why.<p>Examples I've run into:<p>1. The current clojure lambda shortcut-syntax is atrocious, and we can do better. Why don't we do better?<p>2. Clojure could really benefit from a scheme-esque Macro-by-example library. A few exist but they seem largely ignored by the community; despite well-known-benefits to such a system in the normal daily use of macros.<p>3. A strange hatred of macros. Yes, some people are reasonable and argue that functions should have primacy over macros because of composability (and they're right). But then there are people who will tell you macros are always bad, and if you show up in freenode #clojure to ask for help with them they will <i>actively laugh at you.</i><p>I love Clojure and I feel like I know it pretty well, so I'm not trying to say Clojure is considered harmful, etc. But I do think that some of Yegge's criticisms—while poorly delivered and sometimes poorly expressed—have an element of truth to them.<p>* <i>Full disclosure: I was involved in an effort to write a Clojure book for O'Reilly until I got involved with a new startup and had to terminate my involvement in the effort. I may not be the most unbiased judge of Clojure.</i>

Oh god I so hope that Rich ignores this. A "just say yes" mindset is incredibly dangerous; yeah, ok, a trillion people use C++ but that doesn't make it a good language. Clojure to date has been built with great discipline, and it would be <i>tragic</i> to see it go off those rails in the hopes of satisfying a huge mass-market that a) Clojure is fundamentally unsuited for and b) will never be happy regardless. When I say that Clojure is fundamentally unsuited for a certain "mass-market" I don't mean that it shouldn't or won't catch on and into i.e., the TIOBE top 10 -- just that it can't be everything to everyone, and shouldn't try to be. It's a wonderful language that understands what it tries to be, and I hope the Rich never forgets those underlying intuitions on (state, identity, functionalism). Abandoning that discipline own't make it any more powerful, but will just muddy the language to try and satisfy people who won't be impressed because of it.

Youngme Moon, in her book "Different", offers the idea that one should say Yes where others say No, and No where others say Yes to produce meaningful difference. Once you go this way, you iterate and improve on the ways you say Yes to accentuate the difference. There are similar suggestions in other recent books on differentiation (Moore's "Dealing with Darwin", for example)<p>Look at all the ways Clojure says Yes, where other lisps/languages have said no. Being a lisp, embracing the JVM, immutable by default and everywhere, first-class concurrent primitives -- clojure should probably say No if it compromises these core goals. It should say YES when it furthers these tenets.<p>I don't use it enough to really understand Yegge's gripes, but the best move for clojure is probably to make these things possible as libraries if it doesn't want to embrace it in the core, and iterate on the core so that it's the only possible choice when you are in the situation that requires it.

If you can't say no, what do you say to the users who are begging you to say no because they like the language as it is? Every language design decision is a compromise, and a person empowered to make those decisions is going to make people unhappy. Just look at Perl and Python: Perl said no to people who demanded orthogonality, and Python said no to people who wanted a free-for-all TIMTOWTDI language. Java said no to deterministic finalizers. C++ said no to exceptions that could be restarted. All those languages are doing fine.<p>A better idea would be to never turn your back on any class of users -- ignoring their specific requests, perhaps, but always making sure they can solve their problem using their language. Even that strategy doesn't require language support for everything. CPython does just fine with the scientific computing community by punting to C bindings, for example.<p>The examples Yegge provides don't make any sense to me. The need to port Java code to Clojure is questionable, since Clojure provides good Java bindings. If you want a more Clojure-y version of a Java library, then a straight line-for-line port is not much of an improvement. As for the LOOP macro, you don't have to add everybody's little helper function into the standard library. I'm a big fan of languages adding helper functions to standard libraries if there's one obvious way to write them and the act of adding them will save everyone else from including their own version in all their projects, but a LOOP macro is absolutely NOT that.<p>(Unless it's just a straight-up reimplementation of Common Lisp's LOOP macro, which would do exactly one job, which is allowing Common Lisp programmers to be more comfortable in Clojure. Hey, guess what -- Common Lisp programmers already have one of the easiest paths to learning Clojure, since they know a Lisp already. Many non-Lisp programmers are tackling the learning curve and embracing Clojure, so CLers can't complain that it's too hard. Plus, many Common Lisp fans regard LOOP as an abomination and never use it anyway. Writing control structures in a complex DSL that few programmers bother to learn completely is not one of Common Lisp's best features. Saying "no" to a Common Lisp-style LOOP macro would be the right thing to do.)

Yegge points to the Tiobe language index as a metric to language adoption, and implies that "No" languages have low uptake. What about Lua? The Lua implementers don't accept public patches, rather they will rewrite public patches that are submitted, and only if the change makes sense (citation: <a href="http://lua-users.org/lists/lua-l/2008-06/msg00407.html" rel="nofollow">http://lua-users.org/lists/lua-l/2008-06/msg00407.html</a>). Yet Lua is #12, up from 20.<p>Saying "no" to language suggestions is not a bad thing, it all depends on the goals of the language and the philosophy of the language authors. Perhaps Yegge should try and understand the reasons why patches aren't accepted, rather than force their acceptance via his soapbox.

I'd say be careful about reading into this thread too much. It's a public, ad hoc discussion, and won't be as carefully phrased or researched as a blog entry. Cherry-picking one quote, like "Clojure just needs to start saying yes" from a discussion like that and treating it like a mantra doesn't improve discussion nor is it fair to any of the participants.<p>It's an interesting thread, I'm glad it was linked, but take it for what it really is. Hickey's response is a good counter-argument to "languages should always say yes" but basically ignores any of the other subtleties of the discussion. His comment is a starting point, but he hasn't engaged and no one has responded (yet).

Clojure is an aesthetically clean, wonderful language for parallel manipulation of lazy sequences. However after using it as my main language for slightly over two years, I found myself all-to-often butting heads with its paternalistic functionalism (trust me, I'm a grown up, I can manage a little bit of mutable state without shooting myself in the foot).<p>While I would definitely use Clojure as a first choice for any project which was primarily defined by a need for massive parallelism, I am now happily using common lisp as my main language, and I'm a noticeably happier and more productive programmer (while most tasks can be transformed into a purely functional lazy sequence manipulation, the process often takes time and results in code which is harder to read and maintain).

Clojure already says YES where other lisp-based languages said NO to. (Instead of wrapping all java, let's use it for its strength. Don't just use list, use vector, map, etc. No tail-recursive? Aight, let's do it anyway and find a work-around)<p>Now, we make to differentiate users and what they ask. Is it a new clojure user who is used to C++ and try to code C++ in clojure and suggest missing features? Or an experienced clojure user offering useful patches to the community. In the first case, the right answer should probably be "Oh, but XYZ is already in Clojure, it's a little bit different than what you've been used in C++, but in fact, it's even more powerful. Here's how you can do it [...]". In the second case, it's more complicated.. but we should go toward the Yes if it adds real value to a day to day task. I mean, even thought clojure is great, you can't guess everything that will be needed.. so you shouldn't be shy to add missing stuff.<p>Still, Rich's answer is pretty great IMO.

One of the best things I like about clojure actually is how it is currently keeping away new users.<p>It is probably the best thing for clojure right now, looking at the rapid changes that have been happening from 1.0 to 1.2, 1.2 to 1.3 .. Hickey has a clear vision for what he wants the language to be and it doesn't look like he has finished thinking about it yet. It is good that the community is still small and the tools are immature. When the language design is at a stable state then would be the time to start evangelizing.<p>I keep thinking about what happened with ruby .. it is such a beautiful language but the community grew too fast and it is now stuck with so many conventions that could have been better thought out.

This whole "I used the language for 2 weeks so now I am qualified to change it radically" attitude is well-established in the Lisp community (yes I know Steve Yegge is a veteran lisper, but this still applies, especially to some of the other commenters). The authority on this is Brucio, the fictional author of "Lisp at Light Speed" <a href="http://replay.web.archive.org/20080722232746/http://brucio.blogspot.com/" rel="nofollow">http://replay.web.archive.org/20080722232746/http://brucio.b...</a> Bruce's First Law of Lisp is "If it does not do exactly what you expect with zero hours consideration or experience, it is a bug in Lisp that should be fixed."

I don't understand Rich Hickey's point. How does his thought experiment address Steve Yegge's points?<p>Would someone care to explain?

My quest for languages that say "Yes" ended with assembly. I started in BASIC and found the strait jacket it imposed much too restrictive. Then Pascal was the big teaching language but it has it's own ways. It wasn't till I got good as x86 assembly that I felt totally in control and able to do things just the way I wanted. Having achieved that feeling 20ish years ago I've been running away from it ever since. C and C++ proved that at some size of code base even the most brilliant programmers can't do memory management correctly[1] so I love that modern language said "No" to memory management. I've worked at large software companies where the programming style guides ran to 80+ pages. That's 80 pages of documentation of how people will format their code so that it's done consistently. I love that Python said "No" to letting people format their code however they wanted. It's likely that these aren't the kinds of things that Steve Yegge is talking about, but there are a lot of things it's worth saying "No" to, and if they bug you (like they used to bug me) there's always assembly language.<p>[1] <a href="http://research.microsoft.com/pubs/70226/tr-2005-139.pdf" rel="nofollow">http://research.microsoft.com/pubs/70226/tr-2005-139.pdf</a>

For starters, I dislike the title of the post. The thread language design and community/eco-system creation around the language.<p>I am not aware of how if at all Steve is qualified to make a well judged statement on either language design or the communities that develop around languages since afaik he has not done either.<p>I have been following the thread from the beginning since I am on the list, Steve Yegge comes of as delusional with his claims on how he influenced the Python community with one of his blog posts.<p>On the couple of instances where Steve was requested about what he contributed in tangible fashion, he mentions months of effort an JSwat command line support, everyone interested should check out the project and his contributions on code.google.com<p>On the second occasion he refuses to publish anything that the community can see or use or enhance.<p>I hope he proves me wrong, but at this time, he is blowing a lot of hot air, off the wrong end, and should stay away from the blog post he intends to write, his facade of being a real voice for a developer community is crumbling fast

I'll just quote Antoine de Saint-Exupery here: "You know you’ve achieved perfection in design, Not when you have nothing more to add, But when you have nothing more to take away."

I see a lot of people bashing Yegge, bashing Tiobe, praising Clojure, and praising Rich Hickey. All of that is strawman bullshit though as far as I can tell.<p>Virtually no one seems to be addressing what I think is Yegge's core point: <i>neglect</i>.<p>Is it true that there is a considerable body of extant patches/libraries/fixes out there that are being <i>neglected</i> so that a sizable portion of Clojure's user base is feeling <i>neglected</i>.<p>If so, then Yegge has a valid point. If not, then argue why he is wrong about <i>neglect</i>.

I think more important than always saying Yes is providing the ability to make anything possible.

Isn't this how we got C++?

My understanding of what Steve Yegge is saying is that the community needs to be open to ideas and debate, and in his experience it is not. He pulled a few examples from the top of his head.<p>At least that's how I read it.

Yegge is full of it. Python said "no" over and over again, and it's gone like gangbusters.

Mr. Yegge says, "it only takes a few people to poison a community"<p>Yes, and it is the kvetchers that are putting a black cloud over a language and community that has been evolving quite nicely otherwise.

Let's see how Steve's statements stand against evidence.<p>&#62; to get users, languages have to say Yes<p>What languages in wide use today got popular because they said yes? Is it<p>C, Java, Python, Lua?<p>I don't think those qualify as "yes" languages. Oh, maybe it is<p>Perl.