RE: ++CD-ROM drive

["Jonathan Shore" <jshore@example.com>]

>SN_Diamond [Norman.Diamond@example.com] wrote:
> Jonathan Shore wrote:
>
> > Hmm, he did mention *efficient* here - maybe lisp qualifies by another
> > standard.  Last time I checked the lisp/scheme groups they were still
> > talking about GC algorithms (and that after 10+ years).
> Interesting topic
> > but it gives you an idea of some of the problems with the language.
>
> Lisp groups have been discussing garbage collection algorithms for around
> FIFTY years.

Yes much longer than 10 years, was more thinking of discussions on usenet
(which I've followed since the early 80s).  You can often learn a lot about
a language just by looking at what people in the community spend most of
their time discussing (of course using it and being involved in the
community is better).  GC is a fascinating topic but one would have to
wonder whether lisp's dependence on prolific garbage generation is its
achilles heel.

> There is another memory management style that is often considered the
> opposite of garbage collection, but it isn't really the opposite.  That
> style is to let memory leak when programmers make mistakes in
> their careful
> control of memory allocation and deallocation.  Now in fact, I
> almost favor
> this style.  I like efficiency, and I think that programmers should free
> memory when they know that they don't need it any more, instead of waiting
> for big time-consuming collectors to clean up their messes.

Though this posting might have mislead, I favor GC over direct alloc/dealloc
for most envs.  Only issue is choosing a lang/env where the volume of
garbage generated is manageable [define this based on your performance and
memory constraints].  Though lisp is a beautiful language (one of my
favorites functional languages), implementations that I used definitely had
garbage/GC issues.  Of course this is not so simple, it also depends on your
code, choice of env, etc.

Ultimately think lisp deserves a look if you don't need performance down to
the wire.  The bit you may loose in performance is amply compensated by the
flexibility and beauty of the language.  Not to mention good idea to think
in the functional lang mindset for a while if you haven't had exposure
before.

The other factor is that building applications in languages like C and C++
requires a lot more effort and debugging (IMO).  Higher-level languages (or
just languages with better design paradigms) make you and a development team
much more productive (and tend to produce better end results).


>
> If you look carefully, you'll even find some languages that force
> all array
> indices to start at 0, some that let the programmer specify the starting
> index, and some that don't even let the programmer specify
> multidimensional
> arrays in a clean, obvious, readable, reliable manner.  After FIFTY years.

Yeah, but some of those languages which let you set the start index are also
pretty scary (ADA for instance).  As for readability, definitely in the eye
of the beholder.  For me perl or php is unreadable, python readable, lisp
readable (if you wrote it), java readable ...

JS