From: beza1e1
Subject: Why i don't switch to Lisp
Date: 
Message-ID: <1137782553.349307.213030@g14g2000cwa.googlegroups.com>
I started reading Paul Grahams Essays and got hooked. I read a lot to
know more about those "macros" and "continuations". I learned little
syntax, style (thanks college for forcing me to learn some Haskell and
FP) by playing around with Scheme.
But for my current web project i use Python, because i don't manage to
really switch to Lisp or Scheme.

The problem is, i have to switch so much:
- new language (alist, plist, ...)
- new style (more functional, less imperative)
- new IDE (Emacs + SLIME)
- new framework (ucw, which means continuations instead of MVC)
- new environment (Hyperspec, mailing-lists, ...)

Each of these 5 switches alone is hard. Doing them all at once is
nearly impossible.

The sad thing is, i already discovered some of the gems of Lisp. By
writing Python i see a lot of things, where i'd like to use a little
macro or symbols or ... knowing these definitly made me a better
programmer (as some people promised) but knowledge can be painful
sometimes.

I know learning takes time, but if you have some suggestions, i'd be
thankful.

From: Kaz Kylheku
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1137784768.571455.127460@g44g2000cwa.googlegroups.com>
beza1e1 wrote:
> The problem is, i have to switch so much:
> - new language (alist, plist, ...)

Yes, switching to a new language involves ... a new language. No
surprise here.

> - new style (more functional, less imperative)

Common Lisp supports imperative programming quite well. Assignment to
variables; objects with modifiable slots (vectors, arrays, structs,
classes); looping constructs that step the same instances of variables,
etc.

> - new IDE (Emacs + SLIME)

I don't use either of these. It's not required. I use vi for editing
everything.

> - new framework (ucw, which means continuations instead of MVC)

Common Lisp doesn't have continuations.

> - new environment (Hyperspec, mailing-lists, ...)

Obviously! Everything has its community, documents and mailing lists.

The Hyperspec is just anothner document. In a software engineering job,
you have to deal with documents and specifications left and right.
What's another mailing list.

> Each of these 5 switches alone is hard. Doing them all at once is
> nearly impossible.

So, to recap, what have we learned? That you're a whiner and
complainer.

How interesting!

Thanks for sharing.
From: Robert Uhl
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <m3vewesg7j.fsf@4dv.net>
"Kaz Kylheku" <········@gmail.com> writes:
>
>> - new framework (ucw, which means continuations instead of MVC)
>
> Common Lisp doesn't have continuations.

But UCW _does_ use continuations, which it builds itself...

-- 
Robert Uhl <http://public.xdi.org/=ruhl>
We don't just borrow words; on occasion, English has pursued other
languages down alleyways to beat them unconscious and rifle their
pockets for new vocabulary.                     --James D. Nicoll
From: Kaz Kylheku
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1137866561.793256.153400@g47g2000cwa.googlegroups.com>
Robert Uhl wrote:
> "Kaz Kylheku" <········@gmail.com> writes:
> >
> >> - new framework (ucw, which means continuations instead of MVC)
> >
> > Common Lisp doesn't have continuations.
>
> But UCW _does_ use continuations, which it builds itself...

That's right. But why would this third-party framework be some kind of
impediment to someone learning Lisp? That is beyond me.

I've never used it and here I am, somehow.

I don't use SLIME or Emacs, yet here I am.

The OP is going out on a limb to make excuses for himself (moreover,
thinking that they are somehow relevant or interesting to other
people).
From: Kenny Tilton
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <Z_dAf.2569$yE4.2297@news-wrt-01.rdc-nyc.rr.com>
Kaz Kylheku wrote:
> beza1e1 wrote:
> 
>>The problem is, i have to switch so much:
>>- new language (alist, plist, ...)
> 
> 
> Yes, switching to a new language involves ... a new language. No
> surprise here.
> 
> 
>>- new style (more functional, less imperative)
> 
> 
> Common Lisp supports imperative programming quite well. Assignment to
> variables; objects with modifiable slots (vectors, arrays, structs,
> classes); looping constructs that step the same instances of variables,
> etc.
> 
> 
>>- new IDE (Emacs + SLIME)
> 
> 
> I don't use either of these. It's not required. I use vi for editing
> everything.
> 
> 
>>- new framework (ucw, which means continuations instead of MVC)
> 
> 
> Common Lisp doesn't have continuations.
> 
> 
>>- new environment (Hyperspec, mailing-lists, ...)
> 
> 
> Obviously! Everything has its community, documents and mailing lists.
> 
> The Hyperspec is just anothner document. In a software engineering job,
> you have to deal with documents and specifications left and right.
> What's another mailing list.
> 
> 
>>Each of these 5 switches alone is hard. Doing them all at once is
>>nearly impossible.
> 
> 
> So, to recap, what have we learned? That you're a whiner and
> complainer.
> 
> How interesting!
> 
> Thanks for sharing.
> 

Tough crowd. The OP needs a little encouragement and you sucker punch 
him. Excellent.

kt
From: Majorinc, Kazimir
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <MPG.1e3b90d9819c98399896ab@news.carnet.hr>
In article <1137784768.571455.127460
@g44g2000cwa.googlegroups.com>, ········@gmail.com says...

> So, to recap, what have we learned? That you're a whiner and
> complainer.

What an asshole! 
From: Kaz Kylheku
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1137866351.775015.291730@z14g2000cwz.googlegroups.com>
Majorinc wrote:
> In article <1137784768.571455.127460
> @g44g2000cwa.googlegroups.com>, ········@gmail.com says...
>
> > So, to recap, what have we learned? That you're a whiner and
> > complainer.

  X

> What an asshole!

You were going to say something? I think you accidentally hit the post
button before writing the article body, which would, by custom, be
placed at the spot that I marked X.

You know, between the quoted text and your signature line.
From: jayessay
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <m3k6cubtey.fsf@rigel.goldenthreadtech.com>
"beza1e1" <···············@googlemail.com> writes:

> I know learning takes time, but if you have some suggestions, i'd be
> thankful.

Just jump in and do a project.  Could be a toy to start with.  The key
thing is you can't learn by just reading some stuff and trying a few
odds and ends out independently in a REPL or even full blown IDE.  You
must _practice_ and practice on something that actually does something
at the end.

You look like someone who believes that, since there is just so much
to learn/know, you have to somehow learn/know must/all of it before
you can begin anything.  That's not true.  Basically you sound like
you are in "robolock".


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: Bill Atkins
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <87bqy6bnr8.fsf@rpi.edu>
"beza1e1" <···············@googlemail.com> writes:

> I started reading Paul Grahams Essays and got hooked. I read a lot to
> know more about those "macros" and "continuations". I learned little
> syntax, style (thanks college for forcing me to learn some Haskell and
> FP) by playing around with Scheme.
> But for my current web project i use Python, because i don't manage to
> really switch to Lisp or Scheme.
>
> The problem is, i have to switch so much:
> - new language (alist, plist, ...)
> - new style (more functional, less imperative)
> - new IDE (Emacs + SLIME)
> - new framework (ucw, which means continuations instead of MVC)
> - new environment (Hyperspec, mailing-lists, ...)
>
> Each of these 5 switches alone is hard. Doing them all at once is
> nearly impossible.
>
> The sad thing is, i already discovered some of the gems of Lisp. By
> writing Python i see a lot of things, where i'd like to use a little
> macro or symbols or ... knowing these definitly made me a better
> programmer (as some people promised) but knowledge can be painful
> sometimes.
>
> I know learning takes time, but if you have some suggestions, i'd be
> thankful.

Oh no, somebody call the waaaambulance.
From: Kenny Tilton
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <yFaAf.2555$yE4.432@news-wrt-01.rdc-nyc.rr.com>
beza1e1 wrote:
> I started reading Paul Grahams Essays and got hooked. I read a lot to
> know more about those "macros" and "continuations". I learned little
> syntax, style (thanks college for forcing me to learn some Haskell and
> FP) by playing around with Scheme.
> But for my current web project i use Python, because i don't manage to
> really switch to Lisp or Scheme.
> 
> The problem is, i have to switch so much:
> - new language (alist, plist, ...)
> - new style (more functional, less imperative)
> - new IDE (Emacs + SLIME)
> - new framework (ucw, which means continuations instead of MVC)
> - new environment (Hyperspec, mailing-lists, ...)
> 
> Each of these 5 switches alone is hard. Doing them all at once is
> nearly impossible.
> 
> The sad thing is, i already discovered some of the gems of Lisp. By
> writing Python i see a lot of things, where i'd like to use a little
> macro or symbols or ... knowing these definitly made me a better
> programmer (as some people promised) but knowledge can be painful
> sometimes.
> 
> I know learning takes time, but if you have some suggestions, i'd be
> thankful.
> 

Yes, it sucks taking a productivity hit while you learn new tools. OTOH, 
I always find that something new energizes me, which mitgates the 
damage. Anyway...

Meditate on this: the negatives you are running from are temporary 
learning efforts, the positives you are giving up are greater 
productivity. Forever. Hmmm....

kenny
From: BR
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43d13d1b@news.mcleodusa.net>
Kenny Tilton wrote:

> Yes, it sucks taking a productivity hit while you learn new tools. OTOH,
> I always find that something new energizes me, which mitgates the
> damage. Anyway...
> 
> Meditate on this: the negatives you are running from are temporary
> learning efforts, the positives you are giving up are greater
> productivity. Forever. Hmmm....

AJAX
From: Jonathon McKitrick
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1139145755.544904.82790@o13g2000cwo.googlegroups.com>
BR wrote:
> Kenny Tilton wrote:
>
> > Yes, it sucks taking a productivity hit while you learn new tools. OTOH,
> > I always find that something new energizes me, which mitgates the
> > damage. Anyway...
> >
> > Meditate on this: the negatives you are running from are temporary
> > learning efforts, the positives you are giving up are greater
> > productivity. Forever. Hmmm....
>
> AJAX

AJAX on the front, Lisp in the back is the new approach that has
jumpstarted my first project as an independent consultant.  I'm back to
enjoying developing again.

It's close to a true application, without worrying about GUI toolkits
and portability.
From: Alain Picard
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <87psm2iay5.fsf@memetrics.com>
BR <······@comcast.com> writes:

> AJAX

ACHILLES

-- 
Please read about why Top Posting
is evil at: http://en.wikipedia.org/wiki/Top-posting
and http://www.dickalba.demon.co.uk/usenet/guide/faq_topp.html

Please read about why HTML in email is evil at: http://www.birdhouse.org/etc/evilmail.html
From: verec
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43d13d52$0$87299$5a6aecb4@news.aaisp.net.uk>
On 2006-01-20 18:42:33 +0000, "beza1e1" <···············@googlemail.com> said:

> I know learning takes time, but if you have some suggestions, i'd be
> thankful.

I'm in a predicament similar to yours, except that I do stick to it.

Yes, there is a learning curve, yes CL is quite large (but not
as large as say: Java when you include all the standard libraries),
and yes, I'm far less "productive" in Lisp right now, than I am
in Java + Eclispe. But I expect this to change, of course :-)

What little of Lisp I understood in the past few month really
has taught me that I knew little before, no matter how proficient
I was deluding myself I was.

There's one regret I don't want to get when I get old:
"If only I had learnt Lisp then!". And the only way I see
is to take the plunge, as soon as possible, trying "to favor
what is important over what is urgent"[1]
--
JFB
[1] Attributed to Borland's Philip Kahn
From: Kaz Kylheku
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1137792804.728120.283530@f14g2000cwb.googlegroups.com>
verec wrote:
> On 2006-01-20 18:42:33 +0000, "beza1e1" <···············@googlemail.com> said:
>
> > I know learning takes time, but if you have some suggestions, i'd be
> > thankful.
>
> I'm in a predicament similar to yours, except that I do stick to it.

What??? What predicament is that? Are you a permanent newbie or what?

I first came into contact with Lisp for the first time in early 2001.

Then you, Jean-Francois Brouillet,  appeared in the newsgroup in late
December of that year!

What have you done to learn since then?

> What little of Lisp I understood in the past few month really

The past four fucking years is not a "few months".

How can you lie like this?

French Vermin, I'm hereby calling your bullshit.
From: jayessay
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <m37j8ublc5.fsf@rigel.goldenthreadtech.com>
"Kaz Kylheku" <········@gmail.com> writes:

> I first came into contact with Lisp for the first time in early 2001.
> 
> Then you, Jean-Francois Brouillet,  appeared in the newsgroup in late
> December of that year!
> 
> What have you done to learn since then?

Put it aside and not looked at it until a few weeks ago?  It's
possible.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: verec
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43d171f3$0$87293$5a6aecb4@news.aaisp.net.uk>
On 2006-01-20 21:33:24 +0000, "Kaz Kylheku" <········@gmail.com> said:

> verec wrote:
>> On 2006-01-20 18:42:33 +0000, "beza1e1" <···············@googlemail.com> said:
>>> I know learning takes time, but if you have some suggestions, i'd be
>>> thankful.
>> I'm in a predicament similar to yours, except that I do stick to it.
> 
> What??? What predicament is that? Are you a permanent newbie or what?
> 
> I first came into contact with Lisp for the first time in early 2001.
> 
> Then you, Jean-Francois Brouillet,  appeared in the newsgroup in late
> December of that year!
> 
> What have you done to learn since then?

I was put off by remarks like theses, and let Lisp go in
the process ... too bad :-(

>> What little of Lisp I understood in the past few month really
> 
> The past four fucking years is not a "few months".

Indeed. See above. I came back seriously around Oct/Nov
2005

> How can you lie like this?

???

> French Vermin, I'm hereby calling your bullshit.
--
JFB (AKA: French Vermin)
From: Kaz Kylheku
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1137865835.138391.288040@f14g2000cwb.googlegroups.com>
verec wrote:
> On 2006-01-20 21:33:24 +0000, "Kaz Kylheku" <········@gmail.com> said:
>
> > verec wrote:
> >> On 2006-01-20 18:42:33 +0000, "beza1e1" <···············@googlemail.com> said:
> >>> I know learning takes time, but if you have some suggestions, i'd be
> >>> thankful.
> >> I'm in a predicament similar to yours, except that I do stick to it.
> >
> > What??? What predicament is that? Are you a permanent newbie or what?
> >
> > I first came into contact with Lisp for the first time in early 2001.
> >
> > Then you, Jean-Francois Brouillet,  appeared in the newsgroup in late
> > December of that year!
> >
> > What have you done to learn since then?
>
> I was put off by remarks like theses, and let Lisp go in
> the process ... too bad :-(

That's insane. What do remarks like these have to do with Lisp or with
your life or anything?

Sure, little children can be put off from learning a craft or science
by harsh teachers, and supposedly develop problems, like fear of
anything related to numbers or mathematics.

But what are you, a baby or a grown man?

If someone made some remarks related to the atmosphere, would you stop
breathing too?

There isn't a single computing tool that I use for which I couldn't
find some online discussion group where the kinds of things happen that
put you off. That amounts to an excuse to dump every operating system,
programming language, editor et cetera. And what, take up gardening?

Isn't that just a little bit crazy? Giving other people a little bit
too much power over your life?

In this world, people have to struggle against real adverisity and
engage in conflict that makes a few harsh words look like a joke.
From: Coby Beck
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <16vAf.88596$m05.11320@clgrps12>
"Kaz Kylheku" <········@gmail.com> wrote in message 
·····························@f14g2000cwb.googlegroups.com...
> verec wrote:
>> On 2006-01-20 21:33:24 +0000, "Kaz Kylheku" <········@gmail.com> said:
>>
>> > verec wrote:
>> >> On 2006-01-20 18:42:33 +0000, "beza1e1" 
>> >> <···············@googlemail.com> said:
>> >>> I know learning takes time, but if you have some suggestions, i'd be
>> >>> thankful.
>> >> I'm in a predicament similar to yours, except that I do stick to it.
>> >
>> > What??? What predicament is that? Are you a permanent newbie or what?
>> >
>> > I first came into contact with Lisp for the first time in early 2001.
>> >
>> > Then you, Jean-Francois Brouillet,  appeared in the newsgroup in late
>> > December of that year!
>> >
>> > What have you done to learn since then?
>>
>> I was put off by remarks like theses, and let Lisp go in
>> the process ... too bad :-(
>
> That's insane. What do remarks like these have to do with Lisp or with
> your life or anything?
>
> Sure, little children can be put off from learning a craft or science
> by harsh teachers, and supposedly develop problems, like fear of
> anything related to numbers or mathematics.
>
> But what are you, a baby or a grown man?

Well, accepting your false dichotomy, since he is here now he is a grown 
man.  Now, which are you going to be?

-- 
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: verec
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43d28fe6$0$87294$5a6aecb4@news.aaisp.net.uk>
On 2006-01-21 17:50:35 +0000, "Kaz Kylheku" <········@gmail.com> said:

>> I was put off by remarks like theses, and let Lisp go in
>> the process ... too bad :-(
> 
> That's insane. What do remarks like these have to do with Lisp or with
> your life or anything?

[line noise snipped]

> There isn't a single computing tool that I use for which I couldn't
> find some online discussion group where the kinds of things happen that
> put you off. That amounts to an excuse to dump every operating system,
> programming language, editor et cetera. And what, take up gardening?

How did you guess ?

Yep, I am modestly contributing what I can to the CL Gardeners
project ... How come I never saw your name there ?

Oh! Silly me! You are a grown up with real life and responsibility!
A tatooed man! :-)
--
JFB
From: Pascal Bourguignon
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <87zmlqhbr0.fsf@thalassa.informatimago.com>
"beza1e1" <···············@googlemail.com> writes:

> I started reading Paul Grahams Essays and got hooked. I read a lot to
> know more about those "macros" and "continuations". I learned little
> syntax, style (thanks college for forcing me to learn some Haskell and
> FP) by playing around with Scheme.
> But for my current web project i use Python, because i don't manage to
> really switch to Lisp or Scheme.
>
> The problem is, i have to switch so much:
> - new language (alist, plist, ...)
> - new style (more functional, less imperative)
> - new IDE (Emacs + SLIME)
> - new framework (ucw, which means continuations instead of MVC)
> - new environment (Hyperspec, mailing-lists, ...)
>
> Each of these 5 switches alone is hard. Doing them all at once is
> nearly impossible.

Of course.  Don't do them all at once!

I'd advice:

year 0: switch to emacs; do ALL your editing in emacs, C, java, php, whatever,
        including email, web and irc!

year 1: start to learn and program in Common Lisp, but avoid lists.
        Use classic data structures such as arrays,  structures, and
        hash-tables:

     (defstruct person
           name
           age
           sex)

     (defparameter *parents* (make-array 0 :adjustable t :fill-pointer 0))
     (vector-push-extend (make-person :name "Father" :age 40 :sex :m) *parents*)
     (vector-push-extend (make-person :name "Mother" :age 35 :sex :f) *parents*)
     (print (aref *parents* 0))
     etc.

year 2: start slowly to use lists, but avoid anything related to
        a-list or p-list!

     (defparameter *parents* 
         (make-array 2 :initial-contents
                (list (make-person :name "Father" :age 40 :sex :m) *parents*)
                      (make-person :name "Mother" :age 35 :sex :f) *parents*))
     (print (aref *parents* 0))
     
year 3: learn about recursive functions and start to get a hint about
        functional style.

year 4: time to read some more of Hyperspec.

year 5: subscribe to some mail-list, or to news:comp.lang.lisp to ask
        a few newbie questions.

year 6: Now you've got 5 years of emacs experience, time to start to use slime.

year 7: Having pondered the Hyperspec and some list experience, start
        to use a-lists and p-lists.

year 8: no, too soon yet for UCW.  Spend the year writing your own
        programs, CGI, etc.

year 9: learn about UCW and try to convert some of your CGI to UCW.

year 10: complete learning UCW and rewrite your web application with UCW.

year 11: congratulation, you're now an advanced newbie. You can come
         to news:comp.lang.lisp to further advance your knowledge of Lisp.


> The sad thing is, i already discovered some of the gems of Lisp. By
> writing Python i see a lot of things, where i'd like to use a little
> macro or symbols or ... knowing these definitly made me a better
> programmer (as some people promised) but knowledge can be painful
> sometimes.
>
> I know learning takes time, but if you have some suggestions, i'd be
> thankful.

Go at your own rythm!  There's no exam in 5 months...

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"Specifications are for the weak and timid!"
From: beza1e1
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1137833437.571867.242570@g14g2000cwa.googlegroups.com>
Pascal Bourguignon wrote:
>
> I'd advice:
>
> year 0: switch to emacs; do ALL your editing in emacs, C, java, php, whatever,
>         including email, web and irc!
>
> year 1: start to learn and program in Common Lisp, but avoid lists.
> [...]
> year 11: congratulation, you're now an advanced newbie. You can come
>          to news:comp.lang.lisp to further advance your knowledge of Lisp.

Thanks for your idea of a "natural learning path", Pascal.

I don't take i literally for sure, but using "year" looks like "the
Lisp way" is very hard. Python/Ruby promise instant success or at least
something in weeks. Now is Lisp just not for the average programmer, as
some famous essayist says, or don't you think there is any difference?
From: Markus Grueneis
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43eebrF1n3pn5U1@individual.net>
beza1e1 wrote:
> Pascal Bourguignon wrote:
>> I'd advice:
> [...] 
> Thanks for your idea of a "natural learning path", Pascal.
> 
> I don't take i literally for sure, but using "year" looks like "the
> Lisp way" is very hard. Python/Ruby promise instant success or at least
> something in weeks. Now is Lisp just not for the average programmer, as
> some famous essayist says, or don't you think there is any difference?
> 

A nice article: "Teach yourself programming in 10 years" [1]

To be honest:  I am eventually a bad programmer, for sure, but everytime 
I just tried a language for your promised "instant success" time, I only 
got (1) the "instant success" stories the language is known for (lwp or 
so) and (2) some tool and/or algorithm transliteration I've done x-times 
for the sake of seeing it in yet another syntax.

Your mileage will probably be much better, though.


mfg
Markus


[1] http://www.norvig.com/21-days.html
From: Alan Crowe
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <863bjhwwdy.fsf@cawtech.freeserve.co.uk>
"beza1e1" <···············@googlemail.com> writes:
> I don't take i literally for sure, but using "year" looks like "the
> Lisp way" is very hard. Python/Ruby promise instant success or at least
> something in weeks. Now is Lisp just not for the average programmer, as
> some famous essayist says, or don't you think there is any difference?

I friend of mine has a web application that he wrote in
Perl. He got a another contract, to add functionality, and
decided to switch to Ruby on Rails.

He did not know Ruby. He planned to learn it "on the job".

This proved to be too difficult, so he scrapped his new Ruby
code, completed his contract by adding more Perl to his Perl
code base, and then settled down to learn Ruby "off the
job".

I think that his experience is typical of the difficult
judgement calls that you have to make when learning new
things.

"On the job" or "off the job"? A key question is whether you
can dip into reference material, or whether you need to work
through your tutorials systematically, starting at the
beginning.

If you can solve problems as you encounter them by
consulting reference materials, then you can learn "On the
job". If you have to break off from "the job" to read a long
tutorial, or even a book, from the beginning, in order to
get the basic concepts, then the pressure of "the job" will
inhibit you from going back far enough to learn the basics.

My guess is that you need to set aside time to learn the
basics, such as how to use closures, "off the job". ie on a
schedule that leaves time to play, just to satisify your
curiosity, and leaves time for things to sink.

The claim that CL is a larger language is somewhat
misleading. Part of the size lies in the "standard library"
which is part of the language standard and contains many
useful utilities. There are no new concepts there - pick
them up later "on the job" with (apropos ...) and (describe
...) and browsing.

I think that the reason that Lisp is not accessible to
today's "average programmer" is simply that the average
programmer of 2006 is not interested in computer
programming. To him it is just a job. If you are actually
interested, then you are not average, and you will find that
the difficulties in CL yield to a modest amount of hard work
without demanding academic brilliance.

Alan Crowe
Edinburgh
Scotland
From: Frank Buss
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1judt71tuzum$.esq2i0bc0wq3.dlg@40tude.net>
Alan Crowe wrote:

> I think that the reason that Lisp is not accessible to
> today's "average programmer" is simply that the average
> programmer of 2006 is not interested in computer
> programming. To him it is just a job.

A programmer who is not interested in programming sounds strange. And even
if he/she wants to avoid too many time with coding, Lisp could help, once
you have learned it and when you've found the right tools and libraries for
it, because then it should be possible to concentrate on the problem and
not coding, compiling, deploying etc.

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Alan Crowe
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <86y819v9md.fsf@cawtech.freeserve.co.uk>
Frank Buss <··@frank-buss.de> writes:

> A programmer who is not interested in programming sounds strange. And even
> if he/she wants to avoid too many time with coding, Lisp could help, once
> you have learned it and when you've found the right tools and libraries for
> it, because then it should be possible to concentrate on the problem and
> not coding, compiling, deploying etc.

Many young persons do not know what line of work they wish
to pursue. We are going through this heart ache with my
niece and nephew at the minute. A traditional idea is to
chose a career based on how well it pays. Adults say things
such as "accounting is a good job", meaning "accountants are
well paid".

During the dot com boom and for many years before
conventional wisdom was that computer programming was a good
job, meaning again that computer programmers were well paid.

A wiser approach would be to notice that a child enjoys
logic puzzles, likes to make make things, things that do
stuff, and can stick at it, changing it until it does what
was intended. Then you suggest to that particular child
"computer programming would be a good job /for you/."

That is not the way of the world. Many an able student
studies computing or engineering with the same good
discipline and tragic lack of spirit that they bring to any
school subject that they do not much like. Then they get
paid work in that line.

Once they are in paid employment their attitude to
productivity tools is doubly negative. First a new tool
means more study, which is an onerous duty, not an
opportunity to access novelty and joy. Second is the trade
union mentality. Lower productivity means that employers
needs more workers which tightens the jobs market and bids
up wages. Higher productivity means unneeded workers will be
laid off, probably the ones with little enthusiasm for their
work. From this perspective CL is an especially unattractive
language and defmacro is as popular as power looms were with
hand weavers.

Alan Crowe
Edinburgh
Scotland

P.S. see 
http://www.litencyc.com/php/stopics.php?rec=true&UID=678 
http://www.spartacus.schoolnet.co.uk/PRluddites.htm
if my historical allusion is unclear.
From: Ulrich Hobelmann
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43f7l0F1lm7dkU1@individual.net>
Alan Crowe wrote:
> Second is the trade
> union mentality. Lower productivity means that employers
> needs more workers which tightens the jobs market and bids
> up wages. Higher productivity means unneeded workers will be
> laid off, probably the ones with little enthusiasm for their
> work. From this perspective CL is an especially unattractive
> language and defmacro is as popular as power looms were with
> hand weavers.

Against that mentality is the price/value mentality.  If the employer 
doesn't care, he'll just hire *any* coder.  If he does, maybe he'll 
choose Lisp.  Likewise, if some coders are open to tools that'll boost 
their productivity and some don't care, and the trade unions manage to 
push up wages, guess who'll stay employed and who won't (if the person 
in charge makes those productivity tools mandatory). ;)

-- 
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
	Edsger W. Dijkstra
From: Frank Buss
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <ya456b1pcqjn$.iksqdf3id80m$.dlg@40tude.net>
Alan Crowe wrote:

> Once they are in paid employment their attitude to
> productivity tools is doubly negative. First a new tool
> means more study, which is an onerous duty, not an
> opportunity to access novelty and joy. Second is the trade
> union mentality. Lower productivity means that employers
> needs more workers which tightens the jobs market and bids
> up wages. Higher productivity means unneeded workers will be
> laid off, probably the ones with little enthusiasm for their
> work. From this perspective CL is an especially unattractive
> language and defmacro is as popular as power looms were with
> hand weavers.

sound like you are "Paul Graham brainwashed" :-)

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Tim X
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <87u0bxrrol.fsf@tiger.rapttech.com.au>
Alan Crowe <····@cawtech.freeserve.co.uk> writes:

> Frank Buss <··@frank-buss.de> writes:
> 
> > A programmer who is not interested in programming sounds strange. And even
> > if he/she wants to avoid too many time with coding, Lisp could help, once
> > you have learned it and when you've found the right tools and libraries for
> > it, because then it should be possible to concentrate on the problem and
> > not coding, compiling, deploying etc.
> 
> Many young persons do not know what line of work they wish
> to pursue. We are going through this heart ache with my
> niece and nephew at the minute. A traditional idea is to
> chose a career based on how well it pays. Adults say things
> such as "accounting is a good job", meaning "accountants are
> well paid".
> 
> During the dot com boom and for many years before
> conventional wisdom was that computer programming was a good
> job, meaning again that computer programmers were well paid.
> 
> A wiser approach would be to notice that a child enjoys
> logic puzzles, likes to make make things, things that do
> stuff, and can stick at it, changing it until it does what
> was intended. Then you suggest to that particular child
> "computer programming would be a good job /for you/."
> 
> That is not the way of the world. Many an able student
> studies computing or engineering with the same good
> discipline and tragic lack of spirit that they bring to any
> school subject that they do not much like. Then they get
> paid work in that line.
> 
> Once they are in paid employment their attitude to
> productivity tools is doubly negative. First a new tool
> means more study, which is an onerous duty, not an
> opportunity to access novelty and joy. Second is the trade
> union mentality. Lower productivity means that employers
> needs more workers which tightens the jobs market and bids
> up wages. Higher productivity means unneeded workers will be
> laid off, probably the ones with little enthusiasm for their
> work. From this perspective CL is an especially unattractive
> language and defmacro is as popular as power looms were with
> hand weavers.
> 

Its sad, but there does seem to be a growing trend towards people
entering programming because it was seen as an entry point into an
industry which would pay OK and where you would probably always be
able to get work. 

More and more often, I run into young people working as programmers
who tell me they are just doing this until they can get a good job in
the industry - they have no interest in programming, its just the
drudgery you do until you can hook one of the better jobs.   

At the same time, management is constantly looking for that magic
bullet - that language or methodology which will reduce maintenance
overheads on the software which is developed or reduce development
time or requisite skill levels etc. 

Seems a bit crazy to me that so much emphasis these days is
placed on the language and methodology and so little on the people
which actually do the programming! I would have thought it obvious
that no matter what the language or methodology, its the interest and
pride of those actually developing the code which will be the most
crucial factor. Programmers who are actually interested in what they
are doing will seek the best language and methodology without needing
some third party trying to push it down their throat. All thats really
necessary is a bit of guidence to ensure the programmer keeps the 'big
picture' in mind and don't get obsessed with perfection in small
insignificant parts of a project.

Tim 


-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!
From: Ulrich Hobelmann
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43h13rF1ncjh3U1@individual.net>
Tim X wrote:
> Seems a bit crazy to me that so much emphasis these days is
> placed on the language and methodology and so little on the people
> which actually do the programming! I would have thought it obvious

I think there's loads of emphasis on software engineering processes, 
design patterns, and weak technologies like UML (wait, it's not even a 
technology), but little if at all on languages, and none on people.  If 
they were paying attention to languages, we'd all be programming 
enterprise apps on top of Lisp by now (instead of learning or working 
with numerous boring, impotent Java frameworks) ;)

> that no matter what the language or methodology, its the interest and
> pride of those actually developing the code which will be the most
> crucial factor. Programmers who are actually interested in what they
> are doing will seek the best language and methodology without needing
> some third party trying to push it down their throat. All thats really
> necessary is a bit of guidence to ensure the programmer keeps the 'big
> picture' in mind and don't get obsessed with perfection in small
> insignificant parts of a project.

But languages does make a huge difference.  Sure, you can always think 
outside of a language, contradicting Wittgenstein here, but language has 
a huge influence.  When I write C, I aim lower than in better languages, 
so I don't get caught in my own web of abstractions.  But I guess most 
of it is the tedious amount of typing it takes in C...

As to the big picture: that's why we have software engineering, but for 
some reason you have to sleep with design patterns to get a job in that 
area.

-- 
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
	Edsger W. Dijkstra
From: BR
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43d38654@news.mcleodusa.net>
Ulrich Hobelmann wrote:

> As to the big picture: that's why we have software engineering, but for
> some reason you have to sleep with design patterns to get a job in that
> area.

You say that like it's a bad thing?
From: Ulrich Hobelmann
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43hfqjFdh5u9U1@individual.net>
BR wrote:
> Ulrich Hobelmann wrote:
> 
>> As to the big picture: that's why we have software engineering, but for
>> some reason you have to sleep with design patterns to get a job in that
>> area.
> 
> You say that like it's a bad thing?

It's *very* unfortunate that software engineers know *exclusively* (most 
of them, I suppose) Java, maybe C++ and C#, and design patterns, i.e. 
workarounds to express what would be one-five lines in ML or Lisp, in an 
object-oriented language (and all spread out not only over much more 
than a few lines, but even over several different classes, doing, um, no 
good to readability).

We should really be advancing the state of the art, but with the current 
state of the industry, that's not happening.  Buyers aren't paying 
enough attention, obviously, to sound design practices and low software 
TCO.  And maybe the few interesting providers aren't doing good enough 
marketing for their services as compared to something like EJB, Servlets 
+ XML, which aren't groundbreaking technologies, but merely mediocre 
solutions to not necessarily hard problems (well, to be fair, EJB has 
its strengths, but it's still far too complex, because Java+XML is a 
weak base to build on; in fact so complex that most people even try to 
avoid it nowadays, despite its strengths).

-- 
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
	Edsger W. Dijkstra
From: BR
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43d395df@news.mcleodusa.net>
Ulrich Hobelmann wrote:

> It's very unfortunate that software engineers know exclusively (most
> of them, I suppose) Java, maybe C++ and C#, and design patterns, i.e.
> workarounds to express what would be one-five lines in ML or Lisp, in an
> object-oriented language (and all spread out not only over much more
> than a few lines, but even over several different classes, doing, um, no
> good to readability).

Well I don't know if I would see them as "workarounds" so much as "ways to
think about a problem" and a tool for communication amongst peers. If one
is in charge of the "big picture" that's important.
From: Bill Atkins
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <871wz0gv0k.fsf@rpi.edu>
BR <······@comcast.com> writes:

> Ulrich Hobelmann wrote:
>
>> It's very unfortunate that software engineers know exclusively (most
>> of them, I suppose) Java, maybe C++ and C#, and design patterns, i.e.
>> workarounds to express what would be one-five lines in ML or Lisp, in an
>> object-oriented language (and all spread out not only over much more
>> than a few lines, but even over several different classes, doing, um, no
>> good to readability).
>
> Well I don't know if I would see them as "workarounds" so much as "ways to
> think about a problem" and a tool for communication amongst peers. If one
> is in charge of the "big picture" that's important.

http://norvig.com/design-patterns/

It's hard to see them any other way when you realize the equivalent
things can be done in a couple of lines of Lisp.  They are all
solutions to the problem of using an inferior language (C++ and Java)
rather than solutions to the problem itself.  That sounds like a
workaround to me.

--

Bill Atkins
From: BR
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43d3b587@news.mcleodusa.net>
Bill Atkins wrote:

> http://norvig.com/design-patterns/
> 
> It's hard to see them any other way when you realize the equivalent
> things can be done in a couple of lines of Lisp.  They are all
> solutions to the problem of using an inferior language (C++ and Java)
> rather than solutions to the problem itself.  That sounds like a
> workaround to me.

Well in your link he mentions that design patterns are either "invisible" or
simpler. They're still there though. As I mentioned in another post, design
patterns should be seen as a more generic way of looking at things.
From: Kaz Kylheku
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1137957683.702717.86540@g49g2000cwa.googlegroups.com>
BR wrote:
> Bill Atkins wrote:
>
> > http://norvig.com/design-patterns/
> >
> > It's hard to see them any other way when you realize the equivalent
> > things can be done in a couple of lines of Lisp.  They are all
> > solutions to the problem of using an inferior language (C++ and Java)
> > rather than solutions to the problem itself.  That sounds like a
> > workaround to me.
>
> Well in your link he mentions that design patterns are either "invisible" or
> simpler. They're still there though. As I mentioned in another post, design
> patterns should be seen as a more generic way of looking at things.

I would argue that a design pattern which is invisible actually /isn't/
there, and as evidence, I would cite its very invisibility.

A design pattern is a mere coding recipe for obtaining some otherwise
obvious structure or behavior in a programming language in which it is
difficult to imagine how to get that structure or behavior.

The pattern shouldn't be confused for that abstract structure or
behavior itself.

What's more, the pattern is often a compromise. It selects particular
"interesting" cases of that general structure or behavior, matching
them to the restrictions of the language.  What defines these cases as
"interesting" is, actually, that they are easily doable in that
language using that pattern. Supporting those additional
"uninteresting" cases would explode that pattern's complexity,
rendering it unattractive, so they are thrown out.

In other words, the way design patterns are presented reinforces the
common fallacy that everything that is worth doing is easy to do in our
programming language, and everything else was deliberately left out
because it's "not worth doing".

People in computer science, particularly ones who are trying to sell
you on some language or tool or whatever, seem never to properly
acknowledge the complete set of true reasons why they are rejecting
various unsupported alternatives within that space.

Don't tell me that the Visitor Pattern is "there" when I'm indirecting
on CLOS generic functions or using multiple dispatch. It's isn't there
at all.  What is there is the idea of having some aggregate structure
with polymorphic components, operated on using various algorithms, such
that the details of each algorithm are tailored to the types of the
individual components. This kind of thing can almost happen without any
thought when you are working with CLOS. There is no brain-bending going
on with regard to how to get this to happen.

So yes, the design idea of separating the algorithm from the structure,
that may be present. But the specific kludge pattern that a Java
programmer would need to capture some aspect of that idea, that is
definitely absent! That's why it's invisible: it just ain't there.
From: André Thieme
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1137962243.269010.49380@g49g2000cwa.googlegroups.com>
Kaz Kylheku schrieb:

> Don't tell me that the Visitor Pattern is "there" when I'm indirecting
> on CLOS generic functions or using multiple dispatch.

As I understand it this is only one thing the visitor pattern does,
multiple dispatch. It can also encapsulate a state. If you want the
same behaviour in Lisp don't you need the visitor pattern then too?

Norvig mentions that 16 of the 23 patterns explained in the patterns
book "have qualitatively simpler implementation in Lisp or Dylan than
in C++ for at least some uses of each pattern".
What about the other 7 patterns?


André
--
From: Kaz Kylheku
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1138010805.472051.288280@o13g2000cwo.googlegroups.com>
André Thieme wrote:
> Kaz Kylheku schrieb:
>
> > Don't tell me that the Visitor Pattern is "there" when I'm indirecting
> > on CLOS generic functions or using multiple dispatch.
>
> As I understand it this is only one thing the visitor pattern does,
> multiple dispatch.

Not really. What it does is traverse a structure and apply a generic
operation whose behavior is tailored based on the type of each visited
element.

This isn't really even an application for double dispatch. Why? Because
the algorithm does not vary over the entire traversal. For instance if
you have a syntax tree, either you are traversing that syntax tree to
pretty-print it, to do some evaluation, or to compile it or whatever.
The "dispatch" on the algorithm type is made outside of the whole
thing. Flavors of the algorithm are then chosen by the element type.


There are three ingredients.

> It can also encapsulate a state. If you want the
> same behaviour in Lisp don't you need the visitor pattern then too?

No, we just need a function that knows how to traverse the given
structure and apply a one-argument function at every node.

We can then pass in a generic function and it will be dispatched on the
node type.

If we want a function with state, we use a closure. That closure can
capture additional CLOS objects, and its body can call some other
generic function using the node that is passed in, plus these
additional objects.

The ages-old Lisp function MAPCAR in fact implements the Visitor
Pattern (if we really, really want to see it badly enough and claim
that it's actually there).

You can make a list of CLOS objects and use MAPCAR to visit them with a
generic function.

> Norvig mentions that 16 of the 23 patterns explained in the patterns
> book "have qualitatively simpler implementation in Lisp or Dylan than
> in C++ for at least some uses of each pattern".
> What about the other 7 patterns?

Those would be:

Prototype, Singleton, Adapter, Bridge, Composite, Decorator, Memento

We could take Norvig's word for the rest of them and discuss these ones
on a case by case basis.



1. Prototype

This pattern is probably unnecessary. In Lisp, a class is an object,
and serves as the prototype for making instances via MAKE-INSTANCE.

The registration part of this pattern is also unnecessary, since the
DEFCLASS macro not only instantiates the class as an object, but also
registers it in the class system under a symbol.

The FIND-CLASS method fetches a class object from a symbol.

For the sake of convenience, the MAKE-INSTANCE function takes a class
object /or/ a symbol (it's a generic function!) and calls FIND-CLASS
automatically, so you don't have to write (make-instance (find-class
'widget) ...) but simply (make-instance 'widget ...)

Now suppose you want to create objects of some class but in more than
one way; i.e. really have prototypes. You want the properties for the
objects to come from the prototypes rather than from parameters
explicitly passed to MAKE-INSTANCE.

The best way would probably be just to represent these prototypes as
ordinary functions which take no arguments and just return a new
object. Functions are first class objects, and they have a "method",
namely that they can be invoked with FUNCALL. That is adequate to serve
in the place of clone().

I.e. a prototype is just another functor in disguise: a one-function
object for carrying out that object's functional purpose.


2. Singleton

This is not really a pattern, but a kind of global variable disguised
by class scope. Lisp doesn't have class scope, so the closest
approximation would be a function that is put into a proper package,
which returns the one and only instance of some class:

  (in-package 'my-framework)

  (defvar *widget-instance*)
  (defvar *gadget-instance*)

  (defun widget-instance () ...)
  (defun gagdget-instance () ...)

These functions create their things if they don't exist and return
them. YAWN!


3.  Adapter

This would apply to generic function protocol and not really to objects
or classes. You have a framework that uses one set of generic functions
in some way to do a job, but clients written to a different interface.
So you glue the two together.

In CLOS, we don't have the problem that a class contains member
functions and we are not allowed to extend it. If you have some objects
and you want to make them work under some generic functions, then you
just write methods for those generic function specialized to those
objects. Voila, the objects are "adapted".

So this pattern disappears because of the open nature of generic
functions, or manifests itself as functional interface-conversion glue.
 Macros can help here with any repetitive coding.


4. Bridge

This one smells like it's somewhat more "real" design, since it has to
do with separating implementation concerns.

If you have M different kinds of shape objects, and N different
windowing systems, you can handle that naively with multiple dispatch:
have a two-argument DRAW generic function which takes a shape and a
windowing system object and write MxN methods for all combinations.
This solves the problem that inheritance lets you vary only one
classifying parameter.

Without multiple dispatch, you can't solve it this way, because you
can't independently subclass Shape into Circle and Square, and into
Win32Shape and XWindowShape. You are forced to make MxN entire classes:
Win32Circle, XWindowCircle, Win32Square, XWindowSquare ...

Multiple dispatch lets you split that object into two or more objects:
the shape itself, and the utensil for drawing it, etc.

So the problem of writing MxN classes is mitigated into one of writing
MxN methods for that particular operation of interest.

Within that framework, you can try various labor saving strategies to
reduce the code variants. For instance, in this case, break up the DRAW
function into a two phase switch: 1) extraction of some generic
description of the shape and 2) processing that specification to render
it over a given GUI. For instance perhaps each shape can be broken into
a sequence of simpler components, like arcs, splines and line segments.
One generic function extracts such a sequence from any shape, and
another generic function draws such a sequence using some choice of GUI
API.

The drawing could be done by multiple dispatch, but in a much smaller
space: the Cartesian product of simple shape components and GUI
implementations.


5. Composite

I think you could have a field day with this in Lisp. You have some
object that represents a collection of other objects, as a group. It
basically responds in the same way as any one of those individual
components. Same interface.

This is easy to do. Just define the composite class, and write methods
for all the generic functions that already work with the components so
that they work with the composite.

I think we could make some Lisp macro to help automate some of this
because many of the methods that take the composite will be boring
wrappers that bounce control to the contained objects in regular ways.


6. Decorator

Here, we want to customize the methods of an object instance at
run-time, and it's done by adding another object "around" it which
obeys the same protocol and customizes the behavior.

Lisp can help us with this one big time because the decorator object
probably has to support lots of methods, but is not interested in
customizing all of them.

Firstly, one nice thing is that we don't have to inherit any interface
base class and be forced to implement lots of functions.

Another thing is that all the functions which are simple wrappers that
redirect to the decorated object can be written for us by a macro.

But does it have to be done that way?

I can think of other ways of dynamically associating operations with an
object.

7. Memento

I'm getting pretty tired, haha.  One obvious thing that comes to mind
for this last one is to just use functional programming. A memento
cookie then reduces to a simple reference to an object, since any new
versions of an object are new instances:

  (let* ((list '(1 2 3))
         (memento list))
    (push 'a list)
    (push 'b list)
    (print memento))
From: John Thingstad
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <op.s3sbwiekpqzri1@mjolner.upc.no>
On Sun, 22 Jan 2006 15:25:51 +0100, BR <······@comcast.com> wrote:

> Ulrich Hobelmann wrote:
>
>> It's very unfortunate that software engineers know exclusively (most
>> of them, I suppose) Java, maybe C++ and C#, and design patterns, i.e.
>> workarounds to express what would be one-five lines in ML or Lisp, in an
>> object-oriented language (and all spread out not only over much more
>> than a few lines, but even over several different classes, doing, um, no
>> good to readability).
>
> Well I don't know if I would see them as "workarounds" so much as "ways  
> to
> think about a problem" and a tool for communication amongst peers. If one
> is in charge of the "big picture" that's important.

Well perhaps you would like to see Norvigs perspective on design patterns.
http://norvig.com/design-patterns/
I think that design patterns is mostly a SmallTalk hack to get around
the fact that everything is objects and must send messages.
The whole idea of using object to decomose algorithms seems wrong to me.
The fact that this is best in SmallTalk dosn't make it best
for all languages. More it reflects on the limited expressabillity
in SmallTalk.
Some patterns make sense, some don't. Often I find there is a
functional or imperative formulation that mapps better to
the problem.
To often it is complicated because you are trying to put a square peg  
through
a round whole.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Bill Atkins
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <87r770fg07.fsf@rpi.edu>
"John Thingstad" <··············@chello.no> writes:

> On Sun, 22 Jan 2006 15:25:51 +0100, BR <······@comcast.com> wrote:
>
>> Ulrich Hobelmann wrote:
>>
>>> It's very unfortunate that software engineers know exclusively (most
>>> of them, I suppose) Java, maybe C++ and C#, and design patterns, i.e.
>>> workarounds to express what would be one-five lines in ML or Lisp, in an
>>> object-oriented language (and all spread out not only over much more
>>> than a few lines, but even over several different classes, doing, um, no
>>> good to readability).
>>
>> Well I don't know if I would see them as "workarounds" so much as
>> "ways  to
>> think about a problem" and a tool for communication amongst peers. If one
>> is in charge of the "big picture" that's important.
>
> Well perhaps you would like to see Norvigs perspective on design patterns.
> http://norvig.com/design-patterns/
> I think that design patterns is mostly a SmallTalk hack to get around
> the fact that everything is objects and must send messages.
> The whole idea of using object to decomose algorithms seems wrong to me.
> The fact that this is best in SmallTalk dosn't make it best
> for all languages. More it reflects on the limited expressabillity
> in SmallTalk.
> Some patterns make sense, some don't. Often I find there is a
> functional or imperative formulation that mapps better to
> the problem.
> To often it is complicated because you are trying to put a square peg
> through
> a round whole.
>
> -- 
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Smalltalk?  Really?  I've only ever seen design patterns applied to
C++ and Java.

--

Bill Atkins
From: Ulrich Hobelmann
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43hlg1F1muostU1@individual.net>
BR wrote:
> Ulrich Hobelmann wrote:
> 
>> It's very unfortunate that software engineers know exclusively (most
>> of them, I suppose) Java, maybe C++ and C#, and design patterns, i.e.
>> workarounds to express what would be one-five lines in ML or Lisp, in an
>> object-oriented language (and all spread out not only over much more
>> than a few lines, but even over several different classes, doing, um, no
>> good to readability).
> 
> Well I don't know if I would see them as "workarounds" so much as "ways to
> think about a problem" and a tool for communication amongst peers. If one
> is in charge of the "big picture" that's important.

I'm not sure that using design patterns one can even communicate 
effectively.  Especially when you have a real program (i.e. a lot of 
source), but not only then, it's not really helpful if every small 
interaction requires two or three classes to interoperate in a specific 
way.  I'd rather just write two clear, concise lines of code, using a 
higher-order function or two, and be done with it.  No need to 
communicate two-three classes to anybody, because *those classes aren't 
necessary to solve the ploblem at hand*, i.e. they're just a workaround 
to get good program structure into a Java program.

Enough ranting...  I use Java when I must (and then no bitching will 
help), otherwise I avoid it.

-- 
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
	Edsger W. Dijkstra
From: John Thingstad
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <op.s3sd34hlpqzri1@mjolner.upc.no>
On Sun, 22 Jan 2006 16:08:48 +0100, Ulrich Hobelmann <···········@web.de>  
wrote:

>
> I'm not sure that using design patterns one can even communicate  
> effectively.  Especially when you have a real program (i.e. a lot of  
> source), but not only then, it's not really helpful if every small  
> interaction requires two or three classes to interoperate in a specific  
> way.  I'd rather just write two clear, concise lines of code, using a  
> higher-order function or two, and be done with it.  No need to  
> communicate two-three classes to anybody, because *those classes aren't  
> necessary to solve the ploblem at hand*, i.e. they're just a workaround  
> to get good program structure into a Java program.
>
> Enough ranting...  I use Java when I must (and then no bitching will  
> help), otherwise I avoid it.
>

Exactly.
A program spesification describes behaviour.
Softwarepatterns describe design.

It is not practical for a systems analysist to spesify design.
In fact micromanagement can be disasterous.
Noone has that complete a picture of the problem from
the onset it typically evolves as you go along.
To many software projects have faile due to overeager analysists giving  
detailed spefifications.
Along comes a new observation, simple, but it changes everything.
The programmers try to make it work under the spesification and it turnes  
into a cluge.
Time limitations stop them from improving it. Now you have a system that  
noone really
knows how works and further development grinds to a crawl..

Object Oriented Analisis by Code/Yourdon is a good book
on analysis.
Dedign patters is somthing programmers and designers use to document code
when the granularity of classes is to detailed to see the forest for the  
trees
and for uniformity of implementation.
Also see my other post.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: BR
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43d3b3f1@news.mcleodusa.net>
John Thingstad wrote:

> Exactly. A program spesification describes behaviour.
> Softwarepatterns describe design.

And the Facade pattern could describe a compiler. I think part of the
problem we're having here is that one wants to see design patterns in terms
of language implimentation (Dynamic Language patterns being "invisible"),
instead of a more generic way of looking at our designs.
From: John Thingstad
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <op.s3rxxjx3pqzri1@mjolner.upc.no>
On Sun, 22 Jan 2006 02:12:58 +0100, Tim X <····@spamto.devnul.com> wrote:

>
> Seems a bit crazy to me that so much emphasis these days is
> placed on the language and methodology and so little on the people
> which actually do the programming! I would have thought it obvious
> that no matter what the language or methodology, its the interest and
> pride of those actually developing the code which will be the most
> crucial factor. Programmers who are actually interested in what they
> are doing will seek the best language and methodology without needing
> some third party trying to push it down their throat. All thats really
> necessary is a bit of guidence to ensure the programmer keeps the 'big
> picture' in mind and don't get obsessed with perfection in small
> insignificant parts of a project.

I would agree that in programming people are the most important resource.
But have you considered that Lisp seems to attract and hold
some of the best programmers?
If you don't believe me compare the tecnical level on the support here
with other groups.
People that care about programming care about what they program in as well.
The guy that is just in it for the money is more likely to want to learn
a popular language like Java. Very few people approach Lisp as a first  
language.
Already the incentive to want to try many languages to find which you are  
the most
confortable in suggest interest.
I have found it far easier to find good Lisp programmers than good
Java programmers..

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: John Thingstad
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <op.s3r3uciwpqzri1@mjolner.upc.no>
On Sun, 22 Jan 2006 10:57:09 +0100, John Thingstad  
<··············@chello.no> wrote:

Well perhaps your experience is different from mine.
My last job was for Opera where the director was a programer.
I worked under the tecnical director who was/is ilso a programmer.
Here there was certainly a urge to go to great length to get the right  
programmer.
It was acknoleged that the best programmers were up to 10 times more  
productive
than the bad ones. So from my personal experience what you are saing it is  
a
truth with modifications.
At least in Opera the programmers are the kings of the hill :)
If I got the impression that I was just a comodity I think I would
choose another job. A incompetent manager is no better than a
incompetent programmer. Like all people I like recognition for my efforts.
That means I also like to be paid accordingly.
If your manager thinks hiring newbies because it cheap will lead
to cheap operating cost's let him. It's his funeral, don't let it be yours  
as well.
Find another job. Prospective employies can make demands too you know.

> On Sun, 22 Jan 2006 02:12:58 +0100, Tim X <····@spamto.devnul.com> wrote:
>
>>
>> Seems a bit crazy to me that so much emphasis these days is
>> placed on the language and methodology and so little on the people
>> which actually do the programming! I would have thought it obvious
>> that no matter what the language or methodology, its the interest and
>> pride of those actually developing the code which will be the most
>> crucial factor. Programmers who are actually interested in what they
>> are doing will seek the best language and methodology without needing
>> some third party trying to push it down their throat. All thats really
>> necessary is a bit of guidence to ensure the programmer keeps the 'big
>> picture' in mind and don't get obsessed with perfection in small
>> insignificant parts of a project.
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Tim X
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <87hd7wsf1w.fsf@tiger.rapttech.com.au>
"John Thingstad" <··············@chello.no> writes:

> On Sun, 22 Jan 2006 02:12:58 +0100, Tim X <····@spamto.devnul.com> wrote:
> 
> >
> > Seems a bit crazy to me that so much emphasis these days is
> > placed on the language and methodology and so little on the people
> > which actually do the programming! I would have thought it obvious
> > that no matter what the language or methodology, its the interest and
> > pride of those actually developing the code which will be the most
> > crucial factor. Programmers who are actually interested in what they
> > are doing will seek the best language and methodology without needing
> > some third party trying to push it down their throat. All thats really
> > necessary is a bit of guidence to ensure the programmer keeps the 'big
> > picture' in mind and don't get obsessed with perfection in small
> > insignificant parts of a project.
> 
> I would agree that in programming people are the most important resource.
> But have you considered that Lisp seems to attract and hold
> some of the best programmers?
> If you don't believe me compare the tecnical level on the support here
> with other groups.
> People that care about programming care about what they program in as well.
> The guy that is just in it for the money is more likely to want to learn
> a popular language like Java. Very few people approach Lisp as a first
> language.
> Already the incentive to want to try many languages to find which you
> are  the most
> confortable in suggest interest.
> I have found it far easier to find good Lisp programmers than good
> Java programmers..
> 

Well, maybe I wasn't clear, but thats essentially what I was
saying. However, the problem is good programmers are rarely recognised
or acknowledged. Instead, programmers are viewed as either doing
programming until they can get a better position elswhere in the
industry (sales, management, consultant etc) or unmotivated, possibly
lazy people who don't have the aspirations to achieve better
things. There appears to be a growing trend towards de-valuing the
role of programming and little recognition of skill and experience. 

I've actually seen places adopt strategies in which they have gotten
rid of higher paid experienced and talented programmers in favor of
cheaper graduates with little programming or world experience. The
rationale appears to be based in the belief that given a 10 day course in
programming with X, the new younger and cheaper guy will be as good as
the older, experienced, but more expensive one. I constantly run
across these 'cheap' programmers - they are the ones who have to be
sent on a course before they can start using a new language and yet,
my experience has generally been that the best programmers I've worked
with have never taken a course in how to program in X. If they are
intrested in X, they just sit down and learn it. There appears to be
no recognition of the fact that knowing the syntax and standard
libraries of a language is not the same as being able to program
effectively in it. In my experience, a good programmer will generally
be a good programmer regardless of the tool (language). Some
tools/languages will allow you to be a better programmer by imposing
less constraints on how you represent the problem. A good programmer
will be able to do a good job compared to less skilled programmers
regardless of the tools used - better tools will just enable them to
do a better job or do the job faster. 

Of couse, the next thing which happens to these companies who replace
experienced and interested programmers with cheaper less experienced
ones is they unknowingly find themselves on the wrong side of the
equation - they suddenly find their maintenance costs begin to blow
out - they have more bugs to kill, find their systems are more
difficult to extend and cannot seem to hang onto staff (who keep
moving on to better more interesting work - usually not in
programming). So the management starts looking around for majic
bullets - the staff turnover means they get into the mindset where
they stick to popular technology because they are worried about
keeping up with the staff turnover. they start paying consultants who
come in and tell them the problem is with their methodology and they
need to adopt (insert current fashion technology here) and all will be
OK. 

Unfortunately, it rarely occurs to them that the problem may be due to
their programming staff lacking experience or any real interest in
trying to do things well. Its seems rare that anyone says "Hey, could
it be our problems are due to bad design or problem representation
implemented by a largely disinterested group of developers who are
really just waiting for an opening in ........

I think the reason many have observed higher quality programming
coming from people with a lisp background is primarily because those
who get intrested in and skilled in lisp are largely doing it because
they have a real interest in programming. There is a real drive to
understand and get better at what you do and the tools you use to do
it. 

Of course, the danger is that once yu have found a tool like lisp
which you really find powerful, its increadibly frustrating when you
are forced to use something far less powerful when at work!

Tim
-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!
From: Ulrich Hobelmann
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43ha62F1nc68qU1@individual.net>
Tim X wrote:
> Well, maybe I wasn't clear, but thats essentially what I was
> saying. However, the problem is good programmers are rarely recognised
> or acknowledged. Instead, programmers are viewed as either doing
> programming until they can get a better position elswhere in the
> industry (sales, management, consultant etc) or unmotivated, possibly
> lazy people who don't have the aspirations to achieve better
> things. There appears to be a growing trend towards de-valuing the
> role of programming and little recognition of skill and experience. 

I think this is because programmers are often employees, and as such 
considered a commodity.  Nobody knows the names of the individual 
programmers.  Programmers don't have agents or management.  They don't 
do marketing.  Therefore their boss doesn't recognize when one 
programmer causes their system high maintenance, or when one creates an 
excellent system with about zero maintenance.  He/She's then considered 
just a good employee, nothing more.

It'd be good to have a more industrialized consulting or programming 
industry, and with increased outsourcing maybe that will happen.  Those 
companies might focus on clean design and low maintenance costs, unlike 
in-house programming.

Of course another thing that encourages programmers to not go 
industrial, but get an employee position is the skew in most countries 
that employees enjoy vastly better benefits, by law, than independent 
workers.  If I'll stay in Germany, I'd be almost stupid not to work as a 
regular employee, even though that means that nobody will ever care if i 
do a mediocre or an outstanding job.  I suppose that in turn might 
encourage me (depending on the company) not to run the extra miles for 
the "outstanding"; mediocre or "ok" might do.

-- 
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
	Edsger W. Dijkstra
From: Ulrich Hobelmann
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <43eqajF1ndk31U1@individual.net>
beza1e1 wrote:
> I don't take i literally for sure, but using "year" looks like "the
> Lisp way" is very hard. Python/Ruby promise instant success or at least
> something in weeks. Now is Lisp just not for the average programmer, as
> some famous essayist says, or don't you think there is any difference?

I agree that the usage of "year" is unfortunate.  I picked up Lisp quite 
quickly, and without big problems with Emacs, but I have prior 
experience in ML and Scheme.  OTOH I picked up those two languages 
rather fast, too.

I don't think there's anything that makes Python & Co inherently easier 
to learn; only some weird Lisp names that you have to learn, and a lack 
of popular libraries as in Python.

-- 
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
	Edsger W. Dijkstra
From: Thomas F. Burdick
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <xcvek3125fq.fsf@conquest.OCF.Berkeley.EDU>
"beza1e1" <···············@googlemail.com> writes:

> I started reading Paul Grahams Essays and got hooked. I read a lot to
> know more about those "macros" and "continuations". I learned little
> syntax, style (thanks college for forcing me to learn some Haskell and
> FP) by playing around with Scheme.
> But for my current web project i use Python, because i don't manage to
> really switch to Lisp or Scheme.
> 
> The problem is, i have to switch so much:
> - new language (alist, plist, ...)
> - new style (more functional, less imperative)
> - new IDE (Emacs + SLIME)

Yes, you'll want to use a new IDE.  But there are other options than
Emacs -- check out Allegro, LispWorks, Corman, and MCL.  It's
worthwhile to learn an Emacs-like editor, but GNU Emacs is definately
not the easiest one to learn.  The Allegro, LW, and MCL editors are a
more newbie-friendly route to learning emacs.

> - new framework (ucw, which means continuations instead of MVC)

There's no need to use ucw.  There are *tons* of web-programming
options for Common Lisp, most of which are intended to support a more
MVC-like style.  Since you find everything else daunting, maybe you
should wait to investigate continuations until you're more comfortable
with everything else.

> - new environment (Hyperspec, mailing-lists, ...)
>
> Each of these 5 switches alone is hard.

Indeed.  But you can't learn new things without learning new things.

> Doing them all at once is nearly impossible.

Nonesense!  Buy yourself a copy of _Practical Common Lisp_, and take
it slowly.  Some people like to jump in head first, but there's no
reason you can't wade in at your own pace.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Harald Hanche-Olsen
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <pcok6ctsfzr.fsf@shuttle.math.ntnu.no>
+ ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick):

| "beza1e1" <···············@googlemail.com> writes:
|
|> Doing them all at once is nearly impossible.
|
| Nonesense!  Buy yourself a copy of _Practical Common Lisp_, and take
| it slowly.

Or just go to http://www.gigamonkeys.com/book/ and have a look.
But by all means, if you develop an appetite for common lisp after
working through a few chapters, buy the book.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
  than thinking does: but it deprives us of whatever chance there is
  of getting closer to the truth.  -- C.P. Snow
From: André Thieme
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1137863025.841070.120320@f14g2000cwb.googlegroups.com>
beza1e1 schrieb:

> I started reading Paul Grahams Essays and got hooked. I read a lot to
> know more about those "macros" and "continuations". I learned little
> syntax, style (thanks college for forcing me to learn some Haskell and
> FP) by playing around with Scheme.

Great!
Haskell can really be of help to learn some functional programming.
While Lisp supports it, Lisp also supports imperative programming which
makes it harder not to use that option.


> But for my current web project i use Python, because i don't manage to
> really switch to Lisp or Scheme.
>
> The problem is, i have to switch so much:
> - new language (alist, plist, ...)

Well, what did you expect?
Where should the qualities of Lisp come from if it were exactly the
same like the other languages you already know? Just don't use any
advanced language constructs, use only techniques you already know from
other languages and the "new language" argument would be gone. And btw,
alists and plists are just some datastructures which are language
independent.


> - new style (more functional, less imperative)

One might think that. That comes because several lispers pronounce how
positive functional programming can be. But Lisp isn't less imperative
than say, Python.
So as you can program completely imperative this argument doesn't
count.


> - new IDE (Emacs + SLIME)

Emacs has many several unusual keybindings compared to other editors.
However, you only need a few minutes to learn the most important ones
and the rest will come with time. Make a list of the +/- 20 most
important key combinations and put them before you. Within three days
you will be able to use it. This will have the advantage that you can
emacs for coding in other languages too (not that using other languages
is a thing you want to do if you know more about Lisp.. but you would
be prepared). Emacs is very well suited for programming Python for
example.
As it only takes a few minutes to sum up the most important key
bindings and as Emacs is useful for coding in other languages too I
personally can't count this argument.


> - new framework (ucw, which means continuations instead of MVC)

Use AllegroServe and you have MVC.
AllegroServe (or portable AllegroServe) supports "Webactions". That is
a very very sexy development plattform for web applications. There is a
strict separation between webdesign and programming. So in your
programs you never have to write a line of HTML. A webdesigner can work
at the same time on the same page without interfering. MVC is already
built in into AllegroServe.
As you can use MVC I can't really count this framework argument.


> - new environment (Hyperspec, mailing-lists, ...)

Huh?
Uhm yes, you need to send your questions/comments to another mainling
list. But is that really so difficult?
What is different for you when the documentation which you are reading
sits on another internet site?
Whenever I want to learn something new I somehow expect that I need to
read new books/internet pages... in my old readings there won't be
explanations for that new stuff.
Well, for me personally this argument doesn't count.


> Each of these 5 switches alone is hard. Doing them all at once is nearly impossible.

What I did was not a mathematical proof, but to me it seems pretty
clear that none of the arguments you brought up are really a problem.
It means of course that you have to spend a few weeks for learning..
but
"Is initial productivity more important than long term productivity?"
as Cameron MacKinnon asked a few days ago [1].


> The sad thing is, i already discovered some of the gems of Lisp. By writing Python i see a
> lot of things, where i'd like to use a little macro or symbols

For example? Could you maybe post some Python code where you think the
use of a macro or the symbol datatype would be an advantage?


> I know learning takes time, but if you have some suggestions, i'd be thankful.

My suggestion: take the time to learn it.


[1] http://groups.google.de/group/comp.lang.lisp/msg/b3e56d889a3fa0e9


André
--
From: beza1e1
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1138096522.254609.196710@z14g2000cwz.googlegroups.com>
You are right, each problem is no a problem. It's the sum of them. I
decided to make emacs the first task. Mainly because so many people
around me are using it.

An example? I played around to make a Template Library (well, more a
renderable DOM Library or something). I have to write this Python Code:

class em(Tag): tag = 'em'
class h1(Tag): tag = 'h1'
class h2(Tag): tag = 'h2'
class h3(Tag): tag = 'h3'
...

I rewrote a part of this in PLT Scheme and it condensed to:

(generate-html-tags em h1 h2 h3 ...)

There may be a way to make class generation automated in Python but i
haven't found it yet.
From: André Thieme
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1138104525.281758.317140@f14g2000cwb.googlegroups.com>
beza1e1 schrieb:

> You are right, each problem is no a problem. It's the sum of them. I
> decided to make emacs the first task. Mainly because so many people
> around me are using it.

Good idea. Just learn these key combinations, the rest will come with
time:
C-x C-c   close Emacs
C-x C-f   open file
C-x C-s   save (current) buffer
C-x C-w   save buffer as...
C-x k     close buffer

C-x b     change buffer
C-x 2     split window horizontally
C-x 1     show buffer fullscreen
C-x o     switch cursor into another window
C-g       abort

C-Space   start to mark text
M-w       copy marked text
C-w       cut marked text
C-y       insert copied text
C-_       undo

Where C- means: press the Ctrl key while you press the following key
and M- means: press the Alt key while you press the following key.

When you open Emacs select in the "Options" menu the first three
entries:
- Syntax Highlightning
- Active Region Highlightning
- Paren Match Highlightning

and then Options->Save Options

You should be able to learn these key combinations within a very short
time because you simply need them all the time while editing. With
these 15 hotkeys you are very ready to do most stuff.
When you are used to these you can learn 5 more hotkeys for Slime and
voila, Emacs problem solved.



> An example? I played around to make a Template Library (well, more a
> renderable DOM Library or something). I have to write this Python Code:
>
> class em(Tag): tag = 'em'
> class h1(Tag): tag = 'h1'
> class h2(Tag): tag = 'h2'
> class h3(Tag): tag = 'h3'
> ...
>
> I rewrote a part of this in PLT Scheme and it condensed to:
>
> (generate-html-tags em h1 h2 h3 ...)

What is this function doing? Does it create a html string? Or does it
generate the classes for you?


> There may be a way to make class generation automated in Python but i
> haven't found it yet.

Do you mean by "automated class generation" that you create a new class
during runtime?
That is very easy to do in Python...


André
--
From: Frank Buss
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <1hfbbkjk1c1e.o4mqkli4vmp1.dlg@40tude.net>
beza1e1 wrote:

> The problem is, i have to switch so much:

Do you mean switching from Python or do you know Java, C or any other
language already?

> - new language (alist, plist, ...)
> - new style (more functional, less imperative)

You can start programming in Lisp like in any other language you know, you
don't need alists and plists (only implicit, e.g. for keyword function
arguments, but you can learn this later) or using functional concepts.

Some code in C:

struct Foo {
  int x;
  const char* test;
};

struct Foo bar;

void printStruct() {
  printf("x=%i, test=%s\n", bar.x, bar.test);
}

void test() {
  bar.x = 10;
  bar.test = "hello";
}

void main() {
  test();
  printStruct();
}

and in Lisp:

(defstruct foo
  (x)
  (test))

(defparameter bar (make-foo))

(defun print-struct ()
  (format t "x=~a, test=~a~%" (foo-x bar) (foo-test bar)))

(defun test ()
  (setf (foo-x bar) 10)
  (setf (foo-test bar) "hello"))

(defun main ()
  (test)
  (print-struct))

You can learn to write more Lisp-like programs on-the-job, it is not
required, if you start using Lisp.
  
> - new IDE (Emacs + SLIME)

Yes, that's true, currently you have to buy e.g. LispWorks, to have an IDE
which looks and behave like other Windows IDEs: standard Windows keyboard
mapping, easy to use graphical debugger etc. There was a discussion on the
CL Gardeners mailing list ( http://www.lispniks.com/cl-gardeners/ ) about
customizing Lisp-in-a-box with standard Windows keyboard mapping, but I
don't know what the result was.

> - new framework (ucw, which means continuations instead of MVC)

There are other frameworks without continations, e.g. Allegro Serve (or the
free portable version), which is more like the CGI concept.

> - new environment (Hyperspec, mailing-lists, ...)

What do you mean with this? As already written, of course you need some
documentation, like the Hyperspec.

> Each of these 5 switches alone is hard. Doing them all at once is
> nearly impossible.
> 
> The sad thing is, i already discovered some of the gems of Lisp. By
> writing Python i see a lot of things, where i'd like to use a little
> macro or symbols or ... knowing these definitly made me a better
> programmer (as some people promised) but knowledge can be painful
> sometimes.

I don't see any difference in using Python, if you don't know both
languages and available libraries already. But with Lisp you have to search
your best environment first, for Python you have one implementation, which
works on every platform and has many libraries already included. Maybe this
will be solved with some CL Gardeners projects.

-- 
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Larry Clapp
Subject: Re: Why i don't switch to Lisp
Date: 
Message-ID: <slrndt4fbc.hr7.larry@theclapp.ddts.net>
On 2006-01-21, Frank Buss <··@frank-buss.de> wrote:
> beza1e1 wrote:
>> - new IDE (Emacs + SLIME)
>
> Yes, that's true, currently you have to buy e.g. LispWorks, to have
> an IDE which looks and behave like other Windows IDEs: standard
> Windows keyboard mapping, easy to use graphical debugger etc.

Easymacs can help with this, perhaps.
http://www.dur.ac.uk/p.j.heslin/Software/Emacs/Easymacs/

-- L