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 have to worry about which database to use when you merely want to write a program that remembers data when you re-start it. The interface needed to do this is \almost there.... It seemed an eminently useful thing, but it got posted to this list and sank without a trace. Nobody from Core ever contacted her. (She admitted it was a "hack", but isn't that how all patches start out?) Clojure patches are not released every day. How much trouble would it be to make it a custom for one of the core developers to at least \look at patches and acknowledge their existence? I'm not sure of why she didn't submit the patch through official channels as shown on the website----she probably thought that someone from the team would be following this group enough to contact her, and she wanted to see if this would happen before getting too deep into the process. It doesn't seem like too much to ask for some proactive outreach from the core contributors. It would help develop a culture that welcomes contributions and suggestions for improvements, rather than appears to reflexively reject them. At any rate, this particular contributor has been lost to Clojure---- after seeing the lack of interest, and seeing certain deficiencies in the language for her purposes (I am not sure which ones), she moved on to Erlang. This is but a single example, but there are surely others if one took the time to look; and moreover it's an example of precisely what happens when a language fails to grow----I mean to say, that when it fails to grow, it must be that there will be many little stories like this one. A user sees deficiencies. The user happens to be one of those rare ones who is capable of fixing things. After trying to fix a little thing within the community, he decides it isn't going to work and moves on to a language that either has the feature in question, or is one that has better prospects for him developing it and actually getting it accepted. I am not sure I am saying Clojure should therefore become a "yes" language in the sense that one would expect if one were setting up a straw-man argument----a kitchen sink language without any core or soul. But I'm not sure that is what Yegge means (you might have to read behind the lines of his brash style), and there are possibilities of somewhat more open languages that still have a core and a soul. Especially when the language is well-documented, adding convenience features for newer users who are not fully into the gospel doesn't really hurt things for everyone else. Clojure is a Lisp. Lisp is not really a language, it is a maker of languages. It therefore doesn't make sense to run it in the spirit of a prescriptive grammarian. Everyone has the ability to add features anyway (and to an even greater extent once safe reader macros are figured out----which I hope they will be), so rejecting simple and basic features such as loops is ultimately counterproductive, since it will only lead to a lot of different incompatible third-party versions being made. (I really don't think the sky would fall in if they were added----with a general transient feature, such as will probably be added, they would be perfectly harmless; they could come with as many warning labels as necessary that they are Not the Clojure Way. New Lispers have to get used to prefix syntax anyway, and it may be that one paradigm shift at a time is enough for most people, even many smart ones; getting them hooked into the language starting by writing awful programs is, I think, still better than not having them here at all.) Making analogies to natural language is always a little dangerous, because nobody would program in natural language even if the option were available. Nevertheless: imagine how frustrating it would be if in learning to speak English, it became at some point along the way \impossible to speak bad English----especially if you came from another dialect or language. Suppose you are newly arrived in an England or America; you want to get around and start living life in this new country from day one; but people tell you: Wait. I have five books here that you should read. There are many screencasts, and myriad blog posts, that need to be read. You can only speak this language if you are a really, really smart person. Go away and read all these, and \\don't talk to me until you are through\\. Nobody manages to learn English this way. They only manage to learn it because even in its most bastardized form, it is still useful. You can look at a phrasebook and get useful information for day one, even when your accent and grammar are horrible. What happens is that you start talking. If you are a socially apt person, \and you happen to have friends who are a little indulgent, you start to pick it up. At some point you may indeed want to sequester yourself and read some of the great authors and even read a few textbooks to get a feel for proper English style, but if you are constantly worried about making a bad impression, even doing this will not make you able to learn----you will stay in your room and talk to no-one. The greatest killer to ad-hoc learning would be if you inhabited circles where one-upsmanship was common; where you constantly felt you were being judged by what came out of your mouth, rather than by what you really meant; where there was a kind of xenophobia that considered new entrants a threat rather than an opportunity. Some of the dismissive things that are being said about Steve Yegge and Joe Programmer here have quite a similar tenor. Mr. Yegge is right: this kind of etiquette is not helpful. He is also right that it only takes a few people to make the environment unpleasant. We need to develop an etiquette that is helpful and welcoming, and (though people do come in many levels of abilities) does not disparage people for having at a given time \less ability than you do. As you have no doubt found, people really do learn programming languages in an ad-hoc way. They learn to build programs by making useful programs from day one, in any way they know how; they will never acquire the art if they are required to stay in an ivory tower. If Clojure ends up becoming yet another Lisp that nobody uses, then I really don't see the point of it. There are already plenty of Lisps that nobody uses; why go to the trouble of making another? If the cost of having extra users ends up being spending a few more seconds filtering out "noise" in the group or on the IRC channel, then this cost is well worth it. If the cost is a little more humility, then humility is a good thing anyway. And all those extra users are going to bring improvements (and if you don't like a particular 'improvement' they bring, then you are welcome to ignore it; but many of these improvements will be things that \you use, too). They have bosses who won't use the language if it can't be set up in a few minutes, but who have the ability to direct vast resources towards helping any language they \can get to like; they have friends who are well-skilled but wedded to an existing paradigm, and aren't quite adventurous enough to try something new unless it gives them some immediate traction. All of these people, taken in aggregate, are going to bring beneficial changes. It still requires a strong hand at the helm----but that hand is now going to be able to steer many more people in the right direction. At some point this language is going to have to fix up its ecosystem; the only question in my mind is whether it is ready to do so \now----I don't see why not. Meanwhile, the idea that Clojure should aim to stay small, or that it is simply too difficult for most people to pick up, is a counsel of despair and arrogance. You don't know this. As Steve Yegge wrote in an earlier essay, there \was no acceptable Lisp----the road petered out to a dirt track and led to the same godawful swamp we've been mucking around in all these years. Lisp never really had a chance. Clojure may in fact give Lisp a chance, but it is going to have to be a little more responsive. I think you are going to end up being surprised at how smart people really are when they are given the right tools. There were many more smart people in existence than were willing to program machine code; there are still more smart people in existence that will not program Java. I was drawn to Clojure because I felt it was another evolutionary step in programming. I hope I am not wrong. I think Mr. Yegge is trying to help us. He hasn't written his blog post yet, after all----though if he reads this thread, I am afraid it is simply going to confirm his worries. . I once had an English teacher----a prescriptive grammarian par excellence----who posted a bumper sticker in his room: "Hopefully is an adverb". He may have been right that the usage of "hopefully" he deplored was a little tacky-sounding, but that it was totally useless----this I could not accept. I later learned (shoutout to J.C. Smith, in case you are listening!) that this "hopefully" is in fact a \sentential adverb. Sadly, some people have problems using sentential adverbs. I have no such qualms: Hopefully Clojure will turn out to help large numbers of people write useful, comprehensible programs. Hopefully it will change the mainstream and actually make programming a more joyful and endurable activity for all. At this it may or may not fail, but we won't really know without trying to step beyond a niche. I think making a welcoming culture that can nurture and build such a language is a noble goal, and well worth pursuing. On Jul 6, 9:42 am, Carlos Ungil <carlos.un...@gmail.com> wrote: > On Tuesday, July 5, 2011 8:08:51 PM UTC+2, Sean Corfield wrote: > > > It might be an interesting community exercise to examine the 23 GoF > > patterns and discuss whether they are applicable in an FP world and, > > if a pattern _is_ still applicable, what it would look like? > > > > Hi Sean, > > take a look athttp://norvig.com/design-patterns/index.htm > > I think it corresponds to what you're suggesting. > > Cheers, > > Carlos -- 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
