another frustrating learner question, CLOS
in [Lisp]
|
Prev: Anybody mind to translate this Felleisen quote from German to English
Next: Macros and anonymous functions
From: Tim Bradshaw on 2 Mar 2010 11:01 On 2010-03-02 14:34:56 +0000, Giovanni Gigante said: > Btw, I've never understood the traditional "Larry is a linguist" > argument. I think that ambiguities are a source of richness and fun in > human language, but not in computer ones (for most definitions of > "fun"). I wasn't actually thinking about that. What I meant was that mastering a natural language requires people to deal with all sorts of weird idiosyncratic rules and guidelines because natural languages are like that. And it turns out that human beings are *really good* at this, which isn't surprising of course, because natural languages are, well, natural. But somehow, for some people, any programming language which allows some of the variation you see in natural languages is not acceptable. Except it's more complicated than that, since basically all programming languages allow this kind of variation (Common Lisp being a fine example of this). I think the truth is that people will use this kind of syntactic variation as a way to be rude about a language that they have already decided they do not like, for whatever reason. It's not as if the particular examples given are even very good. Why would anyone who knew any Perl at all think that "a/b/c" computed a quotient: "a" is not a variable reference in Perl, after all. "$a/$b/$c" would be a quotient (and lo, it is). In another newsgroup, someone is complaining fiercely that "SPOTTED-DOG-P" does not subtract "P" and "DOG" from "SPOTTED". It's just syntax people, get over it. --tim
From: Ron Garret on 2 Mar 2010 11:29 In article <4b8d2214$0$1131$4fafbaef(a)reader1.news.tin.it>, Giovanni Gigante <giov(a)cidoc.iuav.it> wrote: > Tim Bradshaw wrote: > > > > Like English > > Btw, I've never understood the traditional "Larry is a linguist" > argument. I think that ambiguities are a source of richness and fun in > human language, but not in computer ones (for most definitions of "fun"). The problem is not ambiguity, the problem is that there is nothing with which to conduct a search for more information. Yes, you can change the syntax of Lisp to make in incomprehensible too, but the vast majority of the features in Lisp are bound to strings of constituent characters, which you can do a search on. So even if there is ambiguity, at least there is something to look up to get more information. Perl is more like Chinese or sign language than English. If you see a Chinese character or a sign language gesture that you don't know, there's no way to look it up. You just have to know. Likewise in Perl if you see an unfamiliar combination of letters and punctuation marks you can't look up what it means the way can look up, say, "with-frobnabulator" or "cl-ppcre". BTW, even if the Lisp readtable has been munged to morph the language beyond all comprehension, you can always get an expansion in terms of the core language using READ-FROM-STRING and MACROEXPAND. So in Lisp it is *always* possible to get at least *some* information about what's going on in terms of something that you can look up. Not so in Perl. (Nor, I note in passing, in C++.) rg
From: Ron Garret on 2 Mar 2010 11:52 In article <hmjcp1$u0r$1(a)news.eternal-september.org>, Tim Bradshaw <tfb(a)tfeb.org> wrote: > On 2010-03-02 14:34:56 +0000, Giovanni Gigante said: > > > Btw, I've never understood the traditional "Larry is a linguist" > > argument. I think that ambiguities are a source of richness and fun in > > human language, but not in computer ones (for most definitions of > > "fun"). > > I wasn't actually thinking about that. What I meant was that mastering > a natural language requires people to deal with all sorts of weird > idiosyncratic rules and guidelines because natural languages are like > that. And it turns out that human beings are *really good* at this, > which isn't surprising of course, because natural languages are, well, > natural. Yes. But it is for good reason that natural languages are not used for programming. For a programming language to be more like a natural language in that regard is not a feature. > But somehow, for some people, any programming language which allows > some of the variation you see in natural languages is not acceptable. Again, for good reason. > Except it's more complicated than that, since basically all programming > languages allow this kind of variation (Common Lisp being a fine > example of this). I have already conceded that Common Lisp sucks. But even Common Lisp is less sucky than other languages in this regard because it is always possible to use READ-FROM-STRING, GET-MACRO-CHARACTER, and MACROEXPAND to get an explanation of what is going on in terms of something that you can type into a search engine or do a meta-point on. (Except format strings of course. Format strings are irredeemably sucky.) > I think the truth is that people will use this kind > of syntactic variation as a way to be rude about a language that they > have already decided they do not like, for whatever reason. But I like Common Lisp. I even like format, and use it all the time. Liking or not liking has nothing to do with it. > It's not as if the particular examples given are even very good. Why > would anyone who knew any Perl at all You have completely missed the point. Obviously once you *know* Perl all these issues evaporate. The issue is what happens when you encounter a new construct that you don't already know. > think that "a/b/c" computed a > quotient: "a" is not a variable reference in Perl, after all. Because a naive reader might try to bring other knowledge to bear, like knowledge of other programming languages, or of mathematical notation learned in grade school. > In another newsgroup, someone is complaining fiercely that > "SPOTTED-DOG-P" does not subtract "P" and "DOG" from "SPOTTED". > > It's just syntax people, get over it. There is well designed syntax, and there is badly designed syntax. Perl is the epitome of badly designed syntax because it has a poor impedance match with anything other than the brains of experienced perl programmers, and there's very little payoff in terms of what you can do once you know Perl compared with, say, Python. Lisp has the exact same problem by the way. It has a poor impedance match with anything other than the brains of experienced Lisp programmers. The difference between Lisp and Perl is that warping your brain into a Lisp brain has a much larger payoff in terms of what you can then do than morphing your brain into a Perl brain. I also think it's easier to morph your brain in to a Lisp brain than a Perl brain, but I'm biased. rg
From: Tamas K Papp on 2 Mar 2010 12:11 On Tue, 02 Mar 2010 16:01:37 +0000, Tim Bradshaw wrote: > In another newsgroup, someone is complaining fiercely that > "SPOTTED-DOG-P" does not subtract "P" and "DOG" from "SPOTTED". A somewhat tangential question: lately I am gravitating towards SPOTTED-DOG? instead of SPOTTED-DOG-P. Is that "bad style" in CL? Looks so much nicer, and appears more intuitive to me. Tamas
From: Giovanni Gigante on 2 Mar 2010 12:30
> The problem is not ambiguity, the problem is that there is nothing with > which to conduct a search for more information. Yes, you can change the > syntax of Lisp to make in incomprehensible too, but the vast majority of > the features in Lisp are bound to strings of constituent characters, > which you can do a search on. So even if there is ambiguity, at least > there is something to look up to get more information. > > Perl is more like Chinese or sign language than English. If you see a > Chinese character or a sign language gesture that you don't know, > there's no way to look it up. You just have to know. Likewise in Perl > if you see an unfamiliar combination of letters and punctuation marks > you can't look up what it means the way can look up, say, > "with-frobnabulator" or "cl-ppcre". I had never thought about it this way, but it rings true. To successfully look up a word in a dictionary, one has to: 1) isolate it, 2) look it up in the dictionary, and 3) understand which of the possible meanings is the relevant one. The lookup is not the difficult part: for example the index of the Camel Book is sorted by ASCII and looks exactly that way: a catalogue of "funny characters" (as they called them). It could also be possibly extended to include references to constituent parts. But the problem with perl is in the other two steps. Signs, by themselves, have a lot of multiple meanings, very context-dependent. At times, not even Perl is able to tell the difference, and you have to provide additional hints (for example: in certain situations one has to prepend a literal hash reference with a "+" to be sure that it is not mistaken for a block). And since the Perl culture loves so much the use of very concise and non-alphabetic syntax, this tends to overload the signs a lot. And then, you don't know where a symbol begins and where it ends by just looking at the stream of characters. You have to understand them all. So, if Perl is like a human language, then it is like one written without spaces and with few, short words which can mean many different things. gg |