From: Will Hartung
Subject: Re: "Programming is FUN again" rambling commentary
Date:
Message-ID: <vfr750Epo8o1.EDL@netcom.com>
······@exploited.barmy.army writes:
>In article <················@netcom.com>,
>Will Hartung <······@netcom.com> wrote:
>[Snip]
>>>"Let's learn Common Lisp AND Emacs simultaneously!" Eyah! It has to be
>>>natural and instinctive to be fun.
>I haven't found Lisp environments difficult to use at all.
A lot of this is Baby Duck syndrome. I'm a long time ancient vi(1)
hacker, and Emacs is NOT vi, so there is a bit of a learning curve
there beyond moving the point around.
But, more importantly, beyond simply saving the buffer and
(LOAD ...)ing the file, there is the plethora of SHIFT-ALT-CTRL yada
yada yada commands that interface Emacs to the Lisp environment. A bit
more learning curve.
>>Lisps biggest weakness, now, for me, is it's hard to see the tree for
>>the forest. Scheme doesn't help because I usually can only find seeds
>>and pine cones.
>I'm not quite sure what you mean by that. Would you mind
>elaborating?
Simple analogy.
I like taking new folks out to lunch to a local burger stand. Why? The
food is good for one, but importantly, they have, effectively ZERO
selection. Basically an orthoganal mix of fried burger patties,
cheese, lettuce, tomatoes, onion.
No chicken, no fish, no Gyros, no "Smoked Salmon Salads". When you
have very few choices, decisions are REAL simple. With new people, I
don't have to explain the entire menu to them, so it's a quick
process.
Now, Lisp, as we are all very aware, is a large language with zillions
of options and utilities (so's Emacs for that matter).
Scheme is MUCH smaller. Scheme is so small, that a lot of functionality
needs to be provided by the coder or through a library. That's an
observation.
For the environments *I* work in, and the applications *I* tend to
work on, Scheme is too limited, and I'm lazy enough to not be
motivated to write all of my own stuff. Seeds and pine cones.
Lisp is big big big. There are, what, a half dozen (at least)
DIFFERENT ways to iterate in the language (do, loop, recursion,
dotime, dolist, map...). I'm starting my Lisp training with a 20
drawer roller cabinet FILLED with tools to use, instead of just a
hammer and a screwdriver. *I* find all of these options confusing as
I'm indecisive as to which to use when.
With more experience, it'll be natural, but right now Lisp is
unintuitive to me because I'm always second guessing half the things I
do. DEFSTRUCT, or DEFCLASS? A-List or Hash table? List or vector?
Everything works with everything. Sure there are square pegs and round
holes, but they're all made of foam, so...press to fit.
When you're used to other languages, when you've focused your problem
solving style on using a hammer and screwdriver, and some guy gives
you a roller cabinet AND a lathe and raw stock to make more, you can
get a bit overwhelmed.
>Yeah, GUI stuff is a dreadful bore. I can't think of anything
>more tedious than writing some GUI front end, except maybe
>fixing build errors for a Fortran or Cobol program.
Yeah, but at least the errors you're fixing don't go away when they
user changes his font size :-).
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
From: Leif Nixon
Subject: Re: "Programming is FUN again" rambling commentary
Date:
Message-ID: <v3d8fs1hg8.fsf@softlab.se>
······@netcom.com (Will Hartung) writes:
> Now, Lisp, as we are all very aware, is a large language with zillions
> of options and utilities (so's Emacs for that matter).
>
> Scheme is MUCH smaller. Scheme is so small, that a lot of functionality
> needs to be provided by the coder or through a library. That's an
> observation.
Posts like this would be much easier to understand if people
would stop talking about Common Lisp as just "Lisp".
Scheme is a Lisp.
Elisp is a Lisp.
Interlisp is a Lisp.
Lithp is a Lisp.
Lisp is not necessarily Common Lisp.
If you're referring to Common Lisp specifically, please use
the specific term "Common Lisp", not the general term
"Lisp". This makes reasoning about different Lisps much
easier to follow.
--
Leif Nixon SoftLab AB
-------------------------------------------------
E-mail: ·····@softlab.se Phone: +46 13 23 57 61
-------------------------------------------------
Leif Nixon wheezed these wise words:
> If you're referring to Common Lisp specifically, please use
> the specific term "Common Lisp", not the general term
> "Lisp". This makes reasoning about different Lisps much
> easier to follow.
This is a good point. I have more Lisps on my machine that Common
Lisps. Perhaps this is just a personal bias, but I've also read about
more Lisps than Common Lisps.
OTOH, I can understand why people might wish to distinguish Scheme
from any other Lisp, and Common Lisp from the non-ANSI Lisps. So I
take care to say "Lisp" where I mean _all Lisps_, "Common Lisp" when I
mean ANSI Common Lisp, and Scheme when I specifically mean Scheme. We
could be more specific, of course, as say CLtL2, ans?? (I've forgotten
the name), R4RS, R5RS, etc.
I suspect that this will always be confusing. Will we need to qualify
the meaning, every time we say "Lisp"? I hope not, but it may be hard
to get everyone to agree on a consistant meaning and make it clear
that they're doing so in every post.
When in doubt, ask for a clarification. Common Lisp does this, after
all. Perhaps we can, too. ;)
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
From: ······@exploited.barmy.army
Subject: Re: "Programming is FUN again" rambling commentary
Date:
Message-ID: <6e9540$4jb$1@Masala.CC.UH.EDU>
In article <················@netcom.com>,
Will Hartung <······@netcom.com> wrote:
>······@exploited.barmy.army writes:
>
[Snip]
>
>>I haven't found Lisp environments difficult to use at all.
>
>A lot of this is Baby Duck syndrome. I'm a long time ancient vi(1)
>hacker, and Emacs is NOT vi, so there is a bit of a learning curve
>there beyond moving the point around.
>
With all due respect, I find it hard to believe that anyone who
can use anything as obfusicated and unintuitive as vi would
find Emacs difficult! I mean you've got online help, and
only need a handful of commands to get going. Furthermore
if you're ruunning under a GUI, you've got a nice menu
system that's mouse driven.
>But, more importantly, beyond simply saving the buffer and
>(LOAD ...)ing the file, there is the plethora of SHIFT-ALT-CTRL yada
>yada yada commands that interface Emacs to the Lisp environment. A bit
>more learning curve.
If you are talking about Elisp (The lisp integrated within
emacs), there are only two commands you need to know (in
addition to load) to get started in Elisp coding (actually
only one is really needed for that matter):
C-x e -> Evaluate expression
M-x eval-buffer -> Evaluate the buffer
You can write programs using only those 3 commands (load and the two
above, and even then you can make do without one of them). When
you feel more comfortable you can look into the other commands
for moving around expressions, etc...
Source code formatting, paren matching, you get all that
automatically. So what's so difficult?
[Snip -- good analogy]
>Now, Lisp, as we are all very aware, is a large language with zillions
>of options and utilities (so's Emacs for that matter).
I don't want to sound nitpicky, but the name "Lisp"
denotes an entire family languages, of which Scheme is one.
I'm assuming you mean Common Lisp (which is quite large)?
In any case, I'm fond of Common Lisp's size. I'd rather
have way too much than a bit too little any day.
>
>Scheme is MUCH smaller. Scheme is so small, that a lot of functionality
>needs to be provided by the coder or through a library. That's an
>observation.
>
>For the environments *I* work in, and the applications *I* tend to
>work on, Scheme is too limited, and I'm lazy enough to not be
>motivated to write all of my own stuff. Seeds and pine cones.
>
I agree. I like Scheme's elegance, and better treatment of
functions, and intelligent (and consistent) naming conventions,
but when it comes to functionality, it just falls flat on its
face. As it turns out, functionality is *THE* most
important consideration (for me), so I use Common Lisp
instead.
>Lisp is big big big. There are, what, a half dozen (at least)
>DIFFERENT ways to iterate in the language (do, loop, recursion,
>dotime, dolist, map...). I'm starting my Lisp training with a 20
>drawer roller cabinet FILLED with tools to use, instead of just a
>hammer and a screwdriver. *I* find all of these options confusing as
>I'm indecisive as to which to use when.
Well keep in mind though that these iterations are quite
different, so it becomes much easier to pick one once you
read the description of each.
For example, mapcar applies an n-arity function to
n lists (using the car of each list as an argument to this function).
So it is used for list transformations. (Ie: converting
every element of a list to something else, like
incrementing every element of a list).
Things like dolist are better for side-effecting operations.
Things like map-into destructively modify their arguments.
So decide what you want to do with your iteration, and take
any paradigm considerations into account and things should be
much simpler.
For example, I prefer a functional style when programming
so I never use do, dolist, dotimes, etc... I only use
non-destructive list operations (no map-into, etc...)
and generalized recursion. This heavily reduces the number
of possibilities in my case.
>
>With more experience, it'll be natural, but right now Lisp is
>unintuitive to me because I'm always second guessing half the things I
>do. DEFSTRUCT, or DEFCLASS? A-List or Hash table? List or vector?
>Everything works with everything. Sure there are square pegs and round
>holes, but they're all made of foam, so...press to fit.
>
After a while it will be easier, but for now just keep in mind
what you want to do, how you want to do it, and any paradigms
you want to stick with and you should be ok.
Again, since I've found maps, reductions, and filters to be so
useful for what I'm doing, I'll often pick embedded lists over
defstruct and defclass.
I'm not suggesting you do the same, I'm merely giving you an
example of how easy my choices are once I've made my mind
as to a paradigm to follow and how I want to get my job done.
>When you're used to other languages, when you've focused your problem
>solving style on using a hammer and screwdriver, and some guy gives
>you a roller cabinet AND a lathe and raw stock to make more, you can
>get a bit overwhelmed.
Sure, but for the time being you can just pick out a hammer and
screwdriver and set everything else aside and still get
the job done, and learn about all the other goodies later.
The only problem with having too many tools is in picking
the best one for the job. You can still easily pick
a tool for the job, it just may not be the best one.
>
>>Yeah, GUI stuff is a dreadful bore. I can't think of anything
>>more tedious than writing some GUI front end, except maybe
>>fixing build errors for a Fortran or Cobol program.
>
>Yeah, but at least the errors you're fixing don't go away when they
>user changes his font size :-).
:)
>
>--
>Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
>1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
>1993 Explorer - Cage? Hell, it's a prison. -D. Duck
--
Regards,
Ahmed
My email address has been altered to avoid spam. To email me,
send email to punkrock at cs dot uh dot edu.