
Steve Yegge v. Rich Hickey re: "Clojure just needs to start saying Yes" - cemerick
http://groups.google.com/group/seajure/msg/2d2ec7ac9f2b4713
======
cynicalkane
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.

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.

And of course, Clojure is a highly extensible language that has _implicitly_
said Yes to a vast ideascape.

~~~
m0th87
I'm astonished to discover Clojure _does_ do single-pass compilation. It used
to be done primarily because some intermediate representations of programs
could not fit entirely in memory, but virtually every compiler now is multi-
pass because so many optimization opportunities are lost otherwise.

I have minimum knowledge of Clojure, so is there some motivation for single-
pass other than perhaps simplicity?

Edit: A brief outline of the tradeoffs:
[http://en.wikipedia.org/wiki/Compiler#One-
pass_versus_multi-...](http://en.wikipedia.org/wiki/Compiler#One-
pass_versus_multi-pass_compilers)

~~~
richhickey
The issue is not single-pass vs multi-pass. It is instead, what constitutes a
compilation unit, i.e., a pass over what?

Clojure, like many Lisps before it, does not have a strong notion of a
compilation unit. Lisps were designed to receive a set of interactions/forms
via a REPL, not to compile files/modules/programs etc. This means you can
build up a Lisp program interactively in very small pieces, switching between
namespaces as you go, etc. It is a very valuable part of the Lisp programming
experience. It implies that you can stream fragments of Lisp programs as small
as a single form over sockets, and have them be compiled and evaluated as they
arrive. It implies that you can define a macro and immediately have the
compiler incorporate it in the compilation of the next form, or evaluate some
small section of an otherwise broken file. Etc, etc. That "joke from the
1980's" still has legs, and can enable things large-unit/multi-unit compilers
cannot. FWIW, Clojure's compiler is two-pass, but the units are tiny (top-
level forms).

What Yegge is really asking for is multi-unit (and larger unit) compilation
for circular reference, whereby one unit can refer to another, and vice versa,
and the compilation of both units will leave hanging some references that can
only be resolved after consideration of the other, and tying things together
in a subsequent 'pass'. What would constitute such a unit in Clojure? Should
Clojure start requiring files and defining semantics for them? (it does not
now)

Forward reference need not require multi-pass nor compilation units. Common
Lisp allows references to undeclared and undefined things, and generates
runtime errors should they not be defined by then. Clojure could have taken
the same approach. The tradeoffs with that are as follows:

1) less help at compilation time 2) interning clashes

While #1 is arguably the fundamental dynamic language tradeoff, there is no
doubt that this checking is convenient and useful. Clojure supports 'declare'
so you are not forced to define your functions in any particular order.

#2 is the devil in the details. Clojure, like Common Lisp, is designed to be
compiled, and does not in general look things up by name at runtime. (You can
of course design fast languages that look things up, as do good Smalltalk
implementations, but remember these languages focus on dealing with
dictionary-carrying objects, Lisps do not). So, both Clojure and CL reify
names into things whose addresses can be bound in the compiled code (symbols
for CL, vars for Clojure). These reified things are 'interned', such that any
reference to the same name refers to the same object, and thus compilation can
proceed referring to things whose values are not yet defined.

But, what should happen here, when the compiler has never before seen bar?

    
    
        (defn foo [] (bar))
    

or in CL:

    
    
        (defun foo () (bar))
    

CL happily compiles it, and if bar is never defined, a runtime error will
occur. Ok, but, what reified thing (symbol) did it use for bar during
compilation? The symbol it interned when the form was read. So, what happens
when you get the runtime error and realize that bar is defined in another
package you forgot to import. You try to import other-package and, BAM!,
another error - conflict, other-package:bar conflicts with read-in-
package:bar. Then you go learn about uninterning.

In Clojure, the form doesn't compile, you get a message, and no var is
interned for bar. You require other-namespace and continue.

I vastly prefer this experience, and so made these tradeoffs. Many other
benefits came about from using a non-interning reader, and interning only on
definition/declaration. I'm not inclined to give them up, nor the benefits
mentioned earlier, in order to support circular reference.

Rich

~~~
steve_yegge
Most of the user annoyance vanishes if declare were to support qualified
names: (declare other-namespace/symbol). Is there a technical limitation here?

-steve

~~~
richhickey
One problem is what to do if the other-namespace doesn't already exist. It
would have to be created, and that initialization is unlikely to be the same
as the declared one. Possibly follow-on effects when it is subsequently
required. The other option, with similar issues, is to allow fully qualified
references to non-existent vars in code.

~~~
billmcneale
If it doesn't already exist, _then_ you issue a compilation error. Better then
than the way it works today, IMO.

------
SwellJoe
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 _does_ know all about
language marketing. I'm disappointed Yegge would go there...he's a smart guy.
But, we all have bad days.

Unfortunately for Yegge's argument, he's never built a sizable language
ecosystem from scratch, while Hickey _has_. So, he's making an argument based
on authority that he doesn't have and the person he's arguing with _does_.

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.

~~~
edw
According to his post to the list, Mr. Yegge is responsible for the attitude
transplant that the Python community has experienced. It's amazing what he can
accomplish from his desk, dashing off memos to language communities. Jack
Welch wishes he had that kind of power as CEO of GE.

The most puzzling thing he says is that Clojure's language adoption efforts
have been a failure because Clojure is _over three years old_ and hasn't
broken the top ten in some pointless programming language survey.

How long did it take Python to get there? I'm guessing at least a decade. And
does it even matter?

~~~
jhawk28
The issue with Clojure is that it really gained too much popularity before it
was ready. Ready has a lot of implications. IDE support, debuggers, libraries,
documentation, books, etc. While it is a good language and has a number of
things going for it. It seems that the books and community added too much hype
too soon. This caused new users to come, then go.

~~~
edw
I don't know if I agree with you that Clojure's too popular right now, but I
completely agree with you that the phenomenon exists in general. Rails back in
the early days experienced a huge influx of PHP refugees, who significantly
lowered the signal-to-noise ratio in the community.

I use a language's Freenode channel is a general barometer of the state of its
community's health, and I notice no more questions from bandwagon jumpers _who
have no clue whatsoever of what they're getting into_ on #clojure than I ever
did on #scheme. I use those two channels for comparison because the sort of
questions in question are similar: based on received assumptions that are
counterproductive to being effective.

------
gcv
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.

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.

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 (<http://dev.clojure.org/display/design/Error+Handling>).
(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
[http://www.nhplace.com/kent/Papers/Condition-
Handling-2001.h...](http://www.nhplace.com/kent/Papers/Condition-
Handling-2001.html)).

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.

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.

------
gruseom
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.)

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.

(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.)

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.

~~~
scott_s
I think Python is both prescriptive and widely popular.

~~~
dpritchett
It's also one of the more readable languages in existence and it's implicitly
championed by an IT juggernaut.

~~~
swannodette
Not for production code it isn't.

~~~
rtaycher
As compared to ? Python is very popular.

------
KirinDave
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.

Examples I've run into:

1\. The current clojure lambda shortcut-syntax is atrocious, and we can do
better. Why don't we do better?

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.

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 _actively laugh at you._

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.

* _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._

~~~
gruseom
_if you show up in freenode #clojure to ask for help with them they will
actively laugh at you_

Oh dear. That is a bad sign. It has always seemed to me that building a
healthier community from the ground up was the biggest thing a successful new
Lisp would have to offer. The behavior you describe is all too reminiscent. No
one should _ever_ be "actively laughed at" for asking an honest question, and
Clojure experts (if they know what's good for them) ought to take an
aggressive stance against that kind of behavior. These communities are
delicate things. They can become diseased.

It makes me mad to see anyone get "actively laughed at", let alone by bullies
who assuage the beast of their own insecurity by doing the intellectual
equivalent of beating up children.

Edit: oh, and: they're being laughed at for asking about macros? This _is_ a
Lisp, right?

~~~
swannodette
The best way to deal with trolls is to simply not feed them. My experience on
Clojure IRC the past 3 years is that its orders of magnitude less
condescending than the Python, Ruby, or Node.js IRC channels.

~~~
KirinDave
I won't name names, but you'd know the names I could name. It is true that, so
long as you stay away from a few key third rails, the #clojure channel is
generally a great place. One need only to go to #scala on a bad day to see
what a few bad actors can do to make a place feel oppressive.

There's no value in such arguments tho. It's an undeniable truth that the
Clojure community (and its libraries) are far less macro-friendly and macro-
centric than other lisps. Even PLT Scheme seems more comfortable with defmacro
usage.

~~~
puredanger
There's a joke here about Scala and actors, I'm just sure of it.

------
frisco
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 _tragic_ 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.

------
loumf
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)

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.

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.

------
dkarl
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.

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.

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.

(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.)

~~~
pnathan
_I_ like Common Lisp's LOOP, personally.

~~~
ohyes
It is an abomination until you learn how to use it, then it is completely
awesome.

~~~
G_Morgan
Everything is an abomination until you learn how to use it.

The difficulty with loop is it takes something trivial and makes it more
complex than it needs to be. Simple things are not simple. Complex things are
rare and loop doesn't simplify them enough.

~~~
ohyes
That might be true. It is indeed complex if you look at the BNF in the hyper-
spec.
([http://www.lispworks.com/documentation/HyperSpec/Body/m_loop...](http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm))

If you ignore the hyperspec, however, and get a feel for it by looking at
examples and writing code using it, it becomes quite simple. It is very useful
when you are translating C or Java code.

(<http://www.unixuser.org/~euske/doc/cl/loop.html>)

I find it quite readable in comparison to many of common lisp alternatives for
iteration. And I kind of disagree that simple things aren't simple.

For example: (loop for i from 0 below 10 do ...)

Is pretty much the simplest construct that you normally need. Granted, I would
likely just use dotimes in that case... but lets say you are iterating between
5 and 15, dotimes becomes unwieldy, where the for loop is pretty much the same
code with the numbers changed.

(loop for i from 5 below 15 do ....)

Now try incrementing by 2

(loop for i from 5 below 15 by 2 do ....)

compare to the similar do* code

(do* ((i 5 (+ i 2)))

    
    
        ((>= i 15))
    
      ....)
    

kind of a toss up to me.

Not that I don't understand your point... in fact, as little as a year ago, I
felt that way too... but I have since changed my mind.

My current preference is to use do* if writing a macro that needs iteration,
and to use loop when I am doing something similar to a list comprehension or
array traversal.

------
sharkbot
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:
<http://lua-users.org/lists/lua-l/2008-06/msg00407.html>). Yet Lua is #12, up
from 20.

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.

~~~
masklinn
Lua is probably a bit of a special case, as it grew extremely popular due to
its original niche (trivial integration in complex C and C++ projects): Lua
was born in 1993, and started getting used in big-name games in the late 90s
already (Baldur's Gate was scripted in Lua in 1998, so was Grim Fandango the
same year). From there, it took over most of the gaming industry and could
only leak out as a popular language.

~~~
zem
the other point of view is that that makes it nothing more than the new tcl,
and tcl managed to lose its popularity.

~~~
masklinn
tcl lost its popularity because it was displaced. By Lua. Because Lua had a
lower dissonance with C and C++ (actual data types & al, for instance).

Could lua itself be displaced? Sure, but there's no contender I see right now.
And I don't think that's an other point of view.

~~~
zem
from what i remember, tcl's popularity waned long before lua caught on in a
big way. people were looking to ruby and python as extension languages, even
though they had a far higher impedance mismatch than tcl, simply because they
were vastly more popular as languages by then

------
Goladus
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.

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).

~~~
cemerick
I actually thought it was as fair and representative a quote as I could pull
from the discussion; my apologies to Mr. Yegge if it's uncharitable from his
perspective.

~~~
Goladus
I understand, you've got a very limited space to work with. Just saying that
anyone following the link should take your heading with the grain of salt it
deserves.

(And the point is much less relevant now that Rich and Steve have both
continued the discussion here)

------
eschulte
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).

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).

------
d0m
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)

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.

Still, Rich's answer is pretty great IMO.

------
dusklight
One of the best things I like about clojure actually is how it is currently
keeping away new users.

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.

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.

~~~
hga
See also the Haskell "avoid success at all costs" unofficial slogan, e.g.
[http://www.computerworld.com.au/article/261007/a-z_programmi...](http://www.computerworld.com.au/article/261007/a-z_programming_languages_haskell/?pp=10)

------
rplevy
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"
[http://replay.web.archive.org/20080722232746/http://brucio.b...](http://replay.web.archive.org/20080722232746/http://brucio.blogspot.com/)
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."

------
gregschlom
I don't understand Rich Hickey's point. How does his thought experiment
address Steve Yegge's points?

Would someone care to explain?

~~~
Roboprog
Reduction to absurdity: if (almost) everybody got to add something, you would
have an undifferentiated mass of scar tissue. There needs to be some
discrimination of what changes "fit" the language.

Of course, "fit" and beauty are in the eye of the beholder :-(

~~~
ntoshev
It doesn't quite work, because Steve says "you need to be more open to fixing
annoyances" and Rich responds "Look what a mess would it be if we fixed
everyone's annoyance!". There is a big continuum between the place Clojure is
now and the hypothetical absurd described by Rich.

------
smithbits
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.

[1] <http://research.microsoft.com/pubs/70226/tr-2005-139.pdf>

------
maddalab
For starters, I dislike the title of the post. The thread language design and
community/eco-system creation around the language.

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.

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.

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

On the second occasion he refuses to publish anything that the community can
see or use or enhance.

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

------
markokocic
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."

~~~
dpritchett
McCarthy already wrote that perfectly minimialist language in 1960. It only
had seven functions and two special forms. Most programmers use more than nine
keywords today.

<http://www-formal.stanford.edu/jmc/recursive/recursive.html>

------
theclay
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.

Virtually no one seems to be addressing what I think is Yegge's core point:
_neglect_.

Is it true that there is a considerable body of extant patches/libraries/fixes
out there that are being _neglected_ so that a sizable portion of Clojure's
user base is feeling _neglected_.

If so, then Yegge has a valid point. If not, then argue why he is wrong about
_neglect_.

~~~
spooneybarger
I wonder... have you heard Rich Hickey ever talk about many of those patches
and why they haven't been accepted yet? Clojure has a great deal of conformity
across its abstractions and interfaces. It is really easy to compose things
together. A lot of thought and careful planning goes into that. Many patches
etc run afoul of that because they don't meet that standard.

As to libraries, you don't need to be blessed for a library to go. How exactly
does clojure core neglect a library? By not taking it into the core?

I didn't read this as being about neglect. I think his argument was that you
need to give people what they want or they will leave. I don't find any
validity in that. There are plenty of BDFL projects that do quite well.

I think the real message is... 'I want these things. Why won't get you give
them to me.' If this was anything other than a bit of a childish rant, there
would have been much better channels to carry it out in.

If you want people to change, you don't attack them in public. If you want to
make yourself feel good and vent, you attack people in public.

~~~
theclay
Thank you.

This is the kind of response I was hoping to see. I'm not qualified to comment
at all on Clojure, but I was interested to see what people thought who were
part of this community.

I wish more people would address these points. If Clojure really is fine the
way it is then argue that point positively rather than chip away at Strawman
arguments, which, at best, were only tangential.

Finally, I'm not so sure about the public-private point you are making.
There's a reason we protect free (public) speech: being publicly criticized is
much harder to ignore than private requests.

This rant has become front page material on Hacker News. That's pressure. If
there really is dissatisfaction amongst the Clojure community, this won't be
the last time we'll be reading about this particular exchange.

~~~
spooneybarger
The public/private was...

If you want to influence people, attacking them in public isn't the best way
to go about it. Do it privately, discuss your concerns etc etc. If you just go
for the public 'you are doing it wrong' approach, you breed resentment &
distrust. OTOH, a good rant in public sure can make you feel good even if it
probably isn't going to sway your target to your side. Then again, that wasn't
really the reason it was done, was it?

Or put another way... if you are going to rant, rant. Don't pretend like your
public ranting at someone is an attempt to get them to agree with you. It is
about making yourself feel better. If you need/want to convince someone to
join your side of an argument, quiet diplomacy is going to be far more
effective.

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

~~~
dpritchett
All turing complete languages make anything possible, right? The only question
there is whether or not you detour through Greenspun's Tenth Rule to get where
you're going.

I think Steve's point about Clojure having a limited time to gain acceptance
before it's considered "over" is valid, even if he doesn't necessarily show us
a way out.

~~~
fogus

        All turing complete languages make 
        anything possible, right?
    

But there must exist a point of diminishing returns. There is a difference
between Turing Complete and Gosling Complete.

~~~
groovy2shoes
"Gosling Complete" is such an awesome phrase.

------
sausagefeet
Isn't this how we got C++?

~~~
scorpion032
Rather, PHP.

To be fair, it is actually fairly popular, thats why.

~~~
cemerick
We just got done hearing about how PHP's early years included "official"
abstention from frameworky things (<http://codefury.net/2011/04/why-php-was-a-
ghetto/>). PHP "won" because of distribution, just like Javascript is
"winning" now.

------
pnathan
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.

At least that's how I read it.

------
thinkingeric
Mr. Yegge says, "it only takes a few people to poison a community"

Yes, and it is the kvetchers that are putting a black cloud over a language
and community that has been evolving quite nicely otherwise.

~~~
herdrick
I think the term you are looking for is 'wreckers'.

~~~
thinkingeric
No. They are kvetching.

~~~
herdrick
I was making a joke using communist terminology. To be more direct, I don't
think Steve is casting a dark cloud over the community, in fact the opposite
metaphor is better: he's bringing some important issues to light.

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

------
perfunctory
Let's see how Steve's statements stand against evidence.

> to get users, languages have to say Yes

What languages in wide use today got popular because they said yes? Is it

C, Java, Python, Lua?

I don't think those qualify as "yes" languages. Oh, maybe it is

Perl.

~~~
chromatic
Perhaps if you count the CPAN.

