From: jonathon
Subject: Avoiding 'Not Invented Here' syndrome in Lisp
Date: 
Message-ID: <1118288768.230333.114370@o13g2000cwo.googlegroups.com>
Lisp is amazingly customizable, as I have learned in just a short time.
 Given this fact, and the fact that some developers have said about
Perl AND Lisp 'I hate anything I didn't write...' what are some keys to
engineering Lisp programs that are maintainable and that balance
language customization with the element of 'least surprise'?

Jonathon

From: Eric Lavigne
Subject: Re: Avoiding 'Not Invented Here' syndrome in Lisp
Date: 
Message-ID: <1118292471.411299.43140@g49g2000cwa.googlegroups.com>
>Lisp is amazingly customizable, as I have learned in just a short time.
> Given this fact, and the fact that some developers have said about
>Perl AND Lisp 'I hate anything I didn't write...' what are some keys to
>engineering Lisp programs that are maintainable and that balance
>language customization with the element of 'least surprise'?

>Jonathon

Study the hyperspec. When you right new utilities, get in the habit of
imagining that you are just adding one more piece to this big work of
art. Try to match the pattern so that your new piece fits.

I've certainly had that feeling, hating things that I didn't write.
Part of that comes from the fact that you understand things better when
you create them yourself. Part of it, though, just comes from poor
design. Poor designs get beaten into shape quite fast on this
newsgroup, so post some of your work here and you'll get the tips that
you're looking for real quick :)

Oh, and this problem isn't unique to highly customizable languages. In
any language, programmers try to make the language do what they want.
In less customizable languages, the customizing still happens... and
leads to a horrible mess. Another issue is aimless programming, where
you start trying to understand some function, only to find that it
isn't called anywhere, or when you're trying to trace the flow of logic
in a block of code, only to find that the result gets stored in a
variable that is never touched again.
From: Matthias
Subject: Re: Avoiding 'Not Invented Here' syndrome in Lisp
Date: 
Message-ID: <36wu0k7rjq4.fsf@hundertwasser.ti.uni-mannheim.de>
"Eric Lavigne" <············@gmail.com> writes:

> >Lisp is amazingly customizable, as I have learned in just a short time.
> > Given this fact, and the fact that some developers have said about
> >Perl AND Lisp 'I hate anything I didn't write...' what are some keys to
> >engineering Lisp programs that are maintainable and that balance
> >language customization with the element of 'least surprise'?
> 
> >Jonathon
> 
> Study the hyperspec. When you right new utilities, get in the habit of
> imagining that you are just adding one more piece to this big work of
> art. Try to match the pattern so that your new piece fits.

Actually, in the hyperspec I sometimes fail to see these "patterns".
(E.g. look at the functions for set operations on lisp.  Any pattern?)

Norvig's "Tutorial on Good Lisp Programming Style" is quite good.

But eventually, you have to get tolerant toward other people making
different choices in this huge space of possibilities that is CL.  If
you don't want to: There are language communities that emphasize
consistency stronger than CL (similar: Perl <-> Python).  They have a
narrower concept of "proper" code and it's more likely that code
written by others looks similar to your own.  The price to pay is that
you are discouraged to bend these language as much as you may bend CL.
From: fireblade
Subject: Re: Avoiding 'Not Invented Here' syndrome in Lisp
Date: 
Message-ID: <1118310249.361087.180480@g44g2000cwa.googlegroups.com>
If you're pretty new like me first check the spec ,
i find many things allready written  so reinventing the wheel is mostly
pointless
If  you're  experienced with lisp you probably know
the answer better than me.
From: Jamie Border
Subject: Re: Avoiding 'Not Invented Here' syndrome in Lisp
Date: 
Message-ID: <d89uih$3s2$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>
"fireblade" <········@YAHOO.COM> wrote:

> i find many things allready written  so reinventing the wheel is mostly
> pointless

I also find many things already written.  However, if people didn't try to 
reinvent the wheel from time to time, we would have granite wheels on our 
cars.

> If  you're  experienced with lisp you probably know
> the answer better than me.

Yes, they do.  But having built a single-purpose mapcar, now I can _see_ the 
benefits of mapcar and funargs.  I find this 'feeling' different to being 
told "This is the way to do it."

I'm kinda confused, actually.  I've always approached new languages by:

1) Read existing source code
2) Try to write correctly-executed code (simple, stupid)
3) (Optionally) fail
4) Read documentation
5) Goto 1

Aha! I just realised that I'm not a structured programmer after all :-)

Jamie 
From: Eric Lavigne
Subject: Re: Avoiding 'Not Invented Here' syndrome in Lisp
Date: 
Message-ID: <1118341272.765513.51510@f14g2000cwb.googlegroups.com>
>I'm kinda confused, actually.  I've always approached new languages by:

>1) Read existing source code
>2) Try to write correctly-executed code (simple, stupid)
>3) (Optionally) fail
>4) Read documentation
>5) Goto 1

>Aha! I just realised that I'm not a structured programmer after all :-)

>Jamie

You also have no break condition. Maybe infinite loops are okay for
learning though ^^
From: Brandon J. Van Every
Subject: Re: Avoiding 'Not Invented Here' syndrome in Lisp
Date: 
Message-ID: <d8coio$a4k$1@eskinews.eskimo.com>
jonathon wrote:
> Lisp is amazingly customizable, as I have learned in just a short time.
>  Given this fact, and the fact that some developers have said about
> Perl AND Lisp 'I hate anything I didn't write...' what are some keys to
> engineering Lisp programs that are maintainable and that balance
> language customization with the element of 'least surprise'?

Maybe you are speaking in code words for people more knowledgeable about 
a specific engineering discourse than myself.  Reacting more at face 
value to the subject line, could you be more specific about what class 
of applications, libraries, or devices you're interested in?  I just 
don't see how you could answer this question in a vacuum.  People write 
their own stuff because either (1) they're always going to write their 
own stuff, it turns them on, (2) the off-the-shelf options available are 
inadequate to their tasks.  So "what's out there" is very important to 
deciding the question.

I just spent 2 years looking at all manner of open source stuff.  Sadly, 
I conclude that I should have ignored it all and gone with NIH.  But 
that's the wisdom of hindsight.

-- 
Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA


"The pioneer is the one with the arrows in his back."
                           - anonymous entrepreneur
From: Pascal Bourguignon
Subject: Re: Avoiding 'Not Invented Here' syndrome in Lisp
Date: 
Message-ID: <87psuuxaij.fsf@thalassa.informatimago.com>
"Brandon J. Van Every" <·····················@mycompanyname.com> writes:
> jonathon wrote:
>> Lisp is amazingly customizable, as I have learned in just a short time.
>>  Given this fact, and the fact that some developers have said about
>> Perl AND Lisp 'I hate anything I didn't write...' what are some keys to
>> engineering Lisp programs that are maintainable and that balance
>> language customization with the element of 'least surprise'?
>
> Maybe you are speaking in code words for people more knowledgeable
> about a specific engineering discourse than myself.  Reacting more at
> face value to the subject line, could you be more specific about what
> class of applications, libraries, or devices you're interested in?  I
> just don't see how you could answer this question in a vacuum.  People
> write their own stuff because either (1) they're always going to write
> their own stuff, it turns them on, (2) the off-the-shelf options
> available are inadequate to their tasks.  So "what's out there" is
> very important to deciding the question.

In particular, for point (2), it's very important to realize the
limitations of the provided mechanisms.  Most of the time, stuff
provided is only specified as the minimum stuff that was needed by the
provider, and he just publishes the API (a lot of GUI toolboxes are
like that).  If you need to do the same thing as the provider, good
you'll be able to use his tools, but if you need to do something else
or something more, you'll soon reach the limits.

For example, the definition of time in Common Lisp is totally
inadequat to do anything but what Common Lisp does with it (basically
FILE-WRITE-DATE and getting some coordinate in the present time).  You
cannot use Common Lisp time functions to manage history, biography,
physics, astronomy (space ship navigation) or about anything else.


> I just spent 2 years looking at all manner of open source stuff.
> Sadly, I conclude that I should have ignored it all and gone with
> NIH.  But that's the wisdom of hindsight.

On the other hand, knowing how to use what exists to reach your goal
faster is a valuable skill.  Either you have the power to rewrite
everything from scratch to your own specs, or you have the skills to
use what's existing.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"