I think I've hit upon one of the reasons for the perceived smugness (and weeniness?) of Lispers. They are often lateral thinkers.
I've spent the last year or so learning Lisp (using Scheme for a side project) and so I've pestered a lot of people on freenode's #lisp and #scheme (and a #emacs) and what usually happens is something like the following:
Vincent: So how do I do [[X]]? Lisper: Why do you want to do [[X]]? Vincent: Umm - for auto-didactic purposes? Lisper: You don't want to do [[X]] - you can but it doesn't make sense. You really should do [[Y]] instead. Here is how to do [[Y]]. Vincent: But damnit I want to do [[X]]. =Lengthy argument/discussion during which I realize that doing [[X]] is dumb.=
Hanging out on #lisp a lot, I see this kind of exchange all the time - so it is not just me. People on #lisp invariably want to know the entire context of a question, and when they find out, they generally suggest a solution which is lateral to the question posed.
There is probably an analogy with functions and macros here but I will let someone more erudite pursue it.
Now, lateral thinking is generally recognized as a quality of smart people, so it is hardly exclusive to Lispers. But Lispers are infamous for being an insular community, not friendly to people wanting to approach the language from one blub or another and so it's worth pursuing this topic a bit further.
I'd like to advance the following: the perceived unhelpfulness of Lispers is structural. It derives from the selection criteria operating on Lispers providing advice and "blubbers" looking for it. Here is why: Lispers are, generally, out of the box thinkers, or they wouldn't be using Lisp1. People asking for help on #lisp are 1) new to Lisp and 2) almost surely trying to get a particular thing done, right now. If they were voracious auto-didacts without a particular goal in mind, besides learning, they would likely be content to just figure out any questions themselves. Finally, Lisp is different, which means people coming from other programming languages will probably be laden with a lot of habits which don't serve well in Lisp. As a consequence, they will often be asking questions that amount to "how do I make Lisp act like PHP/Python/Whatever". These questions are exactly the kind of questions that a seasoned, lateral thinking Lisper, is likely to want to divert into other, more lispy questions. And they probably should - it doesn't make a lot of sense to answer the wrong question with the right answer.2
Nevertheless, the overall effect is a kind of impedence mismatch between learners of Lisp and the Lisp learned. It wouldn't surprise me to find out that this observation, more or less, has been made before. But maybe re-iterating it can somehow help make that impedance mismatch a bit less of a barrier to entry for people interested in the language.
1: It is hard to argue that purely on the basis of ease of use (libraries, set up time, familiarity) that Lisp is a win over "batteries included" languages like Python.
2: There is something else interesting here, but it is somewhat lateral to the overall point of this post. Lisp, a language which will let you do anything, no matter how poorly advised, seems to be, in some larger sense, conceptually restrictive. If it wasn't, the question "how can I do [[X]]" would always make sense. What this may reflect is that the community exerts pressure to regularize the use of Lisp which other languages regulate with syntax and/or limitations on semantics.
12 comments:
I have yet to see a programming forum where that doesn't operate that way.
To elaborate on what anonymous#1 said: You compare it to Python, but having used (and taught) both, I haven't seen any significant difference here.
For example, we had to teach a bunch of (professional!) programmers coming from C++, Java, Tcl, and VB, and all of them struggled with many of the core principles of Python -- principles which it shares with Lisp, interestingly.
C++ programmers wanted to know how to define a 32-bit int. Java programmers wanted to know how to do compile-time type-checking. VB programmers thought they got setFoo= for free (or something like that -- I don't know VB). Tcl programmers wanted to know how to walk the call stack just to access a variable defined in a different context.
Sure, Lisp is "weird". Every language is weird if you've not used it before. Is there any language in the world to which you can transfer previously-learned language idioms completely?
I idle in #perl a lot, and about 90% of the questions asked go down the same way you describe, so I don't think this is a phenomenon unique to Lisp.
It seems people asking questions on IRC are usually learning as they go, picking up the pieces of the language that they need for the task at hand. As a result, they are usually using the first couple of tools they came across to try to do everything. On the other side, many of the people answering the questions have been using the language for years and read all the books from Beginner through Guru. There's a bit of an attitude from some of the veterans of "I know the best way to do this and anything else is just silly/stupid." They will also often refuse to give any help or advice until the person states their question with exact technical language and provides proper context with real code. (In the case of Perl, the answer is usually to use a module from CPAN, because someone has already done what you are trying to do, and done it better.)
There good points and bad points to this system, but in the end almost everyone willing to listen gets a good answer, so I guess it works.
I agree, this is how #rubyonrails is as well now adays. That or the words "premature optimization" get uttered whenever you try to plan anything.
I am pretty certain this would apply in particular to any language with relatively flexible constructs - Ruby, Perl, Smalltalk, Logix, all come to mind.
Re. note 1: What batteries is Common Lisp not including?
I'll put it this way re batteries in Common Lisp: asdf-install works about 30% of the time, when I try to use it.
It is better now that I am a slightly seasoned lisper, but I often have to download the packages I want manually and then mess with some files (sometimes, anyway) and then build them.
Compare this to Python where 70% of what you want is shipped with the default distribution and 95% of what you want is available in the Ubuntu Repositories and 99% of what you want is a python setup.py install away.
And there is the issue of quality. Pygame is a super convenient and excellently thought out and stable set of bindings for SDL in Python. CL-SDL is a thin wrapper, pretty poorly documented, and hard to set up. Pygame is just an apt-get away.
Sorry - but it is just silly to compare the two languages at this point for a variety of reasons having nothing to do with the "goodness" of either language.
On the topic of SDL, maybe lispbuilder-sdl http://lispbuilder.sourceforge.net/lispbuilder-sdl.html is a better choice than cl-sdl.
Yeah, yeah, Mr Expert! You still haven't answered my question: how do you do a GOTO in Lisp?
But seriously... I've occasionally helped to provide answers on #lisp, and my focus is very much on answering the right question, not necessarily on answering the first question. That's because I know from bitter experience that by the time I get to the point of asking for help, I've already gone down several paths to try to find the answer myself, and there's a strong chance that one or more of those paths was a wrong turn.
For example, if I'm an expert in framistat reticulation, and someone asks about how to reticulate a framistat using a #9 flange gasket, I could spend an hour regaling him with howtos, FAQs and anecdotes, but you can just bet it'll turn out that he really wanted to oscillate a floobleswonk and he just got his terminology concerned. Whereas if I start by asking "why do you want to do that" then it'll only take a few sentences before I realise what he's thinking that is "wrong" and set him "right" (where all such terms are relative, of course).
So it's not a Lisp thing, it's a bitter experience thing. But there may be no real difference between those two things, now I think of it...
Oh, that was "got his terminology confused", not concerned, in that last comment. Sorry, it's half past midnight, and I really should be asleep.
It's pretty simple: Those who come today asking for help will be those who write Lisp open source libraries tomorrow---which I may want to use at some future point. So I better make sure that they'll be educated to write idiomatic Lisp code in the first place.
"Lisp, a language which will let you do anything, no matter how poorly advised, seems to be, in some larger sense, conceptually restrictive. If it wasn't, the question "how can I do [[X]]" would always make sense. What this may reflect is that the community exerts pressure to regularize the use of Lisp which other languages regulate with syntax and/or limitations on semantics."
I disagree. There is always some specific problem domain where it is necessary to do something that would generally be considered horrible. (e.g. thunking a function in C because you have to erase the memory you're currently running out of). Languages that impose restrictions based on the designer's notions of hygiene end up being good for teaching & not much else (e.g. Pascal, Ada). Whenever I program in Java, I feel like a chef who's had all his cutlery confiscated & replaced with plastic forks.
Post a Comment