I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately. I'd like to know if it may
be possible to add a powerful macro system to Python, while
keeping its amazing syntax, and if it could be possible to
add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience. If the answer is yes,
would many Python programmers switch to Lisp or Scheme if
they were offered identation-based syntax?
Jul 18 '05
699  33241 
Daniel Berlin wrote:
... Libraries distributed as binaries are not portable across different
C++ implementations on the same machine (as a rule).
This isn't true anymore (IE for newer compilers).
Wow, that IS great news! Does it apply to 32-bit Intel-oid machines
(the most widespread architecture)
Yes, but not windows.
Aw:-(. Oh well, so much for the hope of easy extensibility of Python
on Windows by non-MS compilers:-(.
I'm not very familiar with Python on the Mac but I think it uses
another
commercial compiler (perhaps Metrowerks?), so I suspect the same
question may apply here.
It depends. I've built it with both.
I'm sure you can build Python with different compilers, but I was wondering
about the widely distributed pre-built version, the one Apple includes as
part of OS/X.
At least on Mac, Apple's gcc -fast is better than any other compiler
around, according to recent benchmarks.
Unsurprising to me, but i'm a gcc hacker, so i might be biased a bit. :P
Most, if not all, optimizations that commercial compilers implement are
or are being implemented in gcc for 3.5/3.6.
Great news. But I doubt that Python on Windows can simply drop the
use of MSVC++, anyway:-(.
Alex
Joe Marshall wrote:
... Do I want a single writing tool, or separate pencils, pens, markers,
highlighters...? Do I want a single notation to write down ANYthing
on paper, or separate ones for music, algebraic formulas, shopping
... A single web browser?
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?
A single editor?
I prefer to have one for text files, a separate one for video files, and
so on. Editing text and editing video have SO little in common...
A single operating system?
On my cellphone all the way to the datacenter? MS may dream about
that (even though all the "windows" versions they try to sell may have
in common only the name or little more), but it's definitely not my
preference -- I think the OS's for cellphones and those for powerful
servers have too little in common to be "a single OS" sensibly.
A single character encoding scheme?
Now that would be nice, IF one could get away with it. Unfortunately,
throwing away all of the gigabytes of text recorded as other than UCS-4
is definitely impractical, so we're doomed to live with several.
A single analogy?
Perish the thought -- the more the merrier.
Alex
Alex Martelli <al*****@yahoo.com> writes: Joe Marshall wrote:
... Do I want a single writing tool, or separate pencils, pens, markers,
highlighters...? Do I want a single notation to write down ANYthing
on paper, or separate ones for music, algebraic formulas, shopping ... A single web browser?
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?
Cellphone? Why on earth would I want one of those?
A single operating system?
On my cellphone all the way to the datacenter?
A cellphone with an OS?! The phone I use is implemented
with *wires*.
[narrowing down to c.l.l and c.l.p] pr***********@comcast.net writes: Significantly, AFAICT you can easily do this unambiguously and *locally*,
for example your editor can trivially perform this operation on cutting a
piece of python code and its inverse on pasting (so that you only
cut-and-paste the 'local' indentation). Prima facie I don't see how you
loose any fine control.
Only if your cut boundaries are at the same lexical level. If you cut
across boundaries, it is no longer clear what should happen at the paste.
The only unclarity would arise from dedents of more than one level on the
corner of your cut region, I think.
Also, it is frequently the case that you need to `tweak' the code after
you paste it.
Sure, but I don't generally feel that tweaking python code in emacs is
particularly inconvenient (it is not always as convenient as tweaking lisp
code, which is partly due to the fact that essentially there isn't any proper
implementation of the sexp commands for non-lisp modes; OTOH some operations
are more convenient).
You misunderstand me. In a python block, two expressions are
associated with each other if they are the same distance from the left
edge. This is isomorphic to having a nametag identifying the scope
of the line. Lines are associated with each other iff they have the
same nametag. Change one, and all must change.
Hardly a problem with a decent editor (and surely less of a problem even with
the proverbial notepad than getting the closing paren in the right spot and
reindenting everything).
because the grouping information is replicated on each line, I have to
fix this information in the six different places it is encoded:
Why, for example, not just first insert the new if statement and then run an
editor command that indents all the following lines up to the same indent
level one further indent level? To me this wouldn't seem to me have
intrisically more room for screw-ups than inserting a '(WHEN' and an
additional ')'.
The fact that the information is replicated, and that there is nothing
but programmer discipline keeping it consistent is a source of errors.
Sure there is. Your editor and immediate visual feedback (no need to remember
to reindent after making the semantic changes). I don't understand why this is any different to e.g. ')))))' in Lisp. The
closing ')' for DEFUN just looks the same as that for IF.
That is because the parenthesis *only* encode the grouping information,
they do not do double duty and encode what they are grouping.
The key here is to realize that the words `DEFUN' and the `IF' themselves
look very different.
Well, I'm evidently still not getting it, because my reply would be "and so do
'def ...:' and 'if ...:' in python" (and you also can't tell whether the 8
spaces on the left margin come from a 'def' and and an enclosed 'if' or vice
versa). Yet the visual representation is not only identical between all of these, it
cannot even be displayed.
I don't understand what you mean. Could you maybe give a concrete example of
the information that can't be displayed?
Sure. Here are five parens ))))) How much whitespace is there here:
10 spaces (which BTW I counted in emacs in just the same way that I'd count a
similar number of parens) -- but what has counting random trailing whitespace
got to do with anything? Apart from the fact that only leading whitespace is
significant in python, I've personally never felt any need to count it -- have
you? I have, however felt the need to count parens from time to time (in
python as well).
Still, I'm sure you're familiar with the following quote (with which I most
heartily agree):
"[P]rograms must be written for people to read, and only incidentally for
machines to execute."
People can't "read" '))))))))'.
Funny, the people you just quoted would disagree with you about parenthesis.
I expect that they would disagree with you about whitespace as well.
Why, do they know someone with a paren-counting brain-implant? If so every
lisper should get one -- no more carpal tunnel syndrome from frantic C-M-\
pressing or alphabet wastage due to scheme-style 'aliasing' of '[...]' to
'(...)'.
Seriously, I really fail to see see what the source of disagreement with the
above statement could be.
If I gave you a piece of lisp code jotted down on paper that (as those
hypothetical examples usually are) for some reason was of vital importance and
that on typing it in revealed a mismatch between the indentation and the
parenthesation in a key section of the code -- which interpretation would you
hedge your bets on in the absence of other indicators; the one suggested by
the indentation or the 9 trailing parens?
Anyway, readability is an overarching but not the only important factor in the
design of language's syntax (you mentioned the ergonomics of editing and there
are of course others), and as I said I think sexps are in fact a rather good
syntax for an expression oriented language.
'as
Kenny Tilton wrote:
Andrew Dalke wrote:
Kenny Tilton:
I wouldn't take the Greenspun crack too seriously. That's about
applications recreating Lisp, not languages copying Lisp features.
Are you stating that all references of Greenspun's 10th rule,
when applied to Python, are meant in jest?
Can't speak for others, but it certainly would be a mistake to apply it
to another HLL.
Python isn't doing that. It's lives in a perfectly good niche wherein
Lisp is not the most appropriate language.
OK, another Pythonista just told me GVR had greater ambitions. Just
tellin ya what I hear.
You presume that only Lisp gurus can learn Lisp because of the syntax.
Not at all. What I said is that Lisp gurus are self-selected to be
the ones who don't find the syntax to be a problem. You incorrectly
assumed the converse to be true.
No, I got that, but I just wrote it kinda convoluted. And that
self-selection thing is just silly, until people over here:
http://alu.cliki.net/Kenny's%20RtLS%20Top-Ten
...come back in a month and update their responses to say "Drat! That
language is every bit as great as I thought it was, but that syntax is
driving me nuts. I'm outtahere!"
Won't happen, btw. Hell, Tolton loved Lisp even before he picked up some
editing tips.
You know, I just remembered a relevant experience I had, only with a
very early release of Dylan during the search I conducted which led to
Common Lisp, aka The Promised Land.
I actually made a bug report to the Dylan team: "hey, when I hit tab the
cursor jumps way the hell out here, just inside the IF. I mean, that's
pretty fucking cool if you meant that to happen, but what's going on?"
:)
But methinks a number of folks using Emacs Elisp and Autocad's embedded
Lisp are non-professionals.
Methinks there are a great many more people using the VBA
interface to AutoCAD than its Lisp interface. In fact, my friends
(ex-Autodesk) told me that's the case.
Sheesh, who hasn't been exposed to basic? From my generation, that is.
:) But no matter, the point is anyone can handled parens if they try for
more than an hour.
What does it mean to be "a Lisp"? Is Python considered "a Lisp"
for some definitions of Lisp?
lessee:
symbols? no
sexprs? no
code as data as code? no
sorry, charlie.
You (Alex?) also worry about groups of programmers and whether what is
good for the gurus will be good for the lesser lights.
If you ever hear me call anyone who is not an expert programmer
a "lesser light" then I give you -- or anyone else here -- permission
to smack me cross-side the head.
Boy, you sure can read a lot into a casually chosen cliche. But can we
clear up once and for all whether these genius scientists are or are not
as good a programmer as you? I thought I heard Python being recommended
as better for non-professional programmers.
Mind you, to my horror my carefully trained goalie turned out not to
scale at all into game play (my fault) so i am back to square one with
two days to go, so maybe I am not following all this as well as I should.
I will admit getting those editing key strokes was pretty dang nice.
Although I have been doing my coding in Emacs all along. :)
--
Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
Alex Martelli wrote: Pascal Costanza wrote:
...
programming languages are NOT "mathematics", as some claim -- they
are engineering designs, and interact with human minds, sociology
of groups, cultural and educational features, at least as much as
they interact with the architecture and capabilities of computers.
I definitely agree. Computer science is more a sociological science than
a natural science IMHO.
Amen, hallelujah. So, since I've decided to limit my participation in this
thread to c.l.python, 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.
"""
...?
The context in which this statement was made is not clear to me, so I
don't know what I would actually defend.
I haven't followed all branches of the thread, and the posting that
contains that statement is a reaction to an analogy that I think is not
a good one. I don't want to dive further into this specific branch. Sorry.
Pascal
You are mostly correct about Japanese, I took a year of it in college
and it is a fairly standard SOV language. (Like Latin, oddly enough.)
And I'm sure you're right about RPN vs. PN, I always get those
confused. Which is kind of the point, really, having studied math
since I was a kid I got used to stuff like "y = mx + b", can you
blame me if I have an easier time with "y = m*x + b" as opposed to
"(let y (+ (* m x) b))" (Forgive me if the parenthesis on that are
off, the newsreader editor doesn't match them, and maybe I need a
'setq' instead of a 'let' or some other thing, I'm not entirely sure.)
(And again, is the point getting more clear?) And thanks for backing
me up on car's and cdr's, I never could understand why a language
ostensibly designed for 'list processing' has such a bizarre way to
reference items in a list. But is (nth 10 mylist) really as easy as
mylist[10]? My intuition says no, not really.
Sure, I can appreciate looking at things in different ways, and it is
nice to learn new things and see how they apply. But if John Grisham
learns Japanese, does that mean he should write all his books in
Japanese? Or should he stick to English? I suppose if I were a real
CS guy (I'm actually an electrical engineer, the scheme course was one
of the two CS courses I took in college, so I'm mostly self taught) or
if I worked within a big group of Lisp programmers, I would probably
feel more comfortable with it. Since I now mostly work as an isolated
programmer for other engineers, and the last language I was using for
everything was C, Python is a huge improvement, and it doesn't give me
too much of a headache. Sure, it's not perfect. But there's no way
I'm going to adopt Lisp as a perfect language anytime soon. That is,
if I want to keep hitting my deadlines and getting paid. And sure, I
may get comfortable and miss out on cool stuff, but on the upside,
I'll be comfortable.
Oh, and if I'm writing in this thread, I suppose I should comment on
how bad lisp macros are. Except I know nothing about them. But it
seems like most languages have dark corners like that, where you can
do thing above and beyond your standard programming practices. Python
has metaclasses, which give me a headache most of the time, so I don't
really use them at all. But I seem to get plenty of stuff done
without using them, so it works for me. If you really have to use
macros in Lisp to get things done, that sounds kind of troublesome,
but it would be consistent, it always seemed like really working well
in Lisp requires you to really know how everything works all at once,
which always kind of struck me as kind of a downside. But as I said,
I'm not the big CS guru, so Lisp just may not be for me in general.
Ah well, I suppose I'll get by with Python. :D
Albert Lai <tr****@vex.net> wrote in message news:<4u************@vex.net>... co************@attbi.com (Corey Coughlin) writes:
(Not to mention car, cdr, cadr, and
so on vs. index notation, sheesh.)
Yes, that is a real regret. It should have been useful to support
a kind of (nth 10 mylist) straight from the Scheme standard library.
Using parentheses and rpn everywhere makes lisp very easy
to parse, but I'd rather have something easy for me to understand and
That's why I prefer python, you
get a nice algebraic syntax with infix and equal signs, and it's easy
understand.
Python is
intuitive to me out of the box, and it just keeps getting better, so I
think I'll stick with it.
First, a minor correction: Lisp/Scheme is like (* 1 2) and that is
Polish Notation or prefix; Reverse Polish Notation or postfix would be
like (1 2 *).
From what I heard about the Japanese language I have formed the
possibly oversimplified impression that it is largely postfix.
Whereas in English we say "I beat you", they may say something like "I
you beat". So I suppose all of the existing programming notations -
Lisp's and Cobol's (* 1 2) and MULTIPLY 1 BY 2, Fortran's "intuitive"
1+2, and OO's one.add(two) - are very counterintuitive to them, and
they would really like the way of HP calculators, no?
And I suppose the ancient Romans (and even the modern Vaticans) would
laugh at this entire dilemma (or trilemma?) between ___fixes.
Intuition is acquired. It is purely a product of education or
brainwashing. There is nothing natural about it. And since it is
acquired, you may as well keep acquiring new intuitions and see more
horizons, rather than keep reinforcing old intuitions and stagnate.
Appreciating a foreign language such as Japanese some day is not a bad
idea.
Pascal Costanza: And, as Paul Graham put it, if you take a language and "add that final
increment of power, you can no longer claim to have invented a new
language, but only to have designed a new dialect of Lisp". (see
http://www.paulgraham.com/diff.html )
What about a language for quantum based computing? I
know the perl folk have a stab at emulating such a language http://www.perl.com/pub/a/2001/08/08/quantum.html
Are there programming possibilities in manipulating ensembles
of possible expressions? Eg, an O(sqrt(N)) search of all
possible algorithms which solve an optimization problem
might prove interesting.
Hmmm, if a problem can be solved in a language of 32 operators
using, say, 50 of those operators, then it can be found after only
O(sqrt(32**50)) == O(2**30) steps.
I'm sure there are other possibilites which are more realistic though.
The fact that such hardware does not exist shouldn't
be a limitation. Babbage's code worked on a machine that
was never built (*and* it had the potential ability to modify
it's own input, making Lisp a 'dialect' of that ur-language),
and Turing's work was also on a theoretical machine.
But then, I'm just a speaker of a dialect of Proto-Indo-European
and my language hasn't improved on the original over the last
few thousand years. ;)
Andrew da***@dalkescientific.com
Alex Martelli: Absolutely! But funding such studies would seem hard. Unless some
company or group of volunteers had their own reasons to take some
existing large app coded in Lisp/Python/Perl/Ruby, and recode it in
one of the other languages with essentially unchanged functionality,
I keep thinking that the bioperl/biopython/bioruby/biojava code bases
would be a source of data for such a study, but upon just a bit of
thinking I realized that each of the projects has a different way of
dealing with a problem. There is overlap between the two, but even
at the file parsing level, bioperl's approach is different from biojava's
and quite different from biopython's.
Another possibility is the code needed for some cross-platform
standard, like a DOM. That's possible, but I suspect there are
large variations in code size even amoung the Python DOMs,
as well as little likelihood of full compliance by all code bases.
Andrew da***@dalkescientific.com
Alex: Well, somebody once asked how
a Pythonista would go about it -- and the answer was unanimous:
print "Just another Python hacker"
It wasn't unanimous. I recall I posted something like
class Write:
.... def __getattr__(self, word): print word,; return self
.... def __repr__(self): return ""
.... Write().Just.another.Python.hacker
Just another Python hacker
;)
My perhaps-not-extensive-enough experience with macros showed them
being used to merge language and meta-language -- in widely different
ways in different labs or even within a given lab -- while at the
same time other firms were using languages without macros (APL and
variants thereof) and processing them with different and separate
metalanguages AND thereby managing to achieve better (intra-firm, at
least) cooperation.
I rather like the phrase I used in private mail: supports mutliple language
paradigm instead of a multiple paradigm language.
Andrew da***@dalkescientific.com
Alex Martelli: 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.
"""
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.
Mathematicians are people as well.
Andrew da***@dalkescientific.com
On Tue, Oct 07, 2003 at 08:01:37PM +0200, Marcin 'Qrczak' Kowalczyk wrote: I find the Lisp syntax hardly readable when everything looks alike,
mostly words and parentheses, and when every level of nesting requires
parens. I understand that it's easier to work with by macros, but it's
harder to work with by humans like I.
I find the ML/Haskell/infix syntax hardly readable when everything is
visually ambiguous, mostly a jumble of non-alphanumeric characters, and
it is difficult to determine where nesting occurs without looking it up
in a reference. I understand that this gives the code the dubious
distinction of looking a little bit like math notation, perverted into
ASCII, but it's harder to work with by Lisp programmers like myself.
P.S. I've written my fair share of SML, I'd like to think, and while it
could be quite infuriating I did appreciate pattern matching and
currying. Of course, both of these can be done in CL, and more flexibly
too.
--
; Matthew Danish <md*****@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Alexander Schmolck <a.********@gmx.net> writes: [narrowing down to c.l.l and c.l.p]
pr***********@comcast.net writes:
> Significantly, AFAICT you can easily do this unambiguously and *locally*,
> for example your editor can trivially perform this operation on cutting a
> piece of python code and its inverse on pasting (so that you only
> cut-and-paste the 'local' indentation). Prima facie I don't see how you
> loose any fine control.
Only if your cut boundaries are at the same lexical level. If you cut
across boundaries, it is no longer clear what should happen at the paste.
The only unclarity would arise from dedents of more than one level on the
corner of your cut region, I think.
Suppose I cut just one arm of a conditional. When I paste, it is
unclear whether I intend for the code after the paste to be part of
that arm, part of the else, or simply part of the same block.
The fact that the information is replicated, and that there is nothing
but programmer discipline keeping it consistent is a source of errors.
Sure there is. Your editor and immediate visual feedback (no need to remember
to reindent after making the semantic changes).
`immediate visual feedback' = programmer discipline
Laxness at this point is a source of errors.
> I don't understand why this is any different to e.g. ')))))' in Lisp. The
> closing ')' for DEFUN just looks the same as that for IF.
That is because the parenthesis *only* encode the grouping information,
they do not do double duty and encode what they are grouping.
The key here is to realize that the words `DEFUN' and the `IF' themselves
look very different.
Well, I'm evidently still not getting it, because my reply would be "and so do
'def ...:' and 'if ...:' in python" (and you also can't tell whether the 8
spaces on the left margin come from a 'def' and and an enclosed 'if' or vice
versa).
I'm not sure I can explain any better, I *think* perhaps some of the other
Lispers might get what I'm saying here.
>> Yet the visual representation is not only identical between all of these, it
>> cannot even be displayed.
>
> I don't understand what you mean. Could you maybe give a concrete example of
> the information that can't be displayed?
Sure. Here are five parens ))))) How much whitespace is there here:
10 spaces (which BTW I counted in emacs in just the same way that I'd count a
similar number of parens) -- but what has counting random trailing whitespace
got to do with anything?
It is simply an illustration that there is no obvious glyph associated
with whitespace, and you wanted a concrete example of something that can't
be displayed.
> Still, I'm sure you're familiar with the following quote (with which I most
> heartily agree):
>
> "[P]rograms must be written for people to read, and only incidentally for
> machines to execute."
>
> People can't "read" '))))))))'.
Funny, the people you just quoted would disagree with you about parenthesis.
I expect that they would disagree with you about whitespace as well.
Why, do they know someone with a paren-counting brain-implant? If so every
lisper should get one -- no more carpal tunnel syndrome from frantic C-M-\
pressing or alphabet wastage due to scheme-style 'aliasing' of '[...]' to
'(...)'.
Seriously, I really fail to see see what the source of disagreement with the
above statement could be.
I cannot read Abelson and Sussman's minds, but neither of them are
ignorant of the vast variety of computer languages in the world.
Nonetheless, given the opportunity to choose any of them for
exposition, they have chosen lisp. Sussman went so far as to
introduce lisp syntax into his book on classical mechanics.
Apparently he felt that not only *could* people read ')))))))', but
that it was often *clearer* than the traditional notation.
If I gave you a piece of lisp code jotted down on paper that (as those
hypothetical examples usually are) for some reason was of vital importance and
that on typing it in revealed a mismatch between the indentation and the
parenthesation in a key section of the code -- which interpretation would you
hedge your bets on in the absence of other indicators; the one suggested by
the indentation or the 9 trailing parens?
Obviously the indentation. But I'd notice the mismatch.
If I gave you a piece of python code jotted down on paper that (as these
hypothetical examples usually are) for some reason was of vital importance
but I accidentally misplaced the indentation -- how would you know?
On Fri, 10 Oct 2003 10:15:35 -0400, rumours say that Joe Marshall
<jr*@ccs.neu.edu> might have written: I would think Lisp is more like cricket: wickets bracket both ends, no
one can actually understand the rules, but at least the players wear
white.
Oh, come on! Anyone can understand cricket! There are two teams.
The team that's in sits out, except for two batsmen, and the other
team come out and try to get the men that are in out. When a man goes
out, he goes in and another man comes out. When the team that's in
are all out, except for the one who's not out, the other team goes in,
until they're all out, too; and then a second innings is played.
That's more or less all there is to it!
In other words, the man that's in may be out or in. If he's in, he
can go back out, but if he's out, then he can't go back in. Once
everyone is out, everyone goes out, then once the in team is out
again, the out team goes in again and everyone in can go out again.
This amount of input/output should be a responsibility of the operating
system.
--
TZOTZIOY, I speak England very best,
Ils sont fous ces Redmontains! --Harddix
Andrew Dalke wrote: Alex Martelli: 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.
"""
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.
Mathematicians are people as well.
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
In article <QA*****************@newsread4.news.pas.earthlink. net>,
Andrew Dalke <ad****@mindspring.com> wrote: Alex Martelli: 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.
"""
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.
Mathematicians are people as well.
On Sat, 11 Oct 2003 14:21:32 -0000, cl****@lairds.com (Cameron Laird)
wrote:
Well, since you crossposted this to sci.math you must be hoping
for replies from that direction: In article <QA*****************@newsread4.news.pas.earthlink. net>,
Andrew Dalke <ad****@mindspring.com> wrote:Alex Martelli: 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.
"""
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.
Mathematicians are people as well.
.
.
.
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,
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.
and the formalism they
profess.
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?
'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.
What's an actual example of one of those philosophical
inconsistencies that luckily doesn't slow us down?
************************
David C. Ullrich pr***********@comcast.net wrote:
... A single web browser?
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?
Cellphone? Why on earth would I want one of those?
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. A single operating system?
On my cellphone all the way to the datacenter?
A cellphone with an OS?! The phone I use is implemented
with *wires*.
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
Jon S. Anthony wrote:
... 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.
Is it a good thing that you can define "bombs waiting to go off"? Python's reply "There should be one-- and preferably only one --
obvious way to do it."
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.
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
Doug Tolton wrote:
... You are correct. I misremembered "Tolton" as "Tilton" and confused
you with someone else. *blush*
Heh, yeah I've noticed that a couple of times. Poor Kenny keeps getting
blamed for things I've said. D'oh!
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"). 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.
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.
That is, on a per-program (or even per-module) basis, redefine
the 0 point offset for an array.
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.
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
Alex Martelli: 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.
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.
(DHCP, DNS, ntp, Squid for proxying, ...).
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 da***@dalkescientific.com
But is it a sense of security or real security? Hmm.... :)
Alex Martelli <al*****@yahoo.com> writes: 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!-)
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
Alex Martelli: 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.
Having two roughly equivalent ways to do something apparently
leads to death by starvation of many a philosopher, unable to
acquire a fork.
Andrew da***@dalkescientific.com
Alex Martelli wrote: Jon S. Anthony wrote:
...
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.
Is it a good thing that you can define "bombs waiting to go off"?
Yes.
Python's reply "There should be one-- and preferably only one --
obvious way to do it."
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.
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".
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.)
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.
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
Jon S. Anthony wrote:
... > 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.
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.
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.
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. 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
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.
I care about "mode of expression" when I write poetry. When I write
programs, I care about simplicity, clarity, directness. MTOWTDItis encouraging multiple different approaches to solve any given
problem -- this, of course, in turn breeds divergence when compared to a
Actually it breeds better solutions to problems. If you don't
understand this, you will never understand much of anything about good
problem solving.
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!-)] ]] 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
At the moment the only thing I am willing to denounce as idiotic are
your clueless rants.
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
Andrew Dalke wrote:
... 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.
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
Alex Martelli wrote: Jon S. Anthony wrote:
...
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.
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.
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.
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.
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
Pascal Costanza: 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.
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.)
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_.
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")?
Pythonistas are probably driven by the assumption that the language
designers have found the best language feature for any task that might
arise.
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."
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.
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.
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.
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.)
This makes them feel safe. (And the large libraries provided
with Common Lisp and some Scheme systems still cover 90% of the standard
tasks.)
Except for my standard tasks in bioinformatics and chemical
informatics. ;)
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.
No, the worst case for productivity is when no way exists.
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/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.
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.
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 da***@dalkescientific.com
Andrew Dalke wrote: 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")?
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
In article <W5****************@newsread4.news.pas.earthlink.n et>, Andrew Dalke wrote:
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.
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
Alex Martelli <al*****@yahoo.com> wrote previously:
|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?
Andrew Dalke wrote: Pascal Costanza:
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.
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.
Yes, we disagree in this regard.
(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 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.
> 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_.
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")?
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.
Pythonistas are probably driven by the assumption that the language
designers have found the best language feature for any task that might
arise.
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."
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.
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.
Ahh, but that assumes that behaviour is the only important thing
in a language.
No.
I disagree with that assumption, and that difference
in belief is one of the core reasons this thread has gone on so long.
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.
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 don't know. I have to ask my vendor. ;-)
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.
If it's only a syntactical issue, then it's a safe bet that you can add
that to the language. Syntax is boring.
(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.)
Sounds like a possible application for the CLOS MOP. > This makes them feel safe. (And the large libraries provided
with Common Lisp and some Scheme systems still cover 90% of the standard
tasks.)
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? ;) 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.
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.
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
Pascal Costanza <co******@web.de> writes: 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.)
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.
Erann Gat wrote:
... mindset, that anything that is potentially dangerous ought to be avoided
because it is potentially dangerous, is IMHO a perverse impediment to
progress. There is no reward without risk.
I'm quite happy for you, and all other unreasonable men "without which
there can be no progress", to run all the risks you want, and I'll be happy
to applaud you for your successes -- as long as I don't bear any part of
the costs of your failures.
As for me personally, and for my typical customers, we have lower
appetite for risk: risk is something to be assessed and managed, not
run for its own sake. A risky strategy is one that has higher expected
returns but also higher volatility: and often there's a threshold effect,
where beating the threshold by a lot isn't much more valuable than
beating it by a little, but falling short of the threshold would be a
disaster. Think of delivery dates, for example: delivering a month in
advance is cool, but not really all that important; delivering a month
late may mean the firm has gone bust in the meantime for lack of
the application it was counting on. I prefer software development
strategies that let me be reasonably sure I can deliver within the
deadline, rather than ones that may, with luck, allow spectacularly
earlier delivery... but risk missing the crucial deadline. I'm a lucky
man, but part of the secret of luck is not pushing it;-).
You seem to be saying that the technologies you prefer are suited
only for cases in which, e.g., running substantial risks of missing the
deadline IS to be considered acceptable. Presumably, that must be
because no safer technology stands a good chance of delivering
reliably -- i.e., cases in which you're pushing the envelope, and the
state of the art. Been there, done that, decided that research does
not float my boat as well as working in the trenches, in software
production environments. I like delivering good working programs
that people will actually use, thus making their life a little bit better.
In other words, I'm an engineer, not a scientist. Scientists whose
goals are not the programs they write -- all those for whom the
programs are mere tools, not goals in themselves -- tend to feel
likewise about programming and other technologies that support
their main work but are secondary to it, though they may have
ambitions as burning as you wish in other, quite different areas.
So, maybe, your favourite technologies are best for research in
computer science itself, or to develop "artificial intelligence" programs
(has the term gone out of fashion these days?) and other programs
pushing the envelope of computer science and technology -- and
mine are best for the purpose of delivering normal, useful, working
applications safely and reliably. If this is true, there is surely space
for both in this world.
things. If you have no ambitions beyond writing
yet-another-standard-web-app then macros are not for you. But if your
Not necessarily web, of course; and generally not standard, but rather
customized for specific customers or groups thereof. But yes, I basically
feel there's a huge unfilled demand for perfectly normal applications,
best filled by technologies such as Python, which, I find, maximize the
productivity of professional programmers in developing such apps and
frameworks for such apps, AND empower non-professional programmers
to perform some of their own programming, customizing, and the like.
My only, very modest ambition is to make some people's lives a little
better than they would be without my work -- I think it's a realistic goal,
and that, a little bit at a time, I am in fact achieving some part of it.
So, general macros in a general-purpose language are not for me, nor for all
those who feel like me -- not for _production_ use, at least, though I do
see how they're fun to play with.
example, there is no reason it should take multiple work years to write an
operating system. There is no fundamental reason why one could not build
a computational infrastructure that would allow a single person to write
an operating system from scratch in a matter of days, maybe even hours or
minutes. But such a system is going to have to have a fairly deep
So why don't you do it? As I recall, the "lisp machines"' operating
systems, written in lisp, were nothing lilke that -- were the lisp
programmers working for lisp machine companies so clueless as not to
see the possibilities that, to you, are so obvious? And yet I had the
impression those companies hired the very best they could find, the stardom
of lispdom. Well then, there's your chance, or that of any other lisper
who agrees with you -- why don't you guys go for it and *show* us, instead
of making claims which some of us might perhaps think are empty boasts...?
Alex
Pascal Costanza <co******@web.de> writes: Andrew Dalke wrote:
Pascal Costanza:
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.
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.
Yes, we disagree in this regard.
(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 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
That doesn't sound too hard. Perl is *already* fairly non-deterministic.
Personally, I prefer not to think about syntax anymore. It's
boring. But that's maybe just me.
Agreed. It's a solved problem.
In article <gG**********************@news1.tin.it>, Alex Martelli
<al*****@yahoo.com> writes Jon S. Anthony wrote:
... 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.
Is it a good thing that you can define "bombs waiting to go off"?
Python's reply "There should be one-- and preferably only one --
obvious way to do it."
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.
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
I'm not sure when this concern for the one true solution arose, but even
GvR provides an explicit example of multiple ways to do it in his essay http://www.python.org/doc/essays/list2str.html
Even in Python there will always be tradeoffs between clarity and
efficiency.
--
Robin Becker
Kenny Tilton wrote:
... 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.
Stop, your scaring me. You mean to say there are macros out there whose
output/behavior I cannot predict? And I am using them in a context where
I need to know what the behavior will be? What is wrong with me? And
what sort of non-deterministic macros are these, that go out and make
their own conclusions about what I meant in some way not documeted?
Let's start with that WITH-CONDITION-MAINTAINED example of Gat. Remember
it? OK, now, since you don't appear to think it was an idiotic example,
then SHOW me how it takes the code for the condition it is to maintain and
the (obviously very complicated: starting a reactor, operating the reactor,
stopping the reactor -- these three primitives in this sequence) program
over which it is to maintain it, and how does it modify that code to ensure
this purpose. Surely, given its perfectly general name, that macro does not
contain, in itself, any model of the reactor; so it must somehow infer it
(guess it?) from the innards of the code it's analyzing and modifying.
Do you need to know what the behavior will be, when controlling a reactor?
Well, I sort of suspect you had better. So, unless you believe that Gat's
example was utterly idiotic, I think you can start explaining from right
there.
I think the objection to macros has at this point been painted into a
very small corner.
I drastically disagree. This is just one example, that was given by one of
the most vocal people from your side, and apparently not yet denounced
as idiotic, despite my asking so repeatedly about it, so presumably agreed
with by your side at large. So, I'm focusing on it until its import is
clarified. Once that is done, we can tackle the many other open issues.
For example, the fact that Gat himself says that if what I want to write
are normal applications, macros are not for me: only for those who want
to push the boundaries of the possible are they worthwhile. Do you think
THAT is idiotic, or wise? Please explain either the reason of the drastic
disagreements in your camp, or why most of you do keep trying pushing
macros (and lisp in general) at those of us who are NOT particularly
interested in "living on the edge" and running big risks for their own sake,
accordingly to your answer to the preceding question, thanks.
"Small corner"?! You MUST be kidding. Particularly given that so many
on your side don't read what I write, and that you guys answer the same
identical questions in completely opposite ways (see below for examples
of both), I don't, in fact, see how this stupid debate will ever end, except
by exhaustion. Meanwhile, "the objection to macros" has only grown
larger and larger with each idiocy I've seen spouted in macros' favour,
and with each mutual or self-contradiction among the macros' defenders. ...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
There is one c.l.l. denizen/guru who agrees with you. I believe his
....and there's another who has just answered in the EXACTLY opposite
way -- that OF COURSE macros can do more than HOF's. So, collectively
speaking, you guys don't even KNOW whether those macros you love so
much are really necessary to do other things than non-macro HOFs allow
(qualification inserted to try to divert the silly objection, already made
by others on your side, that macros _are_ functions), or just pretty things
up a little bit. Would y'all mind coming to some consensus among you
experienced users of macros BEFORE coming to spout your wisdom over
to us poor benigthed non-lovers thereof, THANKYOUVERYMUCH...? far from all). This is far from the first time I'm explaining this, btw.
Oh. OK, now that you mention it I have been skimming lately.
In this case, I think it was quite rude of you to claim I was not answering
questions, when you knew you were NOT READING what I wrote.
As you claim that macros are just for prettying things up, I will restate
(as you may not have read it) one of the many things I've said over and
over on this thread: I do not believe the minor advantage of prettying
things up is worth the complication, the facilitation of language
divergence between groups, and the deliberate introduction of multiple
equivalent ways to solve the same problem, which I guess you do know
I consider a bad thing, one that impacts productivity negatively.
Alex pr***********@comcast.net: 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.
Guess you don't know Knuth.
The smartest programmers I know prefer Python. Except Guido.
He write a lot of C.
Bias error? On whose side?
The smartest people I know aren't programmers. What does
that say?
Andrew da***@dalkescientific.com
Me: My continued response is that [Lisp is] not optimal for all
domains.
Pascal Costanza: Yes, we disagree in this regard.
*Shrug* The existence of awk/perl (great for 1-liners on the
unix command-line) or PHP (for simple web programming) or
Mathematica (for symbolic math) is strong enough evidence for
me to continue to disagree.
Pascal Costanza: 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.
The fact that all computing can be programmed in Turing Machine
Language doesn't mean TML is the optimal programming language.
The fact that there is perl code for emulating *some* quantum
programming means that Lisp can handle that subset. It doesn't mean
that people have fully explored even in Lisp what it means to do all
of quantum computing.
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.
Another *shrug* And a good C programmer can provide a
domain-specific language for the non-professional programmer.
Any good Python programmer could make an implementation
of a Lisp (slow, and not all of GC Lisp, but a Lisp) in Python, like
import lisp
def spam(distance):
"""(time_to_fall 9.8 distance)"""
spam = lisp.convert(spam)
def time_to_fall(g, distance):
print "The spam takes", (2.0*distance/g)**(0.5), "seconds to fall"
print spam(10)
Ah, but then you need to constantly change the syntax and need to
remember the idiosyncrasies of several languages.
Yup. Just like remembering what macros do for different domains.
I firmly believe people can in general easily handle much more
complicated syntax than Lisp has. There's plenty of room to
spare in people's heads for this subject.
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.
wave equation vs. matrix approach
Newtownian mechanics or Lagrangian
measure theory or non-standard analysis
recursive algorithms vs. iterative ones
travelling salesman vs. maximum clique detection
Each is a pair of different but equivalent ways of viewing the same
problem. Is the difference just syntax?
Ahh, but that assumes that behaviour is the only important thing
in a language.
No.
Thank you for your elaboration. You say the driving force is the
ability to handle unexpected events. I assumed that means you need
new styles of behaviour.
If it's only a syntactical issue, then it's a safe bet that you can add
that to the language. Syntax is boring.
Umm... Sure. C++ can be expressed as a parse tree, and that
parse tree converted to an s-exp, which can be claimed to be
a Lisp; perhaps with the right set of macros.
Still doesn't answer my question on how nicely Lisp handles
the 'unexpected' need of allocating objects from different
memory arenas.
Sounds like a possible application for the CLOS MOP.
Or any other language's MOP.
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.
Then the right solution is to claim the analogy is wrong, not
go along with it as you did. ;)
Andrew da***@dalkescientific.com
Alex Martelli <al*****@yahoo.com> writes: Jon S. Anthony wrote:
[snip] 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
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.
I care about "mode of expression" when I write poetry. When I write
programs, I care about simplicity, clarity, directness.
Right on. Then you should dig (Common Lisp-style) macros because they
give programmers tools it *increase* simplicity, clarity, and
directness. That's the point. They are just another tool for creating
useful abstractions--in this case a way to abstract syntax that would
otherwise be repetitive, obscure, or verbose so the abstracted version
is more clear.
If for some reason you believe that macros will have a different
effect--perhaps decreasing simplicity, clarity, and directness then
I'm not surprised you disapprove of them. But I'm not sure why you'd
think they have that effect.
I don't know if you saw this example when I originally posted it since
it wasn't in c.l.python so I'll take the liberty of quoting myself.
(Readers who've been following this thread in c.l.lisp, c.l.scheme, or
c.l.functional have probably already seen this:
In request for examples of macros that allow one to write
less-convoluted code I give this example:
Okay, here's an example of a couple macros I use all the time. Since I
write a lot of unit tests, I like to have a clean syntax for
expressing the essence of a set of related tests. So I have a macro
DEFTEST which is similar to DEFUN except it defines a "test function"
which has some special characteristics. For one, all test functions
are registered with the test framework so I can run all defined tests.
And each test function binds a dynamic variable to the name of the
test currently being run which is used by the reporting framework when
reporting results. So, to write a new test function, here's what I
write:
(deftest foo-tests ()
(check
(= (foo 1 2 3) 42)
(= (foo 4 5 6) 99)))
Note that this is all about the problem domain, namely testing. Each
form within the body of the CHECK is evaluated as a separate test
case. If a given form doesn't evaluate to true then a failure is
reported like this which tells me which test function the failure
was in, the literal form of the test case and then the values of any
non-literal values is the function call (i.e. the arguments to = in
this case.)
Test Failure:
Test Name: (FOO-TESTS)
Test Case: (= (FOO 1 2 3) 42)
Values: (FOO 1 2 3): 6
Test Failure:
Test Name: (FOO-TESTS)
Test Case: (= (FOO 4 5 6) 99)
Values: (FOO 4 5 6): 15
So what is the equivalent non-macro code? Well the equivalent code
to the DEFTEST form (i.e. the macro expansion) is not *that* much
more complex--it just has to do the stuff I mentioned; binding the
test name variable and registering the test function. But it's
complex enough that I sure wouldn't want to have to type it over and
over again each time I write a test:
(progn
(defun foo-tests ()
(let ((test::*test-name*
(append test::*test-name* (list 'foo-tests))))
(check
(= (foo 1 2 3) 42)
(= (foo 4 5 6) 99))))
(eval-when (:compile-toplevel :load-toplevel :execute)
(test::add-test 'foo-tests)))
But the real payoff comes when we realize that innocent looking CHECK
is also a macro. Thus to see what the *real* benefit of macros is we
need to compare the original four-line DEFTEST form to what it expands
into (i.e. what the compiler actually compiles) when all the
subsidiary macros are also expanded. Which is this:
(progn
(defun foo-tests ()
(let ((test::*test-name*
(append test::*test-name* (list 'foo-tests))))
(let ((#:end-result356179 t))
(tagbody
test::retry
(multiple-value-bind (#:result356180 #:bindings356181)
(let ((#:g356240 (foo 1 2 3)) (#:g356241 42))
(values (= #:g356240 #:g356241)
(list (list '(foo 1 2 3) #:g356240))))
(if #:result356180
(signal
'test::test-passed
:test-name test::*test-name*
:test-case '(= (foo 1 2 3) 42)
:bound-values #:bindings356181)
(restart-case
(signal
'test::test-failed
:test-name test::*test-name*
:test-case '(= (foo 1 2 3) 42)
:bound-values #:bindings356181)
(test::skip-test-case nil)
(test::retry-test-case nil (go test::retry))))
(setq #:end-result356179
(and #:end-result356179 #:result356180))))
(tagbody
test::retry
(multiple-value-bind (#:result356180 #:bindings356181)
(let ((#:g356242 (foo 4 5 6)) (#:g356243 99))
(values (= #:g356242 #:g356243)
(list (list '(foo 4 5 6) #:g356242))))
(if #:result356180
(signal
'test::test-passed
:test-name test::*test-name*
:test-case '(= (foo 4 5 6) 99)
:bound-values #:bindings356181)
(restart-case
(signal
'test::test-failed
:test-name test::*test-name*
:test-case '(= (foo 4 5 6) 99)
:bound-values #:bindings356181)
(test::skip-test-case nil)
(test::retry-test-case nil (go test::retry))))
(setq #:end-result356179
(and #:end-result356179 #:result356180))))
#:end-result356179)))
(eval-when (:compile-toplevel :load-toplevel :execute)
(test::add-test 'foo-tests)))
Note that it's the ability, at macro expansion time, to treat the code
as data that allows me to generate test failure messages that contain
the literal code of the test case *and* the value that it evaluated
to. I could certainly write a HOF version of CHECK that accepts a list
of test-case-functions:
(defun check (test-cases)
(dolist (case test-cases)
(if (funcall case)
(report-pass case)
(report-failure case))))
which might be used like:
(defun foo-tests ()
(check
(list
#'(lambda () (= (foo 1 2 3) 42))
#'(lambda () (= (foo 4 5 6) 99)))))
But since each test case would be an opaque function object by the
time CHECK sees it, there'd be no good option for nice reporting from
the test framework. (Of course I'm no functional programming wizard so
maybe there are other ways to do it in other languges (or even Lisp)
but for me, the test, no pun intended, is, is the thing I have to
write to define a new test function much more complex than my original
DEFTEST form?
-Peter
--
Peter Seibel pe***@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Doug Tolton wrote:
... I can understand and respect honest differences of opinions. I too
If so, that makes you an exception in the chorus of lispers who are
screaming against my alleged idiocy and cluelessness (though I
seem to remember you also did, but I may be confusing people "on
your side" -- it's been a LONG and unpleasant thread).
believe that causes of divergence are largely sociological. I differ
though in thinking that features which allow divergence will necessarily
result in divergence.
I don't think it _necessarily_ will, just that it increases probability by
enough to be a concausal factor.
I have this personal theory (used in the non-strict sense here) that
given enough time any homogenous group will split into at least two
competing factions. This "theory" of mine had it's roots in a nice
Unless there's a common enemy who's perceived to be threatening
enough to the whole group -- this is probably the single strongest
unifying factor ("united we stand, divided we fall" -- if people are scared
enough to believe this, they may then remain united).
But the amount of time and other external factors needed to eventually
promote divergence varies with internal factors -- and in cases where
technology plays a key role in the group, then the details of that
technology matter. Some technological aspects intrinsically promote
convergence and cooperation and thus may help counteract sociological
factors working in the other direction -- other technological aspects
facilitate divergence. "In the long run we're all dead" (Keynes), so if
the time needed for divergence is not enough, divergence will not
happen within the group's lifetime;-).
However in the opensource world I expect splinters to happen frequently,
simply because there is little to no organizational control. Even
And you would be wrong: forks are much less frequent than your theory
predicts. Read some Eric Raymond to understand this, he's got good
ideas about these issues.
Python hasn't been immune to this phenomenon with both Jython and
Stackless emerging.
Neither of them is a fork, nor a splinter, nor a split. Jython tracks the
Python standard (as much as it can with far too few core developers)
and the Python standard has been modified to allow Jython to conform
on some points (e.g. timing of garbage collection). Stackless has been
rewritten to become a patch as small as possible on standard Python.
And if you look at the people involved, well, I've seen Samuele Pedroni
(Jython's chief maintainer), Christian Tismer (Mr Stackless), Guido van
Rossum (Mr Python) -- and many others, including yours truly -- sitting in
the same room hacking at the same project during a "sprint" this summer.
And happily guzzling beer and/or wine at the barbecue afterwards, of course.
There's just no "splinter" effect in all of this -- just different
technology needs (e.g. a need to cooperate with some Java libraries
seamlessly), requiring different implementations of the same language,
Python.
Some people want power and expressiveness. Some people want control and
uniformity. Others still will sacrifice high level constucts for raw
pedal to the metal speed, while others wouldn't dream of this sacrifice.
And people who have freely chosen Python appear to share enough core
values (simplicity, one obvious way to do it, etc) to be very far from any
splintering yet. Why does that surprise you?
What I'm getting at is that I can understand why people don't like
Macros. As David Mertz said, some people are just wired in dramatically
different ways.
Well, it's nice that you understand this. I just wish more people on your
side did -- most seem to think I'm crazy, my posts boggle the mind, etc.
What get's me is when people (and I do this sometimes as well) expess an
opinion as fact, and that all rational people will agree with them. So,
for what it' worth, for the times I have expressed my opinion as the one
true way of thinking, I'm sorry.
I don't think there's anything worth apologizing for, in believing the
opinion you hold is the true one. Insulting people who hold a different
rational opinion is of course another issue.
top secret pet project ;) ) every day. I very much respect your
knowledge Alex, because I do believe you have some good insights, and I
do enjoy discussing issues that we disagree on (when we aren't being
"bristly" ;) ) because you have many times helped me to understand my
own point of view better. So even though we don't always agree, I still
appreciate your opinions.
Likewise -- for you and the other reasonable people on your side (right
now Pascal Costanza is the only one who comes to mind, but, as I said,
it's easy to start confusing people after a thread as long and confused
as this one).
I don't think macros are evil, either -- I just don't want them in
Python:-). Let me give an example: one thing my main client is working on
is a specialized language that represents information-models (actions in
them are in embedded Python), presentation-data to guide generic clients
for GUI / web / print presentation, etc. I do think we need macros there
sooner or later (and sooner would be better;-) -- simply to help remove
redundancy and duplication, because in this purely declarative language
there are no "functions". (Were it not for language/metalanguage confusion
risks, and the issues of ensuring the clarity of error-diagnostics, python
functions emitting code in the specialized language [which gets compiled
into Python], i.e. "functions that run at compile-time", would be the
obvious solution, and we could hack them in within an afternoon -- but we
DO want to provide very clear and precise error diagnostics, of course,
and the language/metalanguage issue is currently open). You will note
that this use of macros involves none of the issues I have expressed about
them (except for the difficulty of providing good error-diagnostics, but
that's of course solvable).
Alex
On Wed, 08 Oct 2003 18:28:36 +1300, "Greg Ewing (using news.cis.dfn.de)"
<g2********@sneakemail.com> wrote: Hans Nowak wrote:
Hmm, if I recall correctly, in Latin the plural of 'virus' is 'virus'.
Actually, the last discussion of this that I saw (can't remember where)
came to the conclusion that the word 'virus' didn't *have* a plural
in Latin at all, because its original meaning didn't refer to something
countable.
'virus' (slime, poison, venom) is a 2nd declension neuter noun and
technically does have a plural 'viri'. However such nouns were usually
only used in the nominative and accusative singular in latin. You don't
normally want to start a sentence with 'venoms'. As you said 'virus'
didn't refer to something you usually count, and also in latin 'viri' is
the nominative for 'men' which you do want to use a lot.
The latin plural of census is census (with a long u, 4th declension).
So in English use viruses.
dewatf.
Alex Martelli wrote: As for me personally, and for my typical customers, we have lower
appetite for risk:
Right, and your customers use no C apps.
In other words, I'm an engineer, not a scientist. Scientists whose
goals are not the programs they write -- all those for whom the
programs are mere tools, not goals in themselves -- tend to feel
likewise about programming and other technologies that support
their main work but are secondary to it, though they may have
ambitions as burning as you wish in other, quite different areas.
So, maybe, your favourite technologies are best for research in
computer science itself, or to develop "artificial intelligence" programs
(has the term gone out of fashion these days?) and other programs
pushing the envelope of computer science and technology -- and
mine are best for the purpose of delivering normal, useful, working
applications safely and reliably. If this is true, there is surely space
for both in this world.
How depressing. Leave the powerful languages to those with Computer Science
degrees and let the "software engineers" use weaker systems? What happens
when more functionality is needed (eg., web services)?
It's now nearly the end of 2003 and web applications are still created with
old, flawed technologies -- CGI, server pages, and explicit session
objects. Wouldn't it be nice if web applications were written like, well,
applications?
# my web adder
print_result( get_number() + get_number() )
where print_result sends out a web page, and get_number gets a number from a
web request.
things. If you have no ambitions beyond writing
yet-another-standard-web-app then macros are not for you. But if your
He's wrong. "Advanced" technologies like continuations and macros are
exactly what are needed to make web apps work correctly. The web-app
writer doesn't have to know he's using any of it, but even the Apache
people realized they needed to provide more power in their application
framework.
[...] I basically
feel there's a huge unfilled demand for perfectly normal applications,
best filled by technologies such as Python, which, I find, maximize the
productivity of professional programmers in developing such apps and
frameworks for such apps, AND empower non-professional programmers
to perform some of their own programming, customizing, and the like.
[...]
So, general macros in a general-purpose language are not for me, nor for
all those who feel like me -- not for _production_ use, at least, though I
do see how they're fun to play with.
What the non-professional programmer wants to write a program using two or
more languages? Should we restrict him? Or give him the tools...
(py-eval "x = 1")
(define py_x (in-python (ns-get 'x)))
(define scm_x (->scheme py_x))
scm_x
1 (in-python (ns-set! 'x (->python (+ 2 scm_x))))
(py-eval "print x")
3
In this case, a special form is again needed:
(define-syntax (in-python stx)
(syntax-case stx ()
[(_ expr) #`(parameterize ([current-namespace pns])
expr)]))
- DS
Andrew Dalke wrote: 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.
Another *shrug* And a good C programmer can provide a
domain-specific language for the non-professional programmer.
The last thing we need in this world is more non-professional programmers
writing C programs to make software even more unstable. The ATM near where
I work crashes enough as it is.
You can restrict a DSL in lisp/scheme to the point of not allowing it to
call eval, for example. Can you restrict a C programmer's ability to
dereference NULL? Can you hide 'exec' from the Python newbie?
Any good Python programmer could make an implementation
of a Lisp (slow, and not all of GC Lisp, but a Lisp) in Python, like
import lisp
def spam(distance):
"""(time_to_fall 9.8 distance)"""
spam = lisp.convert(spam)
def time_to_fall(g, distance):
print "The spam takes", (2.0*distance/g)**(0.5), "seconds to fall"
print spam(10)
Please let me know if you hear of anyone implementing lisp/scheme in
Python :) If it's only a syntactical issue, then it's a safe bet that you can add
that to the language. Syntax is boring.
Umm... Sure. C++ can be expressed as a parse tree, and that
parse tree converted to an s-exp, which can be claimed to be
a Lisp; perhaps with the right set of macros.
Still doesn't answer my question on how nicely Lisp handles
the 'unexpected' need of allocating objects from different
memory arenas.
Just like Python does: native modules.
- DS
dewatf wrote: On Wed, 08 Oct 2003 18:28:36 +1300, "Greg Ewing (using news.cis.dfn.de)"
<g2********@sneakemail.com> wrote:
Hans Nowak wrote:
Hmm, if I recall correctly, in Latin the plural of 'virus' is 'virus'.
Actually, the last discussion of this that I saw (can't remember where)
came to the conclusion that the word 'virus' didn't *have* a plural
in Latin at all, because its original meaning didn't refer to something
countable.
'virus' (slime, poison, venom) is a 2nd declension neuter noun and
technically does have a plural 'viri'.
Doesn't it belong to the group that includes 'fructus'? Of course this has
nothing to do with the plural used in English, but still... :-)
This page, which has a lot of info on this issue, seems to think so: http://www.perl.com/language/misc/virus.html
--
Hans (ha**@zephyrfalcon.org) http://zephyrfalcon.org/
On Sat, 11 Oct 2003, Hans Nowak wrote: Daniel P. M. Silva wrote:
Please let me know if you hear of anyone implementing lisp/scheme in
Python :)
Well, there's Psyche:
http://www.xs4all.nl/~yduppen/site/psyche.html
Excellent; thanks!
- DS
Alex Martelli wrote: Kenny Tilton wrote:
...
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.
Stop, your scaring me. You mean to say there are macros out there whose
output/behavior I cannot predict? And I am using them in a context where
I need to know what the behavior will be? What is wrong with me? And
what sort of non-deterministic macros are these, that go out and make
their own conclusions about what I meant in some way not documeted?
Let's start with that WITH-CONDITION-MAINTAINED example of Gat. Remember
it?
No, and Google is not as great as we think it is. :( I did after
extraordinary effort (on this my second try) find the original, but that
was just an application of the macro, not its innards, and I did not get
enough from his description to make out what it was all about. Worse, I
could not find your follow-up objections. I had stopped following this
thread to get some work done (and because I think the horse is dead).
All I know is that you are trying to round up a lynch mob to string up
WITH-MAINTAINED-CONDITION, and thet Lisp the language is doomed to
eternal damnation if we on c.l.l. do not denounce it. :)
No, seriously, what is your problem? That the macro would wlak the code
of the condition to generate a demon that would not only test the
condition but also do things to maintain the condition, based on its
parsing of the code for the condition?
You got a problem with that? Anyway, this is good, I was going to say
this chit chat would be better if we had some actual macros to fight over.
[Apologies up front: I am guessing left and right at both the macro and
your objections. And ILC2003 starts tomorrow, so I may not get back to
you all for a while.]
kenny
ps. Don't forget to read Paul Grahams Chapter's 1 & 8 in On Lisp, from
now on I think it is pointless not to be debating what he said, vs what
we are saying. The whole book is almost dedicated to macros. From the
preface:
"The title [On Lisp] is intended to stress the importance of bottom-up
programming in Lisp. Instead of just writing your program in Lisp, you
can write your own language on Lisp, and write your program in that.
"It is possible to write programs bottom-up in any language, but Lisp is
the most natural vehicle for this style of programming. In Lisp,
bottom-up design is not a special technique reserved for unusually large
or difficult programs. Any substantial program will be written partly in
this style. Lisp was meant from the start to be an extensible language.
The language itself is mostly a collection of Lisp functions, no
different from the ones you define yourself. What’s more, Lisp functions
can be expressed as lists, which are Lisp data structures. This means
you can write Lisp functions which generate Lisp code.
"A good Lisp programmer must know how to take advantage of this
possibility. The usual way to do so is by defining a kind of operator
called a macro. Mastering macros is one of the most important steps in
moving from writing correct Lisp programs to writing beautiful ones.
Introductory Lisp books have room for no more than a quick overview of
macros: an explanation of what macros are,together with a few examples
which hint at the strange and wonderful things you can do with them.
"Those strange and wonderful things will receive special attention here.
One of the aims of this book is to collect in one place all that people
have till now had to learn from experience about macros."
Alex, have you read On Lisp?
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Andrew Dalke wrote: Guess you don't know Knuth.
Eight years to do TeX? How smart can he be? He should have used Lisp.
The smartest people I know aren't programmers. What does
that say?
Aren't you the scientist who praised a study because statistics showed
the studies statistics had a better than even chance of not being
completely random? Credibility zero, dude. (if you now complain that it
was fully a 75% chance of not being completely random, you lose.)
-- http://tilton-technology.com
What?! You are a newbie and you haven't answered my: http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
On Sat, 11 Oct 2003, Hans Nowak wrote: Daniel P. M. Silva wrote:
Please let me know if you hear of anyone implementing lisp/scheme in
Python :)
Well, there's Psyche:
http://www.xs4all.nl/~yduppen/site/psyche.html
Excellent; thanks!
- DS This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Brandon J. Van Every |
last post by:
What's better about Ruby than Python? I'm sure there's something. What is
it?
This is not a troll. I'm language shopping and I want people's answers. I
don't know beans about Ruby or have...
|
by: michele.simionato |
last post by:
Paul Rubin wrote:
> How about macros? Some pretty horrible things have been done in C
> programs with the C preprocessor. But there's a movememnt afloat to
> add hygienic macros to Python. Got any...
|
by: Xah Lee |
last post by:
Python, Lambda, and Guido van Rossum
Xah Lee, 2006-05-05
In this post, i'd like to deconstruct one of Guido's recent blog about
lambda in Python.
In Guido's blog written in 2006-02-10 at...
|
by: Paddy3118 |
last post by:
This month there was/is a 1000+ long thread called:
"merits of Lisp vs Python"
In comp.lang.lisp.
If you followed even parts of the thread, AND previously
used only one of the languages AND...
|
by: WaterWalk |
last post by:
I've just read an article "Building Robust System" by Gerald Jay
Sussman. The article is here:
http://swiss.csail.mit.edu/classes/symbolic/spring07/readings/robust-systems.pdf
In it there is a...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
