For the record, I'm trying to get a better understanding of the issues myself. So mea culpa. I should have provided more context on technomancy's statement. From my understanding, the issue had to do with technomancy not getting patches accepted at a faster pace, into clojure core (anyone with more insight, please chime in):
http://offtopic.bestinclass.dk/post/2532135003/has-clojure-development-stalled But that's also been countered with the opposite - that Clojure has had breakneck pace and innovation (which from my vantage point, seems to be true). So I just took the broader acceptance / clojure stack vs. not, to be another aspect of which direction to pull the community (or, is the community saying "yes" enough). Sean, you're correct that they're not directly related technically. I'm a former java developer, whose tried scala, ruby, etc. And with clojure, I haven't been this intellectually excited since I designed my first DSL :) So I'm interested to know if there are any problems and how to address. Thanks for the comments - clarifies things for me. On Mon, May 16, 2011 at 11:50 PM, Ken Wesson <kwess...@gmail.com> wrote: > On Mon, May 16, 2011 at 10: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 > > After a cursory look at the first of these, I'd have to sympathize > with Hickey here. > > Point 1: Yegge says "To get users, languages have to say Yes. You > can't ever say No." > > This is a false dicohtomy. It's certainly possible to say Yes some of > the time, without saying Yes all of the time. > > Point 2: Yegge says "You shouldn't force people to code in a certain > style -- and by 'force' I mean exerting cultural pressure by saying > things like 'If you would rather use Common Lisp, go ahead'". > > But if Clojure starts accepting any randomly suggested features into > core (and particularly lots of mutable this, non-threadsafe that, > etc.) it will stop being Clojure and *become* Common Lisp, or > something more like it than like Clojure is now. And there's no point > in that. If you want a thread-unsafe, non-lazy, mutable Common Lisp > running on the JVM and calling Java libraries we already have Armed > Bear. Clojure must distinguish itself rather than be very like, but > incompatible with, an existing language if it is to survive. And so > far it has, but not if Yegge had his way. > > But then there is a point that both sides have missed. Hickey says > this in response: "As far as 'languages have to say yes', I propose > the following thought experiment - YesLang. Each user of YesLang will > get a coupon entitling them to add or change one feature as their > needs require." > > But each user of Clojure already has this coupon, and in a reusable > form. It's called "defmacro". If you want to significantly change or > add to Clojure, you can, even down to a pretty low level. If you want > other people to use your shiny new feature you can make your macro(s) > and supporting code available as a library -- though people may very > well choose not to use it. You can even implement your own reader, add > reader macros, and preprocess your code through that if you want to, > though nobody seems to bother, or fork the whole project, since it is > open source. > > We also have: > > > 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 > > If this is true, and the faults weren't so self-evident that they > didn't need any discussion, then we may have a problem. I'd need to > hear both sides of the story here though to judge, as I hope would > anyone in a stronger position to exert influence. > > -- > 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
