Steve Yegge at speaking on Clojure debugging direction

[Julian]

Steve Yegge spoke on this according to this twitter post:
"Hearing Steve Yegge talk about what needs to happen with Clojure
debugger tooling for competitive uptake at Seajure"
http://twitter.com/#!/technomancy/status/56205750766284800

Does anyone have a set of the powerpoints or the slides?

[Justin Lilly]

There were no slides. It was just chatting in a coffee shop.

[Steve Yegge]

I do have a growing list of things I find irritating about Clojure, now that
I'm actually writing something in it.

I tend to blog when I get upset enough about something, so left unchecked
I will most likely produce a volcanic rant about how Clojure is deliberately
trying to fend away potential new users with a shotgun and a mean glare.

I'm not sure how else to handle it, though.  Whenever I've blogged like that
in the past it has been *incredibly* effective.  People pay attention and
get to work fixing whatever I ranted about.  Whereas if I gripe about things
one at a time on a mailing list, nothing will get done -- at least it appears that
way, since people have *already* griped about every single one of the issues
I'm encountering and met with passive aggression, lethargy and outright
dismissal.

-steve

[Julian]

Steve, you should *definitely* write that blog entry.

On Apr 19, 5:35 am, Steve Yegge <ste...@google.com> wrote:
> I do have a growing list of things I find irritating about Clojure, now that
> I'm actually writing something in it.
>
> I tend to blog when I get upset enough about something, so left unchecked
> I will most likely produce a volcanic rant about how Clojure is deliberately
> trying to fend away potential new users with a shotgun and a mean glare.
>
> I'm not sure how else to handle it, though.  Whenever I've blogged like that
> in the past it has been *incredibly* effective.  People pay attention and
> get to work fixing whatever I ranted about.  Whereas if I gripe about things
> one at a time on a mailing list, nothing will get done -- at least it
> appears that
> way, since people have *already* griped about every single one of the issues
> I'm encountering and met with passive aggression, lethargy and outright
> dismissal.
>
> -steve
>
>
>
> On Mon, Apr 18, 2011 at 8:37 AM, Justin Lilly <justinli...@gmail.com> wrote:
> > There were no slides. It was just chatting in a coffee shop.

> > On Apr 18, 2011 7:39 AM, "Julian" <juliangam...@gmail.com> wrote:
> > > Steve Yegge spoke on this according to this twitter post:
> > > "Hearing Steve Yegge talk about what needs to happen with Clojure
> > > debugger tooling for competitive uptake at Seajure"
> > >http://twitter.com/#!/technomancy/status/56205750766284800
>

> > > Does anyone have a set of the powerpoints or the slides?- Hide quoted text -
>
> - Show quoted text -

[Peter Thatcher]

I agree. How do we make you more upset?

[Ted Neward]

Well, sh*t, now I'm curious.... which things are you ranting about that's
being met with a shotgun and a mean glare?

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com

[Steve Yegge]

The full list is at home, sorry.  I'll tell you this, though:  single-pass compilers
are a joke from the 1980s.  I thought the only one left in existence was C++.
And even C++ allows circular dependencies between translation units if you
forward-declare them.

The standard answer on the Clojure lists is "refactor", to which the standard
newcomer will reply "how about go fuck yourselves; I'll use another language."

But single-pass compilation and no circular dependencies are just two of a
growing list of gripes.  The language is rapidly becoming Not Fun as my
experience with it grows.  And that's just sad.

-steve

[Andrew Cristina]

Now I'd really like to see this blog post.

[Patrick Logan]

"Single-pass compilers no longer around" - if it's any compensation, isn't JavaScript even worse? ie it allows forward references as long as they are not used forwardly!

[Patrick Logan]

If that's the worst of it, I'd say Clojure is in good shape.

On Apr 18, 2011 5:13 PM, "Steve Yegge" <ste...@google.com> wrote:

[Steve Yegge]

The worst of it is the prevailing attitude -- which you've just done a fine job
of caricaturing here -- that "Clojure don't need no fixin', so shut yer traps."

Without a "let's fix all the really stupid stuff" attitude, it's never going to get
fixed, and the friction will preclude adoption.  And believe you me, the mailing
list is filled with people harboring that attitude.

-steve

[Ted Neward]

That’s actually one of biggest things that turns me off to the Python language—the community and their “Guido is the only one who is smart enough to decide how things should be done” attitude.

 

I think part of the problem there is that the Clojure community is populated by ex-Lispers who feel like they’ve finally, after decades of popular neglect, come into the limelight and recognized for the geniuses they are. Which is quite the turn-off.

[Brody Berg]

Non-genius here - totally happy to help on the Yegge-list should it be presented. 

Cheers, 

Brody 

[Steve Yegge]

Actually I get the impression that Clojure doesn't have many ex Common Lispers.
Common Lisp folks seem quite happy to continue using Common Lisp, and I can't
really say I blame them.

Clojure's community seems to have been populated by Schemers and folks from
various statically-typed camps like ML and Haskell.  They generally whine and bitch
whenever anyone tries to work around Clojure's pedantic insistence on functional style
-- for instance, the crapped all over the folks who've tried to port the CL loop macro.

Other examples:

  * There doesn't seem to be any standard mechanism for nonlocal exits, and Rich has
    pronounced: "do not use exception handling for control flow".  Where are catch/throw?

  * Some dude gave a talk last year about how macros are dangerous and you should
    never use them.  I'm not going to look it up, because it'll make my blood boil and I'll
    probably have a heart attack.

It's really easy for a community to become a permanently poisoned well.  Java went
that way.  They now have a fanatical insistence on avoiding certain language mechanisms
(such as inheritance, arrays, static methods, constructors and a bunch of others I'm
forgetting), even though they're perfectly harmless and appropriate much of the time.
The reasons are manifold -- compiler bugs that have never been fixed, issues with the
expressiveness of Java's type system, language inflexibility that precludes unit testing,
and so on.  But rather than fix the language, they've hobbled it even further by cultural
convention.

Clojure is already starting to show signs of cultural poisoning.  The big question in my
mind is whether it's too late to try to fight it.  If it's too late, I'll move on and not worry
about it.  But given that Clojure doesn't show up in the Tiobe top 50 yet, I'm going to
assume that it's not yet too large to be fixable.

-steve

[Patrick Logan]

For the record, I never wrote (nor intended to write) anything
remotely like "shut yer trap".

I did weigh in with my opinion, which is the same as what you did. I
respect your opinion, and would not be upset if clojure changed it's
single-pass declarations.

I expect that you also respect people with different opinions, as long
as we're all tolerant. If you read something other than that in what I
wrote, it was absolutely unintentional.

FWIW I personally have criticisms of clojure that I consider worse
than those you've listed to date in this thread. (Based on my
weighting system and certainly no one else's!)

Regards
-Patrick

[Phil Hagelberg]

On Tue, Apr 19, 2011 at 1:41 PM, Steve Yegge <ste...@google.com> wrote:
> * Some dude gave a talk last year about how macros are dangerous and
> you should never use them. I'm not going to look it up, because
> it'll make my blood boil and I'll probably have a heart attack.

Eh; that's not quite right. The talk I saw was about how functions are
generally more composable than macros, so they should be the first
tool you reach for. I think it was more directed at folks who come to
lisp and are drunk with the power of macros.

(Assuming it was this talk: http://clojure.blip.tv/file/4522250/)

-Phil

[Kevin Downey]

I find common lisp very distasteful, on a number of levels (community,
lisp-2, etc) so I see no reason to complain about the lack of common
lisp in clojure. I hope the common lisp folks are always happy to
continue using common lisp. If you would rather use common lisp,
please go ahead.

--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

[Patrick Logan]

This seems right up the traditional alley of "X Considered Harmful"
position statements in programming. Taking a strong stance is good.
Having a good sense of when and why to ignore such a stance is also
good.

Hopefully there are few things in CS or life that would actually cause
one's blood to boil.

It's sunny in PDX. The sun's the only thing allowed to boil _my_ blood.

[Patrick Logan]

Oh, now you've crossed the line into Lisp-1 v. Lisp-2. You've gone too far! 8*O

[Steve Yegge]

You've missed my point in a rather spectacular way.  I'm glad we're

having this discussion, though, because I need to fine-tune it before I

take it to a larger audience.

What Clojure needs is to be non-prescriptive.  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."

I'm always surprised that I need to repeat myself here, but I'll do it again.

Here's the litany:

  * languages need users to survive.  The more, the better.  Users get you

    documentation, libraries, fleshed out edge cases, and lots of feedback

    about what works and doesn't work in the language.  Users beget jobs,

    money, and commercial/industrial acceptance.

  * to get users, languages have to say Yes.  You can't ever say No.

    This is why language guides are always phrased in terms of what you

    can do in a language, and are never about what you cannot do.  It's a

    fundamental marketing issue.

You _can_ say No, but then other languages win, and you're stuck wondering

why nobody is using your beautiful language.

If you really don't think users matter, then you have no cause to complain

when nobody uses your language.

As for me, I would rather like to see more people use Clojure, and I would

in fact like to use it more myself.  That means Clojure needs to start being

less prescriptive and more accommodating.

So what we need is a pretty simple cultural shift.  Clojure just needs to start

saying Yes.  There are a bunch of patches out there just languishing because

nobody wants to say Yes.  And there are a bunch of libraries that aren't getting

any attention.  And there are a bunch of missing abstractions in the language

itself that are going unaddressed.  Not because nobody is trying to fix them --

no, not for lack of effort on the part of the would-be users.  It's because Clojure

is fast getting into the habit of saying No.

One guy ran into the lack of the >>> operator and made a patch, and his patch

is just sitting there unused -- which means that everyone (including me!) who is

porting Java code to Clojure (which, by golly, is a good way to get a lot of people

using Clojure) is stuck having to rework the code semantically rather than just

doing the simplest possible straight port.  The more they have to do this, the

more you're going to shake users off the tree.

If you embrace users, then Rich won't have to publicly beg for money.  The

money will come naturally as an emergent ecosystem.  But you need users!

The cultural shift here is not just important -- it's life-threateningly so.  Clojure's

life is on the line.  When people announce:  "hey, I made a loop macro!" the

response absolutely can NOT be:  "why can't you just write it as a series of

maps and reductions?"  If anyone says that they need to be re-educated in the

*economic* importance of embracing diverse programming styles.

If you don't understand the marketing issues here, and you fail to see the

basic financial significance of being nice to contributors from all backgrounds

and not just those from the pure-functional crowd, then Clojure is dead at the

starting gate.

-steve

On Tue, Apr 19, 2011 at 2:03 PM, Kevin Downey <red...@gmail.com> wrote:

[Ted Neward]

I’m not really “in” t the Clojure community, but I have several friends who are (Stu Halloway, Neal Ford, etc) and I didn’t get the impression that it was heavily populated by the MLers or Haskellers; in fact, I got the impression that the MLers and Haskellers were more into languages like F# and Scala because of the static typing and type inference in those languages that were more similar to ML and Haskell. *shrug* Like I said, I’m coming at this third-hand, so I can’t say for certain.

 

I do find it interesting that you take the position that Java-ers “have a fanatical insistence on avoiding certain language mechanisms
(such as inheritance, arrays, static methods, constructors and a bunch of others I'm forgetting)”; that’s definitely not been my experience when interacting with said community. If anything, I find it difficult to get them to recognize that arrays suck, that inheritance isn’t the be-all/end-all solution to problems, and so on. I’m not one of the fanatics that you describe—though I do subscribe to some of the aforementioned beliefs, I don’t subscribe to it religiously—but that’s not my point. My point is that I’d love to sit down with you sometime and try to figure out where our opposing views on this come from. (And I mean that in the most pleasant sense—I’m always fascinated by examples where two people look at the same thing and see radically different things.)

 

That said, I do think that domain-driven design is the kiss of death for any multi-JVM project.

 

Meanwhile, back to Clojure.

 

It seems to me that clearly the key to fixing Clojure is to convince Rich Hickey of the sin or infraction in question, and though I’ve not met Rich personally, I get the impression that he’s (a) pretty smart, and (b) pretty opinionated. I’m not sure how successful such an effort would be.

[Peter Thatcher]

Just curious: Is there a good example of a "yes" language community?

[Andrew Cristina]

Common Lisp struck me as a "yes" language, with the caveat that it was
mostly "yes, you can do it yourself"

[Steve Yegge]

I agree that convincing Rich is going to be the key to getting individual problems fixed.

Clojure's been around for over three years now.  It's fairly mature.  But it's not in the TIOBE top 50 languages.  It's not seeing a dramatic uptick in adoption.

To me that says Clojure is doing something seriously wrong.

I don't think the problem is Rich, and I don't think the individual problems with the language or libraries are anywhere near as significant as the overall culture, which Rich can influence but not control.

Understand that it only takes a few people to poison a community, as long as nobody else is doing anything to prevent it.  Rich and Stu and the other "big names" seem nice enough to me, and as far as I can tell it's people like them -- and the 95% of the rest of the community -- who are responsible for everything *good* about Clojure's community.

But that 5% is going to be the death of the language l if we don't start fighting it Right Now.  Languages only have a short window before people say "oh, that's old", meaning nobody liked it and it failed. Clojure is still "new", but it'll only be that way for a few more years.

-steve

[Steve Yegge]

Perl.  How else did such a crappy language become such a dominant force?

Python wasn't until I called them out on it back in my "Bambi Meets Godzilla"

days, and now they're _much_ more careful about their fielding of questions on

the mailing lists and newsgroups.  And (mostly in response to Ruby) for the past

few years they've also been fiercely evolving what used to be a stagnant language.

Common Lisp was -- admittedly at the expense of having to design by committee

and placate a bunch of very large incompatible Lisp bases.  CL "died" during the

AI Winter, so they're no longer adding features to the language, but it was a very

strong "yes" language during its design and evolution.

Java and C++ got where they are today via marketing and tons of money.

If Clojure had tons of money to throw around, then it wouldn't need to take Larry

Wall's guerilla approach of being nice to people and adding everyone's pet feature.

I could go on.  This is an interesting discussion in its own right.

-steve

On Tue, Apr 19, 2011 at 2:50 PM, Peter Thatcher <ptha...@gmail.com> wrote:

[Steve Yegge]

Absolutely -- nothing wrong with that.  Yes is yes.

If Clojure people all said "of course you can use macros!  Of course

you can use CL-style loop facilities!  It's your code, do what you like!

Feel free to use nonlocal exits all you like!" -- well, then it would be a

lot closer to a Yes language.

We'd still need to get some issues resolved that are not fixable by

end users -- circular dependencies, for instance.  Or we'd have to come

up with some really good tools and design patterns that smooth over

the problem so well that people don't notice it anymore -- that's another

perfectly valid way of being accommodating.

-steve

[Patrick Logan]

Common Lisp is also a "yes" language in that, that's how it was
defined in the first place: a combination of MacLisp, NIL, ZetaLisp,
Franz Lisp, Interlisp, Portable Standard Lisp, etc.

Lisp in general is a "yes" language. The more "purely" functional the
lisp, the more challenging it is to have imperative statements "yes"'d
into it. But still. It could be worse. (And that's not better.)

On Tue, Apr 19, 2011 at 2:52 PM, Andrew Cristina <acri...@gmail.com> wrote:

[Stan Dyck]

On 04/19/2011 02:53 PM, Steve Yegge wrote:
> I agree that convincing Rich is going to be the key to getting individual problems fixed.
>
> Clojure's been around for over three years now. It's fairly mature. But it's not in the TIOBE top 50 languages. It's
> not seeing a dramatic uptick in adoption.
>
> To me that says Clojure is doing something seriously wrong.
>
> I don't think the problem is Rich, and I don't think the individual problems with the language or libraries are anywhere
> near as significant as the overall culture, which Rich can influence but not control.
>
> Understand that it only takes a few people to poison a community, as long as nobody else is doing anything to prevent
> it. Rich and Stu and the other "big names" seem nice enough to me, and as far as I can tell it's people like them --
> and the 95% of the rest of the community -- who are responsible for everything *good* about Clojure's community.
>
> But that 5% is going to be the death of the language l if we don't start fighting it Right Now. Languages only have a
> short window before people say "oh, that's old", meaning nobody liked it and it failed. Clojure is still "new", but
> it'll only be that way for a few more years.
>

We must not tolerate the intolerant! My new rallying cry.

StanD.

[Kevin Downey]

so where is your set of proposals that have been shot down? where is
your github fork of clojure which the changes you would like to see?
where are the patches, where is the code? Have you done anything to
move the language in the direction you want?

[Steve Yegge]

On Tue, Apr 19, 2011 at 5:40 PM, Kevin Downey <red...@gmail.com> wrote:

so where is your set of proposals that have been shot down? where is
your github fork of clojure which the changes you would like to see?
where are the patches, where is the code? Have you done anything to
move the language in the direction you want?

I am collecting a list.  Most of my concerns have already been raised on
the mailing lists -- this alone should be a strong signal that something
is amiss.  And in several cases people have already submitted patches
that have been met with apathy or even antipathy.

My primary focus is getting a debugger written.  I believe this is one of the
most pressing needs, and it is the area to which I think I can best contribute,
having spent a few months last year modifying JSwat to add a command-line
interface.  I've also worked with powerful debuggers in the past and have a
clear vision around what I want it to do.  In contrast, most devs consider
a debugger to be a slightly dirty adjunct to the compiler tool suite, and they
only use one in times of dire need.  I hope to change this perception by
creating a tool that people can't remember ever living without.

Hence my compilation of an issues list has been -- and will continue to be --
second-priority and somewhat ad-hoc.  And I am not going to set aside the
debugger work to try to make language or library patches, particularly when
so many others have been so poorly received.  Instead I believe it will be most
useful to highlight the root problem by calling attention to the failures of people
who tried to fix issues long before I came along.

Before I publish anything I'll make sure I have references to the relevant
Clojure group threads.  And I have no plans to publish until the debugger is
up on github -- to give me plenty of time to "adjust" to irritations that may fade
with experience -- so it'll likely be several months before I blog about it.

With any luck, my concerns will have already been addressed by then,
and I can focus on how great Clojure is.

-steve

 

[Tim Clemons]

On Tue, Apr 19, 2011 at 6:51 PM, Steve Yegge <ste...@google.com> wrote:

My primary focus is getting a debugger written.  I believe this is one of the

most pressing needs, and it is the area to which I think I can best contribute,
having spent a few months last year modifying JSwat to add a command-line
interface.  I've also worked with powerful debuggers in the past and have a
clear vision around what I want it to do.  In contrast, most devs consider
a debugger to be a slightly dirty adjunct to the compiler tool suite, and they
only use one in times of dire need.  I hope to change this perception by
creating a tool that people can't remember ever living without.

 

Interesting.  Do you have any of the code on github?

[Patrick Logan]

A pretty reasonable way of writing a debugger is to take advantage of lisp being a good "yes" language. See Dybvig, et al.'s paper on "Expansion Passing Style". Even if you don't want to use EPS for the final product it's more than sufficient to build a highly usable prototype.

[Fogus]

> My primary focus is getting a debugger written.

George Jahad has been working on a debugger called CDT (that
integrates with Emacs) and there may be some chance for collaboration
or inspiration.

http://georgejahad.com/clojure/cdt.html

[David Nolen]

On Apr 18, 8:13 pm, Steve Yegge <ste...@google.com> wrote:
> The full list is at home, sorry.  I'll tell you this, though:  single-pass
> compilers
> are a joke from the 1980s.  I thought the only one left in existence was
> C++.
> And even C++ allows circular dependencies between translation units if you
> forward-declare them.
>
> The standard answer on the Clojure lists is "refactor", to which the
> standard
> newcomer will reply "how about go fuck yourselves; I'll use another
> language."
>
> But single-pass compilation and no circular dependencies are just two of a
> growing list of gripes.  The language is rapidly becoming Not Fun as my
> experience with it grows.  And that's just sad.
>
> -steve

Have you considered what might be lost if the current single-pass
compiler is ditched? Certainly the current limitation/design
simplifies some advanced uses of macros, user-defined type systems
come to mind. Clojure has stiff competition in the functional PL space
- Haskell, Typed Racket, Scala. Clojure should have a clear and simple
path to face those challenges as well. Personally, I think the
paradigm shifting potential of a la carte type systems solidly trumps
the convenience of multi-pass compilation - but that's my humble
opinion.

Having experienced pain with languages that allow circular
dependencies (pretty much everything) I kind of meh about that.

Since the person most qualified to implement such deep changes to the
compiler is Rich Hickey and he hasn't done much on either of these
significant fronts, I have a growing suspicion these are well
considered design decisions to keep the door open for the community to
build very sophisticated extensions/experiments with the language
without undue complications.

David

[Rich Hickey]

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. Obviously
this will be the most popular and successful language, acquiring
hundreds of thousands (or millions?) of developers and a commensurate
number of featur