How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?
Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.
Mark
"Mark Tarver" <··········@ukonline.co.uk> writes:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
<http://google.com/search?q=python+lisp&btnI=I'm+feeling+lucky>
Paul Rubin wrote:
> "Mark Tarver" <··········@ukonline.co.uk> writes:
> > How do you compare Python to Lisp? What specific advantages do you
> > think that one has over the other?
>
> <http://google.com/search?q=python+lisp&btnI=I'm+feeling+lucky>
Thanks; a quick read of your reference to Norvig's analysis
http://norvig.com/python-lisp.html
seems to show that Python is a cut down (no macros) version of Lisp
with a worse performance. The only substantial advantage I can see is
that GUI, and Web libraries are standard. This confirms my suspicion
that Lisp is losing out to newbies because of its
lack of standard support for the things many people want to do.
Mark
Mark Tarver wrote:
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.
or maybe it shows that Lisp is an obfuscated version of Python with
lots of parentheses, backward logic, and complicated constructs that
run faster.
i.
(message (Hello 'Istvan)
(you :wrote :on '(8 Dec 2006 06:11:20 -0800))
(
??>> seems to show that Python is a cut down (no macros) version of Lisp
??>> with a worse performance.
IA> or maybe it shows that Lisp is an obfuscated version of Python
hell no, lisp's syntax is much easier than python's since it's homogenous
(and certainly lisp was invented much 30 years before Python, so that's
Python uses Lisp features)
IA> with lots of parentheses,
that make logic more explicit
IA> backward logic,
??
IA> and complicated constructs that run faster.
no, there are no complicted constructs -- just it's designed with 30-year
history in mind, not like "let's make another simple scripting language".
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi wrote:
> (message (Hello 'Istvan)
> (you :wrote :on '(8 Dec 2006 06:11:20 -0800))
> (
>
> ??>> seems to show that Python is a cut down (no macros) version of Lisp
> ??>> with a worse performance.
>
> IA> or maybe it shows that Lisp is an obfuscated version of Python
>
> hell no, lisp's syntax is much easier than python's since it's homogenous
It sure is easier... if you're a compiler rather than a human. Also a
lightbulb is much easier understood as a bunch of homogeneous elemental
particles.
George
Alex Mizrahi wrote:
> hell no, lisp's syntax is much easier than python's since it's
> homogenous
Can you give an example? I cannot imagine how homogenity always
results in easiness.
> (and certainly lisp was invented much 30 years before
> Python, so that's Python uses Lisp features)
I think you acknowledged that the syntax is different and not
borrowed?
[many parentheses]
> that make logic more explicit
Can you give an example?
Regards,
Bj�rn
Xpost cll,clp
--
BOFH excuse #166:
/pub/lunch
Bjoern Schliessmann <····························@spamgourmet.com> writes:
> I think you acknowledged that the syntax is different and not
> borrowed?
Um, so does that mean that Python couldn't have borrowed other
features?
Bill Atkins wrote:
> Um, so does that mean that Python couldn't have borrowed other
> features?
No, but he used this point in direct conjunction with the syntax. At
least by my understanding.
Regards,
Bj�rn
Xpost cll,clp
--
BOFH excuse #61:
not approved by the FCC
(message (Hello 'Bjoern)
(you :wrote :on '(Fri, 08 Dec 2006 17:31:08 +0100))
(
??>> hell no, lisp's syntax is much easier than python's since it's
??>> homogenous
BS> Can you give an example? I cannot imagine how homogenity always
BS> results in easiness.
homogenity means that i can cut any expression and paste in any other
expression, and as long as lexical variables are ok, i'll get correct
results -- i don't have to reindent it or whatever.
this is aproximately what programmer does -- he paste pieces of code from
his mind into the program.
BS> [many parentheses]
??>> that make logic more explicit
BS> Can you give an example?
also, there's no need for operator precendence to be taken in accound --
order is explicitly defined. expressions are homogenous, they do not depend
on other expressions near them (except lexical variables and side effects).
the other example of homogenous syntax is XML, that is very popular
nowadays, and it's very similar to lisp's s-expressions.
certainly, it's a matter of taste what syntax to prefer -- i prefer lisp
syntax, others might prefer Python, ML or Haskell syntax.
but homogenous syntax is very important for true macros.
??>> (and certainly lisp was invented much 30 years before
??>> Python, so that's Python uses Lisp features)
BS> I think you acknowledged that the syntax is different and not
BS> borrowed?
certainly
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi wrote:
> (message (Hello 'Bjoern)
>> BS> Can you give an example? I cannot imagine how homogenity
>> always BS> results in easiness.
> homogenity means that i can cut any expression and paste in any
> other expression, and as long as lexical variables are ok, i'll
> get correct results -- i don't have to reindent it or whatever.
Ah, so *that's* what you meant ... but I don't really understand the
ease of it.
> also, there's no need for operator precendence to be taken in
> accound -- order is explicitly defined. expressions are
> homogenous, they do not depend on other expressions near them
> (except lexical variables and side effects).
Sorry, I don't get it ;) Where does Python have things like
nonexplicit defined operator order?
> the other example of homogenous syntax is XML, that is very
> popular nowadays, and it's very similar to lisp's s-expressions.
Spoken freely, I don't like XML because it's hardly readable. Is
it "easy"? If yes, what's your definition of "easy"?
Regards,
Bj�rn
Xpost cll,clp
--
BOFH excuse #437:
crop circles in the corn shell
Bjoern Schliessmann wrote:
> Alex Mizrahi wrote:
>
>>(message (Hello 'Bjoern)
>
>
>>> BS> Can you give an example? I cannot imagine how homogenity
>>> always BS> results in easiness.
>
>
>
>>homogenity means that i can cut any expression and paste in any
>>other expression, and as long as lexical variables are ok, i'll
>>get correct results -- i don't have to reindent it or whatever.
>
>
> Ah, so *that's* what you meant ... but I don't really understand the
> ease of it.
Code in the abstract exists as a tree of trees. With parens, we now have
textual markers delimiting these trees. That means I can point to any
arbitrary subtree by pointing to its left or right parens, and tell the
editor to copy or delete "that chunk of logic". And now I am
manipulating chunks of program logic instead of text.
One simple but hopefully illustrative example: suppose I have an if
statement with two big branches. My code then looks like:
(if (condition) (big-branch-1)(big-branch-2))
Please remember that any of those fakes can be arbitrarily deep nested
expressions. Now during refactoring, I decide bb-2 processing goes
elsewhere, maybe somewhere "upstream" in the logic. So I double-click
and then drag-and-drop, or cut and paste.
Then I double-click on the entire if statement, and then do a
control-click on the "then" condition, control-click happening to mean
"paste what I am clicking". Suddenly the "then" is the whole form.
(And, yes, this means my vendor took away from me the normal
copy-and-drop associated with control click <g>, but I could modify
things to get it back if I really cared.)
Of course the next question has to be, how often does that come up? When
refactoring it sometimes feels like I do nothing else. :) It turns out
that this is an insanely natural way to work with code.
Note also that after any amount of dicing I simply hit a magic key combo
and the editor reindents everything. In a sense, Lisp is the language
that handles indentation best.
hth, ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Note also that after any amount of dicing I simply hit a magic key
> combo and the editor reindents everything. In a sense, Lisp is the
> language that handles indentation best.
Erm ... because there's an editor for it that indents automatically?
Or did I miss the point?
Regards,
Bj�rn
Xpost cll,clp
--
BOFH excuse #235:
The new frame relay network hasn't bedded down the software loop
transmitter yet.
Bjoern Schliessmann wrote:
> Ken Tilton wrote:
>
>
>>Note also that after any amount of dicing I simply hit a magic key
>>combo and the editor reindents everything. In a sense, Lisp is the
>>language that handles indentation best.
>
>
> Erm ... because there's an editor for it that indents automatically?
> Or did I miss the point?
I think so, but you did not say enough for me to understand /your/
point. It sounded like you were using sarcasm to point out to me exactly
what I had just said.
We might want to punt on this. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Bjoern Schliessmann <····························@spamgourmet.com> writes:
>
>> Note also that after any amount of dicing I simply hit a magic key
>> combo and the editor reindents everything. In a sense, Lisp is the
>> language that handles indentation best.
>
> Erm ... because there's an editor for it that indents automatically?
Because it's the language for which indentation is automatically
determinable. That is, one can copy/paste a chunk of code, hit a key
and suddenly everything is nicely indented.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Flagrant system error! The system is down. I dunno what you did,
moron, but you sure screwed everything up --Strongbad
Robert Uhl wrote:
> Because it's the language for which indentation is automatically
> determinable. That is, one can copy/paste a chunk of code, hit a
> key and suddenly everything is nicely indented.
Cool, so in other languages I need to set block marks like () and {}
and also indent the code for readability, and in Python I indent
only. From my POV that's less work.
Regards,
Bj�rn
Xpost cll,clp
--
BOFH excuse #431:
Borg implants are failing
Bjoern Schliessmann wrote:
> Robert Uhl wrote:
>
> > Because it's the language for which indentation is automatically
> > determinable. That is, one can copy/paste a chunk of code, hit a
> > key and suddenly everything is nicely indented.
>
> Cool, so in other languages I need to set block marks like () and {}
> and also indent the code for readability, and in Python I indent
> only. From my POV that's less work.
Try reading again. In Lisp, you use () and *your editor* automatically
indents according to the universal standard, or you leave it sloppy
until other folks reading your code convince you to get a proper
programming editor. Indentation does not get out of sync with semantics
because the editor virtually never misses parentheses that the Lisp
compiler sees. Expressions keep the same meaning even if you have to
start breaking them across lines, etc.
In Python, you group in your mind, and press indentation keys to make
it happen in your editor. The editor cannot help that much, because it
cannot read your mind. White space screwups in copy-paste cannot be
fixed by the editor automatically, because it cannot read the original
programmer's mind, and you have to fix it manually, and risk screwing
it up.
On 2006-12-13, ··············@hotmail.com
<············@gmail.com> wrote:
> Try reading again. In Lisp, you use () and *your editor*
> automatically indents according to the universal standard, or
> you leave it sloppy until other folks reading your code
> convince you to get a proper programming editor. Indentation
> does not get out of sync with semantics because the editor
> virtually never misses parentheses that the Lisp compiler sees.
> Expressions keep the same meaning even if you have to start
> breaking them across lines, etc.
Yes, it's the same way in Python. Of course, not everything is an
expression in Python, so it's not saying quite as much.
> In Python, you group in your mind, and press indentation keys
> to make it happen in your editor. The editor cannot help that
> much, because it cannot read your mind. White space screwups in
> copy-paste cannot be fixed by the editor automatically, because
> it cannot read the original programmer's mind, and you have to
> fix it manually, and risk screwing it up.
It is very easy a manual process, possibly as simple as selecting
the correct s-expr and pasting it into the right place in your
code.
--
Neil Cerutti
Neil Cerutti wrote:
> On 2006-12-13, ··············@hotmail.com
> <············@gmail.com> wrote:
> > Try reading again. In Lisp, you use () and *your editor*
> > automatically indents according to the universal standard, or
> > you leave it sloppy until other folks reading your code
> > convince you to get a proper programming editor. Indentation
> > does not get out of sync with semantics because the editor
> > virtually never misses parentheses that the Lisp compiler sees.
> > Expressions keep the same meaning even if you have to start
> > breaking them across lines, etc.
>
> Yes, it's the same way in Python. Of course, not everything is an
> expression in Python, so it's not saying quite as much.
I fail to see how it is the same in Python. I go into a Lisp buffer
white-space area, and press <Tab> and absolutely nothing changes about
my program. There are two reasons for this: I am using a dumb editor
that puts a Tab in that my compiler doesn't care about, or I am using
the moral equivalent of Emacs, which reads <Tab> as "put this line on
the standard Lisp indentation level, as determined by the
non-whitespace characters in the area."
In Python, I hit that <Tab> and the smartest editor in the world would
have to say "Oh, you want to put this line on a different indentation
level, possibly including this line as part of the if: consequences
block above. Hope that helps!"
> > In Python, you group in your mind, and press indentation keys
> > to make it happen in your editor. The editor cannot help that
> > much, because it cannot read your mind. White space screwups in
> > copy-paste cannot be fixed by the editor automatically, because
> > it cannot read the original programmer's mind, and you have to
> > fix it manually, and risk screwing it up.
>
> It is very easy a manual process, possibly as simple as selecting
> the correct s-expr and pasting it into the right place in your
> code.
How does a manual correction process come out as simple as "don't
bother fixing the indentation if you don't care."?
This is exactly the questionable math that I was questioning in the
original post.
On 2006-12-14, ··············@hotmail.com <············@gmail.com> wrote:
>
> Neil Cerutti wrote:
>> On 2006-12-13, ··············@hotmail.com
>> <············@gmail.com> wrote:
>> > Expressions keep the same meaning even if you have to start
>> > breaking them across lines, etc.
>>
>> Yes, it's the same way in Python. Of course, not everything is
>> an expression in Python, so it's not saying quite as much.
>
> I fail to see how it is the same in Python.
if self.flee == (foo.humble(pie) / 500 * hats
+ hippity.hoppity)
The indentation of the second line of that expression is entirely
irrelevant to Python. The parenthesis I added means I don't have
to use the new-line escape character (\), either.
>> > In Python, you group in your mind, and press indentation
>> > keys to make it happen in your editor. The editor cannot
>> > help that much, because it cannot read your mind. White
>> > space screwups in copy-paste cannot be fixed by the editor
>> > automatically, because it cannot read the original
>> > programmer's mind, and you have to fix it manually, and risk
>> > screwing it up.
>>
>> It is very easy a manual process, possibly as simple as
>> selecting the correct s-expr and pasting it into the right
>> place in your code.
>
> How does a manual correction process come out as simple as
> "don't bother fixing the indentation if you don't care."?
>
> This is exactly the questionable math that I was questioning in
> the original post.
Python simply replaces one manual process (moving to the correct
scope (usually sitting on an open or close parenthesis) and then
hitting the grab-s-expr command) with another (after pasting,
correct the indentation--generally a trivial task). I think it's
a major stretch to call either process anything but trivially
easy for an experiences user of the language.
--
Neil Cerutti
The Pastor would appreciate it if the ladies of the congregation would lend
him their electric girdles for the pancake breakfast next Sunday morning.
--Church Bulletin Blooper
Neil Cerutti wrote:
> On 2006-12-14, ··············@hotmail.com <············@gmail.com> wrote:
> >
> > Neil Cerutti wrote:
> >> On 2006-12-13, ··············@hotmail.com
> >> <············@gmail.com> wrote:
> >> > Expressions keep the same meaning even if you have to start
> >> > breaking them across lines, etc.
> >>
> >> Yes, it's the same way in Python. Of course, not everything is
> >> an expression in Python, so it's not saying quite as much.
> >
> > I fail to see how it is the same in Python.
>
> if self.flee == (foo.humble(pie) / 500 * hats
> + hippity.hoppity)
>
> The indentation of the second line of that expression is entirely
> irrelevant to Python. The parenthesis I added means I don't have
> to use the new-line escape character (\), either.
Is this so unconscious that you don't recognize you are doing it, even
though you take a sentence to explain what you had to do to work around
it? Adding parentheses, new-line escape characters---all this is a
burden specific to Python.
> > How does a manual correction process come out as simple as
> > "don't bother fixing the indentation if you don't care."?
> >
> > This is exactly the questionable math that I was questioning in
> > the original post.
>
> Python simply replaces one manual process (moving to the correct
> scope (usually sitting on an open or close parenthesis) and then
> hitting the grab-s-expr command) with another (after pasting,
> correct the indentation--generally a trivial task). I think it's
> a major stretch to call either process anything but trivially
> easy for an experiences user of the language.
The reformatting (admittedly generally trivial, although again your
qualifier of "generally" undermines your point) process is extra in
Python. Period.
1) Recognizing where your code begins and ends to begin the copy-paste
process is not unique to either. Equal.
2) In a python-aware editor, I presume the grab-block keystroke exists
and is equivalent to grab-s-expr. Or, you have to manually select to
tell the editor where the block ends. Equal.
3) Recognizing where you want to paste is the same. Equal.
4) The paste keystroke is presumed Equal.
Lispers are done here.
5) After you are done, Pythonistas admit there is a possible step
called "manually correct the indentation."
Can I be any clearer? Now, you can say 5 is usually generally trivially
easy for an experienced Pythonista in 'the flow' or whatever you like,
but it just is not there for Lisp.
This is pointless discussion if you guys can't even see what you are
saying when you write it in your own posts.
By the way, you guys seem fixate on the parentheses of Lisp without
having the experience which shows that open parens are trivial to find,
because they don't occur in clumps and they are marked by the operator
symbol. The close parens occur in somewhat ugly clumps, but the editor
is the only thing that needs to deal with them.
On 2006-12-14, ··············@hotmail.com <············@gmail.com> wrote:
>
> Neil Cerutti wrote:
>> On 2006-12-14, ··············@hotmail.com <············@gmail.com> wrote:
>> >
>> > Neil Cerutti wrote:
>> >> On 2006-12-13, ··············@hotmail.com
>> >> <············@gmail.com> wrote:
>> >> > Expressions keep the same meaning even if you have to start
>> >> > breaking them across lines, etc.
>> >>
>> >> Yes, it's the same way in Python. Of course, not everything
>> >> is an expression in Python, so it's not saying quite as
>> >> much.
>> >
>> > I fail to see how it is the same in Python.
>>
>> if self.flee == (foo.humble(pie) / 500 * hats
>> + hippity.hoppity)
>>
>> The indentation of the second line of that expression is entirely
>> irrelevant to Python. The parenthesis I added means I don't have
>> to use the new-line escape character (\), either.
>
> Is this so unconscious that you don't recognize you are doing
> it, even though you take a sentence to explain what you had to
> do to work around it? Adding parentheses, new-line escape
> characters---all this is a burden specific to Python.
It already indicated that you are right about Python identation
*outside* of an expression, which is where most indentation takes
place in Python. But you were wrong that it is meaningful inside
an expression.
> The reformatting (admittedly generally trivial, although again
> your qualifier of "generally" undermines your point) process is
> extra in Python. Period.
>
> 1) Recognizing where your code begins and ends to begin the
> copy-paste process is not unique to either. Equal.
Reflecting on what you've written, I see you are right about this
issue. Thanks for the correction.
> 5) After you are done, Pythonistas admit there is a possible
> step called "manually correct the indentation."
Meaningful indentation has drawbacks *and* advantages, though.
> This is pointless discussion if you guys can't even see what
> you are saying when you write it in your own posts.
Please don't assume I speak for all Python programmers. They
might be rolling there eyes at me just as much as you are. ;-)
--
Neil Cerutti
In my prime I could have handled Michael Jordan. Of course, he would be only
12 years old. --Jerry Sloan
··············@hotmail.com wrote:
> Neil Cerutti wrote:
>
> > The parenthesis I added means I don't have
> > to use the new-line escape character (\), either.
>
> Is this so unconscious that you don't recognize you are doing it, even
> though you take a sentence to explain what you had to do to work around
> it?
Yes, it is pretty unconscious. We all do many things
unconsciously in everyday life that would take at
least one sentence to explain to someone else if we
had to think about it.
Besides, in many cases the required brackets are
already there -- e.g. if it's a list, or a function
call with many arguments -- in which case you don't
have to add anything at all.
> Adding parentheses ... all this is a
> burden specific to Python.
As opposed to Lisp, where all you have to do is
use parentheses... oh, er...
> By the way, you guys seem fixate on the parentheses of Lisp without
> having the experience
I don't know about the other Pythonistas in this
discussion, but personally I do have experience with
Lisp, and I understand what you're saying. I have
nothing against Lisp parentheses, I just don't agree
that the Lisp way is superior to the Python way in
all respects, based on my experience with both.
--
Greg
greg schrieb:
> ··············@hotmail.com wrote:
>> Adding parentheses ... all this is a
>> burden specific to Python.
>
> As opposed to Lisp, where all you have to do is
> use parentheses... oh, er...
Lisp has no parens. An editor could support a mode where code
is displayed in written in trees. There wouldn't be a single
paren.
>> By the way, you guys seem fixate on the parentheses of Lisp without
>> having the experience
>
> I don't know about the other Pythonistas in this
> discussion, but personally I do have experience with
> Lisp, and I understand what you're saying. I have
> nothing against Lisp parentheses, I just don't agree
> that the Lisp way is superior to the Python way in
> all respects, based on my experience with both.
Lisp is not superior in all respects. As soon you decide to use a
language you decide against other features.
Python is especially strong as a scripting language as that is the
domain of it.
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> Lisp has no parens. An editor could support a mode where code
> is displayed in written in trees. There wouldn't be a single paren.
But there would be even more tokens, the lines going between the nodes
in the trees, for example.
Paul Rubin schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>> Lisp has no parens. An editor could support a mode where code
>> is displayed in written in trees. There wouldn't be a single paren.
>
> But there would be even more tokens, the lines going between the nodes
> in the trees, for example.
These are painted by the editor.
I also don't count the number of pixels ouf of which a letter consists
as tokens. The nodes in the source tree can be one counting method
which a lot of people could accept.
For Python I also wouldn't count the number of spaces of indentation.
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> > But there would be even more tokens, the lines going between the
> > nodes
> > in the trees, for example.
>
> These are painted by the editor.
If you have to tell the editor where to put them, they are tokens.
greg ha escrito:
> I don't know about the other Pythonistas in this
> discussion, but personally I do have experience with
> Lisp, and I understand what you're saying. I have
> nothing against Lisp parentheses, I just don't agree
> that the Lisp way is superior to the Python way in
> all respects, based on my experience with both.
Parentheses have two advantages over identation. First is they can be
used both inline and block.
The inline (a b (c d (e f g))) needs to be formatted in several Python
lines. Therein SLiP (Python) got problems for inline mixed markup but
LML (LISP) or SXML (Scheme) do not.
Second is that i do not need special editors for writting/editting. It
is more difficult to do identation and editing by hand in 'Notepad'
that adding parens from keyboard [*].
[*] Tip. Type always () and next move your cursor inside ( _ ). You
never forget a closing ) this way!
··············@hotmail.com wrote:
> Neil Cerutti wrote:
>
>>On 2006-12-13, ··············@hotmail.com
>><············@gmail.com> wrote:
>>
>>>Expressions keep the same meaning even if you have to start
>>>breaking them across lines, etc.
>>
>>Yes, it's the same way in Python. Of course, not everything is an
>>expression in Python, so it's not saying quite as much.
>
> I fail to see how it is the same in Python.
Probably what Neil is referring to is the fact that in
Python, *within an expression*, indentation is not relevant.
If you put parens around the whole expression, you can split
it across lines however you like, and indent all the lines
after the first one however you like, and it makes no
difference. You could probably even use your Lisp-aware
auto-indenter on the expression and it would do something
reasonable.
It's only *statement* nesting that's determined by relative
horizontal position (which is a better way of thinking about
it than "whitespace" -- the whitespace is only there to
get things into the right position). And statements normally
occupy one or more entire lines.
> How does a manual correction process come out as simple as "don't
> bother fixing the indentation if you don't care."?
I think the point is that correcting indentation in Python
is the equivalent of fixing misplaced parentheses in Lisp,
and that they're about equally difficult.
--
Greg
··············@hotmail.com a �crit :
> Bjoern Schliessmann wrote:
>> Robert Uhl wrote:
>>
>>> Because it's the language for which indentation is automatically
>>> determinable. That is, one can copy/paste a chunk of code, hit a
>>> key and suddenly everything is nicely indented.
>> Cool, so in other languages I need to set block marks like () and {}
>> and also indent the code for readability, and in Python I indent
>> only. From my POV that's less work.
>
> Try reading again. In Lisp, you use () and *your editor* automatically
> indents according to the universal standard, or you leave it sloppy
> until other folks reading your code convince you to get a proper
> programming editor. Indentation does not get out of sync with semantics
> because the editor virtually never misses parentheses that the Lisp
> compiler sees. Expressions keep the same meaning even if you have to
> start breaking them across lines, etc.
>
> In Python, you group in your mind, and press indentation keys to make
> it happen in your editor. The editor cannot help that much, because it
> cannot read your mind. White space screwups in copy-paste cannot be
> fixed by the editor automatically, because it cannot read the original
> programmer's mind, and you have to fix it manually, and risk screwing
> it up.
Call us when you have an editor that reads your mind and writes the ()
for you.
Christophe wrote:
> ··············@hotmail.com a écrit :
> > Bjoern Schliessmann wrote:
> >> Robert Uhl wrote:
> >>
> >>> Because it's the language for which indentation is automatically
> >>> determinable. That is, one can copy/paste a chunk of code, hit a
> >>> key and suddenly everything is nicely indented.
> >> Cool, so in other languages I need to set block marks like () and {}
> >> and also indent the code for readability, and in Python I indent
> >> only. From my POV that's less work.
> >
> > Try reading again. In Lisp, you use () and *your editor* automatically
> > indents according to the universal standard, or you leave it sloppy
> > until other folks reading your code convince you to get a proper
> > programming editor. Indentation does not get out of sync with semantics
> > because the editor virtually never misses parentheses that the Lisp
> > compiler sees. Expressions keep the same meaning even if you have to
> > start breaking them across lines, etc.
> >
> > In Python, you group in your mind, and press indentation keys to make
> > it happen in your editor. The editor cannot help that much, because it
> > cannot read your mind. White space screwups in copy-paste cannot be
> > fixed by the editor automatically, because it cannot read the original
> > programmer's mind, and you have to fix it manually, and risk screwing
> > it up.
>
> Call us when you have an editor that reads your mind and writes the ()
> for you.
This is an irrelevancy. Typos that drop printing characters in either
language will generally cause changes to the semantics. Lisp
programmers, incidentally, will see that their editor indented things
in a funky way and recognize "hey, I dropped a paren somewhere in that
copy-paste." (And, if so, it is usually at the end, and can be
recovered using automatic matching when typing the ')' ). And,
honestly, the punctuation is no harder to type in Lisp than in other
languages, they just occur in different (and more consistent) places.
The point of Python is that changing white-space to
different-white-space changes the semantics. At best an editor can
notice "hey, funky white-space here, please correct" as IDLE did when I
wrote my first Python in a non-Python-aware editor, and somehow had
swapped tabs and spaces; when I moved it to IDLE---the indentation
*looked fine* but was invisibly weird. At worst, an editor can go
"sure, I'll let you change your program."
I'm not saying the worst case is typical. The annoying case is more
likely. I will even admit that white-space significance does not
materially increase errors among experienced Pythonistas. What it isn't
is some kind of miraculous invention that saves programmers from ever
making mistakes that are common in other languages, or that reduces
effort in copy-paste, as Bjoern seemed to be claiming.
··············@hotmail.com a �crit :
> Christophe wrote:
>> Call us when you have an editor that reads your mind and writes the ()
>> for you.
>
> This is an irrelevancy. Typos that drop printing characters in either
> language will generally cause changes to the semantics. Lisp
> programmers, incidentally, will see that their editor indented things
> in a funky way and recognize "hey, I dropped a paren somewhere in that
> copy-paste." (And, if so, it is usually at the end, and can be
> recovered using automatic matching when typing the ')' ). And,
> honestly, the punctuation is no harder to type in Lisp than in other
> languages, they just occur in different (and more consistent) places.
>
> The point of Python is that changing white-space to
> different-white-space changes the semantics. At best an editor can
> notice "hey, funky white-space here, please correct" as IDLE did when I
> wrote my first Python in a non-Python-aware editor, and somehow had
> swapped tabs and spaces; when I moved it to IDLE---the indentation
> *looked fine* but was invisibly weird. At worst, an editor can go
> "sure, I'll let you change your program."
>
> I'm not saying the worst case is typical. The annoying case is more
> likely. I will even admit that white-space significance does not
> materially increase errors among experienced Pythonistas. What it isn't
> is some kind of miraculous invention that saves programmers from ever
> making mistakes that are common in other languages, or that reduces
> effort in copy-paste, as Bjoern seemed to be claiming.
So, you are more or less saying that, using a smart Lisp editor, you'll
easily catch block errors when you misplace a bracket, but using dumb
Python editors allows inconsistent tab-space usage to go unnoticed?
Yeah, nothing wrong in what you said but hardly relevant I say :)
For the Python side, I just hope that -tt becomes the default option one
day ( interpreter causes errors when mixing spaces and tabs )
··············@hotmail.com wrote:
> What it isn't is some kind of miraculous invention that saves
> programmers from ever making mistakes that are common in other
> languages, or that reduces effort in copy-paste, as Bjoern seemed
> to be claiming.
I didn't. I just stated that the Python way is less work for me.
Regards,
Bj�rn
--
BOFH excuse #112:
The monitor is plugged into the serial port
··············@hotmail.com wrote:
> What it isn't is some kind of miraculous invention that saves
> programmers from ever making mistakes that are common in other
> languages, or that reduces effort in copy-paste, as Bjoern seemed
> to be claiming.
I didn't. I just stated that the Python way is less work for me.
Regards,
Bj�rn
Xpost cll,clp
--
BOFH excuse #112:
The monitor is plugged into the serial port
··············@hotmail.com wrote:
> I wrote my first Python in a non-Python-aware editor, and somehow had
> swapped tabs and spaces; when I moved it to IDLE---the indentation
> *looked fine* but was invisibly weird.
That can admittedly be a problem. It would help if the
parser complained by default about mixed use of tabs and
spaces in a single file, instead of silently assuming tab
stops every 8 spaces (an historical misfeature that we still
have for the time being). Probably this will change in
Python 3.0.
Personally I find Python pleasant enough to work with
that I'm willing to put up with the odd screwup like that
happening now and then. And they really don't happen all
that often -- once you've experienced it a few times,
you learn how to guard against it and get better at
fixing it when it does happen.
> I will even admit that white-space significance does not
> materially increase errors among experienced Pythonistas. What it isn't
> is some kind of miraculous invention that saves programmers from ever
> making mistakes that are common in other languages,
We don't claim that -- only that it's not the unmitigated
disaster than some people assume it will be without ever
having tried it.
--
Greg
(message (Hello 'Bjoern)
(you :wrote :on '(Fri, 08 Dec 2006 19:57:28 +0100))
(
??>> also, there's no need for operator precendence to be taken in
??>> accound -- order is explicitly defined. expressions are
??>> homogenous, they do not depend on other expressions near them
??>> (except lexical variables and side effects).
BS> Sorry, I don't get it ;) Where does Python have things like
BS> nonexplicit defined operator order?
you have an expression 3 + 4 which yields 7.
you have an expression 4 * 1 which yields 4.
if you paste 3 + 4 in place of 1, you'll have 4 * 3 + 4 = 16. as we know, *
is commutative, but 3 + 4 * 4 = 19.
so result depends on implicit operator precendence rules.
in lisp, if you paste (+ 3 4) in (* 4 1), you'll have (* 4 (+ 3 4)), and it
does not depend on order of operands, (* (+ 3 4) 4) yields same results. you
do not have to remember precendence rules -- * and + are not anyhow special
from other functions. all you need to remember is how to call functions.
certainly it's a very simple example, but it shows that generally, homogeous
lisp syntax make expressions much less dependant on context, and there are
much less rules affecting it. thus, work require by brain to understand and
write code can be reduced -- that way it's easier.
Common Lisp specification define internal languages that are not in
homogenous s-expr syntax -- that is formatter and loop macro.
like
(loop for i from 1 to 20 collect i)
or
(loop for e in list
maximizing e into max
minimizing e into min
finally (return (values min max)))
remarkable thing about that is that it's the only place which i cannot
remember and need to lookup quite frequently in the reference.
although it looks almost like plain english and looks quite easy, it's much
harder than other parts of lisp that use uniform syntax.
but certainly this uniform syntax doesn't worth much without macro
facilities.
i'll show an example from my recent experiments.
in this example we want to perform a query into a RDF database
(triplestore), SPARQL-style query, and then we format results as HTML.
here's how it looks in the SPARQL (i'm not fluent in it, so it can be
buggy). basically, we want to query information (firstname, lastname,
salary) or all users in specified departament.
PREFIX myapp: <https://mydomain.net/myapp/1.1/>
SELECT ?fname, ?lname, ?salary
WHERE
{
?user myapp:name ?uname.
?uname myapp:first-name ?fname.
?uname myapp:last-name ?lname.
?user myapp:salary ?salary.
?user myapp:department ?dept.
}
we should feed this text to the query-builder.
then we should bind ?dept to our variable departament (i'm not sure how this
is done in SPARQL, but there should be a way).
then we should iterate over results and output HTML. a python-like
pseudocode:
query = BuildQuery(query_str)
query.bind("?dept", departament)
results = query.execute()
for each rs in results:
print "<tr><td>" + htmlesc(rs.get("?fname")) + "</td><td>" +
htmlesc(rs.get("?lname")) + "</td><td>" + rs.get("?salary") + "</td></tr>"
so how uniform syntax and macros can help here? we can make a macro
rdf:do-query that will both programmatically create query, bind input
variables and then bind results into local variables. also we can wrap HTML
output in a macro too.
so here's a code:
(rdf:do-query
((?user :name ?uname)
(?uname :first-name ?fname)
(?uname :last-name ?lname)
(?user :salary ?salary)
(?user :department department))
(html (:tr
(:td (:princ ?fname))
(:td (:princ ?lname))
(:td (:princ ?salary)))))
as you can find, it's two times less code, it's less clumsy, and there's
even less quotes and parentheses there -- who says that lisp has more
parentheses? also, this code is less error-prone, because some part of
correctless can be checked during compilation time by macros, because it
operates with symbols on semantic level, but not with simple strings.
for example, if i make a type and write ?fnme instead of ?fname in the HTML
output, compiler will report a warning about unbound variable, but if this
variable will be in string-form, compiler will not be able to.
there are other benefits: RDF query language is transparently integrated
into Lisp, there's no need to learn some other language (SPARQL) syntax
additionally. and it strains my brain less when i don't have to switch
between different languages.
is it possible to construct such helper functions (or whatever) to simplify
code in Python?
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi escreveu:
>
> we should feed this text to the query-builder.
> then we should bind ?dept to our variable departament (i'm not sure how this
> is done in SPARQL, but there should be a way).
> then we should iterate over results and output HTML. a python-like
> pseudocode:
>
> query = BuildQuery(query_str)
> query.bind("?dept", departament)
> results = query.execute()
> for each rs in results:
> print "<tr><td>" + htmlesc(rs.get("?fname")) + "</td><td>" +
> htmlesc(rs.get("?lname")) + "</td><td>" + rs.get("?salary") + "</td></tr>"
I just want to add that this kind of HTML mixed with code is something
that should be avoided, no matter what language is used.
Stephen
On Fri, 08 Dec 2006 22:02:59 +0200, Alex Mizrahi wrote:
> you have an expression 3 + 4 which yields 7.
> you have an expression 4 * 1 which yields 4.
> if you paste 3 + 4 in place of 1, you'll have 4 * 3 + 4 = 16. as we know, *
> is commutative, but 3 + 4 * 4 = 19.
> so result depends on implicit operator precendence rules.
>
> in lisp, if you paste (+ 3 4) in (* 4 1), you'll have (* 4 (+ 3 4)), and it
> does not depend on order of operands, (* (+ 3 4) 4) yields same results. you
> do not have to remember precendence rules
Speaking as somebody who programmed in FORTH for a while, that doesn't
impress me much. Prefix/postfix notation is, generally speaking, more of a
pain in the rear end than it is worth, even if it saves you a tiny bit of
thought when pasting code.
Except, of course, it doesn't really save you any thought. You can't just
expect to paste an expression randomly into another expression and have it
do the right thing. Oh, it will compile all right. But it won't do the
right thing! Since you -- not the compiler -- have to understand the
semantics of what you are pasting where, and paste the right expression
into the right place, the effort saved by not using infix notation is less
than the effort needed to mentally translate between prefix and infix.
If you are one of those people who actually think in prefix notation, then
I raise my hat to you while backing away slowly.
(And actually, I'll give you one point: I've been hitting my head against
a brick wall over a particular problem, and I think your email just gave
me a clue how to solve it. Sometimes prefix/postfix notation is the right
tool for the job. See, I can learn from Lisp.)
--
Steven.
Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 22:02:59 +0200, Alex Mizrahi wrote:
>
>
>>you have an expression 3 + 4 which yields 7.
>>you have an expression 4 * 1 which yields 4.
>>if you paste 3 + 4 in place of 1, you'll have 4 * 3 + 4 = 16. as we know, *
>>is commutative, but 3 + 4 * 4 = 19.
>>so result depends on implicit operator precendence rules.
>>
>>in lisp, if you paste (+ 3 4) in (* 4 1), you'll have (* 4 (+ 3 4)), and it
>>does not depend on order of operands, (* (+ 3 4) 4) yields same results. you
>>do not have to remember precendence rules
>
>
> Speaking as somebody who programmed in FORTH for a while, that doesn't
> impress me much. Prefix/postfix notation is, generally speaking, more of a
> pain in the rear end than it is worth, even if it saves you a tiny bit of
> thought when pasting code.
>
> Except, of course, it doesn't really save you any thought. You can't just
> expect to paste an expression randomly into another expression and have it
> do the right thing.
Tell that to the unlimited number of monkeys I have over hear generating
my next application. You might also read what I wrote earlier in this
thread about how I leveraged the parens thing to edit code in logical
chunks instead of chunks of text. If you think about it, that is exactly
how code should be edited.
But I am fascinated: Python text can be edited randomly because it uses
infix? Or did you just throw in randomly because your point sounded so
weak without it? :)
> Oh, it will compile all right. But it won't do the
> right thing! Since you -- not the compiler -- have to understand the
> semantics of what you are pasting where, and paste the right expression
> into the right place, the effort saved by not using infix notation is less
> than the effort needed to mentally translate between prefix and infix.
Has it ever occurred to you that you might be the one translating?
Because you are, you just do not know it. The only time I translate is
when I have to express a multi-operator math formula in Lisp:
(eql y (+ (* m (expt x 2)) b))
I threw an exponent into the slope-intercept form of a line for the heck
of it. Gotta tell you, I do not have to code a lot of math formulas in
Lisp, and I would definitely download and infix-eating macro if I did.
Aside from that, you are the one translating. Prefix is terribly natural
to the mind. Think about it. Add it all up. Add the tax and price and
tip. Those are imperative, this one functional: the sum of the parts.
The only time one hears infix in speech is when one is reading math
notation. So... put two and two together.
>
> If you are one of those people who actually think in prefix notation, then
> I raise my hat to you while backing away slowly.
Be careful backing away from yourself. :) I remember talking to a Welsh
chap who had experienced the transition to a decimal system for money
from the good old days of shillings, etc. He said he still had to
translate pennies to shillings, even though the decimal system was less
ornate. What mattered was the habit, not the clarity of representation.
The good news is in my earlier point: you already are using prefix. Even
in programming. What does a functionall look like? fn(p1,p2,p3) Lisp
just moved the left parenthesis in front of the fn so the logical chunk
(function+parameters) is also a textual chunk neatly packaged and
editable between matching parens.
>
> (And actually, I'll give you one point: I've been hitting my head against
> a brick wall over a particular problem, and I think your email just gave
> me a clue how to solve it. Sometimes prefix/postfix notation is the right
> tool for the job. See, I can learn from Lisp.)
I think that was A Message From God(tm).
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>
> Speaking as somebody who programmed in FORTH for a while, that doesn't
> impress me much. Prefix/postfix notation is, generally speaking, more
> of a pain in the rear end than it is worth, even if it saves you a
> tiny bit of thought when pasting code.
Of course, you use prefix notation all the time in Python:
for x in range(0,len(y)):
dosomething(x)
In the example, 'for,' 'range,' 'len' and 'dosomething' all use
prefix notation. In Lisp the example might look like this, assuming the
proper functions and macros to make it work:
(for ((x (range 0 (length y))))
(dosomething x))
Slightly more idiomatic would be:
(loop for x in (range 0 (length y))
do (dosomething x))
Even more idiomatic would be:
(loop for x below (length y)
do (dosomething x))
Which doesn't seem particularly more or less prefixy or infixy than the
Python version.
Infix is really only used in arithmetic--and there are Lisp macros which
give one infix notation if wanted, so one could write:
(infix 1 + x / 4)
--
Robert Uhl <http://public.xdi.org/=ruhl>
Give a man a fish and you feed him for a day; give him a freshly-charged
Electric Eel and chances are he won't bother you for anything ever again.
--Tanuki the Raccoon-dog
Robert Uhl wrote:
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> >
> > Speaking as somebody who programmed in FORTH for a while, that doesn't
> > impress me much. Prefix/postfix notation is, generally speaking, more
> > of a pain in the rear end than it is worth, even if it saves you a
> > tiny bit of thought when pasting code.
>
> Of course, you use prefix notation all the time in Python:
>
> for x in range(0,len(y)):
> dosomething(x)
In Python, most containers are directly iterable so we are much more
likely to arrange our program to use:
for a in y:
dosomethingwith(a)
-Paddy.
Paddy wrote:
> Robert Uhl wrote:
>
> > Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> > >
> > > Speaking as somebody who programmed in FORTH for a while, that doesn't
> > > impress me much. Prefix/postfix notation is, generally speaking, more
> > > of a pain in the rear end than it is worth, even if it saves you a
> > > tiny bit of thought when pasting code.
> >
> > Of course, you use prefix notation all the time in Python:
> >
> > for x in range(0,len(y)):
> > dosomething(x)
>
> In Python, most containers are directly iterable so we are much more
> likely to arrange our program to use:
> for a in y:
> dosomethingwith(a)
>
> -Paddy.
Or the more succinct Python (FP) construct:
map(dosomething, y)
On Wed, 13 Dec 2006 01:54:58 +0100, Paddy <·········@netscape.net> wrote:
>
> Robert Uhl wrote:
>
>> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>> >
>> > Speaking as somebody who programmed in FORTH for a while, that doesn't
>> > impress me much. Prefix/postfix notation is, generally speaking, more
>> > of a pain in the rear end than it is worth, even if it saves you a
>> > tiny bit of thought when pasting code.
>>
>> Of course, you use prefix notation all the time in Python:
>>
>> for x in range(0,len(y)):
>> dosomething(x)
>
> In Python, most containers are directly iterable so we are much more
> likely to arrange our program to use:
> for a in y:
> dosomethingwith(a)
>
> -Paddy.
>
In lisp: (loop for a in y do (do-something a))
There is one difference.. There is no iterator so you have different
pronouns for each sequence type:
list: (loop for a in y ..
array: (loop for a across y ..
hash: (loop for a over y ..
hardly ideal, but workable.
Still it is a lot simpler to change the declaration in the start of the
loop
than having to changing the access to all references to a variable as you
might have to
with recursion. Consider
(defun func-iter (list)
(func (first list)))
(when (not (endp list))
(func-iter (rest list)))
(You could write (mapc #'(lambda (e) (func e)) list) but that is beside
the point.)
or something like that. What happens if you change the type to a array?
Total rewrite..
From a software engineering point of view iteration is preferable to
recursion because
maintenance and aggregation is simpler. (Sorry about the digression.)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Wed, 13 Dec 2006 01:54:58 +0100, Paddy <·········@netscape.net> wrote:
>
> >
> > Robert Uhl wrote:
> >
> >> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> >> >
> >> > Speaking as somebody who programmed in FORTH for a while, that doesn't
> >> > impress me much. Prefix/postfix notation is, generally speaking, more
> >> > of a pain in the rear end than it is worth, even if it saves you a
> >> > tiny bit of thought when pasting code.
> >>
> >> Of course, you use prefix notation all the time in Python:
> >>
> >> for x in range(0,len(y)):
> >> dosomething(x)
> >
> > In Python, most containers are directly iterable so we are much more
> > likely to arrange our program to use:
> > for a in y:
> > dosomethingwith(a)
> >
> > -Paddy.
> >
>
> In lisp: (loop for a in y do (do-something a))
>
> There is one difference.. There is no iterator so you have different
> pronouns for each sequence type:
>
> list: (loop for a in y ..
> array: (loop for a across y ..
> hash: (loop for a over y ..
>
> hardly ideal, but workable.
>
> Still it is a lot simpler to change the declaration in the start of the
> loop
> than having to changing the access to all references to a variable as you
> might have to
I can't quite figure out the meaning of your sentence above.
> with recursion. Consider
>
> (defun func-iter (list)
> (func (first list)))
> (when (not (endp list))
> (func-iter (rest list)))
>
> (You could write (mapc #'(lambda (e) (func e)) list) but that is beside
> the point.)
>
> or something like that. What happens if you change the type to a array?
> Total rewrite..
Not even close.
In my example above:
for a in y:
dosomethingwith(a)
y could be a lot of built-in types such as an array, list, tuple, dict,
file, or set.
- Paddy.
On Wed, 13 Dec 2006 03:13:26 +0100, Paddy <·········@netscape.net> wrote:
> Not even close.
>
> In my example above:
> for a in y:
> dosomethingwith(a)
> y could be a lot of built-in types such as an array, list, tuple, dict,
> file, or set.
> - Paddy.
>
I was refering to the recursive Lisp example.
Did you even read the post?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Bjoern Schliessmann <····························@spamgourmet.com> writes:
> Can you give an example? I cannot imagine how homogenity always
> results in easiness.
CL-USER> (+ 1 2 3 4 5 6 7 8 9 10)
55
CL-USER> (< 1 2 3 4 5 6 7 8 9 10)
T
CL-USER> (< 1 2 3 4 5 6 7 8 9 10 9)
NIL
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
What are you? A pointy haired boss?
- s
Bjoern Schliessmann wrote:
> Alex Mizrahi wrote:
>
> > hell no, lisp's syntax is much easier than python's since it's
> > homogenous
>
> Can you give an example? I cannot imagine how homogenity always
> results in easiness.
>
> > (and certainly lisp was invented much 30 years before
> > Python, so that's Python uses Lisp features)
>
> I think you acknowledged that the syntax is different and not
> borrowed?
>
> [many parentheses]
> > that make logic more explicit
>
> Can you give an example?
>
> Regards,
>
>
> Björn
>
> Xpost cll,clp
>
> --
> BOFH excuse #166:
>
> /pub/lunch
samantha wrote:
> What are you? A pointy haired boss?
What are you? A 12 year old that has just learned to use Google
Groups? 8)
Regards,
Bj�rn
Xpost cll,clp
Fup2 poster
--
BOFH excuse #211:
Lightning strikes.
On Sat, 09 Dec 2006 12:43:34 +0100, Bjoern Schliessmann
<····························@spamgourmet.com> tried to confuse everyone with
this message:
>samantha wrote:
>
>> What are you? A pointy haired boss?
>
>What are you? A 12 year old that has just learned to use Google
>Groups? 8)
Says a person with a 13-line sig.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Timofei Shatrov wrote:
> Says a person with a 13-line sig.
Who? Mine was exactly three lines long.
Hint: What's "-- "?
Shrugging Regards,
Bj�rn
Fup2p
--
BOFH excuse #88:
Boss' kid fucked up the machine
On Fri, 08 Dec 2006 16:50:01 +0200, Alex Mizrahi wrote:
> (message (Hello 'Istvan)
> (you :wrote :on '(8 Dec 2006 06:11:20 -0800))
> (
>
> ??>> seems to show that Python is a cut down (no macros) version of Lisp
> ??>> with a worse performance.
>
> IA> or maybe it shows that Lisp is an obfuscated version of Python
>
> hell no, lisp's syntax is much easier than python's since it's homogenous
By that "logic" "BrainF*ck" should be even easier still, since it is even
more homogeneous, with even less syntax.
http://www.muppetlabs.com/~breadbox/bf/
Here's "Hello World" in Brainf*ck:
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++
..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
Actually, yes, it is "easier" syntax, if by easier you mean "easier for
the compiler to parse". If you mean "easier for most human beings to
read", then Lisp is easier than Brainf*ck and Python is easier than Lisp.
--
Steven.
Mark Tarver wrote:
> This confirms my suspicion
> that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.
Whoa there, that's a pretty big logical jump there, don't you think?
Consumer choice can never be boiled down to one thing; there are so
many factors. No one knows the whole answer. I certainly don't. (If
I did, I'd be courteously turning down the Nobel Prize for Economics on
account of being so rich I really didn't need the extra pocket change.)
I have no doubt that what you say is a contributing factor, but if I
had to guess the main reason why Lisp is losing out to newbies, I'd say
it's first impressions. When newbies see Python they say, "Ok, I can
kind of follow that, it doesn't look too hard to learn." When they see
Lisp they say, "WTF IS THAT???"
It's kind of sad, in a way, that a superficiality would be so crucial.
(Not that I think outward appearance is all superficial--I think humans
have evolved and/or learned to regard as beautiful that which minimizes
effort--but it's not the whole story and not basis for a whole
judgment.)
Carl Banks
"Mark Tarver" <··········@ukonline.co.uk> wrote in message
·····························@79g2000cws.googlegroups.com...
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.
Performance claims are always controversial. So, Python is much slower
doing array multiplication, when you hand roll it, instead of using the
standard numerical packages available.
I see that the effbot has already responded the first part.
(message (Hello 'Richard)
(you :wrote :on '(Fri, 8 Dec 2006 14:08:09 -0000))
(
??>> seems to show that Python is a cut down (no macros) version of Lisp
??>> with a worse performance.
RB> Performance claims are always controversial. So, Python is much slower
RB> doing array multiplication, when you hand roll it, instead of using the
RB> standard numerical packages available.
heh, do you have "standard numeric packages" for everything? maybe then
we'll make standard programs for everything -- that will obsolete "slow"
"custom scripts" and we'll just use shell to select what program we want to
run?
certainly, it's possible to write code in C and use FFI to access it, but
it's not suitable for rapid prototyping/fast development, when requirements
may change, or you're just experimenting with different methods.
it's interesting than as of bare "interpreter overhead", python is aprox
order of magnitude (10 times) slower than lisp interpreters. it's also
interesting, that python, perl, php and ruby show very similar peformance,
while lisp and scheme implementations show large improvements -- it makes me
think that there's something "pathalogically scripting" in their
specifications (maybe some obligatory use of strings for method dispatch?).
note that i've mentioned "lisp interpreters" above. as for lisp _compilers_,
they run lots faster than lisp interpreters.
please check http://shootout.alioth.debian.org/
to compare Python to Lisp SBCL. lisp is faster more then 10 times in many
benchmarks, and even more than 100 times faster in two benchmarks.
unfortunately there's no lisp interpreters (CLISP) in the benchmark.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi schrieb:
> it's also
> interesting, that python, perl, php and ruby show very similar peformance,
> while lisp and scheme implementations show large improvements -- it makes me
> think that there's something "pathalogically scripting" in their
> specifications (maybe some obligatory use of strings for method dispatch?).
"The most unusual features of the SBCL compiler (which is very similar
to the original CMUCL compiler, also known as Python) is its unusually
sophisticated understanding of the Common Lisp type system and its
unusually conservative approach to the implementation of type
declarations.
These two features reward the use of type declarations throughout
development, even when high performance is not a concern. Also, as
discussed in the chapter on performance (see Efficiency), the use of
appropriate type declarations can be very important for performance as
well."
http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types
If you'd read the docs of the tools you admire you might find the
answers yourself.
(message (Hello 'Kay)
(you :wrote :on '(8 Dec 2006 08:03:18 -0800))
(
KS> http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types
KS> If you'd read the docs of the tools you admire you might find the
KS> answers yourself.
SBCL is a COMPILER that explains everything. it's interesting why
INTERPRETER like CLISP is faster.
well, it can be type declarations as well, but maybe something other too..
for example, in languages like Python, PHP and JavaScript, as i understand,
by semantics of the language interpreter MUST use dict to call objects
method -- at any time it can be changed, for any object instance. i'm not
sure whether it has to dynamically resolve package's methods doing lookup in
packages dict.
however, in Common Lisp object methods are dispatched on object types, that
is a special language entity, so as long as new types are not introduced,
interpreter can optimize calls how it wants to. the difference is that while
it's still dynamic, dispatch over types are more controlled/optimizable than
dispatch using dict.
then, symbols in common-lisp package cannot be changed according to spec,
thus compiler/interpreter is safe to do optimizations it wants when sees
that symbols (if we want symbols with same names, we can make other package
with them).
then, Common Lisp standard defines what inlining is. i bet most
optimizations in dynamic languages are not possible if inlining is not
enabled -- since any symbol that is not inlined can change it's meaning in
any time.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi wrote:
> (message (Hello 'Kay)
> (you :wrote :on '(8 Dec 2006 08:03:18 -0800))
> (
>
> KS> http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types
>
> KS> If you'd read the docs of the tools you admire you might find the
> KS> answers yourself.
>
> SBCL is a COMPILER that explains everything. it's interesting why
> INTERPRETER like CLISP is faster.
> well, it can be type declarations as well, but maybe something other too..
I agree with your other points. Python allows the programmer to
override absolutely anything, including things like addition. This
entails extra work.
It's also worth mentioning that Clisp is an hugely optimized
interpreter. A much work has been put in to making it's bytecode
interpreting inner loops as fast as possible.
O.K. I agree with what you said about the generic function vs per
object dictionary dispatch.
But do the performance differences vanish when only builtin types and
functions are used to express Python algorithms?
(message (Hello 'Kay)
(you :wrote :on '(8 Dec 2006 12:25:09 -0800))
(
KS> O.K. I agree with what you said about the generic function vs per
KS> object dictionary dispatch.
KS> But do the performance differences vanish when only builtin types and
KS> functions are used to express Python algorithms?
no.
language semantics require python to do dict lookup on each access to some
global function (or builtin) or variable.
i don't have enough time for in-depth analysis, but here's what's it.
suppose we have
def Fib(n):
if n < 2:
return 1
else:
return Fib(n -2) + Fib(n-1)
import dis
dis.dis(Fib)
you will see this:
...
21 LOAD_GLOBAL 1 (Fib)
24 LOAD_FAST 0 (n)
27 LOAD_CONST 2 (1)
30 BINARY_SUBTRACT
31 CALL_FUNCTION 1
34 LOAD_GLOBAL 1 (Fib)
37 LOAD_FAST 0 (n)
40 LOAD_CONST 1 (2)
43 BINARY_SUBTRACT
44 CALL_FUNCTION 1
47 BINARY_ADD
48 RETURN_VALUE
now let's check what is LOAD_GLOBAL in ceval.c (i have Python 2.4.1
sources):
case LOAD_GLOBAL:
w = GETITEM(names, oparg);
if (PyString_CheckExact(w)) {
/* Inline the PyDict_GetItem() calls.
WARNING: this is an extreme speed hack.
Do not try this at home. */
long hash = ((PyStringObject *)w)->ob_shash;
if (hash != -1) {
PyDictObject *d;
d = (PyDictObject *)(f->f_globals);
x = d->ma_lookup(d, w, hash)->me_value;
if (x != NULL) {
Py_INCREF(x);
PUSH(x);
continue;
}
d = (PyDictObject *)(f->f_builtins);
x = d->ma_lookup(d, w, hash)->me_value;
if (x != NULL) {
Py_INCREF(x);
PUSH(x);
continue;
}
goto load_global_error;
}
}
/* This is the un-inlined version of the code above */
x = PyDict_GetItem(f->f_globals, w);
if (x == NULL) {
x = PyDict_GetItem(f->f_builtins, w);
if (x == NULL) {
load_global_error:
format_exc_check_arg(
PyExc_NameError,
GLOBAL_NAME_ERROR_MSG, w);
break;
}
}
Py_INCREF(x);
PUSH(x);
continue;
so we can see PyDict access. moreover, it's inlined, since it's very
performance-critical function.
but even inlined PyDict access is not fast at all. ma_lookup is a long and
hairy function containing the loop.
moreover, we can see that there are two dict lookups -- into globals and
builins.
lookup into a global hash should about order of magnitude slower than simple
table fetch, so here's the root of python's slowness.
how lisp can be faster here? lisp has SYMBOLs and well-defined semantics of
source code parsing.
first source code is processed by reader, that outputs trees of code. each
variable or function name becomes a SYMBOL object. symbols are typically
interned into packages, but they don't need to be looked-up in the packages
in runtime -- in fact, it's not possible at all.
i can read a piece of code and then unintern some symbol from package --
that will not make that code invalid. packages are used mostly by reader.
(also, i can have many symbols with same name, if they are not interned --
and they will be all different objects)
in runtime, lisp has to lookup symbol's function -- but symbol can be
implemented as a structure, and symbol-function can be just it's field
access.
one more thing -- you can see lookup into builins, so they are in dict too!
and you can see that builtins dict is checked only if name is not found in
globals, so builtins are even slower than globals. that's a reason for
performance slowdowns too.
one can say that it's the only way to change builtins in runtime. yes, but
dict lookup is a big price for it (well, if python use symbols, it would be
faster).
in fact, Common Lisp also allows to redefine "built-in" function -- you can
define a symbol with a same name as builtin in some package and use it, it
will "shadow" symbol in the common-lisp package (common-lisp:+). you can
change symbol-function of this symbol in runtime and do whatever you want.
but symbols in common-lisp package are immutable. that makes it possible to
optimize code.
and there's inlining. for example, in fib definition:
(defun fib (n)
(if (< n 2)
1
(+ (fib (- n 2))
(fib (- n 1)))))
CLISP does not even use symbol FIB in function bytecodes -- it notes that
it's a recursive function calls, so instead of normal function call it does
a local jump.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi wrote:
...
> so we can see PyDict access. moreover, it's inlined, since it's very
> performance-critical function.
> but even inlined PyDict access is not fast at all. ma_lookup is a long and
> hairy function containing the loop.
I once had a crazy idea about the lookup speed problem;
can't the lookup result be cached in the bytecode ?
I am thinking to something like saving a naked pointer
to the value together with a timestamp of the dictionary.
With timestamp I mean an integer (may be 64 bit) that is
incremented and stamped in the dictionary every time
the dictionary is modified; this counter can be
shared among all dictionaries. The use of a naked pointer
would be IMO safe because to invalidate the object you
would also need to touch the dictionary.
Using this approach the lookup for a constant
string could be
if (bytecode_timestamp == dict->timestamp)
{
// just use the stored result
}
else
{
// do standard lookup and store
// result and dict->timestamp
}
I'd expect that this would be a big win for a lot of
lookup as the problem with python speed is the *potential*
dynamism... hopefully people don't keep changing what
math.sin is during the execution so the vast majority of
lookups at module level will find the timestamp being valid.
This invalidation is not "optimal" as changing math.sin
would also invalidate any lookup on math, but IMO a lot
of lookups happen in *fixed* dictionaries and the the
overhead of checking the cached result first should be
small. What it would break is code that actually
dynamically changes the string being looked up in the
dictionary in the bytecode, but I hope those places
are few if the exist at all.
Is this worth investigation or it has already
been suggested/tried ?
Andrea
Andrea Griffini>Is this worth investigation or it has already been
suggested/tried ?<
Recently some people around the net have discussed about similar ideas
as a possible way to speed up Ruby interpreters a lot.
Bye,
bearophile
(message (Hello 'Andrea)
(you :wrote :on '(Sat, 09 Dec 2006 11:08:34 +0100))
(
??>> so we can see PyDict access. moreover, it's inlined, since it's very
??>> performance-critical function.
??>> but even inlined PyDict access is not fast at all. ma_lookup is a long
??>> and hairy function containing the loop.
AG> I once had a crazy idea about the lookup speed problem;
AG> can't the lookup result be cached in the bytecode ?
actually i don't see any reason why lookup is needed at all.
i think you can use approach similar to Lisp Symbols in Python, so it's
implementation slow, not the language.
there are some subtle differences -- for example, if you del global binding,
function gets undefined, but in Lisp uninterning does not invalidate code
that uses that symbols. but you can easily override this invalidating the
symbol bindings.
i think symbols can be implemented just as cache you suggest, but without
need of timestamp, but with additional indirection.
you should associate a SYMBOL with each entry in the globals dict, however
those SYMBOL lifetime should be managed independently (lifetime management
is one of difficulties, but i think not non-solvable). once you need to
cache lookup, you cache a SYMBOL pointer.
then you just get symbol's value on firther lookups. if dict gets update, it
should update all symbols associated with it. if entry (or whole dict) is
deleted, it should invalidate all symbols, so accessing them will produce
error, but it should not delete symbols.
you can resolve symbols not on first access, but during the read operation
(when bytecode is produced), as it's done in Lisp.
however, it's only applicable to LOAD_GLOBAL and STORE_GLOBAL, i think it
won't be possible to optimize STORE_ATTR that way without changing
semantics.
by the way, maybe some optimizations are already implemented in Psyco?
it's Python JIT with profile-guided type optimization, but i don't know how
it deals with lookups..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> wrote in message
······························@news.sunsite.dk...
> heh, do you have "standard numeric packages" for everything? maybe then we'll make
> standard programs for everything -- that will obsolete "slow" "custom scripts" and we'll
> just use shell to select what program we want to run?
No, I was observing that, faced with a matrix multiplication problem, most
sensible Python developers would do "apt-get install python-numeric" or
equivalent. Trying to do it in pure Python would be the wrong tool for the
job. If you think that's a weakness of Python compared to Lisp, then so
be it.
"Mark Tarver" <··········@ukonline.co.uk> writes:
> Paul Rubin wrote:
> > "Mark Tarver" <··········@ukonline.co.uk> writes:
> > > How do you compare Python to Lisp? What specific advantages do you
> > > think that one has over the other?
> >
> > <http://google.com/search?q=python+lisp&btnI=I'm+feeling+lucky>
>
> Thanks; a quick read of your reference to Norvig's analysis
>
> http://norvig.com/python-lisp.html
>
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance. The only substantial advantage I can see is
> that GUI, and Web libraries are standard. This confirms my suspicion
> that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.
>
> Mark
>
It is not just a newbie thing. Even people who are reasonably fluent
in Lisp use Python for many tasks, and some make python the default
with Lisp as a special case. It would probably be fair to say that
the more you know about a variety of languages, the more you
appreciate Python.
--
Harry George
PLM Engineering Architecture
I'll vouch for what Harry said. I'm definitely not a "newbie", I've
been programming since around 1982, and I am fluent in a plethora of
programming languages, not including Lisp. I have checked out Lisp
several times in the past, but I always get turned off completely by
the parenthesis you have to use for everything. What's up with that
anyway?
I had been a big C/Java/Perl developer for many years, but due to a job
change in May of 2005, I had to add Python into the mix. I had never
even given Python a second thought, but after playing around with it
for one afternoon, I had learned enough to enable me to write programs
that did what I needed them to do. I now use Python on a professional
basis almost every single day, and I can tell you with certainty that I
am far more productive with Python, then with any other language in my
arsenal.
As an aside, I recently introduced a young acquaintance to Python, as a
way to learn programming. Since he had absolutely no background in
programming, it took a little to get him going, but thanks to the ease
of use and readability of Python, he is now very confident in his work,
and asks me questions only rarely.
With Python's ease of learning and use, availability of a large number
of libraries, extremely active development community and large
user-base, I'd say the question to ask is what specific advantages over
Python does Lisp offer, to make people switch to it?
Cheers,
Howard
Harry George wrote:
> "Mark Tarver" <··········@ukonline.co.uk> writes:
>
> > Paul Rubin wrote:
> > > "Mark Tarver" <··········@ukonline.co.uk> writes:
> > > > How do you compare Python to Lisp? What specific advantages do you
> > > > think that one has over the other?
> > >
> > > <http://google.com/search?q=python+lisp&btnI=I'm+feeling+lucky>
> >
> > Thanks; a quick read of your reference to Norvig's analysis
> >
> > http://norvig.com/python-lisp.html
> >
> > seems to show that Python is a cut down (no macros) version of Lisp
> > with a worse performance. The only substantial advantage I can see is
> > that GUI, and Web libraries are standard. This confirms my suspicion
> > that Lisp is losing out to newbies because of its
> > lack of standard support for the things many people want to do.
> >
> > Mark
> >
>
> It is not just a newbie thing. Even people who are reasonably fluent
> in Lisp use Python for many tasks, and some make python the default
> with Lisp as a special case. It would probably be fair to say that
> the more you know about a variety of languages, the more you
> appreciate Python.
>
>
> --
> Harry George
> PLM Engineering Architecture
"HowiPepper" <·······@gmail.com> writes:
> With Python's ease of learning and use, availability of a large number
> of libraries, extremely active development community and large
> user-base, I'd say the question to ask is what specific advantages over
> Python does Lisp offer, to make people switch to it?
Lisp has a more uniform design geared towards large system
development. It doesn't have as many weird quirks and exceptions as
Python. It has much more serious implementations with real compilers.
There is an inevitability about the way the language works, it's just
"cosmic". The only way I can suggest to appreciate that is study an
implementation of it sometime. The parentheses really aren't a big
deal. Lisp is simply hypnotic, to those receptive to that kind of
thing. In musical terms, Python is like a Beatles song, very popular
and easy to sway and dance to. Lisp is like a Bach fugue.
"HowiPepper" <·······@gmail.com> writes:
> I have checked out Lisp several times in the past, but I always get
> turned off completely by the parenthesis you have to use for
> everything. What's up with that anyway?
It's no different from having to use newlines and spaces and square
brackets and parentheses in Python. E.g. the Lisp (f x y) is exactly
equivalent to the Python f(x, y); the Lisp (if x y z) is exactly
equivalent to the Python:
if x:
y
else:
z
There is, though, an advantage: (f x y) and (if x y z) aren't just parts
of programs--they're also lists. That means that one can use all the
list-manipulation primitives on a program, and thus that it's very easy
to write programs which manipulate programs. This in turn leads to
being able to extend the syntax of the language. Imagine if one could
write this in Python:
defsyntax unless(condition, commands):
if not condition:
commands
And use it like this:
unless day == 'Sunday':
work()
That'd be pretty cool, right? After all, 'unless day is Sunday' conveys
the sense of what you're doing a little better than 'if days is not
Sunday.' But in Python it's not possible--even my defsyntax example is
absurd: how would the compiler know the difference between pre-colon
argument and the command block? What if I wanted multiple blocks
(e.g. as with an else:)?
Whereas with Lisp one might simply write:
(defmacro unless (condition &body commands)
`(if (not ,condition)
,@commands))
When used as:
(unless (equal day "Sunday")
(work))
The compiler transforms it into:
(if (not (equal day "Sunday"))
(work))
This is a _really_ simple example (unless is nice, but it's hardly
vital); but what one can do is end up making a much more declarative
program by creating new syntax to describe stuff.
> With Python's ease of learning and use, availability of a large number
> of libraries, extremely active development community and large
> user-base, I'd say the question to ask is what specific advantages
> over Python does Lisp offer, to make people switch to it?
Well, these come to mind; they're in no order and are just my own
particular thoughts. No doubt more reflective commentators can come up
with a better list.
o Macros
As mentioned above, macros can make one's life significantly nicer. I
use Python a lot (it's currently a better choice than Lisp for many of
the problems I face), and I find myself missing macros all the time.
The ability to take some frequently-used idiom and wrap it up in a macro
is wonderful. E.g. a common idiom in Python is:
file = open(path, 'r')
for line in file.readlines():
foo(line)
bar(line)
baz(line)
Even this isn't much nicer:
for line in open(path, 'r').readlines():
foo(line)
bar(line)
baz(line)
Wouldn't it be nice to have a macro with-open-file?
filefor line in path:
foo(line)
bar(line)
baz(line)
o Speed
Lisp interpreters are several orders of magnitude faster than Python,
and Lisp compilers are faster yet. Speed's not the most important
thing, but it is _an_ important thing; all other things being equal, the
faster solution is better.
o Symbols
In Lisp, a symbol is essentially a hashed string; two symbols are alike
if their names are alike, but comparison of symbols is a constant-time
operation. Thus where in Python I have lots of string comparisons for
constants, and in C I have #defined integers, in Lisp I have symbols.
It's not just a performance hack--symbols are part of why macros and
packages work--but when I miss them, I miss them for the performance
side of things
o CLOS
The Common Lisp Object System is a really remarkable piece of work.
Among other things, it has generic functions instead of methods.
E.g. in Python or most other OO languages object.method(arg1, arg2) is
really just a fancy piece of syntactic sugar for method(object, arg1,
arg2); method does different things depending on the type of object, its
first argument.
Wouldn't it be nice to be able to specialise a method on _any_ subset of
its arguments, not just its first one? Well, CLOS offers that. (method
object1 object2) could be specialised on the first argument, the second
or both. This can be very powerful.
Wouldn't it be nice to specify that some action be taken before or after
a superclass's method, rather than over-riding that method entirely?
Sure, one can over-ride the method and then call it within one's own
code, but that obscures the meaning of what one's doing.
o CLSQL
An OR mapper which actually works. 'Nuff said.
OTOH, here's what Python offers which Lisp doesn't:
o A capable standard library
Lisp's standard library was considered large once upon a time--why, it
included lists and hashes! But that's not a big deal nowadays. Right
now there are a plethora of choices, but it's not clear which choices
are blessed or particularly good. Sure, once could use a different MIME
library than Python offers as standard, but it's good to know that there
_is_ a standard.
o A large, friendly community
Lisp's community is small and exceedingly bright; it doesn't suffer
fools gladly. Python's is larger and friendlier, realising that we were
all fools once and that with education many of us get better.
o Top-notch Web frameworks
Pylons and Django are nice to use and take care of a lot of the
boilerplate one would otherwise have to write. While Webactions is a
very cool framework, it lives at a lower level and there's a lot more
one has to add to it for a complete app.
--
Robert Uhl <http://public.xdi.org/=ruhl>
People who are willing to rely on the government to keep them safe are
pretty much standing on Darwin's mat, pounding on the door, screaming,
`Take me, take me!' --Carl Jacobs
Robert Uhl wrote:
> o Macros
>
> As mentioned above, macros can make one's life significantly nicer. I
> use Python a lot (it's currently a better choice than Lisp for many of
> the problems I face), and I find myself missing macros all the time.
> The ability to take some frequently-used idiom and wrap it up in a macro
> is wonderful. E.g. a common idiom in Python is:
>
> file = open(path, 'r')
> for line in file.readlines():
> foo(line)
> bar(line)
> baz(line)
>
> Even this isn't much nicer:
>
> for line in open(path, 'r').readlines():
> foo(line)
> bar(line)
> baz(line)
>
> Wouldn't it be nice to have a macro with-open-file?
>
> filefor line in path:
> foo(line)
> bar(line)
> baz(line)
>
You probably need to refresh your Python skills if you want to be more
productive in it. Files have been iterable for the last couple of years
(since 2.1-2.2, don't remember).
for line in open(path):
foo(line)
bar(line)
baz(line)
You can also iterate through the lines of more than one files using the
fileinput module (http://docs.python.org/lib/module-fileinput.html):
import fileinput
# iterate over the lines of the files passed as command line
# arguments (sys.argv[1:]) or sys.stdin for no arguments
for line in fileinput.input():
foo(line)
I'm sure there should be more convincing examples for macros, but
neither this nor the 'unless' syntax sugar cuts it.
George
George Sakkis wrote:
> I'm sure there should be more convincing examples for macros, but
> neither this nor the 'unless' syntax sugar cuts it.
Also, the new 'with' statement and associated
protocol covers much of the ground that was left
out by the existing constructs.
--
Greg
Robert Uhl wrote:
> o Symbols
>
> In Lisp, a symbol is essentially a hashed string;
Are you aware that strings can be interned in Python?
Furthermore, any string literal in the source that
is a syntactically valid identifier is automatically
interned, and you can intern any string explicitly
if you need. This gives you exactly the same
capabilities as symbols in Lisp.
For example, due to the automatic interning, the
string comparison in the following is just a pointer
comparison:
fred = 'hello'
if fred == 'hello':
print 'Greetings'
--
Greg
On Wed, 13 Dec 2006 16:07:01 +1300, greg <····@cosc.canterbury.ac.nz> tried to
confuse everyone with this message:
>Robert Uhl wrote:
>
>> o Symbols
>>
>> In Lisp, a symbol is essentially a hashed string;
>
>Are you aware that strings can be interned in Python?
>Furthermore, any string literal in the source that
>is a syntactically valid identifier is automatically
>interned, and you can intern any string explicitly
>if you need. This gives you exactly the same
>capabilities as symbols in Lisp.
Are you aware that you hardly know any Lisp yet make such bold and unfounded
claims? Unless interning a string somehow gives it a property list, slot value
and function value it doesn't give you the same capabilities.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Timofei Shatrov wrote:
> Are you aware that you hardly know any Lisp yet make such bold and unfounded
> claims? Unless interning a string somehow gives it a property list, slot value
> and function value it doesn't give you the same capabilities.
I'm talking about the capability of comparing symbols
efficiently by address, which Robert seemed to think
that Python couldn't do. I was pointing out that it
can, despite not having a distinct symbol type.
I know about property lists. The Pythonic way to do
the equivalent thing is using a dictionary.
I also know about the dual function/other value of
a symbol, which has alway seemed like an idiotic
feature to me. All it seems to do is make it more
awkward than necessary to deal with functions as
first class objects, which is supposedly meant to
be one of Lisp's strengths. So I regard it as a
feature that Python *doesn't* have this. :-)
--
Greg
"Mark Tarver" <··········@ukonline.co.uk> writes:
> Thanks; a quick read of your reference to Norvig's analysis
>
> http://norvig.com/python-lisp.html
>
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance. The only substantial advantage I can see is
> that GUI, and Web libraries are standard. This confirms my suspicion
> that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.
There is (IMO) some truth to that, but the flavor of Python
programming is not that much like Lisp any more. Especially with
recent Python releases (postdating that Norvig article) using iterator
and generator objects (basically delayed evaluation streams) more
heavily, Python is getting harder to describe in Lisp terms. It's
moving more in the direction of Haskell.
Paul Rubin wrote:
> "Mark Tarver" <··········@ukonline.co.uk> writes:
> > Thanks; a quick read of your reference to Norvig's analysis
> >
> > http://norvig.com/python-lisp.html
> >
> > seems to show that Python is a cut down (no macros) version of Lisp
> > with a worse performance. The only substantial advantage I can see is
> > that GUI, and Web libraries are standard. This confirms my suspicion
> > that Lisp is losing out to newbies because of its
> > lack of standard support for the things many people want to do.
>
> There is (IMO) some truth to that, but the flavor of Python
> programming is not that much like Lisp any more. Especially with
> recent Python releases (postdating that Norvig article) using iterator
> and generator objects (basically delayed evaluation streams) more
> heavily, Python is getting harder to describe in Lisp terms. It's
> moving more in the direction of Haskell.
Sorry, I missed something here. Why do you need a release to have these
sorts of things? Can't you just expand the language via macros to
create whatever facility of this sort you need... Oh, sorry. You CAN'T
expand the language.... Too bad. I guess waiting for Guido to figure
out what Fits Your Mind is part of The Python Way.
·········@gmail.com" <········@gmail.com> writes:
> > There is (IMO) some truth to that, but the flavor of Python
> > programming is not that much like Lisp any more. Especially with
> > recent Python releases (postdating that Norvig article) using iterator
> > and generator objects (basically delayed evaluation streams) more
> > heavily, Python is getting harder to describe in Lisp terms. It's
> > moving more in the direction of Haskell.
>
> Sorry, I missed something here. Why do you need a release to have these
> sorts of things? Can't you just expand the language via macros to
> create whatever facility of this sort you need...
Huh? Are you saying Lisp systems never release new versions? And you
can't implement Python generators as Lisp macros in any reasonable
way. You could do them in Scheme using call-with-current-continuation
but Lisp doesn't have that.
> Oh, sorry. You CAN'T
> expand the language.... Too bad. I guess waiting for Guido to figure
> out what Fits Your Mind is part of The Python Way.
Now I begin to think you're trolling.
> ... you can't implement Python generators as Lisp macros in any reasonable
> way. You could do them in Scheme using call-with-current-continuation
> but Lisp doesn't have that.
Well, okay, Scheme [same thing (to me), although I realize that they
aren't, quite -- and CWCC is one place where they aren't!] But I don't
follow why you can't come very close by appropriate macrification of
closures. OTOH, this could be my lack of knowledge; it's possible that
Python has somehow gone beyond what one can reasonably do in this way.
But anyway, this wasn't the point of my post; rather, my point was that
Python can't be extended at all (or at least not in the same way that
Lisp can be), not that a given extension can or cannot be done in Lisp.
·········@gmail.com" <········@gmail.com> writes:
> Well, okay, Scheme [same thing (to me), although I realize that they
> aren't, quite -- and CWCC is one place where they aren't!] But I don't
> follow why you can't come very close by appropriate macrification of
> closures.
You have to be able to return from the closure, then re-enter it
(possibly from a different place in the calling program) with all the
lexical variables intact. You have to be able to do this from
multiple places inside the closure. You have to be able to re-enter
and re-exit other such closures between the entry and exit of the
first one. This all has to work with closures that are recursive.
Yeah, Lisp macros are Turing-complete and you could basically
implement a coroutine-supporting compiler out of macros and do all of
the above, but the target language wouldn't be Lisp any more.
> Yeah, Lisp macros are Turing-complete and you could basically
> implement a coroutine-supporting compiler out of macros and do all of
> the above, but the target language wouldn't be Lisp any more.
First off, it probably would be Lisp, but this is a mere issue of
semantics. More importantly, even if I grant you that it's not trivial
(which I'm happy to so stipulate) my point was that YOU COULD do this
if YOU wanted, whereas in Python, YOU COULD NOT unless GUIDO wanted.
QED.
·········@gmail.com" <········@gmail.com> writes:
> First off, it probably would be Lisp, but this is a mere issue of
> semantics. More importantly, even if I grant you that it's not trivial
> (which I'm happy to so stipulate) my point was that YOU COULD do this
> if YOU wanted,
How?
Paul Rubin <·············@NOSPAM.invalid> writes:
> Huh? Are you saying Lisp systems never release new versions? And you
He's pretty clearly not saying that.
(message (Hello 'Paul)
(you :wrote :on '(08 Dec 2006 17:15:32 -0800))
(
PR> Huh? Are you saying Lisp systems never release new versions? And you
PR> can't implement Python generators as Lisp macros in any reasonable
PR> way. You could do them in Scheme using call-with-current-continuation
PR> but Lisp doesn't have that.
we can implement Scheme's call-with-current-continuation first :)
it's relatively easy -- just a code walker that coverts everyting into CPS.
i've used one for a web application development.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> we can implement Scheme's call-with-current-continuation first :)
> it's relatively easy -- just a code walker that coverts everyting into CPS.
It's not enough to convert to CPS, you have to be able to actually
save the continuation when you switch to another one, so you can go
back to the first one later. Maybe I'm missing something but I just
don't see how to do that in the Lisp execution model. I guess you
could write an interpreter in Lisp that simulates it all, but it might
as well be a Python interpreter ;-).
Paul Rubin wrote:
> "Alex Mizrahi" <········@users.sourceforge.net> writes:
>> we can implement Scheme's call-with-current-continuation first :)
>> it's relatively easy -- just a code walker that coverts everyting into CPS.
>
> It's not enough to convert to CPS, you have to be able to actually
> save the continuation when you switch to another one, so you can go
> back to the first one later.
You get this for free once your program is in CPS. (This is true for any
language, btw. It's just that it's easier to abstract away from the
details of CPS in Lisp.)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
(message (Hello 'Paul)
(you :wrote :on '(09 Dec 2006 02:55:49 -0800))
(
PR> "Alex Mizrahi" <········@users.sourceforge.net> writes:
??>> we can implement Scheme's call-with-current-continuation first :)
??>> it's relatively easy -- just a code walker that coverts everyting into
??>> CPS.
PR> It's not enough to convert to CPS, you have to be able to actually
PR> save the continuation when you switch to another one, so you can go
PR> back to the first one later. Maybe I'm missing something but I just
PR> don't see how to do that in the Lisp execution model.
once you convert code to CPS, you can save continuation -- that would be a
simple closure.
let's check how it works using CPS from ARNESI library.
(setq *cc* (with-call/cc (print 1) (let/cc cc cc) (print 3)))
that prints 1 and returns continuation.
when we call that contination:
(funcall *cc* nil)
it prints 3.
we can do a generator now:
(defun gen1 ()
(let (state)
(setf state
(lambda (ignored)
(with-call/cc
(loop for i upfrom 1
do (let/cc cc
(setf state cc)
i)))))
(lambda () (funcall state nil))))
(setq *gen* (gen1))
(funcall *gen*) => 1
(funcall *gen*) => 2
(funcall *gen*) => 3
then we can make a defgenerator macro so it will look like:
(defgenerator gen1 ()
(loop for i upfrom 1 do (yield i))
certainly yield is (let/cc cc (setf state cc) value)
PR> I guess you could write an interpreter in Lisp that simulates it all,
PR> but it might as well be a Python interpreter ;-).
no, we can just transform code, and it can be then compiled or whatever.
there is only additional overhead (lambda and friends) for each call/cc. all
"continuous" forms can be efficiently compiled.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Paul Rubin <·············@NOSPAM.invalid> writes:
>>
>> Sorry, I missed something here. Why do you need a release to have these
>> sorts of things? Can't you just expand the language via macros to
>> create whatever facility of this sort you need...
>
> Huh? Are you saying Lisp systems never release new versions?
The Common Lisp standard hasn't been updated in over a decade.
Moreover, one doesn't need to wait for a standard to add syntax--one
just adds it and gets on with solving the problem at hand.
> And you can't implement Python generators as Lisp macros in any
> reasonable way.
I'm pretty certain it could be done with conditions.
--
Robert Uhl <http://public.xdi.org/=ruhl>
We're going to Moe's. If we're not back, avenge our deaths.
--Homer Simpson
Robert Uhl <·········@NOSPAMgmail.com> writes:
> > And you can't implement Python generators as Lisp macros in any
> > reasonable way.
> I'm pretty certain it could be done with conditions.
It's worse than that, there was a big sub-thread about it, conclusion
seems to be it can be done but you need a code walker. I'd consider
that pretty messy, but at least slightly within the scope of
"reasonable".
Robert Uhl wrote:
> Paul Rubin <·············@NOSPAM.invalid> writes:
>> And you can't implement Python generators as Lisp macros in any
>> reasonable way.
>
> I'm pretty certain it could be done with conditions.
>
Me playing with the idea :
(in-package :cl-user)
(define-condition yield-signal (condition)
((val :initarg :val :accessor val)))
(defparameter %current-signal% nil)
(defun yield (val)
(setf (val %current-signal%) val)
(restart-case (signal %current-signal%)
(next () nil)))
(defmacro for-each (data in generator &body body)
(unless (eq in 'in)
(Error "for-each syntax error : for-each data _in_ generator"))
`(let ((%current-signal% (make-condition 'yield-signal)))
(handler-bind ((yield-signal
(lambda (condition)
(let ((,data (val condition)))
,@body
(invoke-restart 'next)))))
(funcall ,generator))))
(defun make-loop (iterations)
(lambda ()
(loop for i from 1 to iterations
do (yield i))))
(defun consumer ()
(for-each i in (make-loop 10000000)
)) ;nothing here just want to see how fast that is
#|
;this here works pretty good, it is possible to have nested generators
(defun my-loop ()
(loop for i from 1 to 4
do (yield i)))
(defun consumer ()
(for-each i in #'my-loop
(for-each j in #'my-loop
(format t "~%i: ~a j: ~a" i j))))
|#
CL-USER 307 > (time (consumer))
Timing the evaluation of (CONSUMER)
User time = 31.421
System time = 0.062
Elapsed time = 32.047
Allocation = 1160014020 bytes
0 Page faults
NIL
CL-USER 308 >
Oh god, that's slow =/
What's consing that much anyways ?
Sacha
On Fri, 08 Dec 2006 16:14:44 -0800, ········@gmail.com wrote:
>> There is (IMO) some truth to that, but the flavor of Python
>> programming is not that much like Lisp any more. Especially with
>> recent Python releases (postdating that Norvig article) using iterator
>> and generator objects (basically delayed evaluation streams) more
>> heavily, Python is getting harder to describe in Lisp terms. It's
>> moving more in the direction of Haskell.
>
> Sorry, I missed something here. Why do you need a release to have these
> sorts of things? Can't you just expand the language via macros to
> create whatever facility of this sort you need... Oh, sorry. You CAN'T
> expand the language.... Too bad.
No no, the phrase you want is "too good".
> I guess waiting for Guido to figure
> out what Fits Your Mind is part of The Python Way.
For the benefit of anyone who thinks that the troll has a point, consider
this.
In the real world, programmers aren't lone wolves stalking the programming
landscape doing their own thing. Whether we're talking open
source projects maintained by volunteers, or commercial software teams,
standardized languages are a good thing. It is a good thing that not every
hare-brained idea that some random programmer comes up with can be
implemented as part of the core language.
It is a good thing that when Fred decides to stop contributing to an
open source project (or leave the company), other people can read his code
without having to learn his Uber-Special Custom Macro Extended Language.
Even if Fred's USCMEL ran 35% faster (and thus saved an entire four
seconds on an average run with typical data!) the five or six weeks of
reduced programmer productivity when somebody else has to maintain his
code outweighs that.
--
Steven.
Steven D'Aprano wrote:
> It is a good thing that not every
> hare-brained idea that some random programmer comes up with can be
> implemented as part of the core language.
Well, that's the FUD/strawman, but nothing more. Just a hobgoblin to
keep the Pythonistas from straying. But you have an excuse: Lispniks
always /talk/ about macros giving us the ability to create a DSL. But no
one does. :) Macros mostly hide implementation -- always a good thing --
where functions cannot.
This, btw, is why Norvig brushing off macros with the ability to use
regex to parse a DSL was so disappointing.
I guess your other excuse is that your BDFL says the same thing.
All in all, this is getting pretty funny. I am starting to picture you
all (including GvR) running around with your hands over your ears going
woo-woo so you cannot hear what we are saying.
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
(message (Hello 'Ken)
(you :wrote :on '(Sat, 09 Dec 2006 04:26:02 -0500))
(
KT> keep the Pythonistas from straying. But you have an excuse: Lispniks
KT> always /talk/ about macros giving us the ability to create a DSL. But
KT> no one does. :)
certainly there's no reason to make a new DSL each day, but sometimes they
are good.
i've recently posted an example of DSL to do queries to RDF data base -- i
find it's very helpful.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi wrote:
> (message (Hello 'Ken)
> (you :wrote :on '(Sat, 09 Dec 2006 04:26:02 -0500))
> (
>
> KT> keep the Pythonistas from straying. But you have an excuse: Lispniks
> KT> always /talk/ about macros giving us the ability to create a DSL. But
> KT> no one does. :)
>
> certainly there's no reason to make a new DSL each day, but sometimes they
> are good.
> i've recently posted an example of DSL to do queries to RDF data base -- i
> find it's very helpful.
That is different. Your very objective /was/ a language. Naturally, you
created one. I am talking about PGs suggestion that the best way to
solve a problem is to create a language for that problem and then use
it. What I think happens more often is the other thing Graham said:
building up CL to be a better language for the problem. So the language
is still predominantly and visibly CL, and here and there are chunks of
macrology hiding a crapload of boilerplate.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
(message (Hello 'Steven)
(you :wrote :on '(Sat, 09 Dec 2006 20:02:06 +1100))
(
SD> It is a good thing that when Fred decides to stop contributing to an
SD> open source project (or leave the company), other people can read his
SD> code without having to learn his Uber-Special Custom Macro Extended
SD> Language. Even if Fred's USCMEL ran 35% faster (and thus saved an
SD> entire four seconds on an average run with typical data!) the five or
SD> six weeks of reduced programmer productivity when somebody else has to
SD> maintain his code outweighs that.
have you ever faced this problem?
it's not a problem at all.
and it's possible to write unmaintanable code in any langauge. for example,
Bram Cohen's BitTorrent (written in Python)
has a constructors with 21 positional parameters
class Rerequester:
def __init__(self, url, interval, sched, howmany, minpeers,
connect, externalsched, amount_left, up, down,
port, ip, myid, infohash, timeout, errorfunc, maxpeers,
doneflag,
upratefunc, downratefunc, ever_got_incoming):
and here's how it called:
rerequest = Rerequester(response['announce'],
config['rerequest_interval'],
rawserver.add_task, connecter.how_many_connections,
config['min_peers'], encoder.start_connection,
rawserver.add_task, storagewrapper.get_amount_left,
upmeasure.get_total, downmeasure.get_total, listen_port,
config['ip'], myid, infohash, config['http_timeout'], errorfunc,
config['max_initiate'], doneflag, upmeasure.get_rate,
downmeasure.get_rate,
encoder.ever_got_incoming)
i think it might be a bit hard to non-autist to remember order of parameters
in such constructor. (and it's not the only one such place in BitTorrent)
and that guy teaches us how to write maintanable code!
http://advogato.org/article/258.html
thus, you don't need macros to write unmaintanable code -- functions are
enough for this. and with macros you can make it more maintanable, actually
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
[Extensibility of syntax (via Lisp like macros)]
> In the real world, programmers aren't lone wolves stalking the
> programming landscape doing their own thing. Whether we're talking
> open source projects maintained by volunteers, or commercial
> software teams, standardized languages are a good thing. It is a
> good thing that not every hare-brained idea that some random
> programmer comes up with can be implemented as part of the core
> language.
Everything from functions over classes and class hierachies to macros
are just ways to create your own personal language, to create
abstractions.
That's the whole point of high level languages: Say it your
way. Create your (domain specific) vocabulary.
(By the way: You must really hate Guido for allowing operator
overloading in Python. It's exactly the same argument, nearly the same
wording you used, that others used against operator overloading. You
have to really love Java. :))
> It is a good thing that when Fred decides to stop contributing to an
> open source project (or leave the company), other people can read
> his code without having to learn his Uber-Special Custom Macro
> Extended Language.
You don't need macros for this kind of problem -- it's a really old
problem, independend of language. There are assembler, C, Fortran,
Java, Haskell, Lisp and many more hackers who write code, that's
really hard to understand for other people.
Heck, even in natural language there are many people who say or write
things others have really trouble to understand.
So what? Big class hierachies are always hard work to understand, even
the very best designs of mankind. There is much Python code out there,
that's really hard to understand. So Python is a bad language? No,
quite not.
So why do you think, Common Lisp or Macros are a bad thing? What's the
difference (from the perspective of understanding) between a function
foo and a macro bar? Both just transform their inputs. It's just
another form of abstraction and from time to time really quite
helpful.
--
Stefan.
Stefan Nobis <······@gmx.de> writes:
> So why do you think, Common Lisp or Macros are a bad thing? What's the
> difference (from the perspective of understanding) between a function
> foo and a macro bar? Both just transform their inputs. It's just
> another form of abstraction and from time to time really quite
> helpful.
For a long time Scheme had no macros, and Scheme developers who were
exceedingly familiar with Common Lisp were nonetheless willing to get
by without them. So I have to think macros aren't all THAT important.
Scheme did eventually get macros, but somewhat different from CL's.
Paul Rubin <·············@NOSPAM.invalid> writes:
> For a long time Scheme had no macros, and Scheme developers who were
> exceedingly familiar with Common Lisp were nonetheless willing to get
> by without them. So I have to think macros aren't all THAT important.
> Scheme did eventually get macros, but somewhat different from CL's.
Macros are important enough that all the old Scheme implementations I used
offered macros in the style of Lisp's defmacro. Lisp hackers did not have
to suffer without them when writing Scheme code.
Relatively recently, the Scheme standard was augmented with hygenic macros,
a different beast. Scheme standardizes something only when there's nearly
universal support for it, so features appear in the language standard very
slowly.
bob
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>
> It is a good thing that when Fred decides to stop contributing to an
> open source project (or leave the company), other people can read his code
> without having to learn his Uber-Special Custom Macro Extended
> Language.
And yet they have to learn his Uber-Special Custom Function Extended
Language. If adding syntax is bad, surely adding functions is bad too.
And yet, I don't see very many people arguing for a return to
unstructured code.
In fact, the ability to add syntax is as important as the ability to add
functions; it's a second order of structure.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Face it--Bill Gates is a white Persian cat and a monocle away from
being a Bond villain. --Dennis Miller
Mark Tarver wrote:
>
> Thanks; a quick read of your reference to Norvig's analysis
>
> http://norvig.com/python-lisp.html
>
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.
I'm quite interested in Lisp, at least from the perspective of seeing
how it supports particular kinds of development activities where you'd
have to "do extra laps" with languages like Python, but while it's
possible to frame lots of languages as being Lisp with something
removed, such observations neglect the origins and objectives of those
languages (and the contributions of a number of other languages).
> The only substantial advantage I can see is that GUI, and Web libraries are standard.
This is actually something of a running joke in the Python community.
There's one sort of de-facto GUI library which many people swap out for
one of the many other GUI libraries available, many of which are
actually very good and relate to modern, actively and heavily developed
graphical user interface environments. Meanwhile, Web standardisation
in the Python scene needs more attention, although there's so much
activity and so many end-to-end solutions to choose from that Python is
quite a reasonable choice for Web development.
> This confirms my suspicion that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.
There was a thread on comp.lang.lisp recently [1] where Ian Jackson of
Debian fame attempted to raise awareness of a lack of apparent
community standards for Lisp, amongst other things, at least for those
people developing software for various Free Software platforms. I think
a re-reading of the many and varied responses will give you some ideas
about where the Lisp community stands in that and in other respects.
Paul
[1]
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/ea994085b54de92d
Mark Tarver wrote:
> Paul Rubin wrote:
> > "Mark Tarver" <··········@ukonline.co.uk> writes:
> > > How do you compare Python to Lisp? What specific advantages do you
> > > think that one has over the other?
> >
> > <http://google.com/search?q=python+lisp&btnI=I'm+feeling+lucky>
>
> Thanks; a quick read of your reference to Norvig's analysis
>
> http://norvig.com/python-lisp.html
>
> seems to show that Python is a cut down (no macros) version of Lisp
> with a worse performance.
By that standard, every other mainstream dynamically typed language for
you is a cut-down version of Lisp with worse performance.
> The only substantial advantage I can see is
> that GUI, and Web libraries are standard.
Somehow you conveniently miss the fact that he stated that it is ...
1. An excellent language for his intended use.
2. Easy to use and learn.
3. Easier to read than Lisp.
4. Looks more like pseudo code than does Lisp.
Here is a quote from the same Peter Norvig
"Python has been an important part of Google since the beginning, and
remains so as the system grows and evolves. Today dozens of Google
engineers use Python, and we're looking for more people with skills in
this language."
http://www.python.org/Quotes.html
> This confirms my suspicion
> that Lisp is losing out to newbies because of its
> lack of standard support for the things many people want to do.
You confirm things too easily :-).
"Ravi Teja" <···········@gmail.com> writes:
> Mark Tarver wrote:
>>
>> seems to show that Python is a cut down (no macros) version of Lisp
>> with a worse performance.
>
> By that standard, every other mainstream dynamically typed language
> for you is a cut-down version of Lisp with worse performance.
Pretty much;-)
Fewer features, worse performance. Why use 'em? In my case, because
the standard library is larger, and because I can get my teammates to
use 'em.
--
Robert Uhl <http://public.xdi.org/=ruhl>
When you disarm your subjects you offend them by showing that either
from cowardliness or lack of faith, you distrust them; and either
conclusion will induce them to hate you.
--Niccolo Machiavelli, The Prince
Robert Uhl wrote:
> "Ravi Teja" <···········@gmail.com> writes:
>
> > Mark Tarver wrote:
> >>
> >> seems to show that Python is a cut down (no macros) version of Lisp
> >> with a worse performance.
> >
> > By that standard, every other mainstream dynamically typed language
> > for you is a cut-down version of Lisp with worse performance.
>
> Pretty much;-)
>
> Fewer features, worse performance. Why use 'em?
Usability. Especially when users quote a very significant difference
here.
One overlooked advantage for Lisp over Python is a better development
environment, for me that means Slime for Lisp. For Python I have
several years of experience with IDLE and the win32 Ide, and Slime is
the winner. Press a key and the function you are editing is recompiled
and loaded into memory. The crossreference and the object inspector is
very nice. How about fuzzy-complete, I only have to write de-me and
press tab, and I get define-method-combination.
Slime coupled with the paredit structured editing mode, which lets you
edit Lisp code as list structure rather than characters, is a dream.
Pythons advantages are:
Faster startup-time which makes it a good scripting language.
More platforms, there is no Common Lisp on Nokia phones.
Some clever details, like using minus to index vectors from the right.
(aref "hello" -1) gives an error on Lisp, but the character o on
Python.
Another detail I like is that you can choose how to quote strings, in
Python you can write three double-quotes to start a string that can
include anything, quotes, doublequotes and newlines.
You can use double-quote if you want to embed single-quotes "john's" or
single-quote if you want to embed double-quotes '<id="2">'.
Talking about Lisps advantages will take me too long.
/hankhero, a switcher.
hankhero wrote:
[...]
> Pythons advantages are:
> Faster startup-time which makes it a good scripting language.
I agree with the others (especially the cleverness of Python's string
quoting), but on my machine, SBCL starts up and runs a "Hello World"
program a bit faster than Python, and CLisp really blows its doors off.
Cheers, Pillsy
Pillsy <·········@gmail.com> wrote:
+---------------
| hankhero wrote:
| > Pythons advantages are:
| > Faster startup-time which makes it a good scripting language.
|
| ... but on my machine, SBCL starts up and runs a "Hello World"
| program a bit faster than Python, and CLisp really blows its doors off.
+---------------
On my various machines, CMUCL startup is *slightly*
faster than CLISP, but both are under 20 ms...
I use Common Lisp for scripting a *lot*!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
hankhero schrieb:
> Some clever details, like using minus to index vectors from the right.
> (aref "hello" -1) gives an error on Lisp, but the character o on Python.
It would not be difficult to add this feature to Lisp.
> Another detail I like is that you can choose how to quote strings, in
> Python you can write three double-quotes to start a string that can
> include anything, quotes, doublequotes and newlines.
> You can use double-quote if you want to embed single-quotes "john's" or
> single-quote if you want to embed double-quotes '<id="2">'.
You could add a reader macro in Lisp that allows you to do the same.
At the moment I would say that one could pretty much add most Python
features to Lisp. Be it slicing, list comprehension, or, if one wants,
Pythons object system.
On the other hand can I see difficulties in adding macros to Python,
or inventing a new object system, or adding new keywords without
changing the sources of Python itself.
Andr�
--
André Thieme wrote:
> On the other hand can I see difficulties in adding macros to Python,
> or inventing a new object system, or adding new keywords without
> changing the sources of Python itself.
Actually, an even bigger difficulty is the rejection of programmable
syntax by Guido, both for the near and distant future:
"Programmable syntax is not in Python's future -- or at least it's not
for Python 3000. The problem IMO is that everybody will abuse it to
define their own language. And the problem with that is that it will
fracture the Python community because nobody can read each other's code
any more."
http://mail.python.org/pipermail/python-3000/2006-April/000286.html.
George
On Fri, 08 Dec 2006 08:50:41 -0800, George Sakkis wrote:
> Andr� Thieme wrote:
>
>> On the other hand can I see difficulties in adding macros to Python,
>> or inventing a new object system, or adding new keywords without
>> changing the sources of Python itself.
>
> Actually, an even bigger difficulty is the rejection of programmable
> syntax by Guido, both for the near and distant future:
Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.
> "Programmable syntax is not in Python's future -- or at least it's not
> for Python 3000. The problem IMO is that everybody will abuse it to
> define their own language. And the problem with that is that it will
> fracture the Python community because nobody can read each other's code
> any more."
>
> http://mail.python.org/pipermail/python-3000/2006-April/000286.html.
I couldn't have said it better myself.
--
Steven.
Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 08:50:41 -0800, George Sakkis wrote:
> Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.
>
> > "Programmable syntax is not in Python's future -- or at least it's not
> > for Python 3000. The problem IMO is that everybody will abuse it to
> > define their own language. And the problem with that is that it will
> > fracture the Python community because nobody can read each other's code
> > any more."
> >
> > http://mail.python.org/pipermail/python-3000/2006-April/000286.html.
>
> I couldn't have said it better myself.
This is sort of the top-down philosophy, where you have a "benevolent
dictator" rather than more of a democracy. (People actually call them
benevolent dictators.) Like any other top-down society, the benevolent
dictator tells you that he and his lieutenants are merely protecting
you against anarchism; terrible things will happen if you have too much
freedom.
However, I am paid to write Common Lisp, I've recently seen a terribly
unreadable codebase, and the problem wasn't macros -- merely overuse of
global vars. Nothing exotic.
Do we ban loops and recursion because we face infinite looping? Or, as
"power users," do we do the obvious, which is to learn how to use power
correctly?
How do Lisp users deal with a powerful weapon like macros? Well first,
many people don't define new ones. Instead, they use someone else's
time-tested macros, from some library. However, when they do use
macros, it's to make less readable code more readable.
Is all Python code readable? I somehow doubt it. Is the pressure from
experienced Python users stretching Python away from a clean design? I
suspect it is. (Though I could be wrong, as I don't pay close attention
to Python at the moment.)
I'm not trying to convince anyone that Lisp's radical flexibility here
is "better", just there's a different perspective to consider than what
Guido says. Many in the Lisp community have noticed the frequency of
sentences starting with "Guido said" from the Python world, and maybe
that sounds as disturbing to heavy Lisp users as macros sound to heavy
Python users.
Tayssir
--
"Patriotism is usually the refuge of the scoundrel. He is the man who
talks the loudest."
-- Mark Twain, 1908
Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 08:50:41 -0800, George Sakkis wrote:
>
>
>>Andr� Thieme wrote:
>>
>>
>>>On the other hand can I see difficulties in adding macros to Python,
>>>or inventing a new object system, or adding new keywords without
>>>changing the sources of Python itself.
>>
>>Actually, an even bigger difficulty is the rejection of programmable
>>syntax by Guido, both for the near and distant future:
>
>
> Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.
>
>
>>"Programmable syntax is not in Python's future -- or at least it's not
>>for Python 3000. The problem IMO is that everybody will abuse it to
>>define their own language. And the problem with that is that it will
>>fracture the Python community because nobody can read each other's code
>>any more."
>>
>>http://mail.python.org/pipermail/python-3000/2006-April/000286.html.
>
>
> I couldn't have said it better myself.
No, but you could have quoted it more completely <g>:
> But please save your breath. Programmable syntax is not in Python's
> future -- or at least it's not for Python 3000. The problem IMO is
> that everybody will abuse it to define their own language. And the
> problem with that is that it will fracture the Python community
> because nobody can read each other's code any more.
The last time c.l.l and c.l.p went to friendly war over macros we kept
wondering why macros were any less comprehensible than functions or
classes. Here it is!:
>
> It's one thing to read code that calls an external function whose
> meaning you have to guess from its name. It's quite another thing to
> realize that you can't even know for sure where the function calls
> are. Let's not go there.
GvR seems to be thinking of something like the loop macro, which in its
most commonly used syntax (it has two!) constitutes a distinct and
unlispy language. If that is how macros were normally used (LOOP is
quite abnormal) then, yikes, every macro could introduce a new language
to be mastered.
Uhhhh, that is not how macros are used normally. And it is a helluva lot
of work to erect a new syntax as LOOP does, so it is not exactly
tempting. So... is GvR being scared off by a straw man?
The other possibility is that he is just trying to justify not doing it
because it would be so hard without the regular syntax of Lisp,
including parens, and with the JIT module resolution problem discussed
earlier in his remarks. Understandable.
A final good reason is, hey, we already /have/ Lisp, Python needs to be
different in order not to get absorbed into the mother of all languages.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
> The other possibility is that he is just trying to justify not doing it
> because it would be so hard without the regular syntax of Lisp,
> including parens, and with the JIT module resolution problem discussed
> earlier in his remarks. Understandable.
I am surprised that no one brought up Logix yet.
http://livelogix.net/logix/
Macros are perfectly doable in Python while still preserving the white
space syntax. And Python is sufficiently pliable with it's dynamism to
implement this without changing the compiler. And yet, no one cares
about this project and it is effectively dead.
So it is not about technical difficulties. It is not about Python
community not having the opportunity to try out the power of macros.
The Python community on the whole does not think macros as useful.
Personally, I find it strange that we, who argued so many times for
dynamic typing, the need for expressiveness and that it is OK to trust
the programmer with power ("we are all adults here" argument) while
arguing against relatively restrictive languages like Java find macros,
a chaotic and disruptive concept.
On Sat, 09 Dec 2006 14:40:07 -0800, webraviteja wrote:
> Personally, I find it strange that we, who argued so many times for
> dynamic typing, the need for expressiveness and that it is OK to trust
> the programmer with power ("we are all adults here" argument) while
> arguing against relatively restrictive languages like Java find macros,
> a chaotic and disruptive concept.
Why? The benefit of expressiveness and power isn't monotonically
increasing. Look at us: we're all communicating in a common language,
English, and we all agree on syntax and grammar. Now, I could be a lot
more expressive, and language could be a lot more powerful, if I could
define my own language where "You are a poopy-head" was in fact a detailed
and devastatingly accurate and complete explanation for why Python was a
better language than Lisp. You, however, not being an expert in my far
greater expressive language, would see none of that, and would be under
the mistaken impression that I was insulting you.
So it is good that English restricts the expressiveness and power of the
syntax and grammar. While we're talking English, we can both understand
each other, and in fact people who redefine words and ignore the common
meaning of them are often covering weaknesses in their arguments.
The same goes for programming languages. Extra expressiveness comes at the
cost of reduced communication between programmers -- the code becomes
harder to read for those who haven't already learnt how to read it. So
there is no contradiction in the positions that "we are all adults here"
and "macros give too much power". The first is a design decision, the
second is a trade-off, just like the lack of C-style pointers in Python is
a trade-off.
--
Steven.
In article
<·····························@REMOVE.THIS.cybersource.com.au>,
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
> So it is good that English restricts the expressiveness and power of the
> syntax and grammar. While we're talking English, we can both understand
> each other, and in fact people who redefine words and ignore the common
> meaning of them are often covering weaknesses in their arguments.
Ohh, can the guy who does discourse analysis for a (meager) living
respond to this?
To start with, English does not restrict the expressiveness and
power of the syntax and grammar. People who use the English language
in specific communities and in specific forms of discourse do. The
key to how this happens occurs on another layer of how language
works which is almost always left out of internet discussions of
language: pragmatics.
Here is the way it works on usenet. You write, "...English
restricts the expressiveness and power of the syntax and grammar."
And I write, "You should probably do a bit of casual reading into
human linguistics before you make such silly statements."
In general however, there is this great mechanism embedded in human
communication called "feedback." Statements that are unclear or
misunderstood are met with a blank stare, "huh?" or "???" depending
on medium, mode and context variables.
> The same goes for programming languages. Extra expressiveness comes at the
> cost of reduced communication between programmers -- the code becomes
> harder to read for those who haven't already learnt how to read it.
Well, extending this analogy to programming languages, the same
social mechanisms are in effect. In addition to the technical syntax
of computer languages, there is also a fair amount of pragmatics
involved. Lisp code is expected to conform to a lisp style, and
python code is expected to conform to a python style. Developments
that run counter to that style are more likely to be rejected than
developments that conform to that style.
http://www.python.org/doc/essays/styleguide.html
http://www.lisp.org/table/style.htm
On Sun, 10 Dec 2006 04:03:25 +0000, Kirk Sluder wrote:
> In article
> <·····························@REMOVE.THIS.cybersource.com.au>,
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
>
>> So it is good that English restricts the expressiveness and power of the
>> syntax and grammar. While we're talking English, we can both understand
>> each other, and in fact people who redefine words and ignore the common
>> meaning of them are often covering weaknesses in their arguments.
>
> Ohh, can the guy who does discourse analysis for a (meager) living
> respond to this?
>
> To start with, English does not restrict the expressiveness and
> power of the syntax and grammar.
Really? There are no restrictions whatsoever in English syntax and
grammar? None at all?
So, when I say "sits cat rat" it is not only legal English, but you can
tell which animal is sitting on which?
And if I write "i helped my uncle jack off a horse" with no punctuation or
capitalisation, you can tell which of the two meanings I mean?
Although it isn't strictly syntax or grammar, you also understand
precisely what I mean when I say "the gostak distims the doshes" --
because, as you say, English has no restrictions.
And if I write "You are an idiot", you'll understand that in *my* version
of English "You" means watermelon, "are" means to grow, "an" means best,
and "idiot" means in the summertime, and naturally you won't be offended.
But I'm belaboring the point. Of course English has restrictions in
grammar and syntax -- otherwise one could write something in Latin or
Thai or Mongolian and call it English. There are RULES of grammar and
syntax in English, which means that there are possible expressions which
break those rules -- hence there are expressions which one can't write in
legal English.
That doesn't mean that there are concepts which one can't express in legal
English (although there may be). But we can communicate in English because
when I write "Fred hit Barney with a stick" we both agree that it was Fred
who did the hitting, not Barney or the stick, and Barney was the victim.
If English had no grammatical restrictions, we couldn't agree who hit whom
with what.
--
Steven.
In article
<······························@REMOVE.THIS.cybersource.com.au>,
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
> On Sun, 10 Dec 2006 04:03:25 +0000, Kirk Sluder wrote:
>
> > In article
> > <·····························@REMOVE.THIS.cybersource.com.au>,
> > Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
> >
> >> So it is good that English restricts the expressiveness and power of the
> >> syntax and grammar. While we're talking English, we can both understand
> >> each other, and in fact people who redefine words and ignore the common
> >> meaning of them are often covering weaknesses in their arguments.
> >
> > Ohh, can the guy who does discourse analysis for a (meager) living
> > respond to this?
> >
> > To start with, English does not restrict the expressiveness and
> > power of the syntax and grammar.
>
> Really? There are no restrictions whatsoever in English syntax and
> grammar? None at all?
Of course I didn't say that: What I said was, "To start with,
English does not restrict the expressiveness and
power of the syntax and grammar. People who use the English language
in specific communities and in specific forms of discourse do. The
key to how this happens occurs on another layer of how language
works which is almost always left out of internet discussions of
language: pragmatics."
As an example of the context-specific nature of pragmatics at work,
if I was your reviewer or editor, I'd reject this manuscript. As a
participant on usenet, I'll just point out that you selectively
quoted the antithesis, and deleted my thesis to argue a straw-man.
Of course there are restrictions, *enforced by users of language in
specific communities.* But the English language is quite malleable,
and includes not only the discourse we are currently engaged in, but
the clipped jargon of internet chat and amateur radio, the
chronically passive discourse of academia, the passionate chants of
protesters, and a wide variety of poetic expression.
This is where wannabe critics of "English grammar" fail to
understand the language they claim to defend, much to the amusement
of those of us who actually do study language as it is, rather than
the mythical eternal logos we want it to be.
Languages are (with some trivial exceptions) human creations. The
laws, rules and restrictions of languages are dynamic and dependent
on community, mode, medium and context. Of course, wannabe
grammarians frequently rise up at this point and say that if such is
the case, then there is nothing to prevent <language of choice> from
devolving into a babble of incomprehensible dialects. To which the
easy response is that the benefits of conformity to linguistic
communities almost always outweigh the costs of nonconformist
expression.
And if you want to bring this back around to computer languages, the
benefits of conformity to said linguistic communities tends to
outweigh the costs of doing your own thing. (Unless you can make a
convincing argument that "doing your own thing" is superior.)
> So, when I say "sits cat rat" it is not only legal English, but you can
> tell which animal is sitting on which?
What is "legal" in English depends on the communities in which you
are currently participating. Likely there is some community in which
such clipped discourse is understood and therefore legal. If you are
talking to me, I'd express my lack of comprehension by saying
"Pardon?" and ask you to rephrase.
> But I'm belaboring the point. Of course English has restrictions in
> grammar and syntax -- otherwise one could write something in Latin or
> Thai or Mongolian and call it English. There are RULES of grammar and
> syntax in English, which means that there are possible expressions which
> break those rules -- hence there are expressions which one can't write in
> legal English.
When you make an "illegal" statement in English, exactly who or what
corrects you?
Is it Zeus, the divine Logos, the flying spaghetti monster, some
platonic ideal?
As you can probably tell, this kind of silliness is a bit of a sore
spot for me. So please by all means, do some basic reading of
linguistics before you continue to engage in such silliness. Or at
least learn to properly quote an argument.
On Sun, 10 Dec 2006 06:40:46 +0000, Kirk Sluder wrote:
>> > To start with, English does not restrict the expressiveness and
>> > power of the syntax and grammar.
>>
>> Really? There are no restrictions whatsoever in English syntax and
>> grammar? None at all?
>
> Of course I didn't say that: What I said was, "To start with,
> English does not restrict the expressiveness and
> power of the syntax and grammar. People who use the English language
> in specific communities and in specific forms of discourse do.
Hang on... are you saying that *people* create languages?
*slaps head*
And here I was thinking that languages fell from the sky like donuts!
Gosh, thank you for explaining that too me. What a fool I must seem!
By the way, that was sarcasm. Of course the English language doesn't exist
in a vacuum. Of course people -- not rocks, not trees, not the Greek
Furies, and especially not the Academie Francaise -- create languages.
And, as an Australian in a world dominated by Americans, I know damn well
that different communities of English speakers use different rules.
*Slightly* different rules. That's why Standard American English and
British English are both English, not different languages like Italian and
German or Korean and Russian.
[snip]
> As an example of the context-specific nature of pragmatics at work,
> if I was your reviewer or editor, I'd reject this manuscript.
Perhaps you should find out what "manuscript" means before talking about
rejecting one, because what I wrote was most certainly not a manuscript in
any English language I'm aware of.
> As a
> participant on usenet, I'll just point out that you selectively
> quoted the antithesis, and deleted my thesis to argue a straw-man.
Look, I was arguing a really simple point: for communication to occur
between two individuals, both people must agree on a set of rules for the
language that they use to communicate. If they don't have a common
language with agreed upon rules, communication will be feeble and weak, if
not non-existent, or there will be misunderstandings and errors.
Is that so hard to grasp? If you ask for "fire water", by which you
mean whiskey, but I understand to be petrol (gasoline), you're going
to be a very sick person indeed if you drink what I give you.
> Of course there are restrictions, *enforced by users of language in
> specific communities.* But the English language is quite malleable,
> and includes not only the discourse we are currently engaged in, but
> the clipped jargon of internet chat and amateur radio, the
> chronically passive discourse of academia, the passionate chants of
> protesters, and a wide variety of poetic expression.
Did I say it wasn't malleable? You are attacking me for things I never
said.
> This is where wannabe critics of "English grammar" fail to
> understand the language they claim to defend, much to the amusement
> of those of us who actually do study language as it is, rather than
> the mythical eternal logos we want it to be.
Ho ho ho, have you ever jumped to a foolish conclusion. You think I'm one
of those tiresome bores who think that just because the ancient Romans
couldn't end a sentence with a preposition, English shouldn't either?
Puh-lease!
> Languages are (with some trivial exceptions) human creations. The
> laws, rules and restrictions of languages are dynamic and dependent
> on community, mode, medium and context. Of course, wannabe
> grammarians frequently rise up at this point and say that if such is
> the case, then there is nothing to prevent <language of choice> from
> devolving into a babble of incomprehensible dialects. To which the
> easy response is that the benefits of conformity to linguistic
> communities almost always outweigh the costs of nonconformist
> expression.
Yes yes, you're really passionate about language, you have little respect
for grammarians, blah blah blah. None of that has the slightest relevance
to what I was talking about. I'm not denying that languages evolve and
mutate. I'm talking about the simple fact -- and it is a fact -- that two
people must share at least some common linguistic concepts in order
to communicate, and the fewer common constructs they share, the worse
the communication. Languages accomplish that through rules. Yes, the
rules are mere conventions, and can change. They're still rules.
Some languages have very strict rules, some have very flexible rules, but
they all have rules and they all restrict how you use the language.
English has a rule that you turn "programmer" into a plural by adding
"s" to the end. If you decide to drop the -er and add -ing instead, as in
"I hired a team of six programming this week", at best people will do a
double-take and be forced to work out what you mean from context. If you
decide to make the plural of programmer by deleting the first and last
three characters, nobody will have any idea what drugs you are smoking.
[snip]
>> So, when I say "sits cat rat" it is not only legal English, but you can
>> tell which animal is sitting on which?
>
> What is "legal" in English depends on the communities in which you
> are currently participating. Likely there is some community in which
> such clipped discourse is understood and therefore legal.
Oh yes, the mythical "some community". Nope, sorry, I don't buy it. That's
not legal in any English dialect I've come across, and I've dealt with --
and still do -- English speakers from all over the world. No English
language or dialect typically puts the verb in front of both the object
and subject for present tense expressions. It isn't just *clipped*, the
word order is completely different from English. Didn't you notice that?
But in fact even if there is some obscure dialect of English that would
allow that, that doesn't change my point that there are some constructs
which aren't legal in English (as it exists today). If not "sit cat rat",
something else.
No doubt you can come up with some particular idiomatic phrase in English
that puts the verb first, or a different grammatical construct like the
imperative tense, e.g. "Sit on the rat, cat!". Poetry, in particular,
sometimes uses the verb-subject-object order. But these exceptions merely
emphasis that English, unlike Gaelic, doesn't normally write
verb-subject-object.
A language that was so radically different from all the other English
dialects as to allow "sits cat rat" as a typical construct wouldn't be
English. It might be a pidgin or a creole language. But it won't be
English, not now. In the indefinite future, who knows? I'm not saying that
languages are carved in stone, never to change -- that would be stupid.
But at any one time, languages have rules, even if those rules change over
time, and if two people disagree on those rules, communication is hurt, up
to the point of stopping communication completely.
> If you are
> talking to me, I'd express my lack of comprehension by saying
> "Pardon?" and ask you to rephrase.
And how unfortunate for you that in my local community, "pardon" is the
worst insult imaginable and I punch you in the face.
(See, you aren't the only one that can just invent local communities
with implausible variations of English.)
>> But I'm belaboring the point. Of course English has restrictions in
>> grammar and syntax -- otherwise one could write something in Latin or
>> Thai or Mongolian and call it English. There are RULES of grammar and
>> syntax in English, which means that there are possible expressions which
>> break those rules -- hence there are expressions which one can't write in
>> legal English.
>
> When you make an "illegal" statement in English, exactly who or what
> corrects you?
>
> Is it Zeus, the divine Logos, the flying spaghetti monster, some
> platonic ideal?
No. Your peers or your parents or your editor or your teachers correct
you. Or you get a reputation for being "stupid" and people start treating
you as if you were stupid -- maybe they start talk-ing ver-y slow-ly at
you, using baby words. Or people just find it difficult to communicate
with you, or misunderstand what you are trying to say.
There is no law of physics that says that people can't say "Head on my hat
I put". But English speakers just don't do it, and when somebody does,
they are treated as if they aren't speaking English.
But notice that semantics is important -- if I were to say "Head on my
pillow I lay", chances are good that I'd be treated as speaking
poetically, rather than as a non-English speaker. We commonly lay our head
on our pillow, but put our hat on our head.
> As you can probably tell, this kind of silliness is a bit of a sore
> spot for me. So please by all means, do some basic reading of
> linguistics before you continue to engage in such silliness. Or at
> least learn to properly quote an argument.
Before patronizing me, do make the effort to understand what I am saying.
Just because you've got valid concerns about ignorant grammarians doesn't
excuse your carelessness. Instead of reading what I actually wrote, you
read into it what you wanted to see: another stupid wanna-be grammarian
who thinks that languages are frozen, static, dead things. You couldn't be
more wrong, and your repeated assumption -- and that's all it was, just an
assumption -- that I know nothing about linguistics is shameful.
Are you man enough to acknowledge your error, or are you going to continue
this ridiculous charade of attacking me for holding views I don't have?
--
Steven.
In article
<······························@REMOVE.THIS.cybersource.com.au>,
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
> And here I was thinking that languages fell from the sky like donuts!
> Gosh, thank you for explaining that too me. What a fool I must seem!
Certainly that is what you wrote. If you had not meant that English
enforces restrictions on expressiveness, perhaps you should not have
written it.
> Look, I was arguing a really simple point: for communication to occur
> between two individuals, both people must agree on a set of rules for the
> language that they use to communicate. If they don't have a common
> language with agreed upon rules, communication will be feeble and weak, if
> not non-existent, or there will be misunderstandings and errors.
No, in that post you are arguing a straw man. In this post you seem
to be agreeing with me while acting like you disagree.
If we both agree that the rules of languages are social, then we
should both agree that in the case of programming language,
communities of language users help to constrain how the language is
used by rejecting extensions that are not lispy/pythonic, and
accepting extensions that converge with accepted style.
> No. Your peers or your parents or your editor or your teachers correct
> you. Or you get a reputation for being "stupid" and people start treating
> you as if you were stupid -- maybe they start talk-ing ver-y slow-ly at
> you, using baby words. Or people just find it difficult to communicate
> with you, or misunderstand what you are trying to say.
And likewise, if you propose a construct that is unlispy/unpythonic,
that construct is not likely to be adopted by the community of
computer language users.
Since you are apparently in complete agreement with the post you
dishonestly quoted out of context, I don't see where we have an
argument.
> Before patronizing me, do make the effort to understand what I am saying.
I understand what you wrote. Perhaps your problem is that in your
rhetoric zest you chose to dishonestly attack a strawman, and chose
to defend a position you now claim not to hold.
> Are you man enough to acknowledge your error, or are you going to continue
> this ridiculous charade of attacking me for holding views I don't have?
I have no way of knowing the views that you have, only the views
that you write. And if you don't write what you mean, I have no way
of understanding that you are really in agreement with me, when you
attack something I did not say.
On Sun, 10 Dec 2006 14:35:07 +0000, Kirk Sluder wrote:
> In article
> <······························@REMOVE.THIS.cybersource.com.au>,
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
>
>> And here I was thinking that languages fell from the sky like donuts!
>> Gosh, thank you for explaining that too me. What a fool I must seem!
>
> Certainly that is what you wrote. If you had not meant that English
> enforces restrictions on expressiveness, perhaps you should not have
> written it.
Okay, I'm trying to meet a common ground here, but you're not making it
easy. Of course English, like all languages, restricts what can be said in
that language. I'm talking about grammar and syntax, not semantics, just
like I said at the beginning.
I don't expect that there are concepts that can't be expressed in English
(although some linguists disagree -- see the Sapir-Whorf hypothesis). But
there are many restrictions on *how* we express things. That means that
some concepts can't be expressed as briefly and succinctly in English as
in other languages (and, naturally, vice versa).
Oh, you might also like to look up what a straw-man argument is before
continuing to accuse people of making it. There seems to be this myth on
the Internet and Usenet that a straw-man argument is "any argument I don't
like, or don't understand, or can't refute".
> If we both agree that the rules of languages are social, then we
> should both agree that in the case of programming language,
> communities of language users help to constrain how the language is
> used by rejecting extensions that are not lispy/pythonic, and
> accepting extensions that converge with accepted style.
That might be true in the case of public code which is open to the entire
community, but it isn't true of all code. Not all code is open to the
wider programmer community to inspect. Code gets written in small teams,
or by individuals, and then it gets used by potentially millions of people
who never got to review the code but have to suffer the consequences of
any bugs in it.
(I'm not saying this is uniquely a problem caused by Lisp macros. Don't
misinterpret what I'm saying.)
--
Steven.
In article
<······························@REMOVE.THIS.cybersource.com.au>,
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
> On Sun, 10 Dec 2006 14:35:07 +0000, Kirk Sluder wrote:
>
> > In article
> > <······························@REMOVE.THIS.cybersource.com.au>,
> > Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
> >
> >> And here I was thinking that languages fell from the sky like donuts!
> >> Gosh, thank you for explaining that too me. What a fool I must seem!
> >
> > Certainly that is what you wrote. If you had not meant that English
> > enforces restrictions on expressiveness, perhaps you should not have
> > written it.
>
> Okay, I'm trying to meet a common ground here, but you're not making it
> easy. Of course English, like all languages, restricts what can be said in
> that language. I'm talking about grammar and syntax, not semantics, just
> like I said at the beginning.
Well again, the question is exactly *what* is doing the restricting?
What will happen if you make an "illegal" statement in English? If
you can't define some sort of mechanism inherent in the English
language that prevents the expression of "illegal" utterances, then
you can't make the claim that "English. .. restricts what can be
said in that language." This is a technical point, but not a
trivial one. That is one heck of an active verb that you are
attributing to an extremely passive noun.
If you want common ground, it appears that we both agree that
language practices are enforced by social communities. Is this not
the case?
> Oh, you might also like to look up what a straw-man argument is before
> continuing to accuse people of making it. There seems to be this myth on
> the Internet and Usenet that a straw-man argument is "any argument I don't
> like, or don't understand, or can't refute".
Certainly. A straw man is an artificially weak position that you
attribute to your opponent. You chose to argue against the
artificially weak position of "there are no rules." You attributed
that position to me, not acknowledging my stated position. In what
way is this not a straw man?
You now claim to agree with the position I actually stated: language
is restricted by social communities that use language. If we both
agree on this position, we can move on back to the discussion on how
those norms and practices discriminate against unlispy/unpythonic
language extensions.
> That might be true in the case of public code which is open to the entire
> community, but it isn't true of all code. Not all code is open to the
> wider programmer community to inspect. Code gets written in small teams,
> or by individuals, and then it gets used by potentially millions of people
> who never got to review the code but have to suffer the consequences of
> any bugs in it.
What do people who don't need to read code, or don't need access to
code matter in regards to code readability?
And yes, small teams do constitute a linguistic community of
practice as well. But I don't know of many small teams who don't
have histories as members of larger communities of practice.
> (I'm not saying this is uniquely a problem caused by Lisp macros. Don't
> misinterpret what I'm saying.)
Which comes back around again to my constant question. Why do these
threads consider macros as a way to extend the language so much more
of an obfuscatory threat compared to other methods of language
extension: (including libraries, operator overloading, and
polymorphism?)
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> Look at us: we're all communicating in a common language, English,
> and we all agree on syntax and grammar. Now, I could be a lot more
> expressive, and language could be a lot more powerful, if I could
> define my own language where "You are a poopy-head" was in fact a
> detailed and devastatingly accurate and complete explanation for why
> Python was a better language than Lisp.
> So it is good that English restricts the expressiveness and power of
> the syntax and grammar. While we're talking English, we can both
> understand each other, and in fact people who redefine words and
> ignore the common meaning of them are often covering weaknesses in
> their arguments.
Uh, you don't talk often to non-programmers, do you? Talk a bit to
non-programmers about your programming habits, why you prefer which
programming language and so on. Everything in english. How much do
they understand?
Ever talked to skateboarders? Other people of different scenes? They
are creating new, specialized languages every day. Here in Germany a
study was published a little time ago, how few people understand
commercials and their slogans.
Do you know how many jokes work? Yes, by misunderstandings. Why is
this? Because (natural) languages have macros, operator overloading
and all this fuss.
I'm no expert, I not really studied linguistics, but I would say, you
are completley wrong.
--
Stefan.
On Sun, 10 Dec 2006 15:05:04 +0100, Stefan Nobis wrote:
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>
>> Look at us: we're all communicating in a common language, English,
>> and we all agree on syntax and grammar. Now, I could be a lot more
>> expressive, and language could be a lot more powerful, if I could
>> define my own language where "You are a poopy-head" was in fact a
>> detailed and devastatingly accurate and complete explanation for why
>> Python was a better language than Lisp.
>
>> So it is good that English restricts the expressiveness and power of
>> the syntax and grammar. While we're talking English, we can both
>> understand each other, and in fact people who redefine words and
>> ignore the common meaning of them are often covering weaknesses in
>> their arguments.
>
> Uh, you don't talk often to non-programmers, do you?
Oh, if you only knew!
> Talk a bit to
> non-programmers about your programming habits, why you prefer which
> programming language and so on. Everything in english. How much do
> they understand?
That depends on how much jargon I use. Jargon, I should point out, is not
necessarily a pejorative term. It can just mean vocabulary used
only in a specialist field, and as such, jargon is very, very important.
> Ever talked to skateboarders? Other people of different scenes? They
> are creating new, specialized languages every day.
Yes, that's right. And if they insist on using their specialist language
where "that's bad" means "that is best quality", and I insist on using
my language where "that's bad" means "that is worst quality", how much
successful communication are we going to have?
> Here in Germany a
> study was published a little time ago, how few people understand
> commercials and their slogans.
Which just proves my point. If people don't share the same language
constructs, the same words, the same grammar, etc, they can't understand
each other.
> Do you know how many jokes work? Yes, by misunderstandings.
http://en.wikipedia.org/wiki/Humour
--
Steven.
Steven D'Aprano wrote:
> On Sun, 10 Dec 2006 15:05:04 +0100, Stefan Nobis wrote:
> > Ever talked to skateboarders? Other people of different scenes? They
> > are creating new, specialized languages every day.
>
> Yes, that's right. And if they insist on using their specialist language
> where "that's bad" means "that is best quality", and I insist on using
> my language where "that's bad" means "that is worst quality", how much
> successful communication are we going to have?
Having such a specialist language, which goes against common
practice, would be stupid. There nothing to gain from doing so,
so it's not done.
The same is true for macros. Redefining everything and programming
in your own special way just to be different would be stupid, and
it's not done.
Everyone keeps telling you this but you keep ignoring it.
Wonder why.
Macros are used where they must be used, to do things that are not
possible with functions. Functions have benefits that macros don't
have, and for most things (but not all things), those benefits are
more useful than the benefits provided by macros.
I will also note that Ken Tilton was right about analogies, and
far too much of this discussion is now about English language, not
the merits of Lisp vs Python. Sad, because there is some good
stuff in here.
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> Which just proves my point. If people don't share the same language
> constructs, the same words, the same grammar, etc, they can't
> understand each other.
Yes, but that depends *much* more on social background, habits,
experience than on technical details like correct syntax, orthography
etc. Do you know about studies with texts where the letters of each
word are disordered except the first and the last and nearly everyone
was able to read this (OK, it took a little bit more time, but it was
readable)? So much to the importance of syntax and orthography.
Essentially every group of people, scene, community has it's own
special language and if you want to communicate with them, you have to
learn this language. Excatly the same goes for software projects with
their libraries -- completley independet of the technical background
of the abstractions (functions, classes, macros,...) the libraries
provide.
It's really funny to see how you try to create and defend a purely
factitious line between abstraction techniques like functions,
classes, and even operator overloading and shadowing on the one side
and those big bad macro monsters on the other side.
--
Stefan.
> Why? The benefit of expressiveness and power isn't monotonically
> increasing. Look at us: we're all communicating in a common language,
> English, and we all agree on syntax and grammar.
I think we all agree that with flexibility comes abuse "potential". But
if that potential will actually be likely realized or that we are just
being scared of a phantom can only be determined by empirical evidence.
While, reliable empirical evidence is hard to get in programming
languages, we can only ask the people who use the languages which
support features like macros and tell us what they feel about them
rather than make arguments based on hypothetical possibilities.
So far I am hearing a near unanimous statement from users of these
languages that while there is abuse potential, they do not use it in
that manner and that they are glad that the feature is available than
not. Of course, people tend to defend the languages (or just about any
skill) that they have invested in. Especially when they are not aware
of the alternatives. But this does not seem to be the case with these
people. Macros continue to be incorporated in the latest languages
(OCaml, Boo, Nemerle) with no reports of abuse.
But then again, Python may not be the right language for macros. We try
to have a language that is easy for beginners while having sufficient
richness for advanced users. The abuse potential could potentially be
higher with excess expressiveness as we have seen with Perl. That might
be a good argument to not make Macros a part of language but not so
much as to not have external support.
I doubt that Logix did not catch on because people thought it was too
dangerous to use. 3 likely reasons are.
1. They did not hear about it.
2. They did not understand it.
3. The current implementation is slow.
> Now, I could be a lot
> more expressive, and language could be a lot more powerful, if I could
> define my own language where "You are a poopy-head" was in fact a detailed
> and devastatingly accurate and complete explanation for why Python was a
> better language than Lisp.
This is exactly what I meant by a phantom. Could you show me some any
Lisp macros in the wild that show this kind of abuse?
You could just as egregiously abuse Python's dynamic typing and
metaclasses. And it is likely that some do that. But I have not seen
any Python library worth mentioning with such abuse. All the Python
programmers I have seen, seem a lot more sensible than you seem to give
credit. And that is the whole point of "We are all adults here"
argument that you seem to side step.
Sounds like it's time for:
A Beginners' Meta FAQ for comp.lang.lisp:
http://nostoc.stanford.edu/jeff/llisp/cllfaq.html
The purpose of this page is to help those new to Lisp (aka. "newbies")
gain some background before they enter the fray of comp.lang.lisp
(c.l.l). This is not a complete Lisp FAQ! Once you have a sense of Lisp
and of how c.l.l operates you should have no trouble finding all the
additional information you need, either by your own search efforts or
by asking the community. If you have issues with any of the below
please do not send me email. Rather, post on c.l.l in the weekly thread
where this is announced (heading: "*** C.L.L README/FAQ ***").
A suggestion is to mention Dylan as a possibility to people who think
Lisp syntax is too funky but want to see something Lisp-like.
--
Fred Gilham ······@csl.sri.com
Progressive (adj): Value-free; tolerant; non-judgemental.
E.g. traditional archery instruction methods spent tedious hours
teaching the archer to hit a bulls-eye. Progressive methods achieved
better results by telling the student archer to shoot in the manner he
or she found most comfortable, then calling whatever the arrow hit the
bulls-eye.
Mark Tarver wrote:
> How do you compare Python to Lisp?
Lisp programmers are smarter and better looking. And better programmers.
Not sure if that is what you were after, though.
> What specific advantages do you
> think that one has over the other?
http://www.googlefight.com/index.php?lang=en_GB&word1=parentheses&word2=white+space
Ouch.
hth,kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
"Mark Tarver" <··········@ukonline.co.uk> writes:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
>
> Mark
What was the reasoning behind cross-posting this to c.l.p and c.l.l?
This type of question inevitably leads to controversy.
Bill Atkins wrote:
> "Mark Tarver" <··········@ukonline.co.uk> writes:
>
> > How do you compare Python to Lisp? What specific advantages do you
> > think that one has over the other?
> >
> > Note I'm not a Python person and I have no axes to grind here. This is
> > just a question for my general education.
> >
> > Mark
>
> What was the reasoning behind cross-posting this to c.l.p and c.l.l?
> This type of question inevitably leads to controversy.
I don't mind controversy - as long as there is intelligent argument.
And since it involves Python and Lisp, well it should be posted to both
groups. The Lispers will tend to say that Lisp is better for sure -
so it gives the Python people a chance to defend this creation.
I'm looking at Python and I see that the syntax would appeal to a
newbie. Its clearer than ML which is a mess syntactically. But I
don't see where the action is in Python. Not yet anyway. Lisp syntax
is easy to learn. And giving up an order of magnitude is a high price
to pay for using it over Lisp.
Mark
Mark Tarver wrote:
> I don't mind controversy - as long as there is intelligent argument.
> And since it involves Python and Lisp, well it should be posted to both
> groups. The Lispers will tend to say that Lisp is better for sure -
> so it gives the Python people a chance to defend this creation.
And that would be our confirmation that this is another trolling
asshole.
Kaz Kylheku wrote:
> Mark Tarver wrote:
> > I don't mind controversy - as long as there is intelligent argument.
> > And since it involves Python and Lisp, well it should be posted to both
> > groups. The Lispers will tend to say that Lisp is better for sure -
> > so it gives the Python people a chance to defend this creation.
>
> And that would be our confirmation that this is another trolling
> asshole.
This would be a confirmation that you are ignorant in your manners and
don't know how to address a straight question.
Mark
In article <························@16g2000cwy.googlegroups.com>,
Mark Tarver <··········@ukonline.co.uk> wrote:
>
>I'm looking at Python and I see that the syntax would appeal to a
>newbie. Its clearer than ML which is a mess syntactically. But I
>don't see where the action is in Python. Not yet anyway. Lisp syntax
>is easy to learn. And giving up an order of magnitude is a high price
>to pay for using it over Lisp.
Speaking as someone who had been programming for more than twenty years
before learning Python (including a brief gander at Lisp), and also
referring to many years of observations of newcomers to Python: Python's
syntax also appeals to experienced programmers.
I would say that your statement about Lisp syntax is wrong. Not that it
is technically inaccurate, but that it completely misses the point, so
much so that it is wrong to say it. One of the key goals of Python is
readability, and while it is indeed easy to learn the rules for Lisp
syntax, observational experience indicates that many people (perhaps even
the vast majority of people) find it difficult to learn to read Lisp
programs.
As for your claims about speed, they are also nonsense; I doubt one
would find an order of magnitude increase of speed for production
programs created by a competent Lisp programmer compared to programs
created by a competent Python programmer.
Consider this: Lisp has had years of development, it has had millions of
dollars thrown at it by VC firms -- and yet Python is winning over Lisp
programmers. Think about it.
--
Aahz (····@pythoncraft.com) <*> http://www.pythoncraft.com/
Member of the Groucho Marx Fan Club
Aahz wrote:
> As for your claims about speed, they are also nonsense; I doubt one
> would find an order of magnitude increase of speed for production
> programs created by a competent Lisp programmer compared to programs
> created by a competent Python programmer.
Lisp can be compiled into an executable that has c-like speeds. It can
be much faster than python.
-MIke
Aahz wrote:
> I would say that your statement about Lisp syntax is wrong. Not that it
> is technically inaccurate, but that it completely misses the point, so
> much so that it is wrong to say it. One of the key goals of Python is
> readability, and while it is indeed easy to learn the rules for Lisp
> syntax, observational experience indicates that many people (perhaps even
> the vast majority of people) find it difficult to learn to read Lisp
> programs.
I think this holds true for experienced programmers, who often report a
difficult unlearning process with Lisp. However, for people without
preconceptions, the difference is likely less -- after all, many have
painful memories of poorly-taught math and computer classes in school.
So Python's similarity to gradeschool math may not be such a plus.
Richard Stallman explained about a Lisp variant:
"Multics Emacs proved to be a great success -- programming new editing
commands was so convenient that even the secretaries in his office
started learning how to use it. They used a manual someone had written
which showed how to extend Emacs, but didn't say it was a programming.
So the secretaries, who believed they couldn't do programming, weren't
scared off. They read the manual, discovered they could do useful
things and they learned to program."
<http://www.gnu.org/gnu/rms-lisp.html>
But of course this is anecdotal evidence.
> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers. Think about it.
Even now, Lisp still contains radical concepts (as in latin's radix
meaning "root"), and overly radical ideas tend not to dominate in the
marketplace. So we see an incremental progression towards Lisp ideas.
Guy Steele, a central figure in Java, claimed:
"And you're right: we were not out to win over the Lisp programmers; we
were after the C++ programmers. We managed to drag a lot of them about
halfway to Lisp. Aren't you happy?"
<http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html>
But speaking of the marketplace, there's at least one Lisp company
sustaining itself by asking for a cut of its customers' revenues... The
last Lisp implementation I used "merely" asked for thousands per head
per platform. ;)
(Personally, I used Python before being aware of Lisp. Now I use Common
Lisp all the time, though I will recommend Python when I consider it
more appropriate. A few months ago, I missed the Condition System most
when using Python, and also lexical scope. However, it is nice to work
with friends, who know Python and not Lisp.)
Tayssir
············@googlemail.com writes:
> However, it is nice to work
> with friends, who know Python and not Lisp.)
It would be nicer a friendship if you taught them Lisp...
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
············@googlemail.com schrieb:
> A few months ago, I missed the Condition System most
> when using Python, and also lexical scope. However, it is nice to work
> with friends, who know Python and not Lisp.)
Could you explain in which way Python lacks lexical scoping?
"Kay Schluehr" <············@gmx.net> writes:
> > A few months ago, I missed the Condition System most
> > when using Python, and also lexical scope. However, it is nice to work
> > with friends, who know Python and not Lisp.)
>
> Could you explain in which way Python lacks lexical scoping?
Python has lexical scope but you can't update lexical variables from
scopes other than the innermost or outermost (global) scope. I.e:
def counter():
x = 0
def g():
x += 1
return x
return g
c = counter()
print c()
doesn't do what you'd hope. Yes there are workarounds but they're not
all that satisfactory.
Aahz wrote:
> In article <························@16g2000cwy.googlegroups.com>,
> Mark Tarver <··········@ukonline.co.uk> wrote:
>
>>I'm looking at Python and I see that the syntax would appeal to a
>>newbie. Its clearer than ML which is a mess syntactically. But I
>>don't see where the action is in Python. Not yet anyway. Lisp syntax
>>is easy to learn. And giving up an order of magnitude is a high price
>>to pay for using it over Lisp.
>
>
> Speaking as someone who had been programming for more than twenty years
> before learning Python (including a brief gander at Lisp), and also
> referring to many years of observations of newcomers to Python: Python's
> syntax also appeals to experienced programmers.
>
> I would say that your statement about Lisp syntax is wrong. Not that it
> is technically inaccurate, but that it completely misses the point, so
> much so that it is wrong to say it. One of the key goals of Python is
> readability, and while it is indeed easy to learn the rules for Lisp
> syntax, observational experience indicates that many people (perhaps even
> the vast majority of people) find it difficult to learn to read Lisp
> programs.
No programming language is easy to read, and no Lisp programmer stopped
using Lisp because they had been using it for a month and just could not
get used to reading it. So I think you are just making things up. :)
> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers. Think about it.
Haha, what's the score? And how much time is left in the first quarter?
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Fri, 08 Dec 2006 14:52:33 -0500, Ken Tilton wrote:
>
>
> Aahz wrote:
>> In article <························@16g2000cwy.googlegroups.com>,
>> Mark Tarver <··········@ukonline.co.uk> wrote:
>>
>>>I'm looking at Python and I see that the syntax would appeal to a
>>>newbie. Its clearer than ML which is a mess syntactically. But I
>>>don't see where the action is in Python. Not yet anyway. Lisp syntax
>>>is easy to learn. And giving up an order of magnitude is a high price
>>>to pay for using it over Lisp.
>>
>>
>> Speaking as someone who had been programming for more than twenty years
>> before learning Python (including a brief gander at Lisp), and also
>> referring to many years of observations of newcomers to Python: Python's
>> syntax also appeals to experienced programmers.
>>
>> I would say that your statement about Lisp syntax is wrong. Not that it
>> is technically inaccurate, but that it completely misses the point, so
>> much so that it is wrong to say it. One of the key goals of Python is
>> readability, and while it is indeed easy to learn the rules for Lisp
>> syntax, observational experience indicates that many people (perhaps even
>> the vast majority of people) find it difficult to learn to read Lisp
>> programs.
>
> No programming language is easy to read,
Well, you've just blown your credibility out the water with that nonsense.
> and no Lisp programmer stopped
> using Lisp because they had been using it for a month and just could not
> get used to reading it.
Or, to put it another way:
"No programmer who learned Lisp ever gave up before he learned Lisp."
I wonder, how many people gave up trying to learn Lisp because the
language was too hard for them to read? Anyone like to bet that the number
was more than zero?
--
Steven.
Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 14:52:33 -0500, Ken Tilton wrote:
>
>
>>
>>Aahz wrote:
>>
>>>In article <························@16g2000cwy.googlegroups.com>,
>>>Mark Tarver <··········@ukonline.co.uk> wrote:
>>>
>>>
>>>>I'm looking at Python and I see that the syntax would appeal to a
>>>>newbie. Its clearer than ML which is a mess syntactically. But I
>>>>don't see where the action is in Python. Not yet anyway. Lisp syntax
>>>>is easy to learn. And giving up an order of magnitude is a high price
>>>>to pay for using it over Lisp.
>>>
>>>
>>>Speaking as someone who had been programming for more than twenty years
>>>before learning Python (including a brief gander at Lisp), and also
>>>referring to many years of observations of newcomers to Python: Python's
>>>syntax also appeals to experienced programmers.
>>>
>>>I would say that your statement about Lisp syntax is wrong. Not that it
>>>is technically inaccurate, but that it completely misses the point, so
>>>much so that it is wrong to say it. One of the key goals of Python is
>>>readability, and while it is indeed easy to learn the rules for Lisp
>>>syntax, observational experience indicates that many people (perhaps even
>>>the vast majority of people) find it difficult to learn to read Lisp
>>>programs.
>>
>>No programming language is easy to read,
>
>
> Well, you've just blown your credibility out the water with that nonsense.
I am delighted to learn I had any to begin with.
Perhaps you are thinking of individual lines of code being easy to read.
Sure. I am talking about algorithms. Code cannot be read as if it were
the Sunday comics. At any interesting level of complexity, one has to
slow down and effectively hand-execute code in one's mind, not just read
it as one reads natural language (and some of that makes one slow down
to, no matter how well known are the individual words and grammar).
>
>
>
>>and no Lisp programmer stopped
>>using Lisp because they had been using it for a month and just could not
>>get used to reading it.
>
>
> Or, to put it another way:
>
> "No programmer who learned Lisp ever gave up before he learned Lisp."
That would be the obvious retort, but my observation was empirical, so I
am afraid you need numbers, not word games.
You seem awfully hostile, by the way. Won't that make it harder to
conduct an intelligent exchange of value to lurkers?
> I wonder, how many people gave up trying to learn Lisp because the
> language was too hard for them to read? Anyone like to bet that the number
> was more than zero?
Sorry, no one ever discovered Lisp, decided it would be great for
programming, started learning it and then gave up because they could not
handle the syntax. The syntax is actually easier to master because of
its regularity, and lisp-aware editors handle the parentheses such that
they disappear in a month.
Your position is untenable. It relies on this idea that all these Lisp
programmers not only handle Lisp syntax effortlessly but also praise it
as a significant advantage, they have all mastered several non-Lispy
languages, but...what? They are mutants? Who just happen to have no
problem with C and Java and Prolog and COBOL and Basic? Probably not.
If you are saying someone will glance at a Lisp book and say they cannot
understand it, well, that is not very interesting is it?
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
> > "No programmer who learned Lisp ever gave up before he learned Lisp."That would be the obvious retort, but my observation was empirical, so I
> am afraid you need numbers, not word games.
>
> You seem awfully hostile, by the way. Won't that make it harder to
> conduct an intelligent exchange of value to lurkers?
>
> > I wonder, how many people gave up trying to learn Lisp because the
> > language was too hard for them to read? Anyone like to bet that the number
> > was more than zero?Sorry, no one ever discovered Lisp, decided it would be great for
> programming, started learning it and then gave up because they could not
> handle the syntax.
Uh. Clearly no one would be dumb enough to admit it in front of the
entire usenet world, right?
- Mr. NoOne
P.S. I am still going to get back to it when I get some time, really.
LISP seems intriguing and superior, almost a magical Rubik's cube
waiting for me. I just stumbled across Python in the meantime and code
started flowing - I got distracted. I have CL (& Scheme) on all my
machines awaiting my focus.... I'll join the flock any day now. :-)
I've just been busy. There is a cost to learning and I've not had the
spare change to date.
But New Years resolutions need to be made: I could get up a couple
hours early and spend some quality time with CL, do a daily hour jog,
and eat a really heathly breakfast. Writing myself a note on this.
P.P.S. Undoubtedly not learning a syntax either means not enough time
was put in or the student lacked proper intelligence. This will always
bias the significance of learning syntax as a factor in choice of
language to be under reported. cheers
Eric Pederson wrote:
>>>"No programmer who learned Lisp ever gave up before he learned Lisp."That would be the obvious retort, but my observation was empirical, so I
>>
>>am afraid you need numbers, not word games.
>>
>>You seem awfully hostile, by the way. Won't that make it harder to
>>conduct an intelligent exchange of value to lurkers?
>>
>>
>>>I wonder, how many people gave up trying to learn Lisp because the
>>>language was too hard for them to read? Anyone like to bet that the number
>>>was more than zero?Sorry, no one ever discovered Lisp, decided it would be great for
>>
>>programming, started learning it and then gave up because they could not
>>handle the syntax.
>
>
>
>
> Uh. Clearly no one would be dumb enough to admit it in front of the
> entire usenet world, right?
The good news is that I was just trying to flush out a live specimen.
The bad news is that after some tests we want to dissect you.
>
> - Mr. NoOne
>
>
> P.S. I am still going to get back to it when I get some time, really.
> LISP seems intriguing and superior, almost a magical Rubik's cube
> waiting for me. I just stumbled across Python in the meantime and code
> started flowing - I got distracted.
Oh, shucks, that is not "gave up because they could not handle the syntax".
You have me wondering if I would have switched from C to Lisp had Python
been what itis now back in '95. Obviously the simple transition would
have been attractive. OTOH I had done extensive LOGO (and loved it) and
experimented heavily with Prolog, so syntax would not scare me. The
immaturity of Python would have been an issue because I had just gotten
sliced up pretty badly with bleeding edge stuff I tried at the same time
(trying desperately to avoid C++). I beat on the C preprocessor like I
was its daddy, so macros might have made sense to me even without having
played with them. Giving up cycles I would not like all other things
being equal. And to tell you the truth, novelty tends to make me more
productive, not less, because fresh brain cells perforce get pulled into
play. Sounds like I would have dabbled in both, and then Lisp would have
won because I recall the first two weeks being pretty much astonished
whooping and hollering over how great Lisp was. But Python has a lot of
that, too.
> I have CL (& Scheme) on all my
> machines awaiting my focus.... I'll join the flock any day now. :-)
> I've just been busy. There is a cost to learning and I've not had the
> spare change to date.
>
> But New Years resolutions need to be made: I could get up a couple
> hours early and spend some quality time with CL, do a daily hour jog,
> and eat a really heathly breakfast. Writing myself a note on this.
>
>
> P.P.S. Undoubtedly not learning a syntax either means not enough time
> was put in or the student lacked proper intelligence.
Intelligence to understand syntax? Isn't it memory (and not so much that
the correlation with intelligence would matter)? This punctuation means
this, that punctuation means that, and the precedence is this. One of
the big wins of Lisp is that it is just (verb object*) 95% of the time.
Maybe you mean functional vs imperative requires intelligence? That I
might buy. A little. But then Lisp handles imperative, too. You just get
laughed at it if you post it to c.l.l.
> This will always
> bias the significance of learning syntax as a factor in choice of
> language to be under reported.
That's OK, I am looking for the person so bright they have the
self-confidence to expose their failure. Then we do not have to dissect
them, we can ask them to introspect and get useable data. But you did
not say anythng about having a problem with Lisp at all let alone the
syntax and indeed offer some quotes that could go in the RtL Highlight
Film, so you are useless. No fee for you.
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
····@pythoncraft.com (Aahz) writes:
> I would say that your statement about Lisp syntax is wrong. Not that it
> is technically inaccurate, but that it completely misses the point, so
> much so that it is wrong to say it. One of the key goals of Python is
> readability, and while it is indeed easy to learn the rules for Lisp
> syntax, observational experience indicates that many people (perhaps even
> the vast majority of people) find it difficult to learn to read Lisp
> programs.
You see, this is what I meant by "controversy." As much as I'd like
to ignore this whole discussion, I will eventually read something like
the above and feel compelled to respond, thus ensuring that the thread
continues until eventually everyone gives up and we end up....exactly
where we started. (thanks again, Mark Tarver)
This is a silly claim. What observational experience are you talking
about? Lisp is delightfully readable. In fact, I find it more
readable than any other language. Why do you think that is? Could it
be because I use Lisp on a daily basis? Could that also explain why
Python seems more readable than Lisp to you?
> As for your claims about speed, they are also nonsense; I doubt one
> would find an order of magnitude increase of speed for production
> programs created by a competent Lisp programmer compared to programs
> created by a competent Python programmer.
Nonsense? Hardly. Most Lisp implementations compile to native code,
and can take advantage of fifty years of research into making Lisp
compile into efficient code. You are correct, though: the difference
would probably be a little more than an order of magnitude.
> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers. Think about it.
OK, I'm thinking about it. What was supposed to happen?
(BTW, which millions are you talking about? The millions that went
into the AI boom in the 1980's?)
Bill Atkins <······@rpi.edu> writes:
> This is a silly claim. What observational experience are you talking
> about? Lisp is delightfully readable. In fact, I find it more
> readable than any other language. Why do you think that is? Could it
> be because I use Lisp on a daily basis? Could that also explain why
> Python seems more readable than Lisp to you?
Python is more readable than Lisp because it stays readable even if
you don't use it on a daily basis.
Paul Rubin <·············@NOSPAM.invalid> wrote:
+---------------
| Bill Atkins <······@rpi.edu> writes:
| > This is a silly claim. What observational experience are you talking
| > about? Lisp is delightfully readable. In fact, I find it more
| > readable than any other language. Why do you think that is? Could it
| > be because I use Lisp on a daily basis? Could that also explain why
| > Python seems more readable than Lisp to you?
|
| Python is more readable than Lisp because it stays readable even if
| you don't use it on a daily basis.
+---------------
Weird. This is exactly why I use *Lisp* -- because it stays
completely readable even if you don't use it on a daily basis!!!
[That's also why I *don't* use Perl, except when forced to...]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Weird. This is exactly why I use *Lisp* -- because it stays
> completely readable even if you don't use it on a daily basis!!!
Hmm. I haven't used Lisp in a while and no longer find it so
readable.
Lisp just seems hopelessly old-fashioned to me these days. A
modernized version would be cool, but I think the more serious
Lisp-like language designers have moved on to newer ideas.
Paul Rubin wrote:
> Lisp just seems hopelessly old-fashioned to me these days. A
> modernized version would be cool, but I think the more serious
> Lisp-like language designers have moved on to newer ideas.
What are some of their names, and what ideas are they working on?
Also, who are the less serious designers?
"Kaz Kylheku" <········@gmail.com> writes:
> > Lisp just seems hopelessly old-fashioned to me these days. A
> > modernized version would be cool, but I think the more serious
> > Lisp-like language designers have moved on to newer ideas.
>
> What are some of their names, and what ideas are they working on?
http://caml.inria.fr
http://www.haskell.org
etc.
> Also, who are the less serious designers?
The ones like us who waste their time on usenet. ;-)
jayessay <······@foo.com> writes:
> > http://caml.inria.fr
> > http://www.haskell.org
>
> Aren't these "old-fashioned" and boring as well?
Maybe not bleeding edge, but more modern than CL in my opinion.
jayessay <······@foo.com> writes:
> > Maybe not bleeding edge, but more modern than CL in my opinion.
> Odd, caml is even older than CL.
You'd have to compare (say) OCaml to CL if it's dialect against
dialect. If you're going to bring in the earlier ML family you also
have to bring in Lisp 1.5, which goes much further back than CL.
jayessay <······@foo.com> writes:
> Also, there is the issue of whether there even is a "continual
> progression", as in "moving up some ladder" towards something
> "better", in the context of programming languages. All of that is
> pretty fuzzy stuff, and plenty of CogSci work has shown these value
> judgements in this context to be less than obvious in any meaning.
It's simply that newer language designs by definition have more of an
experience base to build on than older ones, if the designers care to
make use of it. ML's designers were quite aware of what it was like
to write Lisp code. Lisp (like anything else) has good and bad
points, and ML's designers were able to examine these in retrospect
and try to improve on them.
Are there any Lisp devotees who have done serious development in ML?
Paul Rubin wrote:
> Are there any Lisp devotees who have done serious development in ML?
There is a disproportionately small overlap between the Lisp/Scheme and
ML/Haskell communities. They are probably of comparable size at the moment.
I believe the difference is largely geographical.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Paul Rubin <·············@NOSPAM.invalid> writes:
> jayessay <······@foo.com> writes:
> > Also, there is the issue of whether there even is a "continual
> > progression", as in "moving up some ladder" towards something
> > "better", in the context of programming languages. All of that is
> > pretty fuzzy stuff, and plenty of CogSci work has shown these value
> > judgements in this context to be less than obvious in any meaning.
>
> It's simply that newer language designs by definition have more of an
> experience base to build on than older ones, if the designers care to
> make use of it.
Agreed. Indeed, that was the underlying guiding principle in putting
together CL. *ML being older than CL didn't have any more opportunity
in this respect.
> ML's designers were quite aware of what it was like to write Lisp
> code. Lisp (like anything else) has good and bad points, and ML's
> designers were able to examine these in retrospect and try to
> improve on them.
I'm sure you're right on that. Of course it's vice-versa as well.
> Are there any Lisp devotees who have done serious development in ML?
There are some here (cll) who appear to have, but I don't know them
personally.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay <······@foo.com> writes:
> > It's simply that newer language designs by definition have more of an
> > experience base to build on than older ones, if the designers care to
> > make use of it.
>
> Agreed. Indeed, that was the underlying guiding principle in putting
> together CL. *ML being older than CL didn't have any more opportunity
> in this respect.
You're forgetting that CL tried to be more or less backwards
compatible with its predecessors, at least compatible enough that
large systems in Maclisp, Interlisp, Zetalisp, etc. could be ported
without too much pain. Therefore, CL could not erase too many
mistakes from the past. Scheme went somewhat further than CL at
cleaning things up, and Scheme's aficionados think CL is a clumsy old
kludge as a result. But it's still a Lisp dialect. The ML's, for
their part, were able to start from scratch.
jayessay <······@foo.com> writes:
> You're mistaken, I'm not forgetting this. And despite this being
> true, CL added several "new" things that (again through actual
> experience) were deemed sufficiently understood to add (CLOS,
> conditions, and such).
I thought CL's condition system was similar to Maclisp or at least the
Lisp machine.
> > mistakes from the past. Scheme went somewhat further than CL at
> > cleaning things up,
>
> But, Scheme was before CL (and indeed CL took some things from
> Scheme). Of course Scheme too has continued to evolve.
But Scheme was able to depart from earlier Lisps more than CL was,
because it made no attempt at backwards compatibility. For example,
its designers chose to make it a Lisp-1 (not saying that's better,
just incompatibly different). CL's designers did really not have that
choice.
> > and Scheme's aficionados think CL is a clumsy old kludge as a
> > result
>
> Well, if you lower into "flamewar" talk, CL aficionados have similar
> things to say about Scheme. But that is just irrelevant silly flamage.
I've never heard CL aficionados say that about Scheme. I've heard
them say that it's an elegant jewel that's too academic and
constricted for practical large program development, which is a
completely different criticism.
> > But it's still a Lisp dialect. The ML's, for their part,
> > were able to start from scratch.
>
> There are Lisps like this as well (EuLisp sort of and now Arc). But
> really, how is "starting from scratch" really an advantage?
Starting from scratch means being able to make choices fundamentally
incompatible with the old language. Consider ML's type system--ML is
statically typed throughout and relies on type inference pervasively.
Yes you could make it look like Lisp by replacing the surface syntax
with parentheses, but it's really different under the skin. Again not
necessarily better, but made choices unavailable to someone trying to
incrementally evolve some Lisp dialect.
> Especially from a _practical_ point of view.
Topic started with how new ideas enter a language. Practicality is
not of so much concern.
> Admittedly, I used to think the same, but now think that is just
> wrong. Again, the example of The Calculus and such come to mind...
Not sure what you mean about calculus.
Paul Rubin wrote:
> jayessay <······@foo.com> writes:
>>> It's simply that newer language designs by definition have more of an
>>> experience base to build on than older ones, if the designers care to
>>> make use of it.
>> Agreed. Indeed, that was the underlying guiding principle in putting
>> together CL. *ML being older than CL didn't have any more opportunity
>> in this respect.
>
> You're forgetting that CL tried to be more or less backwards
> compatible with its predecessors, at least compatible enough that
> large systems in Maclisp, Interlisp, Zetalisp, etc. could be ported
> without too much pain. Therefore, CL could not erase too many
> mistakes from the past. Scheme went somewhat further than CL at
> cleaning things up, and Scheme's aficionados think CL is a clumsy old
> kludge as a result. But it's still a Lisp dialect. The ML's, for
> their part, were able to start from scratch.
It's funny: Language designers have been spending a lot of effort over
the decades on designing language constructs that help to improve the
opportunities to reuse of software libraries. Yet every five years, or
so, new languages and technologies come up that require everyone to
start from scratch. Starting from scratch is even being applauded, due
to some mythical belief that "this time, we are going to get it all right."
Something seems wrong here...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> It's funny: Language designers have been spending a lot of effort over
> the decades on designing language constructs that help to improve the
> opportunities to reuse of software libraries. Yet every five years, or
> so, new languages and technologies come up that require everyone to
> start from scratch. Starting from scratch is even being applauded, due
> to some mythical belief that "this time, we are going to get it all right."
What leads to the best work in language research is not necessarily
what leads immediately to the most useful tools for software
developers.
On Dec 12, 3:16 pm, Pascal Costanza <····@p-cos.net> wrote:
> Paul Rubin wrote:
> > jayessay <······@foo.com> writes:
> >>> It's simply that newer language designs by definition have more of an
> >>> experience base to build on than older ones, if the designers care to
> >>> make use of it.
> >> Agreed. Indeed, that was the underlying guiding principle in putting
> >> together CL. *ML being older than CL didn't have any more opportunity
> >> in this respect.
>
> > You're forgetting that CL tried to be more or less backwards
> > compatible with its predecessors, at least compatible enough that
> > large systems in Maclisp, Interlisp, Zetalisp, etc. could be ported
> > without too much pain. Therefore, CL could not erase too many
> > mistakes from the past. Scheme went somewhat further than CL at
> > cleaning things up, and Scheme's aficionados think CL is a clumsy old
> > kludge as a result. But it's still a Lisp dialect. The ML's, for
> > their part, were able to start from scratch.It's funny: Language designers have been spending a lot of effort over
> the decades on designing language constructs that help to improve the
> opportunities to reuse of software libraries. Yet every five years, or
> so, new languages and technologies come up that require everyone to
> start from scratch. Starting from scratch is even being applauded, due
> to some mythical belief that "this time, we are going to get it all right."
>
> Something seems wrong here...
>
Don't worry, there's nothing wrong here. You'll be happy to know that
Java will be with us for the long haul.
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
············@gmail.com wrote:
>
> On Dec 12, 3:16 pm, Pascal Costanza <····@p-cos.net> wrote:
>> It's funny: Language designers have been spending a lot of effort over
>> the decades on designing language constructs that help to improve the
>> opportunities to reuse of software libraries. Yet every five years, or
>> so, new languages and technologies come up that require everyone to
>> start from scratch. Starting from scratch is even being applauded, due
>> to some mythical belief that "this time, we are going to get it all right."
>>
>> Something seems wrong here...
>
> Don't worry, there's nothing wrong here. You'll be happy to know that
> Java will be with us for the long haul.
...but Java is still a young language. It's only ten years old. And it
doesn't even ensure that code written four years ago still works. ;)
Which other language executes code that was written 40 years ago? ;)
On top of that, Java is a language that has failed to meet almost all of
its original goals...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Dec 13, 3:21 am, Pascal Costanza <····@p-cos.net> wrote:
> ············@gmail.com wrote:
>
> > On Dec 12, 3:16 pm, Pascal Costanza <····@p-cos.net> wrote:
> >> It's funny: Language designers have been spending a lot of effort over
> >> the decades on designing language constructs that help to improve the
> >> opportunities to reuse of software libraries. Yet every five years, or
> >> so, new languages and technologies come up that require everyone to
> >> start from scratch. Starting from scratch is even being applauded, due
> >> to some mythical belief that "this time, we are going to get it all right."
>
> >> Something seems wrong here...
>
> > Don't worry, there's nothing wrong here. You'll be happy to know that
> > Java will be with us for the long haul....
>but Java is still a young language. It's only ten years old. And it
All that code in just ten years...You should be happy to know that it
doesn't look like Sun or IBM isn't going to be starting from scratch
anytime soon.
> doesn't even ensure that code written four years ago still works. ;)
Sure it does. You run it on the same VM you were running 4 years ago.
>
> Which other language executes code that was written 40 years ago? ;)
>
COBOL, Fortran, and all that legacy Java code running in 2036.
> On top of that, Java is a language that has failed to meet almost all of
> its original goals...
>
What goal(s) were that? Set-top boxes? and then Applets? Java's goals
appear to be whatever goals Sun could find a market for after stumbling
around for a bit.
············@gmail.com wrote:
>
> On Dec 13, 3:21 am, Pascal Costanza <····@p-cos.net> wrote:
>> ············@gmail.com wrote:
>>
>>> On Dec 12, 3:16 pm, Pascal Costanza <····@p-cos.net> wrote:
>>>> It's funny: Language designers have been spending a lot of effort over
>>>> the decades on designing language constructs that help to improve the
>>>> opportunities to reuse of software libraries. Yet every five years, or
>>>> so, new languages and technologies come up that require everyone to
>>>> start from scratch. Starting from scratch is even being applauded, due
>>>> to some mythical belief that "this time, we are going to get it all right."
>>>> Something seems wrong here...
>>> Don't worry, there's nothing wrong here. You'll be happy to know that
>>> Java will be with us for the long haul....
>
>> but Java is still a young language. It's only ten years old. And it
>
> All that code in just ten years...
...and yet all so boring... ;)
> You should be happy to know that it
> doesn't look like Sun or IBM isn't going to be starting from scratch
> anytime soon.
I wouldn't be so sure: http://research.sun.com/minds/2005-0302/
In any case, Sun and IBM are big corporations that don't act with a
single consistent strategies.
>> doesn't even ensure that code written four years ago still works. ;)
>
> Sure it does. You run it on the same VM you were running 4 years ago.
...only if that VM runs on current platforms...
>> Which other language executes code that was written 40 years ago? ;)
>
> COBOL, Fortran, and all that legacy Java code running in 2036.
>
>> On top of that, Java is a language that has failed to meet almost all of
>> its original goals...
>>
> What goal(s) were that? Set-top boxes? and then Applets? Java's goals
> appear to be whatever goals Sun could find a market for after stumbling
> around for a bit.
See http://java.sun.com/docs/white/ - especially
http://java.sun.com/docs/overviews/java/java-overview-1.html and
http://java.sun.com/docs/white/langenv/
Compare this to
http://www.supelec.fr/docs/cltl/clm/node6.html#SECTION00510000000000000000
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
jayessay wrote:
> Fair enough. But really, I don't see any of these things as
> particularly "modern" (whatever that means) or groundbreaking.
> Certainly not at this point.
Performance and type theory are modern in the context of FPLs. Both have
been retrofitted to Lisp with varying results.
> Also, there is the issue of whether there even is a "continual
> progression", as in "moving up some ladder" towards something
> "better", in the context of programming languages. All of that is
> pretty fuzzy stuff, and plenty of CogSci work has shown these value
> judgements in this context to be less than obvious in any meaning.
If you look over a long period of time (e.g. back to the last major change
to Lisp) then language research has had clear overall directions.
> There is also a question about "old/new" wrt these value judgements.
> Since Lisp is (admittedly some hand waving here) more or less lambda
> calculus embodied, is it closer to say The Calculus or Group Theory
> than to some random piece of technology?[1] If Lisp is "old
> fashioned", then The Calculus and Group Theory are like _really_ old
> fashioned. But does that lessen them in some way? What would that
> be? Is some random "new" technique (say brute force iterative
> techniques for calculus problems with computers) somehow "better"?
Again, just read research papers to learn what's new.
For example, we're going multicore whether you like it or not, so concurrent
GCs will become much more important over the next few years. F# adds that
to OCaml. That's new and its better.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Paul Rubin wrote:
> "Kaz Kylheku" <········@gmail.com> writes:
> > > Lisp just seems hopelessly old-fashioned to me these days. A
> > > modernized version would be cool, but I think the more serious
> > > Lisp-like language designers have moved on to newer ideas.
> >
> > What are some of their names, and what ideas are they working on?
>
> http://caml.inria.fr
> http://www.haskell.org
Right. What these have in common with Lisp is that they use manifest
typing, whereas Lisp uses latent typing. But after that, they mostly
diverge.
3Paul Rubin <·············@NOSPAM.invalid> writes:
> Lisp just seems hopelessly old-fashioned to me these days. A
Indeed. All the excitement nowadays is centered around youngster
interpreted languages that support type-edit-run development only and
are controlled by a single person. Standardized, mature languages
with good compilers and interactive development just can't keep up
with these modern trends.
Paul Rubin <·············@NOSPAM.invalid> writes:
> ····@rpw3.org (Rob Warnock) writes:
> > Weird. This is exactly why I use *Lisp* -- because it stays
> > completely readable even if you don't use it on a daily basis!!!
>
> Hmm. I haven't used Lisp in a while and no longer find it so
> readable.
I haven't used Python in a while and don't find it especially readable.
A number of years ago I was looking for a high level alternative to C++,
I ran screaming from Perl. Python was better but I ended up preferring
Lisp. Like Python's space indents, Lisp's parens disappear into the
background once you learn how they work. Whats left is the language
itself and I found Lisp worked more easily.
> Lisp just seems hopelessly old-fashioned to me these days. A
> modernized version would be cool, but I think the more serious
> Lisp-like language designers have moved on to newer ideas.
The trick is separating new ideas from fads or things that look new but
are really incomplete reimplementations of older ideas. Frankly I have
yet to find some language "feature" that doesn't exist in Common Lisp or
one of the implementations- OTOH I use it to write software to get
things done so my requirements are essentially practical rather than
doctrinal.
Gregm
Paul Rubin <·············@NOSPAM.invalid> writes:
> Python is more readable than Lisp because it stays readable even if
> you don't use it on a daily basis.
Girls, this is really bullshit!
None programming language is readable. I teach programming to complete
beginners and I tried some languages -- maybe some are a little bit
worse for the uneducated, but all languages are really unreadable.
Intuitive interfaces (GUI, languages,...) are an urban legend, pure
illusion. You have to do hard work and practice to understand them.
--
Stefan.
Stefan Nobis <······@gmx.de> writes:
> Intuitive interfaces (GUI, languages,...) are an urban legend, pure
> illusion. You have to do hard work and practice to understand them.
Well if you write enough code in general, the principles stick with
you. What I found with Perl was that after not using it for a while,
I completely forgot it. I mean the principles were still the same,
but making any sense of the code depended on remembering a lot of
detail which had left me. Python and C are not so much like that.
Lisp is somewhere in between.
Aahz schrieb:
> In article <························@16g2000cwy.googlegroups.com>,
> Mark Tarver <··········@ukonline.co.uk> wrote:
>> I'm looking at Python and I see that the syntax would appeal to a
>> newbie. Its clearer than ML which is a mess syntactically. But I
>> don't see where the action is in Python. Not yet anyway. Lisp syntax
>> is easy to learn. And giving up an order of magnitude is a high price
>> to pay for using it over Lisp.
>
> Speaking as someone who had been programming for more than twenty years
> before learning Python (including a brief gander at Lisp), and also
> referring to many years of observations of newcomers to Python: Python's
> syntax also appeals to experienced programmers.
>
> I would say that your statement about Lisp syntax is wrong. Not that it
> is technically inaccurate, but that it completely misses the point, so
> much so that it is wrong to say it. One of the key goals of Python is
> readability, and while it is indeed easy to learn the rules for Lisp
> syntax, observational experience indicates that many people (perhaps even
> the vast majority of people) find it difficult to learn to read Lisp
> programs.
If you ask a non-programmer to read programs he/she will have difficulties.
But I guess this person would not have more problems learning than any
other programming language. They are not biased because they don't know
how programs look like. If you show Lisp code to people who know C or
Java, Python or PHP they will not find as easily the structure.
They are already used to something, and we all are creatures of habit.
> As for your claims about speed, they are also nonsense; I doubt one
> would find an order of magnitude increase of speed for production
> programs created by a competent Lisp programmer compared to programs
> created by a competent Python programmer.
The Python language interpreter itself is programmed in C (biggest parts).
Lisp compilers are programmed in Lisp.
Both are mature production programs. Why do you think isn't the Python
interpreter programmed in pure Python?
> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers. Think about it.
When Lisp got so many millions it was not known how to create very good
compilers. Mankind had to learn it, so these investments were needed.
Today there are open source Lisps. And while they don't get millions
of Dollars for development they can produce mature production code.
Andr�
--
····@pythoncraft.com (Aahz) writes:
>
> Consider this: Lisp has had years of development, it has had millions of
> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
> programmers. Think about it.
The argument from popularity is invalid. French units have overtaken
standard units, yet they are technically worse. Windows has overtaken
Unix, yet it is technically worse.
The market does not select the technically best (although it may select
what is best when all factors are taken into account; e.g. Windows may
be better when dealing with an ignorant workforce, and French units may
be better when dealing with users thereof).
--
Robert Uhl <http://public.xdi.org/=ruhl>
Traditionally, there are only three classes of people who use 'we' in
describing themselves: Royalty (which you aren't), editors (no evidence
that this applies) and people with tapeworms. Please let us know when
you've been cured. --Hal Heydt, to Dennis O'Connor
Robert Uhl a �crit :
> ····@pythoncraft.com (Aahz) writes:
>> Consider this: Lisp has had years of development, it has had millions of
>> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
>> programmers. Think about it.
>
> The argument from popularity is invalid. French units have overtaken
> standard units,
Never heard of that French unit thing. Unless you talk about that
archaic unit system that was in use before the metric system was created.
Christophe <···············@free.fr> writes:
> Robert Uhl a �crit :
>> ····@pythoncraft.com (Aahz) writes:
>>> Consider this: Lisp has had years of development, it has had millions of
>>> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
>>> programmers. Think about it.
>>
>> The argument from popularity is invalid. French units have overtaken
>> standard units,
> Never heard of that French unit thing. Unless you talk about that
> archaic unit system that was in use before the metric system was
> created.
Who invented the metric system?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
Pascal Bourguignon a �crit :
> Christophe <···············@free.fr> writes:
>
>> Robert Uhl a �crit :
>>> ····@pythoncraft.com (Aahz) writes:
>>>> Consider this: Lisp has had years of development, it has had millions of
>>>> dollars thrown at it by VC firms -- and yet Python is winning over Lisp
>>>> programmers. Think about it.
>>> The argument from popularity is invalid. French units have overtaken
>>> standard units,
>> Never heard of that French unit thing. Unless you talk about that
>> archaic unit system that was in use before the metric system was
>> created.
>
> Who invented the metric system?
That system is called the metric system, not French units. French units
refer to the archaic system used before the metric system was invented (
at least according to google )
So, let's admit that French Units refer to the metric system. I suppose
then that the so called "standard" units refer to the imperial system.
Saying that the French units are technically worse than standard units
is a troll of very poor quality and a very weak argument.
Christophe <···············@free.fr> writes:
>
> Saying that the French units are technically worse than standard units
> is a troll of very poor quality and a very weak argument.
It was just an example that the argument from popularity is invalid.
However, I (and many others) would argue that optimisation for unit
conversion is the wrong choice when designing a system of measures. But
this is not the venue for such a discussion, so I'll stop now:-)
--
Robert Uhl <http://public.xdi.org/=ruhl>
...It [the Mexican dictatorship] has demanded us to deliver up our arms,
which are essential for our defence, the rightful property of freemen,
and formidable only to tyrannical governments...
--Texas Declaration of Independence
Robert Uhl a �crit :
> Christophe <···············@free.fr> writes:
>> Saying that the French units are technically worse than standard units
>> is a troll of very poor quality and a very weak argument.
>
> It was just an example that the argument from popularity is invalid.
> However, I (and many others) would argue that optimisation for unit
> conversion is the wrong choice when designing a system of measures. But
> this is not the venue for such a discussion, so I'll stop now:-)
Well, I spent some time on Wikipedia looking up metric systems and
things like that because of you, and I found a page that shows how to
improve the current SI system by reducing the number of fundamental
units to only two ( S for space and T for time ), and it was a great
read. It even went so far as give a theory for the disapearance of the
dinosaurs!
Thank you for that it was a great read.
Here it is : http://www.blazelabs.com/f-u-suconv.asp
Christophe <···············@free.fr> writes:
> Robert Uhl a écrit :
>
>> The argument from popularity is invalid. French units have overtaken
>> standard units,
>
> Never heard of that French unit thing. Unless you talk about that
> archaic unit system that was in use before the metric system was
> created.
I use 'French units' instead of the term 'metric system' because the
latter means 'measurement system,' and of course could validly be
applied to _any_ system.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Due to an obsessive book-buying habit, and less time to read than I
would like, my to-read pile now has its own bookcase. --stevo
Robert Uhl wrote:
> Christophe <···············@free.fr> writes:
> > Robert Uhl a écrit :
> >
> >> The argument from popularity is invalid. French units have overtaken
> >> standard units,
> >
> > Never heard of that French unit thing. Unless you talk about that
> > archaic unit system that was in use before the metric system was
> > created.
>
> I use 'French units' instead of the term 'metric system' because the
> latter means 'measurement system,' and of course could validly be
> applied to _any_ system.
A good term to use, if your audience is likely to understand it, is "SI
units".
The current units used in science and for most measurements are
"Systeme International d'unites" Units. The original metric system is
not really used anymore, SI is slightly different.
Robert Uhl wrote:
> Christophe <···············@free.fr> writes:
>
>>Robert Uhl a écrit :
>>
>>
>>>The argument from popularity is invalid. French units have overtaken
>>>standard units,
>>
>>Never heard of that French unit thing. Unless you talk about that
>>archaic unit system that was in use before the metric system was
>>created.
>
>
> I use 'French units' instead of the term 'metric system' because the
> latter means 'measurement system,' and of course could validly be
> applied to _any_ system.
>
Now we know how one contractor ended up using English units when the
other was using French units and an entire Mars mission was lost: they
were both using the metric system.
[cue NASA aopologist Ron (or his sidekick Al) for some scenery-chewing
outrage over my condescension and arrogance.]
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
<snip>
> outrage over my condescension and arrogance.]
Your condescension and arrogance are fairly well established, and no
longer cause much outrage, except in extraordinary circumstances.
',mr
--
rydis (Martin Rydstr�m) @CD.Chalmers.SE http://www.rydis.se
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
["Followup-To:" header set to comp.lang.python.]
On 2006-12-08, Mark Tarver <··········@ukonline.co.uk> wrote:
> I'm looking at Python and I see that the syntax would appeal to
> a newbie. Its clearer than ML which is a mess syntactically.
And if you stew it like applesauce, it tastes more like prunes
than rhubarb does.
> But I don't see where the action is in Python. Not yet
> anyway. Lisp syntax is easy to learn. And giving up an order
> of magnitude is a high price to pay for using it over Lisp.
I find it easier to learn syntax than special forms. But either
system comes naturally enough with practice.
--
Neil Cerutti
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
>
> Mark
>
I do not know much about Lisp. What I know is:
Python is a imperative, object oriented dynamic language with duck typing, List is a declarative,
functional dynamic language -> those two languages have different scopes.
For more Information:
http://en.wikipedia.org/wiki/Functional_programming
http://en.wikipedia.org/wiki/Object-oriented_programming
http://en.wikipedia.org/wiki/Dynamic_programming_language
http://en.wikipedia.org/wiki/Lisp_programming_language
http://en.wikipedia.org/wiki/Python_%28programming_language%29
Mathias Panzenboeck wrote:
> Mark Tarver wrote:
> > How do you compare Python to Lisp? What specific advantages do you
> > think that one has over the other?
> >
> > Note I'm not a Python person and I have no axes to grind here. This is
> > just a question for my general education.
> >
> > Mark
> >
>
> I do not know much about Lisp. What I know is:
> Python is a imperative, object oriented dynamic language with duck typing,
Yes, but Python also supports the functional style to some extent.
> List is a declarative,
> functional dynamic language
Lisp is only a functional language in that it support both functional
and imperative programming styles. Duck typing is almost identical to
latent typing in Lisp.
And, Common Lisp at least is object orientated.
> -> those two languages have different scopes.
Their scope is actually very similar. Learn about lisp and you will
soon discover their similarity.
Rob Thorpe wrote:
> Mathias Panzenboeck wrote:
>> Mark Tarver wrote:
>>> How do you compare Python to Lisp? What specific advantages do you
>>> think that one has over the other?
>>>
>>> Note I'm not a Python person and I have no axes to grind here. This is
>>> just a question for my general education.
>>>
>>> Mark
>>>
>> I do not know much about Lisp. What I know is:
>> Python is a imperative, object oriented dynamic language with duck typing,
>
> Yes, but Python also supports the functional style to some extent.
>
I currently visit a course about functional programming at the university of technology vienna:
python implements only a small subset of things needed to be called a functional language (list
comprehension).
but yes, for a imperativ oop language python is very close to functional.
>> List is a declarative,
>> functional dynamic language
>
> Lisp is only a functional language in that it support both functional
> and imperative programming styles. Duck typing is almost identical to
> latent typing in Lisp.
> And, Common Lisp at least is object orientated.
>
>> -> those two languages have different scopes.
>
> Their scope is actually very similar. Learn about lisp and you will
> soon discover their similarity.
>
ic
Mathias Panzenboeck <········@student.tuwien.ac.at> writes:
> I currently visit a course about functional programming at the
> university of technology vienna: python implements only a small
> subset of things needed to be called a functional language (list
> comprehension). but yes, for a imperativ oop language python is
> very close to functional.
List comprehensions are just fairly trivial syntax sugar. The essence
of functional programming is being able to construct new functions on
the fly, and Python does that. See Hughes' paper "Why functional
programming matters" and imagine doing the examples in Python vs. doing
them in Java.
Mathias Panzenboeck a �crit :
> Rob Thorpe wrote:
>
>>Mathias Panzenboeck wrote:
>>
>>>Mark Tarver wrote:
>>>
>>>>How do you compare Python to Lisp? What specific advantages do you
>>>>think that one has over the other?
>>>>
>>>>Note I'm not a Python person and I have no axes to grind here. This is
>>>>just a question for my general education.
>>>>
>>>>Mark
>>>>
>>>
>>>I do not know much about Lisp. What I know is:
>>>Python is a imperative, object oriented dynamic language with duck typing,
>>
>>Yes, but Python also supports the functional style to some extent.
>>
>
>
> I currently visit a course about functional programming at the university of technology vienna:
> python implements only a small subset of things needed to be called a functional language (list
> comprehension).
Python has functions as first-class objects (you can pass functions as
arguments to functions, return functions from functions, and bind
functions to identifiers), and that's the only thing you need to use a
functional approach.
Mathias Panzenboeck <········@student.tuwien.ac.at> writes:
>
> I do not know much about Lisp. What I know is:
>
> Python is a imperative, object oriented dynamic language with duck
> typing, List is a declarative, functional dynamic language -> those
> two languages have different scopes.
Common Lisp is an object oriented language too, and while it has more
declarative features than Python, I don't think that it's really fair to
call it declarative in the same sense as, say, SQL.
Language-feature-wise, Lisp is a superset of Python: there's nothing one
can do in Python that cannot be done in Lisp, although there are some
things one would need to write oneself (e.g. generators) and some stuff
would be more of a pain (e.g. Python provides iterators, which means
that for can understand new objects; CL LOOP is not extensible, unless I
have missed something big, but it's simple enough to write a
map-new-object or loop-new-object or whatever).
Library-wise, Python is pretty much a superset of Lisp, and in fact many
of the things Lisp was criticised for providing as a standard part of
the language are also standard parts of Python.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The problem with 'post-modern' society is there are too many people with
nothing meaningful to do, building 'careers' around controlling the lives of
others and generally making social nuisances of themselves.
--Graham Strachan
Robert Uhl <·········@NOSPAMgmail.com> writes:
> that for can understand new objects; CL LOOP is not extensible, unless I
> have missed something big, but it's simple enough to write a
> map-new-object or loop-new-object or whatever).
There is no standard way to extend loop, but most of the major vendors
let you extend it using add-loop-path. In CLSQL you can do stuff like
(loop for (time event) being the tuples of "select time,event from log"
from *my-db*
do ... )
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mathias Panzenboeck a �crit :
> Mark Tarver wrote:
>
>>How do you compare Python to Lisp? What specific advantages do you
>>think that one has over the other?
>>
>>Note I'm not a Python person and I have no axes to grind here. This is
>>just a question for my general education.
>>
>>Mark
>>
>
>
> I do not know much about Lisp. What I know is:
> Python is a imperative, object oriented dynamic language with duck typing,
Python is a dynamic multi-paradigm language which is mostly OO but has
support for procedural and functional programming
> List
s/s/p/
> is a declarative,
> functional dynamic language -> those two languages have different scopes.
Lisp is a multi-paradigm language which is mostly functional but has
support for procedural and OO programming.
Both are highly dynamic. Neither are declarative.
Bruno Desthuilliers schrieb:
> Mathias Panzenboeck a �crit :
>> Mark Tarver wrote:
>>
>>> How do you compare Python to Lisp? What specific advantages do you
>>> think that one has over the other?
>>>
>>> Note I'm not a Python person and I have no axes to grind here. This is
>>> just a question for my general education.
>>>
>>> Mark
>>>
>>
>>
>> I do not know much about Lisp. What I know is:
>> Python is a imperative, object oriented dynamic language with duck
>> typing,
>
> Python is a dynamic multi-paradigm language which is mostly OO but has
> support for procedural and functional programming
>
>> List
>
> s/s/p/
>
>> is a declarative,
>> functional dynamic language -> those two languages have different scopes.
>
> Lisp is a multi-paradigm language which is mostly functional but has
> support for procedural and OO programming.
>
> Both are highly dynamic. Neither are declarative.
Well, Lisp does support some declarative features in the ansi standard.
Think about :before or :after methods. And with some days of work (has
already been done, so most Lispers could use it as a lib) you can get
many parts of Prolog. See http://bc.tech.coop/blog/040919.html
Andr�
--
Andr� Thieme a �crit :
> Bruno Desthuilliers schrieb:
>
(snip)
>> Both are highly dynamic. Neither are declarative.
>
>
> Well, Lisp does support some declarative features in the ansi standard.
If you go that way, there are declarative stuff in Python too... But
neither Lisp nor Python are close to, say, SQL.
Bruno Desthuilliers wrote:
> André Thieme a écrit :
> > Bruno Desthuilliers schrieb:
> >
> (snip)
> >> Both are highly dynamic. Neither are declarative.
> >
> >
> > Well, Lisp does support some declarative features in the ansi standard.
>
> If you go that way, there are declarative stuff in Python too... But
> neither Lisp nor Python are close to, say, SQL.
False. Common Lisp can be made to support SQL syntax.
Kaz Kylheku a �crit :
> Bruno Desthuilliers wrote:
>
>>Andr� Thieme a �crit :
>>
>>>Bruno Desthuilliers schrieb:
>>>
>>
>>(snip)
>>
>>>>Both are highly dynamic. Neither are declarative.
>>>
>>>
>>>Well, Lisp does support some declarative features in the ansi standard.
>>
>>If you go that way, there are declarative stuff in Python too... But
>>neither Lisp nor Python are close to, say, SQL.
>
>
> False. Common Lisp can be made to support SQL syntax.
>
And Python can be made to support something really close to it, cf
SQLAlchemy. And Python has list comprehensions, which are mostly on the
declarative side (ie : "what, not how"):
[x for x in range(100) if x % 2 == 0]
Etc, etc, etc...
Bruno Desthuilliers schrieb:
> Andr� Thieme a �crit :
>> Bruno Desthuilliers schrieb:
>>
> (snip)
>>> Both are highly dynamic. Neither are declarative.
>>
>>
>> Well, Lisp does support some declarative features in the ansi standard.
>
> If you go that way, there are declarative stuff in Python too... But
> neither Lisp nor Python are close to, say, SQL.
While this is absolutely right one can make Lisp coming much closer,
by going into the direction of, say, Prolog:
http://bc.tech.coop/blog/040919.html
Andr�
--
Okay, since everyone ignored the FAQ, I guess I can too...
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
(Common) Lisp is the only industrial strength language with both pure
compositionality and a real compiler. What Python has is stupid slogans
("It fits your brain." "Only one way to do things.") and an infinite
community of flies that, for some inexplicable reason, believe these
stupid slogns. These flies are, however, quite useful because they
produce infinite numbers of random libraries, some of which end up
being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
is rapidly replacing Perl, and Ruby is simultaneously and even more
rapidly replacing Python. Each is closer to Lisp than the last; the
world is returning to Lisp and is dragging the flies with it.
Eventually the flies will descend upon Lisp itself and will bring with
them their infinite number of random libraries, and then things will be
where they should have been 20 years ago, but got sidetracked by Tcl
and other line noise.
········@gmail.com wrote:
> Okay, since everyone ignored the FAQ, I guess I can too...
>
> Mark Tarver wrote:
> > How do you compare Python to Lisp? What specific advantages do you
> > think that one has over the other?
>
> (Common) Lisp is the only industrial strength language with both pure
> compositionality and a real compiler. What Python has is stupid slogans
> ("It fits your brain." "Only one way to do things.") and an infinite
> community of flies that, for some inexplicable reason, believe these
> stupid slogns. These flies are, however, quite useful because they
> produce infinite numbers of random libraries, some of which end up
> being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
> is rapidly replacing Perl, and Ruby is simultaneously and even more
> rapidly replacing Python. Each is closer to Lisp than the last; the
> world is returning to Lisp and is dragging the flies with it.
> Eventually the flies will descend upon Lisp itself and will bring with
> them their infinite number of random libraries, and then things will be
> where they should have been 20 years ago, but got sidetracked by Tcl
> and other line noise.
What is it about Lisp that despite doing everything first, way before
any other language, people don't stop using anything else and
automatically turn to Lisp? Maybe there is more to this everything than
the Lisp community comprehends.
Maybe Lisp is to science, as Python is to engineering - with a slight
blurring round the edges?
- Paddy.
········@gmail.com wrote:
> Okay, since everyone ignored the FAQ, I guess I can too...
>
> Mark Tarver wrote:
> > How do you compare Python to Lisp? What specific advantages do you
> > think that one has over the other?
>
> (Common) Lisp is the only industrial strength language with both pure
> compositionality and a real compiler. What Python has is stupid slogans
> ("It fits your brain." "Only one way to do things.") and an infinite
> community of flies that, for some inexplicable reason, believe these
> stupid slogns. These flies are, however, quite useful because they
> produce infinite numbers of random libraries, some of which end up
> being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
> is rapidly replacing Perl, and Ruby is simultaneously and even more
> rapidly replacing Python. Each is closer to Lisp than the last; the
> world is returning to Lisp and is dragging the flies with it.
> Eventually the flies will descend upon Lisp itself and will bring with
> them their infinite number of random libraries, and then things will be
> where they should have been 20 years ago, but got sidetracked by Tcl
> and other line noise.
I know we shouldn't feed the trolls, but this one was particularly
amusing to resist the urge. The joke about lisp's world domination in
some unspecified point in the future never fails to bring a good
chuckle. I heard it's scheduled right after strong AI and before time
travel, is this still the plan? A quick look at
http://www.tiobe.com/tpci.htm may be helpful as a reality check before
you go back to your ivory tower (interesting how close in ratings and
growth is the "Lisp/Scheme" entry with another dinosaur, Cobol).
> I heard it's scheduled right after strong AI and before time
> travel...
I think that time travel predated strong AI, although I'm not sure
since it's a little hard to pin down the time coordinates of time
travel (probably The Time Machine will do
> A quick look at
> http://www.tiobe.com/tpci.htm may be helpful as a reality check before
> you go back to your ivory tower (interesting how close in ratings and
> growth is the "Lisp/Scheme" entry with another dinosaur, Cobol).
Oh, Right, George... Reality, of course... I completely neglected
random surveys! I suppose that we should all be using VB because this
survey tells us it's the next best things to C++! See that Ruby green
arrow rocketing up behind you, George; better watch your ass, clown. :-)
George Sakkis wrote:
> ········@gmail.com wrote:
>
>>Okay, since everyone ignored the FAQ, I guess I can too...
>>
>>Mark Tarver wrote:
>>
>>>How do you compare Python to Lisp? What specific advantages do you
>>>think that one has over the other?
>>
>>(Common) Lisp is the only industrial strength language with both pure
>>compositionality and a real compiler. What Python has is stupid slogans
>>("It fits your brain." "Only one way to do things.") and an infinite
>>community of flies that, for some inexplicable reason, believe these
>>stupid slogns. These flies are, however, quite useful because they
>>produce infinite numbers of random libraries, some of which end up
>>being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
>>is rapidly replacing Perl, and Ruby is simultaneously and even more
>>rapidly replacing Python. Each is closer to Lisp than the last; the
>>world is returning to Lisp and is dragging the flies with it.
>>Eventually the flies will descend upon Lisp itself and will bring with
>>them their infinite number of random libraries, and then things will be
>>where they should have been 20 years ago, but got sidetracked by Tcl
>>and other line noise.
>
>
> I know we shouldn't feed the trolls, but this one was particularly
> amusing to resist the urge. The joke about lisp's world domination in
> some unspecified point in the future never fails to bring a good
> chuckle. I heard it's scheduled right after strong AI and before time
> travel, is this still the plan? A quick look at
> http://www.tiobe.com/tpci.htm may be helpful as a reality check before
> you go back to your ivory tower (interesting how close in ratings and
> growth is the "Lisp/Scheme" entry with another dinosaur, Cobol).
>
And it interesting that VB is almost three times "better" than Python,
and that a Honda could kick a Lamboghini's ass for it at Laguna Seca:
http://www.googlefight.com/index.php?lang=en_GB&word1=lamborghini&word2=ford
Come on, COBOL is a great language, even has macros (copy ... replacing)
and the worlds greatest case statement, evaluate. We are proud to be its
neightbor.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> George Sakkis wrote:
> > ········@gmail.com wrote:
> >
> >>Okay, since everyone ignored the FAQ, I guess I can too...
> >>
> >>Mark Tarver wrote:
> >>
> >>>How do you compare Python to Lisp? What specific advantages do you
> >>>think that one has over the other?
> >>
> >>(Common) Lisp is the only industrial strength language with both pure
> >>compositionality and a real compiler. What Python has is stupid slogans
> >>("It fits your brain." "Only one way to do things.") and an infinite
> >>community of flies that, for some inexplicable reason, believe these
> >>stupid slogns. These flies are, however, quite useful because they
> >>produce infinite numbers of random libraries, some of which end up
> >>being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
> >>is rapidly replacing Perl, and Ruby is simultaneously and even more
> >>rapidly replacing Python. Each is closer to Lisp than the last; the
> >>world is returning to Lisp and is dragging the flies with it.
> >>Eventually the flies will descend upon Lisp itself and will bring with
> >>them their infinite number of random libraries, and then things will be
> >>where they should have been 20 years ago, but got sidetracked by Tcl
> >>and other line noise.
> >
> >
> > I know we shouldn't feed the trolls, but this one was particularly
> > amusing to resist the urge. The joke about lisp's world domination in
> > some unspecified point in the future never fails to bring a good
> > chuckle. I heard it's scheduled right after strong AI and before time
> > travel, is this still the plan? A quick look at
> > http://www.tiobe.com/tpci.htm may be helpful as a reality check before
> > you go back to your ivory tower (interesting how close in ratings and
> > growth is the "Lisp/Scheme" entry with another dinosaur, Cobol).
> >
>
> And it interesting that VB is almost three times "better" than Python,
> and that a Honda could kick a Lamboghini's ass for it at Laguna Seca:
Didn't say better, not even in quotes (and btw, if you're only doing
GUI apps in MS, VB is the path of least resistance in many cases, as is
PHP for quick'n'dirty web apps). What was funny in the GP's post was
the pomposity about "flies eventually descending upon Lisp itself", as
if language popularity (or any popularity for that matter) is
determined solely by theoretical computer science metrics.
George
Ken Tilton wrote:
> George Sakkis wrote:
> > ········@gmail.com wrote:
> >
> >>Okay, since everyone ignored the FAQ, I guess I can too...
> >>
> >>Mark Tarver wrote:
> >>
> >>>How do you compare Python to Lisp? What specific advantages do you
> >>>think that one has over the other?
> >>
> >>(Common) Lisp is the only industrial strength language with both pure
> >>compositionality and a real compiler. What Python has is stupid slogans
> >>("It fits your brain." "Only one way to do things.") and an infinite
> >>community of flies that, for some inexplicable reason, believe these
> >>stupid slogns. These flies are, however, quite useful because they
> >>produce infinite numbers of random libraries, some of which end up
> >>being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
> >>is rapidly replacing Perl, and Ruby is simultaneously and even more
> >>rapidly replacing Python. Each is closer to Lisp than the last; the
> >>world is returning to Lisp and is dragging the flies with it.
> >>Eventually the flies will descend upon Lisp itself and will bring with
> >>them their infinite number of random libraries, and then things will be
> >>where they should have been 20 years ago, but got sidetracked by Tcl
> >>and other line noise.
> >
> >
> > I know we shouldn't feed the trolls, but this one was particularly
> > amusing to resist the urge. The joke about lisp's world domination in
> > some unspecified point in the future never fails to bring a good
> > chuckle. I heard it's scheduled right after strong AI and before time
> > travel, is this still the plan? A quick look at
> > http://www.tiobe.com/tpci.htm may be helpful as a reality check before
> > you go back to your ivory tower (interesting how close in ratings and
> > growth is the "Lisp/Scheme" entry with another dinosaur, Cobol).
> >
>
> And it interesting that VB is almost three times "better" than Python,
> and that a Honda could kick a Lamboghini's ass for it at Laguna Seca:
>
> http://www.googlefight.com/index.php?lang=en_GB&word1=lamborghini&word2=ford
>
> Come on, COBOL is a great language, even has macros (copy ... replacing)
> and the worlds greatest case statement, evaluate. We are proud to be its
> neightbor.
>
> ken
>
> --
> Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
>
> "Well, I've wrestled with reality for thirty-five
> years, Doctor, and I'm happy to state I finally
> won out over it." -- Elwood P. Dowd
>
> "I'll say I'm losing my grip, and it feels terrific."
> -- Smiling husband to scowling wife, New Yorker cartoon
Well, Cobol still has the largest and most easy to comprehend system
for doing decimal arithmetic.
Jurgen
········@gmail.com wrote:
> Okay, since everyone ignored the FAQ, I guess I can too...
[snip]
> What Python has is stupid slogans
> ("It fits your brain." "Only one way to do things.") and an infinite
> community of flies that, for some inexplicable reason, believe these
> stupid slogns.
IOW, you posted the FAQ so you could appear to have highest moral
ground, then you ignore your own advice and promptly head to the very
lowest ground with ad hominem insults. Congratulations! That was
quite a turnaround.
(In fact, it was almost as a big a turnaround as a typical newbie who
tries Lisp.)
Carl Banks
Carl Banks wrote:
> ········@gmail.com wrote:
> > Okay, since everyone ignored the FAQ, I guess I can too...
> [snip]
> > What Python has is stupid slogans
> > ("It fits your brain." "Only one way to do things.") and an infinite
> > community of flies that, for some inexplicable reason, believe these
> > stupid slogns.
>
> IOW, you posted the FAQ so you could appear to have highest moral
> ground, then you ignore your own advice and promptly head to the very
> lowest ground with ad hominem insults.
You're right, in part: My implicitly linking Python's pros or cons with
its stupid marketing hype is, I think, an ad hominem argument. But I
don't see a moral issue here; the purpose of posting the FAQ was merely
to try to stop the fight. It failed.
Regardless, there was some content in my post which you have not
addressed:
To wit:
1. Lisp is the only industrial strength language with pure
compositionality, and that this makes it suprior to Python. We don't
have to debate this because it's being debated elsewhere in this
thread.
2. Ruby, which is closer to Lisp than Python, is beginning to eat
Python's lunch. We don't have to debate this either because George has
kindly gave support to it through posting a survey that made this point
quite nicely; Thanks, George! :-)
BTW, for the record, I don't have anything particularly against Python
aside from its stupid marketing hype and a bit of jealousy over those
flies building libraries which I wish we had in Lisp. I've made the
choice uncountable times between PERL, Python, and Tcl when I didn't
have Lisp as an option, and I have always chosen Python in these cases,
even though I can program in any of these. (Although I'm probably going
to start using Ruby instead of Python in these cases, but I'm not
really expert in it yet.)
(Actually, in many cases I can get away with Emacs keyboard macros
where others would program in PERL or Python, although not always.)
········@gmail.com wrote:
> Carl Banks wrote:
> > ········@gmail.com wrote:
> > > Okay, since everyone ignored the FAQ, I guess I can too...
> > [snip]
> > > What Python has is stupid slogans
> > > ("It fits your brain." "Only one way to do things.") and an infinite
> > > community of flies that, for some inexplicable reason, believe these
> > > stupid slogns.
> >
> > IOW, you posted the FAQ so you could appear to have highest moral
> > ground, then you ignore your own advice and promptly head to the very
> > lowest ground with ad hominem insults.
>
> You're right, in part: My implicitly linking Python's pros or cons with
> its stupid marketing hype is, I think, an ad hominem argument.
Ahem. Calling Python programmers "flies".
> But I
> don't see a moral issue here; the purpose of posting the FAQ was merely
> to try to stop the fight. It failed.
GMAB. If you were really interested in not fighting you would have
shut up.
> Regardless, there was some content in my post which you have not
> addressed:
>
> To wit:
>
> 1. Lisp is the only industrial strength language with pure
> compositionality, and that this makes it suprior to Python. We don't
> have to debate this because it's being debated elsewhere in this
> thread.
>
> 2. Ruby, which is closer to Lisp than Python, is beginning to eat
> Python's lunch. We don't have to debate this either because George has
> kindly gave support to it through posting a survey that made this point
> quite nicely; Thanks, George! :-)
>
> BTW, for the record, I don't have anything particularly against Python
> aside from its stupid marketing hype and a bit of jealousy over those
> flies building libraries which I wish we had in Lisp. I've made the
> choice uncountable times between PERL, Python, and Tcl when I didn't
> have Lisp as an option, and I have always chosen Python in these cases,
> even though I can program in any of these. (Although I'm probably going
> to start using Ruby instead of Python in these cases, but I'm not
> really expert in it yet.)
>
> (Actually, in many cases I can get away with Emacs keyboard macros
> where others would program in PERL or Python, although not always.)
Whatever, fanboy.
Carl Banks
"Carl Banks" <··············@gmail.com> writes:
>> You're right, in part: My implicitly linking Python's pros or cons with
>> its stupid marketing hype is, I think, an ad hominem argument.
>
> Ahem. Calling Python programmers "flies".
For what it's worth, I don't think this was called for, either.
> Whatever, fanboy.
Weak.
········@gmail.com wrote:
> 1. Lisp is the only industrial strength language
^^^^^^^^^^^^^^^^^^^
You keep using that phrase. I don't think it means what you think it
means.
> with pure compositionality, and that this makes it suprior to Python.
Perhaps it does in some programming language theory research groups. In
the real world, superiority has to do with far more than technical
merits alone, let alone obscure metaprogramming features which are
irrelevant to the vast majority of programmers.
> 2. Ruby, which is closer to Lisp than Python, is beginning to eat
> Python's lunch. We don't have to debate this either because George has
> kindly gave support to it through posting a survey that made this point
> quite nicely; Thanks, George! :-)
AKA "if you can't beat them, join them". I don't know if other lispers
would join you in your feeble attempt to steal a bite from Ruby's
current glory (mostly thanks to the admirable marketing around the
overhyped Rails framework), but Ruby is much closer to Python than
either of them is to lisp. In fact, if Python suddenly disappeared,
Ruby would probably be my next stop. Both Ruby and Python are high
level dynamic languages with an emphasis on pragmatic needs, not being
the language of the God(s) (see, I can bring up stupid slogans of
languages too). The similarities between Python and Ruby outweigh their
differences, resulting in very few defections from one to the other, so
nobody's eating the other's lunch. They are both appealing alternatives
to different (overlapping) subsets of the Java/C++/Perl/PHP crowd, and
the choice between the two usually comes down to a subjective
preference about the syntax, the availability of libraries or other
non-technical reasons.
> BTW, for the record, I don't have anything particularly against Python
> aside from its stupid marketing hype and a bit of jealousy over those
Talk about a well-founded reason to diss a language.
George
George Sakkis wrote:
> ········@gmail.com wrote:
>
>
>>1. Lisp is the only industrial strength language
>
> ^^^^^^^^^^^^^^^^^^^
> You keep using that phrase. I don't think it means what you think it
> means.
To me in part it means "no one can decide to take away lambda because
they decided they should not have put it in in the first place and then
change their mind and leave it in after I already put a few people on
de-lambdifying our 100kloc system because...", and in part it means
compilation. And it /has/ to have macros. :)
> Perhaps it does in some programming language theory research groups.
haha, the same old straw man, Is it not embarrassing to have to resort
to the same defeated argument again and again?
> In
> the real world, superiority has to do with far more than technical
> merits alone, let alone obscure metaprogramming features ...
Metaprogramming by definition cannot be obscure. Metaprogramming means
programming at a higher level. A higher level means "more productive".
More productive is the essence of pragmatism. QED.
> ...which are
> irrelevant to the vast majority of programmers.
You insult them by suggesting they cannot concieve at a higher level.
Mebbe they could if their language aupported it. Yours does not.
> I don't know if other lispers
> would join you in your feeble attempt to steal a bite from Ruby's
> current glory...
Of course we would. You do not get it. The only thing you guys are
bleating about is greater popularity. Now someone is about to eat your
lunch popularity-wise. Live by the poll, die by the poll. And you held
first place for like a week in language geologic time, taken down merely
because...
> (mostly thanks to the admirable marketing around the
> overhyped Rails framework)
... a little hype came along? Wow, your fundamental advantage must have
been about zip, and all derived from things unrelated to syntax. <gasp>
, but Ruby is much closer to Python than
> either of them is to lisp. In fact, if Python suddenly disappeared,
> Ruby would probably be my next stop. Both Ruby and Python are high
> level dynamic languages with an emphasis on pragmatic needs, not being
> the language of the God(s) (see, I can bring up stupid slogans of
> languages too).
As Graham said, if some pretty good programmers are jumping up and down
about X, mebbe you should take a look at X. Even if assholes like me
piss you off. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> George Sakkis wrote:
> > ········@gmail.com wrote:
> >
> >
> >>1. Lisp is the only industrial strength language
> >
> > ^^^^^^^^^^^^^^^^^^^
> > You keep using that phrase. I don't think it means what you think it
> > means.
>
> To me in part it means "no one can decide to take away lambda because
> they decided they should not have put it in in the first place and then
> change their mind and leave it in after I already put a few people on
> de-lambdifying our 100kloc system because..."
Funny, coming from the guy with an inclination in discovering straw man
arguments in others. Python 3.0 should be at least a year away from
now, let alone the time of discussions about lambda. If you're changing
a working system based on brainstorms and speculations about a
backwards incompatible version to appear after two years or three, I
can't feel sorry for you :)
> , and in part it means
> compilation. And it /has/ to have macros. :)
Oh, and I had the vague impression that it was somehow related to
standards about bleeding-edge technologies, such as sockets. But then,
I could be wrong :)
> Metaprogramming by definition cannot be obscure. Metaprogramming means
> programming at a higher level.
Check.
> A higher level means "more productive".
*Segfault* *core dump* *kernel panic* :)
No, it is more productive only if you (and the other 5, 10, 100 people
in your group) can understand, implement, debug, test and maintain code
in that higher level of abstraction.
The rest of the proof is therefore irrelevant ;-)
> > ...which are
> > irrelevant to the vast majority of programmers.
>
> You insult them by suggesting they cannot concieve at a higher level.
> Mebbe they could if their language aupported it. Yours does not.
Actually it does. Metaclasses, descriptors, decorators are some high
level Python concepts. Most people are productive in Python for years
without ever having to write a custom metaclass, or even know their
existence (although a library or framework they use daily might in fact
use all of the above). Ever heard of Zope ? Even though it's written in
Python, it is criticised for its steep learning curve, one main reason
being its high level of abstraction.
> > I don't know if other lispers
> > would join you in your feeble attempt to steal a bite from Ruby's
> > current glory...
>
> Of course we would. You do not get it. The only thing you guys are
> bleating about is greater popularity. Now someone is about to eat your
> lunch popularity-wise. Live by the poll, die by the poll. And you held
> first place for like a week in language geologic time, taken down merely
> because...
>
> > (mostly thanks to the admirable marketing around the
> > overhyped Rails framework)
>
> ... a little hype came along? Wow, your fundamental advantage must have
> been about zip, and all derived from things unrelated to syntax. <gasp>
Well, for one thing we never held the first place anyway. Second, what
appears to be the big boost for Ruby today maybe its death sentence
tomorrow, ending up as a niche language for web apps, like PHP today.
With a large crowd undoubtly, but I bet most Pythonistas would prefer
lower popularity than ending up in a corner of the application
spectrum.
> , but Ruby is much closer to Python than
> > either of them is to lisp. In fact, if Python suddenly disappeared,
> > Ruby would probably be my next stop. Both Ruby and Python are high
> > level dynamic languages with an emphasis on pragmatic needs, not being
> > the language of the God(s) (see, I can bring up stupid slogans of
> > languages too).
>
> As Graham said, if some pretty good programmers are jumping up and down
> about X, mebbe you should take a look at X. Even if assholes like me
> piss you off. :)
Change that to "amuse me"; nothing better than a sense of
self-knowledge :) If you mean the same Graham that wrote
http://paulgraham.com/pypar.html, perhaps we don't disagree that much
after all :)
George
George Sakkis schrieb:
> Well, for one thing we never held the first place anyway. Second, what
> appears to be the big boost for Ruby today maybe its death sentence
> tomorrow, ending up as a niche language for web apps, like PHP today.
> With a large crowd undoubtly, but I bet most Pythonistas would prefer
> lower popularity than ending up in a corner of the application
> spectrum.
Who really wants to write web apps? Web apps are just an excuse for
Pythonistas to write web frameworks.
George Sakkis wrote:
> ········@gmail.com wrote:
>
>> 1. Lisp is the only industrial strength language
> ^^^^^^^^^^^^^^^^^^^
> You keep using that phrase. I don't think it means what you think it
> means.
[Vizzini has just cut the rope The Dread Pirate Roberts is climbing up]
Vizzini: HE DIDN'T FALL? INCONCEIVABLE.
Inigo Montoya: You keep using that word. I do not think it means what
you think it means.
Brian Adkins wrote:
> George Sakkis wrote:
>
>> ········@gmail.com wrote:
>>
>>> 1. Lisp is the only industrial strength language
Neither Lisp nor Python is an "industrial strength language".
The infrastructure is too weak. Hosting providers and distro
makers aren't concerned over whether Python works. They
care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
Ask them.
John Nagle
Brian Adkins wrote:
> John Nagle wrote:
>
>> Neither Lisp nor Python is an "industrial strength language".
>> The infrastructure is too weak. Hosting providers and distro
>> makers aren't concerned over whether Python works. They
>> care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
>> Ask them.
>>
>> John Nagle
>
>
> In your excitement to post a sweeping and inaccurate generalization (you
> missed diss'ing Ruby), I think you may have missed the point of my post.
> I surely wasn't trying to restart a dead thread, I just thought it was
> funny that there was a similarity to a line from Princess Bride in the
> thread (see relevant part below that you cut out).
>
> If you want to restart a debate, please go back and reply to some
> serious post in the thread - don't hijack mine for your own evil
> purposes and cut out the good parts - did you even see the movie?
Yes. I think George did, too. (I was wondering what you were up to.)
:)
kt
>
> George Sakkis wrote:
> > You keep using that phrase. I don't think it means what you think it
> > means.
>
> [Vizzini has just cut the rope The Dread Pirate Roberts is climbing up]
> Vizzini: HE DIDN'T FALL? INCONCEIVABLE.
> Inigo Montoya: You keep using that word. I do not think it means what
> you think it means.
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
John Nagle wrote:
> Hosting providers and distro
> makers aren't concerned over whether Python works. They
> care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
> Ask them.
Do you have any real experience with recent linux distros? Or with any
_real_ hosting providers?
Because what you've said is clearly not true. Just because the
situation isn't as easy _for you_ as you would like, doesn't mean that
Python is being ignored to the extent you're trying to claim.
-alex23
"alex23" <·······@gmail.com> writes:
> > Hosting providers and distro
> > makers aren't concerned over whether Python works. They
> > care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
> > Ask them.
>
> Do you have any real experience with recent linux distros? Or with any
> _real_ hosting providers?
Care to name a "real" hosting provider that cares whether Python works?
Paul Rubin <·············@NOSPAM.invalid> wrote:
> "alex23" <·······@gmail.com> writes:
> > > Hosting providers and distro
> > > makers aren't concerned over whether Python works. They
> > > care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
> > > Ask them.
> >
> > Do you have any real experience with recent linux distros? Or with any
> > _real_ hosting providers?
>
> Care to name a "real" hosting provider that cares whether Python works?
The first name that comes to mind is xs4all, the major Dutch provider
(they've even got their own Wikipedia entry!-) -- they've long offered
outstanding sponsorship to the Python community, hosting lots of
services for us, btw.
But the OP's mention of "distro" ain't even funny -- ever since RedHat's
original implementation of RPM (in Python), ever more Linux distros are
positively _fanatical_ about Python. Ubuntu, for example, has as its
BDFL Mark Shuttleworth, who (since, as he explains, he made his fortune
thanks to Python -- Python's what allowed him to build Thawte, which he
later sold for mucho dinero) is an unabashed fan of Python; the "XO"
(nee "One Laptop Per Child", OLPC, and once known as the "$100 laptop")
uses Python as its preferred (only?-) application language, and it's
slated to be the most widely distributed Python distro if it hits even
half of its ambitious target-numbers...
Alex
On 2007-03-09 07:00:06 +0000, ·····@mac.com (Alex Martelli) said:
> (nee "One Laptop Per Child", OLPC, and once known as the "$100 laptop")
> uses Python as its preferred (only?-) application language, and it's
> slated to be the most widely distributed Python distro if it hits even
> half of its ambitious target-numbers...
But it won't get anywhere near that because it's a stupid an
ill-conceived idea (not because of Python, note!). The electronic
gadget people need in the developing world is a mobile phone not a
computer.
alex23 wrote:
> John Nagle wrote:
>> Hosting providers and distro
>> makers aren't concerned over whether Python works. They
>> care if C, C++, Java, PHP, and Perl work, but not Python or LISP.
>> Ask them.
>
> Do you have any real experience with recent linux distros? Or with any
> _real_ hosting providers?
>
> Because what you've said is clearly not true. Just because the
> situation isn't as easy _for you_ as you would like, doesn't mean that
> Python is being ignored to the extent you're trying to claim.
>
> -alex23
>
alex23 - please don't feed the trolls.
Brian Adkins wrote:
> John Nagle wrote:
> If you want to restart a debate, please go back and reply to some
> serious post in the thread - don't hijack mine for your own evil
> purposes and cut out the good parts - did you even see the movie?
If you want to post jokes, try rec.humor.funny. Although
they mave moderation and you may not
John Nagle
John Nagle wrote:
> Brian Adkins wrote:
>
>> John Nagle wrote:
>
>
>> If you want to restart a debate, please go back and reply to some
>> serious post in the thread - don't hijack mine for your own evil
>> purposes and cut out the good parts - did you even see the movie?
>
>
> If you want to post jokes...
fer chrissakes, it was the OP of "means what you think it means" who was
obviously doing Princess Bride and being reasonably funny, Brian just
missed that it was deliberate.
, try ...
....comp.lang.lisp. All the SBCL bug reports are starting to drag down
the mood of this NG.
kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
Ken Tilton wrote:
> John Nagle wrote:
>> Brian Adkins wrote:
>>> John Nagle wrote:
>>> If you want to restart a debate, please go back and reply to some
>>> serious post in the thread - don't hijack mine for your own evil
>>> purposes and cut out the good parts - did you even see the movie?
>>
>>
>> If you want to post jokes...
>
> fer chrissakes, it was the OP of "means what you think it means" who was
> obviously doing Princess Bride and being reasonably funny,
Turns out John is having quite a tough time with Python web hosting (the
thread has split off to a c.l.p only fork), so I'm going to cut him some
slack. Maybe with some lovin' we can woo him over to c.l.l ;)
> Brian just
> missed that it was deliberate.
D'oh!
> , try ...
>
> ....comp.lang.lisp. All the SBCL bug reports are starting to drag down
> the mood of this NG.
>
> kt
>
········@gmail.com wrote:
> Okay, since everyone ignored the FAQ, I guess I can too...
>
> Mark Tarver wrote:
>> How do you compare Python to Lisp? What specific advantages do you
>> think that one has over the other?
>
> (Common) Lisp is the only industrial strength language with both pure
> compositionality and a real compiler. What Python has is stupid slogans
> ("It fits your brain." "Only one way to do things.") and an infinite
> community of flies that, for some inexplicable reason, believe these
> stupid slogns. These flies are, however, quite useful because they
> produce infinite numbers of random libraries, some of which end up
> being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
> is rapidly replacing Perl, and Ruby is simultaneously and even more
> rapidly replacing Python. Each is closer to Lisp than the last; the
> world is returning to Lisp and is dragging the flies with it.
> Eventually the flies will descend upon Lisp itself and will bring with
> them their infinite number of random libraries, and then things will be
> where they should have been 20 years ago, but got sidetracked by Tcl
> and other line noise.
>
Hmmm. The last time I fooled around with Lisp was 1966 from the Lisp
1.5 Manual Published by MIT in cloth. It was interesting and different
from the other languages I was using, Algol 60, Basic and Macro
assembler for the GE-235 and GE-635. When I read some of the over the
top type hype by Lisp enthusiasts (like the stuff above) it feels like a
flash back to the mid 60's. Personally, I never like Lisp syntax;
Clearly some people, some fanatic judging by this thread :) think easily
in prefix. I am not one of them. Computer languages are tools and
everyone should pick the ones that they are most comfortable and
productive with.
Six years ago, when I drifted back into programming, I had to learn
about Object Oriented programming and C++. I used Python as a means to
update my programming skills (limited though they are) by 30 years or
so. It was a wonderful intro to OO and served me well. I ended up
writing all kinds of little things for work (simple HTTP servers for
load testing, ECAD hacks for the ASIC guys, even a register level chip
simulator) Even better, I find it a pleasure to write small utilities,
to prototype C code and generally do things quickly. I use it by choice
to get things done, not because it is mandated. At my current job as a
Systems Engineer for a large aerospace firm, I do not program daily, but
when I need to write a quick hack, I always use Python.
david
David Lees <···········@verizon.net> writes:
> ········@gmail.com wrote:
>> Okay, since everyone ignored the FAQ, I guess I can too...
>> Mark Tarver wrote:
>>> How do you compare Python to Lisp? What specific advantages do you
>>> think that one has over the other?
>> (Common) Lisp is the only industrial strength language with both pure
>> compositionality and a real compiler. What Python has is stupid slogans
>> ("It fits your brain." "Only one way to do things.") and an infinite
>> community of flies that, for some inexplicable reason, believe these
>> stupid slogns. These flies are, however, quite useful because they
>> produce infinite numbers of random libraries, some of which end up
>> being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
>> is rapidly replacing Perl, and Ruby is simultaneously and even more
>> rapidly replacing Python. Each is closer to Lisp than the last; the
>> world is returning to Lisp and is dragging the flies with it.
>> Eventually the flies will descend upon Lisp itself and will bring with
>> them their infinite number of random libraries, and then things will be
>> where they should have been 20 years ago, but got sidetracked by Tcl
>> and other line noise.
>>
>
> Hmmm. The last time I fooled around with Lisp was 1966 from the Lisp
> 1.5 Manual Published by MIT in cloth. It was interesting and
> different from the other languages I was using, Algol 60, Basic and
> Macro assembler for the GE-235 and GE-635. When I read some of the
> over the top type hype by Lisp enthusiasts (like the stuff above) it
> feels like a flash back to the mid 60's. Personally, I never like
> Lisp syntax; Clearly some people, some fanatic judging by this thread
> :) think easily in prefix. I am not one of them.
Doesn't matter. We are Borg. You will be assimilated. Resistance is
futile. :-)
But seriously, look at how features from Lisp are constantly finding
their way into mainstream programming languages and have done so for
decades (garbage colection, closures, ...). Maybe one day prefix
notation and Lisp style macros will also find their way into other
languages and then Lisp will finally take over. :-) And here's another
thing: All the interesting features that haven't originated from Lisp
(e. g. OO from Smalltalk) could in turn easily be implemented in Lisp
with a couple of macros. I. e. if Common Lisp didn't have CLOS, its
object system, I could write my own as a library and it would be just
as powerful and just as easy to use as the system Common Lisp already
provides. Stuff like this is impossible in other languages.
To summarize: Lispers are not fanatics. And if we appear to be then
it is simply because we recognize that Lisp truly is The Chosen
Language. [1]
Footnotes:
[1] Kidding! :-) ... or am I?
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
"Wolfram Fenske" <·····@gmx.net> writes:
> with a couple of macros. I. e. if Common Lisp didn't have CLOS, its
> object system, I could write my own as a library and it would be just
> as powerful and just as easy to use as the system Common Lisp already
> provides. Stuff like this is impossible in other languages.
If Common Lisp didn't have lexically scoped variables (most Lisp
dialects before Scheme didn't have them) then it would be very
difficult to add that with macros.
Do you seriously think lexical scoping is the last word in language
features and that there's now nothing left in other languages that
can't straightforwardly be done in CL? Hint:
call-with-current-continuation (also known as call/cc).
I just don't see a non-messy way to simulate Python generators in CL.
They can be done in Scheme using call/cc though.
Take a look sometime at Hughes' paper on "Why Functional Programming
Matters":
http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
The examples in it are pretty easy to do in Python or Scheme, but I
think not so easy in CL.
Paul Rubin <·············@NOSPAM.invalid> writes:
> http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
>
> The examples in it are pretty easy to do in Python or Scheme, but I
> think not so easy in CL.
Hmm, well I guess they can be done in CL too, about the same way as in
Scheme, but I'd say you have to be more careful.
(message (Hello 'Paul)
(you :wrote :on '(09 Dec 2006 01:01:14 -0800))
(
PR> If Common Lisp didn't have lexically scoped variables (most Lisp
PR> dialects before Scheme didn't have them) then it would be very
PR> difficult to add that with macros.
i think there's some way to hack that. for example, make defun a macro that
will collect all lexically scoped variable and mangle them. for example:
(defun foo () (let ((i 1)) (print i)))
will be transformed to
(defun foo () (let ((i_foo 1)) (print i_foo)))
(or just some random suffix). this way variables in different functions will
never collide. maybe there's a catch somewhere, but that should look very
close to lexical variables.
PR> Do you seriously think lexical scoping is the last word in language
PR> features and that there's now nothing left in other languages that
PR> can't straightforwardly be done in CL? Hint:
PR> call-with-current-continuation (also known as call/cc).
there's nothing impossible :)
we even have a lib for nondeterministic calculations -- Screamer, that's
much much more cool than that call/cc..
(defun pythagorean-triples (n)
(all-values
(let ((a (an-integer-between 1 n))
(b (an-integer-between 1 n))
(c (an-integer-between 1 n)))
(unless (= (+ (* a a) (* b b)) (* c c)) (fail))
(list a b c))))
you define ranges for variables, define constraints (in a form very close to
normal lisp code) and then just say -- all-values, or solutions (first thing
that satisfies constaints).
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Paul Rubin <·············@NOSPAM.invalid> writes:
> "Wolfram Fenske" <·····@gmx.net> writes:
>> with a couple of macros. I. e. if Common Lisp didn't have CLOS, its
>> object system, I could write my own as a library and it would be just
>> as powerful and just as easy to use as the system Common Lisp already
>> provides. Stuff like this is impossible in other languages.
>
> If Common Lisp didn't have lexically scoped variables (most Lisp
> dialects before Scheme didn't have them) then it would be very
> difficult to add that with macros.
Alex Mizrahi already took care of that one.
> Do you seriously think lexical scoping is the last word in language
> features and that there's now nothing left in other languages that
> can't straightforwardly be done in CL?
No. My point was more that Lisp is so flexible that it even allows
you to add something as huge as object orientation without requiring a
change to the compiler. What about Aspect-Oriented Programming, for
example? For Java, you need a new compiler/preprocessor, for Lisp, it
can be implemented as a library [1].
> Hint: call-with-current-continuation (also known as call/cc).
You're right call/cc is a problem because you basically can't
implement call/cc without having call/cc. I. e. it requires pervasive
changes to the compiler/interpreter if something like it is not
already in there. Still, Scheme--also a Lisp--has call/cc and was
probably the first language to implement it.
> I just don't see a non-messy way to simulate Python generators in CL.
> They can be done in Scheme using call/cc though.
Scheme is also a Lisp. So?
> Take a look sometime at Hughes' paper on "Why Functional Programming
> Matters":
>
> http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
>
> The examples in it are pretty easy to do in Python or Scheme, but I
> think not so easy in CL.
Anything in particular? I'd be surprised if the solutions in Scheme
and CL would differ very much because apart from the Lisp-1/Lisp-2
issue and call/cc, Scheme and CL are not that different.
Footnotes:
[1] <http://common-lisp.net/project/closer/aspectl.html>
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
"Wolfram Fenske" <·····@gmx.net> writes:
> > If Common Lisp didn't have lexically scoped variables (most Lisp
> > dialects before Scheme didn't have them) then it would be very
> > difficult to add that with macros.
>
> Alex Mizrahi already took care of that one.
I'm not persuaded, I haven't examined his example carefully yet but it
looks like basically a reader hack. Lexical scope in Lisp means among
other things lexical closures and (maybe I'm mistaken) it seemed to me
Alex's example didn't supply that. I'm also unconvinced (so far) of
his description of call/cc as a Lisp macro but that's going to take me
some head scratching.
> > I just don't see a non-messy way to simulate Python generators in CL.
> > They can be done in Scheme using call/cc though.
>
> Scheme is also a Lisp. So?
No I don't buy that, you can't say Scheme is Lisp when it suits you to
do so and that it isn't Lisp at other times. I'd say you can map most
of Python's semantics onto Scheme reasonably straightforwardly, but
mapping them to CL is considerably harder, macros or no macros.
> > http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
> >
> > The examples in it are pretty easy to do in Python or Scheme, but I
> > think not so easy in CL.
>
> Anything in particular? I'd be surprised if the solutions in Scheme
> and CL would differ very much
I took it back, I think you can do it in CL with closures (call/cc not
needed) similar to how it's done in SICP. You could do something
similar in Python but the natural way is with generators.
Paul Rubin <·············@NOSPAM.invalid> writes:
> "Wolfram Fenske" <·····@gmx.net> writes:
[...]
>> > I just don't see a non-messy way to simulate Python generators in CL.
>> > They can be done in Scheme using call/cc though.
>>
>> Scheme is also a Lisp. So?
>
> No I don't buy that, you can't say Scheme is Lisp when it suits you to
> do so and that it isn't Lisp at other times.
OK, I cheated a bit. (Although when I say "Lisp" I don't necessarily
mean Common Lisp. Scheme is also Lisp.) You are right about call/cc
and probably also about lexical variables. I have to modify my
statement from "All the interesting features that haven't originated
from Lisp could easily be implemented in Lisp" to "A lot of the
interesting features ...". Assertions starting with "all" are a
dangerous business because usually someone comes along with a
counter-example. I should have been more careful when I wrote that.
What I meant to say with the two sentences "a lot of 'modern' language
features have originated from Lisp" and "a lot of the interesting
features that haven't originated from Lisp could easily be implemented
in Lisp" was that I believe that Lisp has hit a sweet spot in the
programming language continuum. It must have been right about a lot
of things to still be alive and kicking after all this time.
[...]
>> > http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
>> >
>> > The examples in it are pretty easy to do in Python or Scheme, but I
>> > think not so easy in CL.
>>
>> Anything in particular? I'd be surprised if the solutions in Scheme
>> and CL would differ very much
>
> I took it back,
Sorry, I only noticed that after posting.
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Wolfram Fenske wrote:
> It must have been right about a lot of things to still be alive and
> kicking after all this time.
No. Fortran and Lisp are just old, not better.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Paul Rubin <·············@NOSPAM.invalid> writes:
>> Scheme is also a Lisp. So?
>
> No I don't buy that, you can't say Scheme is Lisp when it suits you to
> do so and that it isn't Lisp at other times. I'd say you can map most
Quite right.
(message (Hello 'Paul)
(you :wrote :on '(10 Dec 2006 00:01:34 -0800))
(
PR> I'm not persuaded, I haven't examined his example carefully yet but it
PR> looks like basically a reader hack. Lexical scope in Lisp means among
PR> other things lexical closures and (maybe I'm mistaken) it seemed to me
PR> Alex's example didn't supply that.
lexical scope is pretty low-level concept that affects lot of stuff, so it
requires lot of changes -- we are not extending a language, but build a new
one actually.
we'll have to create object 'lexical environment' and to query it for
variable values instead of just using variable values: var -> (query env
'var).
then, we'll need to make closures -- that is a pair of environment and code
itself.
so, it's very close to writting new interpreter -- but it's order of
magnitude easier to write this interpreter via macros than from scratch,
most other language constructs can be reused.
that's the point -- macros allow to implement a language with aprox. same
syntax but different semantics relatively easily.
PR> I'm also unconvinced (so far) of his description of call/cc as a Lisp
PR> macro but that's going to take me some head scratching.
there is a chapter about continuations in Paul Graham's "On Lisp".
"Common Lisp doesn't provide call/cc, but with a little extra effort we can
do the same things as we can in Scheme. This section shows how to use macros
to build continuations in Common Lisp programs."
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> so, it's very close to writting new interpreter -- but it's order of
> magnitude easier to write this interpreter via macros than from scratch,
> most other language constructs can be reused.
But now you've got an interpreter and you no longer have that Lisp
compiler.
> there is a chapter about continuations in Paul Graham's "On Lisp".
>
> "Common Lisp doesn't provide call/cc, but with a little extra effort we can
> do the same things as we can in Scheme. This section shows how to use macros
> to build continuations in Common Lisp programs."
I think he's mistaken about being able to implement call/cc in full
generality with CL macros in any reasonable way. But it might be
possible to implement enough to do something like Python generators
using lexical closures that one re-enters through some kind of cond
statement selecting the yield point to be continued from.
(message (Hello 'Paul)
(you :wrote :on '(10 Dec 2006 04:36:43 -0800))
(
??>> so, it's very close to writting new interpreter -- but it's order of
??>> magnitude easier to write this interpreter via macros than from
??>> scratch, most other language constructs can be reused.
PR> But now you've got an interpreter and you no longer have that Lisp
PR> compiler.
why do you think so?
if you have C compiler that translates C to assembly, and then compiles
assembly to machine language -- that's not C compiler, not asm compiler, or
what?
yes, possibly it would be sub-optimal, but at least it will work. and
normally there would be no big performance penalties.
??>> there is a chapter about continuations in Paul Graham's "On Lisp".
??>>
??>> "Common Lisp doesn't provide call/cc, but with a little extra effort
??>> we can do the same things as we can in Scheme. This section shows how
??>> to use macros to build continuations in Common Lisp programs."
PR> I think he's mistaken about being able to implement call/cc in full
PR> generality with CL macros in any reasonable way.
why do you think so?
you know some case that does not work with call/cc?
i was programming quite significant working system with call/cc in Common
Lisp.
and although there were some glitches, it was doing quite well.
PR> But it might be possible to implement enough to do something like
PR> Python generators using lexical closures that one re-enters through
PR> some kind of cond statement selecting the yield point to be continued
PR> from.
why are you theoretizing -- i've showed working real example of generators!
just get SBCL and ARNESI, load it, and then use call/cc as i've shown in
example. that's real generators. there's no need for any cond -- you can
save state as current-continuation.
if you don't understand how it works, run macroexpand -- it's quite simple
thing.
you can find full defgenerator code here
http://www.cl-user.net/asp/Mi4$4/sdataQvxM$sStWNjUDQ3t9G8X8yBX8yBXnMq=/sdataQu3F$sSHnB==
you can find also other implementations of defgenerator's -- but with
ARNESI's CPS call/cc works with LOOP (that's actually surprising -- since
loop uses TAGBODY/GO -- maybe their code walker mutates TAGBODY making it
functional-style, or something like that).
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> PR> But now you've got an interpreter and you no longer have that Lisp
> PR> compiler.
>
> why do you think so?
> if you have C compiler that translates C to assembly, and then compiles
> assembly to machine language -- that's not C compiler, not asm compiler, or
> what?
> yes, possibly it would be sub-optimal, but at least it will work. and
> normally there would be no big performance penalties.
There would be terrible performance penalties dealing with the
environment lookup on every lexical variable reference. That's the
point. The compiler would treat those as references to slots in the
call frame, would do type inference so it could use unboxed atoms
where it could, etc. You'd lose all that.
> PR> I think he's mistaken about being able to implement call/cc in full
> PR> generality with CL macros in any reasonable way.
>
> why do you think so?
> you know some case that does not work with call/cc?
I don't see how to implement coroutines with CL macros. Maybe I'm
missing something.
> why are you theoretizing -- i've showed working real example of generators!
> just get SBCL and ARNESI, load it,
Too much hassle, I haven't used CL in many years and can't see doing
the big download etc. just to try out one example. It's not like I'm
going to suddenly discover the delights of CL. Been there, done that.
I might re-read the LTU papers to see if I'm missing something about
how CPS works. I've always been hazy on that stuff.
> and then use call/cc as i've shown in
> example. that's real generators. there's no need for any cond -- you can
> save state as current-continuation.
Fully general call/cc has to be able to switch from one execution
stack to another and back. However, that is not needed for Python
generators ("simple generators"), which can only yield to their direct
caller. I think you might be able to do simple generators with messy
macros but I don't see how you can do call/cc, jumping out to the
continuation across many levels of function calls and then returning
back into all those calls. The contination is not just a machine
address or environment, it carries a lot of other state.
(message (Hello 'Paul)
(you :wrote :on '(10 Dec 2006 10:07:12 -0800))
(
PR> There would be terrible performance penalties dealing with the
PR> environment lookup on every lexical variable reference.
LOL! you're saying it in Python newsgroup!
do you know that python makes a dict lookup on each access to global
variable/function/builtin?
and it does dict lookup for each object's method/field access.
and actually we can use vectors rather than dicts for lexical environments,
so it will be much faster.
and if you call that "terrible penalties", how will you call python's
performace? i don't know which adjective can express it then..
PR> That's the point. The compiler would treat those as references to
PR> slots in the call frame, would do type inference so it could use
PR> unboxed atoms where it could, etc. You'd lose all that.
i think there can be some optimizations (we need lex env object only where
we need a closure, i think), but right -- to have best performance, you'll
need to implement it in the language level. but you can get functionality
working right, and with acceptable performance.
if python's performance is acceptable for you, why other interpreter's won't
be?
??>> why do you think so?
??>> you know some case that does not work with call/cc?
PR> I don't see how to implement coroutines with CL macros. Maybe I'm
PR> missing something.
read the book.
i can give you a basic idea:
* (macroexpand '(with-call/cc (print 1) (call/cc (lambda (k1) k1)) (print
2)))
(DRIVE-CPS
(PROGN
(PRINT 1)
(LAMBDA ()
(FUNCALL #'TOPLEVEL-K
(FUNCALL #'(LAMBDA (K1) K1)
(MAKE-CALL/CC-K
(LAMBDA (#:V-1712)
(DECLARE (IGNORE #:V-1712))
(LAMBDA ()
(FUNCALL #'TOPLEVEL-K (PROGN (PRINT 2)))))))))))
you see that it makes a cut in call/cc point -- continuous blocks are not
affected with the transform.
??>> and then use call/cc as i've shown in
??>> example. that's real generators. there's no need for any cond -- you
??>> can save state as current-continuation.
PR> Fully general call/cc has to be able to switch from one execution
PR> stack to another and back.
that's from imperative point of view.
but once you convert it to CPS, you just operate with closures. stack is
just a lexical variables caught into closure.
do you know what does CPS mean at all??
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> PR> I don't see how to implement coroutines with CL macros. Maybe I'm
> PR> missing something.
>
> read the book.
Which book?
> but once you convert it to CPS, you just operate with closures. stack is
> just a lexical variables caught into closure.
> do you know what does CPS mean at all??
I once understood the basic notion but confess to have never been
clear on the fine points. However, I don't see how you can do it with
CL closures since CL semantics do not guarantee tail recursion
optimization. If you code a loop with closures and CPS, you will blow
the stack.
(message (Hello 'Paul)
(you :wrote :on '(10 Dec 2006 21:06:56 -0800))
(
??>> read the book.
PR> Which book?
Paul Graham's "On Lisp".
or just refreshing your knowledge about CPS transformaction might be
sufficient.
i've found very good explanation of CPS transformaction in the book
"Programming Languages:Application and Interpretation"
Shriram Krishnamurthi
Brown University
it's not Common Lisp but Scheme though, but it's very interesting since it
shows how continuations can be used for better web programming.
both books are available online.
??>> but once you convert it to CPS, you just operate with closures. stack
??>> is just a lexical variables caught into closure. do you know what does
??>> CPS mean at all??
PR> I once understood the basic notion but confess to have never been
PR> clear on the fine points. However, I don't see how you can do it with
PR> CL closures since CL semantics do not guarantee tail recursion
PR> optimization. If you code a loop with closures and CPS, you will blow
PR> the stack.
most CL implementation do tail call optimization, unless you're running
debug mode -- in that case you'd prefer full stack.
however, it's possible to implement tail call optimizations in non-tail-call
optimizing language. i think it's called trampolined style.
example can be found in PAIP book: interpreter of Scheme is implemented in
Common Lisp.
CPS transformation found in ARNESI implements that -- you might notice on
the macroexpansion i've showed in prev example function drive-cps. it's
defined following way:
(defun drive-cps (cps-lambda)
(catch 'done
(loop for f = cps-lambda then (funcall f))))
additional (lambda () ...) is inserted in the code to delay evaluation. code
becomes like this:
(drive-cps
(block1)
(lambda () (block2))
thus for each CPS tear-point it's able to throw stale stack frames away.
here's an example of CPS-transformed eternal loop
(macroexpand '(with-call/cc (loop for i upfrom 1 do (print i) do (call/cc
(lambda (cont) cont)))))
(DRIVE-CPS
(LET ((#:CPS-LET-I-1712 1))
(DECLARE (TYPE NUMBER #:CPS-LET-I-1712))
(LABELS ((#:TAGBODY-TAG-NEXT-LOOP-1713 ()
(PROGN
(PRINT #:CPS-LET-I-1712)
(LAMBDA ()
(FUNCALL #'TOPLEVEL-K
(FUNCALL #'(LAMBDA (CONT) CONT)
(MAKE-CALL/CC-K
(LAMBDA (#:V-1717)
(DECLARE (IGNORE #:V-1717))
(PROGN
(PROGN
(SETQ #:CPS-LET-I-1712
(1+ #:CPS-LET-I-1712)))
(#:TAGBODY-TAG-NEXT-LOOP-1713))))))))))
(#:TAGBODY-TAG-NEXT-LOOP-1713))))
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> PR> Which book?
> Paul Graham's "On Lisp".
Oh ok, someone mentioned that was online, and I just bookmarked it.
I'll look at it when I'm more awake.
> "Programming Languages:Application and Interpretation"
> Shriram Krishnamurthi
> Brown University
>
> it's not Common Lisp but Scheme though, but it's very interesting since it
> shows how continuations can be used for better web programming.
Scheme probably makes more sense for this type of book--it's simpler than CL.
> most CL implementation do tail call optimization, unless you're running
> debug mode -- in that case you'd prefer full stack.
I'd rather stick to what the CL standard says, rather than what some
implementation might happen to do. CL does not guarantee TCO so these
code transformation schemes mustn't rely on it.
> optimizing language. i think it's called trampolined style.
> example can be found in PAIP book: interpreter of Scheme is implemented in
This book doesn't seem to be online. But anyway I think you mean,
compile the Scheme code into one giant CL function, which is no longer
really a clean mapping of Scheme to CL, it's just writing an
interpreter. And I think that interpreter has to do its own
management of environments rather than letting the CL runtime do it.
So basically it says CL is turing-complete and can do everything,
which we already knew ;-).
> (defun drive-cps (cps-lambda)
> (catch 'done
> (loop for f = cps-lambda then (funcall f))))
Part of the problem I'm having with these examples is I don't know all
the different macros being used. But I think I understand one part of
what was confusing me before: your call/cc macros depend on a
nonstandard feature of some CL implementations. You can't write a
call/cc macro in standard CL--you instead have to write something that
transforms the entire program.
I think even with TCO though, you still can't do coroutines with CL
macros (but you can do them with real call/cc). The point is that you
have to do something like TCO on calls that are not tail calls and
actually have to return. You again have to transform the whole
program, not just expand a call/cc macro locally inside functions that
use it.
Paul Rubin wrote:
> "Alex Mizrahi" <········@users.sourceforge.net> writes:
>
> > "Programming Languages:Application and Interpretation"
> > Shriram Krishnamurthi
> > Brown University
> This book doesn't seem to be online.
http://cs.brown.edu/~sk/Publications/Books/ProgLangs/
Michele Simionato
"Michele Simionato" <·················@gmail.com> writes:
> > > "Programming Languages:Application and Interpretation"
> > > Shriram Krishnamurthi
> > > Brown University
> > This book doesn't seem to be online.
>
> http://cs.brown.edu/~sk/Publications/Books/ProgLangs/
Thanks!
(message (Hello 'Paul)
(you :wrote :on '(11 Dec 2006 04:14:20 -0800))
(
??>> optimizing language. i think it's called trampolined style.
??>> example can be found in PAIP book: interpreter of Scheme is
implemented in
PR> This book doesn't seem to be online. But anyway I think you mean,
PR> compile the Scheme code into one giant CL function, which is no longer
PR> really a clean mapping of Scheme to CL, it's just writing an
PR> interpreter. And I think that interpreter has to do its own
PR> management of environments rather than letting the CL runtime do it.
PR> So basically it says CL is turing-complete and can do everything,
PR> which we already knew ;-).
point is that writting some custom interpreter in CL is very easy AND you
can still use all other features of CL AND communicate with other DSLs.
PR> the different macros being used. But I think I understand one part of
PR> what was confusing me before: your call/cc macros depend on a
PR> nonstandard feature of some CL implementations.
no, it's standard Common Lisp. it's an ARNESI library. it's very standard --
i was able to run non-modified code in Armed Bear Common Lisp implementation
(it's running on JVM), that is very new and does not fully support the
standard -- but nevertheless, CPS code runs out of the box on it.
PR> You can't write a call/cc macro in standard CL--you instead have to
PR> write something that transforms the entire program.
yes, i cannot write just call/cc -- i should wrap code into with-call/cc.
with-call/cc macro performs transformation of the code to CPS -- and then
call/cc is enabled.
i can enable call/cc for specific functions -- i define them with defun/cc
instead of defun. so, i can define both normal CL functions and call/cc
enabled functions. typically, call/cc is required only in a few pieces of
program where interrupts come, so it's OK.
if i'm going to support generators, i only need to run CPS tranformation on
the body of generator function -- that will tear it in yield points.
PR> I think even with TCO though, you still can't do coroutines with CL
PR> macros (but you can do them with real call/cc). The point is that you
PR> have to do something like TCO on calls that are not tail calls and
PR> actually have to return. You again have to transform the whole
PR> program, not just expand a call/cc macro locally inside functions that
PR> use it.
i think only functions that are coroutines should be fully transformed.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> PR> the different macros being used. But I think I understand one part of
> PR> what was confusing me before: your call/cc macros depend on a
> PR> nonstandard feature of some CL implementations.
>
> no, it's standard Common Lisp. it's an ARNESI library. it's very standard --
The ARNESI doc at:
http://common-lisp.net/project/bese/docs/arnesi/html/Automatically_Converting_a_Subset_of_Common_Lisp_to_CPS.html
begins:
By transforming common lisp code into CPS we allow a restricted form
of CALL/CC. While we use the name call/cc what we actually provide is
more like the shift/reset operators (where with-call/cc is reset and
call/cc is shift).
I don't know what shift/reset are but the above says that call/cc in
the Scheme sense is not really implemented. There are also a bunch of
limitations on what can be in the call/cc body, e.g. you can't use
unwind-protect.
Anyway, the nonstandard feature is tail call optimization, if you're
turning continuations into closures, and that's just for the simple
case of dealing with loops written in CPS. E.g.: if you write
(defun sum_to_n (n &optional (acc 0))
;; (sum_to_n n) computes sum of integers from 0 to n
(if (= n 0)
0
(sum_to_n (- 1 n) (+ n acc))))
This function is properly tail recursive (unless I messed up) so with
(sum_to_n 10000000000)
the CPS version is supposed to return the right answer if you wait
long enough. It is not allowed to overflow the stack. This is
guaranteed to work in Scheme but is not guaranteed in CL. And as I
think we agree, with coroutines it gets even worse.
Paul Rubin <·············@NOSPAM.invalid> writes:
> (defun sum_to_n (n &optional (acc 0))
> ;; (sum_to_n n) computes sum of integers from 0 to n
> (if (= n 0)
> 0
> (sum_to_n (- 1 n) (+ n acc))))
Of course meant:
(defun sum_to_n (n &optional (acc 0))
;; (sum_to_n n) computes sum of integers from 0 to n
(if (= n 0)
acc
(sum_to_n (- 1 n) (+ n acc))))
I've made that same error several times in Haskell as well. I'm not
used to this.
On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
> if Common Lisp didn't have CLOS, its object system, I could write my own
> as a library and it would be just as powerful and just as easy to use as
> the system Common Lisp already provides. Stuff like this is impossible
> in other languages.
Dude. Turing Complete. Don't you Lisp developers know anything about
computer science?
Anything any language can do is possible in any other language, if you are
willing to write your own libraries. And debug them. Let's not forget the
debugging and testing, unless you'd like us to believe that Lisp code
never contains bugs. Lisp developers so often gloss over that: "Oh,
feature X is *easy*, I could write it in a couple of macros. Two or three.
Maybe thirty. Or forty, max. And they would work the right way first time.
No, I haven't actually done it myself. But I'm sure I could do it, easy."
--
Steven.
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
+---------------
| Wolfram Fenske wrote:
| > if Common Lisp didn't have CLOS, its object system, I could write my own
| > as a library and it would be just as powerful and just as easy to use as
| > the system Common Lisp already provides. Stuff like this is impossible
| > in other languages.
|
| Dude. Turing Complete. Don't you Lisp developers know anything about
| computer science?
|
| Anything any language can do is possible in any other language,
| if you are willing to write your own libraries. And debug them.
+---------------
Yes, true, but by then you've effectively reimplemented Lisp! ;-}
http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule
Greenspun's Tenth Rule of Programming [...]:
"Any sufficiently complicated C or Fortran program
contains an ad hoc, informally-specified, bug-ridden,
slow implementation of half of Common Lisp."
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Steven D'Aprano wrote:
> Anything any language can do is possible in any other language
Not true. Concurrency, for example.
> Lisp developers so often gloss over that: "Oh,
> feature X is *easy*, I could write it in a couple of macros. Two or three.
> Maybe thirty. Or forty, max. And they would work the right way first time.
> No, I haven't actually done it myself. But I'm sure I could do it, easy."
True.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>
>
>>if Common Lisp didn't have CLOS, its object system, I could write my own
>>as a library and it would be just as powerful and just as easy to use as
>>the system Common Lisp already provides. Stuff like this is impossible
>>in other languages.
>
>
> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?
We just know the Turing Complete thing cannot be used to duck language
feature comparisons because the whole point of language comparison is
"how much pain does each language spare me?", where a Turing machine is
ranked as the ultimate in programming pain.
This might be because the whole point of a programming language is to
spare us the pain of toggling switches on the back of an ENIAC.
>
> Anything any language can do is possible in any other language,...
At what cost? <hint>
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>
>
>>if Common Lisp didn't have CLOS, its object system, I could write my own
>>as a library and it would be just as powerful and just as easy to use as
>>the system Common Lisp already provides. Stuff like this is impossible
>>in other languages.
>
>
> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?
>
> Anything any language can do is possible in any other language, if you are
> willing to write your own libraries.
I do not think you know what are macros. You are talking about
functionality, macros are about the syntax. To achieve what Lisp
developers do with macros you would need to write a preprocessor (and
indeed this has been done when the need was great enough) to run thru
the code expanding all the uses of the preprocessor language. But then
your edit-run cycle is broken unless your IDE will let you specify a
preprocessor and take care of seamlessly running it, but then what do
you debug? And then you cannot just toss off a macro, it becomes an
exercise in compiler development and now you have dozens of
preprocessors running on each cycle. Ewwwww.
> And debug them. Let's not forget the
> debugging and testing, unless you'd like us to believe that Lisp code
> never contains bugs. Lisp developers so often gloss over that: "Oh,
> feature X is *easy*, I could write it in a couple of macros. Two or three.
> Maybe thirty. Or forty, max. And they would work the right way first time.
Do you really talk to a lot of Lisp developers, or were you making that
up? :)
Of course implementing an object system is a big job. Your fantasy about
Lisp programmers misses the point to which you respond: after they had
done all the work to implement an object system, they were able to make
it look like Lisp had always had CLOS, without changing the compiler.
Keep those fat pitches coming. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano
<·····@REMOVE.THIS.cybersource.com.au> tried to confuse everyone with this
message:
>On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>
>> if Common Lisp didn't have CLOS, its object system, I could write my own
>> as a library and it would be just as powerful and just as easy to use as
>> the system Common Lisp already provides. Stuff like this is impossible
>> in other languages.
>
>Dude. Turing Complete. Don't you Lisp developers know anything about
>computer science?
Here, you've basically shot yourself in the ass. Appealing to Turing
completeness when talking about programming language features is about the
dumbest thing you can make. In Turing sense, a program is simply a function that
takes an argument and returns a value. It doesn't say anything about how this
function was implemented. It could be Turing machine, lambda calculus, Markov
chains or whatever else. All these methods produce the same set of programs, but
that doesn't mean you could implement lambda in Turing machine for example.
Is is time for someone to read his computer science books again?
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
On Sat, 09 Dec 2006 14:00:10 +0000, Timofei Shatrov wrote:
> On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano
> <·····@REMOVE.THIS.cybersource.com.au> tried to confuse everyone with this
> message:
>
>>On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>>
>>> if Common Lisp didn't have CLOS, its object system, I could write my own
>>> as a library and it would be just as powerful and just as easy to use as
>>> the system Common Lisp already provides. Stuff like this is impossible
>>> in other languages.
>>
>>Dude. Turing Complete. Don't you Lisp developers know anything about
>>computer science?
>
> Here, you've basically shot yourself in the ass. Appealing to Turing
> completeness when talking about programming language features is about the
> dumbest thing you can make. In Turing sense, a program is simply a function that
> takes an argument and returns a value. It doesn't say anything about how this
> function was implemented. It could be Turing machine, lambda calculus, Markov
> chains or whatever else. All these methods produce the same set of programs, but
> that doesn't mean you could implement lambda in Turing machine for example.
What exactly are you trying to say here? Is this a comment about the
relative practicality of writing code in a Turing machine versus
high-level languages, or are you implying that lambda calculus is "bigger"
than any Turing-complete language?
If you're talking about practicality, then of course you're correct, not
all languages are equally expressive. Some languages are not expressive
enough. Some languages are too expressive. No language is optimal for all
people for all tasks.
> Is is time for someone to read his computer science books again?
Probably. Would you like to borrow mine?
Look, all snarkiness aside, it just isn't true that "stuff like this is
impossible in other languages". If Wolfram Fenske had said "stuff like
this isn't easy in many other languages" he would have been right. And if
he had said "and stuff like this carries risks as well as benefits" he
would have come across as less of a language fanatic.
One of the risks with Python is the ease with which you can modify the
built-ins. An expression like list(2, 3, 4) doesn't necessarily create a
list from 2, 3, and 4, because the built-in list could be redefined.
(In practice, that's not often a real problem, because experienced
Python developers simply learn not to needlessly or confusingly shadow
built-ins. It's not the best system, but it works well enough in
practice.) But at least the basic syntax and keywords of the language are
known to be constant.
With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
"Oh yes, macros give you great power, and with great power comes great
responsibility. Be careful." then, no doubt, we'd take you guys more
seriously. But we don't hear that -- we hear Lispers going on and on about
how great it is that they can easily redefine every corner of the
language. Do you blame people for *believing them* and imagining that
reading Lisp code is like following some ghostly will-o-the-wisp across a
swamp, where nothing is what it seems and the landscape is forever
shifting?
Now, if you want to tell me that, despite all the talk, Lisp coders don't
actually create new syntax or mini-languages all that often, that they
just use macros as functions, then the question becomes: why do you need
macros then if you are just using them as functions? Why not use functions?
--
Steven.
Thankfully folks (including me) seem to be starting to cool off, so
perhaps we can disucss this in somewhat calmer register. I think that
Kenny unintentionally sold macros short by implying that they are
merely window-dressing for boilerplate, and you seem to have a
misunderstanding of macros, which I won't go into too deeply but to
point out that the purpose of macros is not the same as functions.
Functions create new ...uuuhh... functionality, whereas macros create
new programming constructs. These work in very different conceptual
parts of the programming landscape: The former addresses the way that
the functions offered by the programming language fit the parts of the
problem whereas the latter addresses the way that the programming
language itself fits the problem.
So, whereas I will grant that:
> "Oh yes, macros give you great power, and with great power comes great
> responsibility. Be careful."
I don't think that any experience Lisp programming would grant that:
> despite all the talk, Lisp coders don't
> actually create new syntax or mini-languages all that often, that they
> just use macros as functions
So, to your point:
> then the question becomes: why do you need
> macros then if you are just using them as functions? Why not use functions?
No, they are not functions. We need them because although it is usually
possible to make a given programming language's functionally fit any
given problem, it is often much more convenient, and much cleaner, both
practiaclly and conceptually, to make the programming langauge fit the
problem too.
Steven D'Aprano wrote:
> With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
> "Oh yes, macros give you great power, and with great power comes great
> responsibility. Be careful." then, no doubt, we'd take you guys more
> seriously.
Who are "we"? I was a heavy Python and Java user before being aware of
Lisp. I knew even then that there was something wrong with the
programming world, because there were too many programming patterns I
could not automate away within the language. It's ironic to be a
programmer who can't automate her own work.
I told people that programming was just "glorified accounting." I
shrugged when reading about how complexity was exploding, because that
was the language designers' job to manage it.
Upon hearing of Lisp, I taught it to myself alone, because it was
important. Despite all the FUD, despite all the people who presumed
that a language designer was smarter than his users. I came to realize
that the programming world was full of users who repeated "conventional
wisdom" based on generalities they heard from a friend of a friend of
an evangelist of a corporation -- and worse yet, I was part of that
culture and picked up those poor habits.
> Now, if you want to tell me that, despite all the talk, Lisp coders don't
> actually create new syntax or mini-languages all that often, that they
> just use macros as functions, then the question becomes: why do you need
> macros then if you are just using them as functions? Why not use functions?
You may wish to read the following:
<http://www.defmacro.org/ramblings/lisp.html>
Perhaps Lisp becomes clearer once you see its syntactic similarity with
a very mainstream language -- XML. (But sexps are far more lucid than
XML.) Then we can seriously talk about the real-world engineering
implications of macros, and other powerful features which aren't so
hyped as macros.
Tayssir
Steven D'Aprano wrote:
> Some languages are too expressive.
:)
> Look, all snarkiness aside, it just isn't true that "stuff like this is
> impossible in other languages". If Wolfram Fenske had said "stuff like
> this isn't easy in many other languages" he would have been right.
Remember, Lisp macros are like being able to run a preprocessor on an
ad-hoc basis. Without Lisp compilers (er, should I say the Lisp
"reader"?) understanding macros and macro functions, not even Lisp could
transform source code this way.
We won't have an intelligent discussion on macros until this gets better
understood. Macros are not about what one can do at run-time, they are
about what happens at compile time. If your compiler/preprocessor/IDE
are not going to cooperate, then embedding a preprocessed language in
Python is so hard as to be unfeasible.
I also would not quibble over "impossible" vs. "incredibly hard". The
bottom line is that at a pretty low level hard becomes "aint gonna happen".
> And if
> he had said "and stuff like this carries risks as well as benefits" he
> would have come across as less of a language fanatic.
>
> One of the risks with Python is the ease with which you can modify the
> built-ins. An expression like list(2, 3, 4) doesn't necessarily create a
> list from 2, 3, and 4, because the built-in list could be redefined.
> (In practice, that's not often a real problem, because experienced
> Python developers simply learn not to needlessly or confusingly shadow
> built-ins.
Well, duuhhhhh. This the Great Strawman, that Lisp programmers (a) love
having a powerful language (b) so they can produce unreadable code. This
nonsense is an implicit concession that you have no point at all.
> It's not the best system, but it works well enough in
> practice.) But at least the basic syntax and keywords of the language are
> known to be constant.
>
> With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
> "Oh yes, macros give you great power, and with great power comes great
> responsibility. Be careful."
I have to admit you are probably still catching up on what I have
written today.
> then, no doubt, we'd take you guys more
> seriously. But we don't hear that -- we hear Lispers going on and on about
> how great it is that they can easily redefine every corner of the
> language.
You have this tendency as your paragraphs grow to get sillier and
sillier and make up more and more hobgoblin crap, I suppose as you sense
the weakness of your case. Can you point to where someone said that? No,
of course not. Get a grip, will you, this could be a useful cultural
exchange, but not with your hysterics.
> why do you need
> macros then if you are just using them as functions? Why not use functions?
Hint: famous Lisp style rule: never use a macro where a function will do.
Not sure it is worth wasting more time on you at this point or I would
offer examples. Could you calm down a bit and stop making things up?
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> Now, if you want to tell me that, despite all the talk, Lisp coders don't
> actually create new syntax or mini-languages all that often, that they
> just use macros as functions, then the question becomes: why do you need
> macros then if you are just using them as functions? Why not use functions?
Macros let you write what amounts to functions that don't evaluate
their arguments. Think of the endless clpy wars over the ternary
conditional operator. You want to write something like
def ternary(test, iftrue, iffalse):
if test: return iftrue
else iffalse
but because of side effects, you don't want
a = cond(test, f(x), g(x))
to evaluate both f and g. That is trivial to do with a macro but
can't be done with a function. Macros can be used tastefully and
effectively in Lisp programs, though not everyone limits their usage
like that.
Haskell uses a different approach: 1) all arguments are unevaluated
unless the program tries to actually use the values. 2) there are no
side effects anyway. This may be why Haskell's current lack of macros
apparently isn't a big problem.
On Sat, 09 Dec 2006 14:55:13 -0800, Paul Rubin wrote:
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>> Now, if you want to tell me that, despite all the talk, Lisp coders don't
>> actually create new syntax or mini-languages all that often, that they
>> just use macros as functions, then the question becomes: why do you need
>> macros then if you are just using them as functions? Why not use functions?
>
> Macros let you write what amounts to functions that don't evaluate
> their arguments. Think of the endless clpy wars over the ternary
> conditional operator.
[snip]
> That is trivial to do with a macro
I know that. It was more of a rhetorical question -- Lispers are either
trying to emphasis the radical nature of what you can do with macros, or
understate it and make them seem just like functions.
> but can't be done with a function.
*shrug*
You can't get to Sydney from Melbourne via Hobart by bicycle either. You
either change the requirements (why does it have to be by bicycle?) or the
path (why go through Hobart?) or change the infrastructure (build a long,
long bridge connecting Hobart to the mainland). That's three tactics for
solving the problem of "go from Sydney to Melbourne". It is just not true
that the only "correct" solution is to build the bridge.
In the case of the ternary operator, changing the language is like
building the bridge. It's *a* solution. Maybe it is even the best
solution. But it is ludicrous to say that "change the language" is the
only solution.
(I know you didn't say that -- but so many people seem to think that
adding new syntactic support for their pet feature is the only solution to
their problem, no matter what the problem. Those people would, I imagine,
wet themselves in excitement if Python ever got macros. "Now at last I can
make Python look just like the bastard love-child of Perl and Java!" *wink*)
--
Steven.
Steven D'Aprano wrote:
> On Sat, 09 Dec 2006 14:55:13 -0800, Paul Rubin wrote:
>
>
>>Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>>
>>>Now, if you want to tell me that, despite all the talk, Lisp coders don't
>>>actually create new syntax or mini-languages all that often, that they
>>>just use macros as functions, then the question becomes: why do you need
>>>macros then if you are just using them as functions? Why not use functions?
>>
>>Macros let you write what amounts to functions that don't evaluate
>>their arguments. Think of the endless clpy wars over the ternary
>>conditional operator.
>
> [snip]
>
>>That is trivial to do with a macro
>
>
> I know that. It was more of a rhetorical question -- Lispers are either
> trying to emphasis the radical nature of what you can do with macros, or
> understate it and make them seem just like functions.
Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
to PyCells as part of SoC 2006) is another. The latter is the norm.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:
>> I know that. It was more of a rhetorical question -- Lispers are either
>> trying to emphasis the radical nature of what you can do with macros, or
>> understate it and make them seem just like functions.
>
> Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
> to PyCells as part of SoC 2006) is another. The latter is the norm.
If macros' advanced usage is rare, and most usage of macros could be done
by functions, then maybe that explains why so many coders don't miss them.
--
Steven.
Steven D'Aprano wrote:
> On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:
>
>
>>>I know that. It was more of a rhetorical question -- Lispers are either
>>>trying to emphasis the radical nature of what you can do with macros, or
>>>understate it and make them seem just like functions.
>>
>>Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
>>to PyCells as part of SoC 2006) is another. The latter is the norm.
>
>
> If macros' advanced usage is rare,
Hunh? I have tons of them. Of coure at your level of discourse you will
want to know if those are metric tons or...
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Sun, 10 Dec 2006 02:00:02 -0500, Ken Tilton wrote:
> Steven D'Aprano wrote:
>> On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:
>>
>>
>>>>I know that. It was more of a rhetorical question -- Lispers are either
>>>>trying to emphasis the radical nature of what you can do with macros, or
>>>>understate it and make them seem just like functions.
>>>
>>>Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
>>>to PyCells as part of SoC 2006) is another. The latter is the norm.
>>
>>
>> If macros' advanced usage is rare,
>
> Hunh? I have tons of them. Of coure at your level of discourse you will
> want to know if those are metric tons or...
Stop playing games Ken. You said they were rare. Not me. You. The fact
that you personally make lots of use of the more radical macros doesn't
come into it. As you said, the norm across the wider Lisp community is the
less radical macro, the ones that are basically just functions.
That's what you said -- or are you changing your mind?
--
Steven.
Steven D'Aprano wrote:
> On Sun, 10 Dec 2006 02:00:02 -0500, Ken Tilton wrote:
>
>
>
>>Steven D'Aprano wrote:
>>
>>>On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:
>>>
>>>
>>>
>>>>>I know that. It was more of a rhetorical question -- Lispers are either
>>>>>trying to emphasis the radical nature of what you can do with macros, or
>>>>>understate it and make them seem just like functions.
>>>>
>>>>Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
>>>>to PyCells as part of SoC 2006) is another. The latter is the norm.
>>>
>>>
>>>If macros' advanced usage is rare,
>>
>>Hunh? I have tons of them. Of coure at your level of discourse you will
>>want to know if those are metric tons or...
>
>
> Stop playing games Ken. You said they were rare. Not me. You. The fact
> that you personally make lots of use of the more radical macros doesn't
> come into it. As you said, the norm across the wider Lisp community is the
> less radical macro, the ones that are basically just functions.
>
> That's what you said -- or are you changing your mind?
No, I simply misapprehended what you wrote, though it was perfectly
clear. You wrote:
> If macros' advanced usage is rare, and most usage of macros could be done
> by functions, then maybe that explains why so many coders don't miss them.
Maybe my brain misfired because there is so much wrong with that. The
meta-wrong is that clearly you do not understand macros or how they play
out in real applications, but you have climbed up on this soapbox as if
you were an expert on both issues. Like your interview, you are
speculating without basis on what might happen. You do have a good
excuse since GvR does the same.
Here you have a chance to talk with people who program with macros day
in and day out and learn about them, instead you are trying to tell us
how they are used. Does that make a lot of sense? Or do you think we are
lying? :)
Language-transforming macros such as defclass/defmethod (the heart of
CLOS) and my defmodel come along rarely. This does not mean my
applications do not /use/ CLOS extensively. They do. It means I do not
have ten such different language extensions. I have three: defclass,
defmodel, and LOOP. Can you understand that difference? "Used everywhere
because they are so cool" and "just a few such cool tools exist" are not
contradictory.
Does rare mean "who needs it"? Nice try, but obviously not. Well, maybe
not obviously, because not everyone likes OO, but I would not want to
program without defclass or defmodel or even LOOP. The latter is such a
powerful iteration tool it justifies learning the new syntax, which is
also not a problem because I use it all day making it is easy to
remember. (Aside: I /did/ resist learning it for years because of the
different syntax--my loss.)
Recall that this subwar started over someone saying Lisp was able to
"grow" CLOS without changing and have it look like part of the language,
which led you and others to echo GvR and pronounce macros to be
obfuscatory (?). Sorry, no, not in fact. Only in your nightmares.
As for simple macros not being necessary, what they do is clean up the
code, letting the beef stand out more. Obviously people with that
interest do not turn around and create obfuscated code, no matter how
many times you want to FUD that (which seems to be quite a lot <g>).
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Steven D'Aprano schrieb:
> On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:
>
>>> I know that. It was more of a rhetorical question -- Lispers are either
>>> trying to emphasis the radical nature of what you can do with macros, or
>>> understate it and make them seem just like functions.
>> Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
>> to PyCells as part of SoC 2006) is another. The latter is the norm.
>
> If macros' advanced usage is rare, and most usage of macros could be done
> by functions, then maybe that explains why so many coders don't miss them.
You can't do with functions what you can do with macros.
Macros are just parameterized code. A template. Compare it with HTML
templates
<html>
<body>
Your name is <?py print name.getUser(loggedInUser) ?>.<br>
Welcome!
</body>
</html>
The page that arrives the user does not include any template code anymore.
Just plain html.
Same happens with Lisp macros. After compilation (preprocessing the
html template by Zope) there are no macros left.
So in the end you have just some Lisp functions. So one does not *need*
macros, in the sense of turing completeness. But at the same time one
can meet lots of places where templates can make sense and where they
are used. Even the programmers of Zope thought of them as a plus for
productivity.
In Lisp you don't always design one huge macro after the other, which
really saves a lot of code. Many macros save one or two short lines of
code. This might sound not important. But it sums up.
Somewhere else I asked you to imagine how you would like it if you had
to call doodleBoodle() before each if-statement to make it work. That
would be plain stupid if you had to. So if you meet something in code
that you use several times, then you factor that repeating block of
code out into a function that takes another function which will get
called in the right environment.
And macros help here "only" to save one or two loc. But as I said, it
sums up.
Andr�
--
Paul Rubin schrieb:
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>> Now, if you want to tell me that, despite all the talk, Lisp coders don't
>> actually create new syntax or mini-languages all that often, that they
>> just use macros as functions, then the question becomes: why do you need
>> macros then if you are just using them as functions? Why not use functions?
>
> Macros let you write what amounts to functions that don't evaluate
> their arguments. Think of the endless clpy wars over the ternary
> conditional operator. You want to write something like
>
> def ternary(test, iftrue, iffalse):
> if test: return iftrue
> else iffalse
>
> but because of side effects, you don't want
>
> a = cond(test, f(x), g(x))
>
> to evaluate both f and g. That is trivial to do with a macro but
> can't be done with a function.
I think you could do that with functional programming.
You can protect the evaluation by encapsulating the args in a function
object?
def f_Args(x):
return x
def g_Args(x):
return x
and then
a = cond(test, f, g, f_Args(x), g_Args(x))
if you adopt cond. But of course it is getting ugly.
So a macro can free you from this extra code.
Andr�
--
Andr� Thieme wrote:
> I think you could do that with functional programming.
> You can protect the evaluation by encapsulating the args in a function
> object?
>
> def f_Args(x):
> return x
>
> def g_Args(x):
> return x
>
> and then
> a = cond(test, f, g, f_Args(x), g_Args(x))
>
> if you adopt cond. But of course it is getting ugly.
> So a macro can free you from this extra code.
Yes, that's just lazy evaluation. Again, you don't need macros.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> I think you could do that with functional programming.
>> You can protect the evaluation by encapsulating the args in a function
>> object?
>>
>> def f_Args(x):
>> return x
>>
>> def g_Args(x):
>> return x
>>
>> and then
>> a = cond(test, f, g, f_Args(x), g_Args(x))
>>
>> if you adopt cond. But of course it is getting ugly.
>> So a macro can free you from this extra code.
>
> Yes, that's just lazy evaluation. Again, you don't need macros.
This is correct, one really doesn't need them. Every program could be
written without them.
The idea is that macros make you more productive.
I said it several times in this long thread, that many macros save you
just one line of code, or even just a function call, something like that.
This does not sound too good. But if you *really* believe that this is
not important I suggest you to prove it by defining a function that does
nothing and call it each time before you use a let in ocaml.
If you would support your opinion you could start right now and work
over your code.
Otherwise, if you don't want to do that I see this as your agreement to
the usefulnes of macros.
Some macros are saving you several lines of code or many tokens. These
are not so common, but then they give you a bigger win in productivity.
Imagine a pattern matcher - this can be sometimes a real productivity
booster.
In bigger and more complex projects, there will be several domains where
a new feature would help. In Lisp one would begin to integrate this
feature and use it.
Andr�
--
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
> "Oh yes, macros give you great power, and with great power comes great
> responsibility. Be careful." then, no doubt, we'd take you guys more
> seriously. But we don't hear that -- we hear Lispers going on and on about
And, of course, we do say that. Nobody wants people running around
writing incomprehensible macros. How does that help anyone?
Fortunately, it's not a problem in practice, because most macros map
quite straightforwardly to Lisp constructs and almost no one has the
time or the intelligence to write the mini-languages that seem to be
terrifying you so much.
> how great it is that they can easily redefine every corner of the
> language. Do you blame people for *believing them* and imagining that
> reading Lisp code is like following some ghostly will-o-the-wisp across a
> swamp, where nothing is what it seems and the landscape is forever
> shifting?
"every corner of the language"? Please. Why are you so post-happy
when it's quite obvious that you don't know enough about Lisp to
attack it?
Most programmers do not write macros that are incredibly difficult to
understand. Beginners might, but beginners might also write
incomprehensible code in Java or Python. As you learn Lisp, you learn
to keep your macros tied to the underlying Lisp. You learn to make
the expansions into function or method defintions, instead of
reinventing the wheel. You leverage what Lisp offers, instead of
redefining it.
The only times you are really going to find completely alien semantics
are in textbooks (like Prolog in Lisp), in very ambitious and large
projects where the new semantics are the only reason you'd use the
code in the first place (like Franz's AllegroProlog or Marco
Baringer's CPS transformer), or in code written by beginners. Please
stop spreading FUD about this. In real life, macros make coding more
pleasant and make your code more maintainable. They are something to
embrace, not something to fear.
To provide a more solid example, Peter Seibel's book _Practical Common
Lisp_ (full text at http://www.gigamonkeys.com/book) provides a set of
classes for parsing binary files. Some user code provided in the
book:
(define-binary-class id3v2.3-tag (id3-tag)
((extended-header-size (optional :type 'u4 :if (extended-p flags)))
(extra-flags (optional :type 'u2 :if (extended-p flags)))
(padding-size (optional :type 'u4 :if (extended-p flags)))
(crc (optional :type 'u4 :if (crc-p flags extra-flags)))
(frames (id3-frames :tag-size size :frame-type 'id3v2.3-frame))))
This code very closely mirrors the standard DEFCLASS in Common Lisp,
so a maintainer knows right away what to expect. The macro expands
into DEFCLASS and DEFMETHOD forms. There's nothing mysterious going
on here; the macro is just a friendlier syntax for expressing an idea.
What I get from this are methods that read binary data into objects of
the class that I've just defined (*). That's all - methods and a
class. There is no mind-bending going on at all here. It's true of
course that I have to understand how the macro works. But without it,
I'd have to write and/or read through a lot of similar-looking code
for handling binary data. Which would you prefer?
Without a macro like this, the code required would be the definition
of boilerplate. Instead of specifying declaratively the order and
type of fields in the binary file, I would write code to read each
field from the file and then store the result in an object. I'd also
have to take into account fields that are optional. This is ugly and
boring code. Did I mention that DEFINE-BINARY-CLASS also defines
methods to save these objects back to binary files? Because it does.
So why not write this code once and then take advantage of it in the
future to get more expressive, less boring programs?
* If you don't believe me, here is the expansion of the code I cited above:
http://paste.lisp.org/display/31799
Just methods and a class.
Bill Atkins <······@rpi.edu> writes:
> "every corner of the language"? Please. Why are you so post-happy
> when it's quite obvious that you don't know enough about Lisp to
> attack it?
In addition to macros that define classes or methods, a common macro
is the WITH-* macro, which sets up some kind of context, runs the body
inside that context, and then does some cleanup.
For example, my Lisp vendor, LispWorks, provides the macro MP:WITH-LOCK :
(mp:with-lock (*the-big-lock*)
(do-something-atomic)
(something-else)
(almost-odone))
The generated first seizes a process lock called *THE-BIG-LOCK*, runs
the code in the body and then releases the lock. I never have to
worry that I've taken a lock without releasing it, because LispWorks
has encoded that behaviour into MP:WITH-LOCK (and if they handn't,
this macro is trivial to write).
Now I can tell if I'm keeping a lock around too long because all the
code that appears inside this WITH-LOCK is all the code that I'm
locking. Further, the generated code is surrounded by an
UNWIND-PROTECT, which means that if an error is raised or anything
abnormal happens in the dynamic scope of the UNWIND-PROTECT, Lisp will
run cleanup code as it flees back up the stack. So if there is an
error in my code, it does not prevent other processes from seizing
that lock, because it will be released as the error is signaled.
Here is the expansion:
CL-USER 7 > (write (macroexpand '(mp:with-lock (*the-big-lock*)
(do-something-atomic)
(something-else)
(almost-odone)))
:pretty t :case :downcase)
(let ((#:g17553 *the-big-lock*))
(when (mp:process-lock #:g17553)
(unwind-protect
(progn (do-something-atomic) (something-else) (almost-odone))
(mp::in-process-unlock #:g17553))))
Bill Atkins schrieb:
> Bill Atkins <······@rpi.edu> writes:
>
>> "every corner of the language"? Please. Why are you so post-happy
>> when it's quite obvious that you don't know enough about Lisp to
>> attack it?
>
> In addition to macros that define classes or methods, a common macro
> is the WITH-* macro, which sets up some kind of context, runs the body
> inside that context, and then does some cleanup.
>
> For example, my Lisp vendor, LispWorks, provides the macro MP:WITH-LOCK :
>
> (mp:with-lock (*the-big-lock*)
> (do-something-atomic)
> (something-else)
> (almost-odone))
>
> The generated first seizes a process lock called *THE-BIG-LOCK*, runs
> the code in the body and then releases the lock. I never have to
> worry that I've taken a lock without releasing it, because LispWorks
> has encoded that behaviour into MP:WITH-LOCK (and if they handn't,
> this macro is trivial to write).
>
> Now I can tell if I'm keeping a lock around too long because all the
> code that appears inside this WITH-LOCK is all the code that I'm
> locking. Further, the generated code is surrounded by an
> UNWIND-PROTECT, which means that if an error is raised or anything
> abnormal happens in the dynamic scope of the UNWIND-PROTECT, Lisp will
> run cleanup code as it flees back up the stack. So if there is an
> error in my code, it does not prevent other processes from seizing
> that lock, because it will be released as the error is signaled.
>
> Here is the expansion:
>
> CL-USER 7 > (write (macroexpand '(mp:with-lock (*the-big-lock*)
> (do-something-atomic)
> (something-else)
> (almost-odone)))
> :pretty t :case :downcase)
> (let ((#:g17553 *the-big-lock*))
> (when (mp:process-lock #:g17553)
> (unwind-protect
> (progn (do-something-atomic) (something-else) (almost-odone))
> (mp::in-process-unlock #:g17553))))
Now it happens what Graham described. The blub programmer will explain
that this is not needed, because he can do the same thing in blub.
In Python you could write a function withLock that takes a lock and a
function.
Then you can say
def throwAway001():
doSomethingAtomic()
somethingElse()
almostOdone()
withLock(theBigLock, throwAway001)
or maybe
withLock(theBigLock,
lambda ():
doSomethingAtomic()
somethingElse()
almostOdone())
So Lisp saves you the "lambda ():" or "def throwAway001():".
That is nice I would say. Why write it if the computer could do that for
you?
Andr�
--
On Sun, 10 Dec 2006 04:24:43 +1100, Steven D'Aprano
<·····@REMOVE.THIS.cybersource.com.au> tried to confuse everyone with this
message:
>On Sat, 09 Dec 2006 14:00:10 +0000, Timofei Shatrov wrote:
>
>> On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano
>> <·····@REMOVE.THIS.cybersource.com.au> tried to confuse everyone with this
>> message:
>>
>>>On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>>>
>>>> if Common Lisp didn't have CLOS, its object system, I could write my own
>>>> as a library and it would be just as powerful and just as easy to use as
>>>> the system Common Lisp already provides. Stuff like this is impossible
>>>> in other languages.
>>>
>>>Dude. Turing Complete. Don't you Lisp developers know anything about
>>>computer science?
>>
>> Here, you've basically shot yourself in the ass. Appealing to Turing
>> completeness when talking about programming language features is about the
>> dumbest thing you can make. In Turing sense, a program is simply a function that
>> takes an argument and returns a value. It doesn't say anything about how this
>> function was implemented. It could be Turing machine, lambda calculus, Markov
>> chains or whatever else. All these methods produce the same set of programs, but
>> that doesn't mean you could implement lambda in Turing machine for example.
>
>What exactly are you trying to say here? Is this a comment about the
>relative practicality of writing code in a Turing machine versus
>high-level languages, or are you implying that lambda calculus is "bigger"
>than any Turing-complete language?
>
I'm trying to say that the ability to read is a very useful skill in a Usenet
discussion. Your posts, like the two quoted above, seem to indicate the lack of
it.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
In article
<······························@REMOVE.THIS.cybersource.com.au>,
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
> Now, if you want to tell me that, despite all the talk, Lisp coders don't
> actually create new syntax or mini-languages all that often, that they
> just use macros as functions, then the question becomes: why do you need
> macros then if you are just using them as functions? Why not use functions?
Well, as a user of both lisp and python, it seems to me that python
programs can create their own domain-specific mini-languages using
mechanisms such as objects, classes and functions. It's quite
possible to mask the bare-bones python behind functions and objects
derived from imported libraries, which themselves might not be
python-native. And extreme advocates of functional programming
raise the same arguments about objects: they create obfuscated
constructs that are difficult to read and understand without
unpacking their internals. The questions could be asked, why do you
need objects if you are just using them as containers for functions?
Why not just use functions?
Python already is very explicit about supporting OOP, a paradigm
that bundles functions and data into larger constructs. So why is it
that many of these debates center around macros, which is another
paradigm that bundles functions and data into larger constructs?
Both objects and macros have IMO similar potential for abuse and
obfuscation.
But to answer your question, I use a macro when I have a problem
that can't be easily reduced to a naive function. I also use object
classes when I have a problem that can't be easily reduced to a
simple data type. When I don't need an macro or an object class, I
just use naive functions and simple data types.
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> schreibt:
> On Sat, 09 Dec 2006 14:00:10 +0000, Timofei Shatrov wrote:
>
>> On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano
>> <·····@REMOVE.THIS.cybersource.com.au> tried to confuse everyone with this
>> message:
>>
>>>On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>>>
>>>> if Common Lisp didn't have CLOS, its object system, I could write my own
>>>> as a library and it would be just as powerful and just as easy to use as
>>>> the system Common Lisp already provides. Stuff like this is impossible
>>>> in other languages.
>>>
>>>Dude. Turing Complete. Don't you Lisp developers know anything about
>>>computer science?
>>
>> Here, you've basically shot yourself in the ass. Appealing to
>> Turing completeness when talking about programming language
>> features is about the dumbest thing you can make. In Turing sense,
>> a program is simply a function that takes an argument and returns a
>> value. It doesn't say anything about how this function was
>> implemented. It could be Turing machine, lambda calculus, Markov
>> chains or whatever else. All these methods produce the same set of
>> programs, but that doesn't mean you could implement lambda in
>> Turing machine for example.
[...]
> If you're talking about practicality, then of course you're correct,
> not all languages are equally expressive. Some languages are not
> expressive enough.
I agree.
> Some languages are too expressive.
I disagree. "Too expressive"--what a thing to say.
[...]
> Look, all snarkiness aside, it just isn't true that "stuff like this
> is impossible in other languages". If Wolfram Fenske had said "stuff
> like this isn't easy in many other languages" he would have been
> right.
I said that it's impossible to write you own object system in other
languages *and* have it behave like it was part of the language. OK,
you could always write your own pre-processor, i. e., your own
Foo+Objects to Foo compiler. But that's almost like saying it's
impossible. Now, object systems aside, how about that one: One of the
new features of Python 2.5 is a syntax for
--8<---------------cut here---------------start------------->8---
if condition:
x = true_value
else:
x = false_value
--8<---------------cut here---------------end--------------->8---
which becomes
--8<---------------cut here---------------start------------->8---
x = true_value if condition else false_value
--8<---------------cut here---------------end--------------->8---
(see [1]). IMO that's a nice addition because this pattern is
something that has bothered me for some time.
Here's another one, the "with" statement [2]:
--8<---------------cut here---------------start------------->8---
Some standard Python objects now support the context management
protocol and can be used with the 'with' statement. File objects are
one example:
with open('/etc/passwd', 'r') as f:
for line in f:
print line
... more processing code ...
After this statement has executed, the file object in f will have been
automatically closed, even if the 'for' loop raised an exception
part-way through the block.
--8<---------------cut here---------------end--------------->8---
My point is that in Python--and AFAIK any other language except maybe
OCaml and maybe maybe Haskell--, you have to wait for these changes
until the language designers decide to make the for you. And if they
don't, you're out of luck. In Lisp, you can just add this yourself.
> And if he had said "and stuff like this carries risks as well as
> benefits" he would have come across as less of a language fanatic.
Sure, you can shoot yourself in the foot with macros. But you can do
that in any language of any degree of expressiveness [3]. Come to
think of it, the whole reason why we use high level languages is
because of their expressiveness: We get stuff done faster and
introduce less errors. So "the more expressive, the better," right?
But according to you, there's a point when a language gets "too
expressive". I don't see why.
> One of the risks with Python is the ease with which you can modify the
> built-ins. An expression like list(2, 3, 4) doesn't necessarily create a
> list from 2, 3, and 4, because the built-in list could be redefined.
> (In practice, that's not often a real problem, because experienced
> Python developers simply learn not to needlessly or confusingly shadow
> built-ins. It's not the best system, but it works well enough in
> practice.)
So you do trust your developers not to do anything stupid.
> But at least the basic syntax and keywords of the language are known
> to be constant. With Lisp macros, even that isn't guaranteed.
Let me summarize: you're allowed to redefine every built-in function
you want but introducing new syntax is simply too much. See, this is
the kind of thinking I don't understand. I say macros are good
because a), b), and c) and you answer macros are bad because, uhm,
well, it would be pure anarchy.
> Now, if Lispers would say "Oh yes, macros give you great power, and
> with great power comes great responsibility. Be careful." then, no
> doubt, we'd take you guys more seriously.
Sure, it's a powerful tool but it's not *that* hard to use. Maybe
you're afraid of it because that it's something that's unique to Lisp?
But IMO the reason for that is not that they're too powerful. IMO it
has mostly to do with the fact that other languages' syntaxes make it
too difficult to implement Lisp-style macros.
> But we don't hear that -- we hear Lispers going on and on about how
> great it is that they can easily redefine every corner of the
> language. Do you blame people for *believing them* and imagining
> that reading Lisp code is like following some ghostly
> will-o-the-wisp across a swamp, where nothing is what it seems and
> the landscape is forever shifting?
Come on! You're telling me people don't learn Lisp because they are
afraid of it? Python allows you to redefine built-in functions, as
you said, Ruby allows you to attach new methods to live objects, but
Lisp is simply going too far?
> Now, if you want to tell me that, despite all the talk, Lisp coders
> don't actually create new syntax or mini-languages all that often,
> that they just use macros as functions, then the question becomes:
> why do you need macros then if you are just using them as functions?
> Why not use functions?
Easy because macros are not functions. Functions allow you abstract
functionality, macros allow you abstract syntax. Look at the examples
above. How would you implement conditional expressions as a function?
Answer: You can't, it's syntax.
Footnotes:
[1] <http://docs.python.org/whatsnew/pep-308.html>
[2] <http://docs.python.org/whatsnew/pep-343.html>
[3] And here's the proof
<http://www.reed.edu/~tuckers/jokes/foot.html> :-)
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Wolfram Fenske wrote:
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> schreibt:
...
>>Some languages are too expressive.
>
>
> I disagree. "Too expressive"--what a thing to say.
A sad moment in Usenet discourse... a moment of silence, please.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Wolfram Fenske wrote:
> Sure, you can shoot yourself in the foot with macros. But you can do
> that in any language of any degree of expressiveness [3]. Come to
> think of it, the whole reason why we use high level languages is
> because of their expressiveness: We get stuff done faster and
> introduce less errors. So "the more expressive, the better," right?
> But according to you, there's a point when a language gets "too
> expressive". I don't see why.
Is Qi Lisp? There are several problems:
1. Language design is so hard that most people get it wrong (e.g. Python).
What do you do when you find that your proprietary syntax extension was a
bad idea?
2. There is a trade-off between being expressive and sacrificing syntax.
Lisp is very verbose because you must write the AST for your code by hand,
even if you aren't exploiting s-exprs, EVAL and macros.
3. One could argue that every syntax extension in Lisp makes a new language.
So Lisp is a heavily forked language. Is that a good?
Maybe if you're a lone coder and an expert in language design then you can
knock up a DSL and halve your working time using Lisp. In industry, you're
more likely to hire four people with half the expertise each and restrict
them to a well-known C-like syntax.
>> Now, if Lispers would say "Oh yes, macros give you great power, and
>> with great power comes great responsibility. Be careful." then, no
>> doubt, we'd take you guys more seriously.
>
> Sure, it's a powerful tool but it's not *that* hard to use.
Look at all the threads in c.l.l where people have gotten confused by their
own macros. Look at the unboxing macro that Juho Snellman used to try to
get competitive performance for Lisp on my ray tracer benchmark:
(defmacro def ((name params &body body)
(mname &rest mparams)
(wname &rest wparams))
`(progn
(declaim (inline ,name ,wname))
(defun ,name ,params
(declare (type double-float ,@params))
,@body)
(defmacro ,mname ,(mapcar #'car mparams)
,(loop with inner = (list name)
with body = ``,',inner
with all-names = nil
for (form count) in (reverse mparams)
for names = (loop repeat count collect (gensym))
do
(setf all-names (append all-names names))
(setf body ``(multiple-value-bind ,',(reverse names)
,,form ,,body))
finally
(setf (cdr inner) (reverse all-names))
(return body)))
(defun ,wname ,(mapcar #'car wparams)
(,mname ,@(mapcar #'cadr wparams)))))
Note that this page of magic does something done by the compiler in most
other languages.
> Maybe you're afraid of it because that it's something that's unique to
> Lisp?
It isn't unique to Lisp. OCaml has camlp4, for example. It is very rarely
used, perhaps because the OCaml community is wary of syntax extensions or
perhaps because it is even harder to use than Lisp's macros.
> But IMO the reason for that is not that they're too powerful. IMO it
> has mostly to do with the fact that other languages' syntaxes make it
> too difficult to implement Lisp-style macros.
I agree. However, the fact that other languages ship with sophisticated
syntax can also be a good thing: it can make them more concise, it can make
them more expressive (e.g. pattern matching).
I get the impression that Lispers use macros when they could use HOFs.
>> But we don't hear that -- we hear Lispers going on and on about how
>> great it is that they can easily redefine every corner of the
>> language. Do you blame people for *believing them* and imagining
>> that reading Lisp code is like following some ghostly
>> will-o-the-wisp across a swamp, where nothing is what it seems and
>> the landscape is forever shifting?
>
> Come on! You're telling me people don't learn Lisp because they are
> afraid of it? Python allows you to redefine built-in functions, as
> you said, Ruby allows you to attach new methods to live objects, but
> Lisp is simply going too far?
The biggest activation barrier to using Lisp for me is having to write ASTs
for everything by hand. Perhaps it would be a good idea to include an
editor that allowed newbies to use a more familiar syntax and have it
converted to s-exprs for them, so they can see the correspondence and learn
how to write s-exprs themselves?
>> Now, if you want to tell me that, despite all the talk, Lisp coders
>> don't actually create new syntax or mini-languages all that often,
>> that they just use macros as functions, then the question becomes:
>> why do you need macros then if you are just using them as functions?
>> Why not use functions?
>
> Easy because macros are not functions. Functions allow you abstract
> functionality, macros allow you abstract syntax.
While that is true, you've provided two examples to back up his point. In
another post you use the example of wrapping try .. finally which can be
done with a HOF instead of a macro. Next, you use the example of COND,
which can also be written as a HOF instead of as a macro:
> Look at the examples
> above. How would you implement conditional expressions as a function?
> Answer: You can't, it's syntax.
That is not true. You can implement conditional expressions without
extending the syntax:
# let rec cond x rules default = match rules with
| [] -> default
| (f, e) :: _ when f(x) -> e
| _ :: t -> cond x t default;;
val cond : 'a -> (('a -> bool) * 'b) list -> 'b -> 'b = <fun>
For example:
# cond 2
[( = ) 1, "one";
( = ) 2, "two";
( = ) 3, "three"]
"neither one, two nor three";;
- : string = "two"
Of course, this is pointless in OCaml because the built-in pattern matcher
is more expressive, powerful and faster than COND:
# match 2 with
| 1 -> "one"
| 2 -> "two"
| 3 -> "three"
| _ -> "neither one, two nor three";;
- : string = "two"
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> # cond 2
> [( = ) 1, "one";
> ( = ) 2, "two";
> ( = ) 3, "three"]
> "neither one, two nor three";;
> - : string = "two"
I'm missing something. Doesn't Ocaml have strict evaluation? That
means if you use function calls instead of string constants in those
values, they all get called. You haven't really done what cond does.
Paul Rubin wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> # cond 2
>> [( = ) 1, "one";
>> ( = ) 2, "two";
>> ( = ) 3, "three"]
>> "neither one, two nor three";;
>> - : string = "two"
>
> I'm missing something. Doesn't Ocaml have strict evaluation?
Yes.
> That means if you use function calls instead of string constants in those
> values, they all get called.
True.
> You haven't really done what cond does.
Good point. How about this:
# let rec cond x rules default = match rules with
| [] -> default
| f :: t -> match f x with
| Some e -> e
| None -> cond x t default;;
val cond : 'a -> ('a -> 'b option) list -> 'b -> 'b = <fun>
# cond 2
[(fun n -> if n=1 then Some "one" else None);
(fun n -> if n=2 then Some "two" else None);
(fun n -> if n=3 then Some "three" else None)]
"neither one, two nor three";;
- : string = "two"
The 'Some "one"' is only called if its predicate matched. Anyway, you don't
need macros to write COND and you don't need COND if you have pattern
matching.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Paul Rubin wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
[...]
> Good point. How about this:
>
> # let rec cond x rules default = match rules with
> | [] -> default
> | f :: t -> match f x with
> | Some e -> e
> | None -> cond x t default;;
> val cond : 'a -> ('a -> 'b option) list -> 'b -> 'b = <fun>
>
> # cond 2
> [(fun n -> if n=1 then Some "one" else None);
> (fun n -> if n=2 then Some "two" else None);
> (fun n -> if n=3 then Some "three" else None)]
> "neither one, two nor three";;
> - : string = "two"
>
> The 'Some "one"' is only called if its predicate matched. Anyway,
> you don't need macros to write COND
True, if you have closures you don't. But you have to admit that your
solution is ugly. In Lisp:
--8<---------------cut here---------------start------------->8---
(let ((n 2))
(cond
((eql n 1) "one")
((eql n 2) "two")
((eql n 3) "three")
(t "neither one, two nor three")))
--8<---------------cut here---------------end--------------->8---
It's even nicer using CASE:
--8<---------------cut here---------------start------------->8---
(case 2
(1 "one")
(2 "two")
(3 "three")
(t "neither one, two nor three"))
--8<---------------cut here---------------end--------------->8---
> and you don't need COND if you have pattern matching.
Actually, I think CASE is closer to pattern matching than COND. But
this is pointless. I'm sure we can find some macro for which there is
no equivalent in OCaml (or Python, which this discussion was about).
How about PROG1, PROG2, SETF, PSETF, INCF?
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Jon Harrop schrieb:
> Paul Rubin wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>> # cond 2
>>> [( = ) 1, "one";
>>> ( = ) 2, "two";
>>> ( = ) 3, "three"]
>>> "neither one, two nor three";;
>>> - : string = "two"
>> I'm missing something. Doesn't Ocaml have strict evaluation?
>
> Yes.
>
>> That means if you use function calls instead of string constants in those
>> values, they all get called.
>
> True.
>
>> You haven't really done what cond does.
>
> Good point. How about this:
>
> # let rec cond x rules default = match rules with
> | [] -> default
> | f :: t -> match f x with
> | Some e -> e
> | None -> cond x t default;;
> val cond : 'a -> ('a -> 'b option) list -> 'b -> 'b = <fun>
>
> # cond 2
> [(fun n -> if n=1 then Some "one" else None);
> (fun n -> if n=2 then Some "two" else None);
> (fun n -> if n=3 then Some "three" else None)]
> "neither one, two nor three";;
> - : string = "two"
>
> The 'Some "one"' is only called if its predicate matched. Anyway, you don't
> need macros to write COND and you don't need COND if you have pattern
> matching.
>
Very well. A Lisper would probably solve the "cond problem" the same way
(with a HOF). The additional step that a Lisper might do if he uses cond
more than 2 times is to add a macro.
So in the end one could say what Wolfgang Fenske did:
(case 2
(1 "one")
(2 "two")
(3 "three")
(t "neither one, two nor three"))
In this case we have CASE with 10 tokens/brain units and the pure HOF
version, with 43 tokens/brain units.
This is a case where macro begins to really abstract some more stuff
away. For your pattern matcher version I also count 10 tokens.
Andr�
--
Jon Harrop <···@ffconsultancy.com> writes:
> Wolfram Fenske wrote:
>> Sure, you can shoot yourself in the foot with macros. But you can do
>> that in any language of any degree of expressiveness [3]. Come to
>> think of it, the whole reason why we use high level languages is
>> because of their expressiveness: We get stuff done faster and
>> introduce less errors. So "the more expressive, the better," right?
>> But according to you, there's a point when a language gets "too
>> expressive". I don't see why.
>
> Is Qi Lisp?
Maybe, havn't had time to study it yet. Hey, seems like it was
invented by the person who started this thread, Mark Tarver. :-)
> There are several problems:
>
> 1. Language design is so hard that most people get it wrong (e.g. Python).
> What do you do when you find that your proprietary syntax extension was a
> bad idea?
Rewrite it/remove it, like I'd rewrite/remove a function that I decide
was a bad idea.
> 2. There is a trade-off between being expressive and sacrificing syntax.
> Lisp is very verbose because you must write the AST for your code by hand,
> even if you aren't exploiting s-exprs, EVAL and macros.
To say it's verbose "even if you aren't exploiting [...] macros"
doesn't make sense. Macros don't add to the verbosity, they reduce
it. Lisp syntax introduces an overhead if you do a lot of numerical
work but for other code I believe macros more than make up for having
to write the AST by hand.
> 3. One could argue that every syntax extension in Lisp makes a new language.
> So Lisp is a heavily forked language. Is that a good?
Using the same logic one could argue that every new function creates a
new language. I don't see it that way.
[...]
>>> Now, if Lispers would say "Oh yes, macros give you great power, and
>>> with great power comes great responsibility. Be careful." then, no
>>> doubt, we'd take you guys more seriously.
>>
>> Sure, it's a powerful tool but it's not *that* hard to use.
>
> Look at all the threads in c.l.l where people have gotten confused
> by their own macros.
I guess these are mostly newbies. There are a few pitfalls,
especially with CL's macro system, but you learn to avoid them soon
enough [1].
> Look at the unboxing macro that Juho Snellman used to try to get
> competitive performance for Lisp on my ray tracer benchmark:
[...]
> Note that this page of magic does something done by the compiler in
> most other languages.
AFAICT this macro automatically adds type declarations to make the
compiled code faster. This is hardly a typical use of a macro.
>> Maybe you're afraid of it because that it's something that's unique to
>> Lisp?
>
> It isn't unique to Lisp. OCaml has camlp4,
I know. I think I mentioned OCaml somewhere in another thread.
> for example. It is very rarely used, perhaps because the OCaml
> community is wary of syntax extensions or perhaps because it is even
> harder to use than Lisp's macros.
You're right, it *is* harder to use than CL's macro system. But
you're implying that CL's macro system is also are hard to use. I
don't agree. It takes some getting used to but after a time writing
comes as naturally as writing functions. At least it did for me.
>> But IMO the reason for that is not that they're too powerful. IMO it
>> has mostly to do with the fact that other languages' syntaxes make it
>> too difficult to implement Lisp-style macros.
>
> I agree. However, the fact that other languages ship with
> sophisticated syntax can also be a good thing: it can make them more
> concise,
Well, it better! Without any macros whatsoever you're screwed if the
syntax is too verbose.
> it can make them more expressive (e.g. pattern matching).
Again, I think pattern matching is possible with Lisp macros.
> I get the impression that Lispers use macros when they could use
> HOFs.
No. Doing this is actually considered bad form.
[...]
>>> Now, if you want to tell me that, despite all the talk, Lisp coders
>>> don't actually create new syntax or mini-languages all that often,
>>> that they just use macros as functions, then the question becomes:
>>> why do you need macros then if you are just using them as functions?
>>> Why not use functions?
>>
>> Easy because macros are not functions. Functions allow you abstract
>> functionality, macros allow you abstract syntax.
>
> While that is true, you've provided two examples to back up his point. In
> another post you use the example of wrapping try .. finally which can be
> done with a HOF instead of a macro.
Yes, but it would be more natural with a macro. The HOF solution is
not very idiomatic, IMO. Compare this
--8<---------------cut here---------------start------------->8---
def foo(connection):
# code block that uses connection
self.withConnection(foo)
--8<---------------cut here---------------end--------------->8---
to the hypothetical
--8<---------------cut here---------------start------------->8---
withConnection connection:
# code block that uses connection
--8<---------------cut here---------------end--------------->8---
Anyway, more below.
> Next, you use the example of COND, which can also be written as a
> HOF instead of as a macro:
OK. How about CL's DESTRUCTURING-BIND? It modifies the lexical
environment and thus cannot be implemented as a HOF:
--8<---------------cut here---------------start------------->8---
(destructuring-bind (foo (bar &optional (baz (default expression))))
(expression that returns a list)
(+ foo bar baz))
--8<---------------cut here---------------end--------------->8---
It's hard to explain the usefulness of macros to non-Lispers. Small
example tend to be trivial, longer examples require too much context
or seem contrived. Anyway, let's try another one, CL's WITH-SLOTS.
It makes the attributes (called slots) of an object accessible as if
they were local variables. Every time you read or write any of these
"variables" you're actually modifying the attributes of the object.
Instead of "(get-attribute1 obj)" to read the value and
"(set-attribute2 obj 'new-value)" to write it, you say
--8<---------------cut here---------------start------------->8---
(with-slots ((a1 attribute1) (a2 attribute2)) obj
(some-function a1)
(setq a2 'new-value))
--8<---------------cut here---------------end--------------->8---
and the appropriate function calls are inserted.
(AFAIK there's something similar in Visual Basic and probably other
languages.)
>> Look at the examples
>> above. How would you implement conditional expressions as a function?
>> Answer: You can't, it's syntax.
>
> That is not true. You can implement conditional expressions without
> extending the syntax:
>
> # let rec cond x rules default = match rules with
> | [] -> default
> | (f, e) :: _ when f(x) -> e
> | _ :: t -> cond x t default;;
> val cond : 'a -> (('a -> bool) * 'b) list -> 'b -> 'b = <fun>
>
> For example:
>
> # cond 2
> [( = ) 1, "one";
> ( = ) 2, "two";
> ( = ) 3, "three"]
> "neither one, two nor three";;
> - : string = "two"
Ah, but your solution isn't equivalent because all the expression in
"rules" are evaluated. E. g. this
--8<---------------cut here---------------start------------->8---
let _ =
let a = 0 in
cond a [ ( = ) 0, a + 1;
( = ) 1, 1 / a]
42;;
--8<---------------cut here---------------end--------------->8---
produces "Exception: Division_by_zero." whereas
--8<---------------cut here---------------start------------->8---
(let ((a 0))
(cond ((eql a 0) (+ a 1))
((eql a 1) (/ 1 a))
(t 42)))
--8<---------------cut here---------------end--------------->8---
evaluates to 1.
> Of course, this is pointless in OCaml because the built-in pattern matcher
> is more expressive, powerful and faster than COND:
>
> # match 2 with
> | 1 -> "one"
> | 2 -> "two"
> | 3 -> "three"
> | _ -> "neither one, two nor three";;
> - : string = "two"
Of course OCaml's pattern matcher is more expressive and powerful than
than COND. COND was not designed to do pattern matching.
Footnotes:
[1] E. g. by reading the macro chapters in Peter Seibel's "Pratical
Common Lisp":
<http://www.gigamonkeys.com/book/macros-defining-your-own.html>
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Jon Harrop wrote:
> Language design is so hard that most people get it wrong (e.g. Python).
_If_ Python's language design is "wrong", then this only proves the
point that keeping users from defining new language constructs doesn't
ensure sane language designs. In other words, language designers are not
any more special than language users are.
_If_ Python's language design is not "wrong" at least for some people,
then this only proves that people have different opinions about language
design and different preferences in that regard.
> What do you do when you find that your proprietary syntax extension was a
> bad idea?
The same you do with any bad library: You try to fix it, or you throw it
away and start from scratch.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Jon Harrop schrieb:
> It isn't unique to Lisp. OCaml has camlp4, for example. It is very rarely
> used, perhaps because the OCaml community is wary of syntax extensions or
> perhaps because it is even harder to use than Lisp's macros.
I don't know camlp4. At the moment it seems to me, that it is an external
tool, a program that preprocesses your code.
If it works this way I could imagine that this is the reason why not
many people use it. I think most programmers will use stuff that already
is included, if they can.
> I get the impression that Lispers use macros when they could use HOFs.
I personally don't see it this way. The HOF is used first to do most of
the work. For example if you have a pool of connections to a DB, then
you would write a function F which takes a block of code as an argument
(another function), pops a connection out of the pool (protected by a
mutex), calls its argument (executes the passed block of code) and then
pushes the connection back into the pool (again protected by a mutex).
Now F is a HOF which can be used to build useful tools for DB access,
like query functions.
A Lisper would now probably use a macro to free the programmer of a bit
of syntax - for creating the code block that gets passed to F.
So in Lisp instead of calling F you would use your new macro, maybe
(with-connection
(your-code-here)) [2 tokens/brain units]
as an alternative to
(f (lambda () (your-code-here)) [3 tokens/brain units]
> While that is true, you've provided two examples to back up his point. In
> another post you use the example of wrapping try .. finally which can be
> done with a HOF instead of a macro. Next, you use the example of COND,
> which can also be written as a HOF instead of as a macro:
Paul Rubin mentioned some problems with your code.
> Of course, this is pointless in OCaml because the built-in pattern matcher
> is more expressive, powerful and faster than COND:
>
> # match 2 with
> | 1 -> "one"
> | 2 -> "two"
> | 3 -> "three"
> | _ -> "neither one, two nor three";;
> - : string = "two"
In Lisp you can do the same. The pattern matcher is just a lib that you
can load.
You explained that the PM is faster than cond. Is it only a few cpu
cycles that a PM saves or are we talking about tens of millions cycles?
Andr�
--
Andr� Thieme wrote:
> I don't know camlp4. At the moment it seems to me, that it is an external
> tool, a program that preprocesses your code.
> If it works this way I could imagine that this is the reason why not
> many people use it. I think most programmers will use stuff that already
> is included, if they can.
There are some examples using camlp4 syntax extensions (e.g. for lazy stream
parsing) here:
http://www.ffconsultancy.com/free/ocaml/parsing.html
> You explained that the PM is faster than cond. Is it only a few cpu
> cycles that a PM saves or are we talking about tens of millions cycles?
I believe it is asymptotic complexity either in terms of code size or
performance.
You can get Lisp-like s-exprs from the OCaml compiler with -dlambda. Put the
symbolic simplifier from here:
http://www.ffconsultancy.com/free/ocaml/symbolic.html
into "ocaml -dlambda" and you get:
(letrec
(simplify/81
(function expr/82
(let
(expr2/83
(catch
(switch* expr/82
case tag 0: (exit 13)
case tag 1: (exit 13)
case tag 2:
(let
(match/119
(apply (field 10 (global List!)) simplify/81
(field 0 expr/82)))
(if match/119
(let (e/87 (field 0 match/119))
(catch
(let (match/120 (field 1 match/119))
(if match/120
(let (h2/89 (field 0 match/120))
(if (caml_greaterthan e/87 h2/89)
(makeblock 2
(makeblock 0 h2/89
(makeblock 0 e/87 (field 1 match/120))))
(switch e/87
case tag 0:
(let (n/92 (field 0 e/87))
(if (!= n/92 0)
(let
(match/121 (field 1 match/119)
match/122 (field 0 match/121))
(switch match/122
case tag 0:
(makeblock 2
(makeblock 0
(makeblock 0
(+ n/92 (field 0
match/122)))
(field 1 match/121)))
default: (exit 4)))
(makeblock 2 (field 1 match/119))))
case tag 2:
(makeblock 2
(apply (field 21 (global Pervasives!))
(field 0 e/87) (field 1 match/119)))
default: (exit 4))))
e/87))
with (4)
(let (t/101 (field 1 match/119))
(if (caml_equal e/87 (field 0 t/101))
(makeblock 2
(makeblock 0
(makeblock 3
(makeblock 0 [0: 2] (makeblock 0 e/87
0a)))
(field 1 t/101)))
(let
(e/103 (apply simplify/81 (makeblock 2
t/101)))
(switch e/103
case tag 2:
(makeblock 2
(makeblock 0 e/87 (field 0 e/103)))
default:
(makeblock 2
(makeblock 0 e/87 (makeblock 0 e/103
0a)))))))))
[0: 0]))
case tag 3:
(let
(match/123
(apply (field 10 (global List!)) simplify/81
(field 0 expr/82)))
(if match/123
(let (e/104 (field 0 match/123))
(catch
(let (match/124 (field 1 match/123))
(if match/124
(let (h2/106 (field 0 match/124))
(if (caml_greaterthan e/104 h2/106)
(makeblock 3
(makeblock 0 h2/106
(makeblock 0 e/104 (field 1
match/124))))
(switch e/104
case tag 0:
(let (n/110 (field 0 e/104))
(if (!= n/110 0)
(if (!= n/110 1)
(let
(match/125 (field 1 match/123)
match/126 (field 0 match/125))
(switch match/126
case tag 0:
(makeblock 3
(makeblock 0
(makeblock 0
(* n/110
(field 0 match/126)))
(field 1 match/125)))
default: (exit 10)))
(makeblock 3 (field 1 match/123)))
[0: 0]))
case tag 3:
(makeblock 3
(apply (field 21 (global Pervasives!))
(field 0 e/104) (field 1 match/123)))
default: (exit 10))))
e/104))
with (10)
(let
(e/118
(apply simplify/81
(makeblock 3 (field 1 match/123))))
(switch e/118
case tag 3:
(makeblock 3 (makeblock 0 e/104 (field 0
e/118)))
default:
(makeblock 3
(makeblock 0 e/104 (makeblock 0 e/118
0a)))))))
[0: 1])))
with (13) expr/82))
(if (caml_equal expr/82 expr2/83) expr/82
(apply simplify/81 expr2/83)))))
(apply (field 1 (global Toploop!)) "simplify" simplify/81))
That's a lot more code. The more you try to factor your Lisp code to write
things like that more efficiently, the more you Greenspun's tenth rule
because you're reinventing the pattern matcher (and probably doing a bad
job of it).
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop schrieb:
> Andr� Thieme wrote:
> You can get Lisp-like s-exprs from the OCaml compiler with -dlambda. Put the
> symbolic simplifier from here:
>
> http://www.ffconsultancy.com/free/ocaml/symbolic.html
>
> into "ocaml -dlambda" and you get:
>
> (letrec
> [...]
> (apply simplify/81 expr2/83)))))
> (apply (field 1 (global Toploop!)) "simplify" simplify/81))
>
> That's a lot more code. The more you try to factor your Lisp code to write
> things like that more efficiently, the more you Greenspun's tenth rule
> because you're reinventing the pattern matcher (and probably doing a bad
> job of it).
If you would use Lisp you should use a pattern matcher.
Maybe you would like to implement one in Lisp? One that is doing pretty
much the same that ocamls PM is doing?
There should go lot's of effort into it, one time. When it is done then
Lispers could have efficient pattern matching in many of their projects.
Without irony, you could really do it.
For logic programming it already happend, but only for a commercial
Lisp. See: http://bc.tech.coop/blog/040919.html
That was a domain specific task. It is very easy to express this in
Prolog (or here inside Lisp). It ran much faster than an optimized Lisp
version and was very clear.
Programmers who know many paradigms can be very productive in Lisp.
Solve specific tasks with OOP, with PM, functional programming,
declarative/logical programming, etc.
Andr�
--
Steven D'Aprano schrieb:
> With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
> "Oh yes, macros give you great power, and with great power comes great
> responsibility. Be careful."
Well, macros are one (big) thing that Lisp has and which many other
languages don't have. Their are other things too, and some of them are
in Python as well, which is a very nice scripting language.
Often macros save just some bits of code. Saving one loc is not much you
might say. But think about it the other way around.
How would you like it to call doodleShooble() each time before you use
the if statement? Of course you would not like it. The good thing about
Lisp is, that you can eliminate this pattern.
Apropos pattern.. most design patterns are not (very) visible in Lisp.
Many of them can be abstracted away with macros+functional programming.
Andr�
--
Andr� Thieme wrote:
> Well, macros are one (big) thing that Lisp has and which many other
> languages don't have. Their are other things too, and some of them are
> in Python as well, which is a very nice scripting language.
I think s-exprs and EVAL are the main things that Lisp has and that other
languages don't. Note that most other languages don't have these because
they were deemed to be a bad trade-off three decades ago. ;-)
> Often macros save just some bits of code. Saving one loc is not much you
> might say. But think about it the other way around.
> How would you like it to call doodleShooble() each time before you use
> the if statement? Of course you would not like it. The good thing about
> Lisp is, that you can eliminate this pattern.
You can eliminate that pattern with a HOF, of course. You don't need macros.
let if' p e1 e2 =
doodleShooble();
force (if p then e1 else e2)
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> André Thieme wrote:
> > Well, macros are one (big) thing that Lisp has and which many other
> > languages don't have. Their are other things too, and some of them are
> > in Python as well, which is a very nice scripting language.
>
> I think s-exprs and EVAL are the main things that Lisp has and that other
> languages don't.
I don't think eval is really not relevant. Once you have s-expressions
then building eval is easy.
The really unique thing is the uniform treatment of data and code using
s-expressions.
> Note that most other languages don't have these because
> they were deemed to be a bad trade-off three decades ago. ;-)
Saying "they were deemed" is cheating ;). More useful is giving reason
why they are a bad trade off.
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> Well, macros are one (big) thing that Lisp has and which many other
>> languages don't have. Their are other things too, and some of them are
>> in Python as well, which is a very nice scripting language.
>
> I think s-exprs and EVAL are the main things that Lisp has and that other
> languages don't. Note that most other languages don't have these because
> they were deemed to be a bad trade-off three decades ago. ;-)
>
>> Often macros save just some bits of code. Saving one loc is not much you
>> might say. But think about it the other way around.
>> How would you like it to call doodleShooble() each time before you use
>> the if statement? Of course you would not like it. The good thing about
>> Lisp is, that you can eliminate this pattern.
>
> You can eliminate that pattern with a HOF, of course. You don't need macros.
>
> let if' p e1 e2 =
> doodleShooble();
> force (if p then e1 else e2)
>
I see, I expressed it in a way that make you think that a HOF could
eliminate it.
I just wanted to show that it is not good to have some extra work to do.
Your idea was to abstract it away.
Let me try with my non-existant ocaml skills to explain what I mean.
Let's say you have a function f that takes a function object.
When you now call f and want to pass a throw away function you would
want to create an anonymous function.
As I understand it this can be done with "(fun arg -> arg + 1)" or
something similar.
How can you factor out the "(fun)" with a HOF?
Andr�
--
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>
>> if Common Lisp didn't have CLOS, its object system, I could write my own
>> as a library and it would be just as powerful and just as easy to use as
>> the system Common Lisp already provides. Stuff like this is impossible
>> in other languages.
>
> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?
Of course, but you have to realize that Turing-completeness is a
useless concept when comparing languages. C and Python are both
Turing-complete. So: write me some code in each that reads in a line
of text, splits it on spaces and stores the result in an array. Which
would you rather write? Which will be shorter and more easily changed
and straightforwardly grasped in the future?
QED. Turing-completeness is irrelevant when comparing languages.
Take it as a given.
Bill Atkins wrote:
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>
>> On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>>
>>> if Common Lisp didn't have CLOS, its object system, I could write my own
>>> as a library and it would be just as powerful and just as easy to use as
>>> the system Common Lisp already provides. Stuff like this is impossible
>>> in other languages.
>>
>> Dude. Turing Complete. Don't you Lisp developers know anything about
>> computer science?
>
> Of course, but you have to realize that Turing-completeness is a
> useless concept when comparing languages. C and Python are both
> Turing-complete. So: write me some code in each that reads in a line
> of text, splits it on spaces and stores the result in an array. Which
> would you rather write? Which will be shorter and more easily changed
> and straightforwardly grasped in the future?
>
> QED. Turing-completeness is irrelevant when comparing languages.
> Take it as a given.
Lisp ? ;-)
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?
"Can you imagine if carpenters were like computer scientists? Some of
them would argue that it's not necessary to own a hammer because the
butt of a screwdriver is naildriver-complete."
-- Barry Margolin in comp.lang.lisp
On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>
>> if Common Lisp didn't have CLOS, its object system, I could write my own
>> as a library and it would be just as powerful and just as easy to use as
>> the system Common Lisp already provides. Stuff like this is impossible
>> in other languages.
>
> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?
>
> Anything any language can do is possible in any other language, if you are
> willing to write your own libraries.
*lol* Good luck with that attitude:
http://redwing.hutman.net/~mreed/warriorshtm/troglodyte.htm
..or did you forget to add "in theory"; which is of course what everyone
already knows as they see their compilers do it every day.
--
Lars Rune Nøstdal
http://nostdal.org/
Wolfram Fenske wrote:
> But seriously... All the interesting features that haven't originated from
> Lisp (e. g. OO from Smalltalk) could in turn easily be implemented in Lisp
> with a couple of macros.
I was under the impression that CLOS was non-trivial to write. There are
many other interesting features that haven't originated from Lisp (e.g.
pattern matching in SML, OCaml, Haskell, F#, Mathematica, ...) that cannot
be implemented easily in Lisp because they are intrinsically complicated.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Wolfram Fenske wrote:
>> But seriously... All the interesting features that haven't originated from
>> Lisp (e. g. OO from Smalltalk) could in turn easily be implemented in Lisp
>> with a couple of macros.
>
> I was under the impression that CLOS was non-trivial to write.
True, but that's because CLOS is a non-trivial object system. I admit
I may have overstated the case a bit.
> There are many other interesting features that haven't originated
> from Lisp (e.g. pattern matching in SML, OCaml, Haskell, F#,
> Mathematica, ...) that cannot be implemented easily in Lisp because
> they are intrinsically complicated.
As I already wrote in another post, to say "all features ..." was a
mistake. There are certain things that do require a change in the
compiler. However, I'm fairly certain pattern matching isn't one of
them.
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
Wolfram Fenske wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Wolfram Fenske wrote:
>>> But seriously... All the interesting features that haven't originated
>>> from Lisp (e. g. OO from Smalltalk) could in turn easily be implemented
>>> in Lisp with a couple of macros.
>>
>> I was under the impression that CLOS was non-trivial to write.
>
> True, but that's because CLOS is a non-trivial object system. I admit
> I may have overstated the case a bit.
Lots of modern languages have non-trivial OO, pattern matching, type systems
and so on. My point is that these are very hard to implement. Look at
OCaml, lots of people use its features yet they are the substance of recent
research papers on language design. Expecting jo-Lisper to come up with
anything comparable is overly optimistic, IMHO.
On the other hand, there are extensions like Qi that provide some of these
benefits. But the userbase of Qi is tiny compared to OCaml/Haskell.
>> There are many other interesting features that haven't originated
>> from Lisp (e.g. pattern matching in SML, OCaml, Haskell, F#,
>> Mathematica, ...) that cannot be implemented easily in Lisp because
>> they are intrinsically complicated.
>
> As I already wrote in another post, to say "all features ..." was a
> mistake. There are certain things that do require a change in the
> compiler. However, I'm fairly certain pattern matching isn't one of
> them.
You can get the semantics without altering the compiler but I doubt you'll
ever recover the performance.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Wolfram Fenske wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>> Wolfram Fenske wrote:
>>>> But seriously... All the interesting features that haven't originated
>>>> from Lisp (e. g. OO from Smalltalk) could in turn easily be implemented
>>>> in Lisp with a couple of macros.
>>>
>>> I was under the impression that CLOS was non-trivial to write.
>>
>> True, but that's because CLOS is a non-trivial object system. I admit
>> I may have overstated the case a bit.
>
> Lots of modern languages have non-trivial OO, pattern matching, type systems
> and so on. My point is that these are very hard to implement. Look at
> OCaml, lots of people use its features yet they are the substance of recent
> research papers on language design. Expecting jo-Lisper to come up with
> anything comparable is overly optimistic, IMHO.
Maybe Joe Lisper won't come up with it but maybe somebody writes a
library. Then everybody can use this shiny new OO paradigm, for
example. I guess AspectL that allows Aspect-Oriented Programming in
Lisp would be such a case, or the ITERATE macro (a replacement for
CL's hideous LOOP macro), or CFFI, a library that provides unified
access to the various foreign function interfaces of different Common
Lisp implementations.
But there are simpler cases. E. g. you might miss Python's list
comprehension syntax in CL. If you don't want to use CL's LOOP macro,
list comprehension could be added as a macro and might look like this:
(collect elem for elem in (source-expression) if (evenp elem))
In Python, where the example would read
[elem for elem in source_expression() if evenp(elem)]
Of course, CL has LOOP so you'd probably use that instead.
[...]
>>> There are many other interesting features that haven't originated
>>> from Lisp (e.g. pattern matching in SML, OCaml, Haskell, F#,
>>> Mathematica, ...) that cannot be implemented easily in Lisp because
>>> they are intrinsically complicated.
>>
>> As I already wrote in another post, to say "all features ..." was a
>> mistake. There are certain things that do require a change in the
>> compiler. However, I'm fairly certain pattern matching isn't one of
>> them.
>
> You can get the semantics without altering the compiler but I doubt
> you'll ever recover the performance.
I see, performance again ...
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
On Sun, 10 Dec 2006 12:42:37 +0100, Wolfram Fenske <·····@gmx.net> wrote:
>
> But there are simpler cases. E. g. you might miss Python's list
> comprehension syntax in CL. If you don't want to use CL's LOOP macro,
> list comprehension could be added as a macro and might look like this:
>
> (collect elem for elem in (source-expression) if (evenp elem))
>
> In Python, where the example would read
>
> [elem for elem in source_expression() if evenp(elem)]
>
> Of course, CL has LOOP so you'd probably use that instead.
>
Or.. You could just use this library..
http://user.it.uu.se/~svenolof/Collect/
and write something like:
(collect (list) ((* x x))
(in (x) '(1 2 3 4 5 6 7 8))
(when (evenp x))
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Sun, 10 Dec 2006 08:16:35 +0000, Jon Harrop wrote:
> I was under the impression that CLOS was non-trivial to write. There are
> many other interesting features that haven't originated from Lisp (e.g.
> pattern matching in SML, OCaml, Haskell, F#, Mathematica, ...) that cannot
> be implemented easily in Lisp because they are intrinsically complicated.
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/match/miranda/select.cl
On 10 Dez., 09:30, Brian Vanderford <····@localhost.localdomain> wrote:
> On Sun, 10 Dec 2006 08:16:35 +0000, Jon Harrop wrote:
> > I was under the impression that CLOS was non-trivial to write. There are
> > many other interesting features that haven't originated from Lisp (e.g.
> > pattern matching in SML, OCaml, Haskell, F#, Mathematica, ...) that cannot
> > be implemented easily in Lisp because they are intrinsically complicated.http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/...
Various pattern matching ideas have been implement (not always first,
but very early) in Lisp - way before any of these languages you list
even were thought of.
See for example this article by Daniel G. Bobrow and Warren Teitelman
published 1966 in the Proceedings of the first ACM symposium on
Symbolic and algebraic manipulation:
http://portal.acm.org/citation.cfm?id=807968&coll=portal&dl=ACM
"This article describes a notation and a programming language for
expressing, from within a LISP system, string transformations such as
those performed in COMIT or SNOBOL. A simple transformation (or
transformation rule) is specified by providing a pattern which must
match the structure to be transformed and a format which specifies how
to construct a new structure according to the segmentation specified by
the pattern. The patterns and formats are greatly generalized versions
of the left-half and right-half rules of COMIT and SNOBOL. For example,
elementary patterns and formats can be variable names, results of
computations, disjunctive sets, or repeating subpatterns; predicates
can be associated with elementary patterns which check relationships
among separated elements of the match; it is no longer necessary to
restrict the operations to linear strings since elementary patterns can
themselves match structures. The FLIP language has been implemented in
LISP 1.5, and has been successfully used in such disparate tasks as
editing LISP functions and parsing Kleene regular expressions."
You will see that all kinds of pattern matching has been explored in
Lisp
in the last 48 years.
A literature search should find hundreds of examples.
See OPS5, Macsyma, ... Several Lisp extensions
implement function parameter lists with complex patterns. And so
on.
See for example this paper from 1988 about a deductive pattern
matching system:
http://www.isi.edu/isd/LOOM/papers/macgregor/aaai88.pdf
You will find such facilities in a lot of Lisp libraries provide. You
can download LOOM and check it out. A successor of LOOM,
called PowerLOOM still runs in Lisp and is still being maintained.
http://www.isi.edu/isd/LOOM/PowerLoom/
You can download that too.
Yeah, and none is standard. Because there is no standard for 'pattern
matching'.
Haskell's pattern matching is as incompatible to Mathematica's pattern
matching
as to everything else.
On Sun, 10 Dec 2006 01:38:13 -0800, ······@corporate-world.lisp.de wrote:
>
>
> On 10 Dez., 09:30, Brian Vanderford <····@localhost.localdomain> wrote:
>> On Sun, 10 Dec 2006 08:16:35 +0000, Jon Harrop wrote:
>> > I was under the impression that CLOS was non-trivial to write. There are
>> > many other interesting features that haven't originated from Lisp (e.g.
>> > pattern matching in SML, OCaml, Haskell, F#, Mathematica, ...) that cannot
>> > be implemented easily in Lisp because they are intrinsically complicated.http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/...
>
> Various pattern matching ideas have been implement (not always first,
> but very early) in Lisp - way before any of these languages you list
> even were thought of.
I'm pretty sure you wanted to reply to Jon Harrop rather than to me.
On 10 Dez., 10:46, Brian Vanderford <····@localhost.localdomain> wrote:
> On Sun, 10 Dec 2006 01:38:13 -0800, ······@corporate-world.lisp.de wrote:
>
> > On 10 Dez., 09:30, Brian Vanderford <····@localhost.localdomain> wrote:
> >> On Sun, 10 Dec 2006 08:16:35 +0000, Jon Harrop wrote:
> >> > I was under the impression that CLOS was non-trivial to write. There are
> >> > many other interesting features that haven't originated from Lisp (e.g.
> >> > pattern matching in SML, OCaml, Haskell, F#, Mathematica, ...) that cannot
> >> > be implemented easily in Lisp because they are intrinsically complicated.http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/...
>
> > Various pattern matching ideas have been implement (not always first,
> > but very early) in Lisp - way before any of these languages you list
> > even were thought of.I'm pretty sure you wanted to reply to Jon Harrop rather than to me.
Right. Just was confused by the new Google Groups BETA user interface.
Sorry for that...
······@corporate-world.lisp.de wrote:
> Yeah, and none is standard.
And each has a tiny userbase.
> Because there is no standard for 'pattern matching'.
There is a significant common subset.
> Haskell's pattern matching is as incompatible to Mathematica's pattern
> matching
> as to everything else.
SML, OCaml, Haskell, F# and the other MLs have a lot in common, and a lot in
their pattern matchers that would have been a welcome addition in Common
Lisp. However, Lisp continues to ship only with COND...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop schrieb:
> ······@corporate-world.lisp.de wrote:
> > Yeah, and none is standard.
>
> And each has a tiny userbase.
As "SML, OCaml, Haskell, F# and the other MLs".
>
> > Because there is no standard for 'pattern matching'.
>
> There is a significant common subset.
Aha?
>
> > Haskell's pattern matching is as incompatible to Mathematica's pattern
> > matching
> > as to everything else.
>
> SML, OCaml, Haskell, F# and the other MLs have a lot in common,
So much that they are mostly incompatible and don't share much source.
Or does any Haskell implementation use OCaml code?
Plus I think that using pattern matching in function definitions
makes code less maintainable. One exposes the structure of
the data into the interface.
Practice in Common Lisp is to use multi-dispatch over objects passed
as parameters, where you would use pattern matching in other functional
languages. (Yes, we know that you don't like object-oriented
programming.).
> and a lot in
> their pattern matchers that would have been a welcome addition in Common
> Lisp. However, Lisp continues to ship only with COND...
Which Lisp are you talking about? Lots of Lisps are shipping with much
more
than COND.
Jon, if you have no experience with Lisp, why are you continueing to
post here?
Wouldn't it preferably to have atleast a slight interest in Lisp, or
even
have some interest in using some kind of Lisp?
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> Objective CAML for Scientists
> http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
······@corporate-world.lisp.de wrote:
> Jon Harrop schrieb:
>> And each has a tiny userbase.
>
> As "SML, OCaml, Haskell, F# and the other MLs".
OCaml and Haskell have much bigger userbases than any given pattern matching
library in Lisp.
>> SML, OCaml, Haskell, F# and the other MLs have a lot in common,
>
> So much that they are mostly incompatible
Actually SML and OCaml are very similar and F# and OCaml are mostly
compatible.
> Or does any Haskell implementation use OCaml code?
Not AFAIK, but that doesn't make the languages incompatible.
> Plus I think that using pattern matching in function definitions
> makes code less maintainable. One exposes the structure of
> the data into the interface.
That is addressed by views (Haskell) and active patterns (F#) and macros in
OCaml. Look at the lazy stream parsing extension for camlp4, for example:
http://www.ffconsultancy.com/free/ocaml/parsing.html
> Practice in Common Lisp is to use multi-dispatch over objects passed
> as parameters, where you would use pattern matching in other functional
> languages.
That doesn't match the sophistication of the pattern matchers in the
languages I've listed.
> (Yes, we know that you don't like object-oriented programming.).
I have nothing against OOP. I use it when it is appropriate.
>> and a lot in
>> their pattern matchers that would have been a welcome addition in Common
>> Lisp. However, Lisp continues to ship only with COND...
>
> Which Lisp are you talking about?
Common Lisp. I'm using SBCL here.
> Lots of Lisps are shipping with much more than COND.
Do any of these proprietary Lisp's have a significant userbase, e.g.
comparable to Haskell or OCaml?
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop schrieb:
> ······@corporate-world.lisp.de wrote:
> > Jon Harrop schrieb:
> >> And each has a tiny userbase.
> >
> > As "SML, OCaml, Haskell, F# and the other MLs".
>
> OCaml and Haskell have much bigger userbases than any given pattern matching
> library in Lisp.
How do you know that?
Just an indication:
I was looking at sourceforge and looked for OCaml downloads. There are
not much.
Maxima has on sourceforge probably more downloads than any Haskell and
OCaml sourceforge code combined.
>
> >> SML, OCaml, Haskell, F# and the other MLs have a lot in common,
> >
> > So much that they are mostly incompatible
>
> Actually SML and OCaml are very similar and F# and OCaml are mostly
> compatible.
>
> > Or does any Haskell implementation use OCaml code?
>
> Not AFAIK, but that doesn't make the languages incompatible.
But they are?
>
> > Plus I think that using pattern matching in function definitions
> > makes code less maintainable. One exposes the structure of
> > the data into the interface.
>
> That is addressed by views (Haskell) and active patterns (F#) and macros in
> OCaml. Look at the lazy stream parsing extension for camlp4, for example:
Where are 'views' in Haskell? Beyond a proposal from 1996?
>
> http://www.ffconsultancy.com/free/ocaml/parsing.html
>
> > Practice in Common Lisp is to use multi-dispatch over objects passed
> > as parameters, where you would use pattern matching in other functional
> > languages.
>
> That doesn't match the sophistication of the pattern matchers in the
> languages I've listed.
No? Just check 'method combinations' in the ANSI CL
docs. The combination of multiarg-dispatch + multiple-inheritance +
method combinations + objects changing its class is in my view quite
sophisticated.
> > (Yes, we know that you don't like object-oriented programming.).
>
> I have nothing against OOP. I use it when it is appropriate.
Oh, that sounds new to me.
>
> >> and a lot in
> >> their pattern matchers that would have been a welcome addition in Common
> >> Lisp. However, Lisp continues to ship only with COND...
> >
> > Which Lisp are you talking about?
>
> Common Lisp. I'm using SBCL here.
Then you are only three function calls away from a pattern matcher.
(require "ASDF")
(require "ASDF-INSTALL")
(asdf-install:install 'fare-matcher)
> > Lots of Lisps are shipping with much more than COND.
>
> Do any of these proprietary Lisp's have a significant userbase, e.g.
> comparable to Haskell or OCaml?
Does either of those two have a 'significant' userbase?
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> Objective CAML for Scientists
> http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
······@corporate-world.lisp.de wrote:
> Jon Harrop schrieb:
>> OCaml and Haskell have much bigger userbases than any given pattern
>> matching library in Lisp.
>
> How do you know that?
>
> Just an indication:
>
> I was looking at sourceforge and looked for OCaml downloads. There are
> not much.
Yes. The OCaml community rarely use sourceforge.
Here are some more objective indications:
According to Tiobe, the whole of Lisp+Scheme is only 6x bigger than either
Haskell or OCaml.
Google Code search gets 271 hits for Lisp, 180 for OCaml and 151 for
Haskell.
Google hits for "* programming": Lisp 200,000, ML 46,000 and Haskell 48,000.
According to this page, the most advanced Lisp extension that I'm aware of
(Qi):
http://www.lambdassociates.org/users.htm
has had as many downloads as my ray tracer gets every day.
> Maxima has on sourceforge probably more downloads than any Haskell and
> OCaml sourceforge code combined.
FFTW?
>> > Or does any Haskell implementation use OCaml code?
>>
>> Not AFAIK, but that doesn't make the languages incompatible.
>
> But they are?
Different languages, yes.
>> > Plus I think that using pattern matching in function definitions
>> > makes code less maintainable. One exposes the structure of
>> > the data into the interface.
>>
>> That is addressed by views (Haskell) and active patterns (F#) and macros
>> in OCaml. Look at the lazy stream parsing extension for camlp4, for
>> example:
>
> Where are 'views' in Haskell? Beyond a proposal from 1996?
Ask in comp.lang.haskell.
>> > Practice in Common Lisp is to use multi-dispatch over objects passed
>> > as parameters, where you would use pattern matching in other functional
>> > languages.
>>
>> That doesn't match the sophistication of the pattern matchers in the
>> languages I've listed.
>
> No? Just check 'method combinations' in the ANSI CL
> docs. The combination of multiarg-dispatch + multiple-inheritance +
> method combinations + objects changing its class is in my view quite
> sophisticated.
They sound like a few special cases of pattern matching.
>> >> and a lot in
>> >> their pattern matchers that would have been a welcome addition in
>> >> Common Lisp. However, Lisp continues to ship only with COND...
>> >
>> > Which Lisp are you talking about?
>>
>> Common Lisp. I'm using SBCL here.
>
> Then you are only three function calls away from a pattern matcher.
> (require "ASDF")
> (require "ASDF-INSTALL")
> (asdf-install:install 'fare-matcher)
Are there any docs/examples besides:
http://www.cliki.net/fare-matcher-docs
>> > Lots of Lisps are shipping with much more than COND.
>>
>> Do any of these proprietary Lisp's have a significant userbase, e.g.
>> comparable to Haskell or OCaml?
>
> Does either of those two have a 'significant' userbase?
Yes, to the extent that there are businesses specialising in them.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> ······@corporate-world.lisp.de wrote:
>> Jon Harrop schrieb:
>>> And each has a tiny userbase.
>> As "SML, OCaml, Haskell, F# and the other MLs".
>
> OCaml and Haskell have much bigger userbases than any given pattern matching
> library in Lisp.
ROTFL
Pascal
P.S.: Why don't you program in Java - the user base there is even
bigger. :-P
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Brian Vanderford wrote:
> On Sun, 10 Dec 2006 08:16:35 +0000, Jon Harrop wrote:
>> I was under the impression that CLOS was non-trivial to write. There are
>> many other interesting features that haven't originated from Lisp (e.g.
>> pattern matching in SML, OCaml, Haskell, F#, Mathematica, ...) that
>> cannot be implemented easily in Lisp because they are intrinsically
>> complicated.
>
>
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/match/miranda/select.cl
That is already a lot more than a "couple of macros" and it is still a long
way from the functionality provided by the pattern matchers bundled with
any of the languages I listed.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop schrieb:
> Brian Vanderford wrote:
>> On Sun, 10 Dec 2006 08:16:35 +0000, Jon Harrop wrote:
>>> I was under the impression that CLOS was non-trivial to write. There are
>>> many other interesting features that haven't originated from Lisp (e.g.
>>> pattern matching in SML, OCaml, Haskell, F#, Mathematica, ...) that
>>> cannot be implemented easily in Lisp because they are intrinsically
>>> complicated.
>>
> http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/match/miranda/select.cl
>
> That is already a lot more than a "couple of macros" and it is still a long
> way from the functionality provided by the pattern matchers bundled with
> any of the languages I listed.
A complete pattern matcher will be several screens full of code, because
it really isn't the easiest thing to do. The good thing is that it can
be added to lisp as a library, without changing the sources to the
compiler. I don't know how easy it would be to add a macro system to ML
from inside the system...
Andr�
--
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> That is already a lot more than a "couple of macros" and it is still a
>> long way from the functionality provided by the pattern matchers bundled
>> with any of the languages I listed.
>
> A complete pattern matcher will be several screens full of code, because
> it really isn't the easiest thing to do.
The pattern matchers in ML compilers are thousands of lines of code, yes.
> The good thing is that it can
> be added to lisp as a library, without changing the sources to the
> compiler.
You can get the semantics but not the performance because ML pattern
matchers can leverage the compiler's internal run-time representations of
values.
> I don't know how easy it would be to add a macro system to ML
> from inside the system...
You can run camlp4 interactively or as a preprocessor for compiled code.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> Jon Harrop schrieb:
>>> That is already a lot more than a "couple of macros" and it is still a
>>> long way from the functionality provided by the pattern matchers bundled
>>> with any of the languages I listed.
>> A complete pattern matcher will be several screens full of code, because
>> it really isn't the easiest thing to do.
>
> The pattern matchers in ML compilers are thousands of lines of code, yes.
I suppose that a good amount of this code is used for efficiency?
And I further suppose that the PM is written in ML itself - so abstract
programming techniques were used that wouldn't be available in low level
langs like Pascal or C, yes?
>> The good thing is that it can
>> be added to lisp as a library, without changing the sources to the
>> compiler.
>
> You can get the semantics but not the performance because ML pattern
> matchers can leverage the compiler's internal run-time representations of
> values.
I see. In Lisp the macro can do compile time optimizations, so a PM
could have a real good performance that should not be too far away.
Andr�
--
On Sun, 10 Dec 2006 09:16:35 +0100, Jon Harrop <···@ffconsultancy.com>
wrote:
> Wolfram Fenske wrote:
>> But seriously... All the interesting features that haven't originated
>> from
>> Lisp (e. g. OO from Smalltalk) could in turn easily be implemented in
>> Lisp
>> with a couple of macros.
>
> I was under the impression that CLOS was non-trivial to write. There are
> many other interesting features that haven't originated from Lisp (e.g.
> pattern matching in SML, OCaml, Haskell, F#, Mathematica, ...) that
> cannot
> be implemented easily in Lisp because they are intrinsically complicated.
>
?! Read you history.
Maxima was developed originally back in the 1960's.
It was the fist algebra system capable of symbolic algebra.
It used pattern matching. And it was written in Lisp.
When Stephen Wolfram wrote Mathematica he had been a developer of
Maxima for several years. This is where he learnt the tools of
the trade including how pattern matching worked.
Well the code is open-source now so why don't you just take a look
at how this can be achieved in Lisp.
http://maxima.sourceforge.net/download.shtml
OK so you would probably want a library instead of hard-coding it
every time..
"Paradigms in AI Programming" (PAIP) by Peder Norvig,
or "ANSI Common Lisp" by Paul Graham provide examples of this.
(With source code freely available))
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
David Lees wrote:
> ········@gmail.com wrote:
>
>> Okay, since everyone ignored the FAQ, I guess I can too...
>>
>> Mark Tarver wrote:
>>
>>> How do you compare Python to Lisp? What specific advantages do you
>>> think that one has over the other?
>>
>>
>> (Common) Lisp is the only industrial strength language with both pure
>> compositionality and a real compiler. What Python has is stupid slogans
>> ("It fits your brain." "Only one way to do things.") and an infinite
>> community of flies that, for some inexplicable reason, believe these
>> stupid slogns. These flies are, however, quite useful because they
>> produce infinite numbers of random libraries, some of which end up
>> being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
>> is rapidly replacing Perl, and Ruby is simultaneously and even more
>> rapidly replacing Python. Each is closer to Lisp than the last; the
>> world is returning to Lisp and is dragging the flies with it.
>> Eventually the flies will descend upon Lisp itself and will bring with
>> them their infinite number of random libraries, and then things will be
>> where they should have been 20 years ago, but got sidetracked by Tcl
>> and other line noise.
>>
>
> Hmmm. The last time I fooled around with Lisp was 1966 from the Lisp
> 1.5 Manual Published by MIT in cloth. It was interesting and different
> from the other languages I was using, Algol 60, Basic and Macro
> assembler for the GE-235 and GE-635. When I read some of the over the
> top type hype by Lisp enthusiasts (like the stuff above) it feels like a
> flash back to the mid 60's.
Not sure I understand why, unless you mean folks were raving about Lisp
in the 60s. Today's raving is about a much different language, though
the core elegance remains, and is as much about the contrast with other
languages as it is about the pleasure of Lisp itself. Those raving about
Lisp are quite accomplished at all those other languages, and know about
what they are talking. I doubt the Pythonistas weighing in on this
thread ever got far at all with Lisp, so... should they really be
offering comparative analysis?
> Personally, I never like Lisp syntax;
> Clearly some people, some fanatic judging by this thread :) think easily
> in prefix. I am not one of them.
Yeah, you are, you just did not use it heads down for a month. The way
to tell if you spent enough time on Lisp is to look at Lisp code. If you
see any parentheses, you have not spent enough time. They disappear in a
month.
The typical Pythonista values clean code but trembles in the face of
macros, which exist to hide boilerplate. That means the only thing
showing in any given block of code is exactly the interesting variable
and function names. Talk about readability.
> Computer languages are tools and
> everyone should pick the ones that they are most comfortable and
> productive with.
No, languages are not interchangeable. Python is a fine language, but
Lisp is much more expressive/powerful.
>
> Six years ago, when I drifted back into programming, I had to learn
> about Object Oriented programming and C++. I used Python as a means to
> update my programming skills (limited though they are) by 30 years or
> so. It was a wonderful intro to OO and served me well. I ended up
> writing all kinds of little things for work (simple HTTP servers for
> load testing, ECAD hacks for the ASIC guys, even a register level chip
> simulator) Even better, I find it a pleasure to write small utilities,
> to prototype C code and generally do things quickly. I use it by choice
> to get things done, not because it is mandated. At my current job as a
> Systems Engineer for a large aerospace firm, I do not program daily, but
> when I need to write a quick hack, I always use Python.
Much of Lisp's power would be lost on a non-programmer, but Lisp might
make a programmer out of a non-programmer if they had it in them. You
might have the right language for you because what Python does have is
lotsa libraries, and if you are just hacking scripts to glue together
libraries the expressiveness of Lisp is more than offset by the better
library support in Python.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> Not sure I understand why, unless you mean folks were raving about
> Lisp in the 60s. Today's raving is about a much different language,
> though the core elegance remains, and is as much about the contrast
> with other languages as it is about the pleasure of Lisp itself. Those
> raving about Lisp are quite accomplished at all those other languages,
> and know about what they are talking. I doubt the Pythonistas weighing
> in on this thread ever got far at all with Lisp, so... should they
> really be offering comparative analysis?
I've used and implemented Lisp but am not a real expert. Some other
Python newsgroup regulars are very knowledgeable (more than me) about
it. Peter Norvig (author of that comparison page) wrote a Lisp book,
if I remember correctly.
> > Personally, I never like Lisp syntax; Clearly some people, some
> > fanatic judging by this thread :) think easily in prefix. I am not
> > one of them.
The syntax is a pretty superficial thing. The reaction from outsiders
to Lisp's parentheses and Python's indentation-based structure is
about the same. You get used to it either way.
> The typical Pythonista values clean code but trembles in the face of
> macros, which exist to hide boilerplate. That means the only thing
> showing in any given block of code is exactly the interesting variable
> and function names. Talk about readability.
There is just not that much boilerplate in Python code, so there's
not so much need to hide it.
> Much of Lisp's power would be lost on a non-programmer, but Lisp might
> make a programmer out of a non-programmer if they had it in them. You
> might have the right language for you because what Python does have is
> lotsa libraries, and if you are just hacking scripts to glue together
> libraries the expressiveness of Lisp is more than offset by the better
> library support in Python.
Python is more expressive than Lisp in the sense that its built-in
datatypes and simple syntax for using them has to be done through
kludgy macros and libraries with Lisp. I would say Lisp's facilities
for developing very large programs are better, and (for now) Lisp has
much more serious compilers. See the PyPy project for what's
happening in that direction with Python.
Paul Rubin <·············@NOSPAM.invalid> writes:
> There is just not that much boilerplate in Python code, so there's
> not so much need to hide it.
Well, of course there is. There are always going to be patterns in
the code you write that could be collapsed. Language has nothing to
do with it; Lisp without macros would still be susceptible to
boilerplate.
Here's a concrete example:
(let ((control-code (read-next-control-code connection)))
(ecase control-code
(+break+
(kill-connection connection)
(throw :broken-by-client))
(+status+
(send-status-summary connection))
((+noop+ +keep-alive+))))
;; +X+ indicates a constant
The standard ECASE macro encapsulates this pattern: Compare the
variable control-code to +break+. If the two are EQL, then run the
code provided in the +break+ clause. Likewise for +status+. In the
last clause, the test-form is a list, so the generated code will
compare control-code to either +noop+ or +keep-alive+. If it is EQL
to either, it runs the body of that clause, which happens to be blank
here. The E in ECASE stands for "error," so if control-code doesn't
match any of these choices, the generated code will signal an error
with the following text "CONTROL-CODE fell through ECASE expression;
was not one of: +BREAK+, +STATUS+, +NOOP+, +KEEP-ALIVE+". All of that
boilerplate is handled by the macro. In Python, I would need to do
something like:
control_code = connection.read_next_control_code()
if control_code == +break+:
connection.kill()
throw blah
else if control_code == +status+:
connection.send_status_summary()
else if control_code == +noop+ || control_code == +keep_alive+:
else:
error "CONTROL_CODE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"
To change what control codes you want to check for, you need to add
conditionals for them and keep the error text relevant. The reality
is that a computer could be doing this for you, leaving your code
simpler and more easily changed.
Now someone will complain that the ECASE code means nothing until I
understand ECASE. Yep. But once you understand ECASE, you can look
at that code and, *at a glance*, see how control flows through it. In
the equivalent Python code, I need to walk through each conditional
and make sure they're all following the same pattern. If you're not
convinced, extend the example to 12 different control codes.
Note also that ECASE is just expanding to the COND conditional. There
is nothing mind-bending (or even mind-twisty) going on inside of it.
It's simply a way of expressing a common syntactic pattern in
higher-level terms. To prove that macros are not the frightening
beasts you guys are making them out to be:
CL-USER 13 > (let ((*print-case* :downcase))
(pprint (macroexpand '(ecase control-code
(+break+
(kill-connection connection)
(throw :broken-by-client))
(+status+
(send-status-summary connection))
((+noop+ +keep-alive+))))))
(let ((#:g17558 control-code))
(case #:g17558
(+break+ (kill-connection connection) (throw :broken-by-client))
(+status+ (send-status-summary connection))
((+noop+ +keep-alive+))
(otherwise (conditions::ecase-error #:g17558 '(+break+ +status+ (+noop+ +keep-alive+))))))
If you treat the #:G17548 as just a weirdly-named variable, you can
see that the code is just expanding into the standard CASE macro. I
can in turn expand this CASE to:
CL-USER 14 > (let ((*print-case* :downcase))
(pprint (macroexpand '(case #:g17558
(+break+
(kill-connection connection) (throw :broken-by-client))
(+status+
(send-status-summary connection))
((+noop+ +keep-alive+))
(otherwise (conditions::ecase-error #:g17558 '(+break+ +status+ (+noop+ +keep-alive+))))))))
(let ((#:g17559 #:g17558))
(cond ((eql '+break+ #:g17559) (kill-connection connection) (throw :broken-by-client))
((eql '+status+ #:g17559) (send-status-summary connection))
((or (eql '+noop+ #:g17559) (eql '+keep-alive+ #:g17559)) nil)
(t (conditions::ecase-error #:g17558 '(+break+ +status+ (+noop+ +keep-alive+))))))
COND is the Lisp conditional form.
As you can see, ECASE does not blow your mind, but simply names and
standardizes a common pattern of code. It expands into standard
macros. And ECASE is so easy to write that most Lisp programmers have
extended versions of it in their personal libraries. And most of
these are named GENERIC-CASE or STRING-CASE, etc. and most expand into
standard COND, CASE or ECASE macros. We are not going crazy and
definining new langauges; we are simply extending Lisp to meet our
needs, by creating macros that abstract common patterns. In many
cases, the macros resemble standard, well-known Lisp macros even down
to their names.
(In the real world, I might use CLOS's eql-specifiers to define
handlers for each kind of control code. But Python doesn't have
anything analagous to that, so I'll be polite and pretend I have to
use ECASE).
On Sat, 09 Dec 2006 14:57:08 -0500, Bill Atkins wrote:
> Paul Rubin <·············@NOSPAM.invalid> writes:
>
>> There is just not that much boilerplate in Python code, so there's
>> not so much need to hide it.
>
> Well, of course there is. There are always going to be patterns in
> the code you write that could be collapsed. Language has nothing to
> do with it; Lisp without macros would still be susceptible to
> boilerplate.
>
> Here's a concrete example:
>
> (let ((control-code (read-next-control-code connection)))
> (ecase control-code
> (+break+
> (kill-connection connection)
> (throw :broken-by-client))
> (+status+
> (send-status-summary connection))
> ((+noop+ +keep-alive+))))
> ;; +X+ indicates a constant
Eight lines, excluding the comment, and it doesn't handle the case where
control-code is not one of +break+, +status+, +noop+ or +keep-alive+,
although the ecase macro does. And how many lines of code is ecase?
> All of that
> boilerplate is handled by the macro. In Python, I would need to do
> something like:
>
> control_code = connection.read_next_control_code()
> if control_code == +break+:
> connection.kill()
> throw blah
> else if control_code == +status+:
> connection.send_status_summary()
> else if control_code == +noop+ || control_code == +keep_alive+:
> else:
> error "CONTROL_CODE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"
Your Python syntax is rather wonky, but that's incidental.
Nine lines, including handling the case where control_code is none of the
four constants. Ten if you add the "pass" statement that it actually
needs. And it is completely self-contained, with no external functions or
macros to understand.
Saving one line of code, at the expense of having another block of code to
write or understand -- is that really the best example of what macros are
used for in practice? You don't really save writing any boilerplate code,
except for else clause, unless you're claiming that "if" and "elif" is
boilerplate. Fine, you claim them as boilerplate. I'm going to claim all
those unnecessary brackets as boilerplate.
Yes, I know the parser needs them. But as so many people keep telling me,
once you've been writing Lisp code for a month, you don't even notice the
brackets. That makes them unnecessary for the developer, and therefore
something the computer should handle on its own. You've already split
expressions with whitespace, why should you have to use brackets as well?
That's just boilerplate.
Okay, I'm impressed that ecase can pick up on the four constants being
tested against, and feed their names (rather than merely their values)
into an error message. Python has nothing like that, and if you only have
three or four things to test against, *and* they have names, that could be
a useful thing to do. And if I've understood correctly, that's more a
feature of Lisp's symbols than of macros.
But if you're testing against fifty different values, well, is it really
useful for your error message to list all fifty names? Or do you have
another macro ecase-with-lots-of-tests?
And how does ecase handle the more general case of testing against
calculated objects rather than named constants? Or is there yet another
macro for that?
If that's the best example of what macros can be used for, frankly I'm
unimpressed. Yes, I can see some benefit. But I don't see that the benefit
is worth the added complexity. Maybe there are more complex tasks that
macros are better suited for.
--
Steven.
Steven D'Aprano wrote:
> If that's the best example of what macros can be used for, frankly I'm
> unimpressed.
We're shocked.
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> Steven D'Aprano wrote:
>> If that's the best example of what macros can be used for, frankly I'm
>> unimpressed.
>
> We're shocked.
We are.
(Counting lines? Come on.)
Ken Tilton <·········@gmail.com> writes:
> Steven D'Aprano wrote:
> > If that's the best example of what macros can be used for, frankly I'm
> > unimpressed.
>
> We're shocked.
Don't anyone tell him about LOOP.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> On Sat, 09 Dec 2006 14:57:08 -0500, Bill Atkins wrote:
>
>> Paul Rubin <·············@NOSPAM.invalid> writes:
>>
>>> There is just not that much boilerplate in Python code, so there's
>>> not so much need to hide it.
>>
>> Well, of course there is. There are always going to be patterns in
>> the code you write that could be collapsed. Language has nothing to
>> do with it; Lisp without macros would still be susceptible to
>> boilerplate.
>>
>> Here's a concrete example:
>>
>> (let ((control-code (read-next-control-code connection)))
>> (ecase control-code
>> (+break+
>> (kill-connection connection)
>> (throw :broken-by-client))
>> (+status+
>> (send-status-summary connection))
>> ((+noop+ +keep-alive+))))
>> ;; +X+ indicates a constant
>
> Eight lines, excluding the comment, and it doesn't handle the case where
> control-code is not one of +break+, +status+, +noop+ or +keep-alive+,
> although the ecase macro does. And how many lines of code is ecase?
Doesn't matter because it only has to be written once. For Common
Lisp it's already part of the language. It would of course be bad to
write a macro if pattern comes up only a few times. But that's not
how macros are used.
>> All of that boilerplate is handled by the macro. In Python, I
>> would need to do something like:
>>
>> control_code = connection.read_next_control_code()
>> if control_code == +break+:
>> connection.kill()
>> throw blah
>> else if control_code == +status+:
>> connection.send_status_summary()
>> else if control_code == +noop+ || control_code == +keep_alive+:
>> else:
>> error "CONTROL_CODE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"
[...]
> Saving one line of code, at the expense of having another block of code to
> write or understand -- is that really the best example of what macros are
> used for in practice? You don't really save writing any boilerplate code,
> except for else clause, unless you're claiming that "if" and "elif" is
> boilerplate.
No, all the "if control_code == SOME_STATUS:" are boilerplate:
--8<---------------cut here---------------start------------->8---
if control_code == STATUS1:
action_1
else if control_code == STATUS2:
action_2
...
else if control_code == STATUSN:
action_n
else:
Exception(...)
--8<---------------cut here---------------end--------------->8---
The pattern is that one value is compared against several possible
values and depending on which one matches, the appropriate action is
taken. Common Lisp's CASE and ECASE macros and the "switch"
statements of C or Java make this pattern explicit and arguably easier
to recognize. In Python you have to type it out yourself.
[...]
> Okay, I'm impressed that ecase can pick up on the four constants being
> tested against, and feed their names (rather than merely their values)
> into an error message. Python has nothing like that, and if you only have
> three or four things to test against, *and* they have names, that could be
> a useful thing to do. And if I've understood correctly, that's more a
> feature of Lisp's symbols than of macros.
>
> But if you're testing against fifty different values, well, is it really
> useful for your error message to list all fifty names? Or do you have
> another macro ecase-with-lots-of-tests?
Now you're being silly.
[...]
> If that's the best example of what macros can be used for, frankly I'm
> unimpressed. Yes, I can see some benefit. But I don't see that the benefit
> is worth the added complexity. Maybe there are more complex tasks that
> macros are better suited for.
Here's another example. I had to use a database in one of my Python
programs. Everytime I used the database I had write something like
this:
--8<---------------cut here---------------start------------->8---
self.lock.acquire()
try:
connection = sqlite.connect(self.dbFile)
connection.row_factory = dictFactory
try:
# do something with the connection
finally:
connection.close()
finally:
self.lock.release()
--8<---------------cut here---------------end--------------->8---
In Lisp, I could just write a macro "WITH-CONNECTION" that takes the
name of the connection variable and the code for "do something with
the connection" as arguments. Actually, I ended up writing something
like it as a function in Python:
--8<---------------cut here---------------start------------->8---
def withConnection(self, fun):
self.lock.acquire()
try:
connection = sqlite.connect(self.dbFile)
connection.row_factory = dictFactory
try:
return fun(connection)
finally:
connection.close()
finally:
self.lock.release()
--8<---------------cut here---------------end--------------->8---
What would have been the body in the Lisp macro has to be supplied as
function. It's basically a macro, but it still requires more typing
because you have to define a local function eveytime it is used.
Also, there are things you can do with Lisp macros where this
mechanism isn't applicable.
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
"Wolfram Fenske" <·····@gmx.net> writes:
> In Lisp, I could just write a macro "WITH-CONNECTION" that takes the
> name of the connection variable and the code for "do something with
> the connection" as arguments. Actually, I ended up writing something
> like it as a function in Python:
>
> --8<---------------cut here---------------start------------->8---
> def withConnection(self, fun):
> self.lock.acquire() # ...
Do you know about Python's "with" statement? You'd define a class for
those db connections, that acquire the lock on entry, and release it
on exit.
Paul Rubin <·············@NOSPAM.invalid> writes:
> "Wolfram Fenske" <·····@gmx.net> writes:
>> In Lisp, I could just write a macro "WITH-CONNECTION" that takes the
>> name of the connection variable and the code for "do something with
>> the connection" as arguments. Actually, I ended up writing something
>> like it as a function in Python:
>>
>> --8<---------------cut here---------------start------------->8---
>> def withConnection(self, fun):
>> self.lock.acquire() # ...
>
> Do you know about Python's "with" statement? You'd define a class for
> those db connections, that acquire the lock on entry, and release it
> on exit.
Yes, I wrote about it in another post. It was introduced in Python
2.5. And if it hadn't been I'd still have to write code like this.
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
"Wolfram Fenske" <·····@gmx.net> writes:
> Yes, I wrote about it in another post. It was introduced in Python
> 2.5. And if it hadn't been I'd still have to write code like this.
You could do something with decorators that's not too bad. You'd end
up writing:
@withConnection
def some_func():
do_whatever_stuff ()
Paul Rubin <·············@NOSPAM.invalid> writes:
> "Wolfram Fenske" <·····@gmx.net> writes:
>> Yes, I wrote about it in another post. It was introduced in Python
>> 2.5. And if it hadn't been I'd still have to write code like this.
>
> You could do something with decorators that's not too bad. You'd end
> up writing:
>
> @withConnection
> def some_func():
> do_whatever_stuff ()
Yes, now I can. But I had to wait until Python 2.4 to be able to
that. What I like so much about Lisp macros is that they allow me to
make these changes myself.
--
Wolfram Fenske
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?
"Wolfram Fenske" <·····@gmx.net> writes:
> Paul Rubin <·············@NOSPAM.invalid> writes:
>
> > "Wolfram Fenske" <·····@gmx.net> writes:
> >> Yes, I wrote about it in another post. It was introduced in Python
> >> 2.5. And if it hadn't been I'd still have to write code like this.
> >
> > You could do something with decorators that's not too bad. You'd end
> > up writing:
> >
> > @withConnection
> > def some_func():
> > do_whatever_stuff ()
>
> Yes, now I can. But I had to wait until Python 2.4 to be able to
> that. What I like so much about Lisp macros is that they allow me to
> make these changes myself.
Besides, who wants to write production code in a language that keeps
changing? It's enough work just keeping up with new libraries.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
David Steuber <·····@david-steuber.com> writes:
> Besides, who wants to write production code in a language that keeps
> changing? It's enough work just keeping up with new libraries.
BTDT. Perl, 10 years ago. And no, don't want to do it again :-(
--
(espen)
On Sun, 10 Dec 2006 00:03:11 -0800, Wolfram Fenske wrote:
[snip]
> Doesn't matter because it only has to be written once. For Common
> Lisp it's already part of the language. It would of course be bad to
> write a macro if pattern comes up only a few times. But that's not how
> macros are used.
So you say. I've heard it be said that anytime you do anything more than
once, you should abstract it away into a function or macro.
Of course, that was the same person who told me that no function should
ever be more than five lines of code, so perhaps you might consider him
prone to over-stating his case.
[snip]
>> Saving one line of code, at the expense of having another block of code
>> to write or understand -- is that really the best example of what
>> macros are used for in practice? You don't really save writing any
>> boilerplate code, except for else clause, unless you're claiming that
>> "if" and "elif" is boilerplate.
>
> No, all the "if control_code == SOME_STATUS:" are boilerplate:
You still have to include SOME_STATUS in the Lisp example. Calling it
boilerplate for Python is unfair.
[snip]
> The pattern is that one value is compared against several possible
> values and depending on which one matches, the appropriate action is
> taken. Common Lisp's CASE and ECASE macros and the "switch" statements
> of C or Java make this pattern explicit and arguably easier to
> recognize. In Python you have to type it out yourself.
Yes, Python doesn't have a case/switch statement. It may get one in the
future. There are advantages to a case statement, but they aren't
overwhelming, and there are costs to implementing it.
>> Okay, I'm impressed that ecase can pick up on the four constants being
>> tested against, and feed their names (rather than merely their values)
>> into an error message. Python has nothing like that, and if you only
>> have three or four things to test against, *and* they have names, that
>> could be a useful thing to do. And if I've understood correctly, that's
>> more a feature of Lisp's symbols than of macros.
>>
>> But if you're testing against fifty different values, well, is it
>> really useful for your error message to list all fifty names? Or do you
>> have another macro ecase-with-lots-of-tests?
>
> Now you're being silly.
How am I being silly? Do you not believe that people write case blocks
with fifty tests? Okay, how about twenty? Ten? Eight?
One of the advantages of Lisp's ecase macro was specifically stated to be
that it gave you the error message for free, without the coder having to
add new terms to the message as they add new comparisons. Why is it
"silly" to question whether that feature is always useful?
[snip]
> Here's another example. I had to use a database in one of my Python
> programs. Everytime I used the database I had write something like
> this:
[snip]
> In Lisp, I could just write a macro "WITH-CONNECTION" that takes the
> name of the connection variable and the code for "do something with the
> connection" as arguments. Actually, I ended up writing something like
> it as a function in Python:
>
> --8<---------------cut here---------------start------------->8---
> def withConnection(self, fun):
> self.lock.acquire()
> try:
> connection = sqlite.connect(self.dbFile)
> connection.row_factory = dictFactory
> try:
> return fun(connection)
> finally:
> connection.close()
> finally:
> self.lock.release()
> --8<---------------cut here---------------end--------------->8---
>
> What would have been the body in the Lisp macro has to be supplied as
> function. It's basically a macro, but it still requires more typing
> because you have to define a local function eveytime it is used.
Hang on -- why can't you just call the function again?
If you're talking about calling withConnection with different functions,
then of course you have to define a different function each time. How is
that different from the Lisp macro? You still have to write that.
And these functions -- shouldn't they be tested? If they were just
anonymous blocks, won't they be hard to test? These aren't rhetorical
questions.
--
Steven.
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> How am I being silly? Do you not believe that people write case blocks
> with fifty tests? Okay, how about twenty? Ten? Eight?
You should check out generic functions in CLOS. Rather than writing a
ridiculously long case block, you can use EQL specialized functions.
It's a great way to do dispatch.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>> something like:
>>
>> control_code = connection.read_next_control_code()
>> if control_code == +break+:
>> connection.kill()
>> throw blah
>> else if control_code == +status+:
>> connection.send_status_summary()
>> else if control_code == +noop+ || control_code == +keep_alive+:
>> else:
>> error "CONTROL_CODE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"
>
> Your Python syntax is rather wonky, but that's incidental.
What is wonky about it? The use of +foo+ symbols from the Lisp? Is
there some particular bit of wonkiness you can point out that will
make me think you've done anything but intentionally misunderstand my
post?
> Nine lines, including handling the case where control_code is none of the
> four constants. Ten if you add the "pass" statement that it actually
> needs. And it is completely self-contained, with no external functions or
> macros to understand.
>
> Saving one line of code, at the expense of having another block of code to
> write or understand -- is that really the best example of what macros are
> used for in practice? You don't really save writing any boilerplate code,
> except for else clause, unless you're claiming that "if" and "elif" is
> boilerplate. Fine, you claim them as boilerplate. I'm going to claim all
> those unnecessary brackets as boilerplate.
We're not counting lines here, you goon. We're talking about how
expressive constructs are and how closely they match your concept of
what you want to do. The conditional example is lower-level; you're
talking to the interpreter instead of saying what you want to achieve.
You're having to repeat things because that's what the language asks
of you, instead of describing in a higher-level way what you're
actually doing.
> Yes, I know the parser needs them. But as so many people keep telling me,
> once you've been writing Lisp code for a month, you don't even notice the
> brackets. That makes them unnecessary for the developer, and therefore
> something the computer should handle on its own. You've already split
> expressions with whitespace, why should you have to use brackets as well?
> That's just boilerplate.
This simply means that the parentheses do not stand out. It doesn't
mean that they *literally* cease to become visible (unless I have
perhaps missed out on Lisp enlightenment).
Obviously, this doesn't mean that they are "unnecessary." They are
necessary to give Lisp its regular structure, which 1) makes macros
possible, 2) allows easy movement through and automatic indentation of
code and 3) is aesthetically pleasant, which leads to easier
maintenance. Brackets are no more boilerplate than the significant
whitespace in Python is boilerplate (that is, they're not boilerplate
at all).
> Okay, I'm impressed that ecase can pick up on the four constants being
> tested against, and feed their names (rather than merely their values)
> into an error message. Python has nothing like that, and if you only have
> three or four things to test against, *and* they have names, that could be
> a useful thing to do. And if I've understood correctly, that's more a
> feature of Lisp's symbols than of macros.
But you haven't understood it correctly, of course. The only reason
this works is that the macro is passed the unevaluated code, which
still has the original symbols that the programmer used. It can
insert these into the generated code as it pleases. I feel that
should be clear to someone who claims to know as much Lisp as you do.
> But if you're testing against fifty different values, well, is it really
> useful for your error message to list all fifty names? Or do you have
> another macro ecase-with-lots-of-tests?
Is it really useful? Yes, it is.
> If that's the best example of what macros can be used for, frankly I'm
> unimpressed. Yes, I can see some benefit. But I don't see that the benefit
> is worth the added complexity. Maybe there are more complex tasks that
> macros are better suited for.
Did you read the DEFINE-BINARY-CLASS macro I mentioned elsewhere?
Where did you get the notion that ECASE was the best example of where
macros can be used? Why am I responding to another of your absurd
posts?
On Sun, 10 Dec 2006 03:18:07 -0500, Bill Atkins wrote:
> We're not counting lines here, you goon. We're talking about how
> expressive constructs are and how closely they match your concept of
> what you want to do. The conditional example is lower-level; you're
> talking to the interpreter instead of saying what you want to achieve.
> You're having to repeat things because that's what the language asks
> of you, instead of describing in a higher-level way what you're
> actually doing.
To be a little provocative, I wonder if the idea that you're "talking to
the interpreter" doesn't apply more to lisp than to python; you can have
any syntax you like, as long as it looks like an AST.
One of the things I've always found off-putting about lisp as that all the
syntax looks the same. In Algol-derived languages, each syntactic
construct has a fairly distinctive appearance, so when, for instance, I
encounter a for loop, I can quickly recognize that that's what it is, and
bracket out the "scaffolding" and pick out the details that interest me.
With lisp, I can't do that, I have to read through the sexp, decide on
what syntax it is, and then remind myself where to look for the relevant
specific details.
Now, this might well be just due to my comparative lack of familiarity
with lisp; I'd be interested to hear if you lisp people find different
lisp constructs as visually distinctive as constructs in python (or other
similar languages). But I think what people are getting at when they
complain about "all the brackets" in lisp may actually be this issue of
a visual distinction between different constructs (this is also a reason
why having a limited number of syntactic constructs can be helpful - there
are a probably a limited number of stereotypical layouts a programmer can
keep in their mind at once).
I V schrieb:
> One of the things I've always found off-putting about lisp as that all the
> syntax looks the same. In Algol-derived languages, each syntactic
> construct has a fairly distinctive appearance, so when, for instance, I
> encounter a for loop, I can quickly recognize that that's what it is, and
> bracket out the "scaffolding" and pick out the details that interest me.
I guess towards the intentional programming guys around Charles Simonyi
also all Algol languages look roughly the same. I remember how annoyed
I was as a math student that no PL supported my familiar notations
directly. I don't even try to speculate what chemists think about ASCII.
I V wrote:
> One of the things I've always found off-putting about lisp as that all the
> syntax looks the same. In Algol-derived languages, each syntactic
> construct has a fairly distinctive appearance, so when, for instance, I
> encounter a for loop, I can quickly recognize that that's what it is, and
> bracket out the "scaffolding" and pick out the details that interest me.
> With lisp, I can't do that, I have to read through the sexp, decide on
> what syntax it is, and then remind myself where to look for the relevant
> specific details.
May you have tried the wrong Lisp dialects so far:
(loop for i from 2 to 10 by 2
do (print i))
This is Common Lisp. (Many Lisp and Scheme tutorials teach you that you
should implement this using recursion, but you really don't have to. ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> May you have tried the wrong Lisp dialects so far:
>
> (loop for i from 2 to 10 by 2
> do (print i))
The loop language is so complicated and confusing that I never
bothered trying to learn it. I always used simpler primitives to
write loops and it was always enough.
> This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
> you should implement this using recursion, but you really don't have
> to. ;)
You can't really use that much recursion in Lisp because of the lack
of guaranteed TCO. I think that makes it reasonable to say that
Scheme is a functional language but Lisp is not. ("Functional" = it's
reasonable to code in a style where the only way to connect variables
to values is lambda binding (maybe through syntax sugar), so all loops
are implemented with recursion).
Paul Rubin wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> May you have tried the wrong Lisp dialects so far:
>>
>> (loop for i from 2 to 10 by 2
>> do (print i))
>
> The loop language is so complicated and confusing that I never
> bothered trying to learn it.
You can start with loop by using only the simple and straightforward
constructs, and slowly move towards the more complicated cases when
necessary. The nice thing about loop is that with some practice, you can
write code that more or less reads like English.
> I always used simpler primitives to
> write loops and it was always enough.
No language construct is so simple that it cannot be replaced with a
combination of simpler primitives.
>> This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
>> you should implement this using recursion, but you really don't have
>> to. ;)
>
> You can't really use that much recursion in Lisp because of the lack
> of guaranteed TCO. I think that makes it reasonable to say that
> Scheme is a functional language but Lisp is not. ("Functional" = it's
> reasonable to code in a style where the only way to connect variables
> to values is lambda binding (maybe through syntax sugar), so all loops
> are implemented with recursion).
All Common Lisp implementations that I am aware of provide ways to
enable TCO, so it's definitely possible to program in a functional style
if you want to. It's just that the ANSI Common Lisp specification
doesn't guarantee this, but this doesn't matter much. The only downside
is that there is no common interface to enable TCO - that would indeed
be an improvement. The upside is that you can switch TCO off if you want
to, which for example may improve debugging.
It's correct that Scheme has a stronger tendency towards functional
programming than Lisp has.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> You can start with loop by using only the simple and straightforward
> constructs, and slowly move towards the more complicated cases when
> necessary. The nice thing about loop is that with some practice, you
> can write code that more or less reads like English.
Yeah, but I'd also get English-like imprecision. Anyway, If I wanted
to write code that reads like English, I'd write in Cobol.
> All Common Lisp implementations that I am aware of provide ways to
> enable TCO, so it's definitely possible to program in a functional
> style if you want to. It's just that the ANSI Common Lisp
> specification doesn't guarantee this,
Yes; I'd rather go by what the standard says than rely on
implementation-dependent hacks.
Paul Rubin wrote:
> Pascal Costanza <··@p-cos.net> writes:
<snip>
> Yes; I'd rather go by what the standard says than rely on
> implementation-dependent hacks.
But in that case what do you call Python? The whole language has no
standard - is it an "implementation dependent hack"?
Standards are useful, but they are not the beginning and end of
programming.
"Rob Thorpe" <·······@realworldtech.com> writes:
> > Yes; I'd rather go by what the standard says than rely on
> > implementation-dependent hacks.
>
> But in that case what do you call Python? The whole language has no
> standard - is it an "implementation dependent hack"?
This is one of my perpetual complaints about Python. It does have a
reference manual and library manual, but these manuals are full of
gaps, and in practice one does go by the implementation. CLTL2 is a
model of precision and thoroughness compared with any document that's
ever been written about Python.
Paul Rubin <·············@NOSPAM.invalid> wrote:
+---------------
| CLTL2 is a model of precision and thoroughness compared
| with any document that's ever been written about Python.
+---------------
It's a great book, but one needs to be clear that CLtL2 is *not*
the same as the ANSI Common Lisp standard, but was the author's
best guess at the time as to where the standardization effort was
going after CLtL1. You may find the following useful in marking up
your copy of CLtL2 to be closer to the final standard:
http://cbbrowne.com/info/commonlisp.html#AEN10499
http://bc.tech.coop/cltl2-ansi.htm
But note the caveat therein:
A doctored CLTL2 is NOT the ANSI standard. In fact,
this FAQ has many known but minor omissions that are
too awkward to add with pencil to CLTL2.
The Common Lisp HyperSpec (CLHS), while also not the official
ANSI standard per se, was created from "the same" TeX input as
the ANSI standard (with permission from ANSI & X3), and is the
reference most CL programmers use:
http://www.lisp.org/HyperSpec/FrontMatter/index.html
http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
For a downloadable tarball of the whole thing, there's a link near
the bottom of this page:
http://www.lispworks.com/documentation/HyperSpec/index.html
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Paul Rubin wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>You can start with loop by using only the simple and straightforward
>>constructs, and slowly move towards the more complicated cases when
>>necessary. The nice thing about loop is that with some practice, you
>>can write code that more or less reads like English.
>
>
> Yeah, but I'd also get English-like imprecision. Anyway, If I wanted
> to write code that reads like English, I'd write in Cobol.
That was my stance until.... <g>
There /is/ a second Lispy syntax for LOOP, btw. But the goofier syntax
is also where lies part of the "win", so learn that.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Paul Rubin wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> You can start with loop by using only the simple and straightforward
>> constructs, and slowly move towards the more complicated cases when
>> necessary. The nice thing about loop is that with some practice, you
>> can write code that more or less reads like English.
>
> Yeah, but I'd also get English-like imprecision. Anyway, If I wanted
> to write code that reads like English, I'd write in Cobol.
That's the neat thing in Lisp: You can stay in Lisp if you want to write
code in a different style. No need to switch your whole tool chain.
>> All Common Lisp implementations that I am aware of provide ways to
>> enable TCO, so it's definitely possible to program in a functional
>> style if you want to. It's just that the ANSI Common Lisp
>> specification doesn't guarantee this,
>
> Yes; I'd rather go by what the standard says than rely on
> implementation-dependent hacks.
You shouldn't limit yourself to what some standard says.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Paul Rubin wrote:
>> Yes; I'd rather go by what the standard says than rely on
>> implementation-dependent hacks.
>
> You shouldn't limit yourself to what some standard says.
You shouldn't ignore previous work and standards can embody decades of
programming language research.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Pascal Costanza wrote:
> > Paul Rubin wrote:
> >> Yes; I'd rather go by what the standard says than rely on
> >> implementation-dependent hacks.
> > You shouldn't limit yourself to what some standard says.
> You shouldn't ignore previous work and standards can embody decades of
> programming language research.
Not going beyond the ANSI standard for Common Lisp would basically
require ignoring the past 12 years of programming research. But going
beyond that standard is not remotely the same thing as ignoring it,
since it explicitly provides for that possibility.
Cheers,
Pillsy
Pillsy wrote:
> But going
> beyond that standard is not remotely the same thing as ignoring it,
> since it explicitly provides for that possibility.
My point is that knocking up your own ad-hoc and informally specified
pattern matcher is not "going beyond the standard", it is most likely
ignoring decades of research...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Pillsy wrote:
> > But going beyond that standard is not remotely the same thing as
> > ignoring it, since it explicitly provides for that possibility.
> My point is that knocking up your own ad-hoc and informally specified
> pattern matcher is not "going beyond the standard", it is most likely
> ignoring decades of research...
Very possibly.
But I don't see why the same is going to be true of a vendor-provided
extension or third-party library that does pattern matching.
Cheers,
Pillsy
Pillsy schrieb:
> Jon Harrop wrote:
>
>> Pillsy wrote:
>
>>> But going beyond that standard is not remotely the same thing as
>>> ignoring it, since it explicitly provides for that possibility.
>
>> My point is that knocking up your own ad-hoc and informally specified
>> pattern matcher is not "going beyond the standard", it is most likely
>> ignoring decades of research...
>
> Very possibly.
>
> But I don't see why the same is going to be true of a vendor-provided
> extension or third-party library that does pattern matching.
You don't need a vendor for adding that.
It might be possible that your PM is 30% less efficient than those made
by experts, but in the end you should be able to come up with something
very useful.
Decades of research helped to boost efficiency another 6%.
Andr�
--
Pillsy wrote:
> But I don't see why the same is going to be true of a vendor-provided
> extension or third-party library that does pattern matching.
Absolutely, my objection is only that Lisper's perceive these things to be
easy when they're not, e.g. "anything interesting from any other language
can be done in 2 Lisp macros".
If these things are done well in Lisp then that's great. There is still the
problem that the userbase will be tiny, e.g. there are probably far more
people using ML, Haskell or Mathematica pattern matchers than any given
Lisp pattern matcher.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
* Jon Harrop <························@ptn-nntp-reader02.plus.net> :
| If these things are done well in Lisp then that's great. There is still the
| problem that the userbase will be tiny, e.g. there are probably far more
| people using ML, Haskell or Mathematica pattern matchers than any given
| Lisp pattern matcher.
Why should this be a problem? Unless youre delivering advertisments to
the users or selling to them as a market..
To quote Pascal Bourguignon in <··············@thalassa.informatimago.com>
who also thinks this is a `problem'
>Well there are two problems with lisp.
^^^^^^
>
>1- lisp code works. So once a library is developed, there's no much
> traffic, because there's no bug.
[...]
--
Madhu
Madhu wrote:
> * Jon Harrop <························@ptn-nntp-reader02.plus.net> :
> | If these things are done well in Lisp then that's great. There is still
> | the problem that the userbase will be tiny, e.g. there are probably far
> | more people using ML, Haskell or Mathematica pattern matchers than any
> | given Lisp pattern matcher.
>
> Why should this be a problem?
1. Size of programmer market (e.g. Qi programmers are rare compared to OCaml
programmers).
2. Size of target market for source deals (e.g. plenty of people buy my
software in source form but would any if I wrote it in Qi, for example?).
3. Reliability (more widely used software has been tested more and is likely
to be more reliable).
4. Maturity (older software has been used for longer so it is more likely to
be correct).
5. Portability (people are more likely to mimic existing systems, e.g. a lot
of OCaml code will compile and run under Windows because Microsoft just
developed a Caml-devivative called F#).
IMO, OCaml is at the limit of these things. I would not write a book "Qi for
Scientists", for example, because I don't believe enough people would buy
it. I'm only writing "F# for Scientists" because I believe F# will become
the most popular ML/Haskell/Lisp/Scheme over the next 3 years.
> Unless youre delivering advertisments to the users or selling to them as a
> market..
That's exactly what I'm doing.
> To quote Pascal Bourguignon in <··············@thalassa.informatimago.com>
> who also thinks this is a `problem'
>
>>Well there are two problems with lisp.
> ^^^^^^
>>
>>1- lisp code works. So once a library is developed, there's no much
>> traffic, because there's no bug.
> [...]
That isn't even a sentence.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop ha escrito:
> it. I'm only writing "F# for Scientists" because I believe F# will become
> the most popular ML/Haskell/Lisp/Scheme over the next 3 years.
Very interesting, it is not the firts time i read this about F#.
Jon Harrop wrote:
>
> 1. Size of programmer market (e.g. Qi programmers are rare compared to OCaml
> programmers).
>
> 2. Size of target market for source deals (e.g. plenty of people buy my
> software in source form but would any if I wrote it in Qi, for example?).
>
> 3. Reliability (more widely used software has been tested more and is likely
> to be more reliable).
>
> 4. Maturity (older software has been used for longer so it is more likely to
> be correct).
>
> 5. Portability (people are more likely to mimic existing systems, e.g. a lot
> of OCaml code will compile and run under Windows because Microsoft just
> developed a Caml-devivative called F#).
>
Well, a new language needs to start somewhere doesn't it ?
Are you saying we should stop researching new programming languages ?
Sacha
Sacha wrote:
> Well, a new language needs to start somewhere doesn't it ?
Absolutely.
> Are you saying we should stop researching new programming languages ?
Not at all. I'm saying that a bigger user base instills more confidence when
choosing a language.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> wrote:
> Sacha wrote:
> > Well, a new language needs to start somewhere doesn't it ?
>
> Absolutely.
>
> > Are you saying we should stop researching new programming languages ?
>
> Not at all. I'm saying that a bigger user base instills more confidence when
> choosing a language.
That's why everyone should eat at McDonalds, right?
That's why my teenager has my permission to engage in behavior that "all
of the other kids are doing", right?
That's why I should ditch Mac OS X and move to Windows, right?
The size of the user base has little bearing on the merits of a
language. The masses want comfort. They don't want beauty,
consistency, expressiveness, or power -- all hallmarks of the sublime
language that is Lisp.
Bob Felts ha escrito:
> Jon Harrop <···@ffconsultancy.com> wrote:
>
> > Sacha wrote:
> > > Well, a new language needs to start somewhere doesn't it ?
> >
> > Absolutely.
> >
> > > Are you saying we should stop researching new programming languages ?
> >
> > Not at all. I'm saying that a bigger user base instills more confidence when
> > choosing a language.
>
> That's why everyone should eat at McDonalds, right?
> That's why my teenager has my permission to engage in behavior that "all
> of the other kids are doing", right?
> That's why I should ditch Mac OS X and move to Windows, right?
'Average' people feel comfortable with McDonalds. I hate to eat at one,
but do not claim people does being"silly" or "mediocre". And i do not
devote my entire life to grandiloquent (unfounded) claims as
unfortunately is so usual in a subset of LISP community.
Let anyone choose.
> The size of the user base has little bearing on the merits of a
> language. The masses want comfort. They don't want beauty,
> consistency, expressiveness, or power -- all hallmarks of the sublime
> language that is Lisp.
beauty, consistency, expressiveness, power, sublime...
all of these are subjective words. Something can be beatiful for one
but ugly for other. That is consistent for one can be a mess for other,
etc.
I personally can see LISP from different perspectives and can apply all
of those words to LISP language; it is function of on what you compare
LISP.
Juan R. <··············@canonicalscience.com> wrote:
> Bob Felts ha escrito:
>
> > Jon Harrop <···@ffconsultancy.com> wrote:
> >
> > > Sacha wrote:
> > > > Well, a new language needs to start somewhere doesn't it ?
> > >
> > > Absolutely.
> > >
> > > > Are you saying we should stop researching new programming languages
> > >?
> > >
> > > Not at all. I'm saying that a bigger user base instills more
> > > confidence when choosing a language.
> >
> > That's why everyone should eat at McDonalds, right?
> > That's why my teenager has my permission to engage in behavior that "all
> > of the other kids are doing", right?
> > That's why I should ditch Mac OS X and move to Windows, right?
>
> 'Average' people feel comfortable with McDonalds. I hate to eat at one,
> but do not claim people does being"silly" or "mediocre".
There isn't a lot of difference between 'average' and 'mediocre', is
there?
And if you are able to made a better choice, isn't it somewhat silly not
to?
> And i do not devote my entire life to grandiloquent (unfounded) claims as
> unfortunately is so usual in a subset of LISP community.
Did I make any? If not, why paint me with that wide brush?
>
> Let anyone choose.
>
That wasn't the issue. Rather, the issue is, if you're going to choose,
do it for good reasons. "Large user base" is weakly related to the
merits of a language (although one could make a plausible argument based
on humann nature that the larger the user base, the more mediocre the
language.)
> > The size of the user base has little bearing on the merits of a
> > language. The masses want comfort. They don't want beauty,
> > consistency, expressiveness, or power -- all hallmarks of the sublime
> > language that is Lisp.
>
> beauty, consistency, expressiveness, power, sublime...
>
> all of these are subjective words.
So there is no objectivity behind them at all? There really is not
aesthetic difference between Cobol and Lisp?
> Something can be beatiful for one but ugly for other. That is consistent
> for one can be a mess for other, etc.
And I have a brother who really like McDonalds. There's no accounting
for taste.
>
> I personally can see LISP from different perspectives and can apply all
> of those words to LISP language; it is function of on what you compare
> LISP.
I've been programming for 30+ years in over 18 languages. SNOBOL is a
fine language, too.
Bob Felts ha escrito:
> There isn't a lot of difference between 'average' and 'mediocre', is
> there?
Here yes. Mediocre is used as a kind of insult. Average is used in
sense of 'normal'.
> > And i do not devote my entire life to grandiloquent (unfounded) claims as
> > unfortunately is so usual in a subset of LISP community.
>
> Did I make any? If not, why paint me with that wide brush?
I did not said you did. I said "in a subset of LISP community"
> That wasn't the issue. Rather, the issue is, if you're going to choose,
> do it for good reasons.
"good" is another subjective word. What is good for ones can be not
good for others.
> > > The size of the user base has little bearing on the merits of a
> > > language. The masses want comfort. They don't want beauty,
> > > consistency, expressiveness, or power -- all hallmarks of the sublime
> > > language that is Lisp.
> >
> > beauty, consistency, expressiveness, power, sublime...
> >
> > all of these are subjective words.
>
> So there is no objectivity behind them at all?
There is not objectivity on your above discourse. Where you said " of
the sublime language that is Lisp" others would "of the silly
language..."
> There really is not
> aesthetic difference between Cobol and Lisp?
I am more in the LISP camp. And personally i find nice the formal
beauty of the S-expr stuff But those are personal opinions from mine
not dogmas anywhere would agree.
Juan R. <··············@canonicalscience.com> wrote:
> Bob Felts ha escrito:
>
> > There isn't a lot of difference between 'average' and 'mediocre', is
> > there?
>
> Here yes. Mediocre is used as a kind of insult. Average is used in
> sense of 'normal'.
>
Mediocre comes from the Latin and means, "middle height or degree". So
it does mean the same as "average". Both mean "not very good" (as well
as "not very bad").
[...]
>
> > That wasn't the issue. Rather, the issue is, if you're going to choose,
> > do it for good reasons.
>
> "good" is another subjective word. What is good for ones can be not
> good for others.
>
I choose not to argue with moral relativists. They are incapable of
understanding how irrational their positions are.
[...]
Bob Felts ha escrito:
> Mediocre comes from the Latin and means, "middle height or degree". So
> it does mean the same as "average". Both mean "not very good" (as well
> as "not very bad").
I did mean that _is_ usual interpretation where i am living. There is
not such one thing as universal language. Latin does not help much,
because language are not dead and evolutionate.
> > > That wasn't the issue. Rather, the issue is, if you're going to choose,
> > > do it for good reasons.
> >
> > "good" is another subjective word. What is good for ones can be not
> > good for others.
> >
>
> I choose not to argue with moral relativists. They are incapable of
> understanding how irrational their positions are.
Maybe you do not believe but "irrational" is another subjective word.
When Einstein published relativity many mathematicians and physicistst
said he was an insane guy and relativity theory a complete irrational
mess.
[ ... warning -- threadjack ...]
Juan R. <··············@canonicalscience.com> wrote:
> Bob Felts ha escrito:
>
> > Mediocre comes from the Latin and means, "middle height or degree". So
> > it does mean the same as "average". Both mean "not very good" (as well
> > as "not very bad").
>
> I did mean that _is_ usual interpretation where i am living. There is
> not such one thing as universal language. Latin does not help much,
> because language are not dead and evolutionate.
You're a relativist. Why should _I_ care what _your_ interpretation of
a word is? Furthermore, why should you try to convince me that what you
claim is a subjective argument is wrong?
That's the universal thing about relativists -- when someone makes the
claim that what they are doing is wrong then they hide behind "that may
be true for you, but not for me." But the moment they percieve that
someone else is wrong, they try to make a case of the superiority of
their position.
>
> > > > That wasn't the issue. Rather, the issue is, if you're going to choose,
> > > > do it for good reasons.
> > >
> > > "good" is another subjective word. What is good for ones can be not
> > > good for others.
> > >
> >
> > I choose not to argue with moral relativists. They are incapable of
> > understanding how irrational their positions are.
>
> Maybe you do not believe but "irrational" is another subjective word.
> When Einstein published relativity many mathematicians and physicistst
> said he was an insane guy and relativity theory a complete irrational
> mess.
And they were wrong, weren't they?
Bob Felts ha escrito:
>
> You're a relativist. Why should _I_ care what _your_ interpretation of
> a word is? Furthermore, why should you try to convince me that what you
> claim is a subjective argument is wrong?
I am pragmatic. There is not such one thing as universal english. Words
have not a universal meaning and are used in different ways in
different countries or zones. Spanish word "coger" in Spain means "to
catch", In Mexico mean "got sex". Mediocre in some zones has a negative
connotation.
> That's the universal thing about relativists -- when someone makes the
> claim that what they are doing is wrong then they hide behind "that may
> be true for you, but not for me." But the moment they percieve that
> someone else is wrong, they try to make a case of the superiority of
> their position.
You are crazy
> > Maybe you do not believe but "irrational" is another subjective word.
> > When Einstein published relativity many mathematicians and physicistst
> > said he was an insane guy and relativity theory a complete irrational
> > mess.
>
> And they were wrong, weren't they?
Sorry but again i would to say that "wrong" is a relative word. There
is no such absolute meaning of the word true. True is relative. There
is room in science for a new Einstein with a theory contrary to
Einstein thoughts. In fact modern loop quantum gravity contains some
kind of the ether Einstein rejected.
Also wrong in math is relative. 2+2=5 can be both wrong or true, it
depends of the axiomatic sytems choosed. In usual algebra 2+2=4. In
Boolean algebra 2+2=22. because an axiom states x + y = xy.
Juan R. <··············@canonicalscience.com> wrote:
> Bob Felts ha escrito:
> >
> > You're a relativist. Why should _I_ care what _your_ interpretation of
> > a word is? Furthermore, why should you try to convince me that what you
> > claim is a subjective argument is wrong?
>
> I am pragmatic.
So what? If _your_ truth is not _my_ truth, why should I care?
> There is not such one thing as universal english. Words have not a
> universal meaning and are used in different ways in different countries
> or zones. Spanish word "coger" in Spain means "to catch", In Mexico mean
> "got sex". Mediocre in some zones has a negative connotation.
>
So what? If you are offended because of perceived negative connotation,
I would say that's your problem. There are people who find fault with
everything.
> > That's the universal thing about relativists -- when someone makes the
> > claim that what they are doing is wrong then they hide behind "that may
> > be true for you, but not for me." But the moment they percieve that
> > someone else is wrong, they try to make a case of the superiority of
> > their position.
>
> You are crazy
>
Relative to what?
> > > Maybe you do not believe but "irrational" is another subjective word.
> > > When Einstein published relativity many mathematicians and physicistst
> > > said he was an insane guy and relativity theory a complete irrational
> > > mess.
> >
> > And they were wrong, weren't they?
>
> Sorry but again i would to say that "wrong" is a relative word. There
> is no such absolute meaning of the word true. True is relative.
Here you make an absolute statement about a property of truth and you
call _me_ crazy?
> There is room in science for a new Einstein with a theory contrary to
> Einstein thoughts. In fact modern loop quantum gravity contains some kind
> of the ether Einstein rejected.
So? Where does the theory of relativity either demand or reject an
ether?
>
> Also wrong in math is relative. 2+2=5 can be both wrong or true, it
> depends of the axiomatic sytems choosed. In usual algebra 2+2=4. In
> Boolean algebra 2+2=22. because an axiom states x + y = xy.
It isn't relative to the axiom system in use.
Bob Felts ha escrito:
> Juan R. <··············@canonicalscience.com> wrote:
>
> > Bob Felts ha escrito:
> > >
> > > You're a relativist. Why should _I_ care what _your_ interpretation of
> > > a word is? Furthermore, why should you try to convince me that what you
> > > claim is a subjective argument is wrong?
> >
> > I am pragmatic.
>
> So what? If _your_ truth is not _my_ truth, why should I care?
No problem with different opinions and trues. Only problem is with
stuff as "LISP is greatest PL" and similar thoughts when elevated to
kind of universal dogma anyone would agree.
> > There is not such one thing as universal english. Words have not a
> > universal meaning and are used in different ways in different countries
> > or zones. Spanish word "coger" in Spain means "to catch", In Mexico mean
> > "got sex". Mediocre in some zones has a negative connotation.
> >
>
> So what? If you are offended because of perceived negative connotation,
> I would say that's your problem. There are people who find fault with
> everything.
Communication is responsability of two. I simply noticed some of your
words can be incorrectly interpreted in some context, countries, just
that. Take it as advice or ignore it, just that.
> Relative to what?
To you :]
> Here you make an absolute statement about a property of truth and you
> call _me_ crazy?
Eggs and chicken? Nobody win!
> So? Where does the theory of relativity either demand or reject an
> ether?
Ask a physicist
> > Also wrong in math is relative. 2+2=5 can be both wrong or true, it
> > depends of the axiomatic sytems choosed. In usual algebra 2+2=4. In
> > Boolean algebra 2+2=22. because an axiom states x + y = xy.
Typo: Boole --> Brodie.
> It isn't relative to the axiom system in use.
Do not sure about that
"Juan R." <··············@canonicalscience.com> writes:
> Also wrong in math is relative. 2+2=5 can be both wrong or true, it
> depends of the axiomatic sytems choosed. In usual algebra 2+2=4. In
> Boolean algebra 2+2=22. because an axiom states x + y = xy.
I hope you DON'T write any program.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."
Pascal Bourguignon ha escrito:
> "Juan R." <··············@canonicalscience.com> writes:
> > Also wrong in math is relative. 2+2=5 can be both wrong or true, it
> > depends of the axiomatic sytems choosed. In usual algebra 2+2=4. In
> > Boolean algebra 2+2=22. because an axiom states x + y = xy.
>
> I hope you DON'T write any program.
>
Typo: Boole --> Brodie
x + y = xy [1]
Abandoned in last 19th because isomerism was not explained. Recovered
in last 20th because a logician introduced isomerism in a new calculus.
[1] http://www.hyle.org/journal/issues/8-1/bio_brock.htm
Juan R. wrote:
>
> Maybe you do not believe but "irrational" is another subjective word.
> When Einstein published relativity many mathematicians and physicistst
> said he was an insane guy and relativity theory a complete irrational
> mess.
>
What a pile of ....
That is a completely wrong. How do you think he got his papers
published in the first place?
Wade
Wade Humeniuk ha escrito:
> That is a completely wrong. How do you think he got his papers
> published in the first place?
Einstein works were not obligated by peer-review as would be today.
I got a collection of quotes of other scientists speaking about
Einstein, even insulting it!
Even the wiki contains data on strong initial rejection of Einstien
theories:
"Many scientists were still unconvinced for various reasons ranging
from the scientific (disagreement with Einstein's interpretation of the
experiments, belief in the ether or that an absolute frame of reference
was necessary) to the psycho-social (conservatism, anti-Semitism). In
Einstein's view, most of the objections were from experimentalists with
very little understanding of the theory involved.[22] Einstein's public
fame which followed the 1919 article created resentment among these
scientists, some of which lasted well into the 1930s.[23]"
Juan R. wrote:
> I got a collection of quotes of other scientists speaking about
> Einstein, even insulting it!
>
Even when a Saint dies someone is happy. (Paraphrase from a Bhuddist
saying). Do have any quotes saying the opposite? Because I am sure there
was.
> Even the wiki contains data on strong initial rejection of Einstien
> theories:
>
> "Many scientists were still unconvinced for various reasons ranging
> from the scientific (disagreement with Einstein's interpretation of the
> experiments, belief in the ether or that an absolute frame of reference
> was necessary) to the psycho-social (conservatism, anti-Semitism). In
> Einstein's view, most of the objections were from experimentalists with
> very little understanding of the theory involved.[22] Einstein's public
> fame which followed the 1919 article created resentment among these
> scientists, some of which lasted well into the 1930s.[23]"
>
Ahh the proverbial wiki. Doing a brief read he became a full professor in
1911. In the same year he was the youngest to attend the world's first
invitation-only physics conference. By 1914 he was director of the
Kaiser Wilhelm Institute. I suppose he put himself in that position,
after all there was no peer review at that time ;).
Wade
Wade Humeniuk ha escrito:
> Even when a Saint dies someone is happy. (Paraphrase from a Bhuddist
> saying). Do have any quotes saying the opposite? Because I am sure there
> was.
True and now he is idolatred, but then it was mainly rejected. This is
usual in any revolution.
> Ahh the proverbial wiki. Doing a brief read he became a full professor in
> 1911. In the same year he was the youngest to attend the world's first
> invitation-only physics conference. By 1914 he was director of the
> Kaiser Wilhelm Institute. I suppose he put himself in that position,
> after all there was no peer review at that time ;).
Einstein published his papers without peer review. Therefore, 'any' was
published in journals he submmitted.
When he began to sent papers to peer-review journal Einstein got a
rejections [1]. See the letter Einstein wrote to the Editor it is
funny.
I assume you know that Einstein never received Nobel Prize for
relativity (even if mainstream think that). The community always
thought that relativity was too controversial for a Nobel.
[1] http://www.physicstoday.org/vol-58/iss-9/p43.html
Juan R. wrote:
>
> Wade Humeniuk ha escrito:
>
>> Even when a Saint dies someone is happy. (Paraphrase from a Bhuddist
>> saying). Do have any quotes saying the opposite? Because I am sure
>> there was.
>
> True and now he is idolatred, but then it was mainly rejected. This is
> usual in any revolution.
>
>> Ahh the proverbial wiki. Doing a brief read he became a full professor
>> in
>> 1911. In the same year he was the youngest to attend the world's first
>> invitation-only physics conference. By 1914 he was director of the
>> Kaiser Wilhelm Institute. I suppose he put himself in that position,
>> after all there was no peer review at that time ;).
>
> Einstein published his papers without peer review. Therefore, 'any' was
> published in journals he submmitted.
I think this is just a myth used by mediocre thinkers to explain their
own lack of success. When faced by criticism of something they have
stated or written they can always fall back on the "well Einstein was
not accepted by his peers either, so I could be right but you just
cannot see it". But the fact was that the journals did accept Einstein's
papers and the institutions at the time employed him as a professor
and he was accepted by his peers. He was invited to the conference
because other physicists read his papers and thought he had something
valuable to contribute. I am sure most criticism of Einstein's work
came from experimentalists who were hard on him because there
was no objective validation of his assertions (which they were
absolutely right to do).
>
> When he began to sent papers to peer-review journal Einstein got a
> rejections [1]. See the letter Einstein wrote to the Editor it is
> funny.
>
Yeah, Einstein wrote some crap and got called on it. Maybe
Einstein bought into his own mythos and got trapped by it.
> I assume you know that Einstein never received Nobel Prize for
> relativity (even if mainstream think that). The community always
> thought that relativity was too controversial for a Nobel.
>
And Archimedes did not get one for his work on buoyancy.
Wade
> [1] http://www.physicstoday.org/vol-58/iss-9/p43.htm
Wade Humeniuk <··················@telus.net> wrote:
> Juan R. wrote:
>
> >
> > Wade Humeniuk ha escrito:
> >
> >> Even when a Saint dies someone is happy. (Paraphrase from a Bhuddist
> >> saying). Do have any quotes saying the opposite? Because I am sure
> >> there was.
> >
> > True and now he is idolatred, but then it was mainly rejected. This is
> > usual in any revolution.
> >
> >> Ahh the proverbial wiki. Doing a brief read he became a full professor
> >> in
> >> 1911. In the same year he was the youngest to attend the world's first
> >> invitation-only physics conference. By 1914 he was director of the
> >> Kaiser Wilhelm Institute. I suppose he put himself in that position,
> >> after all there was no peer review at that time ;).
> >
> > Einstein published his papers without peer review. Therefore, 'any' was
> > published in journals he submmitted.
>
> I think this is just a myth used by mediocre thinkers to explain their
> own lack of success. When faced by criticism of something they have
> stated or written they can always fall back on the "well Einstein was
> not accepted by his peers either, so I could be right but you just
> cannot see it".
"They laughed at Einstein!"
To which the appropriiate response is, "Well, they also laughed at Bozo
the clown".
Wade Humeniuk ha escrito:
> I think this is just a myth used by mediocre thinkers to explain their
> own lack of success. When faced by criticism of something they have
> stated or written they can always fall back on the "well Einstein was
> not accepted by his peers either, so I could be right but you just
> cannot see it".
I thought during a while on why there exists a strong tendency to
ignore the difficulties for publishing revolutionary theories in
science. History of science has proved that any revolutionary (enough)
theory is always initially rejected by colleagues, after ignored, but
finally accepted.
I think that rationality for hidding this continuous failure of
scientific community is an attempt to hide the irrationality of the
comunity itself when valuating some novel idea they have not diggested.
After all if expertises on a field are unable to differentiate between
Bozo the genious and "Bozo the clown" (paraphrasing Bob Felts below)
then that would generate a kind of crisis on science.
> But the fact was that the journals did accept Einstein's
> papers and the institutions at the time employed him as a professor
> and he was accepted by his peers.
The history of relativity is complex and had a lot of political and
social stuff behind. Trying to present Einstein theories as understood
and completely accepted since first time is an error. Also one would
notice differences on acceptation for special relativity and general
formulation.
>From a recent Nature editorial [1] subtitled: "Accounts of rejected
Nobel-winning discoveries highlight the conservatism in science.
Despite their historical misjudgements, journal editors can help, but
above all, visionaries will need sheer persistence." explain what were
some of the tricks used for publishing revolutionary ideas, including
academic privileges in the cae of PNAS. Next states:
"This is strikingly reminiscent of perhaps the most celebrated
editorial
judgements of all, in Annalen der Physik in1905. That was the
year in which Einstein published five extraordinary papers in that
journal, including special relativity and the photoelectric effect. The
journal had a great editor in Max Planck.He recognized the virtue of
publishing such outlandish ideas, but there was also a policy that
allowed authors much latitude after their first publication. Indeed,
in journals in those days, the burden of proof was generally on the
opponents rather than the proponents of new ideas."
As i already said then was not peer review in German journal and almost
'any' stuff was published and/or debated.
> > When he began to sent papers to peer-review journal Einstein got a
> > rejections [1]. See the letter Einstein wrote to the Editor it is
> > funny.
>
> Yeah, Einstein wrote some crap and got called on it. Maybe
> Einstein bought into his own mythos and got trapped by it.
That was not the point. The point was that Einstein got surprise
because did not know peer-review was. Please read Einstein letter (i
cited). If einstein work had been sent today for publication almost
sure would be rejected by peer-review. History suggests this and
recently a Nobel laureate argued that today Einstein would got
rejection even in ArXiv because policy issues!
[1] Nature 2003, 425, 645
"Juan R." <··············@canonicalscience.com> wrote on 26 Dec 2006 03:5:
> History of science has proved that any revolutionary (enough) theory is
> always initially rejected by colleagues, after ignored, but finally
> accepted.
C.f. Thomas Kuhn, "The Structure of Scientific Revolutions"
http://en.wikipedia.org/wiki/The_Structure_of_Scientific_Revolutions
and the concept of "paradigm shift".
Especially Max Planck's observation that
a new scientific truth does not triumph by convincing its opponents
and making them see the light, but rather because its opponents
eventually die, and a new generation grows up that is familiar with
it.
> I think that rationality for hidding this continuous failure of
> scientific community is an attempt to hide the irrationality of the
> comunity itself when valuating some novel idea they have not diggested.
It's actually far from clear that this behavior of "the scientific
community" is irrational.
Yes, massive paradigm shifts, that were later understood to be correct,
initially encountered great resistance. But so did a million stupid ideas.
Surely science would not be better off gullibly accepting any foolish thing
that somebody invents.
"Extraordinary claims require extraordinary proof." It is reasonable and
correct that controversial new claims are met with great skepticism.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Jiu-jitsu is the art of folding laundry, with the people still in it.
Don Geddis ha escrito:
> "Juan R." <··············@canonicalscience.com> wrote on 26 Dec 2006 03:5:
> > History of science has proved that any revolutionary (enough) theory is
> > always initially rejected by colleagues, after ignored, but finally
> > accepted.
>
> C.f. Thomas Kuhn, "The Structure of Scientific Revolutions"
> http://en.wikipedia.org/wiki/The_Structure_of_Scientific_Revolutions
> and the concept of "paradigm shift".
>
> Especially Max Planck's observation that
>
> a new scientific truth does not triumph by convincing its opponents
> and making them see the light, but rather because its opponents
> eventually die, and a new generation grows up that is familiar with
> it.
And textbooks are updated for the winning paradigm and even the history
of science is sometimes rewritten.
> > I think that rationality for hidding this continuous failure of
> > scientific community is an attempt to hide the irrationality of the
> > comunity itself when valuating some novel idea they have not diggested.
>
> It's actually far from clear that this behavior of "the scientific
> community" is irrational.
Let me cite Roald Hoffmann -Nobel Laureate in Chemistry-:
"in the course of this refereeing process there are incredibly
irrational responses unleashed by perfectly good and otherwise rational
scientist"
> Yes, massive paradigm shifts, that were later understood to be correct,
> initially encountered great resistance. But so did a million stupid ideas.
> Surely science would not be better off gullibly accepting any foolish thing
> that somebody invents.
At least 18 of more cited articles were initially rejected and at least
35 works after awarded by a Nobel Prize were initially rejected for
publication or discredited by the community. That is a much!
Today there exist prohibited topics of research, some journals do not
acept certain speculative material was either correct or wrong (simply
refuse it) and even some Nobel laureates are blacklisted from
publishing in systems as that of ArXiv because administrators do not
agree on their ideas!
Most recent example i know was attempt from string theory comunity to
impede publication of Woit book critizing string theory :] With
'scientists' as Lubos Motl offering in public gifts to anyone writting
a bad critic of Woit book on Amazon (both reading it or not).
Sure that control and peer-review is needed but sometimes control is
excesive and some people see lack of progress in current science (no
revolution) as symptom of current publication and funding and policies.
> "Extraordinary claims require extraordinary proof." It is reasonable and
> correct that controversial new claims are met with great skepticism.
Maybe, but skepticism is not the REAL problem but elimination of
disidents and alternative views.
On Dec 26 2006, 8:25 pm, "Juan R."
<··············@canonicalscience.com> wrote:
>
> Sure that control and peer-review is needed but sometimes control is
> excesive and some people see lack of progress in current science (no
> revolution) as symptom of current publication and funding and policies.
I was a referee for Nuclear Physics B, Physical Review D and Physical
Review
Letters, which are the leading publishers for theorical research in
Quantum
Field Theory. I want to share some light on how the peer review
process
works *in reality*.
In reality, nobody wants to be a referee. Being a referee means that
you have
to spend valuable time checking some other people work, time that you
would rather spend writing your own papers. The needed specialization
to be able to judge a paper in a research field is so high that it is
extremely difficult to find good referees. So, lots of the referee
work
is demanded to young scientists, which means postdoctoral fellows and
possibly even Ph. D. students. It is enough if you have published one
or
two papers in the journal (or if your Ph. D. advisor is friend of the
editor) to become a referee for that journal. So, it happened to me
to
have to referee papers in fields where I had no real expertise, as
well as to referee papers in fields where I had real expertise. In
both cases the approval criteria are similar.
If you have expertise, your typical reaction is "this has been already
done"
and you send back the paper asking to add some relevant prior
reference.
Still, the paper is considered acceptable if you judge that the
author(s)
spent a serious effort on it and it looks technically sound and its
conclusions look reasonable. Of course, you will *never* check the
calculations, since this would require month of effort on you part,
for
proving things that you already know, since you are an expert on that
field.
If you don't have real expertise in the domain, it is of course more
difficult to judge the real value of a paper. However, it is easy to
determine the reputation of the research group that submitted the
paper,
and it is also relatively easy to understand the "level" of the paper,
if
not its correctness. I have seen various papers in the literature,
even
papers which are considered seminal and of extreme relevance, with
errors in them, since nobody actually checked the computations. Still,
if
the idea is right, errors and found and checked later, by the
followers.
This is normal.
If you work in a established group, your paper will likely be
published,
but you have to be preparated to fight. Typically the referees ask for
clarifications because they misunderstand some part of the paper, and
often one has to change/improve some section, adding references to
other people work, etc. I wrote 10 papers in my career as a
scientist,
and nine times I had to discuss with the referees. However, this is
normal
and happens to everybody. Only once we had a referee that was
absolutely
contrary to our paper (a letter to Phys. Rev. D) since he said "this
is not
interesting at all". So we asked for a second referee who said "this
is very relevant research" and we got published. But even this is
normal,
this is part of scientific discussions, opinions can be different and
you can always ask for a second referee. Finally, changing journal can
be an option. Once, I could not publish a paper on Nuclear Physics B
and I had to publish it in another journal. After a while, the editor
of Nuclear Physics B resigned, and I got a mail from one the new
editors
asking me to publish another one on my paper appeared on hep-th
on their journal. That time I had the satisfaction to say "sorry, but
the paper has been already accepted by another journal".
So, publishing on a scientific journal is a bit of a fight, but this
is
okay, it is part of the rules of the game. When I was on the other
part,
I also rejected papers from big professors, asking for improvements.
In
any case, most of the published papers are forgotten after a short
while,
and they deserve to be forgotten.
It is true that things are not perfect: for instance I got published
relatively weak papers when one of my co-authors was a friend of the
editor,
whereas I could not get published relatively strong papers when there
was
only my name on them. This was with Nuclear Physics B, which has a
50%
acceptance policy, they have to reject half of the submissions, and
it
is of course easier to reject works by unknown young physicists.
But overall, the peer review system, with all its issues, is
definitely
NOT the big problem. The real problem is that there are hundreds of
students
and postdocs ou there, and practically no permanent positions, so
that
in order to get a living more than 90% of young physicists is
automatically
forced to move to things like programming, finance, teaching, etc.
But this is entirely another subject, so I will stop here.
Michele Simionato
On Feb 4, 4:10 pm, ··················@gmail.com"
<·················@gmail.com> wrote:
> If you don't have real expertise in the domain, it is of course more
> difficult to judge the real value of a paper. However, it is easy to
> determine the reputation of the research group that submitted the
> paper,
> and it is also relatively easy to understand the "level" of the paper,
> if
> not its correctness.
As general rule? I agree.
However, it is important to notice there exist several well-known
cases of papers rejected by expertises and referees as wrong after
were awarded Nobel Prize.
Sure this failure to correctly evaluate a paper is one between 10000
cases, but it is just that single case after becomes so important that
is awarded a Nobel Prize. It is not unlkely to think that some work,
will receive a Nobel in next 10-20 years, is being now rejected
elsewhere.
> So, publishing on a scientific journal is a bit of a fight, but this
> is
> okay, it is part of the rules of the game.
No problem with fighting; as a scientist one may be prepared to defend
ideas, theories, or hypotesis in basis to reasoning and data. The
problem people is recognizing with current politized science is when
the quantity of figth is excessive, which happen usually with more
revolutionary ideas.
It is ironic revolutionary ideas are not rejected for publication in
conservative journals because before they were rejected by governments
and agencies for funding.
My first scientific work alone was on the issue of nanothermodynamics.
One recognized leader on thermodynamical science enjoyed my work; at
the same time, a spanish agency rejected it for a research prize on
basis to policy (We are not saying your work was not a breaktrough on
the field but... do not fit on government interests for Spanish
research).
When funded the fight continues. Also there the history of science
ilustrates us with scientist who fight during entire decades with
their colleagues, now we call genious to those scientists and we
forgot names of their colleagues.
Sure you studied Lewis theory of chemical bond in school's chemistry,
but do you know the names of physicists developed then alternative
(now wrong) theories?
> But overall, the peer review system, with all its issues, is
> definitely
> NOT the big problem.
It can be for people working in certain conflictive fields. I remember
a communication with editor of a Physical Review (I think was the A)
who politely said me that they did not aceppt papers in certain issues
because in their own words: the field had been sufficiently studied
during decades and had no doubt.
In science, no field is sufficiently studied. Scientific theories are
tested each day.
> The real problem is that there are hundreds of
> students
> and postdocs ou there, and practically no permanent positions, so
> that
> in order to get a living more than 90% of young physicists is
> automatically
> forced to move to things like programming, finance, teaching, etc.
> But this is entirely another subject, so I will stop here.
Yes, money is another issue, like is also that science is in general
becoming more and more monotonous, but unlike John Horgan I do not
think was the end of scientific discovering era, but the result of
current boring policies and funding.
Juan R. wrote:
> Wade Humeniuk ha escrito:
>
>> I think this is just a myth used by mediocre thinkers to explain their
>> own lack of success. When faced by criticism of something they have
>> stated or written they can always fall back on the "well Einstein was
>> not accepted by his peers either, so I could be right but you just
>> cannot see it".
>
> I thought during a while on why there exists a strong tendency to
> ignore the difficulties for publishing revolutionary theories in
> science. History of science has proved that any revolutionary (enough)
> theory is always initially rejected by colleagues, after ignored, but
> finally accepted.
>
> I think that rationality for hidding this continuous failure of
> scientific community is an attempt to hide the irrationality of the
> comunity itself when valuating some novel idea they have not diggested.
>
All I think you are doing here is creating a problem where none exists.
You are playing the very politics you accuse the "community" of playing.
So I think you are really talking about yourself. I see your line
as essentially "the community should be more accepting of ideas on the
chance they might miss or overlook something". You are asking that they
give up "a little bit of critical thinking" for the larger good.
> After all if expertises on a field are unable to differentiate between
> Bozo the genious and "Bozo the clown" (paraphrasing Bob Felts below)
> then that would generate a kind of crisis on science.
>
Crisis? What crisis?
>> But the fact was that the journals did accept Einstein's
>> papers and the institutions at the time employed him as a professor
>> and he was accepted by his peers.
>
> The history of relativity is complex and had a lot of political and
> social stuff behind. Trying to present Einstein theories as understood
> and completely accepted since first time is an error. Also one would
> notice differences on acceptation for special relativity and general
> formulation.
>
I am sorry if that has been your experience with the "community", but
that is what happens when mediocre ideas are presented. They get a
rough ride. My experiences have been is that when an idea has
merit, and is well presented (coherent) that it has a life of its own
and those in the "community" are more than friendly and helpful.
Poor ideas and the people who present them get a less than friendly
reception. They have basically insulted others by not trying
their best (and implying that their ideas be accepted on political
grounds).
>>From a recent Nature editorial [1] subtitled: "Accounts of rejected
> Nobel-winning discoveries highlight the conservatism in science.
> Despite their historical misjudgements, journal editors can help, but
> above all, visionaries will need sheer persistence." explain what were
> some of the tricks used for publishing revolutionary ideas, including
> academic privileges in the cae of PNAS. Next states:
>
> "This is strikingly reminiscent of perhaps the most celebrated
> editorial
> judgements of all, in Annalen der Physik in1905. That was the
> year in which Einstein published five extraordinary papers in that
> journal, including special relativity and the photoelectric effect. The
> journal had a great editor in Max Planck.He recognized the virtue of
> publishing such outlandish ideas, but there was also a policy that
> allowed authors much latitude after their first publication. Indeed,
> in journals in those days, the burden of proof was generally on the
> opponents rather than the proponents of new ideas."
>
> As i already said then was not peer review in German journal and almost
> 'any' stuff was published and/or debated.
>
>>> When he began to sent papers to peer-review journal Einstein got a
>>> rejections [1]. See the letter Einstein wrote to the Editor it is
>>> funny.
>> Yeah, Einstein wrote some crap and got called on it. Maybe
>> Einstein bought into his own mythos and got trapped by it.
>
> That was not the point. The point was that Einstein got surprise
> because did not know peer-review was. Please read Einstein letter (i
> cited). If einstein work had been sent today for publication almost
> sure would be rejected by peer-review. History suggests this and
> recently a Nobel laureate argued that today Einstein would got
> rejection even in ArXiv because policy issues!
>
I did not see that, I read that Einstein's ego got the better of him when
someone caught an error. (As an aside to suggest it is pretty weak to
suggest that Einstein did not know what peer-review was, after all
in his position he to review papers all the time).
W
> [1] Nature 2003, 425, 645
>
Wade Humeniuk wrote:
>
> I did not see that, I read that Einstein's ego got the better of him when
> someone caught an error. (As an aside to suggest it is pretty weak to
^
, it is pretty weak to
> suggest that Einstein did not know what peer-review was, after all
> in his position he to review papers all the time).
^
had
Wow, I should proof my stuff better!
W
Wade Humeniuk ha escrito:
> > I think that rationality for hidding this continuous failure of
> > scientific community is an attempt to hide the irrationality of the
> > comunity itself when valuating some novel idea they have not diggested.
> >
>
> All I think you are doing here is creating a problem where none exists.
> You are playing the very politics you accuse the "community" of playing.
> So I think you are really talking about yourself. I see your line
> as essentially "the community should be more accepting of ideas on the
> chance they might miss or overlook something". You are asking that they
> give up "a little bit of critical thinking" for the larger good.
You are not understanding me. 18 of more cited works and at least 35
works after awarded a Nobel Prize were rejected, discredited, or
stopped from publication even during entire decades. Those days there
is a strong debate even in journals as Nature about politics of
publication and Nature has an experimental process of acceptation of
papers could be rejected when following the usual procedure. It is
difficult to bleieve they are generating a solution for -in your own
words -a problem does not exist.
> > After all if expertises on a field are unable to differentiate between
> > Bozo the genious and "Bozo the clown" (paraphrasing Bob Felts below)
> > then that would generate a kind of crisis on science.
> >
>
> Crisis? What crisis?
Look around you. Crisis on results, crisis on funding, crisis on number
of students, crisis on sistematic rejection of novel ideas -some
journals simply refuse publishing on hot topics either paper was
correct or not-, crisis and hot debate about ArXiv policy, crisis on
blocking people in certain organizations, the BIG crisis on particle
physics with people as Suskind claiming that we would abandon the
scientific method because string theory does not fit well in it, etc.
> >> But the fact was that the journals did accept Einstein's
> >> papers and the institutions at the time employed him as a professor
> >> and he was accepted by his peers.
> >
> > The history of relativity is complex and had a lot of political and
> > social stuff behind. Trying to present Einstein theories as understood
> > and completely accepted since first time is an error. Also one would
> > notice differences on acceptation for special relativity and general
> > formulation.
> >
>
> I am sorry if that has been your experience with the "community", but
> that is what happens when mediocre ideas are presented. They get a
> rough ride. My experiences have been is that when an idea has
> merit, and is well presented (coherent) that it has a life of its own
> and those in the "community" are more than friendly and helpful.
Then you know nothing of the history of science.
> Poor ideas and the people who present them get a less than friendly
> reception. They have basically insulted others by not trying
> their best (and implying that their ideas be accepted on political
> grounds).
Sure, that is that history of science disproves you. Just some examples
for illustration.
C.H. Townes (Physics Nobel, 1964):
"One day...Raby and Kusch, the former and current chairmen of the
department, both of them Nobel Laureates for their work with atomic and
molecular beans and with a lot of weight behind their opinions, came
into my office and sat down. They were worried. Their research depended
on support from the same source as did mine. 'Look', they said, 'you
should stop the work you are doing. You're wasting money. Just stop'."
George W. Beadle (Physiology or Medicine Nobel, 1958):
"...In retrospect one wonders how such important findings could be so
thoroughly unappreciated and disregarded for so many years. Obviously
the time was not ready for their proper appreciation. Even in 1941 when
Tatum and I first reported our induced genetic-biochemical lesions in
Neurospora few people were ready to accept what seemed to us to be a
compelling conclusion...the sceptics were many, the converts few...even
at the time of the 1951 Cold Spring Harbor Symposium on Quantitative
Biology the sceptics were still many..."
Harold W. Kroto (Chemistry Nobel, 1996) on initial response from
scientific community:
"With regard to this question, when our paper was first published there
were several papers which claimed that the experiments were not correct
and that our interpretation was also not correct."
> > That was not the point. The point was that Einstein got surprise
> > because did not know peer-review was. Please read Einstein letter (i
> > cited). If einstein work had been sent today for publication almost
> > sure would be rejected by peer-review. History suggests this and
> > recently a Nobel laureate argued that today Einstein would got
> > rejection even in ArXiv because policy issues!
>
> I did not see that, I read that Einstein's ego got the better of him when
> someone caught an error. (As an aside to suggest it is pretty weak to
> suggest that Einstein did not know what peer-review was, after all
> in his position he to review papers all the time).
Please read again
Juan R. wrote:
> Wade Humeniuk ha escrito:
>>> I think that rationality for hidding this continuous failure of
>>> scientific community is an attempt to hide the irrationality of the
>>> comunity itself when valuating some novel idea they have not diggested.
>>>
>> All I think you are doing here is creating a problem where none exists.
>> You are playing the very politics you accuse the "community" of playing.
>> So I think you are really talking about yourself. I see your line
>> as essentially "the community should be more accepting of ideas on the
>> chance they might miss or overlook something". You are asking that they
>> give up "a little bit of critical thinking" for the larger good.
>
> You are not understanding me. 18 of more cited works and at least 35
> works after awarded a Nobel Prize were rejected, discredited, or
> stopped from publication even during entire decades.
Could you point to the documentation surrounding this assertion?
Such as:
- Why the works were rejected. Officially.
- Then (I suppose) why they were accepted.
- And what changed.
I suppose these questions are too difficult to answer because too
many noses may be out of joint and positions honed and hardened
over time. But I expect many of the situations (if they
are true) to have reasonable explanations.
> Those days there
> is a strong debate even in journals as Nature about politics of
> publication and Nature has an experimental process of acceptation of
> papers could be rejected when following the usual procedure. It is
> difficult to bleieve they are generating a solution for -in your own
> words -a problem does not exist.
>
Just because some people assert there is a problem, does not mean there is
one. For example, Weapons of Mass Destruction and Iraq. For all I
know they are just creating a problem for political ends. (though I
find it interesting that you might accept a peer-reviewed (censored)
debate as authoritative).
W
Juan R. wrote:
> Wade Humeniuk ha escrito:
> > Juan R. wrote:
> > > Wade Humeniuk ha escrito:
<snip>
> Already in the Nature ed i cited are recognized more than 20 Nobel
> laureates's rejections in general. Moreover, they do the mea culpa in a
> number of sound rejections from own Nature.
I've worked for several years now in Electromagnetics, radio
propagation and antennas. These subjects are close to physics and use
referred journals widely. They suffer from many of the problems of
referred journals in general. The problems go beyond rejecting things
that are unacceptable because of content. The problems I've seen are,
in no particular order:-
* Cost - It actually costs money to publish in many journals. $50-$100
per page is the rate the IEEE often charge.
* Taste - Editors have a particular taste about what they like.
Earlier editors of the journal "Transactions of Antennas and
Propagation" took anything to do with those subjects that was good.
The present editor wants mathematics underlying everything, so the
whole style of the journal has changed.
* Length - Publishing something that's long is very difficult. Science
periodicals are exactly that, periodicals, magazines. They are
targetted to attract readers not progress science. Readers don't want
one issue filled with a single author.
* Language barrier - This is a big problem today. If you can't explain
yourself well in the language of the journal (normally english) you
will get your submissions returned. Probably the article won't be
rejected, just returned with a note telling you to improve the
language.
* Complexity - Something containing lots of very involved mathematics
can be difficult to publish if none of the editors can understand it,
or can find the time to understand it. Probably it will be published,
but will lie in the hands of editors for more than a year, and when
published few will read it and understand it.
* Burden of proof - Often journals require a large amount of evidence
before publishing something.
* Professional memberships - Several journals are affiliated to
professional organisations and require member to join or pay even more
to publish through them.
* Acolyte nepotism - The reputation of Academics is built by their work
and that of their students. A student and his master have a common
interest in promoting themselves, since their reputations rub-off on
each other. As a result editors frequently run long articles by their
students.
* Subject "nepotism" - Strange idea, but it happens a lot. If an
editor is working on a particular subject he will often consider it
"the way forward", and will as a result they tend to publish stuff that
goes in the direction they want to know.
* Flagrant dishonesty - I get the impression this is very rare. But I
have heard it said from others that journal editors have stolen ideas
sitting in their slushpiles. Also that they have used those ideas for
the basis of patents. I think it's quite unlikely and the most likely
explanation when it appears to have happened is that more than one
person has had the same idea at the same time.
There is also a big problem when you get something published:
_readership_. Most scientists are busy on their own work, and they do
not follow the work of others that closely. Readership is
almost-always small.
Of the other problems I don't think any of them are insummountable.
Some possible solutions:-
* Cost - Find a cheap journal. Write something short.
* Taste - Read the journal, find out what the editors like, reemphasis
your work accordingly
* Length - Split things into parts. I've seen several papers spanned
over multiple months recently
* Language barrier - Find some native english speakers, get them to
read it. Native English writers are better than just readers.
* Complexity - Split things across several papers. Deal with a simple
case first, then a more complex one.
* Burden of Proof - Hard to deal with. Some journals will find it
acceptable if the authors temper their findings by stating that much
further work is needed to confirm them.
* Professional memberships - Work out which organisation provides the
best value for money. Find someone who has professional membership and
add their name to the paper this often allows it to be published at
members rates.
* Subject "nepotism" - Find a fashionable subject to link your work to.
Often sentences like "This could be usefully applied to X" are common
even if they are not entirely true.
* Acolyte nepotism - Can't really be avoided. One good idea is to get
a notable person in the field to read the paper and check it, then put
his name last on the authors.
* Flagrant dishonesty - Find out what other scientists think of various
editors and journals.
Many of these problems can also be dealt with in another way: by using
Conferences.
Rules at conferences are much laxer, people can do fairly much anything
they like in poster papers. Also, at conference people have time to
read papers. By putting in poster papers you get the chance to polish
your work by asking the bunch of readers in front of you what they
think. They can often tell you more about prior work, and advise on
how to go further. If you can afford to go to a conference, then this
is the best opportunity for presenting really new work. Also, at a
poster session you can hand out what you like, so have a your best work
printed out on paper separate to the posters and hand it to those
interested.
> Also often some expertises valuates some work as wrong and then author
> is considered a cranck before being recognized as brilliant.
I don't think that's a very common problem. The more common problem is
being considered to have little experience in the subject matter.
> If revolution is large then can be needed decades entires before the
> work begin to be aknowledged.
>
> For large revolutions what change is that old guys dead and a new
> generation of scientists born are trained in the new paradigm. For the
> new generation the new paradigm is considered to be 'normal'. Old guys
> usually never accept the new paradigm, therein the quote from the wiki.
I don't think this is true. In my experience acceptance of new
paradigms doesn't depend at all on age. I don't really know what
governs acceptance of new ideas, but I'm pretty sure it's not that.
> > Just because some people assert there is a problem, does not mean there is
> > one.
>
> It is not some people there is strong movement for search of new
> publication systems in different comunities. Jus that Nature (a very
> conservative journal) accepts limitations in traditional peer review
> system is a sign.
FWIW I think there is a problem in some areas. Cost is a big problem.
Rob Thorpe ha escrito:
> * Cost - It actually costs money to publish in many journals. $50-$100
> per page is the rate the IEEE often charge.
True in Black and white or even more expensive when adding fixed
quantity per article. Adds $300-600 per figure in color.
> * Taste - Editors have a particular taste about what they like.
> Earlier editors of the journal "Transactions of Antennas and
> Propagation" took anything to do with those subjects that was good.
> The present editor wants mathematics underlying everything, so the
> whole style of the journal has changed.
True. I know of an editor of a journal of physics cannot publishs stuff
on X, no matter good or wrong the article is. Simply is not even sent
to referees. Often publishing your work mean selecting an editor more
akin to your field, 'no' matter journal him was.
> * Length - Publishing something that's long is very difficult. Science
> periodicals are exactly that, periodicals, magazines. They are
> targetted to attract readers not progress science.
Yes, there is penals on mainstream journals for that. As 150$ per page
in excess beyond 12 pages.
> * Complexity - Something containing lots of very involved mathematics
> can be difficult to publish if none of the editors can understand it,
> or can find the time to understand it. Probably it will be published,
> but will lie in the hands of editors for more than a year, and when
> published few will read it and understand it.
And when the editor misread you wrote? That can be funy!
> * Burden of proof - Often journals require a large amount of evidence
> before publishing something.
Top-level journals may maintain a reputation (and an index :-) and
editors prefer do not publish a revolution rather than publish
something wrong. Therein if editor or referees express doubts about
your article either because is complex or because is a hot debated
topic with multiple points of view then your work probably will be
rejected.
Editor of Physical Review said me that they do not usually publish
material on foundations of physics. That is, 'tacitally' they 'asume'
that foundations of physics are beyond doubt for the ambit of that
journal, and only admit 'mainstream' papers, no revolution there.
> * Professional memberships - Several journals are affiliated to
> professional organisations and require member to join or pay even more
> to publish through them.
Yes, a paper can got published or rejected in function of political
issues. In PNAS several articles were published because members'
privileges. Also ArXiv has a kind of blacklist rejecting articles from
certain authors no matter the work is either fascinating or stupid.
I know also some important people (Nobel laureates and similar) got
their papers published more easy.
> * Acolyte nepotism - The reputation of Academics is built by their work
> and that of their students. A student and his master have a common
> interest in promoting themselves, since their reputations rub-off on
> each other. As a result editors frequently run long articles by their
> students.
Ejem, the article by the student is usually published as "master et
al." That is the master adds the name to the article even if
contribution was small or zero.
You often read of some big boys with publication record of 500-700
articles, but after you discover he has 50 full-time coworkers...
> * Subject "nepotism" - Strange idea, but it happens a lot. If an
> editor is working on a particular subject he will often consider it
> "the way forward", and will as a result they tend to publish stuff that
> goes in the direction they want to know.
right I was that in PLA recenly, once editor passed away, the journal
no more accepted articles on that topic close to editor work.
> * Flagrant dishonesty - I get the impression this is very rare. But I
> have heard it said from others that journal editors have stolen ideas
> sitting in their slushpiles. Also that they have used those ideas for
> the basis of patents. I think it's quite unlikely and the most likely
> explanation when it appears to have happened is that more than one
> person has had the same idea at the same time.
Yes i read there is data on this kind of behavior, Also read referees
rejecting some article but using priviligiated knowledge of ideas on
the paper for own article.
> * Taste - Read the journal, find out what the editors like, reemphasis
> your work accordingly
Ask a colleague where published him...
> * Length - Split things into parts. I've seen several papers spanned
> over multiple months recently
good for CV...
> * Language barrier - Find some native english speakers, get them to
> read it. Native English writers are better than just readers.
Ask some native colleague.
> * Complexity - Split things across several papers. Deal with a simple
> case first, then a more complex one.
Think that editor and referre are stupid. This usually works.
> * Burden of Proof - Hard to deal with. Some journals will find it
> acceptable if the authors temper their findings by stating that much
> further work is needed to confirm them.
I think that this is always true on science, where _anything_ is always
open to debate.
> * Professional memberships - Work out which organisation provides the
> best value for money. Find someone who has professional membership and
> add their name to the paper this often allows it to be published at
> members rates.
Find some colleague with good contacts...
> * Acolyte nepotism - Can't really be avoided. One good idea is to get
> a notable person in the field to read the paper and check it, then put
> his name last on the authors.
So usual...
> Many of these problems can also be dealt with in another way: by using
> Conferences.
Hum, some begin to obtain similar problems and prefer to reject polemic
contributions
> > Also often some expertises valuates some work as wrong and then author
> > is considered a cranck before being recognized as brilliant.
>
> I don't think that's a very common problem. The more common problem is
> being considered to have little experience in the subject matter.
I think is exception, but one may recognize that expertise also can be
wrong.
> > If revolution is large then can be needed decades entires before the
> > work begin to be aknowledged.
> >
> > For large revolutions what change is that old guys dead and a new
> > generation of scientists born are trained in the new paradigm. For the
> > new generation the new paradigm is considered to be 'normal'. Old guys
> > usually never accept the new paradigm, therein the quote from the wiki.
>
> I don't think this is true. In my experience acceptance of new
> paradigms doesn't depend at all on age. I don't really know what
> governs acceptance of new ideas, but I'm pretty sure it's not that.
I agree with history perseverance is the key for revolutions. All
revolutions i know in physics or chemistry needed of decades before
being mainstream accepted.
Juan R. wrote:
> I thought during a while on why there exists a strong tendency to
> ignore the difficulties for publishing revolutionary theories in
> science. History of science has proved that any revolutionary (enough)
> theory is always initially rejected by colleagues, after ignored, but
> finally accepted.
Um, no.... Most revolutionary theories (example: Cold
Fusion) are in fact crap that don't hold up under serious
review and *deserve* to be ignored, and of those, thankfully,
most are never finally accepted. Some, despite being
demonstrably wrong, cater to people's deepest wishful thinking
(examples include Cold Fusion, ZPE, antigravity waves, perpetual
motion devices, etc) and keep coming back up despite vigorous
efforts to educate the public about their flaws. And many
are ignored, whether accepted or not, because they make no
predictions about observable phenomena and are therefore
completely untestable.
In the exceedingly rare case that a revolutionary theory is
not immediately disprovable and makes substantive predictions
about observable phenomena, and explains more than the previous
model explained or gets it right where the previous model got
it wrong, there is a great wailing and gnashing of teeth. The
process tries sorely the character of the scientists in the
field. The best and truest scientists, as well as the young
new scientists who are able to objectively evaluate both since
they've invested little in the old theory yet, immediately
drop the old theory and start using the new one. But some
scientists or more rigid thinkers have difficulty letting
go of the paradigms they've learnt and worked with, and in
particular, letting go of the untested assumptions on which
further results they've spent a lifetime obtaining were based.
If their character fails, then they reject the new theory
regardless of its merit because of emotional attachment to
their work which the new theory invalidates, and continue
to waste further years of their scientific effort. Such are
the casualties and wastes of such work. However, the new
theory, if it's better, is usually fully accepted by the
time a new generation of scientists have had time to grow
up.
> I think that rationality for hidding this continuous failure of
> scientific community is an attempt to hide the irrationality of the
> comunity itself when valuating some novel idea they have not diggested.
Imagine that you are Copernicus, a man who has spent his whole
life observing the planets. You have observed that their orbits
are not, as the ancients believed, circular, and that when they
are nearer the sun they seem to move faster. You have summoned
formidable mathematical skill and spent many years of cold nights
outside at hours when your body was demanding sleep, making tens of
thousands of observations, and finally you have developed a model
that explains their apparent movements using perfect spheres and
epicycles. This has been a whole life's work. Then when Kepler
comes along with his three laws of planetary motion, and Newton
backs up his math, all your work, that you spent years of your
life and pain obtaining, is out the window and will be forgotten.
Do you simply accept that your life's work will be added to
history's scrapheap and forgotten?
It is a test of your character. It is hard. It is painful.
But that is the way of the scientist, and the readiness to
throw out the entire canon of knowledge when a new theory
overturns it or the old theory is disproven, is what
distinguishes scientists from mere promulgators of a fixed
doctrine.
Bear
On Wed, 24 Jan 2007 19:26:26 +0100, Ray Dillinger <····@sonic.net> wrote:
> Juan R. wrote:
>
>> I thought during a while on why there exists a strong tendency to
>> ignore the difficulties for publishing revolutionary theories in
>> science. History of science has proved that any revolutionary (enough)
>> theory is always initially rejected by colleagues, after ignored, but
>> finally accepted.
>
> Um, no.... Most revolutionary theories (example: Cold
> Fusion) are in fact crap that don't hold up under serious
> review and *deserve* to be ignored, and of those, thankfully,
> most are never finally accepted. Some, despite being
> demonstrably wrong, cater to people's deepest wishful thinking
> (examples include Cold Fusion, ZPE, antigravity waves, perpetual
> motion devices, etc) and keep coming back up despite vigorous
> efforts to educate the public about their flaws. And many
> are ignored, whether accepted or not, because they make no
> predictions about observable phenomena and are therefore
> completely untestable.
>
Shows what you know.
1. There are good reason to think that cold fusion could be possible.
2. The rate at which galaxies are moving apart is accelerating..
How are you going to explain that without anti-gravity.
Science does indeed need to be sceptical to new ides.
But blatantly rejecting anything controversial out of
prejudice benefits no-one.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Fri, 26 Jan 2007 19:40:28 +0100, "John Thingstad"
<··············@chello.no> wrote:
>On Wed, 24 Jan 2007 19:26:26 +0100, Ray Dillinger <····@sonic.net> wrote:
>
>> Juan R. wrote:
>>
>>> I thought during a while on why there exists a strong tendency to
>>> ignore the difficulties for publishing revolutionary theories in
>>> science. History of science has proved that any revolutionary (enough)
>>> theory is always initially rejected by colleagues, after ignored, but
>>> finally accepted.
>>
>> Um, no.... Most revolutionary theories (example: Cold
>> Fusion) are in fact crap that don't hold up under serious
>> review and *deserve* to be ignored, and of those, thankfully,
>> most are never finally accepted. Some, despite being
>> demonstrably wrong, cater to people's deepest wishful thinking
>> (examples include Cold Fusion, ZPE, antigravity waves, perpetual
>> motion devices, etc) and keep coming back up despite vigorous
>> efforts to educate the public about their flaws. And many
>> are ignored, whether accepted or not, because they make no
>> predictions about observable phenomena and are therefore
>> completely untestable.
>>
>
>Shows what you know.
>1. There are good reason to think that cold fusion could be possible.
It's important to remember that cold fusion has yet to be conclusively
demonstrated and the mechanism explained. But it is interesting to
note that despite Ray's disgust, there are more than 100 teams
researching cold fusion, it has several peer reviewed journals of its
own, and a number of reviewed papers have appeared in mainstream
physics journals since the Pons/Fleischmann debacle - for which the
failure of reproducible results has been determined to be their use of
an open reaction vessel. More careful experiments done with closed
vessels have reproducibly shown various fusion byproducts, but as yet
the mechanism by which they are produced is unknown.
>2. The rate at which galaxies are moving apart is accelerating..
> How are you going to explain that without anti-gravity.
The reason is not anti-gravity, but another subject Ray denies - zero
point energy. According to theory, ZPE is the force responsible for
the expansion of space.
btw: physicists don't deny the possible existence of an opposing force
to gravity. Indeed the existence of such a force is required by some
dark matter/dark energy theories.
>Science does indeed need to be sceptical to new ides.
>But blatantly rejecting anything controversial out of
>prejudice benefits no-one.
Absolutely.
--
for email reply remove "/" from address
On Jan 27, 12:18 am, George Neuner <·········@comcast.net> wrote:
> >2. The rate at which galaxies are moving apart is accelerating..
> > How are you going to explain that without anti-gravity.The reason is not anti-gravity, but another subject Ray denies - zero
> point energy. According to theory, ZPE is the force responsible for
> the expansion of space.
>
> btw: physicists don't deny the possible existence of an opposing force
> to gravity. Indeed the existence of such a force is required by some
> dark matter/dark energy theories.
Speaking as a former cosmologist and QFT expert, I have no idea of what
you mean by ZPE, but
I suspect it is some clunky idea not to be confused with the vacuum
energy concept,
which is physically meaningful.
BTW, "Vacuum Energy" is a very unfortunate name: the point is that
empty space is not
empty, it is filled by fields, and these fields have energy. For
instance vacuum energy
explains the Casimir effect
(http://en.wikipedia.org/wiki/Casimir_effect). Its existence
if a very trivial consequence of quantum field theory and was predicted
60 years ago.
For what concerns the dark energy, the simplest explanation is to
assume the existence
of a slowly varying scalar field left there as a remnant of inflation.
This kind of a scalar field
can easily provide an equation of state corresponding to negative
pressure: see for instance
http://relativity.livingreviews.org/open?pubNo=lrr-2001-1&page=node21.html
Michele Simionato
<about zero-point-energy>
Uhm, looking at Wikipedia I see that zero-point-energy and vacuum
energy are considered the same,
even if I am familiar only with the vacuum energy term. Anyway, http://
en.wikipedia.org/wiki/Zero-point_energy
says
"""
Despite the definition, the concept of zero-point energy, and the hint
of a possibility of extracting "free energy" from the vacuum, has
attracted the attention of amateur inventors. Numerous perpetual
motion and other pseudoscientific devices, often called free energy
devices, exploiting the idea, have been proposed. As a result of this
activity, and its intriguing theoretical explanation, it has taken on
a life of its own in popular culture, appearing in science fiction
books, games and movies.
"""
and this explain why I had this impression that zero-point energy was
associated to clunky theories.
Anyway the Wikipedia article on the Casimir effect is pretty good, it
begins
"""
In physics, the Casimir effect is a physical force exerted between
separate objects, which is due to neither charge, gravity, nor the
exchange of particles, but instead is due to resonance of all-
pervasive energy fields in the intervening space between the objects.
This is sometimes described in terms of virtual particles interacting
with the objects, due to the mathematical form of one possible way of
calculating the strength of the effect.
"""
I personally dislike the description in terms of virtual particles,
which is common in divulgative books,
but it is no more grounded than "the mathematical form of one possible
way of calculating the
strength of the effect".
Michele Simionato
On 27 Jan 2007 03:06:19 -0800, ··················@gmail.com"
<·················@gmail.com> wrote:
>
>Uhm, looking at Wikipedia I see that zero-point-energy and vacuum
>energy are considered the same, even if I am familiar only with the
>vacuum energy term.
>Anyway, http://en.wikipedia.org/wiki/Zero-point_energy
>says
>
>"""
>Despite the definition, the concept of zero-point energy, and the hint
>of a possibility of extracting "free energy" from the vacuum, has
>attracted the attention of amateur inventors...
>"""
>
>and this explain why I had this impression that zero-point energy was
>associated to clunky theories.
Agreed. Whatever you choose to call it, "Zero Point" or "Vacuum"
energy has gotten a bad name due to the many ridiculous "inventions"
that purport to tap it as an inexhaustible power source.
As Scotty said in regard to Spock's plan to draw power from Hilbert
space to disrupt the Klingon mindshield over Organia - "I'd sooner
stick a 13 ampere tap directly into God".
George
--
for email reply remove "/" from address
a spitting image may hae the sme rsult
Cor
--
The biggest problem LISP has is that it does not apeal to dumb people
If this failed to satisfy you try reading the HyperSpec or woman frig
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Read the policy before mailing http://www.clsnet.nl/mail.html
On Jan 24, 7:26 pm, Ray Dillinger <····@sonic.net> wrote:
> Juan R. wrote:
> > I thought during a while on why there exists a strong tendency to
> > ignore the difficulties for publishing revolutionary theories in
> > science. History of science has proved that any revolutionary (enough)
> > theory is always initially rejected by colleagues, after ignored, but
> > finally accepted.
>
> Um, no....
My previous statement may be confusing. Of course, no any theory will
be accepted, I did mean theories after _proved to be correct_, but
initially rejected, i.e:
History of science has proved that any revolutionary (enough)
_correct_ theory is always initially rejected by colleagues, after
ignored, but finally accepted.
> Most revolutionary theories (example: Cold
> Fusion) are in fact crap that don't hold up under serious
> review and *deserve* to be ignored, and of those, thankfully,
> most are never finally accepted.
History of science is full of revolutionary theories initially
considered to be ignored. Zewail for instance said us how his initial
work was mainly ignored by his chemical colleagues and labelled as of
no importance for chemistry... after he won a Nobel for chemistry.
> Some, despite being
> demonstrably wrong,
Do you know how many important mathematicians and physicists claimed
demonstration that Newton was wrong ? In [1] you can read Clairaut,
Euler, and d'Alembert claiming that Newtonian law of gravity was
wrong. I read in some recent book on history that d'Alembert even
stated that they were so sure that Newton was wrong that no more
proofs or observations would be needed.
I can find similar stuff for each one of (then) revolutionary theories
on physics and chemistry since Newtonian age. Recently I did research
on adsorption kinetics where I was able to generalize SRT approach. Do
you know that 15 years ago had a strong debate between ART and SRT
comunities? Now it is aceppted that SRT work better than ART for a
large experimental range but a few years ago I read papers where it
was (authors believed) proved how wrong SRT was?
> cater to people's deepest wishful thinking
> (examples include Cold Fusion, ZPE, antigravity waves, perpetual
> motion devices, etc) and keep coming back up despite vigorous
> efforts to educate the public about their flaws.
About Cold Fusion, I am not an expert but despite initial flaw on
early Pons/Fleischmann communications, now the topic is being worked
by a large number of groups, and papers recently published in top
journals (including some with very heavy peer review procedure as
Science) claim experimental evidence for fusion or something unusual.
It is a very controversial topic, but far from being obviously wrong
or 'closed' as you appear to believe.
> In the exceedingly rare case that a revolutionary theory is
> not immediately disprovable and makes substantive predictions
> about observable phenomena, and explains more than the previous
> model explained or gets it right where the previous model got
> it wrong, there is a great wailing and gnashing of teeth. The
> process tries sorely the character of the scientists in the
> field. The best and truest scientists, as well as the young
> new scientists who are able to objectively evaluate both since
> they've invested little in the old theory yet, immediately
> drop the old theory and start using the new one.
There are times where a theory is rejected during decades by both old
and youngs; Onsager theory (won Nobel Prize) was ignored during two or
three decades. Also there are cases where the revolutionary theories
are pursued by old people and young scientists reject it.
> But some
> scientists or more rigid thinkers have difficulty letting
> go of the paradigms they've learnt and worked with, and in
> particular, letting go of the untested assumptions on which
> further results they've spent a lifetime obtaining were based.
>
> If their character fails, then they reject the new theory
> regardless of its merit because of emotional attachment to
> their work which the new theory invalidates, and continue
> to waste further years of their scientific effort. Such are
> the casualties and wastes of such work. However, the new
> theory, if it's better, is usually fully accepted by the
> time a new generation of scientists have had time to grow
> up.
Here I agree, no matter how many proofs are presented to old scientist
often they never accept the new revolutionary theory.
> > I think that rationality for hidding this continuous failure of
> > scientific community is an attempt to hide the irrationality of the
> > comunity itself when valuating some novel idea they have not diggested.
>
> Imagine that you are Copernicus, a man who has spent his whole
> life observing the planets. You have observed that their orbits
> are not, as the ancients believed, circular, and that when they
> are nearer the sun they seem to move faster. You have summoned
> formidable mathematical skill and spent many years of cold nights
> outside at hours when your body was demanding sleep, making tens of
> thousands of observations, and finally you have developed a model
> that explains their apparent movements using perfect spheres and
> epicycles. This has been a whole life's work. Then when Kepler
> comes along with his three laws of planetary motion, and Newton
> backs up his math, all your work, that you spent years of your
> life and pain obtaining, is out the window and will be forgotten.
> Do you simply accept that your life's work will be added to
> history's scrapheap and forgotten?
Personally, I would be the first interested in finding my errors, but
well, probably it is a question of character. But it may be noticed
that I call myself ignorant often; that is not a common attitude
between my colleagues.
[1] http://www-history.mcs.st-andrews.ac.uk/Biographies/Clairaut.html
····@stablecross.com (Bob Felts) writes:
> Juan R. <··············@canonicalscience.com> wrote:
>
>> Bob Felts ha escrito:
>>
>> > There isn't a lot of difference between 'average' and 'mediocre', is
>> > there?
>>
>> Here yes. Mediocre is used as a kind of insult. Average is used in
>> sense of 'normal'.
>>
>
> Mediocre comes from the Latin and means, "middle height or degree". So
> it does mean the same as "average". Both mean "not very good" (as well
> as "not very bad").
So when you think about it, 'normal' is rather insulting, in general... ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.
Jon Harrop wrote:
> Sacha wrote:
>
>>Well, a new language needs to start somewhere doesn't it ?
>
>
> Absolutely.
>
>
>>Are you saying we should stop researching new programming languages ?
>
>
> Not at all. I'm saying that a bigger user base instills more confidence when
> choosing a language.
>
Of course. New languages get picked up first by crazed early adopters
who will try anything. Things grow from there or not until second and
third tier groups sign on (I forget the names they were given in
Crossing the Chasm (and I am not sure of that name either)).
I would say book authors come last, but I have two books for Curl
somewhere. That was probably an attempt to jumpstart growth.
It is not a problem for builders of new language if managers who work in
tall buildings do not adopt, it is a problem if the nutjobs do not give
it a try. Or blog about it.
ken
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
Ken Tilton ha escrito:
> The Dalai Lama gets the same crap all the time.
> -- Kenny Tilton on c.l.l when accused of immodesty
Tilton? Who is?
-- The Dalai Lama when named by Ken Tilton
Ken Tilton <·········@gmail.com> wrote on Fri, 22 Dec 2006:
> Of course. New languages get picked up first by crazed early adopters who
> will try anything. Things grow from there or not until second and third tier
> groups sign on (I forget the names they were given in Crossing the Chasm (and
> I am not sure of that name either)).
"Crossing the Chasm", by Geoffrey Moore:
http://en.wikipedia.org/wiki/Crossing_the_Chasm
The market segments were: innovators, early adopters, early majority, late
majority and laggards. The names themselves and the original analysis was
actually about the adoption of new strains of grains among farmers. Moore
applied those insights to the introduction of any discontinuous technology,
particularly in high-tech.
The main thesis of the book was that a "chasm" exists between the needs of
the first two groups (who are gung-ho about new technology), vs. the third
(and later) group(s) where the majority of people are. The later groups are
looking to have a problem solved, and couldn't care less about old vs. new
technology.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Sometimes I lie awake at night and ask "Why me?" Then a voice answers
"Nothing personal, your name just happened to come up."
-- Charlie Brown, _Peanuts_ [Charles Schulz]
Jon Harrop wrote:
> Sacha wrote:
> > Well, a new language needs to start somewhere doesn't it ?
>
> Absolutely.
>
> > Are you saying we should stop researching new programming languages ?
>
> Not at all. I'm saying that a bigger user base instills more confidence when
> choosing a language.
I look for the implementation base: how many times has the language
been independently implemented, and to what extent it is standardized.
Wortwhile languages are invariably implemented many times over again,
and eventually standardized by a major national or international body.
This measure is better than user base because it roughly estimates the
size of that fraction of the user base which matters. A programming
language user only matters if that user has a clue, and has influence.
By this criterion, most of the programming user base of a programming
language contributes nothing to it. This includes even most of the good
programmers; the ones who just throw their hands up in the air, fight
through issues, develop workarounds and ship the product.
Good software is developed /in spite/ of the tools.
Jon Harrop <···@ffconsultancy.com> writes:
> > Are you saying we should stop researching new programming languages ?
>
> Not at all. I'm saying that a bigger user base instills more
> confidence when choosing a language.
I'm just now reading Ayn Rand's "The Fountainhead".
May I perhaps recommend it to you? It's quite an interesting read.
And very apropos.
On 2007-05-11 15:24:25 +0100, Kent M Pitman <······@nhplace.com> said:
> Jon Harrop <···@ffconsultancy.com> writes:
>
>>> Are you saying we should stop researching new programming languages ?
>>
>> Not at all. I'm saying that a bigger user base instills more
>> confidence when choosing a language.
>
> I'm just now reading Ayn Rand's "The Fountainhead".
> May I perhaps recommend it to you? It's quite an interesting read.
> And very apropos.
As much as I enjoyed it back then, it suffers from a fatal
flaw: "they ended up well, and had numerous children" :-(
But "Atlas Shrugged", being less positive, is probably more
to the point: live your ideal, and dpn't bother checking whether
you've got any following: it's not worth it. Hapyness is an
individual thing, which almost by definition, cannot be shared.
My 2p :)
--
JFB
Jon Harrop wrote:
>
> IMO, OCaml is at the limit of these things. I would not write a book "Qi for
> Scientists", for example, because I don't believe enough people would buy
> it. I'm only writing "F# for Scientists" because I believe F# will become
> the most popular ML/Haskell/Lisp/Scheme over the next 3 years.
I doubt that, you can not even use F# to write a Concentration Game.
Wade
Pascal Costanza wrote:
> Paul Rubin wrote:
>
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>> May you have tried the wrong Lisp dialects so far:
>>>
>>> (loop for i from 2 to 10 by 2
>>> do (print i))
>>
>>
>> The loop language is so complicated and confusing that I never
>> bothered trying to learn it.
That was my stance for about seven years of intense Lisp. Then the
author of Practical Common Lisp did a nice job of breaking the whole
mess up into sensible chunks and I picked it up. If one programs Lisp,
one should learn Loop -- it is definitely worth the bother. I def regret
not learning it sooner.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> >> The loop language is so complicated and confusing that I never
> >> bothered trying to learn it.
>
> That was my stance for about seven years of intense Lisp. Then the
> author of Practical Common Lisp did a nice job of breaking the whole
> mess up into sensible chunks and I picked it up. If one programs Lisp,
> one should learn Loop -- it is definitely worth the bother. I def
> regret not learning it sooner.
I don't really code in Lisp any more, I never felt a need for loop
when I was coding in Lisp, and I'm trying to move towards a style of
programming without loops (i.e. I'm playing with Haskell, which
doesn't have loops), giving me even less need for a hairy loop macro.
Paul Rubin wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>>>The loop language is so complicated and confusing that I never
>>>>bothered trying to learn it.
>>
>>That was my stance for about seven years of intense Lisp. Then the
>>author of Practical Common Lisp did a nice job of breaking the whole
>>mess up into sensible chunks and I picked it up. If one programs Lisp,
>>one should learn Loop -- it is definitely worth the bother. I def
>>regret not learning it sooner.
>
>
> I don't really code in Lisp any more, I never felt a need for loop
> when I was coding in Lisp, and I'm trying to move towards a style of
> programming without loops (i.e. I'm playing with Haskell, which
> doesn't have loops), giving me even less need for a hairy loop macro.
Oh, my. time to trot out my "hey, X is cool, let's use it for
everything!" rant.
Freud may not have said, "Sometimes a cigar is just a cigar.", but
sometimes (er, always) iteration is best handled with an iteration
construct. Any craftsman can tell you, use the right tool for the job.
the nice thing about Lisp's many paradigms is that the developer does
not become a slave to any paradigm. I think all-rules-all-the-time
Prolog is the poster boy for paradigm slavery. (I did try for a famous
two months to use Prolog as a general-purpose programming language.)
Just the sentence "I'm trying to program without loops" simply screams
"category error", if you think about it. Mind you, I had great fun using
a Logo which did not have iteration. Now I have fun with CL. They call
it a big ball of mud, but I do not thnk there is a tool in that chest I
have not used, just because that tool fit the problem best.
It only looks like a ball of mud if one does not right much code, and
that describes most Lispniks, so no wonder we ended up with Scheme.
Oops, wrong flamewar.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> Oh, my. time to trot out my "hey, X is cool, let's use it for
> everything!" rant.
Somehow it's something other than a rant if X is Lisp?
Paul Rubin wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>Oh, my. time to trot out my "hey, X is cool, let's use it for
>>everything!" rant.
>
>
> Somehow it's something other than a rant if X is Lisp?
Ah, your discriminator misfired. Keep your eye on the bouncing rant:
I was not espousing any language, I was espousing matching the tool to
the task. That segued into my Lisp ball of mud rant, but, hell, even C
offers iteration along with recursion. That observation turns the rant
back on all-x-all-the-time languages, including I would note Steele's
constraint programming language, which at first used a constraint to do
variable assignment. Speaking of Cells...
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Markus Triska
Subject: Re: merits of Lisp vs Python
Date:
Message-ID: <87r6v4cxl5.fsf@gmx.at>
Ken Tilton <·········@gmail.com> writes:
> I think all-rules-all-the-time Prolog is the poster boy for paradigm
> slavery. (I did try for a famous two months to use Prolog as a
> general-purpose programming language.)
Don't expect to learn Prolog properly in so little time. To your
previous question whether the ~180 lines of Lisp code in some online
book constitute an "industrial strength" Prolog: only if the following
~180 lines of Prolog code implement an "industrial strength" Lisp.
ws --> [W], { W =< 0' }, ws.
ws --> [].
open_paren --> ws, "(", ws.
close_paren --> ws, ")", ws.
parse(String, Expr) :- phrase(expressions(Expr), String).
list(Es) --> open_paren, expressions(Es), close_paren.
expressions([E|Es]) -->
expression(E), ws,
!, % single solution: longest input match
expressions(Es).
expressions([]) --> [].
expression(symbol(A)) --> symbol(A0), { name(A, A0) }.
expression(number(N)) --> number(N0), { name(N, N0) }.
expression(List) --> list(List).
expression([symbol(quote),Q]) --> "'", expression(Q).
number([D|Ds]) --> digit(D), number(Ds).
number([D]) --> digit(D).
digit(D) --> [D], {0'0 =< D, D =< 0'9 }.
symbol([A|As]) -->
[A],
{ memberchk(A, "+/-*><=abcdefghijklmnopqrstuvwxyz") },
symbolr(As).
symbolr([A|As]) -->
[A],
{ memberchk(A, "+/-*><=abcdefghijklmnopqrstuvwxyz0123456789") },
symbolr(As).
symbolr([]) --> [].
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Interpretation
--------------
Declaratively, execution of a Lisp form establishes a relation
between the (function and variable) binding environment before its
execution and the environment after its execution. A Lisp program
is a sequence of Lisp forms, and its result is the sequence of
their results. Initially, the environment is empty.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
run(Program, Values) :-
parse(Program, Forms0),
empty_assoc(E),
compile_all(Forms0, Forms),
eval_all(Forms, E, _, E, _, Values).
fold([], _, V, V).
fold([F|Fs], Op, V0, V) :- E =.. [Op,V0,F], V1 is E, fold(Fs, Op, V1, V).
compile_all(Fs0, Fs) :- maplist(compile, Fs0, Fs).
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
compile/2 marks (with "user/1") calls of user-defined functions.
This eliminates an otherwise defaulty representation of function
calls and thus allows for first argument indexing in eval/7.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
compile(F0, F) :-
( F0 = number(_) -> F = F0
; F0 = symbol(t) -> F = t
; F0 = symbol(nil) -> F = nil
; F0 = symbol(_) -> F = F0
; F0 = [] -> F = []
; F0 = [symbol(quote)|Args] -> F = [quote|Args]
; F0 = [symbol(setq),symbol(Var),Val0] ->
compile(Val0, Val),
F = [setq,Var,Val]
; F0 = [symbol(Op)|Args0],
memberchk(Op, [+,-,*,equal,if,>,<,=,progn,eval,list,car,cons,
cdr,while,not]) ->
compile_all(Args0, Args),
F = [Op|Args]
; F0 = [symbol(defun),symbol(Name),Args0|Body0] ->
compile_all(Body0, Body),
maplist(un_symbol, Args0, Args),
F = [defun,Name,Args|Body]
; F0 = [symbol(Op)|Args0] ->
compile_all(Args0, Args),
F = [user(Op)|Args]
).
un_symbol(symbol(S), S).
eval_all([], Fs, Fs, Vs, Vs, []).
eval_all([A|As], Fs0, Fs, Vs0, Vs, [B|Bs]) :-
eval(A, Fs0, Fs1, Vs0, Vs1, B),
eval_all(As, Fs1, Fs, Vs1, Vs, Bs).
eval(number(N), Fs, Fs, Vs, Vs, N).
eval(t, Fs, Fs, Vs, Vs, t).
eval(nil, Fs, Fs, Vs, Vs, nil).
eval(symbol(A), Fs, Fs, Vs, Vs, V) :- get_assoc(A, Vs, V). % variable lookup
eval([L|Ls], Fs0, Fs, Vs0, Vs, Value) :- eval(L, Ls, Fs0, Fs, Vs0, Vs, Value).
eval(+, Args0, Fs0, Fs, Vs0, Vs, Value) :-
eval_all(Args0, Fs0, Fs, Vs0, Vs, Args),
fold(Args, (+), 0, Value).
eval(-, [V0|Rest], Fs0, Fs, Vs0, Vs, Value) :-
eval(V0, Fs0, Fs1, Vs0, Vs1, V1),
eval_all(Rest, Fs1, Fs, Vs1, Vs, Vals),
fold(Vals, (-), V1, Value).
eval(*, Args0, Fs0, Fs, Vs0, Vs, Value) :-
eval_all(Args0, Fs0, Fs, Vs0, Vs, Args),
fold(Args, (*), 1, Value).
eval(equal, [A0,B0], Fs0, Fs, Vs0, Vs, Value) :-
eval(A0, Fs0, Fs1, Vs0, Vs1, A),
eval(B0, Fs1, Fs, Vs1, Vs, B),
( A == B -> Value = t ; Value = nil ).
eval(if, [Cond,Then|Else], Fs0, Fs, Vs0, Vs, Value) :-
eval(Cond, Fs0, Fs1, Vs0, Vs1, V),
( V = nil ->
eval_all(Else, Fs1, Fs, Vs1, Vs, Values),
last(Values, Value)
; eval(Then, Fs1, Fs, Vs1, Vs, Value)
).
eval(not, [Arg], Fs0, Fs, Vs0, Vs, Value) :-
eval(Arg, Fs0, Fs, Vs0, Vs, V),
( V == nil -> Value = t ; Value = nil ).
eval(>, [Arg1,Arg2], Fs0, Fs, Vs0, Vs, Value) :-
eval(Arg1, Fs0, Fs1, Vs0, Vs1, V1),
eval(Arg2, Fs1, Fs, Vs1, Vs, V2),
( V1 > V2 -> Value = t ; Value = nil ).
eval(<, [Arg1,Arg2], Fs0, Fs, Vs0, Vs, Value) :-
eval(Arg1, Fs0, Fs1, Vs0, Vs1, V1),
eval(Arg2, Fs1, Fs, Vs1, Vs, V2),
( V1 < V2 -> Value = t ; Value = nil ).
eval(=, [Arg1,Arg2], Fs0, Fs, Vs0, Vs, Value) :-
eval(Arg1, Fs0, Fs1, Vs0, Vs1, V1),
eval(Arg2, Fs1, Fs, Vs1, Vs, V2),
( V1 =:= V2 -> Value = t ; Value = nil ).
eval(progn, Ps, Fs0, Fs, Vs0, Vs, Value) :-
eval_all(Ps, Fs0, Fs, Vs0, Vs, Values),
last(Values, Value).
eval(eval, [Form0], Fs0, Fs, Vs0, Vs, V) :-
eval(Form0, Fs0, Fs1, Vs0, Vs1, Form1),
compile(Form1, Form2),
eval(Form2, Fs1, Fs, Vs1, Vs, V).
eval(quote, [Q], Fs, Fs, Vs, Vs, Q).
eval(setq, [Var,V0], Fs0, Fs, Vs0, Vs, V) :-
eval(V0, Fs0, Fs, Vs0, Vs1, V),
put_assoc(Var, Vs1, V, Vs).
eval(defun, [Func,Args|Body], Fs0, Fs, Vs, Vs, Func) :-
put_assoc(Func, Fs0, Args-Body, Fs).
eval(list, Ls0, Fs0, Fs, Vs0, Vs, Ls) :-
eval_all(Ls0, Fs0, Fs, Vs0, Vs, Ls).
eval(cons, [Car0,Cdr0], Fs0, Fs, Vs0, Vs, [Car|Cdr]) :-
eval(Car0, Fs0, Fs1, Vs0, Vs1, Car),
eval(Cdr0, Fs1, Fs, Vs1, Vs, Cdr).
eval(car, [Ls0], Fs0, Fs, Vs0, Vs, Car) :-
eval(Ls0, Fs0, Fs, Vs0, Vs, [Car|_]).
eval(cdr, [Ls0], Fs0, Fs, Vs0, Vs, Cdr) :-
eval(Ls0, Fs0, Fs, Vs0, Vs, [_|Cdr]).
eval(while, [Cond|Body], Fs0, Fs, Vs0, Vs, Value) :-
eval(Cond, Fs0, Fs1, Vs0, Vs1, V),
( V == nil -> Value = nil, Fs = Fs0, Vs = Vs0
; eval_all(Body, Fs1, Fs2, Vs1, Vs2, _),
eval(while, [Cond|Body], Fs2, Fs, Vs2, Vs, Value)
).
eval(user(F), Args0, Fs0, Fs, Vs0, Vs, Value) :-
eval_all(Args0, Fs0, Fs, Vs0, Vs, Args),
get_assoc(F, Fs, As-Body),
empty_assoc(E),
bind_arguments(As, Args, E, Bindings),
eval_all(Body, Fs, _, Bindings, _, Results),
last(Results, Value).
bind_arguments([], [], Bs, Bs).
bind_arguments([A|As], [V|Vs], Bs0, Bs) :-
put_assoc(A, Bs0, V, Bs1),
bind_arguments(As, Vs, Bs1, Bs).
They give you a simple Lisp and, in contrast to some online books
claiming to give you "Prolog" (an ISO-standardised language) and then
failing to even parse a single proper Prolog term, also let you write
it in its natural form. Example queries tested with SWI Prolog:
"append":
?- run("(defun append (x y) (if (equal x '()) y (cons (car x) (append (cdr x) y)))) (append '(1 2 3) '(4 5))", V).
==> V = [append, [number(1), number(2), number(3), number(4), number(5)]] ;
Fibonacci, naive version:
?- time(run("(defun fib (n) (if (= 0 n) 0 (if (= 1 n) 1 (+ (fib (- n 1)) (fib (- n 2)))))) (fib 24)", V)).
==> V = [fib, 46368] ;
9,567,271 inferences, 3.42 CPU in 3.50 seconds (98% CPU, 2797448 Lips)
Different version:
?- time(run("(defun fib (n) (if (= 0 n) 0 (fib1 0 1 1 n))) (defun fib1 (f1 f2 i to) (if (= i to) f2 (fib1 f2 (+ f1 f2) (+ i 1) to))) (fib 100)", V)).
==> 16,275 inferences, 0.01 CPU in 0.01 seconds (163% CPU, 1627500 Lips)
V = [fib, fib1, 354224848179261915075] ;
Using a while loop:
?- time((run("(defun fib (n) (setq f (cons 0 1)) (setq i 0) (while (< i n) (setq f (cons (cdr f) (+ (car f) (cdr f)))) (setq i (+ i 1))) (car f)) (fib 200)", V))).
==> 20,509 inferences, 0.02 CPU in 0.01 seconds (239% CPU, 1025450 Lips)
V = [fib, 280571172992510140037611932413038677189525] ;
Showing "eval" and "map":
?- run("(defun map (f xs) (if (equal xs '()) '() (cons (eval (list f (car xs))) (map f (cdr xs))))) (defun plus1 (x) (+ 1 x)) (map 'plus1 '(1 2 3))", Vs).
==> Vs = [map, plus1, [2, 3, 4]] ;
Prolog's analogon to Lisp's macros is term_expansion/2 by the way.
All the best!
Markus Triska
Markus Triska wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>I think all-rules-all-the-time Prolog is the poster boy for paradigm
>>slavery. (I did try for a famous two months to use Prolog as a
>>general-purpose programming language.)
>
>
> Don't expect to learn Prolog properly in so little time.
Lawdy, no, but I had all those Art of Prolog and Craft of Prolog and a
couple other books and I was staring at pages of intense code just
trying to do basic stuff. I had not learned prolog, but I could see the
masters writing hairy code to basic stuff so I concluded...run away! run
away! :)
I think the other thing that got me was cuts, which I translated as "did
we say unification all the time? sorry..." :)
> To your
> previous question whether the ~180 lines of Lisp code in some online
> book constitute an "industrial strength" Prolog: only if the following
> ~180 lines of Prolog code implement an "industrial strength" Lisp.
<snip lisp-in-Prolog>
Way cool.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Thomas Lindgren
Subject: Re: merits of Lisp vs Python
Date:
Message-ID: <877iwwypm6.fsf@dev.null>
Ken Tilton <·········@gmail.com> writes:
> Markus Triska wrote:
> > Ken Tilton <·········@gmail.com> writes:
> >
> >>I think all-rules-all-the-time Prolog is the poster boy for paradigm
> >>slavery. (I did try for a famous two months to use Prolog as a
> >>general-purpose programming language.)
> > Don't expect to learn Prolog properly in so little time.
>
> Lawdy, no, but I had all those Art of Prolog and Craft of Prolog and a
> couple other books and I was staring at pages of intense code just
> trying to do basic stuff. I had not learned prolog, but I could see
> the masters writing hairy code to basic stuff so I concluded...run
> away! run away! :)
>
> I think the other thing that got me was cuts, which I translated as
> "did we say unification all the time? sorry..." :)
(Were the cuts red or green?)
Prolog was always difficult to teach (and learn). My best guess was
that, when presenting it, we got into backtracking too soon: it's all
too easy to write horrendously inefficient code as a beginner. Even
worse to spend so much time on it when real-world Prolog programming
tended to avoid backtracking search whenever possible.
More time with logic variables first might have been worth the
effort. Logic variables (and a smidgeon of impurity) are an
interesting compromise between the declarative and the imperative.
Also, Prolog is one of a very few select languages (ahem) where syntax
and syntax trees are nearly the same. A Prolog clause
H :- B1,...,Bn.
is also just an infix notation for the term
':-'(H, ','(B1, ','(B2, ... (Bn))))
Not quite as flexible as Lisp (no ,@), but as near as any other
language I know.
Best,
Thomas
--
Thomas Lindgren
"Ever tried. Ever failed. No matter. Try again. Fail again. Fail better."
Markus Triska schrieb:
> Ken Tilton <·········@gmail.com> writes:
>
>> I think all-rules-all-the-time Prolog is the poster boy for paradigm
>> slavery. (I did try for a famous two months to use Prolog as a
>> general-purpose programming language.)
>
> Don't expect to learn Prolog properly in so little time. To your
> previous question whether the ~180 lines of Lisp code in some online
> book constitute an "industrial strength" Prolog: only if the following
> ~180 lines of Prolog code implement an "industrial strength" Lisp.
Hallo, you are of course right. There are some prolog implementations
for Lisp that implement some parts of Prolog. To get the full thing one
would of course need a big lot more of work.
The idea is to get the basic constructs of Prolog available for Lisp.
And with 2k LOC there are already some nice things that one can do.
Those who know the paradigm of logical programming can recognize that
a problem falls into this domain and then use inside of Lisp some tools
that allow to express the problem in this domain specific language.
If one really wants/needs Prolog then one should use it ;)
The Prolog implementations are much more efficient and very stable.
But often even 60% of Prolog are so expressive, that it can be a real
productivity booster.
Andr�
--
Ken Tilton wrote:
[...]
> That was my stance for about seven years of intense Lisp. Then the
> author of Practical Common Lisp did a nice job of breaking the whole
> mess up into sensible chunks and I picked it up. If one programs Lisp,
> one should learn Loop -- it is definitely worth the bother. I def regret
> not learning it sooner.
When I first read PCL (which was my introduction to Lisp) I thought
LOOP was really neato. Once I actually started using it for things that
weren't so simple, I began to really hate it. I think that having a
specialized mini-language for iteration is a superb idea, but I don't
think LOOP is it.
That being said, there's a portable alternatives out there that I like
way better, and I still use LOOP for dashing stuff off one-liners at
the REPL.
Cheers,
Pillsy
Pillsy wrote:
> Ken Tilton wrote:
> [...]
>> That was my stance for about seven years of intense Lisp. Then the
>> author of Practical Common Lisp did a nice job of breaking the whole
>> mess up into sensible chunks and I picked it up. If one programs Lisp,
>> one should learn Loop -- it is definitely worth the bother. I def regret
>> not learning it sooner.
>
> When I first read PCL (which was my introduction to Lisp) I thought
> LOOP was really neato. Once I actually started using it for things that
> weren't so simple, I began to really hate it. I think that having a
> specialized mini-language for iteration is a superb idea, but I don't
> think LOOP is it.
>
> That being said, there's a portable alternatives out there that I like
> way better, and I still use LOOP for dashing stuff off one-liners at
> the REPL.
If you hate LOOP then you don't have to use it.
There's an important lesson to learn here: Not all language constructs
are supposed to be loved by everyone. ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Pillsy wrote:
[...]
> > When I first read PCL (which was my introduction to Lisp) I thought
> > LOOP was really neato. Once I actually started using it for things that
> > weren't so simple, I began to really hate it. I think that having a
> > specialized mini-language for iteration is a superb idea, but I don't
> > think LOOP is it.
> > That being said, there's a portable alternatives out there that I like
> > way better, and I still use LOOP for dashing stuff off one-liners at
> > the REPL.
> If you hate LOOP then you don't have to use it.
Indeed, I *don't* use it except for the simplest things.
> There's an important lesson to learn here: Not all language constructs
> are supposed to be loved by everyone. ;)
Especially in Common Lisp, where it's possible to have replacements
that integrate with the rest of the language as seamlessly as the
original feature they're replacing.
I don't love CL because its devoid of features I hate. I love it
because it provides so many great ways of getting around the features I
hate. If it didn't have features I hate, I might actually like it less,
because I wouldn't have anything to bitch about on USENET. :)
Cheers,
Pillsy
Paul Rubin <·············@NOSPAM.invalid> writes:
> Pascal Costanza <··@p-cos.net> writes:
>> May you have tried the wrong Lisp dialects so far:
>>
>> (loop for i from 2 to 10 by 2
>> do (print i))
>
> The loop language is so complicated and confusing that I never
> bothered trying to learn it. I always used simpler primitives to
> write loops and it was always enough.
I think you're missing out. If you don't find LOOP appealing, look
for the ITERATE package. ITERATE is a more Lispy, more extensible
replacement for LOOP.
>> This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
>> you should implement this using recursion, but you really don't have
>> to. ;)
>
> You can't really use that much recursion in Lisp because of the lack
> of guaranteed TCO. I think that makes it reasonable to say that
> Scheme is a functional language but Lisp is not. ("Functional" = it's
> reasonable to code in a style where the only way to connect variables
> to values is lambda binding (maybe through syntax sugar), so all loops
> are implemented with recursion).
You should be pragmatic about this - I have never used a CL
implementation that didn't do TCO optimization (indeed, are there
any?). Although the standard doesn't require it, I treat it as a de
facto requirement and don't worry too much about it.
Bill Atkins <······@rpi.edu> writes:
> You should be pragmatic about this - I have never used a CL
> implementation that didn't do TCO optimization (indeed, are there
> any?). Although the standard doesn't require it, I treat it as a de
> facto requirement and don't worry too much about it.
I have to confess that most of the Lisp code I've written were on
simpler dialects that didn't have TCO. But I'm not sure if the CL
implementations I've used (KCL back in the day, and CLISP a little
bit) had it either.
I V wrote:
> To be a little provocative, I wonder if the idea that you're "talking to
> the interpreter" doesn't apply more to lisp than to python; you can have
> any syntax you like, as long as it looks like an AST.
Actually, that is false. You can have any syntax you like in Common
Lisp. For instance, the syntax of Python:
http://trac.common-lisp.net/clpython/
What thesaurus are you using which lists "provocative" as a synonym for
"uninformed"?
I V <········@gmail.com> writes:
> On Sun, 10 Dec 2006 03:18:07 -0500, Bill Atkins wrote:
>> We're not counting lines here, you goon. We're talking about how
>> expressive constructs are and how closely they match your concept of
>> what you want to do. The conditional example is lower-level; you're
>> talking to the interpreter instead of saying what you want to achieve.
>> You're having to repeat things because that's what the language asks
>> of you, instead of describing in a higher-level way what you're
>> actually doing.
>
> To be a little provocative, I wonder if the idea that you're "talking to
> the interpreter" doesn't apply more to lisp than to python; you can have
> any syntax you like, as long as it looks like an AST.
Uhhh?
> One of the things I've always found off-putting about lisp as that all the
> syntax looks the same. In Algol-derived languages, each syntactic
> construct has a fairly distinctive appearance, so when, for instance, I
> encounter a for loop, I can quickly recognize that that's what it is, and
> bracket out the "scaffolding" and pick out the details that interest me.
> With lisp, I can't do that, I have to read through the sexp, decide on
> what syntax it is, and then remind myself where to look for the relevant
> specific details.
"Decide on what syntax it is"? Examples?
> Now, this might well be just due to my comparative lack of familiarity
> with lisp; I'd be interested to hear if you lisp people find different
> lisp constructs as visually distinctive as constructs in python (or other
> similar languages). But I think what people are getting at when they
> complain about "all the brackets" in lisp may actually be this issue of
> a visual distinction between different constructs (this is also a reason
> why having a limited number of syntactic constructs can be helpful - there
> are a probably a limited number of stereotypical layouts a programmer can
> keep in their mind at once).
We rely on indentation for readability just as you guys do. Lisp
programs are not chaotic arrangements of parentheses and symbols; code
structure is made apparent through indentation.
(Why are people from c.l.p calling parentheses "brackets"?)
Bill Atkins wrote:
> (Why are people from c.l.p calling parentheses "brackets"?)
Because that's what they are often called outside of the various
literate fields.
[Bill Atkins]
>> (Why are people from c.l.p calling parentheses "brackets"?)
[Kaz Kylheku]
> Because that's what they are often called outside of the various
> literate fields.
For example, the English are "outside of the various literate fields"?
FWIW, Python documentation consistently uses the jargon:
() parentheses
{} braces
[] brackets
That matches North American conventions, but occasionally confuses an
international audience (for example, the English call parentheses
"brackets" or "round brackets").
There's also a long tradition in both mathematics and computer science
of using "bracket" as a generic term for any syntactic device used in
pairs. For example, the "Revised Report on the Algorithmic Language
Algol 60" way back in 1963 even called "begin" and "end" brackets. If
it's tempting to call the authors of that illiterate too, keep in mind
that John McCarthy was one of them -- although I'm sure Peter Naur
would be willing to take the blame for dumbing it down for Europeans ;-)
··········@gmail.com ha escrito:
> FWIW, Python documentation consistently uses the jargon:
>
> () parentheses
> {} braces
> [] brackets
>
> That matches North American conventions, but occasionally confuses an
> international audience (for example, the English call parentheses
> "brackets" or "round brackets").
>
> There's also a long tradition in both mathematics and computer science
> of using "bracket" as a generic term for any syntactic device used in
> pairs.
Brackets are unequal paired syntatic delimiters used for packaging.
Quotations marks "string" or exclamation marks �Esto es espa�ol! are
used in pairs but not are brackets.
A natural convention is brackets = ( ), [ ], { }, < >
( ) parentheses or round brackets
{ } braces or curly brackets
[ ] box or square brackets
< > chevrons or angle brackets
A English calling "brackets" or "round brackets" to the parentheses is
doing nothing wrong, but brackets are not parentheses.
In mathematics the braces are also often called brackets and again that
is not wrong.
Actually, in English, "parenthesis" means the bit in between the
brackets.
The various kinds of brackets (amongst other punctuation marks
including, in most english texts, commas) *demarcate* parentheses.
Wikipedia's "Parenthesis (rhetoric)" is, at time of writing, the correct
British English definition, citing the OED:
http://en.wikipedia.org/wiki/Parenthesis_%28rhetoric%29
"An explanatory or qualifying word, clause, or sentence inserted into a
passage with which it has not necessarily any grammatical connection,
and from which it is usually marked off by round or square brackets,
dashes, or commas"
The use of round brackets to demarcate parentheses in america eventually
somehow led to round brackets themselves being called parentheses in
america, but that usage still makes little sense to many native
speakers of British (or Hiberno-) English outside the computing field.
It's like calling a quotation mark a "quote" instead of a "quotation
mark". And lo, guess who does that too...
Calling round brackets "parenthesis marks" would be acceptable but
perhaps ambiguous in British English, probably needing further
qualification like "double quotation mark", "single quotation mark".
David Golden wrote:
> Actually, in English, "parenthesis" means the bit in between the
> brackets.
>
> The various kinds of brackets (amongst other punctuation marks
Actually, it's 'among', not 'amongst', except to those who are lisping,
degenerate pansies.
Charles Lamb:
I loved a love once, fairest among women
Edward FitzGerald:
Among the Guests Star-scatter'd on the Grass
Similarly, it's 'while', not 'whilst'.
A. E. Housman:
While the hive of hell within
Sent abroad a seething hum
As of towns whose king is come
Leading conquest home from far
And the captives of his war,
> including, in most english texts, commas) *demarcate* parentheses.
>
> Wikipedia's "Parenthesis (rhetoric)" is, at time of writing, the correct
> British English definition, citing the OED:
> http://en.wikipedia.org/wiki/Parenthesis_%28rhetoric%29
>
> "An explanatory or qualifying word, clause, or sentence inserted into a
> passage with which it has not necessarily any grammatical connection,
> and from which it is usually marked off by round or square brackets,
> dashes, or commas"
>
> The use of round brackets to demarcate parentheses in america eventually
> somehow led to round brackets themselves being called parentheses in
> america, but that usage still makes little sense to many native
> speakers of British (or Hiberno-) English outside the computing field.
Actually, you're absolutely wrong, utterly ignorant, and egregiously
arrogant.
According to Paley, the Bishop was once impatient at the
slowness of his Carlisle printer. '"Why does not my book make
its appearance?" said he to the printer. "My Lord, I am
extremely sorry; but we have been obliged to send to Glasgow
for a pound of parentheses."'
-- _Life of Johnson_, volume 3, note 1219
I have quite disfigured my copy of the book with my
annotations. I never take it up without at the same time taking
my pencil, and marking with asterisms, parentheses, etc.,
wherever I meet with an original thought, a nervous remark on
life and manners, a remarkably well-turned period, or a
character sketched with uncommon precision.
-- _The Letters of Robert Burns_
"No. Somebody put a drop under a magnifying-glass and it was all
semicolons and parentheses," said Mrs. Cadwallader.
-- George Eliot, _Middlemarch_
Some pronunciations and usages "froze" when they reached the
American shore. In certain respects, American English is closer to
the English of Shakespeare than modern British English is. Some
"Americanisms" that the British decry are actually originally
British expressions that were preserved in the colonies while lost
at home (e.g., fall as a synonym for autumn, trash for rubbish,
frame-up which was reintroduced to Britain through Hollywood
gangster movies, and loan as a verb instead of lend).
-- http://www.wordorigins.org/histeng.htm
William James wrote:
> Actually, it's 'among', not 'amongst', except to those who are
> lisping, degenerate pansies.
>
lisping: "amongst" => "amongthpt" ?
"amongst" is a fairly common british english variant of "among".
> Some pronunciations and usages "froze" when they reached the
>� American shore. In certain respects, American English is closer to
>� the English of Shakespeare than modern British English is.
In certain respects, modern British English is closer to the
English of Shakespeare than American English is.
In this particular case, in Shakespeare's actual time, we can be pretty
sure ([1],[2]) that "parenthesis" meant the inserted parenthetical
phrase.
I do admit that since the later extension to round brackets themselves
is mentioned at link [2] below (and OED) as first appearing in 1715,
and given your later british examples, I was Just Wrong to lay sole
blame on the americans for it.
[1]
The Arte of English Poesie by George Puttenham, 1589
http://www.gutenberg.org/etext/16420
Chap. XIII
"""
[Sidenote: _Parenthesis_, or the Insertour]
Your first figure of tollerable disorder is [_Parenthesis_] or by an
English name the [_Insertour_] and is when ye will seeme for larger
information or some other purpose, to peece or graffe in the middest of
your tale an vnnecessary parcell of speach, which neuerthelesse may be
thence without any detriment to the rest. The figure is so common that
it
needeth none example, neuerthelesse because we are to teache Ladies and
Gentlewomen to know their schoole points and termes appertaining to the
Art, we may not refuse ro yeeld examples euen in the plainest cases, as
that of maister _Diars_ very aptly.
_But now my Deere_ (_for so my loue makes me to call you still_)
_That loue I say, that lucklesse loue, that works me all this ill._
Also in our Eglogue intituled _Elpine_, which we made being but eightene
yeares old, to king _Edward_ the sixt a Prince of great hope, we
surmised
that the Pilot of a ship answering the King, being inquisitiue and
desirous to know all the parts of the ship and tackle, what they were, &
to what vse they serued, vsing this insertion or Parenthesis.
_Soueraigne Lord (for why a greater name
To one on earth no mortall tongue can frame
No statelie stile can giue the practisd penne:
To one on earth conuersant among men.)_
And so proceedes to answere the kings question?
_The shippe thou seest sayling in sea so large, &c._
This insertion is very long and vtterly impertinent to the principall
matter, and makes a great gappe in the tale, neuerthelesse is no
disgrace
but rather a bewtie and to very good purpose, but you must not vse such
insertions often nor to thick, nor those that bee very long as this of
ours, for it will breede great confusion to haue the tale so much
interrupted.
"""
[2] http://www.etymonline.com/index.php?term=parenthesis
[3] http://rhetoric.byu.edu/Figures/P/parenthesis.htm
David Golden wrote:
> The use of round brackets to demarcate parentheses in america
> eventually somehow led to round brackets themselves being called
> parentheses in america, but that usage still makes little sense to
> many native speakers of British (or Hiberno-) English outside the
> computing field.
>
Yeah, yeah, nitpickers, I should have written "the latter usage" or
something, not "that usage". Every nitpicking correction must itself
have at least one error...
David Golden ha escrito:
> Actually, in English, "parenthesis" means the bit in between the
> brackets.
>
> The various kinds of brackets (amongst other punctuation marks
> including, in most english texts, commas) *demarcate* parentheses.
>
> Wikipedia's "Parenthesis (rhetoric)" is, at time of writing, the correct
> British English definition, citing the OED:
> http://en.wikipedia.org/wiki/Parenthesis_%28rhetoric%29
>
> "An explanatory or qualifying word, clause, or sentence inserted into a
> passage with which it has not necessarily any grammatical connection,
> and from which it is usually marked off by round or square brackets,
> dashes, or commas"
>
> The use of round brackets to demarcate parentheses in america eventually
> somehow led to round brackets themselves being called parentheses in
> america, but that usage still makes little sense to many native
> speakers of British (or Hiberno-) English outside the computing field.
>
> It's like calling a quotation mark a "quote" instead of a "quotation
> mark". And lo, guess who does that too...
>
> Calling round brackets "parenthesis marks" would be acceptable but
> perhaps ambiguous in British English, probably needing further
> qualification like "double quotation mark", "single quotation mark".
No too time or interest on this kind of debate but... Encarta [1],
Compact Oxford English Dictionary [2], Cambridge Advanced Learner's
Dictionary [3, 4], the Wiktionary [5], and the Eric Weisstein's World
of Mathematics [6, 7, 8] agree with i said before.
Brackets is the generic 'class' term used for the grouping, whereas
parentheses, square brackets and curly brakets are specific instances
of brackets. The Cambridge dicctionary remark that in the UK the
parentheses are usually called round brackets.
The Oxford dicttionary says about parentheses (the symbols):
"(parentheses) a pair of round brackets () used to include such a word
or phrase."
IHMO, the Python convention is unfortunate.
[1]
http://encarta.msn.com/encnet/features/dictionary/DictionaryResults.aspx?refid=1861723802
[2] http://www.askoxford.com/concise_oed/parenthesis?view=uk
[3] http://dictionary.cambridge.org/define.asp?key=9258&dict=CALD
[4] http://dictionary.cambridge.org/define.asp?key=57594&dict=CALD
[5] http://en.wiktionary.org/wiki/bracket
[6] http://mathworld.wolfram.com/SquareBracket.html
[7] http://mathworld.wolfram.com/Brace.html
[8] http://mathworld.wolfram.com/Parenthesis.html
Juan R. wrote:
> David Golden ha escrito:
>
> No too time or interest on this kind of debate but... Encarta [1],
> Compact Oxford English Dictionary [2], Cambridge Advanced Learner's
> Dictionary [3, 4], the Wiktionary [5], and the Eric Weisstein's World
> of Mathematics [6, 7, 8] agree with i said before.
>
Dictionaries, especially English dictionaries, tend to be descriptive
rather than prescriptive, they simply document the fact that some
people say "literally" when they mean "virtually", or say "fellow" to
mean "male", without making value judgements.
So by referencing dictionaries you show that some people do indeed
say "parentheses" to mean "round brackets". That doesn't say much
about the desirability of doing so.
See http://en.wikipedia.org/wiki/Linguistic_prescription
for why the debate is endless.
Personally, I tend to say "paren" for round bracket in a computing
context. That way I don't have to say "parenthesis", but americans still
understand me...
David Golden ha escrito:
> Juan R. wrote:
>
> > David Golden ha escrito:
> >
>
> > No too time or interest on this kind of debate but... Encarta [1],
> > Compact Oxford English Dictionary [2], Cambridge Advanced Learner's
> > Dictionary [3, 4], the Wiktionary [5], and the Eric Weisstein's World
> > of Mathematics [6, 7, 8] agree with i said before.
> >
>
> Dictionaries, especially English dictionaries, tend to be descriptive
> rather than prescriptive, they simply document the fact that some
> people say "literally" when they mean "virtually", or say "fellow" to
> mean "male", without making value judgements.
Maybe you forget that languages are living organism and dictionaries
are a up-to-date guide to their metabolism. Sure that 20th century
Spanish is different from 18th century one, do you know? but we are
able to adapt ourselves to new times, others i know (a minory) are
unable to change and continue driving by the left side of the road [*]
[*] Take a look to the map on
http://en.wikipedia.org/wiki/Driving_on_the_left_or_right
Steven D'Aprano wrote:
> If that's the best example of what macros can be used for, frankly I'm
> unimpressed. Yes, I can see some benefit. But I don't see that the benefit
> is worth the added complexity. Maybe there are more complex tasks that
> macros are better suited for.
You both seem to be trying to implement a pattern match. It would probably
be productive for you to compare Python and Lisp to languages that have
pattern matching.
For example, look at the symbolic simplifier here:
http://www.ffconsultancy.com/free/ocaml/symbolic.html
or the interpreter here:
http://www.ffconsultancy.com/free/ocaml/interpreter.html
Implementing this kind of stuff in Python is probably a nightmare. At least
you can address Lisp's deficiencies with macros...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
On 10 Dez., 08:25, Jon Harrop <····@ffconsultancy.com> wrote:
> Steven D'Aprano wrote:
> > If that's the best example of what macros can be used for, frankly I'm
> > unimpressed. Yes, I can see some benefit. But I don't see that the benefit
> > is worth the added complexity. Maybe there are more complex tasks that
> > macros are better suited for.You both seem to be trying to implement a pattern match. It would probably
> be productive for you to compare Python and Lisp to languages that have
> pattern matching.
>
> For example, look at the symbolic simplifier here:
>
> http://www.ffconsultancy.com/free/ocaml/symbolic.html
>
> or the interpreter here:
>
> http://www.ffconsultancy.com/free/ocaml/interpreter.html
>
> Implementing this kind of stuff in Python is probably a nightmare. At least
> you can address Lisp's deficiencies with macros...
Jon, you could try and find out. Since you have no real experience with
Lisp and Python, your posting is mostly useless. Why not try out and
report back here? That would probably more interesting than more
uneducated guesses.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> Objective CAML for Scientistshttp://www.ffconsultancy.com/products/ocaml_for_scientists/index.html...
Steven D'Aprano schrieb:
> On Sat, 09 Dec 2006 14:57:08 -0500, Bill Atkins wrote:
>
>> Paul Rubin <·············@NOSPAM.invalid> writes:
>>
>>> There is just not that much boilerplate in Python code, so there's
>>> not so much need to hide it.
>> Well, of course there is. There are always going to be patterns in
>> the code you write that could be collapsed. Language has nothing to
>> do with it; Lisp without macros would still be susceptible to
>> boilerplate.
>>
>> Here's a concrete example:
>>
>> (let ((control-code (read-next-control-code connection)))
>> (ecase control-code
>> (+break+
>> (kill-connection connection)
>> (throw :broken-by-client))
>> (+status+
>> (send-status-summary connection))
>> ((+noop+ +keep-alive+))))
>> ;; +X+ indicates a constant
>
> Eight lines, excluding the comment, and it doesn't handle the case where
> control-code is not one of +break+, +status+, +noop+ or +keep-alive+,
> although the ecase macro does. And how many lines of code is ecase?
>
>> All of that
>> boilerplate is handled by the macro. In Python, I would need to do
>> something like:
>>
>> control_code = connection.read_next_control_code()
>> if control_code == +break+:
>> connection.kill()
>> throw blah
>> else if control_code == +status+:
>> connection.send_status_summary()
>> else if control_code == +noop+ || control_code == +keep_alive+:
>> else:
>> error "CONTROL_CODE fell through conditional cascade; was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"
>
> Your Python syntax is rather wonky, but that's incidental.
>
> Nine lines, including handling the case where control_code is none of the
> four constants. Ten if you add the "pass" statement that it actually
> needs. And it is completely self-contained, with no external functions or
> macros to understand.
Counting source lines is not the important thing. Look at the complexity
and the number of tokens.
The Lisp code is easier, because it is more abstract. You are closer in
saying what you want.
Counting tokens:
(let ((control-code (read-next-control-code connection))) 4
(ecase control-code 2
(+break+ 1
(kill-connection connection) 2
(throw :broken-by-client)) 2
(+status+ 1
(send-status-summary connection)) 2
((+noop+ +keep-alive+)))) 2
======
16
control_code = connection.read_next_control_code() 4
if control_code == +break+: 4
connection.kill() 2
throw blah 2
else if control_code == +status+: 4
connection.send_status_summary() 2
else if control_code == +noop+ || control_code == +keep_alive+: 8
else: 1
error "CONTROL_CODE fell through conditional cascade; 2
was not one of +BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"
======
29
plus a "pass", would make 30 vs 16 "Brain-units".
Andr�
--
On Sat, 09 Dec 2006 00:56:35 -0800, Paul Rubin wrote:
> The syntax is a pretty superficial thing. The reaction from outsiders
> to Lisp's parentheses and Python's indentation-based structure is
> about the same. You get used to it either way.
I don't agree. Syntax is significant for human readers, who are the vast
majority of programmers.
Yes, people will get used to most syntax, eventually. But "used to"
doesn't necessarily mean "can read it efficiently". I did a lot of FORTH
coding in my youth, far more lines of code than Pascal, but Pascal was
always easier to read than FORTH for me. Now, I can look at a page of
Pascal code and it is still readable, but the FORTH... urgh.
Most programming languages, yes even FORTH, used indenting for human
readability. They just don't make them syntactically important. Python
just enforces good indenting.
I've read all the arguments against significant indents/whitespace, or
in favour of braces, and while there are a few minor good points they
make, a few edge cases where Python's significant indentation is
sub-optimal, overall I believe that the famous reaction of programmers to
Python and whitespace is simply them being more like cats than usual:
"It's different, anything different is frightening, I don't like it, hiss
hiss spit!!!"
But Lisp's syntax is so unlike most written natural languages that that it
is a whole different story. Yes, the human brain is amazingly flexible,
and people can learn extremely complex syntax and grammars (especially if
they start young enough) so I'm not surprised that there are thousands,
maybe tens or even hundreds of thousands of Lisp developers who find the
language perfectly readable.
But that isn't to say that the syntax of Lisp is for everybody. Far from
it -- I'd be willing to bet that Lisp developers are a self-selected group
of far above average intelligence. That would explain why so many of them
seem to be so much more comfortable with higher-order functions than most
other people -- even intelligent people.
(Looking back, I'm embarrassed about my first reaction to factory
functions all those years ago. Hiss hiss spit. But even with added
familiarity, there comes a time where one has to question the benefit of
sufficiently high-order functions. If you are writing a factory function
that returns factory functions that return factory functions that return
the functions that you needed in the first place, chances are you really
need to rethink your tactics.)
If I'm right, then maybe Lisp is "better" in some absolute sense, *for
those who can use it*. For those who can't, it isn't just a matter of
(say) the syntax being hard to read because it is unfamiliar, but it
being objectively harder to use.
An interesting study would be to track people's eyeballs as they read
code, or look at how much oxygen their brain uses. Do Lisp coders do more
work to read Lisp than Python coders do to read Python? I suspect they do,
but successful Lisp coders don't notice. Everybody else does, and
gravitate to languages which might not be "better" but are "good enough".
(If my post leads to any Lisp developer's already swollen head exploding
from pride, my job here is done *wink*)
--
Steven.
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> I don't agree. Syntax is significant for human readers, who are the vast
> majority of programmers.
>
> Yes, people will get used to most syntax, eventually. But "used to"
> doesn't necessarily mean "can read it efficiently". I did a lot of FORTH
> coding in my youth, far more lines of code than Pascal, but Pascal was
> always easier to read than FORTH for me. Now, I can look at a page of
> Pascal code and it is still readable, but the FORTH... urgh.
Forth was always unreadable to me but I never did much. I thought its
aficionados were silly. Yes if you have a complicated math expression
in Lisp, you have to sit there for a moment rearranging it in infix in
your mind to figure out what it says. The point is that such
expressions aren't all that common in typical Lisp code.
Anyway, you know this song? I don't think it could have been written
for Python, which is what I mean about Lisp being primordial:
http://www.songworm.com/db/songworm-parody/EternalFlame.html words
http://www.prometheus-music.com/audio/eternalflame.mp3 audio
> But that isn't to say that the syntax of Lisp is for everybody. Far from
> it -- I'd be willing to bet that Lisp developers are a self-selected group
> of far above average intelligence. That would explain why so many of them
> seem to be so much more comfortable with higher-order functions than most
> other people -- even intelligent people.
Nah, try Haskell for that.
Paul Rubin wrote:
> Forth was always unreadable to me but I never did much. I thought its
> aficionados were silly. Yes if you have a complicated math expression
> in Lisp, you have to sit there for a moment rearranging it in infix in
> your mind to figure out what it says. The point is that such
> expressions aren't all that common in typical Lisp code.
>
I find Lisp, Forth and classic funny-symbol APL relatively readable
(well, once you've learned the funny symbols in the APL case) That
spans prefix/postfix/infix... The commonality is simple evaluation
order, no damn precedence rules. I can _cope_ with precedence rules,
I'm not a moron, but I prefer languages that don't make heavy use of
them. Well, more accurately, sources that don't, but most coders in
communities of languages-with-lots-of-precedence-rules consider
reliance on those precedence rules in source code idiomatic. And
precedence rules, once you get beyond a few (sometimes rather
misleading) similarities to the ones that most people are made to learn
early on for arithmetic notation, can vary a lot from computer language
to computer language.
Steven D'Aprano wrote:
>
> But Lisp's syntax is so unlike most written natural languages that that it
> is a whole different story. Yes, the human brain is amazingly flexible,
> and people can learn extremely complex syntax and grammars (especially if
> they start young enough) so I'm not surprised that there are thousands,
> maybe tens or even hundreds of thousands of Lisp developers who find the
> language perfectly readable.
>
> But that isn't to say that the syntax of Lisp is for everybody.
yeah, I think it is. Folks don't vary that much. If every Lisp
programmer also reports parens disappearing at about thirty days, any
given non-Lispnik can pretty much bet on the same experience.
And since no one can produce a witness who worked fulltime on Lisp for
thirty days and gave up on it because it was a great language but they
could not handle the syntax, or a witness who stayed with Lisp because
it is a great language even though to this day they have trouble reading
the synatx...
> Far from
> it -- I'd be willing to bet that Lisp developers are a self-selected group
> of far above average intelligence.
I think the early adopter is distinguished not so much by greater
intelligence as by restlessness and rebelliousness and a little lunacy.
We lack the knack of happiness. Many of the stories on the RtL reveal
folks who sought A Better Way after mastering other languages. And by
Better Way, sorry, we mean "why do I have to forever worry about the
damn paper tape on this Turing machine!". We do not really like
programming, we like thinking about problems and using a computer to
solve them.
> That would explain why so many of them
> seem to be so much more comfortable with higher-order functions than most
> other people -- even intelligent people.
>
> (Looking back, I'm embarrassed about my first reaction to factory
> functions all those years ago. Hiss hiss spit. But even with added
> familiarity, there comes a time where one has to question the benefit of
> sufficiently high-order functions. If you are writing a factory function
> that returns factory functions that return factory functions that return
> the functions that you needed in the first place, chances are you really
> need to rethink your tactics.)
>
> If I'm right, then maybe Lisp is "better" in some absolute sense, *for
> those who can use it*. For those who can't, it isn't just a matter of
> (say) the syntax being hard to read because it is unfamiliar, but it
> being objectively harder to use.
>
> An interesting study would be to track people's eyeballs as they read
> code, ...
I spend about 90% of my time thinking and writing code, and read it only
to understand how something works or why it broke. And then I am looking
at parentheses no more than you are looking at the lines of resolution
on a TV when watching Baywatch. I am looking at a mechanism and how it
works.
> ...or look at how much oxygen their brain uses. Do Lisp coders do more
> work to read Lisp than Python coders do to read Python? I suspect they do,
> but successful Lisp coders don't notice.
My suspicion goes the other way, and is based not on punctuation, rather
on imperative vs functional. In Lisp every form returns a value, so I do
not have all these local variables around that, in the strecth of an
interesting function, take on a stream of values and transformations to
finally come up with some result, meaning to understand code I have to
jump back and forth thru the code to see the lineage of a value and
figure out its net semantics. Too much like work.
> Everybody else does, and
> gravitate to languages which might not be "better" but are "good enough".
No, they gravitated to a language that was closer to what they already
knew, C or Java (which also mimicked C to pick up those users). Later
charms of Python were a great community and library support. Lisp simply
does not have the latter, one is forever rolling one's own bindings to C
libs.
> (If my post leads to any Lisp developer's already swollen head exploding
> from pride, my job here is done *wink*)
They can't get any bigger. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> yeah, I think it is. Folks don't vary that much. If every Lisp
> programmer also reports parens disappearing at about thirty days, any
> given non-Lispnik can pretty much bet on the same experience.
I think an editing program that balances parens automatically is near
indispensible for writing Lisp code. I can't stand writing Lisp
without Emacs.
> My suspicion goes the other way, and is based not on punctuation,
> rather on imperative vs functional. In Lisp every form returns a
> value, so I do not have all these local variables around that, in the
> strecth of an interesting function, take on a stream of values and
> transformations to finally come up with some result, meaning to
> understand code I have to jump back and forth thru the code to see the
> lineage of a value and figure out its net semantics. Too much like work.
Python has been steadily getting better in this regard.
In article <··············@ruckus.brouhaha.com>,
Paul Rubin <·············@NOSPAM.invalid> wrote:
>
>I think an editing program that balances parens automatically is near
>indispensible for writing Lisp code. I can't stand writing Lisp
>without Emacs.
And that is why I will never write Lisp. I loathe Emacs.
--
Aahz (····@pythoncraft.com) <*> http://www.pythoncraft.com/
Member of the Groucho Marx Fan Club
Aahz <····@pythoncraft.com> wrote:
+---------------
| Paul Rubin <·············@NOSPAM.invalid> wrote:
| >I think an editing program that balances parens automatically is near
| >indispensible for writing Lisp code. I can't stand writing Lisp
| >without Emacs.
|
| And that is why I will never write Lisp. I loathe Emacs.
+---------------
An appropriate version of "Vi" is sufficient. I prefer "nvi-1.79",
but have found that the "vim" at work is also adequate. Either will:
1. Flash matching parens on insert; jump back & forth between matching
parens on command ("%").
2. Deal with S-exprs as "objects" for shifting left/right, copying,
deleting, or pasting. [The shifting works best when you gloablly
"set sw=1" and then use "." to repeat the last shift.]
3. Minimal auto-indent, but "good enough" for my purposes [given #2].
That's pretty much all you need to code in Lisp. It's what *I* use.
So "I loathe Emacs" is *NOT* a believable excuse for avoiding Lisp...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Dec 10, 12:28 am, ····@pythoncraft.com (Aahz) wrote:
>And that is why I will never write Lisp. I loathe Emacs.
Me too. So if that's what's stopping you then you might be interested
to hear that when I moved my free time programming from Python to Lisp
it took only a weekend to learn enough of the language to code up a
little Lisp editor. It's funny that I was able to do this given what
I've now learned from this thread:
- Lisp is only used for research (but I'm not an academic)
- Lisp is hard to learn (because of all those parenthesis)
- There's no practical libraries available (so how did I do it so
fast?)
Phil
···············@gmail.com wrote:
> On Dec 10, 12:28 am, ····@pythoncraft.com (Aahz) wrote:
>
>
>>And that is why I will never write Lisp. I loathe Emacs.
>
>
> Me too. So if that's what's stopping you then you might be interested
> to hear that when I moved my free time programming from Python to Lisp
> it took only a weekend to learn enough of the language to code up a
> little Lisp editor. It's funny that I was able to do this given what
> I've now learned from this thread:
>
> - Lisp is only used for research (but I'm not an academic)
> - Lisp is hard to learn (because of all those parenthesis)
> - There's no practical libraries available (so how did I do it so
> fast?)
Our working hypothesis is "mutant strain". We'll need some DNA.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
···············@gmail.com ha escrito:
> - Lisp is hard to learn (because of all those parenthesis)
I cannot understand why. It is like if you claim that packaging things
in boxes is difficult to learn.
HTML and XML have more brackets than LISP (usually double) for
structuring data and everyone has learned HTML.
Juan R. wrote:
> ···············@gmail.com ha escrito:
> > - Lisp is hard to learn (because of all those parenthesis)
>
> I cannot understand why. It is like if you claim that packaging things
> in boxes is difficult to learn.
>
> HTML and XML have more brackets than LISP (usually double) for
> structuring data and everyone has learned HTML.
I think maybe you missed the point I was making.
To make it clearer I'm saying that the arguments that are being made
over and over again against Lisp in this thread have been the
antithesis of my experience since moving from Python to Lisp.
I just prefer personal experience to popular misconceptions :-)
Phil
···············@gmail.com ha escrito:
> Juan R. wrote:
> > ···············@gmail.com ha escrito:
> > > - Lisp is hard to learn (because of all those parenthesis)
> >
> > I cannot understand why. It is like if you claim that packaging things
> > in boxes is difficult to learn.
> >
> > HTML and XML have more brackets than LISP (usually double) for
> > structuring data and everyone has learned HTML.
>
> I think maybe you missed the point I was making.
Yes i did, sorry
> To make it clearer I'm saying that the arguments that are being made
> over and over again against Lisp in this thread have been the
> antithesis of my experience since moving from Python to Lisp.
>
> I just prefer personal experience to popular misconceptions :-)
I often count 'parentheses' used in other approaches.
E.g. the LISP-based
[HTML [@:XMLNS http://www.w3.org/1999/xhtml]
[HEAD
[TITLE Test page]]
[BODY]]
is SLiP (Python)
html(xmlns="http://www.w3.org/1999/xhtml"):
head():
title(): "Test page"
body():
LISP-based:
5 (
5 )
1 @
1 :
Python:
4 (
4 )
1 =
4 "
4 :
On Dec 9, 11:03 pm, Paul Rubin <·············@NOSPAM.invalid> wrote:
>I think an editing program that balances parens automatically is near
>indispensible for writing Lisp code. I can't stand writing Lisp
>without Emacs.
If you use Linux, you can try out my editor. It supports automatic
bracket and smart insertion. It also provides lexical scope highlights
for pair characters including brackets. I implemented these features in
particular for Scheme editing, because God knows I can't stand Emacs.
:-)
Flash Demo: http://scribes.sourceforge.net/demo.htm
Site: http://scribes.sourceforge.net/
··········@gmail.com wrote:
> On Dec 9, 11:03 pm, Paul Rubin <·············@NOSPAM.invalid> wrote:
>> I think an editing program that balances parens automatically is near
>> indispensible for writing Lisp code. I can't stand writing Lisp
>> without Emacs.
>
> If you use Linux, you can try out my editor. It supports automatic
> bracket and smart insertion. It also provides lexical scope highlights
> for pair characters including brackets. I implemented these features in
> particular for Scheme editing, because God knows I can't stand Emacs.
> :-)
>
> Flash Demo: http://scribes.sourceforge.net/demo.htm
>
> Site: http://scribes.sourceforge.net/
>
You might be the perfect candidate to try out a language comparison.
A few years ago we had a little language comparison with CL, C++ and
Ocaml. The goal was to write a version of the childhood game
Concentration. The version I wrote took about 8 hours.
You can find the lisp source at
http://www3.telus.net/public/whumeniu/concentration.lisp
and a Windows standalone exe and the delivery script at
http://www3.telus.net/public/whumeniu/concentration.zip
I will run within Linux and the Mac but it needs some
tweeking of the font (Webdings for the tile images).
If you would like to implement the same thing in Python I think
it would be an interesting comparison.
Wade
Wade Humeniuk wrote:
> If you would like to implement the same thing in Python I think
> it would be an interesting comparison.
Absolutely. While you're at it, I'll try implementing it in F#... :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Wade Humeniuk wrote:
>> If you would like to implement the same thing in Python I think
>> it would be an interesting comparison.
>
> Absolutely. While you're at it, I'll try implementing it in F#... :-)
>
Are you still working on it, or have you given up the attempt already?
W
Paul Rubin wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>yeah, I think it is. Folks don't vary that much. If every Lisp
>>programmer also reports parens disappearing at about thirty days, any
>>given non-Lispnik can pretty much bet on the same experience.
>
>
> I think an editing program that balances parens automatically is near
> indispensible for writing Lisp code.
I would say indispensible full stop.
> I can't stand writing Lisp
> without Emacs.
Emacs or an Emacs-like editor (or at least Lisp-ware editor) provided by
the Lisp environment.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Steven D'Aprano wrote:
> But Lisp's syntax is so unlike most written natural languages that that it
> is a whole different story.
Bahaha!
> Yes, the human brain is amazingly flexible,
> and people can learn extremely complex syntax and grammars (especially if
> they start young enough) so I'm not surprised that there are thousands,
> maybe tens or even hundreds of thousands of Lisp developers who find the
> language perfectly readable.
1> '(especially if they start young enough)
(ESPECIALLY IF THEY START YOUNG ENOUGH)
2> (sixth *)
ENOUGH
... said!
Yeah, so /unlike/ written natural languages!
What a fucking moron.
On Sat, 09 Dec 2006 13:50:24 -0800, Kaz Kylheku wrote:
> Steven D'Aprano wrote:
>> But Lisp's syntax is so unlike most written natural languages that that it
>> is a whole different story.
>
> Bahaha!
>
>> Yes, the human brain is amazingly flexible,
>> and people can learn extremely complex syntax and grammars (especially if
>> they start young enough) so I'm not surprised that there are thousands,
>> maybe tens or even hundreds of thousands of Lisp developers who find the
>> language perfectly readable.
>
> 1> '(especially if they start young enough)
> (ESPECIALLY IF THEY START YOUNG ENOUGH)
> 2> (sixth *)
> ENOUGH
>
> ... said!
>
> Yeah, so /unlike/ written natural languages!
>
> What a fucking moron.
Oh my god! Lisp can echo STRINGS to the interpreter???? Why didn't
somebody somebody tell me that!!!! That *completely* changes my mind about
the language!
I'm especially impressed that it knew I wanted them printed in uppercase
without being told.
--
Steven.
Steven D'Aprano wrote:
> Oh my god! Lisp can echo STRINGS to the interpreter?
Indeed yes, but that's not exactly what's happening here. (And it's not
necessarily an interpreter, by the way. Some Lisp implementations
compile every expression to machine code and branch to it. Corman Lisp,
for instance, doesn't even contain an interpreter).
My point is not to showcase anything about Lisp, but simply to point
out the irony that in the same paragraph in which you are going on
about Lisp being unreadable compared to human written languages, there
appear pieces of parseable Lisp syntax.
> Why didn't somebody somebody tell me that!
The answer to that would be: because your being properly informed for
these kinds of debates is your responsibility, and it is assumed.
> !!! That *completely* changes my mind about the language!
If you keep up the mind changing, you can maybe trade up to one that
works in perhaps fewer than twenty transactions. (Think: Kyle
MacDonald).
On Sun, 10 Dec 2006 01:29:43 +0100, Steven D'Aprano
<·····@REMOVE.THIS.cybersource.com.au> wrote:
>
>
> Oh my god! Lisp can echo STRINGS to the interpreter???? Why didn't
> somebody somebody tell me that!!!! That *completely* changes my mind
> about
> the language!
>
> I'm especially impressed that it knew I wanted them printed in uppercase
> without being told.
>
>
>
Except it is not a string. It is a list of symbols. Hence the upcase.
"This is how you write a string in Lisp"
and that does preserve case.
(If you want symbols to be case sensitive and default case to be lower
then most
Lisp's allow that, but the ANSI spec dosn't give a standard way.)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad <··············@chello.no> wrote:
+---------------
| (If you want symbols to be case sensitive and default case to be lower
| then most Lisp's allow that, but the ANSI spec dosn't give a standard way.)
+---------------
What about (setf (readtable-case *readtable*) :invert)? That's in ANSI.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> I've read all the arguments against significant indents/whitespace, or
> in favour of braces, and while there are a few minor good points they
> make, a few edge cases where Python's significant indentation is
> sub-optimal, overall I believe that the famous reaction of programmers to
> Python and whitespace is simply them being more like cats than usual:
>
> "It's different, anything different is frightening, I don't like it, hiss
> hiss spit!!!"
What about "It's wrong, it's wrong, hiss hiss spit!" ?
I want to be able to change my code and let the editor indent the
result; if I make extensive changes to a section of Python code, I
have to review it afterward and make sure I haven't introduced any
subtle indentation mistakes. Compare
(let ((x 'blah))
(if (eql x 'foo)
(print "blah")
(print "bloo"))))
This could quite conceivably be the result of a lot of refactoring
of (admittedly silly) code. But now I just press C-M-q and, pow:
(let ((x 'blah))
(if (eql x 'foo)
(print "blah")
(print "bloo")))
All happily-indented. And mistakes in nesting show up as mistakes in
indenting. Who could ask for anything more? Python requires me to
review the structure of the code to make sure I haven't inadvertantly
broken it. Why?
Why do I need Python to enforce my indentation (potentially leading to
bugs) when my editor can indent my code perfectly because the syntax
of Lisp is so free of special cases?
> But Lisp's syntax is so unlike most written natural languages that that it
> is a whole different story. Yes, the human brain is amazingly flexible,
> and people can learn extremely complex syntax and grammars (especially if
> they start young enough) so I'm not surprised that there are thousands,
> maybe tens or even hundreds of thousands of Lisp developers who find the
> language perfectly readable.
Most programming languages are nothing like natural languages
(thankfully - ever heard of something called COBOL?). Lisp's syntax
is trivial to lean, and its semantics are very precise.
> But that isn't to say that the syntax of Lisp is for everybody. Far from
> it -- I'd be willing to bet that Lisp developers are a self-selected group
> of far above average intelligence. That would explain why so many of them
> seem to be so much more comfortable with higher-order functions than most
> other people -- even intelligent people.
>
> (Looking back, I'm embarrassed about my first reaction to factory
> functions all those years ago. Hiss hiss spit. But even with added
> familiarity, there comes a time where one has to question the benefit of
> sufficiently high-order functions. If you are writing a factory function
> that returns factory functions that return factory functions that return
> the functions that you needed in the first place, chances are you really
> need to rethink your tactics.)
>
> If I'm right, then maybe Lisp is "better" in some absolute sense, *for
> those who can use it*. For those who can't, it isn't just a matter of
> (say) the syntax being hard to read because it is unfamiliar, but it
> being objectively harder to use.
>
> An interesting study would be to track people's eyeballs as they read
> code, or look at how much oxygen their brain uses. Do Lisp coders do more
> work to read Lisp than Python coders do to read Python? I suspect they do,
> but successful Lisp coders don't notice. Everybody else does, and
> gravitate to languages which might not be "better" but are "good enough".
>
> (If my post leads to any Lisp developer's already swollen head exploding
> from pride, my job here is done *wink*)
I'm afraid you're on the wrong track. Any programmer can pick up Lisp
and be productive in it these days. Please don't try to make Lisp
seem more mysterious or elitist than it really is. It's just a
programming language, and anyone can learn it:
http://www.gigamonkeys.com/book
Bill Atkins wrote:
> And mistakes in nesting show up as mistakes in
> indenting.
Er, hang on a moment... how do you *know* when you've
got a mistake in indending? You must be visually
verifying the indentation... rather like one does
with Python code...
--
Greg
greg wrote:
> Bill Atkins wrote:
>
>> And mistakes in nesting show up as mistakes in
>> indenting.
>
>
> Er, hang on a moment... how do you *know* when you've
> got a mistake in indending? You must be visually
> verifying the indentation... rather like one does
> with Python code...
Absolutely, and you are not disagreeing with Mr. Atkins, tho you seem to
think you are.
But with Lisp one does not have to clean up the indentation manually
after thrashing away at ones code. As I type each right parens I eyeball
its partner as the editor highlights it to make sure I have not missed
anything, then give the re-indent command and eyeball the result. It
/is/ still possible to screw up because I work fast and loose, but only
very rarely do I end up with a parens in the wrong place, and then the
compiler finds something to whine about.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Sat, 09 Dec 2006 22:06:29 -0500, Ken Tilton wrote:
> As I type each right parens I eyeball
> its partner as the editor highlights it to make sure I have not missed
> anything,
Er, weren't you one of the people claiming that you don't notice parens
when you're reading or writing Lisp code?
Oh yes, there is this:
[quote]
Subject: Re: merits of Lisp vs Python
From: Ken Tilton <·········@gmail.com>
Newsgroups: comp.lang.lisp,comp.lang.python
Date: Sat, 09 Dec 2006 02:29:56 -0500
Yeah, you are, you just did not use it heads down for a month. The way
to tell if you spent enough time on Lisp is to look at Lisp code. If you
see any parentheses, you have not spent enough time. They disappear in a
month.
[end quote]
So, if you're still seeing parentheses, does that mean you've been coding
Lisp for less than a month?
--
Steven.
Steven D'Aprano wrote:
> On Sat, 09 Dec 2006 22:06:29 -0500, Ken Tilton wrote:
>
>
>>As I type each right parens I eyeball
>>its partner as the editor highlights it to make sure I have not missed
>>anything,
>
>
> Er, weren't you one of the people claiming that you don't notice parens
> when you're reading or writing Lisp code?
Steve, you seem to be doing everything you can to make what is basically
a decent cultural exchange unpleasant, mostly by bellowing like some mad
rogue elephant over and over again about macros, now by trying to play
gotcha.
I said they disappear. They do. I do not see parens when I look at code.
The "watching of the matching" is only after furious thrashing during
refactoring, and even then it is unconscious most of the time because we
are usually also indenting as we go.
I presume you look to see if your indentation is correct while you are
indenting, with no more effort than I eyeball the highlighted parens.
You think that some gotcha is somehow going to miraculously reveal that
I do in fact have trouble with parentheses? Now /that/ would be dumb of you.
>> So, if you're still seeing parentheses, does that mean you've been coding
> Lisp for less than a month?
I see you figured it our for yourself. Obviously I love parentheses and
would hate to program without them, so obviously your gotcha falls short.
I myself am simply delighted. I decided I should indeed check out if I
was up against the c.l.p village idiot. Nope, turns out you are the
Master of FUD:
http://www.itwire.com.au/content/view/7359/53/
"According to Steven D'Aprano, operations manager of longstanding open
source services firm Cybersource, Microsoft's new game of attempting to
strike fear into the heart of Linux users by invoking the spectre of
patent infringements may soon take an ominous new twist. Mr D'Aprano
believes that Microsoft may well use similar tactics employed by its
proxy the BSA six years ago when it raided the offices of guitar string
maker Ernie Ball with armed marshalls and found a few machines with
non-compliant software."
I love it, you turning FUD on the FUDster, MS. Good for you! A whole
article with nothing but your unsubstantiated guesses as to Microsoft
suing someone! I do not who impresses me more, you giving such an
interview or the reporter who printed it... no, you guys are allowed to
screw up, the editor should be shot.
Hey, Steve, save that crap for Microsoft, will you?
peace. ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Steven D'Aprano wrote:
>> Er, weren't you one of the people claiming that you don't notice parens
>> when you're reading or writing Lisp code?
>
> Steve, you seem to be doing everything you can to make what is basically
> a decent cultural exchange unpleasant...
He has a point. Lispers always say that you can't see the superfluous
parentheses after a month of staring at them, yet you must match them. I do
prefer autoindenting though. Giving whitespace meaning seems like a
second-rate alternative to me...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
[follow-up to cll respected]
>>>>> "JH" == Jon Harrop <···@ffconsultancy.com> writes:
JH> ... Lispers always say that you can't see the
JH> superfluous parentheses after a month of staring at them, yet
JH> you must match them. ...
There are no superfluous parentheses in lisp. What you stop noticing are
the necessary parentheses. Our editors match them.
cheers,
BM
Jon Harrop <···@ffconsultancy.com> writes:
> He has a point. Lispers always say that you can't see the superfluous
> parentheses after a month of staring at them, yet you must match them. I do
> prefer autoindenting though. Giving whitespace meaning seems like a
> second-rate alternative to me...
Well the editor does the matching. It certainly didn't take too long
for me to stop paying much attention to the parentheses. In fact, I
bet $1 that you are more likely to find superfluous parenthesis in a C
or C like program than in a Lisp program.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
David Steuber wrote:
> Well the editor does the matching. It certainly didn't take too long
> for me to stop paying much attention to the parentheses. In fact, I
> bet $1 that you are more likely to find superfluous parenthesis in a C
> or C like program than in a Lisp program.
That brings me onto another criticism of Lispers: they have a different
definition of "superfluous" to me. Consider the following OCaml/F#:
let a, b = 2, 3 in a + b
and the Lisp equivalent:
(let ((a 2) (b 3)) (+ a b))
The OCaml has no parentheses. That doesn't mean the Lisp's are all
superfluous because OCaml has traded some of those parentheses (e.g.
for "let" and "in") but we need to do a token count. OCaml 12 vs Lisp 18.
So Lisp has 6 "unnecessary" or superfluous tokens. That isn't so important
because the byte count is virtually the same.
But this gets a lot worse when expressions written with conventional syntax
exploit precedence. For example, F# vs Lisp token count:
3 vs 5
a + b
(+ a b)
5 vs 11
f x + g y
(+ (f x) (g y))
11 vs 15
a*x*x + b*x + c
(+ (* a x x) (* b x) c)
So the "Lisp has no superfluous parentheses" doesn't wash with me. Lisp
clearly sacrifices associativity and precedence for superfluous
parentheses. The only time this pays off is when you've got an operator
applied to lots of elements (e.g. a * x * x vs (* a x x))
The usual rebuttal to this is "homogeneous syntax is necessary for
metaprogramming" yet Mathematica, MetaOCaml etc. manage to do
metaprogramming with conventional syntax.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
>
> But this gets a lot worse when expressions written with conventional
> syntax exploit precedence.
I think we can all agree that Lisp often loses for mathematical
expressions. The question is if it wins overall; I think that it does.
And of course for mathematical expressions one can use infix if one
wishes.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I did eventually find a mail-order anvil supplier over the Internet.
I'm not sure how they ship them, but in case they're delivered by air, I
better get my tiny umbrella ready, and keep a sign saying `(yipe)' in my
pocket. --James `Kibo' Parry
Robert Uhl wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
> > But this gets a lot worse when expressions written with conventional
> > syntax exploit precedence.
> I think we can all agree that Lisp often loses for mathematical
> expressions. The question is if it wins overall; I think that it does.
I find that Lisp prefix notation allows one to avoid some common
gotchas that I often find myself preventively parenthesizing against in
other, infix computer languages, and often find myself misreading
expressions by assuming they're going to be closer to written math than
they really are. The badness varies from language to language; the
OCaml examples don't look so bad at all, but Mathematica expressions
are a finicky minefield.
Cheers,
Pillsy
In article <·······················@73g2000cwn.googlegroups.com>,
"Pillsy" <·········@gmail.com> wrote:
> I find that Lisp prefix notation allows one to avoid some common
> gotchas that I often find myself preventively parenthesizing against in
> other, infix computer languages, and often find myself misreading
> expressions by assuming they're going to be closer to written math than
> they really are. The badness varies from language to language; the
> OCaml examples don't look so bad at all, but Mathematica expressions
> are a finicky minefield.
Personally, I don't think that infix was chosen over prefix for
mathematics due to some magical superiority of infix. Or some
perceived correspondence to spoken languages. "Add two and two,"
"the sum of two and two," "two plus two", "+ 2 2", "2 + 2" are all
equally valid ways of expressing the same concept.
One of the things I appreciated coming to lisp from python was that
working with anonymous objects in python can lead to statements like:
object4=object1.function1(object2.property).function3(args)
In pseudo-lisp:
(setq object4
(function3
(function1 object1
(get-property object2))
args))
To me, this makes it much more clear which objects are being passed
to which functions in which order.
>
> Cheers,
> Pillsy
Kirk Sluder wrote:
> One of the things I appreciated coming to lisp from python was that
> working with anonymous objects in python can lead to statements like:
>
> object4=object1.function1(object2.property).function3(args)
>
> In pseudo-lisp:
> (setq object4
> (function3
> (function1 object1
> (get-property object2))
> args))
>
> To me, this makes it much more clear which objects are being passed
> to which functions in which order.
And if you that gets too nested, write a macro which does the same
thing, but with a left-to-right piping syntax:
(setq object4 (filter object2 get-property function1 (function3 _
args)))
Nice left-to-right sequence of what happens to object2.
http://groups.google.ca/group/comp.lang.lisp/msg/68b08ac1c8ec4f20
Message ID: ·······················@o13g2000cwo.googlegroups.com
In article <························@n67g2000cwd.googlegroups.com>,
"Kaz Kylheku" <········@gmail.com> wrote:
> Kirk Sluder wrote:
> > One of the things I appreciated coming to lisp from python was that
> > working with anonymous objects in python can lead to statements like:
> >
> > object4=object1.function1(object2.property).function3(args)
> >
> > In pseudo-lisp:
> > (setq object4
> > (function3
> > (function1 object1
> > (get-property object2))
> > args))
> >
> > To me, this makes it much more clear which objects are being passed
> > to which functions in which order.
>
> And if you that gets too nested, write a macro which does the same
> thing, but with a left-to-right piping syntax:
>
> (setq object4 (filter object2 get-property function1 (function3 _
> args)))
Ohh, shiny. Not the way I'd think to do it, but it works.
Pillsy wrote:
> I find that Lisp prefix notation allows one to avoid some common
> gotchas that I often find myself preventively parenthesizing against in
> other, infix computer languages, and often find myself misreading
> expressions by assuming they're going to be closer to written math than
> they really are. The badness varies from language to language; the
> OCaml examples don't look so bad at all, but Mathematica expressions
> are a finicky minefield.
APL and J are probably better examples but, yes, Mathematica does go too far
with infix operators.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Joe Marshall wrote:
> Robert Uhl wrote:
> >
> > I think we can all agree that Lisp often loses for mathematical
> > expressions.
>
> Not that you consulted me, but I don't agree.
Nor I ... nor, I'm guessing do a significant number of Lispers...and
possibly a significant number of Mathematicians -- many of whom use (or
used) Lisp or Lisp-based symbolic math tools, such as Macsyma. If you
said something like: "Infix is more commonly understood for simple
arithmetic." then I might agree with you, but once you get beyond a
couple of additions, you're gonna be using parens etc. anyhow, so I
don't see that Lisp losses much, nor that Python's ESAS (i.e.,
Elementary School Arithmetic Syntax) buys you much.
The only thing that I have seen agreement on so far is that Python has
better libraries than most Lisps in some areas, that Python is slower
than Lisp, that Python has a more limited object model, and that Python
cannot do macros like Lisp can. All of these (in both directions) are
probably fixable by just unifying Python and Lisp. ;-)
Jon Harrop wrote:
> David Steuber wrote:
>> Well the editor does the matching. It certainly didn't take too long
>> for me to stop paying much attention to the parentheses. In fact, I
>> bet $1 that you are more likely to find superfluous parenthesis in a C
>> or C like program than in a Lisp program.
>
> That brings me onto another criticism of Lispers: they have a different
> definition of "superfluous" to me. Consider the following OCaml/F#:
>
> let a, b = 2, 3 in a + b
>
> and the Lisp equivalent:
>
> (let ((a 2) (b 3)) (+ a b))
>
> The OCaml has no parentheses. That doesn't mean the Lisp's are all
> superfluous because OCaml has traded some of those parentheses (e.g.
> for "let" and "in") but we need to do a token count. OCaml 12 vs Lisp 18.
> So Lisp has 6 "unnecessary" or superfluous tokens. That isn't so important
> because the byte count is virtually the same.
>
> But this gets a lot worse when expressions written with conventional syntax
> exploit precedence. For example, F# vs Lisp token count:
>
Well, lets see your F# Concentration program then. Perhaps a meaningful
comparison can then be made.
Still waiting with baited breath, though I will probably pass out soon.
Wade
Jon Harrop schrieb:
> David Steuber wrote:
>> Well the editor does the matching. It certainly didn't take too long
>> for me to stop paying much attention to the parentheses. In fact, I
>> bet $1 that you are more likely to find superfluous parenthesis in a C
>> or C like program than in a Lisp program.
>
> That brings me onto another criticism of Lispers: they have a different
> definition of "superfluous" to me. Consider the following OCaml/F#:
>
> let a, b = 2, 3 in a + b
>
> and the Lisp equivalent:
>
> (let ((a 2) (b 3)) (+ a b))
>
> The OCaml has no parentheses. That doesn't mean the Lisp's are all
> superfluous because OCaml has traded some of those parentheses (e.g.
> for "let" and "in") but we need to do a token count. OCaml 12 vs Lisp 18.
> So Lisp has 6 "unnecessary" or superfluous tokens. That isn't so important
> because the byte count is virtually the same.
I count 12 for both versions. I see the number of elements in the tree:
Lisp:
let
/ \
/ \
/ \
elements expressions
/ | |
/ | |
/ | |
list list +
/ \ / \ / \
a 2 b 3 a b
Ocaml:
let
/ \
/ \
/ \
= in
/ | |
/ | |
/ | |
, , +
/ \ / \ / \
a b 2 3 a b
> But this gets a lot worse when expressions written with conventional syntax
> exploit precedence. For example, F# vs Lisp token count:
You are right, math can look messy when a lot of two digit functions
like + or / are involved.
It depends on what one is programming.
See
http://lib.store.yahoo.net/lib/paulgraham/acl2.lisp
http://lib.store.yahoo.net/lib/paulgraham/onlisp.lisp
Or the sources of AllegroServe (a Common Lisp application server) to see
how much math is involved.
I admit that
> a*x*x + b*x + c
looks a bit better than
> (+ (* a x x) (* b x) c)
But if I use this 4 times in a program I can accept it.
You know that there are infix macros for Lisp that allow me to write
code as you did in ocaml.
One could even get something that looks better than ocaml:
#i(ax� + bx + c)
There are infix packages, ready for download. The 0,4% of applications
that do a lot of math should maybe really look into them.
> So the "Lisp has no superfluous parentheses" doesn't wash with me.
Lisp has on parens at all. The graphical representation of code has.
But in the program tree there are no parens anymore, in opposit to
other languages, like ML or Java.
You editor could support a tree-view-mode, where the program is shown
and written with trees. In a few years one could use modern hardware,
like seen in the Tom Cruise movie "Minority Report" to move code around
with hand moves and views. It could already be done today this way, but
it is too expensive to be done.
> Lisp
> clearly sacrifices associativity and precedence for superfluous
> parentheses. The only time this pays off is when you've got an operator
> applied to lots of elements (e.g. a * x * x vs (* a x x))
The token syntax tree is not longer in Lisp. I showed you several
examples.
> The usual rebuttal to this is "homogeneous syntax is necessary for
> metaprogramming" yet Mathematica, MetaOCaml etc. manage to do
> metaprogramming with conventional syntax.
There is a Lisp with a syntax as you know it: Dylan, and it also
supports macros. Other people already explained differences between
Lisp macros and those of Mathematica in earlier posts from you.
Andr�
--
Jon Harrop ha escrito:
> That brings me onto another criticism of Lispers: they have a different
> definition of "superfluous" to me. Consider the following OCaml/F#:
To me superfluous mean more regarding a predefined syntax and grammar.
The number of superfluous items is not an absolute measure.
Lisp has superfluous parentheses when compared with OCaml/F# (are _not_
superfluous regarding LISP), but sure that OCaml/F# has other
superfluous syntatic terms when compared with LISP. HTML or XML has
more superfluous 'parentheses' (angle brackets) from a LISP perspective
2: (function argument)
10: <apply><function/><tk>argument</tk></apply>
still i never see people critizing LISP doing the same with XML :]
> So the "Lisp has no superfluous parentheses" doesn't wash with me. Lisp
> clearly sacrifices associativity and precedence for superfluous
> parentheses.
There is not sacrifice if one can design high-level syntax.
> The usual rebuttal to this is "homogeneous syntax is necessary for
> metaprogramming" yet Mathematica, MetaOCaml etc. manage to do
> metaprogramming with conventional syntax.
Mathematica? Cof cof!
Precisely the large criticism to symbolic math in MathML becomes
because people who originated the first MathML spec was people becoming
from CAS community (Mathematica, Maple...). Therein that MathML 2
deprecated a lot of Mathematica-like stuff in 1.0 version. And i wait
still more would be deprecated in next MathML 3.
Nobody doing serious stuff in metaprograming uses Mathematica syntax as
design guiding. Even integral of sin is incorrectly encoded in
Mathematica. Difficult to believe that i can do metaprogramming there.
Also the Mathematica syntax for presentation is very flawed.
Jon Harrop <···@ffconsultancy.com> writes:
> So the "Lisp has no superfluous parentheses" doesn't wash with me. Lisp
> clearly sacrifices associativity and precedence for superfluous
> parentheses. The only time this pays off is when you've got an operator
> applied to lots of elements (e.g. a * x * x vs (* a x x))
Um, no.
The parenthesis are what make Lisp macros possible or, at the very
least, not hard. And don't forget that a Lisp macro can expand into
very complex code at expansion time.
There are real advantages to having the code be a textual
representation of lists that Lisp is so good at manipulating.
--
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
I bump into a lot of veteran riders in my travels.
--- David Hough: Proficient Motorcycling
On Sat, 16 Dec 2006 04:19:15 -0500, David Steuber wrote:
> The parenthesis are what make Lisp macros possible or, at the very
> least, not hard. And don't forget that a Lisp macro can expand into
> very complex code at expansion time.
>
> There are real advantages to having the code be a textual
> representation of lists that Lisp is so good at manipulating.
Isn't that kind of orthogonal, though? The various lisp (and scheme)
infix parsers/readers just leave you with exactly the same list/prefix
parse tree that you would have had if you'd written the expression
long-hand (in prefix notation). So macros shouldn't care one way or the
other: they're operating on the parsed syntax trees.
That should also be applicable to other languages, if anyone cared to
arrange it. [But it seems as though they haven't, so there's probably
more to it than meets the eye...]
Cheers,
--
Andrew
Andrew Reilly wrote:
> On Sat, 16 Dec 2006 04:19:15 -0500, David Steuber wrote:
>
>> The parenthesis are what make Lisp macros possible or, at the very
>> least, not hard. And don't forget that a Lisp macro can expand into
>> very complex code at expansion time.
>>
>> There are real advantages to having the code be a textual
>> representation of lists that Lisp is so good at manipulating.
>
> Isn't that kind of orthogonal, though? The various lisp (and scheme)
> infix parsers/readers just leave you with exactly the same list/prefix
> parse tree that you would have had if you'd written the expression
> long-hand (in prefix notation). So macros shouldn't care one way or the
> other: they're operating on the parsed syntax trees.
>
> That should also be applicable to other languages, if anyone cared to
> arrange it. [But it seems as though they haven't, so there's probably
> more to it than meets the eye...]
Yes, there is more to it: You don't only need to change the abstract
syntax tree, but you also need a way to describe how the macros that
perform such changes are represented at the user-code level.
The advantage in Lisp and Scheme is that you have a common
representation for both levels (internal and what the programmer sees),
so whenever you write a macro, it's sufficient to provide something for
that one representation. As soon as internal and external
representation differ, you have to describe the same construct for both
representations, and more importantly, keep both in sync whenever you
change them later on.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Ken Tilton wrote:
> But with Lisp one does not have to clean up the indentation manually
> after thrashing away at ones code.
That's not how I would describe the experience
I have when I'm editing Python code.
When moving a set of statements in Python, you
are usually selecting a set of complete lines,
cutting them out and then pasting them in
between two other lines somewhere else.
Having done that, the lines you've just pasted
in are selected. Now it's just a matter of
using using your editor's block-shifting commands
to move them left or right until they're in
the correct horizontal position.
I find this to be quite a smooth and natural
process -- no "thrashing" involved at all.
Having edited both Lisp and Python code fairly
extensively, I can't say that I find editing
Python code to be any more difficult or error
prone.
On the plus side, Python makes less demands on the
capabilities of the editor. All you really need
is block-shifting commands. Bracket matching is
handy for expressions but not vital, and you
certainly don't need bracket-based auto-indenting.
--
Greg
greg <····@cosc.canterbury.ac.nz> writes:
> When moving a set of statements in Python, you
> are usually selecting a set of complete lines,
> cutting them out and then pasting them in
> between two other lines somewhere else.
You're missing Ken's point, which is that in Lisp an s-expression
represents a single concept - I can cut out the second form of an IF
and know that I'm cutting the entire test-form. I don't have to
choose the correct "set of complete lines" to correctly move code
around.
> Having edited both Lisp and Python code fairly
> extensively, I can't say that I find editing
> Python code to be any more difficult or error
> prone.
How extensively?
> On the plus side, Python makes less demands on the
> capabilities of the editor. All you really need
> is block-shifting commands. Bracket matching is
> handy for expressions but not vital, and you
> certainly don't need bracket-based auto-indenting.
Oh, please. So we should restrict the power of the languages we
choose just to make sure that our code can be edited in Notepad?
Bill Atkins wrote:
> > On the plus side, Python makes less demands on the
> > capabilities of the editor. All you really need
> > is block-shifting commands. Bracket matching is
> > handy for expressions but not vital, and you
> > certainly don't need bracket-based auto-indenting.
>
> Oh, please. So we should restrict the power of the languages we
> choose just to make sure that our code can be edited in Notepad?
In the real world, it's a non-negligible consideration, IMO. I find
myself needing to write code on machines that aren't my usual dev
machine at least a couple of times a year, and not having to install a
particular editor is nice (especially in terms of keeping the
modifications to someone else's machine down to a minimum).
It's hardly a dealbreaker for a particular language, but it's far from
worthless.
Bill Atkins wrote:
> greg <····@cosc.canterbury.ac.nz> writes:
>
> > When moving a set of statements in Python, you
> > are usually selecting a set of complete lines,
> > cutting them out and then pasting them in
> > between two other lines somewhere else.
>
> You're missing Ken's point, which is that in Lisp an s-expression
> represents a single concept - I can cut out the second form of an IF
> and know that I'm cutting the entire test-form. I don't have to
> choose the correct "set of complete lines" to correctly move code
> around.
Why is selecting a valid s-expression easier than selecting a python
block ? If you mistakenly select an extra parenthesis or omit one, it's
the same thing. Having said that, I find this problem is mostly
academic in both languages with modern editors... there are less
trivial excuses to keep the flamewar raging ;-)
George
On 2006-12-12 19:18:10 -0500, "George Sakkis" <·············@gmail.com> said:
> If you mistakenly select an extra parenthesis or omit one, it's
> the same thing.
Because you can't mistakenly select an extra paren or omit one in a
lisp-aware editor. Whether its a commercial lisp IDE or emacs, you
don't manually select s-expressions. You put your cursor/point at one
paren and you tell the editor - with a keystroke or a mouse click - to
find the matching paren and select everything contained between the two.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com>:
+---------------
| "George Sakkis" <·············@gmail.com> said:
| > If you mistakenly select an extra parenthesis or omit one, it's
| > the same thing.
|
| Because you can't mistakenly select an extra paren or omit one in a
| lisp-aware editor. Whether its a commercial lisp IDE or emacs, you
| don't manually select s-expressions. You put your cursor/point at one
| paren and you tell the editor - with a keystroke or a mouse click - to
| find the matching paren and select everything contained between the two.
+---------------
And for any of you who are rejecting this because you don't want to
learn or use Emacs, Raffael's point is even true in the Vi family of
editors ("nvi" & "vim", at least). The "y%" command yanks (copies)
everything through the matching paren into the anonymous buffer;
"d%" deletes likewise [and saves in the anonymous buffer]; "p" (or "P")
pastes after (or before) the current location. All can be prefixed
with a buffer ("Q-register") name for more flexibility.
Lisp's parens really *do* make editing ever so much easier!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> And for any of you who are rejecting this because you don't want to
> learn or use Emacs, Raffael's point is even true in the Vi family of
> editors ("nvi" & "vim", at least). The "y%" command yanks (copies)
> everything through the matching paren into the anonymous buffer;
> "d%" deletes likewise [and saves in the anonymous buffer]; "p" (or "P")
> pastes after (or before) the current location. All can be prefixed
> with a buffer ("Q-register") name for more flexibility.
If you're on Vim, you also have the "ib" and "ab" commands that work
under visual selection. You repeat them to broaden the selection to the
next level of nesting.
Rob Warnock wrote:
> Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com>:
> +---------------
> | "George Sakkis" <·············@gmail.com> said:
> | > If you mistakenly select an extra parenthesis or omit one, it's
> | > the same thing.
> |
> | Because you can't mistakenly select an extra paren or omit one in a
> | lisp-aware editor. Whether its a commercial lisp IDE or emacs, you
> | don't manually select s-expressions. You put your cursor/point at one
> | paren and you tell the editor - with a keystroke or a mouse click - to
> | find the matching paren and select everything contained between the two.
> +---------------
>
> And for any of you who are rejecting this because you don't want to
> learn or use Emacs, Raffael's point is even true in the Vi family of
> editors ("nvi" & "vim", at least). The "y%" command yanks (copies)
> everything through the matching paren into the anonymous buffer;
> "d%" deletes likewise [and saves in the anonymous buffer]; "p" (or "P")
> pastes after (or before) the current location. All can be prefixed
> with a buffer ("Q-register") name for more flexibility.
Wow, there was some merit in following this thread, besides feeling so
affirmed (not that I care) for deciding to start learning Lisp last week :)
I currently use vim, so the y% d% commands may make up for the time I
lost reading this thread - thx dude.
>
> Lisp's parens really *do* make editing ever so much easier!
>
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
>
"George Sakkis" <·············@gmail.com> writes:
>
> Why is selecting a valid s-expression easier than selecting a python
> block ? If you mistakenly select an extra parenthesis or omit one, it's
> the same thing. Having said that, I find this problem is mostly
> academic in both languages with modern editors...
Or even nearly 30 year old editors; emacs provides support for
error-free selection of s-expressions, although to be frank I still
don't use them as often as I should.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Thanks to the joint efforts of OpenOffice, Mozilla, and a few others, Emacs
officially entered the category of lightweight utilities. --kalifa on /.
Bill Atkins wrote:
> You're missing Ken's point, which is that in Lisp an s-expression
> represents a single concept - I can cut out the second form of an IF
> and know that I'm cutting the entire test-form.
For selecting a single form, that's true. For
more than one form (such as selecting some, but
not all, of the statements in a loop body) it's
not much different.
But my point was that I don't find "manually
reindenting the lines" to be a chore. He made it
sound like you have to laboriously go through
and adjust the lines one by one, but it's not
like that at all. You shift them all at once
in a block.
>>Having edited both Lisp and Python code fairly
>>extensively,
>
> How extensively?
Enough to know what I'm talking about. Tens
of thousands of lines of Lisp and Scheme, and
hundreds of thousands of lines of Python, I
would estimate.
Seeing as you asked, how much Python code have
you or Ken edited?
--
Greg
greg wrote:
> Bill Atkins wrote:
>
>> You're missing Ken's point, which is that in Lisp an s-expression
>> represents a single concept - I can cut out the second form of an IF
>> and know that I'm cutting the entire test-form.
>
>
> For selecting a single form, that's true. For
> more than one form (such as selecting some, but
> not all, of the statements in a loop body) it's
> not much different.
>
> But my point was that I don't find "manually
> reindenting the lines" to be a chore. He made it
> sound like you have to laboriously go through
> and adjust the lines one by one, but it's not
> like that at all. You shift them all at once
> in a block.
It is a gray area. Manually maintaining indentation does not have to be
a "laborious chore" to slow down development.
I believe it was in the mid 1980s when I turned to the developer sitting
next to me and said, "I wonder how much time I spend re-tabbing my
code?" That was probably Vax Basic or COBOL. I /think/ the editor had a
block-tab capability, and I think I used same in some C IDES, but to be
honest retabbling a few lines was not such a laborious chore <g> that I
would first do the select operation to be able to use it.
Also, Python does not support a functional style of programming so the
line is the only meaningful textual entity. In this sense the
primitiveness of Python makes editing easier.
Finally, Python is just a (fine) scripting language. Which means one
does not tackle hard problems with it, the kind one figures out as one
goes. That means less refactoring, and less refactoring means less
slicing and dicing of the code.
> Seeing as you asked, how much Python code have
> you or Ken edited?
See above. Not Python, but out the wazoo in other languages.
Remember, we are not Lisp-only aliens, we program all the languages you
program, plus one. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Mon, 11 Dec 2006 23:24:07 -0500, Ken Tilton wrote:
> Also, Python does not support a functional style of programming so the
> line is the only meaningful textual entity. In this sense the
> primitiveness of Python makes editing easier.
Why do you say that? Wouldn't a block in python be a "meaningful textual
entity" in the same way a lisp form would be?
I V <········@gmail.com> writes:
> > Also, Python does not support a functional style of programming so the
> > line is the only meaningful textual entity. In this sense the
> > primitiveness of Python makes editing easier.
>
> Why do you say that? Wouldn't a block in python be a "meaningful textual
> entity" in the same way a lisp form would be?
You normally wouldn't refactor Python code by moving an indented block
to the inside of an expression. That is done all the time in Lisp.
greg <····@cosc.canterbury.ac.nz> writes:
>>>Having edited both Lisp and Python code fairly
>>>extensively,
>>
>> How extensively?
>
> Enough to know what I'm talking about. Tens
> of thousands of lines of Lisp and Scheme, and
> hundreds of thousands of lines of Python, I
> would estimate.
>
> Seeing as you asked, how much Python code have
> you or Ken edited?
To be honest, very little Python code. But I have manually indented
and rearranged enough code in other line-based languages to appreciate
the convenience of s-expression-based commands.
On 2006-12-09, Bill Atkins <······@rpi.edu> wrote:
> I'm afraid you're on the wrong track. Any programmer can pick
> up Lisp and be productive in it these days. Please don't try
> to make Lisp seem more mysterious or elitist than it really is.
> It's just a programming language, and anyone can learn it:
>
> http://www.gigamonkeys.com/book
I got stuck (last year) in that book:
http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html
The author didn't do Common Lisp (or me) any favors by drawing my
attention to the pathname library. I suppose I missed whatever
the point was supposed to be in the midst of the mind-boggling. I
meant to get back to it but haven't yet.
--
Neil Cerutti
We will sell gasoline to anyone in a glass container. --sign at Santa Fe gas
station
Neil Cerutti <·······@yahoo.com> writes:
>
>> http://www.gigamonkeys.com/book
>
> I got stuck (last year) in that book:
>
> http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html
>
> The author didn't do Common Lisp (or me) any favors by drawing my
> attention to the pathname library.
Yeah, I think his intent was for it to be a nice little practicum to
demonstrate how to use the language--unfortunately it dealt with one of
the uglier bits of CL. The fact that pathnames are really cool doesn't
fix the problem that they are at once overspecified and underspecified.
If the standard were revised, that'd be a good candidate right there.
This is where having a benevolent dictator for life comes in handy.
> I suppose I missed whatever the point was supposed to be in the midst
> of the mind-boggling. I meant to get back to it but haven't yet.
I pretty much skipped that chapter. The bit where it gets mind-boggling
is where he creates ID3-tag reading classes from binary-reading
primitives and ends up with a complete ID3 library in very few lines of
code.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I won't insult your intelligence by suggesting that you really believe
what you just said. --William F. Buckley, Jr.
On Sat, 09 Dec 2006 02:29:56 -0500, Ken Tilton wrote:
>
>
> David Lees wrote:
> Those raving about
> Lisp are quite accomplished at all those other languages, and know about
> what they are talking.
Such a sweeping generalization. Every person who raves about Lisp is also
accomplished with other languages. Yeah, right. I believe you, even if
millions wouldn't.
> I doubt the Pythonistas weighing in on this
> thread ever got far at all with Lisp, so... should they really be
> offering comparative analysis?
I hit my hand with a hammer once. I didn't keep going until I was an
expert in hitting-own-hand-with-hammer before deciding that hitting my
hand with a hammer was not for me. Did I do the wrong thing? Should I have
kept going until I was an expect at it?
(Of course, writing Lisp isn't precisely like hitting one's hand with a
hammer. With the hammer, the endorphins kick in eventually, and it can
become quite pleasant...)
>> Personally, I never like Lisp syntax;
>> Clearly some people, some fanatic judging by this thread :) think easily
>> in prefix. I am not one of them.
>
> Yeah, you are, you just did not use it heads down for a month.
The sheer arrogance of this claim is astounding.
Actually, this is comp.lang.lisp. It isn't astounding at all.
I don't know, maybe lisp coders actually are more intelligent than
ordinary mortals, but it has been my experience that they have absolutely
no grasp whatsoever of the way most (many? some?) people think. And I'm
not talking about can't-walk-and-think-at-the-same-time people either, I'm
talking about bright, intelligent people who, nevertheless, don't agree
with lisp coders.
> The way
> to tell if you spent enough time on Lisp is to look at Lisp code. If you
> see any parentheses, you have not spent enough time. They disappear in a
> month.
If the parentheses are that meaningless, why do you need them?
> The typical Pythonista values clean code but trembles in the face of
> macros, which exist to hide boilerplate.
Funny, when I write code, I try to remove boilerplate, not hide it.
> That means the only thing
> showing in any given block of code is exactly the interesting variable
> and function names. Talk about readability.
Yes. And your point is?
>> Computer languages are tools and
>> everyone should pick the ones that they are most comfortable and
>> productive with.
>
> No, languages are not interchangeable.
Perhaps you should consider what the term "Turing complete" implies.
> Python is a fine language, but
> Lisp is much more expressive/powerful.
Maybe so. A bulldozer is a lot more powerful than a tack-hammer, but if
somebody suggested using a bulldozer to lay carpet, I'd politely show them
to the door. Sometimes more power isn't better.
--
Steven.
Steven D'Aprano wrote:
> On Sat, 09 Dec 2006 02:29:56 -0500, Ken Tilton wrote:
>
>
>>
>>David Lees wrote:
>
>
>>Those raving about
>>Lisp are quite accomplished at all those other languages, and know about
>> what they are talking.
>
>
> Such a sweeping generalization. Every person who raves about Lisp is also
> accomplished with other languages. Yeah, right. I believe you, even if
> millions wouldn't.
Ah, but that is because you are not a careful thinker, you just like
sounding off on Usenet. Me, too!
Think, Steve, think: do you think we pay the rent with /Lisp/ jobs?!
If logic does not work for you, try this:
http://wiki.alu.org/RtL_Highlight_Film
Behind each sound bite is a full survey response, one question being
"what other languages do you use?".
>>I doubt the Pythonistas weighing in on this
>>thread ever got far at all with Lisp, so... should they really be
>>offering comparative analysis?
>
>
> I hit my hand with a hammer once.
Cool, first you use the lame Turing Completeness thing, now you are
arguing by analogy, which does not work because now we have to argue
about how well the analogue maps onto the topic.
When I switched Lisps after several years of Lisp I also had to switch
IDEs (not using Emacs+ILisp). I hated the new IDE. I also told myself to
wait thirty days before worrying about it, since obviously it might just
be a matter of habit. Now when I port things back to the first Lisp I
hate that IDE (except I know a couple of weeks would turn it around).
Now it may be distressing to you that I am talking about something
closer to programming languages than is hammering ones hand, and for
that I apologize in advance. :)
I didn't keep going until I was an
> expert in hitting-own-hand-with-hammer before deciding that hitting my
> hand with a hammer was not for me. Did I do the wrong thing? Should I have
> kept going until I was an expect at it?
>
> (Of course, writing Lisp isn't precisely like hitting one's hand with a
> hammer. With the hammer, the endorphins kick in eventually, and it can
> become quite pleasant...)
>
>
>
>>> Personally, I never like Lisp syntax;
>>>Clearly some people, some fanatic judging by this thread :) think easily
>>>in prefix. I am not one of them.
>>
>>Yeah, you are, you just did not use it heads down for a month.
>
>
> The sheer arrogance of this claim is astounding.
>
> Actually, this is comp.lang.lisp. It isn't astounding at all.
Exactly, and Usenet. Not the Supreme Court. We can speak casually. We
can also speak cordially. <hint>
>
> I don't know, maybe lisp coders actually are more intelligent than
> ordinary mortals,
No, it's the Lisp that makes them so effective. I was joking in my
original remark. But not about Lisp programmers being better looking. :)
> but it has been my experience that they have absolutely
> no grasp whatsoever of the way most (many? some?) people think. And I'm
> not talking about can't-walk-and-think-at-the-same-time people either, I'm
> talking about bright, intelligent people who, nevertheless, don't agree
> with lisp coders.
As you will soon realize because you are such an open,
intellectually-honest person and will do the reading I recommended, most
of us came to Lisp late in our programming careers, having used and
excelled at (in my case) Apple Integer Basic, Microsoft Basic, 6502
Assembler, COBOL, any DEC Basics, C, Logo, and now Lisp (chosen over the
new C++ because the latter seemed like evry bit the horror it turned out
to be). I have done enough Python to appreciate the cleanliness of the
code and its power, and enough Java... well, after Lisp it is impossible
to find anything in some other language that would tempt one to work
much in it.
My point is that we grasp what you think because we /are/ you, we have
worked alongside you, and we are very good at your language. And we use
Lisp and gloat about it and piss everyone off with our smugness. It
can't be helped--Lisp is that good.
>>The way
>>to tell if you spent enough time on Lisp is to look at Lisp code. If you
>>see any parentheses, you have not spent enough time. They disappear in a
>>month.
>
>
> If the parentheses are that meaningless, why do you need them?
Meaningless? Who said that? Did you say that? Someone said that. :)
I said they disappear. I am not looking at parens, I am looking at the
code structure, as manifested by (you'll like this) the indentation, the
indentation provided automatically when I kerplunk control-shift-P (I
think, my fingers know).
You like analogies. When i tried on my first glasses I said "I can see
the frames!". the glasses guy said, "That is because you are looking for
them." Something like that. With the editor handling the parens 90% of
the time, I do not have to thnk about or look for them.
btw, change all the ()s to []s and I /do/ see them. Possibly they would
go away with time, but I have a hunch that []s might not go away, two
cornery or something.
>
>
>
>>The typical Pythonista values clean code but trembles in the face of
>>macros, which exist to hide boilerplate.
>
>
> Funny, when I write code, I try to remove boilerplate, not hide it.
Boilerplate does not mean meaningless. You cannot remove it. It is
absolutely necessary. But it has blanks that must be filled in
differently for each use of the boilerplate. With macros, one supplies
just the fill-ins and the name of the boilerplate, but in a way a
function cannot handle.
The last time we went thru this a Pythonista finally said, Oh, I get it.
These five lines of code I have to write all the time (two setup, one
func call, two cleanup) can be collapsed into one or two. The thread
will be hard to miss in Google groups (two years back?) and the epiphany
appears right at the end of the thread. <hint>
>>That means the only thing
>>showing in any given block of code is exactly the interesting variable
>>and function names. Talk about readability.
>
>
> Yes. And your point is?
You would love macros if Python had them.
>>>Computer languages are tools and
>>>everyone should pick the ones that they are most comfortable and
>>>productive with.
>>
>>No, languages are not interchangeable.
>
>
> Perhaps you should consider what the term "Turing complete" implies.
I have destroyed this elsewhere, but in case you missed it: HLLs exist
precisely to distance us from having to program Turing machines
directly, and are to be judged precisely on how well they do that, so
this fig leaf offers no cover.
>
>
>
>>Python is a fine language, but
>>Lisp is much more expressive/powerful.
>
>
> Maybe so. A bulldozer is a lot more powerful than a tack-hammer, but if
> somebody suggested using a bulldozer to lay carpet, I'd politely show them
> to the door. Sometimes more power isn't better.
I thought we agreed that analogies are useless because they become their
own debate? :) Again, power means maximizing the ratio between how much
time am I thinking about the problem I am trying to express and how much
time am I thnking about your beloved Turing machine.
Not sure how I would say that in infix.
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton schrieb:
> The last time we went thru this a Pythonista finally said, Oh, I get it.
> These five lines of code I have to write all the time (two setup, one
> func call, two cleanup) can be collapsed into one or two. The thread
> will be hard to miss in Google groups (two years back?) and the epiphany
> appears right at the end of the thread. <hint>
Functional programming is the solution here, not Lisp.
You could make that with a new function (in Python), that takes a
function (and its args, don't remember the correct syntax).
def foo(function, args):
setup(1)
setup(2)
function(args)
cleanup(1)
cleanup(2)
The nice thing in Lisp would now be to save a lambda with the macro.
In Python one would fill the name space with throw away functions that
get called only one time.
Andr�
--
Andr� Thieme wrote:
> Ken Tilton schrieb:
>
>> The last time we went thru this a Pythonista finally said, Oh, I get
>> it. These five lines of code I have to write all the time (two setup,
>> one func call, two cleanup) can be collapsed into one or two. The
>> thread will be hard to miss in Google groups (two years back?) and the
>> epiphany appears right at the end of the thread. <hint>
>
>
> Functional programming is the solution here, not Lisp.
No, you do not understand. The Pythonista figured it out: a function
would not do.
>
> You could make that with a new function (in Python), that takes a
> function (and its args, don't remember the correct syntax).
>
> def foo(function, args):
> setup(1)
> setup(2)
> function(args)
> cleanup(1)
> cleanup(2)
>
>
> The nice thing in Lisp would now be to save a lambda with the macro.
> In Python one would fill the name space with throw away functions that
> get called only one time.
Omigod. Is that what you meant? You think macros are unnecessary because
one could hard-code their expansions as separate functions? And that
would constitute hiding the boilerplate? What happens when the
boilerplate changes? <game over>
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton schrieb:
>
>
> Andr� Thieme wrote:
>> Ken Tilton schrieb:
>>
>>> The last time we went thru this a Pythonista finally said, Oh, I get
>>> it. These five lines of code I have to write all the time (two setup,
>>> one func call, two cleanup) can be collapsed into one or two. The
>>> thread will be hard to miss in Google groups (two years back?) and
>>> the epiphany appears right at the end of the thread. <hint>
>>
>>
>> Functional programming is the solution here, not Lisp.
>
> No, you do not understand. The Pythonista figured it out: a function
> would not do.
What do you mean?
>> You could make that with a new function (in Python), that takes a
>> function (and its args, don't remember the correct syntax).
>>
>> def foo(function, args):
>> setup(1)
>> setup(2)
>> function(args)
>> cleanup(1)
>> cleanup(2)
>>
>>
>> The nice thing in Lisp would now be to save a lambda with the macro.
>> In Python one would fill the name space with throw away functions that
>> get called only one time.
>
> Omigod. Is that what you meant? You think macros are unnecessary because
> one could hard-code their expansions as separate functions? And that
> would constitute hiding the boilerplate? What happens when the
> boilerplate changes? <game over>
Well, macros are unnecessary from a mathematical point of view: 0 and
1 are enough. But of course they have the potential to be a real time
saver. What I want to say is: the situation you gave as an example is
not the place where macros shine, because 1st class functions can take
over.
You could maybe give another example: how would one realize something
like (memoize function) in Python?
Or (defmethod name :after ..)?
Andr�
--
Andr� Thieme wrote:
> Ken Tilton schrieb:
>
>>
>>
>> Andr� Thieme wrote:
>>
>>> Ken Tilton schrieb:
>>>
>>>> The last time we went thru this a Pythonista finally said, Oh, I get
>>>> it. These five lines of code I have to write all the time (two
>>>> setup, one func call, two cleanup) can be collapsed into one or two.
>>>> The thread will be hard to miss in Google groups (two years back?)
>>>> and the epiphany appears right at the end of the thread. <hint>
>>>
>>>
>>>
>>> Functional programming is the solution here, not Lisp.
>>
>>
>> No, you do not understand. The Pythonista figured it out: a function
>> would not do.
>
>
> What do you mean?
I am saying use Google groups to find the thread and find out the use
case contributed by a Pythonista in the midddle of a similar thread that
conveyed to his satisfaction the value of macros.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Sun, 10 Dec 2006 01:53:50 +0100, Andr� Thieme wrote:
> You could maybe give another example: how would one realize something
> like (memoize function) in Python?
By spending thirty seconds googling:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/325205
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498110
If your needs are very simple, something as simple as this will do it:
def memoize(func):
def f(arg, _cache={}):
if _cache.has_key(arg):
return _cache[arg]
t = func(arg)
_cache[arg] = t
return t
return f
> Or (defmethod name :after ..)?
I don't even know what that means. Would you like to translate?
--
Steven.
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> > Or (defmethod name :after ..)?
> I don't even know what that means. Would you like to translate?
This is something that I've wished Python had. If I try to describe
it I'll probably get it wrong. But basically say Foo is a class with
multiple superclasses. The superclasses each define a "name" method
and Foo itself may also define a "name" method. When you call
Foo.name() you want that to invoke both Foo's name method and the
superclass methods. In Python you have to do grotty things like
super(Bar,self).name() in the Foo.name() to make this happen by hand,
and you have to keep tweaking that as you add and remove superclasses.
In Lisp, you can set it up so that the multiple "name" calls happen
automatically. The :before, :after, and :around keywords let you say
what order you want the calls to happen in. You'd use :before for
setup actions, :after for cleanup actions, and just plain defmethod
for the stuff that is supposed to happen in between.
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>> Or (defmethod name :after ..)?
>
> I don't even know what that means.
And yet you continue to post as if you know Common Lisp...
Steven D'Aprano schrieb:
> On Sun, 10 Dec 2006 01:53:50 +0100, Andr� Thieme wrote:
>
>> You could maybe give another example: how would one realize something
>> like (memoize function) in Python?
>
> By spending thirty seconds googling:
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/325205
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498110
>
> If your needs are very simple, something as simple as this will do it:
>
> def memoize(func):
> def f(arg, _cache={}):
> if _cache.has_key(arg):
> return _cache[arg]
> t = func(arg)
> _cache[arg] = t
> return t
> return f
>
Yes, you are right, again this can be done with functional programming.
My examples also were not better than those of Kenny.
But anyway, in Lisp you can save some code. Not much in this situation.
Instead of function = memoize(function)
one could just say: memoize(function).
>> Or (defmethod name :after ..)?
>
> I don't even know what that means. Would you like to translate?
Also this won't be very hard to do in Python.
It just means: if you have a method with the name "name" and call it,
then this after-method will be called right after and do some side effect.
In Lisp it is built in. But with some effort it could be done in Python
too. The idea is, that small savings sum up, so macros do make sense.
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> Instead of function = memoize(function)
> one could just say: memoize(function).
In Python you'd say
@memoize
def function(): ...
Paul Rubin <·············@NOSPAM.invalid> writes:
> Andr� Thieme <······························@justmail.de> writes:
>> Instead of function = memoize(function)
>> one could just say: memoize(function).
>
> In Python you'd say
>
> @memoize
> def function(): ...
But in Lisp you'd write the function, say, "Damn, I need to memoize
this sucker," and evaluate
(memoize 'function)
and the function would be memoized.
I suspect you could even do this "while the program was running" from
something like SLIME. Basically the memoize macro changes the
function cell of the symbol, so from that point all the calls to the
function would be to the memoized version.
--
Fred Gilham ······@csl.sri.com
One of the authors of the Daniel Bell volume says, in horror and
astonishment, that the radical right intends to repeal the twentieth
century. Heaven forfend! Who would want to repeal the twentieth
century, the century of horror, the century of collectivism, the
century of mass destruction and genocide, who would want to repeal
that! -- Murray Rothbard
Fred Gilham schrieb:
> Paul Rubin <·············@NOSPAM.invalid> writes:
>
>> Andr� Thieme <······························@justmail.de> writes:
>>> Instead of function = memoize(function)
>>> one could just say: memoize(function).
>> In Python you'd say
>>
>> @memoize
>> def function(): ...
>
> But in Lisp you'd write the function, say, "Damn, I need to memoize
> this sucker," and evaluate
>
> (memoize 'function)
>
> and the function would be memoized.
>
> I suspect you could even do this "while the program was running" from
> something like SLIME. Basically the memoize macro changes the
> function cell of the symbol, so from that point all the calls to the
> function would be to the memoized version.
>
You don't even need to say 'function
(memoize function) would be enough.
And yes, you can memoize functions while the program is running.
And you don't need a tool like slime for it. Lisp already offers ways
for doing that.
Andr�
--
Andr� Thieme a �crit :
> You don't even need to say 'function
> (memoize function) would be enough.
> And yes, you can memoize functions while the program is running.
> And you don't need a tool like slime for it. Lisp already offers ways
> for doing that.
In Python while the program is running :
import module
module.function = memoize(module.function)
Christophe schrieb:
> Andr� Thieme a �crit :
>> You don't even need to say 'function
>> (memoize function) would be enough.
>> And yes, you can memoize functions while the program is running.
>> And you don't need a tool like slime for it. Lisp already offers ways
>> for doing that.
>
> In Python while the program is running :
>
> import module
> module.function = memoize(module.function)
Yes, I mentioned that a bit earlier in this thread (not about the
"during runtime" thing).
I also said that many macros only save some small bits of code.
Your python example contains 4 tokens / brain units.
The Lisp version only has 2.
In the first moment one might want to say:
"Hey, just 10-15 more characters to type in Python". But this sums
up. If someone *really* thinks this extra typing is not bad, why doesn't
this person add some functions like:
def foobar():
pass
and call them from time to time? If a bit of extra typing is not bad one
could call this function each time before one uses the built in * operator.
Why not?
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> > import module
> > module.function = memoize(module.function)
>
> Yes, I mentioned that a bit earlier in this thread (not about the
> "during runtime" thing).
> I also said that many macros only save some small bits of code.
> Your python example contains 4 tokens / brain units.
> The Lisp version only has 2.
You shouldn't count the import statement, since you'd need the
equivalent in Lisp as well.
Contrast the much more common
a[i] = b[n]
with
(setf (aref a i) (aref b n))
and the attractions of Python may make more sense.
Paul Rubin <·············@NOSPAM.invalid> writes:
> Andr� Thieme <······························@justmail.de> writes:
> > > import module
> > > module.function = memoize(module.function)
> >
> > Yes, I mentioned that a bit earlier in this thread (not about the
> > "during runtime" thing).
> > I also said that many macros only save some small bits of code.
> > Your python example contains 4 tokens / brain units.
> > The Lisp version only has 2.
>
> You shouldn't count the import statement, since you'd need the
> equivalent in Lisp as well.
>
> Contrast the much more common
>
> a[i] = b[n]
>
> with
>
> (setf (aref a i) (aref b n))
>
> and the attractions of Python may make more sense.
Not really. The syntax of getting and setting array elements isn't
really the point. It ignores the cognitive efficiency of Lisp when
things get more complex, and likewise whatever similar characteristics
that Python offers. I don't mean to imply Python is inefficient, just
that array manipulation syntax isn't where the two languages' strengths
& weaknesses appear. To compare the languages when things get
complicated, in effect, to see how they help and how they hurt when
problems are difficult, then a more complex example is necessary. Since
the arguments so far seem dominated by syntactical trivia, they seem to
me more about perceived aesthetics and personal preference than anything
else.
I spent a year or so using Python as a scripting language for relatively
simple applications where shell scripts were insufficient. It works
fine as such. But it began to suck performance-wise when I started
trying to manipulate more complex datasets and I began wanting
compilation to get throughput up. Common Lisp, being a highly mature
language (and thus sometimes ossified in appearance), offered a
standardized language with a variety of implementations, some of which
gave me the compiler tools I needed without forcing me to retool
concepts and source code from the freebie implementations I started
with. This is a very important point once there is considerable
conceptual investment in a suite of source.
When the New & Cool arguments are presented, this issue seems neglected.
There are many tradeoffs to be made between New & Cool and Highly
Matured, syntax being only one.
Gregm
Greg Menke <·············@toadmail.com> writes:
re: comparison of
> > a[i] = b[n]
with
> > (setf (aref a i) (aref b n))
>
> Not really. The syntax of getting and setting array elements isn't
> really the point. It ignores the cognitive efficiency of Lisp when
> things get more complex, and likewise whatever similar characteristics
> that Python offers.
Well, there's some similar way to look up elements in a Lisp
hashtable, but I've forgotten the keyword for it (oops, cognitive
inefficiency, having to remember separately.) Python uses the same
syntax for both.
Yeah it's probably true that very complex applications are easier to
develop in Lisp. For small and medium ones, I really do find Python
more pleasant, and I'm speaking as someone for whom the discovery of
Lisp was once an unbelievably powerful epiphany.
Paul Rubin wrote:
> > > a[i] = b[n]
> > > (setf (aref a i) (aref b n))
>
> Well, there's some similar way to look up elements in a Lisp
> hashtable, but I've forgotten the keyword for it (oops, cognitive
> inefficiency, having to remember separately.) Python uses the same
> syntax for both.
That's true, Lisp would benefit from _standard_ homogenuous polymorphic
accessor functions to list-like objects and/or low-level (macro-like)
syntactic sugar. Yes, you can easily make (a i) act like (aref a i)
but it is not done by default. Legacy reasons? Graham has interesting
things to say about this issue:
http://www.paulgraham.com/ilc03.html
Most of my programs are also written in Python, however, I would say
that in many cases "a[i] = b[n]" is an artefact of programming habits
from C, which has no language support for list comprehension,
iterators, etc. I tend to avoid such constructs; usually there is a
more natural way to do the same and it's just too easy to get the
indices wrong.
Piotr
Piotr wrote:
> Paul Rubin wrote:
[...]
> > Well, there's some similar way to look up elements in a Lisp
> > hashtable, but I've forgotten the keyword for it (oops, cognitive
> > inefficiency, having to remember separately.)
FWIW, the command is GETHASH. The situation in CL is actually even
worse than just having different names for these functions, since some
functions put the index as the first argument (GETHASH, NTH) and others
put it as the second argument (AREF, ELT). You can at least hide this
archaic nonsense away by defining methods for a generic function if it
bugs you.
> > Python uses the same syntax for both.
> That's true, Lisp would benefit from _standard_ homogenuous polymorphic
> accessor functions to list-like objects and/or low-level (macro-like)
> syntactic sugar. Yes, you can easily make (a i) act like (aref a i)
> but it is not done by default. Legacy reasons?
Well, it's not such a hot idea in a Lisp-2, since you'll often have a
variable named, say, LIST, and then the meaning of (LIST 1) becomes
ambiguous.
In CL, you could do the implicit indexing with different braces,
though, like [a i] for (aref i); this is something I periodically
consider doing.
Cheers,
Pillsy
Paul Rubin wrote:
> André Thieme <······························@justmail.de> writes:
> > > import module
> > > module.function = memoize(module.function)
> >
> > Yes, I mentioned that a bit earlier in this thread (not about the
> > "during runtime" thing).
> > I also said that many macros only save some small bits of code.
> > Your python example contains 4 tokens / brain units.
> > The Lisp version only has 2.
>
> You shouldn't count the import statement, since you'd need the
> equivalent in Lisp as well.
>
> Contrast the much more common
>
> a[i] = b[n]
>
> with
>
> (setf (aref a i) (aref b n))
>
> and the attractions of Python may make more sense.
Actual Lisp session transcript:
[1]> (load "infix.cl")
;; Loading file infix.cl ...
;;;
*************************************************************************
;;; Infix notation for Common Lisp.
;;; Version 1.3 28-JUN-96.
;;; Written by Mark Kantrowitz, CMU School of Computer Science.
;;; Copyright (c) 1993-95. All rights reserved.
;;; May be freely redistributed, provided this notice is left intact.
;;; This software is made available AS IS, without any warranty.
;;;
*************************************************************************
;; Loaded file infix.cl
T
[2]> #i( if x < y then a[i] = b[j] else a[i] = c[j,j] ^^ w )
*** - EVAL: variable X has no value
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead of X.
STORE-VALUE :R2 You may input a new value for X.
ABORT :R3 ABORT
Break 1 [3]> :a
[4]> (quote #i( if x < y then a[i] = b[j] else a[i] = c[j,j] ^^ w ))
(IF (< X Y) (SETF (AREF A I) (AREF B J))
(SETF (AREF A I) (EXPT (AREF C J J) W)))
In spite of such possibilities, things like this just don't catch on in
Lisp programming. Once people know that they /can/ get it if they want,
they no longer want it.
What doesn't make sense is writing entire language implementations from
scratch in order to experiment with notations.
I think someone may have been working on a Python interface built on
Common Lisp.
Ah, here!
http://trac.common-lisp.net/clpython/wiki/WikiStart
Paul Rubin schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>>> import module
>>> module.function = memoize(module.function)
>> Yes, I mentioned that a bit earlier in this thread (not about the
>> "during runtime" thing).
>> I also said that many macros only save some small bits of code.
>> Your python example contains 4 tokens / brain units.
>> The Lisp version only has 2.
>
> You shouldn't count the import statement, since you'd need the
> equivalent in Lisp as well.
I didn't count it.
1P) module.function
2P) =
3P) memoize(
4P) module.function)
vs
1L) (memoize
2L) function)
I counted 1P and 4P only as one (each) although it should have been 2
for each. But it would have worked too if we didn't need the "module.":
function = memoize(function).
> Contrast the much more common
>
> a[i] = b[n]
>
> with
>
> (setf (aref a i) (aref b n))
>
> and the attractions of Python may make more sense.
Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in Python
one has to write less since "[]" are 2 chars while "aref" are 4, plus
the setf.
But from counting the brain units which I regard as an important factor
they are both equal.
Andr�
--
Andr� Thieme wrote:
>> Contrast the much more common
>>
>> a[i] = b[n]
>>
>> with
>>
>> (setf (aref a i) (aref b n))
>>
>> and the attractions of Python may make more sense.
>
> Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in Python
> one has to write less since "[]" are 2 chars while "aref" are 4, plus
> the setf.
Why are you not counting Lisp's superfluous parentheses but you are counting
the brackets in the Python? I get 9 tokens for Python vs 13 for Lisp.
> But from counting the brain units which I regard as an important factor
> they are both equal.
Python is clearly more succinct in this case. I also think it is worth
counting chars or LOC as well as tokens. Lisp has unnecessarily long
built-in tokens...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop schrieb:
> Andr� Thieme wrote:
>>> Contrast the much more common
>>>
>>> a[i] = b[n]
>>>
>>> with
>>>
>>> (setf (aref a i) (aref b n))
>>>
>>> and the attractions of Python may make more sense.
>> Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in Python
>> one has to write less since "[]" are 2 chars while "aref" are 4, plus
>> the setf.
>
> Why are you not counting Lisp's superfluous parentheses but you are counting
> the brackets in the Python? I get 9 tokens for Python vs 13 for Lisp.
Change the editor and Lisp has no parentheses at all. An editor where
you would draw trees.
The parens are part of the function. In Python I would count foo() as
one token and not as two or three, because the () belong to the call itself.
There are several ways to do it. If you want to count the opening and
closing brackets then yes, Python has less tokens. Maybe one should
count the Newline at the end of the Python code (or the EOF) too.
/- a
/-- aref--
| \- i
|
setf--+
|
| /- b
\-- aref--
\- n
One can replace the setf with =
and the aref with [].
That would give the tree for Python.
>> But from counting the brain units which I regard as an important factor
>> they are both equal.
>
> Python is clearly more succinct in this case. I also think it is worth
> counting chars or LOC as well as tokens. Lisp has unnecessarily long
> built-in tokens...
I agree that LOC is also important (and didn't say it wasn't).
The thing that happens for Lisp is, that we have lot's of one-token
lines, or those with only some bits of code, which doesn't happen so
often in other languages. A line often begins with lots of white space
for indentation. So when counting loc in Lisp one should be aware about
that.
The length of names of built in functions are longer than average, yes.
This might be a question of style. One doesn't have to type these long
names. If someone would be really interested he/she could sit down one
evening and make a package with renames most long-names functions with
shorter names (or even unicode single chars).
Andr�
--
Andr� Thieme a �crit :
> Paul Rubin schrieb:
>> Andr� Thieme <······························@justmail.de> writes:
>>>> import module
>>>> module.function = memoize(module.function)
>>> Yes, I mentioned that a bit earlier in this thread (not about the
>>> "during runtime" thing).
>>> I also said that many macros only save some small bits of code.
>>> Your python example contains 4 tokens / brain units.
>>> The Lisp version only has 2.
>>
>> You shouldn't count the import statement, since you'd need the
>> equivalent in Lisp as well.
>
> I didn't count it.
>
> 1P) module.function
> 2P) =
> 3P) memoize(
> 4P) module.function)
>
> vs
> 1L) (memoize
> 2L) function)
>
> I counted 1P and 4P only as one (each) although it should have been 2
> for each. But it would have worked too if we didn't need the "module.":
> function = memoize(function).
If you really need to : memoize('module.function') but it's ugly.
On 2006-12-12, Andr� Thieme <······························@justmail.de> wrote:
>> Contrast the much more common
>>
>> a[i] = b[n]
>>
>> with
>>
>> (setf (aref a i) (aref b n))
>>
>> and the attractions of Python may make more sense.
>
> Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in
> Python one has to write less since "[]" are 2 chars while
> "aref" are 4, plus the setf. But from counting the brain units
> which I regard as an important factor they are both equal.
A comparison of brain units of the above snippets is irrelevant,
since the snippets are not equivalent.
The Python snippet will work for any object a that provides
__setitem__ and any object b that provides __getitem__.
I don't know what an equivalent Lisp snippet would be (or even
exactly how close the above snippet comes to matching the Python
code), but whatever it is would be a better foundation for
comparing brain units with the above Python.
--
Neil Cerutti
Neil Cerutti schrieb:
> On 2006-12-12, André Thieme <······························@justmail.de> wrote:
> >> Contrast the much more common
> >>
> >> a[i] = b[n]
> >>
> >> with
> >>
> >> (setf (aref a i) (aref b n))
> >>
> >> and the attractions of Python may make more sense.
> >
> > Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in
> > Python one has to write less since "[]" are 2 chars while
> > "aref" are 4, plus the setf. But from counting the brain units
> > which I regard as an important factor they are both equal.
>
> A comparison of brain units of the above snippets is irrelevant,
> since the snippets are not equivalent.
>
> The Python snippet will work for any object a that provides
> __setitem__ and any object b that provides __getitem__.
>
> I don't know what an equivalent Lisp snippet would be (or even
> exactly how close the above snippet comes to matching the Python
> code), but whatever it is would be a better foundation for
> comparing brain units with the above Python.
It would be exactly like the example given, just "aref" replaced with
something else. An example implementation:
==========================================
(defgeneric $ (container key))
(defgeneric (setf $) (value container key))
;;; Implementation for arrays
(defmethod $ ((container array) (key integer))
(aref container key))
(defmethod (setf $) (value (container array) (key integer))
(setf (aref container key) value))
==========================================
And usage:
==========================================
CL-USER(3): (defparameter a (vector 1 2 3 4 5))
A
CL-USER(4): ($ a 0)
1
CL-USER(5): (setf ($ a 0) 9)
9
CL-USER(6): a
#(9 2 3 4 5)
==========================================
The nice thing is, that you *can* dispatch on the container,
the key and the value.
On 2006-12-13, hit_the_lights <··········@gmx.at> wrote:
> Neil Cerutti schrieb:
>
>> >> a[i] = b[n]
>> >>
>> >> with
>> >>
>> >> (setf (aref a i) (aref b n))
>> >>
>> >> and the attractions of Python may make more sense.
>> >
>> > Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in
>> > Python one has to write less since "[]" are 2 chars while
>> > "aref" are 4, plus the setf. But from counting the brain
>> > units which I regard as an important factor they are both
>> > equal.
>>
>> A comparison of brain units of the above snippets is
>> irrelevant, since the snippets are not equivalent.
>>
>> The Python snippet will work for any object a that provides
>> __setitem__ and any object b that provides __getitem__.
>>
>> I don't know what an equivalent Lisp snippet would be (or even
>> exactly how close the above snippet comes to matching the
>> Python code), but whatever it is would be a better foundation
>> for comparing brain units with the above Python.
>
> It would be exactly like the example given, just "aref"
> replaced with something else. An example implementation:
>
>==========================================
> (defgeneric $ (container key))
> (defgeneric (setf $) (value container key))
>
> ;;; Implementation for arrays
>
> (defmethod $ ((container array) (key integer))
> (aref container key))
>
> (defmethod (setf $) (value (container array) (key integer))
> (setf (aref container key) value))
>==========================================
>
> And usage:
>
>==========================================
> CL-USER(3): (defparameter a (vector 1 2 3 4 5))
> A
> CL-USER(4): ($ a 0)
> 1
> CL-USER(5): (setf ($ a 0) 9)
> 9
> CL-USER(6): a
> #(9 2 3 4 5)
>==========================================
>
> The nice thing is, that you *can* dispatch on the container,
> the key and the value.
That's cool. Thanks for posting the code.
Is the above 'duck-typing' idiom considered very useful to a
Lisper? It seems logical to me that duck-typing works best in an
environment where it is ubiquitous. If users have to implement
accessors specifically to use your library, it is not as good as
if they had already implemented one as a matter of routine.
--
Neil Cerutti
Neil Cerutti <·······@yahoo.com> writes:
> Is the above 'duck-typing' idiom considered very useful to a
> Lisper? It seems logical to me that duck-typing works best in an
> environment where it is ubiquitous. If users have to implement
> accessors specifically to use your library, it is not as good as
> if they had already implemented one as a matter of routine.
It's a little more complicated than that, the classes involved have to
have special interfaces to tell setf/getf what to do, sort of a
compile time equivalent of __setattr__/__getattr__ if I remember right.
Paul Rubin schrieb:
> Neil Cerutti <·······@yahoo.com> writes:
> > Is the above 'duck-typing' idiom considered very useful to a
> > Lisper? It seems logical to me that duck-typing works best in an
> > environment where it is ubiquitous. If users have to implement
> > accessors specifically to use your library, it is not as good as
> > if they had already implemented one as a matter of routine.
No, it's not as ubiquitious as in Python. I guess that has many
different reasons, probably many historical. IIRC Peter Seibel
writes in Practical Common Lisp that CLOS (and thus "defgeneric")
was introduced late in the CL standardization process. That my be
one reason why it is not used extensively by the rest of the
standardized language.
> It's a little more complicated than that, the classes involved have to
> have special interfaces to tell setf/getf what to do, sort of a
> compile time equivalent of __setattr__/__getattr__ if I remember right.
The code I've posted is all you need. You can specialize it for any
class (including numbers, functions, symbols etc.) you like.
In case of the lookup "($ a 0)" there is nothing done at compile
time, it's just a call of the generic function "$".
"(setf ($ a 0) 1)" is translated at compile time (setf is a macro)
to something like "(funcall #'(setf $) 1 a 0)".
Andr� Thieme <······························@justmail.de> writes:
> But anyway, in Lisp you can save some code. Not much in this situation.
> Instead of function = memoize(function)
> one could just say: memoize(function).
Um...
Ken Tilton wrote:
> Andr� Thieme wrote:
>> def foo(function, args):
>> setup(1)
>> setup(2)
>> function(args)
>> cleanup(1)
>> cleanup(2)
>>
>> The nice thing in Lisp would now be to save a lambda with the macro.
>> In Python one would fill the name space with throw away functions that
>> get called only one time.
That is a deficiency of Python that doesn't exist in modern FPLs like OCaml,
SML, Haskell, F#...
> Omigod. Is that what you meant? You think macros are unnecessary because
> one could hard-code their expansions as separate functions? And that
> would constitute hiding the boilerplate? What happens when the
> boilerplate changes? <game over>
He is correct. When the boilerplate changes, you change your HOF.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> >> The nice thing in Lisp would now be to save a lambda with the macro.
> >> In Python one would fill the name space with throw away functions that
> >> get called only one time.
>
> That is a deficiency of Python that doesn't exist in modern FPLs like OCaml,
> SML, Haskell, F#...
Nothing stops you from re-using the same internal function name in
your Python code, like you might use "i" as a throwaway loop index in
several places in the same function. It's just like in Scheme, the
function is a first class object like an integer.
Paul Rubin wrote:
>> That is a deficiency of Python that doesn't exist in modern FPLs like
>> OCaml, SML, Haskell, F#...
>
> Nothing stops you from re-using the same internal function name in
> your Python code, like you might use "i" as a throwaway loop index in
> several places in the same function. It's just like in Scheme...
It is not "just like in Scheme" if you don't have anonymous functions in
Python.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> > Nothing stops you from re-using the same internal function name in
> > your Python code, like you might use "i" as a throwaway loop index in
> > several places in the same function. It's just like in Scheme...
>
> It is not "just like in Scheme" if you don't have anonymous functions in
> Python.
Python has anonymous functions (what they can do is somewhat limited
by syntax) but the similarity mentioned with Scheme was about the data
objects. Anyway you don't need to pollute the namespace with lots of
(i.e. more than one) different temporary function name even if you use
non-anonymous functions.
········@gmail.com wrote:
> Okay, since everyone ignored the FAQ, I guess I can too...
>
> Mark Tarver wrote:
>> How do you compare Python to Lisp? What specific advantages do you
>> think that one has over the other?
>
> (Common) Lisp is the only industrial strength language with both pure
> compositionality and a real compiler. What Python has is stupid slogans
> ("It fits your brain." "Only one way to do things.") and an infinite
> community of flies that, for some inexplicable reason, believe these
> stupid slogns. These flies are, however, quite useful because they
> produce infinite numbers of random libraries, some of which end up
> being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
> is rapidly replacing Perl, and Ruby is simultaneously and even more
> rapidly replacing Python. Each is closer to Lisp than the last; the
> world is returning to Lisp and is dragging the flies with it.
> Eventually the flies will descend upon Lisp itself and will bring with
> them their infinite number of random libraries, and then things will be
> where they should have been 20 years ago, but got sidetracked by Tcl
> and other line noise.
pffffffff !
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
>
> Mark
I've never programmed in Lisp but I have programmed in Cadence Skill a
Lisp inspired language with infix notation as an option. I found Skill
to be a very powerful language. At the time I new only AWK, C, Pascal,
Forth, Postcript, Assembler and Basic. Skill was superior and I came
to love it.
But that was a decade ago. Now, I'd rather a company integrate Python
into their product as I find Python to be less 'arcane' than Skill;
with more accessible power, and a great community.
.
Analogy time!
You need Pure Maths, but more mathematicians will be working applying
maths to real-world problems. You need research physicists, but more
physicists will be applying physics in the real world. It seems to me
that Lisp and its basis in maths makes people research and develop a
lot of new techniques in Lisp, but when it comes to applying those
techniques in the real world - switch to Python!
Lisp has a role to play, but maybe a language tuned to research and
with its user base would naturally find it hard to compete in the roles
in which dynamic languages such as Python are strongest.
- Paddy.
"Paddy" <·········@netscape.net> writes:
> Mark Tarver wrote:
>
>> How do you compare Python to Lisp? What specific advantages do you
>> think that one has over the other?
>>
>> Note I'm not a Python person and I have no axes to grind here. This is
>> just a question for my general education.
>>
>> Mark
> I've never programmed in Lisp but I have programmed in Cadence Skill a
> Lisp inspired language with infix notation as an option. I found Skill
> to be a very powerful language. At the time I new only AWK, C, Pascal,
> Forth, Postcript, Assembler and Basic. Skill was superior and I came
> to love it.
Remember; Lisp is a program-language programming language. Sometimes,
one programs in Lisp without really knowing it:
http://www.franz.com/careers/jobs/outside/cadence03.21.06.lhtml
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
>
> Mark
cmp `which clisp` `which python`
/usr/bin/clisp /usr/bin/python differ: byte 25, line 1
HTH
--S
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
Since the late 1950's Lisp has participated in the development of
modern (present day) programming practises. It has shaped and been
shaped by the minds of just not programmers, but people involved
in dealing with the larger impacts and possibilities.
Its been there, is here, and will continue to be there in the future.
Lisp is a human construct that is a force to be reckoned with. Its
construction reflects something very deep and fundamental about
computing. So, it depends on what you want.
What do you want?
W
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
>
> Mark
Im myself python programmer with C,C++,Java,Fortran background and also
quite limited knowledge of Haskel, Lisp,Tcl,... .
Im confused with most python answers like triple doublequotes.
For me python is 'strong OOP' scripting language in first place.
Inheritance, generalization and every kind of abstractions togeteher
with clean and simple syntax make python perfect language for medium
size "scripting" projects (ie just explore the code and add your
features, no messing with compilers). Exceptions, finally/except
blocks, automatic reference counts and destructors make it easy to
write "robust" code. Packaging system and libraries are just fine.
So, python is just C++ combined with elegancy of Java and simplicity of
scripting.
Again, Im not Lisp programmer, so would like to here about mentioned
features, do those things work as nicely, especially OOP ones?
And IMHO paren misfeature is bad, although you claim it to has some
advantages. Mostly, when I copy code in python I just need to call
increase-left-margin emacs macro and there are no mentioned a+b*c
problem. So, I imagine my typical 1-2 page, max 4-5 nested python
function with great readabilty and almost no refactoring problems and I
need to add 20*2 parens to make it homogenous. :)
Oleg
I was the one mentioning triple-quotes because it was one of the few
Python features i could think of that was better than Lisps.
> For me python is 'strong OOP' scripting language in first place.
> Inheritance, generalization and every kind of abstractions togeteher
> with clean and simple syntax make python perfect language for medium
> size "scripting" projects (ie just explore the code and add your
> features, no messing with compilers).
The Common-Lisp object systems has all and more OO-features, some which
you never probably have thought of before. Here's one:
Inheritance lets you specialise a method so a rectangle and a circle
can have a different Draw method. If you wouldn't have OO you would
need a function with if statements to dispatch on thing, if
thing=rectange then drawRectangle if thing=circle then drawCircle.
What if you want a draw method that takes a thing and a backend, then
you need if statements again, draw(self,backend): if backend ==
postscript do one thing else do another.
Maybe you can solve this with multiple inheritance, creating
RectangePostscript and CirclePostscript objects. Lisp supports multiple
inheritance too, but also multimethods which allow a looser coupling
between objects and dispatching on all parameters, not only the first
parameter (self in python speak). Just define one method
draw(rectange,postscript) and another draw(rectangle, pdf)
> Exceptions, finally/except blocks,
Lisp has a unique exception system. Say ReadHtmlTag throws an exception
deep down in your system, UnexpectedChar. In Lisp you can define
recovery strategies all over your system. the IgnoreAttribute recovery
strategy can be in the same method as ReadHtmlTag. You can have another
ways to recover, IgnoreFile, or ReparseFile higher up in your program.
When you catch the error at the highest point in you main function, you
can choose which recovery you want to use. Either IgnoreAttribute and
continue in the ReadHtmlTag method or ReparseFile in the ParseFile
method. The stack and variables will be there right as when the error
occurred. If I write a library I don't have to guess if the users of my
library wan't me to show a nice GUI error message, ignore the error or
whatever. I provide all options and let they choose.
> automatic reference counts and destructors make it easy to
> write "robust" code.
No, Lisp doesn't have anything like that. There is a thing called the
garbage collector however, I think it exists in other languages.
Mark Tarver wrote:
> How do you compare Python to Lisp?
A little bit OT but I can not resist it. What always impressed me with
Lisp is that LOGO (any one remembers) is Lisp based yet designed to
teach kids programming. I do not know Lisp but used to program a bit in
LOGO - everything was so natural ...
--
alfz1
Mark Tarver napisał(a):
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
IMHO Python is like one of modern european language, Lisp is like Latin.
If You want to know the roots of western culture You should learn Latin
and the same is with Lisp.
Yes, I know, Lisp is not dead.
--
Rafał Strzaliński.
Rafal Strzalinski <···············@nospam.gmail.com> writes:
> IMHO Python is like one of modern european language, Lisp is like Latin.
> If You want to know the roots of western culture You should learn Latin
> and the same is with Lisp.
Why is everyone from Pythonland latching onto this weird meme that
Lisp is only useful for research and academics, or that Lisp is some
kind of computer-scientist-only club? Is this a common Common Lisp
myth that we'll have to start covering in FAQ's, like the one that
says Lisp is interpreted, or the one that claims parens are just a
hack to make parsing easier? Jeff, might be time to update the
Meta-FAQ. The truth is that most academics use Scheme or functional
languages instead of CL. Much as you'd like to think otherwise,
Common Lisp is a practical langauge designed for real-world use.
Seriously.
This is from the perspective of an aerospace engineer who passed
through python several years ago on the way to lisp. Futhermore, this
is a 2 glass of wine response.
Nota Bene: All references to lisp in this response imply common lisp.
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
Way back, my initial motivation for learning python was the desire for
something to post-process data files with a cleaner syntax than perl.
It did that in spades. Despite having taken a C++ course in college, it
wasn't until I started using python that I grokked concepts of object
orientation. The aforementioned course spent too much time on basic
concepts. I also envisioned being able to rapidly prototype things in
python, then migrate them to C for performance. Long term, that was
going to be the value of python, rapid prototype->C for performance.
After writing a C interface for python to an engineering analysis code,
I realized that there was nothing rapid about prototyping in python
then migrating to C. This was also a period of time where there was
some schizophrenia concerning numpy versus numeric python. I know this
has been hashed out now, but at the time it was a distraction from the
development of the library and I lost patience.
So, I began searching for alternatives. Spent a couple years with a
language that requires everything to be an object. Can someone hand me
a hammer, I have a round peg here and a square hole there. Didn't have
good numeric support, but based on other perceived advantages, I had
hashed out an object system that would have provided numeric support.
As I'm implementing the numeric stuff, I'm getting very annoyed with
changes in the language that are requiring redesign of my objects.
Plus, performance, while not bad, is not the best. The work required
starts to outway the benefits, so here I go again, searching for the
one language to rule them all. That's when I seriously consider lisp.
At this point, if lisp doesn't work out, I'm giving up and going back
to fortran, never to look at another language again. Ever.
So, six months ago, I start digging into lisp. Hmm, lisp promotes
functional programming, but you can do imperative if you really want
to, or objective, or aspect, or your own.
What about types? Well, to quote Yogi Berra, "In lisp, types are not
required until they are required." This is great, I can quickly thrash
out some code, profile, correct the algorithm, profile, add types, bam!
Good performance. Looking over CMUCL/SBCL, really good numeric
performance.
Playing with code that is 30 years old, still runs, nice.
Forced to learn emacs, why was I using vi again? In the correct
settings, slime can be fun. Emacs+SBCL is one setting, I'll let you
think of the other.
What the hell are closures? Oh, yeah, now I get it, functions with
state, I can use that in simulations with state vectors, very
intuitive.
And macros? Well, I don't need a domain specific language, yet, but
using macros to build closures with multiple functions and shoving as
much computation into the compilation stage as possible makes for very
fast iteration over ODE's. Now I'm simultaneously iterating over 3
variations of an ODE in less time than iterating over 1 ODE in the
previous one size fits all language.
Code is data is code. I know, a tired old cliche. But for an engineer
who wastes too much time data processing and not enough time
analyzing/understanding said data, this is very powerful and provides a
warm fuzzy feeling. Yet again, that could be the wine.
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
I've been writing code for engineering solutions for 15 years in
various languages. I've gained more insight into coding in the last 6
months then in the previous 15 years. Since lisp allows you to employ
any and every programming technique, it actually requires you to
understand the techniques well enough to apply them when appropriate. I
still respect python if for no other reason than I learned concepts of
object orientation with it, but I don't consider for my coding.
You should study lisp for at least a year, use it for some decent size
projects. At the end of the day, even if you decide not to continue
using it, you will be a much better coder. My bet, though, is that if
you use it for a year, you won't want to use anything else. Don't be
deterred by the parens or the prefix notation. You will have to rewire
your brain to read lisp code, but the effort is worth it. The parens
disappear and there is an elegance and simplicity to prefix notation
that can't be matched by infix.
Time for some more wine.
Cheers,
Tom
"tmh" <··········@gmail.com> writes:
> I've been writing code for engineering solutions for 15 years in
> various languages. I've gained more insight into coding in the last 6
> months then in the previous 15 years. Since lisp allows you to employ
> any and every programming technique, it actually requires you to
> understand the techniques well enough to apply them when appropriate.
You might try Mozart, <http://mozart-oz.org>.
> You should study lisp for at least a year, use it for some decent size
> projects. At the end of the day, even if you decide not to continue
> using it, you will be a much better coder. My bet, though, is that if
> you use it for a year, you won't want to use anything else.
I've used Lisp for a long time and I've implemented it from scratch
(small dialects, not full CL) more than once. There's something
primordial about it that is very satisfying to the inner urges. But
there are higher forms of life out there these days too.
Do you know the Paul Graham piece "Beating the Averages"? It's at:
http://www.paulgraham.com/avg.html
The error in it is that Lisp is really just another Blub.
http://weblog.raganwald.com/2006/10/are-we-blub-programmers.html
Paul Rubin wrote:
>
> Do you know the Paul Graham piece "Beating the Averages"? It's at:
>
> http://www.paulgraham.com/avg.html
>
> The error in it is that Lisp is really just another Blub.
>
> http://weblog.raganwald.com/2006/10/are-we-blub-programmers.html
>
There we find: "But when our hypothetical Blub programmer looks in the
other direction, up the power continuum, he doesn't realize he's looking
up. What he sees are merely weird languages... Blub is good enough for
him, because he thinks in Blub."
What is up the power continuum from Lisp?
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> What is up the power continuum from Lisp?
These days I've been fooling with Haskell. Mozart/Oz is also
interesting.
Ken Tilton wrote:
> What is up the power continuum from Lisp?
3-Lisp. ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
tmh wrote:
<snip>
> Time for some more wine.
...and then just cut and paste the snipped bit into:
http://wiki.alu.org/The_Road_to_Lisp_Survey
...if you are not there already. The survey questions are optional and
what you wrote is perfect as is. Tough call on what goes in:
http://wiki.alu.org/RtL_Highlight_Film
Candidates:
"If you use it for a year, you won't want to use anything else."
"I've gained more insight into coding in the last 6 months then in the
previous 15 years."
I'd go with:
"Yet again, that could be the wine."
:)
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
tmh wrote:
> This is from the perspective of an aerospace engineer who passed
> through python several years ago on the way to lisp. Futhermore, this
> is a 2 glass of wine response.
>
<snip>
Thanks for the comments. I think it is great that you took a "harder
and less travelled way". It may be that some people get to a point
where they are either tired or think they know everything. Or.. their
brains just harden up and they become old dogs.
There seems to be a recurring theme to many of the posts in this thread
about syntax and readability. Some of it is "If I can not instantly
read and understand what the code is doing then something is wrong
with it". As if holding oneself as the standard of what is good and
correct is the only way. If you see something and it
is not readily apparent what it is, then that is a sign than something
interesting may be going on. I got into Lisp because when I
looked at it, I did not understand. I did not think WTF! but thought
that something was going on and maybe I was cheating myself if I
brushed it aside.
There is also some disdain expressed about badly written programs.
Why? They may be that way for some very good reasons, it is folly
to think that programs have to be simple, obvious and elegant. I find
interesting that a programmer got out their comfort zone and attempted
something. Its better than the ones with the big egos who play it safe
so they do not appear to be a fool.
Wade
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
>
> Mark
Advantages of Python:
1). More and better mature standard libraries (Languages don't matter,
libraries do).
2). Multiple programming paradigms (including functional style
programming see itertools, functools, operator modules (lambda, map,
filter, reduce, sum etc builtins), higher order functions, list
comprehension, blah, blah)
3). Better OO implementation. (I used to hate OO until I started using
Python)
4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
said. Bindings for almost any lib worth using, at least on *nix)
5). Clearer syntax.
6). Better namespace management. (nobody ever talks about this, but
Python seems to be one of the few languages that gets symbol management
right from a users perspective)
7). Easier packaging and distribution system.
8). Ubiquity! Python is everywhere. Lisp, bleh.
9). Relatively good docs (PHP has better).
10). Fewer perceived community assholes. Large community.
11). Less fragmentation.
Advantages of Lisp:
Learning a functional language can improve your programming range and
depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
when there's mind bending Haskell. I'd go as far as saying I believe
Haskell has a better fate than Lisp.
On Lisp Macros:
I think they are overrated, and in general cause more harm than good.
It's the reason I find Lisp-like programs difficult to grok, maintain
and extend. Cos every smart ass wants to needlessly write his own mini
language to the point of absolute obfuscation. Naturally, I'm supposed
to be awed by his mischievous cleverness.
Conclusion:
The semantics or features of a language is almost irrelevant today.
Developers want to put the lego pieces together, they don't want to
make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
was popular in the 70s, but it's boring and expensive today. Today,
when a developer needs to solve a problem, the question they ask is,
"Is there a library for that?". If the answer is no, they a more likely
to switch to a language that provides a library that solves their
problem. The challenge for developers today is software architecture,
robustness and scalability, not language purity or semantics. The Lisp,
and to an extent Haskell, community will never ever ever grok this.
They'll continue to wonder why an "inferior" language like Python keeps
getting popular. It will always escape them that it might be because
Python is actually easier to use for most people to write "real world"
applications. It has good usability.
"mystilleef" <··········@gmail.com> writes:
> Mark Tarver wrote:
>> How do you compare Python to Lisp? What specific advantages do you
>> think that one has over the other?
>>
>> Note I'm not a Python person and I have no axes to grind here. This is
>> just a question for my general education.
>>
>> Mark
>
> Advantages of Python:
>
> 1). More and better mature standard libraries (Languages don't matter,
> libraries do).
> 2). Multiple programming paradigms (including functional style
> programming see itertools, functools, operator modules (lambda, map,
> filter, reduce, sum etc builtins), higher order functions, list
> comprehension, blah, blah)
> 3). Better OO implementation. (I used to hate OO until I started using
> Python)
> 4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
> said. Bindings for almost any lib worth using, at least on *nix)
> 5). Clearer syntax.
> 6). Better namespace management. (nobody ever talks about this, but
> Python seems to be one of the few languages that gets symbol management
> right from a users perspective)
> 7). Easier packaging and distribution system.
> 8). Ubiquity! Python is everywhere. Lisp, bleh.
> 9). Relatively good docs (PHP has better).
> 10). Fewer perceived community assholes. Large community.
> 11). Less fragmentation.
Are any of these not subjective?
> Advantages of Lisp:
>
> Learning a functional language can improve your programming range and
Lisp is much more than a functional language.
> depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
> when there's mind bending Haskell. I'd go as far as saying I believe
> Haskell has a better fate than Lisp.
Yeah, that's pretty far.
> On Lisp Macros:
>
> I think they are overrated, and in general cause more harm than good.
> It's the reason I find Lisp-like programs difficult to grok, maintain
> and extend. Cos every smart ass wants to needlessly write his own mini
> language to the point of absolute obfuscation. Naturally, I'm supposed
> to be awed by his mischievous cleverness.
Uh huh. Can you cite examples of this? Sounds like you're just
making stuff up here. Contrary to popular belief, writing a Lisp
macro that warps your mind and introduces a totally un-CL-like
semantics is extremely difficult. Most of the people who are good
enough at CL to do it (I'm certainly not one of them) are also
experienced enough to know when it's the right choice.
And Lisp environments all support getting the macroexpansion,
documentation, and source of any unfamiliar macro you might happen
upon, so really this is not as much of a problem as you might
fantasize it to be.
> Conclusion:
>
> The semantics or features of a language is almost irrelevant today.
> Developers want to put the lego pieces together, they don't want to
> make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
> was popular in the 70s, but it's boring and expensive today. Today,
> when a developer needs to solve a problem, the question they ask is,
> "Is there a library for that?". If the answer is no, they a more likely
> to switch to a language that provides a library that solves their
> problem. The challenge for developers today is software architecture,
> robustness and scalability, not language purity or semantics. The Lisp,
> and to an extent Haskell, community will never ever ever grok this.
> They'll continue to wonder why an "inferior" language like Python keeps
> getting popular. It will always escape them that it might be because
> Python is actually easier to use for most people to write "real world"
> applications. It has good usability.
I don't agree with a lot of what you say in this paragraph, but I
you're right that libraries are crucial. That's why I wish there were
more people writing Lisp libraries instead of being scared away by
sheer fabrications like the stuff that's appearing in this thread.
Bill Atkins wrote:
> Are any of these not subjective?
Objectivity is in the eye of the beholder.
> Lisp is much more than a functional language.
Maybe so. But I've only ever appreciated its functional aspects. I
wouldn't choose Lisp or its derivatives for OO related tasks even if
I'm high.
> Uh huh. Can you cite examples of this? Sounds like you're just
> making stuff up here. Contrary to popular belief, writing a Lisp
> macro that warps your mind and introduces a totally un-CL-like
> semantics is extremely difficult. Most of the people who are good
> enough at CL to do it (I'm certainly not one of them) are also
> experienced enough to know when it's the right choice.
Any sizable Lisp applications will make extensive use of macros. Emacs
and magic ( the web framework) come to mind. My experience has shown
that nobody but the person who writes the DSL extension can maintain
their code. The benefits of extending a language in a domain specific
manner are exaggerated. My observation is that macros are important to
Lisp and it's derivative because they lack libraries to begin with.
Common problems solved using macros in Lisp and friends are solved
using specialized libraries in most other languages. And I like the
specialized libraries route. Meta-programming just doesn't tickle my
fancy. It just spells maintainance nightmare.
> And Lisp environments all support getting the macroexpansion,
> documentation, and source of any unfamiliar macro you might happen
> upon, so really this is not as much of a problem as you might
> fantasize it to be.
How's this a good thing? I don't need a Python environment to grok
Python code.
> I don't agree with a lot of what you say in this paragraph, but I
> you're right that libraries are crucial. That's why I wish there were
> more people writing Lisp libraries instead of being scared away by
> sheer fabrications like the stuff that's appearing in this thread.
People only contribute to things they understand and appreciate. More
people would be writing Lisp libraries if it was worthwhile.
Apparently, it doesn't seem to be. A few years ago, I tried to write an
editor is Scheme. The experience was appalling. I was able to write a
fully functional prototype editor in less than a week in Python.
Shockingly, at the time, I had no experience in Python. Guess which
community I was inclined to contribute to afterwards. I hear stories
similar to mine time and again, yet the Lisp community won't take heed.
They'd rather squeal about the superiority of macros and whine about
their frustrations in Python news groups.
"mystilleef" <··········@gmail.com> writes:
> People only contribute to things they understand and appreciate. More
> people would be writing Lisp libraries if it was worthwhile.
> Apparently, it doesn't seem to be. A few years ago, I tried to write an
> editor is Scheme. The experience was appalling. I was able to write a
> fully functional prototype editor in less than a week in Python.
I remember thinking about writing an editor in Python. One of the
editor functions I couldn't figure out how to implement was
search-backward-regexp. Although the underlying regexp package in
Python's standard library is capable of searching backwards, the
Python lib does not export that feature to where Python code can use
it. RFE #516762 about this has been open for almost 5 years.
"mystilleef" <··········@gmail.com> writes:
> Bill Atkins wrote:
>> Are any of these not subjective?
>
> Objectivity is in the eye of the beholder.
Well, for example, "Lisp uses a fully-parenthesized notation for
writing programs" and "Python has significant whitespace" are both
objective facts. Agreed? There's nothing subjective about those two
facts. Do any of your points approach that level of objectivity?
>> Lisp is much more than a functional language.
>
> Maybe so. But I've only ever appreciated its functional aspects. I
> wouldn't choose Lisp or its derivatives for OO related tasks even if
> I'm high.
Ah yes. Glad you went into so much detail.
>> Uh huh. Can you cite examples of this? Sounds like you're just
>> making stuff up here. Contrary to popular belief, writing a Lisp
>> macro that warps your mind and introduces a totally un-CL-like
>> semantics is extremely difficult. Most of the people who are good
>> enough at CL to do it (I'm certainly not one of them) are also
>> experienced enough to know when it's the right choice.
>
> Any sizable Lisp applications will make extensive use of macros. Emacs
> and magic ( the web framework) come to mind. My experience has shown
> that nobody but the person who writes the DSL extension can maintain
> their code.
What experience is this?
> The benefits of extending a language in a domain specific
> manner are exaggerated.
Great, it's settled then!
(Look elsewhere in this thread for my post about Peter Seibel's
DEFINE-BINARY-CLASS macro.)
> My observation is that macros are important to
> Lisp and it's derivative because they lack libraries to begin with.
> Common problems solved using macros in Lisp and friends are solved
> using specialized libraries in most other languages. And I like the
Macros are not a substitute for libraries, nor are libraries a
substitute for macros. Having macros lets you build more powerful and
more expressive libraries.
> specialized libraries route. Meta-programming just doesn't tickle my
> fancy. It just spells maintainance nightmare.
So it's not just macros but metaprogramming as a whole that bothers
you? You must have an enjoyable time writing programs.
>> And Lisp environments all support getting the macroexpansion,
>> documentation, and source of any unfamiliar macro you might happen
>> upon, so really this is not as much of a problem as you might
>> fantasize it to be.
>
> How's this a good thing? I don't need a Python environment to grok
> Python code.
Nor do you need it to grok Lisp code. The environment is there to
make your life better. I was merely responding to your original claim
that it's impossible to make sense of code that uses macros.
>> I don't agree with a lot of what you say in this paragraph, but I
>> you're right that libraries are crucial. That's why I wish there were
>> more people writing Lisp libraries instead of being scared away by
>> sheer fabrications like the stuff that's appearing in this thread.
>
> People only contribute to things they understand and appreciate. More
> people would be writing Lisp libraries if it was worthwhile.
> Apparently, it doesn't seem to be. A few years ago, I tried to write an
> editor is Scheme. The experience was appalling. I was able to write a
> fully functional prototype editor in less than a week in Python.
> Shockingly, at the time, I had no experience in Python. Guess which
> community I was inclined to contribute to afterwards. I hear stories
> similar to mine time and again, yet the Lisp community won't take heed.
> They'd rather squeal about the superiority of macros and whine about
> their frustrations in Python news groups.
Hmm. Anecdotal evidence about Scheme (a vastly and fundamentally
different language from Common Lisp). Again, you've clinched it for
me.
I do believe that the "squealing and whining about macros" was a
response to Pythonistas claiming that macros are not useful. This was
in turn in response to a foolishly (trollishly?) cross-posted
question. It is not as if we have invaded your newsgroup.
Bill Atkins wrote:
> Well, for example, "Lisp uses a fully-parenthesized notation for
> writing programs" and "Python has significant whitespace" are both
> objective facts. Agreed? There's nothing subjective about those two
> facts. Do any of your points approach that level of objectivity?
I believe so. Even though I wasn't trying to be.
> What experience is this?
Experience working with Scheme code in a project a few years back.
> Macros are not a substitute for libraries, nor are libraries a
> substitute for macros. Having macros lets you build more powerful and
> more expressive libraries.
>
And not having them helps you build less powerful and expressive
libraries?
> > specialized libraries route. Meta-programming just doesn't tickle my
> > fancy. It just spells maintainance nightmare.
>
> So it's not just macros but metaprogramming as a whole that bothers
> you? You must have an enjoyable time writing programs.
In Python, yes.
>
> >> And Lisp environments all support getting the macroexpansion,
> >> documentation, and source of any unfamiliar macro you might happen
> >> upon, so really this is not as much of a problem as you might
> >> fantasize it to be.
> >
> > How's this a good thing? I don't need a Python environment to grok
> > Python code.
>
> Nor do you need it to grok Lisp code. The environment is there to
> make your life better. I was merely responding to your original claim
> that it's impossible to make sense of code that uses macros.
>
Not impossible, just painstaking.
> Hmm. Anecdotal evidence about Scheme (a vastly and fundamentally
> different language from Common Lisp). Again, you've clinched it for
> me.
>
I don't believe my experience would have been marginally different had
I used Common Lisp.
> I do believe that the "squealing and whining about macros" was a
> response to Pythonistas claiming that macros are not useful. This was
> in turn in response to a foolishly (trollishly?) cross-posted
> question. It is not as if we have invaded your newsgroup.
Pythonistas are not saying macros are not useful. They are saying their
usefulness in overrated, exaggerated and needless in the context of
Python. They are saying they don't see what they are missing and along
with the rest of the world couldn't give a damn whether or not it is
ever implemented in Python. Okay, I can't speak for all Pythonistas,
but that's what I'm saying.
"mystilleef" <··········@gmail.com> writes:
>> Macros are not a substitute for libraries, nor are libraries a
>> substitute for macros. Having macros lets you build more powerful and
>> more expressive libraries.
>>
> And not having them helps you build less powerful and expressive
> libraries?
If you told me a turbocharger makes a car accelerate faster, and I
said, "So not having a turbochanger helps your car accelerate slower?"
what would be your reaction?
>> > How's this a good thing? I don't need a Python environment to grok
>> > Python code.
>>
>> Nor do you need it to grok Lisp code. The environment is there to
>> make your life better. I was merely responding to your original claim
>> that it's impossible to make sense of code that uses macros.
>>
>
> Not impossible, just painstaking.
No more so than seeing a function you don't understand. Please be
realistic here. Read through the other posts in this thread, where
this same issue is refuted ad nauseam.
>> Hmm. Anecdotal evidence about Scheme (a vastly and fundamentally
>> different language from Common Lisp). Again, you've clinched it for
>> me.
>>
>
> I don't believe my experience would have been marginally different had
> I used Common Lisp.
Well, believe it. The languages are very different, although they
appear superficially similar to anyone who isn't familiar with both.
The similarity is much like that between Python and Ruby. The two
appear to have very similar syntax, but anyone who knows both knows
that they're quite different underneath.
>> I do believe that the "squealing and whining about macros" was a
>> response to Pythonistas claiming that macros are not useful. This was
>> in turn in response to a foolishly (trollishly?) cross-posted
>> question. It is not as if we have invaded your newsgroup.
>
> Pythonistas are not saying macros are not useful. They are saying their
> usefulness in overrated, exaggerated and needless in the context of
> Python. They are saying they don't see what they are missing and along
> with the rest of the world couldn't give a damn whether or not it is
> ever implemented in Python. Okay, I can't speak for all Pythonistas,
> but that's what I'm saying.
Of course they're overrated - *because you don't have them*. It would
be amusing to see how Python's collective tune would change if Guido
issued a royal edict that "Python 3000" (hehehehe) will support
syntactic extensions. If Python had macros, would you really
complain, or would you appreciate the extra expressive power?
On the other hand, I am willing to agree with all of you Pythoners
that Python is winning in the library department. So are Perl and
Ruby. It would be silly for me to claim that libraries are
"overrated," just because other languages have more of them. The
truth is that I would like to have macros, libraries, and Lisp's
interactive development model, all at once.
But your claim upthread that Lisp doesn't have libraries because it's
not "worthwhile" is unfounded. When all of the AI companies collapsed
in the late 80's and early 90's, Lisp went comatose by association.
The revival of Lisp as a tool for doing modern programming dates back
only to about 2000 or so. So six years along, we are behind other
languages that have had active communities for ten years (Ruby),
fifteen years (Python), and nearly twenty years (Perl). I am not
worried about the future of Lisp libraries. We already have some:
- CL-PPCRE, a pure-Lisp regular expression package that is faster than Perl's
- Hunchentoot, a complete web server and web development framework
- CAPI, a proprietary but excellent GUI library
- CommonSQL (and CLSQL, its open-source offspring)
- parenscript, an embeddable Lisp that compiles to Javascript, letting
you use macros in your Javascript code
- assorted useful libraries, like MD5, base64, SDL, XML parsers, web
page fetchers, testing frameworks
- bindings to the common C libraries, like GD, Tk, Gtk+
We will get there, in time. Lisp is still the only language in
history to linger in "mostly dead" status for a decade and then be
resurrected; it is capable of more surprises yet.
Bill Atkins <······@rpi.edu> writes:
> worried about the future of Lisp libraries. We already have some:
>
> - CL-PPCRE, a pure-Lisp regular expression package that is faster than Perl's
> - Hunchentoot, a complete web server and web development framework
> - CAPI, a proprietary but excellent GUI library
> - CommonSQL (and CLSQL, its open-source offspring)
> - parenscript, an embeddable Lisp that compiles to Javascript, letting
> you use macros in your Javascript code
> - assorted useful libraries, like MD5, base64, SDL, XML parsers, web
> page fetchers, testing frameworks
> - bindings to the common C libraries, like GD, Tk, Gtk+
Lest anyone interpret that list as exhaustive: http://www.cl-user.net/
Bill Atkins <······@rpi.edu> writes:
> Lest anyone interpret that list as exhaustive: http://www.cl-user.net/
What have you got for concurrency? How would you write a
multi-threaded web server in Lisp?
Paul Rubin <·············@NOSPAM.invalid> writes:
> Bill Atkins <······@rpi.edu> writes:
>> Lest anyone interpret that list as exhaustive: http://www.cl-user.net/
>
> What have you got for concurrency? How would you write a
> multi-threaded web server in Lisp?
Multithreading is not a standard part of ANSI CL, but in practice all
Lisps (with the major exception of the CLISP implementation) support
threading.
Hunchentoot is, in fact, a multi-threaded web server written in Lisp.
:) There are also others, like AllegroServe and Araneida.
There are compatibility layers that smooth over some of these
implementation-dependent areas of Common Lisp. Bordeaux-threads is
the package that provides a common interface to the different
threading implementations:
http://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation
mystilleef wrote:
> Bill Atkins wrote:
>
>>Are any of these not subjective?
>
>
> Objectivity is in the eye of the beholder.
>
>
>>Lisp is much more than a functional language.
>
>
> Maybe so. But I've only ever appreciated its functional aspects. I
> wouldn't choose Lisp or its derivatives for OO related tasks even if
> I'm high.
But CLOS is the best OO there is. The OMG said so. It can do anything
any other OO can do. Why /specifically/ would you not use it? This type
of thread has no educational value unless one is specific; we already
know what the posters like and prefer, so the only added value comes
from being specific about language details. And funny put-downs. :)
>
>
>>Uh huh. Can you cite examples of this? Sounds like you're just
>>making stuff up here. Contrary to popular belief, writing a Lisp
>>macro that warps your mind and introduces a totally un-CL-like
>>semantics is extremely difficult. Most of the people who are good
>>enough at CL to do it (I'm certainly not one of them) are also
>>experienced enough to know when it's the right choice.
>
>
> Any sizable Lisp applications will make extensive use of macros.
Hopefully, because any sizeable app will have its sum functionality
compartmentalized into internal little sub-APIs. These five/ten data
structures and functions have been created to handle this recurring
problem faced by higher-order functions. Sometimes dealing with that API
requires boilerplate code to be written. Set things up. Make a call.
Check the return status for xyz. etc etc. That boilerplate can become a
macro, such as WITHOUT-C-DEPENDENCY:
(defmacro without-c-dependency (&body body)
`(let (*call-stack*) ,@body))
*CALL-STACK* is internal to Cells and should not be exposed. It is cool
that all I need do to defeat the entire Cells engine is bind one special
variable, but maybe someday that will get hairier. if so, no problem, I
just change the macro. Btw, without special variables, you would need:
(let ((save-stack *call-stack*)
(setf *call-stack* nil)
<your code here, possibly trapping errors>
(setf *call-stack* save-stack))
If you want to use a function instead of a macro and still hide the
boilerplate, it would have to be:
(without-c-dependency (lambda () <your-code-here>))
Not the end of the world and at least one Lisp legend thinks that makes
macros unnecessary.
> Emacs
> and magic ( the web framework) come to mind. My experience has shown
> that nobody but the person who writes the DSL extension can maintain
> their code.
You and GvR are thinking of the case where a macro is used to create a
whole new syntax, like LOOP (a mildly controversial part of standard
Lisp). I have written more macros than you can imagine and only once
even came close to it (but the language was just a list of things to do,
nothing incomprehensible). I have never seen a macro which introduced a
new language.
Of course, we all keep saying this and you all keep repeating the
opposite, so we do appreciate the excuse to repeatedly explain how
macros are really used. :)
> The benefits of extending a language in a domain specific
> manner are exaggerated.
Careful, there are laws now against cruelty to straw men.
> My observation is that macros are important to
> Lisp and it's derivative because they lack libraries to begin with.
Damn! Exactly which macro would have saved me creating bindings to
OpenGL? (I think you have a little category error going here.)
> Common problems solved using macros in Lisp and friends are solved
> using specialized libraries in most other languages.
Damn! Exactly which macro would have saved me creating bindings to
OpenGL? (I think you have a little category error going here.)
> And I like the
> specialized libraries route.
Damn! Exactly which macro would have saved me creating bindings to
OpenGL? (I think you have a little category error going here.)
> Meta-programming just doesn't tickle my
> fancy. It just spells maintainance nightmare.
The whole idea of meta-programming is reducing coding and simplifying
maintenance, so I have to wonder how much experience you have writing
macros. Could you post a few?
Macros come into play when we find a pattern in out code that is a level
more abstract than straight token replacement (ala C) will support. My
simple example above is just about avoiding typing LAMBDA, which I hate.
:) More interesting macros take a look at the input source to the acro
invocation and, instead of subsituting in a fixed template as does the C
preprocessor, actively assembles template bits and input bits to produce
the final result.
Of course one has to be clever enough to see higher-order patterns and
appreciate the vast productivity increase available in return for the
effort of thinking through a macro -- well, i should note that often I
do not create the macro until I see also that this bit of internal API
will be coming up often enough (or will be changing often enough as I
come to understand it) to make the effort of carving out a macro
worthwhile -- or, yes, the point of macros will be lost on you.
That's OK. I once knew a guy who cut and pasted code to create tens of
duplicates rather than create a function. He was not stupid, but clearly
there was something wrong upstairs. I think to him it was somehow
"simpler" than getting involved with these complicated function things.
Sound familiar? :)
>>And Lisp environments all support getting the macroexpansion,
>>documentation, and source of any unfamiliar macro you might happen
>>upon, so really this is not as much of a problem as you might
>>fantasize it to be.
>
>
> How's this a good thing? I don't need a Python environment to grok
> Python code.
How would that be a bad thing? Do you do a lot of programming without a
Python environment. But I love the wall of flak you are throwing up. :)
>
>
>>I don't agree with a lot of what you say in this paragraph, but I
>>you're right that libraries are crucial. That's why I wish there were
>>more people writing Lisp libraries instead of being scared away by
>>sheer fabrications like the stuff that's appearing in this thread.
>
>
> People only contribute to things they understand and appreciate.
<cough>
> More
> people would be writing Lisp libraries if it was worthwhile.
We are, now that a few application programmers have landed on her
shores. Most Lispniks are just useless groupie wannabes coding Java all
day to pay the bills with no energy for programming when they get home.
> Apparently, it doesn't seem to be. A few years ago, I tried to write an
> editor is Scheme. The experience was appalling.
Damn. I wish this was the quarterly Lisp vs Scheme flamewar.
> I was able to write a
> fully functional prototype editor in less than a week in Python.
> Shockingly, at the time, I had no experience in Python. Guess which
> community I was inclined to contribute to afterwards. I hear stories
> similar to mine time and again, yet the Lisp community won't take heed.
> They'd rather squeal about the superiority of macros and whine about
> their frustrations in Python news groups.
>
You seem to be the unhappy one. We are just here correcting FUD. We are
ecstatic with Lisp and would not want anyone to miss out on it because
of your misnformation. No one cares if you try it and decide against or
do not try it based on good information.
But for someone to miss out on Lisp because of your deliberate
misrepresentation would be a shame.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Sat, 09 Dec 2006 17:01:15 -0500, Ken Tilton wrote:
>> How's this a good thing? I don't need a Python environment to grok
>> Python code.
>
> How would that be a bad thing? Do you do a lot of programming without a
> Python environment. But I love the wall of flak you are throwing up. :)
Actually, yes, sometimes it is useful to print code out and read it on the
train, or in the bath, without the advantage of syntax highlighting,
pretty-printing, parenthesis-balancing or code folding. Not necessarily as
pleasant as having all those things, but it is nice that working Python
code is, by definition, already formatted correctly for pretty printing.
Even if you're stuck on some god-forsaken Windows PC with just Notepad,
you can still read Python code.
Now, *writing* Python code with Notepad isn't as easy, but it is still
doable. How about Lisp code?
That's not a criticism of Lisp exactly, but a reminder to think about not
just what problem you're trying to solve, but what resources you will have
to solve it. If you *know* that you're going to need to edit code by
ssh-ing across an high-latency connection to a machine without Emacs, then
Lisp will probably not be the best solution.
The day has not yet arrived that nobody ever needs to edit code in a
plain, vanilla text editor.
--
Steven.
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> Even if you're stuck on some god-forsaken Windows PC with just Notepad,
> you can still read Python code.
>
> Now, *writing* Python code with Notepad isn't as easy, but it is still
> doable. How about Lisp code?
I've generally used IDLE when editing Python under Windows. It comes
with the Python distro after all.
Yes, very large systems have been developed with much worse editing
facilities than Notepad. Specifically, through the whole 1960's and
early 1970's, display terminals were a rarity and people usually
edited code (whether in Lisp or another language) on printing
terminals (usually noisy Teletypes). It gets worse than that. In the
very early days (the Lisp terms "car" and "cdr" are derived from names
of registers of the ancient IBM 709 mainframes) they used punch card
systems instead of printing terminals. It gets worse than THAT. One
of the important historical Lisp applications was James R. Slagle's
SAINT symbolic integration program on the IBM 704. Written on punched
cards. Except Slagle sadly became blind while writing this program,
so he did a fair amount of the development by feeling the holes in the
cards with his fingers to read them. I don't think anyone writes
Python that way ;-).
> The day has not yet arrived that nobody ever needs to edit code in a
> plain, vanilla text editor.
It's not impossible or terribly difficult to write Lisp that way, it's
just unpleasant, once you've gotten used to doing it with editors that
automatically indent and balance parens.
On Sat, 09 Dec 2006 19:31:38 -0800, Paul Rubin wrote:
>> The day has not yet arrived that nobody ever needs to edit code in a
>> plain, vanilla text editor.
>
> It's not impossible or terribly difficult to write Lisp that way, it's
> just unpleasant, once you've gotten used to doing it with editors that
> automatically indent and balance parens.
Er, an editor that does that is not a plain, vanilla text editor.
--
Steven.
In some cases lisp macros are a way of saying tomato to something
that would be called "tomahto" in python.
One common use of macros is custom iteration constructs. In my
social network analysis I wanted to do something to each and every
sender-recipient pair in the header line of "mail" messages in my
dataset. (And yes, I did have permission to use this data.) Each
message had one sender, but possibly multiple recipients. Since I
would be doing multiple forms of analysis, I might as well create
one iterator to do this.
The DO-MAIL-RELATIONS macro takes the mail message (line), parses
the sender field and assigns it to (sender), splits the recipient
field and assigns it to (recip) and then performs the logic in the
body which often involved looking up values in a database, and
setting values in a matrix.
(kirk.matrix-process:do-mail-relations (message sender recip)
;;about 12 lines of logic snipped
)
To be pedantic about this call. "KIRK.MATRIX-PROCESS" identifies the
package/namespace for the macro call. "DO-MAIL-RELATIONS" names the
macro as part of the DO family of iteration constructs which are
basic to lisp.
Now that I think about this, in python I'd probably do this using
object logic that returned the recipient list as an iteratable
object:
for sender, recipient in message.relationPairs:
#about 12 lines of logic
Would it have been possible to implement DO-MAIL-RELATIONS as a
function? Possibly, but I found trying to compact all of that logic
into a single-use function that could be safely passed to another
function to be more trouble.
Another common macro use is the "WITH-STREAM" family which opens a
stream for IO and closes it at the end.
(with-open-file (file-handle "filename" :direction :output)
(format file-handle "Hello world.~%")
)
The pythonic way to do this would be to create a class that
implements file-like behaviors:
output = fileLike.open()
output.write("Hello world\n")
output.close()
You might want to use a custom "WITH-STREAM" macro or file-like
object if you need to format, filter, or compress the outgoing
stream in any way.
Kirk Sluder <····@nospam.jobsluder.net> writes:
> Another common macro use is the "WITH-STREAM" family which opens a
> stream for IO and closes it at the end.
> (with-open-file (file-handle "filename" :direction :output)
> (format file-handle "Hello world.~%")
> )
>
> The pythonic way to do this would be to create a class that
> implements file-like behaviors:
>
> output = fileLike.open()
> output.write("Hello world\n")
> output.close()
Actually the Python example can lose (e.g. leak a file descriptor
temporarily) if output.write raises an exception (prevents
output.close from running). For this reason Python recently
introduced the "with" statement:
with output as fileLike.open():
output.write("Hello world\n")
Here the file gets closed automatically (by running an exit method in
the fileLike class) when the "with" block exits, whether normally or
through an exception.
In article <··············@ruckus.brouhaha.com>,
Paul Rubin <·············@NOSPAM.invalid> wrote:
> Kirk Sluder <····@nospam.jobsluder.net> writes:
> > The pythonic way to do this would be to create a class that
> > implements file-like behaviors:
....
>
> Actually the Python example can lose (e.g. leak a file descriptor
> temporarily) if output.write raises an exception (prevents
> output.close from running). For this reason Python recently
> introduced the "with" statement:
>
> with output as fileLike.open():
> output.write("Hello world\n")
>
> Here the file gets closed automatically (by running an exit method in
> the fileLike class) when the "with" block exits, whether normally or
> through an exception.
Ohhh, shiny!
Steven D'Aprano wrote:
> The day has not yet arrived that nobody ever needs to edit code in a
> plain, vanilla text editor.
Gee, 200kloc of Lisp and I have not got there yet. Keep banging that
drom, Steve. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> On Sat, 09 Dec 2006 17:01:15 -0500, Ken Tilton wrote:
>
>>> How's this a good thing? I don't need a Python environment to grok
>>> Python code.
>>
>> How would that be a bad thing? Do you do a lot of programming without a
>> Python environment. But I love the wall of flak you are throwing up. :)
>
> Actually, yes, sometimes it is useful to print code out and read it on the
> train, or in the bath, without the advantage of syntax highlighting,
> pretty-printing, parenthesis-balancing or code folding. Not necessarily as
> pleasant as having all those things, but it is nice that working Python
> code is, by definition, already formatted correctly for pretty printing.
> Even if you're stuck on some god-forsaken Windows PC with just Notepad,
> you can still read Python code.
>
> Now, *writing* Python code with Notepad isn't as easy, but it is still
> doable. How about Lisp code?
Of course we can read Lisp without IDE's; we look for indentation cues
just as you guys do.
> That's not a criticism of Lisp exactly, but a reminder to think about not
> just what problem you're trying to solve, but what resources you will have
> to solve it. If you *know* that you're going to need to edit code by
> ssh-ing across an high-latency connection to a machine without Emacs, then
> Lisp will probably not be the best solution.
Oh no? Emacs lets you save and write files over an SSH connection,
even if you end up in the strange straw man situation you're
describing ("yeah, but can you edit Lisp if your keyboard doesn't have
paren keys?").
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>
> Even if you're stuck on some god-forsaken Windows PC with just
> Notepad, you can still read Python code.
Ummm...Lisp ain't APL--it's just ASCII (or ISO-8859-1 or Unicode or
whatever...), and thus just as readable in Notepad as anything else.
> Now, *writing* Python code with Notepad isn't as easy, but it is still
> doable. How about Lisp code?
Given that fellows were writing Lisp code before there were CRTs
(e.g. using teletypes to type), it's quite doable. Would I want to do
so? Of course not, no more than I'd want to write Python in Notepad.
> The day has not yet arrived that nobody ever needs to edit code in a
> plain, vanilla text editor.
My platform has emacs and vi by default. There are editors as
brain-damaged as Notepad, but I never use them, and in an emergency they
wouldn't run (as they require X).
Now, force me to write Lisp _or_ Python in ed and things will get very
ugly...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Whoa, there. Those are some strong words for somebody who doesn't
even own a machine gun. --Milkman Dan
mystilleef wrote:
>
> People only contribute to things they understand and appreciate. More
> people would be writing Lisp libraries if it was worthwhile.
> Apparently, it doesn't seem to be. A few years ago, I tried to write an
> editor is Scheme. The experience was appalling. I was able to write a
> fully functional prototype editor in less than a week in Python.
> Shockingly, at the time, I had no experience in Python. Guess which
> community I was inclined to contribute to afterwards. I hear stories
> similar to mine time and again, yet the Lisp community won't take heed.
> They'd rather squeal about the superiority of macros and whine about
> their frustrations in Python news groups.
>
Hmm.. Here is my first prototype in Lisp. It took 20 seconds
to write.
(defun display-editor ()
(capi:contain (make-instance 'capi:editor-pane)))
CL-USER 1 > (display-editor)
#<CAPI:EDITOR-PANE 2069F40C>
CL-USER 2 >
W
On Sat, 09 Dec 2006 22:04:04 +0100, mystilleef <··········@gmail.com>
wrote:
> Bill Atkins wrote:
>> Are any of these not subjective?
>
> Objectivity is in the eye of the beholder.
>
>> Lisp is much more than a functional language.
>
> Maybe so. But I've only ever appreciated its functional aspects. I
> wouldn't choose Lisp or its derivatives for OO related tasks even if
> I'm high.
>
You are just being silly.
Lisp's OO environment CLOS is vastly superior to Python classes.
Both in terms of expressive power and flexibility.
You might even find out if you ever learnt how to use it.
Lisp also supports procedural programming just fine.
In the windows world the best way to access system libraries are
via .NET. Thus each language inventing it's own libraries is quickly
becoming
a thing of the past. Also you can mix and match languages according to
need.
Python is fine if you approach programming as Lego, simply gluing together
libraries.
But if you want to do some serious algorithmic's you may find that it is
just to slow.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> You are just being silly.
> Lisp's OO environment CLOS is vastly superior to Python classes.
> Both in terms of expressive power and flexibility.
> You might even find out if you ever learnt how to use it.
>
Donkeys have wings.
> In the windows world the best way to access system libraries are
> via .NET. Thus each language inventing it's own libraries is quickly
> becoming
You're only proving my point. Why do you think most windows developers
use .NET?
> Python is fine if you approach programming as Lego, simply gluing together
> libraries.
You mean it's fine for what 90% of programmers do?
> But if you want to do some serious algorithmic's you may find that it is
> just to slow.
Slow for users who aren't familiar with Psyco, Pyrex and C extensions,
sure.
"mystilleef" <··········@gmail.com> writes:
> Slow for users who aren't familiar with Psyco, Pyrex and C extensions,
> sure.
Psyco is not included in the Python distro. Pyrex and C extensions
depend on having C compilers available for every target platform. As
a Linux user, if I want to release Python programs that Windows users
will run, I cannot use C extensions because I have no way to compile
them for Windows, and most Windows users don't have C compilers
either.
Anyway it's pretty lousy advocacy for a language to say "well if the
language is too slow, don't use it, use another langauge like C instead".
I think PyPy will make a big difference when it becomes part of
regular Python but for now it's vaporware.
Paul Rubin wrote:
> "mystilleef" <··········@gmail.com> writes:
> > Slow for users who aren't familiar with Psyco, Pyrex and C extensions,
> > sure.
>
>
> Anyway it's pretty lousy advocacy for a language to say "well if the
> language is too slow, don't use it, use another langauge like C instead".
Python can be used as a glue language. It is not solely a glue
language.
A lot of people find using Python to script libraries written in other
languages
a way to get things done. Ask the scipy guys or the biopython guys.
The Python community actively encourages groups writing useful
libraries
to maintain a Python port, or Python users might wrap libraries
themselves.
You don't always wrap a module in Python for reasons of speed of
execution.
Software testing may well be easier to do in Python than in the
native language of the wrapped library. The library itself may be
better
used in the dynamic environment of Pythons command line; or used
together
with other libraries already wrapped for/accessible from Python.
- Paddy.
"Paddy" <·········@netscape.net> writes:
> Python can be used as a glue language. It is not solely a glue
> language.
> A lot of people find using Python to script libraries written in other
> languages
> a way to get things done. Ask the scipy guys or the biopython guys.
Sure, connecting together programs and libraries that were written in other
languages is what a glue language is.
> You don't always wrap a module in Python for reasons of speed of
> execution.
>
> Software testing may well be easier to do in Python than in the
> native language of the wrapped library. ...
That's the thing, those modules are written in languages other than
Python because Python is not attractive for coding those functions
directly in Python. That is a real weakness of Python and glossing
over it by saying to write the functions in other languages and then
wrap them in the C API is not a very impressive answer. For example,
Lisp is routinely used for writing scientific and numerical code
directly with performance comparable to C or whatever. There is no
need to mess with wrapping modules written in other languages, an
operation which should not be trivialized.
Paul Rubin wrote:
> "Paddy" <·········@netscape.net> writes:
> > Python can be used as a glue language. It is not solely a glue
> > language.
> > A lot of people find using Python to script libraries written in other
> > languages
> > a way to get things done. Ask the scipy guys or the biopython guys.
>
> Sure, connecting together programs and libraries that were written in other
> languages is what a glue language is.
>
> > You don't always wrap a module in Python for reasons of speed of
> > execution.
> >
> > Software testing may well be easier to do in Python than in the
> > native language of the wrapped library. ...
>
> That's the thing, those modules are written in languages other than
> Python because Python is not attractive for coding those functions
> directly in Python. That is a real weakness of Python and glossing
> over it by saying to write the functions in other languages and then
> wrap them in the C API is not a very impressive answer. For example,
> Lisp is routinely used for writing scientific and numerical code
> directly with performance comparable to C or whatever. There is no
> need to mess with wrapping modules written in other languages, an
> operation which should not be trivialized.
You failed to see that Python accepts that useful work is out their,
already written, and some of it is not written in Python.
Would you say that All useful code is only written in Lisp? Or that all
future useful code will only be written in Lisp?
You could waste a lot of time re-writing what is already available, in
Lisp.
- Paddy.
mystilleef wrote:
> John Thingstad wrote:
> > You might even find out if you ever learnt how to use it.
>
> Donkeys have wings.
Please stop misinforming your fellow Python users. Feel free to look up
"CLOS" and the "metaobject protocol." Further, Lisp is not a functional
language like Scheme; it has unusually powerful iteration and array
facilities.
Common Lisp's OOP has multiple inheritance, a metaobject protocol,
method combinations, generic functions. I realize these sound like
buzzwords to you; I vaguely recall this being a nice video intro:
<http://www.archive.org/details/DanielGB1987>
Alan Kay coined the term object oriented programming, and I think
you'll enjoy his keynote "The computer revolution hasn't happened yet."
At 54:30, he praised the book explaining Common Lisp's metobject
protocol as being the "best book anybody's written in ten years", for
containing "some of the most profound insights, and the most practical
insights about OOP, that anybody has done about OOP in the last many
years."
<http://video.google.com/videoplay?docid=-2950949730059754521>
And he offered a Limoge Balloon award to anyone who'd simply rewrite
the book so that the general OOP community could understand it, for
being "a great service to mankind."
The concepts in that book underlie Lisp's modern OOP system.
Further, you portray Lisp as a "functional" language. But it is a
powerful iterative language. Check out LOOP, a powerful iteration
facility. Check out its powerful multidimensional arrays, which are
adjustable and have fill-pointers.
There exist legitimate criticisms of Common Lisp, and I've even written
a page with "gotchas." One should remain appropriately skeptical of
Lisp users' claims, because they too can mislead. I wish we could
critique thoughtfully. On the basis of facts, not invented claims.
Tayssir
············@googlemail.com wrote
> Further, Lisp is not a functional
> language like Scheme; it has unusually powerful iteration and array
> facilities.
Excuse me, I mean to say it is not a pure functional language.
Tayssir
On Sat, 09 Dec 2006 22:49:59 +0100, mystilleef <··········@gmail.com>
wrote:
>
> Donkeys have wings.
>
? You attitude towards CLOS is obviously insane.
>> In the windows world the best way to access system libraries are
>> via .NET. Thus each language inventing it's own libraries is quickly
>> becoming
>
> You're only proving my point. Why do you think most windows developers
> use .NET?
>
Lisp can also use .NET. .NET =/= C#
>> Python is fine if you approach programming as Lego, simply gluing
>> together
>> libraries.
>
> You mean it's fine for what 90% of programmers do?
>
Yes CRUD (Create, Read Update, Delete)..
Sure you can do that in any languge..
Not sure I would call it programming.
>> But if you want to do some serious algorithmic's you may find that it is
>> just to slow.
>
> Slow for users who aren't familiar with Psyco, Pyrex and C extensions,
> sure.
>
Even then..
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
mystilleef wrote:
> John Thingstad wrote:
>> You are just being silly.
>> Lisp's OO environment CLOS is vastly superior to Python classes.
>> Both in terms of expressive power and flexibility.
>> You might even find out if you ever learnt how to use it.
>>
>
> Donkeys have wings.
And thus you think you can fly?
>> In the windows world the best way to access system libraries are
>> via .NET. Thus each language inventing it's own libraries is quickly
>> becoming
>
> You're only proving my point. Why do you think most windows developers
> use .NET?
I didn't realize .NET is a *language*.
>> Python is fine if you approach programming as Lego, simply gluing together
>> libraries.
>
> You mean it's fine for what 90% of programmers do?
>
>> But if you want to do some serious algorithmic's you may find that it is
>> just to slow.
>
> Slow for users who aren't familiar with Psyco, Pyrex and C extensions,
> sure.
>
On Sat, 09 Dec 2006 22:29:45 +0100, John Thingstad wrote:
>> Maybe so. But I've only ever appreciated its functional aspects. I
>> wouldn't choose Lisp or its derivatives for OO related tasks even if
>> I'm high.
>>
>
> You are just being silly.
> Lisp's OO environment CLOS is vastly superior to Python classes.
> Both in terms of expressive power and flexibility.
Oh, well, with evidence like that, I'm convinced!
> Python is fine if you approach programming as Lego, simply gluing
> together libraries.
> But if you want to do some serious algorithmic's you may find that it is
> just to slow.
Nobody ever said that Python was idea for serious number crunching
(although see numpy -- use the right tool for the job). If I knew what
sort of "serious algorithmics" you meant, I could comment.
--
Steven.
"mystilleef" <··········@gmail.com> writes:
>
> Any sizable Lisp applications will make extensive use of macros. Emacs
> and magic ( the web framework) come to mind.
$ cat `find /usr/share/emacs/ -name '*.el' -print ` | grep defmacro | wc -l
1393
$ cat `find /usr/share/emacs/ -name '*.el' -print ` | grep defun | wc -l
29244
So it looks like there's one macro for every twenty-one functions. That
doesn't seem too extensive, nor too scarce.
> My experience has shown that nobody but the person who writes the DSL
> extension can maintain their code.
Emacs has been used for almost thirty years now, by tens (hundreds?) of
thousands of programmers, and extended by almost every one of them.
> The benefits of extending a language in a domain specific manner are
> exaggerated.
Certainly they seem useful to the authors of such packages as BBDB and
emacs-w3m.
--
Robert Uhl <http://public.xdi.org/=ruhl>
As a client for MS Exchange, MS Outlook is quite good. As an Internet
e-mail client [e.g, POP3/IMAP], it's roughly equivalent to strapping a
few pounds of plastique to your gonads and painting a day-glo orange
bulls-eye on your knickers. -- Morely Dotes in nan-ae
"mystilleef" <··········@gmail.com> writes:
> Advantages of Python:
>
> 1). More and better mature standard libraries (Languages don't matter,
> libraries do).
Erm, somewhat true, but Python's library is overrated. Lisp's on the
other hand is out of date.
> 2). Multiple programming paradigms (including functional style
> programming see itertools, functools, operator modules (lambda, map,
> filter, reduce, sum etc builtins), higher order functions, list
> comprehension, blah, blah)
Getting there but still full of warts.
> 3). Better OO implementation. (I used to hate OO until I started using
> Python)
Have you used CLOS? Flavors?
> 4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
> said. Bindings for almost any lib worth using, at least on *nix)
Hmm, Python's C API is awful compared with the FFI's in reasonable
Lisp implementations or to Java's JNI.
> 5). Clearer syntax.
OK.
> 6). Better namespace management. (nobody ever talks about this, but
> Python seems to be one of the few languages that gets symbol management
> right from a users perspective)
I dunno, Python gets some things completely wrong in this regard.
> 7). Easier packaging and distribution system.
Because there's basically just one Python implementation (CPython).
> 8). Ubiquity! Python is everywhere. Lisp, bleh.
Not so sure of this, unless you're limiting to Common Lisp. There are
Lisp systems out there that use as little as 20k of memory, running
inside cellular phones etc. By comparison an attempt to shoehorn
Python into the 1 megabyte Palm handheld computer was abandoned.
> 9). Relatively good docs (PHP has better).
Lisp's docs are far superior to Python's. This is one of the areas
where I bag on Python all the time.
> 10). Fewer perceived community assholes. Large community.
> 11). Less fragmentation.
True and true.
> Advantages of Lisp:
>
> Learning a functional language can improve your programming range and
> depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
> when there's mind bending Haskell. I'd go as far as saying I believe
> Haskell has a better fate than Lisp.
I don't really of think Lisp as a functional language; its data
representation is what makes it worth knowing. Despite years of
experience with Lisp and Python I'm still having trouble wrapping my
head around Haskell, and that tells me Haskell is really doing stuff
that Lisp does not.
> On Lisp Macros:
>
> I think they are overrated, and in general cause more harm than good.
> It's the reason I find Lisp-like programs difficult to grok, maintain
> and extend. Cos every smart ass wants to needlessly write his own mini
> language to the point of absolute obfuscation. Naturally, I'm supposed
> to be awed by his mischievous cleverness.
There is certainly the possibility of writing Lisp code that way, but
it's not all that big a problem when the code is written tastefully.
> Conclusion:
>
> The semantics or features of a language is almost irrelevant today.
> Developers want to put the lego pieces together, they don't want to
> make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
> was popular in the 70s, but it's boring and expensive today. Today,
> when a developer needs to solve a problem, the question they ask is,
> "Is there a library for that?".
But it seems to me that Java crushes Python in this regard.
In article <························@j44g2000cwa.googlegroups.com>,
"mystilleef" <··········@gmail.com> wrote:
> 1). More and better mature standard libraries (Languages don't matter,
> libraries do).
....
> On Lisp Macros:
>
> I think they are overrated, and in general cause more harm than good.
> It's the reason I find Lisp-like programs difficult to grok, maintain
> and extend. Cos every smart ass wants to needlessly write his own mini
> language to the point of absolute obfuscation. Naturally, I'm supposed
> to be awed by his mischievous cleverness.
I've not seen a convincing explanation as to why imported macros
from some library are so much more evil than imported functions. In
both cases one might have to dig into documentation and/or comments
to understand exactly what that imported snippit is doing.
Kirk Sluder <····@nospam.jobsluder.net> writes:
> In article <························@j44g2000cwa.googlegroups.com>,
> "mystilleef" <··········@gmail.com> wrote:
>
>> 1). More and better mature standard libraries (Languages don't matter,
>> libraries do).
> ....
>> On Lisp Macros:
>>
>> I think they are overrated, and in general cause more harm than good.
>> It's the reason I find Lisp-like programs difficult to grok, maintain
>> and extend. Cos every smart ass wants to needlessly write his own mini
>> language to the point of absolute obfuscation. Naturally, I'm supposed
>> to be awed by his mischievous cleverness.
>
> I've not seen a convincing explanation as to why imported macros
> from some library are so much more evil than imported functions. In
> both cases one might have to dig into documentation and/or comments
> to understand exactly what that imported snippit is doing.
And the difference with a library function is?
(defpackage "LIBRARY" (:export "THIS-IS-A-FUNCTION"))
(library:this-is-a-function ???) ; ???
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
Pascal Bourguignon wrote:
> Kirk Sluder <····@nospam.jobsluder.net> writes:
>
>
>>In article <························@j44g2000cwa.googlegroups.com>,
>> "mystilleef" <··········@gmail.com> wrote:
>>
>>
>>>1). More and better mature standard libraries (Languages don't matter,
>>>libraries do).
>>
>>....
>>
>>>On Lisp Macros:
>>>
>>>I think they are overrated, and in general cause more harm than good.
>>>It's the reason I find Lisp-like programs difficult to grok, maintain
>>>and extend. Cos every smart ass wants to needlessly write his own mini
>>>language to the point of absolute obfuscation. Naturally, I'm supposed
>>>to be awed by his mischievous cleverness.
>>
>>I've not seen a convincing explanation as to why imported macros
>>from some library are so much more evil than imported functions. In
>>both cases one might have to dig into documentation and/or comments
>>to understand exactly what that imported snippit is doing.
>
>
> And the difference with a library function is?
Uh, that was his point.
And if you all dig back thru this thread you will find me quoting GvR on
the difference, which is (paraphrasing) "with macros you do not even
know where the function calls are". I think he is talking about a
loop-like erection of a new language.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Kirk Sluder <····@nospam.jobsluder.net> writes:
> > I've not seen a convincing explanation as to why imported macros
> > from some library are so much more evil than imported functions. In
> > both cases one might have to dig into documentation and/or comments
> > to understand exactly what that imported snippit is doing.
>
> And the difference with a library function is?
>
> (defpackage "LIBRARY" (:export "THIS-IS-A-FUNCTION"))
>
> (library:this-is-a-function ???) ; ???
Well, my argument is that there is little difference. Functions,
objects and macros all redefine some aspect of the system's
language, and all of them can be vulnerable to obfuscation or
unnecessary abstraction. The question I have is why do critics
single out macros and not other forms of abstraction such as
objects, packages, libraries, and functions?
just as an example:
from foolib import *
bar.bar("somefile")
What does this program do? I have no idea. Its functionality is
hidden behind multiple layers of abstraction (function, object,
library.)
Kirk Sluder wrote:
> unnecessary abstraction. The question I have is why do critics
> single out macros and not other forms of abstraction such as
> objects, packages, libraries, and functions?
The answer is: because they are pitiful morons.
But you knew that already.
On Sat, 09 Dec 2006 21:55:19 +0000, Kirk Sluder wrote:
> The question I have is why do critics
> single out macros and not other forms of abstraction such as
> objects, packages, libraries, and functions?
Who says they do? All forms of abstraction have been criticized. Sometimes
the criticism is valid. Sometimes it warns against abuses of the
abstraction. Just because a feature is useful sometimes doesn't
necessarily mean the benefit outweighs the cost.
> just as an example:
> from foolib import *
> bar.bar("somefile")
>
> What does this program do? I have no idea. Its functionality is
> hidden behind multiple layers of abstraction (function, object,
> library.)
Sure.
But at least you know that foolib is a module or package. You know what
from and import do, and that can't change. And you know that bar is an
object with a method also called bar, it is being called, and the
argument is a string "somefile". Those things can't change. Imagine a
hypothetical language where those two lines could mean *anything*.
Rightly or wrongly, people fear that Lisp's macros push Lisp closer to
that hypothetical anything-goes language than is healthy. Maybe that's a
problem of perception rather than a problem of fact, but you have to ask,
why do people perceive Lisp that way?
Could it be because of people like J Shrager who writes things like this?
"Can't you just expand the language via macros to create whatever facility
of this sort [major new features with new syntax] you need..."
(This thread, dated 8 Dec 2006 16:14:44 -0800)
Or Wolfram Fenske:
"All the interesting features that haven't originated from Lisp (e. g. OO
from Smalltalk) could in turn easily be implemented in Lisp with a couple
of macros."
(This thread, dated 8 Dec 2006 23:38:02 -0800)
To someone outside of Lisp, that looks like "I can make Lisp look like any
language I like in just a few lines." And that implies that to read a Lisp
program, one might need to be able to read code that looks like Lisp, or
Smalltalk, or Prolog, or Fortran, or all of those, or whatever bizarre
syntax the developer wanted it to look like.
My point isn't whether or not their claims are correct (a "couple" of
macros? really?) but that things like this feed the perception that Lisp
is close to that hypothetical language where anything could be anything.
If anything could be anything, do you really know what (+ 1 2) means
without reading every line of code?
And it isn't really that much comfort to be told that good Lisp
developers know not to do stupid things with macros. Sure. But in the real
world of programming, most developers aren't good developers, they are
merely average -- in fact fifty percent of them are below average. And
the bottom 30% can't be trusted with facilities like Lisp's macros,
because they WILL do stupid things with them and turn your code base into
a morass of shifting syntax, buggy DSLs and other maintenance nightmares.
The damage they can do with operator overloading is minor by comparison.
Even something simple like file I/O can be abused. Example: I've seen
*real* code where somebody needed a dict with ten million keys. (Well, he
thought he needed that dict, I never worked out exactly why. Maybe he
thought he was pre-allocating memory as an optimization.) So he started
off with something like this:
def make_dict():
mydict = {}
mydict[0] = 0
mydict[1] = 0
mydict[2] = 0
and realised that it would take him forever to write that much code. So
he wrote a C program to create the make_dict function for him! Translated
into Python:
def make_dict_factory():
code = open('makedict.py', 'w')
code.write("def make_dict():\n")
code.write(" mydict = {}\n")
for i in range(10000000):
code.write(" mydict[%d] = 0\n" % i)
code.write(" return mydict\n")
code.close()
from makedict import make_dict
return make_dict
(This is an interesting demonstration that any language that allows file
I/O and importing of external program files can always treat functions
as data, even if the language doesn't directly support it. An alternative
would be to keep the strings in memory instead of writing to a module,
then use exec on them instead of importing the module.)
Honest to god, the code really was like that! Maybe I've got the precise
details wrong, it was a long time ago, but if it wasn't just as I've got
it, the consequences were the same: he built a single function that was so
large that loading it caused his machine to thrash for twenty minutes
trying to free enough memory.
Is that an argument against factory functions? Damn straight it is:
they are a powerful tool, and in the hands of morons, they can be
dangerous. Does that mean that languages shouldn't permit higher-order
functions? Not necessarily: all programming tools can be misused, but some
can be misused more easily than others. Power and risk is often a
trade-off, and language designers can't eliminate all risk of stupid
behaviour, but they can design the language to allow whatever level of
risk they believe is acceptable. (E.g. there is no doubt that C's raw
pointers are powerful, but many languages deliberately don't use them.)
The risk of stupid factory functions is small compared to the benefit, but
maybe there is some domain somewhere where the ideal solution is a
language that DOESN'T treat functions as first class objects, deliberately
weakening the language so that a particular class of errors (or stupid
behaviour) just cannot happen. But that language isn't Python.
When it comes to Lisp's macros, the perception is that the power is
correspondingly greater, and the risk of abuse even more so. The safe
examples of what macros can be used for don't seem to provide any
over-whelming advantage (that's not to say they provide NO advantage,
merely that if you use macros safely, the advantage seems small, but if
you use them to their full potential, the risk of abuse is too high).
That's the perspective of many people, and maybe it is wrong. Maybe you
really need to be immersed in Lisp for a while to see the advantages of
macros.
Or maybe it is only an advantage while Lisp programmers are a
self-selected group of above-average skill. Wait until fifty million VB
code monkeys start writing Lisp macros and maybe, just maybe, you'll wish
they were using a less powerful and more restrictive language.
--
Steven.
Steven D'Aprano wrote:
> Rightly or wrongly, people fear...
So when people fear wrongly we burn whatever witches we must to reassure
them?
> that Lisp's macros push Lisp closer to
> that hypothetical anything-goes language than is healthy. Maybe that's a
> problem of perception rather than a problem of fact, but you have to ask,
> why do people perceive Lisp that way?
>
> Could it be because of people like J Shrager who writes things like this?
>
> "Can't you just expand the language via macros to create whatever facility
> of this sort [major new features with new syntax] you need..."
The context was CLOS. Something that big needs new syntax. But what you
do not know is that the syntax is Lispy, so learning it is tantamount to
understanding new function names, as even Pythonistas must do (tho a few
of you seem to think Pythonistas are incapable of learning <g>).
>
> (This thread, dated 8 Dec 2006 16:14:44 -0800)
>
> Or Wolfram Fenske:
>
> "All the interesting features that haven't originated from Lisp (e. g. OO
> from Smalltalk) could in turn easily be implemented in Lisp with a couple
> of macros."
Right, something big like an OO.
>
> (This thread, dated 8 Dec 2006 23:38:02 -0800)
>
> To someone outside of Lisp, that looks like "I can make Lisp look like any
> language I like in just a few lines."
On the contrary, on the rare case when it happens (CLOS, my Cells
package) one is obliged by exactly the hobgoblins you fear to remain
true to lisp patterns when extending Lisp. And there are patterns in
macro usage as well:
(my-macro <optional arguments to macro expansion>
<my-macro-forms>+)
Your hands must be getting sore from banging that drum so hard and so
long -- has it ever occurred to you that good programmers concerned with
power do not obfuscate code? And now you have read a dozen messages from
serious Lispniks trying to tell you that that is not the case, and you
persist.
We love the chance to preach to the unsaved, so we are indebted to you
for the many chances to clarify, but something tells me I should check
the c.l.p archives to make sure I am not chatting away happily with the
village idiot. :)
> And that implies that to read a Lisp
> program, one might need to be able to read code that looks like Lisp, or
> Smalltalk, or Prolog, or Fortran, or all of those, or whatever bizarre
> syntax the developer wanted it to look like.
"I don't want to think, I just want to bang on de drum all day.
I don't want to learn, just want to bang on de drum all day."
>
> My point isn't whether or not their claims are correct (a "couple" of
> macros? really?) but that things like this feed the perception...
Ah, well at least you are copping to witch-burning. Thx.
> And it isn't really that much comfort to be told that good Lisp
> developers know not to do stupid things with macros.
Hmm, didn't we see that as a comforter for some powerful Python
mechanism earlier in this thread?
> Sure. But in the real
> world of programming, most developers aren't good developers, they are
> merely average
Two questions: do you really voluntarily use libraries from crappy
developers? Second, you think a language can stop people from writing
bad code? Java tried, and look where that got the language. Elsewhere a
Pythonista (Mr. Rubin?) bemoaned this thread's appearance of Pythonistas
shrinking from power... could you two get together? :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> Rightly or wrongly, people fear that Lisp's macros push Lisp closer to
> that hypothetical anything-goes language than is healthy. Maybe that's a
Wrongly. And do they? To paraphrase Brian Griffin: "Are you sure it
was people? Are you sure it wasn't...nothing?"
> My point isn't whether or not their claims are correct (a "couple" of
> macros? really?) but that things like this feed the perception that Lisp
> is close to that hypothetical language where anything could be anything.
> If anything could be anything, do you really know what (+ 1 2) means
> without reading every line of code?
Jesus H Christ. Didn't you just get through talking about how easily
someone can redefine built-ins in Python?
> Even something simple like file I/O can be abused. Example: I've seen
Agreed. This is why I've always argued that I/O should never have
been included in programming languages. Too dangerous. And, let's
face it, pretty old-fashioned these days.
> (This is an interesting demonstration that any language that allows file
> I/O and importing of external program files can always treat functions
> as data, even if the language doesn't directly support it. An alternative
> would be to keep the strings in memory instead of writing to a module,
> then use exec on them instead of importing the module.)
No, it treats code as text. See the difference?
> Honest to god, the code really was like that!
Holy cow! How incredible!
> Is that an argument against factory functions? Damn straight it is:
> they are a powerful tool, and in the hands of morons, they can be
> dangerous. Does that mean that languages shouldn't permit higher-order
> functions? Not necessarily: all programming tools can be misused, but some
> can be misused more easily than others. Power and risk is often a
> trade-off, and language designers can't eliminate all risk of stupid
> behaviour, but they can design the language to allow whatever level of
> risk they believe is acceptable. (E.g. there is no doubt that C's raw
> pointers are powerful, but many languages deliberately don't use them.)
Could you please calm down?
> The risk of stupid factory functions is small compared to the benefit, but
> maybe there is some domain somewhere where the ideal solution is a
> language that DOESN'T treat functions as first class objects, deliberately
> weakening the language so that a particular class of errors (or stupid
> behaviour) just cannot happen. But that language isn't Python.
Could you calm down?
> When it comes to Lisp's macros, the perception is that the power is
NB: here, "the" means "Steven D'Aprano's" (the number of meanings
"the" can assume in different contexts is quite surprising).
> correspondingly greater, and the risk of abuse even more so. The safe
Don't you get tired of making the same arguments? Because I'm getting
tired of making the same counterpoints.
On Sun, 10 Dec 2006 02:12:29 -0500, Bill Atkins wrote:
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>
>> Rightly or wrongly, people fear that Lisp's macros push Lisp closer to
>> that hypothetical anything-goes language than is healthy. Maybe that's a
>
> Wrongly.
That's your opinion, and as an experienced Lisp coder, it is an opinion
worth treating seriously. Nevertheless, a mere denial doesn't constitute
evidence, let alone proof.
> And do they? To paraphrase Brian Griffin: "Are you sure it
> was people? Are you sure it wasn't...nothing?"
You know, I'm really starting to think that you Lispers -- and I hate to
generalise, but in this case I feel I'm forced to -- have a real problem
here. On the one hand, I keep reading how unfair it is that the rest of
the programming world won't give Lisp a fair go, that all these other
programmers are spreading FUD over Lisp, especially over the macros and
parentheses. And then you come along and imply that nobody is concerned
about Lisp macros.
So which is it? If Lisp is so self-evidently better than every other
language, and if nobody has any fears or concerns with Lisp, why is Lisp a
fringe language? Not as fringe as it was ten years ago, and maybe growing
in popularity, and it is beyond all doubt that Lisp has a lot of influence
amongst language designers, but outside of a few niche areas, its still a
fringe language.
>> My point isn't whether or not their claims are correct (a "couple" of
>> macros? really?) but that things like this feed the perception that Lisp
>> is close to that hypothetical language where anything could be anything.
>> If anything could be anything, do you really know what (+ 1 2) means
>> without reading every line of code?
>
> Jesus H Christ. Didn't you just get through talking about how easily
> someone can redefine built-ins in Python?
Yes. But you can't redefine 1+2 in Python, at least not without hacking
the interpreter. Can you redefine (+ 1 2) in Lisp?
>> Even something simple like file I/O can be abused. Example: I've seen
>
> Agreed. This is why I've always argued that I/O should never have
> been included in programming languages. Too dangerous. And, let's
> face it, pretty old-fashioned these days.
Ha ha, I love good sarcasm!
Unfortunately, that isn't good sarcasm.
>> (This is an interesting demonstration that any language that allows file
>> I/O and importing of external program files can always treat functions
>> as data, even if the language doesn't directly support it. An alternative
>> would be to keep the strings in memory instead of writing to a module,
>> then use exec on them instead of importing the module.)
>
> No, it treats code as text. See the difference?
Text is data.
What is the point of your comment? You don't have to argue about every
thing I say, even the ones we agree on. Look again at what I wrote. Is
there anything that gave you the impression that I think that having the
ability to write text to a file and import it is better than actually
supporting functional programming directly?
[snip]
>> Is that an argument against factory functions? Damn straight it is:
>> they are a powerful tool, and in the hands of morons, they can be
>> dangerous. Does that mean that languages shouldn't permit higher-order
>> functions? Not necessarily: all programming tools can be misused, but some
>> can be misused more easily than others. Power and risk is often a
>> trade-off, and language designers can't eliminate all risk of stupid
>> behaviour, but they can design the language to allow whatever level of
>> risk they believe is acceptable. (E.g. there is no doubt that C's raw
>> pointers are powerful, but many languages deliberately don't use them.)
>
> Could you please calm down?
Huh?
>> The risk of stupid factory functions is small compared to the benefit, but
>> maybe there is some domain somewhere where the ideal solution is a
>> language that DOESN'T treat functions as first class objects, deliberately
>> weakening the language so that a particular class of errors (or stupid
>> behaviour) just cannot happen. But that language isn't Python.
>
> Could you calm down?
Okay, once was funny. Twice is worrying. What exactly is giving you the
idea I need to calm down? Was it the use of reasoning and logic?
Perhaps it was the attempt to be reasonable and moderate and find some
middle ground that we could agree on, or if not agree, at least say "Well,
I disagree with you, but at least I understand where you are coming from"?
>> When it comes to Lisp's macros, the perception is that the power is
>
> NB: here, "the" means "Steven D'Aprano's" (the number of meanings
> "the" can assume in different contexts is quite surprising).
>
>> correspondingly greater, and the risk of abuse even more so. The safe
>
> Don't you get tired of making the same arguments? Because I'm getting
> tired of making the same counterpoints.
Steven D'Aprano wrote:
> On Sun, 10 Dec 2006 02:12:29 -0500, Bill Atkins wrote:
>
>
>>Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>>
>>
>>>Rightly or wrongly, people fear that Lisp's macros push Lisp closer to
>>>that hypothetical anything-goes language than is healthy. Maybe that's a
>>
>>Wrongly.
>
>
> That's your opinion, and as an experienced Lisp coder, it is an opinion
> worth treating seriously. Nevertheless, a mere denial doesn't constitute
> evidence, let alone proof.
Well, it does unless you think we are lying, or creating obfuscated code
and do not know it. This would be consistent with the theory that we
positively love parentheses only because we are mutants. To be honest, I
think it would be way cool if it turned out I was this mutant life form,
the only kind that can understand Lisp. And this would be consistent
with my theory that John McCarthy must be an alien. How else can he
wander over to his desk one day, misread Church, and create a language
that, as you say, is growing in popularity and whose essence can be
found in every popular language except C++, which only makes my point.
Have you read On Lisp by Paul Graham? It is on-line. Just the preface
will do, I think, maybe also Chapter One where he raves on macros. Do
you think he is mistaken? Confused? Lying? Mutant?
This exchange has not been a complete disaster, but it sure could have
covered a lot more ground if you had not had your hands over your ears.
Now I see you want Lispniks to explain its unpopularity. I like that, we
have to figure out what is wrong with you. :) Apparently that would be
fear of the unknown, xenophobia, and prejudice. Meanwhile, given that
Python and Ruby have copied so much from Lisp, and that languages seem
to be converging on Lisp, now we have to have an equally daft exchange
over the possibility that Lisp is the most popular language going. Even
Java has Groovy.
Lisp has all the cool qualities you like in your pets, plus native
compilation in most implementations, plus maturity and a standard, plus
a better OO, plus macros, plus a dozen more small wins. Including
automatic indentation. :)
It is just a matter of critical mass. At some very low threshold Lisp
becomes "OK". I get the feeling that has already begun, but it is not
quite there yet. Certainly it gets mentioned now when language names get
bandied about, if only to be dismissed. That is a step up for us. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> Have you read On Lisp by Paul Graham? It is on-line. Just the preface
> will do, I think, maybe also Chapter One where he raves on macros. Do
> you think he is mistaken? Confused? Lying? Mutant?
I remember Paul Graham's piece about macros that made him sound like
someone who went nuts with them, as is certainly possible to do. In
my experience, good coders write for clarity and that includes in
their use of Lisp macros. All in all Lisp's macro system is something
like the C preprocessor. Yes, you can obfuscate things horribly with
it, but you can also use it to make things clearer, and that's what
good programmers do.
Paul Rubin wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>Have you read On Lisp by Paul Graham? It is on-line. Just the preface
>>will do, I think, maybe also Chapter One where he raves on macros. Do
>>you think he is mistaken? Confused? Lying? Mutant?
>
>
> I remember Paul Graham's piece about macros that made him sound like
> someone who went nuts with them, as is certainly possible to do.
But you could have just flipped thru the rest of the pages to see if he
/had/ gone nuts with them!
> In
> my experience, good coders write for clarity and that includes in
> their use of Lisp macros. All in all Lisp's macro system is something
> like the C preprocessor. Yes, you can obfuscate things horribly with
> it, but you can also use it to make things clearer, and that's what
> good programmers do.
One has to be from the US and of a certain age to remember this, but
this old line from a commercial for high-octane gasoline says it for me:
power to be used, not abused.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
>
> Paul Rubin wrote:
>
>> Ken Tilton <·········@gmail.com> writes:
>>
>>> Have you read On Lisp by Paul Graham? It is on-line. Just the preface
>>> will do, I think, maybe also Chapter One where he raves on macros. Do
>>> you think he is mistaken? Confused? Lying? Mutant?
>>
>>
>>
>> I remember Paul Graham's piece about macros that made him sound like
>> someone who went nuts with them, as is certainly possible to do.
>
>
> But you could have just flipped thru the rest of the pages to see if he
> /had/ gone nuts with them!
>
>> In
>> my experience, good coders write for clarity and that includes in
>> their use of Lisp macros. All in all Lisp's macro system is something
>> like the C preprocessor. Yes, you can obfuscate things horribly with
>> it, but you can also use it to make things clearer, and that's what
>> good programmers do.
>
>
> One has to be from the US and of a certain age to remember this, but
> this old line from a commercial for high-octane gasoline says it for me:
> power to be used, not abused.
Here is a bit of concrete I just tossed off:
(defmacro defskill (id &body skill-info)
`(progn
,@(loop with sub-id = id
for (q . q-def) in skill-info
collecting
(ecase q
((title annotations hints)
`(defmethod ,(intern (conc$ 'skill- q)) ((tf-id (eql
',sub-id)))
,@q-def))))))
It lets me code this:
(defskill absolute-value
(title "Absolute Value")
(annotations
"Take the absolute value of #op#."
"The vertical bars around #op# mean 'the absolute value of' #op#."
"Absolute value of #strn# is the 'distance' of #strn# from zero."
"Absolute value is always zero or positive: #str|n|=n#, and
#str|-n|=n#.")
(hints
"What do those vertical bars around #op# mean?"
"Have you learned about 'absolute value'?"
"Absolute value can be thought of as the 'distance' of a value from
zero on the number line, and distance is always positive."
"The rule is:#str|-n|=|n|##str=n#. Can you apply that to #op#?"
"Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#."
"To get the absolute value of a number such as #op#, we simply drop
any minus sign."))
...and get this:
(PROGN
(DEFMETHOD SKILL-TITLE ((TF-ID (EQL 'ABSOLUTE-VALUE)))
"Absolute Value")
(DEFMETHOD SKILL-ANNOTATIONS ((TF-ID (EQL 'ABSOLUTE-VALUE)))
"Take the absolute value of #op#." "The vertical bars around #op#
mean 'the absolute value of' #op#."
"Absolute value of #strn# is the 'distance' of #strn# from zero."
"Absolute value is always zero or positive: #strn=n#, and #str-n=n#.")
(DEFMETHOD SKILL-HINTS ((TF-ID (EQL 'ABSOLUTE-VALUE)))
"What do those vertical bars around #op# mean?" "Have you learned
about 'absolute value'?"
"Absolute value can be thought of as the 'distance' of a value
from zero on the number line, and distance is always positive."
"The rule is:#str-n=n##str=n#. Can you apply that to #op#?" "Some
examples: #str+42=42#, #str-42=42#, and #str0=0#."
"To get the absolute value of a number such as #op#, we simply
drop any minus sign."))
The above is how my upcoming death-defying interactive Algebra
tutor-in-a-drum ("You'll laugh! You'll cry!") will know how to coax some
befuddled teen through |-42| -> 42 if they get stuck. And a hundred
other subskills (so there will be a hundred of these definitions).
If I hire someone they will look at defskill and not fall to the ground
frothing at the mouth. They likely will not even macroexpand it because
it is self-explanatory. If they wonder if there are other options they
can alt-. to the source. The language has been extended, but I followed
a pattern familiar to Lispniks. Zero confusion results.
If I decide not to use generic method dispatch to "look up" the hints I
just have to change the macro and then write a DEFUN (no dispatch on
type) to, say, look up the symbol in a hash table.
hth,ken
ps. I won't mention the other benefit, which is that I want educators to
edit these if they have a better idea on how to tutor absolute value. I
am not mentioning it because I am as impatient with superfluous syntax
as a non-programmer would be. k
pps. How would Python do this? Is it possible to avoid committing to an
implementation mechanism? Compare and contrast. k
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> pps. How would Python do this? Is it possible to avoid committing to
> an implementation mechanism? Compare and contrast. k
You'd just write a function. Python's expression syntax is comparable
to a Lisp reader (you can have nested values of mixed types etc.) so
you can use Python expressions to initialize pretty much anything.
Paul Rubin <·············@NOSPAM.invalid> writes:
> Ken Tilton <·········@gmail.com> writes:
> > pps. How would Python do this? Is it possible to avoid committing to
> > an implementation mechanism? Compare and contrast. k
>
> You'd just write a function. Python's expression syntax is comparable
> to a Lisp reader (you can have nested values of mixed types etc.) so
> you can use Python expressions to initialize pretty much anything.
Nah, that won't work. He's defining a set of methods _declaratively_
via a high level description.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Ken Tilton wrote:
> pps. How would Python do this?
Here's one way it could look:
defskill("absolute-value",
title = "Absolute Value",
annotations = [
"Take the absolute value of #op#.",
"The vertical bars around #op# mean 'the absolute value of' #op#.",
"Absolute value of #strn# is the 'distance' of #strn# from zero.",
"Absolute value is always zero or positive: #str|n|=n#, and #str|-n|=n#."
],
hints = [
"What do those vertical bars around #op# mean?",
"Have you learned about 'absolute value'?",
"""Absolute value can be thought of as the 'distance' of a value from
zero on the number line, and distance is always positive.""",
"The rule is:#str|-n|=|n|##str=n#. Can you apply that to #op#?",
"Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#.",
"""To get the absolute value of a number such as #op#, we simply drop
any minus sign."""
]
)
> Is it possible to avoid committing to an
> implementation mechanism?
The defskill function could do just about anything with this.
Here's one possibility:
skills = {}
class Skill:
pass # fill in whatever methods you need here
def defskill(name, title, annotations, hints):
skill = Skill()
skill.title = title
skill.annotations = annotations
skill.hints = hints
skills[name] = skill
This gives you a dictionary of Skill instances indexed by name,
each one having a title and lists of annotation and hint strings.
The rest of the system can process this however required.
--
Greg
greg wrote:
> Ken Tilton wrote:
>
>> pps. How would Python do this?
>
>
> Here's one way it could look:
>
> defskill("absolute-value",
> title = "Absolute Value",
> annotations = [
> "Take the absolute value of #op#.",
> "The vertical bars around #op# mean 'the absolute value of' #op#.",
> "Absolute value of #strn# is the 'distance' of #strn# from zero.",
> "Absolute value is always zero or positive: #str|n|=n#, and
> #str|-n|=n#."
> ],
> hints = [
> "What do those vertical bars around #op# mean?",
> "Have you learned about 'absolute value'?",
> """Absolute value can be thought of as the 'distance' of a value from
> zero on the number line, and distance is always positive.""",
> "The rule is:#str|-n|=|n|##str=n#. Can you apply that to #op#?",
> "Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#.",
> """To get the absolute value of a number such as #op#, we simply drop
> any minus sign."""
> ]
> )
>
> > Is it possible to avoid committing to an
> > implementation mechanism?
>
> The defskill function could do just about anything with this.
> Here's one possibility:
>
> skills = {}
>
> class Skill:
> pass # fill in whatever methods you need here
>
> def defskill(name, title, annotations, hints):
> skill = Skill()
> skill.title = title
> skill.annotations = annotations
> skill.hints = hints
> skills[name] = skill
>
> This gives you a dictionary of Skill instances indexed by name,
> each one having a title and lists of annotation and hint strings.
> The rest of the system can process this however required.
Ok, not too bad, not much syntax in there. But now I have a tougher
requirement for you, which I noticed only after posting. (I tried
running the damn thing and it whined about not knowing how to "reverse"
absolute-value (to clone one problem into a similar problem).) A
reversal must be able to yield any given a result, and sometimes must
use given operands already settled on by the larger reversing algorithm.
In the simpler case, to reverse absolute-value with result 42 we produce
either |42| or |-42|. In the more complicated case, the multiply-literal
reverser may discover 6 is an operand and 42 is the result (meaning it
does no randomization, it just supplies the (* 6 7) reversal. Why am I
telling you all this? I don't know. The point is, we need code (not just
data) in defskill (apologies for nasty formatting):
(defmacro defskill (id &body skill-info)
`(progn
,@(loop with sub-id = id
for (q . q-def) in skill-info
collecting (ecase q
((title annotations hints)
`(defmethod ,(intern (conc$ 'skill- q))
((tf-id (eql ',sub-id)))
(list ,@q-def)))
(reverse
`(defmethod tf-reverse ((id (eql ',sub-id))
resx opnds)
(declare (ignorable resx opnds))
,@q-def))))))
--------------- (Abbreviated) Example.... ------------------------------
(defskill absolute-value
(title "Absolute Value")
(annotations
"Absolute value is always zero or positive: #str|n|=n#, and
#str|-n|=n#.")
(hints
"What do those vertical bars around #op# mean?")
(reverse
(ensure-cloning resx
(make-instance 'mx-number
:value (loop with op1 = (car opnds)
with log = (max 1 (ceiling (log (abs (value op1)) 10)))
for n = (* (signum (value op1))
(+ 2 (random (expt 10 log))))
when (/= n (value op1))
return n)
:representation (representation resx)))))
-------------- Producing.... ---------------------------------
(progn (defmethod skill-title ((tf-id (eql 'absolute-value))) (list
"absolute value"))
(defmethod skill-annotations ((tf-id (eql 'absolute-value)))
(list "absolute value is always zero or positive: #strn=n#,
and #str-n=n#."))
(defmethod skill-hints ((tf-id (eql 'absolute-value)))
(list "what do those vertical bars around #op# mean?"))
(defmethod tf-reverse ((id (eql 'absolute-value)) resx opnds)
(declare (ignorable resx opnds))
(ensure-cloning resx
(make-instance 'mx-number :value
(loop with op1 = (car opnds) with log = (max 1 (ceiling
(log (abs (value op1)) 10))) for n =
(* (signum (value op1)) (+ 2 (random (expt 10
log)))) when (/= n (value op1)) return n)
:representation (representation resx)))))
How close can Python get when code is involved? The reverse function
signature is fixed, so can lambda help?
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> don't know. The point is, we need code (not just data) in defskill
> (apologies for nasty formatting):
Man that whole thing is messy. I can't for the life of me understand
why it's so important to use a macro for that. Even in Lisp, I'd
probably set up the reverse thingie as an auxiliary function.
Paul Rubin wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>don't know. The point is, we need code (not just data) in defskill
>>(apologies for nasty formatting):
>
>
> Man that whole thing is messy. I can't for the life of me understand
> why it's so important to use a macro for that. Even in Lisp, I'd
> probably set up the reverse thingie as an auxiliary function.
And when you got to skill 42 and you discovered you needed a new
optional argument to the reversal method you would throw up your hands
and register for bartending school rather than go edit the other 41.
defskill is writing my code for me. When things change, I have it write
different code. Implementation is hidden, even from the programmer. I am
one step removed from the code when writing a macro. This is the "meta"
in metaprogramming.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> > Man that whole thing is messy. I can't for the life of me understand
> > why it's so important to use a macro for that. Even in Lisp, I'd
> > probably set up the reverse thingie as an auxiliary function.
>
> And when you got to skill 42 and you discovered you needed a new
> optional argument to the reversal method you would throw up your hands
> and register for bartending school rather than go edit the other 41.
I don't see the problem. Python uses keyword args sort of like
Lisp's, and the called function (if it asks) receives a dictionary
containing any keyword args not bound explicitly in the arg list.
So you can invent new args whenever you want.
Paul Rubin wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>>Man that whole thing is messy. I can't for the life of me understand
>>>why it's so important to use a macro for that. Even in Lisp, I'd
>>>probably set up the reverse thingie as an auxiliary function.
>>
>>And when you got to skill 42 and you discovered you needed a new
>>optional argument to the reversal method you would throw up your hands
>>and register for bartending school rather than go edit the other 41.
>
>
> I don't see the problem. Python uses keyword args sort of like
> Lisp's, and the called function (if it asks) receives a dictionary
> containing any keyword args not bound explicitly in the arg list.
> So you can invent new args whenever you want.
I am not making this up. I just decided to change the signature to the
reversal function(s). I had been clever, trying to pass in just what I
deemed necessary from a transformation (TF) data structure that needed
reversing, now I recall -- because I needed something else from the TF
-- I should never try to be smart, just pass in the whole frickin TF (duh).
So this:
(defmethod tf-reverse (id (eql ',sub-id)) resx (drv-opnds tf drv))
,@reverser)
becomes this:
(defmethod tf-reverse ((id (eql ',sub-id)) tf drv
&aux (opnds (drv-opnds tf drv)))
(loop for resx in (results drv)
,@reverser))
I pass in drv (a derivation, a part of a transformation) because (I
forgot) reversal code has to reverse each derivation of a TF separately.
In the new macroexpansion I preserve the bindings RESX and OPNDS
expected by the 41 (not really, but it could be) existing uses of the
defskill macro, and then <gasp> move an iteration across possible
multiple results (RESXs) of a TF into the generate tf-reverse method
(and the poor body of code has no idea I did that).
At this point if I had to redo these manually we can forget bartending
school, I'd be going straight to the Betty Ford clinic .
btw, you called the defskill messy (repeated below) "messy". The only
text not specific to absolute value is D-E-F-S-K-I-L-L. Expanding that
into "tidy" separate methods adds 25% of dead weight boilerplate. In 4-5
separate toplevel definitions instead of one. How is that less messy?
ken
(defskill absolute-value
(title "Absolute Value")
(annotations
"Take the absolute value of #signed-value#."
"The vertical bars around #signed-value# mean 'the absolute value
of' #signed-value#."
"Absolute value of #strn# is the 'distance' of #strn# from zero."
"Absolute value is always zero or positive: #str|n|=n#, and
#str|-n|=n#.")
(hints
"What do those vertical bars around #signed-value# mean?"
"Have you learned about 'absolute value'?"
"Absolute value can be thought of as the 'distance' of a value from
zero on the number line, and distance is always positive."
"The rule is:#str|-n|=|n|##str=n#. Can you apply that to
#signed-value#?"
"Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#."
"To get the absolute value of a number such as #signed-value#, we
simply drop any minus sign.")
(reverse
(ensure-cloning resx
(make-instance 'mx-number
:value (loop with op1 = (car opnds)
with log = (max 1 (ceiling (log (abs (value op1)) 10)))
for n = (* (signum (value op1))
(+ 2 (random (expt 10 log))))
when (/= n (value op1))
return n)
:representation (representation resx)))))
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> btw, you called the defskill messy (repeated below) "messy". The only
> text not specific to absolute value is D-E-F-S-K-I-L-L.
No, the messiness was not in the macro instantation (defskill blah...),
but in the defmacro that tells the compiler how to expand it. Python
function defs are lightweight enough that I don't experience a big pain
from using an extra one for a thing like that.
Paul Rubin wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>btw, you called the defskill messy (repeated below) "messy". The only
>>text not specific to absolute value is D-E-F-S-K-I-L-L.
>
>
> No, the messiness was not in the macro instantation (defskill blah...),
> but in the defmacro that tells the compiler how to expand it.
Again, that is precisely the point of macrology (in cases like this).
When a pattern will repeat a sufficient number of times, and a function
cannot handle the job, we do a little extra work (write some meta-code)
to make dozens (or hundreds) of applications as minimalist as possible.
That makes them concise, readable, and maintainable.
> Python
> function defs are lightweight enough that I don't experience a big pain
> from using an extra one for a thing like that.
Check out the latest, plz. The example has grown now beyond what a
function can do, I think. meanwhile, I have not seen how Python lets you
avoid revisiting dozens of instances when changes to a mechanism are
required.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> Again, that is precisely the point of macrology (in cases like
> this). When a pattern will repeat a sufficient number of times, and a
> function cannot handle the job,
But this is not a case where a function can't handle the job.
> Check out the latest, plz. The example has grown now beyond what a
> function can do, I think. meanwhile, I have not seen how Python lets
> you avoid revisiting dozens of instances when changes to a mechanism
> are required.
I'm missing what the difficulty is.
Paul Rubin wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>Again, that is precisely the point of macrology (in cases like
>>this). When a pattern will repeat a sufficient number of times, and a
>>function cannot handle the job,
>
>
> But this is not a case where a function can't handle the job.
Is, too.
>
>
>>Check out the latest, plz. The example has grown now beyond what a
>>function can do, I think. meanwhile, I have not seen how Python lets
>>you avoid revisiting dozens of instances when changes to a mechanism
>>are required.
>
>
> I'm missing what the difficulty is.
Your terse response does not provide enough for me to.
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
>
> meanwhile, I have not seen how Python lets you avoid revisiting dozens
> of instances when changes to a mechanism are required.
I think his solution would have been to use:
def foo(**args):
everywhere, and call it like this
foo(bar=baz)
Of course that makes calls pretty verbose, but it would prevent having
to visit every function/method every time the signature changes. As
long they'd all been set up initially to use keyword args like that.
And of course one would lose some of the compile-time benefits of
compiler signature checking.
It's not optimal, but I think it'd get the job done.
--
Robert Uhl <http://public.xdi.org/=ruhl>
So how *do* you determine the gender of bread? Ah, no doubt L'Academie
has vast teams of staff who wander through France assigning gender to
inanimate objects, in such a way as to cause maximum confusion among
students of French... --Tanuki the Raccoon-dog
Robert Uhl wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>meanwhile, I have not seen how Python lets you avoid revisiting dozens
>>of instances when changes to a mechanism are required.
>
>
> I think his solution would have been to use:
>
> def foo(**args):
>
> everywhere, and call it like this
>
> foo(bar=baz)
>
> Of course that makes calls pretty verbose, but it would prevent having
> to visit every function/method every time the signature changes. As
> long they'd all been set up initially to use keyword args like that.
> And of course one would lose some of the compile-time benefits of
> compiler signature checking.
>
> It's not optimal, but I think it'd get the job done.
>
Cue Steve and his Turing Equivalence rant. <hint>
And as the mechanism has elaborated, neato things like signature
flexibility were not enough to keep Python in the game. Or at least
people stop offering Python equivalents, at which point we could have
contrasted and compared.
Python /does/ have a lot of reflection and meta-capability, as I know
from an abortive attempt to port Cells there. So perhaps something was
possible.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Robert Uhl a �crit :
> Ken Tilton <·········@gmail.com> writes:
>> meanwhile, I have not seen how Python lets you avoid revisiting dozens
>> of instances when changes to a mechanism are required.
>
> I think his solution would have been to use:
>
> def foo(**args):
>
> everywhere, and call it like this
>
> foo(bar=baz)
>
> Of course that makes calls pretty verbose, but it would prevent having
> to visit every function/method every time the signature changes. As
> long they'd all been set up initially to use keyword args like that.
> And of course one would lose some of the compile-time benefits of
> compiler signature checking.
>
> It's not optimal, but I think it'd get the job done.
>
More along the lines of :
def foo(*args, **kwds):
pass_params(*args, **kwds)
def pass_params(hi, there):
print "hi :", hi
print "there :", there
foo("first", there="second")
Ken Tilton wrote:
> So this:
> (defmethod tf-reverse (id (eql ',sub-id)) resx (drv-opnds tf drv))
> ,@reverser)
>
> becomes this:
>
> (defmethod tf-reverse ((id (eql ',sub-id)) tf drv
> &aux (opnds (drv-opnds tf drv)))
> (loop for resx in (results drv)
> ,@reverser))
I don't see why you can't just write a function that
loops over the results and calls the user's reversal
function for each one.
def reverse_multiple(skill, resx_list, opnds):
for resx in rex_list:
skill.reverse(resx, opnds)
There's no need to macro-expand this code into every
reversal function, when it can be done once as part of
the framework that calls the reversal functions.
--
Greg
greg wrote:
> Ken Tilton wrote:
>
>> So this:
>> (defmethod tf-reverse (id (eql ',sub-id)) resx (drv-opnds tf drv))
>> ,@reverser)
>>
>> becomes this:
>>
>> (defmethod tf-reverse ((id (eql ',sub-id)) tf drv
>> &aux (opnds (drv-opnds tf drv)))
>> (loop for resx in (results drv)
>> ,@reverser))
>
>
> I don't see why you can't just write a function that
> loops over the results and calls the user's reversal
> function for each one.
That was the original coding, but notice that a derivation (DRV) is an
argument to tf-reverse. Can you say "encapsulation"? :) What if that
changes? It did. I used to have just one result per derivation, until a
multi-result case came along.
Since I will be having many dozens of these I might well try to keep as
much code as possible out of them (encapsulation de damned <g>) to
minimize the inevitable hit when I refactor, but I have macros so I do
not have to.
>
> def reverse_multiple(skill, resx_list, opnds):
> for resx in rex_list:
> skill.reverse(resx, opnds)
>
> There's no need to macro-expand this code into every
> reversal function, when it can be done once as part of
> the framework that calls the reversal functions.
Rather than go into "argue mode" before fully understanding the issues,
please note that I am just looking to learn (without judgment) what the
Python equivalent would be. Things I offer are not "you can't touch
this!", they are "what does the Python look like?". Afterwards we can
get into a pissing match. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
>
> Paul Rubin wrote:
>
>> Ken Tilton <·········@gmail.com> writes:
>>
>>> don't know. The point is, we need code (not just data) in defskill
>>> (apologies for nasty formatting):
>>
>>
>>
>> Man that whole thing is messy.
I do not see much difference, except that the character count is 25%
less in the macro version:
(defskill absolute-value
(title "Absolute Value")
(annotations
"Absolute value of #strn# is the 'distance' of #strn# from zero."
"Absolute value is always zero or positive: #str|n|=n#, and
#str|-n|=n#.")
(hints
"Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#."
"To get the absolute value of a number such as #signed-value#, we
simply drop any minus sign.")
(reverse
(ensure-cloning resx
(make-instance 'mx-number
:value (loop with op1 = (car opnds)
with log = (max 1 (ceiling (log (abs (value op1)) 10)))
for n = (* (signum (value op1))
(+ 2 (random (expt 10 log))))
when (/= n (value op1))
return n)
:representation (representation resx)))))
(defmethod skill-title ((tf-id (eql 'absolute-value)))
(list "absolute value"))
(defmethod skill-annotations ((tf-id (eql 'absolute-value)))
(list "absolute value of #strn# is the 'distance' of #strn# from zero."
"absolute value is always zero or positive: #strn=n#, and #str-n=n#."))
(defmethod skill-hints ((tf-id (eql 'absolute-value)))
(list "some examples: #str+42=42#, #str-42=42#, and #str0=0#."
"to get the absolute value of a number such as #signed-value#, we
simply drop any minus sign."))
(defmethod tf-reverse ((id (eql 'absolute-value)) resx opnds)
(declare (ignorable resx opnds))
(ensure-cloning resx
(make-instance 'mx-number :value
(loop with op1 = (car opnds) with log = (max 1 (ceiling (log (abs
(value op1)) 10))) for n =
(* (signum (value op1)) (+ 2 (random (expt 10 log)))) when
(/= n (value op1)) return n)
:representation (representation resx)))))
Let's lose the strings and count again, since they are a fixed cost. OK,
now the macro version is 30% shorter.
>> I can't for the life of me understand
>> why it's so important to use a macro for that.
Pythonistas, when arguing about macros, always seem to forget that one
of the primary design imperatives of Python is cleaner code. Indentation
is use to avoid single characters { and }. But when macros come up you
all suddenly become the Mavis Beacon of programmers.
And, again, perhaps the bigger thing going on here is that the 30% is
boilerplate code representing implementation, which can change.
I don't know, perhaps the best argument against macros is that no
Pythonista wants them. That is actually a damn good reason.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> >> Man that whole thing is messy.
>
> I do not see much difference, except that the character count is 25%
> less in the macro version:
The macro calls aren't so bad, but the macro definition is pretty
horrendous. There's no need to invent and program all that new syntax
when Python's existing syntax does the job perfectly well.
> I don't know, perhaps the best argument against macros is that no
> Pythonista wants them. That is actually a damn good reason.
I've wanted macros from time to time, but this isn't a situation that
calls for them. They're just less important in Python than in Lisp.
Python already has enough syntax to not constantly need new syntax
extensions.
Paul Rubin wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>>>Man that whole thing is messy.
>>
>>I do not see much difference, except that the character count is 25%
>>less in the macro version:
>
>
> The macro calls aren't so bad, but the macro definition is pretty
> horrendous.
(a) /Precisely/ :)
(b) Omigod, that macro is trivial (except I forgot how to reach out two
levels of backquote to get a parameter and had to kludge it!). You just
aren't used to thinking at a level where one is writing code to write code.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Thu, 14 Dec 2006 03:01:46 -0500, Ken Tilton wrote:
> You just
> aren't used to thinking at a level where one is writing code to write code.
Firstly, I'm looking into lisp because my current python project is too
full of boilerplate :-) and too slow. Coming from a C and assembler
background, I'm *used* to meta-programming, and do it all the time. I
even use python, Matlab and bash to write C, sometimes :-)
However, in this particular instance, I'm inclined to wonder why
meta-programming is the right answer, rather than just doing all of the
interpolation and what-not at run-time, based on a big table of your
algebra rules? It's for output to a human, isn't it? It's not as though
it needs to be particularly fast?
Maybe I'm just not digging the example sufficiently. That's likely: I've
yet to write my first lisp program...
Cheers,
--
Andrew
Andrew Reilly wrote:
> On Thu, 14 Dec 2006 03:01:46 -0500, Ken Tilton wrote:
>
>
>>You just
>>aren't used to thinking at a level where one is writing code to write code.
>
>
> Firstly, I'm looking into lisp because my current python project is too
> full of boilerplate :-) and too slow. Coming from a C and assembler
> background, I'm *used* to meta-programming, and do it all the time. I
> even use python, Matlab and bash to write C, sometimes :-)
>
> However, in this particular instance, I'm inclined to wonder why
> meta-programming is the right answer, rather than just doing all of the
> interpolation and what-not at run-time, based on a big table of your
> algebra rules?
I am afraid I do not see what alternative you are suggesting. I
especially do not see how interpolation is in play.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
>
> Andrew Reilly wrote:
>
>> On Thu, 14 Dec 2006 03:01:46 -0500, Ken Tilton wrote:
>>
>>
>>> You just aren't used to thinking at a level where one is writing code
>>> to write code.
>>
>>
>>
>> Firstly, I'm looking into lisp because my current python project is too
>> full of boilerplate :-) and too slow. Coming from a C and assembler
>> background, I'm *used* to meta-programming, and do it all the time. I
>> even use python, Matlab and bash to write C, sometimes :-)
>>
>> However, in this particular instance, I'm inclined to wonder why
>> meta-programming is the right answer, rather than just doing all of the
>> interpolation and what-not at run-time, based on a big table of your
>> algebra rules?
>
>
> I am afraid I do not see what alternative you are suggesting. I
> especially do not see how interpolation is in play.
[Guessing pending your clarification] "Interpolation" does happen at
runtime. This not about the actually quite rare use of macrology to move
certain calculations to compile time, this is about getting dozens of
transformation-specifc rules written to fit into a larger mechanism (by
having the right arguments and returning the right kinds of results,
with a minimum of boilerplate and a maximum of resiliency in the face of
refactoring.
The reason I post macro expansions along with examples of the macro
being applied is so that one can see what code would have to be written
if I did not have the defskill macro to "write" them for me. I sugest
one start there, by comparing before and after.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Thu, 14 Dec 2006 04:06:26 -0500, Ken Tilton wrote:
> Ken Tilton wrote:
>> Andrew Reilly wrote:
>>> However, in this particular instance, I'm inclined to wonder why
>>> meta-programming is the right answer, rather than just doing all of the
>>> interpolation and what-not at run-time, based on a big table of your
>>> algebra rules?
>>
>> I am afraid I do not see what alternative you are suggesting. I
>> especially do not see how interpolation is in play.
>
> [Guessing pending your clarification] "Interpolation" does happen at
> runtime. This not about the actually quite rare use of macrology to move
> certain calculations to compile time, this is about getting dozens of
> transformation-specifc rules written to fit into a larger mechanism (by
> having the right arguments and returning the right kinds of results,
> with a minimum of boilerplate and a maximum of resiliency in the face of
> refactoring.
>
> The reason I post macro expansions along with examples of the macro
> being applied is so that one can see what code would have to be written
> if I did not have the defskill macro to "write" them for me. I sugest
> one start there, by comparing before and after.
Please pardon my woeful grasp of lisp: that's probably why I'm off-beam
here. It seemed to me that the bulk of your macro-ified/templated version
was taking some text and a "reverse" operation and creating the methods of
an object, or generic functions or ?? Each skill seems to have a title, a
list of annotations, and a list of hints (and a reverse, which I don't
understand). That all looks like data. Couldn't you do that with a table
containing those fields, and key it off the defskill argument (or even the
title?) at startup? Then you don't have to worry about re-factoring the
code: there's only going to be one piece of code, driven by a table.
I only mentioned interpolation because it seemed likely that you might
want to be mutating these strings to be more specific to what your student
was actually doing. I didn't expect that "42" was necessarily the right
answer...
To back out a bit, here, and get back to the meat of the matter: if one is
using Python, then it's because one doesn't much care about performance,
and it's reasonable to do expansions, pattern matching and domain specific
language creation/use at run-time. After all, that's how the language
itself works, mostly.
When one finds that one *does* care about performance, that doesn't leave
much wriggle room, though...
--
Andrew
Andrew Reilly wrote:
>> Each skill seems to have a title, a
> list of annotations, and a list of hints (and a reverse, which I don't
> understand).
There's the problem.
> That all looks like data.
No, not reverse, the part you did not understand. I do not mean what the
code was doing, I meant that it was code.
> Couldn't you do that with a table
> containing those fields, and key it off the defskill argument (or even the
> title?) at startup?
Not the code. In reverse.
> Then you don't have to worry about re-factoring the
> code: there's only going to be one piece of code, driven by a table.
What if it turns into an SQL lookup during refactoring?
>
> I only mentioned interpolation because it seemed likely that you might
> want to be mutating these strings to be more specific to what your student
> was actually doing.
Interpolation does not mean what you think it means. :) That's OK, I
figgered it out. Yes, that is what the program does, it substitutes
terms from the student's problem to produce a hint or annotation. The
function is called "expand". Because the text is like a macro. :)
> I didn't expect that "42" was necessarily the right
> answer...
No, but it so happens any #STR...# token is a literal bit of math
encoded as an ascii string. That gets translated to proper math notation
(by which I mean, what you would see in tex output). During template
conversion. So this hint is just saying to the kid, "Dude, |-42|=42,
|42|=42, get over it."
>
> To back out a bit, here, and get back to the meat of the matter: if one is
> using Python, then it's because one doesn't much care about performance,
I'll try again: this has nothing to do with performance.
> and it's reasonable to do expansions, pattern matching and domain specific
> language creation/use at run-time. After all, that's how the language
> itself works, mostly.
The last example showed the macro inserting code to magically produce a
binding inside the reverse function. It would be easier to compare and
contrast with the Python equivalent if someone had posted such, but your
troops have fallen back to Fort So What? and pulled up the drawbridge.
Peace. Out. Ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Andrew Reilly wrote:
>
> > That all looks like data.
>
> No, not reverse, the part you did not understand. I do not mean what the
> code was doing, I meant that it was code.
>
Code is data is code - even in Python:
skills_table = [
{
"title": "Absolute Value",
"annotations": ["Bleah bleah", "ho hum", "etc..."],
"hints": ["and so on", "etc..."],
"reverse" : (lambda x: whatever(x))
},
{
"title": "Square Root",
"annotations": ["Bleah bleah", "ho hum", "etc..."],
"hints": ["and so on", "etc..."],
"reverse" : (lambda x: someother(x))
},
# etc...
]
Of course those lambdas are crippled in Python (and not really
necessary in this bogus example)... But that's without trying to be
clever:
class AbsoluteValue:
title="Absolute Value"
annotations=["Some list", "goes here"]
@classmethod
def reverse(cls, *args):
# I didn't understand what your code was doing
pass
defskill(AbsoluteValue)
That would be a reasonable place for a "pie decorator" on a class, but
I guess that's not allowed. I doubt this second example would be
considered "Pythonic" in any case...
> > Couldn't you do that with a table
> > containing those fields, and key it off the defskill argument (or even the
> > title?) at startup?
>
> Not the code. In reverse.
>
Why not?
Python has plenty of other flaws that I can't happily work around, and
I do think Lisp is more flexible. However, I think your example is
readable enough with a data driven algorithm in most any popular
language. All of the data is visible to the reverse(...) method.
Maybe I missed something in your example, but I think you aren't trying
hard enough. :-)
The one I liked was: http://ll1.ai.mit.edu/shriram-talk.pdf
If I ever fill in your RtL survey, I'll be citing that one as a turning
point for me.
>
> Interpolation does not mean what you think it means.
I'm sure he meant "string interpolation", which is a common enough term
in scripting languages nowdays.
> It would be easier to compare and
> contrast with the Python equivalent if someone had posted such, but your
> troops have fallen back to Fort So What? and pulled up the drawbridge.
>
Oh God! Is it just me out here? And I'm not even a believer.
Cheers.
·······@gmail.com wrote:
> Ken Tilton wrote:
>
>>Andrew Reilly wrote:
>>
>>
>>> That all looks like data.
>>
>>No, not reverse, the part you did not understand. I do not mean what the
>>code was doing, I meant that it was code.
>>
>
>
> Code is data is code
I was hoping no one would make that mistake. :) macros are all about
code is data, but code is not data in Python* so the two words code and
data serve to differentiate them for Pythonistas.
* Taking questions after a keynote to ILC200? where he reiterated that
Python was the same as Lisp for all intents and purposes:
Norvig: "Yes, John?"
McCarthy: "Is code also data in Python?"
Norvig: "No."
End of exchange. :)
>- even in Python:
This could be tougher than I thought.
>
> skills_table = [
> {
> "title": "Absolute Value",
> "annotations": ["Bleah bleah", "ho hum", "etc..."],
> "hints": ["and so on", "etc..."],
> "reverse" : (lambda x: whatever(x))
That does not demonstrate that code is data, that demonstrates that a
lambda is a first-class object (and, yes, Python's lambda is lame).
You will know you have code as data when you can write Python code that
takes apart "whatever(x)" and produces "oh-now-I-get-it(y)". As part of
the language, such that Python applies your transforming code for you
whenever it sees whatever. (Hell, even C has a preprocessor.)
> },
> {
> "title": "Square Root",
> "annotations": ["Bleah bleah", "ho hum", "etc..."],
> "hints": ["and so on", "etc..."],
> "reverse" : (lambda x: someother(x))
> },
> # etc...
> ]
>
> Of course those lambdas are crippled in Python (and not really
> necessary in this bogus example)... But that's without trying to be
> clever:
>
> class AbsoluteValue:
> title="Absolute Value"
> annotations=["Some list", "goes here"]
> @classmethod
> def reverse(cls, *args):
> # I didn't understand what your code was doing
yeah, and god forbid you should ask. :) this is the crux of the matter!
Actually, it is kinda cool that you and Greg are semi-identifying the
crux by saying "this is the only bit I do not get, I'll skip this, move
on, nothing to see here".
> pass
> defskill(AbsoluteValue)
>
> That would be a reasonable place for a "pie decorator" on a class, but
> I guess that's not allowed.
Hmmm. Actually, that is the whole point, all of Python is allowed.
decorators were used in PyCells, but I never got much of an idea what
they did. Is there a moral equivalent of a macroexpansion for decorators
so you can show the before and after?
> I doubt this second example would be
> considered "Pythonic" in any case...
exactly what we are looking for in this cultural exchange: how would
Python handle what I am doing with macros in the reverse functions? Make
it as slick and programmer-friendly (cuz I may get to a hundred of these
before I am done with Algebra I) as possible. When all the Pythonistas
proclaim it optimal, then we compare and contrast.
This, btw, is the Tilton Test for language comparison: Not measurements
of programmer effort, rather examination of perfect equivalent code.
PyCells vs Cells would be an amazing case, because that is some hairy
functionality.
>>Not the code. In reverse.
>>
> Why not?
Is, too! (ie, I am kinda looking for a specific question that conveys
understanding of the use case.)
> Python has plenty of other flaws that I can't happily work around, and
> I do think Lisp is more flexible. However, I think your example is
> readable enough with a data driven algorithm in most any popular
> language. All of the data is visible to the reverse(...) method.
> Maybe I missed something in your example, but I think you aren't trying
> hard enough. :-)
Precisely. I am not trying at all. I am coding between visits to Usenet.
This use case just popped up and was pretty simple (at first, before I
got to the reverse function) so I dropped it off. This is a wild macro,
not farm-bred, deliberately crafted to embarrass macro. A real live
natural comes up all the time working wouldn't want to code without it
macro. I could have searched my code base to find more brutal cases, but
this is short and sweet and unforced and uncontrived and wheres my
thesaurus?
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> ·······@gmail.com wrote:
> >
> > Code is data is code
>
> I was hoping no one would make that mistake. :) macros are all about
> code is data, but code is not data in Python* so the two words code and
> data serve to differentiate them for Pythonistas.
>
I disagree. I frequently write data-driven algorithms in C and Python
(data is code). I occasionally write code-generators too (code is
data). Just because the representation is different between code and
data in those languages doesn't mean that you can't use data as code
(interpreter style) or generate code as data (compiler style). (I
won't bother boring you with the Python bytecode hacks or the parser
module, because I think those are not terribly practical.)
It's very elegant that Lisp makes the representations between code and
data so similar, but it looks like you know the mantra and not the
meaning if you can't apply that principle in other languages.
BTW... Even in Scheme, I have to use syntax-object->datum and it's
inverse to switch between the two. I suspect this has something to do
with the other context that must be associated with the data to turn it
into code. Probably at least the enclosing environment for lexical
scoping and the line numbers for debugging or exception handling. Does
Common Lisp maintain this information with it's macro expansions? If
so, you have a slight difference between code and data too. If not,
how do you get the line number when a problem happens in a nested
macro?
Moreover, if you really want to be pedantic about what "is" means in
"code is data", then you have to acknowledge that data is a superset of
code, since all code is obviously data, but there are plenty of types
of data that aren't used as code. Or are they? :-)
> * Taking questions after a keynote to ILC200? where he reiterated that
> Python was the same as Lisp for all intents and purposes:
>
> Norvig: "Yes, John?"
> McCarthy: "Is code also data in Python?"
> Norvig: "No."
>
> End of exchange. :)
>
Really? You're relying on an appeal to authority? Ok, I'm going to
start arguing by analogy then...
> > def reverse(cls, *args):
> > # I didn't understand what your code was doing
>
> yeah, and god forbid you should ask. :) this is the crux of the matter!
>
> Actually, it is kinda cool that you and Greg are semi-identifying the
> crux by saying "this is the only bit I do not get, I'll skip this, move
> on, nothing to see here".
>
Ok, I'll bite. What does it do? I read through it, and it looks the
code you're passing to the macro does some things like calculating the
number of decimal digits and generating a 2 + a random number of that
many digits to find a divisor or something. It also looks like you
have some "string interpolation" to substitute names in your text, but
as a whole, I really don't have any clue what it's all about.
It looks like the macro itself is building some names on the fly and
defining methods (new specializations for multimethods?) with those
names.
So I'm sure I'm missing something, but there is almost certainly a
readable equivalent in Python (and even C). If you really want to
generate dynamic names for functions, you can do that in Python by
modifying the class or globals hash or whatever. A more standard way
might be to be have members in the base class.
There is even a multi-methods module in Python, but I've never used it.
I'd guess you could add to that dynamically too.
> >
> > That would be a reasonable place for a "pie decorator" on a class, but
> > I guess that's not allowed.
>
> Hmmm. Actually, that is the whole point, all of Python is allowed.
> decorators were used in PyCells, but I never got much of an idea what
> they did. Is there a moral equivalent of a macroexpansion for decorators
> so you can show the before and after?
>
It's Python that doesn't allow you to decorate classes. (You can
decorate functions, but not classes...) I made this comment as a
criticism of Python since it seems like a non-orthogonal corner... It
would have fit in this case.
Decorators are pretty simple:
@foo
def bar(): pass
is equivalent to:
def bar(): pass
bar = foo(bar)
The callable foo can use whatever it wants to inspect, modify, or wrap
the function bar.
but:
@foo
class bar: pass
is not currently allowed, so you have to do
class bar: pass
bar = foo(bar)
>
> exactly what we are looking for in this cultural exchange: how would
> Python handle what I am doing with macros in the reverse functions? Make
> it as slick and programmer-friendly (cuz I may get to a hundred of these
> before I am done with Algebra I) as possible. When all the Pythonistas
> proclaim it optimal, then we compare and contrast.
>
> This, btw, is the Tilton Test for language comparison: Not measurements
> of programmer effort, rather examination of perfect equivalent code.
> PyCells vs Cells would be an amazing case, because that is some hairy
> functionality.
>
That seems like a fine strategy. I fall more on the programmer effort
side. I want to write as little code as possible in a readable way
such that it meets the requirements.
I'm not a particularly good ambassador for Python. I know Python much
better than Lisp (Scheme), but I already think Scheme is a better
language. Macros are part of that. I'm mostly playing devil's
advocate here because I don't think your example really brings it home.
I've got limited time that I'm willing to invest in learning your
algebra system, but I haven't seen (understood, if you insist) anything
yet that couldn't be done readably in Python. If you want Common Lisp
to win in your language battle against the Pythonistas, you're going to
need to break out with something stronger. Then again, you're probably
pissing into the wind anyway.
Cheers,
-Scott
·······@gmail.com wrote:
> Ken Tilton wrote:
>
>>·······@gmail.com wrote:
>>
>>>Code is data is code
>>
>>I was hoping no one would make that mistake. :) macros are all about
>>code is data, but code is not data in Python* so the two words code and
>>data serve to differentiate them for Pythonistas.
>>
>
>
> I disagree.
I might agree. The suggest alternative where the engine would build up
an "environment" such that a lambda could seem to be accessing a
pre-defined slot-name reminded me of some of the magic I noticed when
trying to port Cells to Python. If the interpreter (as it seems)
gracefully handles things like that, then one could argue that Python
can at least generate code to be consumed by what I would have as a
macro body, and thus achieve a degree of code is data.
Of course then I would point out that this would be terribly confusing
and should be banned from Python for the same reason as are macros. :)
I frequently write data-driven algorithms in C and Python
> (data is code). I occasionally write code-generators too (code is
> data). Just because the representation is different between code and
> data in those languages doesn't mean that you can't use data as code
> (interpreter style) or generate code as data (compiler style). (I
> won't bother boring you with the Python bytecode hacks or the parser
> module, because I think those are not terribly practical.)
>
> It's very elegant that Lisp makes the representations between code and
> data so similar, but it looks like you know the mantra and not the
> meaning if you can't apply that principle in other languages.
>
> BTW... Even in Scheme, I have to use syntax-object->datum and it's
> inverse to switch between the two. I suspect this has something to do
> with the other context that must be associated with the data to turn it
> into code. Probably at least the enclosing environment for lexical
> scoping and the line numbers for debugging or exception handling. Does
> Common Lisp maintain this information with it's macro expansions? If
> so, you have a slight difference between code and data too. If not,
> how do you get the line number when a problem happens in a nested
> macro?
>
> Moreover, if you really want to be pedantic about what "is" means in
> "code is data", then you have to acknowledge that data is a superset of
> code, since all code is obviously data, but there are plenty of types
> of data that aren't used as code. Or are they? :-)
>
>
>
>>* Taking questions after a keynote to ILC200? where he reiterated that
>>Python was the same as Lisp for all intents and purposes:
>>
>>Norvig: "Yes, John?"
>>McCarthy: "Is code also data in Python?"
>>Norvig: "No."
>>
>>End of exchange. :)
>>
>
>
> Really? You're relying on an appeal to authority? Ok, I'm going to
> start arguing by analogy then...
Analogies! My favorite! When a state trooper tells me not to drive my
Corvair over 55 that is argument from authority. When Ralph Nader tells
me....
>
>
>
>
>>> def reverse(cls, *args):
>>> # I didn't understand what your code was doing
>>
>>yeah, and god forbid you should ask. :) this is the crux of the matter!
>>
>>Actually, it is kinda cool that you and Greg are semi-identifying the
>>crux by saying "this is the only bit I do not get, I'll skip this, move
>>on, nothing to see here".
>>
>
>
> Ok, I'll bite. What does it do?
There's been more on this elsewhere and I need to get some work done, so
i am afraid from now on it will have to be analogies and arguments from
authority, much faster.
> I read through it, and it looks the
> code you're passing to the macro does some things like calculating the
> number of decimal digits and generating a 2 + a random number of that
> many digits to find a divisor or something. It also looks like you
> have some "string interpolation" to substitute names in your text, but
> as a whole, I really don't have any clue what it's all about.
>
> It looks like the macro itself is building some names on the fly and
> defining methods (new specializations for multimethods?) with those
> names.
>
> So I'm sure I'm missing something, but there is almost certainly a
> readable equivalent in Python (and even C). If you really want to
> generate dynamic names for functions, you can do that in Python by
> modifying the class or globals hash or whatever. A more standard way
> might be to be have members in the base class.
>
> There is even a multi-methods module in Python, but I've never used it.
> I'd guess you could add to that dynamically too.
>
>
>
>>>That would be a reasonable place for a "pie decorator" on a class, but
>>>I guess that's not allowed.
>>
>>Hmmm. Actually, that is the whole point, all of Python is allowed.
>>decorators were used in PyCells, but I never got much of an idea what
>>they did. Is there a moral equivalent of a macroexpansion for decorators
>>so you can show the before and after?
>>
>
>
> It's Python that doesn't allow you to decorate classes. (You can
> decorate functions, but not classes...) I made this comment as a
> criticism of Python since it seems like a non-orthogonal corner... It
> would have fit in this case.
>
> Decorators are pretty simple:
>
> @foo
> def bar(): pass
>
> is equivalent to:
>
> def bar(): pass
> bar = foo(bar)
>
> The callable foo can use whatever it wants to inspect, modify, or wrap
> the function bar.
>
> but:
>
> @foo
> class bar: pass
>
> is not currently allowed, so you have to do
>
> class bar: pass
> bar = foo(bar)
>
>
>
>
>>exactly what we are looking for in this cultural exchange: how would
>>Python handle what I am doing with macros in the reverse functions? Make
>>it as slick and programmer-friendly (cuz I may get to a hundred of these
>>before I am done with Algebra I) as possible. When all the Pythonistas
>>proclaim it optimal, then we compare and contrast.
>>
>>This, btw, is the Tilton Test for language comparison: Not measurements
>>of programmer effort, rather examination of perfect equivalent code.
>>PyCells vs Cells would be an amazing case, because that is some hairy
>>functionality.
>>
>
>
> That seems like a fine strategy. I fall more on the programmer effort
> side. I want to write as little code as possible in a readable way
> such that it meets the requirements.
You misunderstood. The Tilton Test is not indifferent to programmer
effort, it simply acknowledges that one cannot use it to compare
languages because one cannot control for programmer ability, which
varies more than language expressiveness. I am guessing (literally) that
we have a better chance of objective measures comparing two
community-polished code products passing the same functional tests.
>
> I'm not a particularly good ambassador for Python. I know Python much
> better than Lisp (Scheme), but I already think Scheme is a better
> language. Macros are part of that. I'm mostly playing devil's
> advocate here because I don't think your example really brings it home.
> I've got limited time that I'm willing to invest in learning your
> algebra system, but I haven't seen (understood, if you insist) anything
> yet that couldn't be done readably in Python.
That is fine, this is a cultural exchange, merely disguised as a war to
keep the children amused. Again, I thought the environment suggestion
was promising, and reminded me that Python /does/ do some neat things in
re turning references into dictionary lookups such that datanames /can/
be at least generated dynamically.
> If you want Common Lisp
> to win in your language battle against the Pythonistas, you're going to
> need to break out with something stronger. Then again, you're probably
> pissing into the wind anyway.
A long, civil, technical thread contrasting Python and Lisp is not
exactly a loss to humanity. Too bad Ruby could not join us.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> McCarthy: "Is code also data in Python?"
> Norvig: "No."
I don't think that was the right answer. He should have
said "Yes", and then shown McCarthy eval() and exec.
Code isn't quite as *convenient* to work with as data
in Python as it is in Lisp, but that doesn't mean it
can't be done.
(I agree that the proffered example was not an instance
of "code is data", though.)
--
Greg
greg wrote:
> Ken Tilton wrote:
>
>> McCarthy: "Is code also data in Python?"
>> Norvig: "No."
>
>
> I don't think that was the right answer.
Norvig is a smart guy. He was talking to John McCarthy. He gave the
right answer. :)
> He should have
> said "Yes", and then shown McCarthy eval() and exec.
No, in those cases the Python interpreter is still dealing with the
code, not the user's application code. As a meta-developer (to coin a
word) I want to be able to write code that takes apart other code I
write to do useful things with it /without writing a parser for my
chosen language/. I just found a bug in ACL that might be instructive.
The defskill macro I have been writing might be coded like this:
(defskill abs-value
(category "Algebra I" "Real Numbers")
....)
(I am kinda mirroring defclass here, which looks like:
(defclass <name> <superclasses>*
(<slot-defs>*)
...and then optional sub-specs each keyed by the first symbol..
(:documentation "chya")
(:metaclass...)
(:default-initargs)))
Come to think of it, I might have made /my/ options :keywords just to
make the resemblance stronger (and yes I am digressing into the bit
about how Lispniks by convention stay recognizable with new syntax).
Anyway, I decided to do a little auto QA and add an assertion to make
sure I did not inadvertently leave out the category option (long story,
I am not usually so anal), so defskill starts like this:
(defmacro defskill (id &body skill-info)
(assert (find 'category skill-info :key 'car))...
That is just normal list code. The macro signature destructures the code
I write inside the defskill invocation into an id and a list of
following code ("&body skill-info" says "bind the rest of the code to
the local variable skill-info as a list"). the (find ... :key 'car)
walks down the list taking the car (first) of each list and comparing
against that which is being sought. Simple ol' Lisp.
I then expand the (somewhat) validated data/code:
(loop with sub-id = id
for (q . q-def) in skill-info
collecting
(ecase q
(category <return desired Lisp code>)
...etc...)
q for "quality" or "attribrute". Not "o" for option. :) Again, using
standard loop destructuring on the option code/data.
Y'all need to get over it: we really are writing code that eats
code/data to produce code. Unaided by any parser other than the same
destructuring mechanisms we use on data.
ken
ps. I forgot the bug. I coded in the end:
(defskill |Absolute Value| ...etc..)
Where |absolute value| should be treated as a single symbol, and is by
the ACL compiler. An interactive macroexpand, however, misses that that
is one symbol and defskill (if you followed the Lisp) dies trying to
take the car of the atom VALUE (a symbol). k
greg <····@cosc.canterbury.ac.nz> writes:
> Ken Tilton wrote:
>
>> McCarthy: "Is code also data in Python?"
>> Norvig: "No."
>
> I don't think that was the right answer. He should have
> said "Yes", and then shown McCarthy eval() and exec.
>
> Code isn't quite as *convenient* to work with as data
> in Python as it is in Lisp, but that doesn't mean it
> can't be done.
This sounds like the Turing argument, because that convenience makes
all the difference. Raw, unparsed text is nothing like trees of
symbols and objects when it comes to transforming or analyzing code.
Ken Tilton wrote:
> What if it turns into an SQL lookup during refactoring?
If the macro can produce SQL code, then whatever interprets the
table can produce SQL code as well.
If you're thinking of the macro taking apart the user's reverse
function (rather than just wrapping it) and somehow translating
it into SQL, well... a macro *could* do that, but it would be
an awfully hairy thing to do, especially if the user is allowed
to write arbitrary Lisp code in the body of his function (as
it seems he is, in your example).
A better way would be to design an abstract API for the user
to use in his reverse functions. Then you can just re-implement
the functions making up the API so that they do SQL queries
instead of whatever they were doing before. No macro processing
needed then.
> The last example showed the macro inserting code to magically produce a
> binding inside the reverse function.
Are you sure? It looked to me like it was adding code *around*
the reverse function, not inside it. I posted a Python function
that achieves the same thing by calling the existing reverse
function.
> It would be easier to compare and
> contrast with the Python equivalent if someone had posted such, but your
> troops have fallen back to Fort So What? and pulled up the drawbridge.
I'm still trying, but some of the code you posted is rather
impenetrable without knowing a lot more about the details of
your system. I'm doing my best to show some Python demonstrating
the gist of what could be done.
--
Greg
greg wrote:
> Ken Tilton wrote:
>
>> The last example showed the macro inserting code to magically produce
>> a binding inside the reverse function.
>
>
> Are you sure? It looked to me like it was adding code *around*
> the reverse function, not inside it. I posted a Python function
> that achieves the same thing by calling the existing reverse
> function.
You are thinking about the results iteration, where you broke
encapsulation. I just reminded you of the magical "signed-value" binding
in a reply to another post of yours.
btw, when looking back at the rest of the code I was reminded I had done
something even wilder (well, maybe as wild) in the transforming code
itself. I say "wilder" in the sense of it being waaaaay cool, having a
flying-without-a-net feeling, yet making coding of dozens and dozens of
these transformations simpler, terser, and less buggy.
Someone had me laughing when they said the actual application of a macro
was nice and simple, but the macro itself was scary. It reminded me of a
cranky but sweet old guy on a project who was outraged upon learning I
was using a finite state machine to handle a shaky exchange between two
processes. He maintained that I was "foisting a crazy scheme on the
bank" which no one would be able to maintain. He actually forced me to
defend it in a group code review, the first they ever had, so don't
think it was a normal process for them, this was war. After my
demonstration on how the FSM would react to either or both processes
going south at any point in the exchange, the crank pronounced his
satisfaction with the approach and said, "OK, that is simple. The
infinite-state thing is complicated, but the way it works is simple."
That really made the whole thing worthwhile. :)
> I'm still trying, but some of the code you posted is rather
> impenetrable without knowing a lot more about the details of
> your system. I'm doing my best to show some Python demonstrating
> the gist of what could be done.
Great. That's the spirit. But how do we move forward if you just express
global confusion? See if you can understand the magical binding of the
parameter "signed-value". The reverse function will be called by the
engine to reverse a mathematical transformation, in this case simply
taking the absolute value. The generic engine has no way of knowing out
of all the targets, results, and operands (targets from a "before"
expression relocated in their incarnation in the expression operated on)
recorded by a transformation to pass in that position. When I code that
reverse function, I just want to work on the signed-value, as identified
in hard-code fashion by the transformation. ie, All I need do is
coordiate the TF and its reverser. If the reverser needs something else,
say the "coefficient" (this would be a add-like-terms TF), I just go to
the add-like-terms and have it tag the coefficients with the symbol
'coefficient, then I can code:
(reverse (coefficient literal-part)...)
Ah. Time to refactor. I will have multiple coefficients, and when
multiples are expected I want all the input math forms searched for
those tagged coefficient. Any ideas out there? :) It is so tempting to
add an s and have the macroexpansion look for a trailing s in the
symbol-name, but then I am bound to have some singular and in s. Ah,
grep to the rescue: (reverse (literal-part coefficient+)...)
Sweet. By using + I can even have the macroexpansion insert an assertion
that there is at least one. Of course there should be at least two or
this TF would not fire. And so it goes...
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> The reason I post macro expansions along with examples of the macro
> being applied is so that one can see what code would have to be written
> if I did not have the defskill macro to "write" them for me.
It seems to me your brain is somewhat stuck on the use
of macros. You're looking at the expansion of your
macro and assuming that you'd have to write all that
code by hand if you didn't have macros. You're not
thinking about alternative approaches, which could
just as well be used in Lisp as well as Python, that
are just as compact yet don't make use of macros.
Unless there's something very subtle that I'm missing
(I can't claim to follow exactly what all the code
you posted does in detail) I haven't seen anything
that couldn't be done quite reasonably with an
appropriate data structure and ordinary functions
and methods operating on that data structure.
--
Greg
greg wrote:
> Ken Tilton wrote:
>
>> The reason I post macro expansions along with examples of the macro
>> being applied is so that one can see what code would have to be
>> written if I did not have the defskill macro to "write" them for me.
>
>
> It seems to me your brain is somewhat stuck on the use
> of macros. You're looking at the expansion of your
> macro and assuming that you'd have to write all that
> code by hand if you didn't have macros. You're not
> thinking about alternative approaches,...
I think your brain is stuck on flaming. I am not thinking about Python
approaches, I am sking Pythonistas to do that. After understanding my
examples. Unfortunately I do not see the latter really happening, so we
are about done here.
> Unless there's something very subtle that I'm missing
> (I can't claim to follow exactly what all the code
> you posted does in detail) I haven't seen anything
> that couldn't be done quite reasonably with an
> appropriate data structure and ordinary functions
> and methods operating on that data structure.
I did explain the last little fun bit (where reverse code miraculously
got a case-specific "signed-value" parameter bound to exactly the right
bit of math structure). This process works only if you then ask
specifically about that (if anything was unclear--my guess is you did
not try all that hard since you are in argue-mode). The other reason you
may not have understodd is that that is waaaaay meta-cool, so meta I do
understand if it went over your head and I would (have been) happy to
explain had you asked.
Time to put the game on, I think. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> I think your brain is stuck on flaming.
Sorry, I didn't mean to come across as flaming, far
from it. I'll take a deep breath before posting from
now on, I promise. :-)
> I did explain the last little fun bit (where reverse code miraculously
> got a case-specific "signed-value" parameter bound to exactly the right
> bit of math structure).
I didn't mention that because it was addressed by
another poster. The signature of the user's reverse
function can be made extremely flexible if you have
the foresight to define it as something like
def reverse(resx, opnd, **kwds):
...
Then you can later change it to
def reverse(resx, opnd, signed_value, **kwds):
...
and any existing reverse functions will just absorb
and ignore the extra argument.
However, rather than add an ever-increasing number
of arguments to the signature, I think I would do it
a different way: pass a single object with attributes.
For the want of a better name, let's call it "env"
for "environment". The signature is then
def reverse(env):
...
and the body can refer to env.resx, env.opnd,
env.signed_value, or whatever else is required.
If this still doesn't cover the requirements, please
explain and I'll try to adapt it accordingly.
--
Greg
greg wrote:
> Ken Tilton wrote:
>
>> I did explain the last little fun bit (where reverse code miraculously
>> got a case-specific "signed-value" parameter bound to exactly the
>> right bit of math structure).
>
>
> I didn't mention that because it was addressed by
> another poster. The signature of the user's reverse
> function can be made extremely flexible if you have
> the foresight to define it as something like
>
> def reverse(resx, opnd, **kwds):
> ...
>
> Then you can later change it to
>
> def reverse(resx, opnd, signed_value, **kwds):
> ...
>
> and any existing reverse functions will just absorb
> and ignore the extra argument.
>
> However, rather than add an ever-increasing number
> of arguments to the signature, I think I would do it
> a different way: pass a single object with attributes.
> For the want of a better name, let's call it "env"
> for "environment". The signature is then
>
> def reverse(env):
> ...
>
> and the body can refer to env.resx, env.opnd,
> env.signed_value, or whatever else is required.
Looks promising. How does a generic engine that sees only a solution (a
list of mathematical expressions and for each the transformations,
results, and opnds logged by individual TF functions) build up this
environment such that it has named attributes such as signed-value?
Assume that it can examine all those opnds and results looking for
tagged values such that it then knows the name of those values that have
been named.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton schrieb:
> Looks promising. How does a generic engine that sees only a solution (a
> list of mathematical expressions and for each the transformations,
> results, and opnds logged by individual TF functions) build up this
> environment such that it has named attributes such as signed-value?
Most likely it doesn't since there is no such engine. Instead local
rules and combinators are encoded in classes. Hence there is nothing
but an object tree and actions are threaded through recursive method
calls.
This implies that the generic reverse function is just the dual of a
method call:
def reverse(expr):
return expr.reverse()
What expr does depends on the internal representation encoded in the
class of expr. This also implies that not only the form of the
expression is significant but also its ( dynamic ) type.
Kay Schluehr wrote:
> Ken Tilton schrieb:
>
>
>>Looks promising. How does a generic engine that sees only a solution (a
>>list of mathematical expressions and for each the transformations,
>>results, and opnds logged by individual TF functions) build up this
>>environment such that it has named attributes such as signed-value?
>
>
> Most likely it doesn't since there is no such engine. Instead local
> rules and combinators are encoded in classes. Hence there is nothing
> but an object tree and actions are threaded through recursive method
> calls.
Most likely that is the engine of which I was speaking. :) Why does the
engine consisting of "internal" methods make it not an engine? I think
you saw the word "engine" and assumed I did not understand OO design. I
feel a Naggum coming on...
kt
ps. This won't make sense unless you know about my Cells project, but
the solution to a /problem/ which has attributes expr and instructions,
is a declarative attribute of a problem. But that attribute is coded
essentially like this:
(defclass problem ()
....
(solution :accessor solution
:initform (c-formula ()
(solve (expr self) (instructions self)))))
k
>
> This implies that the generic reverse function is just the dual of a
> method call:
>
> def reverse(expr):
> return expr.reverse()
>
> What expr does depends on the internal representation encoded in the
> class of expr. This also implies that not only the form of the
> expression is significant but also its ( dynamic ) type.
>
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> How does a generic engine that sees only a solution (a
> list of mathematical expressions and for each the transformations,
> results, and opnds logged by individual TF functions) build up this
> environment such that it has named attributes such as signed-value?
How did your macro know that the user's reverse function
needed a signed_value parameter in that particular case?
> Assume that it can examine all those opnds and results looking
> for tagged values such that it then knows the name of those values
> that have been named.
You might be able to handle this using a general method
that searches the tree for a specified tag, e.g.
env.find_tag("signed_value")
--
Greg
greg schrieb:
> Ken Tilton wrote:
>
>> The reason I post macro expansions along with examples of the macro
>> being applied is so that one can see what code would have to be
>> written if I did not have the defskill macro to "write" them for me.
>
> It seems to me your brain is somewhat stuck on the use of macros.
That you see it this way is normal.
A BASIC programmer would tell you the same thing. He can show you
solutions that don't use classes, methods or functions.
Some sweet gotos and gosubs are enough.
The idea is that macros save you tokens and allow you to experess
in a clearer way what you want to do. But in no case one "needs"
them to solve a programming problem. All what Kenny showed could
be done without his macro. It would just be a bit more complicated
and the resulting code wouldn't look good.
> You're looking at the expansion of your
> macro and assuming that you'd have to write all that
> code by hand if you didn't have macros. You're not
> thinking about alternative approaches, which could
> just as well be used in Lisp as well as Python, that
> are just as compact yet don't make use of macros.
He wouldn't have to write the full expansion. With functional
programming he could also solve it, but then he would need
a funcall here, a lambda there. And his code would not look
so understandable anymore, because it is filled up with some
low level details.
I will take one of the first macro examples form "On Lisp".
Let's say for some reason you want to analyse some numbers
and do something depending on their sign. We want a function
"numeric if":
def nif(num, pos, zero, neg):
if num > 0:
return pos
else:
if num == 0:
return zero
else:
return neg
In Lisp very similar:
(defun nif (num pos zero neg)
(case (truncate (signum num))
(1 pos)
(0 zero)
(-1 neg)))
Now one example Graham gives is:
(mapcar #'(lambda (x)
(nif x 'p 'z 'n))
'(0 2.5 -8))
which results in the list (Z P N).
You can do the same thing in Python.
But it gets hairier if we want to make function calls that
have side effects.
Let me add these three functions:
(defun p ()
(print "very positive")
"positive")
(defun z ()
(print "no no")
"zero")
(defun n ()
(print "very negative")
"negative")
And now see what happens:
CL-USER> (mapcar #'(lambda (x)
(nif x (p) (z) (n)))
'(0 2.5 -8))
"very positive"
"no no"
"very negative"
"very positive"
"no no"
"very negative"
"very positive"
"no no"
"very negative"
("zero" "positive" "negative")
The messages were printed in each case.
To stop that I need lazy evaluation:
CL-USER> (mapcar #'(lambda (x)
(funcall
(nif x
#'(lambda () (p))
#'(lambda () (z))
#'(lambda () (n)))))
'(0 2.5 -8))
"no no"
"very positive"
"very negative"
("zero" "positive" "negative")
I put the calls to the functions p, z and n into a function object.
In some languages it would look a bit cleaner, for example Ruby.
They have a single name space and don't need funcall and lambda is
shorter. But still, we need to add several tokens. Maybe Haskell has
built in support for that.
Now with nif as a macro:
(defmacro nif (expr pos zero neg)
`(case (truncate (signum ,expr))
(1 ,pos)
(0 ,zero)
(-1 ,neg)))
It is a bit more complex as the function. It has one ` and 4 ,s
extra.
But now we can express the problem very well:
CL-USER> (mapcar #'(lambda (x)
(nif x (p) (z) (n)))
'(0 2.5 -8))
"no no"
"very positive"
"very negative"
("zero" "positive" "negative")
And the first example also still works the same way.
Now the expansion shows more code than we would have need to
write ourself. However, now we can write code that matches
much better how we think. No need for "low level" details like
embedding the code inside of anon functions.
This represents what most macros do. Save one or more lambdas
and/or funcalls. One consequence is that development time gets
cut down.
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> def nif(num, pos, zero, neg):
> if num > 0:
> return pos
> else:
> if num == 0:
> return zero
> else:
> return neg
def nif(num, pos, zero, neg):
return (neg, zero, pos)[cmp(num, 0)+1]
> The messages were printed in each case.
> To stop that I need lazy evaluation:
> CL-USER> (mapcar #'(lambda (x)
> (funcall
> (nif x
> #'(lambda () (p))
> #'(lambda () (z))
> #'(lambda () (n)))))
> '(0 2.5 -8))
in Python:
def lazy_nif(num, pos, zero, neg):
return (neg, zero, pos)[cmp(num, 0)+1]() # the () at the end means funcall
map(lambda x: lazy_nif(x, p, z, n), (0, 2.5, -8))
"nif" is even cleaner in Haskell, if I have this right:
nif x p z n | (x < 0) = n
| (x == 0) = z
| (x > 0) = p
All Haskell evaluation is automatically lazy, so no lambdas etc. needed.
>
> > The messages were printed in each case.
> > To stop that I need lazy evaluation:
> > CL-USER> (mapcar #'(lambda (x)
> > (funcall
> > (nif x
> > #'(lambda () (p))
> > #'(lambda () (z))
> > #'(lambda () (n)))))
> > '(0 2.5 -8))in Python:
>
> def lazy_nif(num, pos, zero, neg):
> return (neg, zero, pos)[cmp(num, 0)+1]() # the () at the end means funcall
>
> map(lambda x: lazy_nif(x, p, z, n), (0, 2.5, -8))
>
In Lisp, you'd need to wrap the functions in lambdas to avoid them
being evaluated when passed on to the function. In Python, the function
isn't evaluated (executed) when you pass it somewhere.
Can you please explain how forcing execution and passing along the
_return value_ (instead of the function itself!) makes it lazy?
--
Mikael Jansson
Paul Rubin wrote:
>
> "nif" is even cleaner in Haskell, if I have this right:
>
> nif x p z n | (x < 0) = n
> | (x == 0) = z
> | (x > 0) = p
>
> All Haskell evaluation is automatically lazy, so no lambdas etc. needed.
You can use that style in CL.
(defun nif (x p z n)
(or (when (< x 0) n)
(when (= x 0) z)
(when (> x 0) p)))
Wade
Wade Humeniuk <··················@telus.net> writes:
> > "nif" is even cleaner in Haskell, if I have this right:
> > nif x p z n | (x < 0) = n
> > | (x == 0) = z
> > | (x > 0) = p
> > All Haskell evaluation is automatically lazy, so no lambdas
> > etc. needed.
>
> You can use that style in CL.
>
> (defun nif (x p z n)
> (or (when (< x 0) n)
> (when (= x 0) z)
> (when (> x 0) p)))
Yeah but you can't apply it the same way.
[nif x p z n | x <- [0,2.5,-8]]
evaluates exactly one of p, z, or n, for each of the args in that
list. Side effects don't work the same way either, you have to use
special declarations around code with side effects. I'm not yet
conversant enough with Haskell to know how to do it for this example
though.
Paul Rubin wrote:
> André Thieme <······························@justmail.de> writes:
>> def nif(num, pos, zero, neg):
>> if num > 0:
>> return pos
>> else:
>> if num == 0:
>> return zero
>> else:
>> return neg
>
> def nif(num, pos, zero, neg):
> return (neg, zero, pos)[cmp(num, 0)+1]
Since we are in one liners, let's be even smarter and do it like that :
def nif(num, pos, zero, neg):
return (zero, pos, neg)[cmp(num, 0)]
;)
Christophe Cavalaria schrieb:
> Paul Rubin wrote:
>
>> Andr� Thieme <······························@justmail.de> writes:
>>> def nif(num, pos, zero, neg):
>>> if num > 0:
>>> return pos
>>> else:
>>> if num == 0:
>>> return zero
>>> else:
>>> return neg
>> def nif(num, pos, zero, neg):
>> return (neg, zero, pos)[cmp(num, 0)+1]
> Since we are in one liners, let's be even smarter and do it like that :
>
> def nif(num, pos, zero, neg):
> return (zero, pos, neg)[cmp(num, 0)]
Okay, that reduces the complexity of the Python version to that of Lisp.
Now both have the same token count.
Andr�
--
Paul Rubin schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>> def nif(num, pos, zero, neg):
>> if num > 0:
>> return pos
>> else:
>> if num == 0:
>> return zero
>> else:
>> return neg
>
> def nif(num, pos, zero, neg):
> return (neg, zero, pos)[cmp(num, 0)+1]
That is a nice idea. I can do the same in Lisp, but have to do it
without syntactic sugar which makes it longer, characterwise:
(defun nif2 (num pos zero neg)
(nth (1+ (truncate (signum num)))
(list pos zero neg)))
What Python has is cmp. That is doing what truncate+signum do in
Lisp. So that makes the biggest difference. Another one is that Lisps
signum keeps the datatype:
cmp(5.3, 0) => 1
(signum 5.3) => 1.0
Or also with complex numbers [syntax #C(real, img)]:
(signum #C(10 4)) => #C(0.9284767 0.37139067)
Anyway, from the complexity the Lisp version is a bit better.
The Python version has 11 tokens:
return, tuple-reference, comma, neg, zero, pos, +, 1, cmp, num, 0
and the Lisp version has only 9:
nth, 1+, truncate, signum, num, list, pos, zero, neg
(I didn't count the function head, because both have the same
token count).
>> The messages were printed in each case.
>> To stop that I need lazy evaluation:
>> CL-USER> (mapcar #'(lambda (x)
>> (funcall
>> (nif x
>> #'(lambda () (p))
>> #'(lambda () (z))
>> #'(lambda () (n)))))
>> '(0 2.5 -8))
>
> in Python:
>
> def lazy_nif(num, pos, zero, neg):
> return (neg, zero, pos)[cmp(num, 0)+1]() # the () at the end means funcall
>
> map(lambda x: lazy_nif(x, p, z, n), (0, 2.5, -8))
We could do the same in Lisp:
(defun lazy-nif (num pos zero neg)
(funcall (nth (1+ (truncate (signum num)))
(list pos zero neg))))
Here the token count is 12py vs 10cl.
CL-USER> (mapcar #'(lambda (x) (lazy-nif2 x #'p #'z #'n))
'(0 2.5 -8))
"no no"
"very negative"
"very positive"
("zero" "negative" "positive")
But there is a disadvantage:
>>> lazy_nif(0, "p", "z", "n")
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 2, in lazy_nif
TypeError: 'str' object is not callable
I don't know how I can fix that. Maybe you could tell me.
In Lisp I would just go with the macro. That works for all cases.
> "nif" is even cleaner in Haskell, if I have this right:
>
> nif x p z n | (x < 0) = n
> | (x == 0) = z
> | (x > 0) = p
>
> All Haskell evaluation is automatically lazy, so no lambdas etc. needed.
Yes, that was what I already supposed.
Do you also know how I can "deactivate" lazyness?
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> and the Lisp version has only 9:
> nth, 1+, truncate, signum, num, list, pos, zero, neg
Oh come on, you have to count the parentheses too.
Anyway, token count doesn't mean much, you have to instead go by the
user's cognitive effort in dealing with the prefix notation etc.,
which isn't purely a matter of token count. And if (+ 2 3) were
really as easy to read as 2+3, mathematics would have been written
that way all along.
> TypeError: 'str' object is not callable
> I don't know how I can fix that. Maybe you could tell me.
>>> lazy_nif(0, lambda: "p", lambda: "z", lambda: "n")
> > All Haskell evaluation is automatically lazy, so no lambdas etc. needed.
>
> Yes, that was what I already supposed.
> Do you also know how I can "deactivate" lazyness?
There's a Haskell builtin called 'seq' which forces evaluation but
again I'm not sure precisely how to apply it here.
Paul Rubin wrote:
> André Thieme <······························@justmail.de> writes:
> which isn't purely a matter of token count. And if (+ 2 3) were
> really as easy to read as 2+3, mathematics would have been written
> that way all along.
Maybe I am a "mutant" as Ken suggests but while mathematicians may
think in terms of infix, programmers have got very used to:
function (arg, arg, ...)
So when I see (+ 2 3) I just think function 'add' with arguments 2 and
3. Yep, I've moved the parens and removed the comma but that just makes
it even clearer. Then bring in more statement and you either have to
remember precedence rules (I can never remember those) or add some
parenthesis (oops!).
This may sounds paper thin to some people but if you appreciate
consistency then you'll appreciate the syntax.
Phil
···············@gmail.com wrote:
> Then bring in more statement and you either have to
> remember precedence rules (I can never remember those) or add some
> parenthesis (oops!).
Probably you've been burned by C, which has a
ridiculously large number of precedence levels --
I don't know *anyone* who can remember them all.
Most people just remember a subset and use
parens for everything else.
Pascal had four levels, which was easy to remember
but not really enough. About six or seven seems
optimal to me.
Python, incidentally, has rather too many (it
seems to have caught this disease from C).
--
Greg
Paul Rubin <·············@NOSPAM.invalid> writes:
> Andr� Thieme <······························@justmail.de> writes:
>> and the Lisp version has only 9:
>> nth, 1+, truncate, signum, num, list, pos, zero, neg
>
> Oh come on, you have to count the parentheses too.
No. Parentheses are editor commands. They don't count anymore than
spaces "count" in Python.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You question the worthiness of my code? I should kill you where you
stand!"
Paul Rubin schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>> and the Lisp version has only 9:
>> nth, 1+, truncate, signum, num, list, pos, zero, neg
>
> Oh come on, you have to count the parentheses too.
We could define hundreds of way how to count tokens.
But see the program as a tree:
nth
/ \
/ \
/ \
1+ list
| / | \
| / | \
truncate pos zero neg
|
|
signum
|
|
num
And I didn't count the indentation level and \n in Python code.
Why should I? They are editor commands.
> Anyway, token count doesn't mean much, you have to instead go by the
> user's cognitive effort in dealing with the prefix notation etc.,
How complicated ss it to say "cmp(a, b)" compared to "a cmp b"?
After a few days writing Lisp code your brain specializes on that
style. Arabian countries write from right to left. They seem to have
no problem to use what they know.
I admit that I am used to write +, -, * and / infix, because I were
trained in that thinking since day 1 in school.
In our example program there was only 1+ compared to ".. + 1" which
looks "alien" to untrained people.
If a program uses extensive math we can get syntax for Lisp that is
even more pleasant to read than Pythons:
17a + x�-x�
> which isn't purely a matter of token count. And if (+ 2 3) were
> really as easy to read as 2+3, mathematics would have been written
> that way all along.
Mathmaticians invented prefix notation and they use it regularily.
They inventey operators that wrap around their arguments, as one can
see here: http://www.mathe-trainer.com/formel/?SN=&t=1
Or think of indices, etc.
>> TypeError: 'str' object is not callable
>> I don't know how I can fix that. Maybe you could tell me.
>
>>>> lazy_nif(0, lambda: "p", lambda: "z", lambda: "n")
Yes, that works. And that's why I wanted to make it a macro.
Now you are essentially doing what I did in my first Lisp version.
While this works it is farer away from what we think.
(nif 0 "p" "z" "n")
(nif 0 #'p #'z #'n)
are exactly what one thinks.
For this reason "if" is implemented as a keyword in Python.
It allows you to give code as a block instead of embedding it into
a lambda or a def (which even needs a name).
And we might go further (again with an easy Graham example).
See this typical pattern:
result = timeConsumingCalculation()
if result:
use(result)
We need this ugly temporary variable result to refer to it.
If we could use the anaphor[1] "it" that could make situations like
these more clean.
Imagine Python would have an "anaphoric if", "aif". Then:
aif timeConsumingCalculation():
use(it)
Many Lispers might have this as a macro in their toolbox after some
time of coding or after reading Graham.
A short three-liner in Lisp and I can really say:
(aif (timeConsumingCalculation)
(use it))
How would you solve this in Python?
You could embed it inside a lambda and must somehow make the
variable "it" visible in it, because in the context of aif this
"it" gets bound to the result.
>>> All Haskell evaluation is automatically lazy, so no lambdas etc.
needed.
>> Yes, that was what I already supposed.
>> Do you also know how I can "deactivate" lazyness?
>
> There's a Haskell builtin called 'seq' which forces evaluation but
> again I'm not sure precisely how to apply it here.
I wouldn't wonder if there was an operator like "seq" to do that.
So in some languages that support functional programming one needs to do
extra work to get lazyness, while in Haskell one gets extra work if one
doesn't want it. But maybe someone can correct me here.
In Lisp one could build some features to get lazyness as well.
[1] http://en.wikipedia.org/wiki/Anaphora_%28linguistics%29
I hope this posting was not sent two times. I just sent it but it didn't
appear in my list after reloading.
Andr�
--
André Thieme wrote:
> Paul Rubin schrieb:
> > André Thieme <······························@justmail.de> writes:
> >> and the Lisp version has only 9:
> >> nth, 1+, truncate, signum, num, list, pos, zero, neg
> >
> > Oh come on, you have to count the parentheses too.
>
> We could define hundreds of way how to count tokens.
> But see the program as a tree:
>
> nth
> / \
> / \
> / \
> 1+ list
> | / | \
> | / | \
> truncate pos zero neg
> |
> |
> signum
> |
> |
> num
>
> And I didn't count the indentation level and \n in Python code.
> Why should I? They are editor commands.
>
>
> > Anyway, token count doesn't mean much, you have to instead go by the
> > user's cognitive effort in dealing with the prefix notation etc.,
>
> How complicated ss it to say "cmp(a, b)" compared to "a cmp b"?
> After a few days writing Lisp code your brain specializes on that
> style. Arabian countries write from right to left. They seem to have
> no problem to use what they know.
> I admit that I am used to write +, -, * and / infix, because I were
> trained in that thinking since day 1 in school.
> In our example program there was only 1+ compared to ".. + 1" which
> looks "alien" to untrained people.
> If a program uses extensive math we can get syntax for Lisp that is
> even more pleasant to read than Pythons:
> 17a + x³-x²
>
>
>
> > which isn't purely a matter of token count. And if (+ 2 3) were
> > really as easy to read as 2+3, mathematics would have been written
> > that way all along.
>
> Mathmaticians invented prefix notation and they use it regularily.
> They inventey operators that wrap around their arguments, as one can
> see here: http://www.mathe-trainer.com/formel/?SN=&t=1
>
> Or think of indices, etc.
>
>
>
> >> TypeError: 'str' object is not callable
> >> I don't know how I can fix that. Maybe you could tell me.
> >
> >>>> lazy_nif(0, lambda: "p", lambda: "z", lambda: "n")
>
> Yes, that works. And that's why I wanted to make it a macro.
> Now you are essentially doing what I did in my first Lisp version.
> While this works it is farer away from what we think.
>
> (nif 0 "p" "z" "n")
> (nif 0 #'p #'z #'n)
> are exactly what one thinks.
> For this reason "if" is implemented as a keyword in Python.
> It allows you to give code as a block instead of embedding it into
> a lambda or a def (which even needs a name).
>
>
> And we might go further (again with an easy Graham example).
> See this typical pattern:
>
> result = timeConsumingCalculation()
> if result:
> use(result)
>
> We need this ugly temporary variable result to refer to it.
> If we could use the anaphor[1] "it" that could make situations like
> these more clean.
>
> Imagine Python would have an "anaphoric if", "aif". Then:
>
> aif timeConsumingCalculation():
> use(it)
>
> Many Lispers might have this as a macro in their toolbox after some
> time of coding or after reading Graham.
> A short three-liner in Lisp and I can really say:
>
> (aif (timeConsumingCalculation)
> (use it))
>
> How would you solve this in Python?
> You could embed it inside a lambda and must somehow make the
> variable "it" visible in it, because in the context of aif this
> "it" gets bound to the result.
In Ruby:
def aif val
yield val if val
end
def complex_calc n
if n % 2 == 1
n**n
else
nil
end
end
aif( complex_calc( 9 ) ) {|x| puts "hello, #{x}"}
aif( complex_calc( 8 ) ) {|x| puts "hello, #{x}"}
--- output -----
hello, 387420489
>
> > How would you solve this in Python?
> > You could embed it inside a lambda and must somehow make the
> > variable "it" visible in it, because in the context of aif this
> > "it" gets bound to the result.In Ruby:
>
> def aif val
> yield val if val
> end
>
> def complex_calc n
> if n % 2 == 1
> n**n
> else
> nil
> end
> end
>
> aif( complex_calc( 9 ) ) {|x| puts "hello, #{x}"}
> aif( complex_calc( 8 ) ) {|x| puts "hello, #{x}"}
>
> --- output -----
> hello, 387420489
>
Okay, so it's certainly _doable_. I think the question is more if it's
usable. Regular if:s don't like that in Ruby/Python/similar, and adding
such a construct would mean extending the syntax.
In Lisp, all (well, almost) functions are equal, so an (if ...) would
look the same like the (aif ...). I think that's the point here.
--
Mikael Jansson
··············@gmail.com schrieb:
William James schrieb:
>>> How would you solve this in Python?
>>> You could embed it inside a lambda and must somehow make the
>>> variable "it" visible in it, because in the context of aif this
>>> "it" gets bound to the result.In Ruby:
>> def aif val
>> yield val if val
>> end
>>
>> def complex_calc n
>> if n % 2 == 1
>> n**n
>> else
>> nil
>> end
>> end
>>
>> aif( complex_calc( 9 ) ) {|x| puts "hello, #{x}"}
>> aif( complex_calc( 8 ) ) {|x| puts "hello, #{x}"}
>>
>> --- output -----
>> hello, 387420489
>>
> Okay, so it's certainly _doable_. I think the question is more if it's
> usable. Regular if:s don't like that in Ruby/Python/similar, and adding
> such a construct would mean extending the syntax.
>
> In Lisp, all (well, almost) functions are equal, so an (if ...) would
> look the same like the (aif ...). I think that's the point here.
Exactly that is the point.
*Of course* it is doable.
And what William shows us is maybe one of the best solutions
in Ruby. He used advanced abstractions that made it possible.
The thing with most (if not all) programming languages other than Lisp
is: these abstractions are leaky.
They have a low level knowledge leak. Users of aif need to know how to
pass in arguments. As you see he had do embed the code that needs execution
into a block (anon function) and then use this special syntax for x.
Andr�
--
André Thieme wrote:
> ··············@gmail.com schrieb:
> William James schrieb:
> >>> How would you solve this in Python?
> >>> You could embed it inside a lambda and must somehow make the
> >>> variable "it" visible in it, because in the context of aif this
> >>> "it" gets bound to the result.In Ruby:
> >> def aif val
> >> yield val if val
> >> end
> >>
> >> def complex_calc n
> >> if n % 2 == 1
> >> n**n
> >> else
> >> nil
> >> end
> >> end
> >>
> >> aif( complex_calc( 9 ) ) {|x| puts "hello, #{x}"}
> >> aif( complex_calc( 8 ) ) {|x| puts "hello, #{x}"}
> >>
> >> --- output -----
> >> hello, 387420489
> >>
> > Okay, so it's certainly _doable_. I think the question is more if it's
> > usable. Regular if:s don't like that in Ruby/Python/similar, and adding
> > such a construct would mean extending the syntax.
> >
> > In Lisp, all (well, almost) functions are equal, so an (if ...) would
> > look the same like the (aif ...). I think that's the point here.
>
> Exactly that is the point.
> *Of course* it is doable.
> And what William shows us is maybe one of the best solutions
> in Ruby. He used advanced abstractions that made it possible.
> The thing with most (if not all) programming languages other than Lisp
> is: these abstractions are leaky.
> They have a low level knowledge leak. Users of aif need to know how to
> pass in arguments. As you see he had do embed the code that needs execution
> into a block (anon function) and then use this special syntax for x.
>
>
> André
> --
I may have tried too hard. The simpler way is usually better.
No aif() is needed:
if x = complex_calc( 9 )
puts "hello, #{x}"
end
Andr� Thieme wrote:
> The thing with most (if not all) programming languages other than Lisp
> is: these abstractions are leaky.
> They have a low level knowledge leak. Users of aif need to know how to
> pass in arguments. As you see he had do embed the code that needs execution
> into a block (anon function) and then use this special syntax for x.
Yes, but all the standard looping constructs, etc.
in Ruby are expressed like this too. So it's
perfectly consistent with the rest of the language.
It's not something new that the user needs to learn
just to use this function.
This is even more evident in Smalltalk, where
*all* control structures, without exception, are
expressed in terms of code blocks, possibly
with parameters. And Smalltalk has no macros,
either, btw.
--
Greg
Andr� Thieme <······························@justmail.de> writes:
> And I didn't count the indentation level and \n in Python code.
> Why should I? They are editor commands.
No they're part of Python syntax. A change in indent level is
recognized by Python's lexical scanner as a token and you should count
it. You wouldn't count the indent and \n separately though.
> > Anyway, token count doesn't mean much, you have to instead go by the
> > user's cognitive effort in dealing with the prefix notation etc.,
>
> How complicated ss it to say "cmp(a, b)" compared to "a cmp b"?
It gets worse when the expressions are nested.
> Imagine Python would have an "anaphoric if", "aif". Then:
>
> aif timeConsumingCalculation():
> use(it)
Well, it's not really in the Pythonic style to add obscurity like
that, but you could certainly write something like:
def aif(func):
it = func()
if it: use(it)
aif(timeConsumingCalculation)
> So in some languages that support functional programming one needs
> to do extra work to get lazyness, while in Haskell one gets extra
> work if one doesn't want it. But maybe someone can correct me here...
> In Lisp one could build some features to get lazyness as well.
I think that is essentially correct. But it's not so easy to do extra
work to get Haskell-like laziness in languages that don't have it, not
because laziness itself is difficult, but non-lazy languages usually
end up giving up referential transparency.
http://lambda-the-ultimate.org/classic/message5750.html
Paul Rubin schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>> And I didn't count the indentation level and \n in Python code.
>> Why should I? They are editor commands.
>
> No they're part of Python syntax. A change in indent level is
> recognized by Python's lexical scanner as a token and you should count
> it. You wouldn't count the indent and \n separately though.
>
>> > Anyway, token count doesn't mean much, you have to instead go by the
>> > user's cognitive effort in dealing with the prefix notation etc.,
>>
>> How complicated ss it to say "cmp(a, b)" compared to "a cmp b"?
>
> It gets worse when the expressions are nested.
So instead of
cmp(foo(a, b, c), bar(x, y, z)) you would prefer
foo(a, b, c) cmp bar(x, y, z) ?
for x in 0 range len(s): ...
Maybe make single-digit functions postfix?
for x in 0 range (s)len: ...
>> Imagine Python would have an "anaphoric if", "aif". Then:
>>
>> aif timeConsumingCalculation():
>> use(it)
>
> Well, it's not really in the Pythonic style to add obscurity like
> that, but you could certainly write something like:
>
> def aif(func):
> it = func()
> if it: use(it)
>
> aif(timeConsumingCalculation)
This isn't doing the same. This hardencodes the call to use() inside
aif.
if timeConsumingCalculation():
foo(it)
bar(it)
But "if" is already taken for the standard if.
Instead we add a new keyword to Python, "aif".
Then we can say:
aif timeConsumingCalculation():
foo(it)
bar(it)
You can pass anonymous functions around etc, but it will become
ugly - no Pythoniast would ever do it in production code.
If there was an aif built into Python we would find it every
now and then.
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> >> How complicated ss it to say "cmp(a, b)" compared to "a cmp b"?
> > It gets worse when the expressions are nested.
>
> So instead of
> cmp(foo(a, b, c), bar(x, y, z)) you would prefer
> foo(a, b, c) cmp bar(x, y, z) ?
Don't be silly. Some operators are more natural as infix and others
as functions. It's just like in natural language. People have an
innate ability to make such distinctions and it's fine for a
programming language to use it.
In article <··············@ruckus.brouhaha.com>,
Paul Rubin <·············@NOSPAM.invalid> wrote:
> Don't be silly. Some operators are more natural as infix and others
> as functions. It's just like in natural language. People have an
> innate ability to make such distinctions and it's fine for a
> programming language to use it.
I don't think you can really make this case. In English, German and
Spanish noun-verb order is flexible to accommodate differences in
mood, tense, and emphasis:
"Add 2 and 2." imperative.
"The sum of 2 and 2" noun phrase.
"2 was added to 2." passive voice.
Personally, I've always preferred use the imperative to describe
basic math rather than the passive. This would seem to map better to
RPN than infix.
And on top of that, some languages are even more flexible in regard
to word order, preferring to communicate relationships through the
modification of noun stems. In such a language, "He* her- the ring+
gave," is just as valid as "Her- the ring+ gave he*" and "He* gave
her- the ring+." ("+/-/*" signifying modifications which do not
exist in modern English.)
At any rate, I find this argument to be weak given that English
doesn't always use the same word order. And English is just one
language out of hundreds.
Kirk Sluder <····@nospam.jobsluder.net> writes:
> Personally, I've always preferred use the imperative to describe
> basic math rather than the passive. This would seem to map better to
> RPN than infix.
For writing down complicated, nested expressions too? That's very
unusual. E.g.
n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...
vs. the same thing in Lisp notation, and that's not even so complicated.
Paul Rubin wrote:
> Kirk Sluder <····@nospam.jobsluder.net> writes:
>> Personally, I've always preferred use the imperative to describe
>> basic math rather than the passive. This would seem to map better to
>> RPN than infix.
>
> For writing down complicated, nested expressions too? That's very
> unusual. E.g.
>
> n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...
>
> vs. the same thing in Lisp notation, and that's not even so complicated.
Yes, infix is better ( and note that Math uses primarly infix notation for
common operators ) because you have a clear view of the evaluation tree
that way. With prefix or postfix notation, you need to parse the full
expression to find what goes to the first parameter of that +, and what
goes to the second parameter.
I would say that prefix/postfix is somewhat easier to write, but that infix
is far far far easier to read.
Christophe Cavalaria ha escrito:
> Yes, infix is better ( and note that Math uses primarly infix notation for
> common operators ) because you have a clear view of the evaluation tree
> that way. With prefix or postfix notation, you need to parse the full
> expression to find what goes to the first parameter of that +, and what
> goes to the second parameter.
>
> I would say that prefix/postfix is somewhat easier to write, but that infix
> is far far far easier to read.
The advantages from infix notation becomes from readability not from
familiarity -which is the common LISPer claim-. There exist LISPers -as
Paul Graham- working all his life with LISP and still claiming that
prefix notation is _not_ good for math and any future lisp may include
infix math -however, he plans syntatic macros which i disagree-.
Mathematicians and scientists know prefix notation for many many
decades ago and nobody (repeat: nobody) uses, specially in complex
math. It is not a matter of tradition because news operators are
defined in an infix way, e.g. product in novel non-commutative geometry
is defined infix: f \star g.
The infix position splits the structure into two clear zones doing easy
the matching of patterns. The prefix position needs of more abstraction
(double pattern matching) => more difficult to read.
[a + b] --> [a] {{+}} [b]
+
/ \
a b
(+ a b) --> {{+}} [a b] --> {{+}} [[a] [b]]
/\
+ /\
a b see [1]
This is not different from serif vs. sans-serif. Serif fonts need of
more abstraction for matching pattern therein that are more difficult
to read in paper that their cousins.
Also the prefix notation is less optimal from a formal point of view.
Because topological properties the same infix notation can need of many
more parentheses in prefix way. Prefix operators do not split
adequately the space.
Compare CanonML and LISP for a very common formal structure in science
(thermodynamics, quantum mechanics, electromagnetism, ecology, chemical
kinetics...):
CanonML: [[a b OVER a c] EQUALS d b]
LISP:
would be (equals (over a b a c) d b) but is ambiguous, what is the
numerator? a? (a b)? (a b a)? Therein you need extra parentheses
(equals (over (a b) (a c)) (d b))
but now you got wrong semantics because prefix position of two a and
the d, therein you need some kind of quote
(equals (over '(a b) '(a c)) '(d b))
is
(equals (over (quote (a b)) (quote (a c))) (quote (d b)))
The same formula in LISP needs 16 brackets (parentheses) and just 4
(square brackets) in CanonML. Notice that no precedence, conventions or
special asumptions are used in CanonML, the LISP structure needs of
400% more brackets.
Of course, in CanonML you can define higher-level syntaxes using
conventions. For instance, if a group of people agrees [2] on using =
as input for EQUALS concept and / for OVER then you can write [[a b / a
c] = d b]
If your discourse is that of usual arithmetic, and you want to follow
arithmetic predence rules you can define a higher level syntax. In this
case, default CanonML still gains over typical syntaxes because [a b /
a c] is more concise than usual arithmetic (a b) / (a c), but take [[m
/ 2] = w]. You can define [m / 2 = w] at _higher-level_ if desire [2].
Even you can forget the brackets and rely on indentation if you like
that
[PYTHON-LIKE-SYNTAX
Your indented code without brackets here [3]
]
However, those higher-level syntaxes are based in conventions and
asumptions and will be used just by subset of people who agree on those
conventions. Any enough complex symbolic language does not use
mathematical asumptions of most programming languages.
Another advantage of infix notation is on presentation. Precisely the
problem of MathML has been an incorrect -and limited- presentational
structure (very close to Mathematica boxes) doing very difficult
integration in browsers rendering engines. There is plans to correct
this on MathML 3 but not sure how many deprecated code the WG members
will provide.
LISP (plus 2 3) has the wrong structure for presentation and something
like
<apply><plus/><cn>2</cn><cn>3</cn></apply>
***cannot*** be rendered by the HTML/CSS engine in browsers. None
browser supports c-MathML.
-----
[1] I am ignoring now the NIL on S-expr, which would implicate a new
level of abstraction for the LISP form. But that level of abstraction
is related to a lists-cons debate and i am limiting here the comparison
to prefix-infix syntax.
[2] However, _nobody_ is forced to follow symbolic conventions and can
invent their own ones. CL uses = when Python uses ==; ASCIIMath uses //
when TeX uses /. Think on languages using != vs. /= vs <>; etc.
For more static and limited fields of discourse, you can use more
restricted syntaxes, doing use of conventions and asumptions like
predecence. E.g. if your ambit of discourse is that where = means and
only measn EQUALS use it. In chemistry = can mean not EQUALS, for
instance SO_4^=. When people type chemistry using ASCIIMath, the equal
is converted to <mo>=</mo> when would be <mi>=</mi>. This is because,
ASCIIMath is using conventions does not apply to chemistry.
[3] Whereas this can work for certain algorithms in a typical PL usage,
the Python syntax is not so concise for encoding complex datumets. SLiP
(Python) is more concise than SXML (Scheme), but CanonML is more
concise still than SLiP.
Juan R. schrieb:
> The infix position splits the structure into two clear zones doing easy
> the matching of patterns. The prefix position needs of more abstraction
> (double pattern matching) => more difficult to read.
>
> [a + b] --> [a] {{+}} [b]
>
> +
> / \
> a b
>
> (+ a b) --> {{+}} [a b] --> {{+}} [[a] [b]]
>
> /\
> + /\
> a b see [1]
The code tree of C's a + b
is the same as Lisps (+ a b). Both times we get
+
/ \
a b
But if you give more args then Lisp is easier:
a + b + c has this representation:
+
/ \
a +
/ \
b c
In Lisp (+ a b c) has this:
+
/ | \
a b c
> CanonML: [[a b OVER a c] EQUALS d b]
>
> LISP:
>
> would be (equals (over a b a c) d b) but is ambiguous, what is the
> numerator? a? (a b)? (a b a)? Therein you need extra parentheses
>
> (equals (over (a b) (a c)) (d b))
>
> but now you got wrong semantics because prefix position of two a and
> the d, therein you need some kind of quote
>
> (equals (over '(a b) '(a c)) '(d b))
>
> is
>
> (equals (over (quote (a b)) (quote (a c))) (quote (d b)))
If you really think that infix is the better notation, then noone stops
you from using infix in Lisp. I don't know what you guys are up to.
You can use infix in Lisp. What are you arguing about?
Andr�
--
André Thieme ha escrito:
> Juan R. schrieb:
>
> > The infix position splits the structure into two clear zones doing easy
> > the matching of patterns. The prefix position needs of more abstraction
> > (double pattern matching) => more difficult to read.
> >
> > [a + b] --> [a] {{+}} [b]
> >
> > +
> > / \
> > a b
> >
> > (+ a b) --> {{+}} [a b] --> {{+}} [[a] [b]]
> >
> > /\
> > + /\
> > a b see [1]
>
> The code tree of C's a + b
> is the same as Lisps (+ a b). Both times we get
>
> +
> / \
> a b
>
> But if you give more args then Lisp is easier:
No, it is not, reason that _all_ mathematicians write (a + b + c) and
_all_ chemists write (A --> B --> C) instead LISP prefix notation. The
LISP form is confusing.
> a + b + c has this representation:
>
> +
> / \
> a +
> / \
> b c
>
> In Lisp (+ a b c) has this:
> +
> / | \
> a b c
Forgotting now the cons underlying structure (is not that you wrote), i
would claim that from a mathematical point of view this representation
is confusing and hiddes the binary nature of the operation. At least a
mathematician writting (a + b + c) knows that is writting a syntatic
convention for an underlying sequence of binary computations. The
*mathematical* tree taking (a + (b + c)) *is*
+
/ \
a +
/ \
b c
>From a chemical point of view the (--> A B C) is confusing because the
temporal ordering of the --> symbol is wrong. Therein chemists write [A
--> B --> C] in chemical kinetics. The '-->' correspond to certain
region in the hypersurface (PES) and localization is 'infix'. Also
physicists writting [e + e] in particle physics are not following some
historical convention (as some lisper said me) but that (+ e e) has the
wrong orientation in a spacetime diagram. The '+' corresponds to
quantum correlations between the electrons localized 'infix'.
> > CanonML: [[a b OVER a c] EQUALS d b]
> >
> > LISP:
> >
> > would be (equals (over a b a c) d b) but is ambiguous, what is the
> > numerator? a? (a b)? (a b a)? Therein you need extra parentheses
> >
> > (equals (over (a b) (a c)) (d b))
> >
> > but now you got wrong semantics because prefix position of two a and
> > the d, therein you need some kind of quote
> >
> > (equals (over '(a b) '(a c)) '(d b))
> >
> > is
> >
> > (equals (over (quote (a b)) (quote (a c))) (quote (d b)))
>
> If you really think that infix is the better notation,
Me? Take a look round you and check the popularity of prefix. Look
people does in math, science, enginnering, almost any programming
language...
I can understand that prefix is a credo in LISP (as postfix is in Forth
comunity) but i cannot understand is the ignoring of evidence and the
tendency to try to convince others to use something almost nobody want
to use.
I am not trying to convince some LISPer to change the chip; as i am not
trying to convince Britannics to drive by the right side of the road;
as i am not trying to convince some religion fundamentalist that their
creation theory is crazy.
I simply am introducing data on the debate:
In infix you can save even 400% of parentheses.
Any a priori advantage from processing prefix forms is lost in layout
processing -LISP was not designed for layout-.
Experience processing large SGML documents proves that call-by-key data
desing is more appropiate than nested structures of calls-by-position
(LISP desing).
At Arc community was recognized that (f . x) is limited even for
elementary tasks and was argued someting as (annotation f . x) would be
more appropiate for some tasks.
Part of problem of lack of standard format for attributes in LISP
(against XML or Python) is because the prefix notation is limited.
The typical CL form (tag attributes data) is syntatically violating the
underlying data structure, because the attributes are _not_ data of the
tag; therein that XML structure is <tag {attributes}>data</tag> and the
Python is tag(attributes): data and TeX is \tag[attributes]{data}...
Etc, etc, etc.
Moreover, you are failing to notice that prefix notation is a special
case from infix one (when prearguments zone is empty {}). I can define
the LISP (plus 2 3) as special case in a generic infix notation, but
you cannot define the CanonML [2 PLUS 3] as special case of LISP
because (2 plus 3) is plain wrong.
> then noone stops
> you from using infix in Lisp.
Not so easy! Difficulties are main reason any (repeat: any) attempt to
popularize an infix LISP has failed during decades since LISP was
created (and there was a lot of them. including copying Algol-like
syntax). Reason also i disagree with Graham proposal for next LISP and
believe he will fail there as others before him.
LISP _is_ prefix, that you call "using infix in lisp" is just a
syntatic cosmetics do not working except for elementary stuff. Writting
#I(a + b) when the underlying data structure is (+ a b) do not help me
much, specially in complex tasks. Moreover, using a syntatic cosmetics
does not solve any of the problems i listed above with LISP prefix way.
Juan R. schrieb:
> Andr� Thieme ha escrito:
>
>> Juan R. schrieb:
>> The code tree of C's a + b
>> is the same as Lisps (+ a b). Both times we get
>>
>> +
>> / \
>> a b
>>
>> But if you give more args then Lisp is easier:
>
> No, it is not, reason that _all_ mathematicians write (a + b + c) and
> _all_ chemists write (A --> B --> C) instead LISP prefix notation. The
> LISP form is confusing.
Easier in the tree. Maybe not easier for people whose brains are already
specialized on infix.
So chemists will use an infix package, good.
>> a + b + c has this representation:
>>
>> +
>> / \
>> a +
>> / \
>> b c
>>
>> In Lisp (+ a b c) has this:
>> +
>> / | \
>> a b c
>
> Forgotting now the cons underlying structure (is not that you wrote), i
> would claim that from a mathematical point of view this representation
> is confusing and hiddes the binary nature of the operation. At least a
> mathematician writting (a + b + c) knows that is writting a syntatic
> convention for an underlying sequence of binary computations. The
> *mathematical* tree taking (a + (b + c)) *is*
>
> +
> / \
> a +
> / \
> b c
What underlying cons structure?
C:
set_color(255, 255, 255);
Lisp:
(set-color 255 255 255)
For both the tree is:
color
/ | \
/ | \
255 255 255
Same goes for
C:
add(a, b, c)
or Lisp:
(+ a b c)
Imagine a tree Editor instead of a plain text editor.
When I start it I am confronted with an empty bubble.
bubble
I enter "defun<space>" and three new bubbles 1-3 open, cursor [c] is set
to bubble 1.
defun
/ | \
/ | \
[c]
I enter "foo<space>" and cursor goes to bubble 2.
defun
/ | \
/ | \
foo [c]
I enter "nil<space>" and cursor goes to bubble 3.
defun
/ | \
/ | \
foo nil [c]
Here I enter my first form, say "+<space>" and a new bubble appears
defun
/ | \
/ | \
foo nil +
|
[c]
I enter "1<space>" - a new buble appears:
defun
/ | \
/ | \
foo nil +
/ \
1 [c]
Enter "2<space>", new bubble:
defun
/ | \
/ | \
foo nil +
/ | \
/ | \
1 2 [c]
Now "3)<enter>" and a "waiting..." appears:
defun
/ | \
/ | \ waiting for your descision, master.. *blink*
foo nil +
/ | \
/ | \
1 2 3
If I know type in ")<enter>" I get a new empty bubble to put code in.
If I press "(<enter>" my tree gets changed:
defun
/ | \
/ | \
foo nil progn
/ \
/ \
/ [c]
+
/ | \
/ | \
1 2 3
The "(" and ")" are not part of the program itself. They are directives
to my system to open/close/move bubbles.
>>From a chemical point of view the (--> A B C) is confusing because the
> temporal ordering of the --> symbol is wrong. Therein chemists write [A
> --> B --> C] in chemical kinetics.
I believe you. This might be wonderful for chemists. I am sure there are
chemists using Lisp with a prefix package.
But I also believe that it is a matter of training. Take a 6 year old
boy/girl and confront him/her his/her life with mostly prefix syntax.
He/She would probably master it and like it.
> Me? Take a look round you and check the popularity of prefix. Look
> people does in math, science, enginnering, almost any programming
> language...
I see that prefix is used very much. Looking at same random C code I see
several calls. Most infix uses are for basic math, setting values and
boolean expressions. I also find a some postfix operators.
When using a functional coding style setting operations are not used as
often anymore.
> I can understand that prefix is a credo in LISP (as postfix is in Forth
> comunity) but i cannot understand is the ignoring of evidence and the
> tendency to try to convince others to use something almost nobody want
> to use.
Having prefix as default might really be one of the many reasons why
Lisp is not very popular.
> I simply am introducing data on the debate:
>
> In infix you can save even 400% of parentheses.
Yes, there are such cases, and for some its probably even more.
I personally have used many parens long time before I knew Lisp, just
to make code a bit clearer for me. So in my case I would probably stay
a bit under your savings.
Andr�
--
In article <············@registered.motzarella.org>,
Andr� Thieme <······························@justmail.de> wrote:
> Juan R. schrieb:
> >>From a chemical point of view the (--> A B C) is confusing because the
> > temporal ordering of the --> symbol is wrong. Therein chemists write [A
> > --> B --> C] in chemical kinetics.
>
> I believe you. This might be wonderful for chemists. I am sure there are
> chemists using Lisp with a prefix package.
The temporal ordering of infix operators also does not cleanly read
left->right. For example:
x <- y*z^3 (from S+ and R)
The assignment operator on the left happens last, and the power
operator on the right is calculated first.
The order of events that occur in a sentence in a natural language
can also violate a simple left->right order.
"Before driving your car, buckle your safety belt."
But, computer languages are not primarily notation for expressing
concepts between people, but notation for expressing instructions to
a computer system. In python such a chemical equation would be
something like.
B = process1(A)
C = process2(B)
Or if you wanted to compress it:
C = process2(process1(A))
With trivial rearrangement:
(setq C (process2 (process1 A)))
I find arguments about the lack of infix to be overrated, because
the bulk of my programs involve function calls.
And the possibility that lisp is not the best tool for some tasks,
does not mean that it is not a very good tool for other tasks.
> Andr�
> --
André Thieme ha escrito:
> Easier in the tree. Maybe not easier for people whose brains are already
> specialized on infix.
> So chemists will use an infix package, good.
No they do will not use in the end. As already said any infix Lisp
attempt fails except for simplests tasks. Writting #I(a + b) _but_
thinking in (+ a b) is still poor than thinking and writting (+ a b).
There exists a rumour saying that working with an infix package (or
developing one) is one of requirements for a newbie to become a LISP
hacker. Once mastered the infix package is forgotten because generating
more problems than benefits.
> What underlying cons structure?
> or Lisp:
> (+ a b c)
Already wrote about this!
> Imagine a tree Editor instead of a plain text editor.
This kind of argument is 'foolish'.
"XML is verbose because obligate to you to type full end tags"
Common reply: "Imagine a XML editor..."
"LISP contains many parentheses"
Common reply: "Imagine a LISP editor..."
"Python spaces and indentation conventions can break code"
Common reply: "Imagine a Python editor..."
"String theory is not scientific"
Common reply: "Imagine an acelerator of the size of the galaxy..."
> The "(" and ")" are not part of the program itself. They are directives
> to my system to open/close/move bubbles.
Are part of the syntax, are not?
> But I also believe that it is a matter of training. Take a 6 year old
> boy/girl and confront him/her his/her life with mostly prefix syntax.
> He/She would probably master it and like it.
Typical (but plain wrong) reply from LISP community! Other would also
believe that binary code is not so difficult and it is all a matter of
training. What about a course on "binary for childs?"
101010101000010011000110001101001
100110000011011000110100010001011
100000110001100001110000000111010
Question is that readability is mainly related to _perception_ not to
familiarity. A serif font is not more readable than a sans serif one
because most of newspapers use (ugly) Times New Roman by default.
Anyone believing that taking 6 year old boys and confronting them with
Arial font printed books will not change readability rules for
typography may be a bit 'out'.
As already explained 6 or 7 times, far from trying to convince people
to use something they wannot not use i ***will leave*** people to
_choose_ infix, prefix, or postfix, or mixed!
> > Me? Take a look round you and check the popularity of prefix. Look
> > people does in math, science, enginnering, almost any programming
> > language...
>
> I see that prefix is used very much. Looking at same random C code I see
> several calls. Most infix uses are for basic math, setting values and
> boolean expressions. I also find a some postfix operators.
> When using a functional coding style setting operations are not used as
> often anymore.
If you want to distort reality in such one way, i cannot not help more.
If you think that prefix is okay and prefix is elsewhere except for
basic math, setting values, and boolean expressions, then congrats.
I have an eye on the world. As a scientist, i fit theory to
experimental data not inverse. Whereas i wait that a core of LISP
community never aknowledge limitations of the prefix syntax of LISP and
never change, i see with optimism to famous LISPers as Paul Graham
recognizing in public that prefix maths sucks and that next LISP (Arc)
will adress this point:
"There are two possible problems with prefix notation: that it is
unfamiliar to programmers, and that it is not dense enough. The
conventional wisdom in the Lisp world is that the first problem is the
real one. I'm not so sure."
"A more serious problem is the diffuseness of prefix notation."
"Sometimes infix syntax is easier to read. This is especially true for
math expressions. I've used Lisp my whole programming life and I still
don't find prefix math expressions natural."
However, i believe that he will fail because taking a look to the long
history of 'infix' LISPs.
After some research i think that S-expr are both the main strenght and
weakness of LISP. It is a pity that from some modification of S-expr we
could obtain someting really good but seeing that LISP community is
unable to change... I decided to begin such a kind of project.
[http://www.pault.com/xmlalternatives.html]
Just note the ranking for a modification of S-expr, without 400% of
extra parentheses, without forcing prefix, without forcing parens,
using square brackets... and compare with popularity of very old
projects based in LISP or Scheme: SXML, LML, Scribe, Skribe, Latte...
and other attempts as DSSSL (abandoned), HOP, Water (dead?), Franz, ...
Nobody would worry if LISP and Scheme continue next tendency:
[http://www.tiobe.com/tpci.htm]
"Juan R." <··············@canonicalscience.com> writes:
> I have an eye on the world. As a scientist, i fit theory to
> experimental data not inverse. Whereas i wait that a core of LISP
> community never aknowledge limitations of the prefix syntax of LISP and
> never change,
Sorry, I must have been blind. What limitation exactly do you observe
in lisp prefix notation for mathematical formula?
Let's consider a small formula. Use your favorite editor (even an
equation editor), and try to enter this formula with matematical
notation:
i
n a
Σ ---------
i=0 i+1
(1+2 )
and they try to enter this equivalent formula in lisp notation:
(sum (i 0 n) (/ (expt a i)
(+ 1 (expt 2 (+ i 1)))))
You're saying lisp notation is limited.
What mathematical formula can't you write in lisp?
What mathematical formula takes less input gestures in any editor than
the equivalent lisp formula?
> [...]
> "A more serious problem is the diffuseness of prefix notation."
> [...]
I don't see infix notation improve much the compacity of mathematical
formulas. A C programmer would write:
sum(i, 0, n, pow(a, i) / (1 + pow(2, i+1)));
Compared to the compact mathematical notation, I see it "as" big as
the lisp notation.
I'm still convinced that the "editor" is the solution. That is, IDE
tools working above the source bytes.
In HAL/S, apparently, one can write formulas in pure infix notation,
(as well as in multiline exponents/indices notation), and the lister
can print these formula in multiline exponent/indices notation.
By the same token, an IDE could parse sexps (or infix) code, and when
it sees mathematical operators, it could overlay a bitmap displaying
the formula in mathematical notation. The IDE could also include an
"equation editor" to directly edit the mathematical formulas. (I'm
would probably NOT use it, finding after 30+ years of editing of
various kind of text or GUI stuff that text editors are the most
efficient).
There's a SF dream. In Asimov's Foundation, the histomathematicians
use a room with an interactive equation editing "black-boad". I
assume it would look as smooth a user interface as Minority Report's
one. We don't have that yet, because you need some level of AI to
implement it properly.
Have a look at this state of the art user interface:
http://video.google.com/videoplay?docid=-409028730194183047&q=video+user+interface+3D
Well, I don't see any real work done during this 7mn session. Some
juggling, perhaps, but no work. I'm afraid manipulating an equation
editor feels the same.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pour moi, la grande question n'a jamais été: «Qui suis-je? Où vais-je?»
comme l'a formulé si adroitement notre ami Pascal, mais plutôt:
«Comment vais-je m'en tirer?» -- Jean Yanne
Pascal Bourguignon wrote:
>
> Sorry, I must have been blind. What limitation exactly do you observe
> in lisp prefix notation for mathematical formula?
>
I think the quadratic formula is hairy in prefix. Compare:
(define (quadratic-formula a b c)
(cons
(/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a))
(/ (- (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a))))
To something like:
function quadratic_formula(a, b, c) {
return [(-b + sqrt(b*b - 4*a*c))/(2*a), (-b - sqrt(b*b -
4*a*c))/(2*a)]
}
Even with a paren-smart editor, the Scheme one took much longer to
write, and I had to double check it for correctness. Maybe that's just
my limitation (or my editor's), but the infix one was easy.
Here's Dybvig's version:
(define quadratic-formula
(lambda (a b c)
(let ((minusb (- 0 b))
(radical (sqrt (- (* b b) (* 4 (* a c)))))
(divisor (* 2 a)))
(let ((root1 (/ (+ minusb radical) divisor))
(root2 (/ (- minusb radical) divisor)))
(cons root1 root2)))))
Cheers,
-Scott
·······@gmail.com writes:
> Pascal Bourguignon wrote:
>>
>> Sorry, I must have been blind. What limitation exactly do you observe
>> in lisp prefix notation for mathematical formula?
>>
>
> I think the quadratic formula is hairy in prefix. Compare:
>
> (define (quadratic-formula a b c)
> (cons
> (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a))
> (/ (- (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a))))
>
> To something like:
>
> function quadratic_formula(a, b, c) {
> return [(-b + sqrt(b*b - 4*a*c))/(2*a), (-b - sqrt(b*b -
> 4*a*c))/(2*a)]
> }
They are to be compared to (imagine a bitmap instead of this
approximating "unicode-art"):
______ ______
-b + √b²-4ac -b - √b²-4ac
------------ , ------------
2a 2a
My second argument is that they're both as big and extravagant
compared to the mathematical notation. I don't see the point of a 10%
increase when we're still 90% afar from the "ideal", and losing at the
same time the advantages sexps bring for metaprogramming.
(My first argument is that sexps are not limited in anyway: you can
write any mathematical formula with sexps, even more than in any other
programming language, given the code=data aspect that allows us to
implement declarative formulas and new operators seamlessly).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.
Pascal Bourguignon wrote:
>
> They are to be compared to (imagine a bitmap instead of this
> approximating "unicode-art"):
>
> ______ ______
> -b + √b²-4ac -b - √b²-4ac
> ------------ , ------------
> 2a 2a
>
I don't think fully rendered mathematical notation is so ideal for me
anymore. I've gotten to where I hand-write a bastardization of C with
superscripts for exponents:
(-b + sqrt(b² - 4*a*c))/(2*a)
I even draw the multiplications with six pointed stars instead of a
tiny x or dot. I might use a subscript in some cases, but it would be
a[i] for series in many cases. (How did you get the superscript? I
had to cut and paste yours. I can get the radical with fn-option-v on
my Mac.)
I only dive into a text book for a small piece on occasion, and it
takes me a bit to get comfortable again with:
S = abc
is actually:
S = a*b*c
>
> (My first argument is that sexps are not limited in anyway: you can
> write any mathematical formula with sexps, even more than in any other
> programming language, given the code=data aspect that allows us to
> implement declarative formulas and new operators seamlessly).
>
No argument there other than that the person you're responding to
probably meant "limited" in a different sense.
Operator precedence gives a lot of brevity in some cases, and it's
arguably worth the cost of remembering that * and / parse more tightly
than + and -. You could do it with an infix-parsing macro, but it
would have to be a clever reader macro or something to be able to leave
the spaces out.
Cheers,
-Scott
·······@gmail.com wrote:
> Pascal Bourguignon wrote:
>> They are to be compared to (imagine a bitmap instead of this
>> approximating "unicode-art"):
>>
>> ______ ______
>> -b + √b²-4ac -b - √b²-4ac
>> ------------ , ------------
>> 2a 2a
>>
>
> I don't think fully rendered mathematical notation is so ideal for me
> anymore. I've gotten to where I hand-write a bastardization of C with
> superscripts for exponents:
>
> (-b + sqrt(b² - 4*a*c))/(2*a)
>
Thats because you have never probably never had to express and equation like
Riemann Tensor
http://mathworld.wolfram.com/RiemannTensor.html
Wade
Wade Humeniuk wrote:
> ·······@gmail.com wrote:
> >
> > I don't think fully rendered mathematical notation is so ideal for me
> > anymore. I've gotten to where I hand-write a bastardization of C with
> > superscripts for exponents:
> >
> > (-b + sqrt(b² - 4*a*c))/(2*a)
> >
>
> Thats because you have never probably never had to express and equation like
> Riemann Tensor
>
> http://mathworld.wolfram.com/RiemannTensor.html
>
You're right in that. I've never made use of complicated tensor
notation, and I don't understand them very well, but don't dismiss me
too quickly. I have a bachelor's in mathematics, and I write
scientific applications for a living, so I'm not just a CS wheenie...
The reason I prefer the C-like notation is that I'll have to translate
anything I solve into code to use it, and I spend more time in my
editor than I do at the white board. The few holdovers (like
superscripts for exponents) is because that notation sucks in C/Python
etc... I will give the Lispers credit in that sucks no worse than
anything else for them.
Cheers,
-Scott
Pascal Bourguignon wrote:
> (My first argument is that sexps are not limited in anyway: you can
> write any mathematical formula with sexps, even more than in any other
> programming language, given the code=data aspect that allows us to
> implement declarative formulas and new operators seamlessly).
Can you give an example of a mathematical formula that can only be written
in prefix and not in infix or postfix?
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Pascal Bourguignon wrote:
>> (My first argument is that sexps are not limited in anyway: you can
>> write any mathematical formula with sexps, even more than in any other
>> programming language, given the code=data aspect that allows us to
>> implement declarative formulas and new operators seamlessly).
>
> Can you give an example of a mathematical formula that can only be written
> in prefix and not in infix or postfix?
It's Juan who said sexps were limited. So it's up to him to show a
mathematical formula that cannot be written as a sexp.
"Juan R." <··············@canonicalscience.com> writes:
> I have an eye on the world. As a scientist, i fit theory to
> experimental data not inverse. Whereas i wait that a core of LISP
> community never aknowledge limitations of the prefix syntax of LISP and
> never change,
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
Pascal Bourguignon wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Pascal Bourguignon wrote:
>>> (My first argument is that sexps are not limited in anyway: you can
>>> write any mathematical formula with sexps, even more than in any other
>>> programming language, given the code=data aspect that allows us to
>>> implement declarative formulas and new operators seamlessly).
>>
>> Can you give an example of a mathematical formula that can only be
>> written in prefix and not in infix or postfix?
>
> It's Juan who said sexps were limited. So it's up to him to show a
> mathematical formula that cannot be written as a sexp.
I'll quote you again:
"you can write any mathematical formula with sexps, even more than in any
other programming language"
I'm asking you to substantiate that.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Pascal Bourguignon wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>> Pascal Bourguignon wrote:
>>>> (My first argument is that sexps are not limited in anyway: you can
>>>> write any mathematical formula with sexps, even more than in any other
>>>> programming language, given the code=data aspect that allows us to
>>>> implement declarative formulas and new operators seamlessly).
>>> Can you give an example of a mathematical formula that can only be
>>> written in prefix and not in infix or postfix?
>> It's Juan who said sexps were limited. So it's up to him to show a
>> mathematical formula that cannot be written as a sexp.
>
> I'll quote you again:
>
> "you can write any mathematical formula with sexps, even more than in any
> other programming language"
>
> I'm asking you to substantiate that.
>
(setf |Axoim of Choice| '(with (C a (collection-of-non-empty-subsets))
(there-exists (function f) such-that
(for-each set S in C f(S) is in C))))
Wade
Wade Humeniuk wrote:
> Jon Harrop wrote:
>> "you can write any mathematical formula with sexps, even more than in any
>> other programming language"
>>
>> I'm asking you to substantiate that.
>
> (setf |Axoim of Choice| '(with (C a (collection-of-non-empty-subsets))
> (there-exists (function f) such-that
> (for-each set S in C f(S) is in C))))
My point is that s-exprs can be translated into object hierarchies, variant
types or other forms that are exactly equivalent.
Here's an OCaml equivalent:
let axiom_of_choice =
`_with[`C[`a; `collection_of_non_empty_subsets];
`there_exists[`func `f; `such_that;
`for_each[`set; `S; `_in; `C; `f[`S]; `is; `_in; `C]]];;
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Pascal Bourguignon wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>> Pascal Bourguignon wrote:
>>>> (My first argument is that sexps are not limited in anyway: you can
>>>> write any mathematical formula with sexps, even more than in any other
>>>> programming language, given the code=data aspect that allows us to
>>>> implement declarative formulas and new operators seamlessly).
>>>
>>> Can you give an example of a mathematical formula that can only be
>>> written in prefix and not in infix or postfix?
>>
>> It's Juan who said sexps were limited. So it's up to him to show a
>> mathematical formula that cannot be written as a sexp.
>
> I'll quote you again:
>
> "you can write any mathematical formula with sexps, even more than in any
> other programming language"
>
> I'm asking you to substantiate that.
Is it the "any mathematical formula" that you're contesting, or the
"more than in any other programming language"?
For the former, I hope it's obvious. For the later, here is an example:
Try to write this in C:
(quote (and (= y (+ (* 4 x) 3))
(= y (+ (* 3 x) -1))))
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
·······@gmail.com schrieb:
> Pascal Bourguignon wrote:
>> Sorry, I must have been blind. What limitation exactly do you observe
>> in lisp prefix notation for mathematical formula?
>>
>
> I think the quadratic formula is hairy in prefix. Compare:
>
> (define (quadratic-formula a b c)
> (cons
> (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a))
> (/ (- (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a))))
>
> To something like:
>
> function quadratic_formula(a, b, c) {
> return [(-b + sqrt(b*b - 4*a*c))/(2*a), (-b - sqrt(b*b -
> 4*a*c))/(2*a)]
> }
Or in Lisp:
(defun quadratic-formula (a b c)
(cons [(-b + √(b² - 4ac))/2a]
[(-b - √(b² - 4ac))/2a]))
André
--
From: Markus Triska
Subject: Re: merits of Lisp vs Python
Date:
Message-ID: <87wt4qpi6r.fsf@gmx.at>
Pascal Bourguignon <···@informatimago.com> writes:
>
> Let's consider a small formula. Use your favorite editor (even an
> equation editor), and try to enter this formula with matematical
> notation:
>
> i
> n a
> Σ ---------
> i=0 i+1
> (1+2 )
> (sum (i 0 n) (/ (expt a i) (+ 1 (expt 2 (+ i 1)))))
> sum(i, 0, n, pow(a, i) / (1 + pow(2, i+1)));
With J, a successor of APL ("Iverson notation"):
+/(a^i.>:n)%1+2^>:i.>:n
All the best,
Markus Triska
Pascal Bourguignon wrote:
> What mathematical formula takes less input gestures in any editor than
> the equivalent lisp formula?
Almost all. Here are some trivial examples:
Maths OCaml Lisp
a+b a+b (+ a b)
f(x) f x (f x)
2*a+b 2*a+b (* 2 (+ a b))
Lisp is very verbose.
> I don't see infix notation improve much the compacity of mathematical
> formulas. A C programmer would write:
>
>
> sum(i, 0, n, pow(a, i) / (1 + pow(2, i+1)));
If "sum" is a C function then that isn't valid C because "i" would be
evaluated before the call to sum. They would have to write a loop over an
ossified type:
double accu=0;
for (i=0; i<=n; ++i)
accu += pow(a, i) / (1 + pow(2, i+1));
return accu;
> Compared to the compact mathematical notation, I see it "as" big as
> the lisp notation.
You've chosen a silly example that uses as many prefix operators as infix in
C. Not only that, neither your Lisp nor your C code work.
Consider another example:
a/3 x^2 + b/2 x + c
(+ (* (/ a 3) (* x x)) (* (/ b 2) x) c)
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Pascal Bourguignon wrote:
>> What mathematical formula takes less input gestures in any editor than
>> the equivalent lisp formula?
>
> Almost all. Here are some trivial examples:
>
> Maths OCaml Lisp
> a+b a+b (+ a b)
> f(x) f x (f x)
> 2*a+b 2*a+b (* 2 (+ a b))
>
> Lisp is very verbose.
So why are you hanging out on comp.lang.lisp?
Bill Atkins wrote:
> So why are you hanging out on comp.lang.lisp?
Surely the question is: why aren't you guys reading outside Lisp?
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Bill Atkins wrote:
>> So why are you hanging out on comp.lang.lisp?
>
> Surely the question is: why aren't you guys reading outside Lisp?
But of course we are. Most of us have explored lots of other
languages before deciding on Lisp.
Jon Harrop <···@ffconsultancy.com> writes:
> Pascal Bourguignon wrote:
>> What mathematical formula takes less input gestures in any editor than
>> the equivalent lisp formula?
>
> Almost all. Here are some trivial examples:
>
> Maths OCaml Lisp
> a+b a+b (+ a b)
> f(x) f x (f x)
> 2*a+b 2*a+b (* 2 (+ a b))
Yep. That's where the superiority of lisp notation is glaring.
2*a+b is generally understood by the compilers as: (+ (* 2 a) b)
but obviously human programmer are not as good as precise parsing and
sometime understand (* 2(+ a b)) instead.
In Lisp, there's no ambiguity.
And if you reject lisp for a+b, well good for you, there are alot of
languages where a+b can be written in 3 characters.
> [...]
> Consider another example:
>
> a/3 x^2 + b/2 x + c
>
> (+ (* (/ a 3) (* x x)) (* (/ b 2) x) c)
(+ (* 1/3 a x x) (* 1/2 b x) c)
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Pascal Bourguignon wrote:
>>> What mathematical formula takes less input gestures in any editor than
>>> the equivalent lisp formula?
>>
>> Almost all. Here are some trivial examples:
>>
>> Maths OCaml Lisp
>> a+b a+b (+ a b)
>> f(x) f x (f x)
>> 2*a+b 2*a+b (* 2 (+ a b))
>
> Yep. That's where the superiority of lisp notation is glaring.
>
> 2*a+b is generally understood by the compilers as: (+ (* 2 a) b)
> but obviously human programmer are not as good as precise parsing and
> sometime understand (* 2(+ a b)) instead.
Virtually no programmers will misunderstand 1+2*3.
> In Lisp, there's no ambiguity.
You are mistaking precedence for ambiguity.
> And if you reject lisp for a+b, well good for you, there are alot of
> languages where a+b can be written in 3 characters.
I was merely providing trivial counter-examples to your incorrect assertion.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Pascal Bourguignon wrote:
> > Jon Harrop <···@ffconsultancy.com> writes:
> >> Pascal Bourguignon wrote:
> >>> What mathematical formula takes less input gestures in any editor than
> >>> the equivalent lisp formula?
> >>
> >> Almost all. Here are some trivial examples:
> >>
> >> Maths OCaml Lisp
> >> a+b a+b (+ a b)
> >> f(x) f x (f x)
> >> 2*a+b 2*a+b (* 2 (+ a b))
> >
> > Yep. That's where the superiority of lisp notation is glaring.
> >
> > 2*a+b is generally understood by the compilers as: (+ (* 2 a) b)
> > but obviously human programmer are not as good as precise parsing and
> > sometime understand (* 2(+ a b)) instead.
>
> Virtually no programmers will misunderstand 1+2*3.
LOL. Do you have any idea how embarrassing this is for your
position???
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Pascal Bourguignon wrote:
>> > Jon Harrop <···@ffconsultancy.com> writes:
>> >> Pascal Bourguignon wrote:
>> >>> What mathematical formula takes less input gestures in any editor
>> >>> than the equivalent lisp formula?
>> >>
>> >> Almost all. Here are some trivial examples:
>> >>
>> >> Maths OCaml Lisp
>> >> a+b a+b (+ a b)
>> >> f(x) f x (f x)
>> >> 2*a+b 2*a+b (* 2 (+ a b))
>> >
>> > Yep. That's where the superiority of lisp notation is glaring.
>> >
>> > 2*a+b is generally understood by the compilers as: (+ (* 2 a) b)
>> > but obviously human programmer are not as good as precise parsing and
>> > sometime understand (* 2(+ a b)) instead.
>>
>> Virtually no programmers will misunderstand 1+2*3.
>
> LOL. Do you have any idea how embarrassing this is for your
> position???
I didn't misunderstand 1+2*3.
So it really backs up what I was saying (and what someone else said in the
context of the quadratic solutions), that Lisp notation is very error-prone
for mathematics. That isn't surprising given how verbose it is (contrary to
Pascals incorrect assertion).
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> jayessay wrote:
> > Jon Harrop <···@ffconsultancy.com> writes:
> >> Pascal Bourguignon wrote:
> >> > Jon Harrop <···@ffconsultancy.com> writes:
> >> >> Pascal Bourguignon wrote:
> >> >>> What mathematical formula takes less input gestures in any editor
> >> >>> than the equivalent lisp formula?
> >> >>
> >> >> Almost all. Here are some trivial examples:
> >> >>
> >> >> Maths OCaml Lisp
> >> >> a+b a+b (+ a b)
> >> >> f(x) f x (f x)
> >> >> 2*a+b 2*a+b (* 2 (+ a b))
> >> >
> >> > Yep. That's where the superiority of lisp notation is glaring.
> >> >
> >> > 2*a+b is generally understood by the compilers as: (+ (* 2 a) b)
> >> > but obviously human programmer are not as good as precise parsing and
> >> > sometime understand (* 2(+ a b)) instead.
> >>
> >> Virtually no programmers will misunderstand 1+2*3.
> >
> > LOL. Do you have any idea how embarrassing this is for your
> > position???
>
> I didn't misunderstand 1+2*3.
Nice try, but it was you who miss defined its meaning up there and you
didn't even bother to try to claim it was "just a typo".
> So it really backs up what I was saying (and what someone else said in the
LOL.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> Nice try, but it was you who miss defined its meaning up there and you
> didn't even bother to try to claim it was "just a typo".
It wasn't a typo. My Lisp was wrong.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> jayessay wrote:
> > Nice try, but it was you who miss defined its meaning up there and you
> > didn't even bother to try to claim it was "just a typo".
>
> It wasn't a typo. My Lisp was wrong.
Exactly. You attempted to remove the precedence based notation from
the equation 2*a+b. In doing so you misunderstood the meaning of the
precedence and evaluated the multiplication before the addition. So
the final expression was incorrect. If you make mistakes like that and
you're an advocate of precedence then what chance to the rest of us
have ;)
BTW I'm mystified why anyone cares about the length of algebraic
expressions in code. I doubt 10% of my code is algebraic expressions,
they don't really come up that often.
On 2006-12-20, Rob Thorpe <·······@realworldtech.com> wrote:
> Jon Harrop wrote:
>> jayessay wrote:
>> > Nice try, but it was you who miss defined its meaning up
>> > there and you didn't even bother to try to claim it was
>> > "just a typo".
>>
>> It wasn't a typo. My Lisp was wrong.
>
> Exactly. You attempted to remove the precedence based notation
> from the equation 2*a+b. In doing so you misunderstood the
> meaning of the precedence and evaluated the multiplication
> before the addition. So the final expression was incorrect.
> If you make mistakes like that and you're an advocate of
> precedence then what chance to the rest of us have ;)
I don't see why youwon't admit the possibility that he
misunderstood the prefix notation. That seems a much more likely
explanation, considering the simplicity of the infix, and his
actual insistence that that's indeed what happened.
It's still amusingly ironic from the perspective of someone
totally comfortable with infix notation, but that total comfort
shouldn't be taken for granted or projected onto others.
--
Neil Cerutti
I pulled away from the side of the road, glanced at my mother-in-law and
headed over the embankment. --Insurance Claim Blooper
Neil Cerutti wrote:
> On 2006-12-20, Rob Thorpe <·······@realworldtech.com> wrote:
> > Jon Harrop wrote:
> >> jayessay wrote:
> >> > Nice try, but it was you who miss defined its meaning up
> >> > there and you didn't even bother to try to claim it was
> >> > "just a typo".
> >>
> >> It wasn't a typo. My Lisp was wrong.
> >
> > Exactly. You attempted to remove the precedence based notation
> > from the equation 2*a+b. In doing so you misunderstood the
> > meaning of the precedence and evaluated the multiplication
> > before the addition. So the final expression was incorrect.
> > If you make mistakes like that and you're an advocate of
> > precedence then what chance to the rest of us have ;)
>
> I don't see why youwon't admit the possibility that he
> misunderstood the prefix notation. That seems a much more likely
> explanation,
Well I'll certainly admit the possibility. But, since Jon gave the
example in the first place I assumed that he took an equation in a form
he was familar with, such as in OCaml and then translated it into Lisp.
I don't know how he did it though. If he did it the other way around
and made a mistake translating into Lisp notation then that could be an
argument against Lisp notation.
> considering the simplicity of the infix,
? ;)
> and his
> actual insistence that that's indeed what happened.
>
> It's still amusingly ironic from the perspective of someone
> totally comfortable with infix notation, but that total comfort
> shouldn't be taken for granted or projected onto others.
Yes.
I think what it says more than anything is that there are always
problems in translating things, and especially translating them by
hand.
One point no-one has laboured is that in many languages you can't
practically write long expressions like:-
(a + b/c)*d*e
Because you have to check regularly for error conditions. You can in a
language with bignums.
Rob Thorpe wrote:
> Neil Cerutti wrote:
>> I don't see why youwon't admit the possibility that he
>> misunderstood the prefix notation. That seems a much more likely
>> explanation,
>
> Well I'll certainly admit the possibility. But, since Jon gave the
> example in the first place I assumed that he took an equation in a form
> he was familar with, such as in OCaml and then translated it into Lisp.
I did it in the order that I wrote it: I took the maths 2*a+b and translated
it into the C/C++/Java/C#/OCaml 2*a+b and then into the Lisp but got the
Lisp wrong.
> I don't know how he did it though. If he did it the other way around
> and made a mistake translating into Lisp notation then that could be an
> argument against Lisp notation.
Exactly. I could pretend it was a cunning joke about how hard it is to write
infix notation but it was an honest mistake that backs up what I said:
people are used to 1+2*3 and not (+ 1 (* 2 3)). I think that's right. ;-)
>> It's still amusingly ironic from the perspective of someone
>> totally comfortable with infix notation, but that total comfort
>> shouldn't be taken for granted or projected onto others.
>
> Yes.
> I think what it says more than anything is that there are always
> problems in translating things, and especially translating them by
> hand.
Do you agree that people think in infix because they've used it since they
were kids? If so, then you agree that we must translate into the prefix for
conventionally infix operators? So we're likely to make more mistakes when
prefix is imposed upon us. That was my original point.
> One point no-one has laboured is that in many languages you can't
> practically write long expressions like:-
> (a + b/c)*d*e
> Because you have to check regularly for error conditions. You can in a
> language with bignums.
I don't think that's true. Look at my ray tracer: there aren't any error
conditions to check for.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Rob Thorpe wrote:
> > Neil Cerutti wrote:
> >> I don't see why youwon't admit the possibility that he
> >> misunderstood the prefix notation. That seems a much more likely
> >> explanation,
> >
> > Well I'll certainly admit the possibility. But, since Jon gave the
> > example in the first place I assumed that he took an equation in a form
> > he was familar with, such as in OCaml and then translated it into Lisp.
>
> I did it in the order that I wrote it: I took the maths 2*a+b and translated
> it into the C/C++/Java/C#/OCaml 2*a+b and then into the Lisp but got the
> Lisp wrong.
>
> > I don't know how he did it though. If he did it the other way around
> > and made a mistake translating into Lisp notation then that could be an
> > argument against Lisp notation.
>
> Exactly. I could pretend it was a cunning joke about how hard it is to write
> infix notation but it was an honest mistake that backs up what I said:
> people are used to 1+2*3 and not (+ 1 (* 2 3)). I think that's right. ;-)
But surely you evaluated 2*a+b wrongly to create the lisp version?
> >> It's still amusingly ironic from the perspective of someone
> >> totally comfortable with infix notation, but that total comfort
> >> shouldn't be taken for granted or projected onto others.
> >
> > Yes.
> > I think what it says more than anything is that there are always
> > problems in translating things, and especially translating them by
> > hand.
>
> Do you agree that people think in infix because they've used it since they
> were kids?
When I was a kid we used infix notation, but it was not the same as
that used in computer programming languages. All the
maths-teachers/mathematicians I've met use notation in different ways.
No-one really agrees on many common meanings, it's really computer
programmers who have invented most of the common meanings.
It's not a system that should be immitated by computer programming,
especially since the meanings of equations in computer programming are
normally quite different.
> If so, then you agree that we must translate into the prefix for
> conventionally infix operators? So we're likely to make more mistakes when
> prefix is imposed upon us. That was my original point.
When thinking about mathematics I think about the operations that need
doing and the variables that need operating on. Then I translate these
ideas into whatever notation I happen to be writing it in.
> > One point no-one has laboured is that in many languages you can't
> > practically write long expressions like:-
> > (a + b/c)*d*e
> > Because you have to check regularly for error conditions. You can in a
> > language with bignums.
>
> I don't think that's true. Look at my ray tracer: there aren't any error
> conditions to check for.
Your ray-tracer is a special case. It takes very little input and
generates a large peice of output. Most programs take much more input.
As I'm sure you know, if you're writing a program that uses fixnums
and that takes those fixnums from external sources then you have to do
a lot of checking (and quite a lot with bignums too). Sometimes it's
best to modularise the checking and separate it from the rest of the
code. If this is the case then you may find a situation where you can
write fairly long equations without having to break them up.
Rob Thorpe ha escrito:
> All the
> maths-teachers/mathematicians I've met use notation in different ways.
> No-one really agrees on many common meanings, it's really computer
> programmers who have invented most of the common meanings.
>
Math: 2 + 3
PL: 2 + 3 add 2 to 3 2+3 [2 + 3] 2.plus(3) (+ 2 3) 2 plus
(3) <plus 2 3 /> 2 3 + ...
Rob Thorpe wrote:
>> Exactly. I could pretend it was a cunning joke about how hard it is to
>> write infix notation but it was an honest mistake that backs up what I
>> said: people are used to 1+2*3 and not (+ 1 (* 2 3)). I think that's
>> right. ;-)
>
> But surely you evaluated 2*a+b wrongly to create the lisp version?
If that we're true I'd have gotten one of the others wrong as well: only my
Lisp was wrong.
>> Do you agree that people think in infix because they've used it since
>> they were kids?
>
> When I was a kid we used infix notation, but it was not the same as
> that used in computer programming languages.
It was pretty similar though: \times instead of * and \divide instead of /.
> All the maths-teachers/mathematicians I've met use notation in different
> ways.
I've never come across Lisp notation outside Lisp and Scheme.
> No-one really agrees on many common meanings, it's really computer
> programmers who have invented most of the common meanings.
Certainly for more complicated topics. But 1+2*3 means the same thing in C,
C++, Java, C#, Matlab, Mathematica, OCaml, SML, Haskell, Python, ... but
not Lisp.
> It's not a system that should be immitated by computer programming,
> especially since the meanings of equations in computer programming are
> normally quite different.
I'm not so sure. I'm much happier writing mathematical expressions in
Mathematica rather than OCaml or Lisp because it is closer to conventional
syntax:
a x^2 + b x + c
instead of:
a *. x ** 2. +. b *. x +. c
(+ (* a x x) (* b x) c)
>> If so, then you agree that we must translate into the prefix for
>> conventionally infix operators? So we're likely to make more mistakes
>> when prefix is imposed upon us. That was my original point.
>
> When thinking about mathematics I think about the operations that need
> doing and the variables that need operating on. Then I translate these
> ideas into whatever notation I happen to be writing it in.
Surely there comes a point where brevity is important?
>> I don't think that's true. Look at my ray tracer: there aren't any error
>> conditions to check for.
>
> Your ray-tracer is a special case.
Every counterexample will be a special case. I think all of the example
programs from my book are also counter examples. Check them out:
http://www.ffconsultancy.com/products/ocaml_for_scientists/
> It takes very little input and generates a large peice of output.
Some of the example from my book read lots of input too.
> Most programs take much more input.
Why is the amount of input related to the amount of error checking within
mathematical expressions?
> As I'm sure you know, if you're writing a program that uses fixnums
> and that takes those fixnums from external sources then you have to do
> a lot of checking (and quite a lot with bignums too).
I've never used bignums in real programs (i.e. outside the implementation of
languages that require bignums) and I can't remember doing any error
checking on my fixnums.
> Sometimes it's
> best to modularise the checking and separate it from the rest of the
> code. If this is the case then you may find a situation where you can
> write fairly long equations without having to break them up.
Can you give an example of the kind of checking that you're referring?
Isn't any FFT a counter example as well? It inputs as much data as it
outputs...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Certainly for more complicated topics. But 1+2*3 means the same thing in C,
> C++, Java, C#, Matlab, Mathematica, OCaml, SML, Haskell, Python, ... but
> not Lisp.
Since the vast majority of the operators I use are not in the set +-/*,
it's unclear why their (supposed) unambiguity should be decisive. (It
means something different in APL.)
Each of those languages has far more operators and we've established
time and time again that almost no one knows their precedence, which is
why most folks use redundant parentheses and/or temp expressions.
And, the same is true of math.
Nevertheless, F# and OCaml are perfect languages and clearly superior
to lisp. The heathens who still like lisp in the face of that fact are
clearly too stupid to benefit from Harrop's genius. He should leave
them to wallow in their error. Please.
On 2006-12-20, Rob Thorpe <·······@realworldtech.com> wrote:
> Neil Cerutti wrote:
>> I don't see why youwon't admit the possibility that he
>> misunderstood the prefix notation. That seems a much more
>> likely explanation,
>
> Well I'll certainly admit the possibility. But, since Jon gave the
> example in the first place I assumed that he took an equation in a form
> he was familar with, such as in OCaml and then translated it into Lisp.
> I don't know how he did it though. If he did it the other way around
> and made a mistake translating into Lisp notation then that could be an
> argument against Lisp notation.
>
>> considering the simplicity of the infix,
>
> ? ;)
I meant the simplicity of that particular bit of infix, not infix
notation itself. ;)
--
Neil Cerutti
To succeed in the world it is not enough to be stupid, you must also be well-
mannered. --Voltaire
On 20 Dec 2006 17:24:38 +0100, Neil Cerutti <·······@yahoo.com> tried to confuse
everyone with this message:
>On 2006-12-20, Rob Thorpe <·······@realworldtech.com> wrote:
>> Jon Harrop wrote:
>>> jayessay wrote:
>>> > Nice try, but it was you who miss defined its meaning up
>>> > there and you didn't even bother to try to claim it was
>>> > "just a typo".
>>>
>>> It wasn't a typo. My Lisp was wrong.
>>
>> Exactly. You attempted to remove the precedence based notation
>> from the equation 2*a+b. In doing so you misunderstood the
>> meaning of the precedence and evaluated the multiplication
>> before the addition. So the final expression was incorrect.
>> If you make mistakes like that and you're an advocate of
>> precedence then what chance to the rest of us have ;)
>
>I don't see why youwon't admit the possibility that he
>misunderstood the prefix notation.
Yeah, a qualified mathematician who mixes up f(g(x)) and g(f(x)). Right. Very
likely.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Timofei Shatrov wrote:
> > I don't see why youwon't admit the possibility that he
> > misunderstood the prefix notation.
>
> Yeah, a qualified mathematician who mixes up f(g(x)) and g(f(x)). Right.
> Very likely.
Absolutely. We're talking about Lisp notation though, which is a long way
from conventional mathematical notation.
Not only is (+ (* 2 a) b) an abuse of conventionally binary infix operators,
it isn't even conventional prefix notation, which has the function outside
the brackets and comma separated arguments:
add(mul(2, a), b)
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop ha escrito:
> Absolutely. We're talking about Lisp notation though, which is a long way
> from conventional mathematical notation.
Mathematical notation was not designed for computation. Why do you use
* for products in OCaml? Usual mathematical practice is juxtaposition
but that is misleading for a computer.
> Not only is (+ (* 2 a) b) an abuse of conventionally binary infix operators,
Completely agree!
> it isn't even conventional prefix notation, which has the function outside
> the brackets and comma separated arguments:
>
> add(mul(2, a), b)
On what brach of mathematics? Elementary functional analysis? Math for
'average' scientists? I agree, but in fundamental mathematics and
metamatematics, I can see (f g), denoting application of symbol f on g.
Examples are lambda calculus and Curry logic.
In 'metamatematics' i also see mathematicians writting stuff as
\begin{quote}
Of course, the key element of our efforts in describing "objects",
their properties and relations, will be assertions, for example, the
commutative law in arithmetic: ((x+y)=(y+x)). In predicate languages,
assertions are called formulas (or, sometimes, well formed formulas -
wff-s, or sentences).
\end{quote}
Interestingly, it looks close to CanonML format [[x + y] = [y + x]].
Brackets are needed at a fundamental level of discourse, but can be
omitted at some less sophisticated level of discourse (e.g. math for
biologists).
This simplification on notation is usual in _any_ discipline; water is
denoted by H2O only at some introductory level. At fundamental
research, water is not more H2O.
Juan R. wrote:
> Jon Harrop ha escrito:
>> Absolutely. We're talking about Lisp notation though, which is a long way
>> from conventional mathematical notation.
>
> Mathematical notation was not designed for computation. Why do you use
> * for products in OCaml?
Indeed, but if "a b" meant "a*b" then how would you express "f x"
unambiguously? If "f[x]" then how do you represent application to a
one-element list literal (f[x] in OCaml) or array subscript (a[i] in
C/C++)?
And why isn't there a \times key?
> Usual mathematical practice is juxtaposition but that is misleading for a
> computer.
Not at all. CASs like Mathematica do it. I find it more natural when
programming lots of mathematical expressions. I have used this in my own
languages as well. I prefer:
a+b
a b
a^b
but many general-purpose languages (including OCaml) use ** for power and *
for multiplication. I'd probably reserve * for outer product...
>> it isn't even conventional prefix notation, which has the function
>> outside the brackets and comma separated arguments:
>>
>> add(mul(2, a), b)
>
> On what brach of mathematics?
I was thinking of other programming languages actually.
> Elementary functional analysis? Math for 'average' scientists?
Function applications were always written f(x) or g(a, b) as I recall (in
physics). Perhaps there were some exceptions. I think operators applied to
functions were often written F[f].
> I agree, but in fundamental mathematics and
> metamatematics, I can see (f g), denoting application of symbol f on g.
> Examples are lambda calculus and Curry logic.
True, but they are both branches of computer science. Was that notation used
before such times?
> This simplification on notation is usual in _any_ discipline; water is
> denoted by H2O only at some introductory level. At fundamental
> research, water is not more H2O.
I thought water was still H2O (subscript 2). What do you mean? H3O+
perhaps? ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop ha escrito:
> Juan R. wrote:
> > Jon Harrop ha escrito:
> >> Absolutely. We're talking about Lisp notation though, which is a long way
> >> from conventional mathematical notation.
> >
> > Mathematical notation was not designed for computation. Why do you use
> > * for products in OCaml?
>
> Indeed, but if "a b" meant "a*b" then how would you express "f x"
> unambiguously? If "f[x]" then how do you represent application to a
> one-element list literal (f[x] in OCaml) or array subscript (a[i] in
> C/C++)?
Yeah each language does asumptions about is more used and take
conventions. Something as convention f g for f(g) is very useful at
'applicative' languages.
> And why isn't there a \times key?
In my numeric keyboard it is *.
> > Usual mathematical practice is juxtaposition but that is misleading for a
> > computer.
>
> Not at all. CASs like Mathematica do it.
True but is not forced because * is equivalent. So far as i know
Mathematica is the only language doing that for times.
> I was thinking of other programming languages actually.
>
> > Elementary functional analysis? Math for 'average' scientists?
>
> Function applications were always written f(x) or g(a, b) as I recall (in
> physics). Perhaps there were some exceptions.
sin x is common alternative to sin(x).
> I think operators applied to
> functions were often written F[f].
Schrodinguer equation is a beatiful counterexample: H Phi = E Phi
> > I agree, but in fundamental mathematics and
> > metamatematics, I can see (f g), denoting application of symbol f on g.
> > Examples are lambda calculus and Curry logic.
>
> True, but they are both branches of computer science. Was that notation used
> before such times?
No, so far as i know are standard notation on those fields. However =
is infix.
(K x y) = x
> > This simplification on notation is usual in _any_ discipline; water is
> > denoted by H2O only at some introductory level. At fundamental
> > research, water is not more H2O.
>
> I thought water was still H2O (subscript 2). What do you mean? H3O+
> perhaps? ;-)
Any introductory textbooks of chemistry will you that 18 g water
consists of 6.22045 10^23 H2O molecules.
But that is a brutal simplification, and when you advance in chemical
sciences you modify the definition of water adding more and more
precisions:
- molecules on water are built up of different isotopes of hydrogen and
oxygen in various combinations.
- Different concentration of H3O+ and OH-, varying with temperature and
pressure.
- Different dinamical aggrupations guided by covalent bonding, hydrogen
bonding, van der Waals interactions, or electrostatic and spin-spin
interaction.
Etc, etc.
In fact, even it is not just true that HOH angle is fixed. and to a
more fundamental level electronic or nuclear state matters, therefore
molecule in electronic state A is not the same that in state B.
But even admiting that water is [H2O + OH- + H3O+ + D2O + ...] The
state of the art today include a heavy debate on if the own concept of
molecules has sense in a pure quantum mechanical formalism [1].
But "18 g water consists of 6.22045 10^23 H2O molecules" will be enough
at introductory level. Level you want achieve on a discipline matters
the simplifications.
This is not very different from taking [a OPERATOR-A [b OPERATOR-B c]]
as fundamental level but generating 2 + 3 * 4 for average users.
Using LISP for anyone is so stupid as using quantum mechanics for
computing trajectories of Boeings. Part of the art of a good scientist
is on knowing when to do approximations. LISPERs are obligated to work
with extra parentheses and other difficulties because limitations of
their formal system.
[1] See for example "What is a molecule?" on
[http://canonical-chemistry.chemblogs.org/archives/2006/10/20/chemistry-is-not-reduced-to-quantum-mechanic]
and references cited therein.
"Juan R." <··············@canonicalscience.com> writes:
> Jon Harrop ha escrito:
>> And why isn't there a \times key?
>
> In my numeric keyboard it is *.
In my emacs keyboard, there's C-x 8 . --> ·
and C-x 8 x --> ×
On the other hand, there's no "times" character per se in unicode:
Unicode characters with TIME in the name:
#x02062 8290 "INVISIBLE_TIMES"
#x02297 8855 ⊗ "CIRCLED_TIMES"
#x022A0 8864 ⊠ "SQUARED_TIMES"
#x022C7 8903 ⋇ "DIVISION_TIMES"
#x029D4 10708 ⧔ "TIMES_WITH_LEFT_HALF_BLACK"
#x029D5 10709 ⧕ "TIMES_WITH_RIGHT_HALF_BLACK"
#x02A02 10754 ⨂ "N-ARY_CIRCLED_TIMES_OPERATOR"
#x02A09 10761 ⨉ "N-ARY_TIMES_OPERATOR"
#x02A18 10776 ⨘ "INTEGRAL_WITH_TIMES_SIGN"
Unicode characters with MULTIPL in the name:
#x000D7 215 × "MULTIPLICATION_SIGN"
#x016EC 5868 ᛬ "RUNIC_MULTIPLE_PUNCTUATION"
#x0228D 8845 ⊍ "MULTISET_MULTIPLICATION"
#x02715 10005 ✕ "MULTIPLICATION_X"
#x02716 10006 ✖ "HEAVY_MULTIPLICATION_X"
#x02A30 10800 ⨰ "MULTIPLICATION_SIGN_WITH_DOT_ABOVE"
#x02A31 10801 ⨱ "MULTIPLICATION_SIGN_WITH_UNDERBAR"
#x02A34 10804 ⨴ "MULTIPLICATION_SIGN_IN_LEFT_HALF_CIRCLE"
#x02A35 10805 ⨵ "MULTIPLICATION_SIGN_IN_RIGHT_HALF_CIRCLE"
#x02A36 10806 ⨶ "CIRCLED_MULTIPLICATION_SIGN_WITH_CIRCUMFLEX_ACCENT"
#x02A37 10807 ⨷ "MULTIPLICATION_SIGN_IN_DOUBLE_CIRCLE"
#x02A3B 10811 ⨻ "MULTIPLICATION_SIGN_IN_TRIANGLE"
#x02AC1 10945 ⫁ "SUBSET_WITH_MULTIPLICATION_SIGN_BELOW"
#x02AC2 10946 ⫂ "SUPERSET_WITH_MULTIPLICATION_SIGN_BELOW"
Unicode characters with PRODUCT in the name:
#x0220F 8719 ∏ "N-ARY_PRODUCT"
#x02210 8720 ∐ "N-ARY_COPRODUCT"
#x02240 8768 ≀ "WREATH_PRODUCT"
#x022C9 8905 ⋉ "LEFT_NORMAL_FACTOR_SEMIDIRECT_PRODUCT"
#x022CA 8906 ⋊ "RIGHT_NORMAL_FACTOR_SEMIDIRECT_PRODUCT"
#x022CB 8907 ⋋ "LEFT_SEMIDIRECT_PRODUCT"
#x022CC 8908 ⋌ "RIGHT_SEMIDIRECT_PRODUCT"
#x029E2 10722 ⧢ "SHUFFLE_PRODUCT"
#x02A2F 10799 ⨯ "VECTOR_OR_CROSS_PRODUCT"
#x02A32 10802 ⨲ "SEMIDIRECT_PRODUCT_WITH_BOTTOM_CLOSED"
#x02A33 10803 ⨳ "SMASH_PRODUCT"
#x02A3C 10812 ⨼ "INTERIOR_PRODUCT"
#x02A3D 10813 ⨽ "RIGHTHAND_INTERIOR_PRODUCT"
#x02A3F 10815 ⨿ "AMALGAMATION_OR_COPRODUCT"
#x02A50 10832 ⩐ "CLOSED_UNION_WITH_SERIFS_AND_SMASH_PRODUCT"
You'd need a lot of keys...
> Using LISP for anyone is as stupid as using quantum mechanics for
> computing trajectories of Boeings.
But if we tried it, perhaps we could find a solution where the Boeings
can go thru towers without exploding?
--
__Pascal Bourguignon__ http://www.informatimago.com/
CONSUMER NOTICE: Because of the "uncertainty principle," it is
impossible for the consumer to simultaneously know both the precise
location and velocity of this product.
Pascal Bourguignon ha escrito:
> "Juan R." <··············@canonicalscience.com> writes:
> > Jon Harrop ha escrito:
> >> And why isn't there a \times key?
> >
> > In my numeric keyboard it is *.
>
> In my emacs keyboard, there's C-x 8 . --> ·
> and C-x 8 x --> ×
Wow! Also i can see a · over my <3> key. And the × or the • are not
so difficult pressing <Alt>
> Unicode characters with TIME in the name:
>
> #x02062 8290 "INVISIBLE_TIMES"
> #x02297 8855 ⊗ "CIRCLED_TIMES"
> #x022A0 8864 ⊠ "SQUARED_TIMES"
> #x022C7 8903 ⋇ "DIVISION_TIMES"
> #x029D4 10708 ⧔ "TIMES_WITH_LEFT_HALF_BLACK"
> #x029D5 10709 ⧕ "TIMES_WITH_RIGHT_HALF_BLACK"
> #x02A02 10754 ⨂ "N-ARY_CIRCLED_TIMES_OPERATOR"
> #x02A09 10761 ⨉ "N-ARY_TIMES_OPERATOR"
> #x02A18 10776 ⨘ "INTEGRAL_WITH_TIMES_SIGN"
>
> Unicode characters with MULTIPL in the name:
>
> #x000D7 215 × "MULTIPLICATION_SIGN"
> #x016EC 5868 ᛬ "RUNIC_MULTIPLE_PUNCTUATION"
> #x0228D 8845 ⊍ "MULTISET_MULTIPLICATION"
> #x02715 10005 ✕ "MULTIPLICATION_X"
> #x02716 10006 ✖ "HEAVY_MULTIPLICATION_X"
> #x02A30 10800 ⨰ "MULTIPLICATION_SIGN_WITH_DOT_ABOVE"
> #x02A31 10801 ⨱ "MULTIPLICATION_SIGN_WITH_UNDERBAR"
> #x02A34 10804 ⨴ "MULTIPLICATION_SIGN_IN_LEFT_HALF_CIRCLE"
> #x02A35 10805 ⨵ "MULTIPLICATION_SIGN_IN_RIGHT_HALF_CIRCLE"
> #x02A36 10806 ⨶ "CIRCLED_MULTIPLICATION_SIGN_WITH_CIRCUMFLEX_ACCENT"
> #x02A37 10807 ⨷ "MULTIPLICATION_SIGN_IN_DOUBLE_CIRCLE"
> #x02A3B 10811 ⨻ "MULTIPLICATION_SIGN_IN_TRIANGLE"
> #x02AC1 10945 ⫁ "SUBSET_WITH_MULTIPLICATION_SIGN_BELOW"
> #x02AC2 10946 ⫂ "SUPERSET_WITH_MULTIPLICATION_SIGN_BELOW"
>
> Unicode characters with PRODUCT in the name:
>
> #x0220F 8719 ∏ "N-ARY_PRODUCT"
> #x02210 8720 ∐ "N-ARY_COPRODUCT"
> #x02240 8768 ≀ "WREATH_PRODUCT"
> #x022C9 8905 ⋉ "LEFT_NORMAL_FACTOR_SEMIDIRECT_PRODUCT"
> #x022CA 8906 ⋊ "RIGHT_NORMAL_FACTOR_SEMIDIRECT_PRODUCT"
> #x022CB 8907 ⋋ "LEFT_SEMIDIRECT_PRODUCT"
> #x022CC 8908 ⋌ "RIGHT_SEMIDIRECT_PRODUCT"
> #x029E2 10722 ⧢ "SHUFFLE_PRODUCT"
> #x02A2F 10799 ⨯ "VECTOR_OR_CROSS_PRODUCT"
> #x02A32 10802 ⨲ "SEMIDIRECT_PRODUCT_WITH_BOTTOM_CLOSED"
> #x02A33 10803 ⨳ "SMASH_PRODUCT"
> #x02A3C 10812 ⨼ "INTERIOR_PRODUCT"
> #x02A3D 10813 ⨽ "RIGHTHAND_INTERIOR_PRODUCT"
> #x02A3F 10815 ⨿ "AMALGAMATION_OR_COPRODUCT"
> #x02A50 10832 ⩐ "CLOSED_UNION_WITH_SERIFS_AND_SMASH_PRODUCT"
>
This sharp product [1] will be also needed in a future :]
> You'd need a lot of keys...
How in chinese? Therein that general discourse languages, cannot be
based in characters, because same Unicode character can be used for
different stuff.
[a TIMES b] ---> [TOKEN a] [TOKEN #x02062] [TOKEN b]
This is default style but using a stylesheet your content [a TIMES b]
could be rendered other way e.g. using the "dot", you do not listed
above
[a TIMES b] ---> [TOKEN a] [TOKEN #x022C5] [TOKEN b]
For instance, modern LISP (* ...) are mixing binary product with n-ary
operator product. It is enough for computational uses of LISP but the
tendency in knowledge representation goes the other way.
>
> > Using LISP for anyone is as stupid as using quantum mechanics for
> > computing trajectories of Boeings.
>
> But if we tried it, perhaps we could find a solution where the Boeings
> can go thru towers without exploding?
>
Since that the QM model reduces to classical one in that limit, you are
obtaining the same replies using a more complex formalism with unneded
features, which is stupid. No quantum tunneling for Boeings!
Similar thoughts apply to LISP or Python. Both take a discourse and
both are good for _that_ discourse.
CanonML mimics the epistemological and ontological structure of
sciences. You got a continuum between most fundamental level to uper
ones. You select your level in function of your needs and skills.
[1] http://lists.w3.org/Archives/Public/www-math/2006Nov/0102.html
Juan R. wrote:
> Jon Harrop ha escrito:
>> Indeed, but if "a b" meant "a*b" then how would you express "f x"
>> unambiguously? If "f[x]" then how do you represent application to a
>> one-element list literal (f[x] in OCaml) or array subscript (a[i] in
>> C/C++)?
>
> Yeah each language does asumptions about is more used and take
> conventions. Something as convention f g for f(g) is very useful at
> 'applicative' languages.
F# provides operator overloading. Maybe we could overload "a b" to mean both
apply and multiply?
>> And why isn't there a \times key?
>
> In my numeric keyboard it is *.
That gives you a cross?
>> > Usual mathematical practice is juxtaposition but that is misleading for
>> > a computer.
>>
>> Not at all. CASs like Mathematica do it.
>
> True but is not forced because * is equivalent.
Yes. I'm not sure why they did that... anyway, my point was that "a b" can
mean multiply just as it means apply in ML.
> So far as i know Mathematica is the only language doing that for times.
I've done it in DSLs. I think it works well...
>> I was thinking of other programming languages actually.
>>
>> > Elementary functional analysis? Math for 'average' scientists?
>>
>> Function applications were always written f(x) or g(a, b) as I recall (in
>> physics). Perhaps there were some exceptions.
>
> sin x is common alternative to sin(x).
Good point.
>> I think operators applied to functions were often written F[f].
>
> Schrodinguer equation is a beatiful counterexample: H Phi = E Phi
I'd only write it like that if I had ^ above operators, otherwise I might
write H[?] = E ? in the absence of fancier typesetting.
> Using LISP for anyone is so stupid as using quantum mechanics for
> computing trajectories of Boeings. Part of the art of a good scientist
> is on knowing when to do approximations. LISPERs are obligated to work
> with extra parentheses and other difficulties because limitations of
> their formal system.
I couldn't agree more: good science is artful approximation.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop ha escrito:
> F# provides operator overloading. Maybe we could overload "a b" to mean both
> apply and multiply?
I personally dislike overloading but if F# uses maybe will become
popular. For your example eigenvalue equations would become ambiguous.
A Y = a Y
A Y = a * Y
> >> And why isn't there a \times key?
> >
> > In my numeric keyboard it is *.
>
> That gives you a cross?
No, sorry i misunderstood you. That character i call cross operator.
> > Schrodinguer equation is a beatiful counterexample: H Phi = E Phi
>
> I'd only write it like that if I had ^ above operators, otherwise I might
> write H[?] = E ? in the absence of fancier typesetting.
Traditionally QM notation was subindex op e.g. H_op. Probably because
typographical limitations for typesseting old literature.
After become the hats ^. \hat{H} but one lost a lot of time writting
all those hats and readability 'sucks' for dot derivatives of operators
and so on.
Now in modern literature i see two notations. One uses roman bold font
(probably because quantum operator <--> matrix relationhip), other
denotes operators as some curly caligraphic font.
I personally use bold roman font or nothing in context:
operator function ---> bold normal
superoperator operator ---> bold normal
Juan R. wrote:
> Jon Harrop ha escrito:
>> F# provides operator overloading. Maybe we could overload "a b" to mean
>> both apply and multiply?
>
> I personally dislike overloading but if F# uses maybe will become
> popular. For your example eigenvalue equations would become ambiguous.
>
> A Y = a Y
>
> A Y = a * Y
You get graphical type throwback of inferred types, so hovering the mouse
over the subexpressions will tell you their inferred types.
>> >> And why isn't there a \times key?
>> >
>> > In my numeric keyboard it is *.
>>
>> That gives you a cross?
>
> No, sorry i misunderstood you. That character i call cross operator.
Sure. I want a cross. :-)
>> > Schrodinguer equation is a beatiful counterexample: H Phi = E Phi
>>
>> I'd only write it like that if I had ^ above operators, otherwise I might
>> write H[?] = E ? in the absence of fancier typesetting.
>
> Traditionally QM notation was subindex op e.g. H_op. Probably because
> typographical limitations for typesseting old literature.
>
> After become the hats ^. \hat{H} but one lost a lot of time writting
> all those hats and readability 'sucks' for dot derivatives of operators
> and so on.
>
> Now in modern literature i see two notations. One uses roman bold font
> (probably because quantum operator <--> matrix relationhip), other
> denotes operators as some curly caligraphic font.
Yes. I wanted to use the curly "H" but couldn't find one that KDE can
render. Still, things seem to be improving... :-)
> I personally use bold roman font or nothing in context:
>
> operator function ---> bold normal
>
> superoperator operator ---> bold normal
Maybe Visual Studio could boldify higher-order functions in F#...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Neil Cerutti <·······@yahoo.com> writes:
> On 2006-12-20, Rob Thorpe <·······@realworldtech.com> wrote:
> > Jon Harrop wrote:
> >> jayessay wrote:
> >> > Nice try, but it was you who miss defined its meaning up
> >> > there and you didn't even bother to try to claim it was
> >> > "just a typo".
> >>
> >> It wasn't a typo. My Lisp was wrong.
> >
> > Exactly. You attempted to remove the precedence based notation
> > from the equation 2*a+b. In doing so you misunderstood the
> > meaning of the precedence and evaluated the multiplication
> > before the addition. So the final expression was incorrect.
> > If you make mistakes like that and you're an advocate of
> > precedence then what chance to the rest of us have ;)
>
> I don't see why youwon't admit the possibility that he
> misunderstood the prefix notation.
Because that makes him look even more silly than he already does?
Really, are you saying (and maybe he is tying to claim) that he
couldn't understand the fully qualified definition of what the
unqualified infix expression is idiomatically taken to be?
How on earth can anyone with any relevant experience in these matters
possibly think that
(* 2 (+ a b))
could indicate in any way that the 2 reaches into the nested (+ a b)
expression, and multiplies only the a and then somehow also then
indicates the b is added to this? I am even willing to believe that
writing the prefix is somehow "harder" to write for some folks, but it
really exceeds one's credulity to think someone could possibly get the
interpretation wrong in the presumed way. You have to really go out
of your way to get that wrong.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Jon Harrop <···@ffconsultancy.com> writes:
> Pascal Bourguignon wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>> Pascal Bourguignon wrote:
>>>> What mathematical formula takes less input gestures in any editor than
>>>> the equivalent lisp formula?
>>>
>>> Almost all. Here are some trivial examples:
>>>
>>> Maths OCaml Lisp
>>> a+b a+b (+ a b)
>>> f(x) f x (f x)
>>> 2*a+b 2*a+b (* 2 (+ a b))
>>
>> Yep. That's where the superiority of lisp notation is glaring.
>>
>> 2*a+b is generally understood by the compilers as: (+ (* 2 a) b)
>> but obviously human programmer are not as good as precise parsing and
>> sometime understand (* 2(+ a b)) instead.
>
> Virtually no programmers will misunderstand 1+2*3.
But practically, you DID.
> I was merely providing trivial counter-examples to your incorrect assertion.
Making a mistake in the process, thus prooving my point. Thanks.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
Pascal Bourguignon wrote:
>>>> Almost all. Here are some trivial examples:
>>>>
>>>> Maths OCaml Lisp
>>>> a+b a+b (+ a b)
>>>> f(x) f x (f x)
>>>> 2*a+b 2*a+b (* 2 (+ a b))
>>>
>>> Yep. That's where the superiority of lisp notation is glaring.
>>>
>>> 2*a+b is generally understood by the compilers as: (+ (* 2 a) b)
>>> but obviously human programmer are not as good as precise parsing and
>>> sometime understand (* 2(+ a b)) instead.
>>
>> Virtually no programmers will misunderstand 1+2*3.
>
> But practically, you DID.
No, I misunderstood (* 2 (+ a b)).
>> I was merely providing trivial counter-examples to your incorrect
>> assertion.
>
> Making a mistake in the process,
Yes.
> thus prooving my point.
No.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Pascal Bourguignon wrote:
> >>>> Almost all. Here are some trivial examples:
> >>>>
> >>>> Maths OCaml Lisp
> >>>> a+b a+b (+ a b)
> >>>> f(x) f x (f x)
> >>>> 2*a+b 2*a+b (* 2 (+ a b))
> >>>
> >>> Yep. That's where the superiority of lisp notation is glaring.
> >>>
> >>> 2*a+b is generally understood by the compilers as: (+ (* 2 a) b)
> >>> but obviously human programmer are not as good as precise parsing and
> >>> sometime understand (* 2(+ a b)) instead.
> >>
> >> Virtually no programmers will misunderstand 1+2*3.
> >
> > But practically, you DID.
>
> No, I misunderstood (* 2 (+ a b)).
FOFLMOL
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Pascal Bourguignon wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>> Pascal Bourguignon wrote:
>>> What mathematical formula takes less input gestures in any editor than
>>> the equivalent lisp formula?
>>
>> Almost all. Here are some trivial examples:
>>
>> Maths OCaml Lisp
>> a+b a+b (+ a b)
>> f(x) f x (f x)
>> 2*a+b 2*a+b (* 2 (+ a b))
>
> Yep. That's where the superiority of lisp notation is glaring.
>
> 2*a+b is generally understood by the compilers as: (+ (* 2 a) b)
> but obviously human programmer are not as good as precise parsing and
> sometime understand (* 2(+ a b)) instead.
Virtually no programmers will misunderstand 1+2*3.
> In Lisp, there's no ambiguity.
You are mistaking precedence for ambiguity.
> And if you reject lisp for a+b, well good for you, there are alot of
> languages where a+b can be written in 3 characters.
I was merely providing trivial counter-examples to your incorrect assertion.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Pascal Bourguignon wrote:
>> Jon Harrop <···@ffconsultancy.com> writes:
>>
>>> 2*a+b 2*a+b (* 2 (+ a b))
>>
>> Yep. That's where the superiority of lisp notation is glaring.
>>
>> 2*a+b is generally understood by the compilers as: (+ (* 2 a) b)
>> but obviously human programmer are not as good as precise parsing and
>> sometime understand (* 2(+ a b)) instead.
>
> Virtually no programmers will misunderstand 1+2*3.
You did, enough to write it in lisp as (* 2 (+ a b)) instead of (+ (* 2
a) b)...
I agree, though, that prefix notation is suboptimal for math; however,
it works for functions and infix math is available with macros, so how
does it really matter?
--
Robert Uhl <http://public.xdi.org/=ruhl>
I once did a dd if=bootdisk.img of=/dev/hda. Luckily, /dev/hda had
Windows 95 and a swap partition on it. /dev/hdb was where Linux lived.
Nothing important was lost. --PD
On Sun, 17 Dec 2006 19:22:04 +0100, Jon Harrop <···@ffconsultancy.com>
wrote:
> Consider another example:
>
> a/3 x^2 + b/2 x + c
>
> (+ (* (/ a 3) (* x x)) (* (/ b 2) x) c)
>
Using the infix package:
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/infix.cl
One can write:
INFIX 16 > '#I"(a/3)*x^^2 + (b/2)*x + c"
(+ (* (/ A 3) (EXPT X 2)) (* (/ B 2) X) C)
The #I"" surronds the formula. The ' is used so the code is not evaluated
at the command line.
Note that this is a reader macro so the the compiler would see the
expression below.
I sometimes use this macro instead of translating the formula by hand.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
>
> Using the infix package:
> http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/infix.cl
>
> One can write:
>
> INFIX 16 > '#I"(a/3)*x^^2 + (b/2)*x + c"
> (+ (* (/ A 3) (EXPT X 2)) (* (/ B 2) X) C)
>
Do you use the reader macro in your source, or just to translate and
cut and paste?
If it's in the source, does it handle other macros inside of the infix
macro? Can you put literal vectors inside of it? I don't know Common
Lisp, but I mean something like Scheme's #(1 2 3 4). I don't see any
reason it couldn't, so I'm actually kind of curious if they carried it
to the natural limit.
Cheers,
-Scott
On Mon, 18 Dec 2006 02:39:50 +0100, <·······@gmail.com> wrote:
>
> John Thingstad wrote:
>>
>> Using the infix package:
>> http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/infix.cl
>>
>> One can write:
>>
>> INFIX 16 > '#I"(a/3)*x^^2 + (b/2)*x + c"
>> (+ (* (/ A 3) (EXPT X 2)) (* (/ B 2) X) C)
>>
>
> Do you use the reader macro in your source, or just to translate and
> cut and paste?
>
Well as a reader macro it isn't exactly pretty.
Consider #I"one-two-3" does that mean variable (- one-two 3) or (- one two
3)?
Well the second. If you want the first #I(- one\-two 3) or #I"one\\-two".
I generally don't use it except to translate a series of complex formula
and I think it messes up the lisp code so I usually just translate.
> If it's in the source, does it handle other macros inside of the infix
> macro?
Yes. NB! ! gives a Lisp escape. (it does not mean not)
> Can you put literal vectors inside of it? I don't know Common
> Lisp, but I mean something like Scheme's #(1 2 3 4).
Yes. (same in CL)
consider:
CL-USER 11 > '#I(s=#(1 2 3),s[2])
(PROGN (SETQ S #(1 2 3)) (AREF S 2))
Not the prettiest code though. (should use setf)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jon Harrop schrieb:
> Consider another example:
>
> a/3 x^2 + b/2 x + c
>
> (+ (* (/ a 3) (* x x)) (* (/ b 2) x) c)
In Lisp you could write your example as you stated first.
But can you have math expressions in Python/C/F# like this:
[7x₆ + 9π³ - 6ˣ]
or
(if [√2 ≈ 1,41]
(print "Yay"))
?
André
--
Andr� Thieme wrote:
> Jon Harrop schrieb:
>
> > Consider another example:
> >
> > a/3 x^2 + b/2 x + c
> >
> > (+ (* (/ a 3) (* x x)) (* (/ b 2) x) c)
>
>
> In Lisp you could write your example as you stated first.
You mean if you change the syntax of the language? Yes.
> But can you have math expressions in Python/C/F# like this:
>
> [7x? + 9?� - 6?]
>
> or
>
> (if [?2 ? 1,41]
> (print "Yay"))
OCaml and F# yes. I don't know about the others.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop schrieb:
> André Thieme wrote:
>> Jon Harrop schrieb:
>>
>> > Consider another example:
>> >
>> > a/3 x^2 + b/2 x + c
>> >
>> > (+ (* (/ a 3) (* x x)) (* (/ b 2) x) c)
>>
>>
>> In Lisp you could write your example as you stated first.
>
> You mean if you change the syntax of the language? Yes.
Providing a reader macro that translates math expressions
between [ and ] into Lisp syntax as you stated it.
>> But can you have math expressions in Python/C/F# like this:
>>
>> [7x? + 9?³ - 6?]
>>
>> or
>>
>> (if [?2 ? 1,41]
>> (print "Yay"))
>
> OCaml and F# yes. I don't know about the others.
Did your newsreader display the unicode symbols?
So in OCaml you can do that? I personally am having problems
with it. In the interpreter I typed:
# 6²;;<enter>
and got:
Illegal character (\178)
And also:
# √2;;<enter>
changes the display to:
# ��2;;
Illegal character (\136)
André
--
Andr� Thieme wrote:
>> OCaml and F# yes. I don't know about the others.
>
> Did your newsreader display the unicode symbols?
>
> So in OCaml you can do that?
You'd have to write a macro reader, but yes. Emacs used to use ? but they've
reverted back to sqrt now.
> I personally am having problems
> with it. In the interpreter I typed:
>
> # 6�;;<enter>
>
> and got:
> Illegal character (\178)
>
> And also:
> # ?2;;<enter>
>
> changes the display to:
>
> # ??2;;
> Illegal character (\136)
F# probably supports the unicode characters directly but they haven't
defined which are infix symbols yet.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Andr� Thieme wrote:
>>> OCaml and F# yes. I don't know about the others.
>> Did your newsreader display the unicode symbols?
>>
>> So in OCaml you can do that?
>
> You'd have to write a macro reader, but yes. Emacs used to use ? but they've
> reverted back to sqrt now.
>
>> I personally am having problems
>> with it. In the interpreter I typed:
>>
>> # 6�;;<enter>
>>
>> and got:
>> Illegal character (\178)
>>
>> And also:
>> # ?2;;<enter>
>>
>> changes the display to:
>>
>> # ??2;;
>> Illegal character (\136)
>
> F# probably supports the unicode characters directly but they haven't
> defined which are infix symbols yet.
Why don't you change this yourself instead of waiting for the F#
designers to do this for you?
Ah, wait, no syntactic extensibility - damn...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Bourguignon ha escrito:
> "Juan R." <··············@canonicalscience.com> writes:
> > I have an eye on the world. As a scientist, i fit theory to
> > experimental data not inverse. Whereas i wait that a core of LISP
> > community never aknowledge limitations of the prefix syntax of LISP and
> > never change,
>
> Sorry, I must have been blind. What limitation exactly do you observe
> in lisp prefix notation for mathematical formula?
>
I would say limitations of prefix LISP notation as base for a formal
metalanguage (with programming language as a subset). Next some.
1] Readability of prefix is poor for mathematics. This is even
recognized by LISPer gurus as Graham, Norvig, etc. even when I am
rather confident they have not worked complex math in LISP they find
uncomfortable. It is not a matter of 'familiarity' as Graham explains.
The 99% of mathematicians, scientists, and enginneers would agree with
me. All of standard bibliography do not use prefix. I never see an
article on J. Math. Phys. J or a physics book on some University
library writing (= E (* m (^ c 2))) for Poincare-Einstein formula.
2] You can save parentheses. I wrote an example where you save a 400%
of parentheses. Someone replied me that he could think of other
examples saving more!
The prefix notation is not optimal because topological partition of
space. The infix way automatically defines two regions: before and
after the operator. The prefix way only defines one region. This
limitation of prefix notation does needed the introduction of extra
parentheses for disambiguating the list of parameters. But that is a
limitation of just prefix!
I already provided an example based in a very common formal construct
arising in several scientific disciplines. Infix [[]] (4 delimiters)
needs of LISP 16 delimiters (((((((()))))))). I see no rationale for
forcing people to write last one when first one is enough and –I
firmly believe– more elegant.
3] The formal properties of (operator arguments) are limited.
How do you write [operator attribute arguments] in LISP form? You
cannot without finding syntatic ambiguities therein that (annotation f
. x) was discussed as possible generalization of LISP for Arc (I doubt
that Graham want to modify LISP in this radical way after so many years
claiming that LISP is a kind of optimal formal structure :).
It is not so strange that still today there exists no-standard accepted
way to encode that in a LISP form. DSSSL uses :key; SXML uses @ list ;
GSXML uses @ naming...
4] How do you apply two operators to the same argument? LISP common way
is composition of functions
(bdit xxx) --> (bd (it xxx))
but that is incorrect because the data for bd is not (it xxx) but xxx
itself. GODDAG can do it because is based in directed trees.
<bd/ xxx /it>
bd it
\ /
\ /
xxx
LISP cannot because binary trees with prefix rationale
/\
/ \
bd /\
/ \
it /\
/ \
xxx NIL
incorrect formal structure!!
CanonML goes beyond GOODDAG because as in liminal language (approach
based in range algebra) you can apply more than two operators at once.
5] Non hierarchies.
How do you deal with non-hierarchies in a prefix formulation?
Take next LISP data structure
(H e e)
(F e e e e e e e e)
and obtain total number of es? LISP will generates 10 after summation
the number of elements of the corresponding CDR. The correct number is
8. Problem? LISP prefix cannot naturally deal with non-hierarchic
structures.
> Let's consider a small formula. Use your favorite editor (even an
> equation editor), and try to enter this formula with matematical
> notation:
>
> i
> n a
> Σ ---------
> i=0 i+1
> (1+2 )
>
> and they try to enter this equivalent formula in lisp notation:
>
> (sum (i 0 n) (/ (expt a i)
> (+ 1 (expt 2 (+ i 1)))))
>From a pure syntatical side, this formula is ambiguous one because (sum
...) looks like (function data) when (1 0 n) is not data but metadata
for "sum". Therein that mathematical notation carefully puts them at
bottom and top of the summation symbol and not to the right where data
is placed. This inherent ambiguity is one of problems of the
"all-prefix" approach.
Moreover, I would not do it in this way. Let me explain this a bit
because I think is part of the Python versus LISP debate could be
avoided when people think about.
People becoming from C, Java, Python, etc. often critizes LISP
parentheses because they think that
y = a + m * x
is always enough and parentheses are redundant.
Well, parentheses are needed at a fundamental level (as quantum
mechanics is for fundamental physics) for structuring the data. Once
this remarked, one can see abstraction layers can be defined for
specialized discourses based in conventions a community agree.
For usual arithmetic calculus, and if you only need that, you could
define precedence rules, taking conventions about meaning of symbols as
*, +, and, =. This is not very different to a Boeing enginneer using
classical mechanics, because in him/her field of interest, that is
enough and do not need of extra complexities of quantum field theory!
Therefore [y = a + m * x] IS correct for _some_ level of discourse, but
also are [y == a + m * x], or [y = a + m x] and other variants.
For instance, Python uses explicit * for products, but Mathematica
syntax assumes product for two adjacent tokens. Both syntaxes work for
some communities and specific problems. None of those syntaxes work for
others. E.g. when I wrote L ρ I do not mean product of L and ρ ,
therefore the Mathematica syntax convention do not apply to this kind
of discourse.
Therefore, I define [y EQUALS [a PLUS [m TIMES x] ]] at a rather
fundamental level *but* leeting people chossing/optimizing/adapting the
syntax to their specific needs.
Do you want always to use == for equality, + for plus and * for times?
Do it!
Do you want always to work with predefined precedence for symbols? Do
it!
Do you like an all-prefix? Do it!
LISP guru Peter Norvig is another who want to see infix math on next
LISP (Arc). He suggests that if a non-alphanumeric symbol appeared in
the first or second element of a list to be evaled, then the list is in
infix form; therefore (x = 3 + 4) is (= x (+ 3 4)).
I can say something about that. The first is that he is asumming stuff
will be valid only for a determined level of discourse. The second to
be noticed is that input syntax is ambiguous (in rigor it is mistaken).
Rewrite as "(a b c d e) and (b a (d c e))". At the last form, the
correct S-expr, both "b" and "d" are operators. At the left form, "a"
would be some operator and "d" would be data because the expression
looks like (function arguments).
The "infix" structure per se is both ambiguous and misleading. In fact,
it is not real infix, just a cosmetic macro looking as (once a
physicist said about string theory) "a very old woman with too much
lipstick".
And why? Because LISP emphasis on prefix. Call-by-key is better than
call-by-position desing.
I suspect this Arc attempt to introduce an infix cosmetics over an
underlying prefix structure will fail as dozens of previous approaches
did before. Exists a very large history for "infix" LISP attempts.
This kind of problem is not in CanonML.
It is interesting to remark now how often we work over a bunch of
simplifications, asumptions, and conventions.
For instance, you take the above mathematical formula and write "sum"
for denoting the operator. You are asumming stuff there. A more
mathematician author would encode like <OMS cd="arith1" name="sum"/>
reading like "symbol sum defined in arith1 content dictionary". I
prefer to use namespaces for that and would write [ARITH1:SUM ]
instead using attributes but the basic idea is the same.
Most of people (99%) would not need of this level of sophistication and
would not differentiate between several definitions for sum concept,
somewhat as they do not differentiate between several mathematical
definitions for plus, minus, sin, exp...
For that 99% you can do
[SUM ...] --> [ARITH1:SUM ...]
they can read, write and manipulate just [SUM ...] if all they need is
that. Unnecesary complexity may be hidden.
>
> You're saying lisp notation is limited.
> What mathematical formula can't you write in lisp?
>
> What mathematical formula takes less input gestures in any editor than
> the equivalent lisp formula?
Did not I reply this?
> > [...]
> > "A more serious problem is the diffuseness of prefix notation."
> > [...]
>
> I don't see infix notation improve much the compacity of mathematical
> formulas. A C programmer would write:
Ok, you do not see and I can live with that. Please note that above
quote is becoming from a famous LISP guru, not from a C programmer.
> I'm still convinced that the "editor" is the solution. That is, IDE
> tools working above the source bytes.
Editors are a big "big". They are so useful editing LISP forms as XML
editors are editing XML files. But I prefer direct optimization of
source.
On Mon, 18 Dec 2006 06:34:52 -0800, Juan R. wrote:
> 4] How do you apply two operators to the same argument? LISP common way
> is composition of functions
>
> (bdit xxx) --> (bd (it xxx))
>
> but that is incorrect because the data for bd is not (it xxx) but xxx
> itself.
Not sure what you mean, but:
(defmacro apply* (operators &rest arguments)
`(list
,@(loop :for operator :in operators
:collect `(apply ,operator ',arguments))))
(defun bd (x)
(format t "bd: ~A~%" x)
'return-value-from-bd)
(defun it (x)
(format t "it: ~A~%" x)
'return-value-from-it)
..then..
cl-user> (apply* ('bd 'it) 2)
bd: 2
it: 2
(return-value-from-bd return-value-from-it)
..?
--
Lars Rune Nøstdal
http://nostdal.org/
Lars Rune Nøstdal ha escrito:
> On Mon, 18 Dec 2006 06:34:52 -0800, Juan R. wrote:
>
> > 4] How do you apply two operators to the same argument? LISP common way
> > is composition of functions
> >
> > (bdit xxx) --> (bd (it xxx))
> >
> > but that is incorrect because the data for bd is not (it xxx) but xxx
> > itself.
>
> Not sure what you mean, but:
>
> (defmacro apply* (operators &rest arguments)
> `(list
> ,@(loop :for operator :in operators
> :collect `(apply ,operator ',arguments))))
>
>
> (defun bd (x)
> (format t "bd: ~A~%" x)
> 'return-value-from-bd)
>
>
> (defun it (x)
> (format t "it: ~A~%" x)
> 'return-value-from-it)
>
>
> ..then..
>
>
> cl-user> (apply* ('bd 'it) 2)
> bd: 2
> it: 2
> (return-value-from-bd return-value-from-it)
>
Yeah, you are looping. Also i could directly write
(bd xxx)
(it xxx)
and i am applying two operators to the same argument. But that is not i
did mean. I did mean the aciclic directed graph i wrote. Important data
structure can be represented in other language designs as GODDAG (also
in CanonML) but that you cannot unambiguously represent on LISP because
limitations of the prefix way (operator . arguments)
LISP is great, concise, very powerful, and formally elegant. Reasons i
have taken it as a base for further development, but avoiding the
limitations of prefix, binary trees, and maybe of the functional
approach.
It sound to me that part of the LISP community has taken too seriously
the myth that LISP forms are a kind of optimal maximum for data
representation believing (incorrectly) any other language tends to LISP
over time.
Fortunately, McCarthy agrees with me that LISP forms are limited and
can be improved, indicating me i am not so crazy.
"Juan R." <··············@canonicalscience.com> writes:
> Me? Take a look round you and check the popularity of prefix. Look
> people does in math, science, enginnering, almost any programming
> language...
Checks around the uni's science and engineering department...
Yup -- they're all using HP's line of RPN calculators.
Alain Picard ha escrito:
> "Juan R." <··············@canonicalscience.com> writes:
>
> > Me? Take a look round you and check the popularity of prefix. Look
> > people does in math, science, enginnering, almost any programming
> > language...
>
> Checks around the uni's science and engineering department...
> Yup -- they're all using HP's line of RPN calculators.
1) I already explained three or four times that both prefix and postfix
notations can be derived from an generic infix notation.
[a OPERATOR b]
|
|____ [{} OPERATOR b] --> (OPERATOR b)
|
|____ [a OPERATOR {}] --> {a OPERATOR} or � la Forth a
OPERATOR
No need to obligate to people to use one they wannot use. _Let_ people
choose they want use, instead trying to force they to embrace prefix
(or postfix) via inefficient marketing (prefix is very old :)
techniques and dubidous arguments.
2) Never seen one RPN on University less still in the Marine Sciences
Center here.
3) How many calculators follow HP? What is the ratio RPN/infix at HP
products? How many new calculators are RPN vs optional-to-user, versus
non RPN? It looks to me they are abandoning the RPN paradigm and
providing RPN only by backward compatibiltiy with users [*].
4) An important advantage of RPN (programmable) calculators is on
efficient memory management. With next generations of memory chips
still more calculators will ignore RPN.
[*] At least this was the history of the HP19. The 10 was RPN, the
sucessor 12 was RPN, the 19 was not RPN, then people using the old 12
ask for support and the next HP19(II) offered RPN as option (but
default was algebraic)
Andr� Thieme wrote:
> In Lisp (+ a b c) has this:
> +
> / | \
> a b c
That implies to me that the last element ("c" in this case) can be accessed
in O(1) time. Can it?
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Andr� Thieme wrote:
>> In Lisp (+ a b c) has this:
>> +
>> / | \
>> a b c
>
> That implies to me that the last element ("c" in this case) can be accessed
> in O(1) time. Can it?
Yes.
(defun nth (n list)
(loop
:with result = nil
:for i :from 0 :below call-arguments-limit
:for e = list :then (cdr e)
:when (= i n) :do (setf result e)
:finally (return result)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Jon Harrop <···@ffconsultancy.com> writes:
>
> > Andr� Thieme wrote:
> >> In Lisp (+ a b c) has this:
> >> +
> >> / | \
> >> a b c
> >
> > That implies to me that the last element ("c" in this case) can be accessed
> > in O(1) time. Can it?
>
> Yes.
>
> (defun nth (n list)
> (loop
> :with result = nil
> :for i :from 0 :below call-arguments-limit
> :for e = list :then (cdr e)
> :when (= i n) :do (setf result e)
> :finally (return result)))
Huh? Is this another one of your bad jokes (a la
http://groups.google.com/group/comp.lang.lisp/msg/1d85f2e1ec5f6e0b)?
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> Jon Harrop <···@ffconsultancy.com> writes:
>>
>> > Andr� Thieme wrote:
>> >> In Lisp (+ a b c) has this:
>> >> +
>> >> / | \
>> >> a b c
>> >
>> > That implies to me that the last element ("c" in this case) can be accessed
>> > in O(1) time. Can it?
>>
>> Yes.
>>
>> (defun nth (n list)
>> (loop
>> :with result = nil
>> :for i :from 0 :below call-arguments-limit
>> :for e = list :then (cdr e)
>> :when (= i n) :do (setf result e)
>> :finally (return result)))
>
> Huh? Is this another one of your bad jokes (a la
> http://groups.google.com/group/comp.lang.lisp/msg/1d85f2e1ec5f6e0b)?
No. This is an implementation of nth that is in O(1). It execution
time and space is strictly independant of the length of the list.
Seems to me you don't know what O(1) means...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> >> Jon Harrop <···@ffconsultancy.com> writes:
> >>
> >> > Andr� Thieme wrote:
> >> >> In Lisp (+ a b c) has this:
> >> >> +
> >> >> / | \
> >> >> a b c
> >> >
> >> > That implies to me that the last element ("c" in this case) can be
> >> > accessed
> >> > in O(1) time. Can it?
> >>
> >> Yes.
> >>
> >> (defun nth (n list)
> >> (loop
> >> :with result = nil
> >> :for i :from 0 :below call-arguments-limit
> >> :for e = list :then (cdr e)
> >> :when (= i n) :do (setf result e)
> >> :finally (return result)))
> >
> > Huh? Is this another one of your bad jokes (a la
> > http://groups.google.com/group/comp.lang.lisp/msg/1d85f2e1ec5f6e0b)?
>
> No. This is an implementation of nth that is in O(1).
No, it isn't. In fact, it is neither of those things.
> It execution
> time and space is strictly independant of the length of the list.
That is a stronger claim that being O(1). And it is also false.
> Seems to me you don't know what O(1) means...
Seems to me you're a pretentious fool.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <··············@thalassa.informatimago.com>,
>> > Pascal Bourguignon <···@informatimago.com> wrote:
>> >
>> >> Jon Harrop <···@ffconsultancy.com> writes:
>> >>
>> >> > Andr� Thieme wrote:
>> >> >> In Lisp (+ a b c) has this:
>> >> >> +
>> >> >> / | \
>> >> >> a b c
>> >> >
>> >> > That implies to me that the last element ("c" in this case) can be
>> >> > accessed
>> >> > in O(1) time. Can it?
>> >>
>> >> Yes.
>> >>
>> >> (defun nth (n list)
>> >> (loop
>> >> :with result = nil
>> >> :for i :from 0 :below call-arguments-limit
>> >> :for e = list :then (cdr e)
>> >> :when (= i n) :do (setf result e)
>> >> :finally (return result)))
>> >
>> > Huh? Is this another one of your bad jokes (a la
>> > http://groups.google.com/group/comp.lang.lisp/msg/1d85f2e1ec5f6e0b)?
>>
>> No. This is an implementation of nth that is in O(1).
>
> No, it isn't. In fact, it is neither of those things.
>
>> It execution
>> time and space is strictly independant of the length of the list.
>
> That is a stronger claim that being O(1). And it is also false.
>
>> Seems to me you don't know what O(1) means...
>
> Seems to me you're a pretentious fool.
First note that this NTH function is designed only to work on function calls:
> In Lisp (+ a b c) has this:
> +
> / | \
> a b c
so CALL-ARGUMENTS-LIMIT is effectively the maximum length of the lists
passed to this NTH function.
Now look at these timings:
C/USER1[148]> (defun nth-argument (n list)
(loop
:with result = nil
:for i :from 0 :below call-arguments-limit
:for e = list :then (cdr e)
:when (= i n) :do (setf result e)
:finally (return result)))
NTH-ARGUMENT
C/USER1[149]> (let* ((length 1)
(list (make-list length)))
(time (loop :repeat 1000 :do (nth-argument (1- length) list))))
Real time: 21.31973 sec.
Run time: 17.565098 sec.
Space: 4392 Bytes
NIL
C/USER1[150]> (let* ((length call-arguments-limit)
(list (make-list length)))
(time (loop :repeat 1000 :do (nth-argument (1- length) list))))
Real time: 20.745884 sec.
Run time: 15.620976 sec.
Space: 4392 Bytes
NIL
C/USER1[151]>
Seems to me it takes about the same time when the length of the list
is 1 or when it's call-arguments-limit. That's what we call O(1).
Ask a mathematician if you don't believe me.
So who's the fool now?
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >>
> >> > In article <··············@thalassa.informatimago.com>,
> >> > Pascal Bourguignon <···@informatimago.com> wrote:
> >> >
> >> >> Jon Harrop <···@ffconsultancy.com> writes:
> >> >>
> >> >> > Andr� Thieme wrote:
> >> >> >> In Lisp (+ a b c) has this:
> >> >> >> +
> >> >> >> / | \
> >> >> >> a b c
> >> >> >
> >> >> > That implies to me that the last element ("c" in this case) can be
> >> >> > accessed
> >> >> > in O(1) time. Can it?
> >> >>
> >> >> Yes.
> >> >>
> >> >> (defun nth (n list)
> >> >> (loop
> >> >> :with result = nil
> >> >> :for i :from 0 :below call-arguments-limit
> >> >> :for e = list :then (cdr e)
> >> >> :when (= i n) :do (setf result e)
> >> >> :finally (return result)))
> >> >
> >> > Huh? Is this another one of your bad jokes (a la
> >> > http://groups.google.com/group/comp.lang.lisp/msg/1d85f2e1ec5f6e0b)?
> >>
> >> No. This is an implementation of nth that is in O(1).
> >
> > No, it isn't. In fact, it is neither of those things.
> >
> >> It execution
> >> time and space is strictly independant of the length of the list.
> >
> > That is a stronger claim that being O(1). And it is also false.
> >
> >> Seems to me you don't know what O(1) means...
> >
> > Seems to me you're a pretentious fool.
>
>
> First note that this NTH function is designed only to work on function calls:
Now you tell us? In Lisp code is data, so just because a list starts
with + doesn't necessarily mean it's a function call.
> > In Lisp (+ a b c) has this:
> > +
> > / | \
> > a b c
>
> so CALL-ARGUMENTS-LIMIT is effectively the maximum length of the lists
> passed to this NTH function.
You betray an appalling lack of imagination. What if I wanted to write
something like this:
(defmacro with-honking-big-arglists ((func &rest arglist))
(if (> (length arglist) call-arguments-limit)
`(combine-results (,func ,@(loop for i from 0 to call-arguments-limit
collect (nth-argument i arglist)))
(,func ,@(loop for i from call-arguments-limit to
(* 2 call-arguments-limit)
collect (nth-argument i arglist)))
...
> Now look at these timings:
>
> C/USER1[148]> (defun nth-argument (n list)
> (loop
> :with result = nil
> :for i :from 0 :below call-arguments-limit
> :for e = list :then (cdr e)
> :when (= i n) :do (setf result e)
> :finally (return result)))
> NTH-ARGUMENT
> C/USER1[149]> (let* ((length 1)
> (list (make-list length)))
> (time (loop :repeat 1000 :do (nth-argument (1- length)
> list))))
> Real time: 21.31973 sec.
> Run time: 17.565098 sec.
> Space: 4392 Bytes
> NIL
> C/USER1[150]> (let* ((length call-arguments-limit)
> (list (make-list length)))
> (time (loop :repeat 1000 :do (nth-argument (1- length)
> list))))
> Real time: 20.745884 sec.
> Run time: 15.620976 sec.
> Space: 4392 Bytes
> NIL
> C/USER1[151]>
>
> Seems to me it takes about the same time when the length of the list
> is 1 or when it's call-arguments-limit. That's what we call O(1).
> Ask a mathematician if you don't believe me.
First, your claim was that he execution time is "strictly independent of
the length of the list." This is not true. Processing a long list
entails walking a long CDR chain, whereas processing a short list
entails repeatedly taking the CDR of NIL. These may or may not take the
same amount of time depending on the implementation.
Second, putting an (undocumented) upper bound on the size of the input
and performing dummy calculations so that all possible input sizes take
the worst-case time does mean that the algorithm is O(1). Big O
notation refers to ASYMPTOTIC behavior. The time it takes to compute
the answer on bounded-size inputs is irrelevant. Ask a mathematician if
you don't believe me.
Third, your algorithm is pedantic and stupid.
Last but not least, your algorithm is just flat-out incorrect:
? (defun nth-argument (n list)
(loop
:with result = nil
:for i :from 0 :below call-arguments-limit
:for e = list :then (cdr e)
:when (= i n) :do (setf result e)
:finally (return result)))
NTH-ARGUMENT
? (nth-argument 2 '(+ a b c))
(B C)
?
> So who's the fool now?
You tell me.
rg
Ron Garret <·········@flownet.com> writes:
> You betray an appalling lack of imagination. What if I wanted to write
> something like this:
I could as well have used (expt 2 32) as upper limit. (or (expt 2 64)
on a 64-bit processor). There cannot be proper lists longer than 2��
in an 32-bit address space.
> Second, putting an (undocumented) upper bound on the size of the input
> and performing dummy calculations so that all possible input sizes take
> the worst-case time does mean that the algorithm is O(1). Big O
> notation refers to ASYMPTOTIC behavior.
And what is the asymptote of a constant?
> The time it takes to compute the answer on bounded-size inputs is
> irrelevant. Ask a mathematician if you don't believe me.
>
> Third, your algorithm is pedantic and stupid.
>
> Last but not least, your algorithm is just flat-out incorrect:
>
> ? (defun nth-argument (n list)
> (loop
> :with result = nil
> :for i :from 0 :below call-arguments-limit
> :for e = list :then (cdr e)
> :when (= i n) :do (setf result e)
> :finally (return result)))
> NTH-ARGUMENT
> ? (nth-argument 2 '(+ a b c))
> (B C)
> ?
Right, It should be:
(defun nth-argument (n list)
(loop
:with result = nil
:for i :from 0 :below call-arguments-limit
:for e = list :then (cdr e)
:when (= i n) :do (setf result (car e))
:finally (return result)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > You betray an appalling lack of imagination. What if I wanted to write
> > something like this:
>
> I could as well have used (expt 2 32) as upper limit. (or (expt 2 64)
> on a 64-bit processor).
I will buy you a 64-bit machine if you promise to run this benchmark on
it and not post anything more to usenet until it's done.
> There cannot be proper lists longer than 2��
> in an 32-bit address space.
Of course there can. Is there no end to your ignorance?
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > You betray an appalling lack of imagination. What if I wanted to write
>> > something like this:
>>
>> I could as well have used (expt 2 32) as upper limit. (or (expt 2 64)
>> on a 64-bit processor).
>
> I will buy you a 64-bit machine if you promise to run this benchmark on
> it and not post anything more to usenet until it's done.
Ah ah! You're starting to see the light, aren't you!
O(...) doesn't matter, what matter is the exact finite number of
operations done for a specific finite input size.
>> There cannot be proper lists longer than 2��
>> in an 32-bit address space.
>
> Of course there can. Is there no end to your ignorance?
I've not said that you couldn't implement your own kind of lazy
sequence with more than 2^32 elements, I've said that there cannot be
more than 2^32 CONS cells (what proper lists are made of) in a 32-bit
address space. The actual limit is much smaller, around 64 Mcons in
implementations like sbcl (with default compilation options) or clisp,
on 32-bit processos.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Specifications are for the weak and timid!"
Pascal Bourguignon wrote:
> Ron Garret <·········@flownet.com> writes:
>
>
>>In article <··············@thalassa.informatimago.com>,
>> Pascal Bourguignon <···@informatimago.com> wrote:
>>
>>
>>>Ron Garret <·········@flownet.com> writes:
>>>
>>>
>>>>You betray an appalling lack of imagination. What if I wanted to write
>>>>something like this:
>>>
>>>I could as well have used (expt 2 32) as upper limit. (or (expt 2 64)
>>>on a 64-bit processor).
>>
>>I will buy you a 64-bit machine if you promise to run this benchmark on
>>it and not post anything more to usenet until it's done.
>
>
> Ah ah! You're starting to see the light, aren't you!
>
> O(...) doesn't matter, what matter is the exact finite number of
> operations done for a specific finite input size.
>
>
>
>>>There cannot be proper lists longer than 2��
>>>in an 32-bit address space.
>>
>>Of course there can. Is there no end to your ignorance?
>
>
> I've not said that you couldn't implement your own kind of lazy
> sequence with more than 2^32 elements, I've said that there cannot be
> more than 2^32 CONS cells (what proper lists are made of) in a 32-bit
> address space. The actual limit is much smaller, around 64 Mcons in
> implementations like sbcl (with default compilation options) or clisp,
> on 32-bit processos.
>
Dumb and Dumber II?
hth, ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> O(...) doesn't matter
It does for real problems.
> what matter is the exact finite number of
> operations done for a specific finite input size.
Those are not mutually exclusive possibilities.
> >> There cannot be proper lists longer than 2��
> >> in an 32-bit address space.
> >
> > Of course there can. Is there no end to your ignorance?
>
> I've not said that you couldn't implement your own kind of lazy
> sequence with more than 2^32 elements, I've said that there cannot be
> more than 2^32 CONS cells (what proper lists are made of) in a 32-bit
> address space.
No, that is not what you said. What you said was "There cannot be
proper lists longer than 2�� in an 32-bit address space." But neither
of your claims is true. I recommend you begin by looking up the term
"proper list." It doesn't mean what you think it means.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> O(...) doesn't matter
>
> It does for real problems.
>
>> what matter is the exact finite number of
>> operations done for a specific finite input size.
>
> Those are not mutually exclusive possibilities.
>
>> >> There cannot be proper lists longer than 2��
>> >> in an 32-bit address space.
>> >
>> > Of course there can. Is there no end to your ignorance?
>>
>> I've not said that you couldn't implement your own kind of lazy
>> sequence with more than 2^32 elements, I've said that there cannot be
>> more than 2^32 CONS cells (what proper lists are made of) in a 32-bit
>> address space.
>
> No, that is not what you said. What you said was "There cannot be
> proper lists longer than 2�� in an 32-bit address space." But neither
> of your claims is true. I recommend you begin by looking up the term
> "proper list." It doesn't mean what you think it means.
Perhaps there's a problem of rendering in your newsreader. 2�� is
two to the power 32. In a 32-bit address space, there can be at most
2^32 different objects. Since cons cells take 8 bytes, there's
actually at most 2^29 cons cells. Actually of course much less. A
proper list is a list without circles. Each cons cell appears at most
once in the list, and therefore the proper list cannot contain more
than 2^32 cons cells in theory, and no more than much less than 2^29
in practice.
In theory, you could implement a proper list of bytes as a vector of
bytes in the address space. In practice, this is not exactly a proper
list, even it it's still a sequence.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> >> O(...) doesn't matter
> >
> > It does for real problems.
> >
> >> what matter is the exact finite number of
> >> operations done for a specific finite input size.
> >
> > Those are not mutually exclusive possibilities.
> >
> >> >> There cannot be proper lists longer than 2��
> >> >> in an 32-bit address space.
> >> >
> >> > Of course there can. Is there no end to your ignorance?
> >>
> >> I've not said that you couldn't implement your own kind of lazy
> >> sequence with more than 2^32 elements, I've said that there cannot be
> >> more than 2^32 CONS cells (what proper lists are made of) in a 32-bit
> >> address space.
> >
> > No, that is not what you said. What you said was "There cannot be
> > proper lists longer than 2�� in an 32-bit address space." But neither
> > of your claims is true. I recommend you begin by looking up the term
> > "proper list." It doesn't mean what you think it means.
>
> Perhaps there's a problem of rendering in your newsreader. 2�� is
> two to the power 32.
Yes, I know.
> In a 32-bit address space, there can be at most 2^32 different objects.
That is not true.
> A proper list is a list without circles.
Neither is that.
rg
Ron Garret wrote:
> Pascal Bourguignon <···@informatimago.com> wrote:
>
> > In a 32-bit address space, there can be at most 2^32 different objects.
>
> That is not true.
>
Now you're being provocative. Ok, I'll bite. Do you mean bits, or how
can you have more objects? I'm honestly curious.
> > A proper list is a list without circles.
>
> Neither is that.
>
Lacking any authority what-so-ever, my definition of a proper list (in
the context of Lisp) is one where repeated application of cdr
eventually results in a nil. I guess you're saying the car can point
to something with a cycle?
In article <························@80g2000cwy.googlegroups.com>,
·······@gmail.com wrote:
> Ron Garret wrote:
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> > > In a 32-bit address space, there can be at most 2^32 different objects.
> >
> > That is not true.
> >
>
> Now you're being provocative.
Following Pascal's lead. Trying to show how utterly annoying it can be.
> Ok, I'll bite. Do you mean bits, or how
> can you have more objects? I'm honestly curious.
There are many ways. Wade pointed out one. But in general, the size of
the address space is irrelevant. The only thing that matters is the
size of the available memory. Even without off-line storage, a 32-bit
address space can address a potentially infinite memory using e.g.
bank-switching techniques. In the extreme, a Turing machine has a
zero-bit address space, but it can represent an infinite number of
objects. Even a plain-vanilla Unix box running a Lisp that represents
objects in the usual way can easily contain more than 2^32 objects
simultaneously in multiple Lisp processes, some of which are swapped out
to virtual memory.
Pascal's point that physical computers (and indeed arguably the entire
universe) are finite state machines is a fact of little practical
interest.
> > > A proper list is a list without circles.
> >
> > Neither is that.
> >
>
> Lacking any authority what-so-ever, my definition of a proper list (in
> the context of Lisp) is one where repeated application of cdr
> eventually results in a nil. I guess you're saying the car can point
> to something with a cycle?
No. Here's a clue:
1. Point your browser at www.google.com
2. In the search box, type in "proper list"
3. Click "I'm feeling lucky"
4. Read.
rg
Ron Garret wrote:
> >
> > Now you're being provocative.
>
> Following Pascal's lead. Trying to show how utterly annoying it can be.
>
Seems to be a c.l.l thing... Your next strategy is successful too:
>
> No. Here's a clue:
>
> 1. Point your browser at www.google.com
> 2. In the search box, type in "proper list"
> 3. Click "I'm feeling lucky"
> 4. Read.
>
My "luck" must be different than yours. I got a result that supported
my definition very closely.
Whatever. I'll give Pascal credit for at least having a
semi-interesting end in mind when he plays these games. I doubt this
path of yours is leading anywhere. Take care.
·······@gmail.com wrote:
> Ron Garret wrote:
>
>>>Now you're being provocative.
>>
>>Following Pascal's lead. Trying to show how utterly annoying it can be.
>>
>
>
> Seems to be a c.l.l thing... Your next strategy is successful too:
Not if you put them both in your killfile. :)
>
>
>>No. Here's a clue:
>>
>>1. Point your browser at www.google.com
>>2. In the search box, type in "proper list"
>>3. Click "I'm feeling lucky"
>>4. Read.
>>
>
>
> My "luck" must be different than yours. I got a result that supported
> my definition very closely.
You mean?:
"improper list n. a list which is not a proper list: a circular list or
dotted list."
You left out dotted-list when you said "without circles".
hth,kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
> You mean?:
>
> "improper list n. a list which is not a proper list: a circular list or
> dotted list."
>
> You left out dotted-list when you said "without circles".
>
> hth,kt
>
Nah, Pascal said "without circles". I said cdr-ing terminates with
nil. I should go create a Wikipedia entry to support my case in the
future.
Cheers,
-Scott
·······@gmail.com wrote:
> Ken Tilton wrote:
>
>>You mean?:
>>
>>"improper list n. a list which is not a proper list: a circular list or
>> dotted list."
>>
>>You left out dotted-list when you said "without circles".
>>
>>hth,kt
>>
>
>
> Nah, Pascal said "without circles".
Oops.
> I said cdr-ing terminates with
> nil.
Not bad.
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ron Garret <·········@flownet.com> writes:
> In article <························@80g2000cwy.googlegroups.com>,
> ·······@gmail.com wrote:
>
>> Ron Garret wrote:
>> > Pascal Bourguignon <···@informatimago.com> wrote:
>> >
>> > > In a 32-bit address space, there can be at most 2^32 different objects.
>> >
>> > That is not true.
>> >
>>
>> Now you're being provocative.
>
> Following Pascal's lead. Trying to show how utterly annoying it can be.
>
>> Ok, I'll bite. Do you mean bits, or how
>> can you have more objects? I'm honestly curious.
>
> There are many ways. Wade pointed out one. But in general, the size of
> the address space is irrelevant. The only thing that matters is the
> size of the available memory. Even without off-line storage, a 32-bit
> address space can address a potentially infinite memory using e.g.
> bank-switching techniques.
This would increase the address space. I've not spoken of the memory
space, but of the address space.
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <························@80g2000cwy.googlegroups.com>,
> > ·······@gmail.com wrote:
> >
> >> Ron Garret wrote:
> >> > Pascal Bourguignon <···@informatimago.com> wrote:
> >> >
> >> > > In a 32-bit address space, there can be at most 2^32 different objects.
> >> >
> >> > That is not true.
> >> >
> >>
> >> Now you're being provocative.
> >
> > Following Pascal's lead. Trying to show how utterly annoying it can be.
> >
> >> Ok, I'll bite. Do you mean bits, or how
> >> can you have more objects? I'm honestly curious.
> >
> > There are many ways. Wade pointed out one. But in general, the size of
> > the address space is irrelevant. The only thing that matters is the
> > size of the available memory. Even without off-line storage, a 32-bit
> > address space can address a potentially infinite memory using e.g.
> > bank-switching techniques.
>
> This would increase the address space. I've not spoken of the memory
> space, but of the address space.
It doesn't matter. You assertion is either vacuous (being based on an
arbitrary constraint on the amount of available storage disguised as
some technical buzzword that you probably don't even understand) or it's
wrong. Take your pick.
rg
·······@gmail.com wrote:
> Ron Garret wrote:
>> Pascal Bourguignon <···@informatimago.com> wrote:
>>
>>> In a 32-bit address space, there can be at most 2^32 different objects.
>> That is not true.
>>
>
> Now you're being provocative. Ok, I'll bite. Do you mean bits, or how
> can you have more objects? I'm honestly curious.
>
Its the same way a 32-bit system can have a SQL Database with Terabytes of
information. A piece at a time.
http://www.postgresql.org/docs/faqs.FAQ.html#item4.4
Wade
Wade Humeniuk <··················@telus.net> writes:
> ·······@gmail.com wrote:
>> Ron Garret wrote:
>>> Pascal Bourguignon <···@informatimago.com> wrote:
>>>
>>>> In a 32-bit address space, there can be at most 2^32 different objects.
>>> That is not true.
>>>
>>
>> Now you're being provocative. Ok, I'll bite. Do you mean bits, or how
>> can you have more objects? I'm honestly curious.
>>
>
> Its the same way a 32-bit system can have a SQL Database with Terabytes of
> information. A piece at a time.
>
> http://www.postgresql.org/docs/faqs.FAQ.html#item4.4
Even if your data is stored in a swap file, or in a database, if you
have only 2^32 different addresses, you cannot identify more than 2^32
different objects.
To identify more objects in a database, or bits, you need more than
32 bits.
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
On 2006-12-19, Pascal Bourguignon <···@informatimago.com> wrote:
> Even if your data is stored in a swap file, or in a database,
> if you have only 2^32 different addresses, you cannot identify
> more than 2^32 different objects.
>
> To identify more objects in a database, or bits, you need more
> than 32 bits.
Braille is a 6-bit code, but encodes more than 64 meanings by
using context, escape codes and shift codes.
--
Neil Cerutti
On 2006-12-19, Manuel Giraud <·············@gmail.com> wrote:
> Neil Cerutti <·······@yahoo.com> writes:
>
>> [...]
>> using context, escape codes and shift codes.
>
> So it is, at least, a 7 bits code :)
I don't know what you mean.
--
Neil Cerutti
Neil Cerutti wrote:
> On 2006-12-19, Manuel Giraud <·············@gmail.com> wrote:
>> Neil Cerutti <·······@yahoo.com> writes:
>>
>>> [...]
>>> using context, escape codes and shift codes.
>>
>> So it is, at least, a 7 bits code :)
>
> I don't know what you mean.
>
Bit is a unit for amount of information. Context is also information.
Do not mess up with information and encoding! See Unicode. A single 8
bit word is not enough to express all possible Unicode values, but you can
encode all possible Unicode values using only 8 bit words. Or less, if
you desire to do...
--
Markus Grueneis
On 2006-12-19, Markus Grueneis <···@gmx.at> wrote:
> Neil Cerutti wrote:
>> On 2006-12-19, Manuel Giraud <·············@gmail.com> wrote:
>>> Neil Cerutti <·······@yahoo.com> writes:
>>>
>>>> [...]
>>>> using context, escape codes and shift codes.
>>>
>>> So it is, at least, a 7 bits code :)
>>
>> I don't know what you mean.
>
> Bit is a unit for amount of information. Context is also
> information.
OK, I get it. :)
> Do not mess up with information and encoding! See Unicode. A
> single 8 bit word is not enough to express all possible
> Unicode values, but you can encode all possible Unicode values
> using only 8 bit words. Or less, if you desire to do...
It appears to me that, using UTF-8, we do identify more than 256
objects using only 8 bits. Unless Pascal used the word 'identify'
in some limited technical sense.
--
Neil Cerutti
In article <·····················@FIAD06.norwich.edu>,
Neil Cerutti <·······@yahoo.com> wrote:
> It appears to me that, using UTF-8, we do identify more than 256
> objects using only 8 bits. Unless Pascal used the word 'identify'
> in some limited technical sense.
No, Pascal is just blowing pedantic smoke out of his ass.
rg
Neil Cerutti wrote:
> On 2006-12-19, Markus Grueneis <···@gmx.at> wrote:
>> [...]
>> Bit is a unit for amount of information. Context is also
>> information.
>
> OK, I get it. :)
>
>> Do not mess up with information and encoding! See Unicode. [...]
>
> It appears to me that, using UTF-8, we do identify more than 256
> objects using only 8 bits. Unless Pascal used the word 'identify'
> in some limited technical sense.
>
Well, but that's the point I was talking about. You can identify much
more than 256 chars with UTF-8. But then you need more than 8 bit ;-) I
haven't followed the thread so closely, but I think to remember he was
referring to 32 bit, not to 32 bit encoding. That's not limited technical
sense, that's quite sane.
Well, here it is:
Pascal wrote:
> [...]
> To identify more objects in a database, or bits, you need more than
> 32 bits.
> [...]
--
Markus Grueneis
On 2006-12-19, Markus Grueneis <···@gmx.at> wrote:
> Neil Cerutti wrote:
>> On 2006-12-19, Markus Grueneis <···@gmx.at> wrote:
>>> [...]
>>> Bit is a unit for amount of information. Context is also
>>> information.
>>
>> OK, I get it. :)
>>
>>> Do not mess up with information and encoding! See Unicode. [...]
>>
>> It appears to me that, using UTF-8, we do identify more than 256
>> objects using only 8 bits. Unless Pascal used the word 'identify'
>> in some limited technical sense.
>
> Well, but that's the point I was talking about. You can
> identify much more than 256 chars with UTF-8. But then you
> need more than 8 bit ;-) I haven't followed the thread so
> closely, but I think to remember he was referring to 32 bit,
> not to 32 bit encoding. That's not limited technical sense,
> that's quite sane.
>
> Well, here it is:
>
> Pascal wrote:
>> [...]
>> To identify more objects in a database, or bits, you need
>> more than 32 bits. [...]
OK, I see. I thought he meant a 32-bit data-type.
Thanks for the correction. I'd amazed to learng about the two-bit
32-bit computer in question. ;)
--
Neil Cerutti
The recording I listened to had Alfred Brendel doing the dirty work of
performing this sonata (Liszt B minor) --Music Lit Essay
·······@gmail.com wrote:
> Lacking any authority what-so-ever, my definition of a proper list (in
> the context of Lisp) is one where repeated application of cdr
> eventually results in a nil. I guess you're saying the car can point
> to something with a cycle?
For "proper list" meaning non-cyclic list, isn't a finite lazy list the
simplest counter-example to Pascal's latest blatantly incorrect assertion?
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Pascal Bourguignon <···@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> >> Jon Harrop <···@ffconsultancy.com> writes:
> >>
> >> > Andr� Thieme wrote:
> >> >> In Lisp (+ a b c) has this:
> >> >> +
> >> >> / | \
> >> >> a b c
> >> >
> >> > That implies to me that the last element ("c" in this case) can be
> >> > accessed in O(1) time. Can it?
> >>
> >> Yes.
> >>
> >> (defun nth (n list)
> >> (loop
> >> :with result = nil
> >> :for i :from 0 :below call-arguments-limit
> >> :for e = list :then (cdr e)
> >> :when (= i n) :do (setf result e)
> >> :finally (return result)))
> >
> > Huh? Is this another one of your bad jokes (a la
> > http://groups.google.com/group/comp.lang.lisp/msg/1d85f2e1ec5f6e0b)?
>
> No. This is an implementation of nth that is in O(1). It execution
> time and space is strictly independant of the length of the list.
>
> Seems to me you don't know what O(1) means...
Wait... what? The above algorithm is O(n).
Must be some insider joke that I'm not privy to...
····@stablecross.com (Bob Felts) writes:
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <··············@thalassa.informatimago.com>,
>> > Pascal Bourguignon <···@informatimago.com> wrote:
>> >
>> >> Jon Harrop <···@ffconsultancy.com> writes:
>> >>
>> >> > Andr� Thieme wrote:
>> >> >> In Lisp (+ a b c) has this:
>> >> >> +
>> >> >> / | \
>> >> >> a b c
>> >> >
>> >> > That implies to me that the last element ("c" in this case) can be
>> >> > accessed in O(1) time. Can it?
>> >>
>> >> Yes.
>> >>
>> >> (defun nth (n list)
>> >> (loop
>> >> :with result = nil
>> >> :for i :from 0 :below call-arguments-limit
>> >> :for e = list :then (cdr e)
>> >> :when (= i n) :do (setf result e)
>> >> :finally (return result)))
>> >
>> > Huh? Is this another one of your bad jokes (a la
>> > http://groups.google.com/group/comp.lang.lisp/msg/1d85f2e1ec5f6e0b)?
>>
>> No. This is an implementation of nth that is in O(1). It execution
>> time and space is strictly independant of the length of the list.
>>
>> Seems to me you don't know what O(1) means...
>
> Wait... what? The above algorithm is O(n).
Wrong. The above algorithm is obviously O(call-argument-limit) = O(1)
since call-argument-limit is a constant.
> Must be some insider joke that I'm not privy to...
Ask the mathematicians...
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon <···@informatimago.com> wrote:
> ····@stablecross.com (Bob Felts) writes:
>
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >>
> >> > In article <··············@thalassa.informatimago.com>,
> >> > Pascal Bourguignon <···@informatimago.com> wrote:
> >> >
> >> >> Jon Harrop <···@ffconsultancy.com> writes:
> >> >>
> >> >> > Andr� Thieme wrote:
> >> >> >> In Lisp (+ a b c) has this:
> >> >> >> +
> >> >> >> / | \
> >> >> >> a b c
> >> >> >
> >> >> > That implies to me that the last element ("c" in this case) can be
> >> >> > accessed in O(1) time. Can it?
> >> >>
> >> >> Yes.
> >> >>
> >> >> (defun nth (n list)
> >> >> (loop
> >> >> :with result = nil
> >> >> :for i :from 0 :below call-arguments-limit
> >> >> :for e = list :then (cdr e)
> >> >> :when (= i n) :do (setf result e)
> >> >> :finally (return result)))
> >> >
> >> > Huh? Is this another one of your bad jokes (a la
> >> > http://groups.google.com/group/comp.lang.lisp/msg/1d85f2e1ec5f6e0b)?
> >>
> >> No. This is an implementation of nth that is in O(1). It execution
> >> time and space is strictly independant of the length of the list.
> >>
> >> Seems to me you don't know what O(1) means...
> >
> > Wait... what? The above algorithm is O(n).
>
> Wrong. The above algorithm is obviously O(call-argument-limit) = O(1)
> since call-argument-limit is a constant.
>
By that logic, any algorithm that deals with a fixed-number of elements
is O(1). That isn't how O() notation is defined.
····@stablecross.com (Bob Felts) writes:
> Pascal Bourguignon <···@informatimago.com> wrote:
>> Wrong. The above algorithm is obviously O(call-argument-limit) = O(1)
>> since call-argument-limit is a constant.
>
> By that logic, any algorithm that deals with a fixed-number of elements
> is O(1). That isn't how O() notation is defined.
Check your lecture notes. O(2) = O(1) = O(50) = O(call-argument-limit)
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
Pascal Bourguignon <···@informatimago.com> wrote:
> ····@stablecross.com (Bob Felts) writes:
>
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >> Wrong. The above algorithm is obviously O(call-argument-limit) = O(1)
> >> since call-argument-limit is a constant.
> >
> > By that logic, any algorithm that deals with a fixed-number of elements
> > is O(1). That isn't how O() notation is defined.
>
> Check your lecture notes.
My 30+ year old copy of Knuth vol 1. will do just fine, thanks.
> O(2) = O(1) = O(50) = O(call-argument-limit)
Sure, but that isn't what's at issue. Your algorithm is of the form:
from 1 to N do ...
Oh, wait... it isn't. The code doesn't exit when it finds the Nth
element, it continues looking at the list even after the result is
found.
"That's different. Never mind."
····@stablecross.com (Bob Felts) writes:
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> ····@stablecross.com (Bob Felts) writes:
>>
>> > Pascal Bourguignon <···@informatimago.com> wrote:
>> >> Wrong. The above algorithm is obviously O(call-argument-limit) = O(1)
>> >> since call-argument-limit is a constant.
>> >
>> > By that logic, any algorithm that deals with a fixed-number of elements
>> > is O(1). That isn't how O() notation is defined.
>>
>> Check your lecture notes.
>
> My 30+ year old copy of Knuth vol 1. will do just fine, thanks.
>
>> O(2) = O(1) = O(50) = O(call-argument-limit)
>
> Sure, but that isn't what's at issue. Your algorithm is of the form:
>
> from 1 to N do ...
>
> Oh, wait... it isn't. The code doesn't exit when it finds the Nth
> element, it continues looking at the list even after the result is
> found.
Indeed. That's why it's O(call-arguments-limit) = O(1)!
It takes the same time whatever the size of the list, and whatever the
value of n! That's the definition of an O(1) algorithm.
--
__Pascal Bourguignon__ http://www.informatimago.com/
HANDLE WITH EXTREME CARE: This product contains minute electrically
charged particles moving at velocities in excess of five hundred
million miles per hour.
Pascal Bourguignon <···@informatimago.com> wrote:
[...]
> >
> > Oh, wait... it isn't. The code doesn't exit when it finds the Nth
> > element, it continues looking at the list even after the result is
> > found.
>
> Indeed. That's why it's O(call-arguments-limit) = O(1)!
>
> It takes the same time whatever the size of the list, and whatever the
> value of n! That's the definition of an O(1) algorithm.
Well, yes. The problem wasn't in the O() definition; the problem was
that I didn't initially recognize that the algorithm continued to search
after the desired object was found. You get points for making the
algorithm O(1) instead of O(N), but I'd have to deduct points since, in
this case, the algorithm is less efficient than O(N).
····@stablecross.com (Bob Felts) writes:
> Pascal Bourguignon <···@informatimago.com> wrote:
>
> [...]
>
>> >
>> > Oh, wait... it isn't. The code doesn't exit when it finds the Nth
>> > element, it continues looking at the list even after the result is
>> > found.
>>
>> Indeed. That's why it's O(call-arguments-limit) = O(1)!
>>
>> It takes the same time whatever the size of the list, and whatever the
>> value of n! That's the definition of an O(1) algorithm.
>
> Well, yes. The problem wasn't in the O() definition; the problem was
> that I didn't initially recognize that the algorithm continued to search
> after the desired object was found. You get points for making the
> algorithm O(1) instead of O(N), but I'd have to deduct points since, in
> this case, the algorithm is less efficient than O(N).
Indeed that was my point.
You cannot claim anything saying that something is not O(1), because
in any conceivable computer of this finite universe, any algorithm
that is O(f(n)) can be "extended" to execute a constant number of
instructions. The asymptotic behavior is irrelevant since the
universe terminates before the asymptote is reached. Therefore there
is always a program that behaves in O(1) and you cannot say anything
in the antecedent of the implication, which is what Jon did.
What can be discussed is the real number of instructions and time used
for given finite input to given programs. The constants are what
matter in programs!
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon wrote:
> The asymptotic behavior is irrelevant since the universe terminates before
> the asymptote is reached.
Why do you think asymptotic algorithmic complexity is universally recognised
as being hugely important and is taught in all of the best books on
algorithms?
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Pascal Bourguignon wrote:
> > The asymptotic behavior is irrelevant since the universe terminates before
> > the asymptote is reached.
>
> Why do you think asymptotic algorithmic complexity is universally recognised
> as being hugely important and is taught in all of the best books on
> algorithms?
>
Big-O is a good thing to think about, but Pascal has a point too. (The
problem methinks is that he's trying to be provocative in presenting
it. He's apparently an unusual breed of insightful Lisper and Troll.
It's probably a good thing you're feeding him because it let's him make
his point. Be careful running any code that he gives you though...)
As an example, (from Python's implementation no less, so I can pretend
this is on topic) it takes a really big n for Karatsuba multiplication
O(n**log2(3)) to lose out to an FFT based multiplication O(n*log(n)).
So blindly using the big-O comparison in choosing an algorithm to
implement your Python longs or Scheme bignums can mislead you. And a
naive implementation of the FFT multiplication can fall apart and give
you the wrong answer after the numbers get big enough that it's
difficult to verify without grabbing someone else's working algorithm.
Cheers,
-Scott
Jon Harrop <···@ffconsultancy.com> writes:
> Pascal Bourguignon wrote:
>> The asymptotic behavior is irrelevant since the universe terminates before
>> the asymptote is reached.
>
> Why do you think asymptotic algorithmic complexity is universally recognised
> as being hugely important and is taught in all of the best books on
> algorithms?
Like any mathematical theorem, the conditions of applications are the
most important part, and the most often forgotten.
Asymptotes don't matter in a finite universe: the conditions of
application of the asymptotes, that is, infinite input, are not
fulfilled.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
Pascal Bourguignon wrote:
> ····@stablecross.com (Bob Felts) writes:
>
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >> Wrong. The above algorithm is obviously O(call-argument-limit) = O(1)
> >> since call-argument-limit is a constant.
> >
> > By that logic, any algorithm that deals with a fixed-number of elements
> > is O(1). That isn't how O() notation is defined.
>
> Check your lecture notes. O(2) = O(1) = O(50) = O(call-argument-limit)
Asymptotic analysis depends on the concept of some independent N
allowed to become abitrarily large. The analysis and its notation
simply do not apply if N itself is bounded.
When an algorithm has an O(1) running time (or memory usage or whatever
performance parameter), that still expresses an upper bound of some
function of the parameter N (usually the input size), as N gets large.
O(1) asserts that the performance simply not varry according to N,
regardless of how large N gets: the upper bound is a function of the
form 0 * N + T, where T is some term that is either constant, or
possibly even a function of N that decreases as N gets large such as
1/N.
Clamping N to some fixed value C does not cause the asymptotic bound to
be O(C); that's just an abuse of the concept and the notation. N is
then no longer a free variable that can be used to investigate the
dependent functions as it gets large.
If you want to play it that way, you have to identify parameter N to
represent something else: for instance some input size to an algorithm
involving these lists of bounded size, giving rise to a situation where
you are justified to abstract away these accesses as a constant-time
operation that is O(1) in the input size N to the overall algorithm.
+ Pascal Bourguignon <···@informatimago.com>:
| Ron Garret <·········@flownet.com> writes:
|
|> Huh? Is this another one of your bad jokes (a la
|> http://groups.google.com/group/comp.lang.lisp/msg/1d85f2e1ec5f6e0b)?
|
| No. This is an implementation of nth that is in O(1). It execution
| time and space is strictly independant of the length of the list.
|
| Seems to me you don't know what O(1) means...
Mwuahahaha ... Pascal, you are an evil man ...
And what scares me, is that I mean that as a compliment.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> In Lisp (+ a b c) has this:
>> +
>> / | \
>> a b c
>
> That implies to me that the last element ("c" in this case) can be accessed
> in O(1) time. Can it?
It works the same in ocaml. In your raytracer I found this call:
GlClear.color (0., 0.1, 0.2);
How much longer does it take ocaml to reach the 0. and how long
until it finds the 0.2 ?
Andr�
--
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> That implies to me that the last element ("c" in this case) can be
>> accessed in O(1) time. Can it?
>
> It works the same in ocaml.
I don't think so. The + function in Lisp has arbitrary arity. To get the
same effect in OCaml you must pass a container of arguments. Given that the
standard container in Lisp is a list, I think the equivalent in OCaml is to
pass a list:
foo [a; b; c]
in which case accessing the "i"th argument is T(i) and O(n) and not O(1).
Pascal Bourguignon has demonstrated that it is O(call-arguments-limit) where
call-arguments-limit is 1152921504606846975 on my machine. So it can take a
lot of time to fetch an argument.
However, I am sure Lisp compilers spend some of their time translating lists
into tuples, i.e.:
foo [a; b; c]
into:
foo(a, b, c)
so it is O(1) when the arity can be inferred at compile time and you don't
know when this is.
In any case, the point that I was making originally was that (+ a b c)
should not be represented diagramattically as:
+
/|\
a b c
but rather as:
+
\
a
\
b
\
c
This, in turn, undermines what other people said about the above diagram
making Lisp superior. I was hoping everyone would infer that from my
original statement but, instead, they seem to have lapsed into a futile
discussion about asymptotes. Bloody Lispers...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> In any case, the point that I was making originally was that (+ a b c)
> should not be represented diagramattically as:
>
> +
> /|\
> a b c
>
> but rather as:
>
> +
> \
> a
> \
> b
> \
> c
No. You should rather represent it as:
(address) (content)
01001000110000010010001101111000: 01001000110000010010001110000001 (cdr)
01001000110000010010001101111100: 00000100110000010001001011110001 (car)
01001000110000010010001110000000: 01001000110000010010001110001001
01001000110000010010001110000100: 00000100110000010001001011111001
01001000110000010010001110001000: 01001000110000010010001110010001
01001000110000010010001110001100: 00000100110000010001001100000001
01001000110000010010001110010000: 01001000110000010010001110011001
01001000110000010010001110010100: 00000100110000010001001100001001
01001000110000010010001110011000: 01001000110000010010001110100001
01001000110000010010001110011100: 00000000000000000000000000000000
(+ a b c) represents a ternary tree node, at the correct abstraction level!
> This, in turn, undermines what other people said about the above diagram
> making Lisp superior. I was hoping everyone would infer that from my
> original statement but, instead, they seem to have lapsed into a futile
> discussion about asymptotes. Bloody Lispers...
It may be faster to follow three pointers than to index an array.
Depending on the compiler and the processor.
--
__Pascal Bourguignon__ http://www.informatimago.com/
WARNING: This product warps space and time in its vicinity.
Pascal Bourguignon wrote:
>> This, in turn, undermines what other people said about the above diagram
>> making Lisp superior. I was hoping everyone would infer that from my
>> original statement but, instead, they seem to have lapsed into a futile
>> discussion about asymptotes. Bloody Lispers...
>
> It may be faster to follow three pointers than to index an array.
> Depending on the compiler and the processor.
What compilers/processors do you think will be faster at three dereferences
than one lookup with a known offset?
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> What compilers/processors do you think will be faster at three dereferences
> than one lookup with a known offset?
Any system where those three derefs hit cache as opposed to the array
ref going significantly further afield.
Jon Harrop schrieb:
> In any case, the point that I was making originally was that (+ a b c)
> should not be represented diagramattically as:
>
> +
> /|\
> a b c
>
> but rather as:
>
> +
> \
> a
> \
> b
> \
> c
Why?
To the programmer (+ a b c)
looks like a call of a function with three arguments.
So the tokens (brain units) can be put into this tree:
+
/|\
a b c
The tree you gave looks to me like:
(+ (a (b c)))
Andr�
--
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> +
>> \
>> a
>> \
>> b
>> \
>> c
>
> Why?
>
> To the programmer (+ a b c)
> looks like a call of a function with three arguments.
> So the tokens (brain units) can be put into this tree:
>
> +
> /|\
> a b c
>
>
> The tree you gave looks to me like:
> (+ (a (b c)))
Exactly. If it were an nary function call you could access the "n"th element
in constant time but you cannot because it is a list.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> Jon Harrop schrieb:
>>> +
>>> \
>>> a
>>> \
>>> b
>>> \
>>> c
>> Why?
>>
>> To the programmer (+ a b c)
>> looks like a call of a function with three arguments.
>> So the tokens (brain units) can be put into this tree:
>>
>> +
>> /|\
>> a b c
>>
>>
>> The tree you gave looks to me like:
>> (+ (a (b c)))
>
> Exactly. If it were an nary function call you could access the "n"th element
> in constant time but you cannot because it is a list.
Your tree in C syntax:
+a(b(c)); // the unary "+" operator.
Andr�
--
Andr� Thieme wrote:
> Your tree in C syntax:
> +a(b(c)); // the unary "+" operator.
Better to do it in Lisp rather than C:
* '(+ a b c)
(+ A B C)
is equivalent to:
* '(+ . (a . (b . (c))))
(+ A B C)
i.e. the function and arguments are just a list. Hence I'd rather draw them
as a list rather than a 3-tuple. If you want a 3-tuple in Lisp then you can
use an array:
* '(f #(a b c))
(f #(A B C))
I believe the "arguments" to f can now be accessed in O(1) time because they
are in an array. Perhaps a Lisper will correct me if I'm wrong.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> Your tree in C syntax:
>> +a(b(c)); // the unary "+" operator.
>
> Better to do it in Lisp rather than C:
>
> * '(+ a b c)
>
> (+ A B C)
>
> is equivalent to:
>
> * '(+ . (a . (b . (c))))
>
> (+ A B C)
While, that's right it also is a low level detail how lists are
constructed. I don't think about it when I write (+ a b c).
For me it is a function call with 3 args, sums up to 4 tokens.
So conceptually (+ a b c) is less complex than a + b + c which has 5
tokens.
In Python one could do that too:
def add3(a, b, c):
return a + b + c
and then add3(1, 2, 3)
> i.e. the function and arguments are just a list.
During programming I don't think about this.
I usually also don't try to imagine how the machine code would look like.
> If you want a 3-tuple in Lisp then you can use an array:
>
> * '(f #(a b c))
f
|
#()
/|\
a b c
A tree consisting out of five tokens.
> I believe the "arguments" to f can now be accessed in O(1) time because they
> are in an array. Perhaps a Lisper will correct me if I'm wrong.
You are correct. During runtime they can be accessed in O(1).
[but there is only one argument to f]
Andr�
--
Andr� Thieme wrote:
> Jon Harrop schrieb:
>> Andr� Thieme wrote:
>>> Your tree in C syntax:
>>> +a(b(c)); // the unary "+" operator.
>>
>> Better to do it in Lisp rather than C:
>>
>> * '(+ a b c)
>>
>> (+ A B C)
>>
>> is equivalent to:
>>
>> * '(+ . (a . (b . (c))))
>>
>> (+ A B C)
>
> While, that's right it also is a low level detail how lists are
> constructed.
I would call it a high-level detail because it affects the asymptotic
complexity.
> I don't think about it when I write (+ a b c).
> For me it is a function call with 3 args, sums up to 4 tokens.
> So conceptually (+ a b c) is less complex than a + b + c which has 5
> tokens.
Only if you ignore the superfluous parentheses.
> In Python one could do that too:
> def add3(a, b, c):
> return a + b + c
>
> and then add3(1, 2, 3)
The equivalent in other languages is really to pass a list of arguments to
every function.
>> i.e. the function and arguments are just a list.
>
> During programming I don't think about this.
You should if it affects the asymptotic complexity of your algorithm.
> I usually also don't try to imagine how the machine code would look like.
The use of an unconventional data structure for passing arguments is much
higher-level than machine code.
> > If you want a 3-tuple in Lisp then you can use an array:
>>
>> * '(f #(a b c))
>
>
> f
> |
> #()
> /|\
> a b c
>
> A tree consisting out of five tokens.
Exactly.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
On Mon, 18 Dec 2006 20:30:07 +0100, Jon Harrop <···@ffconsultancy.com>
wrote:
>
> (f #(A B C))
>
> I believe the "arguments" to f can now be accessed in O(1) time because
> they
> are in an array. Perhaps a Lisper will correct me if I'm wrong.
>
A list with a pointer to a array?
I see it differently.
+
a b c
would mean:
(cons '+ (cons (cons 'a nil) (cons (cons 'b nil) (cons (cons 'c nil)
nil)))))
Normally (cons '+ (cons 'a (cons 'b (cons 'c nil))))
The problem is that you can't use apply on arrays so
instead of (apply '+ arguments)
(reduce if you want a arbitrary number. apply is limited to some
CALL-ARGUMENTS-LIMIT)
you would need:
(defun + (array) (loop for number across array summing number))
for a array.
The construction is about equally expensive so there dosn't seem to be a
great benefit
with the array form.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jon Harrop schrieb:
> In any case, the point that I was making originally was that (+ a b c)
> should not be represented diagramattically as:
>
> +
> /|\
> a b c
>
> but rather as:
>
> +
> \
> a
> \
> b
> \
> c
Why?
To the programmer (+ a b c)
looks like a call of a function with three arguments.
So the tokens (brain units) can be put into this tree:
+
/|\
a b c
The tree you gave looks to me like:
(+ (a (b c)))
Andr�
--
In article <··············@ruckus.brouhaha.com>,
Paul Rubin <·············@NOSPAM.invalid> wrote:
> Kirk Sluder <····@nospam.jobsluder.net> writes:
> > Personally, I've always preferred use the imperative to describe
> > _basic_ math rather than the passive. This would seem to map better to
> > RPN than infix.
(emphasis added)
> For writing down complicated, nested expressions too? That's very
> unusual. E.g.
>
> n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...
>
> vs. the same thing in Lisp notation, and that's not even so complicated.
I wasn't even talking about Polish notation vs. other standard
notations. I was talking about your claimed correspondence between
infix and natural Languages.
(1/12n) - "divide 1 by the product of" of 12 and n"
sqrt(2*pi*n) - "calculate the square root of the product of 2 pi and
n."
If computer languages were to mimic natural languages on this point,
they would support both forms of expression and be sensitive to mode
and mood.
In article
<··························@newsclstr03.news.prodigy.net>,
Kirk Sluder <····@nospam.jobsluder.net> wrote:
> In article <··············@ruckus.brouhaha.com>,
> Paul Rubin <·············@NOSPAM.invalid> wrote:
>
> > n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...
>
> If computer languages were to mimic natural languages on this point,
> they would support both forms of expression and be sensitive to mode
> and mood.
And ok, bringing this around to lisp, many complex expressions such
as polynomials can be viewed as lists of sub-expressions. So in this
case, the expression can be re-written as:
(* (subexp1) (subexp2) (subexp3) (subexp4))
Which is probably how I'd solve the expression if I was using paper
and pencil: simplify and combine.
And there is something that is missing here in arguing about
computer language notations in relationship to human language
readability, or correspondence to spoken language. I'm not writing
code for another human, I'm writing code for a machine. Often, the
optimum expression of an mathematical concept for a machine is
relatively baroque compared to the optimum expression for a human
being.
Paul Rubin schrieb:
> Kirk Sluder <····@nospam.jobsluder.net> writes:
>> Personally, I've always preferred use the imperative to describe
>> basic math rather than the passive. This would seem to map better to
>> RPN than infix.
>
> For writing down complicated, nested expressions too? That's very
> unusual. E.g.
>
> n! = (n/e)**n * sqrt(2*pi*n) * (1 + (1/12n)) * ...
>
> vs. the same thing in Lisp notation, and that's not even so complicated.
As I said earlier: if there are three formulas in your code, then it
doesn't matter too much.
If you write more then use infix in Lisp. It even looks better than Python:
[7x₆ + 9π³ - 6ˣ]
or
(if [√2 ≈ 1,41]
(print "Yay"))
Or mathematical reasoning:
(proof [∃ x∈M ∀ y∈Q : x≤y])
So what?
André
--
Andr� Thieme wrote:
> So instead of
> cmp(foo(a, b, c), bar(x, y, z)) you would prefer
> foo(a, b, c) cmp bar(x, y, z) ?
Incidentally, someone once came up with an fiendishly
clever hack that lets you write things in Python like
foo(a, b, c) |kmp| bar(x, y, z)
i.e. effectively define your own infix operators. And
it doesn't even require a macro. :-)
(Finding the trick to implementing this is left as an
exercise for the googler.)
--
Greg
Andr� Thieme wrote:
> (aif (timeConsumingCalculation)
> (use it))
I think the answer is that you just wouldn't do
that in Python at all. Having magic variables
spring into existence in your local namespace
as a side effect of calling something is just
not Pythonic. (It is very Perlish, on the other
hand.)
The closest you might come is using the new
"with" statement like this:
with aif(timeConsumingCalculation()) as it:
use(it)
where the object returned by aif(x) has an
__enter__ method that raises an exception which
aborts the whole with statement if x is None,
thus avoiding executing the body. But that's
so horribly convoluted that any sane programmer
would just write it out the straightforward
way to begin with.
> > There's a Haskell builtin called 'seq' which forces evaluation but
> > again I'm not sure precisely how to apply it here.
>
> So in some languages that support functional programming one needs to do
> extra work to get lazyness, while in Haskell one gets extra work if one
> doesn't want it.
Sort of, but it's more so that you can write code
that does things like I/O in what looks like a
procedural style, even though it's still purely
functional. Read about "monads" if you want to
know more -- it's truly mind-expanding (and
possibly head-exploding:-) stuff...
--
Greg
greg schrieb:
> Andr� Thieme wrote:
>> (aif (timeConsumingCalculation)
>> (use it))
>
> I think the answer is that you just wouldn't do
> that in Python at all. Having magic variables
> spring into existence in your local namespace
> as a side effect of calling something is just
> not Pythonic. (It is very Perlish, on the other
> hand.)
>
> The closest you might come is using the new
> "with" statement like this:
>
> with aif(timeConsumingCalculation()) as it:
> use(it)
>
> where the object returned by aif(x) has an
> __enter__ method that raises an exception which
> aborts the whole with statement if x is None,
> thus avoiding executing the body. But that's
> so horribly convoluted that any sane programmer
> would just write it out the straightforward
> way to begin with.
Sounds like "Blub" to me:
http://www.paulgraham.com/avg.html
I will quote some parts of it:
"You can see that machine language is very low level. But, at least as a
kind of social convention, high-level languages are often all treated as
equivalent. They're not. Technically the term "high-level language"
doesn't mean anything very definite. There's no dividing line with
machine languages on one side and all the high-level languages on the
other. Languages fall along a continuum [4] of abstractness, from the
most powerful all the way down to machine languages, which themselves
vary in power.
[...]
Programmers get very attached to their favorite languages, and I don't
want to hurt anyone's feelings, so to explain this point I'm going to
use a hypothetical language called Blub. Blub falls right in the middle
of the abstractness continuum. It is not the most powerful language, but
it is more powerful than Cobol or machine language.
And in fact, our hypothetical Blub programmer wouldn't use either of
them. Of course he wouldn't program in machine language. That's what
compilers are for. And as for Cobol, he doesn't know how anyone can get
anything done with it. It doesn't even have x (Blub feature of your
choice).
As long as our hypothetical Blub programmer is looking down the power
continuum, he knows he's looking down. Languages less powerful than Blub
are obviously less powerful, because they're missing some feature he's
used to. But when our hypothetical Blub programmer looks in the other
direction, up the power continuum, he doesn't realize he's looking up.
What he sees are merely weird languages. He probably considers them
about equivalent in power to Blub, but with all this other hairy stuff
thrown in as well. Blub is good enough for him, because he thinks in
Blub.
When we switch to the point of view of a programmer using any of the
languages higher up the power continuum, however, we find that he in
turn looks down upon Blub. How can you get anything done in Blub? It
doesn't even have y.
By induction, the only programmers in a position to see all the
differences in power between the various languages are those who
understand the most powerful one. (This is probably what Eric Raymond
meant about Lisp making you a better programmer.) You can't trust the
opinions of the others, because of the Blub paradox: they're satisfied
with whatever language they happen to use, because it dictates the way
they think about programs."
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> Sounds like "Blub" to me:
> http://www.paulgraham.com/avg.html
It never occurs to Lisp programmers that Lisp, too, might be a Blub.
On 2006-12-16 08:21:59 -0500, Paul Rubin <·············@NOSPAM.invalid> said:
> It never occurs to Lisp programmers that Lisp, too, might be a Blub.
Of course it does - Thats why we try ocaml and haskell etc. It's just
that we don't see the useful features of these languages as being
sufficiently useful to compensate for their lack of the ability to
easily do syntactic abstractions over a uniform syntax. There's no
question that other languages have some features that common lisp does
not (and vice versa). Lispers just can't abide being locked into a
particular paradigm because a language doesn't have the basic features
(macros and uniform syntax) necessary to provide new paradigms for
ourselves when needed or wanted.
For example, a common lisp with optional static typing on demand would
be strictly more expressive than common lisp. But, take say, haskell;
haskell's static typing is not optional (you can work around it, but
you have to go out of your way to do so); haskell's pure functional
semantics are not optional (again, workarounds possible to a limited
extent). This requires you to conceive your problem solution (i.e.,
program) within the framework of a particular paradigm. This lock-in to
a particular paradigm, however powerful, is what makes any such
language strictly less expressive than one with syntactic abstraction
over a uniform syntax.
Raffael Cavallaro ha escrito:
> This lock-in to
> a particular paradigm, however powerful, is what makes any such
> language strictly less expressive than one with syntactic abstraction
> over a uniform syntax.
Right, but it would be also remarked that there is not reason to
ignoring the development and implementation of specific syntaxes,
paradigms, etc. optimized to specialized (sub)fields of discourse.
If all you need is basic arithmetics and 'static' data structures,
optimization � la Python Y = a + b * c gets sense in most of cases.
If you are developing symbolic software where data structures as highly
'dinamic' and where you would wait something more than sums, divisions,
sines and cosines, and some numeric differentials then the parens
automatically gets sense.
Using LISP-like syntax for everything would be so stupid as using
quantum mechanics for billiards.
Using LISP-like syntax for everything would be so stupid as using
quantum mechanics for billiards.
Claiming that LISP parens are Stupid, Superfluous, or Silly just
because you do not need them in your limited field of discourse, would
be so stupid as those people thinking that just because they use
classical mechanics at the macro scale and works for them, then
classical mechanics would also work at the atomic scale [*].
[*] Even today, after 100 years some people think that quantum
mechanics is Stupid, Superfluous, or Silly and some classical
formulation will replace.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> > It never occurs to Lisp programmers that Lisp, too, might be a Blub.
>
> Of course it does - Thats why we try ocaml and haskell etc. It's just
> that we don't see the useful features of these languages as being
> sufficiently useful to compensate for their lack of the ability to
> easily do syntactic abstractions over a uniform syntax.
That sounds to me like a Blub programmer speaking.
> For example, a common lisp with optional static typing on demand would
> be strictly more expressive than common lisp. But, take say, haskell;
> haskell's static typing is not optional (you can work around it, but
> you have to go out of your way to do so); haskell's pure functional
> semantics are not optional (again, workarounds possible to a limited
> extent). This requires you to conceive your problem solution (i.e.,
> program) within the framework of a particular paradigm. This lock-in
> to a particular paradigm, however powerful, is what makes any such
> language strictly less expressive than one with syntactic abstraction
> over a uniform syntax.
Incorrect, I believe. The above is like saying Lisp's lack of
optional manual storage allocation and machine pointers makes Lisp
less powerful. It's in fact the absence of those features that lets
garbage collection work reliably. Reliable GC gets rid of a large and
important class of program errors and makes possible programming in a
style that relies on it. You can make languages more powerful by
removing features as well as by adding them. This is what Haskell
does, with its functional purity. Haskell's lazy evaluation semantics
pretty much depend on the purity.
See also SPJ's papers on composable memory transactions in Haskell:
http://research.microsoft.com/~simonpj/papers/stm/index.htm
These transactions rely on Haskell's pure functional semantics and if
I understand correctly, can't be implemented reliably without it. And
just like GC gets rid of a large class of pointer and storage
allocation errors, composable transactions in concurrent programs get
rid of lock-related errors, traditionally a huge source of problems in
real-world code.
Paul Rubin wrote:
> Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> > For example, a common lisp with optional static typing on demand would
> > be strictly more expressive than common lisp. But, take say, haskell;
> > haskell's static typing is not optional (you can work around it, but
> > you have to go out of your way to do so); haskell's pure functional
> > semantics are not optional (again, workarounds possible to a limited
> > extent). This requires you to conceive your problem solution (i.e.,
> > program) within the framework of a particular paradigm. This lock-in
> > to a particular paradigm, however powerful, is what makes any such
> > language strictly less expressive than one with syntactic abstraction
> > over a uniform syntax.
>
> Incorrect, I believe. The above is like saying Lisp's lack of
> optional manual storage allocation and machine pointers makes Lisp
> less powerful.
That is true. By itself, that feature makes Lisp less poweful for
real-world software dev, which is why we have implementation-defined
escape hatches for that sort of thing.
> It's in fact the absence of those features that lets
> garbage collection work reliably.
This is a bad analogy to the bondage-and-discipline of purely
functional languages.
The removal for the need for manual object lifetime computation does
not cause a whole class of useful programs to be rejected.
In fact, all previously correct programs continue to work as before,
and in addition, some hitherto incorrect programs become correct.
That's an increase in power: new programs are possible without losing
the old ones.
Wheas programs can't be made to conform to the pure functional paradigm
by adjusting the semantics of some API function. Programs which don't
conform have to be rejected,
> Reliable GC gets rid of a large and
> important class of program errors and makes possible programming in a
> style that relies on it.
Right. GC gets rid of /program errors/. Pure functional programming
gets rid of /programs/.
> You can make languages more powerful by removing features as well as by adding them.
Note that changing the storage liberation request from an imperative to
a hint isn't the removal of a feature. It's the /addition/ of a
feature. The new feature is that objects can still be reliably used
after the implementation was advised by the program that they are no
longer needed. Programs which do this are no longer buggy. Another new
feature is that programs can fail to advise the implementation that
some objects are no longer needed, without causing a leak, so these
programs are no longer buggy. The pool of non-buggy programs has
increased without anything being rejected.
Okay, that is not quite true, which brings me back to my very first
point. GC does (effectively) reject programs which do nasty things with
pointers. For instance, hiding pointers from being visible to GC.
However, such things can be made to coexist with GC. GC and non-GC
stuff /can/ and does, for pragmatic reasons, live in the same image.
Likewise, functional programming and imperative programming can also
coexist in the same image.
/Pure/ functional programming isn't about adding the feature of
functional programming. It's about eliminating other features which
are not functional programming.
"Kaz Kylheku" <········@gmail.com> writes:
> > Incorrect, I believe. The above is like saying Lisp's lack of
> > optional manual storage allocation and machine pointers makes Lisp
> > less powerful.
>
> That is true. By itself, that feature makes Lisp less poweful for
> real-world software dev, which is why we have implementation-defined
> escape hatches for that sort of thing.
> ...
> This is a bad analogy to the bondage-and-discipline of purely
> functional languages. [/] The removal for the need for manual object
> lifetime computation does not cause a whole class of useful programs
> to be rejected.
Did you just say two conflicting things? It's that very rejection
that necessitates the escape hatches.
> In fact, all previously correct programs continue to work as before,
> and in addition, some hitherto incorrect programs become correct.
> That's an increase in power: new programs are possible without losing
> the old ones.
There's more to power than making more programs possible. We also
want to be able to distinguish correct programs from incorrect ones.
Lisp has the power to eliminate a large class of pointer-related
errors that are common in C programs, so Lisp is more powerful than C
in that regard. Increasing the number of programs one can write in
the unfounded hope that they might be correct is just one way to
increase power. You can sometimes do that by adding features to the
language. Increasing the number of programs you can write that are
demonstrably free of large classes of errors is another way to
increase power. You can sometimes do that by REMOVING features.
That's what the Lisp holdouts don't seem to understand.
> Right. GC gets rid of /program errors/. Pure functional programming
> gets rid of /programs/.
GC also gets rid of programs. There are programs you can write in C
but not in Lisp, like device drivers that poke specific machine
addresses.
> /Pure/ functional programming isn't about adding the feature of
> functional programming. It's about eliminating other features which
> are not functional programming.
It seems to me that Haskell does some mumbo-jumbo to be purely
functional only in some theoretical sense. In practice, its purity is
enforced only in functions with a certain class of type signatures
(i.e. most functions). You can write impure code when needed, by
adding certain monads to the type signature of your function. The
point is Haskell's static type system can then tell exactly which
parts of your code are pure and which are impure. If you do something
impure in a funciton with the wrong signature, you get a compile time
error. You can choose to write in a style that separates pure from
impure functional code in a Lisp program, but the compiler can't check
it for you. If you get it wrong and call an impure function from your
"pure" code (say in a lock-free concurrent program), all kinds of
obscure bugs can result, like pointer errors in a C program.
Paul Rubin wrote:
>
> [...] There are programs you can write in C
> but not in Lisp, like device drivers that poke specific machine
> addresses.
>
I should assume you meant Common Lisp, but there isn't really any
reason you couldn't
(poke destination (peek source))
in some version of Lisp that was meant for writing device drivers
(perhaps under a Lisp machine or something).
SIOD actually has (%%% memref address) for peek.
·······@gmail.com writes:
> I should assume you meant Common Lisp, but there isn't really any
> reason you couldn't
>
> (poke destination (peek source))
That breaks the reliability of GC. I'd say you're no longer writing
in Lisp if you use something like that. Writing in this "augmented
Lisp" can be ok if well-localized and done carefully, but you no
longer have the guarantees that you get from unaugmented Lisp. By
adding one feature you've removed another.
Paul Rubin wrote:
> ·······@gmail.com writes:
> > I should assume you meant Common Lisp, but there isn't really any
> > reason you couldn't
> >
> > (poke destination (peek source))
>
> That breaks the reliability of GC. I'd say you're no longer writing
> in Lisp if you use something like that. Writing in this "augmented
> Lisp" can be ok if well-localized and done carefully, but you no
> longer have the guarantees that you get from unaugmented Lisp. By
> adding one feature you've removed another.
I don't agree. The addresses (mapped registers or DMA or whatever) you
peak and poke in a device driver aren't going to be managed by the
garbage collector.
Even regarding interupts, I don't see a problem without a solution:
(with-interupts-and-garbage-collection-disabled
(poke destination (peek source))
You could even allocate memory (cons cells for instance) with the
interupts disabled, but it would be considered the same bad practice
that it would be if you did that in C.
Cheers,
-Scott
·······@gmail.com writes:
> Even regarding interupts, I don't see a problem without a solution:
> (with-interupts-and-garbage-collection-disabled
> (poke destination (peek source))
It's not just GC or interrupts, it's the possibility of clobbering the
Lisp heap. If the peek/poke addresses are restricted to some i/o
region as Bill suggests, then the above approach may be reasonable.
Paul Rubin wrote:
> ·······@gmail.com writes:
> > Even regarding interupts, I don't see a problem without a solution:
> > (with-interupts-and-garbage-collection-disabled
> > (poke destination (peek source))
>
> It's not just GC or interrupts, it's the possibility of clobbering the
> Lisp heap. If the peek/poke addresses are restricted to some i/o
> region as Bill suggests, then the above approach may be reasonable.
So don't (poke (random) value). That would be obvious to anyone
capable of writing a device driver in C or Lisp or Oberon or ....
Cheers,
-Scott
·······@gmail.com writes:
> So don't (poke (random) value). That would be obvious to anyone
> capable of writing a device driver in C or Lisp or Oberon or ....
Similarly in C programs, don't do
*random = 0;
Avoiding that is easier said than done. C programs suffer endless
bugs of that type.
Paul Rubin wrote:
> ·······@gmail.com writes:
> > So don't (poke (random) value). That would be obvious to anyone
> > capable of writing a device driver in C or Lisp or Oberon or ....
>
> Similarly in C programs, don't do
>
> *random = 0;
>
> Avoiding that is easier said than done. C programs suffer endless
> bugs of that type.
I see your point. Since that kind of error is less likely in Lisp, and
we want less bugs in our device drivers, device drivers should be
written in Lisp. Only using low level peeks and pokes where absolutely
necessary. It makes good sense, and I'm glad you talked me into it.
:-)
Cheers,
-Scott
On Mon, 18 Dec 2006 05:19:49 +0100, <········@NOSPAM.invalid>> wrote:
> ·······@gmail.com writes:
>> So don't (poke (random) value). That would be obvious to anyone
>> capable of writing a device driver in C or Lisp or Oberon or ....
>
> Similarly in C programs, don't do
>
> *random = 0;
>
> Avoiding that is easier said than done. C programs suffer endless
> bugs of that type.
Don't know where you get that idea.
I have used a bounds checker in C++ since 1990..
If I set a pointer to a space on the heap that isn't allocated
I would get a error. If I forgot to deallocate it it would
warn me when the program terminates. Then I just jump to the place
in the file where the memory reference was allocated. Admitably
it could be a great problem if such tools weren't available, but that
hasn't
been the case in years.
Much worse are buffer overflow errors. Functions that don't check buffer
constraints. But then most modern compilers can turn that on too.
Wanna overwrite the return stack. A cookie at the end checks for this
as well.
As for old libraries like string(s) modern replacement's are available
that check constraints. For that matter C++'s type checks are much stricter
than C's.
In fact it hasn't been much a problem for a long time.
(Debugging template error's now that is a pain..)
Incremental linkers and fast compiler time also makes incremental
developement
possible.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Paul Rubin <·············@NOSPAM.invalid> writes:
> ·······@gmail.com writes:
>> I should assume you meant Common Lisp, but there isn't really any
>> reason you couldn't
>>
>> (poke destination (peek source))
>
> That breaks the reliability of GC. I'd say you're no longer writing
> in Lisp if you use something like that. Writing in this "augmented
> Lisp" can be ok if well-localized and done carefully, but you no
> longer have the guarantees that you get from unaugmented Lisp. By
> adding one feature you've removed another.
Whatever do you mean? The portion of memory used for memory-mapped
registers is simply excluded from GC; everything else works as normal.
All modern Lisps (yes, *Common* Lisps) support a foreign-function
interface to talk to C libraries. Data involved with these kinds of
interface is ignored by the GC, for obvious reasons. Do you claim
that these implementations are not truly Lisps?
--
There are three doors. Behind one is a tiger. Behind another: the
Truth. The third is a closet... choose wisely.
E-mail me at:
(remove-if (lambda (c) (find c ";:-")) ···········@r;p:i-.:e-d:u;")
Bill Atkins <························@not-a-real-domain.com> writes:
> Whatever do you mean? The portion of memory used for memory-mapped
> registers is simply excluded from GC; everything else works as normal.
Well ok, if the peek and poke functions validate the addresses.
> All modern Lisps (yes, *Common* Lisps) support a foreign-function
> interface to talk to C libraries. Data involved with these kinds of
> interface is ignored by the GC, for obvious reasons. Do you claim
> that these implementations are not truly Lisps?
I think usually those objects are simply treated as opaque by the GC
and the contents are inaccessible except through FFI calls. You can't
have the Lisp code running amuck trampling things through naked
pointers. Obviously the foreign function can trample things but it's
not written in Lisp.
Paul Rubin <·············@NOSPAM.invalid> writes:
> ·······@gmail.com writes:
> > I should assume you meant Common Lisp, but there isn't really any
> > reason you couldn't
> >
> > (poke destination (peek source))
>
> That breaks the reliability of GC. I'd say you're no longer writing
> in Lisp if you use something like that.
Please note: GC is not part of CL's definition. It is likely not part
of any Lisp's definition (for reasons that should be obvious), and for
the same reasons likely not part of any language's definition. So,
your point here is actually a category error...
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> Please note: GC is not part of CL's definition. It is likely not part
> of any Lisp's definition (for reasons that should be obvious), and for
> the same reasons likely not part of any language's definition.
Really? So how do you write a portable program in CL, that is to run
for unbounded lengths of time?
- Anders
Anders J. Munch wrote:
> jayessay wrote:
> > Please note: GC is not part of CL's definition. It is likely not part
> > of any Lisp's definition (for reasons that should be obvious), and for
> > the same reasons likely not part of any language's definition.
>
> Really? So how do you write a portable program in CL, that is to run
> for unbounded lengths of time?
You can't.
The thing about the spec not defining GC is almost a bit of humour.
No-one would use an implementation with no GC.
The issue with specifying it is: How would you do it? The memory used
by a program is an aspect of the language implementation and the system
the program is running on, so how can it be defined in a useful way?
You could say for example "Storage allocated for an object is released
when the object is no longer visible and memory usage is high". But
how do you define how high memory usage should be? You could say when
memory is almost exhausted, even that is difficult to define. Then you
could have the situation where someone creates a lisp compiler than
emits FPGA netlists, how do you check something like this?
None of this would be in the spirit of the spec, which doesn't even
define memory AFAIK. The spec deals entirely in matters of the
language and it's appearance to the programmer. For what it's worth I
think the C spec is the same, and says nothing about actual memory
usage.
"Rob Thorpe" <·······@realworldtech.com> writes:
> Anders J. Munch wrote:
>> jayessay wrote:
>> > Please note: GC is not part of CL's definition. It is likely not part
>> > of any Lisp's definition (for reasons that should be obvious), and for
>> > the same reasons likely not part of any language's definition.
>>
>> Really? So how do you write a portable program in CL, that is to run
>> for unbounded lengths of time?
>
> You can't.
You can. Just use reversible operations.
Or use pre-allocated objects. Yes, that means that you implement your
own memory management or garbage collector, but this would be portable.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Do not adjust your mind, there is a fault in reality"
-- on a wall many years ago in Oxford.
Pascal Bourguignon wrote:
> "Rob Thorpe" <·······@realworldtech.com> writes:
> > Anders J. Munch wrote:
> >> jayessay wrote:
> >> > Please note: GC is not part of CL's definition. It is likely not part
> >> > of any Lisp's definition (for reasons that should be obvious), and for
> >> > the same reasons likely not part of any language's definition.
> >>
> >> Really? So how do you write a portable program in CL, that is to run
> >> for unbounded lengths of time?
> >
> > You can't.
>
> You can. Just use reversible operations.
>
> Or use pre-allocated objects. Yes, that means that you implement your
> own memory management or garbage collector, but this would be portable.
I don't think there is any gaurantee in the spec that says that even
doing nothing at all doesn't allocate more memory. AFAIK a conforming
implementation could leak a fixed amount of memory per second.
Rob Thorpe wrote:
> Anders J. Munch wrote:
>> Really? So how do you write a portable program in CL, that is to
>> run for unbounded lengths of time?
>
> You can't.
>
> The thing about the spec not defining GC is almost a bit of humour.
> No-one would use an implementation with no GC.
>
> The issue with specifying it is: How would you do it? The memory
> used by a program is an aspect of the language implementation and
> the system the program is running on, so how can it be defined in a
> useful way?
Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.
Require that u(t) is a member of O(t -> max{t'<=t: r(t')})
There. That wasn't so hard, was it?
- Anders
Anders J. Munch wrote:
> Rob Thorpe wrote:
> > Anders J. Munch wrote:
> >> Really? So how do you write a portable program in CL, that is to
> >> run for unbounded lengths of time?
> >
> > You can't.
> >
> > The thing about the spec not defining GC is almost a bit of humour.
> > No-one would use an implementation with no GC.
> >
> > The issue with specifying it is: How would you do it? The memory
> > used by a program is an aspect of the language implementation and
> > the system the program is running on, so how can it be defined in a
> > useful way?
>
> Let u(t) be the actual memory used by the program at time t.
> Let r(t) be the size of reachable memory at time t.
>
> Require that u(t) is a member of O(t -> max{t'<=t: r(t')})
>
> There. That wasn't so hard, was it?
That's quite a clever definition actually.
But, let's say I have a lisp machine. It has an unusual architecture,
it's made entirely of SRAM cells of ~9bits. Sometimes these cells are
used as storage, sometimes their contents represent logic circuits and
the routing between them is configured to form them into a processor.
Please tell me what reachable memory is ;). (The above processor is
not science fiction, it could easily be done with FPGAs)
I suppose a solution would be:-
If the lisp implementation runs on a fixed processor that has separate
storage then ...
Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.
...
Rob Thorpe wrote:
> Anders J. Munch wrote:
>> Let u(t) be the actual memory used by the program at time t.
>> Let r(t) be the size of reachable memory at time t.
>>
>> Require that u(t) is a member of O(t -> max{t'<=t: r(t')})
>>
>> There. That wasn't so hard, was it?
>
> That's quite a clever definition actually.
> But, let's say I have a lisp machine. It has an unusual architecture,
> it's made entirely of SRAM cells of ~9bits. Sometimes these cells are
> used as storage, sometimes their contents represent logic circuits and
> the routing between them is configured to form them into a processor.
> Please tell me what reachable memory is ;). (The above processor is
> not science fiction, it could easily be done with FPGAs)
Reachable memory is the set of interpreter objects (conses, closures, scopes,
atoms and what have you) reachable from from some appropriately defined root
set. It can be unambiguously defined with respect to a virtual machine, with no
regard to how actual implementations represent these things.
For actual memory use, a simple byte count would do fine. If code and data are
intermingled, just use the combined size of both of them.
If you're worried about comparing incompatible units, don't be: apples and
oranges compare just fine under big-Oh.
- Anders
Anders J. Munch wrote:
> Rob Thorpe wrote:
> > Anders J. Munch wrote:
> >> Let u(t) be the actual memory used by the program at time t.
> >> Let r(t) be the size of reachable memory at time t.
> >>
> >> Require that u(t) is a member of O(t -> max{t'<=t: r(t')})
> >>
> >> There. That wasn't so hard, was it?
> >
> > That's quite a clever definition actually.
> > But, let's say I have a lisp machine. It has an unusual architecture,
> > it's made entirely of SRAM cells of ~9bits. Sometimes these cells are
> > used as storage, sometimes their contents represent logic circuits and
> > the routing between them is configured to form them into a processor.
> > Please tell me what reachable memory is ;). (The above processor is
> > not science fiction, it could easily be done with FPGAs)
>
> Reachable memory is the set of interpreter objects (conses, closures, scopes,
> atoms and what have you) reachable from from some appropriately defined root
> set. It can be unambiguously defined with respect to a virtual machine, with no
> regard to how actual implementations represent these things.
Yes.
> For actual memory use, a simple byte count would do fine. If code and data are
> intermingled, just use the combined size of both of them.
Well, in my example the code, the data and the processor are
intermingled. Still you could do it this way. But, what would happen
for example if on a normal machine someone wrote a program that
generated lots of functions that it never used, would it have to be
detected by the GC. This is hard to do. The solution is probably to
define the root set only in terms of data.
> If you're worried about comparing incompatible units, don't be: apples and
> oranges compare just fine under big-Oh.
Yes. Thank you for comprehensively out-arguing me.
I'll give one last reason why it may not be a good thing to define:
reference counting. Some people want to use refcounts, and believe
that under certain circumstances they provide better performance than
GC. I don't know if they're right, I suspect they are for some limited
circumstances. A normal ref-count system can't be gauranteed to have
no memory holes introduced by loops in the data. But, if the
programmer causes no loops to come into being then he/she is safe. An
implementation that used refcounting might not be of much general use,
but for specific purposes, embedded programming for example, it might
be useful.
Anders J. Munch wrote:
> jayessay wrote:
> > Please note: GC is not part of CL's definition. It is likely not part
> > of any Lisp's definition (for reasons that should be obvious), and for
> > the same reasons likely not part of any language's definition.
>
> Really? So how do you write a portable program in CL, that is to run
> for unbounded lengths of time?
>
> - Anders
Write it, and depend on the implementation to do its job well, and
complain to the implementors if it doesn't.
How do you write a portable program in C that is to run for unbounded
lengths of time? Even if you religiously call free() on every
malloc()'d block, you could eventually fragment memory enough that the
allocator might eventually fail. You can exceed the VM capacity. The OS
could decide to crash periodically. The power supply could fail, the
sun could progress to the red giant phase...
The real answer is that these are not issues for the language
definition, but for the implementor.
"Anders J. Munch" <····@jmunch.dk> writes:
> jayessay wrote:
> > Please note: GC is not part of CL's definition. It is likely not part
> > of any Lisp's definition (for reasons that should be obvious), and for
> > the same reasons likely not part of any language's definition.
>
> Really?
Really.
> So how do you write a portable program in CL, that is to run
> for unbounded lengths of time?
Make it non-consing (like for any such program in any language). Of
course, this won't guarantee success as the implementation or OS or
... may leak or other wise cons memory even if your program doesn't.
I'm surprised there are people out there that find this interesting
let alone surprising.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
<·······@gmail.com> wrote:
+---------------
| Paul Rubin wrote:
| > [...] There are programs you can write in C but not in Lisp,
| > like device drivers that poke specific machine addresses.
|
| I should assume you meant Common Lisp, but there isn't really any
| reason you couldn't
| (poke destination (peek source))
| in some version of Lisp that was meant for writing device drivers
| (perhaps under a Lisp machine or something).
+---------------
I do this kind of thing *every day* in CMUCL!! It's my primary
user-mode hardware debugging tool. Here's a typical utility function:
;;; Used for things like polling for a "done" flag.
;;; BUG: Assumes contents of ADDR will change within fixnum polls.
(defun spin-until-change (addr)
(declare (optimize (speed 3) (debug 0) (safety 0)))
(loop with v0 of-type (unsigned-byte 32) = (r32 addr)
with counts fixnum = 0
while (= v0 (r32 addr))
do (setf counts (the fixnum (1+ counts)))
finally (return counts)))
+---------------
| SIOD actually has (%%% memref address) for peek.
+---------------
CMUCL has SYSTEM:SAP-REF-{8,16,32} and SETFs of same. The R32
above is just my convenience wrapper around SYSTEM:SAP-REF-32:
(declaim (inline r32))
(defun r32 (addr)
(declare (optimize (speed 3) (debug 0) (safety 0)))
(system:sap-ref-32 (system:int-sap addr) 0))
(defun w32 (addr &rest values)
(declare (optimize (speed 3) (debug 0) (safety 0)))
(loop for i fixnum from 0 by 4
and v of-type (unsigned-byte 32) in values
do (setf (system:sap-ref-32 (system:int-sap addr) i) v))
(values))
Most other Common Lisp implementations surely have something similar.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Paul Rubin <·············@NOSPAM.invalid> writes:
>> In fact, all previously correct programs continue to work as before,
>> and in addition, some hitherto incorrect programs become correct.
>> That's an increase in power: new programs are possible without losing
>> the old ones.
>
> There's more to power than making more programs possible. We also
> want to be able to distinguish correct programs from incorrect ones.
> Lisp has the power to eliminate a large class of pointer-related
> errors that are common in C programs, so Lisp is more powerful than C
> in that regard. Increasing the number of programs one can write in
> the unfounded hope that they might be correct is just one way to
> increase power. You can sometimes do that by adding features to the
> language. Increasing the number of programs you can write that are
> demonstrably free of large classes of errors is another way to
> increase power. You can sometimes do that by REMOVING features.
> That's what the Lisp holdouts don't seem to understand.
>
>> Right. GC gets rid of /program errors/. Pure functional programming
>> gets rid of /programs/.
>
> GC also gets rid of programs. There are programs you can write in C
> but not in Lisp, like device drivers that poke specific machine
> addresses.
I'm sure this would be news to the people who wrote the operating
system for the Lisp machine.
What makes you think that a Lisp implementation couldn't provide this?
--
There are three doors. Behind one is a tiger. Behind another: the
Truth. The third is a closet... choose wisely.
(remove-if (lambda (c) (find c ";:-")) ···········@r;p:i-.:e-d:u;")
Bill Atkins <························@not-a-real-domain.com> writes:
> > GC also gets rid of programs. There are programs you can write in C
> > but not in Lisp, like device drivers that poke specific machine
> > addresses.
>
> I'm sure this would be news to the people who wrote the operating
> system for the Lisp machine.
That stuff is written in a special dialect of Lisp that doesn't have
regular Lisp semantics and doesn't have the usual Lisp functions,
IIRC. I think maybe you can't even use "cons". But my Orangenual is
currently in storage so I can't easily check.
Anyway I'm not willing to use "Lisp" to describe every language whose
surface syntax is S-expressions. That, as JWZ put it in another
context, is like trying to build a bookcase out of mashed potatoes.
Lisp means Common Lisp as defined by the ANSI standard. Otherwise all
languages are equally powerful as long as they have a way to inline
assembly code.
Paul Rubin schrieb:
> GC also gets rid of programs. There are programs you can write in C
> but not in Lisp, like device drivers that poke specific machine
> addresses.
You are talking about an ANSI Common Lisp implementation.
But nothing stops a vendor to deliver its CL with libs that support
the writing of device drivers.
When Naughty Dog programmed games for the Play Station 2 the used
Common Lisp to develop a Lisp called "GOAL" (Game Oriented Assembly
Lisp) that was specialized for writing PS2 games.
Andr�
--
Kaz Kylheku wrote:
> The removal for the need for manual object lifetime computation does
> not cause a whole class of useful programs to be rejected.
Sometimes you must be able to guarantee that a resource has been disposed
before you can continue. That is why we have finalisers in OCaml and
dispose in .NET (to manage external resources).
> In fact, all previously correct programs continue to work as before,
Removing (external) resource allocation will break some programs.
> and in addition, some hitherto incorrect programs become correct.
> That's an increase in power: new programs are possible without losing
> the old ones.
It is a trade-off. Aside from managing external resources, GC has
performance implications that affect the design decisions of real-time
applications.
> Wheas programs can't be made to conform to the pure functional paradigm
> by adjusting the semantics of some API function. Programs which don't
> conform have to be rejected,
You can rephrase any impure program as a pure program (Turing).
>> Reliable GC gets rid of a large and
>> important class of program errors and makes possible programming in a
>> style that relies on it.
>
> Right. GC gets rid of /program errors/. Pure functional programming
> gets rid of /programs/.
Pure functional programming does not get rid of any programs.
Pure functional programming does get rid of program errors, e.g. concurrency
issues.
>> You can make languages more powerful by removing features as well as by
>> adding them.
>
> Note that changing the storage liberation request from an imperative to
> a hint isn't the removal of a feature. It's the /addition/ of a
> feature. The new feature is that objects can still be reliably used
> after the implementation was advised by the program that they are no
> longer needed. Programs which do this are no longer buggy. Another new
> feature is that programs can fail to advise the implementation that
> some objects are no longer needed, without causing a leak, so these
> programs are no longer buggy. The pool of non-buggy programs has
> increased without anything being rejected.
You have rejected all programs that rely upon a resource being disposed
before a certain point.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
On Sun, 17 Dec 2006 00:19:40 +0100, <········@NOSPAM.invalid>> wrote:
>
> Incorrect, I believe. The above is like saying Lisp's lack of
> optional manual storage allocation and machine pointers makes Lisp
> less powerful. It's in fact the absence of those features that lets
> garbage collection work reliably. Reliable GC gets rid of a large and
> important class of program errors and makes possible programming in a
> style that relies on it.
Truth with modifications. The foreign function library of most systems does
allow manual storage. If it didn't it would go into conniptions when
talking
to C where stored values are never moved.
> You can make languages more powerful by
> removing features as well as by adding them. This is what Haskell
> does, with its functional purity. Haskell's lazy evaluation semantics
> pretty much depend on the purity.
>
Some people like it some people don't.
(I should add I have never put serious effort into learning Haskell so my
opinion
should be taken with a grain of salt.)
Like many lispers I use multiple paradigms.
I have similar problems with SmallTalk by the way.
> See also SPJ's papers on composable memory transactions in Haskell:
>
> http://research.microsoft.com/~simonpj/papers/stm/index.htm
>
> These transactions rely on Haskell's pure functional semantics and if
> I understand correctly, can't be implemented reliably without it. And
> just like GC gets rid of a large class of pointer and storage
> allocation errors, composable transactions in concurrent programs get
> rid of lock-related errors, traditionally a huge source of problems in
> real-world code.
These days modern CPU's have multiple cores.
Parallelism is obviously easier to accomplish with a functional style
so I might take a closer look in the near future.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Raffael Cavallaro wrote:
> Of course it does - Thats why we try ocaml and haskell etc. It's just
> that we don't see the useful features of these languages as being
> sufficiently useful to compensate for their lack of the ability to
> easily do syntactic abstractions over a uniform syntax.
That applies to the Lispers who've tried other languages and stayed with
Lisp.
> There's no
> question that other languages have some features that common lisp does
> not (and vice versa). Lispers just can't abide being locked into a
> particular paradigm because a language doesn't have the basic features
> (macros and uniform syntax) necessary to provide new paradigms for
> ourselves when needed or wanted.
Why do you think that uniform syntax is necessary to provide new paradigms
when it is equivalent to infix syntax?
> For example, a common lisp with optional static typing on demand would
> be strictly more expressive than common lisp. But, take say, haskell;
> haskell's static typing is not optional (you can work around it, but
> you have to go out of your way to do so); haskell's pure functional
> semantics are not optional (again, workarounds possible to a limited
> extent).
In what way is Haskell's support for imperative programming limited?
> This requires you to conceive your problem solution (i.e.,
> program) within the framework of a particular paradigm. This lock-in to
> a particular paradigm, however powerful, is what makes any such
> language strictly less expressive than one with syntactic abstraction
> over a uniform syntax.
Can you give an example of a Lisp macro that does something useful that you
can't do in these other languages?
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
On 2006-12-16 13:58:37 -0500, Jon Harrop <···@ffconsultancy.com> said:
> Why do you think that uniform syntax is necessary to provide new paradigms
> when it is equivalent to infix syntax?
Because it doesn't require one to write a parser for each new syntax
for each new paradigm.
> In what way is Haskell's support for imperative programming limited?
It requires one to frame everything in functional terms or to jump
through the hoop of monads.
> Can you give an example of a Lisp macro that does something useful that you
> can't do in these other languages?
It isn't a question of "can't do in these other languages," it's a
matter of "can't do as easily in these other languages." Look at kenny
tilton's cells. Its a dataflow paradigm built largely of macros. It
goes completely against the semantics of haskell - cells is all about
the eager evaluation of side effecting state mutation. Could you do it
in haskell? Yes, in the greenspun/turing-completeness sense, but not
nearly as easily as in common lisp, because the very paradigm - eager
evaluation combined with side effecting state mutation - goes against
the basic semantics of haskell. You'd have to jump through extra hoops
to build a system whose very nature contradicts two of the semantic
foundations of haskell - laziness and absense of side effects.
Then there's the issue of the new syntax. Easy to build in lisp without
learning another language - lisp macros use lisp. What little I've seen
of caml4p looks like perlesque line noise. Ultimately I think that the
defaults of both haskell and ocaml - functional, static typing,
non-uniform syntax - are things I don't want as defaults, but as
options for later in the development of only certain pieces of code. I
don't want to be required to jump through the pure-functional,
must-use-monads-for-any-side-effects, static-type, non-uniform-syntax
hoops to express my ideas. It makes me less flexible in dealing with
individual parts of a program differently.
Raffael Cavallaro wrote:
> On 2006-12-16 13:58:37 -0500, Jon Harrop <···@ffconsultancy.com> said:
>> Why do you think that uniform syntax is necessary to provide new
>> paradigms when it is equivalent to infix syntax?
>
> Because it doesn't require one to write a parser for each new syntax
> for each new paradigm.
Why not use a single, extensible parser, e.g. camlp4?
>> In what way is Haskell's support for imperative programming limited?
>
> It requires one to frame everything in functional terms or to jump
> through the hoop of monads.
Can you give some example code demonstrating these hoops?
>> Can you give an example of a Lisp macro that does something useful that
>> you can't do in these other languages?
>
> It isn't a question of "can't do in these other languages," it's a
> matter of "can't do as easily in these other languages."
Yes, absolutely.
> Look at kenny
> tilton's cells. Its a dataflow paradigm built largely of macros. It
> goes completely against the semantics of haskell - cells is all about
> the eager evaluation of side effecting state mutation.
Perhaps that is because Cells is written in a language (Lisp) that forces
you to jump through hoops to get lazy evaluation?
The Cells project appears to deal with a graph (in the graph-theoretic
sense). There is nothing inherently side-effecting about that and the
problem that Cells is trying to solve seems to be fundamentally lazy:
update cells only when necessary.
> Could you do it
> in haskell? Yes, in the greenspun/turing-completeness sense, but not
> nearly as easily as in common lisp, because the very paradigm - eager
> evaluation combined with side effecting state mutation - goes against
> the basic semantics of haskell.
Can you give some evidence to back that up, e.g. a program that solves a
problem like this in Haskell but is more convoluted that the Lisp?
> You'd have to jump through extra hoops
> to build a system whose very nature contradicts two of the semantic
> foundations of haskell - laziness and absense of side effects.
What if eager impurity isn't the "very nature" of the problem but, rather,
is the very nature of Tilton's chosen solution?
> Then there's the issue of the new syntax. Easy to build in lisp without
> learning another language - lisp macros use lisp.
You can use Lisp macros to add some of the features found in modern FPLs.
Once you've done that, users of your modern Lisp variant must learn how to
use your macros. How is that better than learning a modern FPL directly?
> What little I've seen
> of caml4p looks like perlesque line noise. Ultimately I think that the
> defaults of both haskell and ocaml - functional, static typing,
> non-uniform syntax - are things I don't want as defaults, but as
> options for later in the development of only certain pieces of code. I
> don't want to be required to jump through the pure-functional,
> must-use-monads-for-any-side-effects, static-type, non-uniform-syntax
> hoops to express my ideas. It makes me less flexible in dealing with
> individual parts of a program differently.
You can use tools like camlp4 to generate uniform syntax from OCaml's
syntax. You can also use the -dlambda to output OCaml's Lisp-like
intermediate representation.
Why do you think that uniform syntax like this Lisp:
(defun intersect (orig dir scene)
(labels ((aux (lam normal scene)
(let* ((center (sphere-center scene))
(lamt (ray-sphere orig
dir
center
(sphere-radius scene))))
(if (>= lamt lam)
(values lam normal)
(etypecase scene
(group
(dolist (kid (group-children scene))
(setf (values lam normal)
(aux lam normal kid)))
(values lam normal))
(sphere
(values lamt (unitise
(-v (+v orig (*v lamt dir))
center)))))))))
(aux infinity zero scene)))
is better than syntax with conventional mathematical grammar, like this
equivalent OCaml:
let rec intersect orig dir (lambda, _ as hit) (center, radius, scene) =
let lambda' = ray_sphere orig dir center radius in
if lambda' >= lambda then hit else match scene with
| Sphere -> lambda', unitise (orig +| lambda' *| dir -| center)
| Group scenes -> List.fold_left (intersect orig dir) hit scenes
From my point of view, people started with Lisp and used its macros to add
new syntax to the language and they got Haskell and OCaml. After all,
Haskell and OCaml are more popular that any given Lisp variant with similar
features (e.g. pattern matching), AFAIK.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
On 2006-12-17 07:54:28 -0500, Jon Harrop <···@ffconsultancy.com> said:
> What if eager impurity isn't the "very nature" of the problem but, rather,
> is the very nature of Tilton's chosen solution?
That's the whole point which you keep missing - that a programming
language is expressive precisely to the extent that it allows you to
express the solution in the *programmer's* chosen form, not the
paradigm imposed by the language.
You look down your nose at cells, but if that's the way kenny conceived
of the problem - as a graph of changing state, why should he be forced
to reconceptualize it according to someone else's notion of programming
correctness (be that pure functional or any other paradigm)?
By asking this question you've implicitly admitted that to solve it *as
he thought of it* in a pure functional language would require
reconceptualizing it (i.e., the aforementioned "jumping through
hoops"). We don't want to reconceptualize everything according to a
particular paradigm, we want the flexibility to write the solution to
the problem in the terms we think and talk about it, not the
procrustean bed of pure functional semantics.
Raffael Cavallaro wrote:
> On 2006-12-17 07:54:28 -0500, Jon Harrop <···@ffconsultancy.com> said:
>> What if eager impurity isn't the "very nature" of the problem but,
>> rather, is the very nature of Tilton's chosen solution?
>
> That's the whole point which you keep missing - that a programming
> language is expressive precisely to the extent that it allows you to
> express the solution in the *programmer's* chosen form, not the
> paradigm imposed by the language.
That is the ideal, yes.
In practice, different languages encourage you to use different solutions.
For example, when faced with a problem best solved using pattern matching
in Lisp, most Lisp programmers would reinvent an ad-hoc, informally
specified and bug-ridden pattern matcher of their own. Do you not think
that Lispers typically "compile" their high-level algorithms into low-level
Lisp constructs like COND or IF?
> You look down your nose at cells, but if that's the way kenny conceived
> of the problem - as a graph of changing state, why should he be forced
> to reconceptualize it according to someone else's notion of programming
> correctness (be that pure functional or any other paradigm)?
Kenny isn't being forced to do anything.
> By asking this question you've implicitly admitted that to solve it *as
> he thought of it* in a pure functional language would require
> reconceptualizing it (i.e., the aforementioned "jumping through
> hoops").
You are saying that solving it as he solved it requires a different
solution. How does that make Lisp any different to the next language?
> We don't want to reconceptualize everything according to a
> particular paradigm, we want the flexibility to write the solution to
> the problem in the terms we think and talk about it, not the
> procrustean bed of pure functional semantics.
Of the programming paradigms that can be implemented in Lisp, Lisp doesn't
exactly make them easy. Moreover, every time you pick a random Lisp library
off the wall to implement some feature already found in most other
languages, you fragment the already tiny user base into even fewer people.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
On 2006-12-17 12:49:46 -0500, Jon Harrop <···@ffconsultancy.com> said:
> For example, when faced with a problem best solved using pattern matching
> in Lisp, most Lisp programmers would reinvent an ad-hoc, informally
> specified and bug-ridden pattern matcher of their own.
No, I think most of us would use an exising lisp pattern matcher, like
cl-unification.
>
>> By asking this question you've implicitly admitted that to solve it *as
>> he thought of it* in a pure functional language would require
>> reconceptualizing it (i.e., the aforementioned "jumping through
>> hoops").
>
> You are saying that solving it as he solved it requires a different
> solution. How does that make Lisp any different to the next language?
Give kenny some credit for not being a complete idiot. Cells was
originally designed to keep UI elements in sync with an internal
application model. The UI domain is I/O, i.e., a side effect. To do
this lazily invites situations where an inherently unpredictable user
action forces a complex series of constraints to be computed before
anything can be displayed to the user, so the user must wait while the
lazy system catches up. To do this eagerly means that at any time, any
unpredictable user action will cause already computed state to be
displayed, because everything has been kept up to date automatically
all along.
I'm saying that he conceived of the problem in the most natural way -
state with mutations - and implemented it that way. He was not forced
by his language to reconceive it purely functionally, have haskell
implement the default lazy semantics, only to require the programmer to
find an escape hatch from this default laziness since what he really
wants is eager evaluation of side effects (i.e., I/O - syncing of model
state with GUI display).
People habitually think of the world as state and mutations of state.
We've been doing so for a minimum of tens of thousands of years, quite
possibly a million or more. People are good at thinking about mutation.
Maybe this should tell us something about the desirability of certain
programming language semantics and that referential transparency is a
bit overrated.
>
>> We don't want to reconceptualize everything according to a particular
>> paradigm, we want the flexibility to write the solution to
>> the problem in the terms we think and talk about it, not the
>> procrustean bed of pure functional semantics.
>
> Of the programming paradigms that can be implemented in Lisp, Lisp doesn't
> exactly make them easy. Moreover, every time you pick a random Lisp library
> off the wall to implement some feature already found in most other
> languages, you fragment the already tiny user base into even fewer people.
Not all lisp programmers will be solving the same sorts of problems as
each other, so naturally they'll be using different sets of libraries.
This use of different sets of libraries for different tasks doesn't
constitute laguage fragmentation.
On 2006-12-17 07:54:28 -0500, Jon Harrop <···@ffconsultancy.com> said:
> After all,
> Haskell and OCaml are more popular that any given Lisp variant with similar
> features (e.g. pattern matching), AFAIK.
What doublespeak!
haskell and ocaml are more popular than any lisp library that tries to
imitate Haskell and ocaml. So what! This only speaks to the relative
unpopularity of imitating these features of haskell and ocaml when you
already have lisp.
Raffael Cavallaro wrote:
> haskell and ocaml are more popular than any lisp library that tries to
> imitate Haskell and ocaml.
Implementing pattern matching does not mean imitating Haskell or OCaml.
> This only speaks to the relative
> unpopularity of imitating these features of haskell and ocaml when you
> already have lisp.
On the contrary, Lisp predates the features and, since their inception, most
Lisp programmers have moved on to newer languages.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
On 2006-12-17 12:52:34 -0500, Jon Harrop <···@ffconsultancy.com> said:
> Implementing pattern matching does not mean imitating Haskell or OCaml.
We were explicitly comparing lisp with haskell and ocaml. Adding
features built into haskell and ocaml but not present in ANSI common
lisp would therefore constitute imitating haskell and ocaml in the
context of this discussion. Surely you don't think I'm unaware of the
fact that haskell and ocaml weren't the first languages to use some
form of pattern matching. I acutally used SNOBOL once upon a time.
On Dec 16, 7:21 am, Paul Rubin <·············@NOSPAM.invalid> wrote:
> André Thieme <······························@justmail.de> writes:
> > Sounds like "Blub" to me:
> >http://www.paulgraham.com/avg.html
> It never occurs to Lisp programmers that Lisp, too, might be a Blub.
To Haskellers, Lisp is blub.
On 2006-12-16 14:25:55 -0500, ·············@gmail.com"
<············@gmail.com> said:
> To Haskellers, Lisp is blub.
No, haskellers think lisp is blub because they are so besotted with the
pure functional paradigm that they cannot believe that it might ever be
more expressive to use another, or have the flexibility to use many
paradigms in one program.
I would go so far as to say that pure functional languages are of
necessity less expressive than lisp (or any language that allows the
easy mutation of state - easy side effects) because pure functional
languages work against the natural ontology of all human languages. All
natural languages have categories for state (nouns) and mutators of
state (verbs) and all human languages are based on a world-view of the
continual mutation of state. Haskel therefore forces one to conceive of
programs in a way that goes directly against the easiest natural
language way for people to conceptualize and discuss problems and their
solutions.
Expressiveness is the ease with which one can state a program as
closely as possible as one would talk about it in natural language.
Since pure functional languages fight the basic categories and
world-view of natural language, they are of necessity less expressive
than those that allow the easy mutation of state.
On 2006-12-16 23:44:40 -0500, ·············@gmail.com"
<············@gmail.com> said:
>
> No? Hehe
If my whole post had consisted of "No" you might have had something
there. As it is, it was a fairly elaborate point, which you of course
snipped and completely ignored:
"haskellers think lisp is blub because they are so besotted with the
pure functional paradigm that they cannot believe that it might ever be
more expressive to use another, or have the flexibility to use many
paradigms in one program.
I would go so far as to say that pure functional languages are of
necessity less expressive than lisp (or any language that allows the
easy mutation of state - easy side effects) because pure functional
languages work against the natural ontology of all human languages. All
natural languages have categories for state (nouns) and mutators of
state (verbs) and all human languages are based on a world-view of the
continual mutation of state. Haskel therefore forces one to conceive of
programs in a way that goes directly against the easiest natural
language way for people to conceptualize and discuss problems and their
solutions.
Expressiveness is the ease with which one can state a program as
closely as possible as one would talk about it in natural language.
Since pure functional languages fight the basic categories and
world-view of natural language, they are of necessity less expressive
than those that allow the easy mutation of state."
So your "Hehe" is just an infantile evasion.
On Dec 16, 11:35 pm, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-16 23:44:40 -0500, ·············@gmail.com"
> <············@gmail.com> said:
>
>
>
> > No? Hehe
>If my whole post had consisted of "No" you might have had something
> there.
You said no and then repeated what I wrote. Why would you write no?
On 2006-12-17 01:50:07 -0500, ·············@gmail.com"
<············@gmail.com> said:
> You said no and then repeated what I wrote. Why would you write no?
You don't read very carefully:
You wrote:
"To Haskellers, Lisp is blub."
^^
I replied:
"No, haskellers think lisp is blub because they are so besotted with
the pure functional
^^^^^^
paradigm that they cannot believe that it might ever be more expressive
to use another,
or have the flexibility to use many paradigms in one program."
The verb in your statement is the verb "is" - i.e., you state what
haskeller's believe to be a fact.
The verb in my statement is "think" - i.e., I state that haskellers
only think this to be the case, and then I go on to state why they hold
this misconception.
> Your personal definition of expressive is irrelevant and doesn't even
> put Lisp in a good light.
Since this is usenet, the thing we're dealing in is personal opinions,
so stating that mine is "irrelevant" is just another evasion. You still
haven't adressed the very real issue that programmers find a language
precisely to the extent that it allows them to express a solution in
the way that they think and talk about it, not the way some particular
paradigm says they should conceptualize it.
Raffael Cavallaro wrote:
> On 2006-12-17 01:50:07 -0500, ·············@gmail.com"
> <············@gmail.com> said:
>
> > You said no and then repeated what I wrote. Why would you write no?
>
> You don't read very carefully:
>
> You wrote:
>
> "To Haskellers, Lisp is blub."
> ^^
>
> I replied:
>
> "No, haskellers think lisp is blub because they are so besotted with
> the pure functional
>
> ^^^^^^
>
> paradigm that they cannot believe that it might ever be more expressive
> to use another,
> or have the flexibility to use many paradigms in one program."
>
> The verb in your statement is the verb "is" - i.e., you state what
> haskeller's believe to be a fact.
>
> The verb in my statement is "think" - i.e., I state that haskellers
> only think this to be the case, and then I go on to state why they hold
> this misconception.
>
Oh, so Haskeller only "think" that, and it's a "misconception" - like
why Lispniks only "think" that Python is blub based on Lispnik
"misconceptions". Your "no" was a knee-jerk to a tongue-in-cheek
comment, in which you scrambled to convince someone that you have a
mind-meld with the Haskell community.
> > Your personal definition of expressive is irrelevant and doesn't even
> > put Lisp in a good light.
> haven't adressed the very real issue that programmers find a language
> precisely to the extent that it allows them to express a solution in
> the way that they think and talk about it, not the way some particular
> paradigm says they should conceptualize it.
And that is exactly why I wrote that talking about expressiveness is
almost always an exercise in hand-waving - "in the way that they think".
On 2006-12-17 13:17:00 -0500, ·············@gmail.com"
<············@gmail.com> said:
> And that is exactly why I wrote that talking about expressiveness is
> almost always an exercise in hand-waving - "in the way that they think".
Here it is meant literally, not as some abstract model of human
thought. Programmers want to express a problem exactly as they would
think and talk about it, not as the language designer thought all
problems should be framed. This means being able to define new syntax
and paradigms which lisp macros facilitate, and haskell does not.
On 2006-12-17 13:17:00 -0500, ·············@gmail.com"
<············@gmail.com> said:
> Your "no" was a knee-jerk to a tongue-in-cheek
> comment, in which you scrambled to convince someone that you have a
> mind-meld with the Haskell community.
Mind meld would imply some sympathy. My comment was a critique of their
short sighted group-think.
Your comment was a mere restatement of a point made earlier in the
thread by Paul Rubin:
> On 2006-12-16 08:21:59 -0500, Paul Rubin <·············@NOSPAM.invalid> said:
>
>> It never occurs to Lisp programmers that Lisp, too, might be a Blub.
to which I had already replied:
> Of course it does - Thats why we try ocaml and haskell etc. It's just
> that we don't see the useful features of these languages as being
> sufficiently useful to compensate for their lack of the ability to
> easily do syntactic abstractions over a uniform syntax. There's no
> question that other languages have some features that common lisp does
> not (and vice versa). Lispers just can't abide being locked into a
> particular paradigm because a language doesn't have the basic features
> (macros and uniform syntax) necessary to provide new paradigms for
> ourselves when needed or wanted.
>
> For example, a common lisp with optional static typing on demand would
> be strictly more expressive than common lisp. But, take say, haskell;
> haskell's static typing is not optional (you can work around it, but
> you have to go out of your way to do so); haskell's pure functional
> semantics are not optional (again, workarounds possible to a limited
> extent). This requires you to conceive your problem solution (i.e.,
> program) within the framework of a particular paradigm. This lock-in to
> a particular paradigm, however powerful, is what makes any such
> language strictly less expressive than one with syntactic abstraction
> over a uniform syntax.
>
So you can see how your post hardly counts as a witticism, let alone an
original one.
>
On Dec 17, 12:52 pm, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-17 13:17:00 -0500, ·············@gmail.com"
> <············@gmail.com> said:
>
> > Your "no" was a knee-jerk to a tongue-in-cheek
> > comment, in which you scrambled to convince someone that you have a
> > mind-meld with the Haskell community.Mind meld would imply some sympathy.
>My comment was a critique of their
> short sighted group-think.
>
More of your telepathy with the Haskell community. Nice. And of
course all those PhDs doing language research using Haskell, ML...(no
Lisp in sight) are short-sighted and weak-minded groupthinkers. They
probably don't realize that. You better go inform them on one of their
mailing lists.
> Your comment was a mere restatement of a point made earlier in the
> thread by Paul Rubin:
>
Yes, I should have made sure that Raffael didn't have that covered
already. Next time I'll check.
>So you can see how your post hardly counts as a witticism, let alone an
> original one.
Oh, it'd be so much easier for you if it was just the "lesser"
dynamically typed languages that you could blubbify, and you were the
sole definer of "expressive".
Hats off to Mark Tarver. Hook-line-sinker.
On Dec 17, 1:35 pm, Bill Atkins
<····························@gmail.com> wrote:
> ·············@gmail.com" <············@gmail.com> writes:
> > Hats off to Mark Tarver. Hook-line-sinker.
>For serious. What a mean-spirited thing to do.
Mark Tarver is mean-spriited because the non-blubs on c.l.l took the
bait? Gavino should have used another name, but it looks like he's got
some bites changing Python to Smalltalk. Maybe we can get a massive
cross-post of dynamic vs static typing next.
On 2006-12-17 14:46:23 -0500, ·············@gmail.com"
<············@gmail.com> said:
> Mark Tarver is mean-spriited because the non-blubs on c.l.l took the
> bait? Gavino should have used another name, but it looks like he's got
> some bites changing Python to Smalltalk. Maybe we can get a massive
> cross-post of dynamic vs static typing next.
Might want to look at these before equating Mark Tarver with Gavino:
<http://www.lambdassociates.org/>
<http://www.lambdassociates.org/members.htm>
<http://www.lambdassociates.org/aboutqi.htm>
On Dec 17, 2:43 pm, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-17 14:46:23 -0500, ·············@gmail.com"
> <············@gmail.com> said:
>
> > Mark Tarver is mean-spriited because the non-blubs on c.l.l took the
> > bait? Gavino should have used another name, but it looks like he's got
> > some bites changing Python to Smalltalk. Maybe we can get a massive
> > cross-post of dynamic vs static typing next.
>Might want to look at these before equating Mark Tarver with Gavino:
>
> <http://www.lambdassociates.org/>
>
> <http://www.lambdassociates.org/members.htm>
>
> <http://www.lambdassociates.org/aboutqi.htm>
You mean I should know everybody who posts on c.l.I? Is there a bio
list somewhere? I guess we can start appealing to authority now, since
you broke your own rule.
On 2006-12-17 19:04:22 -0500, ·············@gmail.com"
<············@gmail.com> said:
> You mean I should know everybody who posts on c.l.I? Is there a bio
> list somewhere? I guess we can start appealing to authority now, since
> you broke your own rule.
Since we were discussing these *people themselves* (Mark Tarver and
gavino) not the truth or falsity of some *proposition* either was
advocating, talking about these *people themselves* can't possibly be
an argument from authority. It would be an argument from authority to
say "So-and-so is a PhD and he thinks Mark Tarver is a great guy," but
that's not what happened. If you prefer, you can simply review their
posting histories on c.l.l:
gavino:
<http://groups.google.com/groups?as_q=&num=30&scoring=r&hl=en&as_epq=&as_oq=&as_eq=&as_ugroup=comp.lang.lisp&as_usubject=&as_uauthors=gavino&lr=&as_drrb=q&as_qdr=&as_mind=1&as_minm=1&as_miny=1981&as_maxd=17&as_maxm=12&as_maxy=2006>
Mark
Tarver
<http://groups.google.com/groups?as_q=&num=30&scoring=r&hl=en&as_epq=&as_oq=&as_eq=&as_ugroup=comp.lang.lisp&as_usubject=&as_uauthors=mark+tarver&lr=&as_drrb=q&as_qdr=&as_mind=1&as_minm=1&as_miny=1981&as_maxd=17&as_maxm=12&as_maxy=2006>
·············@gmail.com" <············@gmail.com> writes:
> On Dec 17, 1:35 pm, Bill Atkins
> <····························@gmail.com> wrote:
>> ·············@gmail.com" <············@gmail.com> writes:
>> > Hats off to Mark Tarver. Hook-line-sinker.
>>For serious. What a mean-spirited thing to do.
>
> Mark Tarver is mean-spriited because the non-blubs on c.l.l took the
> bait? Gavino should have used another name, but it looks like he's got
> some bites changing Python to Smalltalk. Maybe we can get a massive
> cross-post of dynamic vs static typing next.
There is very little to be gained from cross-posting a kind of
question like the one at the top of this mess. Obviously, the kind of
people who read comp.lang.python are going to give very pro-Python
responses, and the people who read comp.lang.lisp are going to give
very pro-Lisp responses. I find it incredible that someone would
expect anything other than bickering to result from this.
On Dec 17, 2:53 pm, Bill Atkins
<························@not-a-real-domain.com> wrote:
> ·············@gmail.com" <············@gmail.com> writes:
> > On Dec 17, 1:35 pm, Bill Atkins
> > <····························@gmail.com> wrote:
> >> ·············@gmail.com" <············@gmail.com> writes:
> >> > Hats off to Mark Tarver. Hook-line-sinker.
> >>For serious. What a mean-spirited thing to do.
>
> > Mark Tarver is mean-spriited because the non-blubs on c.l.l took the
> > bait? Gavino should have used another name, but it looks like he's got
> > some bites changing Python to Smalltalk. Maybe we can get a massive
> > cross-post of dynamic vs static typing next.There is very little to be gained from cross-posting a kind of
> question like the one at the top of this mess. Obviously, the kind of
> people who read comp.lang.python are going to give very pro-Python
> responses, and the people who read comp.lang.lisp are going to give
> very pro-Lisp responses. I find it incredible that someone would
> expect anything other than bickering to result from this.
Raffael says that we can't question Mark Taver's motivations since he's
some authority figure at Lambda Associates;) On the other hand,
Raffael can and will read the mind of everybody in the haskell
community.
Bill Atkins wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
>
>>On Dec 17, 1:35 pm, Bill Atkins
>><····························@gmail.com> wrote:
>>
>>>·············@gmail.com" <············@gmail.com> writes:
>>>
>>>>Hats off to Mark Tarver. Hook-line-sinker.
>>>
>>>For serious. What a mean-spirited thing to do.
>>
>>Mark Tarver is mean-spriited because the non-blubs on c.l.l took the
>>bait? Gavino should have used another name, but it looks like he's got
>>some bites changing Python to Smalltalk. Maybe we can get a massive
>>cross-post of dynamic vs static typing next.
>
>
> There is very little to be gained from cross-posting a kind of
> question like the one at the top of this mess. Obviously, the kind of
> people who read comp.lang.python are going to give very pro-Python
> responses, and the people who read comp.lang.lisp are going to give
> very pro-Lisp responses. I find it incredible that someone would
> expect anything other than bickering to result from this.
That's OK. Richard Gabriel himself recommended at LUGM '99 picking a
fight with another language as a way of gaining mindshare for Lisp. The
fight is not the thing, rather the publicity. The participants are not
persuaded, the lurkers are made curious. The trick is to keep the fight
technical, so lurkers benefit the most.
Pepsi once had a "Pepsi Challenge" ad campaign. People were supposed to
buy Pepsi and Coke and decide for themselves. At the time Pepsi had half
the market Coke had. Anyone taking them up on the challenge was at least
buying as much Pepsi as Coke, a win in itself. And of course Avis's #2
ad campaign. Same thing.
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
············@gmail.com schrieb:
>
> On Dec 17, 1:35 pm, Bill Atkins
> <····························@gmail.com> wrote:
>> ·············@gmail.com" <············@gmail.com> writes:
>>> Hats off to Mark Tarver. Hook-line-sinker.
>> For serious. What a mean-spirited thing to do.
>
> Mark Tarver is mean-spriited because the non-blubs on c.l.l took the
> bait? Gavino should have used another name, but it looks like he's got
> some bites changing Python to Smalltalk. Maybe we can get a massive
> cross-post of dynamic vs static typing next.
>
Mark Tarver is the developer of Qi, a Lisp (new reader and some extra
packages).
http://www.lambdassociates.org/
Here you can learn why the type system of Qi is the most powerful of its
kind and more powerful than Haskell and ML:
http://www.lambdassociates.org/advtypes.htm
Andr�
--
On 2006-12-17 14:28:42 -0500, ·············@gmail.com"
<············@gmail.com> said:
> More of your telepathy with the Haskell community. Nice. And of
> course all those PhDs doing language research using Haskell, ML...(no
> Lisp in sight) are short-sighted and weak-minded groupthinkers. They
> probably don't realize that. You better go inform them on one of their
> mailing lists.
"Weak minded" was your addition. I stand by short sighted. They've lost
sight of the expressiveness of both syntactic abstraction and side
effects in their infatuation with the pure functional pardigm. I stand
by group-think. They've built up an academic community where most
eveyone thinks the same. This makes thinking differently a risky
proposition for academics. The fact that they are PhDs is an argument
from authority, and so needs no refutation.
>
>> Your comment was a mere restatement of a point made earlier in the
>> thread by Paul Rubin:
>>
>
> Yes, I should have made sure that Raffael didn't have that covered
> already. Next time I'll check.
Just read the thread in order and you won't repeat what others have
already said thinking your snide comment is an original piece of wit.
>> So you can see how your post hardly counts as a witticism, let alone an
>> original one.
>
> Oh, it'd be so much easier for you if it was just the "lesser"
> dynamically typed languages that you could blubbify, and you were the
> sole definer of "expressive".
Programmers are the definers of what is expressive for them, usually
following the practice of domain experts. Haskell wants all problems to
be defined according to haskell's paradigms (pure functional, lazy) and
doesn't give the programmer the freedom to easily add new paradigms
through syntactic abstraction. Lisp does.
On Dec 17, 2:31 pm, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-17 14:28:42 -0500, ·············@gmail.com"
> <············@gmail.com> said:
>
> > More of your telepathy with the Haskell community. Nice. And of
> > course all those PhDs doing language research using Haskell, ML...(no
> > Lisp in sight) are short-sighted and weak-minded groupthinkers. They
> > probably don't realize that. You better go inform them on one of their
> > mailing lists."Weak minded" was your addition. I stand by short sighted. They've lost
> sight of the expressiveness of both syntactic abstraction and side
> effects in their infatuation with the pure functional pardigm.
Can I try telepathy too? Lispniks have lost sight of syntax itself,
and have become infatuated with parentheses. Lispniks are so
short-sighted.
> I stand
> by group-think. They've built up an academic community where most
> eveyone thinks the same. This makes thinking differently a risky
> proposition for academics.
Did you poll or more telepathy? I'll claim that Lispniks are borg.
The fact that they are PhDs is an argument
> from authority, and so needs no refutation.
>
Short-bus riding QuickBasicers claim that Lispniks are blub.
>
>
> >> Your comment was a mere restatement of a point made earlier in the
> >> thread by Paul Rubin:
>
> > Yes, I should have made sure that Raffael didn't have that covered
> > already. Next time I'll check.
>Just read the thread in order and you won't repeat what others have
> already said thinking your snide comment is an original piece of wit.
>
I've decided to cancel my deferment to Raffael pledge.
> >> So you can see how your post hardly counts as a witticism, let alone an
> >> original one.
>
> > Oh, it'd be so much easier for you if it was just the "lesser"
> > dynamically typed languages that you could blubbify, and you were the
> > sole definer of "expressive"
>.Programmers are the definers of what is expressive for them, usually
> following the practice of domain experts. Haskell wants all problems to
> be defined according to haskell's paradigms (pure functional, lazy) and
> doesn't give the programmer the freedom to easily add new paradigms
> through syntactic abstraction. Lisp does.
And Lispniks want everything defined according to the paradigm of
parentheses.
············@gmail.com wrote:
> Can I try telepathy too? Lispniks have lost sight of syntax itself,
> and have become infatuated with parentheses. Lispniks are so
> short-sighted.
Yup!
I never want to learn another language ever again that:
- doesn't have an ANSI/ISO standard
- has a syntax with associativity and precedence rules
- isn't programmable (without hacking the source code of the
implementation).
I don't ever want to ship a hacked implementation of the language
compiler, interpreter or run-time to an end user. New syntax and
semantics should just be a module that loads into the standard image.
On 2006-12-17 19:00:50 -0500, ·············@gmail.com"
<············@gmail.com> said:
>> I stand by short sighted. They've lost
>> sight of the expressiveness of both syntactic abstraction and side
>> effects in their infatuation with the pure functional pardigm.
>
> Can I try telepathy too? Lispniks have lost sight of syntax itself,
> and have become infatuated with parentheses. Lispniks are so
> short-sighted.
>
>> I stand
>> by group-think. They've built up an academic community where most
>> eveyone thinks the same. This makes thinking differently a risky
>> proposition for academics.
>
> Did you poll or more telepathy? I'll claim that Lispniks are borg.
>
>> The fact that they are PhDs is an argument
>> from authority, and so needs no refutation.
>>
>
> Short-bus riding QuickBasicers claim that Lispniks are blub.
Since you're clearly just here to rant it's time for me to say bye.
On Dec 17, 11:09 pm, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-17 19:00:50 -0500, ·············@gmail.com"
> <············@gmail.com> said:
>
>
>
> >> I stand by short sighted. They've lost
> >> sight of the expressiveness of both syntactic abstraction and side
> >> effects in their infatuation with the pure functional pardigm.
>
> > Can I try telepathy too? Lispniks have lost sight of syntax itself,
> > and have become infatuated with parentheses. Lispniks are so
> > short-sighted.
>
> >> I stand
> >> by group-think. They've built up an academic community where most
> >> eveyone thinks the same. This makes thinking differently a risky
> >> proposition for academics.
>
> > Did you poll or more telepathy? I'll claim that Lispniks are borg.
>
> >> The fact that they are PhDs is an argument
> >> from authority, and so needs no refutation.
>
> > Short-bus riding QuickBasicers claim that Lispniks are blub.
>Since you're clearly just here to rant it's time for me to say bye.
It's good to see you're done trolling.
On 2006-12-17 11:48:22 -0500, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> said:
sorry, lost a word there, should be:
You still haven't adressed the very real issue that programmers find a
language *expressive* precisely to the extent that it allows them to
express a solution in the way that they think and talk about it, not
the way some particular paradigm says they should conceptualize it.
On Dec 16, 11:35 pm, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-16 23:44:40 -0500, ·············@gmail.com"
> <············@gmail.com> said:
>
>
>
> > No? HeheIf my whole post had consisted of "No" you might have had something
> there. As it is, it was a fairly elaborate point, which you of course
> snipped and completely ignored:
>
> "haskellers think lisp is blub because they are so besotted with the
> pure functional paradigm that they cannot believe that it might ever be
> more expressive to use another, or have the flexibility to use many
> paradigms in one program.
>
> I would go so far as to say that pure functional languages are of
> necessity less expressive than lisp (or any language that allows the
> easy mutation of state - easy side effects) because pure functional
> languages work against the natural ontology of all human languages. All
> natural languages have categories for state (nouns) and mutators of
> state (verbs) and all human languages are based on a world-view of the
> continual mutation of state. Haskel therefore forces one to conceive of
> programs in a way that goes directly against the easiest natural
> language way for people to conceptualize and discuss problems and their
> solutions.
>
> Expressiveness is the ease with which one can state a program as
> closely as possible as one would talk about it in natural language.
> Since pure functional languages fight the basic categories and
> world-view of natural language, they are of necessity less expressive
> than those that allow the easy mutation of state."
>
> So your "Hehe" is just an infantile evasion.
Your personal definition of expressive is irrelevant and doesn't even
put Lisp in a good light.
············@gmail.com schrieb:
> On Dec 16, 7:21 am, Paul Rubin <·············@NOSPAM.invalid> wrote:
> > André Thieme <······························@justmail.de> writes:
> > > Sounds like "Blub" to me:
> > >http://www.paulgraham.com/avg.html
>
> > It never occurs to Lisp programmers that Lisp, too, might be a Blub.
>
> To Haskellers, Lisp is blub.
I've tried more than a dozen imperative languages and IMO Lisp is
clearly the most powerful one. When it comes to Haskell, I admit that
it has properties that Lisp misses. I think that the purely
functional/garbage collector analogy is appropriate.
OTOH there is my personal experience. I've invested roughly the same
time in Haskell and in Common Lisp and I'm more productive in Common
Lisp. Yesterday someone posted a Haskell intro to Reddit:
http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/16#programming-haskell-intro.
The Haskell code is very elegant, but there is no way I would have come
up with such elegant code. I tried the example in Common Lisp, and the
first solution resulted in about the same amount of code, without
resorting to one letter variable names. Additionally my naive CL
solution was (with sbcl) three times faster than the Haskell solution
when compiled with ghc.
Through macros, CL lets me express many concepts with *no* boilerplate.
Theoretically, it should be possible to achieve the same in Haskell
with higher order functions and lazy evaluation, but practically it
doesn't work for me.
Another thing is, with Haskell you are back to the old edit - compile -
run cycle. This is stone age for a Lisper. And no, ghci is not the
answer.
I'd say that Haskell is not strictly more powerful than Common Lisp
(and vice versa), whereas IMO CL is strictly more powerful than Java,
Ruby, Python, C++, C#, Smalltalk, etc. Haskell might be the pointer in
the direction of a more powerful language, but it's not this version of
Haskell, maybe Haskell 2 or a new language that combines the strengths
of Haskell and CL (dreaming is still allowed :-).
Stefan
Paul Rubin <·············@NOSPAM.invalid> writes:
> Andr� Thieme <······························@justmail.de> writes:
> > Sounds like "Blub" to me:
> > http://www.paulgraham.com/avg.html
>
> It never occurs to Lisp programmers that Lisp, too, might be a Blub.
You are mistaken...
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
greg <····@cosc.canterbury.ac.nz> writes:
> Andr� Thieme wrote:
>> (aif (timeConsumingCalculation)
>> (use it))
>
> I think the answer is that you just wouldn't do
> that in Python at all. Having magic variables
> spring into existence in your local namespace
> as a side effect of calling something is just
> not Pythonic. (It is very Perlish, on the other
> hand.)
Anaphoric macros are controversial in CL, too, for just that reason.
But there are a parallel set of macros that explicitly bind a variable
so you can get the convenience without the weirdness:
(bif (items (remove-if-not #'useful-p big-list-o-items))
(format t "~D items~%" (length items))
(format t "Nothing useful.~%"))
You can rewrite the expression in the grandparent as:
(aif (result (timeConsumingCalculation))
(use result)
or, more idiomatically:
(awhen (result (time-counsuming-calculation))
(use result))
André Thieme wrote:
> greg schrieb:
> > Ken Tilton wrote:
> >
> >> The reason I post macro expansions along with examples of the macro
> >> being applied is so that one can see what code would have to be
> >> written if I did not have the defskill macro to "write" them for me.
> >
> > It seems to me your brain is somewhat stuck on the use of macros.
>
> That you see it this way is normal.
> A BASIC programmer would tell you the same thing. He can show you
> solutions that don't use classes, methods or functions.
> Some sweet gotos and gosubs are enough.
> The idea is that macros save you tokens and allow you to experess
> in a clearer way what you want to do. But in no case one "needs"
> them to solve a programming problem. All what Kenny showed could
> be done without his macro. It would just be a bit more complicated
> and the resulting code wouldn't look good.
>
>
> > You're looking at the expansion of your
> > macro and assuming that you'd have to write all that
> > code by hand if you didn't have macros. You're not
> > thinking about alternative approaches, which could
> > just as well be used in Lisp as well as Python, that
> > are just as compact yet don't make use of macros.
>
> He wouldn't have to write the full expansion. With functional
> programming he could also solve it, but then he would need
> a funcall here, a lambda there. And his code would not look
> so understandable anymore, because it is filled up with some
> low level details.
>
>
> I will take one of the first macro examples form "On Lisp".
> Let's say for some reason you want to analyse some numbers
> and do something depending on their sign. We want a function
> "numeric if":
>
> def nif(num, pos, zero, neg):
> if num > 0:
> return pos
> else:
> if num == 0:
> return zero
> else:
> return neg
>
>
> In Lisp very similar:
> (defun nif (num pos zero neg)
> (case (truncate (signum num))
> (1 pos)
> (0 zero)
> (-1 neg)))
>
>
> Now one example Graham gives is:
> (mapcar #'(lambda (x)
> (nif x 'p 'z 'n))
> '(0 2.5 -8))
>
> which results in the list (Z P N).
> You can do the same thing in Python.
> But it gets hairier if we want to make function calls that
> have side effects.
> Let me add these three functions:
>
> (defun p ()
> (print "very positive")
> "positive")
>
> (defun z ()
> (print "no no")
> "zero")
>
> (defun n ()
> (print "very negative")
> "negative")
>
>
> And now see what happens:
>
> CL-USER> (mapcar #'(lambda (x)
> (nif x (p) (z) (n)))
> '(0 2.5 -8))
>
> "very positive"
> "no no"
> "very negative"
> "very positive"
> "no no"
> "very negative"
> "very positive"
> "no no"
> "very negative"
> ("zero" "positive" "negative")
>
> The messages were printed in each case.
> To stop that I need lazy evaluation:
> CL-USER> (mapcar #'(lambda (x)
> (funcall
> (nif x
> #'(lambda () (p))
> #'(lambda () (z))
> #'(lambda () (n)))))
> '(0 2.5 -8))
>
> "no no"
> "very positive"
> "very negative"
> ("zero" "positive" "negative")
>
>
> I put the calls to the functions p, z and n into a function object.
> In some languages it would look a bit cleaner, for example Ruby.
> They have a single name space and don't need funcall and lambda is
> shorter. But still, we need to add several tokens. Maybe Haskell has
> built in support for that.
def p
puts "very positive"
"positive"
end
def z
puts "no no"
"zero"
end
def n
puts "very negative"
"negative"
end
def nif num, pos, zero, neg
send( num>0 ? pos : (num==0 ? zero : neg) )
end
[0, 2.5, -8].map{|x| nif x, :p, :z, :n}
### Another way #####
p = proc {
puts "very positive"
"positive" }
z = proc {
puts "no no"
"zero" }
n = proc {
puts "very negative"
"negative" }
def nif num, pos, zero, neg
( num>0 ? pos : (num==0 ? zero : neg) ).call
end
[0, 2.5, -8].map{|x| nif x, p, z, n}
William James schrieb:
I suppose that is Ruby code.
So my statement was correct when I said:
"In some languages it would look a bit cleaner, for example Ruby."
This is because it has a minimal syntax for "lambda".
> def p
> puts "very positive"
> "positive"
> end
> def z
> puts "no no"
> "zero"
> end
> def n
> puts "very negative"
> "negative"
> end
> def nif num, pos, zero, neg
> send( num>0 ? pos : (num==0 ? zero : neg) )
> end
This code would work
> [0, 2.5, -8].map{|x| nif x, :p, :z, :n}
See how you move away from the idea of an if.
Here you need to say :p, :z, :n.
That is not much better as Lisps #'
> ### Another way #####
>
> p = proc {
> puts "very positive"
> "positive" }
> z = proc {
> puts "no no"
> "zero" }
> n = proc {
> puts "very negative"
> "negative" }
> def nif num, pos, zero, neg
> ( num>0 ? pos : (num==0 ? zero : neg) ).call
> end
>
> [0, 2.5, -8].map{|x| nif x, p, z, n}
But will this version also work this way:
[0, 2.5, -8].map{|x| nif x, "p", "z", "n"}
You can't express it like an "if" in Ruby.
In Lisp it is like an IF and represents exactly what
we think.
IF in Lisp:
(if expr
(then-part)
(else-part))
nif in Lisp:
(nif expr
(positive-part)
(zero-part)
(negative-part))
It looks as if it were a construct directly built into Lisp.
If one wants one could even add some additional syntax, so
that it looks like:
(nif expr
positive:
(foo1)
(foo2)
zero:
(foo3)
negative:
(foo4))
If you regard that idea nonsense then I suggest you to not
use Rubys if-statement anymore. But instead program your
own version "RubyIF" so that in future you have to pass all code
inside blocks to your RubyIF function. If you *really* think
that the Lisp savings are not worth it, then you would begin
with my suggestion today.
Andr�
--
On 2006-12-15, Andr� Thieme
<······························@justmail.de> wrote:
> In Lisp it is like an IF and represents exactly what we think.
> IF in Lisp:
> (if expr
> (then-part)
> (else-part))
>
> nif in Lisp:
> (nif expr
> (positive-part)
> (zero-part)
> (negative-part))
>
> It looks as if it were a construct directly built into Lisp. If
> one wants one could even add some additional syntax, so that it
> looks like:
> (nif expr
> positive:
> (foo1)
> (foo2)
> zero:
> (foo3)
> negative:
> (foo4))
>
> If you regard that idea nonsense then I suggest you to not use
> Rubys if-statement anymore. But instead program your own
> version "RubyIF" so that in future you have to pass all code
> inside blocks to your RubyIF function. If you *really* think
> that the Lisp savings are not worth it, then you would begin
> with my suggestion today.
I don't know how to build a house. It doesn't make me want to
live in a cave. ;-)
--
Neil Cerutti
The third verse of Blessed Assurance will be sung without musical
accomplishment. --Church Bulletin Blooper
William James schrieb:
> def nif num, pos, zero, neg
> send( num>0 ? pos : (num==0 ? zero : neg) )
> end
btw, your nif body is built out of 13 tokens, so more
complicated than the Python version.
Andr�
--
André Thieme wrote:
> William James schrieb:
>
> > def nif num, pos, zero, neg
> > send( num>0 ? pos : (num==0 ? zero : neg) )
> > end
>
> btw, your nif body is built out of 13 tokens, so more
> complicated than the Python version.
>
>
> André
> --
def nif num, *args
send args[ 1 + (0 <=> num) ]
end
William James schrieb:
> Andr� Thieme wrote:
>> William James schrieb:
>>
>>> def nif num, pos, zero, neg
>>> send( num>0 ? pos : (num==0 ? zero : neg) )
>>> end
>> btw, your nif body is built out of 13 tokens, so more
>> complicated than the Python version.
>>
>>
>> Andr�
>> --
>
> def nif num, *args
> send args[ 1 + (0 <=> num) ]
> end
send
|
|
[ ]
/ \
/ \
/ \
args +
/ \
/ \
1 ()
|
|
<=>
/ \
/ \
0 num
Okay, 9. Now it is at the complexity level of the Lisp
and Python example.
But how would a call to nif look like?
I hope it doesn't involve an extra operator to group the
args into a list or tuple. That would add more complexity to
each call - so one should better have a slightly more complex
nif because that exists only one time.
And can this nif now handle any input values, such as strings
or function objects?
The <=> is called cmp in Python.
In Lisp it is called signum. The Lisp function has in general the
advantage that it keeps type information.
While Pythons cmp returns either -1, 0 or 1 the Lisp version can
also return -1.0 and 1.0 and also complex numbers:
(signum #C(10 4)) => #C(0.9284767 0.37139067)
Andr�
--
André Thieme wrote:
> William James schrieb:
> > André Thieme wrote:
> >> William James schrieb:
> >>
> >>> def nif num, pos, zero, neg
> >>> send( num>0 ? pos : (num==0 ? zero : neg) )
> >>> end
> >> btw, your nif body is built out of 13 tokens, so more
> >> complicated than the Python version.
> >>
> >>
> >> André
> >> --
> >
> > def nif num, *args
> > send args[ 1 + (0 <=> num) ]
> > end
>
>
> send
> |
> |
> [ ]
> / \
> / \
> / \
> args +
> / \
> / \
> 1 ()
> |
> |
> <=>
> / \
> / \
> 0 num
>
> Okay, 9. Now it is at the complexity level of the Lisp
> and Python example.
> But how would a call to nif look like?
A call is unchanged:
[0, 2.5, -8].map{|x| nif x, :p, :z, :n}
> I hope it doesn't involve an extra operator to group the
> args into a list or tuple. That would add more complexity to
> each call - so one should better have a slightly more complex
> nif because that exists only one time.
>
> And can this nif now handle any input values, such as strings
> or function objects?
It handles only symbols.
I suppose this can handle anything ...
p = proc {
puts "very positive"
"positive" }
z = proc {
puts "no no"
"zero" }
n = proc {
puts "very negative"
"negative" }
def nif num, *args
args[ 1 + (0 <=> num) ].call
end
[0, 2.5, -8].map{|x| nif x, p, z, n}
puts [0, 2.5, -8].map{|x| nif x,
proc{'zero'}, proc{'plus'}, proc{'minus'}}
... if you wrap everything in a proc (lambda).
Andr� Thieme wrote:
> The <=> is called cmp in Python.
> In Lisp it is called signum. The Lisp function has in general the
> advantage that it keeps type information.
> While Pythons cmp returns either -1, 0 or 1 the Lisp version can
> also return -1.0 and 1.0 and also complex numbers:
> (signum #C(10 4)) => #C(0.9284767 0.37139067)
Unless you can use it to compare arbitrary types
such as two strings or two lists, it's not really
the same thing as Python's cmp.
Python 2.3 (#1, Aug 5 2003, 15:52:30)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> cmp("hello", "world")
-1
>>> cmp([1,3], [1,2])
1
--
Greg
On 2006-12-15, Andr� Thieme
<······························@justmail.de> wrote:
> I will take one of the first macro examples form "On Lisp".
> Let's say for some reason you want to analyse some numbers and
> do something depending on their sign. We want a function
> "numeric if":
>
> In Lisp very similar:
> (defun nif (num pos zero neg)
> (case (truncate (signum num))
> (1 pos)
> (0 zero)
> (-1 neg)))
>
>
> Now one example Graham gives is:
> (mapcar #'(lambda (x)
> (nif x 'p 'z 'n))
> '(0 2.5 -8))
>
> which results in the list (Z P N). You can do the same thing in
> Python. But it gets hairier if we want to make function calls
> that have side effects. Let me add these three functions:
>
> (defun p ()
> (print "very positive")
> "positive")
>
> (defun z ()
> (print "no no")
> "zero")
>
> (defun n ()
> (print "very negative")
> "negative")
>
> And now see what happens:
>
> CL-USER> (mapcar #'(lambda (x)
> (nif x (p) (z) (n)))
> '(0 2.5 -8))
>
> "very positive"
> "no no"
> "very negative"
> "very positive"
> "no no"
> "very negative"
> "very positive"
> "no no"
> "very negative"
> ("zero" "positive" "negative")
That's not a real difficulty, is it?
CL-USER> (mapcar #'(lambda (x)
(funcall (nif x p z n)))
'(0 2.5 -8))
"no no"
"very positive"
"very negative"
("zero" "positive" "negative")
At any rate, that's what I'd do in Python, too.
> Now with nif as a macro:
> (defmacro nif (expr pos zero neg)
> `(case (truncate (signum ,expr))
> (1 ,pos)
> (0 ,zero)
> (-1 ,neg)))
>
> It is a bit more complex as the function. It has one ` and 4 ,s
> extra. But now we can express the problem very well:
>
> CL-USER> (mapcar #'(lambda (x)
> (nif x (p) (z) (n)))
> '(0 2.5 -8))
>
> "no no"
> "very positive"
> "very negative"
> ("zero" "positive" "negative")
>
> And the first example also still works the same way.
That's the part that Python doesn't naturally provide, and I
believe, Python programmers don't usually want.
--
Neil Cerutti
I have opinions of my own -- strong opinions -- but I don't always agree with
them. --George W. Bush
Neil Cerutti schrieb:
> That's not a real difficulty, is it?
>
> CL-USER> (mapcar #'(lambda (x)
> (funcall (nif x p z n)))
> '(0 2.5 -8))
Didn't you forget the #' before p, z and n?
>> CL-USER> (mapcar #'(lambda (x)
>> (nif x (p) (z) (n)))
>> '(0 2.5 -8))
>>
>> "no no"
>> "very positive"
>> "very negative"
>> ("zero" "positive" "negative")
>>
>> And the first example also still works the same way.
>
> That's the part that Python doesn't naturally provide, and I
> believe, Python programmers don't usually want.
Then I have the solution:
they can build their own functional if.
Instead of
if x > 10:
do()
something()
else:
foo()
They can say:
def blah1():
do()
something()
def blah2():
foo()
pythonIF(x > 10,
# then
blah1,
# else
blah)
I personally thought the first version was the Python way.
Now let's admit that
nif number:
pos_then:
p()
zero_then:
z()
neg_then:
n()
is also the Python way. With just one problem: they can't have it.
Andr�
--
Neil Cerutti wrote:
>
> That's not a real difficulty, is it?
>
> CL-USER> (mapcar #'(lambda (x)
> (funcall (nif x p z n)))
> '(0 2.5 -8))
>
> "no no"
> "very positive"
> "very negative"
> ("zero" "positive" "negative")
>
> At any rate, that's what I'd do in Python, too.
>
>> Now with nif as a macro:
>> (defmacro nif (expr pos zero neg)
>> `(case (truncate (signum ,expr))
>> (1 ,pos)
>> (0 ,zero)
>> (-1 ,neg)))
>>
>> It is a bit more complex as the function. It has one ` and 4 ,s
>> extra. But now we can express the problem very well:
>>
>> CL-USER> (mapcar #'(lambda (x)
>> (nif x (p) (z) (n)))
>> '(0 2.5 -8))
>>
>> "no no"
>> "very positive"
>> "very negative"
>> ("zero" "positive" "negative")
>>
>> And the first example also still works the same way.
>
> That's the part that Python doesn't naturally provide, and I
> believe, Python programmers don't usually want.
>
What if I want
(mapcar #'(lambda (x)
(nif x (p some-arg) (z) (n arg1 arg2)))
'(0 2.5 -8))
How would Python programmers prefer to write this nif form?
Even better, what if I want this -
(mapcar #'(lambda (x)
(nif x
(p some-arg)
z
(if (evenp x)
(n arg1 arg2)
(n arg2 arg1))))
'(0 2.5 -8))
Now z is just a variable, and the fourth argument to nif is a special
form. How will this be written in a python nif? Wrap a lambda around
each expression in nif? That's really ugly, IMO.
Ken Tilton wrote:
>
>
> Ken Tilton wrote:
>
>>
>>
>> Paul Rubin wrote:
>>
>>> Ken Tilton <·········@gmail.com> writes:
>>>
>>>> don't know. The point is, we need code (not just data) in defskill
>>>> (apologies for nasty formatting):
>>>
>>>
>>>
>>>
>>> Man that whole thing is messy.
>
>
> I do not see much difference, except that the character count is 25%
> less in the macro version:
>
> (defskill absolute-value
> (title "Absolute Value")
> (annotations
> "Absolute value of #strn# is the 'distance' of #strn# from zero."
> "Absolute value is always zero or positive: #str|n|=n#, and
> #str|-n|=n#.")
> (hints
> "Some examples: #str|+42|=42#, #str|-42|=42#, and #str|0|=0#."
> "To get the absolute value of a number such as #signed-value#, we
> simply drop any minus sign.")
> (reverse
> (ensure-cloning resx
> (make-instance 'mx-number
> :value (loop with op1 = (car opnds)
> with log = (max 1 (ceiling (log (abs (value op1)) 10)))
> for n = (* (signum (value op1))
> (+ 2 (random (expt 10 log))))
> when (/= n (value op1))
> return n)
> :representation (representation resx)))))
>
> (defmethod skill-title ((tf-id (eql 'absolute-value)))
> (list "absolute value"))
>
> (defmethod skill-annotations ((tf-id (eql 'absolute-value)))
> (list "absolute value of #strn# is the 'distance' of #strn# from zero."
> "absolute value is always zero or positive: #strn=n#, and #str-n=n#."))
>
> (defmethod skill-hints ((tf-id (eql 'absolute-value)))
> (list "some examples: #str+42=42#, #str-42=42#, and #str0=0#."
> "to get the absolute value of a number such as #signed-value#, we
> simply drop any minus sign."))
>
> (defmethod tf-reverse ((id (eql 'absolute-value)) resx opnds)
> (declare (ignorable resx opnds))
> (ensure-cloning resx
> (make-instance 'mx-number :value
> (loop with op1 = (car opnds) with log = (max 1 (ceiling (log (abs
> (value op1)) 10))) for n =
> (* (signum (value op1)) (+ 2 (random (expt 10 log)))) when
> (/= n (value op1)) return n)
> :representation (representation resx)))))
Even better. That "(car opnds)" up there is an unpleasant hard-coding
that must align with how operands get recorded by the transformation
code that built the TF log entry that is being reversed. Ewww. What the
first opnds is supposed to be is the signed value of which the absolute
vale is being taken. Wouldn't it be nice to just say "signed-value"?:
We can just look at the reverse option now:
(defskill absolute-value
....
(reverse (signed-value)
(ensure-cloning resx
(make-instance 'mx-number
:value (loop with svn = (value signed-value)
with log = (max 1 (ceiling (log (abs svn) 10)))
for n = (* (signum svn)(+ 2 (random (expt 10 log))))
when (/= n svn)
return n)
:representation (representation resx)))))
A major point here is that the above (trust me) is the exact syntax of
FLET and LABELS in Lisp. The big hobgoblin (and precise objection
offered by GvR) is that macro use yields unrecognizably (in this case)
Lisp code. But we love lisp and its patterns, and one ethic for macro
writers is to follow those patterns in extending the language.
Maybe that poor horse can be allowed to rest in peace, or must we flog
it some more for youse people?
Now operands and results get tagged at TF time with symbols. How on
earth does a local variable of the same name get bound to the operand
logged at TF time? Easy, look it up. But where is the code? Not outside
the function; the caller of the reversal function does not know which
logged operand to pass in which function parameter position. So the
lookup code has to be in the reverse function source, like this:
(defmethod tf-reverse ((id (eql 'absolute-value)) tf drv
&aux (opnds (drv-opnds tf drv)))
(declare (ignorable opnds))
(let ((signed-value (tf-drv-lookup tf drv 'signed-value))) <=====
(loop for resx in (results drv) do
(ensure-cloning resx
(make-instance 'mx-number :value
(loop with svn = (value signed-value)
with log = (max 1 (ceiling (log (abs svn) 10)))
for n = (* (signum svn)
(+ 2 (random (expt 10 log))))
when (/= n svn) return n)
:representation (representation resx))))))
WordPerfect says thats 405 characters, 64 words vs 241/38 for the actual
source.
Now in this case I happen to be just starting on this mechanism, so i do
not really have 42 I do not have to change, but I am about to start
churning these things out and I expect refinements to continue.
No problem.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> How close can Python get when code is involved? The reverse function
> signature is fixed, so can lambda help?
Lambda can be used if the body can be written as a
single expression. Otherwise you need to write the
function as a separate def. When the body is more
than a line or two, this is not usually much of
a problem, and is arguably more readable anyway.
--
Greg
Ken Tilton ha escrito:
> It is just a matter of critical mass. At some very low threshold Lisp
> becomes "OK". I get the feeling that has already begun, but it is not
> quite there yet.
Sometime in the past LISP got an increased 'popularity' (i suspect
because LISP natural fit into web services). However, i also noticed
that since some months ago, the TIOBE index for LISP decreases and
decreases and decreases... whereas Python, Ruby, and company increase.
Last December index, Ruby increases ranking by 9 positions to 11th,
Python 1 to 7th, whereas LISP decreases to 17th from 13th.
Ken Tilton wrote:
>
> Lisp has all the cool qualities you like in your pets, plus native
> compilation in most implementations, plus maturity and a standard, plus
> a better OO, plus macros, plus a dozen more small wins. Including
> automatic indentation. :)
>
Better OO? You mean the one that doesn't support basic encapsulation
and is retardedly cumbersome to use? There's a reason I said, I'd never
use Lisp for OO not even when I'm high. Gimme Python, Eiffel or
Smalltalk anyday, not the retarded add-on package bolted on CL.
> It is just a matter of critical mass. At some very low threshold Lisp
> becomes "OK". I get the feeling that has already begun, but it is not
> quite there yet. Certainly it gets mentioned now when language names get
> bandied about, if only to be dismissed. That is a step up for us. :)
>
Bahahahaha! You lispers and your fairy little macros world.
mystilleef wrote:
> Ken Tilton wrote:
>
>>Lisp has all the cool qualities you like in your pets, plus native
>>compilation in most implementations, plus maturity and a standard, plus
>>a better OO, plus macros, plus a dozen more small wins. Including
>>automatic indentation. :)
>>
>
>
> Better OO? You mean the one that doesn't support basic encapsulation
> and is retardedly cumbersome to use? There's a reason I said, I'd never
> use Lisp for OO not even when I'm high. Gimme Python, Eiffel or
> Smalltalk anyday, not the retarded add-on package bolted on CL.
>
>
>>It is just a matter of critical mass. At some very low threshold Lisp
>>becomes "OK". I get the feeling that has already begun, but it is not
>>quite there yet. Certainly it gets mentioned now when language names get
>>bandied about, if only to be dismissed. That is a step up for us. :)
>>
>
>
> Bahahahaha! You lispers and your fairy little macros world.
>
I admire your knack for self-refuting discourse.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
"mystilleef" <··········@gmail.com>:
> Better OO? You mean the one that doesn't support basic encapsulation
> and is retardedly cumbersome to use?
Encapsulation isn't so much a property of the language as of your data
types.
> There's a reason I said, I'd never use Lisp for OO not even when I'm
> high. Gimme Python, Eiffel or Smalltalk anyday, not the retarded
> add-on package bolted on CL.
Python also lacks encapsulation, in the sense you probably mean.
--
Björn Lindström <····@stp.lingfil.uu.se>
Student of computational linguistics, Uppsala University, Sweden
Björn Lindström wrote:
> Encapsulation isn't so much a property of the language as of your data
> types.
"Modern" and well designed object oriented languages provide sane
mechanisms for encapsulation, at least when implementing new types.
> Python also lacks encapsulation, in the sense you probably mean.
>
That's news to me. How so?
mystilleef schrieb:
> Ken Tilton wrote:
>> Lisp has all the cool qualities you like in your pets, plus native
>> compilation in most implementations, plus maturity and a standard, plus
>> a better OO, plus macros, plus a dozen more small wins. Including
>> automatic indentation. :)
>>
>
> Better OO? You mean the one that doesn't support basic encapsulation
> and is retardedly cumbersome to use? There's a reason I said, I'd never
> use Lisp for OO not even when I'm high. Gimme Python, Eiffel or
> Smalltalk anyday, not the retarded add-on package bolted on CL.
What do you mean with "encapsulation" in this context?
I am looking for something that Pythons or Smalltalks OO system have
which isn't in Lisps...
Andr�
--
André Thieme wrote:
[...]
> What do you mean with "encapsulation" in this context?
Presumably that CLOS makes no attempt to enforce the distinction
between "private" and "public" methods or class slots. I suppose you
can indicate that certain classes, generic functions et c. are
"private" by not exporting the symbols associated with them from the
relevant package, but even then you merely have a way to communicate
your intent to the user, not a way to force them to keep their hands
off.
ISTR that it's easy to get at "private" things in Python, too, so I'd
be surprised if this were a make-or-break issue for Pythonistas.
Cheers,
Pillsy
Andr� Thieme wrote:
> mystilleef schrieb:
>
>> Ken Tilton wrote:
>>
>>> Lisp has all the cool qualities you like in your pets, plus native
>>> compilation in most implementations, plus maturity and a standard, plus
>>> a better OO, plus macros, plus a dozen more small wins. Including
>>> automatic indentation. :)
>>>
>>
>> Better OO? You mean the one that doesn't support basic encapsulation
>> and is retardedly cumbersome to use? There's a reason I said, I'd never
>> use Lisp for OO not even when I'm high. Gimme Python, Eiffel or
>> Smalltalk anyday, not the retarded add-on package bolted on CL.
>
>
> What do you mean with "encapsulation" in this context?
Mr. mystilleef's remarks struck me as needlessly contentious and perhaps
unavoidably ignorant, hence unworthy of response. YMMV.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> You know, I'm really starting to think that you Lispers -- and I hate to
> generalise, but in this case I feel I'm forced to -- have a real problem
You feel you're forced to generalize about an entire group of language
users based on what a handful of people have posted on a newsgroup?
> So which is it? If Lisp is so self-evidently better than every other
> language, and if nobody has any fears or concerns with Lisp, why is Lisp a
> fringe language? Not as fringe as it was ten years ago, and maybe growing
> in popularity, and it is beyond all doubt that Lisp has a lot of influence
> amongst language designers, but outside of a few niche areas, its still a
> fringe language.
I'd like to know the answer. But the problem most people cite is the
parentheses, not the fear that someone will abuse macros. I have
certainly never seen anyone as worried about macros as you seem to be.
>>> My point isn't whether or not their claims are correct (a "couple" of
>>> macros? really?) but that things like this feed the perception that Lisp
>>> is close to that hypothetical language where anything could be anything.
>>> If anything could be anything, do you really know what (+ 1 2) means
>>> without reading every line of code?
>>
>> Jesus H Christ. Didn't you just get through talking about how easily
>> someone can redefine built-ins in Python?
>
> Yes. But you can't redefine 1+2 in Python, at least not without hacking
> the interpreter. Can you redefine (+ 1 2) in Lisp?
Yes. Can't you redefine standard functions in Python?
Frank Buss correctly points out that you can shadow the + symbol and
make it whatever you'd like it to be. This is true, but now someone
has to intentionally and specifically import the package containing
that shadowed + into their own package. You are never unwittingly
using a different + than the standard CL one, although you really seem
to want this to be the case.
>>> (This is an interesting demonstration that any language that allows file
>>> I/O and importing of external program files can always treat functions
>>> as data, even if the language doesn't directly support it. An alternative
>>> would be to keep the strings in memory instead of writing to a module,
>>> then use exec on them instead of importing the module.)
>>
>> No, it treats code as text. See the difference?
>
> Text is data.
>
> What is the point of your comment? You don't have to argue about every
> thing I say, even the ones we agree on. Look again at what I wrote. Is
> there anything that gave you the impression that I think that having the
> ability to write text to a file and import it is better than actually
> supporting functional programming directly?
Well, text is not code. Text is a syntaxful representation of the
actual code, which is an AST. If I have a string full of text, I
can't do very much meaningful work with it. On the other hand, if I
have an AST, I can transform it or analyze it however I choose.
>> Could you calm down?
>
> Okay, once was funny. Twice is worrying. What exactly is giving you the
> idea I need to calm down? Was it the use of reasoning and logic?
> Perhaps it was the attempt to be reasonable and moderate and find some
> middle ground that we could agree on, or if not agree, at least say "Well,
> I disagree with you, but at least I understand where you are coming from"?
Where I'm coming from? Dude, you're writing paragraph upon paragraph
about the same thing, multiple times per day. You're terrified of
worst-case scenarios that everyone else is telling you are not
realistic.
Bill Atkins <······@rpi.edu> writes:
>> Yes. But you can't redefine 1+2 in Python, at least not without hacking
>> the interpreter. Can you redefine (+ 1 2) in Lisp?
>
> Yes. Can't you redefine standard functions in Python?
>
> Frank Buss correctly points out that you can shadow the + symbol and
> make it whatever you'd like it to be.
Well, there is no "THE + symbol", there are a lot of different symbols
named "+". The one you get when you read the characters of "(+ 1 2)"
depends on the dynamic binding of the COMMON-LISP:*PACKAGE* symbol.
> This is true, but now someone
> has to intentionally and specifically import the package containing
> that shadowed + into their own package. You are never unwittingly
> using a different + than the standard CL one, although you really seem
> to want this to be the case.
The Common Lisp standard has no provision to and indeed forbid to
modify the function binding of the COMMON-LISP:+ symbol.
On the other hand, implementations may allow, sometimes with the help
of an implementation specific WITHOUT-PACKAGE-LOCK operator, to change
the function binding of the COMMON-LISP:+ symbol.
So, while the standard preserves itself, and wants you to explicitely
say you're using a symbol named "+" from a different package than
COMMON-LISP, rather than modifying CL:+, the implementations may still
allow you to actually modify the COMMON-LISP package, but of course,
this may not be Common Lisp anymore, if you don't follow the
specifications of Common Lisp (and if you do, why are you trying to
modify CL:+ that already implements Common Lisp!?).
--
__Pascal Bourguignon__ http://www.informatimago.com/
This universe shipped by weight, not volume. Some expansion may have
occurred during shipment.
Pascal Bourguignon <···@informatimago.com> writes:
>> This is true, but now someone
>> has to intentionally and specifically import the package containing
>> that shadowed + into their own package. You are never unwittingly
>> using a different + than the standard CL one, although you really seem
>> to want this to be the case.
>
> The Common Lisp standard has no provision to and indeed forbid to
> modify the function binding of the COMMON-LISP:+ symbol.
I'm not talking about redefining the + symbol; I'm talking about
shadowing it and defining a new function on a different symbol that
has the same symbol-name.
In article
<······························@REMOVE.THIS.cybersource.com.au>,
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
> Yes. But you can't redefine 1+2 in Python, at least not without hacking
> the interpreter. Can you redefine (+ 1 2) in Lisp?
Not without barreling through error messages about name conflicts.
Kirk Sluder wrote:
> In article
> <······························@REMOVE.THIS.cybersource.com.au>,
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
>
> > Yes. But you can't redefine 1+2 in Python, at least not without hacking
> > the interpreter. Can you redefine (+ 1 2) in Lisp?
>
> Not without barreling through error messages about name conflicts.
By LISP do you mean CL?
In Scheme next
(+ 1 2)
--> -1
is possible. It would be possible in other dialects of LISP also
On Sun, 10 Dec 2006 14:21:17 +0000, Kirk Sluder wrote:
> In article
> <······························@REMOVE.THIS.cybersource.com.au>,
> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
>
>> Yes. But you can't redefine 1+2 in Python, at least not without hacking
>> the interpreter. Can you redefine (+ 1 2) in Lisp?
>
> Not without barreling through error messages about name conflicts.
Ah, nice to get a straight answer to a question for a change, and without
an insult or a misrepresentation in sight. Thank you.
--
Steven
On Mon, 11 Dec 2006 02:51:50 +1100, Steven D'Aprano wrote:
> On Sun, 10 Dec 2006 14:21:17 +0000, Kirk Sluder wrote:
>
>> In article
>> <······························@REMOVE.THIS.cybersource.com.au>,
>> Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
>>
>>> Yes. But you can't redefine 1+2 in Python, at least not without hacking
>>> the interpreter. Can you redefine (+ 1 2) in Lisp?
>>
>> Not without barreling through error messages about name conflicts.
>
> Ah, nice to get a straight answer to a question for a change, and without
> an insult or a misrepresentation in sight. Thank you.
Such a pity that answer is, apparently, wrong.
Thank you to those who wrote back with the more accurate answer, which
apparently is "yes, it is easy and there are no error messages".
I'd love to say it has been fun, but it has been more frustrating than
enjoyable. I don't mind an honest disagreement between people who
genuinely are trying to see the other's point of view, but I don't think
that was the case here. What was especially frustrating was that the more
I tried to understand certain Lispers' positions by asking questions, the
more nasty and insulting they became. So now I have an even better
understanding for why Lispers have a reputation for being difficult and
arrogant.
(And believe me, I could say a lot more about that, but I'm trying to be
conciliatory, so I'll just shut up now.)
But I also gained a little more insight into why Lispers love their
language. I've learnt that well-written Lisp code isn't as hard to read as
I remembered, so I'd just like to withdraw a comment I made early in the
piece. I no longer believe that Lisp is especially strange compared to
natural languages.
Anyway, real life catches up on me, and so I must drop out of this thread.
May it not last for ever.
--
Steven.
Steven D'Aprano wrote:
> I'd love to say it has been fun, but it has been more frustrating than
> enjoyable. I don't mind an honest disagreement between people who
> genuinely are trying to see the other's point of view, but I don't think
> that was the case here. What was especially frustrating was that the more
> I tried to understand certain Lispers' positions by asking questions, the
> more nasty and insulting they became. So now I have an even better
> understanding for why Lispers have a reputation for being difficult and
> arrogant.
This is only because they openly disagree with your beliefs. Note that
you appear the same way to your Lisp-using flamewarrior counterparts.
We might look in the mirror:
<http://www.escapefromcubiclenation.com/get_a_life_blog/2006/04/how_the_technog.html>
Maybe Lisp users are singled out as particularly arrogant because they
claim that the last 20 or so years of the software profession have been
something of a fraud.
Tayssir
············@googlemail.com wrote:
> Steven D'Aprano wrote:
> > I'd love to say it has been fun, but it has been more frustrating than
> > enjoyable. I don't mind an honest disagreement between people who
> > genuinely are trying to see the other's point of view, but I don't think
> > that was the case here. What was especially frustrating was that the more
> > I tried to understand certain Lispers' positions by asking questions, the
> > more nasty and insulting they became. So now I have an even better
> > understanding for why Lispers have a reputation for being difficult and
> > arrogant.
>
> This is only because they openly disagree with your beliefs. Note that
> you appear the same way to your Lisp-using flamewarrior counterparts.
>
> We might look in the mirror:
> <http://www.escapefromcubiclenation.com/get_a_life_blog/2006/04/how_the_technog.html>
>
> Maybe Lisp users are singled out as particularly arrogant because they
> claim that the last 20 or so years of the software profession have been
> something of a fraud.
Well, having read a lot of this thread, I can see one of the
reasons why the software profession might want to avoid
lispies. With advocacy like this, who needs detractors?
·····@yahoo.com wrote:
> Well, having read a lot of this thread, I can see one of the
> reasons why the software profession might want to avoid
> lispies. With advocacy like this, who needs detractors?
And thus your plan for breaking into the software profession is ... to
develop Usenet advocacy skills.
``That guy we just interviewed, I don't know. Perfect score on the C++
test, lots of good architectural knowledge, but he seems to care more
about being correct than convincing people. He'd be fine for now, but
what does that say about his ability when the crunch comes, and he's
called upon to ... advocate?''
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> I'd love to say it has been fun, but it has been more frustrating than
> enjoyable. I don't mind an honest disagreement between people who
> genuinely are trying to see the other's point of view, but I don't think
> that was the case here. What was especially frustrating was that the more
> I tried to understand certain Lispers' positions by asking questions, the
> more nasty and insulting they became. So now I have an even better
Could that be because you were submitting enormous posts making the
same claim and ignoring any new developments several times a day?
> But I also gained a little more insight into why Lispers love their
> language. I've learnt that well-written Lisp code isn't as hard to read as
> I remembered, so I'd just like to withdraw a comment I made early in the
> piece. I no longer believe that Lisp is especially strange compared to
> natural languages.
Strange that you'd come to that conclusion. I thought we'd
established higher up that most programming languages are not like
natural languages
Steven D'Aprano wrote:
>
> But I also gained a little more insight into why Lispers love their
> language. I've learnt that well-written Lisp code isn't as hard to read as
> I remembered, so I'd just like to withdraw a comment I made early in the
> piece. I no longer believe that Lisp is especially strange compared to
> natural languages.
>
> Anyway, real life catches up on me, and so I must drop out of this thread.
> May it not last for ever.
>
And I have heard why Pythonistas like their language. They can get things
accomplished in it. The best positive feedback is success. You can get
lost in theoretical, metaphorical discussions about computer languages.
It is frustrating and in many cases pointless.
As for why you have seen conflicting answers and, yes, sometimes hostile
responses. I have no idea. But, I think I have come to a point in my
life where I do not need to be right.
W
Steven D'Aprano wrote:
> I'd love to say it has been fun, but it has been more frustrating than
> enjoyable. I don't mind an honest disagreement between people who
Honest disagreement requires parties who are reasonably informed, and
who are willing not to form opinions about things that they have no
experience with.
> So now I have an even better understanding for why Lispers have a reputation for being difficult and
> arrogant.
Whereas, for instance, lecturing a Lisp newsgroup (of all places) in
the following manner isn't arrogant, right?
``Turing Complete. Don't you Lisp developers know anything about
computer science? ''
If that had been intended to be funny, you should have made that more
clear by choosing, say, lambda calculus as the subject.
> But I also gained a little more insight into why Lispers love their
> language. I've learnt that well-written Lisp code isn't as hard to read as
> I remembered, so I'd just like to withdraw a comment I made early in the
> piece.
You /think/ you learned that, but in reality you only read some
/opinions/ that Lisp isn't as hard to read as was maintained by your
previously held opinions. Second-hand opinions are only little better
than spontaneous opinions. It's, at best, a slightly favorable trade.
> I no longer believe that Lisp is especially strange compared to natural languages.
Natural languages are far less completely understood than any
programming language. Only your own, and perhaps some others in nearby
branches of the language tree do not appear strange to you.
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
>>>
>>>> Yes. But you can't redefine 1+2 in Python, at least not without hacking
>>>> the interpreter. Can you redefine (+ 1 2) in Lisp?
>>>
>>> Not without barreling through error messages about name conflicts.
>>
>> Ah, nice to get a straight answer to a question for a change, and without
>> an insult or a misrepresentation in sight. Thank you.
>
> Such a pity that answer is, apparently, wrong.
>
> Thank you to those who wrote back with the more accurate answer, which
> apparently is "yes, it is easy and there are no error messages".
Yes, you can do it if you want--but you have to explicitly say that
you're doing so. In other words, it wouldn't happen by accident. And
due to the package system, package A doing it wouldn't infect package B
unless B allowed it to.
In other words, you have to put the bullet in the chamber, take off the
safety and point the gun at your foot.
--
Robert Uhl <http://public.xdi.org/=ruhl>
What some idiot in Glasgow or NYC, what a million idiots do, has nothing
at all to do with me, I can only be judged by the actions I take with my
possessions. To do anything else is to spit upon my existence as an
individual human. --R.D. Metcalf
Steven D'Aprano wrote:
> Yes. But you can't redefine 1+2 in Python, at least not without hacking
> the interpreter. Can you redefine (+ 1 2) in Lisp?
Yes, that's no problem and works without warnings and in every Common Lisp
implementation:
CL-USER > (shadow '+)
T
CL-USER > (defun + (&rest rest) (apply #'- rest))
+
CL-USER > (+ 3 1)
2
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Dmitry V. Gorbatovsky
Subject: Re: merits of Lisp vs Python
Date:
Message-ID: <elh82m$evq$1@aioe.org>
Steven D'Aprano wrote:
> So which is it? If Lisp is so self-evidently better than every other
> language, and if nobody has any fears or concerns with Lisp, why is Lisp a
> fringe language?
Because shifting to lisp somewhere in the middle of
your project or carear is VERY EXPENSIVE STEP.
And its doubtable movement for absolute majority
of GUI's button makers.
Steven D'Aprano schrieb:
> Yes. But you can't redefine 1+2 in Python, at least not without hacking
> the interpreter. Can you redefine (+ 1 2) in Lisp?
It is possible as was pointed out.
If anyone would do it, he/she would do it inside a package.
Then you would write:
(package:+ 1 2)
So in real world programs there is no danger.
In Python I could just say
def list():
return 30
and won't get a warning. In Lisp I would at least have to shadow +
explicitely.
In Python it can't happen because + is not a function.
And what do you do if you want to pass + as a HOF?
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> In Python it can't happen because + is not a function.
> And what do you do if you want to pass + as a HOF?
Use a lambda. There's a library module (use "import operator") that
exports functions for most of these operators. It's used sometimes
but not all that often. You could think of Python as sort of a
Huffman code. It tries to make the most common operations very
convenient, sometimes at the expense of the less common ones.
In article
<······························@REMOVE.THIS.cybersource.com.au>,
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
> On Sat, 09 Dec 2006 21:55:19 +0000, Kirk Sluder wrote:
>
> Who says they do? All forms of abstraction have been criticized. Sometimes
> the criticism is valid. Sometimes it warns against abuses of the
> abstraction. Just because a feature is useful sometimes doesn't
> necessarily mean the benefit outweighs the cost.
The primary focus of the criticism in this discussion has been that
macros are a bad from of abstraction compared to libraries, (and I'm
admittedly extending that to objects, functions and classes.)
> But at least you know that foolib is a module or package. You know what
> from and import do, and that can't change. And you know that bar is an
> object with a method also called bar, it is being called, and the
> argument is a string "somefile". Those things can't change. Imagine a
> hypothetical language where those two lines could mean *anything*.
But as was pointed out earlier in the thread, those keywords can be
overshadowed by custom functions in python as well. The only reason
that we don't assume those two python lines could mean *anything* is
because those mechanisms are not well advertised, and most people
don't have a need to shadow "import."
Of course, it is possible to abstract away all of the lisp in such a
way that you have a completely new programming language. But is this
really a problem? Perl5 and bash are abstractions of C. Python has
been implemented on both C and java, and chunks of perl6 have been
implemented on top of Haskell. Completely new programming languages
and frameworks develop their own base of knowledge and expertise
separate from the parent language.
> My point isn't whether or not their claims are correct (a "couple" of
> macros? really?) but that things like this feed the perception that Lisp
> is close to that hypothetical language where anything could be anything.
> If anything could be anything, do you really know what (+ 1 2) means
> without reading every line of code?
How do you know that operator has not been shadowed or overloaded in
python? In most cases what you have to do is trust both the
underlying implementation, and the author(s) of the libraries you
use.
Both python and lisp share mechanisms to protect namespaces is part
of the answer. So one way to protect myself is to run my code in
it's own namespace, and require explicit addressing of imported
functions and constructs. In this way I can be pretty certain that
(+ 1 2) uses the lisp primitives, and has not been shadowed, while
(SOMEPACKAGE:+ 1 2) should be treated with suspicion.
The process of writing lisp often involves access to the REPL, so I
can have lisp expand the definition of any expression:
CL-USER> (macroexpand '(+ 1 2))
(+ 1 2)
NIL
CL-USER> (macroexpand '(loop for i upto 100 collect i))
(BLOCK NIL
...<expansion snipped for brevity>...
)
T
CL-USER>
This tells me that + is not a macro in my current environment. While
loop is.
And at least one of the powerful aspects of lisp is than since lisp
programs are nested stets of s-expressions, you can design something
that walks through the code and highlights all macro calls, and
foreign functions that shadow native functions. I don't how
difficult this would be for languages such as python.
... extended argument snipped ...
> Or maybe it is only an advantage while Lisp programmers are a
> self-selected group of above-average skill. Wait until fifty million VB
> code monkeys start writing Lisp macros and maybe, just maybe, you'll wish
> they were using a less powerful and more restrictive language.
Perhaps it's because I'm a social scientist and not a programmer by
training, but I find many arguments for *technical* solutions to
*human performance* problems to be rather weak as a general
practice. In some cases, using a very restrictive language may be
the best solution for the problem. However, there are plenty of
other ways around the problem that can be tailored to special needs.
In addition to sandboxing macros into packages and walking the code
to detect macros, you could run a custom lisp image that does not
permit DEFMACRO or enforces documentation on DEFMACRO. Or you could
rely on social mechanisms like only using libraries from trusted
sources, and better training of those code monkeys.
On Sun, 10 Dec 2006 03:37:26 +0000, Kirk Sluder wrote:
>> But at least you know that foolib is a module or package. You know what
>> from and import do, and that can't change. And you know that bar is an
>> object with a method also called bar, it is being called, and the
>> argument is a string "somefile". Those things can't change. Imagine a
>> hypothetical language where those two lines could mean *anything*.
>
> But as was pointed out earlier in the thread, those keywords can be
> overshadowed by custom functions in python as well.
Really?
>>> def import():
File "<stdin>", line 1
def import():
^
SyntaxError: invalid syntax
Nope, can't shadow or change keywords. (And yes, the error message could
be better.)
> The only reason
> that we don't assume those two python lines could mean *anything* is
> because those mechanisms are not well advertised, and most people
> don't have a need to shadow "import."
Or because they can't mean just anything.
> Of course, it is possible to abstract away all of the lisp in such a
> way that you have a completely new programming language. But is this
> really a problem? Perl5 and bash are abstractions of C. Python has
> been implemented on both C and java, and chunks of perl6 have been
> implemented on top of Haskell.
That depends. If somebody smart is designing a new programming language,
then no, you get a new programming language.
If somebody not-so-smart is merely hammering the round peg of Lisp into
the square hole of not-quite-Lisp-and-not-quite-anything-else, then yes,
that will be a problem. But apparently, despite the talk of using macros
to implement anything in Lisp, nobody actually does that.
>> My point isn't whether or not their claims are correct (a "couple" of
>> macros? really?) but that things like this feed the perception that Lisp
>> is close to that hypothetical language where anything could be anything.
>> If anything could be anything, do you really know what (+ 1 2) means
>> without reading every line of code?
>
> How do you know that operator has not been shadowed or overloaded in
> python?
Because the tokens 1 and 2 cannot be anything but ints, and + with two
int args cannot be anything but addition.
>> Or maybe it is only an advantage while Lisp programmers are a
>> self-selected group of above-average skill. Wait until fifty million VB
>> code monkeys start writing Lisp macros and maybe, just maybe, you'll wish
>> they were using a less powerful and more restrictive language.
>
> Perhaps it's because I'm a social scientist and not a programmer by
> training, but I find many arguments for *technical* solutions to
> *human performance* problems to be rather weak as a general
> practice. In some cases, using a very restrictive language may be
> the best solution for the problem.
I don't know about you, but I'm not talking about VERY restrictive
languages -- I'm using Python, which isn't very restrictive at all. But
even Lisp has some restrictions -- you can't jump to an arbitrary memory
location and treat whatever random bytes are there as executable code, can
you?
--
Steven.
Steven D'Aprano schrieb:
> >>> def import():
> File "<stdin>", line 1
> def import():
> ^
> SyntaxError: invalid syntax
>
>
> Nope, can't shadow or change keywords. (And yes, the error message could
> be better.)
I have a very interesting Python module. Look what it does:
======= python ====================
>>> import a
>>> import b
You sucker thought I'd import b for you.
Instead I'm going to erase your hard drive.
================================
Somehow the meaning of "import" changed between the first
and the second line. Doesn't it frighten you?
(BTW: Do you know how that works, or should a Lisper show
you?)
It seems that Phytonistas, including Guido, don't trust each
other. Guido always provides half assed restrictive solutions
instead of decent meta programming. Examples include "lambda",
the new "with" syntax and decorators.
hit_the_lights wrote:
>
[import side-effects]
> Somehow the meaning of "import" changed between the first
> and the second line. Doesn't it frighten you?
> (BTW: Do you know how that works, or should a Lisper show
> you?)
Given that the meaning of import doesn't need to have changed to bring
out the described consequences, I guess anyone wanting to know more
won't be asking you specifically.
> It seems that Phytonistas, including Guido, don't trust each
> other. Guido always provides half assed restrictive solutions
> instead of decent meta programming. Examples include "lambda",
> the new "with" syntax and decorators.
Actually there are people in the Python community who don't really
approve of stuff like "with", the removal of "lambda" and the lack of
macros, "programmable syntax", and so on. But that's probably not
apparent to those who paint every picture with broad strokes.
Paul
Paul Boddie schrieb:
> Given that the meaning of import doesn't need to have changed to bring
> out the described consequences, I guess anyone wanting to know more
> won't be asking you specifically.
I should have added some lines:
==== python ====================
>>> import a
>>> import b
You sucker thought I'd import b for you.
Instead I'm going to erase your hard drive.
>>> a
<module 'a' from 'a.pyc'>
>>> b
>>>
==============================
I was suprised that b was defined at all.
hit_the_lights wrote:
>
> I should have added some lines:
>
> ==== python ====================
> >>> import a
> >>> import b
> You sucker thought I'd import b for you.
> Instead I'm going to erase your hard drive.
> >>> a
> <module 'a' from 'a.pyc'>
> >>> b
> >>>
> ==============================
>
> I was suprised that b was defined at all.
Well, I've done all sorts of things with Python's import machinery, and
I'd prefer not to stare too long at its implementation, but both import
statements by their very nature in Python are still import statements.
Of course you can always argue that some undesirable effect of
redefining the keyword via a macro is also achievable by misusing the
import machinery, that both things are therefore just as dangerous, and
that macros are inherently no more dangerous than exposed library
mechanisms employed by the virtual machine. I'd agree generally with
that reasoning, and you can see in various features of Python that lots
of covert side-effects can be introduced which would prove surprising
to the casual developer when he or she uses some seemingly harmless
construct. (Interestingly, some of the newer features in Python could
have been introduced using macros, and perhaps EasyExtend already
demonstrates this.)
Ultimately, I think that the main point of contention is little to do
with macros or their absence from Python. Instead, it's more about
people coming to an agreement about form and behaviour guarantees for
Python programs - in other words, what you can expect when you open a
Python source file and start reading the code. It should be noted that
attitudes are generally negative towards careless redefinition of
fundamental or common concepts or mechanisms of the language, just as I
imagine it would be with Lisp, and one only needs to consider reactions
to various Ruby-related advocacy to see where the many in the Python
community supposedly draw the line at things like pervasive
monkey-patching of built-in classes. To bring that maligned natural
language analogy back into repute, I'd argue that Python and its
apparent restrictions act a lot like the specialised vocabularies and
familiar structures employed when presenting material in various
scientific disciplines: one could argue, upon reading a paper, that it
would have been a lot easier for the author to have structured the
paper differently and to have defined a one-off vocabulary, but issues
of convenient communication are highly likely to override such
considerations, especially in disciplines where conventions in
communication are already very strictly defined.
Paul
Paul Boddie wrote:
> To bring that maligned natural
> language analogy back into repute, I'd argue that Python and its
> apparent restrictions act a lot like the specialised vocabularies and
> familiar structures employed when presenting material in various
> scientific disciplines: one could argue, upon reading a paper, that it
> would have been a lot easier for the author to have structured the
> paper differently and to have defined a one-off vocabulary, but issues
> of convenient communication are highly likely to override such
> considerations, especially in disciplines where conventions in
> communication are already very strictly defined.
Keeping with the analogy, Lisp offers power to adapt your notation to
the domain you're describing. One thing people expect from a language
is a certain malleability in order for it to somehow resemble the
domain they're describing.
So for example, Lisp may not offer infix syntax by default, but there
exist infix libraries you can download. (Haven't used it myself
though.)
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/0.html
In this sense, you can see that Lisp's syntax is rather general and can
be molded. Within the constraints of typical text sourcecode.
Tayssir
············@googlemail.com wrote:
>
> Keeping with the analogy, Lisp offers power to adapt your notation to
> the domain you're describing. One thing people expect from a language
> is a certain malleability in order for it to somehow resemble the
> domain they're describing.
I think the more interesting issue of relevance to both communities
(and I wonder whether the original inquirer is still reading) is
whether a language like Python is an acceptable specialised notation
for so many domains as to make a more malleable language like Lisp less
interesting for most specialists. In other words, that there are so
many areas where Python's arguably mundane semantics are sufficient
that the specialists have their convenient, common means of
communication which happens to span large areas of computational
endeavour. And on the occasions where Python doesn't provide adequate,
convenient metaprogramming features, might it not be the case that less
elegant program transformation mechanisms or even other approaches to
architectural design aren't good enough solutions? After all, the
various object-oriented design movements, for example, even though they
may be regarded as having produced clumsy and verbose mechanisms for
expressing certain kinds of systems, have in some way or other provided
a recognisable vocabulary that many people understand.
Paul
Paul Boddie wrote:
> ············@googlemail.com wrote:
> > Keeping with the analogy, Lisp offers power to adapt your notation to
> > the domain you're describing. One thing people expect from a language
> > is a certain malleability in order for it to somehow resemble the
> > domain they're describing.
>
> I think the more interesting issue of relevance to both communities
> (and I wonder whether the original inquirer is still reading) is
> whether a language like Python is an acceptable specialised notation
> for so many domains as to make a more malleable language like Lisp less
> interesting for most specialists. In other words, that there are so
> many areas where Python's arguably mundane semantics are sufficient
> that the specialists have their convenient, common means of
> communication which happens to span large areas of computational
> endeavour.
Well, I think it's twofold:
* How well do languages keep up with changing requirements and
paradigms?
* Don't you want a domain expert (perhaps you) designing your problem
domain's notation, someone who cares deeply about the problems you
face?
When Python is fine for your domain, great. But as you stray from the
intention of Python's central designers, your code loses correspondence
with your problem domain.
For example, this book offers a case study in an mp3 parser syntax
which corresponds visually to the spec:
<http://www.gigamonkeys.com/book/>
Or here are some simple examples, with HTML:
<http://weitz.de/cl-who/#example>
> And on the occasions where Python doesn't provide adequate,
> convenient metaprogramming features, might it not be the case that less
> elegant program transformation mechanisms or even other approaches to
> architectural design aren't good enough solutions? After all, the
> various object-oriented design movements, for example, even though they
> may be regarded as having produced clumsy and verbose mechanisms for
> expressing certain kinds of systems, have in some way or other provided
> a recognisable vocabulary that many people understand.
OOP is actually a good example. Alan Kay stated: "I invented the term
Object-Oriented, and I can tell you I did not have C++ in mind." (From
a link I gave earlier.)
The central designers behind C++ were certainly thoughtful. But they
weren't all OOP experts. There should be some room for interested
people to easily experiment with a new paradigm's concepts. After going
through enough testing and common use, it can even be folded into the
language itself.
There's another anecdote. At LL2, a convention of language designers, I
recall the guy from Microsoft Research wanted nondeterminism in a
programming language. But you can actually download a Lisp library
which provides nondeterministic computing features.
<http://ll2.ai.mit.edu/>
<http://www.cliki.net/Screamer>
YMMV, as usual.
Tayssir
In article
<······························@REMOVE.THIS.cybersource.com.au>,
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> wrote:
> That depends. If somebody smart is designing a new programming language,
> then no, you get a new programming language.
>
> If somebody not-so-smart is merely hammering the round peg of Lisp into
> the square hole of not-quite-Lisp-and-not-quite-anything-else, then yes,
> that will be a problem. But apparently, despite the talk of using macros
> to implement anything in Lisp, nobody actually does that.
Then what exactly is your argument here?
And BTW:
CL-USER> (defun + (a b))
Lock on package COMMON-LISP violated when setting fdefinition of +.
[Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]
While lisp doesn't prohibit such name conflicts, it does mean that
anyone trying it will generate a fair number of errors each time the
definition is compiled.
> > Perhaps it's because I'm a social scientist and not a programmer by
> > training, but I find many arguments for *technical* solutions to
> > *human performance* problems to be rather weak as a general
> > practice. In some cases, using a very restrictive language may be
> > the best solution for the problem.
>
> I don't know about you, but I'm not talking about VERY restrictive
> languages -- I'm using Python, which isn't very restrictive at all. But
> even Lisp has some restrictions -- you can't jump to an arbitrary memory
> location and treat whatever random bytes are there as executable code, can
> you?
Certainly, and I've even pointed out a few that would mediate
against your claim of incompetent programmers being able to
arbitrarily shadow core functions in a way that is invisible to
anyone else.
Steven D'Aprano <·····@REMOVE.THIS.cybersource.com.au> writes:
> Is that an argument against factory functions? Damn straight it is:
> they are a powerful tool, and in the hands of morons, they can be
> dangerous. Does that mean that languages shouldn't permit
> higher-order functions? Not necessarily: all programming tools can
> be misused, but some can be misused more easily than others. Power
> and risk is often a trade-off, and language designers can't
> eliminate all risk of stupid behaviour, but they can design the
> language to allow whatever level of risk they believe is
> acceptable. (E.g. there is no doubt that C's raw pointers are
> powerful, but many languages deliberately don't use them.)
I understand your point, I understand the Java folks. But I think this
point of view is really wrong. The right solution would be to better
train people, to give more good examples or even to not employ those,
who don't grasp it.
You point of view is that of (big) companies: Every developer should
be equal, exchangable. I'm very sure this is only an illusion. And I
think this point of view leads to many failures of (big)
projects. Each project has it's working horse(s) and these are quite
more equal than the others. :)
To deny the good developers, the working horses the power they need
isn't a good idea. Give them all the tools they need and let others
learn from them -- so (nearly) everybody becomes a good to great
developer.
Am I naive? Maybe...
> The risk of stupid factory functions is small compared to the
> benefit, but maybe there is some domain somewhere where the ideal
> solution is a language that DOESN'T treat functions as first class
> objects, deliberately weakening the language so that a particular
> class of errors (or stupid behaviour) just cannot happen.
And with Lisp macros the good developers may easily create these DSLs
to be used by the not so good developers. :)
> That's the perspective of many people, and maybe it is wrong. Maybe
> you really need to be immersed in Lisp for a while to see the
> advantages of macros.
Yes, I think this perspective is wrong. Some time ago I wondered about
the hype of LinQ -- with Lisp macros it's already there. These things,
embedded languages (like embedded SQL, embedded Prolog, ...) are
really great. I also hate the amount of boilerplate code nesseccary in
Java -- yes, in Python it's muss less, but in Lisp it really vanished.
If you use a really good designed language which don't assume every
programmer to be dumb and equal, yes, maybe macros would be not that
big a bonus. But hey, they are not worse than operator overloading and
the like, so why not include them? (Answer: In most cases it's hard to
add macros because of non-homogenous syntax.) :)
--
Stefan.
Steven D'Aprano wrote:
> > from foolib import *
> > bar.bar("somefile")
> >
> > What does this program do? I have no idea. Its functionality is
> > hidden behind multiple layers of abstraction (function, object,
> > library.)
>
> Sure.
>
> But at least you know that foolib is a module or package. You know what
> from and import do, and that can't change. And you know that bar is an
> object with a method also called bar, it is being called, and the
> argument is a string "somefile". Those things can't change. Imagine a
> hypothetical language where those two lines could mean *anything*.
Oh, you mean imagining a hypothetical language like Python? Where bar
might not have a method bar at all? Where it might be a property set to
an intance of a class with __call__ method? Oh where a metaclass for
bar can intercept a request for "bar" property, do *anything* and call
sys.exit() without even getting to the ("somefile") part?
Thanks, it was fun to hear about Python being hypothetical.
mystilleef wrote:
> Rewriting the sun and moon, or needlessly reinvent the wheel
> was popular in the 70s, but it's boring and expensive today. Today,
> when a developer needs to solve a problem, the question they ask is,
> "Is there a library for that?". If the answer is no, they a more likely
> to switch to a language that provides a library that solves their
> problem.
Indeed. Software development is not a purely technical discipline:
combinations of issues such as the ability to reuse components, the
availability of such components, economics, project organisation, the
skills of participants, and so on, all start to weigh against the
benefits of being able to roll one's own elegant solutions over and
over again.
> The challenge for developers today is software architecture,
> robustness and scalability, not language purity or semantics. The Lisp,
> and to an extent Haskell, community will never ever ever grok this.
I'm not sure that you're correct about the Haskell community: there
appears to be a fair amount of relevant new work emerging from that
direction which may not only help Haskell developers to deal with the
harder problems of developing scalable and robust systems, but also
might affect the evolution of a number of other languages. However, I'd
agree that with the emergence of languages like Erlang, people want
solutions focused on particular systems engineering problems - it's all
very well arguably having the toolbox to create such solutions, but
most software developers just want to be handed the right tool.
> They'll continue to wonder why an "inferior" language like Python keeps
> getting popular. It will always escape them that it might be because
> Python is actually easier to use for most people to write "real world"
> applications. It has good usability.
And with regard to the remark about having access to libraries, it's
worth remembering that there's a lot of envy about things like CPAN -
an extensive collection of libraries for an even more "inferior"
language. When it is said that "CPAN is the language, Perl 6 is the
syntax", the remark should not be a surprise - it's a trend that was
observed at least twenty or thirty years ago, if not before.
Paul
mystilleef wrote:
> Advantages of Python:
>
> 1). More and better mature standard libraries (Languages don't matter,
> libraries do).
Right.
> 2). Multiple programming paradigms (including functional style
> programming see itertools, functools, operator modules (lambda, map,
> filter, reduce, sum etc builtins), higher order functions, list
> comprehension, blah, blah)
Either you meant this to go under "advantges of Lisp" or you know
nothing
about Lisp.
> 3). Better OO implementation. (I used to hate OO until I started using
> Python)
Better than what? Lisp's OO? Same comment as number 2.
> 4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
> said. Bindings for almost any lib worth using, at least on *nix)
Plays well with C - correct. But who does not? C++, really, you sure
about that?
Java and .NET? Sure. Separtely. How about some of the above at the same
time?
Oh, sorry, no advatage here...
Also, when you say "plays well" you mean the necessity to hand-craft a
C wrapper, compile and debug it *in C*? Or do you mean the easy and
"pythonish" way, the ctypes thing, that even IIRC was even included in
python 2.5 (I switched to Lisp before 2.5) which allows to create the
bindings without leaving the comfort of your host language? Yeah, the
praise for ctypes was well-earned, it was a very nice development,
great for python world. Now, that said, wanna make a wild guess how
exactly the foreign-function interfaces in Lisp have been working? ;)
> 5). Clearer syntax.
Sometimes. Sometimes not.
class aaa:
def mmm()
...
mmm=staticmethod(mmm)
> 6). Better namespace management. (nobody ever talks about this, but
> Python seems to be one of the few languages that gets symbol management
> right from a users perspective)
Maybe, yes. Subject for discussion.
> 7). Easier packaging and distribution system.
Oh which one do you mean? the <=2.4 style, which is a tar.gz with a
setup.py inside, and that setup.py knows how to compile the library?
Kina like ASDF in Lisp, only not handling dependencies, recompilation
etc? Or the new 2.5+ style, that can also download stuff from the
net... Kinda like ASDF-INSTALL? (I'm using version numbers here as time
designators, mybe the new system works with 2.4, I don't know)
> 8). Ubiquity! Python is everywhere. Lisp, bleh.
You're probably right. Still, are you able to name without doing a
research three-five platforms that support python, but don't support
Lisp? And how many of them are you using?
> 9). Relatively good docs (PHP has better).
"Relatively" is a keyword here.
> 10). Fewer perceived community assholes.
I thought so before (although it didn't bother me). But this thread
somewhat readjusted my perception of the amount of pythonistassholes.
> Large community.
Right.
> 11). Less fragmentation.
Not sure what you mean here. Are you referring to multiple Lisp
implementations? Do you think they differ much more that python vs.
jython?
> Advantages of Lisp:
>
> Learning a functional language can improve your programming range and
> depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
Right, you know nothing about Lisp.
> I think they are overrated, and in general cause more harm than good.
> It's the reason I find [...] programs difficult to grok, maintain
> and extend. Cos every smart ass wants to needlessly write his own mini
> language to the point of absolute obfuscation. Naturally, I'm supposed
> to be awed by his mischievous cleverness.
Substitute, for example, python metaclasses for [...]
You've got a point about the libraries though.
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
From my point of view as neither a Lisp nor Python user:
Lisp has some interesting features that separate it from many other
programming languages. In contrast, there is nothing interesting about the
Python language, AFAIK.
Lisp is fairly elegant in the way that it facilitates different programming
paradigms. Python is inelegant.
Lisp is likely to be faster.
Lisp is more mature but Python is (currently) more popular.
I think that people who know more languages and more about programming will
be much more inclined to use Lisp than Python. Look at the contents of the
newsgroups for example, c.l.l has a thread on memoization whereas c.l.p has
a thread about wrestling oiled pigs.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Mark Tarver wrote:
>
>>How do you compare Python to Lisp? What specific advantages do you
>>think that one has over the other?
>>
>>Note I'm not a Python person and I have no axes to grind here. This is
>>just a question for my general education.
>
>
> From my point of view as neither a Lisp nor Python user:
uh-oh. :)
> Look at the contents of the
> newsgroups for example, c.l.l has a thread on memoization whereas c.l.p has
> a thread about wrestling oiled pigs.
Woohoo! Can someone recommend a good book on Python?
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On Sat, 09 Dec 2006 10:50:51 +0000, Jon Harrop <···@ffconsultancy.com> tried to
confuse everyone with this message:
y) more popular.
>
>I think that people who know more languages and more about programming will
>be much more inclined to use Lisp than Python. Look at the contents of the
>newsgroups for example, c.l.l has a thread on memoization whereas c.l.p has
>a thread about wrestling oiled pigs.
>
Was that "wrestling oiled pigs" thread also started by gavino?
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
On Sat, 09 Dec 2006 10:50:51 +0000, Jon Harrop wrote:
> From my point of view as neither a Lisp nor Python user:
>
> Lisp has some interesting features that separate it from many other
> programming languages. In contrast, there is nothing interesting about the
> Python language, AFAIK.
You say that as if it were a bad thing. To quote Tim Peters:
"I've seen Python criticized as 'ugly' precisely because it doesn't have a
trick-based view of the world. In many ways, it's a dull language,
borrowing solid old concepts from many other languages & styles: boring
syntax, unsurprising semantics, few automatic coercions, etc etc. But
that's one of the things I like about it."
> I think that people who know more languages and more about programming will
> be much more inclined to use Lisp than Python. Look at the contents of the
> newsgroups for example, c.l.l has a thread on memoization whereas c.l.p has
> a thread about wrestling oiled pigs.
See, that's because writing Python is so much simpler that it doesn't take
an entire thread to discuss memoization, and we can get into more
interesting things like wrestling oiled pigs.
--
Steven.
Steven D'Aprano wrote:
> "I've seen Python criticized as 'ugly' precisely because it doesn't have a
> trick-based view of the world. In many ways, it's a dull language,
> borrowing solid old concepts from many other languages & styles: boring
> syntax, unsurprising semantics, few automatic coercions, etc etc. But
> that's one of the things I like about it."
Python seems to do a bad job of borrowing "solid old concepts" like
functional programming though.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
On Pungenday, The Aftermath 51, 3172 YOLD, Jon Harrop wrote:
> Lisp has some interesting features that separate it from many other
> programming languages. In contrast, there is nothing interesting about the
> Python language, AFAIK.
One word: yield. It's only thing I miss from Python when programming
Lisp.
With generators, I can think and write in terms of generating sequence
and not carry about state. I get transparent co-programs for free.
Yes, there is Arnesi CPS transformer-based emulation of generators,
but CPS transofmation gives inefficient code (function body is parsed
into set of structures and evaluated by hand) and has some major
caveats (no way of handling conditions within WITH-CALL/CC).
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { (3) With sufficient thrust, pigs fly just fine. However,
,|{-}|}| }\/ this is not necessarily a good idea.[...] }
\/ |____/ ( RFC 1925, Basic Truths of Networking ) -><-
Maciek Pasternacki wrote:
> One word: yield. It's only thing I miss from Python when programming
> Lisp.
I thought yield was a poor version of continuation passing style, which you
can do in Lisp (although it is difficult without a static type system).
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
On Boomtime, The Aftermath 60, 3172 YOLD, Jon Harrop wrote:
>> One word: yield. It's only thing I miss from Python when programming
>> Lisp.
>
> I thought yield was a poor version of continuation passing style, which you
> can do in Lisp (although it is difficult without a static type system).
It's not, chrome-wise. In Python, I can just yield values, without
needing to even know of continuations or state bookkeeping.
If CL had true continuations, it would be fairly easy with a bunch of
macros. But it hasn't any. It has Arnesi's CPS transformer, which
works, but, as I wrote in my earlier post, is has its caveats and is
*way* inefficient for non-trivial code (and if I need to wrap parts of
my code in functions or lambdas, what's the difference from manual
book-keeping?). And, it doesn't handle conditions. As far as I know,
condition system is main reason for CL not having continuations --
that was a conscious design tradeoff by ANSI commitee. Type system
has nothing to do with this (lack of it doesn't disturb Python to have
generators).
OTOH, Python exceptions also don't prevent Python from having
generators. And Python has more flexible duck typing (I can't just
create some data type that would be, e.g., iterable on standard CL
constructs, or even in add-on like ITERATE - I have to write custom
iterator, so my library's users can't easily interchange my data type
with any other). CL-Containers seems to address this problem, but I
didn't have any occasion to use it yet.
--
__ Maciek Pasternacki <·······@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...look into my eyes and it's easy to see:
,|{-}|}| }\/ one and one make two, two and one make three,
\/ |____/ it was destiny... } ( Tenacious D ) -><-
Maciek Pasternacki <·······@japhy.fnord.org> wrote:
+---------------
| Jon Harrop wrote:
| > Lisp has some interesting features that separate it from many other
| > programming languages. In contrast, there is nothing interesting about the
| > Python language, AFAIK.
|
| One word: yield. It's only thing I miss from Python when programming
| Lisp.
|
| With generators, I can think and write in terms of generating sequence
| and not carry about state. I get transparent co-programs for free.
| Yes, there is Arnesi CPS transformer-based emulation of generators,
| but CPS transofmation gives inefficient code (function body is parsed
| into set of structures and evaluated by hand) and has some major
| caveats (no way of handling conditions within WITH-CALL/CC).
+---------------
A fully-general CALL/CC is not necessary. In any Common Lisp
implementations with threads (and it doesn't really matter whether
it's OS threads or "green" threads [coroutines] as in CMUCL),
you can implement "proper" generators with a natural YIELD function
fairly easily. E.g., look at the MP:PROCESS-YIELD function in
implementations with CLIM-like threads.
And you can handle conditions within your generator threads however
you like...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Tue, 19 Dec 2006 03:35:35 +0100, Rob Warnock <····@rpw3.org> wrote:
>
> A fully-general CALL/CC is not necessary. In any Common Lisp
> implementations with threads (and it doesn't really matter whether
> it's OS threads or "green" threads [coroutines] as in CMUCL),
> you can implement "proper" generators with a natural YIELD function
> fairly easily. E.g., look at the MP:PROCESS-YIELD function in
> implementations with CLIM-like threads.
>
> And you can handle conditions within your generator threads however
> you like...
>
>
What I wonder is "why didn't it make it to the standard like in Scheme?"
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Tue, 19 Dec 2006 03:35:35 +0100, Rob Warnock <····@rpw3.org> wrote:
>
>>
>> A fully-general CALL/CC is not necessary. In any Common Lisp
>> implementations with threads (and it doesn't really matter whether
>> it's OS threads or "green" threads [coroutines] as in CMUCL),
>> you can implement "proper" generators with a natural YIELD function
>> fairly easily. E.g., look at the MP:PROCESS-YIELD function in
>> implementations with CLIM-like threads.
>>
>> And you can handle conditions within your generator threads however
>> you like...
>>
>
> What I wonder is "why didn't it make it to the standard like in Scheme?"
IIUC, call/cc did not make it into Common Lisp because it was considered
a too low-level feature. Call/cc is a reflective feature that gives you
access to the state of the call stack, and allows you to "reinstall" a
saved call stack. This is not necessarily well supported by the
underlying hardware architecture, and also has problematic side effects
in that different implementations of the same algorithms that are
otherwise indistinguishable may become distinguishable. See
http://lists.r6rs.org/pipermail/r6rs-discuss/2006-September/000186.html
for example.
There are also other possible designs for reflecting on the call stack.
I think the Smalltalk design to represent it as a chain of objects
representing the stack frames would be more interesting.
Multithreading is probably not in ANSI CL because there are many
different possible designs, and it's not clear what the "right" one
would be.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
+ Pascal Costanza <··@p-cos.net>:
| Multithreading is probably not in ANSI CL because there are many
| different possible designs, and it's not clear what the "right" one
| would be.
And (perhaps more to the point) if it isn't clear today, it most
definitely wasn't any clearer when the standard was being worked on.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
>
> Mark
They are both a lot of fun.
Python is a clean, focused language that never was designed to replace
every programming language out there or solve all of the world's
problems.
Lisp is an entire world in itself.
Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
>
> Mark
NOBODY expects the Lispers Inquisition!
Our chief weapon is age... age and macros...
...macros and age.
Our two weapons are age and macros....
And mathematical rigour...
Our THREE weapons are age, macros, and mathematical rigour...
...And an almost fanatical belief in Lisps superiority.
Our *four* ...no.
AMONGST our weapons...
Amongst our weaponry...
...Are such elements as fear, surprise.... I'll come in again.
Python is fun to use.
Easy to read.
Simple and powerful.
Easy to test.
Easy to maintain.
Fast. Very fast!
- Paddy.
.
"Paddy" <·········@netscape.net> writes:
> Fast. Very fast!
You hit it on the head. Interpreted langauges were the efficiency
breakthrough we've all been waiting for.
Paddy wrote:
> Python is fun to use.
> Easy to read.
> Simple and powerful.
> Easy to test.
> Easy to maintain.
> Fast. Very fast!
Okay, I'm going to commit another rhetorical fallacy here called
"Argument from Authority": I challenge anyone making psychological
claims about language X (for any X) being easier to either
read/learn/use than language Y (for any Y) to come up with any valid
evidence whatever. Having a PhD in Cognitive Psychology (as well as two
degrees in computer science) where my subject was how people learn to
program (among other things), and having extensive experience in this
field, I am almost certain that no such evidence exists (at least not
for any real programming language). Now, like any good scientist, I
could be wrong, but you'd have to convince me, and I very much doubt
that you could.
While I'm engaging in this particular fallacy, here's another instance:
Since I'm probably (although I'm not certain) the only person in this
thread who has made a significant amount of money on either of these
languages (i.e., via the sale of a startup whose product was tens of
thousands of lines of Lisp code, and some Tk GUI stuff), and knowing
both Lisp and Python (although I'm certainly not a Python wizard), I am
nearly certain that what we did in Lisp COULD NOT HAVE BEEN DONE IN
PYTHON -- PERIOD. The reason has little to do with macros (although
they were very helpful, of course, esp. in making Tcl look like a
reasonable language so that we could use Tk); it has to do with speed,
which has to do with compilers, which, as it turns out, has to do with
macros. (See below.)
Now, speaking as a scientist, permit me to make a small practical
suggestion: Why not just figure out a way to simplify some brand of
Python -- make parens (or whatever) optionally replace whitespace and
line breaks as syntax -- and then add a simple macro facility -- macros
are actually a very simple extension if you have homogenous syntax,
homogenizing your syntax to the point where macros are possible is the
hard part -- and just see what happens. One of two general things are
likely to happen: Either people will not use them, and they will
languish and die, and then at least you can say; "Been there, done
that" to the Lisp community. Or, more likely, the some subset of the
Python community will get it, and will figure out how useful they are,
although it might take some time. And then you might find yourself with
a wonderful new tool. You might even get a compiler out of the deal, at
a pretty low cost, too! If you get macros, and get a compiler, I'm
pretty sure that you will have no problem winning over the Lisp
community, who would LOVE to have your extensive libraries, and that
you will probably be able to maintain and improve your flagging
position wrt Ruby (which, according to Matz, is more-or-less just Lisp
w/o macros.)
I'm not saying that this is going to be an easy or quick experiment,
but it's one that I, and I think most Lispers, would both like to see
happen, and would benefit from! Moreover, I dare say that some of us in
the Lisp community would love to HELP -- at least I would, and I'm
guessing that others would as well.
(Unless you guys get a compiler too, you'll always just be a
scripting language, but compilers are GREATLY facilitated by having a
macro facility because (at first blush) all you need to do is to
macro-expand down to something you know how to turn into code. This
isn't the only, nor perhaps the best way to get a compiler, but it's
a step in that direction. Later on you can learn the other great
features offered by homogeneous syntax, like being able to write code
walkers, which help improve over the "first blush" compiler. Soon
enough, I predict, you'll be so far past us and Ruby that...well,
even Kenny with jump on board! :-)
········@gmail.com skrev:
>
> The reason has little to do with macros (although
> they were very helpful, of course, esp. in making Tcl look like a
> reasonable language so that we could use Tk)
How long ago was this? ;-)
[Macros in Python]
> Either people will not use them, and they will languish and die, and then
> at least you can say; "Been there, done that" to the Lisp community.
Well, someone did write Logix probably with the intention of getting
interest from the community:
http://livelogix.net/logix/
It's already been noted what the response has been.
> Or, more likely, the some subset of the Python community will get it,
> and will figure out how useful they are, although it might take some time.
I've been interested in macros for Python, and you'll find other people
with similar views:
http://www.fiber-space.de/EasyExtend/doc/EE.html
That said, you'll find the discussion about macros to be quite open,
occasionally even on the Python development lists. But it is also
important to note that the development and usage of Python is not
guided from purely technical motivations (or from technically pure
motivations), and the heated discussion about natural language
analogies reveals that just as people are content to form communities
around certain kinds of literature, so are people interested in forming
communities around developing certain kinds of systems.
[...]
> you will probably be able to maintain and improve your flagging
> position wrt Ruby (which, according to Matz, is more-or-less just Lisp
> w/o macros.)
I think this would be a fairly weak argument for what would otherwise
be a reasonable suggestion. "Come over to my way of thinking or be
destroyed" sounds like something the Emperor would say to Luke
Skywalker. And we all know how that ended. ;-)
And on the subject of remarks about Python developers somehow being
remote controlled by the BDFL, I think that anyone who takes a closer
look will see varying levels of dissent and dissatisfaction, just as
you'd find in any community. Again, many more issues must be considered
to understand why people keep using Python (or alternatively stop using
it).
Paul
········@gmail.com wrote:
> Paddy wrote:
> > Python is fun to use.
> > Easy to read.
> > Simple and powerful.
> > Easy to test.
> > Easy to maintain.
> > Fast. Very fast!
>
> Okay, I'm going to commit another rhetorical fallacy here called
> "Argument from Authority": I challenge anyone making psychological
> claims about language X (for any X) being easier to either
> read/learn/use than language Y (for any Y) to come up with any valid
> evidence whatever. Having a PhD in Cognitive Psychology (as well as two
> degrees in computer science) where my subject was how people learn to
> program (among other things), and having extensive experience in this
> field, I am almost certain that no such evidence exists (at least not
> for any real programming language). Now, like any good scientist, I
> could be wrong, but you'd have to convince me, and I very much doubt
> that you could.
Whilst you wait for 'evidence' proving that, for any languages X and Y,
for
example, befunge is easier to grasp than Logo; people who have tried
Python and found it easier to learn than other languages can switch to
Python, (welcome, by the way); and just get things done.
,
>
> While I'm engaging in this particular fallacy, here's another instance:
> Since I'm probably (although I'm not certain) the only person in this
> thread who has made a significant amount of money on either of these
> languages (i.e., via the sale of a startup whose product was tens of
> thousands of lines of Lisp code, and some Tk GUI stuff), and knowing
> both Lisp and Python (although I'm certainly not a Python wizard), I am
> nearly certain that what we did in Lisp COULD NOT HAVE BEEN DONE IN
> PYTHON -- PERIOD. The reason has little to do with macros (although
> they were very helpful, of course, esp. in making Tcl look like a
> reasonable language so that we could use Tk); it has to do with speed,
> which has to do with compilers, which, as it turns out, has to do with
> macros. (See below.)
Maybe for your application, but others think that speed is more to do
with algorithm. Python has to rely more on using the right algorithm
but
it makes algorithm exploration easier than some languages, embedding
good algorithms for things like sort, and allowing the wrapping of
libraries optimised in other languages.
>
> Now, speaking as a scientist, permit me to make a small practical
> suggestion:
Speaking as an engineer please allow me to make the large practical
suggestions ;-)
> Python -- make parens (or whatever) optionally replace whitespace and
> line breaks as syntax -- and then add a simple macro facility -- macros
> are actually a very simple extension if you have homogenous syntax,
> homogenizing your syntax to the point where macros are possible is the
> hard part -- and just see what happens. One of two general things are
> likely to happen: Either people will not use them, and they will
> languish and die, and then at least you can say; "Been there, done
> that" to the Lisp community. Or, more likely, the some subset of the
> Python community will get it, and will figure out how useful they are,
> although it might take some time. And then you might find yourself with
> a wonderful new tool. You might even get a compiler out of the deal, at
> a pretty low cost, too! If you get macros, and get a compiler, I'm
> pretty sure that you will have no problem winning over the Lisp
> community, who would LOVE to have your extensive libraries, and that
> you will probably be able to maintain and improve your flagging
> position wrt Ruby (which, according to Matz, is more-or-less just Lisp
> w/o macros.)
>
> I'm not saying that this is going to be an easy or quick experiment,
> but it's one that I, and I think most Lispers, would both like to see
> happen, and would benefit from! Moreover, I dare say that some of us in
> the Lisp community would love to HELP -- at least I would, and I'm
> guessing that others would as well.
Talk to these guys:
http://en.wikipedia.org/wiki/PyPy they have an interesting take on
Pythons
interpreter, and their work is being used as part of a Python->C++
flow..
>
> (Unless you guys get a compiler too, you'll always just be a
> scripting language,
Guess what. Scripting Language is not a pejorative term. If you mean
that
python can only be used for 'glue code' then, you'r right, you don't
know
enough about Python.
> but compilers are GREATLY facilitated by having a
> macro facility because (at first blush) all you need to do is to
> macro-expand down to something you know how to turn into code. This
> isn't the only, nor perhaps the best way to get a compiler, but it's
> a step in that direction. Later on you can learn the other great
> features offered by homogeneous syntax, like being able to write code
> walkers, which help improve over the "first blush" compiler. Soon
> enough, I predict, you'll be so far past us and Ruby that...well,
> even Kenny with jump on board! :-)
Code walkers? Do you mean reflection?
Python has this unsung module called doctest that neatly shows some of
the strengths of python:
http://en.wikipedia.org/wiki/Doctest
- Paddy.
> Python has to rely more on using the right algorithm...
This sound familiar: "Macros are dangerous!" "Compilers make you lazy."
"Worse is better!" (I have a Russian friend -- a mathematician -- who
jokes that the reason the Soviets were great mathematicians because
their computers sucked, so they had to use extensive formal
manipulation to get things to run fast enough to get anything done. He
was joking (I think); you don't appear to be.)
> Talk to these guys:
> http://en.wikipedia.org/wiki/PyPy they have an interesting take on
No, actually maybe you should talk to them since you seem to think that
making Python run fast is dangerous, or at least unnecessary.
> Python has this unsung module called doctest that neatly shows some of
> the strengths of python: http://en.wikipedia.org/wiki/Doctest
Now I'm *certain* that you're just pulling my leg: You guys document
all your random ten-line hacks in Wikipedia?!?! What a brilliant idea!
Hey, you even have dead vaporware projects like uuu documented in
Wikipedia! Cool! (Actually, I don't know that doctest is ten lines in
Python, but it'd be about ten lines of Lisp, if that, so I'm just
guessing here.)
········@gmail.com wrote:
> > Talk to these guys:
> > http://en.wikipedia.org/wiki/PyPy they have an interesting take on
>
> No, actually maybe you should talk to them since you seem to think that
> making Python run fast is dangerous, or at least unnecessary.
>
I find it amusing that most of the arguments that python-people are
making in this thread are actually the arguments that C++ and Java make
against Python. "Who needs dynamic typing?", "Who needs closures?",
"The idea of using whitespace for syntax is beyond stupid"... Now the
python guys obviouly see that that those arguments are bogus, but they
keep the same reasoning against lisp.
I switched to learning Lisp after Python and knowing Python helped me
greatly. And not only the fact that many features were already familiar
from Python (I've already known Smalltalk, Prolog and Mozart-Oz for
example, as the more weird ones, besides of course the whole array of
standard ones like FORTRAN, Pascal, C, Modula-2,C++, etc), but mostly
it was the fact that even if something looks weird and
unreadable/useless/dangerous/whatever at first sight, it might turn out
different when you get used to it. For example I started to learn
Python three times. The first two - I've read about whitespace syntax,
exclaimed "how stupid some people are" and threw the book away. The
third time I've managed to pass that barrier and found the experience
rewarding. And that was the *real* knowledge - when faced with Lisp's
parentheses I would've probably have the same reaction, but I've
remembered my experience with Python and decided to give it a try. So,
thanks to Python for making me more open to unconventional concepts and
guiding me to learning Lisp!
I still find Python a nice language and have warm feelings towards it,
although I don't think that given a choce I'd ever pick it over Lisp.
······@gmail.com schrieb:
> I find it amusing that most of the arguments that python-people are
> making in this thread are actually the arguments that C++ and Java make
> against Python. "Who needs dynamic typing?", "Who needs closures?",
> "The idea of using whitespace for syntax is beyond stupid"... Now the
> python guys obviouly see that that those arguments are bogus, but they
> keep the same reasoning against lisp.
Yes, this structure of argument is the same in *any* discussion about
language design and feature integration. The solution could be laissez
faire but then you have to counteract creating standards for a minimal
contract social. In either way you cut down language feature diversity
and feature implementation redundancy, something macros strongly
encourage. So Lisp is always the right language to start with but what
is the right language to end with? The answer is BASIC and although the
reference to the historical BASIC language is not accidental, I
actually mean all kind of general purpose languages that aim to
facilitate programming in the first place. That's why Python = BASIC or
more accurately Python = ABC. Of course you can start with BASIC too,
instead of Lisp, or Ruby and quote Yukihiro Matsumoto who just wants
happy users - from the very beginning and not just after one month,
when one starts looking through the jungle of parens ( Ken Tilton ) or
perform any other cognitive transformation to ease the pain.
While Pythonistas might defend their language with all kind of typical
nerdish idiocy, Lispers try to convince Pythonistas to be unhappy,
because they lack X, Y and Z and recommend Lisp as the cure. But just
like a beautifull woman, Pythonistas stay unimpressed and do respond:
no, I don't lack anything, I am complete; stay away from me with your
weirdness!
········@gmail.com wrote:
> > Python has to rely more on using the right algorithm...
>
> This sound familiar: "Macros are dangerous!"
Yes. I changed my opinion on advocating Python having macros in one
of our long threads on the subject. Maintainance counts.
> "Compilers make you lazy."
This is new to me. In fact, for the compiled languages available to me.
Using them *first* would be the difficult choice.
> "Worse is better!"
Yep, I think I read that one. To (over), summarise what I read: the
author
states that waiting for perfect will often give the advantage to a
competitor who ships with 'good enough'. The author gives examples.
The skill to me resides in knowing what is good enough ;-)
> (I have a Russian friend -- a mathematician -- who
> jokes that the reason the Soviets were great mathematicians because
> their computers sucked, so they had to use extensive formal
> manipulation to get things to run fast enough to get anything done. He
> was joking (I think); you don't appear to be.)
I can't vouch for your Russian friend, but yes I do think that the
gumph on
exponential time algorithms versus linear time algorithms makes sense.
I started using my first scripting language AWK whilst using C and went
through only using it for small tasks to using it for more and more
because it was fast enough. In my case I'd be finishing some task in
a much shoter time giving my customers solutions that might take 10
minutes to run instead of ten seconds, but they were using it in a flow
that took maybe overnight to run.
Unlike Lisp, Python does not have a ubiquitous compiler. It is
therefore
made to interface nicely with compiled languages. Other compiled
language users see the need for dynamic interpreted languages like
Python and maintain links Python such as the Boost Python C++
wrapper. IronPython for .NET, Jython for Java.
Lisp is its own interpreter and compiler, which should be a great
advantage, but only if you don't make the mistake of ignoring the
wealth of code out there that is written in other languages.
>
> > Talk to these guys:
> > http://en.wikipedia.org/wiki/PyPy they have an interesting take on
>
> No, actually maybe you should talk to them since you seem to think that
> making Python run fast is dangerous, or at least unnecessary.
>
> > Python has this unsung module called doctest that neatly shows some of
> > the strengths of python: http://en.wikipedia.org/wiki/Doctest
>
> Now I'm *certain* that you're just pulling my leg: You guys document
> all your random ten-line hacks in Wikipedia?!?! What a brilliant idea!
Python is newbie-friendly. Part of that is being accessible.
Doctest is about a novel way of using a feature shared by Lisp, that is
docstrings. Testing is important, usually not done enough, and doctests
are a way to get people to write more tests by making it easier. Does
Lisp have similar?
> Hey, you even have dead vaporware projects like uuu documented in
> Wikipedia! Cool! (Actually, I don't know that doctest is ten lines in
> Python, but it'd be about ten lines of Lisp, if that, so I'm just
> guessing here.)
Does Lisp have a doctest-like module as part of its standard
distribution?
Or are you saying that If you ever needed it, then it would be trivial
to
implement in Lisp, and you would 'roll your own'? There are advantages
to
doctest being one of Pythons standard modules.
- Paddy.
Paddy wrote:
> Does Lisp have a doctest-like module as part of its standard
> distribution?
No, and it never will.
The wording you are using betrays cluelessness. Lisp is an ANSI
standard language. Its distribution is a stack of paper.
There isn't a ``standard distribution'' of Lisp any more than there is
such a thing of C++.
> There are advantages to
> doctest being one of Pythons standard modules.
There are also advantages in being able to tell idiots who have
terrible language extension ideas that they can simply roll their own
crap---and kindly keep it from spreading.
This is generally what happens in intelligent, mature programming
language communities. For instance, whenever someone comes along who
thinks he has a great idea for the C programming language, the standar
answer is: Wonderful! Implement the feature into a major compiler like
GCC, to show that it's feasible. Gain some experience with it in some
community of users, work out any wrinkles, and then come back.
In the Lisp community, we can do one better than that by saying: Your
feature can be easily implemented in Lisp and loaded by whoever wants
to use it. So, i.e. don't bother.
Lisp disarms the nutjobs who want to inflict harm on the world by
fancying themselves as programming language designers. They are reduced
to the same humble level as other software developers, because the best
they can do is write something which is just optionally loaded like any
other module, and easily altered beyond their original design or
rejected entirely. Those who are not happy with the lack of worship run
off an invent shitty little languages for hordes of newbies, being
careful that in the designs of those languages, they don't introduce
anything from Lisp which would land them in the same predicament from
which they escaped.
"Paddy" <·········@netscape.net> writes:
> ········@gmail.com wrote:
>
>> > Python has to rely more on using the right algorithm...
>>
>> This sound familiar: "Macros are dangerous!"
> Yes. I changed my opinion on advocating Python having macros in one
> of our long threads on the subject. Maintainance counts.
Yes, it does, but that should take you to exactly the opposite
conclusion.
>> "Compilers make you lazy."
> This is new to me. In fact, for the compiled languages available to me.
> Using them *first* would be the difficult choice.
These are not real sentences, but if you're saying that compiled
languages make programming more difficult, then you're simply using
the wrong compiled languages. Lisp is a dynamic language that also
supports compilation to native code.
> Unlike Lisp, Python does not have a ubiquitous compiler. It is
> therefore
> made to interface nicely with compiled languages. Other compiled
What on earth does this mean? You're saying that because Python
doesn't have a compiler, it can interface more easily to compiled
languages? That's nonsense.
Further, most Lisp implementations support an interface to C that
doesn't require you to write and compile C code in order to use C
extensions in Lisp. Can Python do the same more "nicely" than Lisp?
> language users see the need for dynamic interpreted languages like
> Python and maintain links Python such as the Boost Python C++
> wrapper. IronPython for .NET, Jython for Java.
> Lisp is its own interpreter and compiler, which should be a great
> advantage, but only if you don't make the mistake of ignoring the
> wealth of code out there that is written in other languages.
Um.
> > > Python has this unsung module called doctest that neatly shows some of
> > > the strengths of python: http://en.wikipedia.org/wiki/Doctest
> > Now I'm *certain* that you're just pulling my leg: You guys document
> > all your random ten-line hacks in Wikipedia?!?! What a brilliant idea!
> Python is newbie-friendly. Part of that is being accessible.
> Doctest is about a novel way of using a feature shared by Lisp, that is
> docstrings. Testing is important, usually not done enough, and doctests
> are a way to get people to write more tests by making it easier. Does
> Lisp have similar?
Seems like a trivial commonality between the languages, and a trivial
library, but that's not at all what I was laughing at...
> > Hey, you even have dead vaporware projects like uuu documented in
> > Wikipedia! Cool! (Actually, I don't know that doctest is ten lines in
> > Python, but it'd be about ten lines of Lisp, if that, so I'm just
> > guessing here.)
> Does Lisp have a doctest-like module as part of its standard
> distribution? Or are you saying that If you ever needed it, then it would be
> trivial to implement in Lisp, and you would 'roll your own'? There are
> advantages to doctest being one of Pythons standard modules.
Actually, I don't care what you put into your library -- to some exent,
the more the merrier (as I've said elsewhere, I wish we had your
community of busy ... um ... beavers :-) to create libraries full of
stuff, trivial or not!) The wheat will rise from the chaff. (Some
Lispers might disagree with me here.)
But anyway, what I was laughing at had nothing to do with doctest --
but that you use wikipedia to document your libraries. Elsewhere I have
aregued that Wikipedia is a stupid marketing document -- *many* Lispers
disagree with me here, so let's no go down this road, please as it's
soooooooo OT! So, I'm mostly laughing at the laughability of the
concept of the Wikipedia as somehow a source of all wisdom, not doctest
per se. Random ten-line Python libraries (as well as dead vaporware
python projects, as well as a whole bunch of other useless crap, and
the very occassionally useful crap) being in Wikiperdia just makes me
smile, that's all.
········@gmail.com wrote:
> > > > Python has this unsung module called doctest that neatly shows some of
> > > > the strengths of python: http://en.wikipedia.org/wiki/Doctest
>
> > > Now I'm *certain* that you're just pulling my leg: You guys document
> > > all your random ten-line hacks in Wikipedia?!?! What a brilliant idea!
>
> > Python is newbie-friendly. Part of that is being accessible.
> > Doctest is about a novel way of using a feature shared by Lisp, that is
> > docstrings. Testing is important, usually not done enough, and doctests
> > are a way to get people to write more tests by making it easier. Does
> > Lisp have similar?
>
> Seems like a trivial commonality between the languages, and a trivial
> library, but that's not at all what I was laughing at...
Yep, doctest is trivial to use. Its part of its power ;-)
>
> > > Hey, you even have dead vaporware projects like uuu documented in
> > > Wikipedia! Cool! (Actually, I don't know that doctest is ten lines in
> > > Python, but it'd be about ten lines of Lisp, if that, so I'm just
> > > guessing here.)
>
> > Does Lisp have a doctest-like module as part of its standard
> > distribution? Or are you saying that If you ever needed it, then it would be
> > trivial to implement in Lisp, and you would 'roll your own'? There are
> > advantages to doctest being one of Pythons standard modules.
>
> Actually, I don't care what you put into your library -- to some exent,
> the more the merrier (as I've said elsewhere, I wish we had your
> community of busy ... um ... beavers :-) to create libraries full of
> stuff, trivial or not!) The wheat will rise from the chaff. (Some
> Lispers might disagree with me here.)
Its not so much the library creation. You also need the organisation,
and the willingness to accept that others can write good code too, (in
whatever language), and hold off from that first impulse to
roll-your-own library.
>
> But anyway, what I was laughing at had nothing to do with doctest --
> but that you use wikipedia to document your libraries. Elsewhere I have
> aregued that Wikipedia is a stupid marketing document -- *many* Lispers
> disagree with me here, so let's no go down this road, please as it's
> soooooooo OT! So, I'm mostly laughing at the laughability of the
> concept of the Wikipedia as somehow a source of all wisdom, not doctest
> per se. Random ten-line Python libraries (as well as dead vaporware
> python projects, as well as a whole bunch of other useless crap, and
> the very occassionally useful crap) being in Wikiperdia just makes me
> smile, that's all.
Oh, you don't like Wikipedia.
There are a lot of people that use Wikipedia. I think some of them
might want to learn to program. I make it easier for them to find
Python by helping to maintain Python within Wikipedia.
If I am researching anything then I like to cross check with
information from multiple sites. that's just good practice.
Some people dislike Wikipedia which is fine. Some people dislike
Wikipedia and deliberately sabotage it, which is vandalism.
-Paddy.
On 12 Dec 2006 18:03:49 -0800, "Paddy" <·········@netscape.net> tried to confuse
everyone with this message:
>There are a lot of people that use Wikipedia. I think some of them
>might want to learn to program.
I think you misunderstood the goal of Wikipedia. It is not to teach people
programming.
>I make it easier for them to find
>Python by helping to maintain Python within Wikipedia.
If someone wants to find Python, he types "Python" in the search bar and works
from there. He certainly wouldn't end up in "doctest" article.
>Some people dislike Wikipedia which is fine. Some people dislike
>Wikipedia and deliberately sabotage it, which is vandalism.
Writing vanity articles about non-notable things is not much better.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
On Wed, 13 Dec 2006 09:39:44 +0100, Timofei Shatrov <····@mail.ru> wrote:
> On 12 Dec 2006 18:03:49 -0800, "Paddy" <·········@netscape.net> tried to
> confuse
> everyone with this message:
>
>> There are a lot of people that use Wikipedia. I think some of them
>> might want to learn to program.
>
> I think you misunderstood the goal of Wikipedia. It is not to teach
> people
> programming.
>
>> I make it easier for them to find
>> Python by helping to maintain Python within Wikipedia.
>
> If someone wants to find Python, he types "Python" in the search bar and
> works
> from there. He certainly wouldn't end up in "doctest" article.
>
>> Some people dislike Wikipedia which is fine. Some people dislike
>> Wikipedia and deliberately sabotage it, which is vandalism.
>
> Writing vanity articles about non-notable things is not much better.
>
You are being silly. Wikipedia has for instance the best coverage of math
of any encyclopedia (if you can call it that). This is how I came in touch
with it. If you want trivia you get trivia. If you want Phd. level math it
has that as well. It is as diverse as the people that use it.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Paddy wrote:
> http://en.wikipedia.org/wiki/Doctest
I pity the hoplelessly anti-intellectual douche-bag who inflicted this
undergraduate misfeature upon the programming language.
This must be some unofficial patch that still has a hope of being shot
down in flames, right?
Kaz Kylheku wrote:
> Paddy wrote:
> > http://en.wikipedia.org/wiki/Doctest
>
> I pity the hoplelessly anti-intellectual douche-bag who inflicted this
> undergraduate misfeature upon the programming language.
>
> This must be some unofficial patch that still has a hope of being shot
> down in flames, right?
Sour grapes. Eh :-)
Or were you going to follow up with some intellectual argument to
support your adjectives?
1. pity
2. hopelessly
3. anti-intellectual
4. douche-bag
5. inflicted
6. undergraduate
7. misfeature
8. unofficial patch
9. shot down in flames
That's a lot of hate in 2 sentences for judging a novel feature you
barely came across.
On 11 Dec 2006 00:27:28 -0800, "Ravi Teja" <···········@gmail.com> tried to
confuse everyone with this message:
>
>That's a lot of hate in 2 sentences for judging a novel feature you
>barely came across.
>
But, you have to admit that it looks horrible (at least at the first glance). If
there's some programming style that I absolutely can't stand, it would be the
one where programmer writes a huge block of commentary describing what a
function does, followed by one-liner of code, which contains the same amount of
information in itself. With doctest it is even worse, because examples also
contain superfluous information. Everyone can just copy-paste the code in REPL
and see what happens when you execute it. Besides that, there are many reasons
why tests should be stored in a separate file, or at least not in the same
function that they are testing.
Also Wikipedia article contains some "Cons of doctest" that look pretty nasty:
* Large numbers of tests in a docstring can become unwieldy. docstrings
should be pruned and excised tests put in external file(s).
* Tests producing large amounts of output make for large docstrings.
* Debugging integration is far from perfect
* 'print' (or 'trace') debugging is not possible (because it intervenes with
the test result)
* Test setup has to be either copied or hidden away from the test, making
the overall environment harder to understand.
* Many of the complex assertions of existing unit tests frameworks do not
exist, (e.g. assertRaises, assertEquals, assertAlmostEqual, ...), although some
are not necessary.
* Failing assertions are very hard to debug (Especially in Web applications
if the expected result is a web page with a lot of HTML)
It's not surprising that no one uses this stuff for serious work.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Timofei Shatrov wrote:
> It's not surprising that no one uses this stuff for serious work.
Well, I replaced all my unittests with doctests long ago, and I am not
the only one following this way
(see the Zope 3 project for instance).
Michele Simionato
Timofei Shatrov wrote:
> But, you have to admit that it looks horrible (at least at the first glance). If
> there's some programming style that I absolutely can't stand, it would be the
> one where programmer writes a huge block of commentary describing what a
> function does, followed by one-liner of code
You Sir, are no fan of Literate Programming :-).
> information in itself. With doctest it is even worse, because examples also
> contain superfluous information. Everyone can just copy-paste the code in REPL
> and see what happens when you execute it.
And doctest automates such REPL tests. Like macros, don't knock it till
you try it.
> Besides that, there are many reasons
> why tests should be stored in a separate file, or at least not in the same
> function that they are testing.
You need not have doctest as a part of source code. You can also create
a separate documentation file that contains prose as well as tests
intervening.
http://www.python.org/doc/lib/doctest-simple-testfile.html
Combine it with ReStructured Text and you have a wonderful
documentation and testing solution in one place. Personally, I like
this a lot better than Javadoc style documentation where usage examples
are often absent.
> Also Wikipedia article contains some "Cons of doctest" that look pretty nasty:
Of course, doctest is hardly the ultimate testing solution. But it does
an admirable job for many cases where you don't need to setup elaborate
tests.
> It's not surprising that no one uses this stuff for serious work.
I have seen enough libraries that use doctest. Zope, Twisted and Paste
are some of the popular Python projects in that use it. Epydoc supports
it as well.
Maybe this was already mentioned in this thread and I didn't see it.
Anyway, I find that Scheme (so I am talking about Scheme as a member of
the "lisp family") has pedagogical advantages over Python.
1. There are a range of excellent books that will introduce not just
Scheme but programming and computer science to audiences with varied
background and previous programming experience.
1.1. I do not know of any Python equivalents to "The Little Schemer"
and "The Seasoned Schemer". These teach you recursion and "the art of
scheme programming". I think "Core Python Programming" (and, to a
lesser extent, "Learning Python") might teach some of "the art of
python programming", but the focus, style, and effectivenes are quite
different (and, I'd say, not as successful; you can read the little
schemer in a couple of long train commutes; there is no way you can do
that with Core Python Programming.). Sure, the style of "The little
Schemer" is not for everyone.
1.2. "How to design programs" is obviously a much broader,
comprehensive, detailed, and far-reaching textbook than (the nice) "How
to think like a computer scientist; learning with Python".
1.3. SICP has no counterpart in the Python world. I've read some people
have taught SICP like using Python (and that there is a new course at
MIT, taught by Abelson and/or Sussman, that will use Python, not
Scheme; but this is not a course that really substitutes the original
for which SICP was written). But SICP remains SICP. It'd be nice to see
something similar in Python.
1.4. More advanced material is available as "Programming Languages:
Application and Interpretation" (Krishnamurthi). I know of no Python
counterpart in the range and depth of topics covered.
1.5. Last, but not least, lots of this material is available on-line.
So you can check it out before buying the dead-tree version.
2. PLT scheme and Dr. Scheme are a wonderful learning environment for
Scheme, with no equivalent in Python. Its not just the great debugging
and tracing facilities, but also who you can restrict the language you
use to concentrate on some key features, so as to build incrementally
(to avoid the forest from preventing you to see some specific trees).
Interestingly, I think there has been at least one attempt to build
something similar for Python on top of Dr. Scheme (in PyCon 2004 or
2005?).
3. Schemers (some Schemers at least) are making a strong effort to
teach CS to audiences of varied backgrounds and experiences. They even
have a sequence that starts from basically 0, teaches you Scheme, and
ends up including Java (I guess this is catering to the "but I really
need Java to get a job when I get out of here!"). That Scheme is way
ahead of Python in this area I think has been recognized by relevant
members of the Python community (comp.lnag.python not long ago).
4. Python, instead, has the wealth of "nutshells", "pocket guides",
etc. Which are fine (I always have my Ptyhon in a Nuthsell and Python
Pocket Reference nearby when writing Python). But I doubt these books
really teach you basic computer science as the above do. They are of
the applied kind (and here probably the only Lisp coutnerpart might be
"Practical Common Lisp").
Why does all this matters (or at least matters to me, who am
considering moving most of my programming from Python to Scheme and
CL)?
a) If the issue of teaching programming to a kid/adolescent arises, I'd
definitely have a lot more resources, which also teach much more than
just a language, if I choose Scheme. (And, no, I do not think a
parenthesis is inherently more scary than a tab for someone who is new
to both).
b) I have no formal CS training; I am a biologist and statistician by
training and have used Basic, C/C++, Pascal, Fortran, R (oh, and RPL,
that minor language of the HP48 calc., which I used extensively for 18
months for writing lots of animal behavior recording programs). But
once and for all, I'd like to learn some basic CS, while learning how
to use a language. I have a strong feeling that, with the Scheme route,
this will be fulfilled. Not with Python. (Sure, this is also fulfilled
with Mozart/Oz and "Concepts and Techniques and Models of Comp.
Progr.", but Mozart/Oz does not seem as ready for the types of projects
I work on and there are speed issues). The first three chapters of SICP
and the first four chapters of CTM so far have really been
mind-expanding. None of the Python books I've read have felt anyway
similar (Python has felt cozy, nice, easy to use; not eye opening).
c) Now, if Scheme/CL were just "toy languages" we could dismiss all the
above by saying "we are not talking about why kids learn XYZ, nor why
CS ignorants like you prefer to be spoon fed basic CS concepts by
learning language UVW". But of course, I think that neither Scheme nor
CL are just toy languages.
Just my 2 cents.
Ramon
On Sun, 10 Dec 2006 08:51:44 -0800, ········@gmail.com wrote:
> Since I'm probably (although I'm not certain) the only person in this
> thread who has made a significant amount of money on either of these
> languages (i.e., via the sale of a startup whose product was tens of
> thousands of lines of Lisp code
Care to tell us what the startup was, and where it is now?
--
Steven.
Steven D'Aprano wrote:
> Care to tell us what the startup was, and where it is now?
Sure. We were called Afferent, Inc. We did simulated organic chemistry,
robot planning and control, and semi-automatic products analysis for
combinatorial chemistry for drug discovery for the pharmaceutical
industry. Founded in, um, ~1996? we were acquired in, um, 1999? (sorry,
I'm a little fuzzy on the dates) by MDL, Inc. for ... well, I'm not
sure that I'm supposed to say how much, so I won't. If someone can find
it in the public record, please feel free to post it. Let's just say
that we weren't a Dot Com but we also weren't particularly unhappy
about the deal. :-)
BTW, I didn't mean to imply that only reason that we used Lisp was the
compiler. What we were doing was more-or-less AI, and we wouldn't have
even thought to try to use anything other than Lisp. (I won't say that
we couldn't have in theory done it in another compiled language for
fear of attack by the Turing Mafia! :-) What I meant was the we
certainly would not have even consider Python or any other uncompiled
language because it would have been WAY too slow! Our (delivered
executable!) product could do hundreds of thousands of simulated
chemical reactions and solve robot planning problems in seconds. (The
robot planning was actually pretty simple. The simulated chemistry was
decidedly NOT!) The Tk-based GUI was by far the slowest part of the
system!
I have the code here (probably not the latest bcs I left the company
when it was acquired), let's do a little experiment, for what it's
worth: 89727 lines of Lisp code in 131 modules (lisp code files), 3306
"(defun" (by grep|wc), and 261 "(defmacro". [We did NOT use
macros as functions!] [Note that lines of code doesn't really matter
in Lisp.]
If you are interested, you can read a little about our product in this
paper:
http://nostoc.stanford.edu/jeff/personal/vita/pubs/2001designforscience.pdf
as well as seeing a little of the interface. (If you have any interest
in history of science, EScience, or drug discovery, you might even find
the content of the paper interesting! :-)
·········@gmail.com" <········@gmail.com> writes:
>
> I have the code here (probably not the latest bcs I left the company
> when it was acquired), let's do a little experiment, for what it's
> worth: 89727 lines of Lisp code in 131 modules (lisp code files), 3306
> "(defun" (by grep|wc), and 261 "(defmacro". [We did NOT use macros as
> functions!] [Note that lines of code doesn't really matter in Lisp.]
Wow--my emacs install has 1,152,598 lines of code in 1,570 files, 29,244
defuns and 1,393 defmacros. This really doesn't prove anything
whatsoever (as I imagine that your stuff was a _lot_ more complex),
except maybe how great the FSF is for giving away this sort of thing for
free.
--
Robert Uhl <http://public.xdi.org/=ruhl>
`We're ten parsecs from Regina, we've got a full tank of LH-two, a half
pack of cigarettes, I've dimmed the lights, and we're wearing sunglasses.'
`Let's jump.' --Leslie Bates
Robert Uhl wrote:
> ·········@gmail.com" <········@gmail.com> writes:
> > I have the code here (probably not the latest bcs I left the company
> > when it was acquired), let's do a little experiment, for what it's
> > worth: 89727 lines of Lisp code in 131 modules (lisp code files), 3306
> > "(defun" (by grep|wc), and 261 "(defmacro". [We did NOT use macros as
> > functions!] [Note that lines of code doesn't really matter in Lisp.]
>
> Wow--my emacs install has 1,152,598 lines of code in 1,570 files, 29,244
> defuns and 1,393 defmacros. This really doesn't prove anything
> whatsoever (as I imagine that your stuff was a _lot_ more complex),
> except maybe how great the FSF is for giving away this sort of thing for
> free.
Let us note that it's not FSF that gives this stuff away for free -- or
if it is them proximally, it is not them ultimately -- ultimately it's
the engineers who did all that work that gave it away for free.
·········@gmail.com" <········@gmail.com> writes:
> Let us note that it's not FSF that gives this stuff away for free -- or
> if it is them proximally, it is not them ultimately -- ultimately it's
> the engineers who did all that work that gave it away for free.
When I worked there, they paid me ;-)
Robert Uhl <·········@NOSPAMgmail.com> wrote:
+---------------
| ·········@gmail.com" <········@gmail.com> writes:
| > I have the code here (probably not the latest bcs I left the company
| > when it was acquired), let's do a little experiment, for what it's
| > worth: 89727 lines of Lisp code in 131 modules (lisp code files), 3306
| > "(defun" (by grep|wc), and 261 "(defmacro". [We did NOT use macros as
| > functions!] [Note that lines of code doesn't really matter in Lisp.]
|
| Wow--my emacs install has 1,152,598 lines of code in 1,570 files,
| 29,244 defuns and 1,393 defmacros.
+---------------
Wow, indeed! The entire CMUCL-19c distribution is "only" 592081 lines
of source code in 1192 files, with 10699 DEFUNs and 1839 DEFMACROs.
I didn't realize CMUCL was so "small" compared to Emacs. ;-}
[Of course, that doesn't include the number of DEFUNs & DEFMACROs
which are defined *by* macros, or the total of 2809 DEFINE-VOPs
in the various flavors of the compiler...]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
········@gmail.com schrieb:
> Now, speaking as a scientist, permit me to make a small practical
> suggestion: Why not just figure out a way to simplify some brand of
> Python -- make parens (or whatever) optionally replace whitespace and
> line breaks as syntax -- and then add a simple macro facility -- macros
> are actually a very simple extension if you have homogenous syntax,
> homogenizing your syntax to the point where macros are possible is the
> hard part -- and just see what happens.
The problem is not so much to add a macro facility ( or source
transformer ) but to soften it and make the macro facility actually
*simple* to use. Note that you don't need to replace whitespaces. The
Python parser is LL(1) and whitespace is almost completely abstracted
away once the Python source was tokenized successfully ( there is
exactly one non-terminal in the Python grammar, the "suite" NT, that
uses INDENT and DEDENT as moral equivalents for left- and right parens
). Note also that a homogenous syntax is not that important when
analyzing parse trees ( on the contrary, the more different structures
the better ) but when synthesizing new ones by fitting different
fragments of them together.
There are two basic approaches. In one you start with a piece of source
code ( a template ) and enhance the source description slightly with
somewhat like template parameters that keep source fragments and expand
them. In this case you also need an unquoting mechanism or a way to
evaluate code within the template. The second approach acts with high
level wrappers of more low level source trees ( just like ASTs are high
level wrappers of concrete syntax trees in most languages ). In Python
one might even use operator overloading to hide the AST structure and
provide a more convenient syntax.
But this only describes the transformational aspect. The definitional
part is not less important. I try to consider a grammar description of
a full programming language as as script in an own little language (
actually it is and the grammars grammar is often just an EBNF grammar
description ). This however presumes that enhancing grammars to enhance
languages is a reasonable approach not just in a Lex-Yacc ( or ANTLR )
setting. The next question concerns compositionality of language
enhancements or composition of even completely independent language
definitions and transformers both on source and on binary level. While
this is not feasible in general without creating ambiguities, I believe
this problem can be reduced to ambiguity detection in the underlying
grammars.
> One of two general things are
> likely to happen: Either people will not use them, and they will
> languish and die, and then at least you can say; "Been there, done
> that" to the Lisp community. Or, more likely, the some subset of the
> Python community will get it, and will figure out how useful they are,
> although it might take some time. And then you might find yourself with
> a wonderful new tool.
I think so too.
> You might even get a compiler out of the deal, at
> a pretty low cost, too! If you get macros, and get a compiler, I'm
> pretty sure that you will have no problem winning over the Lisp
> community, who would LOVE to have your extensive libraries, and that
> you will probably be able to maintain and improve your flagging
> position wrt Ruby (which, according to Matz, is more-or-less just Lisp
> w/o macros.)
Just a moment ago you called programmers of other languages "flies"
which I found annoying and now you offer LOVE in big letters? I don't
even think the "competition" to Ruby matters. Once an easy to use
metaprogramming system could be done for Python it could be ported with
some adaptions to other languages with more "complicated syntax" ( non
LL(1) parsable ).
Kay
Kay Schluehr wrote:
[Interesting and useful analysis of issues in language homogenization
snipped.]
> > You might even get a compiler out of the deal, at
> > a pretty low cost, too! If you get macros, and get a compiler, I'm
> > pretty sure that you will have no problem winning over the Lisp
> > community, who would LOVE to have your extensive libraries, and that
> > you will probably be able to maintain and improve your flagging
> > position wrt Ruby (which, according to Matz, is more-or-less just Lisp
> > w/o macros.)
>
> Just a moment ago you called programmers of other languages "flies"
> which I found annoying and now you offer LOVE in big letters?
Since everyone seems to have taken offence and this remark, let me
hereby apologize for the unintended implication. For the record, I
quote myself in full:
> Common) Lisp is the only industrial strength language with both pure
> compositionality and a real compiler. What Python has is stupid slogans
> ("It fits your brain." "Only one way to do things.") and an infinite
> community of flies that, for some inexplicable reason, believe these
> stupid slogns. These flies are, however, quite useful because they
> produce infinite numbers of random libraries, some of which end up
> being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
> is rapidly replacing Perl, and Ruby is simultaneously and even more
> rapidly replacing Python. Each is closer to Lisp than the last; the
> world is returning to Lisp and is dragging the flies with it.
> Eventually the flies will descend upon Lisp itself and will bring with
> them their infinite number of random libraries, and then things will be
> where they should have been 20 years ago, but got sidetracked by Tcl
> and other line noise.
I've already admitted that this was both a poor choice of words and, as
pointed out by Carl, an ad hominem argument. However, if you read the
whole thing you'll see that I'm really railing against the silly "It
fits your brain" and "Only one way to do things" marketing hype, and
programmers who seem to swallow and repeat it, not programmers in
general, nor even python programmers in general. In the last part it
say: "Eventually the flies will descend upon Lisp itself and will bring
with them their infinite number of random libraries, ..." Note that I'm
looking forward to this! So, although "flies" was a poor choice of
words, for which I whole heartedly apologize to those who might have
taken offence (and I do understand the reading and why you might take
offense at this given the context!), what I meant to say was: "Hey, all
you busy little pythonistas creating a million interesting libraries
(and some not, but that's fine) come over here and help do that for our
language too!"
Maybe "beavers" would have been a better animal. Mea Culpa!
Regardless, the topic of the rest our conversation -- how to put macros
and a compiler into Python -- stands as an interesting possibility
because it would enable us to come to you rather than the other way
around -- I'd be happy either way.
········@gmail.com wrote:
> I've already admitted that this was both a poor choice of words and, as
> pointed out by Carl, an ad hominem argument. However, if you read the
> whole thing you'll see that I'm really railing against the silly "It
> fits your brain" and "Only one way to do things" marketing hype, and
> programmers who seem to swallow and repeat it, not programmers in
> general, nor even python programmers in general.
Yes, but these are community symbols or tribe marks. They don't have
much meaning per se, just like the language name or a corporate
identity. However they express an attitude ( being easy and free from
language design redundancy ) that can be measured at least subjectively
by the user. If Ruby "fits the brain" better, then people will simply
drop Python in future or right now. There is nothing deep about it.
I'm not precisely sure when programming languages have turned into pop
culture and language designers stopped to name them "Algol", "Scheme"
or "A Programming Language" but "Joy", "Perl" or "Java". Even the small
lambda symbol is a pop fetish nowadays that is printed on the T-shirts
of Haskellians. Obviously language communities need some emotional glue
to grow even when they are constituted mainly by CS PhDs. I don't find
this necessarily a bad thing. In case of Lisp I don't think Paul Graham
made a bad job in constructing the imagery of a libertarian macho
hacker with a high end tool. Meanwhile all the flies are sitting on
Blubb that means on a heap of shit. A bit archaic and more cowboy than
Michelangelo but even Hegel is more famous for ending history, over 150
years before F. Fukuyama repeated this act, then for his intricate
systems theory created by idealist speculation. Some things end as pop
cult while others fill the archives of university libraries.
> Yes, but these are community symbols or tribe marks. They don't have
> much meaning per se, just like the language name or a corporate
> identity.
Unfortunately, I don't believe that this is entirely correct....I do
lurk c.l.p and see quite often people arguing (if briefly) about what
the one (and preferably only one) obvious way of doing things is. This
is only subtly ridiculous. The other ("It fits your brain") is much
less subtle, and much more problematic:
Now, I'm willing to buy that "it fits your brain" is taken less
seriously, but ...
> However they express an attitude ( being easy and free from
> language design redundancy ) that can be measured at least subjectively
> by the user. If Ruby "fits the brain" better, then people will simply
> drop Python in future or right now. There is nothing deep about it.
...if not deep, at least insidious, as demonstrated in part by the
current thread wherein, until forced to give it up, the present
pythonistas spent a significant number of chars trying to arguing, in
effect, that Lisp does NOT fit (one's) brain (e.g, is easier to use,
easier to learn, etc.) IN GENERAL. It seems to me (here and on c.l.p)
that many pythonista have somehow drunk this Koolaide and that as a
result have a sort of smug superiority about it. Of course, Lispers
have a smug superiority as well, but at least we have actual language
features (macros, compositionality, compilers) to wave around, not
ridiculous pop psychological noise.
········@gmail.com escreveu:
> > Yes, but these are community symbols or tribe marks. They don't have
> > much meaning per se, just like the language name or a corporate
> > identity.
>
> Unfortunately, I don't believe that this is entirely correct....I do
> lurk c.l.p and see quite often people arguing (if briefly) about what
> the one (and preferably only one) obvious way of doing things is. This
> is only subtly ridiculous. The other ("It fits your brain") is much
> less subtle, and much more problematic:
>
> Now, I'm willing to buy that "it fits your brain" is taken less
> seriously, but ...
>
> > However they express an attitude ( being easy and free from
> > language design redundancy ) that can be measured at least subjectively
> > by the user. If Ruby "fits the brain" better, then people will simply
> > drop Python in future or right now. There is nothing deep about it.
>
> ...if not deep, at least insidious, as demonstrated in part by the
> current thread wherein, until forced to give it up, the present
> pythonistas spent a significant number of chars trying to arguing, in
> effect, that Lisp does NOT fit (one's) brain (e.g, is easier to use,
> easier to learn, etc.) IN GENERAL. It seems to me (here and on c.l.p)
> that many pythonista have somehow drunk this Koolaide and that as a
> result have a sort of smug superiority about it. Of course, Lispers
> have a smug superiority as well, but at least we have actual language
> features (macros, compositionality, compilers) to wave around, not
> ridiculous pop psychological noise.
Right.
So, let's suppose I now want to learn LISP (I did try, on several
occasions). What I would like to do would be to replace Python and code
GUI applications. Yes, those boring business-like applications that
have to access databases and consume those new-fangled web-services and
whatnot. Heck, maybe even code games using DirectX.
So, how would I do that? For Python, that was simple. I learned the
basics, then moved to the libraries, learning as I went. Python has
some excelent online resources.
No, I don't want to see yet another Fibonacci example. No, console
output is not fun. And yes, I know about this list processing stuff.
All I can find are introductions to LISP written for computer science
courses. I can't seem to put together all those mnemonics into a
working program. LISP is full of primitives with 3-4 characters, chosen
for historical reasons.
The bottom line is that I didn't have a pleasant learning experience.
Perhaps the lispers here could offer some insights?
Stephen
> So, how would I do that? For Python, that was simple. I learned the
> basics, then moved to the libraries, learning as I went.
We've already all agreed that Python has a much larger set of standard
libraries than Lisp. You're right; This is an advantage that we all
recognize, and would love to have. We've also all agreed (I think) that
there's nothing in principle stopping Lisp from having these except
popularity, and that there is no good reason for this...except not
already having lots of libraries. Unfortunately, this is a bad bug, and
we (the lisp community) is hung on it. So if you guys would just fix
your language by adding homogeneous syntax and all that it brings with
it (macros, compilers, etc) we'd be happy to use your version of Lisp,
and all its great libraries, instead of ours! :-)
········@gmail.com wrote:
> So if you guys would just fix
> your language by adding homogeneous syntax and all that it brings with
> it (macros, compilers, etc) we'd be happy to use your version of Lisp,
> and all its great libraries, instead of ours! :-)
But if we did that, it wouldn't be Python any
more, it'd be Lisp. And then all those great
libraries wouldn't work with it, because they're
for Python, not Lisp. :-(
--
Greg
greg wrote:
> ········@gmail.com wrote:
> > So if you guys would just fix
> > your language by adding homogeneous syntax and all that it brings with
> > it (macros, compilers, etc) we'd be happy to use your version of Lisp,
> > and all its great libraries, instead of ours! :-)
>
> But if we did that, it wouldn't be Python any
> more, it'd be Lisp. And then all those great
> libraries wouldn't work with it, because they're
> for Python, not Lisp. :-(
Does the word "TRONDANT" hold some special meaning for you?
········@gmail.com wrote:
> Does the word "TRONDANT" hold some special meaning for you?
Er, no, in fact my brain raises a KeyError on it.
Is it supposed to mean anything?
--
Greg
greg wrote:
> ········@gmail.com wrote:
>
>> So if you guys would just fix
>> your language by adding homogeneous syntax and all that it brings with
>> it (macros, compilers, etc) we'd be happy to use your version of Lisp,
>> and all its great libraries, instead of ours! :-)
>
>
> But if we did that, it wouldn't be Python any
> more, it'd be Lisp.
And someone would then have to invent Python.
Let Python be Python, let Lisp be Lisp. It's all good.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Stephen Eilert wrote:
> So, let's suppose I now want to learn LISP (I did try, on several
> occasions). What I would like to do would be to replace Python and code
> GUI applications. Yes, those boring business-like applications that
> have to access databases and consume those new-fangled web-services and
> whatnot. Heck, maybe even code games using DirectX.
DrScheme for the first. Oh...well, there's loads of OpenGL support if
you can bear using that instead of DirectX. If you want CL, cl-opengl
and cells-gtk seem to work well.
> So, how would I do that? For Python, that was simple. I learned the
> basics, then moved to the libraries, learning as I went. Python has
> some excelent online resources.
http://www.gigamonkeys.com/book/ (Practical Common Lisp)
http://www.paulgraham.com/onlisp.html (On Lisp)
http://www.htdp.org/ (HTDP)
http://mitpress.mit.edu/sicp/ (SICP)
http://schemecookbook.org/
http://www.cliki.net/index
(Note: I mixed Scheme and CL pages above)
Not sure what other online resources you want.
> No, I don't want to see yet another Fibonacci example. No, console
> output is not fun. And yes, I know about this list processing stuff.
> All I can find are introductions to LISP written for computer science
> courses. I can't seem to put together all those mnemonics into a
> working program. LISP is full of primitives with 3-4 characters, chosen
> for historical reasons.
You're welcome to use things like first, rest, or second instead of
car, cdr, or cadr, but I always find the latter easier (car and cdr are
composable, and remind you that you're using cons cells). What other
mnemonics are there? I guess cons, but that shouldn't be hard...
On the other hand, Python has no 3-letter words. *struck dead by a
flying "def"*
Greg Johnston escreveu:
> Stephen Eilert wrote:
> > So, let's suppose I now want to learn LISP (I did try, on several
> > occasions). What I would like to do would be to replace Python and code
> > GUI applications. Yes, those boring business-like applications that
> > have to access databases and consume those new-fangled web-services and
> > whatnot. Heck, maybe even code games using DirectX.
>
> DrScheme for the first. Oh...well, there's loads of OpenGL support if
> you can bear using that instead of DirectX. If you want CL, cl-opengl
> and cells-gtk seem to work well.
>
Actually, that was an example. I'd rather use OpenGL, but sometimes you
are requested to do otherwise.
As soon as I get some free time, I'm going to play with them.
> > So, how would I do that? For Python, that was simple. I learned the
> > basics, then moved to the libraries, learning as I went. Python has
> > some excelent online resources.
>
> http://www.gigamonkeys.com/book/ (Practical Common Lisp)
> http://www.paulgraham.com/onlisp.html (On Lisp)
> http://www.htdp.org/ (HTDP)
> http://mitpress.mit.edu/sicp/ (SICP)
> http://schemecookbook.org/
> http://www.cliki.net/index
> (Note: I mixed Scheme and CL pages above)
>
It will take some time, but I'll take a look at those.
> You're welcome to use things like first, rest, or second instead of
> car, cdr, or cadr, but I always find the latter easier (car and cdr are
> composable, and remind you that you're using cons cells). What other
> mnemonics are there? I guess cons, but that shouldn't be hard...
I think they are too cryptic for no reason. Then again, that's the sort
of thing that disappears with usage.
> On the other hand, Python has no 3-letter words. *struck dead by a
> flying "def"*
There's len, and a couple more built-ins. But at least they've got
proper names :P
Stephen
"Stephen Eilert" <········@gmail.com> writes:
> So, let's suppose I now want to learn LISP (I did try, on several
> occasions). What I would like to do would be to replace Python and code
> GUI applications. Yes, those boring business-like applications that have
> to access databases and consume those new-fangled web-services and
> whatnot. Heck, maybe even code games using DirectX.
>
> So, how would I do that?
First, get a copy of Practical Common Lisp, which shows how to build, well,
practical programs in Lisp:
http://www.gigamonkeys.com/book/
Next, download a Common Lisp implementation. I happen to prefer SBCL, but
any of the free commercial trial products will do, as will CLISP, CMUCL,
ABCL, Open MCL, etc.
To find libraries, look in Cliki, in the Common Lisp Directory, and in
Common-Lisp.net. The Directory is especially good for finding obscure
stuff.
http://www.cliki.net/
http://www.cl-user.net/
http://common-lisp.net/
Bookmark the Hyperspec, which is an HTML version of the ANSI Common Lisp
standard. Skim the whole thing once, so you have a vague idea of what
functions are available in the standard library.
http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
Finally, ask questions on the #lisp IRC channel or in comp.lang.lisp when
you are stuck.
Stephen Eilert wrote:
> So, let's suppose I now want to learn LISP (I did try, on several
> occasions). What I would like to do would be to replace Python and code
> GUI applications. Yes, those boring business-like applications that
> have to access databases and consume those new-fangled web-services and
> whatnot. Heck, maybe even code games using DirectX.
>
> So, how would I do that?
You may also be interested in related languages. I've written several
interesting programs in OCaml:
http://www.ffconsultancy.com/free/ocaml/examples.html
http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation
More recently, I've been writing F# examples:
http://www.ffconsultancy.com/dotnet/fsharp
You can probably translate the F# demos into a Lisp for .NET without too
much difficulty.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
"Stephen Eilert" <········@gmail.com> writes:
>
> So, let's suppose I now want to learn LISP (I did try, on several
> occasions). What I would like to do would be to replace Python and
> code GUI applications. Yes, those boring business-like applications
> that have to access databases and consume those new-fangled
> web-services and whatnot. Heck, maybe even code games using DirectX.
GUIs are a weak point, or were last I looked. There are at least three
GTK+ interfaces.
Database access is handled very nicely with CLSQL, which does OR mapping
right.
I've not written code to 'consume web-services,' but I daresay that
NET.HTML.CLIENT (believe that's the name) would do the trick.
--
Robert Uhl <http://public.xdi.org/=ruhl>
If anybody can show me in the Bible the command, 'Thou shalt not smoke,'
I am ready to keep it; but I haven't found it yet. I find ten
commandments, and it's as much as I can do to keep them; and I've no
desire to make them into eleven or twelve. --C. H. Spurgeon
Robert Uhl wrote:
> "Stephen Eilert" <········@gmail.com> writes:
>
>>So, let's suppose I now want to learn LISP (I did try, on several
>>occasions). What I would like to do would be to replace Python and
>>code GUI applications. Yes, those boring business-like applications
>>that have to access databases and consume those new-fangled
>>web-services and whatnot. Heck, maybe even code games using DirectX.
>
>
> GUIs are a weak point, or were last I looked.
LW comes with CAPI, portable across the big 3. ACL has Common Graphics
on win32, and I think they have Gtk bindings elsewhere (just guessing,
really). Everyone has Ltk, Cells-Gtk, and Celtk. (Two Tks, one Gtk if
that is not clear).
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
·········@gmail.com" <········@gmail.com> writes:
> Kay Schluehr wrote:
>
> > is rapidly replacing Perl, and Ruby is simultaneously and even more
> > rapidly replacing Python.
Really? Given its small base, the percentage increases in Ruby use
(for any reason) can look quite impressive. I've see data suggesting
Ruby is replacing Perl and maybe Java. But I've yet to see data which
shows people dropping Python and moving to Ruby. Where do I find that
data?
--
Harry George
PLM Engineering Architecture
Harry George ha escrito:
> Really? Given its small base, the percentage increases in Ruby use
> (for any reason) can look quite impressive. I've see data suggesting
> Ruby is replacing Perl and maybe Java. But I've yet to see data which
> shows people dropping Python and moving to Ruby. Where do I find that
> data?
No _scientific_ data but TIOBE Dec index shows an increase of 9x on
Ruby, 1x for Python and -4x for LISP [1]. More:
"There is only 1 month to go before TIOBE announces its 'programming
language of the year 2006'... Ruby remains to be top favorite for the
title."
Look also to Google Trends [2, 3]. One can notice further increase for
Ruby and slight decreasing for Python.
[1] http://www.tiobe.com/tpci.htm
[2]
http://www.google.com/trends?q=ruby+programming%2C+python+programming&ctab=0&geo=all&date=all
http://www.google.com/trends?q=ruby+language%2C+python+language&ctab=0&geo=all&date=all
Harry George wrote:
> ·········@gmail.com" <········@gmail.com> writes:
>
>
>>Kay Schluehr wrote:
>>
>>
>>>is rapidly replacing Perl, and Ruby is simultaneously and even more
>>>rapidly replacing Python.
>
>
> Really? Given its small base, the percentage increases in Ruby use
> (for any reason) can look quite impressive. I've see data suggesting
> Ruby is replacing Perl and maybe Java. But I've yet to see data which
> shows people dropping Python and moving to Ruby. Where do I find that
> data?
You missed it? Google fight:
http://www.googlefight.com/index.php?lang=en_GB&word1=Python&word2=Ruby
Python wins, 74 to 69.3. And there is no Monty Ruby to help.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton ha escrito:
> You missed it? Google fight:
>
> http://www.googlefight.com/index.php?lang=en_GB&word1=Python&word2=Ruby
>
> Python wins, 74 to 69.3. And there is no Monty Ruby to help.
>
> ken
Nice animation!
http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Monty+Ruby
Juan R. wrote:
> Ken Tilton ha escrito:
> > You missed it? Google fight:
> >
> > http://www.googlefight.com/index.php?lang=en_GB&word1=Python&word2=Ruby
> >
> > Python wins, 74 to 69.3. And there is no Monty Ruby to help.
> >
> > ken
>
> Nice animation!
>
> http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Monty+Ruby
It's not fair to pick on him just because you're better at
Googlefighting...
http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Juan+Gonz%E1lez
This thing is strange, I don't understand it at all...
http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Robert+Thorpe
I find the results dubious. A conspiracy masterminded by Monty Ruby no
doubt.
Rob Thorpe ha escrito:
> Juan R. wrote:
> > Ken Tilton ha escrito:
> > > You missed it? Google fight:
> > >
> > > http://www.googlefight.com/index.php?lang=en_GB&word1=Python&word2=Ruby
> > >
> > > Python wins, 74 to 69.3. And there is no Monty Ruby to help.
> > >
> > > ken
> >
> > Nice animation!
> >
> > http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Monty+Ruby
>
> It's not fair to pick on him just because you're better at
> Googlefighting...
I simply noticed (eval "there is no Monty Ruby to help") --> NIL
> http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Juan+Gonz%E1lez
>
> This thing is strange, I don't understand it at all...
There is many "Juan Gonz�lez" but i am not one of them. Try next
http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Juan+R.+Gonz%E1lez+%C1lvarez
> http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Robert+Thorpe
> I find the results dubious. A conspiracy masterminded by Monty Ruby no
> doubt.
With some help from mediocre programmers :)
Kay Schluehr ha escrito:
> Note also that a homogenous syntax is not that important when
> analyzing parse trees ( on the contrary, the more different structures
> the better ) but when synthesizing new ones by fitting different
> fragments of them together.
Interesting, could you provide some illustration for this?
> The next question concerns compositionality of language
> enhancements or composition of even completely independent language
> definitions and transformers both on source and on binary level. While
> this is not feasible in general without creating ambiguities, I believe
> this problem can be reduced to ambiguity detection in the underlying
> grammars.
A bit ambiguous my reading. What is not feasible in general? Achieving
compositionality?
Juan R. wrote:
> Kay Schluehr ha escrito:
> > Note also that a homogenous syntax is not that important when
> > analyzing parse trees ( on the contrary, the more different structures
> > the better ) but when synthesizing new ones by fitting different
> > fragments of them together.
>
> Interesting, could you provide some illustration for this?
My approach is strongly grammar based. You start with a grammar
description of your language. This is really not much different from
using Lex/Yacc except that it is situated and adapted to a pre-existing
language ecosystem. I do not intend to start from scratch.
Besides the rules that constitute your host language you might add:
repeat_stmt ::= 'repeat' ':' suite 'until' ':' test
The transformation target ( the "template" ) is
while True:
<suite>
if <test>:
break
The structure of the rule is also the structure of its constituents in
the parse tree. Since you match the repeat_stmt rule and its
corresponding node in the parse tree you immediately get the <suite>
node and the <test> node:
class FiberTransformer(Transformer):
@transform
def repeat_stmt(self, node):
_suite = find_node(node, symbol.suite)
_ test = find_node(node, symbol.test, depth = 1)
#
# create the while_stmt here
#
return _while_stmt_node
So analysis works just fine. But what about creating the transformation
target? The problem with the template above is that it can't work
precisely this way as a Python statement, because the rule for a while
statement looks like this:
while_stmt: 'while' test ':' suite
That's why the macro expander has to merge the <suite> node, passed
into the template with the if_stmt of the template, into a new suite
node.
Now think about having created a while_stmt from your original
repeat_stmt. You return the while_stmt and it has to be fitted into the
original syntax tree in place of the repeat_stmt. This must be done
carefully. Otherwise structure in the tree is desroyed or the node is
inserted in a place where the compiler does not expect it.
The framework has to do lots of work to ease the pain for the meta
programmer.
a) create the correct transformation target
b) fit the target into the syntax tree
Nothing depends here particularly on Python but is true for any
language with a fixed grammar description. I've worked exclusively with
LL(1) grammars but I see no reason why this general scheme shall not
work with more powefull grammars and more complicated languages - Rubys
for example.
> > The next question concerns compositionality of language
> > enhancements or composition of even completely independent language
> > definitions and transformers both on source and on binary level. While
> > this is not feasible in general without creating ambiguities, I believe
> > this problem can be reduced to ambiguity detection in the underlying
> > grammars.
>
> A bit ambiguous my reading. What is not feasible in general? Achieving
> compositionality?
Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
grammars and T1, T2 transformers that transform source written in L1 or
L2 into some base language
L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
s.t. the transformers T1 and T2 can be used also to transform L3 = (G3
= G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
the answer is NO. But it could also be YES in many relevant cases. So
the question is whether it is necessary and sufficient to check whether
the "crossing" between G1 and G2 is feasible i.e. doesn't produce
ambiguities.
Kay Schluehr wrote:
> Juan R. wrote:
> > A bit ambiguous my reading. What is not feasible in general? Achieving
> > compositionality?
>
> Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
> grammars and T1, T2 transformers that transform source written in L1 or
> L2 into some base language
> L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
> s.t. the transformers T1 and T2 can be used also to transform L3 = (G3
> = G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
> the answer is NO. But it could also be YES in many relevant cases. So
> the question is whether it is necessary and sufficient to check whether
> the "crossing" between G1 and G2 is feasible i.e. doesn't produce
> ambiguities.
See, we don't have this problem in Lisp, unless some of the transfomers
in T1 have names that clash with those in T2. That problem can be
avoided by placing the macros in separate packages, or by renaming. In
In the absence of naming conflicts, the two macro languages L1 and L2
combine seamlessly into L3, because the transformers T are defined on
structure, not on lexical grammar. The read grammar doesn't change (and
is in fact irrelevant, since the whole drama is played out with
objects, not text). In L1, the grammar is nested lists. In L2, the
grammar is, again, nested lists. And in L3: nested lists. So that in
fact, at one level, you don't even recognize them as being different
languages, but on a different level you can.
The problems you are grappling with are in fact created by the
invention of an unsuitable encoding. You are in effect solving a puzzle
that you or others created for you.
Kaz Kylheku wrote:
> Kay Schluehr wrote:
> > Juan R. wrote:
> > > A bit ambiguous my reading. What is not feasible in general? Achieving
> > > compositionality?
> >
> > Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
> > grammars and T1, T2 transformers that transform source written in L1 or
> > L2 into some base language
> > L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
> > s.t. the transformers T1 and T2 can be used also to transform L3 = (G3
> > = G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
> > the answer is NO. But it could also be YES in many relevant cases. So
> > the question is whether it is necessary and sufficient to check whether
> > the "crossing" between G1 and G2 is feasible i.e. doesn't produce
> > ambiguities.
>
> See, we don't have this problem in Lisp, unless some of the transfomers
> in T1 have names that clash with those in T2. That problem can be
> avoided by placing the macros in separate packages, or by renaming. In
> In the absence of naming conflicts, the two macro languages L1 and L2
> combine seamlessly into L3, because the transformers T are defined on
> structure, not on lexical grammar.
Renaming is of course feasible too but it has to be done manually and
likely involves the change of some keyword. If both L1 and L2 define a
repeat_stmt with slightly different semantics they can't be combined -
renaming of rules is not always a big problem since a new package is
created for L3 anyway and scripts that work with L1 and L2 are at least
binary compatible with L3. The clash happens when one tries to edit an
L2 script in an L3 context. One has to refactor it regarding the
renamed rule ( this can very likely be done automatically ).
Since the rule definitions originate in different packages ( each
language is created in an own package ) there is basically no conflict
and one can switch between L1 and L2 and also import L1 in L2 or vice
versa but this is not the kind of composition I intend since one can't
really nest the statements/expressions made in L1 with those made in
L2.
> The read grammar doesn't change (and
> is in fact irrelevant, since the whole drama is played out with
> objects, not text). In L1, the grammar is nested lists. In L2, the
> grammar is, again, nested lists. And in L3: nested lists. So that in
> fact, at one level, you don't even recognize them as being different
> languages, but on a different level you can.
I don't see how this differs. A grammar G is just a "script" written in
another language ( say EBNF ) which can be represented within the sytem
as just another grammar. The internal representation of G is that of a
list of lists. While the programmer manipulates the surface structure
of the Grammar script which could be represented in whatever she likes
( currently as plain text but maybe also as a graph using dot and
graphviz or in any other slick way an UI designer imagines ) all
internal operations are defined on nested lists i.e. objects.
Kaz Kylheku ha escrito:
> Kay Schluehr wrote:
> > Juan R. wrote:
> > > A bit ambiguous my reading. What is not feasible in general? Achieving
> > > compositionality?
> >
> > Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
> > grammars and T1, T2 transformers that transform source written in L1 or
> > L2 into some base language
> > L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
> > s.t. the transformers T1 and T2 can be used also to transform L3 = (G3
> > = G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
> > the answer is NO. But it could also be YES in many relevant cases. So
> > the question is whether it is necessary and sufficient to check whether
> > the "crossing" between G1 and G2 is feasible i.e. doesn't produce
> > ambiguities.
>
> See, we don't have this problem in Lisp, unless some of the transfomers
> in T1 have names that clash with those in T2. That problem can be
> avoided by placing the macros in separate packages, or by renaming.
Or simply namespacing!
foo from package alpha --> alpha:foo
foo from package beta --> beta:foo
But what composition of different languages? E.g. LISP and Fortran in
the same source.
> In
> In the absence of naming conflicts, the two macro languages L1 and L2
> combine seamlessly into L3, because the transformers T are defined on
> structure, not on lexical grammar. The read grammar doesn't change (and
> is in fact irrelevant, since the whole drama is played out with
> objects, not text). In L1, the grammar is nested lists. In L2, the
> grammar is, again, nested lists. And in L3: nested lists. So that in
> fact, at one level, you don't even recognize them as being different
> languages, but on a different level you can.
>
> The problems you are grappling with are in fact created by the
> invention of an unsuitable encoding. You are in effect solving a puzzle
> that you or others created for you.
Kay Schluehr ha escrito:
> Juan R. wrote:
>
> > Kay Schluehr ha escrito:
> > > Note also that a homogenous syntax is not that important when
> > > analyzing parse trees ( on the contrary, the more different structures
> > > the better ) but when synthesizing new ones by fitting different
> > > fragments of them together.
> >
> > Interesting, could you provide some illustration for this?
>
> My approach is strongly grammar based. You start with a grammar
> description of your language. This is really not much different from
> using Lex/Yacc except that it is situated and adapted to a pre-existing
> language ecosystem. I do not intend to start from scratch.
>
> Besides the rules that constitute your host language you might add:
>
> repeat_stmt ::= 'repeat' ':' suite 'until' ':' test
>
> The transformation target ( the "template" ) is
>
> while True:
> <suite>
> if <test>:
> break
>
> The structure of the rule is also the structure of its constituents in
> the parse tree. Since you match the repeat_stmt rule and its
> corresponding node in the parse tree you immediately get the <suite>
> node and the <test> node:
>
> class FiberTransformer(Transformer):
> @transform
> def repeat_stmt(self, node):
> _suite = find_node(node, symbol.suite)
> _ test = find_node(node, symbol.test, depth = 1)
> #
> # create the while_stmt here
> #
> return _while_stmt_node
>
> So analysis works just fine. But what about creating the transformation
> target? The problem with the template above is that it can't work
> precisely this way as a Python statement, because the rule for a while
> statement looks like this:
>
> while_stmt: 'while' test ':' suite
>
> That's why the macro expander has to merge the <suite> node, passed
> into the template with the if_stmt of the template, into a new suite
> node.
>
> Now think about having created a while_stmt from your original
> repeat_stmt. You return the while_stmt and it has to be fitted into the
> original syntax tree in place of the repeat_stmt. This must be done
> carefully. Otherwise structure in the tree is desroyed or the node is
> inserted in a place where the compiler does not expect it.
>
> The framework has to do lots of work to ease the pain for the meta
> programmer.
>
> a) create the correct transformation target
> b) fit the target into the syntax tree
>
> Nothing depends here particularly on Python but is true for any
> language with a fixed grammar description. I've worked exclusively with
> LL(1) grammars but I see no reason why this general scheme shall not
> work with more powefull grammars and more complicated languages - Rubys
> for example.
Thanks.
> > > The next question concerns compositionality of language
> > > enhancements or composition of even completely independent language
> > > definitions and transformers both on source and on binary level. While
> > > this is not feasible in general without creating ambiguities, I believe
> > > this problem can be reduced to ambiguity detection in the underlying
> > > grammars.
> >
> > A bit ambiguous my reading. What is not feasible in general? Achieving
> > compositionality?
>
> Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
> grammars and T1, T2 transformers that transform source written in L1 or
> L2 into some base language
> L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
> s.t. the transformers T1 and T2 can be used also to transform L3 = (G3
> = G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
> the answer is NO.
You mean direct compositionality. Is there any formal proof that you
cannot find a (G2' , T2') unambiguously generating (G2, T2) and
combining with L1 or this is always possible?
This would not work for language enhancements but for composition of
completely independent languages.
> But it could also be YES in many relevant cases. So
> the question is whether it is necessary and sufficient to check whether
> the "crossing" between G1 and G2 is feasible i.e. doesn't produce
> ambiguities.
Juan R. schrieb:
> > Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
> > grammars and T1, T2 transformers that transform source written in L1 or
> > L2 into some base language
> > L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
> > s.t. the transformers T1 and T2 can be used also to transform L3 = (G3
> > = G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
> > the answer is NO.
>
> You mean direct compositionality. Is there any formal proof that you
> cannot find a (G2' , T2') unambiguously generating (G2, T2) and
> combining with L1 or this is always possible?
You mean a universal language adapter? I guess this is always possible
using alpha conversion but I don't believe this leads to theoretical or
practical interesting solutions but is just a limit concept.
> This would not work for language enhancements but for composition of
> completely independent languages.
The practical problem with composing enhancements is that any two
extensions L1, L2 share a lot of rules and rely on their structure.
What if they don't just extend their host language L0 conservatively
but also redefine rules of L0? This is not just a theoretical problem
but it happens quite naturally if you want to adapt an extension
developed for Python 2.4 for working with Python 2.5. Here Python 2.5
is considered as just another particular extension. Obviously Py3K will
become an interesting testcase for all kinds of syntactical and
semantical transformations.
Kay Schluehr wrote:
>
> You mean a universal language adapter? I guess this is always possible
> using alpha conversion but I don't believe this leads to theoretical or
> practical interesting solutions but is just a limit concept.
Not familiarized with you terminology. I think that i would call that a
universal language composer.
I mean if there exists some theoretical limitation to composionality of
two directly collapsing languages (G1, T1) and (G2, T2) via a
unambiguous modification (e.g. 'renaming') to a third one (G2', T2'),
unknown to me. I mean some theoretical limitation in the sense of known
theoretical limitations to proving theorems in closed formal systems.
After all proving a formal theorem is not very different from
enhacement of a language.
> The practical problem with composing enhancements is that any two
> extensions L1, L2 share a lot of rules and rely on their structure.
> What if they don't just extend their host language L0 conservatively
> but also redefine rules of L0? This is not just a theoretical problem
> but it happens quite naturally if you want to adapt an extension
> developed for Python 2.4 for working with Python 2.5. Here Python 2.5
> is considered as just another particular extension. Obviously Py3K will
> become an interesting testcase for all kinds of syntactical and
> semantical transformations.
I would consider redefined-L0 to be L0'. I think that a concept of
namespaces could be also used for versioning-like conflicts:
L0v24:foo(), L0v25:foo(). The problem is that both versions may be
stored and managed during initial period of time. But in the long run
old libraries, extensions... would be updated to the new version.
Juan R. schrieb:
> Kay Schluehr wrote:
> >
> > You mean a universal language adapter? I guess this is always possible
> > using alpha conversion but I don't believe this leads to theoretical or
> > practical interesting solutions but is just a limit concept.
>
> Not familiarized with you terminology. I think that i would call that a
> universal language composer.
>
> I mean if there exists some theoretical limitation to composionality of
> two directly collapsing languages (G1, T1) and (G2, T2) via a
> unambiguous modification (e.g. 'renaming') to a third one (G2', T2'),
> unknown to me. I mean some theoretical limitation in the sense of known
> theoretical limitations to proving theorems in closed formal systems.
> After all proving a formal theorem is not very different from
> enhacement of a language.
But proving the theorem might be trivial and the implementation
useless. It's like saying you want "universal composition" of two
geometric objects e.g. two manifolds M1, M2 and I write down M3 = M1 x
M2. This is always feasible but this is just not the right kind of
thing in many occasions.
I want to give a practical example. The Python grammar defines a
compound_stmt rule by:
compound_stmt: for_stmt | while_stmt | if_stmt | ...
Now you might add a switch_stmt to G1 and a repeat_stmt to G2
G1: compound_stmt: for_stmt | while_stmt | if_stmt | switch_stmt |...
G2: compound_stmt: for_stmt | while_stmt | if_stmt | repeat_stmt |...
What you actually want in G3 is
G3: compound_stmt: for_stmt | while_stmt | if_stmt | switch_stmt |
repeat_stmt |...
You don't want to rename each statement and mangle each terminal of G2
although this might always be possible. Renaming also negatively
affects the transformer of G2 which precedes composition and is encoded
as Python source. It has to be refactored too when you rename a rule.
So one requirement on a system of composition rules is to drop alpha
conversion which is just a last resort. I guess in any *reasonable*
system of composition rules the question whether G1 and G2 are
composable is decidable and this can also be proofed at least for
certain classes of grammars that are not Turing complete languages by
themselves.
>
> > The practical problem with composing enhancements is that any two
> > extensions L1, L2 share a lot of rules and rely on their structure.
> > What if they don't just extend their host language L0 conservatively
> > but also redefine rules of L0? This is not just a theoretical problem
> > but it happens quite naturally if you want to adapt an extension
> > developed for Python 2.4 for working with Python 2.5. Here Python 2.5
> > is considered as just another particular extension. Obviously Py3K will
> > become an interesting testcase for all kinds of syntactical and
> > semantical transformations.
>
> I would consider redefined-L0 to be L0'. I think that a concept of
> namespaces could be also used for versioning-like conflicts:
> L0v24:foo(), L0v25:foo(). The problem is that both versions may be
> stored and managed during initial period of time. But in the long run
> old libraries, extensions... would be updated to the new version.
Sure, but it's preferable to see how far one gets without name mangling
and other crutches.
In <························@n67g2000cwd.googlegroups.com>, Kay Schluehr
wrote:
> Once an easy to use metaprogramming system could be done for Python it
> could be ported with some adaptions to other languages with more
> "complicated syntax" ( non LL(1) parsable ).
FYI: Here's how Nemerle does macros: http://nemerle.org/Macros
I guess you can't really transform Nemerle into a completely different
language, but it is at least interesting to see such a feature in language
with a more complex syntax than Lisp.
Ciao,
Marc 'BlackJack' Rintsch
Marc 'BlackJack' Rintsch schrieb:
> In <························@n67g2000cwd.googlegroups.com>, Kay Schluehr
> wrote:
>
> > Once an easy to use metaprogramming system could be done for Python it
> > could be ported with some adaptions to other languages with more
> > "complicated syntax" ( non LL(1) parsable ).
>
> FYI: Here's how Nemerle does macros: http://nemerle.org/Macros
>
> I guess you can't really transform Nemerle into a completely different
> language, but it is at least interesting to see such a feature in language
> with a more complex syntax than Lisp.
>
> Ciao,
> Marc 'BlackJack' Rintsch
Hi Mark, there are quite a lot of meta programming systems ( MPS ) for
non Lispy languages ( O'Caml, Haskell, Java of course and also Dylan
as a member of the "Lisp family" with non homogenous syntax ). I hope I
will find time in the new year to review and compare them to the
grammar based approach I described in the grandparent post and follow
myself with "EasyExtend" for Python - which is *radical* and somewhat
in between a language specific MPS and Lex/Yacc. The idea to separate
the MPS from the host language but providing a multi-language framework
is somewhat complementary to that of PyPy that is a framework that
supports several backends for one language.
Marc 'BlackJack' Rintsch <······@gmx.net> writes:
> FYI: Here's how Nemerle does macros: http://nemerle.org/Macros
>
> I guess you can't really transform Nemerle into a completely different
> language, but it is at least interesting to see such a feature in language
> with a more complex syntax than Lisp.
Nobody seems to concerned that Haskell lacks macros. What's up with that?
In <··············@ruckus.brouhaha.com>, Paul Rubin wrote:
> Marc 'BlackJack' Rintsch <······@gmx.net> writes:
>> FYI: Here's how Nemerle does macros: http://nemerle.org/Macros
>>
>> I guess you can't really transform Nemerle into a completely different
>> language, but it is at least interesting to see such a feature in language
>> with a more complex syntax than Lisp.
>
> Nobody seems to concerned that Haskell lacks macros. What's up with that?
Hm, right from the Nemerle macro page linked above:
We are following them in the direction of much more powerful, and at the
same time more secure (type-safe) solutions like Haskell Template
Meta-programming.
So there seems to be something macro-like for Haskell.
Ciao,
Marc 'BlackJack' Rintsch
Marc 'BlackJack' Rintsch <······@gmx.net> writes:
> We are following them in the direction of much more powerful, and at the
> same time more secure (type-safe) solutions like Haskell Template
> Meta-programming.
>
> So there seems to be something macro-like for Haskell.
I think that's some kind of proposed or experimental Haskell feature,
not in the current standard, but I'm not sure. I'm barely even a
newbie with Haskell.
In article <··············@ruckus.brouhaha.com>, Paul Rubin wrote:
>Marc 'BlackJack' Rintsch <······@gmx.net> writes:
>> So there seems to be something macro-like for Haskell.
>
>I think that's some kind of proposed or experimental Haskell feature,
>not in the current standard, but I'm not sure. I'm barely even a
>newbie with Haskell.
It's called Template Haskell.
http://www.haskell.org/th/
"Template Haskell is an extension to Haskell 98 that allows you to do
type-safe compile-time meta-programming, with Haskell both as the
manipulating language and the language being manipulated."
There is an experimental implementation in new versions of GHC.
Follow-ups set to comp.lang.haskell in case anyone wants to discuss it. I
claim no understanding of it yet. Better figure out ordinary Haskell
first...
Paul Rubin <·············@NOSPAM.invalid> writes:
> Nobody seems to concerned that Haskell lacks macros. What's up with
> that?
Haskell is lazy, so it doesn't need macros (well, it would be more
accurate to say that by not evaluating function arguments until they
are needed it makes many of the usual macro usecases moot).
lazyness has a nontrivial cost, however, both runtime and cognitive.
hoping he's not answering a rhetorical question,
--m
--
I'm on a seafood diet -- I see food and I eat it. -- anonymous
Michael Livshin <······@cmm.kakpryg.net> writes:
> > Nobody seems to concerned that Haskell lacks macros. What's up with
> > that?
>
> Haskell is lazy, so it doesn't need macros (well, it would be more
> accurate to say that by not evaluating function arguments until they
> are needed it makes many of the usual macro usecases moot).
>
> lazyness has a nontrivial cost, however, both runtime and cognitive.
>
> hoping he's not answering a rhetorical question,
It's a reasonable answer. Does SML have a macro system?
Michael Livshin wrote:
> Paul Rubin <·············@NOSPAM.invalid> writes:
>> Nobody seems to concerned that Haskell lacks macros. What's up with
>> that?
>
> Haskell is lazy, so it doesn't need macros
Outside Lisp, macros are for syntax. Evaluation semantics (e.g. lazy
evaluation) then have nothing to do with macros.
So Haskell being lazy doesn't obviate macros. You might still want to extend
the syntax of Haskell, i.e. want macros. However, this is much less
desirable than Lisp because Haskell already provides a wealth of powerful
features and related syntax (e.g. pattern matching, comprehensions). I
think this is an important point often missed by Lispers.
> lazyness has a nontrivial cost, however, both runtime and cognitive.
The main problem with lazy evaluation is unpredictable memory use.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Outside Lisp, macros are for syntax. Evaluation semantics (e.g. lazy
> evaluation) then have nothing to do with macros.
I don't think that's entirely true. With currying
and lazy evaluation, there's a sense in which
Haskell function definitions already *are* macros.
There are limits to the degree of syntactical
transformation you can reasonably achieve -- it
wouldn't be easy to make Haskell code look exactly
like Cobol, for example. But usually that's not
what you're after -- rather you just want to
devise some way to express your intent with a
minimum of boilerplate.
I once implemented a parser in HUGS. Using nothing
but built-in language features, I was able to
construct a system whereby I could more or less
just write down the BNF grammar rules and feed them
straight into the HUGS compiler. Achieving a
similar trick in Lisp would probably have required
using macros.
--
Greg
From: Dmitry V. Gorbatovsky
Subject: Re: merits of Lisp vs Python
Date:
Message-ID: <eljjtl$q1c$1@aioe.org>
········@gmail.com wrote:
>I challenge anyone making psychological
> claims about language X (for any X) being easier to either
> read/learn/use than language Y (for any Y) to come up with any valid
> evidence whatever.
Put aside,that I don't understand meaning of term
"psychological claim" in that context.
It is obvious that different
medium of information exchange provides
different levels of readability for humans.
And accordingly easier/harder to learn/use.
Regards, Dmitry
········@gmail.com wrote:
> compilers are GREATLY facilitated by having a
> macro facility because (at first blush) all you need to do is to
> macro-expand down to something you know how to turn into code.
There's no way you could compile Python to efficient
machine code just by macro expansion. You'd also need
some very heavy-duty type inferencing.
Python is extremely dynamic, even more so than Lisp.
That's why compiling Python is hard, not because it
doesn't have macros.
--
Greg
greg <····@cosc.canterbury.ac.nz> writes:
> ········@gmail.com wrote:
>> compilers are GREATLY facilitated by having a
>> macro facility because (at first blush) all you need to do is to
>> macro-expand down to something you know how to turn into code.
>
> There's no way you could compile Python to efficient
> machine code just by macro expansion. You'd also need
> some very heavy-duty type inferencing.
When I used to use Ruby a lot, I believed this line that the Ruby
community fed itself (and apparently Python feeds itself as well):
Ruby/Python has to be interpreted because it's too dynamic. This is
wrong, of course. A compiler shifts a lot of decisions that an
interpreter would have to make at runtime to compile-time. There is
no reason a dynamic language can't enjoy this efficiency. On the
other hand, if Python is doing a hash lookup on every function call,
as Alex Mizrahi claims, compilation may not do much to smooth over
such awkwardness.
> Python is extremely dynamic, even more so than Lisp.
> That's why compiling Python is hard, not because it
> doesn't have macros.
Uh huh. "More so than Lisp"? Just making stuff up now?
Despite its dynamism, Lisp is quite compilable. For example, I can
redefine classes, functions, macros, etc. at runtime and compiled code
referring to the old code will still work. You are conflating
dynamism with interpretedness, and that's incorrect.
Bill Atkins <······@rpi.edu> writes:
> > There's no way you could compile Python to efficient
> > machine code just by macro expansion. You'd also need
> > some very heavy-duty type inferencing.
>
> When I used to use Ruby a lot, I believed this line that the Ruby
> community fed itself (and apparently Python feeds itself as well):
> Ruby/Python has to be interpreted because it's too dynamic.
I don't think you can reasonably compile Python just by what we'd
usually call macro expansion. You need fancier compiler techniques.
> > Python is extremely dynamic, even more so than Lisp.
> > That's why compiling Python is hard, not because it
> > doesn't have macros.
>
> Uh huh. "More so than Lisp"? Just making stuff up now?
Python is more dynamic than Lisp.
> Despite its dynamism, Lisp is quite compilable.
Yes. Lisp is dynamic, but less so than Python. And not by
coincidence, Lisp is more compilable than Python.
> For example, I can redefine classes, functions, macros, etc. at
> runtime and compiled code referring to the old code will still work.
> You are conflating dynamism with interpretedness, and that's
> incorrect.
If you say foo.frob() in Python, that's supposed to look up 'frob' in
a dictionary hanging off of foo. You can modify the contents of this
dictionary any time you want. The Lisp equivalent would be some
generic function (frob foo) that you define with CLOS in the usual
way, but then there's some hashtable that lets you redefine frob at
any time by modifying it (i.e. just a normal hashtable that you poke
with setf, no special notification to the class system). This can
happen anywhere in the code, in another thread, or whatever. You can
even replace that hashtable with another hashtable. You can also
insert (at any time) a __getattr__ method into foo's class, that is a
user-supplied function that replaces the hash lookup.
This stuff is all quite hard to optimize the way CLOS can be
optimized. I'd like to hope Python tones down these aspects of its
dynamism as it continues to evolve.
Paul Rubin <·············@NOSPAM.invalid> writes:
> If you say foo.frob() in Python, that's supposed to look up 'frob' in
> a dictionary hanging off of foo. You can modify the contents of this
> dictionary any time you want.
You can redefine CLOS methods at run time any time you like, so this
doesn't make Python more /dynamic/ than CLOS. Maybe you should replace
"more dynamic" with "less managable", if that's what you mean?
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> > If you say foo.frob() in Python, that's supposed to look up 'frob' in
> > a dictionary hanging off of foo. You can modify the contents of this
> > dictionary any time you want.
>
> You can redefine CLOS methods at run time any time you like, so this
> doesn't make Python more /dynamic/ than CLOS. Maybe you should replace
> "more dynamic" with "less managable", if that's what you mean?
Can you redefine CLOS methods without calling CLOS functions that tell
the object system what to expect (so it can do things like update the
MRO cache)? I.e. can you redefine them by poking some random
dictionary? You can in Python. I don't claim that's a good thing.
Paul Rubin <·············@NOSPAM.invalid> writes:
> Can you redefine CLOS methods without calling CLOS functions that tell
> the object system what to expect (so it can do things like update the
> MRO cache)? I.e. can you redefine them by poking some random
> dictionary? You can in Python. I don't claim that's a good thing.
Just as I said: Less managable, but not more dynamic.
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> > Can you redefine CLOS methods without calling CLOS functions that tell
> > the object system what to expect (so it can do things like update the
> > MRO cache)? I.e. can you redefine them by poking some random
> > dictionary? You can in Python. I don't claim that's a good thing.
>
> Just as I said: Less managable, but not more dynamic.
I'm not getting through to you. Yes, you could create a Python-like
object system in Lisp that's separate from CLOS, but nobody would use
it. It wouldn't matter whether you could compile it efficiently or
not, since nobody would care. What matters is that you can compile
CLOS efficiently.
Python's object system is used in every Python program and it has
those properties and if you try to remove them, you don't have Python
any more. A Python compiler has to deal with that. So compiled
Python code is necessarily going to suffer compared with compiled Lisp
code.
Paul Rubin <·············@NOSPAM.invalid> writes:
> Espen Vestre <·····@vestre.net> writes:
>> > Can you redefine CLOS methods without calling CLOS functions that tell
>> > the object system what to expect (so it can do things like update the
>> > MRO cache)? I.e. can you redefine them by poking some random
>> > dictionary? You can in Python. I don't claim that's a good thing.
>>
>> Just as I said: Less managable, but not more dynamic.
>
> I'm not getting through to you. Yes, you could create a Python-like
> object system in Lisp that's separate from CLOS, but nobody would use
> it ....
I think you are not understanding the point that Espen is trying to make.
He is not suggesting a different object system for Lisp.
Espen is saying that Common Lisp often offers the same dynamic feature as
Python has, such as the ability to redefining a method at runtime. Lisp,
however, forces you to call a CLOS function or use an well defined interface
when redefining a method. You can't just change a value in a hash table.
Does this make Lisp "less dynamic" than Python? Espen would say it's not
less dynamic, but rather that a similar level of dynamism is achieved in
Common Lisp via well defined interfaces. The compiler knows the interfaces,
so it can do a better job optimizing the code.
Robert Brown <······@speakeasy.net> writes:
> Does this make Lisp "less dynamic" than Python? Espen would say it's not
> less dynamic, but rather that a similar level of dynamism is achieved in
> Common Lisp via well defined interfaces. The compiler knows the interfaces,
> so it can do a better job optimizing the code.
I'd say Python is more dynamic in the sense that the Python runtime
system has to actually concern itself about the dynamism all the time
in practice, i.e. on every object method invocation. The Lisp runtime
only has to think about it when the application calls specific
functions in those interfaces. The rest of the time, it can use
various optimizations like compile-time analysis and caching. I do
not consider this contrast to be in Python's favor.
Paul Rubin wrote:
> Robert Brown <······@speakeasy.net> writes:
> > Does this make Lisp "less dynamic" than Python? Espen would say it's not
> > less dynamic, but rather that a similar level of dynamism is achieved in
> > Common Lisp via well defined interfaces. The compiler knows the interfaces,
> > so it can do a better job optimizing the code.
>
> I'd say Python is more dynamic in the sense that the Python runtime
> system has to actually concern itself about the dynamism all the time
> in practice, i.e. on every object method invocation. The Lisp runtime
> only has to think about it when the application calls specific
> functions in those interfaces. The rest of the time, it can use
> various optimizations like compile-time analysis and caching. I do
> not consider this contrast to be in Python's favor.
The main complaint I have myself is that the CPython runtime can't even
deal with static information presumed that it is available. Psyco
indeed can do it but it is a plugin and it is not supported and
understood by the whole core development team but only by Armin Rigo
himself. Instead of making up the CPython runtime for better support of
Psyco and related approaches Armin had to start PyPy ( this happened
more than 3 years ago! ) Now we are in the situation that parts of
Python are also RPython which means that their can be analyzed
statically but we need PyPy to compile them into CPython extensions.
This is really weird.
Paul Rubin <·············@NOSPAM.invalid> writes:
> Robert Brown <······@speakeasy.net> writes:
> > Does this make Lisp "less dynamic" than Python? Espen would say it's not
> > less dynamic, but rather that a similar level of dynamism is achieved in
> > Common Lisp via well defined interfaces. The compiler knows the interfaces,
> > so it can do a better job optimizing the code.
[thank you for clarifying my post, Robert]
> I'd say Python is more dynamic in the sense that the Python runtime
> system has to actually concern itself about the dynamism all the time
> in practice, i.e. on every object method invocation.
Ok, but when you state that language A is more dynamic than language
B, most programmers would interpret that as (or so I guess) "A offers
more dynamism to the programmer than B" - not that it burdens the run
time system implementor with more dynamism...
--
(espen)
Espen Vestre <·····@vestre.net> writes:
> > I'd say Python is more dynamic in the sense that the Python runtime
> > system has to actually concern itself about the dynamism all the time
> > in practice, i.e. on every object method invocation.
>
> Ok, but when you state that language A is more dynamic than language
> B, most programmers would interpret that as (or so I guess) "A offers
> more dynamism to the programmer than B" - not that it burdens the run
> time system implementor with more dynamism...
I'm sorry for any misunderstanding. Maybe I should have said that
Python's dynamism is more pervasive: it can be activated in more
different ways and that creates an extra burden on the runtime system.
Remember that the context was whether Python could be compiled to
efficient machine code. So I referred to "more dynamism" from the
implementers' point of view--the runtime has to pay attention to more
things and spend more resources dealing with the dynamism.
I think the Lispies see "more dynamism" as a good thing and are
therefore defending their language from suggestions that Python is
even more dynamic than Lisp. I mean "dynamic" in a less good way--
there is a huge amount of state scattered all through a running Python
program, that the application can modify at random and whose contents
the working of really fundamental operations like method invocation.
It's just a big mess and I'd get rid of it if I could. It reminds me
of like old time Lisp programs that pervasively used property lists on
symbols to attach random attributes to the symbol, instead of using
something like defstruct to make multi-field data values.
How about if I say Python and Lisp are both dynamic, but Lisp does a
better job of keeping its dynamism's potentially chaotic effects
contained. Does that help?
Paul Rubin <·············@NOSPAM.invalid> writes:
> I think the Lispies see "more dynamism" as a good thing
Sure...
> I mean "dynamic" in a less good way-- there is a huge amount of
> state scattered all through a running Python program, that the
> application can modify at random and whose contents the working of
> really fundamental operations like method invocation.
That's what I call /kludgy/, not /dynamic/ ;-)
> How about if I say Python and Lisp are both dynamic, but Lisp does a
> better job of keeping its dynamism's potentially chaotic effects
> contained. Does that help?
Yes, that's fine with me!
--
(espen)
Espen Vestre wrote:
> Paul Rubin <·············@NOSPAM.invalid> writes:
> > there is a huge amount of
> > state scattered all through a running Python program, that the
> > application can modify at random
>
> That's what I call /kludgy/, not /dynamic/ ;-)
I think "kludgy" is a bit unfair, since this is a
result of doing things in a very simple and uniform
way -- rather a Lispy concept, I would have thought. :-)
--
Greg
Paul Rubin wrote:
> I think the Lispies see "more dynamism" as a good thing and are
> therefore defending their language from suggestions that Python is
> even more dynamic than Lisp. I mean "dynamic" in a less good way--
Indeed, Python has sometimes been described
as "pathologically dynamic". All that dynamism
is handy sometimes, but it does get in the
way of improving efficiency.
Often discussions take place on python-dev
about ways to selectively limit the dynamism
to make some optimisation possible.
--
Greg
jayessay <······@foo.com> writes:
> > If you say foo.frob() in Python, that's supposed to look up 'frob' in
> > a dictionary hanging off of foo. You can modify the contents of this
> > dictionary any time you want.
>
> Unless I'm missing something this looks absolutely dead easy to
> implement in Lisp and with a very little macrology you would have the
> syntax as well. I'm not sure how this makes one or the other "more
> dynamic".
I'm talking about the way Lisp is actually used, not what contortions
one can do with macros. The way one does OOP in Lisp is with CLOS.
Paul Rubin <·············@NOSPAM.invalid> writes:
> jayessay <······@foo.com> writes:
> > > If you say foo.frob() in Python, that's supposed to look up 'frob' in
> > > a dictionary hanging off of foo. You can modify the contents of this
> > > dictionary any time you want.
> >
> > Unless I'm missing something this looks absolutely dead easy to
> > implement in Lisp and with a very little macrology you would have the
> > syntax as well. I'm not sure how this makes one or the other "more
> > dynamic".
>
> I'm talking about the way Lisp is actually used, not what contortions
> one can do with macros.
But this _is_ the way it's actually used. I think this is a key point
that many people here don't understand. _If_ the construct you
mention, really had any underlying use/goodness, for someone who
wanted it, they would simply add it with the nice syntax and all.
Also note that most of this would not involve macros - that would only
be a final step to add the "nice" syntax.
This isn't any sort of "contortion", it's simply how things are
actually done. And indeed, in this case, the macrology would be
pretty straight forward and simple as opposed to "contorted" (which
I'm sure there are cases of).
> The way one does OOP in Lisp is with CLOS.
I'm not sure your construct has anything necessarily to do with "OOP"
(which is a pretty nebulus concept). But even if it did, what you can
really say is that CLOS is the preferred/standard way to do it in CL.
If you have other requirements that don't quite fit, you don't try
pounding them into the round hole. There have been a few people here
in the last few months who have wanted to do just that. Of course you
can get quite a distance in this respect via the MOP and may not need
or want to do more.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Bill Atkins wrote:
> Despite its dynamism, Lisp is quite compilable. For example, I can
> redefine classes, functions, macros, etc. at runtime and compiled code
> referring to the old code will still work. You are conflating
> dynamism with interpretedness, and that's incorrect.
There is clearly a trade-off. Look at my ray tracer benchmark, for example:
http://www.ffconsultancy.com/free/ray_tracer/languages.html
The static languages are significantly faster.
I think Python can hope to be as fast as SBCL-compiled Lisp, after a huge
amount of work on Python compilers, but it will never be as fast as the
compiled static languages.
On that ray tracer, Python might be able to approach OCaml's brevity but it
will be orders of magnitude slower as long as it is interpreted. Compiling
Python to a decent bytecode might give better performance, but OCaml
bytecode is 30x slower than native code on this benchmark.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
[...]
> I think Python can hope to be as fast as SBCL-compiled Lisp, after a huge
> amount of work on Python compilers, but it will never be as fast as the
> compiled static languages.
How does SBCL compare to the static languages with fast-math turned
off?
Cheers,
Pillsy
Jon Harrop schrieb:
> Bill Atkins wrote:
>> Despite its dynamism, Lisp is quite compilable. For example, I can
>> redefine classes, functions, macros, etc. at runtime and compiled code
>> referring to the old code will still work. You are conflating
>> dynamism with interpretedness, and that's incorrect.
>
> There is clearly a trade-off. Look at my ray tracer benchmark, for example:
>
> http://www.ffconsultancy.com/free/ray_tracer/languages.html
>
> The static languages are significantly faster.
I suppose you wanted to say "statically typed languages..". Otherwise I
would like to know what a static language is.
> I think Python can hope to be as fast as SBCL-compiled Lisp, after a huge
> amount of work on Python compilers, but it will never be as fast as the
> compiled static languages.
I don't think what you wrote will be true.
The "never" is the problem I see.
When in 30-50 years computer programs will be thousands of times more
intelligent than humans are, they can take programs written/spoken in
natural language and make more efficient code out of it than any human
could do - within 0.1 seconds.
So in the end all programming languages will allow to make programs that
are equal in speed. Programming languages will probably all natural
languages.
Not Python, ocaml and not Lisp.
Andr�
--
André Thieme wrote:
> Jon Harrop schrieb:
> > Bill Atkins wrote:
> >> Despite its dynamism, Lisp is quite compilable. For example, I can
> >> redefine classes, functions, macros, etc. at runtime and compiled code
> >> referring to the old code will still work. You are conflating
> >> dynamism with interpretedness, and that's incorrect.
> >
> > There is clearly a trade-off. Look at my ray tracer benchmark, for example:
> >
> > http://www.ffconsultancy.com/free/ray_tracer/languages.html
> >
> > The static languages are significantly faster.
>
> I suppose you wanted to say "statically typed languages..". Otherwise I
> would like to know what a static language is.
>
>
> > I think Python can hope to be as fast as SBCL-compiled Lisp, after a huge
> > amount of work on Python compilers, but it will never be as fast as the
> > compiled static languages.
>
> I don't think what you wrote will be true.
> The "never" is the problem I see.
> When in 30-50 years computer programs will be thousands of times more
> intelligent than humans are, they can take programs written/spoken in
> natural language and make more efficient code out of it than any human
> could do - within 0.1 seconds.
> So in the end all programming languages will allow to make programs that
> are equal in speed. Programming languages will probably all natural
> languages.
Ugh, have you ever tried writing down how program works in a natural
language, or even a specification?
For the above to work what the human describes to the computer program
would have to include enough information for that program to generate
code correctly. That would mean that a spec would need to be written
defining every part of what the code must do. My experience is that
specs written in English are not precise. A computer program could not
guess the bits in-between the spec. Some things could be accurately
guessed, but not many - and how is the program to know if the guesses
are correct?
What I think is more likely is that in the future programming languages
will become increasingly high-level. Eventually a language will be
created that is so high level it encompasses the functions of natural
languages, amongst other things.
There is also the possibility of using systems that are slightly
imprecise, but interrogate the user/programmer for specifics when they
need them.
Rob Thorpe schrieb:
> Andr� Thieme wrote:
>> Jon Harrop schrieb:
>>> Bill Atkins wrote:
>>>> Despite its dynamism, Lisp is quite compilable. For example, I can
>>>> redefine classes, functions, macros, etc. at runtime and compiled code
>>>> referring to the old code will still work. You are conflating
>>>> dynamism with interpretedness, and that's incorrect.
>>> There is clearly a trade-off. Look at my ray tracer benchmark, for example:
>>>
>>> http://www.ffconsultancy.com/free/ray_tracer/languages.html
>>>
>>> The static languages are significantly faster.
>> I suppose you wanted to say "statically typed languages..". Otherwise I
>> would like to know what a static language is.
>>
>>
>>> I think Python can hope to be as fast as SBCL-compiled Lisp, after a huge
>>> amount of work on Python compilers, but it will never be as fast as the
>>> compiled static languages.
>> I don't think what you wrote will be true.
>> The "never" is the problem I see.
>> When in 30-50 years computer programs will be thousands of times more
>> intelligent than humans are, they can take programs written/spoken in
>> natural language and make more efficient code out of it than any human
>> could do - within 0.1 seconds.
>> So in the end all programming languages will allow to make programs that
>> are equal in speed. Programming languages will probably all natural
>> languages.
>
> Ugh, have you ever tried writing down how program works in a natural
> language, or even a specification?
>
> For the above to work what the human describes to the computer program
> would have to include enough information for that program to generate
> code correctly. That would mean that a spec would need to be written
> defining every part of what the code must do. My experience is that
> specs written in English are not precise. A computer program could not
> guess the bits in-between the spec. Some things could be accurately
> guessed, but not many - and how is the program to know if the guesses
> are correct?
>
> What I think is more likely is that in the future programming languages
> will become increasingly high-level. Eventually a language will be
> created that is so high level it encompasses the functions of natural
> languages, amongst other things.
>
> There is also the possibility of using systems that are slightly
> imprecise, but interrogate the user/programmer for specifics when they
> need them.
Nah, you are thinking about it without seeing how the world would be if
computers were more intelligent than humans.
They would know everything you know, and more. They would like to go to
the cinema and they would love to talk about movies.
If you want to see Terminator 5 with a 38 year old Arnold Schwarzenegger
you would say something like:
"Computer, generate a movie: Terminator 5. Find a good story. Arnie
should be around 38 years old. Timeline: between after part 2 but before
part 3. Lots of action, not too much humor, very brutal."
As the computer knows all Terminator movies and also knows your taste it
could generate a movie which you would like. Later you could change some
details if that were important.
Programs would be "written" in a similar way:
"Hey, I need a new usenet client. Make it mind based, so that I can read
and write postings directly from my brain."
When you ended your sentence the program would be ready.
Andr�
--
André Thieme wrote:
> Rob Thorpe schrieb:
> > André Thieme wrote:
> >> Jon Harrop schrieb:
> >>> Bill Atkins wrote:
<snip>
> > There is also the possibility of using systems that are slightly
> > imprecise, but interrogate the user/programmer for specifics when they
> > need them.
>
> Nah, you are thinking about it without seeing how the world would be if
> computers were more intelligent than humans.
How is that supposed to happen in 50 years? Given the progress of AI
research in the last 50 years I doubt it will happen in the next 500.
Computer power will increase of-course, but this has little to do with
the problem of creating intelligent programs.
Rob Thorpe schrieb:
> Andr� Thieme wrote:
>> Rob Thorpe schrieb:
>>> Andr� Thieme wrote:
>>>> Jon Harrop schrieb:
>>>>> Bill Atkins wrote:
> <snip>
>>> There is also the possibility of using systems that are slightly
>>> imprecise, but interrogate the user/programmer for specifics when they
>>> need them.
>> Nah, you are thinking about it without seeing how the world would be if
>> computers were more intelligent than humans.
>
> How is that supposed to happen in 50 years? Given the progress of AI
> research in the last 50 years I doubt it will happen in the next 500.
This is what Ray Kurzweil calls
"The Intuitive Linear View versus the Historical Exponential View".
Progress is coming exponetially, it is not linear.
Depending on what function underlies the technology an exponential graph
looks like a straight line on some parts, and therewith linear.
You will need to read
http://www.kurzweilai.net/meme/frame.html?main=/articles/art0134.html
to understand why in ca. 30-50 years humans will no longer be the most
intelligent life form on this planet.
For reading and understanding that essay you will get $40 trillion.
> Computer power will increase of-course, but this has little to do with
> the problem of creating intelligent programs.
That is correct. In ca. 5-7 years the best supercomputer on earth will
already have the calculation capabilies like the human brain. Of course
the software is missing for real AI. How we can get the software is
described in that article from Kurzweil.
Anyway: we don't need such a strong intelligence to make Lisp compilers
generate faster code. It will happen gradually. Over the coming years
Lisp compilers will generate better and better code. Also Python will
get faster.
Andr�
--
André Thieme wrote:
> Rob Thorpe schrieb:
> > André Thieme wrote:
> >> Rob Thorpe schrieb:
> >>> André Thieme wrote:
> >>>> Jon Harrop schrieb:
> >>>>> Bill Atkins wrote:
> > <snip>
> >>> There is also the possibility of using systems that are slightly
> >>> imprecise, but interrogate the user/programmer for specifics when they
> >>> need them.
> >> Nah, you are thinking about it without seeing how the world would be if
> >> computers were more intelligent than humans.
> >
> > How is that supposed to happen in 50 years? Given the progress of AI
> > research in the last 50 years I doubt it will happen in the next 500.
>
> This is what Ray Kurzweil calls
> "The Intuitive Linear View versus the Historical Exponential View".
Oh dear, Ray Kurzweil. I prefer Vernor Vinge's science fiction myself.
I've been eading James Tiptree Jr recently though, very much
recommended. Both of those other writers have much better plots than
Kurzweil.
There are many problems with what Kurzweil says:-
1. Exponentials. A small section of an exponential still looks like an
exponential, only a very small section looks linear.
2. He does not back up his argument with facts, just vague views of
history.
3. He quotes Moores Law, which is really something quite exceptional.
Other areas of engineering do not progress so fast. Programmers are
still talking about a 20year old language that's still better than most
of the ones people are using today. In RF engineering, where I work
these days, progress is much slower.
4. His arguments concern the drivers of technology, assuming that
anything is possible, which is not the case. Once the drivers hit
problems with what is possible they must slow down. Similarly, what
happens when demand slows down? Personally I can't find anything
useful to do with a fast computer these days, from my own point-of-view
fast computers are only for playing games.
In article <·······················@l12g2000cwl.googlegroups.com>,
"Rob Thorpe" <·······@realworldtech.com> wrote:
> Andr� Thieme wrote:
> > This is what Ray Kurzweil calls
> > "The Intuitive Linear View versus the Historical Exponential View".
>
> Oh dear, Ray Kurzweil. I prefer Vernor Vinge's science fiction myself.
> I've been eading James Tiptree Jr recently though, very much
> recommended. Both of those other writers have much better plots than
> Kurzweil.
I think Vinge's singularity futurism lost me when I took a look at
the evidence he was using to back his claims up, and saw little
related to the sociology or economics of technology.
> There are many problems with what Kurzweil says:-
> 1. Exponentials. A small section of an exponential still looks like an
> exponential, only a very small section looks linear.
> ...
> 4. His arguments concern the drivers of technology, assuming that
> anything is possible, which is not the case. Once the drivers hit
> problems with what is possible they must slow down. Similarly, what
> happens when demand slows down? Personally I can't find anything
> useful to do with a fast computer these days, from my own point-of-view
> fast computers are only for playing games.
I share your skepticism.
In most systems, exponential curves get squished as other feedback
mechanisms start kicking in. In biology, exponential population
curves are limited by the mathematical principle that colonies can't
expand their access to resources as fast as their numbers. In
astronomy, electromagnetism and gravity reach equilibrium points
except in extreme circumstances. In transportation, early large
increases in power and efficiency were slowed by concerns about
safety and the relative abundance of petroleum.
As much as we like to talk about "disruptive technologies,"
technology is fundamentally embedded in human culture and economics.
Potentially disruptive technologies are murdered in the cradle, or
carefully groomed and tamed to support existing power relationships.
I'll place my nickel bet on Gibson's quasi-Marxist vision of a
future dominated by corporate feudalism against Kurzweil's utopian
dreams of intelligent machines breaking free from the weight of
plodding socioeconomic history.
Rob Thorpe schrieb:
> Andr� Thieme wrote:
>> Rob Thorpe schrieb:
>>> How is that supposed to happen in 50 years? Given the progress of AI
>>> research in the last 50 years I doubt it will happen in the next 500.
>> This is what Ray Kurzweil calls
>> "The Intuitive Linear View versus the Historical Exponential View".
>
> Oh dear, Ray Kurzweil. I prefer Vernor Vinge's science fiction myself.
> I've been eading James Tiptree Jr recently though, very much
> recommended. Both of those other writers have much better plots than
> Kurzweil.
Why are they better?
> There are many problems with what Kurzweil says:-
> 1. Exponentials. A small section of an exponential still looks like an
> exponential, only a very small section looks linear.
Is that true for all exponentials?
Take (expt x -5).
Looks very linear to me: http://www.purplemath.com/modules/logs/grphex15.gif
> 2. He does not back up his argument with facts, just vague views of
> history.
Can you back up this statement with facts?
What about his analyses of his "Kurzweil law" for the last 100 years?
It is correct.
> 3. He quotes Moores Law, which is really something quite exceptional.
And he worked out himself some more info, and some proofs you were
looking for.
Let me quote his website:
--------------------------------
If we plot the speed (in instructions per second) per $1000 (in constant
dollars) of 49 famous calculators and computers spanning the entire
twentieth century, we note some interesting observations.
Moore's Law Was Not the First, but the Fifth Paradigm To Provide
Exponential Growth of Computing
Each time one paradigm runs out of steam, another picks up the pace.
It is important to note that Moore's Law of Integrated Circuits was not
the first, but the fifth paradigm to provide accelerating
price-performance. Computing devices have been consistently multiplying
in power (per unit of time) from the mechanical calculating devices used
in the 1890 U.S. Census, to Turing's relay-based "Robinson" machine that
cracked the Nazi enigma code, to the CBS vacuum tube computer that
predicted the election of Eisenhower, to the transistor-based machines
used in the first space launches, to the integrated-circuit-based
personal computer which I used to dictate (and automatically transcribe)
this essay.
But I noticed something else surprising. When I plotted the 49 machines
on an exponential graph (where a straight line means exponential
growth), I didn't get a straight line. What I got was another
exponential curve. In other words, there's exponential growth in the
rate of exponential growth. Computer speed (per unit cost) doubled every
three years between 1910 and 1950, doubled every two years between 1950
and 1966, and is now doubling every year.
[...]
Thus the (double) exponential growth of computing is broader than
Moore's Law, which refers to only one of its paradigms.
--------------------------------
Here you have the proof of what happened.
Chip manufacturers are working on 3d chips, meta meterials and science
is making progress with quantum computers.
> Other areas of engineering do not progress so fast. Programmers are
> still talking about a 20year old language that's still better than most
> of the ones people are using today. In RF engineering, where I work
> these days, progress is much slower.
Not everything is developing exponetially.
But several areas of knowledge that become information technologies
undergo the same exponential groth as computers themself.
See dna sequencing.
Quote:
"For example, when the human genome scan started fourteen years ago,
critics pointed out that given the speed with which the genome could
then be scanned, it would take thousands of years to finish the project.
Yet the fifteen year project was nonetheless completed slightly ahead of
schedule."
Today the complete process could be done within a few months.
> 4. His arguments concern the drivers of technology, assuming that
> anything is possible, which is not the case. Once the drivers hit
> problems with what is possible they must slow down. Similarly, what
> happens when demand slows down? Personally I can't find anything
> useful to do with a fast computer these days, from my own point-of-view
> fast computers are only for playing games.
He also talks about the slow downs.
If you personally can't find useful things that you can do with computers
it doesn't mean that others see it in a same way.
Jon Harrop for example seems to want faster computers. He is waiting
for systems that allow Stalin to compile a program in less than one
second.
Google also would like to have computers that are some trillion times
faster than todays.
I am looking forward to 2010/11, when Intel will ship its 80 core cpu
for webservers.
Andr�
--
André Thieme wrote:
> Rob Thorpe schrieb:
> > André Thieme wrote:
> >> Rob Thorpe schrieb:
>
> >>> How is that supposed to happen in 50 years? Given the progress of AI
> >>> research in the last 50 years I doubt it will happen in the next 500.
> >> This is what Ray Kurzweil calls
> >> "The Intuitive Linear View versus the Historical Exponential View".
> >
> > Oh dear, Ray Kurzweil. I prefer Vernor Vinge's science fiction myself.
> > I've been eading James Tiptree Jr recently though, very much
> > recommended. Both of those other writers have much better plots than
> > Kurzweil.
>
> Why are they better?
They admit what they're doing is fiction. It allows for much better
plotting.
They also spice up their stories with characters, Vinge isn't too good
at that though.
> > There are many problems with what Kurzweil says:-
> > 1. Exponentials. A small section of an exponential still looks like an
> > exponential, only a very small section looks linear.
>
> Is that true for all exponentials?
> Take (expt x -5).
> Looks very linear to me: http://www.purplemath.com/modules/logs/grphex15.gif
Fair point.
> > 2. He does not back up his argument with facts, just vague views of
> > history.
>
> Can you back up this statement with facts?
Well, some yes. The burden of proof should not fall on me though, I'm
simply claiming that technological progress won't result in a
"singularity". This is not a revolutionary idea, the burden of proof
should lie on those claiming the revolutionary idea to be correct.
> What about his analyses of his "Kurzweil law" for the last 100 years?
> It is correct.
Regarding information technology, I think he has a point. Raw
computational power has increased hugely over time. This has not led
to a great increase in the usefulness of that computational power
though. Is your computer really more useful to you than it was 6 years
ago, mine isn't.
> > 3. He quotes Moores Law, which is really something quite exceptional.
>
> And he worked out himself some more info, and some proofs you were
> looking for.
I know, I've read it.
I particularly like this last bit:-
> now doubling every year.
My response to that would be "really?" Anyone who's bought a computer
recently will know that, getting something significantly faster than 1
year ago is becoming increasingly difficult. "Dual core" hardly counts
as faster.
> Thus the (double) exponential growth of computing is broader than
> Moore's Law, which refers to only one of its paradigms.
> --------------------------------
>
> Here you have the proof of what happened.
> Chip manufacturers are working on 3d chips, meta meterials and science
> is making progress with quantum computers.
>
>
> > Other areas of engineering do not progress so fast. Programmers are
> > still talking about a 20year old language that's still better than most
> > of the ones people are using today. In RF engineering, where I work
> > these days, progress is much slower.
>
> Not everything is developing exponetially.
> But several areas of knowledge that become information technologies
> undergo the same exponential groth as computers themself.
> See dna sequencing.
Sure.
> Quote:
> "For example, when the human genome scan started fourteen years ago,
> critics pointed out that given the speed with which the genome could
> then be scanned, it would take thousands of years to finish the project.
> Yet the fifteen year project was nonetheless completed slightly ahead of
> schedule."
> Today the complete process could be done within a few months.
Yes, but this is just a relatively simple computational task. These
things are not really that hard. If the need to do it had existed in
1960 then someone with the resources could probably have done it even
then, by using special purpose computers.
> > 4. His arguments concern the drivers of technology, assuming that
> > anything is possible, which is not the case. Once the drivers hit
> > problems with what is possible they must slow down. Similarly, what
> > happens when demand slows down? Personally I can't find anything
> > useful to do with a fast computer these days, from my own point-of-view
> > fast computers are only for playing games.
>
> He also talks about the slow downs.
> If you personally can't find useful things that you can do with computers
> it doesn't mean that others see it in a same way.
> Jon Harrop for example seems to want faster computers. He is waiting
> for systems that allow Stalin to compile a program in less than one
> second.
> Google also would like to have computers that are some trillion times
> faster than todays.
Yes. But it is the mass-market that makes other things possible.
Today people aren't as worried about the compuational power of their
computers as they were once. They're more concerned about style and
usability.
This is something people forget. Kurzweil talks about the huge
increase in bandwidth of wireless communications networks. He talks as
though its created through better technology. Really this only has a
small part to play, systems with similar capabilities to todays GSM
networks could have been built far earlier than they were. The real
driver for change was financial, the network owners managed to get a
large user base.
> I am looking forward to 2010/11, when Intel will ship its 80 core cpu
> for webservers.
Each to there own. I've no idea what I would do with an 80 core cpu,
probably turn-off 78 of the cores and save electricity.
Rob Thorpe schrieb:
> Andr� Thieme wrote:
>>> 2. He does not back up his argument with facts, just vague views of
>>> history.
>> Can you back up this statement with facts?
>
> Well, some yes. The burden of proof should not fall on me though, I'm
> simply claiming that technological progress won't result in a
> "singularity". This is not a revolutionary idea, the burden of proof
> should lie on those claiming the revolutionary idea to be correct.
I think he did a good job with his several books, talks and hundreds of
pages of text on his website.
>> What about his analyses of his "Kurzweil law" for the last 100 years?
>> It is correct.
>
> Regarding information technology, I think he has a point. Raw
> computational power has increased hugely over time. This has not led
> to a great increase in the usefulness of that computational power
> though. Is your computer really more useful to you than it was 6 years
> ago, mine isn't.
My computer is more useful. Perhaps if you would get back a P3 733 with
256 MB Ram and 20 GB HD you would change your opinion.
I personally like to have a faster computer. Even small savings are
worth something, for example the reduced render time of web pages.
If you think otherwise you shouldn't use macros in Lisp which often do
save you to type #'(lambda () ...) and not more.
>>> 3. He quotes Moores Law, which is really something quite exceptional.
>> And he worked out himself some more info, and some proofs you were
>> looking for.
>
> I know, I've read it.
>
> I particularly like this last bit:-
>> now doubling every year.
>
> My response to that would be "really?" Anyone who's bought a computer
> recently will know that, getting something significantly faster than 1
> year ago is becoming increasingly difficult. "Dual core" hardly counts
> as faster.
It is tricky. He is not saying that your computer doubles its speed each
year. What he says is that ca. every 12 months the number of calculations
per timeunit that can be bought for 1000$ are doubling.
And that I calculated several times over the past years and it seemed ca.
correct to me.
For me something happened about which Kurzweil is not talking but which
some people think he is:
Last year I bought an AMD 64 3200+ for 156 Euro. This year in august the
price was around 73 Euro (now it costs 55,84 Euro).
Btw: for task that can be parallelized well the speed doubles with
2x amount of cores.
>> Quote:
>> "For example, when the human genome scan started fourteen years ago,
>> critics pointed out that given the speed with which the genome could
>> then be scanned, it would take thousands of years to finish the project.
>> Yet the fifteen year project was nonetheless completed slightly ahead of
>> schedule."
>> Today the complete process could be done within a few months.
>
> Yes, but this is just a relatively simple computational task. These
> things are not really that hard. If the need to do it had existed in
> 1960 then someone with the resources could probably have done it even
> then, by using special purpose computers.
Maybe. But perhaps it would have cost some billion dollars.
With computers as big as New York it might have been possible ;)
Let's take a look at
http://www.kurzweilai.net/articles/images/chart04.jpg
In the 60ies the price for one base pair must have been around 10k.
2002 it cost 1 Cent and today the prices are probably even lower.
And history luckily begins to repeat, this time with medicine.
Science begins to discover medicine as an information technology.
We begin to understand more about it. Until today medicine was more or
less blind guessing. If we can continue to get more knowledge we can
begin to calculate drugs. Much less tests with animals will be needed
in the coming years and drugs can be found much faster.
Another point of critic: after something happened it is easy to say
"Yes, but ...".
When in 2030 computers are as fast as Kurzweil predicted all critics in
this thread will say "Of course, I always knew it."
>>> 4. His arguments concern the drivers of technology, assuming that
>>> anything is possible, which is not the case. Once the drivers hit
>>> problems with what is possible they must slow down. Similarly, what
>>> happens when demand slows down? Personally I can't find anything
>>> useful to do with a fast computer these days, from my own point-of-view
>>> fast computers are only for playing games.
>> He also talks about the slow downs.
>> If you personally can't find useful things that you can do with computers
>> it doesn't mean that others see it in a same way.
>> Jon Harrop for example seems to want faster computers. He is waiting
>> for systems that allow Stalin to compile a program in less than one
>> second.
>> Google also would like to have computers that are some trillion times
>> faster than todays.
>
> Yes. But it is the mass-market that makes other things possible.
> Today people aren't as worried about the compuational power of their
> computers as they were once. They're more concerned about style and
> usability.
I agree: speed is not a big priority anymore (besides those of us who
are forced to work with the Scheme Stalin compiler).
I for example invested in a silent computer system.
> This is something people forget. Kurzweil talks about the huge
> increase in bandwidth of wireless communications networks. He talks as
> though its created through better technology. Really this only has a
> small part to play, systems with similar capabilities to todays GSM
> networks could have been built far earlier than they were. The real
> driver for change was financial, the network owners managed to get a
> large user base.
But what you say is true for any technology. Now as everything we have
already is developed it is easy to say "It could have been done earlier."
I don't buy that.
Of course the market plays a big role. We can't sell things that are
percieved as too expensive. Anyway, check the number of Patents that are
made, about success in science, nanotechnology, IT, medicin, etc.
When we look at the bigger picture there is something happening.
And it is not going to advance with the speed it is happening today.
It is getting faster. At least this is what happened in the past 10k
years. Saying that the paradigm shift rate will stop to increase will
need strong arguments.
>> I am looking forward to 2010/11, when Intel will ship its 80 core cpu
>> for webservers.
>
> Each to there own. I've no idea what I would do with an 80 core cpu,
> probably turn-off 78 of the cores and save electricity.
Absolute legitimate. Target of this chip is not the private person but
the industry.
The funny thing is: people don't "need" faster computers or video cards
as long the hardware is too expensive. If the price falls then people
suddenly begin to argue: "Oh yes, I really need this new hardware. I
just can't continue without it."
When you can buy a 80 core cpu for 60$ you might become interested as
well.
Andr�
--
André Thieme wrote:
> Rob Thorpe schrieb:
> > André Thieme wrote:
> >>> 2. He does not back up his argument with facts, just vague views of
> >>> history.
> >> Can you back up this statement with facts?
> >
> > Well, some yes. The burden of proof should not fall on me though, I'm
> > simply claiming that technological progress won't result in a
> > "singularity". This is not a revolutionary idea, the burden of proof
> > should lie on those claiming the revolutionary idea to be correct.
>
> I think he did a good job with his several books, talks and hundreds of
> pages of text on his website.
I don't. He leans of specific examples from information processing
which are not analogous to the situation in other fields.
> >> What about his analyses of his "Kurzweil law" for the last 100 years?
> >> It is correct.
> >
> > Regarding information technology, I think he has a point. Raw
> > computational power has increased hugely over time. This has not led
> > to a great increase in the usefulness of that computational power
> > though. Is your computer really more useful to you than it was 6 years
> > ago, mine isn't.
>
> My computer is more useful. Perhaps if you would get back a P3 733 with
> 256 MB Ram and 20 GB HD
Actually my computer is a Duron 1400 with 256MB ram and a 20GB hard
disk.
> you would change your opinion.
> I personally like to have a faster computer. Even small savings are
> worth something, for example the reduced render time of web pages.
I find that is down to the speed of the internet connection. It didn't
improve
last time I upgraded my PC.
> If you think otherwise you shouldn't use macros in Lisp which often do
> save you to type #'(lambda () ...) and not more.
Yes. But the improvements are different, they are accumulative and
help the important and time-consuming task of maintaining code.
> >>> 3. He quotes Moores Law, which is really something quite exceptional.
> >> And he worked out himself some more info, and some proofs you were
> >> looking for.
> >
> > I know, I've read it.
> >
> > I particularly like this last bit:-
> >> now doubling every year.
> >
> > My response to that would be "really?" Anyone who's bought a computer
> > recently will know that, getting something significantly faster than 1
> > year ago is becoming increasingly difficult. "Dual core" hardly counts
> > as faster.
>
> It is tricky. He is not saying that your computer doubles its speed each
> year. What he says is that ca. every 12 months the number of calculations
> per timeunit that can be bought for 1000$ are doubling.
> And that I calculated several times over the past years and it seemed ca.
> correct to me.
But is it relevant. Compuational power by itself is only of use to a
very narrow field of science. That where 1) computation is important
2) programs can easily be rewritten to take into account new computer
technology.
I work in RF and electromagnetics, you would have thought in that area
the increase in the raw cost of computation would be very important.
Surprisingly it isn't, what is more important is practical performance
of real code. The people who sell electromagnetics simulators for
example have not yet optimized them to work well with
multiple-processors, even though their customers have been using
multiple processors for years.
> For me something happened about which Kurzweil is not talking but which
> some people think he is:
> Last year I bought an AMD 64 3200+ for 156 Euro. This year in august the
> price was around 73 Euro (now it costs 55,84 Euro).
>
I'd agree that is important to people buying PCs.
> Btw: for task that can be parallelized well the speed doubles with
> 2x amount of cores.
Not for many though.
> >> Quote:
> >> "For example, when the human genome scan started fourteen years ago,
> >> critics pointed out that given the speed with which the genome could
> >> then be scanned, it would take thousands of years to finish the project.
> >> Yet the fifteen year project was nonetheless completed slightly ahead of
> >> schedule."
> >> Today the complete process could be done within a few months.
> >
> > Yes, but this is just a relatively simple computational task. These
> > things are not really that hard. If the need to do it had existed in
> > 1960 then someone with the resources could probably have done it even
> > then, by using special purpose computers.
>
> Maybe. But perhaps it would have cost some billion dollars.
> With computers as big as New York it might have been possible ;)
> Let's take a look at
> http://www.kurzweilai.net/articles/images/chart04.jpg
I doubt that. You have to understand the nature of technology a little
more. Technology comes into being when there is a market for it. In
recent times there has been a market for DNA sequencing so great
advances have been made.
If the need had been earlier in the century, and the need had been
great enough then it probably would have happened. As an example, the
Collosus machines used to break the Fish ciphers in WWII were special
purpose computers. Because great effort was put into optimizing for
their exact task it was only in the 90's when general purpose computers
because faster at it.
> In the 60ies the price for one base pair must have been around 10k.
> 2002 it cost 1 Cent and today the prices are probably even lower.
>
> And history luckily begins to repeat, this time with medicine.
> Science begins to discover medicine as an information technology.
> We begin to understand more about it. Until today medicine was more or
> less blind guessing. If we can continue to get more knowledge we can
> begin to calculate drugs. Much less tests with animals will be needed
> in the coming years and drugs can be found much faster.
I've known people who work in this area. I'm afraid to say medicine is
still largely blind guessing. The problem here is that it will take
many decades, probably centuries, of science to understand even how the
processes in a single human cell work. Information science will
continue to advance and aid the work of scientists, but it cannot do
the work of evidence gathering itself. In medicine it is evidence
gathering that is the most difficult step.
> Another point of critic: after something happened it is easy to say
> "Yes, but ...".
> When in 2030 computers are as fast as Kurzweil predicted all critics in
> this thread will say "Of course, I always knew it."
The question is will they be fast in any way that is usable to a normal
programmer.
I expect that in 2030 computers will be of formidable power. Probably
the average machine will have hundreds of processors. But I don't
expect it to be radically more useful to people, and I don't expect the
increase in usefulness to be necessarily driven by the increase in
speed.
In Windows Vista for example there are useful new features, and the
whole system is slower than XP. But these things are not interlinked.
The features are there to persuage people to buy Vista. The slowdown
is there to encourage people to upgrade their machines and buy more
Vista licenses.
> >>> 4. His arguments concern the drivers of technology, assuming that
> >>> anything is possible, which is not the case. Once the drivers hit
> >>> problems with what is possible they must slow down. Similarly, what
> >>> happens when demand slows down? Personally I can't find anything
> >>> useful to do with a fast computer these days, from my own point-of-view
> >>> fast computers are only for playing games.
> >> He also talks about the slow downs.
> >> If you personally can't find useful things that you can do with computers
> >> it doesn't mean that others see it in a same way.
> >> Jon Harrop for example seems to want faster computers. He is waiting
> >> for systems that allow Stalin to compile a program in less than one
> >> second.
> >> Google also would like to have computers that are some trillion times
> >> faster than todays.
> >
> > Yes. But it is the mass-market that makes other things possible.
> > Today people aren't as worried about the compuational power of their
> > computers as they were once. They're more concerned about style and
> > usability.
>
> I agree: speed is not a big priority anymore (besides those of us who
> are forced to work with the Scheme Stalin compiler).
> I for example invested in a silent computer system.
Exactly, and with more people making that choice those who demand speed
will not be able to ride on the coat-tails of everyone else, as they
have for a long time.
> > This is something people forget. Kurzweil talks about the huge
> > increase in bandwidth of wireless communications networks. He talks as
> > though its created through better technology. Really this only has a
> > small part to play, systems with similar capabilities to todays GSM
> > networks could have been built far earlier than they were. The real
> > driver for change was financial, the network owners managed to get a
> > large user base.
>
> But what you say is true for any technology. Now as everything we have
> already is developed it is easy to say "It could have been done earlier."
> I don't buy that.
> Of course the market plays a big role. We can't sell things that are
> percieved as too expensive. Anyway, check the number of Patents that are
> made,
Many more patents have been made recently not because more things have
been invented, but because the USPTO have stopped checking patents.
You can patent anything you like these days, it doesn't have to work or
be useful. Most patents don't and aren't useful.
Besides, citing patents as evidence that technological progress will
increase in the future is false. Patents give revenue the assignee, to
everyone else they are a disadvantage, a tax. Increasing numbers of
patents hold back the use of new technology. I for example am working
on a hardware project currently. I'm doing what I can to avoid
patented technology, even at the cost of time, money and performance.
> about success in science, nanotechnology, IT, medicin, etc.
> When we look at the bigger picture there is something happening.
I don't see science or technology increasing at any faster a rate than
they were 10 years ago. I guess it's a matter of point of view.
> And it is not going to advance with the speed it is happening today.
> It is getting faster. At least this is what happened in the past 10k
> years. Saying that the paradigm shift rate will stop to increase will
> need strong arguments.
No, what needs a strong argument is that information science and
technology is so important to the rest of science/technology.
> >> I am looking forward to 2010/11, when Intel will ship its 80 core cpu
> >> for webservers.
> >
> > Each to there own. I've no idea what I would do with an 80 core cpu,
> > probably turn-off 78 of the cores and save electricity.
>
> Absolute legitimate. Target of this chip is not the private person but
> the industry.
> The funny thing is: people don't "need" faster computers or video cards
> as long the hardware is too expensive. If the price falls then people
> suddenly begin to argue: "Oh yes, I really need this new hardware. I
> just can't continue without it."
Yes. And computer hardware companies convince them of that.
> When you can buy a 80 core cpu for 60$ you might become interested as
> well.
Yep.
I speak only for myself in this message.
Andr� Thieme <······························@justmail.de> writes:
> Rob Thorpe schrieb:
>> There are many problems with what Kurzweil says:-
>> 1. Exponentials. A small section of an exponential still looks like an
>> exponential, only a very small section looks linear.
>
> Is that true for all exponentials?
> Take (expt x -5).
> Looks very linear to me: http://www.purplemath.com/modules/logs/grphex15.gif
(expt x 0) IS linear. ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
HANDLE WITH EXTREME CARE: This product contains minute electrically
charged particles moving at velocities in excess of five hundred
million miles per hour.
Andr� Thieme <······························@justmail.de> writes:
> > There are many problems with what Kurzweil says:-
> > 1. Exponentials. A small section of an exponential still looks like an
> > exponential, only a very small section looks linear.
>
> Is that true for all exponentials?
> Take (expt x -5).
> Looks very linear to me: http://www.purplemath.com/modules/logs/grphex15.gif
To me this function looks _extremely_ nonlinear. Probably you should
refresh your math.
Nicolas
Nicolas Neuss schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>
>>> There are many problems with what Kurzweil says:-
>>> 1. Exponentials. A small section of an exponential still looks like an
>>> exponential, only a very small section looks linear.
>> Is that true for all exponentials?
>> Take (expt x -5).
>> Looks very linear to me: http://www.purplemath.com/modules/logs/grphex15.gif
>
> To me this function looks _extremely_ nonlinear. Probably you should
> refresh your math.
Not the function, but its graphical representation.
The resolution of my eyes is not high enough to see that the line is not
straight. Perhaps you have really good eyes.
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> Not the function, but its graphical representation.
> The resolution of my eyes is not high enough to see that the line is not
> straight. Perhaps you have really good eyes.
Do you know at all what a linear function is? The function on the picture
is obviously not straight, but has a very sharp inflection point near the
origin!
Nicolas
Nicolas Neuss schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>
>> Not the function, but its graphical representation.
>> The resolution of my eyes is not high enough to see that the line is not
>> straight. Perhaps you have really good eyes.
>
> Do you know at all what a linear function is? The function on the picture
> is obviously not straight, but has a very sharp inflection point near the
> origin!
That is correct.
What I am talking about is how my eyes see the graphical representation.
Look at the graph, starting at x >= 3.
It looks like a straight line.
See what Kurzweil said:
------------------------------------
The first technological steps-sharp edges, fire, the wheel--took tens of
thousands of years. For people living in this era, there was little
noticeable technological change in even a thousand years. By 1000 A.D.,
progress was much faster and a paradigm shift required only a century or
two. In the nineteenth century, we saw more technological change than in
the nine centuries preceding it. Then in the first twenty years of the
twentieth century, we saw more advancement than in all of the nineteenth
century. Now, paradigm shifts occur in only a few years time. The World
Wide Web did not exist in anything like its present form just a few
years ago; it didn't exist at all a decade ago.
The paradigm shift rate (i.e., the overall rate of technical progress)
is currently doubling (approximately) every decade; that is, paradigm
shift times are halving every decade (and the rate of acceleration is
itself growing exponentially). So, the technological progress in the
twenty-first century will be equivalent to what would require (in the
linear view) on the order of 200 centuries. In contrast, the twentieth
century saw only about 25 years of progress (again at today's rate of
progress) since we have been speeding up to current rates. So the
twenty-first century will see almost a thousand times greater
technological change than its predecessor.
------------------------------------
and see this graph:
http://www.kurzweilai.net/articles/images/chart01.jpg
For people living from 10.000BC up to 1900 it all looked line a straight
line. Every 1000 years one new discovery.
I am *not* trying to say that exponential functions are linear functions.
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> Nicolas Neuss schrieb:
> > Andr� Thieme <······························@justmail.de> writes:
> >
> >> Not the function, but its graphical representation.
> >> The resolution of my eyes is not high enough to see that the line is not
> >> straight. Perhaps you have really good eyes.
> > Do you know at all what a linear function is? The function on the picture
> > is obviously not straight, but has a very sharp inflection point near the
> > origin!
>
> That is correct.
> What I am talking about is how my eyes see the graphical representation.
> Look at the graph, starting at x >= 3.
> It looks like a straight line.
If you have exponential growth, you will see exponential growth, unless you
choose a very bad graphical representation[*]. This is a simple
mathematical fact which you should better accept.
Nicolas
[*] Of course, you can "see" many curves as "straight" lines near to the
x-axis if you choose an idiotic scaling in y, or "straight" lines escaping
to infinity, if you choose an idiotic scaling in x. And as soon as you see
both, you don't see a linear function.
Andr� Thieme wrote:
> Is that true for all exponentials?
> Take (expt x -5).
y(x) = x^-5 isn't an exponential function.
> Looks very linear to me:
> http://www.purplemath.com/modules/logs/grphex15.gif
Note how the function in the graph enters almost vertically on the left and
leaves almost horizontally on the right.
That looks like a graph of:
y(x) = e^(-5 x)
which is:
(exp (* -5 x))
in Lisp.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Andr� Thieme wrote:
> Progress is coming exponetially, it is not linear.
Given that "progress" can't be quantified, a statement about its
mathematical evolution isn't very useful...
> Depending on what function underlies the technology an exponential graph
> looks like a straight line on some parts, and therewith linear.
We're going to hit problems in physics pretty soon.
> That is correct. In ca. 5-7 years the best supercomputer on earth will
> already have the calculation capabilies like the human brain.
IIRC, Bishop said that the fastest computers could simulate 12 neurons
realistically in real time in 1996. That is over a billion times fewer than
found in the human brain.
> Of course
> the software is missing for real AI. How we can get the software is
> described in that article from Kurzweil.
So even if we can make this unfathomable hardware we can't program it.
> Anyway: we don't need such a strong intelligence to make Lisp compilers
> generate faster code. It will happen gradually. Over the coming years
> Lisp compilers will generate better and better code. Also Python will
> get faster.
That is a very bizarre statement to make. People want to know how fast
language implementations are on a given computer. Saying that Lisp will be
as fast as other languages already are is fruitless.
Perhaps it will be interesting to see what happens when computers are 1,000x
faster and Stalin-compiled Scheme can compile a simple program in under
1sec. I doubt that will cause any radical shift in tool use though.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> André Thieme wrote:
> > Progress is coming exponetially, it is not linear.
>
> Given that "progress" can't be quantified, a statement about its
> mathematical evolution isn't very useful...
Exactly
> > Depending on what function underlies the technology an exponential graph
> > looks like a straight line on some parts, and therewith linear.
>
> We're going to hit problems in physics pretty soon.
Maybe, maybe not. Chips as they are built today certainly are not
following Moores Law anymore, they have been developing more slowly for
~6 years now. New technology, if anyone comes up with any, need not be
so limited. The physical limits on computation are quite far off.
> > That is correct. In ca. 5-7 years the best supercomputer on earth will
> > already have the calculation capabilies like the human brain.
>
> IIRC, Bishop said that the fastest computers could simulate 12 neurons
> realistically in real time in 1996. That is over a billion times fewer than
> found in the human brain.
There is a big difference here. Andre is just comparing computational
power. You are talking about simulating one type of computer using a
much different one.
There is not evidence that things that work like animal neurons are the
only path to intelligent machines. In fact they're so difficult to
deal with they're almost worth ignoring in my opinion. To achieve
intelligent machines you need another path, that is what has not been
forthcoming, and I don't see anyone coming up with one for a long time.
I don't agree with Andre either. Who knows what the computational
ability of the human brain is? How can it be compared to a computer
when they work in very different ways? Any comparisons are just
guesses. They probably depend entirely on what the "intelligent
program" is doing.
> > Anyway: we don't need such a strong intelligence to make Lisp compilers
> > generate faster code. It will happen gradually. Over the coming years
> > Lisp compilers will generate better and better code. Also Python will
> > get faster.
>
> That is a very bizarre statement to make. People want to know how fast
> language implementations are on a given computer. Saying that Lisp will be
> as fast as other languages already are is fruitless.
>
> Perhaps it will be interesting to see what happens when computers are 1,000x
> faster and Stalin-compiled Scheme can compile a simple program in under
> 1sec. I doubt that will cause any radical shift in tool use though.
Maybe it will, maybe it won't. What I'd say though is:-
* The number of programs where performance is a key requirement seems
to be going down.
* There are many further optimizations that can be done of current
tools.
In the OCaml compiler for example there are still ways that the code
generated could be made better. More unboxing could be used for
example, some of the tricks with specialisation from MLton could be
used. In Lisp, many of the same tricks could be used. Also, programs
that make lisp system images into restricted executable programs
(tree-shakers) could be made more sophisticated.
There is not the same amount of potential improvement open to other
languages like C where much of the work has been done.
Rob Thorpe wrote:
>> We're going to hit problems in physics pretty soon.
>
> Maybe, maybe not. Chips as they are built today certainly are not
> following Moores Law anymore, they have been developing more slowly for
> ~6 years now. New technology, if anyone comes up with any, need not be
> so limited. The physical limits on computation are quite far off.
Either way there is no reason to expect exponential growth: That is born of
one generation of computers being used to build the next.
> There is not evidence that things that work like animal neurons are the
> only path to intelligent machines.
But animal brains are the basis for all of our notions of intelligence
because we define the meaning of intelligence.
> I don't agree with Andre either. Who knows what the computational
> ability of the human brain is?
Well, brains can solve a variety of tasks that computers cannot.
> How can it be compared to a computer
> when they work in very different ways?
The same way we compare programming languages. :-)
You set them both tasks. Playing "go", for example...
> Any comparisons are just
> guesses. They probably depend entirely on what the "intelligent
> program" is doing.
Yes, they will be very limited in scope. If computers can beat humans at all
such tests then I'll concede that they are "cleverer".
>> Perhaps it will be interesting to see what happens when computers are
>> 1,000x faster and Stalin-compiled Scheme can compile a simple program in
>> under 1sec. I doubt that will cause any radical shift in tool use though.
>
> Maybe it will, maybe it won't. What I'd say though is:-
> * The number of programs where performance is a key requirement seems
> to be going down.
Agreed.
> * There are many further optimizations that can be done of current
> tools.
Definitely, and many that are facilitated by having faster machines.
> In the OCaml compiler for example there are still ways that the code
> generated could be made better. More unboxing could be used for
> example, some of the tricks with specialisation from MLton could be
> used.
Yes. MLton is several times faster at symbolic code.
> In Lisp, many of the same tricks could be used. Also, programs
> that make lisp system images into restricted executable programs
> (tree-shakers) could be made more sophisticated.
But they are fundamentally whole-program optimisations.
> There is not the same amount of potential improvement open to other
> languages like C where much of the work has been done.
You mean C compilers are as optimising as they'll get? Yes.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
Jon Harrop wrote:
> Rob Thorpe wrote:
> >> We're going to hit problems in physics pretty soon.
> >
> > Maybe, maybe not. Chips as they are built today certainly are not
> > following Moores Law anymore, they have been developing more slowly for
> > ~6 years now. New technology, if anyone comes up with any, need not be
> > so limited. The physical limits on computation are quite far off.
>
> Either way there is no reason to expect exponential growth: That is born of
> one generation of computers being used to build the next.
I'd agree there.
> > There is not evidence that things that work like animal neurons are the
> > only path to intelligent machines.
>
> But animal brains are the basis for all of our notions of intelligence
> because we define the meaning of intelligence.
No, the outputs of animal brains are the basis for intelligence, not
the objects themselves. People recognised intelligent action before
they knew it was associated with brains.
This is one of Searles arguments against AI, he said brains "mentate"
in the same way animal nipples lactate. This is true to some extent, a
brain is distingushable from other things by actually being a brain.
But it's largely irrelevant, what everyone is interested in is the milk
;).
> > I don't agree with Andre either. Who knows what the computational
> > ability of the human brain is?
>
> Well, brains can solve a variety of tasks that computers cannot.
Yes. And we don't know what the full spectrum of abilities the
hardware of a computer (even a current one) has. The software is the
essential question.
> > How can it be compared to a computer
> > when they work in very different ways?
>
> The same way we compare programming languages. :-)
>
> You set them both tasks. Playing "go", for example...
And like computers a wide selection of relevant benchmarks are needed -
I think we might soon get beaten at "Go".
> > Any comparisons are just
> > guesses. They probably depend entirely on what the "intelligent
> > program" is doing.
>
> Yes, they will be very limited in scope. If computers can beat humans at all
> such tests then I'll concede that they are "cleverer".
It's a matter of benchmarking. I'd take ~100 attributes of
intelligence, make test for them and declare the winner through
geometric mean, like the SPEC benchmark. Careful account would have to
be taken of "benchmark engineering" too.
> >> Perhaps it will be interesting to see what happens when computers are
> >> 1,000x faster and Stalin-compiled Scheme can compile a simple program in
> >> under 1sec. I doubt that will cause any radical shift in tool use though.
> >
> > Maybe it will, maybe it won't. What I'd say though is:-
> > * The number of programs where performance is a key requirement seems
> > to be going down.
>
> Agreed.
>
> > * There are many further optimizations that can be done of current
> > tools.
>
> Definitely, and many that are facilitated by having faster machines.
>
> > In the OCaml compiler for example there are still ways that the code
> > generated could be made better. More unboxing could be used for
> > example, some of the tricks with specialisation from MLton could be
> > used.
>
> Yes. MLton is several times faster at symbolic code.
>
> > In Lisp, many of the same tricks could be used. Also, programs
> > that make lisp system images into restricted executable programs
> > (tree-shakers) could be made more sophisticated.
>
> But they are fundamentally whole-program optimisations.
Yes, but whole-program optimization is useful for many purposes. We
lispers may like programs to contain compilers and be completely
open-ended, but it's not necessary for many purposes.
> > There is not the same amount of potential improvement open to other
> > languages like C where much of the work has been done.
>
> You mean C compilers are as optimising as they'll get? Yes.
I think they can get better, but only at a slower rate than languages
where the compilers are less refined. The GCC authors spent years
writing a new register allocator and in the end gave up on it when they
found their old one was actually better. SBCL, OCaml et al are not
facing similar problems, their are still clear paths of improvement.
On 2006-12-13 12:45:50 -0500, "Rob Thorpe" <·······@realworldtech.com> said:
> No, the outputs of animal brains are the basis for intelligence, not
> the objects themselves. People recognised intelligent action before
> they knew it was associated with brains.
> This is one of Searles arguments against AI, he said brains "mentate"
> in the same way animal nipples lactate. This is true to some extent, a
> brain is distingushable from other things by actually being a brain.
> But it's largely irrelevant, what everyone is interested in is the milk
> ;).
I think the problem arises if, using your analogy, only something that
works essetially like a mamary gland can make milk. IOW, it may well be
that the only thing that can produce truly human level intelligent
outputs is something that works essentially like a human brain does,
including all its phases of growth, development, and learning, as well
as its integration into a physical body with all our senses. This would
mean we'd have to understand how human brains work, develop, and learn
in conjuction with the rest of our bodies, all in fairly exhaustive
detail.
So having sufficient computational power might not be enough - we would
be able to program such future computers (in the trivial sense that we
would have languages and compilers for them) - but we might very well
not know *what program* to write.
Raffael Cavallaro wrote:
> On 2006-12-13 12:45:50 -0500, "Rob Thorpe" <·······@realworldtech.com> said:
> > No, the outputs of animal brains are the basis for intelligence, not
> > the objects themselves. People recognised intelligent action before
> > they knew it was associated with brains.
> > This is one of Searles arguments against AI, he said brains "mentate"
> > in the same way animal nipples lactate. This is true to some extent, a
> > brain is distingushable from other things by actually being a brain.
> > But it's largely irrelevant, what everyone is interested in is the milk
> > ;).
>
> I think the problem arises if, using your analogy, only something that
> works essetially like a mamary gland can make milk. IOW, it may well be
> that the only thing that can produce truly human level intelligent
> outputs is something that works essentially like a human brain does,
> including all its phases of growth, development, and learning, as well
> as its integration into a physical body with all our senses. This would
> mean we'd have to understand how human brains work, develop, and learn
> in conjuction with the rest of our bodies, all in fairly exhaustive
> detail.
But the evidence from the history of computing so far is in the
opposite direction, computers are much more similar than they are
different. It seems possible to do almost anything with any kind of
remotely-sane computer. As soon a someone says "that will never run
efficiently on an X" some smart alec comes up with an algorithm that
does so.
It's possible things will turn out this way, but there is no hard
evidence to suggest that it's likely.
On 2006-12-13 14:25:38 -0500, "Rob Thorpe" <·······@realworldtech.com> said:
> But the evidence from the history of computing so far is in the
> opposite direction, computers are much more similar than they are
> different. It seems possible to do almost anything with any kind of
> remotely-sane computer.
You must be reading the history very differently than I read it. I read
it as the assumption that what you state is true - i.e., the assumption
that digital computers are pretty much interchangeable with brains -
and the repeated disappointment when it turns out that things
researchers assumed would be easily solved - robust computer vision,
robust natural language understanding - turn out not to be easy to do.
imho, this is because those who assumed that computers are like brains
overlooked the folowing:
1. brains are connected in complex ways to very complex bodies immersed
in a complex world
2. brains grow, develop and learn over the lifetime of the person -
brains are far from the static entities that digital computers are.
3. brains have had hundreds of millions of years to evolve a "program"
that researchers set themselves the task of writing in 5 or 6 orders of
magnitude less time
In many ways it is as if AI researchers confused our conscious
verbal-conceptual attention, which is just the tip of the iceberg, with
the capabilities of the whole organism. Easy to see how they overlooked
the rest too - the rest is, by definition, unconscious. Given what we
now understand about the relative proportions of conscious attention
and unconscious cognition, it's no wonder that everyday things turned
out to be doubly intractable:
1. we aren't aware of that of which we're unaware (unconscious
cognitive processes), so it's hard to write programs to emulate them -
such programs are woefully underspecified
2. that of which we are unaware (unconscious cognitive processes) turn
out to be the overwhelming majority of cognition
Raffael Cavallaro wrote:
> On 2006-12-13 14:25:38 -0500, "Rob Thorpe" <·······@realworldtech.com> said:
>
> > But the evidence from the history of computing so far is in the
> > opposite direction, computers are much more similar than they are
> > different. It seems possible to do almost anything with any kind of
> > remotely-sane computer.
>
> You must be reading the history very differently than I read it. I read
> it as the assumption that what you state is true - i.e., the assumption
> that digital computers are pretty much interchangeable with brains -
> and the repeated disappointment when it turns out that things
> researchers assumed would be easily solved - robust computer vision,
> robust natural language understanding - turn out not to be easy to do.
I don't think anyone sensible assumed those things would be easy.
> imho, this is because those who assumed that computers are like brains
> overlooked the folowing:
>
> 1. brains are connected in complex ways to very complex bodies immersed
> in a complex world
How is that relevant to the problem?
It is still one of computation, information goes in the senses and
comes out in movements.
> 2. brains grow, develop and learn over the lifetime of the person -
> brains are far from the static entities that digital computers are.
But the software in them isn't.
> 3. brains have had hundreds of millions of years to evolve a "program"
> that researchers set themselves the task of writing in 5 or 6 orders of
> magnitude less time
This is a much more relevant point. There is no reason to believe that
intelligence is that different from other forms computation. But it is
obviously much more complex. Also, it is complex in a dimension
unexplored by most areas of computer programming.
The majority of programming is done for:-
* Presenting data to humans and getting it from humans
* Processing data for commercial purposes
* Simulation of physical processes
* Control of equipment
There is little overlap here with what we think of as "intelligence".
Only really AI researchers have looked seriously at the problem. Is it
any wonder that a community of probably only a few hundred people
working for only ~50years have not got that far.
> In many ways it is as if AI researchers confused our conscious
> verbal-conceptual attention, which is just the tip of the iceberg, with
> the capabilities of the whole organism.
Did they?
The main justification for designing AI experiments based around that
area of our capabilities were:-
* Its obviously interesting and so far appears uniquely human
* It is easier than visual/auditory/sensual work
If I had been there in the early days of AI I would have gone in
exactly the same direction.
> Easy to see how they overlooked
> the rest too - the rest is, by definition, unconscious. Given what we
> now understand about the relative proportions of conscious attention
> and unconscious cognition, it's no wonder that everyday things turned
> out to be doubly intractable:
>
> 1. we aren't aware of that of which we're unaware (unconscious
> cognitive processes), so it's hard to write programs to emulate them -
> such programs are woefully underspecified
Yes.
Raffael Cavallaro schrieb:
> 1. we aren't aware of that of which we're unaware (unconscious cognitive
> processes), so it's hard to write programs to emulate them - such
> programs are woefully underspecified
>
> 2. that of which we are unaware (unconscious cognitive processes) turn
> out to be the overwhelming majority of cognition
Sometimes you need to program many many hours to get a result that can
be presented within 2 seconds.
A lot of brain circles are used to analyse and process sensoric data.
Another huge amount goes into controlling the body machinery.
An intelligent program does not need to do that.
And lot's of processing stuff in todays programs can be seen in some
way as the "unconscious mind" of the program.
A nice book to read is: "Consciousness Explained" by Daniel Dennett.
Andr�
--
On 2006-12-15 14:04:01 -0500, Andr� Thieme
<······························@justmail.de> said:
> A nice book to read is: "Consciousness Explained" by Daniel Dennett.
the title is logically circular, and the book fails for that simple reason:
1. Science is a logical system
2. The existence of a uniform real world is axiomatic of science (can't
do science if laws change from place to place and time to time; can't
do science if the world is imaginary)
3. The existence of conscious observers is axiomatic of science (can't
do science w/o observations, can't have observations without conscious
observers)[*]
4. "Explaining" consciousness is "explaining" an axiom of the logical system
i.e., science can no more "explain" why there exists the thing we call
consciousness than Euclidean geometry can "explain" why there exist
these things we call parallel lines - they are both axioms of their
respective logical systems, and are therefore beyond the scope of each
of their respective systems to "explain." If you want to have science,
you have to posit the existence of consciousness as an axiom of the
logical system. Consciousness is thus a fundamental ontological
category of the scientific universe.
[*] if you argue that an unconscious machine could do the observations,
to what/whom would these observations be reported or by what/whom would
they be understood? An unconscious machine doing "observatons" is no
different in priciple than, say, a rain guage. If water collects in it
to a certain height, no observation has been made (yet). The guage
needs to be read (i.e., observed) by a conscious being (like one of us
humans) for it to be said that an observation has been made.
> 4. "Explaining" consciousness is "explaining" an axiom of the logical system
The problem I have with this is that consciousness appears to be
embedded in the material world itself and seems to consist of certain
physical subcomponents that interact to produce the conscious
experience. We see that damage to certain brain centers modifies
consciousness profoundly as do psychoactive drugs. We might never know
*what* consciousness is but the *how* of it is certainly amenable to
scientific investigation. I think that is what Dennett is trying to
explain in that book.
On 2006-12-15 17:53:10 -0500, ······@gmail.com said:
> We might never know
> *what* consciousness is but the *how* of it is certainly amenable to
> scientific investigation.
It is certainly possible to do scientific work *about* consciousness -
to discuss how consciousness and/or the contents thereof are modified
by certain brain injuries, drugs, etc. But none of these things
constitute an explanation of consciousness itself. To reuse my earlier
analogy, Euclidean geometers can make a great number of reasoned
statements *about* parallel lines, their properties, their relationship
to other aspects of geometry. None of this however constitutes an
"explanation" of parallel lines. There is not, nor can there be any
"explanation" of parallel lines in Euclidean geometry. They're simply
an axiom of the system. Similarly, there is not, nor can there be any
scientific "explanation" of consciousness. It is an axiom of the
logical system of science.
> I think that is what Dennett is trying to
> explain in that book.
Dennett's position in the book was far stronger - he maintained that he
had explained consciousness away completely - i.e., that it does not
exist and is just a subjective illusion. This position is, as I pointed
out, a logical circularity, since his "explanation" was based in large
part on the science of the neurophysiology of the brain, and the
logical system of science must posit the existence of conscious
observers as one of its axioms.
Raffael Cavallaro wrote:
> Dennett's position in the book was far stronger - he maintained that he
> had explained consciousness away completely - i.e., that it does not
> exist and is just a subjective illusion. This position is, as I pointed
> out, a logical circularity, since his "explanation" was based in large
> part on the science of the neurophysiology of the brain, and the
> logical system of science must posit the existence of conscious
> observers as one of its axioms.
What I don't like about your axiomatization is that you have these as
axioms:
1) The physical world exists
2) Consciousness exists
and yet it is undeniable that consciousness arises when certain
assemblages of physical matter are brought together. So consciousness
becomes an epiphenomenon of matter, hence not an axiom.
On 2006-12-15 21:03:10 -0500, ······@gmail.com said:
> What I don't like about your axiomatization is that you have these as
> axioms:
>
> 1) The physical world exists
> 2) Consciousness exists
>
> and yet it is undeniable that consciousness arises
Too late! You *already* have consciousness when you observe *anything*
in the physical world.
We habitually forget, or take for granted, step 0:
Consciousness precedes - both chronologically and logically - any
observation you or anyone else has ever made, including your
observation that consciousness is associated with certain physical
correlates.
Your observation that consciousness arises from certain assemblages of
physical matter perforce comes *after* you've already been forced to
accept as a fundamental premise that there exist a class of entities
that are conscious, else you would be making any observations
whatsoever.
In order for anything to be a subject for scientific enquiry we need to
make certain observations of the world (such as yours that
consciousness is associated with certain physical correlates, like
human brains). But in the logical system that is science all of our
observations must presuppose the existence of consciously aware
observers or there would be no observations.
> when certain
> assemblages of physical matter are brought together. So consciousness
> becomes an epiphenomenon of matter, hence not an axiom.
And so you here fall into the same trap of circularity as Dennett
because you've neglected that your own consciousness precedes
(logically and temporally) any observation you make about consciousness
or anything else.
The very first honest step in any logical system about the world is an
admission that "hey, something is going on here!" (i.e., I perceive the
world and myself in it). That experience of "something is going on
here" *is* conscious awareness. Therefore conscious awareness must be a
fundamental ontological category - we can't honestly construct a
logical system about the world without recognizing it as the basis of
all our observations of the world, and hence an axiom of the logical
system that is science.
Once again, this does not bar us from making any number of interesting
and useful discoveries *about* conscious awareness and the brain (see
Ramachandran's book that I recommended earlier in this thread). Its
just that nothing that we learn about the brain can ever explain why
there is such a thing as consciousness because conscious awareness is a
fundamental ontological category in the scientific logical system.
Raffael Cavallaro wrote:
> On 2006-12-15 21:03:10 -0500, ······@gmail.com said:
>
> > What I don't like about your axiomatization is that you have these as
> > axioms:
> >
> > 1) The physical world exists
> > 2) Consciousness exists
> >
> > and yet it is undeniable that consciousness arises
>
> Too late! You *already* have consciousness when you observe *anything*
> in the physical world.
Oh, I know and that speaks in favor of your ontology. What I am saying
is that I do not care for the idea of an axiom system where one axiom
certainly seems to arise out of the consequences of another. Axioms
should be pure little diamonds, not big hulking machines. It suggests
strongly to me that this axiom system is wrong. Perhaps the physical
world needs to abandoned and we end up with solipsism. To sum up:
1) In order to make observations we must first be conscious, hence
consciousness is axiomatic.
2) Yet, our observations tell us that consciousness is made of physical
parts and we take the physical world to be axiomatic as well.
3) Axioms should not be reducable to other axioms, hence consciousness
is not axiomatic.
For practical applications I don't think it matters which of us is
right. Neuroscience and even strong AI is possible regardless.
On 2006-12-16 12:59:19 -0500, ······@gmail.com said:
> 1) In order to make observations we must first be conscious, hence
> consciousness is axiomatic.
> 2) Yet, our observations tell us that consciousness is made of physical
> parts and we take the physical world to be axiomatic as well.
No, you want this to be the case for some reason, but our observations
tell us no such thing for two reasons. First, all observation must be a
logical consequence of awareness, so nothing we observe can ever
"explain" that which is already the logical starting point of any
logical world system. Second our observations tell us that
consciousness manifests in certain material situations, not that it is
made of physical parts.
IOW, the universe is fundamentally a "conscious" place, just as it is
fundamentally an "energy-matter" place. Certain circumstances cause
each of these natures to manifest in different ways, but the physical
circumstances in which consciousness manifests no more cause
consciousness than consciousness causes the material world to come into
existence when you observe it. Note I said "no more." In fact they
arise mutually, consciousness/observation providing a means for the
physical world to manifest (a-la quantum mechanics), and phsyical
circumstances providing a means for consciousness to manifest.
> 3) Axioms should not be reducable to other axioms, hence consciousness
> is not axiomatic.
So consciousness is not reducible to any other axiom (i.e., the
existence of a non-imaginal, unform "real" world). It is another
fundamental ontological category like the "real" world. They both give
rise to eachother mutually. (Cue kenzo with a taoist quote)
In any event, we've strayed way off topic so I think we may just have
to agree to disagree on this one.
Raffael Cavallaro wrote:
> On 2006-12-16 12:59:19 -0500, ······@gmail.com said:
> Second our observations tell us that
> consciousness manifests in certain material situations, not that it is
> made of physical parts.
But how to tell the difference between "manifests when subcomponents
(x1,x2,..xn) are assembled" and "is made up of subcomponents
(x1,x2,..xn)"?
>
> IOW, the universe is fundamentally a "conscious" place, just as it is
> fundamentally an "energy-matter" place.
Sounds like the Penrose/Hamerof(sp?) position of fundamental conscious
"quanta".
> In any event, we've strayed way off topic so I think we may just have
> to agree to disagree on this one.
Understood, nice chatting with you. I second your rec about
Ramachandran BTW. I read everything of his I can get.
Raffael Cavallaro wrote:
> On 2006-12-15 14:04:01 -0500, André Thieme
> <······························@justmail.de> said:
>
> > A nice book to read is: "Consciousness Explained" by Daniel Dennett.
>
> the title is logically circular, and the book fails for that simple reason:
>
> 1. Science is a logical system
>
> 2. The existence of a uniform real world is axiomatic of science (can't
> do science if laws change from place to place and time to time; can't
> do science if the world is imaginary)
>
> 3. The existence of conscious observers is axiomatic of science (can't
> do science w/o observations, can't have observations without conscious
> observers)[*]
>
> 4. "Explaining" consciousness is "explaining" an axiom of the logical system
>
> i.e., science can no more "explain" why there exists the thing we call
> consciousness than Euclidean geometry can "explain" why there exist
> these things we call parallel lines - they are both axioms of their
> respective logical systems, and are therefore beyond the scope of each
> of their respective systems to "explain." If you want to have science,
> you have to posit the existence of consciousness as an axiom of the
> logical system. Consciousness is thus a fundamental ontological
> category of the scientific universe.
>
> [*] if you argue that an unconscious machine could do the observations,
> to what/whom would these observations be reported or by what/whom would
> they be understood? An unconscious machine doing "observatons" is no
> different in priciple than, say, a rain guage. If water collects in it
> to a certain height, no observation has been made (yet). The guage
> needs to be read (i.e., observed) by a conscious being (like one of us
> humans) for it to be said that an observation has been made.
Just because a part of the system must be axiomatic doesn't prevent a
great deal being found out about it.
Taking an example from Radio frequency electronics. When measuring
antennas every measurement depends on the properties of another
antenna. That antenna properties must be axiomatic within a particular
set of experiments on another one. This does not mean that nothing can
be known about that antenna, in fact it's properties can be derived
from a careful set of experiments, even if it remains axiomatic.
The same situation is present here. There are few limits on what
Humans can in-theory understand about how human brains as a class work.
Also, if the technology becomes available it may be possible to look
into your own brain and find out how it works in-particular. Of course
it's never possible to remove the necessity to depend on senses to feed
the information back.
In my view this reliance on senses (or conciousness) does not prevent
us from understanding the phenomenon. After all we depend on our
senses (and conciousness) for all other understanding.
Rob Thorpe wrote:
>
> Taking an example from Radio frequency electronics. When measuring
> antennas every measurement depends on the properties of another
> antenna. That antenna properties must be axiomatic within a particular
> set of experiments on another one. This does not mean that nothing can
> be known about that antenna, in fact it's properties can be derived
> from a careful set of experiments, even if it remains axiomatic.
Hmm... But isn't the whole thing really bootstrapped from some very
simple antenna whose properties are derived from Maxwell's equations?
You use that antenna to understand a slightly more complex one and then
that one to understand an even more complex one, etc... Only the very
first one is truly axiomatic.
······@gmail.com wrote:
> Rob Thorpe wrote:
> >
> > Taking an example from Radio frequency electronics. When measuring
> > antennas every measurement depends on the properties of another
> > antenna. That antenna properties must be axiomatic within a particular
> > set of experiments on another one. This does not mean that nothing can
> > be known about that antenna, in fact it's properties can be derived
> > from a careful set of experiments, even if it remains axiomatic.
>
> Hmm... But isn't the whole thing really bootstrapped from some very
> simple antenna whose properties are derived from Maxwell's equations?
> You use that antenna to understand a slightly more complex one and then
> that one to understand an even more complex one, etc... Only the very
> first one is truly axiomatic.
You can do it that way. There are several ways. Another is to build a
set of antennas, you can then make axiomatic loss due to the inverse
square law of radiowave propagation through space, and that the
antennas are reciprocal devices. Then by performing a set of
experiments you can find the properties of those antennas.
Unlike the original problem concerning science in general there are
several obvious different ways to approach the problem.
On 2006-12-15 14:04:01 -0500, Andr� Thieme
<······························@justmail.de> said:
> A nice book to read is: "Consciousness Explained" by Daniel Dennett.
A much better book is V. S. Ramachandran's _A Brief Tour of Human
Consciousness_
Raffael Cavallaro wrote:
> On 2006-12-15 14:04:01 -0500, Andr� Thieme
> <······························@justmail.de> said:
>
>> A nice book to read is: "Consciousness Explained" by Daniel Dennett.
>
>
> A much better book is V. S. Ramachandran's _A Brief Tour of Human
> Consciousness_
>
Mad Magazine said it all for me. My2.
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Jon Harrop schrieb:
> Andr� Thieme wrote:
>> Progress is coming exponetially, it is not linear.
>
> Given that "progress" can't be quantified, a statement about its
> mathematical evolution isn't very useful...
Progress in the world of IT can be measured in some ways. The number of
calculations a CPU can do per time unit could be a way to do that.
>> Depending on what function underlies the technology an exponential graph
>> looks like a straight line on some parts, and therewith linear.
>
> We're going to hit problems in physics pretty soon.
Well, this has happened several times already, as you had read on the
website as I provided. Every time a new paradigm helped out.
Of course there will be limit some day, but it will be several decades
before we hit it. So there is still enough room for improvements.
>> That is correct. In ca. 5-7 years the best supercomputer on earth will
>> already have the calculation capabilies like the human brain.
>
> IIRC, Bishop said that the fastest computers could simulate 12 neurons
> realistically in real time in 1996. That is over a billion times fewer than
> found in the human brain.
Hmm, that assumptions is not too unrealistic.
I don't know what he meant by "the fastest computers". If he was talking
about a single cpu it could have been pretty close.
You probably read Kurzweils essay, that's why you answered me.
So you already know his calculation.
If it was a single cpu then super computers were ca. 1000 times faster.
This leaves us with a million. Then it will have been nearly two decades,
giving us the factor of a million.
>> Of course
>> the software is missing for real AI. How we can get the software is
>> described in that article from Kurzweil.
>
> So even if we can make this unfathomable hardware we can't program it.
It is programmable. But we will have the hardware first and then the
software.
>> Anyway: we don't need such a strong intelligence to make Lisp compilers
>> generate faster code. It will happen gradually. Over the coming years
>> Lisp compilers will generate better and better code. Also Python will
>> get faster.
>
> That is a very bizarre statement to make. People want to know how fast
> language implementations are on a given computer. Saying that Lisp will be
> as fast as other languages already are is fruitless.
The statement might be bizarre if you don't take enough information into
account. Lisp already runs fast in almost all cases, comes close to C.
Otherwise there is still asm...
I am just saying that in ca 30-50 years all "programming" will result in
programs that execute as the same speed. But in these days everyone will
be a programmer. It will be a task that everyone can do. Most programs
will be made within seconds.
> Perhaps it will be interesting to see what happens when computers are 1,000x
> faster and Stalin-compiled Scheme can compile a simple program in under
> 1sec. I doubt that will cause any radical shift in tool use though.
I don't know Stalin. Is there no computer on which it can compile a minimal
program in less than one second?
Andr�
--
"Rob Thorpe" <·······@realworldtech.com> writes:
> Ugh, have you ever tried writing down how program works in a natural
> language, or even a specification?
Have a look at:
Metafor Interactive Natural Language Programming
http://www.lehigh.edu/~amsp/2005/03/metafor-natural-language-programming.html
http://web.media.mit.edu/%7Ehugo/demos/metafor-bartender-simple.mov
--
__Pascal Bourguignon__ http://www.informatimago.com/
Un chat errant
se soulage
dans le jardin d'hiver
Shiki
On Tue, 12 Dec 2006 17:14:32 +0100, Jon Harrop <···@ffconsultancy.com>
wrote:
>
> On that ray tracer, Python might be able to approach OCaml's brevity but
> it
> will be orders of magnitude slower as long as it is interpreted.
> Compiling
> Python to a decent bytecode might give better performance, but OCaml
> bytecode is 30x slower than native code on this benchmark.
>
Why is the ray tracing done in software? Isn't it better to leave
that sort of thing to the graphics hardware?
Seems to me it is to slow to make it practical any other way.
If the interface is high level it won't really matter how slow the
language is. (Like num-py resolves the problem of floating-point math in
Python)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> There is clearly a trade-off. Look at my ray tracer benchmark, for example:
>
> http://www.ffconsultancy.com/free/ray_tracer/languages.html
>
> The static languages are significantly faster.
At last! You mentioned the raytracer benchmark! And here I thought
seeing a new and less repetitive Jon Harrop.
Bill Atkins wrote:
> greg <····@cosc.canterbury.ac.nz> writes:
>
> > There's no way you could compile Python to efficient
> > machine code just by macro expansion. You'd also need
> > some very heavy-duty type inferencing.
>
> A compiler shifts a lot of decisions that an
> interpreter would have to make at runtime to compile-time. There is
> no reason a dynamic language can't enjoy this efficiency.
I'm not saying that it's impossible to compile
Python, only that's there's a lot more to it than
just macro expansion. The OP was saying something
like "If you added macros, you might get a compiler
for free", which is clearly far from true.
> if Python is doing a hash lookup on every function call,
> as Alex Mizrahi claims, compilation may not do much to smooth over
> such awkwardness.
As currently implemented, CPython does a dictionary
lookup or two every time a module global or builtin
(which most stand-alone functions are) is referenced.
It would actually be relatively easy to optimise this
into an array lookup in most cases, but most calls in
Python code tend to be *method* calls, which are rather
harder to deal with. Possibly cacheing of method
lookups would help, although I don't know of anyone
having tried it.
> > Python is extremely dynamic, even more so than Lisp.
>
> Uh huh. "More so than Lisp"? Just making stuff up now?
When a Lisp compiler sees
(setq c (+ a b))
it can reasonably infer that the + is the built-in numeric
addition operator. But a Python compiler seeing
c = a + b
can't tell *anything* about what the + means without
knowing the types of a and b. They might be numbers, or
strings, or lists, or some user-defined class with its
own definition of addition.
From another angle, think about what a hypothetical
Python-to-Lisp translator would have to do. It couldn't
just translate "a + b" into "(+ a b)". It would have
to be something like "(*python-add* a b)" where
*python-add* is some support function doing all the
dynamic dispatching that the Python interpreter would
have done.
That's what I mean by Python being more dynamic than
Lisp.
> Despite its dynamism, Lisp is quite compilable.
Please correct me if I'm wrong, but as I understand,
getting efficient code out of a Lisp compiler requires
putting type declarations into the source.
If you put the same declarations into a piece of
Python code, then of course it would be fairly
straightforward to compile it efficiently. But it
wouldn't really be dynamic Python any more.
Python may end up going this way -- there are
currently plans to make room for attaching optional
annotations to function arguments, which could be
used to convey type information to a compiler
(although that's not currently the main intended
use).
The alternative is whole-program analysis and huge
amounts of type inferencing, which the PyPy people
are working on. Maybe something practical will come
out of that.
Whichever, it's nowhere near a simple as just
"adding macros"!
--
Greg
greg <····@cosc.canterbury.ac.nz> writes:
> From another angle, think about what a hypothetical Python-to-Lisp
> translator would have to do. It couldn't just translate "a + b" into
> "(+ a b)". It would have to be something like "(*python-add* a b)" where
> *python-add* is some support function doing all the dynamic dispatching
> that the Python interpreter would have done.
Luckily, Willem Broekema has written a Python to Lisp compiler called
clpython that can be consulted to answer questions like these.
http://trac.common-lisp.net/clpython/
It turns out that addition is fairly straightforward. Attribute lookup,
however, turns out to be complex, as is comparing objects. Here is Willem's
description of the attribute lookup algorithm from the file doc/pres.txt:
To look up person.name (the "name" attribute of object "person")
a. if the class of "person" (say, Person), or one of Person's
base classes (say, Animal) defines __getattribute__,
that will intercept all attribute lookups.
Call: Animal.__getattribute__(person, name)
b. look in instance dictionary: val = person.__dict__["name"]
- but if it has fixed slots:
look in person.__slots__
and give error if "name" is not one of the fixed slots
- unless "__dict__" is specified as one of the fixed slots:
in that case, don't give an error if it is not one of the
fixed slots, but search in the instance dictionary too
c. look in the classes Person, Animal for an attribute called "name"
- if it is a `descriptor', call its __get__ method
- else, if it is a method, make it a bound method
- else, return it unchanged
d. if nothing found so far: look for __getattr__ method in the
classes, and call it: C.__getattr__(person, "name")
Robert Brown <······@speakeasy.net> writes:
> Luckily, Willem Broekema has written a Python to Lisp compiler called
> clpython that can be consulted to answer questions like these.
>
> http://trac.common-lisp.net/clpython/
Does this count as a "children of a lesser Python"? How does clpython
implement Python's immutable strings, for example?
http://dirtsimple.org/2005/10/children-of-lesser-python.html
Paul Rubin <·············@NOSPAM.invalid> writes:
> Robert Brown <······@speakeasy.net> writes:
>> Luckily, Willem Broekema has written a Python to Lisp compiler called
>> clpython that can be consulted to answer questions like these.
>>
>> http://trac.common-lisp.net/clpython/
>
> Does this count as a "children of a lesser Python"? How does clpython
> implement Python's immutable strings, for example?
>
> http://dirtsimple.org/2005/10/children-of-lesser-python.html
I think CLPython is in the "children of a lesser Python" category, on the
grounds that it doesn't implement the complete language and there's no
obvious way to reuse the C packages that make CPython so useful. However,
the other distinguishing feature of the "children" category is bending
semantics to gain speed. CLPython doesn't appear to be doing much of this.
The author says it runs at about the same speed as CPython.
Python strings are implemented in CLPython as instances of a CLOS class, not
as raw Common Lisp strings, so they appear to be immutable.
Paul Rubin wrote:
> Does this count as a "children of a lesser Python"?
This sounds like a quite derogatory first question. CLPython is not a
dead and abandoned project, nor is execution speed its main goal, nor
are Python semantics bended anywhere (it can run the Pie-thon
benchmark). Sure, some recently introduced language features are
missing, but with just a little effort that's solved...
Moreover, in Common Lisp source code analysis and manipulation can be
expressed easily. CLPython thus provides ample opportunities to analyze
type inference or caching schemes. Most of that is unexplored
territory, I think. I like the journey so far.
> How does clpython implement Python's immutable strings, for example?
Normal Python strings are represented by normal Lisp strings. Instances
of subclasses of 'str' are represented by CLOS instances. That's for
performance reasons. This dual-representation aspect is nicely hidden
behind macros, so that even in the code of CLPython itself there's no
need to worry, or even know, about it.
Why not take a look in the code -- I'll be happy to explain things.
- Willem
Willem Broekema wrote:
> Paul Rubin wrote:
> > Does this count as a "children of a lesser Python"?
>
> This sounds like a quite derogatory first question.
I wouldn't take it that way: it's only a quote from an opinion piece
about alternative Python implementations (albeit a contentious one).
> CLPython is not a dead and abandoned project, nor is execution speed
> its main goal, nor are Python semantics bended anywhere (it can run
> the Pie-thon benchmark). Sure, some recently introduced language
> features are missing, but with just a little effort that's solved...
What would it take to get Python people more interested in it? I've
been monitoring the site [1] and the mailing list [2] for some time,
but nothing particularly visible seems to be happening. And wouldn't a
more prominent announcement be the first step to some real publicity? I
think it only got announced on comp.lang.lisp [3] with someone picking
up on it in comp.lang.python. Perhaps getting it on the python.org
front page would attract some attention, although I accept that a lot
of Python developers would rather mess around writing C than writing
Lisp.
Anyway, I'm happy to hear that you're still working on CLPython.
Paul
P.S. Follow-ups set to comp.lang.python.
[1] http://trac.common-lisp.net/clpython/
[2] http://common-lisp.net/pipermail/clpython-devel/
[3] http://groups.google.com/group/comp.lang.lisp/msg/57ae88c5f9a59143
greg ha escrito:
> From another angle, think about what a hypothetical
> Python-to-Lisp translator would have to do. It couldn't
> just translate "a + b" into "(+ a b)". It would have
> to be something like "(*python-add* a b)" where
> *python-add* is some support function doing all the
> dynamic dispatching that the Python interpreter would
> have done.
>
> That's what I mean by Python being more dynamic than
> Lisp.
I see no dinamism on your example, just static overloading.
Juan R. wrote:
> I see no dinamism on your example, just static overloading.
There's nothing static about it:
q = raw_input()
if q == "A":
a = 1
b = 2
else:
a = "x"
b = "y"
c = a + b
There is no way that the compiler can statically
determine what the + operator needs to do here.
--
Greg
greg ha escrito:
> Juan R. wrote:
>
> > I see no dinamism on your example, just static overloading.
>
> There's nothing static about it:
>
> q = raw_input()
> if q == "A":
> a = 1
> b = 2
> else:
> a = "x"
> b = "y"
> c = a + b
>
> There is no way that the compiler can statically
> determine what the + operator needs to do here.
Before or after the input? :]
No, it is not that i did mean. Of course, the operation for c is
dinamic, but just statically overloading the +. The definition for c
could be adapted to the cases and introduced on the if.
I would call dinamic code, for instance, if the if, the different cases
and the def for c could be modified on the fly _� la_ LISP macro style.
On Tue, 12 Dec 2006 16:35:48 +1300, greg wrote:
> When a Lisp compiler sees
>
> (setq c (+ a b))
>
> it can reasonably infer that the + is the built-in numeric
> addition operator. But a Python compiler seeing
>
> c = a + b
>
> can't tell *anything* about what the + means without
> knowing the types of a and b. They might be numbers, or
> strings, or lists, or some user-defined class with its
> own definition of addition.
That may be true, but lisp's numeric addition operator knows how to add
fixnums, bignums, rationals and whatever the lisp name for floating points
is (imprecise?) -- something that not many (if any) processor instruction
sets can manage. So that's still type-dependent dispatch, which isn't
going to get us to the speeds that we actually see reported unless there's
extra stuff going on. Type inference? Declarations?
Cheers,
--
Andrew
Andrew Reilly <···············@areilly.bpc-users.org> writes:
> On Tue, 12 Dec 2006 16:35:48 +1300, greg wrote:
>
> > When a Lisp compiler sees
> >
> > (setq c (+ a b))
> >
> > it can reasonably infer that the + is the built-in numeric
> > addition operator. But a Python compiler seeing
> >
> > c = a + b
> >
> > can't tell *anything* about what the + means without
> > knowing the types of a and b. They might be numbers, or
> > strings, or lists, or some user-defined class with its
> > own definition of addition.
>
> That may be true, but lisp's numeric addition operator knows how to add
> fixnums, bignums, rationals and whatever the lisp name for floating points
> is (imprecise?)
float. Of which there are several flavors.
http://www.lispworks.com/documentation/HyperSpec/Body/t_float.htm
> sets can manage. So that's still type-dependent dispatch, which
> isn't going to get us to the speeds that we actually see reported
> unless there's extra stuff going on. Type inference? Declarations?
Yes - both are typically involved.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
greg <····@cosc.canterbury.ac.nz> writes:
>> A compiler shifts a lot of decisions that an
>> interpreter would have to make at runtime to compile-time. There is
>> no reason a dynamic language can't enjoy this efficiency.
>
> I'm not saying that it's impossible to compile
> Python, only that's there's a lot more to it than
> just macro expansion. The OP was saying something
> like "If you added macros, you might get a compiler
> for free", which is clearly far from true.
Yeah, my mistake - I simply glided right past the "just by macro
expansion." Oops. :)
>> Despite its dynamism, Lisp is quite compilable.
>
> Please correct me if I'm wrong, but as I understand,
> getting efficient code out of a Lisp compiler requires
> putting type declarations into the source.
>
> If you put the same declarations into a piece of
> Python code, then of course it would be fairly
> straightforward to compile it efficiently. But it
> wouldn't really be dynamic Python any more.
Type declarations can squeeze out extra efficiency, but vanilla Lisp
without type declarations will still beat Python, both because the
language is designed to compile well and because compilers for Lisp
are generally very mature. So it is not the case that type
declarations are the only thing that make Lisp efficient.
> greg <····@cosc.canterbury.ac.nz> writes:
>
> >> A compiler shifts a lot of decisions that an
> >> interpreter would have to make at runtime to compile-time. There is
> >> no reason a dynamic language can't enjoy this efficiency.
> >
> > I'm not saying that it's impossible to compile
> > Python, only that's there's a lot more to it than
> > just macro expansion. The OP was saying something
> > like "If you added macros, you might get a compiler
> > for free", which is clearly far from true.
Speaking as the OP, let's see what the OP really said:
>... compilers are GREATLY facilitated by having a
> macro facility because (at first blush) all you need to do is to
> macro-expand down to something you know how to turn into code.
> This isn't the only, nor perhaps the best way to get a compiler, but it's
> a step in that direction. Later on you can learn the other great
> features offered by homogeneous syntax, like being able to write code
> walkers, which help improve over the "first blush" compiler....
So, "If you added macros, you might get a compiler for free" is not a
fair paraphrase of this.
(Another way, BTW, that macros improve efficiency is by replacing
function calls with in-line code. Another cheap improvement facilitated
by macros.)
> Fast. Very fast!
>
> - Paddy.
Well, Python certainly is faster than most people doing floating-point
arithmetic by hand, but I don't think this is the correct argument to use
against Lisp :-P.
Jes�s Carrete Monta�a wrote:
> > Fast. Very fast!
> >
> > - Paddy.
>
>
> Well, Python certainly is faster than most people doing floating-point
> arithmetic by hand, but I don't think this is the correct argument to use
> against Lisp :-P.
Why not!
Lispers can indeed roll-their-own anything, many do it seems do just
that. But others look at the *time saving* libraries available to users
of Python and think hmm...
-Paddy.
This is not a response to any particular post, but rather to the
general argument that macros are not as useful as we Lispers claim.
Here is a fairly complete GUI RSS reader in 90 lines of Lisp (the GUI
code itself is 90 lines, but it makes use of some RSS reading/writing
code I had laying around and two public CL libraries: s-xml and
trivial-http). The code employs a handy macro called DEFINE-INTERFACE
that LispWorks provides with their CAPI toolkit. I hope this will be
useful as an illustration of what macros (and Lisp in general) can do,
and as an example of what a moderately practical CL application looks
like.
The application presents a list of feeds and allows the user to add
new feeds or to delete existing feeds. The feeds are presented as a
tree, with each channel acting as a parent to several items. The user
can refresh all of the feeds with the "Refresh All" button.
Double-clicking on any item will display its description field (as in
the screenshot). Each channel shows the number of unread articles and
the articles are arranged so that the unseen articles appear before
the articles that have already been read.
Important things to note:
1) the DEFINE-INTERFACE syntax closely resembles the syntax of the
standard DEFCLASS macro, so newcomers have a basic idea of what
DEFINE-INTERFACE is going to do
2) the expansion ( http://galoot.org/~bill/code/rss-reader/expanded.lisp )
of just the DEFINE-INTERFACE is quite involved, a testament to
the amount of work the macro saves
3) much of the GUI can be specified declaratively because of the
DEFINE-INTERFACE syntactic abstraction, and this declarativeness
makes it very easy for maintainers to understand what's going on
4) even without knowing the implementation of DEFINE-INTERFACE and
even without prior experience with it, one can make good guesses
about what it does
5) the GUI code is stunningly concise
Here is the GUI code alone:
< http://galoot.org/~bill/code/rss-reader/rss-gui.lisp >
Here is a screenshot of the application in development:
< http://galoot.org/~bill/code/rss-reader/development.png >
and two screenshots of the application in use
< http://galoot.org/~bill/code/rss-reader/in%20action.png >
< http://galoot.org/~bill/code/rss-reader/in%20action%202.png >
Here are the support files:
< http://galoot.org/~bill/code/rss-reader/ >
Here is an OS X universal binary (run at your own risk; I've only
done very basic testing):
< http://galoot.org/~bill/code/rss-reader/BarebonesRSS.app.tar.gz >
Enjoy.
Bill Atkins wrote:
> This is not a response to any particular post, but rather to the
> general argument that macros are not as useful as we Lispers claim.
>
> Here is a fairly complete GUI RSS reader in 90 lines of Lisp
For comparison, here's how something with a similar
API might be used from Python.
class RSSInterface(Interface):
def __init__(self):
Interface.__init__(self,
panes = [
TextInput('url_pane',
title = 'Feed URL:',
callback = 'add_feed',
callback_type = 'interface'),
PushButton('add',
text = 'Add Feed',
callback = 'add_feed',
callback_type = 'interface'),
PushButton('refresh',
text = 'Refresh All',
callback = 'refresh_feeds',
callback_type = 'interface'),
PushButton('delete',
text = 'Delete Feed',
callback = 'delete_feed',
callback_type = 'interface'),
TreeView('tree',
visible_min_width = ('character', 84),
visible_min_height = ('character', 40),
action_callback = 'browse_item',
callback_type = 'item_interface',
expandp_function = lambda: True, # not sure how best to translate
children_function = 'tree_item_children',
print_function = 'tree_item_string')
],
layouts = [
ColumnLayout('main', ('top', 'tree')),
RowLayout('top', ('url_pane', 'add', 'refresh', 'delete'))
],
title = 'Barebones RSS Reader v1.0')
self.channels = [
parse_rss_from_url(url) for url in [
'http://planet.lisp.org/rss20.xml',
'http://feeds.theonion.com/theonion/daily']]
def add_feed(self):
...
def delete_feed(self):
...
# etc.
--
Greg
········@gmail.com wrote:
> Come on; you guys can't just leave this at 999 posts!
>
Funny you should whine, i was just getting ready to sign off with:
I noticed while singing the praises of auto-indentation that there was a
shortcoming in The Greatest Feature Known to Editing source code, which
is the ability to copy an arbitrary block of code (say, a case statement
in the else branch of an if statement in a loop) with a single
control-click of the mouse, viz, that I still had to reindent if it was
a multiline statement. The first line of course landed exactly where I
clicked so that was fine, but other lines in the block were retaining
the indentation extant at the time of the click.
A few glasses of...<cough> a few hours ago I dashed off an RFE to Franz
tech support apologizing for a trivial matter but wondering if it might
not be just a line or two, and lawdy-it-must-be-xmas a glass later back
came a patch I am just wallowing in.
interestingly, the techie happens not to have been a user of
control-click, probably a hardcore keyboard guy who never touches the
mouse. I started programming GUIs on a Mac 512, didn't /have/ a keyboard.***
And now the punch line: spare me the "oh gosh reindentation is so easy"
dodge. So is a manual control-shift-p to auto-reindent after an ungainly
paste, but this is definitely one of those deals where we don't notice
until we stop hitting ourselves with that hammer.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
BLISS programs Just Work.
Never revisited, they
Never get refined.
- Warnock's Explanation of Large Programs
On Fri, 08 Dec 2006 03:07:09 -0800, Mark Tarver wrote:
> How do you compare Python to Lisp? What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here. This is
> just a question for my general education.
>
> Mark
Kill this frakkin thread; Lisp rules -- while Python is boring (but better
than many other alternatives). E.O.F.
--
Lars Rune Nøstdal
http://nostdal.org/
Lars Rune Nøstdal wrote:
> On Fri, 08 Dec 2006 03:07:09 -0800, Mark Tarver wrote:
>
> > How do you compare Python to Lisp? What specific advantages do you
> > think that one has over the other?
> >
> > Note I'm not a Python person and I have no axes to grind here. This is
> > just a question for my general education.
> >
> > Mark
>
> Kill this frakkin thread; Lisp rules -- while Python is boring (but better
> than many other alternatives). E.O.F.
>
Perhaps only with the addendum that although 'Lisp roolz', no-one uses
for anything of relevance anymore and it is continuing it's geriatric
decline into obscurity. ;-)
Python is dull, except to the ever increasing group of programmers who
use it for practical purposes.
Hmm... a fitting. EOF.
Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml
> --
> Lars Rune Nøstdal
> http://nostdal.org/
Fuzzyman ha escrito:
> Perhaps only with the addendum that although 'Lisp roolz', no-one uses
> for anything of relevance anymore and it is continuing it's geriatric
> decline into obscurity. ;-)
I do not think that i cannot agree with the contrary of this but i do
not think the contrary neither.
I am being said that LISP is being actively pursued by a number of
joung hackers as Graham and Tilton. Do not believe?
Ken Tilton has noticed that Dalai Lama has becomed interested in LISP
also.
On Sat, 23 Dec 2006 12:38:30 -0800, Fuzzyman wrote:
>
> Lars Rune Nøstdal wrote:
>> On Fri, 08 Dec 2006 03:07:09 -0800, Mark Tarver wrote:
>>
>> > How do you compare Python to Lisp? What specific advantages do you
>> > think that one has over the other?
>> >
>> > Note I'm not a Python person and I have no axes to grind here. This is
>> > just a question for my general education.
>> >
>> > Mark
>>
>> Kill this frakkin thread; Lisp rules -- while Python is boring (but better
>> than many other alternatives). E.O.F.
>>
>
> Perhaps only with the addendum that although 'Lisp roolz', no-one uses
> for anything of relevance anymore and it is continuing it's geriatric
> decline into obscurity. ;-)
Screw it; I'll die a "non-professional" programmer if I have to. Meanwhile
ridiculing and scorning all the fools using inferior languages. *hah!*
If I can't do what I love when it comes to programming I'd rather have a
shitty non-programming job that enables me to instantly forget what I've
been doing while at work as soon as I'm done for the day.
My trade -- my tools. :}
--
Lars Rune Nøstdal
http://nostdal.org/