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: refun on 25 Feb 2010 14:13 In article <dac96124-4225-4a4d-bdf9-13f4e0537711(a)g11g2000yqe.googlegroups.com>, oraclmaster(a)gmail.com says... > > 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. Do you have a copy of the Hyperspec installed locally, so you can easily look up standard CL functions in it from SLIME? Each chapter's dictionary is a good point to look for functions related to some domain. Obviously this is only for the COMMON-LISP package, if you're interested in the MOP, read AMOP, otherwise for other packages you'll want to consult the library documentation, as it usually comes with one. Another very helpful thing is having source access to your implementation and library and using M-. in SLIME to see how something is implemented, which usually gives you a better understanding of things (especially when it comes to libraries other people made).
From: Nicolas Neuss on 25 Feb 2010 14:54 piscesboy <oraclmaster(a)gmail.com> writes: > 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. Besides learning to browse the Hyperspec, don't forget that you can also ask in comp.lang.lisp, if you suspect that someone has already written something you need. Nicolas
From: Ole Arndt on 25 Feb 2010 17:16 Giovanni Gigante <giov(a)cidoc.iuav.it> writes: > ccc31807 wrote: >> Perl doesn't have an interactive environment like the Lisp REPL. > > That's what I thought as well, until I discovered this: > http://search.cpan.org/~mstrout/Devel-REPL-1.003007/lib/Devel/REPL.pm > :-) You can get even closer to a Slime-like perl development environment with Sepia: http://search.cpan.org/~seano/Sepia-0.991/lib/Sepia.pm A "must have", IMHO. Ole -- Ole Arndt http://www.sugarshark.com
From: Ron Garret on 25 Feb 2010 18:08 In article <gnus.m3k4u1c66z.fsf(a)sugarshark.com>, Ole Arndt <ole(a)sugarshark.com> wrote: > Giovanni Gigante <giov(a)cidoc.iuav.it> writes: > > > ccc31807 wrote: > >> Perl doesn't have an interactive environment like the Lisp REPL. > > > > That's what I thought as well, until I discovered this: > > http://search.cpan.org/~mstrout/Devel-REPL-1.003007/lib/Devel/REPL.pm > > :-) > > You can get even closer to a Slime-like perl development environment > with Sepia: > > http://search.cpan.org/~seano/Sepia-0.991/lib/Sepia.pm > > A "must have", IMHO. > > Ole That rumbling sound you hear is Erik Naggum rolling over in his grave. http://groups.google.com/group/comp.lang.lisp/msg/fc76ebab1cb2f863 rg
From: Tamas K Papp on 26 Feb 2010 02:45
On Thu, 25 Feb 2010 06:25:32 -0800, ccc31807 wrote: > On Feb 25, 1:23 am, Tamas K Papp <tkp...(a)gmail.com> wrote: >> On Wed, 24 Feb 2010 15:08:02 -0800, ccc31807 wrote: >> > Learning Lisp is like pulling teeth, except more painful! >> >> Either Lisp is not a good match for you, or you are not ready for it >> yet. In either case, you are not likely to benefit from learning Lisp >> for now. > > I strongly disagree. I don't believe that people are 'matched' to > programming languages any more than they are 'matched' to human > languages. A good programmer can program in any language whether he > knows it or not, and a poor programmer can't program in any language > whether he know it or not. Whatever. I don't think that classification is useful: it takes time to learn a rich language like CL really well, so even "good" programmers can't program in it without learning it first (contrary to your claim). And I have seen some programmers who could get the job done in the Blub of their choice, but would have a really hard time with eg Haskell. > As to 'being ready' this is like lifting weights. The only way you can > be ready to lift heavy weights is to start by lifting light weights and > build yourself up. How could anyone 'be ready' to learn any language if > he never exercised himself by attempting to learn the language? The purpose of weightlifting is presumably to build up muscles. But what is the purpose of learning a programming language, if you don't enjoy programming in it? Most people who learned CL did it because it was enjoyable. Sure, there are some initial hurdles, and all encounter minor frustrations in the learning process. I am quite surprised that for you, it feels like "pulling teeth, except more painful". I have never experienced that when learning CL --- quite the opposite. It is of course up to you to decide, but if I felt that learning something was very frustrating, I would abandon it, for the following reasons: first, I think that learning is most efficient when it is enjoyable, and when it isn't, I will not learn much anyway even if I should, so it is a waste of time; and second, I believe that people have different aptitudes in various areas, and it is best when a good match is found between the two --- if I am frustrated by something, it is very likely that my comparative advantage lies elsewhere. > 'remembered' and gave the error message. In a perfect world, the error > message would have been something like this: "Hey, you dummy, you > already defined an area function, so you need to give this one a > different name." Unless your implementation includes an AI, it can't figure out the source of error for you (except in a few pre-programmed cases which are covered by simple heuristics). Tamas |