Various Topics on Lisp

..sc.. ..stan..

Stefan Ram wrote:

> So, Lisp programmers nowadays have to look for other areas
> that make Lisp different from other languages. Often, I hear
> about macros in this regard. What is accomplished with macros
> roughly correspond to building special purpose languages,
> which might be implemented in other languages, too, when
> required. This might still be more effort than using Lisp-
> macros, but when the language is XML-based, tools to parse
> it to an object are already given.

See http://www.sdmagazine.com/do***ents/s=8993/sdm0405h/ in this context.


Pascal

--
Pascal Costanza University of Bonn
mailto:costanza@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

..m ..adsh..

Stefan Ram wrote:
> Macros, IIRC, where not present in historic variants
> of LISP, so the "Lisp-Difference" of today might have not
> much in common with the "LISP-Difference" of 30 years ago.

I'm not sure how old macros are (someone will know) but they must be
effectively as old as ***ps are - the moment you can easily read Lisp
sources with lisp and build a low-commitment structure, macros are
really only a tiny step away.

--tim

..m ..adsh..

Tayssir John Gabbour wrote:
>
> I'd be interested in knowing a little bit more about peoples'
> experiences working with lisp programmers.

I live in hope that the proportion that are recognisably human beings
is increasing (and it does seem to be). It's low enough for
programmers of any kind, of course, but Lisp programmers certainly
used to be well below average (although I suspect there are enormous
numbers of really, really, difficult programmers who I've been lucky
enough to avoid, in areas like functional programming).

--tim

..sc.. ..stan..

Tim Bradshaw wrote:

> Stefan Ram wrote:
>
>> Macros, IIRC, where not present in historic variants
>> of LISP, so the "Lisp-Difference" of today might have not
>> much in common with the "LISP-Difference" of 30 years ago.
>
> I'm not sure how old macros are (someone will know) but they must be
> effectively as old as ***ps are - the moment you can easily read Lisp
> sources with lisp and build a low-commitment structure, macros are
> really only a tiny step away.

I think the birthdate is October 1963:

Timothy Hart, MACRO Definitions for LISP, AIM-057

See ftp://publications.ai.mit.edu/ai-pub...499/AIM-057.ps

Pascal

--
Pascal Costanza University of Bonn
mailto:costanza@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)

..n.. ..lt..

Tim Bradshaw wrote:
> Tayssir John Gabbour wrote:
>
>>I'd be interested in knowing a little bit more about peoples'
>>experiences working with lisp programmers.
>
>
> I live in hope that the proportion that are recognisably human beings
> is increasing (and it does seem to be). It's low enough for
> programmers of any kind, of course, but Lisp programmers certainly
> used to be well below average

This is lousy science, and leads to the self-fulfilling decision against
using Lisp.

The right choice would have been to take the best of the java herd you
have over there, throw Lisp saddles on them and turn them into proper
ranch work horses: faster, more nimble, and better for trips into town
for R&R.

Lisp programmers tend to be (a) very good programmers and (b) "don't
fence me in" types. I guess they also come from academia for the most
part. What a prescripion for ***inity! Of course we are useless in a
group situation -- well, worse than useless because we are also
insubordinate and actively foment discontent and rebellion -- but that
is not because of the Lisp.

I mean, what about Lisp could possibly explain why I am such a jerk[1]?
destructuring-bind? eql specializers on generic methods? I have always
suspected VALUES...



kenny

[1] Actually I also like COBOL and C, so I can function in corporate
settings if my cubicle is sufficiently far from the others' and I am not
told about meetings.

k

..n.. ..lt..

Tim Bradshaw wrote:

> Chris Capel wrote:
>
>
>>I think this is a special case of the more general "Microsoft
>
> anxiety" that
>

> .... Programming language choice makes less
> difference than you might think, especially for large systems.
>
> For instance, I'm currently working on a fairly large e-commerce
> system: I think there are many tens (possibly several hundred)
> machines, multiple database backends, interfaces to many suppliers and
> so on. 90% of this is in Java. Arguably some benefit could be gained
> by using Lisp (especially now that there are good Lisp<->Java
> interfaces so it wouldn't be necessary to reimplement all the random
> database & other ****: existing and reasonably good Java APIs could be
> used for all the boring low-level stuff).
>
> However changing to Lisp would only solve a tiny part of the problems
> of this system. There are *much* more significant problems concerning
> configuration and release management, testing, reliability, coherent
> logging and auditing, debuggability, do***entation, replicability and
> so on. These problems are really nothing to do with language choice,
> they're just the standard `****ed up system' issues. In fact, my
> guess is that Lisp would make these problems *worse*.

Our rather hairy/huge clinical trial data management system excelled in
each of those areas precisely because we were using Lisp. I confess I
was surprised when, for example, the daunting
configuration/release/change management problem simply disappeared in
the face of some nifty Lisp created to solve an unrelated problem, so I
am not surprised you got this wrong.

kenny

--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

..le.. ..rtezaog..

>>>>> "TimB" == Tim Bradshaw <tfb+google@tfeb.org> writes:
Tayssir John Gabbour wrote:
>> I'd be interested in knowing a little bit more about peoples'
>> experiences working with lisp programmers.

TimB> I live in hope that the proportion that are recognisably
TimB> human beings is increasing (and it does seem to be).

Whoa. Huh? Maybe you could elaborate?

TimB> It's
TimB> low enough for programmers of any kind, of course, but Lisp
TimB> programmers certainly used to be well below average
TimB> (although I suspect there are enormous numbers of really,
TimB> really, difficult programmers who I've been lucky enough to
TimB> avoid, in areas like functional programming).

I wonder to what extent putting the net between programmers helps this?
I would ***ume truly difficult people, unless they had talent/luck to
compensate, would eventually have to reconsider their attitude due to
financial pressures. Probably not on a timescale of a single project
though. But then again, (applying one possible interpretation of the
'human' reference above to myself), if you don't spend much, a lucky
break does last a long time.

I'd like to hear more of this if you don't mind.

cheers,

BM

..n.. ..lt..

Stefan Ram wrote:

> "Tim Bradshaw" <tfb+google@tfeb.org> writes:
>
>>That being said, I think the whole `language supremacist' thing
>>that Lisp people are so keen on is really a bit of a red
>>herring. Well, a lot of a red herring in fact. Programming
>>language choice makes less difference than you might think,
>>especially for large systems.
>
>
> To me, it sometimes is amazing how the "Lisp-Difference" has
> changed. I mean, what makes Lisp or LISP different from the
> mainstream languages of its time.
>
> It used to be the garbage collector and the ease with which
> dynamic data structures, such as trees, can be built. What was
> called "AI programming" often needed such features.
>
> Nowadays, a mainstream language, such as Java, has support for
> garbage collection and several kinds of dynamic collections.

You are holding the wrong end of the spear. The above translates to
"Other languages are getting better as they painfully, slowly, halting
become more like Lisp". That just translates to "Lisp is better", and in
turn "Use Lisp".

>
> Then, LISP had support for a kind of literal of trees or
> graphs, i.e., S-expressions. So the datastructures could not
> only be programmed using lisp, but the constant data needed
> could also be written as S-expressions. Nowadays, XML is often
> used for the same purpose in Java, for example, to configure
> the tool "Ant", which fulfills a purpose similar to the UNIX
> "make" tool.

Whoa, nelly! How about writing source code qua ***prs?

>
> So, Lisp programmers nowadays have to look for other areas
> that make Lisp different from other languages.

One swallow does not a summer make. Copying GC or GFs or any detail does
not make Java into Lisp.

Often, I hear
> about macros in this regard. What is accomplished with macros
> roughly correspond to building special purpose languages,
> which might be implemented in other languages, too, when
> required. This might still be more effort than using Lisp-
> macros, but when the language is XML-based, tools to parse
> it to an object are already given.

Nah. The whole point of macros is that they are part of Lisp and written
in Lisp. This reminds me of Norvig's hand-waving when he tried to turn
regex parsing into Lisp macros because it could be used to create an
embedded language.

kenny


--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

..om.. ..hilli..

Pascal Costanza <costanza@web.de> wrote:

> See http://www.sdmagazine.com/do***ents/s=8993/sdm0405h/ in this context.

From the above article:

In Lisp, almost every position is evaluated, so, for a number
of years, Lisp macros used only evaluated-position tags. But
in the 1980s, the declare syntax was added, providing a
nonevaluated position for tags.

Huh? Declare syntax? There's also an image stating

(with-transaction
...)

being equivalant to

(declare transactional)
...

Never heard of this. Can someone explain?

..m ..adsh..

Kenny Tilton wrote:
> Our rather hairy/huge clinical trial data management system excelled
in
> each of those areas precisely because we were using Lisp. I confess I

> was surprised when, for example, the daunting
> configuration/release/change management problem simply disappeared in

> the face of some nifty Lisp created to solve an unrelated problem, so
I
> am not surprised you got this wrong.
>

I'd be interested to hear more about stuff to do, for instance,
configuration and deployment of systems that run across many machines
(including machine allocation, OS build, network configuration, test,
logging and so on) done in Lisp. If you have a system which will
actually do this, you should be out there getting seriously rich,
because it is *the* problem that people want to solve at the moment
(look at all the stuff on virtualisation / grid computing for
instance).

--tim