Looks like the BDFL is planning to take lambda, reduce, filter, and
map out of Python in the next big rev of Python (so called Python
3000):
<http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
And yet at the same time they're making a big fuss about adding stuff
that looks like an extension to the LOOP syntax:
any(x > 42 for x in S) # True if any elements of S are > 42
all(x != 0 for x in S) # True if all elements if S are nonzero
(Note that you can get the same effect in Lisp with SOME and EVERY and,
in the "any" example, a lambda function. (Note: I want the Arc-like [>
_ 42] reader syntax in CL, so I think I'll add it---something that
would be a very big deal in Python))
-Peter
"Peter Scott" <·········@gmail.com> writes:
> And yet at the same time they're making a big fuss about adding stuff
> that looks like an extension to the LOOP syntax:
>
> any(x > 42 for x in S) # True if any elements of S are > 42
> all(x != 0 for x in S) # True if all elements if S are nonzero
Adding LOOP-like syntax takes Python further away from Lisp doesn't
it?
[...]
From: M Jared Finder
Subject: Re: Python becoming less Lisp-like
Date:
Message-ID: <4234ac64_4@x-privat.org>
Peter Seibel wrote:
> Looks like the BDFL is planning to take lambda, reduce, filter, and
> map out of Python in the next big rev of Python (so called Python
> 3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
Would someone who knows enough Python translate this over and post it?
Even though I know very little Python myself, I'd hate to see such a
useful feature as Lambda get thrown away. WRITE-INT32, SEEK, and
GET-POS all take seekable file streams as parameters. As you can guess,
I have yet to learn Lisp's file IO as well. This code is actually taken
from Java, where I wrote it using anonymous classes. :P
------------------------------
I think removing Lambda from Python is a huge mistake. Anonymous
functions are very useful when writing generic code. For example, let's
say you a chunky file format, where each chunk has a header that has the
chunk's unique ID, and the size of the chunk. Each chunk can contain
arbitrary data, including other chunks. With anonymous functions, you
could write a generic write_chunk function as follows:
(defun write-chunk (s id writer)
"S is the stream to write to, ID is the unique id, and writer is an
arbitrary block."
(let ((size-pos (+ (get-pos s) 4))
(start-pos (+ (get-pos s) 8)))
(write-int32 s id)
(write-int32 s -1) ;; total size, to be written later
(funcall writer)
(let ((end-pos (get-pos s)))
(seek s size-pos)
(write-int32 s (- end-pos start-pos))
(seek s end-pos))))
Which could then be used like this for writing a file format:
(write-chunk s +data-id+
(lambda ()
(write-int32 s +version+)
(write-int32 s (length enemies))
(doseq (enemy enemies)
(write-chunk s +enemy-id+
(lambda ()
(write-int32 s enemy.health)
(write-int32 s enemy.position)
(write-int32 s enemy.type))))
(write-int32 s (length power-ups))
(doseq (power-up power-ups)
(write-chunk s +power-up-id+
(lambda ()
(write-int32 s power-up.type)
(write-int32 s power-up.position))))
If you can't pass around anonymous clases you have to explicitly call
START-CHUNK at the start of each chunk and END-CHUNK at the end of each
chunk, which is much more error prone.
-- MJF
M Jared Finder <·····@hpalace.com> writes:
[...]
> If you can't pass around anonymous clases you have to explicitly call
> START-CHUNK at the start of each chunk and END-CHUNK at the end of
> each chunk, which is much more error prone.
Or you use a named function (or class) instead. Or you use
decorators, <http://www.python.org/doc/2.4/whatsnew/node6.html>, I
guess. (I don't know much about Python, but losing lambda doesn't
seem a catastrophe if you've got suitably scoped named functions, and
if you've got alternative syntaxes for common uses like generators.)
i'm no python expert but in my few attempts to write someting
in the language, i found the lambda so limited that it was almost
useless. As i understand, the lambda can only contain a single
expression, and no control flow and no conditionals. it is
probably not a big loss to throw away such a limited partial
implementation.
-jim
M Jared Finder wrote:
> Peter Seibel wrote:
>
>> Looks like the BDFL is planning to take lambda, reduce, filter, and
>> map out of Python in the next big rev of Python (so called Python
>> 3000):
>>
>> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
>
>
> Would someone who knows enough Python translate this over and post it?
> Even though I know very little Python myself, I'd hate to see such a
> useful feature as Lambda get thrown away. WRITE-INT32, SEEK, and
> GET-POS all take seekable file streams as parameters. As you can guess,
> I have yet to learn Lisp's file IO as well. This code is actually taken
> from Java, where I wrote it using anonymous classes. :P
>
> ------------------------------
>
> I think removing Lambda from Python is a huge mistake. Anonymous
> functions are very useful when writing generic code. For example, let's
> say you a chunky file format, where each chunk has a header that has the
> chunk's unique ID, and the size of the chunk. Each chunk can contain
> arbitrary data, including other chunks. With anonymous functions, you
> could write a generic write_chunk function as follows:
>
> (defun write-chunk (s id writer)
> "S is the stream to write to, ID is the unique id, and writer is an
> arbitrary block."
> (let ((size-pos (+ (get-pos s) 4))
> (start-pos (+ (get-pos s) 8)))
> (write-int32 s id)
> (write-int32 s -1) ;; total size, to be written later
>
> (funcall writer)
>
> (let ((end-pos (get-pos s)))
> (seek s size-pos)
> (write-int32 s (- end-pos start-pos))
> (seek s end-pos))))
>
> Which could then be used like this for writing a file format:
>
> (write-chunk s +data-id+
> (lambda ()
> (write-int32 s +version+)
>
> (write-int32 s (length enemies))
> (doseq (enemy enemies)
> (write-chunk s +enemy-id+
> (lambda ()
> (write-int32 s enemy.health)
> (write-int32 s enemy.position)
> (write-int32 s enemy.type))))
>
> (write-int32 s (length power-ups))
> (doseq (power-up power-ups)
> (write-chunk s +power-up-id+
> (lambda ()
> (write-int32 s power-up.type)
> (write-int32 s power-up.position))))
>
> If you can't pass around anonymous clases you have to explicitly call
> START-CHUNK at the start of each chunk and END-CHUNK at the end of each
> chunk, which is much more error prone.
>
> -- MJF
From: M Jared Finder
Subject: Re: Python becoming less Lisp-like
Date:
Message-ID: <4234c1bf_2@x-privat.org>
Jim Newton wrote:
> i'm no python expert but in my few attempts to write someting
> in the language, i found the lambda so limited that it was almost
> useless. As i understand, the lambda can only contain a single
> expression, and no control flow and no conditionals. it is
> probably not a big loss to throw away such a limited partial
> implementation.
Wow, I would have never thought that lambda in Python would be so wimpy.
What was the rationale behind this limitation? Please tell me it was
not so that return could be implicit; that would be an awful reason.
-- MJF
From: Stefan Nobis
Subject: Re: Python becoming less Lisp-like
Date:
Message-ID: <87is3u8sjg.fsf@snobis.de>
M Jared Finder <·····@hpalace.com> writes:
[Python: lambda allows only a single expression]
> Wow, I would have never thought that lambda in Python would be
> so wimpy. What was the rationale behind this limitation?
I thing the problem is syntax. In Python only whitespaces can
delimit blocks and i think they don't accept more syntax only for
this single feature. As far as i understand this, lambda is only a
quick hack from some lisp-guy.
I like Python very much as a language for beginners (i use it in
basic programming courses) and it's a great language for the
average programmer. But for lisp programmer, it's not a very
natural choice -- i think in the group Perl, Python, PHP, Ruby the
last one would fit better.
--
Stefan.
Jim Newton wrote:
> i'm no python expert but in my few attempts to write someting
> in the language, i found the lambda so limited that it was almost
> useless. As i understand, the lambda can only contain a single
> expression, and no control flow and no conditionals. it is
> probably not a big loss to throw away such a limited partial
> implementation.
>
> -jim
I don't think that anonymous functions (or _lambda_) is partially
implemented in Python. For what I know, those limitations are intentional.
I've only programmed a few lines of Python but the whole language seamed
oriented to named functions.
Peter Seibel wrote:
> Looks like the BDFL is planning to take lambda, reduce, filter, and
> map out of Python in the next big rev of Python (so called Python
> 3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
The Lambda cannot be lambasted; its lambency shall shine forever!
--tcr.
+ "Tobias C. Rittweiler" <······@freebits.de>:
| The Lambda cannot be lambasted; its lambency shall shine forever!
And of course, the lambada is a rather indecent form of dance in the
eyes of some people.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Peter Seibel wrote:
> Looks like the BDFL is planning to take lambda, reduce, filter, and
> map out of Python in the next big rev of Python (so called Python
> 3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
That's probably a good thing. In particular, I feel bad for the
commentor (on the 3rd page) who claimed these were Python beliefs:
"The programmer knows best and is the ultimate authority."
"Power should be maximized."
Python's stated goal is actually about limiting choice: "There should
be preferably only one way to do something." In particular, a tool that
Guido van Rossum wants to personally use.
If you're a poor overworked programmer coming from Java, Python is
obviously a liberation. That leads many to believe peculiar things
about Python's goals, which Guido honestly states are not the case.
Peter Seibel <·····@gigamonkeys.com> writes:
> Looks like the BDFL is planning to take lambda, reduce, filter, and
> map out of Python in the next big rev of Python (so called Python
> 3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
Aaaargh, don't remind me. It pissed me off so much when I read in on
Friday, that I didn't want look at Python all day ...
Take some clear, simple, orthogonal features and replace them with
ad-hoc special case solutions for the use cases you can think of.
... and now you rub my nose in it in c.l.lisp, of all places.
Let's just hope that this really happens in the year 3000.
Jacek Generowicz wrote:
> Aaaargh, don't remind me. It pissed me off so much when I read in on
> Friday, that I didn't want look at Python all day ...
Why look at Python at all? One day I went to their website, saw the
whitespace syntax and Yet-Another-Imperative-Scripting-Language. Didn't
look at Python ever again.
If someone forces me into scripting I will take a closer look at Ruby
and Lua.
> Take some clear, simple, orthogonal features and replace them with
> ad-hoc special case solutions for the use cases you can think of.
That's Python. They might have nicer ad-hoc solutions than the
C-dialects, but the whitespaces: uuuh.
You took one look at Python and were turned off by the whitespace
significance? That reminds me of disliking Lisp because of the
parentheses. Both are fairly easy to work with once you get your editor
set up and become accustomed to them.
Really, what's the problem?
-Peter
Peter Scott wrote:
> You took one look at Python and were turned off by the whitespace
> significance? That reminds me of disliking Lisp because of the
> parentheses. Both are fairly easy to work with once you get your editor
> set up and become accustomed to them.
>
> Really, what's the problem?
>
> -Peter
>
But in C I can at least write "foo->a = a; foo->b = b; bla(); barz();"
I don't want to use all whitespace and newlines, just because Mr van
Rossum thinks that's cool.
Also, why should I learn the language? What compelling advantages does
it have (again, except for libraries)?
Ulrich Hobelmann wrote:
> Peter Scott wrote:
>> You took one look at Python and were turned off by the whitespace
>> significance? That reminds me of disliking Lisp because of the
>> parentheses. Both are fairly easy to work with once you get your
>> editor set up and become accustomed to them.
>>
>> Really, what's the problem?
>>
>> -Peter
>>
>
> But in C I can at least write "foo->a = a; foo->b = b; bla();
> barz();" I don't want to use all whitespace and newlines, just
> because Mr van Rossum thinks that's cool.
>
> Also, why should I learn the language? What compelling advantages
> does it have (again, except for libraries)?
I think Python's compelling advantages are:
0) large open source library support
1) easy for newbies to pick up. Isn't weird, resembles C/C++. This is all
by design; BDFL puts a premium on readability, clarity, ease of use. That's
what the Zen Of Python is about.
2) consequently, many open source developers are standardizing on it as a
Builds, GUIs, and Tools language. It's good for communal development, where
projects are "relatively dumb."
Python's main disadvantage IMO is it's slow. I'm doing 3D graphics and game
AI, so slow matters to me. I want something compiled. I've seen little
compelling proof of concept in those problem domains. 3D, in particular,
always relies on some underlying C++ engine. Also game AI is a "roll my
own" problem, not a communal problem.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
Brandon J. Van Every wrote:
> I think Python's compelling advantages are:
> 0) large open source library support
> 1) easy for newbies to pick up. Isn't weird, resembles C/C++. This is all
You know, "not weird" and "resembles C" sounds like a contradiction to me ;)
> by design; BDFL puts a premium on readability, clarity, ease of use. That's
> what the Zen Of Python is about.
Okay, it really seems quite a readable language, even for non-pythoners.
> 2) consequently, many open source developers are standardizing on it as a
> Builds, GUIs, and Tools language. It's good for communal development, where
> projects are "relatively dumb."
Well, I would wish it could replace Perl, then I wouldn't have to learn
that in the future.
> Python's main disadvantage IMO is it's slow. I'm doing 3D graphics and game
> AI, so slow matters to me. I want something compiled. I've seen little
> compelling proof of concept in those problem domains. 3D, in particular,
> always relies on some underlying C++ engine. Also game AI is a "roll my
> own" problem, not a communal problem.
I think there's a partial compiler, Psycho (or Psyco?), but it isn't
really fast, either, from what I've heard.
Ulrich Hobelmann wrote:
> Brandon J. Van Every wrote:
>> I think Python's compelling advantages are:
>> 0) large open source library support
>> 1) easy for newbies to pick up. Isn't weird, resembles C/C++. This
>> is all
>
> You know, "not weird" and "resembles C" sounds like a contradiction
> to me ;)
Yes but you are hanging out in comp.lang.lisp, so probably have poisoned
tastes as far as the rest of the programming world is concerned. C is not
weird. C++ has parts that are weird and painful.
>> 2) consequently, many open source developers are standardizing on it
>> as a Builds, GUIs, and Tools language. It's good for communal
>> development, where projects are "relatively dumb."
>
> Well, I would wish it could replace Perl, then I wouldn't have to
> learn that in the future.
Python can do any job Perl can do. It's only a question of competing
installed base. If you have control over the development, you don't have to
use Perl. If you have the power of recommendation, you may be able to sway
a project from Perl to Python. It's only when "we're already using Perl"
that you're stuck.
> I think there's a partial compiler, Psycho (or Psyco?), but it isn't
> really fast, either, from what I've heard.
Yes, my Pythonic friend has done game development with Psyco. It doesn't
result in any amazing speedup. Maybe 2x 3x over something that was already
quite slow? Can't remember exactly, but it's still not approaching compiled
language speeds.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
Brandon J. Van Every wrote:
> Ulrich Hobelmann wrote:
>
>>Brandon J. Van Every wrote:
>>
>>>I think Python's compelling advantages are:
>>>0) large open source library support
>>>1) easy for newbies to pick up. Isn't weird, resembles C/C++. This
>>>is all
>>
>>You know, "not weird" and "resembles C" sounds like a contradiction
>>to me ;)
>
>
> Yes but you are hanging out in comp.lang.lisp, so probably have poisoned
> tastes as far as the rest of the programming world is concerned. C is not
> weird. C++ has parts that are weird and painful.
I'm not sure about that. Maybe.
I consider it weird when I have a function like this (annotated with the
*real* type):
/* parser -> parsetype * parsevalue */
ParseType parse(Parser * p, ParseValue * pv);
Yes, it's supposed to return INT or STRING or something else AND to
return the value of the int/string/bla as well. But in C I have to
write this with a crazy pointer.
To call it I have to:
ParseValue pv; ParseType t = parse(p, &pv);
instead of something sensible like (t, pv) = parse(p).
Ok, here we're actually talking Python, and totally unintended of me :)
Anyway, C is totally ad-hoc, has slow, arbitrary calling conventions,
has arbitrary syntax and other limitations (because it's ad-hoc). It's
incredible that millions of programmers just put up with it because of
inertia.
C++ is both much nicer in some respects and incredibly ugly (templates?
compiling the same generic container class over and over again, instead
of using a C module that just takes a void * as parameter).
Maybe I'll write a frontend to C someday that allows me some freedom.
But that will be a lot of work, too. So I end up using Scheme/Lisp/SML
once in a while.
> Python can do any job Perl can do. It's only a question of competing
> installed base. If you have control over the development, you don't have to
> use Perl. If you have the power of recommendation, you may be able to sway
> a project from Perl to Python. It's only when "we're already using Perl"
> that you're stuck.
Well, people will have to relearn everything (or something) for Perl 6.
That's the chance: Lispniks, bite them!
Ulrich Hobelmann wrote:
>
> Anyway, C is totally ad-hoc, has slow, arbitrary calling conventions,
> has arbitrary syntax and other limitations (because it's ad-hoc).
True. The reason it isn't 'weird' is because everybody learns it.
> It's incredible that millions of programmers just put up with it
> because of inertia.
That's not the only reason. Name me 1 language that's easy to bind to other
languages, other than C. The C calling convention is the only thing we've
got. C is also a portable assembler, and useful wherever anyone would want
a portable assembler.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
When no one else sells courage, supply and demand take hold.
Brandon J. Van Every wrote:
>>It's incredible that millions of programmers just put up with it
>>because of inertia.
>
>
> That's not the only reason. Name me 1 language that's easy to bind to other
> languages, other than C. The C calling convention is the only thing we've
> got. C is also a portable assembler, and useful wherever anyone would want
> a portable assembler.
>
(rant
"I dare disagree (though I agree an C being the standard for calling
conventions and language bindings). Calling C a portable assembler IMHO
is an insult to the people who made PPC, ARM, and other beautiful
architectures what they are (I'm sure you didn't mean it that way ;) ),
unfortunately.
There's so much you can do with assembly language, that C doesn't even
consider, like the already mentioned multiple-return-values (sure, after
all we are allowed to pass n parameters TO the function, right?), tail
calls (or space-safety in general, though this is an implementation
issue, I guess [1]), special variables that are kept in registers (I'm
not sure, does C honor global register int definitions?). (Of course
there's C-- for stuff like this, but everyone uses C, even for compiler
backends.) In x86 the calling conventions are somewhat braindead, but
then the architecture isn't the best, anyway. In particular pushing the
return-value on a call might make continuations harder (that is: a lot
slower I would guess, since it confuses the CPU's optimizations to work
around this old 'feature'). On PPC the CCs are weird too, so a portable
assembler could optimize a lot, but even gcc could produce better code
and still stay within the compatible allowances. When I learnt the arch
some months ago, I did simple stuff like the recursive fibonacci
function. Asm beat gcc -O2 by a lot, but even a C-compatible function
was a lot faster, just by changing the function pro-/epilogue. That's sad.
All it takes for a portable assembler would be mechanisms for structs
(or even only vectors of 32bit words) and continuation calls (i.e.
goto/jump with arguments). I think that would be it. Everything else,
including a saner C (and from there ++, Java, you name it), could be
layered on this. I'm just too lazy to do it, I guess.
But C is very portable, yes (in fact much more portable than The Great
Java).
[1] I mean that a C function might use storage even if it's not needed
at the time, like in:
{ BigStruct bs; foo(); bar(&bs); }
While foo() (which might be a complex recursive call) is running, the
stack shouldn't waste space for bs. What's unrelated: in typical
gcc-output (x86+PPC), every single function even does stuff like
decrementing the stack pointer by 32, and then incrementing it by
another -32 (yes, this could be a single instruction). It does this for
functions that have no or only small space requirements, in the order of
under 20 bytes. Alignment would make this 32 bytes maybe, but gcc often
makes a function use 80 and more. This eats stack space and L1-cache I
guess, especially for recursion, again.")
Brandon J. Van Every <·····························@yahoo.com> wrote:
> Python's main disadvantage IMO is it's slow. I'm doing 3D graphics and game
> AI, so slow matters to me. I want something compiled. I've seen little
> compelling proof of concept in those problem domains. 3D, in particular,
> always relies on some underlying C++ engine. Also game AI is a "roll my
> own" problem, not a communal problem.
It's not THAT slow. For example there's a VoIP software written in
Python and a SIP server too with Stun and UPnP support.
Since you might not know, SIP servers need to send packages every 20ms
to all the connected clients (if there is a conference going on clients
may be more than 2). And of course each voice stream has to be mixed
with the others.
Using python standard libraries and python itself the developers managed
to get the sampling/mixing done in about 1ms for 18 tracks.
There are many web servers written in python and each of them can serve
at least 500 reqs/sec.
Andrea Arcangeli (of linux Virtual Machine fame) is using python with
Twisted Matrix for its www.cpushare.com project.
And he managed to saturate a 10mbit line with just 2 Twisted.web
processes with a load balancer.
The popular RPG game: Temple of Elemental Evil was written using python.
All this to say: I probably have to agree if you talk about raw speed
(which anyway depends on the particular job, java, which is considered
to be faster, most of the times yields slower GUIs; libglade contains an
algorithm to handle scheduling which is slower than the one in Twisted
Matrix written in pure python), but the real question should be: is
python fast enough? Most of the times yes. When it is not, anyway, there
are many and confortable ways to make it faster: Pyrex, psyco, swig,
pyasm, ctypes and so on.
HTH, cheers
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> Brandon J. Van Every <·····························@yahoo.com> wrote:
>
>> Python's main disadvantage IMO is it's slow. I'm doing 3D graphics
>> and game AI, so slow matters to me. I want something compiled.
>> I've seen little compelling proof of concept in those problem
>> domains. 3D, in particular, always relies on some underlying C++
>> engine. Also game AI is a "roll my own" problem, not a communal
>> problem.
>
> It's not THAT slow. For example there's a VoIP software written in
> Python and a SIP server too with Stun and UPnP support.
>
> Since you might not know, SIP servers need to send packages every 20ms
> to all the connected clients (if there is a conference going on
> clients may be more than 2).
2ms is a very, very long time to a number crunching 3D graphics or AI guy.
> And of course each voice stream has to be mixed with the others.
Are you saying someone is doing tons of signal processing with Python and no
underlying C library?
> There are many web servers written in python and each of them can
> serve at least 500 reqs/sec.
If anyone claimed a 3D graphics card could do 500 triangles/sec, people
would laugh. 500 frames/sec would be quite impressive, however, for complex
scenes. I just don't think we're working with the same definition of the
term "fast."
> The popular RPG game: Temple of Elemental Evil was written using
> python.
In Pygame, which is written on top of SDL, which is a C library. A
developer interview:
http://www.pygame.org/interview/stevemoret.shtml I'm guessing by the
screenshot they're using SDL's OpenGL layer. Python is proven useful for
the scripting aspects of games. It does not have the chops to implement 3D
engines.
You may say, no problem, just use Python and C++ to implement your full
system. But I don't believe in this kind of split development. It does not
help me for my AI problems, which need to be both high level and fast, in
the millions of instructions sense of the term. For 3D graphics problems,
it is a chore to bridge between C++ and any high level language. That chore
is acceptable if someone has already built a complete 3D engine that has all
the capabilities one needs, but I'd never choose a 2 language approach if
starting from scratch.
> but the real question should be: is
> python fast enough? Most of the times yes.
The only way that statement is true, is if you're speaking of all problem
domains. Most software is accounting software, so in that sense, "yes,"
you're right. This idea of "most of the time" completely breaks down when
one's problem domain is more specific. Python is *never* fast enough to
implement the core of a 3D engine.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
Brandon J. Van Every wrote:
> Valentino Volonghi aka Dialtone wrote:
>>
>> The popular RPG game: Temple of Elemental Evil was written using
>> python.
>
> In Pygame, which is written on top of SDL, which is a C library. A
> developer interview:
> http://www.pygame.org/interview/stevemoret.shtml I'm guessing by the
> screenshot they're using SDL's OpenGL layer. Python is proven useful
> for the scripting aspects of games. It does not have the chops to
> implement 3D engines.
I apologize, I completely spaced out actually reading the article once I
Googled for it. It's an interview with the ToEE developer that just happens
to appear on the Pygame website. ToEE was not written on Pygame, so my
deductions about SDL are spurious. However, one can reasonably infer from
the article that Python was only used for scripting. The "big worry" was
one (1) script that got called every frame. Let's be generous and say the
game ran at 120 fps. 120 invocations of a script per second is nothing.
Run it millions of times a second, then we'll talk.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."
> Brandon J. Van Every wrote:
>> Valentino Volonghi aka Dialtone wrote:
>>>
>>> The popular RPG game: Temple of Elemental Evil was written using
>>> python.
>>
>> http://www.pygame.org/interview/stevemoret.shtml
And BTW, the article strongly confirms my original points about "what Python
is good for." Python is excellent as a communal development language for
"relatively dumb" code. The article says:
"All the dialog writers used Python expressions to handle which dialog lines
were available to people, and the artists wrote simple Python statements to
emit particles or trigger visual effects during specific frames of
animation. In the end, I'd say over 1/2 of the team had touched Python code
at some point through the course of the development of the game."
I will wager 0 game artists touch lisp code. Would love to hear any
anecdotes to the contrary, even in hobbyist open source development.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Taking risk where others will not.
"Brandon J. Van Every" <·····························@yahoo.com> wrote:
> I will wager 0 game artists touch lisp code. Would love to hear any
> anecdotes to the contrary, even in hobbyist open source development.
Perhaps they don't talk about it, because if the competitors uses it, too,
they would lost an advantage, but there are some known stories:
http://groups.google.com/groups?selm=lak7reuqel.fsf%40buzz.in-fusio.com
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Perhaps they don't talk about it, because if the competitors uses it, too,
> they would lost an advantage, but there are some known stories:
>
> http://groups.google.com/groups?selm=lak7reuqel.fsf%40buzz.in-fusio.com
>
They mention the Final Fantasy Movie, and not all seemed to go well:
"Fluid naming convention : As mentioned above, the database operation
relied on the fact that all the data files followed well-defined naming
convention that the database knew. However, we needed to adjust naming
conventions constantly to address the problems in the production
pipeline, and the internals of the database had to be adjusted
constantly. Occasionally such changes were made locally rather than with
global consensus, and the database had to interpret several sets of
mutually incompatible rules (*8). Since the database was written in a
single monolithic server including the Web interface part, and written
in a rather uncommon language Lisp, all of such requests had to go
through only one or two programmers, and eventually this became a
bottleneck."
So, always bring enough programmers!
Following some links brought me this:
http://www.shiro.dreamhost.com/scheme/docs/jlugm2000.html
(Shooting A Moving Target---An Experience In Developing A Production
Tracking Database), which describes the DB used for the FF movie in more
detail.
...going off to read.
From: Brandon J. Van Every
Subject: game artists who touch Lisp (was: Python becoming less Lisp-like)
Date:
Message-ID: <39oc10F62ge32U1@individual.net>
Frank Buss wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> wrote:
>
>> I will wager 0 game artists touch lisp code. Would love to hear any
>> anecdotes to the contrary, even in hobbyist open source development.
>
> Perhaps they don't talk about it, because if the competitors uses it,
> too, they would lost an advantage, but there are some known stories:
>
> http://groups.google.com/groups?selm=lak7reuqel.fsf%40buzz.in-fusio.com
Naughty Dog is well known in the game industry for having used their
homespun Game Object Assembly Lisp. The question is, did their artists
touch it? Another question is, how similar to Common Lisp is it, from the
artist's point of view? Did Naughty Dog add any features to make it easier
for artists to manipulate?
Square is interesting for using straight up ACL (correct assumption?)
Again, what did the artists touch?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
> Brandon J. Van Every <·····························@yahoo.com> wrote:
> > Python's main disadvantage IMO is it's slow. I'm doing 3D graphics and game
> > AI, so slow matters to me. I want something compiled. I've seen little
> > compelling proof of concept in those problem domains. 3D, in particular,
> > always relies on some underlying C++ engine. Also game AI is a "roll my
> > own" problem, not a communal problem.
>
> It's not THAT slow. For example there's a VoIP software written in
> Python and a SIP server too with Stun and UPnP support.
About two years ago I tried to port code analyzing satellite images to
python. It was 1000 times (no typo!) slower than the C++ version.
When I prototyped a new algorithm in Python, I started the program,
then re-wrote the same algorithm in C++. I stopped doing that when I
realized that it took the Python program longer to complete on a
sample data set than me writing a C++ program, compile and execute.
Python fans told me just to write "the few speed-critical lines" as an
C extension. Unfortunately, these were the same lines that I had to
change all the time. So no productivity boost from that. (I also
disliked that I had to do my own reference counting in the C
extensions.)
> python fast enough? Most of the times yes. When it is not, anyway, there
> are many and confortable ways to make it faster: Pyrex, psyco, swig,
> pyasm, ctypes and so on.
This large number of workarounds just shows that there's a real
problem with speed.
Personally, I tried psyco (nice, but on my data 2x speedup only), swig
(not simple enough at that time), some C-inlining tool (cool, but why
not do it right in C). After that I returned to C++ and Matlab.
Python's kind of nice, very easy to teach, with tons of libraries.
But boy can it be slow...
Matthias Mar 15, 2:45 am wrote:
==
About two years ago I tried to port code analyzing satellite images to
python. It was 1000 times (no typo!) slower than the C++ version.
When I prototyped a new algorithm in Python, I started the program,
then re-wrote the same algorithm in C++. I stopped doing that when I
realized that it took the Python program longer to complete on a
sample data set than me writing a C++ program, compile and execute.
==
If that hadn't been done already (I have a hard time to follow google
discussion under the new scheme): please could you name the timings. Do
you speak of hours, or seconds when refering to "1000 times slower"?
As a scientist and Python hater and Bigloo admirer I would be
interested in your figures.
Förster vom Silberwald
PS: I wonder why Matlab/C++ gave you the boost but Python/C++ did not.
PSS: What prevents you from using CommonLisp/C++ for analyzing
satellite data?
"F�rster vom Silberwald" <··········@hotmail.com> writes:
> Matthias Mar 15, 2:45 am wrote:
> ==
> About two years ago I tried to port code analyzing satellite images to
> python. It was 1000 times (no typo!) slower than the C++ version.
>
> When I prototyped a new algorithm in Python, I started the program,
> then re-wrote the same algorithm in C++. I stopped doing that when I
> realized that it took the Python program longer to complete on a
> sample data set than me writing a C++ program, compile and execute.
> ==
>
> If that hadn't been done already (I have a hard time to follow google
> discussion under the new scheme): please could you name the timings. Do
> you speak of hours, or seconds when refering to "1000 times slower"?
Exactly. Seconds to minutes for C++ and several hours for Python. I
don't have the timings at my fingertips, but I did do them and the
1000 is accurate.
> PS: I wonder why Matlab/C++ gave you the boost but Python/C++ did not.
It's the libs.
Matlab is an ugly language with extremely nice libraries. The
libraries (for visualization, optimization, statistics in my case)
make up for the design errors in the language. I don't love it, but
it feels very productive. ;-)
But the main reason for Matlab is that it's the lingua franca in the
field. Everyone uses it. Many cool tools are available for it. I
don't want to spend my time re-implementing in another language stuff
readily available for Matlab.
> PSS: What prevents you from using CommonLisp/C++ for analyzing
> satellite data?
To start with: At the time I made the decision there was no simple way
to load an image/picture into the CL implementation of my choice
(cmucl).
Sure, I could implement this, and visualization, a good syntax for
arrays, fast & accurate numerics, etc. But that's not what I'm paid
for. And that's not what I want to do with my time. And frankly, I
don't believe that at the end the time invested to re-implement,
debug, document, and maintain all that stuff would pay off in
super-increased productivity. Of course, other people feel
differently and make different decisions. Fine with me.
Matthias Mar 15, 6:07 am wrote
==
Exactly. Seconds to minutes for C++ and several hours for Python. I
don't have the timings at my fingertips, but I did do them and the
1000 is accurate.
It's the libs.
Matlab is an ugly language with extremely nice libraries. The
libraries (for visualization, optimization, statistics in my case)
make up for the design errors in the language. I don't love it, but
it feels very productive. ;-)
==
In my field everyone uses IDL. However, I have never used it.
If I had to use some special functions I would try to make a binding
from Bigloo to the gnu scientific library.
It would be nice to have a place where to look up basic functions
written in plain simple C. The problem often with bindings: it is damn
hard. I wrote my own binding to the plotting library DISLIN. But I
would get stuck if I had to start writing a binding to lets say the R
language for statistics. The basic layout of the R language functions
in C is complicated.
I think it often depends on the individual whether he uses something
different than the mainstream. For example Python has been cheerled
quite a lot by F. Dubois in the journal "Computing in Science and
Engineering". As I understand it: Python is predestined for steering
code.
I for one steer legacy radiative transfer codes in Fortran by means of
Bigloo. I couldn't think of another way as to use Bigloo for pre- and
post-processing my tasks. I couldn't even think programming in Scheme
without adding some basic types:
--
(define
(add-vec::vector vec1::vector vec2::vector x::bint)
....)
--
Förster vom Silberwald
Matthias <····@spam.pls> wrote:
> Exactly. Seconds to minutes for C++ and several hours for Python. I
> don't have the timings at my fingertips, but I did do them and the
> 1000 is accurate.
This is way too much IMHO. There is a package called numarray that is
exactly used to work on satellite images from hubble space telescope.
http://www.stsci.edu/resources/software_hardware/numarray
> But the main reason for Matlab is that it's the lingua franca in the
> field. Everyone uses it. Many cool tools are available for it. I
> don't want to spend my time re-implementing in another language stuff
> readily available for Matlab.
Surely Matlab has a lot of good libraries optimized for this. But there
is plenty of packages to do a lot of the computations you need. For
example: matplotlib, numarray or Numeric, the scipy package and many
more like biopython (which has nothing to do with this particular
field).
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
> Matthias <····@spam.pls> wrote:
> > Exactly. Seconds to minutes for C++ and several hours for Python. I
> > don't have the timings at my fingertips, but I did do them and the
> > 1000 is accurate.
>
> This is way too much IMHO. There is a package called numarray that is
> exactly used to work on satellite images from hubble space telescope.
It's also too much in my opinion. I used numpy, I think. But each
time I lead an actual Python function operate on the image things
slowed down tremendously.
> Surely Matlab has a lot of good libraries optimized for this. But there
> is plenty of packages to do a lot of the computations you need. For
> example: matplotlib, numarray or Numeric, the scipy package and many
> more like biopython (which has nothing to do with this particular
> field).
Thanks for telling me what I need.
Matthias wrote:
> Exactly. Seconds to minutes for C++ and several hours for Python. I
> don't have the timings at my fingertips, but I did do them and the
> 1000 is accurate.
We are doing a major project that involves parsing some 2000-7000
hierarchical messages per second. We used the two-language approach,
Python and C, and re-wrote the speed-critical portions (the core
parsers) in C. The speed difference between optimized Python and
optimized C is 5x.
The C people aren't even ours, and suffice to say I am confident that
they are outstanding C programmers. They are using specialized
libraries that may be slow; not sure about that. But if my assumptions
are true (namely that the C programmers involved are good and the
libraries aren't terrible) the small speed difference in the case I
describe suggests either that you are a brilliant C++ programmer, a
so-so Python programmer, or both. I suspect it's both!
steve
"Steven D. Arnold" <·······@neosynapse.net> writes:
> Matthias wrote:
> > Exactly. Seconds to minutes for C++ and several hours for Python. I
> > don't have the timings at my fingertips, but I did do them and the
> > 1000 is accurate.
>
> We are doing a major project that involves parsing some 2000-7000
> hierarchical messages per second. We used the two-language approach,
> Python and C, and re-wrote the speed-critical portions (the core
> parsers) in C. The speed difference between optimized Python and
> optimized C is 5x.
>
> The C people aren't even ours, and suffice to say I am confident that
> they are outstanding C programmers. They are using specialized
> libraries that may be slow; not sure about that. But if my assumptions
> are true (namely that the C programmers involved are good and the
> libraries aren't terrible) the small speed difference in the case I
> describe suggests either that you are a brilliant C++ programmer, a
> so-so Python programmer, or both. I suspect it's both!
It's also possible that analyzing satellite images is very different
from parsing strings. Not all applications are equal.
On 15 Mar 2005 11:45:28 +0100, Matthias <····@spam.pls> wrote:
> Python's kind of nice, very easy to teach, with tons of libraries.
> But boy can it be slow...
Yes. Integer computation can be outrageously slow.
Did you try numpy? It's one forgiving feature for scientific computation.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Matthias wrote:
> About two years ago I tried to port code analyzing satellite images to
> python. It was 1000 times (no typo!) slower than the C++ version.
>
When talking about the speed of languages like Python, one has to look
at their implementation and performance characteristics.
Micro-performance, like in an integer addition i = i + 1 *is* extremly
slow, so the factor 1000 is a good estimate. (fetching the content of
i from the heap, adding 1, allocating new memory on the heap and store
the result there, not to forget to perform reference counting for the
heap operations...)
However, if you have a complex operation, like putting a value into a
hash table or sorting an array, these are single calls into native
libraries, so they are going to perform close to the speed of c-code.
This has two effects: these operations have about the same runtime as a
single integer operation, so what is to be considered as "optimal" code
in python is way different than for example C, so to create fast python
code, often different styles have to be used - takes some practise.
And the second thing is, the overall performance of a python program in
comparison to C depends on how much library functions can be used and
how much has to be written in python code itself. So writing a 3d
library from lowlevel python code isn't a good idea, but python using a
library like numpy or sdl might have quite decent performance. Reading a
file into a list of lines is a single python statement, so its as fast
as it gets.
As a result, there are some fast python programs, even if the language
itself isn't tuned for micro performance.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Ulrich Hobelmann wrote:
> But in C I can at least write "foo->a = a; foo->b = b; bla(); barz();"
> I don't want to use all whitespace and newlines, just because Mr van
> Rossum thinks that's cool.
You can use semicolons that way in Python too. Unless
Guido decides that they don't belong in Python either,
which now I come to think of it sounds uncomfortably
plausible. I hope he doesn't read comp.lang.lisp.
> Also, why should I learn the language? What compelling advantages
> does it have (again, except for libraries)?
Well, the libraries *are* pretty nice. Whether the
language has compelling advantages depends on what
you compare it to. Compared to Common Lisp, probably
not, but then what has? List comprehensions are
nice; various things are more dynamic than in Lisp,
which makes it easier to define new kinds of things
to iterate over or index into, etc. These are advantages,
but certainly not compelling ones, especially when
comparing with a language where almost any feature
you can imagine is only a macro away.
Compared to C++ or Java or Perl, it's a different
story. The syntax is at least reasonably clean (true
also of Java, but not C++ or Perl), dynamic typing
is in most contexts a clear win (advantage over C++
and Java, but not Perl), and so on.
I use Python all the time at work. I want my colleagues
to be able to read the code I write, and it's not
reasonable to expect them to become fluent in Lisp.
For most of the things I need to do, I can get by
without a truly programmable programming language;
the thing I miss most is the performance of Lisp,
but I can get that at a cost by writing critical portions
of the software in C or C++, something Python supports
quite well.
If I had no colleagues, or if I worked for a company
full of lispniks, then I'd almost always prefer to
write in Lisp. But I don't, and Python's not a bad
second choice. That, for me, is the really compelling
advantage; the language is *good enough*, and it fits
into the Rest of the World a bit better than Lisp does.
Oh, and the libraries are handy sometimes, too.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan wrote:
> If I had no colleagues, or if I worked for a company
> full of lispniks, then I'd almost always prefer to
> write in Lisp. But I don't, and Python's not a bad
> second choice. That, for me, is the really compelling
> advantage; the language is *good enough*, and it fits
> into the Rest of the World a bit better than Lisp does.
Sounds like a good compromise language. Maybe I'll learn it the next
time I do something with other people (instead of using Java then :( ).
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Python becoming less Lisp-like
Date:
Message-ID: <87ekei58k8.fsf@qrnik.zagroda>
Ulrich Hobelmann <···········@web.de> writes:
>> You took one look at Python and were turned off by the whitespace
>> significance? That reminds me of disliking Lisp because of the
>> parentheses. Both are fairly easy to work with once you get your
>> editor set up and become accustomed to them.
>> Really, what's the problem?
> But in C I can at least write "foo->a = a; foo->b = b; bla(); barz();"
> I don't want to use all whitespace and newlines, just because Mr van
> Rossum thinks that's cool.
You can use semicolons in Python too. Not all kinds of compound
statements can be written without newlines, but in this case it's
accepted.
I agree that bashing Python because of whitespace is like bashing Lisp
because of parentheses. Some people like it, some people hate it,
it's not a real obstacle but a matter of taste.
> Also, why should I learn the language? What compelling advantages
> does it have (again, except for libraries)?
Don't underestimate the power of libraries.
For example Python makes easy to access the Unix API.
There are many C libraries which have an already made interface to
Python (e.g. databases, Gtk+ / GNOME, mod_python for Apache, XML
stuff, network protocols, cryptography, talking to CVS, accessing
a Gmail account etc.).
In the above two categories only C/C++, Perl and maybe Java can beat it
(Java only in the second category I think, if at all - certainly not
under Linux).
Python has a sane Unicode support (separate byte strings and Unicode
strings, most libraries can work with both). This is a rare thing
among scripting languages: Unicode in Perl is being worked on but
sucks horribly, Ruby mostly ignores Unicode because it's Japanese,
and Lua ignores Unicode because it has a tiny runtime on top of C.
Python is quite easily embeddable in C (much easier than Perl, a bit
harder than Ruby, I don't know about Lua).
Python is easy to learn for beginners. This is not a reason to use it
if you are experienced and you can invest more time into learning, but
it is a reason why it became popular.
I think Python code written by other people is easy to read, especially
if the task is typical. Instead of providing a set of hyper-general
constructs which can be used to roll your own abstractions for common
tasks, it provides these common tasks directly. This increases the
likelihood that different programmers would model a given problem in
the same way, and thus one of them will immediately recognize the
other's model.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> For example Python makes easy to access the Unix API.
And meanwhile, CL's portable Posix library is still in the planning
stages. :-(
I really ought to give those guys a hand. File streams and sockets
cover a lot of what I do, but I can forsee times where I'll really want
access to everything.
And speaking of Python's libraries... Hmmm. The FOIL people have
created interfaces for Java and C#, could Python be harder than those?
I'm guessing it would be easier, C# and Java are statically typed.
Hmmm...
James Graves
Ulrich Hobelmann wrote:
> Jacek Generowicz wrote:
>> Aaaargh, don't remind me. It pissed me off so much when I read in on
>> Friday, that I didn't want look at Python all day ...
>
> Why look at Python at all? One day I went to their website, saw the
> whitespace syntax and Yet-Another-Imperative-Scripting-Language.
> Didn't look at Python ever again.
>
> If someone forces me into scripting I will take a closer look at Ruby
> and Lua.
Lua is very capable as a lightweight embeddable scripting language, as it
was designed to be. It is of no use as a systems language. Python has a
major advantage there. Someone at the Python convention last year gave a
talk entitled "Scripting Language My Ass" IIRC. Python could really stand a
marketing campaign to overcome the idea that it's only capable of scripting.
But, that crowd can't market, so....
Ruby is like Python done by Perl programmers, so I am told. It doesn't have
the user base of Python.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
On Mon, 14 Mar 2005 14:51:06 -0800, "Brandon J. Van Every"
<·····························@yahoo.com> wrote:
>Ruby is like Python done by Perl programmers, so I am told. It doesn't have
>the user base of Python.
Rather by smalltalkers. ;-)
Ulrich Hobelmann <···········@web.de> writes:
> Jacek Generowicz wrote:
> > Aaaargh, don't remind me. It pissed me off so much when I read in on
> > Friday, that I didn't want look at Python all day ...
>
> Why look at Python at all?
Because I get paid to do so.
Because it is so much better than so many of the alternatives.
Because, for a certain kind of programmer (the kind I have to cater
for) it is a very good solution.
> That's Python. They might have nicer ad-hoc solutions than the
> C-dialects, but the whitespaces: uuuh.
While the whitespace has it's problems, it actually solves some
problems to. At a certain level, I think it is an excellent idea. And
my job involves catering for that level.
Jacek Generowicz wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>>Why look at Python at all?
>
>
> Because I get paid to do so.
Oh, for a job I wouldn't mind Python at all. Most jobs force you to
Java and C, so that's a rather good deal ;)
> Because it is so much better than so many of the alternatives.
If the above two are the alternatives, yes. (and if you need certain
libraries, I guess, too)
On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel <·····@gigamonkeys.com>
wrote:
>Looks like the BDFL is planning to take lambda, reduce, filter, and
>map out of Python in the next big rev of Python (so called Python
>3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
Basically, it says that it will get rid of the explicit map, filter
and reduce and substitute them by some syntactic sugar that uses them
implicitly. That's ok, and not a big deal.
It will also get rid of lambda, and it's not a great loss, since
python's version is so limited that it's almost useless. Besides,
given the syntactic sugar used to replace map, reduce and filter,
there's no real need for lambda in the most usual cases.
The real problem with Python is that it has been very successful as a
scripting language in the static-typing/C/C++ world. Those
programmers, instead of adapting their evil ways to Python, and
realizing the advantages of a dynamic language, are influencing
Python's design and forcing it into the static-typing mold. Python is
going the C++ way: piling feature upon feature, adding bells and
whistles while ignoring or damaging its core design.
The new 'perlified' syntax for decorators, the new static type bonds
and the weird decision to kill lambda instead of fixing it are good
examples that show that Python is going the wrong way. What used to be
a cool language will soon be an interpreted C/C++ without any
redeeming value. A real pity...
Hallöchen!
Fernando <···@easyjob.net> writes:
> [...]
>
> [...] Python is going the C++ way: piling feature upon feature,
> adding bells and whistles while ignoring or damaging its core
> design.
I'm new to Python, but I while I skimmed through the "What's new?"
of recent versions, I saw the same unfortunate development.
Moreover, I dislike the fact that new features are implemented
partly in the interpreter and partly in Python itself. It reminds
me of TeX/LaTeX, where the enormous flexibility of TeX is used to
let it change itself in order to become a LaTeX compiler. However,
the underlying constructs are utterly ugly, as are some of Python's
features (e.g. __getattr__ and such, and decorators, in order to get
nice class properties).
> The new 'perlified' syntax for decorators,
Python lost its innocence here: The first really special character,
disturbing the former syntax style. Not important, but irritating.
> the new static type bonds
What is meant by that?
> [...] What used to be a cool language will soon be an interpreted
> C/C++ without any redeeming value. A real pity...
I don't think so, there will be always an enormous difference. But
Python seems a little bit chaotic.
I looked for a new language for my hobby programming. I used to use
Turbo Pascal for 10 years and then C++ for 6 years. A couple of
weeks ago, I narrowed my decision to C#, Ruby, and Python. At the
moment, I want to go with Python, but you can definitely see that
it's the oldest one: Many parts of its syntax are awkward and look
like patchwork.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Hallöchen!
Fernando <···@easyjob.net> writes:
> [...]
>
> [...] Python is going the C++ way: piling feature upon feature,
> adding bells and whistles while ignoring or damaging its core
> design.
I'm new to Python, but I while I skimmed through the "What's new?"
of recent versions, I saw the same unfortunate development.
Moreover, I dislike the fact that new features are implemented
partly in the interpreter and partly in Python itself. It reminds
me of TeX/LaTeX, where the enormous flexibility of TeX is used to
let it change itself in order to become a LaTeX compiler. However,
the underlying constructs are utterly ugly, as are some of Python's
features (e.g. __getattr__ and such, and descriptors, in order to
get nice class properties).
> The new 'perlified' syntax for decorators,
Python lost its innocence here: The first really special character,
disturbing the former syntax style. Not important, but irritating.
> the new static type bonds
What is meant by that?
> [...] What used to be a cool language will soon be an interpreted
> C/C++ without any redeeming value. A real pity...
I don't think so, there will be always an enormous difference. But
Python seems a little bit chaotic.
I looked for a new language for my hobby programming. I used to use
Turbo Pascal for 10 years and then C++ for 6 years. A couple of
weeks ago, I narrowed my decision to C#, Ruby, and Python. At the
moment, I want to go with Python, but you can definitely see that
it's the oldest one: Many parts of its syntax are awkward and look
like patchwork.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Torsten Bronger wrote:
> Hallöchen!
Tach!
> Moreover, I dislike the fact that new features are implemented
> partly in the interpreter and partly in Python itself. It reminds
> me of TeX/LaTeX, where the enormous flexibility of TeX is used to
> let it change itself in order to become a LaTeX compiler. However,
> the underlying constructs are utterly ugly, as are some of Python's
> features (e.g. __getattr__ and such, and descriptors, in order to
> get nice class properties).
Well, I think TeX is just an awful, weird language with (AFAIK) dynamic
scoping. Thinking of Lisp macros, I'd say that implementing features on
top of a small language core is GREAT!
Maybe You can answer my question what this simple LISP function does ?
(defun addn (n)
#'(lambda (x)
(+ x n)))
This is correct LISP-syntax if You bear in mind LISPs powerwull macro
language...
I think Guido and python-dev are very carefull in adding new power to
Python. They have to balance the needs for powerfull language features
on the one hand, simplicity on the other hand. That this relation
drifts towards more power and more complexity since Python 2.2. is a
correct observation, but You probably may have notized that the number
of large projects using Python as their primal language is growing. The
boundary between that what was formerly called "systems programming"
and "scripting" is blurred ( if Your mindset reduces
"systems-programming" on the availability of pointers You certainly
don't have any problems with the common public prejudices ).
> The real problem with Python is that it has been very successful as a
> scripting language in the static-typing/C/C++ world. Those
> programmers, instead of adapting their evil ways to Python, and
> realizing the advantages of a dynamic language, are influencing
> Python's design and forcing it into the static-typing mold. Python is
> going the C++ way: piling feature upon feature, adding bells and
> whistles while ignoring or damaging its core design.
Maybe You should explain what You regard as Pythons "core design", what
belongs to the core and what to the periphery? Otherwise Your statement
seems to be plain emotional.
> The new 'perlified' syntax for decorators, the new static type bonds
> and the weird decision to kill lambda instead of fixing it are good
> examples that show that Python is going the wrong way.
My hypothesis about lambda: lambda will be trashed because it is an
alien in the language. It is impure. Trashing it is an expression of
Pythons rassism. There is no way of "doing it right" without exceeding
it's power and making it less controlable. When Guido once stated that
the generator way of doing things is Pythons future it was also a
renouncement of lambda. Compared with this ideological orientation the
introduction of the @-syntax is a minor sacrilege on syntax esthetics -
though this special character may hurd the souls of the believers more
that everything else introduced into the language.
Kay
"Kay Schluehr" <············@gmx.net> wrote
> Maybe You can answer my question what this simple LISP function does ?
It obviously returns a function adding n to the function's parameter,
n being bound into the functions's closure during the call to ADDN.
It's simple and straightforward.
> This is correct LISP-syntax if You bear in mind LISPs powerwull macro
> language...
Actually, this suffices:
(defun addn (n)
(lambda (x)
(+ x n)))
And Lisp's "macro language" isn't involved at all here.
> (defun addn (n)
> (lambda (x)
> (+ x n)))
>
> And Lisp's "macro language" isn't involved at all here.
(macroexpand-1 '(lambda (x) (+ x n))) => #'(LAMBDA (X) (+ X N))
Also, #' is a read-macro. Fully expanded the #'(lambda expression
would be
(function (lambda (x) (+ x n)))
Then there's the "defun" macro . . . .
:-)
--
Fred Gilham ······@csl.sri.com
A common sense interpretation of the facts suggests that a
superintellect has monkeyed with physics, as well as with chemistry
and biology, and that there are no blind forces worth speaking about
in nature. --- Fred Hoyle
Fred Gilham <······@snapdragon.csl.sri.com> wrote
> > And Lisp's "macro language" isn't involved at all here.
> Also, #' is a read-macro.
A read-macro and a macro aren't the same thing.
> Then there's the "defun" macro . . . .
There is IMHO a difference between using a macro and using the "macro language".
·············@swipnet.se (Peter Lewerin) writes:
> Fred Gilham <······@snapdragon.csl.sri.com> wrote
>
> > > And Lisp's "macro language" isn't involved at all here.
>
> > Also, #' is a read-macro.
>
> A read-macro and a macro aren't the same thing.
>
> > Then there's the "defun" macro . . . .
>
> There is IMHO a difference between using a macro and using the
> "macro language".
What macro language? Common-Lisp?
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
Pascal Bourguignon <····@mouse-potato.com> wrote
> ·············@swipnet.se (Peter Lewerin) writes:
> > There is IMHO a difference between using a macro and using the
> > "macro language".
>
> What macro language? Common-Lisp?
OP wrote "This is correct LISP-syntax if You bear in mind LISPs
powerwull[sic] macro language...".
My perception was that the code he presented did not explicitly use
any language mechanisms specifically related to the construction of
macros.
I may be confused.
·············@swipnet.se (Peter Lewerin) writes:
> Pascal Bourguignon <····@mouse-potato.com> wrote
>
> > ·············@swipnet.se (Peter Lewerin) writes:
> > > There is IMHO a difference between using a macro and using the
> > > "macro language".
> >
> > What macro language? Common-Lisp?
>
> OP wrote "This is correct LISP-syntax if You bear in mind LISPs
> powerwull[sic] macro language...".
>
> My perception was that the code he presented did not explicitly use
> any language mechanisms specifically related to the construction of
> macros.
Yes.
> I may be confused.
No.
But since the whole Common-Lisp language is available to write macros
in Common-Lisp, Common-Lisp IS the macro language of Common-Lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
Peter Lewerin wrote:
> "Kay Schluehr" <············@gmx.net> wrote
>
>>Maybe You can answer my question what this simple LISP function does ?
>
> It obviously returns a function adding n to the function's parameter,
> n being bound into the functions's closure during the call to ADDN.
> It's simple and straightforward.
This is off-topic for comp.lang.python. Follow-ups set.
--
Michael Hoffman
Kay> Maybe You can answer my question what this simple LISP function does ?
Kay> (defun addn (n)
Kay> #'(lambda (x)
Kay> (+ x n)))
Is that a real question or are you making a rhetorical point here?
Kay> This is correct LISP-syntax if You bear in mind LISPs powerwull macro
Kay> language...
It's indeed correct CL syntax, but I don't see much macro usage in there.
Try (mapcar (addn 4) (list 1 2 3))...
Ole
On 15 Mar 2005 00:43:49 -0800, "Kay Schluehr" <············@gmx.net>
wrote:
>Maybe You can answer my question what this simple LISP function does ?
>
>(defun addn (n)
> #'(lambda (x)
> (+ x n)))
The same as
def addn(n):
def fn(x):
return n + x
return fn
>This is correct LISP-syntax if You bear in mind LISPs powerwull macro
>language...
defun is a macro but I don't think that's what you mean...
Fernando <···@easyjob.net> writes:
>
> On 15 Mar 2005 00:43:49 -0800, "Kay Schluehr" <············@gmx.net>
> wrote:
>
> >Maybe You can answer my question what this simple LISP function does ?
> >
> >(defun addn (n)
> > #'(lambda (x)
> > (+ x n)))
>
> The same as
> def addn(n):
> def fn(x):
> return n + x
> return fn
Is this really equivalent?
What happens if you call addn more than once with different
parameters. Will you get different functions that you can
use simultaneously?
The lisp snippet creates new functions each time the addn function is
called, so one can interleave calls to the individual functions.
--
Thomas A. Russ, USC/Information Sciences Institute
On Tue, 15 Mar 2005 14:16:09 -0800, Thomas A. Russ wrote:
> The lisp snippet creates new functions each time the addn function is
> called, so one can interleave calls to the individual functions.
Yes, I believe them to be equivalent. Each call to addn creates an
activation record which is closed over by fn.
foo = addn(5)
bar = addn(6)
foo(4)
=> 9
bar(4)
=> 10
Matt
--
"You do not really understand something unless you can explain it to your
grandmother." — Albert Einstein.
Thomas A. Russ wrote:
> Fernando <···@easyjob.net> writes:
>
>
>>On 15 Mar 2005 00:43:49 -0800, "Kay Schluehr" <············@gmx.net>
>>wrote:
>>
>>
>>>Maybe You can answer my question what this simple LISP function does ?
>>>
>>>(defun addn (n)
>>> #'(lambda (x)
>>> (+ x n)))
>>
>>The same as
>>def addn(n):
>> def fn(x):
>> return n + x
>> return fn
>
>
> Is this really equivalent?
AFAIK, yes. I admit that I know almost nothing about Lisp though. And
I'm not a Python guru either.
> What happens if you call addn more than once with different
> parameters. Will you get different functions that you can
> use simultaneously?
Yes. Using the addn function defined above, you can do for example:
>>> add4 = addn(4)
>>> add10 = addn(10)
>>> add4(5)
9
>>> add10(7)
17
>>> add4(add10(28))
42
And so on. At least, I think that's what you mean.
--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton
Roel Schroeven
Thomas A. Russ <···@sevak.isi.edu> wrote:
> > >(defun addn (n)
> > > #'(lambda (x)
> > > (+ x n)))
> >
> > The same as
> > def addn(n):
> > def fn(x):
> > return n + x
> > return fn
>
> Is this really equivalent?
yes
> What happens if you call addn more than once with different
> parameters. Will you get different functions that you can
> use simultaneously?
yes
> The lisp snippet creates new functions each time the addn function is
> called, so one can interleave calls to the individual functions.
In [21]: a = addn(4)
In [22]: b = addn(5)
In [23]: c = addn(25)
In [24]: a(1)
Out[24]: 5
In [25]: b(1)
Out[25]: 6
In [26]: c(1)
Out[26]: 26
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
···@sevak.isi.edu (Thomas A. Russ) writes:
>> >(defun addn (n)
>> > #'(lambda (x)
>> > (+ x n)))
>>
>> The same as
>> def addn(n):
>> def fn(x):
>> return n + x
>> return fn
>
> Is this really equivalent?
>
> What happens if you call addn more than once with different
> parameters. Will you get different functions that you can
> use simultaneously?
Yes.
It also behaves correctly when a variable it refers to is later
mutated.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
···@sevak.isi.edu (Thomas A. Russ) writes:
>> >(defun addn (n)
>> > #'(lambda (x)
>> > (+ x n)))
>>
>> The same as
>> def addn(n):
>> def fn(x):
>> return n + x
>> return fn
>
> Is this really equivalent?
>
> What happens if you call addn more than once with different
> parameters. Will you get different functions that you can
> use simultaneously?
Yes.
It also behaves correctly when a variable it refers to is later
mutated.
BTW, the fact that a closure refers to a variable itself rather to its
current value can be used to check the true attitude of languages with
respect to functional programming, by observing how they understand
their basic loops :-)
Python loses:
>>> closures = []
>>> for i in range(10):
... def add(x):
... return x + i
... closures.append(add)
...
>>> closures[5](1000)
1009
as does Ruby:
$ ruby -e '
closures = []
for i in 0..9 do
closures.push(proc {|x| x + i})
end
puts closures[5][1000]'
1009
but Lisp loses too:
> (let ((closures (make-array 10)))
(do ((i 0 (+ i 1)))
((= i 10))
(setf (svref closures i) #'(lambda (x) (+ x i))))
(funcall (svref closures 5) 1000))
1010
Scheme wins:
> (let ((closures (make-vector 10)))
(do ((i 0 (+ i 1)))
((= i 10))
(vector-set! closures i (lambda (x) (+ x i))))
((vector-ref closures 5) 1000))
1005
and what is perhaps surprising, Perl wins:
$ perl -e '
foreach my $i (0..9) {
push @closures, sub {$_[0] + $i}
}
print $closures[5](1000), "\n"'
1005
If you think it's unlikely that one would want to keep a closure
referring to a loop control variable longer than the loop iteration
which has created it, think about the loop body spawning a thread.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> BTW, the fact that a closure refers to a variable itself rather to its
> current value can be used to check the true attitude of languages with
> respect to functional programming, by observing how they understand
> their basic loops :-)
The thread "Midfunction Recursion"� from October 2002 sounds relevant
here, exploring options for bindings in iteration.
Footnotes:
� http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/422226bb18e56cad/0590de10f975a059
--
Steven E. Harris
Marcin 'Qrczak' Kowalczyk wrote:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
> >> >(defun addn (n)
> >> > #'(lambda (x)
> >> > (+ x n)))
> >>
> >> The same as
> >> def addn(n):
> >> def fn(x):
> >> return n + x
> >> return fn
> >
> > Is this really equivalent?
> >
> > What happens if you call addn more than once with different
> > parameters. Will you get different functions that you can
> > use simultaneously?
>
> Yes.
>
> It also behaves correctly when a variable it refers to is later
> mutated.
>
>
> BTW, the fact that a closure refers to a variable itself rather to
its
> current value can be used to check the true attitude of languages
with
> respect to functional programming, by observing how they understand
> their basic loops :-)
>
> Python loses:
>
> >>> closures = []
> >>> for i in range(10):
> ... def add(x):
> ... return x + i
> ... closures.append(add)
> ...
> >>> closures[5](1000)
> 1009
I had a minor discussion on this a couple weeks ago, wherein I
suggested that Python does it that way because nested scopes weren't
specifically done to enhance functional programming. (It's not a
secret that Python is moving away from abstract functional support.)
For example, Python might lose when it comes to functional programming,
but it wins when it comes to nested functions like this (where a,b,c,d
are in the enclosing scope and presumably changing):
def print_variables():
print a,b,c,d
If Python did it the way Scheme did, this would be pretty useless.
IMO, this sort of usage is FAR more common than the functional usage as
a closure inside a loop.
Closing on a value rather than a variable would have been a lot easier
to implement. I'm sure there was talk about which way to do it in the
discussions about adding nested scopes to the language, and if the
Python gods felt closing on a variable wasn't significantly more useful
than closing on a value, I doubt they would have done that.
> If you think it's unlikely that one would want to keep a closure
> referring to a loop control variable longer than the loop iteration
> which has created it, think about the loop body spawning a thread.
Yes, it does happen here and there. I've needed to do that in GUI
programming. But I would say it's not remotely as common as it other
uses, and is easy to work around:
> >>> closures = []
> >>> for i in range(10):
> ... def defineadder(y):
> ... def add(x):
> ... return x + y
> ... return add
> ... closures.append(defineadder(i))
> ...
> >>> closures[5](1000)
> 1005
--
CARL BANKS
Or, just to impress Lispers,
>>> def add(x,y):
... return x + y
>>> closures = []
>>> for i in range(10):
... closures.append(add.__get__(i))
...
>>> closures[5](1000)
1005
Remember, in Python do not have functions, we have descriptors! ;)
Michele Simionato
Carl Banks:
> Python might lose when it comes to functional programming,
> but it wins when it comes to nested functions like this (where
a,b,c,d
> are in the enclosing scope and presumably changing):
> def print_variables():
> print a,b,c,d
Yes, clearly if I have
def toplevel():
a = 1
def f():
print a
a = 2
f()
toplevel()
I want 2 to be printed, not 1.
> If Python did it the way Scheme did, this would be pretty useless.
But notice that Scheme has no problems whatsoever:
(define (toplevel)
(define a 1)
(define (f)
(display a))
(set! a 2)
(f))
(toplevel)
prints 2 the same as in Python.
> IMO, this sort of usage is FAR more common than the functional usage
as
> a closure inside a loop.
Maybe, but for me it is quite common to have closures inside loops
(typically for callbacks in Tkinter or a Web framework).
> Closing on a value rather than a variable would have been a lot
easier
> to implement. I'm sure there was talk about which way to do it in
the
> discussions about adding nested scopes to the language, and if the
> Python gods felt closing on a variable wasn't significantly more
useful
> than closing on a value, I doubt they would have done that.
I have no doubt about that. Still, there are people who disagrees
with Guido's choice, even on python-dev. This was a tough decision
to make, with pros and contras. It would be possible to change
the current default and have a more Schemish/Haskellish syntax
for loops: it would be enough to internally convert something like
result = []
for i in range(10):
result.append(lambda : i)
into
result = []
def for_block(i):
result.append(lambda : i)
for i in range(10): for_block(i)
However this approach has a drawback (which is not there in Scheme,
since Scheme has set!): if a new scope was created at each iteration
(which is what the function call is doing) we could not reassign
variables (i.e. they would become names locals to the "for" scope,
touching them would not affect variables outside the scope).
So this idiom
a = ""
for i in range(10):
if i == 5: a = "5 was reached"
print a
would not work. So, as I said, there are pros and contros.
Personally, I like better the Scheme way (what I do not like
in Scheme is the issue of inner defines vs. toplevel defines,
but this is another story).
Michele Simionato
Michele Simionato wrote:
> Carl Banks:
> > If Python did it the way Scheme did, this would be pretty useless.
>
> But notice that Scheme has no problems whatsoever:
>
> (define (toplevel)
> (define a 1)
> (define (f)
> (display a))
> (set! a 2)
> (f))
>
> (toplevel)
>
> prints 2 the same as in Python.
Hmm. On closer inspection, I'm going to have to amend my implictation
of Scheme: the example poster was cheating. Scheme and Python both do
closures the same way. However, the Scheme snippet in the original
example used a let-block. I.e., it introduced a new scope, whereas the
Python example did not (because it doesn't have anything like let).
--
CARL BANKS
"Carl Banks" <············@aerojockey.com> writes:
> Michele Simionato wrote:
> > Carl Banks:
> > > If Python did it the way Scheme did, this would be pretty useless.
> >
> > But notice that Scheme has no problems whatsoever:
> >
> > (define (toplevel)
> > (define a 1)
> > (define (f)
> > (display a))
> > (set! a 2)
> > (f))
> >
> > (toplevel)
> >
> > prints 2 the same as in Python.
>
> Hmm. On closer inspection, I'm going to have to amend my implictation
> of Scheme: the example poster was cheating. Scheme and Python both do
> closures the same way. However, the Scheme snippet in the original
> example used a let-block. I.e., it introduced a new scope, whereas the
> Python example did not (because it doesn't have anything like let).
Yes, we've been over this many times. I'm surprised that Michele
hasn't yet referenced the thread where we exposed the gory details, as
was his custom for a while :-)
Message-ID: <···············@pcepsft001.cern.ch>, for this particular
aspect, in case anyone gives a monkey's left testicle.
> I'm surprised that Michele
>hasn't yet referenced the thread where we exposed the gory details, as
>was his custom for a while :-)
>Message-ID: <···············@pcepsft001.cern.ch>, for >this particular
>aspect, in case anyone gives a monkey's left testicle.
I had forgot the title of that thread and also I wanted
to spare the poor monkeys :)
Michele Simionato wrote:
> However this approach has a drawback (which is not there in Scheme,
> since Scheme has set!): if a new scope was created at each iteration
> (which is what the function call is doing) we could not reassign
> variables (i.e. they would become names locals to the "for" scope,
> touching them would not affect variables outside the scope).
There is a middle way: the for-loop could be made
to create a new binding for its control variable
on each iteration, while the body continues to
execute in the outer scope as before.
It would actually be very easy to implement this
in CPython the way it currently works. Guido seems
to be against this sort of thing, though, as he
seems to regard it as a useful feature that the
for-loop control variable is not local to the
loop.
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
But then why he agreed to have the loop variable disappear outside a
generator comprehension?
I think there is something more than a backward compatibility concern.
Michele Simionato
>>>>> "Michele" == michele simionato <·················@gmail.com> writes:
Michele> But then why he agreed to have the loop variable
Michele> disappear outside a generator comprehension? I think
Michele> there is something more than a backward compatibility
Michele> concern.
With normal for-loop (as opposed to genexps and LCs), the "last" value
of the loop variable might be useful outside the loop if the loop was
exited prematurely through 'break' statement or exception.
--
Ville Vainio http://tinyurl.com/2prnb
"Carl Banks" <············@aerojockey.com> writes:
>> BTW, the fact that a closure refers to a variable itself rather to
>> its current value can be used to check the true attitude of
>> languages with respect to functional programming, by observing how
>> they understand their basic loops :-)
> Closing on a value rather than a variable would have been a lot easier
> to implement.
To be clear: closing on the variable is the only sane choice. Closing
on its current value would be inconsistent with global variables and
no language does this.
The issue is about the semantics of loops: whether they introduce
a new variable for each iteration, or change the value of a single
variable.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> The issue is about the semantics of loops: whether they introduce
> a new variable for each iteration, or change the value of a single
> variable.
Yes, I see what you are saying now. Good point.
--
CARL BANKS
Marcin 'Qrczak' Kowalczyk wrote:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
>
>>>>(defun addn (n)
>>>> #'(lambda (x)
>>>> (+ x n)))
>>>
>>>The same as
>>>def addn(n):
>>> def fn(x):
>>> return n + x
>>> return fn
>>
>>Is this really equivalent?
>>
>>What happens if you call addn more than once with different
>>parameters. Will you get different functions that you can
>>use simultaneously?
>
>
> Yes.
>
> It also behaves correctly when a variable it refers to is later
> mutated.
>
>
> BTW, the fact that a closure refers to a variable itself rather to its
> current value can be used to check the true attitude of languages with
> respect to functional programming, by observing how they understand
> their basic loops :-)
None of the examples you show close over values. The difference is in
whether the loop constructs use one binding for their control variable
or create new bindings in each iteration:
(loop for i below 10
collect (lambda (x) (setq i x)) into setters
collect (lambda () i) into getters
finally
(print (funcall (elt getters 0)))
(funcall (elt setters 4) 42)
(print (funcall (elt getters 9))))
=> 10
=> 42
If this difference matters to you, just be more explicit.
Pascal
On Wed, 16 Mar 2005 00:36:40 +0100, Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
>···@sevak.isi.edu (Thomas A. Russ) writes:
>
>>> >(defun addn (n)
>>> > #'(lambda (x)
>>> > (+ x n)))
>>>
>>> The same as
>>> def addn(n):
>>> def fn(x):
>>> return n + x
>>> return fn
>>
>> Is this really equivalent?
>>
>> What happens if you call addn more than once with different
>> parameters. Will you get different functions that you can
>> use simultaneously?
>
>Yes.
>
>It also behaves correctly when a variable it refers to is later
>mutated.
>
>
>BTW, the fact that a closure refers to a variable itself rather to its
>current value can be used to check the true attitude of languages with
>respect to functional programming, by observing how they understand
>their basic loops :-)
>
>Python loses:
>
>>>> closures = []
>>>> for i in range(10):
>... def add(x):
>... return x + i
>... closures.append(add)
>...
>>>> closures[5](1000)
>1009
Fire the coach -- the team can do it ;-)
One way is with the help of a byte-code-hacking decorator:
>>> from ut.presets import presets
>>> closures = []
>>> for i in range(10):
... @presets(i=i)
... def add(x):
... return x + i
... closures.append(add)
...
>>> closures[5](1000)
1005
>>> import dis
>>> dis.dis(closures[5])
2 0 LOAD_CONST 1 (5)
3 STORE_FAST 1 (i)
4 6 LOAD_FAST 0 (x)
9 LOAD_FAST 1 (i)
12 BINARY_ADD
13 RETURN_VALUE
>>> dis.dis(closures[3])
2 0 LOAD_CONST 1 (3)
3 STORE_FAST 1 (i)
4 6 LOAD_FAST 0 (x)
9 LOAD_FAST 1 (i)
12 BINARY_ADD
13 RETURN_VALUE
Of course, if you want to do it without byte code hacking, you can:
>>> closures2 = list((lambda i: lambda x: x + i)(i) for i in xrange(10))
>>> closures2[5](1000)
1005
>>> dis.dis(closures2[5])
1 0 LOAD_FAST 0 (x)
3 LOAD_DEREF 0 (i)
6 BINARY_ADD
7 RETURN_VALUE
>>> closures2[3](1000)
1003
Or same thing without lambda:
>>> def mkadd(i):
... def add(x): return x + i
... return add
...
>>> closures3 = [mkadd(i) for i in xrange(10)]
>>> closures3[5](1000)
1005
>>> closures3[3](1000)
1003
>>> dis.dis(closures3[5])
2 0 LOAD_FAST 0 (x)
3 LOAD_DEREF 0 (i)
6 BINARY_ADD
7 RETURN_VALUE
>
>as does Ruby:
>
>$ ruby -e '
> closures = []
> for i in 0..9 do
> closures.push(proc {|x| x + i})
> end
> puts closures[5][1000]'
>1009
>
>but Lisp loses too:
>
>> (let ((closures (make-array 10)))
> (do ((i 0 (+ i 1)))
> ((= i 10))
> (setf (svref closures i) #'(lambda (x) (+ x i))))
> (funcall (svref closures 5) 1000))
>1010
>
>
>Scheme wins:
>
>> (let ((closures (make-vector 10)))
> (do ((i 0 (+ i 1)))
> ((= i 10))
> (vector-set! closures i (lambda (x) (+ x i))))
> ((vector-ref closures 5) 1000))
>1005
>
>and what is perhaps surprising, Perl wins:
>
>$ perl -e '
> foreach my $i (0..9) {
> push @closures, sub {$_[0] + $i}
> }
> print $closures[5](1000), "\n"'
>1005
>
>
>If you think it's unlikely that one would want to keep a closure
>referring to a loop control variable longer than the loop iteration
>which has created it, think about the loop body spawning a thread.
>
Just do what you need to do. Python usually provides a way ;-)
Or do you just want what you want using your idea of the right spelling? ;-)
Regards,
Bengt Richter
On Wed, 16 Mar 2005 00:36:40 +0100, Marcin 'Qrczak' Kowalczyk
<······@knm.org.pl> wrote:
>
>
>BTW, the fact that a closure refers to a variable itself rather to its
>current value can be used to check the true attitude of languages with
>respect to functional programming, by observing how they understand
>their basic loops :-)
>
>Python loses:
>
>>>> closures = []
>>>> for i in range(10):
>... def add(x):
>... return x + i
>... closures.append(add)
>...
>>>> closures[5](1000)
>1009
>
[snip]
>Scheme wins:
>
>> (let ((closures (make-vector 10)))
> (do ((i 0 (+ i 1)))
> ((= i 10))
> (vector-set! closures i (lambda (x) (+ x i))))
> ((vector-ref closures 5) 1000))
>1005
>
>and what is perhaps surprising, Perl wins:
>
>$ perl -e '
> foreach my $i (0..9) {
> push @closures, sub {$_[0] + $i}
> }
> print $closures[5](1000), "\n"'
>1005
Smalltalk 'loses' too:
closures := Array new: 10.
1 to: 10 do: [:i |
closures at: i put: [:x| x + i]].
(closures at: 5) value: 1000
returns 1011
>If you think it's unlikely that one would want to keep a closure
>referring to a loop control variable longer than the loop iteration
>which has created it, think about the loop body spawning a thread.
I'm still not convinced this is really useful, but Scheme's behavior
seems more intuitive.
Fernando wrote:
> On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel
<·····@gigamonkeys.com>
> wrote:
>
> >Looks like the BDFL is planning to take lambda, reduce, filter, and
> >map out of Python in the next big rev of Python (so called Python
> >3000):
> >
> > <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
>
> Basically, it says that it will get rid of the explicit map, filter
> and reduce and substitute them by some syntactic sugar that uses them
> implicitly. That's ok, and not a big deal.
>
> It will also get rid of lambda, and it's not a great loss, since
> python's version is so limited that it's almost useless. Besides,
> given the syntactic sugar used to replace map, reduce and filter,
> there's no real need for lambda in the most usual cases.
>
> The real problem with Python is that it has been very successful as a
> scripting language in the static-typing/C/C++ world. Those
> programmers, instead of adapting their evil ways to Python, and
> realizing the advantages of a dynamic language, are influencing
> Python's design and forcing it into the static-typing mold. Python is
> going the C++ way: piling feature upon feature, adding bells and
> whistles while ignoring or damaging its core design.
You're wrong about design: http://www.artima.com/intv/pyscale.html
Quoting Guido: The first sound bite I had for Python was, "Bridge
the gap between the shell and C." So I never intended Python to be
the primary language for programmers.
>
> The new 'perlified' syntax for decorators, the new static type bonds
> and the weird decision to kill lambda instead of fixing it are good
> examples that show that Python is going the wrong way. What used to
> be a cool language will soon be an interpreted C/C++ without any
> redeeming value. A real pity...
Yeah, that was a good time. After a nice bridge between the shell
and C was built they never ceased piling feature upon feature and
kept adding bells and wristles.
Serge.
Fernando wrote:
> The real problem with Python is ... Python is
> going the C++ way: piling feature upon feature, adding bells
> and whistles while ignoring or damaging its core design.
I totally agree.
Look at a recent thread "Compile time evaluation (aka eliminating
default argument hacks)"
http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/d0cd861daf3cff6d/6a8abafed95a9053#6a8abafed95a9053
where people coming from C++ or other typical programming languages
would do:
x = 1
def _build_used():
y = x + 1
return x, y
def f(_used = _build_used()):
x, y = _used
print x, y
instead of:
x=1
def f():
y=x+1
global f
def f(x=x, y=y):
print x, y
f()
It is easy to see that people have been molded into thinking one way
(declaration of functions, legacy from staticly typed languages),
instead of viewing code also as object that you can tweak.
Fernando <···@easyjob.net> wrote:
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
> > Looks like the BDFL is planning to take lambda, reduce, filter, and
> > map out of Python in the next big rev of Python (so called Python
> > 3000):
> >
> > <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
>
>Basically, it says that it will get rid of the explicit map, filter
>and reduce and substitute them by some syntactic sugar that uses them
>implicitly. That's ok, and not a big deal.
>
>It will also get rid of lambda, and it's not a great loss, since
>python's version is so limited that it's almost useless. Besides,
>given the syntactic sugar used to replace map, reduce and filter,
>there's no real need for lambda in the most usual cases.
It is my opinion that this is a natural consequence of infix notation,
deep operator precedence heirarchy, and consequently no macro system.
With Lisp, you have the good, solid, general constructs. And if you
need syntactic sugar (like WHEN, for example), you can just build
it up using macros.
So with Python 3000, you're going to end up with a language just as big
as CL, but without the most fundamental building blocks. Ah well, to
each his own.
My Road to Lisp was long and twisty. For a while it covered some Python
territory. But I started look into where exactly the interesting bits
of Python came from. And here I am. Though I've still got a lot to
learn.
James Graves
James Graves wrote:
>
> So with Python 3000, you're going to end up with a language just as
> big as CL, but without the most fundamental building blocks. Ah
> well, to each his own.
Preventing people from building things from scratch is probably an
industrial advantage. Look how fragmented the Lisp world is.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"witch-hunt" - (noun) (Date: 1885)
1: a searching out for persecution of persons accused
of witchcraft
2: the searching out and deliberate harassment of
those (as political opponents) with unpopular views
- witch-hunter (noun)
- witch-hunting (noun or adjective)
Brandon J. Van Every <·····························@yahoo.com> wrote:
>James Graves wrote:
>>
>> So with Python 3000, you're going to end up with a language just as
>> big as CL, but without the most fundamental building blocks. Ah
>> well, to each his own.
>
>Preventing people from building things from scratch is probably an
>industrial advantage.
I believe that steering people away from building similar constructs
from scratch is a good thing. You end up different implementations
which do almost, but not quite, the same thing. And that is a hassle to
maintain.
However, trying to _prevent_ this in the language itself is too
restrictive, IMHO. Most (perhaps nearly all) of the time, I should be
using the standard constructs provided by the language base. But there
will be times and circumstances where I will want to build my own, from
the ground up.
And some of these times, that will be the Right Thing to Do, too.
>Look how fragmented the Lisp world is.
I have looked at the Lisp world. In depth. It's not as bad as it used
to be, and it is getting better day-by-day.
If you want a nice enviroment to learn programming, get DrScheme. There
are some good (free!) books out there on the 'net.
If you want to do application development, Common Lisp is where it's at,
no doubt about it. There are more and better libraries for CL these
days, and they are easier to install and manage with tools like ASDF.
Multiple open-source implementations, covering the most popular
platforms (Windows, Linux, Mac).
Cheers,
James Graves
From: Brandon J. Van Every
Subject: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39oukjF4bk3ceU1@individual.net>
James Graves wrote:
>
> If you want to do application development, Common Lisp is where it's
> at, no doubt about it. There are more and better libraries for CL
> these days, and they are easier to install and manage with tools like
> ASDF. Multiple open-source implementations, covering the most popular
> platforms (Windows, Linux, Mac).
Last I looked, 2 years ago?, there were no compiled, open source lisps that
ran on Windows. Has this changed?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
From: James Graves
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <d17ip3$ejt$1@new7.xnet.com>
Brandon J. Van Every <·····························@yahoo.com> wrote:
>James Graves wrote:
>>
>> If you want to do application development, Common Lisp is where it's
>> at, no doubt about it. There are more and better libraries for CL
>> these days, and they are easier to install and manage with tools like
>> ASDF. Multiple open-source implementations, covering the most popular
>> platforms (Windows, Linux, Mac).
>
>Last I looked, 2 years ago?, there were no compiled, open source lisps that
>ran on Windows. Has this changed?
Yes.
GCL compiles to C first. And it has been ported to Windows. It isn't
fully ANSI compliant yet, though they are working on that. I haven't
had to try that yet.
There's talk about a port of SBCL to Windows. But I don't know what
progress has been made on that front.
But coverage in this area (compiled CL) is a bit thin, I'll admit.
James Graves
From: David Golden
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <e6KZd.49657$Z14.37895@news.indigo.ie>
James Graves wrote:
>
> But coverage in this area (compiled CL) is a bit thin, I'll admit.
>
But who really cares? After all, there are the mature commercial
proprietary lisp compilers for those people who insist on using
closedware OSes, and they've already proven they're willing to use
closedware.
This, I fear, is similar to Brandon's demands for a microcrap
visual-studio compatible yet open source gaming framework. or silly
expectations of microsoft suite support for various open-source
language implementations (just google search on groups for his
name...):
Might happen (has happened, to an extent), but where's the developer
motivation? It's not like it's hard to install linux these days.
Most open source developers would be indifferent at best to a windows
port, it's not like it's even a fun challenge like a port to an obscure
platform like AROS would be, you just end up with
creeping hungarian notation ugliness in your code, and lots of #defines.
Most people writing open source and for the fun of it just aren't going
to go massively out of the way to support windows, and even if they do,
they're just giving the slaves another excuse not to throw off their
chains.
From: Brandon J. Van Every
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39p9m6F61itknU1@individual.net>
David Golden wrote:
>
> Might happen (has happened, to an extent), but where's the developer
> motivation? It's not like it's hard to install linux these days.
I will not bother to try to explain the plights of a Windows game developer
to you, except to say that as far as commercial game developers are
concerned, the Linux desktop is a useless market. It's fine as a server but
plenty of games aren't servers.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
From: Ulrich Hobelmann
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39pgtcF64a966U1@individual.net>
Brandon J. Van Every wrote:
> I will not bother to try to explain the plights of a Windows game developer
> to you, except to say that as far as commercial game developers are
> concerned, the Linux desktop is a useless market. It's fine as a server but
> plenty of games aren't servers.
>
Why's that? Admittedly in my linux times I wouldn't have paid for most
games, but that was because I generally have a slow machine, because I
don't care about 3D-Egoshooters or strategy games that consist of you
managing every teeny-weeny unit individually. Also I didn't have sound
working.
A game that's fun and not too expensive would make even Linuxers pay, I
guess.
Also, if you are developing a game far Windows, the PS2, the GameCube
and the XBox, that leaves only OpenGL as a common 3D-Platform, so you
might just as well include the Mac and Linux for free. Sound and I/O is
different again, but I think that stuff is developed once for each
platform and that's it.
Not everyone builds games only for Windows and makes money on that.
It's just a bigger market (so it's easy to be not seen in it).
Ulrich Hobelmann wrote:
>
> A game that's fun and not too expensive would make even Linuxers pay,
> I guess.
Last I checked, Mac had more game consumers than Linux, and both markets
were tiny. Admittedly I could stand to check again. Both are dwarfed by
the Windows market.
> Also, if you are developing a game far Windows, the PS2, the GameCube
> and the XBox, that leaves only OpenGL as a common 3D-Platform,
OpenGL does not run on either the PS2 or the XBox. I don't know about
GameCube. I suspect it is also proprietary. OpenGL gives you Windows, Mac,
and Linux PCs.
> so you might just as well include the Mac and Linux for free.
It is not "free." Windows-only toolchains and cross-platform toolchains are
different, and one must conscientiously choose, as there are pros and cons.
For instance, the Nebula2 3D engine http://nebuladevice.cubik.org has a
MIT-style license, is Windows-centric, VC7.1 gets the most banging on, and
OpenGL is not implemented yet. The Ogre 3D engine http://www.ogre3d.org is
LGPL licensed, seems to be more platform neutral, is not as technologically
advanced as Nebula2, but has far better documentation, tutorials, and
example code than Nebula2. I won't get into the free vs. commercial model
import plugins mess. Ogre appears to have beaten Nebula2 as far as shipping
the 1st commercial product. However, the graphics of this 1st commercial
product - Supremacy: Four Paths To Power - aren't that sexy.
http://www.blackhammergame.com/games.html This is leaving aside commercial
3D engines, who on Windows probably care about VC7.1 and not Cygwin or
MinGW, but I could be mistaken as I haven't chased them down.
The point is, there are many choices to be made, and when you decide to
"buck the trends" and nix VC7.1, you do take compatibility and support
risks.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Taking risk where others will not.
Brandon J. Van Every wrote:
> OpenGL does not run on either the PS2 or the XBox. I don't know about
> GameCube. I suspect it is also proprietary. OpenGL gives you Windows, Mac,
> and Linux PCs.
I thought most console game dev was done in GL, at least it's not
Direct3D... But then I don't know too much about console SDKs.
From: M Jared Finder
Subject: Re: compiled open source Windows lisp
Date:
Message-ID: <4237b3b7_1@x-privat.org>
Ulrich Hobelmann wrote:
> Brandon J. Van Every wrote:
>
>> OpenGL does not run on either the PS2 or the XBox. I don't know about
>> GameCube. I suspect it is also proprietary. OpenGL gives you
>> Windows, Mac,
>> and Linux PCs.
>
>
> I thought most console game dev was done in GL, at least it's not
> Direct3D... But then I don't know too much about console SDKs.
Most console game dev is done in libraries more similar to OpenGL than
Direct3D (in that they are C libraries and not C++ libraries). Really,
all 3D APIs are extremely similar, because they are all speaking to
similar hardware.
-- MJF
From: David Golden
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <aqLZd.49663$Z14.37793@news.indigo.ie>
Brandon J. Van Every wrote:
> I will not bother to try to explain the plights of a Windows game
> developer to you,
Er. If you're a commercial game developer, what do you care about open
source lisp [or anything] compilers on windows? You've
already chosen a closed platform, so you're likely just after something
free[gratis], free[libre] is coming a distant second.
Nothing stopping you prototyping on linux with an open source system and
porting to windows, either - unless you want to dive headlong into
microsoft APIs instead of OpenGL for no very good reason (and I don't
consider technicalities like relative merits of pixel shader
implementations good reason), in which case you might as well use
MSVC++ on windows anyway, as you've already kinda locked yourself out
of ps3, gbds, macosx and linux, so all that's really left
other than winpc is xbox.
And you could just cough up for one of the commercial lisps if you've
really got your heart set on lisp. Lispworks is only EUR3K or so,
AFAIK, and if you can't recoup that on your commercial game, well,
I recommend not looking upon it as a commercial venture.
Myself, I'd happily write a game in lisp, but I'd be writing it for fun,
not for commercial profit, and as windows hasn't been on a computer I
or anyone whose opinion of my game I'd care about own since last
century, I certainly wouldn't be doing it on windows.
Seeing your comp.lang.functional and comp.games.development.programming
posts, I think you know that you're being vaguely unreasonable, or at
least have been informed of that by people who definitely know what
they're talking about, already.
You could just use C++ like 99% of everybody else and benefit from
network effects and existing libraries - yeah, C++ is kinda sucky, but
it's Good Enough for most games, the hard part is writing a good game
rather than procrastinating on usenet about what language to use. The
"good game" bit is largely language independent, and a much harder
problem than writing in C++ vs. Forth vs. ML vs. Lisp vs. whatever. In
my day, we wrote games in assembler, uphill 3 miles in the snow each
way, and we liked it, damnit. You're spoilt rotten by options these
days.
David Golden wrote:
> Brandon J. Van Every wrote:
>
>> I will not bother to try to explain the plights of a Windows game
>> developer to you,
>
> Er. If you're a commercial game developer, what do you care about open
> source lisp [or anything] compilers on windows?
I will not bother to try to explain the concept of open source MIT / BSD
business models on Windows to you. To give you a hint, consider that an
*indie* game developer is often trying to avoid the onerous Publisher
system, and often has limited financial and manpower resources.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Brandon J. Van Every wrote:
> I will not bother to try to explain the concept of open source MIT /
> BSD
> business models on Windows to you.
What? You're suggesting your commercial game would be BSD or MIT
licensed?
Or (more likely I guess) that all supporting software you want
would/should be thusly licensed for use on windows and all developers
should take pains to make their stuff work on windows, just because,
um, you want it, and can't afford e.g. USD100 for GG Torque?
Also:
AFAIK the LGPL Crystal Space [1] is already windows compatible (and hey,
has python bindings*) so I really don't know what you're moaning about,
or is the LGPL too onerous for you too? There are people
using it in commercial productions, AFAIK, and OpenGL Crystal Space is
IMHO now plenty good enough for "Indy" game production and versatile
enough for a diverse range of games from abstract puzzlers to RPGs to
3D platformers to FPS.
Or maybe crystal space still isn't easy enough for you, to which I can
only say: whaddaya want, the computer to write the game for you?
[1]
http://www.crystalspace3d.org/tikiwiki/tiki-index.php?page=About+Crystal+Space
http://community.crystalspace3d.org/tiki-browse_gallery.php?galleryId=5
* Somebody with time on their hands could probably whip up Lisp bindings
fairly readily, though I haven't looked in depth at the problem.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> I will not bother to try to explain the concept of open source MIT / BSD
> business models on Windows to you. To give you a hint, consider that an
> *indie* game developer is often trying to avoid the onerous Publisher
> system, and often has limited financial and manpower resources.
Again, that has nothing to do with open source and everything to do
with "no cost".
I hear that Franz are often quite flexible with their licensing;
someone from that organization is free to comment here, but I'd have
thought it'd at least be worth trying to negotiate something with them
and see if you can cut a deal that loads more on royalties and less on
the up-front.
-dan
···@telent.net wrote:
>
> I hear that Franz are often quite flexible with their licensing;
> someone from that organization is free to comment here, but I'd have
> thought it'd at least be worth trying to negotiate something with them
> and see if you can cut a deal that loads more on royalties and less on
> the up-front.
I'm not interested in royalty deals. I would need a pretty incredible
software system that already solves the vast majority of my game production
problems to even consider royalty deals. Lisp is just a language that
leaves me to do all the hard work.
Also, I do believe in the idea of sparing other indies pain and suffering
through the principle of MIT-style open source. Everyone's got their
windmills to tilt at; mine are game publisher windmills. They've got way
too much of a stranglehold on the creative process. I might dispense with
such ideals in order to get a cash flow going, but the "software commons" is
a problem I do have a long term interest in. I would like other people to
build upon my gruntwork, so that we are not all continuously suffering from
gruntwork, and thereby conceding advantages to those with greater manpower
and capital. I would like to write articles on Gamasutra about how I
succeeded, and for people to be able to easily try out and duplicate my
toolchain without substantial $$$$ committments.
It is only out of necessity that I've recently abandoned the 2 projects that
would help others as they would help me: a Nebula2 model importer that
doesn't require a $$$$ SDK, and a Python example code game. The importer
project is boring, I don't see it making me money, it's a fair chunk of
work, and I want to see more progress on my primary needs. With solid AI
code in hand I think I'll have a stronger justification for the supporting
gruntwork of 3D engines, their importers, etc.
I've also accepted that in many ways, Nebula2 has just been slowing me down
all this time, and that it's not the only open source 3D engine out there.
Just the one with the best technology and license. For learning curve and
initial ease of use, it's crap. I don't much believe in wading through crap
"just to get started" anymore.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Lisp is just a language that leaves me to do all the hard work.
That is exactly what Lisp is designed for: doing the hard work. C++
is really no different in that respect (although the design philosophy
is completely different). The hard work is the interesting stuff.
How much easier do you think game design would be if there was a
turn-key portable game engine anyway? Apart from all that art work,
sound fx, music, and other candy, you still need something of a plot.
Well maybe not for a game like Grand Turismo.
> Also, I do believe in the idea of sparing other indies pain and suffering
> through the principle of MIT-style open source. Everyone's got their
> windmills to tilt at; mine are game publisher windmills. They've got way
> too much of a stranglehold on the creative process. I might dispense with
> such ideals in order to get a cash flow going, but the "software commons" is
> a problem I do have a long term interest in. I would like other people to
> build upon my gruntwork, so that we are not all continuously suffering from
> gruntwork, and thereby conceding advantages to those with greater manpower
> and capital. I would like to write articles on Gamasutra about how I
> succeeded, and for people to be able to easily try out and duplicate my
> toolchain without substantial $$$$ committments.
Good luck with that.
> I've also accepted that in many ways, Nebula2 has just been slowing me down
> all this time, and that it's not the only open source 3D engine out there.
> Just the one with the best technology and license. For learning curve and
> initial ease of use, it's crap. I don't much believe in wading through crap
> "just to get started" anymore.
Wading through crap as you put it is a right of passage. Even with a
fully documented and complete API, you would still have to learn it
and use it to become productive with it. There is simply no way
around that. You can't just wish a bridge into existence.
Free software tends to be about scratching a personal itch. If a lot
of people have the same itch, a community can develope around it. If
your itch is different, then you have to build your own tools.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>
>> Lisp is just a language that leaves me to do all the hard work.
>
> That is exactly what Lisp is designed for: doing the hard work. C++
> is really no different in that respect (although the design philosophy
> is completely different). The hard work is the interesting stuff.
And except that C++ makes all the hard work much harder. ;-)
> How much easier do you think game design would be if there was a
> turn-key portable game engine anyway? Apart from all that art work,
> sound fx, music, and other candy, you still need something of a plot.
> Well maybe not for a game like Grand Turismo.
The difference is the hard work I enjoy doing and most fires my imagination,
vs. what is merely a boring support maintenance slog. I'm quite happy to do
the hard work of my AI code, and also the pencil-and-paper hard work that
goes into a proper game design.
> Wading through crap as you put it is a right of passage.
Flexing my B.A. in sociocultural anthropology, I believe you meant 'rite' of
passage. :-) I don't believe in rites of passage. I have no interest in
being within Nebula2's sacred circle.
> Even with a
> fully documented and complete API, you would still have to learn it
> and use it to become productive with it. There is simply no way
> around that. You can't just wish a bridge into existence.
You underestimate the time loss due to no docs, no good tutorials, and no
good free 3D model import plugins. Ogre is much better than Nebula2 in
these regards, and probably Irrlicht as well. Different developers focus on
different stages of the game, and some are clearly more beginner friendly
than others. Nebula2 still has much more to offer a big commercial project,
but if it continues to hemmorage newbies to other, easier-to-use 3D engines,
that may very well change in 2 years' time.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> > Wading through crap as you put it is a right of passage.
>
> Flexing my B.A. in sociocultural anthropology, I believe you meant 'rite' of
> passage. :-) I don't believe in rites of passage. I have no interest in
> being within Nebula2's sacred circle.
I didn't think that looked right, but I hit C-c C-c anyway.
You must do what you feel is right of course.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
From: Harry George
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <xqxis3qqqba.fsf@cola2.ca.boeing.com>
David Golden <············@oceanfree.net> writes:
> James Graves wrote:
>
> >
> > But coverage in this area (compiled CL) is a bit thin, I'll admit.
> >
>
> But who really cares? After all, there are the mature commercial
> proprietary lisp compilers for those people who insist on using
> closedware OSes, and they've already proven they're willing to use
> closedware.
>
> This, I fear, is similar to Brandon's demands for a microcrap
> visual-studio compatible yet open source gaming framework. or silly
> expectations of microsoft suite support for various open-source
> language implementations (just google search on groups for his
> name...):
>
> Might happen (has happened, to an extent), but where's the developer
> motivation? It's not like it's hard to install linux these days.
> Most open source developers would be indifferent at best to a windows
> port, it's not like it's even a fun challenge like a port to an obscure
> platform like AROS would be, you just end up with
> creeping hungarian notation ugliness in your code, and lots of #defines.
> Most people writing open source and for the fun of it just aren't going
> to go massively out of the way to support windows, and even if they do,
> they're just giving the slaves another excuse not to throw off their
> chains.
>
>
These are good arguments, but miss the crucial point that many of us
work in environments that are dictated by PHB's. So we use Linux (and
other *NIX's) where possible, and then install cygwin and ntemacs and
other OSS tools on MS Win** systems when forced to use that
environment.
The motivation to *use* OSS tools on MS WinXX is to operate in a
platform-independent world, so you can develop on *NIX and deploy on
MS WinXX. The motivation to *develop* such tools is to help wean the
world from vendor lockin.
>
>
>
>
--
··············@boeing.com
6-6M21 BCA CompArch Design Engineering
Phone: (425) 294-4718
From: David Golden
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <jQl_d.49789$Z14.37721@news.indigo.ie>
Harry George wrote:
>
> These are good arguments, but miss the crucial point that many of us
> work in environments that are dictated by PHB's. So we use Linux (and
> other *NIX's) where possible, and then install cygwin and ntemacs and
> other OSS tools on MS Win** systems when forced to use that
> environment.
>
Yes, but Brandon had previously explicitly disregarded cygwin as it's
not the windows way. He seems to want Open Source projects that
take advantage of the peculiar advantages (there are some) and account
for the particular quirks of the windows environment in a windowsy way,
not change windows into a clunky unixoid with cygwin. Your goal or my
goal might be to abstract away from windows as much as possible, I
suspect (but do not claim to peak for him!) that brandon would like to
see OSS projects that make maximal use of windows-only features like
e.g. Direct3D, rather than minimal.
Back in the day, I sometimes felt similar about open source on the Amiga
platform: the vast bulk just used ixemul (conceptually similar to
cygwin, allowing running GNU toolchain on top of the Amiga
pseudomicrokernel), disregarding the peculiar advantages of the Amiga
platform (e.g. GNU clisp being an interesting exception, as far as I
recall, with its native support for various Amiga-y things. But GNU
clisp is german, and amiga had much higher penetration in europe than
the US, so presumably there were amiga people maintaining the support)
I don't think that demanding someone else do the hard work of
integrating for your favorite platform is reasonable: If Brandon wants
windows makefiles for something, let him write them. If Brandon wants
extensive changes to an OSS projects source tree to account for
windowsisms (like prefixing every bloody function with some goofy
pragma), let him maintain a patch set, ask for his patches to go into
the main tree (or maintain a windows friendly-fork). (In fairness,
AFAIK he has done some of that sort of thing in the past!).
From: David Golden
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <j5m_d.49793$Z14.38038@news.indigo.ie>
David Golden wrote:
> I suspect (but do not claim to peak for him!) that brandon would like
I sure as hell don't peak for him... speak for him, I meant.
Geez. You have a few drinks in dublin on paddy's day, and suddenly you
cna't tpye...
From: ······@motorola.com
Subject: Re: compiled open source Windows lisp
Date:
Message-ID: <ovd5s8w2gn.fsf@motorola.com>
David Golden <············@oceanfree.net> writes:
> David Golden wrote:
>
>> I suspect (but do not claim to peak for him!) that brandon would like
>
> I sure as hell don't peak for him... speak for him, I meant.
> Geez. You have a few drinks in dublin on paddy's day, and suddenly you
> cna't tpye...
Not to mention getting curry, garlic mayo, and vomit all over the
keyboard...
From: Karl A. Krueger
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <d1ci56$2cf$1@baldur.whoi.edu>
In comp.lang.lisp James Graves <·······@typhoon.xnet.com> wrote:
> GCL compiles to C first.
Which is funny, because GCC compiles to s-expressions first, in the form
of Register Transfer Language.
A quote from _Using and Porting GCC_:
RTL is inspired by Lisp lists. It has both an internal form,
made up of structures that point at other structures, and a
textual form that is used in the machine description and in
printed debugging dumps. The textual form uses nested
parentheses to indicate the pointers in the internal form.
And here's an example from the same work:
(parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
(set (mem:SI (reg:SI 1)) (reg:SI 1))])
says unambiguously that the values of hard register 1 and the
memory location addressed by it are interchanged.
RTL isn't really a Lisp because, well, it doesn't have list operations
or other useful things like that.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
From: Christopher C. Stacy
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <u1xagoamz.fsf@news.dtpq.com>
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Last I looked, 2 years ago?, there were no compiled, open source
> lisps that ran on Windows. Has this changed?
GCL (formerly known as KCL and ACL) has been around since 1984,
and has been available on Windows since 2000.
ECL (another KCL derivative) has been available since about 1990.
Corman Common Lisp only runs on Windows, and has been available since 1998.
There might be others; those are off the top of my head.
I am also not counting here any Lisp implementations that
ran on Windows under the Cygwin support; just native ones.
Historically, compiled open-souce Lisp implementations
have been available since the 1960s.
All this information has been available in FAQs and
on many web pages since forever.
Christopher C. Stacy wrote:
>
> All this information has been available in FAQs and
> on many web pages since forever.
When I Google for "comp.lang.lisp FAQ," I get a document that was last
updated in 1997. Consequently I do not pay attention to it. I do peruse
newsgroup archives, and I did make a thorough search of "Lisp stuff" 2 years
ago. It is possible, however, that my criteria was somewhat more
restrictive back then.
As for "websites," well, there's a sea of them. I ask human beings for
pointers because it saves time.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Christopher C. Stacy wrote:
> >
> > All this information has been available in FAQs and
> > on many web pages since forever.
>
> When I Google for "comp.lang.lisp FAQ," I get a document that was last
> updated in 1997. Consequently I do not pay attention to it.
When I Google for "light speed relativity", I get a document that was
last updated in 1905. Consequently I do not pay attention to it.
--
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?
__Pascal Bourguignon__ http://www.informatimago.com/
Pascal Bourguignon wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>
>> Christopher C. Stacy wrote:
>>>
>>> All this information has been available in FAQs and
>>> on many web pages since forever.
>>
>> When I Google for "comp.lang.lisp FAQ," I get a document that was
>> last updated in 1997. Consequently I do not pay attention to it.
>
> When I Google for "light speed relativity", I get a document that was
> last updated in 1905. Consequently I do not pay attention to it.
I imagine if light speed relativity changed as often as compilers, APIs, and
industry darlings, you wouldn't. Geez man in 1997 we hadn't even hit the
height of the dot.com boom.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
From: Fraca7
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <pan.2005.03.15.22.27.21.11700@free.fr>
On Tue, 15 Mar 2005 12:25:02 -0800, Brandon J. Van Every wrote:
> Last I looked, 2 years ago?, there were no compiled, open source lisps that
> ran on Windows. Has this changed?
I don't think so. I recently (about 2 months ago) started to want to learn
Lisp (didn't go far for now) and wanted to find a Windows impl, to
evaluate "cross-platformability". The only open source/free software Lisp
interpreter I found was Common Lisp under Cygwin. Not exactly win32
native. But good enough, I think.
--
One Page Principle:
A specification that will not fit on one page of 8.5x11 inch
paper cannot be understood.
-- Mark Ardis
From: Edi Weitz
Subject: Re: compiled open source Windows lisp
Date:
Message-ID: <uhdjchbhx.fsf@agharta.de>
On Tue, 15 Mar 2005 23:29:04 +0100, Fraca7 <······@free.fr> wrote:
> I don't think so. I recently (about 2 months ago) started to want to
> learn Lisp (didn't go far for now) and wanted to find a Windows
> impl, to evaluate "cross-platformability". The only open source/free
> software Lisp interpreter
Compiler, not interpreter. All available Common Lisp implementations
are compilers - one (CLISP) compiles to bytecode while all others
compile to machine code.
> I found was Common Lisp under Cygwin.
"Common Lisp" is not an implementation but a language (defined by an
ANSI standard).
You're probably talking about CLISP (which is an implementation of the
language Common Lisp) which runs on Cygwin.
> Not exactly win32 native. But good enough, I think.
Native Win32 versions of CLISP are available. And there's also ECL.
Also, if you're just learning CL it's perfectly fine to use the trial
versions of AllegroCL or LispWorks. Why do you need an open source
implementation to learn a language?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Tue, 15 Mar 2005 23:29:04 +0100, Fraca7 <······@free.fr> wrote:
>>I don't think so. I recently (about 2 months ago) started to want to
>>learn Lisp (didn't go far for now) and wanted to find a Windows
>>impl, to evaluate "cross-platformability". The only open source/free
>>software Lisp interpreter
> Compiler, not interpreter. All available Common Lisp implementations
> are compilers - one (CLISP) compiles to bytecode while all others
> compile to machine code.
I find it increasingly difficult to discern between an interpreter and a
compiler for a virtual machine. I guess that something that produces
"bytecode" for an actual CPU is a compiler :)
>>I found was Common Lisp under Cygwin.
> "Common Lisp" is not an implementation but a language (defined by an
> ANSI standard)
> You're probably talking about CLISP (which is an implementation of the
> language Common Lisp) which runs on Cygwin.
Indeed, I was.
>>Not exactly win32 native. But good enough, I think.
> Native Win32 versions of CLISP are available. And there's also ECL.
Didn't know about this one, I'll google it.
> Also, if you're just learning CL it's perfectly fine to use the trial
> versions of AllegroCL or LispWorks. Why do you need an open source
> implementation to learn a language?
As a matter of fact, I don't. I actually installed LispWorks on my job
PC, just to experiment. But if I'm going to write actual free software
in LISP, I'd better have it run under an OS/FS Lisp
interpreter/compiler, whatever. I always feel kind of awkward about free
software being written in a proprietary environment, like Delphi [see
Dev-C++]. Maybe it's just me.
--
Just about every computer on the market today runs Unix, except the Mac
(and nobody cares about it).
-- Bill Joy 6/21/85
Ulrich Hobelmann <···········@web.de> schrieb:
> Just because a compiler is involved at some point (like javac) the
> language isn't compiled.
Compile is a verb. I'm not sure it makes any sense to talk about a
"compiled language", but clearly if you compile it, it is compiled. Or
what do you call what javac does?
Adrian Kubala wrote:
> Ulrich Hobelmann <···········@web.de> schrieb:
>
>>Just because a compiler is involved at some point (like javac) the
>>language isn't compiled.
>
>
> Compile is a verb. I'm not sure it makes any sense to talk about a
> "compiled language", but clearly if you compile it, it is compiled. Or
> what do you call what javac does?
That's compiled bytecode, sure. But my point is that it's not a usable
end-product on a typical (non-jazelle) CPU, but it needs further
compilation or interpretation.
I only call something compiled, if it's compiled "all the way through".
Ulrich Hobelmann <···········@web.de> writes:
> Adrian Kubala wrote:
> > Ulrich Hobelmann <···········@web.de> schrieb:
> >
> >>Just because a compiler is involved at some point (like javac) the
> >>language isn't compiled.
> > Compile is a verb. I'm not sure it makes any sense to talk about a
> > "compiled language", but clearly if you compile it, it is compiled. Or
> > what do you call what javac does?
>
> That's compiled bytecode, sure. But my point is that it's not a
> usable end-product on a typical (non-jazelle) CPU, but it needs
> further compilation or interpretation.
>
> I only call something compiled, if it's compiled "all the way through".
Of course.
That's why I call your program "compiled" with gcc for x86 *interpreted*.
Since I have to use VirtualPC on my Mac to run it, obviously it is not
compiled but interpreted!
--
__Pascal Bourguignon__ http://www.informatimago.com/
fraca7 wrote:
> Edi Weitz wrote:
>
>> On Tue, 15 Mar 2005 23:29:04 +0100, Fraca7 <······@free.fr> wrote:
>
>>> I don't think so. I recently (about 2 months ago) started to want to
>>> learn Lisp (didn't go far for now) and wanted to find a Windows
>>> impl, to evaluate "cross-platformability". The only open source/free
>>> software Lisp interpreter
>
>> Compiler, not interpreter. All available Common Lisp implementations
>> are compilers - one (CLISP) compiles to bytecode while all others
>> compile to machine code.
>
> I find it increasingly difficult to discern between an interpreter and a
> compiler for a virtual machine. I guess that something that produces
> "bytecode" for an actual CPU is a compiler :)
...and a CPU is an interpreter for such "bytecode". As soon as you grasp
that concept, enlightenment will follow... ;-)
Pascal
fraca7 <······@free.fr> writes:
> Edi Weitz wrote:
>
> > Also, if you're just learning CL it's perfectly fine to use the trial
> > versions of AllegroCL or LispWorks. Why do you need an open source
> > implementation to learn a language?
>
> As a matter of fact, I don't. I actually installed LispWorks on my job
> PC, just to experiment. But if I'm going to write actual free software
> in LISP, I'd better have it run under an OS/FS Lisp
> interpreter/compiler, whatever. I always feel kind of awkward about free
> software being written in a proprietary environment, like Delphi [see
> Dev-C++]. Maybe it's just me.
What an absolutely silly point of view! If you're dogmatic about free
software, why does Windows get the free pass that Lispworks, Allegro,
and Corman don't?
fraca7 <······@free.fr> writes:
> I find it increasingly difficult to discern between an interpreter and
> a compiler for a virtual machine. I guess that something that produces
> "bytecode" for an actual CPU is a compiler :)
If you give it a program in some language, and it produces a
translation of that program into another language, then it's a compiler.
If you give it a program in some language, and it executes the
program, then it's an interpreter.
A very important class of interpreters is computer hardware, which
interprets a very important class of "interpreted languages": machine
code.
Most Common Lisp implementations have both compilers and
interpreters. Some "fake" the interpretation by compliling the code
and asking the hardware to interpret the result.
Most Common Lisp implementations' compilers compile to native machine
code (which gets interpreted by the hardware). Some, notably Clisp,
compile to byte code (which gets interpreted by the VM).
fraca7 wrote:
> As a matter of fact, I don't. I actually installed LispWorks on my job
> PC, just to experiment. But if I'm going to write actual free software
> in LISP, I'd better have it run under an OS/FS Lisp
> interpreter/compiler, whatever. I always feel kind of awkward about free
> software being written in a proprietary environment, like Delphi [see
> Dev-C++]. Maybe it's just me.
No I think it isn't just you - I was quite annoyed when I found an open
source software that I looked for a long time on the net, only to
discover, that I needed Delphi to compile it, which I do not have.
But the nice thing is, as long as you stick to Ansi Common Lisp and
portable libraries, nothing prevents others to compile the source with
SBCL for example - fortunately using propriatary tools not always means
to be locked in.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
From: Carl Shapiro
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <ouy7jk7u8hi.fsf@panix3.panix.com>
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Last I looked, 2 years ago?, there were no compiled, open source lisps that
> ran on Windows. Has this changed?
I have a virtually completed port of CMUCL to Win32. And, if I was
not busy organizing a Lisp conference, it would be publicly available
by now. An observation: most of the open-source Lisp implementations
make egregious assumptions about the underlying operating system, most
of which are just barely valid, even on UNIX. (Perhaps this is an
observation about UNIX software in general.) A lot of this had to be
untangled in order to make CMUCL usable. More work remains to be
done.
When playing the role of a Windows developer, I have never been
satisfied with the level of integration that language run-times with a
UNIX heritage has to the Win32 API. Such things as file system
interaction, I/O completion ports, thread pools, componentized
software, synchronization primitives and the like never quite work
correctly, especially when there is a run-time library which sits
above the C library. You will find an amazing amount of shennanigans
in Lisp run-time libraries (commercial and open-source) as well as
those belonging to the various strongly-typed functional languages,
and scripting languages. These systems would appear to have been
written with the assumption that they would be the "harness" of an
application, and that UNIX compatibility was an overriding concern;
fatal flaws for Win32 development.
I have never been a game developer, but I have worked on real-time
systems--written in Lisp. I would guess that programmers in both
these domains have similar concerns. You can write continuous systems
in Lisp, but it requires a fair amount of wizardry. (This is
basically true of most garbage collected systems.) Real-time
collectors help but often sap performance and introduce constraints of
their own.
From: Brandon J. Van Every
Subject: Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39reliF64ggomU1@individual.net>
Carl Shapiro wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>
>> Last I looked, 2 years ago?, there were no compiled, open source
>> lisps that ran on Windows. Has this changed?
>
> I have a virtually completed port of CMUCL to Win32. [etc]
Ah, so you're the brave lad I heard about. :-) Well, good going! Hope to
see it sometime.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
When no one else sells courage, supply and demand take hold.
On 16 Mar 2005 06:37:45 -0500, Carl Shapiro <·············@panix.com>
wrote:
>I have a virtually completed port of CMUCL to Win32. And, if I was
>not busy organizing a Lisp conference, it would be publicly available
>by now.
If it's the conference I think, then the deadline for papers was about
a week ago. I suspect that most of the other routine parts have been
taken care of leaving scheduling. IOW your time is freeing up.
OTOH it may just be wishful thinking on my part. Any idea how much
longer?
The reply-to email address is ··········@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,
**
Thaddeus L. Olczyk, PhD
There is a difference between
*thinking* you know something,
and *knowing* you know something.
Peter Seibel wrote:
> Looks like the BDFL is planning to take lambda, reduce, filter, and
> map out of Python in the next big rev of Python (so called Python
> 3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
Ok. No problem. Then most hackers will take out Python of their
toolbox...
Python wants to be Java or Visual Basic? Then it will be used only by
the
people of Visual Basic IQ level...
·······@gmail.com wrote:
>
> Ok. No problem. Then most hackers will take out Python of their
> toolbox...
> Python wants to be Java or Visual Basic? Then it will be used only by
> the people of Visual Basic IQ level...
That strikes me as naked, unfounded prejudice. The vast majority of Python
code is not relying on being fancy brainy brilliant.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Brandon J. Van Every wrote:
> > Ok. No problem. Then most hackers will take out Python of their
> > toolbox...
> > Python wants to be Java or Visual Basic? Then it will be used only
by
> > the people of Visual Basic IQ level...
>
> That strikes me as naked, unfounded prejudice. The vast majority of
Python
> code is not relying on being fancy brainy brilliant.
Sure. But everybody coding in python knows, that if they'll need
something
a bit more complicated then simple script glue, the language will allow
them to do this with a little afford. Now, without this nice functional
constructions, it will become a pure scripting glue-oriented language,
with the same target problem domain as VBA.
·······@gmail.com <·······@gmail.com> wrote:
> them to do this with a little afford. Now, without this nice functional
> constructions, it will become a pure scripting glue-oriented language,
> with the same target problem domain as VBA.
This is utterly false. Since python has not removed any of the
functionality that those constructs provide (and I would bring some
evidence to support such a high flying statement).
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
·······@gmail.com <·······@gmail.com> wrote:
> Ok. No problem. Then most hackers will take out Python of their
> toolbox...
I doubt this will happen only because they removed lambda, reduce,
filter and company.
> Python wants to be Java or Visual Basic? Then it will be used only by
> the
> people of Visual Basic IQ level...
This is offensive, and plain false, but if it makes you more comfortable
to disqualify your statements in this way then I cannot stop you from
going on.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> > Ok. No problem. Then most hackers will take out Python of their
> > toolbox...
>
> I doubt this will happen only because they removed lambda, reduce,
> filter and company.
Sure, it is just a small part of the major Python development trend.
Trend leading to another one Visual Basic...
> > Python wants to be Java or Visual Basic? Then it will be used only
by
> > the
> > people of Visual Basic IQ level...
>
> This is offensive, and plain false,
This can't be directly concluded from the referred GvR quote, but from
the other sources it is clean that he is going to "simplify" the
language
as much as possible (e.g. - remember the tail recursion issue).
·······@gmail.com <·······@gmail.com> wrote:
> This can't be directly concluded from the referred GvR quote, but from
> the other sources it is clean that he is going to "simplify" the
> language
> as much as possible (e.g. - remember the tail recursion issue).
Simplyfing a language is a good choice. Complex constructs like
descriptors or metaclasses are always there, but having a small core
language with a good standard library is a respectable choice, and I
would say this is the choice that lisp developers made with macros.
In python you don't want to use recursion because function calls are
very expensive compared to other languages.
Also list comprehensions are almost always faster and more flexible than
any combination of filter and map because of particular bytecode
optimizations in list comprehensions. Lately generator expressions have
been added to the language to allow lazy list construction.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> ·······@gmail.com <·······@gmail.com> wrote:
>
> > This can't be directly concluded from the referred GvR quote, but
from
> > the other sources it is clean that he is going to "simplify" the
> > language
> > as much as possible (e.g. - remember the tail recursion issue).
>
> Simplyfing a language is a good choice. Complex constructs like
> descriptors or metaclasses are always there, but having a small core
> language with a good standard library is a respectable choice, and I
> would say this is the choice that lisp developers made with macros.
True. And you have to select a correct, orthogonal core. Lambda is a
best possible base for such a core.
> In python you don't want to use recursion because function calls are
> very expensive compared to other languages.
No. GvR said that "recursion is too complicated". And, for tail
recursion
you don't have to bother about the function call efficiency.
> Also list comprehensions are almost always faster and more flexible
than
> any combination of filter and map because of particular bytecode
> optimizations in list comprehensions. Lately generator expressions
have
> been added to the language to allow lazy list construction.
Good. Now why they can't use all this brilliant stuff as a backend for
a functional constructions compilation?
·······@gmail.com <·······@gmail.com> wrote:
> Good. Now why they can't use all this brilliant stuff as a backend for
> a functional constructions compilation?
Probably because it's easy to write a map implementation using list
comprehensions or generator expressions in your personal library.
def map(fun, list):
return [fun(x) for x in list]
def lazy_map(fun, list):
return (fun(x) for x in list)
the same goes for the other functional constructs.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> > Good. Now why they can't use all this brilliant stuff as a backend
for
> > a functional constructions compilation?
>
> Probably because it's easy to write a map implementation using list
> comprehensions or generator expressions in your personal library.
>
> def map(fun, list):
> return [fun(x) for x in list]
>
> def lazy_map(fun, list):
> return (fun(x) for x in list)
>
> the same goes for the other functional constructs.
The most important is an anonymous functions (lambda). Without them
everything else is useless...
Valentino Volonghi aka Dialtone wrote:
> In python you don't want to use recursion because function calls are
> very expensive compared to other languages.
Which is about the worst design+implementation decision one could ever
make for a language!
Remember the first programming languages (yes, you should use functions
for modularity even though they're dog slow) and the Guy Steele paper:
function calls don't have to be dog slow?
Ulrich Hobelmann <···········@web.de> wrote:
> > In python you don't want to use recursion because function calls are
> > very expensive compared to other languages.
>
> Which is about the worst design+implementation decision one could ever
> make for a language!
It's not a design choice. Already explained in another post.
> Remember the first programming languages (yes, you should use functions
> for modularity even though they're dog slow) and the Guy Steele paper:
> function calls don't have to be dog slow?
function calls are slow compared to other lower level languages. On my
ibook 1.3Ghz it takes 5-6 microseconds to call a function with a pass
statement inside.
And recursion can be converted into iteration in many different ways.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> function calls are slow compared to other lower level languages. On my
> ibook 1.3Ghz it takes 5-6 microseconds to call a function with a pass
> statement inside.
Ouch, and mine has only 800MHz!
> And recursion can be converted into iteration in many different ways.
>
But definitely not always. Also have a look at "The Swine Before Perl"
(PDF-slides) from Shriram Krishnamurti, which explains why tail
recursion is cool :)
Valentino Volonghi aka Dialtone wrote:
> Simplyfing a language is a good choice. Complex constructs like
> descriptors or metaclasses are always there, but having a small core
> language with a good standard library is a respectable choice, and I
> would say this is the choice that lisp developers made with macros.
You think that it's a good idea to remove lambda but keep metaclasses?
Weird.
> In python you don't want to use recursion because function calls are
> very expensive compared to other languages.
>
> Also list comprehensions are almost always faster and more flexible than
> any combination of filter and map because of particular bytecode
> optimizations in list comprehensions. Lately generator expressions have
> been added to the language to allow lazy list construction.
Does this mean that the Python language design is driven by their
implementors' lack of ability to implement it efficiently?
Pascal
Pascal Costanza <··@p-cos.net> wrote:
> You think that it's a good idea to remove lambda but keep metaclasses?
> Weird.
lambda was the weird thing in python, not metaclasses.
Metaclasses and descriptors all fit very well inside the new object
model that was added in python 2.2 lots of years ago.
In python lambda is usually replaced with a nested function like this:
def _(result):
return myFun(result[0], result[1])
d = a_function_that_returns_a_deferred_object()
d.addCallback(_)
Using a lambda would have been like:
d = a_function_that_returns_a_deferred_object()
d.addCallback(lambda result: myFun(result[0], result[1]))
I agree, it is shorter, but it's _NOT_ anything that you can't live
without, and most beginners just don't understand lambda.
> Does this mean that the Python language design is driven by their
> implementors' lack of ability to implement it efficiently?
No, that means that it was my opinion, and Guido stated something
different. My opinion is based on my experience with python, this
explains why it is tidied to implementation choices in current CPython.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> In python lambda is usually replaced with a nested function like this:
>
> def _(result):
> return myFun(result[0], result[1])
>
> d = a_function_that_returns_a_deferred_object()
> d.addCallback(_)
That's a lambda to me, (even though not called "lambda" and) even though
you have to bind it first. I'm relieved.
> Using a lambda would have been like:
>
> d = a_function_that_returns_a_deferred_object()
> d.addCallback(lambda result: myFun(result[0], result[1]))
>
> I agree, it is shorter, but it's _NOT_ anything that you can't live
> without, and most beginners just don't understand lambda.
Okay, the difference here is unimportant. A wouldn't care about this
little bit of syntax.
Valentino Volonghi aka Dialtone wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>>You think that it's a good idea to remove lambda but keep metaclasses?
>>Weird.
>
> lambda was the weird thing in python, not metaclasses.
[...]
> I agree, it is shorter, but it's _NOT_ anything that you can't live
> without, and most beginners just don't understand lambda.
What I find weird is that your claims seem to imply that beginners do
understand metaclasses. Or why are they kept in the language while
lambda is not? This sounds all very random to me.
Do Python beginners understand metaclasses, or is this another feature
that is likely to be removed in the future?
>>Does this mean that the Python language design is driven by their
>>implementors' lack of ability to implement it efficiently?
>
> No, that means that it was my opinion, and Guido stated something
> different. My opinion is based on my experience with python, this
> explains why it is tidied to implementation choices in current CPython.
I don't understand what you are saying at all. You have different
opinions on what is more efficient? Efficiency can be measured, no need
for opinions here.
So: Is tail recursion removed because of efficiency concerns or because
beginners find it hard to understand?
Pascal
Pascal Costanza wrote:
>
> Do Python beginners understand metaclasses, or is this another feature
> that is likely to be removed in the future?
Python beginners don't understand anything. That's the strength of the
language, they don't *need* to understand anything. As a person posting on
comp.lang.lisp that may be an alien concept to you. All I can tell you is
that Python is not a "guru language" and isn't going to become one. The
idea that Python can only handle Visual Basic style programming is
prejudicial, but the idea that Python can replace Visual Basic is very
valid.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
When no one else sells courage, supply and demand take hold.
Pascal Costanza wrote:
> So: Is tail recursion removed because of efficiency concerns or because
> beginners find it hard to understand?
Excellent question, but we also have to ask it to the CL committee.
Why aren't overhead-free tail calls required? If anyone wants to keep
stack records for debugging, there could always be a flag to turn on,
but at least (tail-call guarantee) it preserves some semantics (like a
program running in constant space).
Ulrich Hobelmann wrote:
> Pascal Costanza wrote:
>
>> So: Is tail recursion removed because of efficiency concerns or
>> because beginners find it hard to understand?
>
> Excellent question, but we also have to ask it to the CL committee.
> Why aren't overhead-free tail calls required? If anyone wants to keep
> stack records for debugging, there could always be a flag to turn on,
> but at least (tail-call guarantee) it preserves some semantics (like a
> program running in constant space).
If you allow a flag to switch off tail call optimization, then that
optimiziation is by definition not a required, but an optional one.
Don't mix the levels in the discussion:
- Most CL implementations provide tail call optimization as an option.
- The ANSI CL standard doesn't require them.
- Python doesn't seem to provide them.
- Python doesn't have a standard, we're talking solely about a single
implementation. So there's no "Python standard" to require tail call
optimization or not.
Pascal
Pascal Costanza wrote:
> If you allow a flag to switch off tail call optimization, then that
> optimiziation is by definition not a required, but an optional one.
No, the turning OFF is optional. The TCO-opt would be a requirement,
like in Scheme.
> Don't mix the levels in the discussion:
>
> - Most CL implementations provide tail call optimization as an option.
In CL TCO is optional, yes.
That might be fine, if you have the right implementation. :)
> - The ANSI CL standard doesn't require them.
> - Python doesn't seem to provide them.
That's one of its faults ;)
> - Python doesn't have a standard, we're talking solely about a single
> implementation. So there's no "Python standard" to require tail call
> optimization or not.
One implementation isn't bad necessarily, but most good languages
somehow spawn multiple implementations, maybe because they aren't
dogmatic about how everything works. (all the Schemes with different
stackful/stackless engines...)
Ulrich Hobelmann wrote:
> Pascal Costanza wrote:
>
>> - Python doesn't have a standard, we're talking solely about a single
>> implementation. So there's no "Python standard" to require tail call
>> optimization or not.
>
> One implementation isn't bad necessarily, but most good languages
> somehow spawn multiple implementations, maybe because they aren't
> dogmatic about how everything works. (all the Schemes with different
> stackful/stackless engines...)
Why assume that dogma is bad? Dogma clearly has some advantages for
industrial coordination.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Pascal Costanza wrote:
> I am sorry to pick nits, but turning tail call optimization off would
> then mean to turn your implementation into a non-conforming one.
> Furthermore, there are sometimes good reasons to run a program with
> debugging features turned on, so again you would run a program in a
> non-conformant way.
For CL, yes. I was talking about that it would be better if required
and implementations could provide stack-based debugging as an option.
Anyway, this discussion is not relevant, since Lisp systems are the way
they are :)
> The goals of the various Scheme standards differ strongly from those of
> ANSI Common Lisp, this is why they can require "proper" tail recursion.
> Deviations from RnRS in actual Scheme implementations seem to have a
> different standing in the Scheme community than in the Common Lisp
> community.
I don't think Schemers accept non-standard ones any more than Lispers
do. There might always be an interesting kind-of-Lisp; most people
ignore it.
>> One implementation isn't bad necessarily, but most good languages
>> somehow spawn multiple implementations, maybe because they aren't
>> dogmatic about how everything works. (all the Schemes with different
>> stackful/stackless engines...)
>
>
> Scheme seems to be very dogmatic about how tail recursion should be
> implemented. ;-P
Only *that* it's implemented. This just means safe-for-space: values
that aren't needed any more are freed or left to the GC.
You can use C-style runtime stacks (which makes those weird
continuations slow), or 100% heap-allocation which has its own
features... etc.
Pascal Costanza <··@p-cos.net> wrote:
> What I find weird is that your claims seem to imply that beginners do
> understand metaclasses. Or why are they kept in the language while
> lambda is not? This sounds all very random to me.
There is a tiny difference: lambda is useless in python. Metaclasses are
the foundation of the python object model.
lambdas are only used to have inline functions. Python already has
nested scopes and nested functions/classes.
> Do Python beginners understand metaclasses, or is this another feature
> that is likely to be removed in the future?
No they don't understand metaclasses probably. But since python relies
on metaclasses for its object system they can't go away. lambdas are a
total different story.
> > No, that means that it was my opinion, and Guido stated something
> > different. My opinion is based on my experience with python, this
> > explains why it is tidied to implementation choices in current CPython.
>
> I don't understand what you are saying at all. You have different
> opinions on what is more efficient? Efficiency can be measured, no need
> for opinions here.
In current CPython there's no tail recursion, function calls are rather
expensive ==> recursion is often avoided.
This is what I meant.
Which is the opposite. An implementation detail changed the way people
write code, not the opposite (which is absurd).
> So: Is tail recursion removed because of efficiency concerns or because
> beginners find it hard to understand?
It seems Guido stated this, so yes.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> In current CPython there's no tail recursion, function calls are rather
> expensive ==> recursion is often avoided.
>
> This is what I meant.
>
> Which is the opposite. An implementation detail changed the way people
> write code, not the opposite (which is absurd).
You think it's GOOD that people change their programming style to match
the limitations of a language implementation??
I don't think it's absurd to change a language's design+impl to allow
people to write code differently.
Ulrich Hobelmann wrote:
> Valentino Volonghi aka Dialtone wrote:
>> In current CPython there's no tail recursion, function calls are
>> rather expensive ==> recursion is often avoided.
>>
>> This is what I meant.
>>
>> Which is the opposite. An implementation detail changed the way
>> people write code, not the opposite (which is absurd).
>
> You think it's GOOD that people change their programming style to
> match the limitations of a language implementation??
Do you think it's good to have a language community be utterly fragmented,
like Lisp? A weakness in one respect can be a strength in another respect.
> I don't think it's absurd to change a language's design+impl to allow
> people to write code differently.
Then clearly you aren't down with the Zen Of Python. Python is about having
One, True, Clear way of doing things, at least in principle, and usually in
practice.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Trollhunt" - (n.) A searching out for persecution
of persons accused of Trolling. (c.f. witch-hunt)
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Ulrich Hobelmann wrote:
> > Valentino Volonghi aka Dialtone wrote:
> >> In current CPython there's no tail recursion, function calls are
> >> rather expensive ==> recursion is often avoided.
> >>
> >> This is what I meant.
> >>
> >> Which is the opposite. An implementation detail changed the way
> >> people write code, not the opposite (which is absurd).
> >
> > You think it's GOOD that people change their programming style to
> > match the limitations of a language implementation??
>
> Do you think it's good to have a language community be utterly fragmented,
No.
> like Lisp?
You're living 20+ years ago. What do you claim is fragmented now?
> A weakness in one respect can be a strength in another respect.
True, but in this case that is an irrelevant comment.
> > I don't think it's absurd to change a language's design+impl to allow
> > people to write code differently.
>
> Then clearly you aren't down with the Zen Of Python. Python is about having
> One, True, Clear way of doing things, at least in principle, and usually in
> practice.
Which is why Python really is a dumb language. There simply is no
such thing as "One, True, Clear way of doing things". Only some idiot
working in programming language "design" would ever even think this.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Brandon J. Van Every
Subject: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39p7teF62s7u8U1@individual.net>
jayessay wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>>
>> Do you think it's good to have a language community be utterly
>> fragmented,
>
> No.
>
>> like Lisp?
>
> You're living 20+ years ago. What do you claim is fragmented now?
I don't claim great knowledge of the Lisp world at present. But when I last
looked at it 2 years ago, I saw many compilers and interpreters with
incompatible FFIs. I will leave others to comment on how easy it is to port
from one implementation to another. My impression was that one did not
simply pick Lisp, one picked an implementation of Lisp and basically lived
or died by it.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> jayessay wrote:
> > "Brandon J. Van Every" <·····························@yahoo.com>
> > writes:
> >>
> >> Do you think it's good to have a language community be utterly
> >> fragmented,
> >
> > No.
> >
> >> like Lisp?
> >
> > You're living 20+ years ago. What do you claim is fragmented now?
>
> I don't claim great knowledge of the Lisp world at present.
Great. Another goofball making wild hyperbolic claims without any
knowledge of what he speaks.
> But when I last looked at it 2 years ago, I saw many compilers and
> interpreters with incompatible FFIs. I will leave others to comment
> on how easy it is to port from one implementation to another. My
> impression was that one did not simply pick Lisp, one picked an
> implementation of Lisp and basically lived or died by it.
Given that definition, Python is also utterly fragmented. Actually
C++ is as well.
> 20% of the world is real.
> 80% is gobbledygook we make up inside our own heads.
How ironic...
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39p9toF63ronnU1@individual.net>
jayessay wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
>
>> But when I last looked at it 2 years ago, I saw many compilers and
>> interpreters with incompatible FFIs. I will leave others to comment
>> on how easy it is to port from one implementation to another. My
>> impression was that one did not simply pick Lisp, one picked an
>> implementation of Lisp and basically lived or died by it.
>
> Given that definition, Python is also utterly fragmented.
Not within the world of Python.
> Actually C++ is as well.
That's true to some degree, especially the 'value adds' in MSVC++. But, it
has become more standards compliant as time has gone on.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> jayessay wrote:
> > "Brandon J. Van Every" <·····························@yahoo.com>
> >
> >> But when I last looked at it 2 years ago, I saw many compilers and
> >> interpreters with incompatible FFIs. I will leave others to comment
> >> on how easy it is to port from one implementation to another. My
> >> impression was that one did not simply pick Lisp, one picked an
> >> implementation of Lisp and basically lived or died by it.
> >
> > Given that definition, Python is also utterly fragmented.
>
> Not within the world of Python.
Sure it is, given the definition you state.
> > Actually C++ is as well.
>
> That's true to some degree, especially the 'value adds' in MSVC++.
> But, it has become more standards compliant as time has gone on.
That's irrelevant to the definition you give. Think name mangling
here.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39pf7vF64mjaoU1@individual.net>
jayessay wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>> jayessay wrote:
>>> "Brandon J. Van Every" <·····························@yahoo.com>
>>>
>>>> But when I last looked at it 2 years ago, I saw many compilers and
>>>> interpreters with incompatible FFIs. I will leave others to
>>>> comment on how easy it is to port from one implementation to
>>>> another. My impression was that one did not simply pick Lisp, one
>>>> picked an implementation of Lisp and basically lived or died by it.
>>>
>>> Given that definition, Python is also utterly fragmented.
>>
>> Not within the world of Python.
>
> Sure it is, given the definition you state.
I don't understand where you're coming from here. Python has *one*
implementation that matters, with different version numbers of course. If
you want to explain what you mean, feel free. I'm not smart enough to play
"I'm a better guru programmer."
>>> Actually C++ is as well.
>>
>> That's true to some degree, especially the 'value adds' in MSVC++.
>> But, it has become more standards compliant as time has gone on.
>
> That's irrelevant to the definition you give. Think name mangling
> here.
Yes, C++ name mangling is nasty. It is one of several reasons why it's so
damn hard to bind C++ code to any other language.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> jayessay wrote:
> > "Brandon J. Van Every" <·····························@yahoo.com>
> > writes:
> >> jayessay wrote:
> >>> "Brandon J. Van Every" <·····························@yahoo.com>
> >>>
> >>>> But when I last looked at it 2 years ago, I saw many compilers and
> >>>> interpreters with incompatible FFIs. I will leave others to
> >>>> comment on how easy it is to port from one implementation to
> >>>> another. My impression was that one did not simply pick Lisp, one
> >>>> picked an implementation of Lisp and basically lived or died by it.
> >>>
> >>> Given that definition, Python is also utterly fragmented.
> >>
> >> Not within the world of Python.
> >
> > Sure it is, given the definition you state.
>
> I don't understand where you're coming from here. Python has *one*
> implementation that matters, with different version numbers of course.
^^^^^^^^^^^^
1. Tell that to those who think otherwise (and use things like Jython)
2. If "one" implementation somehow == "not fragmented", then pick any
one Lisp implementation (free or otherwise) and voila' no
fragmentation even by your "definition".
3. Either way, according to your "definition", one is just as "utterly
fragmented" as the other. Which probably only really goes to show
just how utterly ridiculous your definition is.
> >>> Actually C++ is as well.
> >>
> >> That's true to some degree, especially the 'value adds' in MSVC++.
> >> But, it has become more standards compliant as time has gone on.
> >
> > That's irrelevant to the definition you give. Think name mangling
> > here.
>
> Yes, C++ name mangling is nasty. It is one of several reasons why it's so
> damn hard to bind C++ code to any other language.
Indeed. At least were square on this point.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39pjgkF64hes8U1@individual.net>
jayessay wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>
>> jayessay wrote:
>>> "Brandon J. Van Every" <·····························@yahoo.com>
>>> writes:
>>>> jayessay wrote:
>>>>> "Brandon J. Van Every" <·····························@yahoo.com>
>>>>>
>>>>>> But when I last looked at it 2 years ago, I saw many compilers
>>>>>> and interpreters with incompatible FFIs. I will leave others to
>>>>>> comment on how easy it is to port from one implementation to
>>>>>> another. My impression was that one did not simply pick Lisp,
>>>>>> one picked an implementation of Lisp and basically lived or died
>>>>>> by it.
>>>>>
>>>>> Given that definition, Python is also utterly fragmented.
>>>>
>>>> Not within the world of Python.
>>>
>>> Sure it is, given the definition you state.
>>
>> I don't understand where you're coming from here. Python has *one*
>> implementation that matters, with different version numbers of
>> course.
> ^^^^^^^^^^^^
>
> 1. Tell that to those who think otherwise (and use things like Jython)
I am inclined to think that the number of Jython users is trivial. Do you
know otherwise?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
jayessay wrote:
>>I don't understand where you're coming from here. Python has *one*
>>implementation that matters, with different version numbers of course.
>
> ^^^^^^^^^^^^
>
> 1. Tell that to those who think otherwise (and use things like Jython)
Jython and Stackless are implementations. The defacto standard is
Python, and the other two (or more?) look to that for compatibility.
> 2. If "one" implementation somehow == "not fragmented", then pick any
> one Lisp implementation (free or otherwise) and voila' no
> fragmentation even by your "definition".
I think Lisp is somewhat more fragmented, since there are many
non-standard interfaces that people use (threads, networking).
Of course some have portable interfaces as well, so it's not too bad,
certainly much better than the Scheme situation.
Ulrich Hobelmann <···········@web.de> writes:
> jayessay wrote:
> >>I don't understand where you're coming from here. Python has *one*
> >>implementation that matters, with different version numbers of course.
> > ^^^^^^^^^^^^
> > 1. Tell that to those who think otherwise (and use things like
> > Jython)
>
> Jython and Stackless are implementations. The defacto standard is
> Python, and the other two (or more?) look to that for compatibility.
This, of course, makes no sense as there is no formal standard of
which all three are implementations. It's pretty hard to be
compatible with an implementation (actually, it's not even clear what
that even means) without simply duplicating the implementation.
> > 2. If "one" implementation somehow == "not fragmented", then pick any
> > one Lisp implementation (free or otherwise) and voila' no
> > fragmentation even by your "definition".
>
> I think Lisp is somewhat more fragmented, since there are many
> non-standard interfaces that people use (threads, networking).
You have to make up your mind and at least try for some level of
consistent thought. If you're talking about a formal standard, Python
doesn't even have one. If you are talking about an _implementation_
then just _pick_ an implementation of Lisp. Neither one, in the
latter case, will be more _fragmented_ than the other as the notion of
"fragmentation" here is a _category error_, i.e., it's nonsense. Put
another way, if you want a single implementation, then quit whinning
and just pick one; if you want a _standard_, then I don't know how
Python even enters into it.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39rg82F647u3jU1@individual.net>
jayessay wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>>
>> Jython and Stackless are implementations. The defacto standard is
>> Python, and the other two (or more?) look to that for compatibility.
>
> This, of course, makes no sense as there is no formal standard
The "de facto" standard is...
> If you're talking about a formal standard, Python
> doesn't even have one.
The "de facto" standard is...
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> jayessay wrote:
> > Ulrich Hobelmann <···········@web.de> writes:
> >>
> >> Jython and Stackless are implementations. The defacto standard is
> >> Python, and the other two (or more?) look to that for compatibility.
> >
> > This, of course, makes no sense as there is no formal standard
>
> The "de facto" standard is...
>
> > If you're talking about a formal standard, Python
> > doesn't even have one.
>
> The "de facto" standard is...
Python is an implementation, not a standard. Once there's an ANSI or
IEEE spec for Python, THEN its a standard. Same with VB, Java, .NET and
all the other single implementation languages. Which is not to say they
aren't widely used, but thats still not the same as a standard. Common
Lisp, C, Fortran and COBOL (IIRC) are all standards-based languages with
multiple more or less conforming implementations.
Gregm
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39s6sqF63et71U1@individual.net>
Greg Menke wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>
>> jayessay wrote:
>>> Ulrich Hobelmann <···········@web.de> writes:
>>>>
>>>> Jython and Stackless are implementations. The defacto standard is
>>>> Python, and the other two (or more?) look to that for
>>>> compatibility.
>>>
>>> This, of course, makes no sense as there is no formal standard
>>
>> The "de facto" standard is...
>>
>>> If you're talking about a formal standard, Python
>>> doesn't even have one.
>>
>> The "de facto" standard is...
>
> Python is an implementation, not a standard. Once there's an ANSI or
> IEEE spec for Python, THEN its a standard.
No, it is a "de facto" standard *NOW*. Just because you have personal
issues with de facto standards...
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Greg Menke wrote:
> > "Brandon J. Van Every" <·····························@yahoo.com>
> > writes:
> >>
> >> The "de facto" standard is...
> >
> > Python is an implementation, not a standard. Once there's an ANSI or
> > IEEE spec for Python, THEN its a standard.
>
> No, it is a "de facto" standard *NOW*. Just because you have personal
> issues with de facto standards...
Dude, standards bodies come up with standards. Having a single
implementation of a programming language no way makes it a standard.
Windows is not a standard for the same reason. POSIX is more or less a
standard.
From dictionary.com;
de fac�to Audio pronunciation of "de facto" ( P ) Pronunciation Key (d fkt, d)
adv.
In reality or fact; actually.
adj.
1. Actual: de facto segregation.
2. Exercising power or serving a function without being legally or
officially established: a de facto government; a de facto nuclear
storage facility.
so "de facto standard" means an "actual standard"? If so, please
indicate where I can find the document detailing the standard elements
of a python implementation, hopefully also indicating which elements are
unspecified.
You cannot have a standard without the document- simply pointing to an
implementation will not do.
Gregm
Greg Menke wrote:
> Dude, standards bodies come up with standards. Having a single
We all know what a standard IS.
> implementation of a programming language no way makes it a standard.
> Windows is not a standard for the same reason. POSIX is more or less a
Windows is no real standard. Does anyone care? No.
> 2. Exercising power or serving a function without being legally or
> officially established: a de facto government; a de facto nuclear
> storage facility.
Windows is exercising power like a standard would (and everyone writes
drivers for it etc.), even though nobody made it standard.
> so "de facto standard" means an "actual standard"? If so, please
> indicate where I can find the document detailing the standard elements
> of a python implementation, hopefully also indicating which elements are
> unspecified.
I can't understand why you are so obsessed about this. We mentioned
several times that there is no official standard, so you are right. BUT
the programmers don't care. Like Windows, Python is exercising power
and everyone bows to that. If you need info for creating a Python
clone, ask on their newsgroup or ask Guido, whatever will do, and
whatever you want.
Ulrich Hobelmann <···········@web.de> writes:
> Greg Menke wrote:
> > Dude, standards bodies come up with standards. Having a single
>
> We all know what a standard IS.
Actually, no; we all make the term "standard" mean whatever we want
it to mean, as is obvious by this perennial discussion.
Common Lispers are no different; we unfortunately talk about "the
Ansi Standard", but it is not a "standard", it is a _specification_
that has been standardized. Look at the first paragraph in the
Scope and Purpose (1.1.1) of the spec, which can be found here:
http://www.franz.com/support/documentation/7.0/ansicl/subsecti/scopeand.htm
"The specification set forth in this document is designed to
promote the portability of Common Lisp programs among a variety
of data processing systems. It is a language specification aimed
at an audience of implementors and knowledgeable programmers. It
is neither a tutorial nor an implementation guide."
No mention of a "standard" here; what is "standard" about this
specification is that it was hashed out and _accepted_ as standard
by a standards body.
Common Lispers: we should be more careful when talking about the
specification for CL. Treat the term "standard" as a bananna peel
which we should walk around...
--
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
Greg Menke <··········@toadmail.com> writes:
> From dictionary.com;
>
> de fac�to Audio pronunciation of "de facto" ( P ) Pronunciation Key (d fkt, d)
> adv.
>
> In reality or fact; actually.
> adj.
>
> 1. Actual: de facto segregation.
>
> 2. Exercising power or serving a function without being legally or
> officially established: a de facto government; a de facto nuclear
> storage facility.
>
>
> so "de facto standard" means an "actual standard"?
No. It's the second meaning. But you were close.
To Python users their implementation (the one they chose to use)
serves the function of a standard: If they have a question regarding
the language, they type something into their interpreter.
While that may not be as cool as searching in a typically
incomprehensible super-long document Python fans will argue: The worst
thing that could happen to Python is an ANSI standard. Because this
would slow down the pace of its development to that of other
ANSI-standardized languages.
In my opinion, the best thing about Python is its libraries. It would
be an insanely huge and an insanely useless task to try to specify
them in a formal standard. The same holds for Java, Perl, Ruby, etc.
Matthias <····@spam.pls> writes:
> Greg Menke <··········@toadmail.com> writes:
> > From dictionary.com;
> >
> > de fac�to Audio pronunciation of "de facto" ( P ) Pronunciation Key (d fkt, d)
> > adv.
> >
> > In reality or fact; actually.
> > adj.
> >
> > 1. Actual: de facto segregation.
> >
> > 2. Exercising power or serving a function without being legally or
> > officially established: a de facto government; a de facto nuclear
> > storage facility.
> >
> >
> > so "de facto standard" means an "actual standard"?
>
> No. It's the second meaning. But you were close.
>
> To Python users their implementation (the one they chose to use)
> serves the function of a standard: If they have a question regarding
> the language, they type something into their interpreter.
No it doesn't serve as a "standard", its an example.
> While that may not be as cool as searching in a typically
> incomprehensible super-long document Python fans will argue: The worst
> thing that could happen to Python is an ANSI standard. Because this
> would slow down the pace of its development to that of other
> ANSI-standardized languages.
How in the hell do you expect to document what must, may, must not and
may not be in a language without a long document? If Python did become
ANSI standardized, the language syntax, grammar and behavior would be
standard, but it would probably not (and should not) standardize the
library bindings. Same as Common Lisp & C.
And since you don't read standards, on what basis do judge how useful
they are or aren't?
Let me put your argument the other way, why should I trust a language
whose syntax is evolving so quickly that I have to relearn it every
year?
I don't write throwaway apps, the stuff I work on has to work and be
portable without major or even significant revision to evolving hardware
architectures for 5 or 10 years- maybe longer depending on circumstance.
I can't afford to be saddled with a language that evolves ever further
past me year after year. And by "evolve", I mean object systems change,
syntactical features come and go- I do not mean new libraries come in
and deprecated ones leave.
I can write an app in Lispworks on an x86 Linux box, take the source and
run it on CMUCL on a SPARC or CLISP on a Windows machine with no
changes- no byte order issues, no byzantine ifdefs or makefile
craziness- its all working off the ANSI Common Lisp standard. With a
bit of planning & additional work, I can switch between architectures
and compilers in C too. THAT is what a standard gives you.
In Python-land, I have to get the same version of the single
implementation installed on each architecture & OS. And I have to stick
with this particular version because thats the version I'm authorized to
run this software on and heaven only knows how the language syntax and
grammar has evolved since. Ooops- what if its not supported on an
architechure & OS I need to run it on- and its a version from 3 years
ago? I'm stuck- no competitor can provide a standard implementation
which I can get authorization to use and run- no standard to work
from.. too bad for me. Do I now have to go in and port the language to
the new architecture myself? On what basis do I make the
architecture-specific decisions? How the hell do I validate the port?
A standard answers the last 2 questions, "pointing to the single
implementation" does not.
> In my opinion, the best thing about Python is its libraries. It would
> be an insanely huge and an insanely useless task to try to specify
> them in a formal standard. The same holds for Java, Perl, Ruby, etc.
I agree with you there. In the same way it would be a mess to document
that sort of thing for Common Lisp or C.
Gregm
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39ti7cF6619icU3@individual.net>
Greg Menke wrote:
>
> Let me put your argument the other way, why should I trust a language
> whose syntax is evolving so quickly that I have to relearn it every
> year?
Don't, if it makes you queasy. But you're introducing a new issue that
wasn't relevant to the original debate. We were never concerned about what
you do or don't trust.
> I don't write throwaway apps, the stuff I work on has to work and be
> portable without major or even significant revision to evolving
> hardware architectures for 5 or 10 years- maybe longer depending on
> circumstance.
Industrial Light & Magic simply back-ported later Python functionality to
their earlier machines. They could do this because Python is completely
open source, and because they have the financial resources to control their
own destiny in this manner. http://www.pythonology.com/success&story=ilm
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
Greg Menke wrote:
> How in the hell do you expect to document what must, may, must not and
> may not be in a language without a long document? If Python did become
I don't know how they do it. Ask on c.l.python. THAT would be on-topic.
> Let me put your argument the other way, why should I trust a language
> whose syntax is evolving so quickly that I have to relearn it every
> year?
What language would that be?
> I don't write throwaway apps, the stuff I work on has to work and be
> portable without major or even significant revision to evolving hardware
> architectures for 5 or 10 years- maybe longer depending on circumstance.
> I can't afford to be saddled with a language that evolves ever further
> past me year after year. And by "evolve", I mean object systems change,
> syntactical features come and go- I do not mean new libraries come in
> and deprecated ones leave.
Then refrain from using hacked-together languages that change every
year, like Perl or PHP.
> architecture-specific decisions? How the hell do I validate the port?
> A standard answers the last 2 questions, "pointing to the single
> implementation" does not.
A specification plus validation (regression-test), like exists for Java,
could do that. You don't need a standard for that.
Greg Menke <··········@toadmail.com> writes:
> Matthias <····@spam.pls> writes:
>
> > Greg Menke <··········@toadmail.com> writes:
> > > From dictionary.com;
> > >
> > > de fac�to Audio pronunciation of "de facto" ( P ) Pronunciation Key (d fkt, d)
> > > adv.
> > >
> > > In reality or fact; actually.
> > > adj.
> > >
> > > 1. Actual: de facto segregation.
> > >
> > > 2. Exercising power or serving a function without being legally or
> > > officially established: a de facto government; a de facto nuclear
> > > storage facility.
> > >
> > >
> > > so "de facto standard" means an "actual standard"?
> >
> > No. It's the second meaning. But you were close.
> >
> > To Python users their implementation (the one they chose to use)
> > serves the function of a standard: If they have a question regarding
> > the language, they type something into their interpreter.
>
> No it doesn't serve as a "standard", its an example.
I'm not participating in this game over words. If you define
"standard" as "a document, specifying..." then say so.
But don't expect the world to _automatically_ follow you in a narrow,
technical interpretation of the word. WordNet find's 6 distinct
meaning of "standard", yours is one of them. Your opponents probably
use #2, #3, #5:
2: commonly used or supplied; "standard procedure"; "standard
car equipment"
3: established or widely recognized as a model of authority or
excellence; "a standard reference work" [ant:
nonstandard]
5: regularly and widely used or sold; "a standard size"; "a
stock item" [syn: stock]
Above, I used "a place where you get your questions answered",
probably close to #3.
If you just make your assumptions explicit this whole "argument"
disappears.
> > While that may not be as cool as searching in a typically
> > incomprehensible super-long document Python fans will argue: The worst
> > thing that could happen to Python is an ANSI standard. Because this
> > would slow down the pace of its development to that of other
> > ANSI-standardized languages.
>
> How in the hell do you expect to document what must, may, must not and
> may not be in a language without a long document? If Python did become
> ANSI standardized, the language syntax, grammar and behavior would be
> standard, but it would probably not (and should not) standardize the
> library bindings. Same as Common Lisp & C.
Because Python without libs is pointless. More pointless than CL or C.
> And since you don't read standards, on what basis do judge how useful
> they are or aren't?
I do read them.
> Let me put your argument the other way, why should I trust a language
> whose syntax is evolving so quickly that I have to relearn it every
> year?
I don't care where you put your trust in.
> I don't write throwaway apps, the stuff I work on has to work and be
> portable without major or even significant revision to evolving hardware
> architectures for 5 or 10 years- maybe longer depending on circumstance.
> I can't afford to be saddled with a language that evolves ever further
> past me year after year. And by "evolve", I mean object systems change,
> syntactical features come and go- I do not mean new libraries come in
> and deprecated ones leave.
Then you should not use Python, Java, Perl, etc. With these
requirements, your best choice here would be a dead language that
doesn't change any more.
> I can write an app in Lispworks on an x86 Linux box, take the source and
> run it on CMUCL on a SPARC or CLISP on a Windows machine with no
> changes- no byte order issues, no byzantine ifdefs or makefile
> craziness- its all working off the ANSI Common Lisp standard.
None of the applications I've used today would work with Ansi CL _only_.
Each would require some extension.
> With a bit of planning & additional work, I can switch between
> architectures and compilers in C too. THAT is what a standard gives
> you.
These are the benefits of a standard. There are also costs involved.
The indirect cost, that you have to port & maintain every lib to/in
every implementation, is probably the most significant one. Here the
Python/Java/etc. model shines.
> > In my opinion, the best thing about Python is its libraries. It would
> > be an insanely huge and an insanely useless task to try to specify
> > them in a formal standard. The same holds for Java, Perl, Ruby, etc.
>
> I agree with you there. In the same way it would be a mess to document
> that sort of thing for Common Lisp or C.
I think it would be terrible for the Python community to have 12
different implementations of language syntax and semantics, each with
a different set of libraries supported.
For C it's not a problem, since C bindings are the de facto standard
(meaning #3) anyway. CL decided to pay the costs, i.e., less/more
expensive libraries for any given implementation.
Matthias <····@spam.pls> writes:
> Greg Menke <··········@toadmail.com> writes:
> > > To Python users their implementation (the one they chose to use)
> > > serves the function of a standard: If they have a question regarding
> > > the language, they type something into their interpreter.
> >
> > No it doesn't serve as a "standard", its an example.
>
> I'm not participating in this game over words. If you define
> "standard" as "a document, specifying..." then say so.
I define "standard" as a document, then.
> > > While that may not be as cool as searching in a typically
> > > incomprehensible super-long document Python fans will argue: The worst
> > > thing that could happen to Python is an ANSI standard. Because this
> > > would slow down the pace of its development to that of other
> > > ANSI-standardized languages.
> >
> > How in the hell do you expect to document what must, may, must not and
> > may not be in a language without a long document? If Python did become
> > ANSI standardized, the language syntax, grammar and behavior would be
> > standard, but it would probably not (and should not) standardize the
> > library bindings. Same as Common Lisp & C.
>
> Because Python without libs is pointless. More pointless than CL or C.
C without libraries is quite useful; bootloaders, device drivers, etc..
CL without libraries is standard Common Lisp and covers a quite a lot of
functionality.
>
> > I don't write throwaway apps, the stuff I work on has to work and be
> > portable without major or even significant revision to evolving hardware
> > architectures for 5 or 10 years- maybe longer depending on circumstance.
> > I can't afford to be saddled with a language that evolves ever further
> > past me year after year. And by "evolve", I mean object systems change,
> > syntactical features come and go- I do not mean new libraries come in
> > and deprecated ones leave.
>
> Then you should not use Python, Java, Perl, etc. With these
> requirements, your best choice here would be a dead language that
> doesn't change any more.
So C is dead?
> > I can write an app in Lispworks on an x86 Linux box, take the source and
> > run it on CMUCL on a SPARC or CLISP on a Windows machine with no
> > changes- no byte order issues, no byzantine ifdefs or makefile
> > craziness- its all working off the ANSI Common Lisp standard.
>
> None of the applications I've used today would work with Ansi CL _only_.
> Each would require some extension.
Thats true of the ones I've used today as well. OTOH, I know where the
extensions are- I also have a number of apps that don't.
> > With a bit of planning & additional work, I can switch between
> > architectures and compilers in C too. THAT is what a standard gives
> > you.
>
> These are the benefits of a standard. There are also costs involved.
> The indirect cost, that you have to port & maintain every lib to/in
> every implementation, is probably the most significant one. Here the
> Python/Java/etc. model shines.
Clearly there are costs- sometimes quite large. But there are also
costs for non-standardized (spec'ed and/or paper documented type of
standard) solutions. The relative magnitude of the two costs are also
going to be vary widely.
> > > In my opinion, the best thing about Python is its libraries. It would
> > > be an insanely huge and an insanely useless task to try to specify
> > > them in a formal standard. The same holds for Java, Perl, Ruby, etc.
> >
> > I agree with you there. In the same way it would be a mess to document
> > that sort of thing for Common Lisp or C.
>
> I think it would be terrible for the Python community to have 12
> different implementations of language syntax and semantics, each with
> a different set of libraries supported.
In the same way its terrible for C/C++?
> For C it's not a problem, since C bindings are the de facto standard
> (meaning #3) anyway. CL decided to pay the costs, i.e., less/more
> expensive libraries for any given implementation.
Its not a problem for Common Lisp either. If you want to add in a
library, do so- same as C. The procedures for doing so do vary between
implementations- which is a bummer- but they vary to some extent for
C/C++ as well.
If you settle on a single Common Lisp implementation, then you don't
have to deal with porting the library binding- just like Python.
Gregm
Greg Menke <··········@toadmail.com> writes:
> > > > portable without major or even significant revision to evolving hardware
> > > architectures for 5 or 10 years- maybe longer depending on circumstance.
> > > I can't afford to be saddled with a language that evolves ever further
> > > past me year after year. And by "evolve", I mean object systems change,
> > > syntactical features come and go- I do not mean new libraries come in
> > > and deprecated ones leave.
> >
> > Then you should not use Python, Java, Perl, etc. With these
> > requirements, your best choice here would be a dead language that
> > doesn't change any more.
>
> So C is dead?
Please. It just wouldn't be your best choice.
Esp. the current ANSI standard C'99 would be a bad choice as it's
still not so widely implemented and it's not clear when it will be
and how long it'll be supported. Same holds for C++. Its ANSI
standard changes every 5 years.
"Standard" does not guarantee everlasting compatibility. Though
with CL you should be on the save side...
> > > With a bit of planning & additional work, I can switch between
> > > architectures and compilers in C too. THAT is what a standard gives
> > > you.
> >
> > These are the benefits of a standard. There are also costs involved.
> > The indirect cost, that you have to port & maintain every lib to/in
> > every implementation, is probably the most significant one. Here the
> > Python/Java/etc. model shines.
>
> Clearly there are costs- sometimes quite large. But there are also
> costs for non-standardized (spec'ed and/or paper documented type of
> standard) solutions. The relative magnitude of the two costs are
> also going to be vary widely.
That was the whole and single point I was trying to make.
(Well this, and that there are different meanings for "standard".)
> > I think it would be terrible for the Python community to have 12
> > different implementations of language syntax and semantics, each with
> > a different set of libraries supported.
>
> In the same way its terrible for C/C++?
Much worse since integrating into C/C++ is at essentially a recompile/
relink. C bindings are omnipresent:
> > For C it's not a problem, since C bindings are the de facto standard
> > (meaning #3) anyway. CL decided to pay the costs, i.e., less/more
> > expensive libraries for any given implementation.
>
> Its not a problem for Common Lisp either. If you want to add in a
> library, do so- same as C.
I don't want to. I just want to have the libs. I don't want to
do the whole work myself. In fact, if it's something small I'm
much more likely to quickly hack it in Python.
And again: There's no work involved integrating a lib with C. Libs
already come with a C interface. Now, operating system issues are
more annoying to deal with. But that's the price to pay when
you work so close to the metal.
> The procedures for doing so do vary between
> implementations- which is a bummer- but they vary to some extent for
> C/C++ as well.
>
> If you settle on a single Common Lisp implementation, then you don't
> have to deal with porting the library binding- just like Python.
Exactly. In fact, I _do_ use only one CL implementation. That's
why I don't care overly for the standard. I'm still paying
the cost that I cannot benefit from the nice work people do for
these other CL implementations I happen not to use.
Then: The CL spec is an interesting read. Kind of cool. Others
do use multiple implementations and love the slow pace of changes.
So well, no deal. Just, please, don't try to bash the others
for not having a standard. They just made different trade-offs.
From: Ng Pheng Siong
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <d1dtfd$60v$2@nobel.pacific.net.sg>
According to Matthias <····@spam.pls>:
> Because Python without libs is pointless. More pointless than CL or C.
One counter example: Most of the Python programming I do these days
are 50 liner-type sysadmin or code/config generation scripts and AFAP I
avoid using anything that doesn't come as part of the standard
installation.
Since you don't play word games I trust you aren't going to argue that the
stuff that comes with the standard installation is known as the "standard
library" and therefore I'm still not "without libs".
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com -+- Transparent AES Encryption for SQLite
····@netmemetic.com (Ng Pheng Siong) writes:
> According to Matthias <····@spam.pls>:
> > Because Python without libs is pointless. More pointless than CL or C.
>
> One counter example: Most of the Python programming I do these days
> are 50 liner-type sysadmin or code/config generation scripts and AFAP I
> avoid using anything that doesn't come as part of the standard
> installation.
>
> Since you don't play word games I trust you aren't going to argue that the
> stuff that comes with the standard installation is known as the "standard
> library" and therefore I'm still not "without libs".
I consider the "standard libraries" as libraries.
Greg Menke <··········@toadmail.com> wrote:
+---------------
| How in the hell do you expect to document what must, may,
| must not and may not be in a language without a long document?
+---------------
IEEE Standard Scheme? [IEEE 1178-1990 (R1995).]
Almost exactly the same length as R4RS, 50 pages or so.
"Standard" doesn't *have* to mean "long document"...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Matthias wrote:
> Greg Menke <··········@toadmail.com> writes:
>
>>From dictionary.com;
>>
>>de fac�to Audio pronunciation of "de facto" ( P ) Pronunciation Key (d fkt, d)
>>adv.
>>
>> In reality or fact; actually.
>>adj.
>>
>> 1. Actual: de facto segregation.
>>
>> 2. Exercising power or serving a function without being legally or
>> officially established: a de facto government; a de facto nuclear
>> storage facility.
>>
>>
>>so "de facto standard" means an "actual standard"?
>
>
> No. It's the second meaning. But you were close.
>
> To Python users their implementation (the one they chose to use)
> serves the function of a standard: If they have a question regarding
> the language, they type something into their interpreter.
>
> While that may not be as cool as searching in a typically
> incomprehensible super-long document Python fans will argue: The worst
> thing that could happen to Python is an ANSI standard. Because this
> would slow down the pace of its development to that of other
> ANSI-standardized languages.
The discussion is not about whether standards are good or not. It's
about whether Python has one or not.
Pascal
From: Ng Pheng Siong
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <d1dt09$60v$1@nobel.pacific.net.sg>
According to Brandon J. Van Every <·····························@yahoo.com>:
> Greg Menke wrote:
> > Python is an implementation, not a standard. Once there's an ANSI or
> > IEEE spec for Python, THEN its a standard.
>
> No, it is a "de facto" standard *NOW*. Just because you have personal
> issues with de facto standards...
CPython is the de facto standard implementation of Python. Python doesn't
have a standard because it is defined by the implementation known as
CPython, not by some formal specification.
Jython and other Python implementations start from CPython's behaviour
not some formal specification.
But yeah, nowadays there are the PEPs, so Python is getting specified.
--
Ng Pheng Siong <····@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com -+- Transparent AES Encryption for SQLite
From: Peter Seibel
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <m3is3r430p.fsf@gigamonkeys.com>
Greg Menke <··········@toadmail.com> writes:
> "Brandon J. Van Every" <·····························@yahoo.com> writes:
>
>> jayessay wrote:
>> > Ulrich Hobelmann <···········@web.de> writes:
>> >>
>> >> Jython and Stackless are implementations. The defacto standard is
>> >> Python, and the other two (or more?) look to that for compatibility.
>> >
>> > This, of course, makes no sense as there is no formal standard
>>
>> The "de facto" standard is...
>>
>> > If you're talking about a formal standard, Python
>> > doesn't even have one.
>>
>> The "de facto" standard is...
>
> Python is an implementation, not a standard. Once there's an ANSI or
> IEEE spec for Python, THEN its a standard. Same with VB, Java, .NET and
> all the other single implementation languages. Which is not to say they
> aren't widely used, but thats still not the same as a standard.
Well, there's a middle ground--Java, while not "standardized", *is*
"specified". You can go buy _The Java Language Specification_ and _The
Java Virtual Machine Specification_ and implement them or use them to
determine what behavior you can expect from a Java compiler or VM
implementation. Now, thanks to bugs, those expectations might not
always be met by any particular implementation but that's true of
Common Lisp too--the best anyone can hope to do is "purport to
conform". I don't know of Microsoft has published specifications for
any of the .NET languages. I'm pretty sure CLR specification is
available--I don't think the Mono guys reversed engineered the whole
thing.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39s7aiF647u66U1@individual.net>
Peter Seibel wrote:
> I don't know of Microsoft has published specifications for
> any of the .NET languages.
Presumably because you never bothered to look for them, or had need to look
for them. C# and the CLR have been ISO standards for a few years now. The
.NET library is not, and that of course is Microsoft's whole business model.
There's so much "network effect" or "guilt by association" that they think
they can afford to make part of the technology standard, so that they can
claim something Sun can't with Java. In reality, it will be awhile before
anyone uses C# and the CLR "for their own sake" independent of .NET. In
fact it's possible it never happens, that something better than Java or C#
comes along before C# achieves any real world independence from Microsoft.
But FWIW all your basic higher level library functions are standard, like
lists and hashes and such. I checked, I needed to know what I might be
getting into.
If you want to see the standard and not pay for it, google for "C# ECMA."
ECMA was the precursor to the ISO standard and AFAIK it's identical.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Brandon J. Van Every wrote:
In reality, it will be awhile
> before
> anyone uses C# and the CLR "for their own sake" independent of .NET.
Well, the Mono (of "let's name our project after the slang for a
miserable infectious disease!" fame) project has done some vaguely
interesting stuff, but do run the risk of falling foul of U.S. (and soon
the EU if the bureaucrats are stupid enough to allow them) software
patents held by Microsoft.
Most prominent of Mono-using projects is probably Beagle, very loosely
the GNOME+Linux/BSD challenge to Microsoft WinFS (as far as I can
see, they're further along than Microsoft have publically demonstrated
WinFS to be, too).
http://www.gnome.org/projects/beagle/
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> jayessay wrote:
> > Ulrich Hobelmann <···········@web.de> writes:
> >>
> >> Jython and Stackless are implementations. The defacto standard is
> >> Python, and the other two (or more?) look to that for compatibility.
> >
> > This, of course, makes no sense as there is no formal standard
>
> The "de facto" standard is...
An implementation is not a standard - not an informal one, not a "de
facto" one, not one at all. You need some kind of specification for
that, not just a hunk of code. A good example of a "de facto"
standard would probably be Meyer's "Eiffel The Language" or Sun's Java
language Spec. No amount of O'Rielly books == a standard either. I'm
not sure what's so hard to understand about this. Also, it's not
necessarily a big deal to not have a standard.
The really odd thing in this thread is that for something like Common
Lisp which _does_ have a standard, you get comments saying that it is
"utterly fragmented" and that it is somehow "incorrect" to compare a
single implementation of Common Lisp with the "only implementation" of
Python when considering "fragmentation". Weird.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> An implementation is not a standard - not an informal one, not a "de
> facto" one, not one at all. You need some kind of specification for
Right. It isn't. But that's not the point. Everyone who uses Python,
Perl or Java treats them as a standard. So if you want to create a
compatible implementation, you need to conform. Or what was this thread
about, at all?
> that, not just a hunk of code. A good example of a "de facto"
> standard would probably be Meyer's "Eiffel The Language" or Sun's Java
> language Spec. No amount of O'Rielly books == a standard either. I'm
Those are specifications. They aren't standardized, but at least
formally (?) specified. For Python it's probably "fire the interpreter
up, and see what it says."
> not sure what's so hard to understand about this. Also, it's not
> necessarily a big deal to not have a standard.
That's what I mean :)
Nobody cares; people *use* languages. Very few read standards in the
first place.
> The really odd thing in this thread is that for something like Common
> Lisp which _does_ have a standard, you get comments saying that it is
> "utterly fragmented" and that it is somehow "incorrect" to compare a
Lots of things (Lisp extensions, libraries) are not standardized, AND
the several implementations don't all agree on them. This creates
fragmentation.
If Python has threads (I don't know...) I'm sure all implementations
treat them the same (or it's considered a bug). That's because every
programmer *treats* Python as the de-facto standard (meaning it's
treated as one, even though it isn't).
> single implementation of Common Lisp with the "only implementation" of
> Python when considering "fragmentation". Weird.
Because for all relevant purposes (everyone who codes Python), the one
big Python IS LAW. A divergent implementation would have ZERO users
immediately.
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39s88bF65lu1iU1@individual.net>
Ulrich Hobelmann wrote:
>
> Those are specifications. They aren't standardized, but at least
> formally (?) specified. For Python it's probably "fire the
> interpreter up, and see what it says."
I feel that people here are very lazy about inquiring into the actual
process by which Python is developed, including myself. In an effort to
somewhat alleviate this laziness and apathy among Lispers, I offer the
following URL: http://www.python.org/peps/
The argument, as far as I'm concerned, is pedantic. Some people want the
word "standard" to mean one and only one thing, like an ANSI or ISO
standard. Others are happy with a liberal arts / business / common sense /
operative / pragmatic usage of terms like "de facto standard." Since the
pedants can't re-engineer the use of language for their exclusive purposes,
at best we can agree to disagree about the solidity of terms.
As for the original point of this thread, the point is the Python world is
far more unified than the Lisp world, because it is driven by a de facto
standard. It is, for that matter, more unified than the C++ world as
someone pointed out. I don't know how unified Python or Java are, in the
cross-platform sense. I suspect they're in the same ballpark, but not
knowing enough about either I could be mistaken. C# is surely the most
unified of the current popular languages, because it does not attempt to be
cross-platform.
> Because for all relevant purposes (everyone who codes Python), the one
> big Python IS LAW. A divergent implementation would have ZERO users
> immediately.
Well no, it would have its homebrew and early adopter users. "Close to zero
users" is accurate. A non-conforming implementation would have to offer
major advantages, probably to some niche crowd.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Brandon J. Van Every wrote:
> I feel that people here are very lazy about inquiring into the actual
> process by which Python is developed, including myself. In an effort to
> somewhat alleviate this laziness and apathy among Lispers, I offer the
> following URL: http://www.python.org/peps/
From that page:
The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Reading this, who would have guessed they talk of *Python*?
> As for the original point of this thread, the point is the Python world is
> far more unified than the Lisp world, because it is driven by a de facto
> standard. It is, for that matter, more unified than the C++ world as
> someone pointed out. I don't know how unified Python or Java are, in the
> cross-platform sense.
I would think Python is more Unix-oriented, whereas Java is a little bit
more cross-platform.
On Thu, 17 Mar 2005 00:12:44 -0600, Ulrich Hobelmann wrote:
> I would think Python is more Unix-oriented, whereas Java is a little bit
> more cross-platform.
In my experience, Python is heaps more cross-platform than Java. But then,
one of the raisons d'etre of Python is to glue existing applications (and
systems) together, and for that to be practical you need to be maximally
cross-platform. Java is more of a 'classic' application development
language, so its needs to play nice with other systems are limited.
--
Christopher
Christopher Koppler wrote:
> On Thu, 17 Mar 2005 00:12:44 -0600, Ulrich Hobelmann wrote:
>
>
>>I would think Python is more Unix-oriented, whereas Java is a little bit
>>more cross-platform.
>
>
> In my experience, Python is heaps more cross-platform than Java. But then,
> one of the raisons d'etre of Python is to glue existing applications (and
> systems) together, and for that to be practical you need to be maximally
> cross-platform. Java is more of a 'classic' application development
> language, so its needs to play nice with other systems are limited.
>
I guess it's more portable over Unices, since it's more lightweight than
Java. The latter only runs on the BSDs for a couple of years, and I
guess there are no free or official implementations for more exotic
CPUs/platforms.
But right, Java tries to be standalone anyway. Since it doesn't play
nice with the system it runs on, I try not to use it (oh, and the
language and VM suck).
Ulrich Hobelmann <···········@web.de> writes:
> Brandon J. Van Every wrote:
> > I feel that people here are very lazy about inquiring into the actual
> > process by which Python is developed, including myself. In an effort to
> > somewhat alleviate this laziness and apathy among Lispers, I offer the
> > following URL: http://www.python.org/peps/
>
> From that page:
> The Zen of Python
>
> Beautiful is better than ugly.
> Explicit is better than implicit.
> Simple is better than complex.
> Complex is better than complicated.
> Flat is better than nested.
> Sparse is better than dense.
> Readability counts.
> Special cases aren't special enough to break the rules.
> Although practicality beats purity.
> Errors should never pass silently.
> Unless explicitly silenced.
> In the face of ambiguity, refuse the temptation to guess.
> There should be one-- and preferably only one --obvious way to do it.
> Although that way may not be obvious at first unless you're Dutch.
> Now is better than never.
> Although never is often better than *right* now.
> If the implementation is hard to explain, it's a bad idea.
> If the implementation is easy to explain, it may be a good idea.
> Namespaces are one honking great idea -- let's do more of those!
>
> Reading this, who would have guessed they talk of *Python*?
Python people? IMO, the real odd bit about the above is that they are
all subjective. I'm sure most any (excluding perhaps C++) language
community would claim most if not all of those for their own. Which,
come to think of it, was maybe what your point was.
> > As for the original point of this thread, the point is the Python world is
> > far more unified than the Lisp world, because it is driven by a de facto
This I don't buy. And even if one did buy it, why wouldn't, say the
cmucl world, be just as "unified"?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
>> From that page:
>>The Zen of Python
>>
>> [...]
>>Reading this, who would have guessed they talk of *Python*?
>
>
> Python people? IMO, the real odd bit about the above is that they are
> all subjective. I'm sure most any (excluding perhaps C++) language
> community would claim most if not all of those for their own. Which,
> come to think of it, was maybe what your point was.
Yes.
>>>As for the original point of this thread, the point is the Python world is
>>>far more unified than the Lisp world, because it is driven by a de facto
>
>
> This I don't buy. And even if one did buy it, why wouldn't, say the
> cmucl world, be just as "unified"?
You could say it is, but the Python (language, not the Lisp compiler ;)
) world is probably far bigger. Of course any single programmer is
unified in him/herself :)
On Fri, 18 Mar 2005 13:22:07 -0600, Ulrich Hobelmann wrote:
> ) world is probably far bigger. Of course any single programmer is
> unified in him/herself :)
But only over relatively short periods of time. As I'm programming now,
I'm definitely not unified in myself of 5 years ago...
--
Christopher
Ulrich Hobelmann <···········@web.de> writes:
> > not sure what's so hard to understand about this. Also, it's not
> > necessarily a big deal to not have a standard.
>
> That's what I mean :)
> Nobody cares; people *use* languages. Very few read standards in the
> first place.
Really? That may explain a lot of bugs and bad code...
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
Pascal Bourguignon wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>>>not sure what's so hard to understand about this. Also, it's not
>>>necessarily a big deal to not have a standard.
>>
>>That's what I mean :)
>>Nobody cares; people *use* languages. Very few read standards in the
>>first place.
>
>
> Really? That may explain a lot of bugs and bad code...
>
I wouldn't believe it does. People don't read standards, because they
(standards) are very formal, verbose and not really intuitive.
Mostly a programmer only writes code that clearly falls into unambiguous
terrain. More exotic structures are usually tried out in the small, if
not avoided. (OK, that's at least my philosophy.)
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39s8b4F612trnU1@individual.net>
Ulrich Hobelmann wrote:
>
> Mostly a programmer only writes code that clearly falls into
> unambiguous terrain. More exotic structures are usually tried out in
> the small, if not avoided. (OK, that's at least my philosophy.)
Sure as hell true for me with C++! Once upon a time I did all the multiply
inherited virtual base class stuff. I made it work, but it's a nightmare.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
Ulrich Hobelmann <···········@web.de> writes:
> jayessay wrote:
> > that, not just a hunk of code. A good example of a "de facto"
> > standard would probably be Meyer's "Eiffel The Language" or Sun's Java
> > language Spec. No amount of O'Rielly books == a standard either. I'm
>
> Those are specifications. They aren't standardized, but at least
> formally (?) specified. For Python it's probably "fire the interpreter
> up, and see what it says."
Thats a superficial measure of "standard". All it tells you is what an
implementation will produce, not how you might go about developing a
"compatible" alternative implementation, where "compatible" means
something you can meaure.
> > not sure what's so hard to understand about this. Also, it's not
> > necessarily a big deal to not have a standard.
>
> That's what I mean :)
> Nobody cares; people *use* languages. Very few read standards in the
> first place.
No doubt a large part of the reason why so much software is lamentably
bad wheel reinvention.
And if you think people don't use standards, I suggest you give a try at
serious aerospace or medical or financial software.
> > The really odd thing in this thread is that for something like Common
> > Lisp which _does_ have a standard, you get comments saying that it is
> > "utterly fragmented" and that it is somehow "incorrect" to compare a
>
> Lots of things (Lisp extensions, libraries) are not standardized, AND
> the several implementations don't all agree on them. This creates
> fragmentation.
Very few standards are complete. Lots of things in C/C++ compilers also
aren't standardized, leading to all sorts of chaos when switching
compilers. Is C/C++ also fragmented?
>
> > single implementation of Common Lisp with the "only implementation" of
> > Python when considering "fragmentation". Weird.
>
> Because for all relevant purposes (everyone who codes Python), the one
> big Python IS LAW. A divergent implementation would have ZERO users
> immediately.
So there can never be a competitive implementation of Python?
Gregm
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39th9nF637p2oU3@individual.net>
Greg Menke wrote:
>
> Thats a superficial measure of "standard". All it tells you is what
> an implementation will produce, not how you might go about developing
> a "compatible" alternative implementation, where "compatible" means
> something you can meaure.
Sure. Crossing swords with a de facto standard is *your* problem, because
they're bigger and badder and more important than you are. A de facto
standard *doesn't* have to iron everything out, it can lord its supremacy
over your puny head and command you to lick its boots. It's not an accident
that the contrast betweeen "de facto" and "de jure" is made. When the rule
of law is absent, Might Makes Right.
>> That's what I mean :)
>> Nobody cares; people *use* languages. Very few read standards in the
>> first place.
>
> No doubt a large part of the reason why so much software is lamentably
> bad wheel reinvention.
I will uncharacteristically defend NIH to point out how much more successful
Python is at acquiring new users than Lisp is. For many mere mortals, Lisp
is a bad wheel.
> Very few standards are complete. Lots of things in C/C++ compilers
> also aren't standardized, leading to all sorts of chaos when switching
> compilers. Is C/C++ also fragmented?
Yes, C++ is fragmented.
>> Because for all relevant purposes (everyone who codes Python), the
>> one big Python IS LAW. A divergent implementation would have ZERO
>> users immediately.
>
> So there can never be a competitive implementation of Python?
Not until the BDFL problem is overcome. Haven't you realized that he's
exercising "de facto" monopoly power? Sure, it's totally open source,
anybody can *try* to make another implementation, but how will they ever
keep up with the BDFL?
Actually this demonstrates how brittle and cottage industry all our
programming efforts are. Maybe 30 years from now, people will find it a bit
silly that we programmed everything with all these different, idiosyncratic
languages. "Why didn't they just run the universal Turing mapper?" "Well,
Veronica, back in their day computers weren't very powerful...."
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Greg Menke wrote:
>>Those are specifications. They aren't standardized, but at least
>>formally (?) specified. For Python it's probably "fire the interpreter
>>up, and see what it says."
>
>
> Thats a superficial measure of "standard". All it tells you is what an
> implementation will produce, not how you might go about developing a
> "compatible" alternative implementation, where "compatible" means
> something you can meaure.
Is there a standardized test suite (like Java AFAIK has) for Lisp that
you can fire up to see if you're running a standard CL?
>>Nobody cares; people *use* languages. Very few read standards in the
>>first place.
>
>
> No doubt a large part of the reason why so much software is lamentably
> bad wheel reinvention.
You might have a point there...
> And if you think people don't use standards, I suggest you give a try at
> serious aerospace or medical or financial software.
Yes. But for normal app development people don't really care. The
areas you mentioned are also expensive like hell (well, I don't know
about financial; I assume the wins are worth it).
> Very few standards are complete. Lots of things in C/C++ compilers also
> aren't standardized, leading to all sorts of chaos when switching
> compilers. Is C/C++ also fragmented?
I don't know too much about the C++ implementation situation. If still
most compilers are incomplete standards implementations, I think you
could call C++ fragmented.
Ulrich Hobelmann <···········@web.de> writes:
> Greg Menke wrote:
> >>Those are specifications. They aren't standardized, but at least
> >>formally (?) specified. For Python it's probably "fire the interpreter
> >>up, and see what it says."
> > Thats a superficial measure of "standard". All it tells you is what
> > an
>
> > implementation will produce, not how you might go about developing a
> > "compatible" alternative implementation, where "compatible" means
> > something you can meaure.
>
> Is there a standardized test suite (like Java AFAIK has) for Lisp that
> you can fire up to see if you're running a standard CL?
Yes, there is.
--
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
Ulrich Hobelmann <···········@web.de> writes:
> Greg Menke wrote:
> >>Those are specifications. They aren't standardized, but at least
> >>formally (?) specified. For Python it's probably "fire the interpreter
> >>up, and see what it says."
> > Thats a superficial measure of "standard". All it tells you is what an
> > implementation will produce, not how you might go about developing a
> > "compatible" alternative implementation, where "compatible" means
> > something you can meaure.
>
> Is there a standardized test suite (like Java AFAIK has) for Lisp that
> you can fire up to see if you're running a standard CL?
The standard tells you the things you can trust conforming
implementations to have as well as the things that it is free to do as
it chooses. On that basis, an implementation can be tested for the
necessary degree of conformance, not to mention you can avoid
implementation dependence as necessary. I believe there are a number of
Common Lisp test suites, though I've not used them- I work from the
Common Lisp standard so the code I write will run on a variety of
platforms and implementations.
> > And if you think people don't use standards, I suggest you give a try at
> > serious aerospace or medical or financial software.
>
> Yes. But for normal app development people don't really care. The
> areas you mentioned are also expensive like hell (well, I don't know
> about financial; I assume the wins are worth it).
Statements like this are really astonishing. You rely (and would
probably insist) on standards from your clothes to your car to your
computer and nearly everything else you come into contact with, but
somehow they are irrelevant when it comes to "normal app" development-
whatever that is.
>
> > Very few standards are complete. Lots of things in C/C++ compilers also
> > aren't standardized, leading to all sorts of chaos when switching
> > compilers. Is C/C++ also fragmented?
>
> I don't know too much about the C++ implementation situation. If still
> most compilers are incomplete standards implementations, I think you
> could call C++ fragmented.
I wouldn't. The standard is a bit unpleasant to start with, and spotty
conformance is annoying, but there is a wide spectrum from conformant to
fragmented.
Gregm
Ulrich Hobelmann <···········@web.de> writes:
> Greg Menke wrote:
>>>Those are specifications. They aren't standardized, but at least
>>>formally (?) specified. For Python it's probably "fire the interpreter
>>>up, and see what it says."
>> Thats a superficial measure of "standard". All it tells you is what
>> an implementation will produce, not how you might go about developing a
>> "compatible" alternative implementation, where "compatible" means
>> something you can meaure.
>
> Is there a standardized test suite (like Java AFAIK has) for Lisp that
> you can fire up to see if you're running a standard CL?
>
One that I know of, probably more.
I don't think any implementations actually succeed in *every* test,
but considering how obscure some of them are, I don't particularily mind.
>>>Nobody cares; people *use* languages. Very few read standards in the
>>>first place.
>> No doubt a large part of the reason why so much software is
>> lamentably
>> bad wheel reinvention.
>
> You might have a point there...
>
Actually, I read the standard _all the time_.
Okay, actually I'm reading the Hyperspec, but it's mostly the same
thing; the primary change is the addition of hyperlinks.
Why not, when the standard doubles as very good documentation?
>> And if you think people don't use standards, I suggest you give a try at
>> serious aerospace or medical or financial software.
>
> Yes. But for normal app development people don't really care. The
> areas you mentioned are also expensive like hell (well, I don't know
> about financial; I assume the wins are worth it).
>
Sure I care; if I'm not entirely sure what something does, I look it
up. Having the standard three keystrokes away helps, though; I admit
to not doing the same in C or C++.
At that point, paying some attention to what is compliant and what
isn't doesn't cost me very much.
Ulrich Hobelmann wrote:
> jayessay wrote:
>
>> An implementation is not a standard - not an informal one, not a "de
>> facto" one, not one at all. You need some kind of specification for
>
> Right. It isn't. But that's not the point. Everyone who uses Python,
> Perl or Java treats them as a standard. So if you want to create a
> compatible implementation, you need to conform. Or what was this thread
> about, at all?
So Stackless Python and JPython are not implementations of Python?
Stackless Python deviates from the "standard" because it provides
different stack semantics. JPython deviates from the "standard" because
it runs on a JVM. Both deviations are not covered by "standard" Python,
right?
Pascal
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39t60bF65b6pcU1@individual.net>
Pascal Costanza wrote:
>
> So Stackless Python and JPython are not implementations of Python?
> Stackless Python deviates from the "standard" because it provides
> different stack semantics. JPython deviates from the "standard"
> because it runs on a JVM. Both deviations are not covered by
> "standard" Python, right?
They're different. Some background material on differences:
http://www.onlamp.com/pub/a/python/2000/10/04/stackless-intro.html
http://jython.sourceforge.net/docs/differences.html
I think it comes down to how many users CPython, Jython, and Stackless
Python really have. If they all had an equal number of users, then we'd
call Python a fragmented community, but that's not actually the case. I
haven't found hard numbers, but it looks like Jython has serious stagnation
problems.
http://www.jython.org/cgi-bin/wiki/MovingJythonForward
I can't get a fix on the size of the Stackless Python community, it has
exceeded my Google patience. I believe it's tiny. I believe CPython
utterly dominates all other potentially competing implementations.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."
Brandon J. Van Every wrote:
> Pascal Costanza wrote:
>
>>So Stackless Python and JPython are not implementations of Python?
>>Stackless Python deviates from the "standard" because it provides
>>different stack semantics. JPython deviates from the "standard"
>>because it runs on a JVM. Both deviations are not covered by
>>"standard" Python, right?
>
> They're different. Some background material on differences:
> http://www.onlamp.com/pub/a/python/2000/10/04/stackless-intro.html
> http://jython.sourceforge.net/docs/differences.html
The first link doesn't tell me anything about differences that may or
may not be relevant when porting code from Python to Stackless Python.
The second link even counters the point that you are seemingly trying to
make. To quote from that page:
"CPython and Jython are two different implementations of the Python
language. While a Language Reference exists for the Python language,
there are a number of features of the language that are incompletely
specified."
"Any other differences not listed here can probably be considered a bug
in Jython. Understand of course that CPython and Jython advance at
different paces. All efforts are made to keep the two implementations in
sync, but that's not always possible."
Still, that page doesn't say anything about, say, metaclasses. Since a
goal of Jython was to be able to subclass Java classes and vice versa,
there is no chance that the metaclass models can be the same.
Pascal
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39tacmF665v78U1@individual.net>
Pascal Costanza wrote:
> Brandon J. Van Every wrote:
>> Pascal Costanza wrote:
>>
>>> So Stackless Python and JPython are not implementations of Python?
>>> Stackless Python deviates from the "standard" because it provides
>>> different stack semantics. JPython deviates from the "standard"
>>> because it runs on a JVM. Both deviations are not covered by
>>> "standard" Python, right?
>>
>> They're different. Some background material on differences:
>> http://www.onlamp.com/pub/a/python/2000/10/04/stackless-intro.html
>> http://jython.sourceforge.net/docs/differences.html
>
> The first link doesn't tell me anything about differences that may or
> may not be relevant when porting code from Python to Stackless Python.
Yes I know. I googled a long time to find a decent FAQ on CPython vs.
Stackless Python, then I gave up.
> The second link even counters the point that you are seemingly trying
> to make. To quote from that page:
>
> "CPython and Jython are two different implementations of the Python
> language. While a Language Reference exists for the Python language,
> there are a number of features of the language that are incompletely
> specified."
I think you're just devolving back to the emphasis on rigorous standards vs.
de facto standards. The point I'm clearly trying to make (or trying to make
clear?) is that CPython overwhelms any and all attempts to implement
something else. Nobody else is even vaguely in the running as to what
matters. It doesn't matter whether resolutions of differences are formal,
informal, semi-formal, or left as loose ends. CPython wins by a landslide.
This is not true in the Lisp world and hence Lisp is much more fragmented.
I commented long ago that, oddly enough, an ISO standard encourages vendors
to compete with each other to offer value adds, thus subverting the
standard. A de facto standard doesn't have this difficulty. You diverge
from the one who controls the implementation at your peril.
The standards-driven process I'm most familiar with is OpenGL. There's
certainly a helluva lot of jockeying in the ARB, enough so that the common
good of OpenGL suffers, and its market progress slows down relative to
Microsoft's DirectX.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
When no one else sells courage, supply and demand take hold.
Brandon J. Van Every wrote:
> Pascal Costanza wrote:
>
>>Brandon J. Van Every wrote:
>>
>>>Pascal Costanza wrote:
>>>
>>>>So Stackless Python and JPython are not implementations of Python?
>>>>Stackless Python deviates from the "standard" because it provides
>>>>different stack semantics. JPython deviates from the "standard"
>>>>because it runs on a JVM. Both deviations are not covered by
>>>>"standard" Python, right?
>>>
>>>They're different. Some background material on differences:
>>>http://www.onlamp.com/pub/a/python/2000/10/04/stackless-intro.html
>>>http://jython.sourceforge.net/docs/differences.html
>>
>>The first link doesn't tell me anything about differences that may or
>>may not be relevant when porting code from Python to Stackless Python.
>
> Yes I know. I googled a long time to find a decent FAQ on CPython vs.
> Stackless Python, then I gave up.
So why did you provide the link in the first place? I can google myself.
>>The second link even counters the point that you are seemingly trying
>>to make. To quote from that page:
>>
>>"CPython and Jython are two different implementations of the Python
>>language. While a Language Reference exists for the Python language,
>>there are a number of features of the language that are incompletely
>>specified."
>
> I think you're just devolving back to the emphasis on rigorous standards vs.
> de facto standards. The point I'm clearly trying to make (or trying to make
> clear?) is that CPython overwhelms any and all attempts to implement
> something else. Nobody else is even vaguely in the running as to what
> matters. It doesn't matter whether resolutions of differences are formal,
> informal, semi-formal, or left as loose ends. CPython wins by a landslide.
So the only way to implement Python correctly is to copy the source code
of CPython? Assume I would like to reimplement Python, say, in a
different language, how would I know that I have actually achieved my goal?
> This is not true in the Lisp world and hence Lisp is much more fragmented.
This is either a tautology or just nonsense.
> I commented long ago that, oddly enough, an ISO standard encourages vendors
> to compete with each other to offer value adds, thus subverting the
> standard.
You can add value without subverting a standard.
Pascal
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39thklF61vb88U3@individual.net>
Pascal Costanza wrote:
> Brandon J. Van Every wrote:
>>
>> Yes I know. I googled a long time to find a decent FAQ on CPython
>> vs. Stackless Python, then I gave up.
>
> So why did you provide the link in the first place? I can google
> myself.
Who says this thread is solely for your benefit? I am always considering
people who lurk, people who have just come to the party, who don't care
about a lot of what's going on and only want a snippet of information, and
especially people who search archives.
> So the only way to implement Python correctly is to copy the source
> code
> of CPython? Assume I would like to reimplement Python, say, in a
> different language, how would I know that I have actually achieved my
> goal?
Run lotsa tests? Really, if this is an operative question you should take
it up with the Python crowd.
>> This is not true in the Lisp world and hence Lisp is much more
>> fragmented.
>
> This is either a tautology or just nonsense.
Lisp has no de facto standard.
>> I commented long ago that, oddly enough, an ISO standard encourages
>> vendors to compete with each other to offer value adds, thus
>> subverting the standard.
>
> You can add value without subverting a standard.
So what? Vendors care more about their personal survival than they do about
standards.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
From: Thomas A. Russ
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <ymi64zqyslq.fsf@sevak.isi.edu>
"Brandon J. Van Every" <·····························@yahoo.com> writes:
>
> Lisp has no de facto standard.
>
Perhaps true for "Lisp" in general, but "Common Lisp" has a de jure
standard which, since it is widely implemented is also a de facto
standard.
Just because the standard doesn't cover everything doesn't make it any
less a standard. Python presumably doesn't have a standard xml parser,
does it? Or a standard game engine?
--
Thomas A. Russ, USC/Information Sciences Institute
From: Will Hartung
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <3a0l4sF662h8gU1@individual.net>
"Thomas A. Russ" <···@sevak.isi.edu> wrote in message
····················@sevak.isi.edu...
> "Brandon J. Van Every" <·····························@yahoo.com> writes:
> >
> > Lisp has no de facto standard.
>
> Perhaps true for "Lisp" in general, but "Common Lisp" has a de jure
> standard which, since it is widely implemented is also a de facto
> standard.
>
> Just because the standard doesn't cover everything doesn't make it any
> less a standard. Python presumably doesn't have a standard xml parser,
> does it? Or a standard game engine?
Well, to be blunt, Python doesn't have a Standard at all.
Regards,
Will Hartung
(·····@msoft.com)
Brandon J. Van Every wrote:
> Pascal Costanza wrote:
>
>>Brandon J. Van Every wrote:
>>
>>>Yes I know. I googled a long time to find a decent FAQ on CPython
>>>vs. Stackless Python, then I gave up.
>>
>>So why did you provide the link in the first place? I can google
>>myself.
>
> Who says this thread is solely for your benefit? I am always considering
> people who lurk, people who have just come to the party, who don't care
> about a lot of what's going on and only want a snippet of information, and
> especially people who search archives.
...but your answer wasn't even useful for them.
>>So the only way to implement Python correctly is to copy the source
>>code
>>of CPython? Assume I would like to reimplement Python, say, in a
>>different language, how would I know that I have actually achieved my
>>goal?
>
> Run lotsa tests?
And what should I test against?
>>>This is not true in the Lisp world and hence Lisp is much more
>>>fragmented.
>>
>>This is either a tautology or just nonsense.
>
> Lisp has no de facto standard.
Sure it has, many of them. With all the complications involved.
>>>I commented long ago that, oddly enough, an ISO standard encourages
>>>vendors to compete with each other to offer value adds, thus
>>>subverting the standard.
>>
>>You can add value without subverting a standard.
>
> So what? Vendors care more about their personal survival than they do about
> standards.
Not in my experience.
Pascal
From: Brandon J. Van Every
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <39tju0F669tj6U1@individual.net>
Pascal Costanza wrote:
> Brandon J. Van Every wrote:
>>
>> Who says this thread is solely for your benefit?
>
> ...but your answer wasn't even useful for them.
Ok, now I'm beginning to think you're just crossing into the realm of the
irritated and cantankerous. Otherwise I'd have to presume your ego is huge,
that you're the arbiter of what unknown persons searching archives find
useful.
>> Run lotsa tests?
>
> And what should I test against?
I don't want to help you solve Python standards problems anymore. We've
explained to death what the Python situation is, and the comparisons to the
Lisp situation are straightforward to make. I feel that most of this
discussion has been armchair generalship about the Python standards process,
with little real knowledge of PEPs or other test mechanisms on anybody's
part. Including my own. But at least I lifted a finger to actually find
out what the Python crowd really does.
>> Lisp has no de facto standard.
>
> Sure it has, many of them. With all the complications involved.
Lisp has no de facto standard implementation.
>> So what? Vendors care more about their personal survival than they
>> do about standards.
>
> Not in my experience.
You must be used to working with *very nice* companies! I'm used to VC++.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Pascal Costanza wrote:
> Ulrich Hobelmann wrote:
>> Right. It isn't. But that's not the point. Everyone who uses
>> Python, Perl or Java treats them as a standard. So if you want to
>> create a compatible implementation, you need to conform. Or what was
>> this thread about, at all?
>
>
> So Stackless Python and JPython are not implementations of Python?
> Stackless Python deviates from the "standard" because it provides
> different stack semantics. JPython deviates from the "standard" because
> it runs on a JVM. Both deviations are not covered by "standard" Python,
> right?
I don't know what Stackless and JP do. I think Stackless runs Python
apps like Python does, since it only changes the stack implementation.
There are stackful and stackless Schemes; they are all R5RS conformant.
OTOH Stackless might have features the normal Python doesn't, but I
don't enough about it.
Likewise I don't see why JP's being implemented on top of Java should be
visible to the programmer at all. I guess you don't notice (except
maybe in speed and memory use) if your Lisp (or whatever) runs on Intel,
PPC, or the JVM?
From: Brian Downing
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <9Ni_d.145080$4q6.136885@attbi_s01>
In article <···············@individual.net>,
Ulrich Hobelmann <···········@web.de> wrote:
> Likewise I don't see why JP's being implemented on top of Java should be
> visible to the programmer at all. I guess you don't notice (except
> maybe in speed and memory use) if your Lisp (or whatever) runs on Intel,
> PPC, or the JVM?
I believe CPython runs destructors as soon as the object falls out of
visibility (because it is reference-counted), while Jython runs the
destructor when the object is garbage collected. That is a very large
programmer-visible difference.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
Ulrich Hobelmann wrote:
> Pascal Costanza wrote:
>
>> Ulrich Hobelmann wrote:
>>
>>> Right. It isn't. But that's not the point. Everyone who uses
>>> Python, Perl or Java treats them as a standard. So if you want to
>>> create a compatible implementation, you need to conform. Or what was
>>> this thread about, at all?
>>
>>
>>
>> So Stackless Python and JPython are not implementations of Python?
>> Stackless Python deviates from the "standard" because it provides
>> different stack semantics. JPython deviates from the "standard"
>> because it runs on a JVM. Both deviations are not covered by
>> "standard" Python, right?
>
> I don't know what Stackless and JP do. I think Stackless runs Python
> apps like Python does, since it only changes the stack implementation.
> There are stackful and stackless Schemes; they are all R5RS conformant.
> OTOH Stackless might have features the normal Python doesn't, but I
> don't enough about it.
>
> Likewise I don't see why JP's being implemented on top of Java should be
> visible to the programmer at all. I guess you don't notice (except
> maybe in speed and memory use) if your Lisp (or whatever) runs on Intel,
> PPC, or the JVM?
The devil is in the details. A stackless implementation that exposes
some of its advantages may have interactions with other features. A Lisp
implemented on top of a JVM will very likely have problems if it wants
to integrate with the JVM well. For example, some Scheme implementations
on top of a JVM restrict their strings to be immutable, although the
Scheme specifications say that they should be mutable. (A specification
- thanks to Duane for suggesting the better term - allows you to talk
about such deviations while an implemtation doesn't.)
Pascal
Pascal Costanza wrote:
> The devil is in the details. A stackless implementation that exposes
> some of its advantages may have interactions with other features. A Lisp
> implemented on top of a JVM will very likely have problems if it wants
> to integrate with the JVM well. For example, some Scheme implementations
> on top of a JVM restrict their strings to be immutable, although the
> Scheme specifications say that they should be mutable. (A specification
> - thanks to Duane for suggesting the better term - allows you to talk
> about such deviations while an implemtation doesn't.)
Sure, a spec is better.
But to the example: I can see no reason why strings on the JVM should be
immutable [1]. Anyway, this is a deviation from the spec or desired
implementation (and would be one even if considered language in this
case were Python).
[1]: The usual way to do this would be to not use Java strings, but
define a SchemeString class that allows all Scheme string methods. Do
you have a pointer to why some Schemes don't do that?
Ulrich Hobelmann wrote:
> Pascal Costanza wrote:
>
>> The devil is in the details. A stackless implementation that exposes
>> some of its advantages may have interactions with other features. A
>> Lisp implemented on top of a JVM will very likely have problems if it
>> wants to integrate with the JVM well. For example, some Scheme
>> implementations on top of a JVM restrict their strings to be
>> immutable, although the Scheme specifications say that they should be
>> mutable. (A specification - thanks to Duane for suggesting the better
>> term - allows you to talk about such deviations while an implemtation
>> doesn't.)
>
> Sure, a spec is better.
>
> But to the example: I can see no reason why strings on the JVM should be
> immutable [1]. Anyway, this is a deviation from the spec or desired
> implementation (and would be one even if considered language in this
> case were Python).
>
> [1]: The usual way to do this would be to not use Java strings, but
> define a SchemeString class that allows all Scheme string methods. Do
> you have a pointer to why some Schemes don't do that?
Sorry, not at hand, but the reason is just because they want to
interoperate with existing Java libraries, probably without loosing too
much efficiency.
Pascal
jayessay wrote:
>>Jython and Stackless are implementations. The defacto standard is
>>Python, and the other two (or more?) look to that for compatibility.
>
>
> This, of course, makes no sense as there is no formal standard of
> which all three are implementations. It's pretty hard to be
> compatible with an implementation (actually, it's not even clear what
> that even means) without simply duplicating the implementation.
Why not? If Python is any good, a programmer should have some notion of
its semantics. There might be some undefined or ambiguous cases, where
Python (the impl.) is the reference for compatibility.
The impl is the defacto standard, since probably 90% use it.
>>>2. If "one" implementation somehow == "not fragmented", then pick any
>>> one Lisp implementation (free or otherwise) and voila' no
>>> fragmentation even by your "definition".
>>
>>I think Lisp is somewhat more fragmented, since there are many
>>non-standard interfaces that people use (threads, networking).
>
>
> You have to make up your mind and at least try for some level of
> consistent thought. If you're talking about a formal standard, Python
> doesn't even have one. If you are talking about an _implementation_
> then just _pick_ an implementation of Lisp. Neither one, in the
> latter case, will be more _fragmented_ than the other as the notion of
> "fragmentation" here is a _category error_, i.e., it's nonsense. Put
> another way, if you want a single implementation, then quit whinning
> and just pick one; if you want a _standard_, then I don't know how
> Python even enters into it.
Python is ist own standard. CL has an ANSI standard (I should say an AN
standard). Since all Lisps might differ somewhat in the unspecified
details of the standard, it would be wrong to pick any one
implementation and declare it standard.
Also, which one would you choose? I guess the popular impl's have each
about 20%-30% market share.
And frankly I don't think I'm "whinning" (you mean whining?), and I
don't even know what your problem with this standards thing is :)
Ulrich Hobelmann <···········@web.de> writes:
> jayessay wrote:
> >>Jython and Stackless are implementations. The defacto standard is
> >>Python, and the other two (or more?) look to that for compatibility.
> > This, of course, makes no sense as there is no formal standard of
> > which all three are implementations. It's pretty hard to be
> > compatible with an implementation (actually, it's not even clear what
> > that even means) without simply duplicating the implementation.
>
> Why not? If Python is any good, a programmer should have some notion
> of its semantics. There might be some undefined or ambiguous cases,
> where Python (the impl.) is the reference for compatibility.
I don't think you understand the difference between a standard and an
implementation. Just saying an implementation is "a standard" doesn't
make it so. For more info on this see Pascal Costanza's points.
> unspecified details of the standard, it would be wrong to pick any one
> implementation and declare it standard.
That's fundamentally because _implementations_ are not standards.
> And frankly I don't think I'm "whinning" (you mean whining?), and I
> don't even know what your problem with this standards thing is :)
The attribution was unclear and did not intend to refer to you. I
don't know if you are whining or not.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
>>Why not? If Python is any good, a programmer should have some notion
>>of its semantics. There might be some undefined or ambiguous cases,
>>where Python (the impl.) is the reference for compatibility.
>
>
> I don't think you understand the difference between a standard and an
> implementation. Just saying an implementation is "a standard" doesn't
> make it so. For more info on this see Pascal Costanza's points.
Sure, I agree with you two on that. However, Python clones are
developed (where I believe Stackless is based on the Python code?). So
it *is* being done, and the reason is that most language behavior is
visible from even *an* implementation. After all, a programmer develops
a notion how a language will behave, even without reading a standards
document. I agree that only a standard can cover the ambiguous or
undefined points, or separate accidental aspects of the de-facto
standard from the intended aspects.
Still, people are looking to Python as a standard. If something doesn't
work in Jython as it does in Python, Python is treated as a standard
definition.
Ulrich Hobelmann <···········@web.de> writes:
> Still, people are looking to Python as a standard. If something
> doesn't work in Jython as it does in Python, Python is treated as a
> standard definition.
I'm sure you're right about that - doesn't mean it makes any sense.
The logical implication here is that Python (the "de facto" one),
_can't_ have any bugs in it. How could it? By definition whatever it
does is the _correct standard behavior_. Frankly, to me, that makes
it much closer to _insane_ than _standard_.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Will Hartung
Subject: Re: Lisp fragmentation (was Re: Python becoming less Lisp-like)
Date:
Message-ID: <3a1636F664o8vU1@individual.net>
"jayessay" <······@foo.com> wrote in message
···················@rigel.goldenthreadtech.com...
> Ulrich Hobelmann <···········@web.de> writes:
>
> > Still, people are looking to Python as a standard. If something
> > doesn't work in Jython as it does in Python, Python is treated as a
> > standard definition.
>
> I'm sure you're right about that - doesn't mean it makes any sense.
> The logical implication here is that Python (the "de facto" one),
> _can't_ have any bugs in it. How could it? By definition whatever it
> does is the _correct standard behavior_. Frankly, to me, that makes
> it much closer to _insane_ than _standard_.
Poppycock. If you find a bug, you find a bug. There are no doubt some edge
cases where the behavior is questionable, and you as an implementor may not
know whether the demonstrated behavior of the de facto implementation is as
intended or an actual bug.
But, that's what the lists and such are for. Thankfully you have at your
disposal the implementor(s) of the de facto and they can clarify any odd
behavior that you encounter.
There are ambiguous gray areas in any complicated standard that suffer this
same problem.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> But, that's what the lists and such are for. Thankfully you have at your
> disposal the implementor(s) of the de facto and they can clarify any odd
> behavior that you encounter.
>
> There are ambiguous gray areas in any complicated standard that suffer this
> same problem.
Exactly. How do you know if something in a standard isn't a bug? It's
the some solution, ask the people who are into the language.
Ulrich Hobelmann <···········@web.de> writes:
> Will Hartung wrote:
> > But, that's what the lists and such are for. Thankfully you have at your
> > disposal the implementor(s) of the de facto and they can clarify any odd
> > behavior that you encounter.
> > There are ambiguous gray areas in any complicated standard that
> > suffer this
> > same problem.
>
> Exactly. How do you know if something in a standard isn't a bug?
> It's the some solution, ask the people who are into the language.
Of course it is not the same. A standard spec may indeed have a bug,
but that typically shows up when implementations show different
interpretations, which may then be argued to see if they are
resolvable. When you have a single implementation, what's to argue?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
"Will Hartung" <·····@msoft.com> writes:
> "jayessay" <······@foo.com> wrote in message
> ···················@rigel.goldenthreadtech.com...
> > Ulrich Hobelmann <···········@web.de> writes:
> >
> > > Still, people are looking to Python as a standard. If something
> > > doesn't work in Jython as it does in Python, Python is treated as a
> > > standard definition.
> >
> > I'm sure you're right about that - doesn't mean it makes any sense.
> > The logical implication here is that Python (the "de facto" one),
> > _can't_ have any bugs in it. How could it? By definition whatever it
> > does is the _correct standard behavior_. Frankly, to me, that makes
> > it much closer to _insane_ than _standard_.
>
> Poppycock. If you find a bug, you find a bug. There are no doubt some edge
What is the definition of a bug here? How would you know it is a bug
and not just something that behaved other than what _you_ expected but
which is "conforming".
> cases where the behavior is questionable, and you as an implementor may not
> know whether the demonstrated behavior of the de facto implementation is as
> intended or an actual bug.
Now you are getting there. I would suspect there are actually many of
these, though they may not show up often in typical ordinary code.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Ulrich Hobelmann wrote:
> jayessay wrote:
>
>>> Jython and Stackless are implementations. The defacto standard is
>>> Python, and the other two (or more?) look to that for compatibility.
>>
>> This, of course, makes no sense as there is no formal standard of
>> which all three are implementations. It's pretty hard to be
>> compatible with an implementation (actually, it's not even clear what
>> that even means) without simply duplicating the implementation.
>
> Why not? If Python is any good, a programmer should have some notion of
> its semantics. There might be some undefined or ambiguous cases, where
> Python (the impl.) is the reference for compatibility.
A language specification, contrary to an implementation, defines what an
implementation is required to do and, at the same time, where it has
freedoms. This allows implementors to experiment with different
tradeoffs, and programmers to decide whether they want to stick to
portable code or whether to stick with a specific implementation.
A single implementation language cannot provide this, unless it also has
a specification. For each and every implementation detail, some
programmers may expect them to be required and others may expect them to
be optional. For example: Is a specific sorting algorithm provided by a
library required to be stable, or is it just accidentally stable and you
could provide a different sorting algorithm as well? Are the iteration
constructs accidentally transformed into recursions, or must they be
implemented that way? Are integers intentionally 32 bits wide, or could
they be replaced by "real" integers? Is it an accident that the standard
library treats strings as immutable, or is it intentional and can I
tighten my implementation and make them actually immutable? Can I inline
function calls, or do programmers expect them to be changeable at
runtime? And so forth.
You cannot derive such information from an implementation.
Pascal
From: Christopher C. Stacy
Subject: Re: Python becoming less Lisp-like
Date:
Message-ID: <u64zsoc4a.fsf@news.dtpq.com>
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Do you think it's good to have a language community be utterly fragmented, like Lisp?
In what way is the Lisp community fragmented, in your view?
Also, do you consider yourself to be in this community,
or are you looking at this from the outside?
Ulrich Hobelmann <···········@web.de> wrote:
> You think it's GOOD that people change their programming style to match
> the limitations of a language implementation??
>
> I don't think it's absurd to change a language's design+impl to allow
> people to write code differently.
The world is full of languages that may or may not match your
programming style.
When I learned CL I had to learn a new programming style and so on for
every language. Every langauge has its idiomatic forms and the
programmer should learn how to write idiomatic code to gain the most out
of a particular language.
To summarize:
if learning a new style has some gains then yes, I think it's good.
Otherwise no, it is not.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
On Tue, 15 Mar 2005 20:02:01 +0100, Valentino Volonghi aka Dialtone wrote:
>
> Which is the opposite. An implementation detail changed the way people
> write code, not the opposite (which is absurd).
If you really believe this, I assume you write everything in assembler?
Anything else would be changing the implementation to match the way you
write code, which is apparently absurd.
Cheers,
Bill.
William Bland <·······@abstractnonsense.com> wrote:
> Anything else would be changing the implementation to match the way you
> write code, which is apparently absurd.
I don't think you fully understood what I meant.
And I don't write anything in asm.
but this has hardly anything to do with the original topic. Removing
lambda has nothing to do with the python implementation. Lambda in
python is crappy and completely useless except for inline function
definition.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
>>Do Python beginners understand metaclasses, or is this another feature
>>that is likely to be removed in the future?
>
> No they don't understand metaclasses probably. But since python relies
> on metaclasses for its object system they can't go away.
Metaclasses are not necessary to set up an object system. There exist
enough object systems / object-oriented languages that don't expose
their metalevel. So a) if the metaclasses are not necessary and b) they
are not understood by beginners, let me ask this question again: Why are
they still part of Python?
My assumption is that sooner or later people do advanced stuff with
Python because that's inevitable. In a similar vein, lambda and other
abstractions could remain part of Python because they make programmers'
lifes easier in the long run.
So to summarize: What I find weird is that in some parts of the
language, beginners' needs are addressed and more advanced stuff is
completely elided whereas in other parts, advanced users' needs are
addressed and beginners are left behind. This looks like a very
unbalanced design to me.
I know programming languages that are either primarily designed as
teaching languages, or else as advanced programming languages for either
academic, pragmatic or domain-specific purposes. What you say gives me
the impression that Python does a little bit of everything. What's the
rationale behind this?
Pascal
Pascal Costanza <··@p-cos.net> wrote:
> Metaclasses are not necessary to set up an object system. There exist
> enough object systems / object-oriented languages that don't expose
> their metalevel. So a) if the metaclasses are not necessary and b) they
> are not understood by beginners, let me ask this question again: Why are
> they still part of Python?
Not being exposed to beginners is a completely different matter. And it
seems to me that you don't actually know anything of the python
philosophy. My question is: If you don't understand python, why are you
questioning its design?
> My assumption is that sooner or later people do advanced stuff with
> Python because that's inevitable. In a similar vein, lambda and other
> abstractions could remain part of Python because they make programmers'
> lifes easier in the long run.
People already wrote VERY advanced stuff in python. In the short time
I've been using CL I've never found any framework at Twisted Matrix
level for working on networking and distributed applications so well
integrated and thought out (with tons of protocols already implemented
inside the framework and lots of ready to use code for most of the
jobs). Other people would cite Zope2 and Zope3. Others would talk about
ERP5, others again about Strakt's CAPS, or google.
Let me repeat myself: lambda is completely useless in python. defining a
function for doing the very same thing that you do with a lambda takes
you only one more line.
> So to summarize: What I find weird is that in some parts of the
> language, beginners' needs are addressed and more advanced stuff is
> completely elided whereas in other parts, advanced users' needs are
> addressed and beginners are left behind. This looks like a very
> unbalanced design to me.
Nobody is required to understand metaclasses to work with python. If you
need to do advanced stuff like redefining the way classes are created
then you probably need them, and nothing will stop you from getting to
the root of the problem instead of monkey patching the behaviour of your
objects.
To me this looks like a design which doesn't confuse beginners who will
never need to know (and will probably never know) metaclasses for their
basic homeworks, but helps with advanced uses of the object model.
What's the loss received from removing lambda? Nothing.
What's the loss received from removing metaclasses exposure?
Flexibility.
I'd rather lose nothing instead of flexibility.
But you seem to give lambdas more 'power' than they deserve, and this
probably will eventually be your python ignorance. Which is like me
saying that Lisp cannot be used for big projects because it lacks
syntax, plain false since you can live without syntax, the language
helps with a lot of powerful constructs.
> I know programming languages that are either primarily designed as
> teaching languages, or else as advanced programming languages for either
> academic, pragmatic or domain-specific purposes. What you say gives me
> the impression that Python does a little bit of everything. What's the
> rationale behind this?
Python is easy to use. But it's made for 'adults who know what they are
doing', which means that doesn't prevent you from doing what you think
is better for your particular job.
Philip J. Eby also implemented a CLOS like object model using decorators
in python in less than 1500 LOC in pyprotocols.dispatch.
Is there anything weird in teaching newbies to drive with N2 under the
passenger seat in case you need it?
You are probably missing the fact that lambda is useless in python (I
repeat myself again) while metaclasses are not and it's a common
practice to give hooks to the programmer to attach to python behaviours.
HTH, cheers :)
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
On Tue, 15 Mar 2005 22:48:19 +0100, Pascal Costanza wrote:
> However: The fact that Python neither has a concept for closures (be it
> Lisp-like lambda expressions or Smalltalk-like blocks) nor one for
> macros makes me very suspicious. This means that Python is missing
> something very important for building higher-level abstractions. Named
> local functions are not enough in that regard (unless you have some way
> of quoting code and evaluating it later on, but that probably gives you
> problems with getting your environments right).
>
Doesn't fn count as a closure?
def addn(n):
def fn(x):
return n + x
return fn
--
"You do not really understand something unless you can explain it to your
grandmother." — Albert Einstein.
Matthew D Swank wrote:
> On Tue, 15 Mar 2005 22:48:19 +0100, Pascal Costanza wrote:
>
>
>>However: The fact that Python neither has a concept for closures (be it
>>Lisp-like lambda expressions or Smalltalk-like blocks) nor one for
>>macros makes me very suspicious. This means that Python is missing
>>something very important for building higher-level abstractions. Named
>>local functions are not enough in that regard (unless you have some way
>>of quoting code and evaluating it later on, but that probably gives you
>>problems with getting your environments right).
>>
>
>
> Doesn't fn count as a closure?
>
> def addn(n):
> def fn(x):
> return n + x
> return fn
Yep. Change the paragraph above to "The fact that Python neither has a
concept for anonymous closures ...".
Sorry for the fuzz.
Pascal
Pascal Costanza <··@p-cos.net> wrote:
> However: The fact that Python neither has a concept for closures (be it
> Lisp-like lambda expressions or Smalltalk-like blocks) nor one for
> macros makes me very suspicious. This means that Python is missing
> something very important for building higher-level abstractions. Named
> local functions are not enough in that regard (unless you have some way
> of quoting code and evaluating it later on, but that probably gives you
> problems with getting your environments right).
What makes you think this? Python has closures as most of the advanced
languages. The only thing it lacks are macros.
def adder(x):
def _(y):
return x+y
return _
add_to_45 = adder(45)
add_to_45(5)
50
I often use closure to implement the so-called ajax using the framework
I help to develop: Nevow.
I can tell you more: Nevow needs closures when you want to parametrize
renderers or data directives.
> As a Lisper, I welcome that kind of power, but it really doesn't seem to
> fit the Python philosophy. Metaclass programming is a means for creating
> new abstractions, just like lambdas, blocks or macros. It's really in
> that same league. If a language provides metaclasses and ways to work
> with them beyond pure introspection, you open the pandora box of
> potentially providing more than one way to achieve things. For example,
> a metaclass could decide to transform the bodies of its associated
> methods when they are tail-recursive so that they are actually executed
> iteratively. Suddenly you have a choice of expressing things iteratively
> or recursively. (I assume that metaclasses in Python are that powerful,
> maybe they are not...)
Modifying code on the fly is not possible in python. But you can bind
different functions inside the class namespace using a metaclass
depending on constructor arguments.
Metaclasses are actually very powerful, in the next Python cookbook (for
which I did techical reviewage) there's a recipe that automatically
binds non local variables in the local namespace modifying the bytecode
at compile time.
recursion is felt like a complex thing that shouldn't be used except for
the very few things for which it is the only solution. Simply speaking,
python has many things that help you avoid recursion.
> ...which seems to be a very different goal than "there's only one way to
> do it". Did Python change its goals? Or what is it that I am missing?
You are missing something. Nobody said that python prevents you from
shooting you in your foot. If you want to write:
(5).__add__(5)
instead of:
5 + 5
it's perfectly legal.
The clear way is the pythonic way and the pythonic way is the way that
follows the Zen of Python which also states that flat is better than
nested ;) .
And once you are comfortable with python you quickly end up with the
same algorithms that the other developers use. This is a very big
advantage since foreign code looks very familiar to every developer.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> Pascal Costanza <··@p-cos.net> wrote:
> > However: The fact that Python neither has a concept
> > for closures (be it Lisp-like lambda expressions or
> > Smalltalk-like blocks) nor one for macros makes me
> > very suspicious. This means that Python is missing something
> > very important for building higher-level abstractions. Named
> > local functions are not enough in that regard (unless you have
> > some way of quoting code and evaluating it later on, but that
> > probably gives you problems with getting your environments right).
>
> What makes you think this? Python has closures as most of the
> advanced languages. The only thing it lacks are macros.
>
> def adder(x):
> def _(y):
> return x+y
> return _
>
> add_to_45 = adder(45)
> add_to_45(5)
> 50
Could you do a minor refactoring, and change adder() to update the
value of x, so that repeated calls to
add_to_45(5)
will return 55, then 60, then 65...
I haven't used Python in a while, and haven't read the entire thread,
but I suspect you'd have to add in another feature like Python's
generators.
Tayssir John Gabbour <···········@yahoo.com> wrote:
> Could you do a minor refactoring, and change adder() to update the
> value of x, so that repeated calls to
> add_to_45(5)
> will return 55, then 60, then 65...
>
> I haven't used Python in a while, and haven't read the entire thread,
> but I suspect you'd have to add in another feature like Python's
> generators.
generators or classes. This is because of a python wart with namespaces.
def adder(n):
n = n
def _(y)
n = n+ y
...
...
This raises UnboundLocalError because variables used in expressions must
be already existent. But in this case the language doesn't know if you
want to modify or create a local n or the outer n. Unfortunately this is
fixable only using the global namespace and the global keyword and this
rather misses the point. This is fixable using a bit of magic but it's
not common (using sys._getframe() to get the outer frame and gather the
local variables from the outer frame to update the right n)
If you want to have this behaviour the most common code is:
class Adder(object):
def __init__(self, start=0):
self.current = start
def __call__(self, add=1):
self.current = self.current + add
return self.current
This would work as expected:
add_to_45 = Adder(45)
add_to_45(5)
50
add_to_45(5)
55
add_to_45(5)
60
For the more common usecase there is itertools.count() that takes a
start and then keeps adding 1 for every iteration over it.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone <························@gmail.com>
wrote:
> This raises UnboundLocalError because variables used in expressions must
this should be:
... used in expressions and/or statements must ...
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
> If you want to have this behaviour the most common code is:
>
> class Adder(object):
> def __init__(self, start=0):
> self.current = start
> def __call__(self, add=1):
> self.current = self.current + add
> return self.current
>
> This would work as expected:
>
> add_to_45 = Adder(45)
> add_to_45(5)
> 50
> add_to_45(5)
> 55
> add_to_45(5)
> 60
>
> For the more common usecase there is itertools.count() that takes a
> start and then keeps adding 1 for every iteration over it.
And now you're getting at the heart of what annoys me so thoroughly
about some Python development decisions. We have a simple clean,
general feature ... with some warts. So, rather than fix the warts,
rather than improve the general simple feature, we intoduce a plethora
of utilities to cover "common usecases".
Drives me nuts.
"Tayssir John Gabbour" <···········@yahoo.com> writes:
> Valentino Volonghi aka Dialtone wrote:
>
> > def adder(x):
> > def _(y):
> > return x+y
> > return _
> >
> > add_to_45 = adder(45)
> > add_to_45(5)
> > 50
>
>
> Could you do a minor refactoring, and change adder() to update the
> value of x, so that repeated calls to
> add_to_45(5)
> will return 55, then 60, then 65...
>>> def adder(x):
... x = [x]
... def _(y):
... res = x[0] + y
... x[0] += 5
... return res
... return _
...
>>> a = adder(45)
>>> a(5)
50
>>> a(5)
55
>>> a(5)
60
>>>
i.e. enclosed variables are read-only, but mutable.
Valentino Volonghi aka Dialtone wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>>However: The fact that Python neither has a concept for closures (be it
>>Lisp-like lambda expressions or Smalltalk-like blocks) nor one for
>>macros makes me very suspicious. This means that Python is missing
>>something very important for building higher-level abstractions. Named
>>local functions are not enough in that regard (unless you have some way
>>of quoting code and evaluating it later on, but that probably gives you
>>problems with getting your environments right).
>
> What makes you think this? Python has closures as most of the advanced
> languages. The only thing it lacks are macros.
>
> def adder(x):
> def _(y):
> return x+y
> return _
>
> add_to_45 = adder(45)
> add_to_45(5)
> 50
This is an example in which you use named functions, not anonymous
closures (sorry for being a bit too fuzzy in my previous post).
What anonymous closures allow you to do is build your own language
abstractions that control the evaluation of code that has been passed to
them, like "if":
(defun if (cond then else)
(cond (cond (funcall then))
(t (funcall else))))
...which you can use like this:
(if (some-condition)
(lambda () (print "Hello."))
(lambda () (print "Go away.")))
or "while":
(defun while (cond block)
(if (funcall cond)
(lambda ()
(funcall block)
(while cond block))
(lambda () ())))
(while
(lambda () (< i 10))
(lambda () (incf i)))
Note that we don't program like this in Lisp, of course, these are just
toy examples for illustration purposes. This code contains too many
lambdas: In Lisp, we use macros to hide so that code becomes more
natural, and in Smalltalk, they use a different syntax and slightly
different semantics for anonymous closures, so that code becomes more
readable without macros in such cases.
But these are the kinds of highel-constructs that you can't seem to
build in Python because you don't have the power of lambdas, blocks or
macros at hand. It still escapes me why you suddenly want to have that
kind of power at a metaclass level.
> And once you are comfortable with python you quickly end up with the
> same algorithms that the other developers use. This is a very big
> advantage since foreign code looks very familiar to every developer.
This reminds me of an old joke from the 80's: The American general tells
the Russian general that the Soviet Union doesn't allow their people to
travel where they want. The Russion general responds: "But they can
travel where they want, for example to Poland, Czechoslowakia, East
Germany, and so on." "But what about France, Italy, Spain, Australia,
South America?" "They don't want to."
;)
Pascal
Pascal Costanza wrote:
> Valentino Volonghi aka Dialtone wrote:
>>
>> And once you are comfortable with python you quickly end up with the
>> same algorithms that the other developers use. This is a very big
>> advantage since foreign code looks very familiar to every developer.
>
> This reminds me of an old joke from the 80's: The American general
> tells the Russian general that the Soviet Union doesn't allow their
> people to travel where they want. The Russion general responds: "But
> they can travel where they want, for example to Poland,
> Czechoslowakia, East Germany, and so on." "But what about France,
> Italy, Spain, Australia, South America?" "They don't want to."
>
> ;)
If you rate Python on the basis of "I want it to be good for everything,"
clearly it will fail you. As I commented some time ago, it fails me on high
performance 3D graphics and AI problems. Python is really nice as long as
you remain within the Python universe. When you need to do something
outside that universe, it sucks.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
On Tue, 15 Mar 2005 23:56:59 +0100, Pascal Costanza wrote:
> This reminds me of an old joke from the 80's: The American general tells
> the Russian general that the Soviet Union doesn't allow their people to
> travel where they want. The Russion general responds: "But they can
> travel where they want, for example to Poland, Czechoslowakia, East
> Germany, and so on." "But what about France, Italy, Spain, Australia,
> South America?" "They don't want to."
>
> ;)
>
> Pascal
I think you have (rather sardonically of course) hit upon why Python
fans like their language so much: they don't want to go to those
other places. I think the level of expressiveness offered by Python
and Lisp is closer than Python and Java or C++.
I seem to recall all the examples for Peter Norvig's "AI, a Modern
Approach" are available in Python as well as Lisp. I don't think advanced
Python programmers will miss the cut features very much; generators, lazy
lists, metaobjects, and named closures will certainly be sufficient. I
think that's what Pyton programmers want, sufficient expressiveness with a
simple Algol syntax (Both of these are subject to feature creep but I
think it is a design goal).
N.B. I actually dislike python syntax quite a bit, but I think I
understand why Python is the way it is.
Matt
--"You do not really understand something unless you can explain it to
your grandmother." — Albert Einstein.
Pascal Costanza <··@p-cos.net> wrote:
> But these are the kinds of highel-constructs that you can't seem to
> build in Python because you don't have the power of lambdas, blocks or
> macros at hand. It still escapes me why you suddenly want to have that
> kind of power at a metaclass level.
You are very away the reality. All your examples seem to share one
thing: they all modify code on the fly with macros or pass lambdas as
arguments to functions.
Everything in python is an object and thus can be passed as an argument
to each function you want.
Ruby or smalltalk probably need blocks because their function object are
not first class citizens while in python everything is a first class
citizen.
import random
def some_condition():
return random.choice([True, False])
def then_fun(): print "Hello"
def else_fun(): print "Go away"
def if_expr(some_condition, then_fun, else_fun):
if some_condition(): then_fun()
else: else_fun()
if_expr(some_condition, then_fun, else_fun)
The real difference is between expressions and statements.
if is a statement. I might agree that this is not 'good', but this is
the main reason because python is easier to learn for beginners. It
doesn't force you any particular paradigm, chose or write yourself one.
> This reminds me of an old joke from the 80's: The American general tells
> the Russian general that the Soviet Union doesn't allow their people to
> travel where they want. The Russion general responds: "But they can
> travel where they want, for example to Poland, Czechoslowakia, East
> Germany, and so on." "But what about France, Italy, Spain, Australia,
> South America?" "They don't want to."
>
> ;)
Ehe :), Sort of. But really, they don't want to :).
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>>But these are the kinds of highel-constructs that you can't seem to
>>build in Python because you don't have the power of lambdas, blocks or
>>macros at hand. It still escapes me why you suddenly want to have that
>>kind of power at a metaclass level.
>
> You are very away the reality. All your examples seem to share one
> thing: they all modify code on the fly with macros or pass lambdas as
> arguments to functions.
They show how you can control the evaluation of code, while keeping the
code whose evaluation you want to control can stay where it belongs.
> Everything in python is an object and thus can be passed as an argument
> to each function you want.
>
> Ruby or smalltalk probably need blocks because their function object are
> not first class citizens while in python everything is a first class
> citizen.
In Smalltalk, blocks are functions objects. I don't know enough about
Ruby, but I guess it's the same there.
> import random
> def some_condition():
> return random.choice([True, False])
>
> def then_fun(): print "Hello"
> def else_fun(): print "Go away"
>
> def if_expr(some_condition, then_fun, else_fun):
> if some_condition(): then_fun()
> else: else_fun()
>
> if_expr(some_condition, then_fun, else_fun)
In order to make this work you had to move the then and else parts
outside of the if statement. I don't want that.
You should take a look at Pico, it has a nicer solution for this. Here
is the while loop in Pico:
while(cond(),body()) ::
if(cond(), {body(); while(cond(), body())})
while(i<10, i=i+1)
This is nice because Pico has managed to stay away from anonymous
closures but only allows named functions while still being able to
control evaluation of code. Pico achieves this by allowing function
headers to be declared as parameters inside other function headers.
Of course, this also gives you more than "one way to do it". But Pico is
successfully used as a beginners' language, which is its main goal.
> The real difference is between expressions and statements.
> if is a statement. I might agree that this is not 'good', but this is
> the main reason because python is easier to learn for beginners.
I don't buy that.
Pascal
Pascal Costanza <··@p-cos.net> wrote:
> In order to make this work you had to move the then and else parts
> outside of the if statement. I don't want that.
This difference (if it is a big one) doesn't change anything from my
point of view. And I think we are going down the 'I like this more than
that'-path.
To me the Pico syntax is completely unreadable because I'm not used to
that kind of syntax whereas python syntax is terse and immediately
obvious.
This is just to say that this thread started because if python lose its
lambda it wouldn't be anymore productive and no more big projects and
bla bla bla.
Currently the discussion is:
python misses anonymous closures and in python you cannot embed a
condition definition inside an if.
Enough for me ;).
Anyway there is, as usual, a lot of discussion about blocks in python as
a substitute for lambdas, and there even is a wiki on python.org about
this issue. I don't think they will ever come inside the language, but
with PyPy you will be able to add them very easily tweaking the language
in python itself (in this case it's just tweaking the parser more than
the language which already understands passing functions objects).
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
> To me the Pico syntax is completely unreadable because I'm not used
> to that kind of syntax whereas python syntax is terse and
> immediately obvious.
Do you have any idea how completely ridiculous this sounds? Read it
and think about it for a moment. It borders on being embarrassing
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay <······@foo.com> wrote:
> Do you have any idea how completely ridiculous this sounds? Read it
> and think about it for a moment. It borders on being embarrassing
Weren't you talking with brandon? Go on then. This was a friendly
discussion, I don't want to start yet another flame because you are
frustrated for your being a real man (tm) but nobody noticing you.
bye.
Please don't reply, I won't reply to you anymore hence you will waste
bandwidth and time (I'm sure you have other people to annoy)
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
> jayessay <······@foo.com> wrote:
>
> > Do you have any idea how completely ridiculous this sounds? Read it
> > and think about it for a moment. It borders on being embarrassing
>
> Weren't you talking with brandon? Go on then. This was a friendly
> discussion, I don't want to start yet another flame because you are
> frustrated for your being a real man (tm) but nobody noticing you.
>
> bye.
So long. And thanks for the humor.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: M Jared Finder
Subject: Re: Python becoming less Lisp-like
Date:
Message-ID: <4237c233$1_2@x-privat.org>
Valentino Volonghi aka Dialtone wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>
>>In order to make this work you had to move the then and else parts
>>outside of the if statement. I don't want that.
>
>
> This difference (if it is a big one) doesn't change anything from my
> point of view. And I think we are going down the 'I like this more than
> that'-path.
>
> To me the Pico syntax is completely unreadable because I'm not used to
> that kind of syntax whereas python syntax is terse and immediately
> obvious.
>
> This is just to say that this thread started because if python lose its
> lambda it wouldn't be anymore productive and no more big projects and
> bla bla bla.
> Currently the discussion is:
> python misses anonymous closures and in python you cannot embed a
> condition definition inside an if.
>
> Enough for me ;).
>
> Anyway there is, as usual, a lot of discussion about blocks in python as
> a substitute for lambdas, and there even is a wiki on python.org about
> this issue. I don't think they will ever come inside the language, but
> with PyPy you will be able to add them very easily tweaking the language
> in python itself (in this case it's just tweaking the parser more than
> the language which already understands passing functions objects).
I find blocks/anonymous functions to be *extremely* important in writing
clear, concise code. My original example was a structured binary file
format writer, which in Lisp looks like this:
(write-chunk s +data-id+
(lambda ()
(write-int32 s +version+)
(write-int32 s (length enemies))
(do-seq (enemy enemies)
(write-chunk s +enemy-id+
(lambda ()
(write-int32 s (enemy-health enemy))
(write-int32 s (enemy-position enemy))
(write-int32 s (enemy-type enemy)))))
(write-int32 s (length power-ups))
(do-seq (power-up power-ups)
(write-chunk s +power-up-id+
(lambda ()
(write-int32 s (power-up-type power-up))
(write-int32 s (power-up-position power-up)))))))
I find this to be very readable because the form of the code matches
directly up to the form of the file format. Just glancing at this, I
can see the simple structured file format, and I suspect that with a
trivial amount of Lisp knowledge, you could too.
If each block has to be given a name before it can be used, then the
structure is turned *partially* upside down, making it much harder to
read. The previous example would become something like this:
(flet ((enemy-block-writer ()
(write-int32 s (enemy-health enemy))
(write-int32 s (enemy-position enemy))
(write-int32 s (enemy-type enemy)))
(power-up-block-writer ()
(write-int32 s (power-up-type power-up))
(write-int32 s (power-up-position power-up))))
(flet ((data-block-writer ()
(write-int32 s +version+)
(write-int32 s (length enemies))
(do-seq (enemy enemies)
(write-chunk s +enemy-id+ enemy-block-writer))
(write-int32 s (length power-ups))
(do-seq (power-up power-ups)
(write-chunk s +power-up-id+ power-up-block-writer))))
(write-chunk s +data-id+ data-block-writer)))
Now the code flow is a complicated interweaving from the bottom to the
middle, to all the way up, back to the middle, and then somewhat up,
before going back to the bottom. What was a simple, top-down control
flow is now spaghetti code that jumps all over the place. Things become
slightly better if forward references are allowed, but the code flow
is still no longer a simple top-top bottom.
Blocks are useful in the same way meta-objects are useful; they allow
you to structure code in a way that makes sense (on the data-structure
level for meta-objects and on the statement level for blocks). They
both are relatively advanced features that can bring forth a huge
advantage in productivity and expressibility.
But the kicker for me is that if the language already has the concept of
first class functions internally, (as you say it does), then why must I
bind the symbol before I use it? Python doesn't require me to bind the
number 5 to a symbol five before I use it, nor does it require me to
bind the object fooBar() to a symbol theFooBar before I use it, so why
are functions treated differently here?
(For the Lispers, I have some similar questions about Common Lisp. The
biggest one is why ((lambda (x y) ...) 1 2) is treated specially instead
of extending the evaluator to consider the value after it considers the
SYMBOL-FUNCTION of the first element in a to-be-evaluated list.)
-- MJF
M Jared Finder <·····@hpalace.com> writes:
> (For the Lispers, I have some similar questions about Common Lisp.
> The biggest one is why ((lambda (x y) ...) 1 2) is treated specially
> instead of extending the evaluator to consider the value after it
> considers the SYMBOL-FUNCTION of the first element in a
> to-be-evaluated list.)
I have a similar question that is related. Given the form:
((foo x) 1 2)
Can the compiler always prove that (foo x) => (lambda (x y) ...)?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
> I have a similar question that is related. Given the form:
>
> ((foo x) 1 2)
>
> Can the compiler always prove that (foo x) => (lambda (x y) ...)?
>
If foo is a function, then the compiler could do something like ML-style
type inference to see that all variations in the function (ifs, conds,
...) return a lambda of two. If any compiler (or Lisp typechecker) does
this, I don't know.
Ulrich Hobelmann wrote:
> David Steuber wrote:
>
>> I have a similar question that is related. Given the form:
>>
>> ((foo x) 1 2)
>>
>> Can the compiler always prove that (foo x) => (lambda (x y) ...)?
>
> If foo is a function, then the compiler could do something like ML-style
> type inference to see that all variations in the function (ifs, conds,
> ...) return a lambda of two. If any compiler (or Lisp typechecker) does
> this, I don't know.
Wouldn't make too much sense. foo may not exist yet at compile time.
Pascal
David Steuber <·····@david-steuber.com> writes:
> M Jared Finder <·····@hpalace.com> writes:
>
> > (For the Lispers, I have some similar questions about Common Lisp.
> > The biggest one is why ((lambda (x y) ...) 1 2) is treated specially
> > instead of extending the evaluator to consider the value after it
> > considers the SYMBOL-FUNCTION of the first element in a
> > to-be-evaluated list.)
>
> I have a similar question that is related. Given the form:
>
> ((foo x) 1 2)
>
> Can the compiler always prove that (foo x) => (lambda (x y) ...)?
In Common-Lisp, the only kind of list that can appear as function in a
function call is a lambda-expression. That'd be: (funcall (foo x) 1 2)
I guess the type checker could indeed deduce that the result of (foo
x) should be a binary function or a variadic function.
But anyways, (foo x) may return anything at run-time, so it's more a
question for the run-time than for the compiler.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
David Steuber wrote:
> M Jared Finder <·····@hpalace.com> writes:
>
>>(For the Lispers, I have some similar questions about Common Lisp.
>>The biggest one is why ((lambda (x y) ...) 1 2) is treated specially
>>instead of extending the evaluator to consider the value after it
>>considers the SYMBOL-FUNCTION of the first element in a
>>to-be-evaluated list.)
>
> I have a similar question that is related. Given the form:
>
> ((foo x) 1 2)
>
> Can the compiler always prove that (foo x) => (lambda (x y) ...)?
These things could lead to too many ambiguities. For example:
- In ((foo x) 1 2), (foo x) could be a macro that expands to a symbol.
Should that symbol then be looked up in the function space or in the
value space?
- In (f x), f could be a symbol macro that expands to (foo ...). Would
you consider macroexpanding f? Would the semantics of that piece of code
then need to change as someone binds the symbol-value of 'f?
It seems to me that one cannot come up with a consistent approach here
(I might be wrong), and since you wouldn't gain any substantial
expressive power it's better to leave it undefined.
lambda expressions as the car of a form seem somewhat unnecessary to me.
Do they provide anything beyond what you could equally well get from
(funcall (lambda ...) ...)?
Pascal
From: M Jared Finder
Subject: Re: Python becoming less Lisp-like
Date:
Message-ID: <4239a52d_5@x-privat.org>
Pascal Costanza wrote:
> David Steuber wrote:
>
>> M Jared Finder <·····@hpalace.com> writes:
>>
>>> (For the Lispers, I have some similar questions about Common Lisp.
>>> The biggest one is why ((lambda (x y) ...) 1 2) is treated specially
>>> instead of extending the evaluator to consider the value after it
>>> considers the SYMBOL-FUNCTION of the first element in a
>>> to-be-evaluated list.)
>>
>>
>> I have a similar question that is related. Given the form:
>>
>> ((foo x) 1 2)
>>
>> Can the compiler always prove that (foo x) => (lambda (x y) ...)?
>
>
> These things could lead to too many ambiguities. For example:
Assuming this was to be implemented, I don't see any problem with
ambiguities, the process is very simple. If there is any problem with
the SYMBOL-FUNCTION of the car of a form, then you use the value
instead. Essentially, I am proposing replacing the part of the
evaluator that must say:
;; Evaluate a list form
(let ((func (car form))
(args (cdr form)))
(if (or (and (symbolp func) (fboundp func))
(and (listp func) (eq (car func) 'lambda)))
(apply #'func args)
(error 'error)))
with this one:
;; Evaluate a list form
(let ((func (car form))
(args (cdr form)))
(if (and (symbolp func) (fboundp func))
(apply #'func args)
(apply (eval func) args)))
You would never return to the function namespace once you leave it. I'd
expect this not to be used with variables as much as it would be used
with function calls that return functions.
> - In ((foo x) 1 2), (foo x) could be a macro that expands to a symbol.
> Should that symbol then be looked up in the function space or in the
> value space?
Since (foo x) is not a symbol, it would look it up in the value
namespace of whatever foo returns.
>
> - In (f x), f could be a symbol macro that expands to (foo ...). Would
> you consider macroexpanding f? Would the semantics of that piece of code
> then need to change as someone binds the symbol-value of 'f?
As long as f is not a global function, I'd macroexpand f and then use
thee value of the result, not the SYMBOL-FUNCTION. Once you leave the
function namespace, there is no return.
> It seems to me that one cannot come up with a consistent approach here
> (I might be wrong), and since you wouldn't gain any substantial
> expressive power it's better to leave it undefined.
>
> lambda expressions as the car of a form seem somewhat unnecessary to me.
> Do they provide anything beyond what you could equally well get from
> (funcall (lambda ...) ...)?
I agree that there is minimal additional expresive power; everything
that could be done with this new syntax could be done by just putting in
a funcall as the car of the form. That's why I mentioned it only
offhand. It's just that the special treatment of ((lambda ...) ...)
forms irks me. Why is the special treatment there, and why only for
lambda forms? Does anyone make use of it? Would anyone kick and scream
if this special case was removed from the language tomorrow? Will I
ever stop asking silly questions?
Inquiring minds want to know!
-- MJF
M Jared Finder wrote:
> I agree that there is minimal additional expresive power; everything
> that could be done with this new syntax could be done by just putting in
> a funcall as the car of the form. That's why I mentioned it only
> offhand. It's just that the special treatment of ((lambda ...) ...)
> forms irks me. Why is the special treatment there, and why only for
> lambda forms? Does anyone make use of it?
I think it's mainly a heritage from the past. I vaguely recall that it
can be handy for macros for generating code, but I don't remember any
details.
Pascal
From: M Jared Finder
Subject: Re: Python becoming less Lisp-like
Date:
Message-ID: <423c87e2$1_2@x-privat.org>
Pascal Costanza wrote:
> M Jared Finder wrote:
>
>> I agree that there is minimal additional expresive power; everything
>> that could be done with this new syntax could be done by just putting
>> in a funcall as the car of the form. That's why I mentioned it only
>> offhand. It's just that the special treatment of ((lambda ...) ...)
>> forms irks me. Why is the special treatment there, and why only for
>> lambda forms? Does anyone make use of it?
>
>
> I think it's mainly a heritage from the past. I vaguely recall that it
> can be handy for macros for generating code, but I don't remember any
> details.
That's what I suspected. Will the warts of having a 40+ year old
language never be cleaned?
-- MJF
M Jared Finder wrote:
> Pascal Costanza wrote:
>
>> M Jared Finder wrote:
>>
>>> I agree that there is minimal additional expresive power; everything
>>> that could be done with this new syntax could be done by just putting
>>> in a funcall as the car of the form. That's why I mentioned it only
>>> offhand. It's just that the special treatment of ((lambda ...) ...)
>>> forms irks me. Why is the special treatment there, and why only for
>>> lambda forms? Does anyone make use of it?
>>
>> I think it's mainly a heritage from the past. I vaguely recall that it
>> can be handy for macros for generating code, but I don't remember any
>> details.
>
> That's what I suspected. Will the warts of having a 40+ year old
> language never be cleaned?
No, and that can be a good thing.
Pascal
Valentino Volonghi aka Dialtone wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>>In order to make this work you had to move the then and else parts
>>outside of the if statement. I don't want that.
>
> This difference (if it is a big one) doesn't change anything from my
> point of view.
That's the only difference that matters in programming language design:
What is elegant to express and what is not, including if and how to
contrain the expressive power of a language in order to achieve a
certain elegance. Python already has an if construct, so this specific
example doesn't buy you much. But you are disallowing programmers to
build their own language constructs that are similarly concise, and
instead you ask them to be more verbose. You like it, I don't, but
that's not the point of the discusssion.
What the point of the discussion is is that I still don't understand why
Python doesn't allow programmers to build their own language constructs
but at the same time allows them to build their own object models. The
increased expressivity of metaclasses is not a good answer here because
increased expressivity doesn't seem to be a worthwhile goal in the case
of anonymous closures. Is there a rationale or is this just an accident?
If there is a rationale, then what is it?
I am really interested in this.
> To me the Pico syntax is completely unreadable because I'm not used to
> that kind of syntax whereas python syntax is terse and immediately
> obvious.
Yet it is very successfully used in practice to get non-programmers to
understand programming in an extremely short amount of time. See
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/submissions/DeMeuterDHondtDedecker.pdf
Also check their website at http://pico.vub.ac.be - "Pico in Brief" and
"A Basic Tutorial" are very worthwhile.
The readability of Pico is not a matter of opinion, it is proven in
practice. The fact that it has a concept of closures that combines both
the advantages of anonymity and required names should be interesting to
people who take beginners' issues seriously.
Pascal
Pascal Costanza wrote:
>What the point of the discussion is is that I still don't understand
why
>Python doesn't allow programmers to build their own language
constructs
>but at the same time allows them to build their own object models. The
>increased expressivity of metaclasses is not a good answer here
because
>increased expressivity doesn't seem to be a worthwhile goal in the
case
>of anonymous closures. Is there a rationale or is this just an
accident?
>If there is a rationale, then what is it?
There are various answers on "why metaclasses are there".
The pragmatic one: Metaclasses are there because the Zope guys needed
them.
They are pretty useful for framework builders; Zope 2.X use pretty ugly
C-coded extensions classes that can be replaced by pure Python
meta-enhanced
classes.
The cynic one: Metaclass are there because Guido liked them. This a
valid
answer as any other.
Also, metaclasses where already in Python (browse for the essay
"metaclasses in
Python 1.5") and it was technically easy to give them a better API, so
it was done.
Furthermore, metaclasses are not likely to be touched by inexpert
programmers,
and it is unlikely an inexpert programmer will ever read metaclass
code.
He will just use the framework. So, they are not "dangerous".
OTOH (for what concern "why no anonymous closures") in current Python
it is very likely for an inexpert programmer to read code with lambdas
and to get confused, so they are "dangerous" (NOTE: in this context I
am using "dangerous" as a synonimous for "difficult to read for its
typical readers").
Personally I find
def adder(n):
return lambda x: x+n
easier to read than the equivalent with a named function:
def adder(n):
def addn(x): return x+n
return addn
however I discovered giving a Python course a couple of months
ago that all my students understood the second form better.
So I guess Guido is right on the readability point.
The idea is "good programmers are good, there is no point in making
things simpler for them, lets do things simple for the bad
programmers".
This is exactly the opposite philosophy of Lisp.
I HTH,
Michele Simionato
·················@gmail.com wrote:
> There are various answers on "why metaclasses are there".
Thanks a lot for your response! It makes some points clearer to me.
Pascal
P.S.: The next thread could be: If you allow metaclasses, then why no
macros? But let's not go there... ;-)
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
> Let me repeat myself:
... to the point of tedium.
> lambda is completely useless in python.
... in _your_ opinion.
> defining a function for doing the very same thing that you do with a
> lambda takes you only one more line.
And _I_ along with many other programmers greatly appreciate not
having to write that extra line.
Particularly when you take into account that that line
- thereby _doubles_ the number of lines I have to write[*]
- forces you to think of a name for the function
- pollutes the namespace with said name
- breaks the flow of reading and writing the code.
[*] Actually, more than doubles: the original lambda was a _fraction_
of a line. Besides, in Python 3000, that line will take up at
least 2 lines.
If the ability to create an unnamed object inline is useless, then you
should espouse the same opinion about anonymous lists, tuples,
dictionaries, strings etc. Try writing some Python code without any of
those, and see how far you get without going nuts. Then try it without
anonymous numbers.
> You are probably missing the fact that lambda is useless in python
You are missing the fact that it isn't. Just because _you_ don't care
for it, doesn't mean your opinion is objectively true.
> (I repeat myself again)
Yes, please don't.
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
> What's the loss received from removing lambda? Nothing.
> But you seem to give lambdas more 'power' than they deserve, and this
> probably will eventually be your python ignorance.
> Python is easy to use. But it's made for 'adults who know what they are
> doing',
I believe this is just an excellent place to quote Kent M. Pitman. He
generally argues that one should not denigrate somebody on the basis
that one does not see the value that the other sees in something.
Some people see value in lambda in Python. If you don't, there not
more value in your opinion than in your opponents. Just accept it as is.
KMP's lesson is: the ignorance is more likely to be on the side of the
one who does not see.
Regards
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle <······@users.sourceforge.net> writes:
> ························@gmail.com (Valentino Volonghi aka Dialtone) writes:
> > What's the loss received from removing lambda? Nothing.
>
> > But you seem to give lambdas more 'power' than they deserve, and this
> > probably will eventually be your python ignorance.
>
> > Python is easy to use. But it's made for 'adults who know what they are
> > doing',
>
> I believe this is just an excellent place to quote Kent M. Pitman. He
> generally argues that one should not denigrate somebody on the basis
> that one does not see the value that the other sees in something.
>
> Some people see value in lambda in Python. If you don't, there not
> more value in your opinion than in your opponents. Just accept it as is.
>
> KMP's lesson is: the ignorance is more likely to be on the side of the
> one who does not see.
Anyway, perhaps it's a good thing that Python deletes lambda.
Then the programmers who want lambda will come to lisp civilization
instead of staying in the barbarous lands of Python. :-)
We should move to remove cpp macros in C and C++...
--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.
On Fri, 18 Mar 2005 20:33:33 +0100, Pascal Bourguignon wrote:
> Anyway, perhaps it's a good thing that Python deletes lambda.
>
> Then the programmers who want lambda will come to lisp civilization
> instead of staying in the barbarous lands of Python. :-)
>
> We should move to remove cpp macros in C and C++...
Well, the barbarous people of the C would probably travel not much
further than to Java then...
--
Christopher
Pascal Costanza <··@p-cos.net> writes:
> So to summarize: What I find weird is that in some parts of the
> language, beginners' needs are addressed and more advanced stuff is
> completely elided whereas in other parts, advanced users' needs are
> addressed and beginners are left behind. This looks like a very
> unbalanced design to me.
Sure. But remember that a Benevolent Dictator For Life gets the final
say on how Python evolves. He is a human, and is subject to human
whims, opinions, mood changes etc. Don't expect humans to be perfectly
balanced and completely rational.
> I know programming languages that are either primarily designed as
> teaching languages, or else as advanced programming languages for
> either academic, pragmatic or domain-specific purposes. What you say
> gives me the impression that Python does a little bit of
> everything. What's the rationale behind this?
It puts a powerful and relatively pleasant to use language within
reach of people who might otherwise settle, or be saddled with,
something inferior.
Jacek Generowicz wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> So to summarize: What I find weird is that in some parts of the
>> language, beginners' needs are addressed and more advanced stuff is
>> completely elided whereas in other parts, advanced users' needs are
>> addressed and beginners are left behind. This looks like a very
>> unbalanced design to me.
>
> Sure. But remember that a Benevolent Dictator For Life gets the final
> say on how Python evolves. He is a human, and is subject to human
> whims, opinions, mood changes etc. Don't expect humans to be perfectly
> balanced and completely rational.
Nor are committees. Frankly I'd sooner expect consistent logic out of an
individual designer than a committee. The problem is, you have to
acknowledge that it's *their* logic, not your own logic, and that your own
logic isn't the unblemished ideal Truth. If you have a capacity for
wrapping your head around other people's logic, you'll find it easier to
deal with other people's language designs.
> It puts a powerful and relatively pleasant to use language within
> reach of people who might otherwise settle, or be saddled with,
> something inferior.
Indeed, and that's a notable achievement. Seemingly absent from most other
languages. Lua has probably nailed ease-of-use for lightweight scripting,
though. Python has broader ambitions to be a Java-like systems language.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
························@gmail.com (Valentino Volonghi aka Dialtone) writes:
> But since python relies on metaclasses for its object system they
> can't go away.
You are aware that Python didn't have metaclasses for approximately
80% of the time it has existed (while it's had an object system from
the start), aren't you ?
Jacek Generowicz <················@cern.ch> wrote:
> You are aware that Python didn't have metaclasses for approximately
> 80% of the time it has existed (while it's had an object system from
> the start), aren't you ?
Are you aware of all the warts (that you also complain about) that the
old object model had? If the answer is yes please think before posting
again arguing that your listener is an ignorant idiot that doesn't know
what he talks about. If the answer is no you simply don't know python
enough to comment on anything (and this would explain everything).
You are too arrogant to deserve any more answers to any of your posts.
I'll just stop partecipating to this thread since I've already explained
my point, you are free to disagree or not. That doesn't change anything.
I'm not interested in the language you use or you like best.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi wrote:
> Are you aware of all the warts (that you also complain about) that
the
> old object model had? If the answer is yes please think before
posting
> again arguing that your listener is an ignorant idiot that doesn't
know
> what he talks about. If the answer is no you simply don't know python
> enough to comment on anything (and this would explain everything).
> You are too arrogant to deserve any more answers to any of your
posts.
Be careful Valentino, since Jacek could say the same of you ;)
Jacek, about your point "instead of fixing lambda they make special
cases"
(or something like that) do you have an idea of how to fix lambda?
I think people have tried for 12 years and finally they give up.
The problem is that the dicotomy statements vs. expressions
prevents that. IMO statements are bad, generally speaking.
But they have the advantage that they force undisciplined
programmers to write readable code, and Python is all
about readability.
Personally, I do not like lambda very much, but I aknowledge that
we do not have a viable replacement yet. I guess Guido will come
out with some idea in Python 3000 (code blocks may be?)
We will see, for the moment I am trying to compensate as
I can with decorators and descriptors.
Michele Simionato
·················@gmail.com writes:
> Valentino Volonghi wrote:
> > Are you aware of all the warts (that you also complain about) that
> > the old object model had? If the answer is yes please think before
> > posting again arguing that your listener is an ignorant idiot that
> > doesn't know what he talks about. If the answer is no you simply
> > don't know python enough to comment on anything (and this would
> > explain everything). You are too arrogant to deserve any more
> > answers to any of your posts.
>
> Be careful Valentino, since Jacek could say the same of you ;)
I was hoping that he would deduce this point by reading between the
lines of my various followups, but perhaps I was being too subtle.
> Jacek, about your point "instead of fixing lambda they make special
> cases" (or something like that) do you have an idea of how to fix
> lambda?
Heh! (Or maybe even "Touche!")
> I think people have tried for 12 years and finally they give up.
I admit I have not studied the history of attempts to fix it, so my
perception of this history is necessarily rather superficial. But I
think I've seen a lot of whining about lambda and little evidence of
attempts to fix it. Of course, the former are more likely to appear in
c.l.py, while the latter are more likely to be discussed in
python-dev. Overall I have probably followed c.l.py more closely than
python-dev, so it's probably just my skewed perception.
> The problem is that the dicotomy statements vs. expressions prevents
> that.
So, Python 3000 would be an excellent opportunity to get rid of a
fundamental wart in Python :-)
> IMO statements are bad, generally speaking. But they have the
> advantage that they force undisciplined programmers to write
> readable code, and Python is all about readability.
Readability is subjective.
use_it_here(lambda x:x+1)
if far more readeble to ME than
def add_1(x):
return x+2
use_it_here(add_1)
(Even after you remove the (deliberate for didactic purposes, in this
case, but all-too-often inadvertent in real code) mistake). But mine
is probably a minority opinion on c.l.py.
> Personally, I do not like lambda very much, but I aknowledge that
> we do not have a viable replacement yet. I guess Guido will come
> out with some idea in Python 3000 (code blocks may be?)
Oh, I don't care what it is called, or how it is implemented. Just
give me a means of creating unnamed functions (closures) inline, and
lambda can go. I just wish people would stop blaming anonymous
functions in general, for what they dislike about Pyton's lambda in
particular.
> We will see, for the moment I am trying to compensate as I can with
> decorators and descriptors.
But decorators and descriptors are orthogenal to creation of inline,
anonymous functions! This is what my point is about: orthogonality of
abstractions. I'm a great fan of good (simple, powerful, general)
abstractions, and of orthogonal features that play well together and
allow me to combine simply and easily to implement all sorts of
functionality. Here we seem to be moving away from generality and
orthogonality: "If you want to do this, then use that, but if you want
to do this, then use the other (say 15 times) ... then we can get rid
of this ONE single thing."
If the reason for killing lambda is that it can't be implemented
decently in Python, then I wish they'd come out and say it. But
instead we get pathetic "justifications" along the lines of "We don't
need it because this use case is covered by this specific feature,
while that use case covered by that special feature, and if you come
up with another use case, I can probably invent another special
feature to cater for it."
Overall, this complicates the language, and makes it much more
difficult to read and learn. In isolation, it might be tempting to
prefer listcomps to map/lambda here, prefer decorators there, zip
somewhere else, itertools over there, introduce any/all thither, and
so on and so forth ... but do notice that we now have 15 features
which all do what a couple of simple, general, orthogonal ones are
able to do already. How does this stack up agains the "There should be
one way to do it" philosophy?
Jacek:
> I admit I have not studied the history of attempts to fix it, so my
> perception of this history is necessarily rather superficial. But I
> think I've seen a lot of whining about lambda and little evidence of
> attempts to fix it. Of course, the former are more likely to appear
in
> c.l.py, while the latter are more likely to be discussed in
> python-dev. Overall I have probably followed c.l.py more closely than
> python-dev, so it's probably just my skewed perception.
There was a long and deep thread on c.l.py years ago explaining all
the gory details of why having a full powered lambda is impossible,
given
the inner working of today Python compiler. Unfortunately, I have not
keep
track of that thread :-(
> > The problem is that the dicotomy statements vs. expressions
prevents
> > that.
>
> So, Python 3000 would be an excellent opportunity to get rid of a
> fundamental wart in Python :-)
You dream! ;)
> Readability is subjective.
>
> use_it_here(lambda x:x+1)
>
> if far more readeble to ME than
>
> def add_1(x):
> return x+2
>
> use_it_here(add_1)
Me too, but as I explained in another post in this same thread I have
discovered myself that newbies understand much better the
second form, even after I went in detail explaining to them how lambda
works ;)
> Oh, I don't care what it is called, or how it is implemented. Just
> give me a means of creating unnamed functions (closures) inline, and
> lambda can go. I just wish people would stop blaming anonymous
> functions in general, for what they dislike about Pyton's lambda in
> particular.
Well, not everybody is blaming anonymous functions in general ;)
> > We will see, for the moment I am trying to compensate as I can with
> > decorators and descriptors.
>
> But decorators and descriptors are orthogenal to creation of inline,
> anonymous functions!
Yep, this a workaround.
> This is what my point is about: orthogonality of
> abstractions. I'm a great fan of good (simple, powerful, general)
> abstractions, and of orthogonal features that play well together and
> allow me to combine simply and easily to implement all sorts of
> functionality. Here we seem to be moving away from generality and
> orthogonality: "If you want to do this, then use that, but if you
want
> to do this, then use the other (say 15 times) ... then we can get rid
> of this ONE single thing."
>
> If the reason for killing lambda is that it can't be implemented
> decently in Python, then I wish they'd come out and say it. But
> instead we get pathetic "justifications" along the lines of "We don't
> need it because this use case is covered by this specific feature,
> while that use case covered by that special feature, and if you come
> up with another use case, I can probably invent another special
> feature to cater for it."
Well, at least Alex Martelli is on the record for saying many times
"I am against lambda because it is cripped lambda; if I had a real
lambda I would keep it". OTOH, Guido never said that. If I can venture
in mind reading, maybe Guido thinks that lambdas are not obvious, so
he tries to stop developers to using them. For this reason he does
not give us a working
[lambda :i for i in range(10)] # yes always our old friend! ;)
The working replacement
[lambda i=i: i for i in range(10)]
is to ugly to be contempled, so he practically forces us to use
class Func(object):
def __init__(self, i):
self.i = i
def __call__(self):
return self.i
[Func(i) for in in range(10)]
which he probably things is more obvious. This is certainly more
verbose than
def func(i):
def f(): return i
return i
but I must admit it has at least an advantage: both __init__ and
__call__ are easily introspectable, whereas the inner function in
the closure is not that accessible (yes, I think debuggability is
a mighty important concern).
I think Guido *on purpose* remove certain functionalities since
he wants other idioms to be used instead (for instance there is
no "case" statement, since you should dispatch on a dictionary
or on a class). It is possible that he sees lambdas as too low level
construct to be replaced by an higher level construct in the same
sense as "case statement vs. dispatch pattern" (here I am
just speculating).
> Overall, this complicates the language, and makes it much more
> difficult to read and learn. In isolation, it might be tempting to
> prefer listcomps to map/lambda here, prefer decorators there, zip
> somewhere else, itertools over there, introduce any/all thither, and
> so on and so forth ... but do notice that we now have 15 features
> which all do what a couple of simple, general, orthogonal ones are
> able to do already. How does this stack up agains the "There should
be
> one way to do it" philosophy?
>
There should be one *obvious* way. The obvious way is the one which is
prebuilt in the library and requires you the less thinking (if it
requires
you a lot of thinking then may be you are not dutch ;). So I don't
see an inconsistency with Python philosophy here.
It is just that we are not all dutch!
More seriously, I think we are spending a disproportiate amount of
effort discussing a not-so-critical point. I can leave with or
without lambda, and there are still many other things that work
well, so lets go on!
Michele Simionato
·················@gmail.com writes:
> > I can leave with or without lambda
>
> Freudian? Obviously I means "I can live with or without lambda" ;)
Perhaps, but in both cases, either he'll live with Lambda, or he'll leave it.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
·················@gmail.com writes:
> I think Guido *on purpose* remove certain functionalities since he
> wants other idioms to be used instead (for instance there is no
> "case" statement, since you should dispatch on a dictionary
And this approach is extremely weak, in the absence of fully-fledged
anonymous functions (or code blocks).
> More seriously, I think we are spending a disproportiate amount of
> effort discussing a not-so-critical point. I can leave with or
> without lambda, and there are still many other things that work
> well, so lets go on!
Yes, let's move on.
Valentino Volonghi aka Dialtone wrote:
> I'll just stop partecipating to this thread since I've already explained
> my point, you are free to disagree or not. That doesn't change anything.
> I'm not interested in the language you use or you like best.
Note that you're in the wrong newsgroup then.
Pascal
Spake Valentino Volonghi aka Dialtone:
> I agree, [lambda] is shorter, but it's _NOT_ anything that you can't live
> without, and most beginners just don't understand lambda.
I wonder if that is a valid reason to remove functionality from a system.
Personally, I'd like to know I have every conceivable tool in my shed,
even if I normally only need two or three.
--
Trent Buck, Student Errant
The only thing I'd use on guinea-fowl is a shredder. Same with peacocks.
The sound of peacocks being shredded can't possibly be any worse than
the sound of peacocks not being shredded. -- Tanuki
Trent Buck <·········@tznvy.pbz> wrote:
> I wonder if that is a valid reason to remove functionality from a system.
>
> Personally, I'd like to know I have every conceivable tool in my shed,
> even if I normally only need two or three.
I already explained that the python lambda doesn't actually bring
anything to the language besides the possibility to declare inline
functions. This hardly has any advantage over the named approach but
confusing newbies.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Valentino Volonghi aka Dialtone wrote:
> Trent Buck <·········@tznvy.pbz> wrote:
>
>> I wonder if that is a valid reason to remove functionality from a
>> system.
>>
>> Personally, I'd like to know I have every conceivable tool in my
>> shed, even if I normally only need two or three.
>
> I already explained that the python lambda doesn't actually bring
> anything to the language besides the possibility to declare inline
> functions. This hardly has any advantage over the named approach but
> confusing newbies.
[Directed mainly to Trent.]
You might be interested to measure whether you're more of a Perceiver or a
Judger in the Myers-Briggs Type Indicators (MBTI). Perceivers resist
closure, want to keep all the options open. Judgers want to close and
finalize them. Take a test at http://www.humanmetrics.com
Have you ever looked at the legal code for your city? Ever tried to figure
out city vs. county vs. state law, and civil vs. criminal vs. infractions?
If you have, you know that "laws are forever." One would dearly like
someone to reach in sometime and just clean house. Remove all the spurious,
redundant, irrelevant, conflicting laws and forge a document that mere
citizens can understand when they're trying to fight a traffic ticket. But
the power interests surrounding traffic tickets don't want that to happen.
It would ruin the $$$$$$ of their cult of bureaucracy.
Every once in awhile I've gotten to vote on a local measure that would
indeed "clean house" in the municipal code. Some whiner always says what
horrible damage it's going to do to remove this-and-that. Whenever that
kind of whining starts, I immediately know to vote YES to remove. Last
time, believe it or not, we voted on the words "he" vs. "he or she!" and
similarly weighty issues. Of course they tucked in something that really
was important after 17 pages of this drivel, so that people would vote in
apathy on it.
BDFL does exactly the right thing to remove a wart that has almost no value
in Python. I wonder at people who say Python is going the way of C++,
because BDFL is clearly a hedge trimmer. He's pretty good at that sort of
thing. It's his ineptitude as a marketer that I take issue with. For
instance, he believes that Python currently has a good logo. I think the
man should be chained to the gates of an art museum and left to rot.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> It's his ineptitude as a marketer that I take issue with. For
> instance, he believes that Python currently has a good logo. I think the
> man should be chained to the gates of an art museum and left to rot.
I agree. http://python.org/pics/pythonHi.gif
Even the favicon.ico is better!
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
Pascal Costanza <··@p-cos.net> writes:
> Valentino Volonghi aka Dialtone wrote:
>
> > Also list comprehensions are almost always faster
Codswallop ! [see below]
> > and more flexible than any combination of filter and map
Balderdash ! [e.g. map(fn, seq1, seq2, seq3) ]
> > because of particular bytecode optimizations in list
> > comprehensions.
I've been hearing this ever since list comprehensions were intoduced,
but the evidence (ie actually timing the stuff) always refutes
it. Admittedly, I got bored of the whole issue, and probably haven't
checked in Python 2.4. Let's see ...
python2.4 -m timeit -s "def foo(n): return n" -s "seq = range(10)" "map(foo, seq)"
100000 loops, best of 3: 6.73 usec per loop
python2.4 -m timeit -s "def foo(n): return n" -s "seq = range(10)" "[foo(x) for x in seq]"
100000 loops, best of 3: 6.98 usec per loop
(OK, so listcomps are catching up with map, but they haven't got there
yet.)
Typically, the claims that listcomps are more efficient than map are
based on things like
[a.b for a in sequence]
being faster than
map(lambda a: a.b, sequence)
because of the extra pure-Python function call overhead, introduced by
the lambda:
python2.4 -m timeit -s "seq = [dir]*10" "map(lambda x:x.__name__, seq)"
100000 loops, best of 3: 10.2 usec per loop
python2.4 -m timeit -s "seq = [dir]*10" "[x.__name__ for x in seq]"
100000 loops, best of 3: 5.64 usec per loop
Of course, this proves nothing about map: it only proves that the
programmer is unable to chose the most appropriate solution to the
problem at hand.
> Does this mean that the Python language design is driven by their
> implementors' lack of ability to implement it efficiently?
No, but I think that it is driven by the desire not to give the
programmer any choice: if there is no choice, the you can't make the
wrong choice. Pretty daft IMO, but maybe appropriate for Python's
intended audience.
I also think that it is influenced by the desire to cater for the kind
of programmer who might say
Lambda is scary because I never studied Greek. Please make it go
away or I will cry. No, I won't listen to your explanation of how
stunningly simple it actually is, because I'd rather throw my toys
out of the pram. And if a scary word such as 'lambda' is somehow
related to anonymous functions, then anonymous functions must be
evil themselves. Please make sure that I never have to see one.
Or somesuch.