Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion newbie in deep over his head
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Nils Goesche  
View profile  
 More options Mar 1 2002, 9:15 am
Newsgroups: comp.lang.lisp
From: Nils Goesche <car...@cartan.de>
Date: 1 Mar 2002 14:15:37 GMT
Local: Fri, Mar 1 2002 9:15 am
Subject: Re: newbie in deep over his head

In article <sfw3czkl9dt....@shell01.TheWorld.com>, Kent M Pitman wrote:
> Nils Goesche <car...@cartan.de> writes:

>> I remember that I disliked #'(lambda ...) from the very first time I
>> saw it.  To me, (lambda ...) looks like something that evaluates
>> to a /function/, not to a symbol whose value slot would be taken
>> if I left out the #'.

> It's probably a matter of historical effect, but I find #'foo and
> #'(lambda ...) to be more aesthetic, not less.

> First, it makes it easier to find the head of the function.

> Second, it is more consistent to me because it means functions as data
> are all case-marked by #'.  I was taught that #' was followed by a function
> name, and that (lambda ...) was the name of a function.

I am not sure if that was clear: I have nothing against #'car,
only against #'(lambda ...), because if #'blark is a function
that returns another function I do (funcall (blark ...) ...); then,
(funcall (lambda ...) ...) looks more visually consistent, doesn't it?
It doesn't, of course, if you think of (lambda ...) as the ``name''
of a function, as you say, but that sounds really foreign to me :-)
Indeed a cultural matter, it seems.

> I find it quite a lot more offensive to see every keyword in purple
> (or whatever) and every string in brown and so on just because I may
> not be caring about comments or keywords.  I definitely am annoyed
> to see editors highlight the definition name in a function even when
> I'm not debugging anything that requires use of the name.

> I have grudgingly tried to train myself to live with colors because
> I think most people like them, and because there are occasionally
> times that the color tells me something important.  But I almost
> wish I could have an editor that hid color and that had a command
> that would instantaneously enable color when I was searching for
> something in particular...

> (I have similar problems with Unix ANSI-colored directory list,
> which is always highlighting too many things, making it hard to find
> the one kind of thing I want highlit.)

Interesting.  I love syntax coloring just as much as I violently
hate ``ls --color''...

How about ``ls -F''?  Does that look fine to you?

> Bottom line?  Programming language notations are statically required
> all the time.  Focus issues are dynamically needed or not needed,
> so are not always well addressed by static notation.  It's often
> a judgment call what to emphasize and what not to in the static
> notation, and people often think they're being a lot more principled
> than they are.  Mostly I don't see a lot of science applied here
> at all.

Sure, it is pretty clear that this is all about aesthetics.  Trying
to have a rigorous discussion about this seems as futile to me as,
say, wondering about what kind of being the ``it'' in ``it is
rainy'' is :-)

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x42B32FC9


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.