C
Christos TZOTZIOY Georgiou
This amount of input/output should be a responsibility of the operating
system.
This amount of input/output should be a responsibility of the operating
system.
A
Alex Martelli
Andrew said:
Your point is very well taken, and I should have made it myself; Kuhn's
"Structure of Scientific Revolutions" applies to maths just as well as to
other sciences (even though I wasn't aware of your specific reference --
and I'm ordering it right now
.But, there's more: maths is emphatically NOT only done by mathematicians;
and the favourite languages and notations used by other scientists and
technicians to speak maths *often differ by field*, all the way down to
silly little lexical quibbles such as using j or i to denote sqrt(-1) .
So, even if software WAS mostly about maths, rather than mostly about
interactions among human beings, this *still* wouldn't suggest that a single
programming language "good for all uses" should be adopted instead of
following a "horses for courses" approach.
Alex
C
Cameron Laird
.
.
.
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 "foundations".
There's a wide, wide divergence between the intuitionism
working mathematicians practice, and the formalism they
profess.
'Good thing, too; our age enjoys the blessing of superb
mathematicians, and I'm relieved that philosophical in-
consistencies don't (appear to) slow them down.
D
David C. Ullrich
Well, since you crossposted this to sci.math you must be hoping
for replies from that direction:
Actually "inuitionism" has a certain technical meaning,
and actual intuitionism is not what most mathematicians
practice. But never mind, I believe I know what you meant.
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?
What's an actual example of one of those philosophical
inconsistencies that luckily doesn't slow us down?
************************
David C. Ullrich
for replies from that direction:
Actually "inuitionism" has a certain technical meaning,
and actual intuitionism is not what most mathematicians
practice. But never mind, I believe I know what you meant.
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?
What's an actual example of one of those philosophical
inconsistencies that luckily doesn't slow us down?
************************
David C. Ullrich
A
Alex Martelli
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.
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
A
Alex Martelli
Jon S. Anthony wrote:
...
Is it a good thing that you can define "bombs waiting to go off"?
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
...
Is it a good thing that you can define "bombs waiting to go off"?
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
A
Alex Martelli
Doug Tolton wrote:
...
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").
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.
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
...
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").
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.
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
A
Andrew Dalke
Alex Martelli:
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.
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
(e-mail address removed)
But is it a sense of security or real security? Hmm....
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.
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
(e-mail address removed)
But is it a sense of security or real security? Hmm....
V
Ville Vainio
Alex Martelli said:
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.
A
Andrew Dalke
Alex Martelli:
Having two roughly equivalent ways to do something apparently
leads to death by starvation of many a philosopher, unable to
acquire a fork.
Andrew
(e-mail address removed)
Having two roughly equivalent ways to do something apparently
leads to death by starvation of many a philosopher, unable to
acquire a fork.
Andrew
(e-mail address removed)
P
Pascal Costanza
Alex said:
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.)
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
A
Alex Martelli
Jon S. Anthony wrote:
...
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.
I care about "mode of expression" when I write poetry. When I write
programs, I care about simplicity, clarity, directness.
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!-)] ]]
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
...
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.
I care about "mode of expression" when I write poetry. When I write
programs, I care about simplicity, clarity, directness.
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!-)] ]]
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
A
Alex Martelli
Andrew Dalke wrote:
...
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
...
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
P
Pascal Costanza
Alex said:
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
A
Andrew Dalke
Pascal Costanza:
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.)
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")?
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."
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.
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.)
Except for my standard tasks in bioinformatics and chemical
informatics.
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.
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
(e-mail address removed)
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.)
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")?
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."
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.
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.)
Except for my standard tasks in bioinformatics and chemical
informatics.
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.
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
(e-mail address removed)
K
Kenny Tilton
Andrew said:
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.
L
Lulu of the Lotus-Eaters
|Easy pop quiz: of the designers of the languages Perl and Python,
|which one was born in South California, which one in the
|Netherlands...;-?
Sure... you reckon Larry Wall will move to Amsterdam now?
|which one was born in South California, which one in the
|Netherlands...;-?
Sure... you reckon Larry Wall will move to Amsterdam now?
D
Dave Benjamin
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
P
Pascal Costanza
Andrew said:
Yes, we disagree in this regard.
I am no expert in quantum computing, so I can't comment on that.
However, you have mentioned that someone has implemented an quantum
extension for Perl - and if that's possible then you can safely bet that
it's also possible in pure Lisp.
I believe that non-professional are more capable than most of us seems
to think. Furthermore, it has been suggested more than once that a valid
working model is that a good Lisp programmer can provide a
domain-specific language for the non-professional programmer. It's very
likely that a DSL matches better the needs of the user than some
restricted general-purpose language.
Ah, but then you need to constantly change the syntax and need to
remember the idiosyncrasies of several languages.
I am not so sure whether this is a good idea. Personally, I prefer not
to think about syntax anymore. It's boring. But that's maybe just me.
I don't know. I have to ask my vendor. ;-)
If it's only a syntactical issue, then it's a safe bet that you can add
that to the language. Syntax is boring.
Sounds like a possible application for the CLOS MOP.
Except for my standard tasks in bioinformatics and chemical
informatics.
Again, I don't know. You don't really expect me to know everything about
any conceivable field of computer science, do you?
You have forgotten the stupid politicians who go to war because it makes
them look better on television. No, I don't feel comfortable to depend
on them.
Seriously, I haven't invented this analogy, I have just tried to answer
a rhetorical question by Alex in a non-obvious way. Basically, I think
the analogy is flawed.
Pascal
P
prunesquallor
Pascal Costanza said:
The smartest programmers I know all prefer Lisp (in some form or
another). Given that they agree on very little else, that's saying
a lot.