Prev: Anybody mind to translate this Felleisen quote from German to English
Next: Macros and anonymous functions
From: ccc31807 on 25 Feb 2010 11:13
On Feb 25, 10:14 am, Zach Beane <x...(a)xach.com> wrote:
> Problematic state can happen in many systems. Resetting a system is a
> usually not necessary if you have the tools and skills needed to inspect
> and manage the system's state. You have the tools but not the skills
> when it comes to Lisp, but practice should give you the skills. Good for
> you if you have both the tools and skills in your normal environments.

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. With Perl, I
use vi and a command prompt, so I write code, save it with :w, switch
to the prompt with SHFT-TAB (on Windows), and run it (generally with
the command history key). With Lisp, I use emacs, so I save and
compile code with CTL-c, CTL-k, switch to the REPL window with CTL-x,
o, and run the code. I've never had this kind of problem (a corrupted
environment) with Perl in the same way I experienced yesterday with
Lisp, so I didn't have the mental tools to comprehend what was
happening.

Obviously, there are good parts and weak parts to each environment,
and saying which is 'better' in some sense requires a value judgment,
which depends on the values of the user.

Programming languages are tools to get work done, and different
languages reflect the requirement of different kinds of work. I think
learning different languages is valuable because it teaches different
approaches to different kinds of problems. I pity the poor souls who
think that Visual Basic is the appropriate tool to solve every
problem, and that if Visual Basic can't solve a particular problem
then the problem isn't worth solving ... and yes ... I have friends
that think exactly that.

CC.
From: Giovanni Gigante on 25 Feb 2010 11:16
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
:-)
From: Zach Beane on 25 Feb 2010 11:34
ccc31807 <cartercc(a)gmail.com> writes:

> On Feb 25, 10:14 am, Zach Beane <x...(a)xach.com> wrote:
>> Problematic state can happen in many systems. Resetting a system is a
>> usually not necessary if you have the tools and skills needed to inspect
>> and manage the system's state. You have the tools but not the skills
>> when it comes to Lisp, but practice should give you the skills. Good for
>> you if you have both the tools and skills in your normal environments.
>
> 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.

> With Perl, I use vi and a command prompt, so I write code, save it
> with :w, switch to the prompt with SHFT-TAB (on Windows), and run it
> (generally with the command history key). With Lisp, I use emacs, so I
> save and compile code with CTL-c, CTL-k, switch to the REPL window
> with CTL-x, o, and run the code.

During development, I rarely compile whole files (aside from compiling
and loading whole systems). I usually use C-c C-c to compile individual
forms as I write them, and switch to the repl (C-c C-z or, my global
slime-selector binding, C-c s r) to test and run functions as they're
written.

> I've never had this kind of problem (a corrupted environment) with
> Perl in the same way I experienced yesterday with Lisp, so I didn't
> have the mental tools to comprehend what was happening.

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.

Zach
From: ccc31807 on 25 Feb 2010 11:45
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.
From: piscesboy on 25 Feb 2010 13:47
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.



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Prev: Anybody mind to translate this Felleisen quote from German to English
Next: Macros and anonymous functions