To Phil: I am certainly not complaining about your efforts on Leiningen, Swank, etc. I appreciate them and use them----they have already made things vastly easier for people, and the problems with setting up Emacs, certainly, are probably more to do with Emacs itself. I am just pointing out that there is still a long way to go with the overall user experience, documentation, etc.; and as long as this remains, Steve Yegge will have a point, and it is not fair to simply dismiss what he says. The original poster in this thread was arguing that Clojure has no need to grow to a larger community. He also was arguing essentially that barriers to new users were a \good thing. I just wanted to argue against this, and indeed it ended up being at some length. If I have offended anyone in doing so, that was not my intent.
When the transition to a more broad-based language happens, then there will end up being a lot more users than there are people with the ability to make fundamental changes in the language. They may make small improvements that don't get much attention, or they may simply be users with suggestions. There is nothing wrong with either of these things. I don't think their experience is any less important than people who "pull their weight". Telling them always to "fix it yourself" is not necessarily going to improve things----I think we are all well aware that we should make contributions if we are able. What fraction of Python users end up making any contribution at all? Are they a bad thing for Python? As to making contributions, I just pointed out an example of someone who made a contribution and was ignored. And as to improving documentation, how is one to go about doing it? This would be an excellent area to have some community effort on, especially from relative beginners, and that is an itch I would not mind scratching. It isn't my intention to disparage the community. It is a very good and active community; but this doesn't mean it isn't capable of improving, even based on suggestions from outsiders like Steve Yegge. Mark has a good point that the original poster is a fairly new member, and he is also right that there have been a lot of balanced responses. I felt however that nobody had really spoken directly and fully against his basic premise----if someone had, I would not have said anything. It is also correct to say that fixing many issues with user experience is a lot of hard work. I don't dispute that (and I was certainly exagerrating to say it would only take tens of hours). But there also seem to be things that might make a very big difference in initial impression, and would also not be too much trouble. I don't really know much about packaging, but is it really necessary (for 3+ years) to tell users under 'getting started' to type "java -cp jline-0_9_5.jar:clojure.jar jline.ConsoleRunner clojure.main" as their first introduction to Clojure? (This is what I was talking about with respect to difficulties in shell scripting.) The fact that it has remained under "getting started" for all this time (in a place where virtually every new user is going to visit within his first five minutes)----this sets the tone to a certain extent, and it makes impressions about where the priorities of the community might be. It also gives a mistaken impression that the language is not ready yet---- which is entirely untrue. When Yegge talks about "marketing" a language, this is exactly the kind of thing he is talking about. There may be points of disagreement as to how exactly the user experience should improve, but I hope that the goal of getting new users up to speed and writing useful code quickly is not really a controversial one. Needless to say, I have gone on long enough---- --Nick. On Jul 6, 5:53 pm, Mark Rathwell <mark.rathw...@gmail.com> wrote: > > And ending up here with a thread titled "stand firm > > against..." seems to be exactly the sort of community problem that he > > is worried about. > > To be fair, this post and its title were the work of an individual who has > only been in this community for about 3 weeks. And while that individual, > and everyone else, is completely entitled to their beliefs, and those > beliefs may be justified from the perspective they were written from, it is > unfair to ascribe them to the community as a whole (which is growing large > and very diverse). You can see in the responses, as is almost always seen > in this community, the calm, reasoned and balanced behavior of the group as > a whole. > > > But what bothers Steve Yegge and many other > > people, I suspect, is that fixing this fragmented user experience and > > the gaps in the language doesn't really seem to be a priority----when > > in fact it should be a prime mission. > > Again, to be fair, the problem is not a lack of effort on the part of the > community. The problem is multiple fold: everyone has their own idea of > what the ideal new user experience should be, and it is an extraordinarily > massive amount of work and a lot of trial and error to go from zero to easy > for everyone. Python has had 15+ years to get to that point, Clojure is at > 3+. Needs are seeming to be addressed at a reasonable rate, in my view. > Not to be rude, only practical: if there are itches you are having that are > not being scratched, it would be far more productive to do something about > it than complain that others are not pulling their weight. > > > > > > > > On Wed, Jul 6, 2011 at 7:30 PM, nchubrich <nchubr...@gmail.com> wrote: > > I've been using Clojure on and off for a while----currently off, > > though not because of the language itself. The thread now seems to > > have moved in a different direction, but I have to say (looking at the > > Seajure and Y Combinator threads) that Steve Yegge has some good > > points. And ending up here with a thread titled "stand firm > > against..." seems to be exactly the sort of community problem that he > > is worried about. > > > I wish that we did not have to deal with a fundamental disagreement > > about what a language is \for. If a programming language is something > > like Hermann Hesse's Glass Bead Game----an intellectual diversion for > > superior intellects----then spending time contemning "Joe Developer" > > and "deploring" people who want to suggest different directions for > > the language is a worthwhile activity. But ultimately programming > > languages are about getting things \done, just as cars are about > > \going places. > > > It is still possible (though increasingly difficult) to tinker with > > your own car before driving it. In the beginning, it was obligatory. > > You had to choose a third-party auto-body manufacturer. You had to > > crank the engine yourself. You even had to manually set the ignition > > timing while you were driving. There was a lot of cruft you had to > > deal with that had nothing to do with getting from point A to point > > B. The first users of cars had to be willing to work with them as a > > kind of \hobby----you had to give over a certain amount of time out of > > your day just to just keeping the things running. At some point, a > > transition happened. They became mass-market devices. The tinkerers > > never went away, but their increased numbers, and the increased > > numbers of people simply \using cars, led to an increase in simplicity > > and reliability. Every time there was an issue to deal with, there > > were that many more people with a stake in fixing it. Some people may > > miss the old hobbyist culture around cars, but I don't think anyone > > really wants to go back to Model T days. The remarkable thing > > nowadays is that a \huge number of people become good drivers > > (although admittedly there are quite a few that shouldn't be on the > > roads)----and driving is a fairly demanding and crucial activity. > > Sadly, we cannot say the same thing for computer users. > > > Clojure is still in the Model T days (though it is continuously > > improving). Getting a non-broken Emacs setup is not always easy (I > > attended a Clojure class a few weeks ago where we spent the first > > couple of hours just trying to get Clojure and Emacs working). There > > is no built-in command-line REPL or interpreter. Debugging is cryptic > > and not particularly helpful, and occasionally outright misleading > > (see what someone posted to the Seajure and Y Combinator threads on > > his roundabout way of discovering that Clojure needed advance > > declarations). The documentation is not quite as consolidated and > > organized as the Java or Python documentation (though it has also > > gotten better), and people really wanting to get things done must deal > > with two independent sets of documentation, Java and Clojure, the > > latter of which is simply organized alphabetically. Supposing that > > they do get over this hump and now wish to develop a practical > > project, they are immediately faced with more choices. There is no > > standard, immediate path for developing web apps, GUIs, or even shell > > scripts----you have to use your sixth sense of what libraries may or > > may not actually work (which on the Internet can be quite difficult, > > as something that doesn't really work rarely \tells you so itself). > > > You can jump into Python as a complete noob in the morning, and have a > > useful program by the afternoon. This is much less likely to happen > > with Clojure. There are plenty of smart people who lack both the time > > and the system administration chops to deal with getting into > > Clojure. This is very sad, because once you get into it, Clojure is > > very easy and very sensible. There are surely many great programs > > that are not being written----some of them would be programs that help > > smoothe the way for everyone else. Many people who would help spread > > the functional programming gospel are getting their brains fried in > > Python and Java----and teaching them will be that much harder when > > they eventually come around (as people have pointed out here). > > > Now all of the rough edges are perfectly understandable for a new > > language, and they continue to get better----and the more you are > > willing to Google around and read blogs and so forth, the more > > solutions you find. But what bothers Steve Yegge and many other > > people, I suspect, is that fixing this fragmented user experience and > > the gaps in the language doesn't really seem to be a priority----when > > in fact it should be a prime mission. People actually make the > > argument that these difficulties are good "weed outs" for the "joe > > developers" who would (presumably) get in here and muck everything > > up. I have actually heard people say here that people who don't have > > the wherewithal to configure emacs and classpaths will never learn > > functional programming, and therefore good riddance to them. This is > > nonsense. There are different skill sets, and system administration > > is a somewhat different one from programming. Functional programming > > is a timeless skill, whereas learning the intricacies of Emacs and > > Classpaths only gives you knowledge of a very particular insanity > > (even though the patience to deal with it is of course a good > > attribute). And some people who might become great Clojurians simply > > don't have the \time to deal with all of these things when doing them > > does not yield an immediate payoff, as I said. Moreover this time- > > cost is spent by \everyone, to one extent or another. It's the result > > of a slightly disconnected attitude. A few people could spend a few > > tens of hours making things easier for everyone else, thereby saving > > thousands of man-hours (isn't this supposed to be what programming is > > about in the first place?), and yet it doesn't happen. > > > One might speculate why this is so. Returning to the car example, it > > might be that it's much more rewarding to spend your time rebuilding > > the engine and making it that much more performant. But the number of > > people who will benefit from this zippy engine is greatly reduced when > > you still require hand-cranking, manual ignition timing, and after- > > market auto bodies. At some point, you will have to roll up your > > sleeves and admit that although making automatic starters is not > > terribly interesting, the time has come to do the job----and it is > > going to make things a lot better. > > > Programming languages at some point have to face that kind of > > transition. Clojure has already faced one such transtition: Rich > > Hickey decided to release it. On that day, it became more than his > > personal project. Other people by their investment of time developed > > a stake in it----what Steve Yegge is saying, I think, is that this > > stake has to be recognized; and the culture of the language has to > > evolve towards respecting and integrating these stakeholders as a > > reflex response, rather than the reflex response being "that's the way > > the cookie crumbles...." > > > Now people will say: There are problems, and people who see these > > problems should try to create a library or a contrib. But this only > > goes so far. You can't reorganize the documentation that way, and you > > cannot provide a smoothe, approved path to building real-world > > applications---in fact, initially, by releasing a library you are only > > creating more noise. Meanwhile, although this list \does seem > > genuinely open to answering people's questions, when it comes to > > accepting more substantive contributions, there seems to be a barrier. > > > For instance, a little while ago I was corresponding with someone who > > had released a patch to Clojure. (This was Alyssa Kwan, in case you > > want to look up the thread.) Her patch made refs persistent to > > disk----something that seemed very much in the spirit of Clojure. > > Dealing with disk persistence in a production-ready way may be its own > > discipline, but in a language that wishes to "reduce ceremony", there > > is no reason that you should... > > read more » -- 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
