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: Pascal J. Bourguignon on 1 Mar 2010 15:01 Ron Garret <rNOSPAMon(a)flownet.com> writes: > In article <4b8c016f$0$1129$4fafbaef(a)reader3.news.tin.it>, > Giovanni Gigante <giov(a)cidoc.iuav.it> wrote: > >> > Which one would you rather try to debug? >> >> >> None!!! >> >> Anyway, I don't understand what you're trying to prove. > > I'm not trying to prove anything. I'm just trying to explain why I > don't like Perl. > > And it's not really regexps per se, it's the general syntactic and > semantic ugliness of it. It's not just regexps that are write-only, > it's the whole freakin' language. The syntax of the language is > perversely complex. It consists of almost nothing but random rules that > have no rhyme, reason or regularity to them. Different letters and > punctuation marks have different semantic relevance depending on the > context. For example the following three lines: > > print a/b/c; > > print q/r/s; > > print x/y/z; > > do three completely different things, none of which involve computing a > quotient. And this is just a single example of a long, long, long list > of syntactic and semantic insanity. > > The worst part is that the design of Perl makes it nearly impossible to > figure out what a piece of code does unless you're already intimately > familiar with the language. Not only you need to be intimately familiar with the language, but you also need to know what have been executed before. But this is the same in Lisp, where the reader and the current package can be highly customized. (print (car x)) may have a semantic drastically entirely unrelated to what you know. You also need to know intimately the language, and the program. > Consider the above three lines of code, and > suppose you didn't know what they did. How would you find out? What > would you look up? And in Lisp too you may have difficulties in finding a reference, if reader macros are used. That said, I agree that the gratuituous aspect of syntactic overloading found in perl is disgusting. -- __Pascal Bourguignon__
From: Ron Garret on 1 Mar 2010 15:14 In article <87d3zn95fu.fsf(a)galatea.lan.informatimago.com>, pjb(a)informatimago.com (Pascal J. Bourguignon) wrote: > Ron Garret <rNOSPAMon(a)flownet.com> writes: > > > In article <4b8c016f$0$1129$4fafbaef(a)reader3.news.tin.it>, > > Giovanni Gigante <giov(a)cidoc.iuav.it> wrote: > > > >> > Which one would you rather try to debug? > >> > >> > >> None!!! > >> > >> Anyway, I don't understand what you're trying to prove. > > > > I'm not trying to prove anything. I'm just trying to explain why I > > don't like Perl. > > > > And it's not really regexps per se, it's the general syntactic and > > semantic ugliness of it. It's not just regexps that are write-only, > > it's the whole freakin' language. The syntax of the language is > > perversely complex. It consists of almost nothing but random rules that > > have no rhyme, reason or regularity to them. Different letters and > > punctuation marks have different semantic relevance depending on the > > context. For example the following three lines: > > > > print a/b/c; > > > > print q/r/s; > > > > print x/y/z; > > > > do three completely different things, none of which involve computing a > > quotient. And this is just a single example of a long, long, long list > > of syntactic and semantic insanity. > > > > The worst part is that the design of Perl makes it nearly impossible to > > figure out what a piece of code does unless you're already intimately > > familiar with the language. > > Not only you need to be intimately familiar with the language, but you > also need to know what have been executed before. > > But this is the same in Lisp, where the reader and the current package > can be highly customized. > > (print (car x)) > > may have a semantic drastically entirely unrelated to what you know. > You also need to know intimately the language, and the program. > > > > Consider the above three lines of code, and > > suppose you didn't know what they did. How would you find out? What > > would you look up? > > And in Lisp too you may have difficulties in finding a reference, if > reader macros are used. You're right. Lisp sucks too. rg
From: Slobodan Blazeski on 1 Mar 2010 15:41 On Mar 1, 8:44 pm, Pascal Costanza <p...(a)p-cos.net> wrote: > On 01/03/2010 18:44, Slobodan Blazeski wrote: > > > > > On Feb 25, 7:47 pm, piscesboy<oraclmas...(a)gmail.com> wrote: > >> On Feb 25, 11:45 am, ccc31807<carte...(a)gmail.com> wrote: > > >>> On Feb 25, 11:34 am, Zach Beane<x...(a)xach.com> wrote: > > >>>>> I make my living as a Perl programmer, munging data. Perl doesn't have > >>>>> an interactive environment like the Lisp REPL. However, the cycle of > >>>>> writing, testing, and running code is almost identical. > > >>>> Not in my experience. > > >>> Maybe that's a function of working habits rather than languages or > >>> programming environments. I have developed a habit of write-switch- > >>> run, and this is true with Perl, C, Java, and Lisp (although Java is > >>> different in that I customarily write test cases for classes before I > >>> write the class so I am not strictly running the code directly.) > > >>>> I sometimes see Perl environments corrupted by unexpected PATH or > >>>> PERLLIB environment variables, leading to running an unexpected version > >>>> of Perl or an unexpected version of a module. > > >>> I have been fortunate to control every machine that I have developed > >>> on, so I've never had this particular problem, but with Java, yes, you > >>> have to fiddle with the environment, e.g., CLASSPATH. > > >>> CC. > > >> Tangentially on the OP, > > >> Since I am learning Lisp and CLOS in particular, what would be the > >> best, most direct route to doing so? The least painful method? Also > >> the cheapest method? One that doesn't involve enrolling in school or > >> taking classes? > > >> There's lots of resources out there in the form of online tutorials, > >> code examples, etc for learning CLOS syntax, etc, but is there some > >> simple resource available that conveniently catalogs functions and > >> classes, their parameters, their uses, which packages they belong to > >> etc...? > > >> I've been programming in Lisp for several months now, in depth, and I > >> still have a hard time tracking down function names, class names, > >> etc...through apropos, describe, and the various other documentation > >> functions built into the REPL (I currently have clisp and ccl > >> installed along with SLIME), and it is a real pain to track down > >> functions that often have incomplete or sparse documentation if it > >> exists. > > >> Often, it is through simple trial and error that I find functions for > >> which I spent the last few hair pulling days that already exist in the > >> existing Lisp packages, negating a lot of my work moot. It would be > >> nice if the documenation and usage of all functions and classes in the > >> standard user package and CLOS were documented mainly so I don't waste > >> time writing something that already exists in a package. > > >> Forgive me if this is already the case, and if it is then point me in > >> that direction. > > > Nick Levine Fundamentals of CLOS is a good tutorial > >http://www.ravenbrook.com/doc/2003/07/15/clos-fundamentals/but you > > won't need much CLOS anyway. Unless your name is Pascal Constanza of > > course. > > It's Costanza, not Constanza. I apologize, guess the one starting with cons sounded lispier. Slobodan > > Pascal > > -- > My website:http://p-cos.net > Common Lisp Document Repository:http://cdr.eurolisp.org > Closer to MOP & ContextL:http://common-lisp.net/project/closer/
From: ccc31807 on 1 Mar 2010 15:50 On Mar 1, 1:46 pm, Zach Beane <x...(a)xach.com> wrote: > This is a terrible pattern for email addresses. > > What would you do if you found a false negative or false positive? Would > you patch it up to be good enough again (until the next problem), or > would you try to get it right? Depends on what your need is. If you are validating an HTML form submission, all you may care about is three groups of letters divided by an '@' and a '.'. In most situations, you don't particularly care about the correctness of an email address, simply that it either matches a value from another source (such as the result of a database query) or that it meets the formal requirement. Even if you do care about the correctness, you can send a message using the purported email address and check your email server's error log. Obviously, the amount of effort you expend is directly related to the criticality of the need. In my job, the only time I care about email addresses is whether the value /could/ be an email address, and flag obvious errors -- neither false positives nor false negatives mean much to the application. But you are right about fixing unanticipated problems. If it's a problem and you didn't anticipate it, you fix it after the fact. CC.
From: Slobodan Blazeski on 1 Mar 2010 16:07
On Feb 28, 5:52 pm, Giovanni Gigante <g...(a)cidoc.iuav.it> wrote: > Nicolas Neuss wrote: > > Giovanni Gigante <g...(a)cidoc.iuav.it> writes: > > >> Btw, I am curious what the volume "lisp style and design" contains. Never > >> been able to see a copy. > > > You can even obtain it online: > >http://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf > > That's a different thing. The one I am referring to is an old paper book:http://portal.acm.org/citation.cfm?id=78980 Rainer wrote about it at http://lispm.dyndns.org/news?ID=NEWS-2006-05-28-1 judging by the contents I would like to read it myself Slobodan |