Python syntax in Lisp and Scheme

[Cameron Laird]

Science is a human activity (was: Python syntax in Lisp and Scheme)

In article <QAJhb.6667$dn6 .5852@newsread4 .news.pas.earth link.net>,
Andrew Dalke <adalke@mindspr ing.com> wrote:[color=blue]
>Alex Martelli:[color=green]
>> would you kindly set right the guys (such as your
>> namesake) who (on c.l.lisp with copy to my mailbox but not to here) are
>> currently attacking me because, and I quote,
>> """
>> Software is a department of mathematics.
>> """[/color]
>
>And anyone who doesn't think mathematics has its own
>culture with ideas and even mistaken preferences for what
>is right and wrong should read
>
>The Mystery of the Aleph: Mathematics, the Kabbalah, and the Human Mind
>
>to see how Cantor's ideas of transfinite numbers (and other ideas,
>as I recall, like showing there are functions which are everywhere
>continuous and nowhere differentiable) were solidly rejected by
>most other mathematicians of his time.
>
>Mathematicia ns are people as well.[/color]

[David C. Ullrich]

Re: Science is a human activity (was: Python syntax in Lisp and Scheme)

On Sat, 11 Oct 2003 14:21:32 -0000, claird@lairds.c om (Cameron Laird)
wrote:

Well, since you crossposted this to sci.math you must be hoping
for replies from that direction:
[color=blue]
>In article <QAJhb.6667$dn6 .5852@newsread4 .news.pas.earth link.net>,
>Andrew Dalke <adalke@mindspr ing.com> wrote:[color=green]
>>Alex Martelli:[color=darkred]
>>> would you kindly set right the guys (such as your
>>> namesake) who (on c.l.lisp with copy to my mailbox but not to here) are
>>> currently attacking me because, and I quote,
>>> """
>>> Software is a department of mathematics.
>>> """[/color]
>>
>>And anyone who doesn't think mathematics has its own
>>culture with ideas and even mistaken preferences for what
>>is right and wrong should read
>>
>>The Mystery of the Aleph: Mathematics, the Kabbalah, and the Human Mind
>>
>>to see how Cantor's ideas of transfinite numbers (and other ideas,
>>as I recall, like showing there are functions which are everywhere
>>continuous and nowhere differentiable) were solidly rejected by
>>most other mathematicians of his time.
>>
>>Mathematician s are people as well.[/color]
> .
> .
> .
>And let no one assume that these are mere foibles of the
>past that we moderns have overcome; mathematics remains
>stunningly incoherent in what's labeled "foundation s".
>There's a wide, wide divergence between the intuitionism
>working mathematicians practice,[/color]

Actually "inuitionis m" has a certain technical meaning,
and actual intuitionism is not what most mathematicians
practice. But never mind, I believe I know what you meant.
[color=blue]
>and the formalism they
>profess.[/color]

Far be it from me to insist we've overcome the foibles
of the past. But:

It's certainly true that mathematicians do not _write_
proofs in formal languages. But all the proofs that I'm
aware of _could_ be formalized quite easily. Are you
aware of any counterexamples to this? Things that
mathematicians accept as correct proofs which are
not clearly formalizable in, say, ZFC?
[color=blue]
>'Good thing, too; our age enjoys the blessing of superb
>mathematicians , and I'm relieved that philosophical in-
>consistencie s don't (appear to) slow them down.[/color]

What's an actual example of one of those philosophical
inconsistencies that luckily doesn't slow us down?

*************** *********

David C. Ullrich

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

prunesquallor@c omcast.net wrote:
...[color=blue][color=green][color=darkred]
>>> A single web browser?[/color]
>>
>> I far prefer to have on my cellphone one that's specialized for its small
>> screen and puny cpu/memory, and on more powerful computers, more
>> powerful browsers. Don't you?[/color]
>
> Cellphone? Why on earth would I want one of those?[/color]

Why would you want a cellphone, or why would you want a browser on it?
As for the former, many people I know first got their cellphones because
their parents were old and sick, and they wanted to be sure their parents
could immediately get in touch with them in case of need. Of course, not
knowing you at all, I can't tell whether you're an orphan, or have parents
who are young and healthy, or don't care a whit about their being able to
reach you -- whatever. Once you do have a cellphone for whatever reason,
why not get more use out of it? Checking whether reports for wherever
you're traveling to, etc, etc -- a browser's a decent way to do many such
things.

[color=blue][color=green][color=darkred]
>>> A single operating system?[/color]
>>
>> On my cellphone all the way to the datacenter?[/color]
>
> A cellphone with an OS?! The phone I use is implemented
> with *wires*.[/color]

Forget cellphones then, and let's check if we DO want a single operating
system over a huge range of computers serving enormously different
tasks, as Microsoft is so keen to tell us, or not.

What do I want of the OS running my firewall? Security, security, security.
It's nice if it can run on very scant resources, offers solid and usable
packet filtering, and has good, secure device drivers available for the
kind of devices I may want in a computer dedicated to firewalling -- all
sorts of ethernet cards, wifi thingies, pppoe and plain old ppp on ISDN for
emergency fallback if cable service goes down, UPS boxes, a serial console
of course, perhaps various storage devices, and that's about it.

I see no reason why I should use anything but OpenBSD for that. Right now
I'm running it, for a LAN of half a dozen desktops and 2-5 laptops, on an
old scavenged Pentium-75, 32MB RAM, 1GB disk ISA machine, and it's got so
many resources to spare that I ended up running services aplently on it too
(DHCP, DNS, ntp, Squid for proxying, ...).

What do I want of the OS running my desktop? Resources are not a real
problem, since throwing CPU cycles, RAM, and disk at it is so dirt-cheap.
Some security, just enough to avoid most of the pesky worms and viruses
going around. Lots and LOTS of apps, and lots and LOTS of drivers for all
sort of cool devices for video, audio, and the like. Linux is pretty good
there, though I understand Windows can be useful sometimes (drivers
aren't yet available for _every_thing under Linux) even though security is
awful there, and MacOS/X would be cool was it not for HW cost. For a small
server? Resources should not be eaten up by the OS but available for
serving the rest of the LAN -- lots of free server-side apps & proxies --
security important, device drivers so-so -- I can see either Linux,
OpenBSD, or FreeBSD being chosen there.

A LARGE server, were I to need one? A Linux cluster, or an IBM mainframe
able to run Linux at need on virtual machines, sound better then.

A laptop? A palmtop? Linux may cover some of those (I do enjoy it on my
Zaurus) but is really too demanding for the cheapest palmtops -- and I
still can't get good sleep (as opposed to hybernate) from it on laptops
with ACPI.

What about the several computers in my car? They play very specialized
roles and would get NO advantages from general-purpose OS's -- and on
the other hand, most of them REALLY need hard real-time OS's to do their
jobs. I think not even MS tries to push Windows into most of THOSE
computers -- it would be just too crazy even for them.

So, in practice, I'd never go with the same OS on ALL computers. What
is most needed on computers playing such widely different roles is just
too different: an OS trying to cover ALL bases would be so huge, complicated
and unwieldy that its security AND general bugginess would suck (please
notice that Windows is the only OS really trying, even though not really on
anywhere near the WHOLE gamut -- with Linux admittedly close behind;-).


Alex

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Jon S. Anthony wrote:
...[color=blue]
> bombs waiting to go off since they have long standing prior meanins
> not in any way associated with this type of operation. OTOH, if you
> really wanted them, you could define them.[/color]

Is it a good thing that you can define "bombs waiting to go off"?

[color=blue][color=green]
>> Python's reply "There should be one-- and preferably only one --
>> obvious way to do it."[/color]
>
> This then is probably the best reason to _not_ use Python for anything
> other than the trivial. It has long been known in problem solving
> (not just computation) that multiple ways of attacking a problem, and
> shifting among those ways, tends to yield the the better solutions.[/color]

One, and preferably only one, of those ways should be the obvious one,
i.e., the best solution. There will always be others -- hopefully they'll
be clearly enough inferior to the best one, that you won't have to waste
too much time considering and rejecting them. But the obvious one
"may not be obvious at first unless you're Dutch".

The worst case for productivity is probably when two _perfectly
equivalent_ ways exist. Buridan's ass notoriously starved to death in
just such a worst-case situation; groups of programmers may not go
quite as far, but are sure to waste lots of time & energy deciding.


Alex

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Doug Tolton wrote:
...[color=blue][color=green]
>> You are correct. I misremembered "Tolton" as "Tilton" and confused
>> you with someone else. *blush*[/color]
>
> Heh, yeah I've noticed that a couple of times. Poor Kenny keeps getting
> blamed for things I've said. D'oh![/color]

That's clearly you lispers' fault for not having "preferably only one
obvious [i.e. widely different] way to spell your names". (Admittedly,
in the Python world we run into similar issues with the name "Tim").

[color=blue][color=green]
>> As for a language feature which should never be used. Alex Martelli
>> gave an example of changing the default definition for == between
>> floats, which broke other packages, and my favorite is "OPTION
>> BASE 1" in BASIC or its equivalent in Perl and other langauges.[/color][/color]

APL had that too (quad-IO, if I recall correctly) as well as the ability
to tweak comparison tolerance for numbers. Eeek, to say the least.
[color=blue][color=green]
>> That is, on a per-program (or even per-module) basis, redefine
>> the 0 point offset for an array.[/color]
>
> Again, I can see setting corporate wide policies that specify if you
> change the OPTION BASE, we are going to take you out behind the shed and
> beat you silly. I don't think the existence of OPTION BASE is a
> problem, personally I think it's when someone decides they want to
> change the OPTION BASE to 0 while everyone else is still using 1. That
> doesn't necessarily imply that OPTION BASE is by itself and evil
> construct.[/color]

A third-party package is quite likely to assume SOME specific setting
of quad-IO, OPTION BASE, or other such global setting. By providing
such global settings, therefore, the language is inherently restricting your
abilities to reuse third-party code seamlessly and in full respect of
the 'open-closed principle'. Complicating a language to ensure that its use
will split into mutually incompatible dialects seems truly evil to me. In
practice, any sufficiently complex language does in practice "get
subsetted" by different groups using it, but at least, without global
settings threading on each other's toes, you can still _re-use_ third party
code (although perhaps not practically _maintain_ it, if it uses a subset
or style too different from what your own development group uses).


Alex

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Alex Martelli:[color=blue]
> What do I want of the OS running my firewall? Security, security,[/color]
security.[color=blue]
> It's nice if it can run on very scant resources, offers solid and usable
> packet filtering, and has good, secure device drivers available for the
> kind of devices I may want in a computer dedicated to firewalling -- all
> sorts of ethernet cards, wifi thingies, pppoe and plain old ppp on ISDN[/color]
for[color=blue]
> emergency fallback if cable service goes down, UPS boxes, a serial console
> of course, perhaps various storage devices, and that's about it.
>
> I see no reason why I should use anything but OpenBSD for that.[/color]

I'm running a Linksys box as my primary firewall. I like the feeling of
security that the OS is in firmware and can't be updated (I hope) except
through the USB connector. I like that the box is portable (I've taken
it to a couple of conferences), low power (I leave it on all the time), and
quiet.

I do have a network -> dialup box as well when I needed to do dialup
to one of my clients, but I've not needed that feature as a backup
to my DSL in over a year.
[color=blue]
> (DHCP, DNS, ntp, Squid for proxying, ...).[/color]

It does DHCP but not the rest. Would be nice, but I would prefer
those features to be on this side of my firewall. Yes, I know about
OpenBSD's "only one remote hold in the default install, in more
than 7 years" claim to fame.

Andrew
dalke@dalkescie ntific.com

But is it a sense of security or real security? Hmm.... :)

[Ville Vainio]

Nazis (was Re: Python syntax in Lisp and Scheme

Alex Martelli <aleaxit@yahoo. com> writes:
[color=blue]
> I may feel a bit pessimistic at this point, but after the huge amount of
> time devoted to this thread and the tiny ROI, I think that's justified!-)[/color]

Speaking of which, has anyone been compared with the nazis in this
thread yet? I saw the first post of this thread, before the
conversation had escalated, and saw that it was a crosspost between
c.l.py and c.l.l... the first thought in my mind was "here we go
again". Looks like I wasn't wrong.

Mark my words, Lisp will rise again. And it will run great on Amiga.

--
Ville Vainio http://www.students.tut.fi/~vainio24

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Alex Martelli:[color=blue]
> The worst case for productivity is probably when two _perfectly
> equivalent_ ways exist. Buridan's ass notoriously starved to death in
> just such a worst-case situation; groups of programmers may not go
> quite as far, but are sure to waste lots of time & energy deciding.[/color]

Having two roughly equivalent ways to do something apparently
leads to death by starvation of many a philosopher, unable to
acquire a fork.

Andrew
dalke@dalkescie ntific.com

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:[color=blue]
> Jon S. Anthony wrote:
> ...
>[color=green]
>>bombs waiting to go off since they have long standing prior meanins
>>not in any way associated with this type of operation. OTOH, if you
>>really wanted them, you could define them.[/color]
>
>
> Is it a good thing that you can define "bombs waiting to go off"?[/color]

Yes.
[color=blue][color=green][color=darkred]
>>>Python's reply "There should be one-- and preferably only one --
>>>obvious way to do it."[/color]
>>
>>This then is probably the best reason to _not_ use Python for anything
>>other than the trivial. It has long been known in problem solving
>>(not just computation) that multiple ways of attacking a problem, and
>>shifting among those ways, tends to yield the the better solutions.[/color]
>
>
> One, and preferably only one, of those ways should be the obvious one,
> i.e., the best solution. There will always be others -- hopefully they'll
> be clearly enough inferior to the best one, that you won't have to waste
> too much time considering and rejecting them. But the obvious one
> "may not be obvious at first unless you're Dutch".[/color]

Python probably really offers a good selection of features suited for
particular problems. But it is very unlikely that it provides the right
set of features for all conceivable problems. To put it in a provocative
way, Python is a domain-specific language for vaguely defined domains -
those that GvR (subconsciously ?) had in mind when he designed the language.

I am pretty sure that Python is an excellent language for a lot of tasks
- otherwise it wouldn't be used by that many people even though it
didn't have a massive budget as Microsoft and Sun can provide for their
pet languages.

But on the other hand, it is also clear that for unknown domains yet to
be explored you cannot know the best set of features in advance _by
definition_.

Here is a conjecture - I am not sure myself whether it is true, but
anyway: The choice for a particular language is _always_ driven by a
wish for safety. What the various languages provide are different
perspectives on safety.

Pythonistas are probably driven by the assumption that the language
designers have found the best language feature for any task that might
arise. And even if they are not optimal in some cases, they at least
help to better understand the code of each other. This makes them feel
safe. (And these assumptions might even be true for 90% of the tasks
that arise in the domains in which Python is actually used.)

Lispniks are driven by the assumption that there is always the
unexpected. No matter what happens, it's a safe bet that you can make
Lisp behave the way you want it to behave, even in the unlikely event
that something happens that no language designer has ever thought of
before. And even if you cannot find a perfect solution in some cases,
you will at least be able to find a good approximation for hard
problems. This makes them feel safe. (And the large libraries provided
with Common Lisp and some Scheme systems still cover 90% of the standard
tasks.)
[color=blue]
> The worst case for productivity is probably when two _perfectly
> equivalent_ ways exist. Buridan's ass notoriously starved to death in
> just such a worst-case situation; groups of programmers may not go
> quite as far, but are sure to waste lots of time & energy deciding.[/color]

No, the worst case for productivity is when no way exists.

Yes, it is good thing that a language enables you to "define bombs
waiting to go off", because this means that you can also define
solutions for your unexpected problems.


Pascal

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Jon S. Anthony wrote:
...[color=blue][color=green][color=darkred]
>> > Can someone write a nifty Python hack to figure out how many times
>> > Lispniks have tried to get Alex to explain how macros are any different
>> > than high-order functions or new classes when it comes to The
>> > Divergence Problem? I love that we have given it a name, by the way.[/color]
>>
>> The very 'feature' that was touted by Erann Gat as macros' killer
>> advantage in the WITH-CONDITION-MAINTAINED example he posted is the
>> crucial difference: functions (HO or not) and classes only group some
>> existing code and data; macros can generate new code based on examining,
>> and presumably to some level *understanding* , a LOT of very deep things
>> about the code arguments they're given.[/color]
>
> Are you really this dense? For crying out loud - functions can
> generate code as well and just as easily as macros. In fact macros
> are just functions anyway so it really should go without saying.[/color]

These assertions may hold in your favourite corner of the world, but
they surely don't in mine. So, cry out just as loud as you want, and
keep insulting me at will, but you will hardly change my opinion: functions
_compute and return a result_ (which may be another function, but that's a
detail) -- they cannot in any way break nor bend the syntax of the language
[in non-pure-FP languages, including Python and lisp, functions can also
have side effects, but that's another debate -- since c.f.programming is
not in the list of groups targeted by this sub-sub-thread we probably don't
need to pursue it]. Macros can. Even Gat asserts that "in MOST cases" the
divergent language one builds with macros is a superset of lisp -- which
means it needs not be. Without macros, you cannot alter the syntax and
make the language in which you embed your functions a different one,
perhaps not even a superset of the one you started with. You can of
course implement a _separate_ language (hey, most language implementations
around today are probably coded in C, even for languages that have nothing
at all to do with C), but that's quite different from mixing language and
meta-language freely.

[color=blue][color=green]
>> If all you do with your macros is what you could do with HOF's,
>> it's silly to have macros in addition to HOF's -- just[/color]
>
> No it isn't, because they the mode of _expression_ may be better with
> on in context A and better with the other in context B.[/color]

I care about "mode of expression" when I write poetry. When I write
programs, I care about simplicity, clarity, directness.

[color=blue][color=green]
>> MTOWTDItis encouraging multiple different approaches to solve any given
>> problem -- this, of course, in turn breeds divergence when compared to a[/color]
>
> Actually it breeds better solutions to problems. If you don't
> understand this, you will never understand much of anything about good
> problem solving.[/color]

Right: that's why I'm a decently-paid consultant and in my spare time write
best-selling-in-niche books -- because I don't understand much of anything
about good problem solving. Flailing around between a zillion divergent
approaches is clearly the One True Way of problem-solving: that's why
perl, which glorifies that multiplicity, r00lez, right?

Meanwhile, while the perl-using team is halfway through the heated debate
among the bazillion oh-so-EVER-clever and dazzling ways, the plodding,
pragmatical, simplicity-oriented python-using team has delivered a clear,
simple, maintainable solution and is well on its way towards the next one.

Easy pop quiz: of the designers of the languages Perl and Python, which
one was born in South California, which one in the Netherlands...;-? [more
later about such geography-based stereotypes...]

Downside: nobody really gets entitled to feel smarter-than-thou for having
unearthed a solution so obscure it had escaped all the others; if you're in
the programming game for ego-boosting, a cleverness-requiring language
with a built-in competition for "stardom" may suit you better. If you're
into it to actually solve problems, egoless programming may be ok, though.

[[ back to stereotypes: now, lisp is clearly in-between, its designer being
from Massachussets. And just for a little self-satire -- if a language had
an _Italian_ designer, it probably would be little use for _programming_,
though it would likely be good for cuisine, fashion, major-scale graft, and
seducing beautiful women [though come to think of it, I didn't do all that
badly with Python on the latter -- Hi Anna!-)] ]]

[color=blue][color=green]
>> Oh, and if you're one of those who disapprove of Gat's example feel free
>> to say so, but until I hear a substantial majority denouncing it as
>> idiotic[/color]
>
> At the moment the only thing I am willing to denounce as idiotic are
> your clueless rants.[/color]

Excellent! I interpret the old saying "you can judge a man by the quality
of his enemies" differently than most do: I'm _overjoyed_ that my enemies
are the scum of the earth, and you, sir [to use the word loosely], look as
if you're fully qualified to join that self-selected company.


Alex

[Alex Martelli]

Re: Python syntax in Lisp and Scheme

Andrew Dalke wrote:
...[color=blue]
> Of the 6 languages there are two major misorderings.
> First, C actually ended up easier to use than Java or C++.
> (which is strange since you would think C++ would be
> at least as good as C), and second, Tcl actually ends up
> much better.[/color]

Personally, I'm not surprised that, for a sufficiently simple
problem, C's simplicity makes its users more productive
than the users of (particularly) C++ in all of its glory. Sure,
the C solution might have been adopted in C++, but once
having gone to the trouble to learn a 10-times-bigger language,
the temptation is obvious to strive and find ways use SOME of
those extra 9 helpings, no?-)


Alex

[Pascal Costanza]

Re: Python syntax in Lisp and Scheme

Alex Martelli wrote:
[color=blue]
> Jon S. Anthony wrote:
> ...
>[color=green][color=darkred]
>>>>Can someone write a nifty Python hack to figure out how many times
>>>>Lispniks have tried to get Alex to explain how macros are any different
>>>>than high-order functions or new classes when it comes to The
>>>>Divergenc e Problem? I love that we have given it a name, by the way.
>>>
>>>The very 'feature' that was touted by Erann Gat as macros' killer
>>>advantage in the WITH-CONDITION-MAINTAINED example he posted is the
>>>crucial difference: functions (HO or not) and classes only group some
>>>existing code and data; macros can generate new code based on examining,
>>>and presumably to some level *understanding* , a LOT of very deep things
>>>about the code arguments they're given.[/color]
>>
>>Are you really this dense? For crying out loud - functions can
>>generate code as well and just as easily as macros. In fact macros
>>are just functions anyway so it really should go without saying.[/color]
>
>
> These assertions may hold in your favourite corner of the world, but
> they surely don't in mine. So, cry out just as loud as you want, and
> keep insulting me at will, but you will hardly change my opinion: functions
> _compute and return a result_ (which may be another function, but that's a
> detail) -- they cannot in any way break nor bend the syntax of the language
> [in non-pure-FP languages, including Python and lisp, functions can also
> have side effects, but that's another debate -- since c.f.programming is
> not in the list of groups targeted by this sub-sub-thread we probably don't
> need to pursue it]. Macros can. Even Gat asserts that "in MOST cases" the
> divergent language one builds with macros is a superset of lisp -- which
> means it needs not be. Without macros, you cannot alter the syntax and
> make the language in which you embed your functions a different one,
> perhaps not even a superset of the one you started with. You can of
> course implement a _separate_ language (hey, most language implementations
> around today are probably coded in C, even for languages that have nothing
> at all to do with C), but that's quite different from mixing language and
> meta-language freely.[/color]

Macros are localized. When you see something like this:

(with-whatever ...
...)

You can be pretty sure that the effect of the macro spans only the
extent of that macro.

This is similar to what you can do with local functions:

(flet ((print (x) ...))
...)

Now, in the scope of that local definition, the previously defined print
function gets a new meaning.

Nothing breathtaking going here in both examples.


Does Python allow local function definitions? Can they shadow predefined
functions?


Pascal

[Andrew Dalke]

Re: Python syntax in Lisp and Scheme

Pascal Costanza:[color=blue]
> To put it in a provocative
> way, Python is a domain-specific language for vaguely defined domains -
> those that GvR (subconsciously ?) had in mind when he designed the[/color]
language.

But by the same vein, is not Lisp is a domain-specific language for
vaguely defined domains? You say that's because Lisp can be used
for all domains. My continued response is that it's not optimal for all
domains. (Also, in another post I conjectured that a thoeretical
quantum computing 'Lisp' may have features for manipulating ensembles
of structures, in ways inappropriate to current Lisps.)
[color=blue]
> But on the other hand, it is also clear that for unknown domains yet to
> be explored you cannot know the best set of features in advance _by
> definition_.[/color]

I'll agree with that. So why should Lisp, designed in the 1950s,
provide the best set of features (and I include more than semantic
abilities) for situations unenvisioned half a centry later (eg, the concept
of a "non-professional programmer")?
[color=blue]
> Pythonistas are probably driven by the assumption that the language
> designers have found the best language feature for any task that might
> arise.[/color]

Not at all. When I need language features best found in C (using
shared memory, or memory mapped I/O), I use C; perhaps called
from Python.

Were I to need logic programming, I would use at least consider
Prolog, with bindings like AmziPy or PyProlog, or cousins like
the Python/CLIPS interface.

(Most of the time though, I need libraries. Eg, calling out to a
Fortran binary, using 'web services', CORBA, or even, when
I need browser applet features best found in Java, I use Python
in its Jython incarnation.)

The phrase I'm trying to push is "multiple language paradigm;
not multiple paradigm language."
[color=blue]
> Lispniks are driven by the assumption that there is always the
> unexpected. No matter what happens, it's a safe bet that you can make
> Lisp behave the way you want it to behave, even in the unlikely event
> that something happens that no language designer has ever thought of
> before.[/color]

Ahh, but that assumes that behaviour is the only important thing
in a language. I disagree with that assumption, and that difference
in belief is one of the core reasons this thread has gone on so long.
[color=blue]
> And even if you cannot find a perfect solution in some cases,
> you will at least be able to find a good approximation for hard
> problems.[/color]

So, umm, how does Lisp handle shared memory? Can I, as
with C++, say that certain objects/data structures are to be
allocated from a block of shared memory rather than the standard
memory arena? What's the way to do I/O through a
memory-mapped port as on an old DOS machine?

Python cannot do the first, excepted in limited cases using
extensions written in C/C++, which is also how to handle
the second case.

I'm not saying that Lisp doesn't handle support for allocation
from multiple arenas; my searches showed many examples
of using Lisp on shared memory parallel machines. However,
given my understanding of the language, it isn't obvious how
that's done. By comparison, C++ has syntax support for
letting an class define the allocator for an instance and its
standard templates also take an optional memory allocator.

(Background on when I used C++'s per-class allocators. I
was writing software for the CAVE, an immersive virtual
reality system. Each wall of the CAVE is driven by a
different CPU. The main software driving the visualization
runs on yet another CPU, and uses high-speed shared
memory to update the model viewed by the display CPUs.
It was easy to support; I made a new subclass for the
model data structures, with an allocator which used the
shared memory arena. I then made a new container (this
was pre STL) for storing those objects. A few library
calls and it was working.)
[color=blue]
> This makes them feel safe. (And the large libraries provided
> with Common Lisp and some Scheme systems still cover 90% of the standard
> tasks.)[/color]

Except for my standard tasks in bioinformatics and chemical
informatics. ;)
[color=blue][color=green]
> > The worst case for productivity is probably when two _perfectly
> > equivalent_ ways exist. Buridan's ass notoriously starved to death in
> > just such a worst-case situation; groups of programmers may not go
> > quite as far, but are sure to waste lots of time & energy deciding.[/color]
>
> No, the worst case for productivity is when no way exists.[/color]

When there are two perfectly equivalent ways to do something,
people may be stuck in "analysis lock" trying to figure out which
one to take. When there's no way to do something the answer is
to make a way -- which may be to use Lisp.

Here's a page on Buridan's ass

http://www.postmodernvillage.com/eastwest/issue5/ftf05.html

] The theory often referred to as "Buridan's ass" states that, when
] given the option of two equally wonderful piles of hay, the ass
] will starve to death because it cannot choose. This concept was
] first discussed in writing by Aristotle, but has been in existence
] long before it was documented in writing

Stretching the analogy, if there was no solution (no hay), the ass
would keep on looking for food.
[color=blue]
> Yes, it is good thing that a language enables you to "define bombs
> waiting to go off", because this means that you can also define
> solutions for your unexpected problems.[/color]

Ahh, more analogies. Most people don't work in munitions
factories. While some are able to make their own bombs,
most are happy to relegate the task to professionals, and
depend on still others (the military) to deploy those bombs.

Andrew
dalke@dalkescie ntific.com

[Kenny Tilton]

Re: Python syntax in Lisp and Scheme



Andrew Dalke wrote:[color=blue]
> I'll agree with that. So why should Lisp, designed in the 1950s,
> provide the best set of features (and I include more than semantic
> abilities) for situations unenvisioned half a centry later (eg, the concept
> of a "non-professional programmer")?[/color]

Macros. :)

In On Lisp (the reason I am breaking my vow of silence on this thread)
Paul Graham shows how things like objects and prolog can be built out of
standard ANSI Lisp (without using the built-in CLOS, of course):

http://www.paulgraham.com/onlisp.html

And the synatx looks nice (important feature, right?) because of macros.

I am kicking myself for not simply referring everyone to Mr. Graham when
this thread (and its prior incarnation on clp alone) started. Graham
says it all, and says it better than I ever could.

That link includes a download of the whole book. Chapter 8 is called
"When to Use Macros".

Chapter 1 answers your quoted question above; it is called "The
Extensible Language". It includes discussion of why that is a Good
Thing, and not to be dreaded because of the concerns Alex (and other
Pythonistas have) over extending a language.


--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Dave Benjamin]

Re: Python syntax in Lisp and Scheme

In article <W5Zhb.7603$dn6 .620@newsread4. news.pas.earthl ink.net>, Andrew Dalke wrote:[color=blue]
>
> Here's a page on Buridan's ass
> http://www.postmodernvillage.com/eas...ue5/ftf05.html
> ] The theory often referred to as "Buridan's ass" states that, when
> ] given the option of two equally wonderful piles of hay, the ass
> ] will starve to death because it cannot choose. This concept was
> ] first discussed in writing by Aristotle, but has been in existence
> ] long before it was documented in writing
>
> Stretching the analogy, if there was no solution (no hay), the ass
> would keep on looking for food.[/color]

Maybe that's why, when confronted with two perfectly good languages, instead
of just picking one of them and writing some code, we instead must make
asses of ourself on long crossposted threads about the relative merits and
demerits of each other's hay.

hay-is-for-horses-ly y'rs - dave