If Scheme is so good why MIT drops it?

How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

It's all part of a Dutch conspiracy to take over the world! :-)

Elena

2009-07-19 18:22:30 UTC

Post by fft1976
How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

To be mainstream a language has to fit in most programmers' minds.

Marek Kubica

2009-07-20 00:54:13 UTC

On Sun, 19 Jul 2009 11:22:30 -0700 (PDT)

Post by Elena

Post by fft1976
How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

To be mainstream a language has to fit in most programmers' minds.

Sometimes I wonder whether Python is not too complex for "most
programmers", since "most programmers" use Java, which is heavily
mainstream. Interesting whether it is in spite of the ridiculous
limitations or because of these. Probably a mix of both.

regards,
Marek

Frank Buss

2009-07-19 18:31:36 UTC

Post by fft1976
How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

Python is not that bad. Unlike Lisp, there is much less undefined behavior,
there is one free unique implementation on the 3 major platforms Linux,
Windows and MacOS X, which is stable, support multithreading and has a
default GUI library binding, which is difficult to find for Lisp (e.g. I
don't know of a free modern and stable Lisp implemenation with
mulithreading support for Windows, with a licence with which you can use it
in closed source commercial programs, like you can do with Python). Many
problems in the Lispbuilder mailing list are related to problems due to
different operating systems and Lisp implementations.

But maybe the most important point: The syntax looks simple compared to
Common Lisp (much less parentheses) and if you program in Python, it feels
easier for programmer newbies. As Sussman says: "undergraduate?s initial
experiences maximally productive". And this holds even for more experienced
programmers. If you know already a bit of C, it is easy to use Python, but
without the ability to do silly errors like writing out of array bounds (of
course, you can do this in Lisp, too, if you remember to set the safe mode
and if you use the right implementation). GC helps, too, to make the
programming task easier than in C. Some more arguments, e.g. 5 times less
program size than Java or C and more productive programmers:

http://www.artima.com/intv/speedP.html

(of course, an interview with Van Rossum might be a bit biased :-)

--
Frank Buss, fb at frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Roy Smith

2009-07-19 19:09:28 UTC

In article <1cethsrrw8h6k$.9ty7j7u7zovn.dlg at 40tude.net>,

Post by Frank Buss
there is one free unique implementation on the 3 major platforms Linux,
Windows and MacOS X

Most people would still consider Solaris to be a "major platform".

Terry Reedy

2009-07-19 20:01:26 UTC

Post by Roy Smith
In article <1cethsrrw8h6k$.9ty7j7u7zovn.dlg at 40tude.net>,

Post by Frank Buss
there is one free unique implementation on the 3 major platforms Linux,
Windows and MacOS X

Most people would still consider Solaris to be a "major platform".

?? I do not, but I have no idea what comes in 4th after the other three
by whatever metric.

Emile van Sebille

2009-07-19 21:16:38 UTC

On 7/19/2009 1:01 PM Terry Reedy said...

Post by Roy Smith
In article <1cethsrrw8h6k$.9ty7j7u7zovn.dlg at 40tude.net>,

Post by Frank Buss
there is one free unique implementation on the 3 major platforms Linux,
Windows and MacOS X

Most people would still consider Solaris to be a "major platform".

?? I do not, but I have no idea what comes in 4th after the other three
by whatever metric.

one metric calls fourth as the iPhone OS...

http://marketshare.hitslink.com/report.aspx?qprid=8&qptimeframe=Y&qpsp=2009&qpmr=100&qpdt=1&qpct=0&qpob=UV%20DESC

Emile

unknown

2009-07-19 23:35:01 UTC

Post by Emile van Sebille

Post by Roy Smith
Most people would still consider Solaris to be a "major platform".

?? I do not, but I have no idea what comes in 4th after the other
three by whatever metric.

one metric calls fourth as the iPhone OS...
http://marketshare.hitslink.com/report.aspx?qprid=8...

That metric is clearly wrong. The #1 platform OS platform in terms of
number of units shipped is Javacard, which is in the SIM cards of
billions of GSM phones.

Emile van Sebille

2009-07-21 22:37:40 UTC

On 7/19/2009 4:35 PM Paul Rubin said...

Post by Emile van Sebille

Post by Roy Smith
Most people would still consider Solaris to be a "major platform".

?? I do not, but I have no idea what comes in 4th after the other
three by whatever metric.

one metric calls fourth as the iPhone OS...
http://marketshare.hitslink.com/report.aspx?qprid=8...

That metric is clearly wrong. The #1 platform OS platform in terms of
number of units shipped is Javacard, which is in the SIM cards of
billions of GSM phones.

Yes -- that location includes disclaimers on how they reach their
conclusions.

Marek Kubica

2009-07-20 00:51:49 UTC

On Sun, 19 Jul 2009 15:09:28 -0400

Post by Roy Smith
In article <1cethsrrw8h6k$.9ty7j7u7zovn.dlg at 40tude.net>,

Post by Frank Buss
there is one free unique implementation on the 3 major platforms
Linux, Windows and MacOS X

Most people would still consider Solaris to be a "major platform".

Depends on who you ask. On the desktop it doesn't matter at all
(fortunately, since everytime I work on Solaris I'm entering a world of
pain which is just slowly getting better with OpenSolaris), on the
server it (and other propietary Unices) is losing ground compared to
the free Unices.

But ok, let's say 3 major platforms: Unix, Windows and Mac OS X. Mac OS
X is formally a Unix but everything with GUI is non-Unix'y so it can be
considered a separate platform.

regards,
Marek

Roy Smith

2009-07-20 02:07:34 UTC

In article <20090720025149.326f0cfc at halmanfloyd.lan.local>,

Post by Marek Kubica

Post by Roy Smith

Post by Frank Buss
there is one free unique implementation on the 3 major platforms
Linux, Windows and MacOS X

Most people would still consider Solaris to be a "major platform".

Clearly, there's not much (if any) Solaris on the desktop. But it's sure
alive and kicking in the server world.

One of the things I like about Python is not just how portable is it is,
but how easy it is to build and deploy. We build our product on Windows, N
different Linux distros, Solaris, HPUX, AIX, and OSX. I've built Python
for all of those platforms. Then, I checked the install areas into
Perforce. Deploying is as simple as checking out the right sandbox.

We've gone through the same exercise for Perl. That was a lot more
painful.

vippstar

2009-07-19 22:54:17 UTC

Post by Frank Buss

Post by fft1976
How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

<snip>

Post by Frank Buss
But maybe the most important point: The syntax looks simple compared to
Common Lisp (much less parentheses)

hahaha.

Bob Martin

2009-07-20 06:12:45 UTC

Post by Roy Smith
In article <1cethsrrw8h6k$.9ty7j7u7zovn.dlg at 40tude.net>,

Post by Frank Buss
there is one free unique implementation on the 3 major platforms Linux,
Windows and MacOS X

Most people would still consider Solaris to be a "major platform".

?? I do not, but I have no idea what comes in 4th after the other three
by whatever metric.

I think the OP means "major PC operating systems". Those with a wider
knowledge of the computer world would consider IBM's mainframe operating
systems to be deserving of the description "major".

Frank Buss

2009-07-20 06:28:58 UTC

Post by Bob Martin
I think the OP means "major PC operating systems". Those with a wider
knowledge of the computer world would consider IBM's mainframe operating
systems to be deserving of the description "major".

Maybe you are right, if you mean big machines. I know mainframes a bit and
there are interesting concepts, like hot-swapping of CPU modules and
mainframes are very reliable. But expensive, too. I know at least one
client, who wants to change it to some cheap Linux boxes, like Google
demonstrates it. If you take care (e.g. Xen virtualization for easier
computer changing and RAID harddisks, if a downtime of some hours might be
ok), it doesn't matter if one PC goes out of order.

But even on IBM mainframes you can install Linux or other Unix systems in
parallel to the usual operating systems for this machines, so except for
special cases, like embedded systems, the most installed and used operating
systems might be Unix-like systems and Windows. But looks like Python even
runs on more native operating systems for mainframes.

--
Frank Buss, fb at frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Bob Martin

2009-07-20 06:40:21 UTC

Post by Frank Buss

Maybe you are right, if you mean big machines. I know mainframes a bit and
there are interesting concepts, like hot-swapping of CPU modules and
mainframes are very reliable. But expensive, too. I know at least one
client, who wants to change it to some cheap Linux boxes, like Google
demonstrates it. If you take care (e.g. Xen virtualization for easier
computer changing and RAID harddisks, if a downtime of some hours might be
ok), it doesn't matter if one PC goes out of order.
But even on IBM mainframes you can install Linux or other Unix systems in
parallel to the usual operating systems for this machines, so except for
special cases, like embedded systems, the most installed and used operating
systems might be Unix-like systems and Windows. But looks like Python even
runs on more native operating systems for mainframes.

Yes, a "platform" is really the combination of hardware architecture and operating system,
so Linux on Intel and Linux on 390 are different platforms.

Scott Burson

2009-07-20 22:07:58 UTC

I don't know of a free modern and stable Lisp implementation with
mulithreading support for Windows, with a licence with which you can use it
in closed source commercial programs

Have you looked at ECL?

http://ecls.sourceforge.net/

I've used it only a little, so I can't vouch for its stability, but it
fits the threading and license requirements (well, some corporate
lawyers have trouble with the LGPL, but I think it's usable).

-- Scott

Frank Buss

2009-07-21 04:57:39 UTC

Post by Scott Burson
Have you looked at ECL?
http://ecls.sourceforge.net/
I've used it only a little, so I can't vouch for its stability, but it
fits the threading and license requirements (well, some corporate
lawyers have trouble with the LGPL, but I think it's usable).

I didn't tried it myself, but looks like it is not very stable:

http://www.mail-archive.com/application-builder at lispniks.com/msg01069.html

--
Frank Buss, fb at frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Rainer Joswig

2009-07-21 07:00:16 UTC

http://www.mail-archive.com/application-buil... at lispniks.com/msg01069.html

I'm not sure if it is fair to post a reference to a single
post by someone without context and without having used ECL.
If there are stability problems, people can report to the
ECL mailing list. The maintainers are very active.

Frank, I have seen you constructive and posting code a year ago.
What happened? Several messages of yours I've seen here are now
going in the direction of been mostly useless. I thought
you could do better.

If you are no longer interested in Lisp with no first hand usage,
why not switch to comp.lang.misc or some other random place?

Frank Buss

2009-07-21 16:44:23 UTC

Post by Rainer Joswig
I'm not sure if it is fair to post a reference to a single
post by someone without context and without having used ECL.
If there are stability problems, people can report to the
ECL mailing list. The maintainers are very active.

This was just one example. Another one:

http://www.mail-archive.com/application-builder at lispniks.com/msg01024.html

Luke and Elliott are no beginners, so it is at least difficult to use ECL:
On Windows it doesn't work with MinGW and on MacOS X there was at least one
case were it freezed. But as I have written, I didn't tried it myself, so
this is only some second hand experience. Maybe it is all wrong setups in
combination with Lispbuilder and ECL itself is stable, I don't know.

But I know that it is much easier to get a full featured running Python
system on Windows, MacOS X and Linux, so this is something where Lisp
distributions could be improved.

--
Frank Buss, fb at frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Juanjo

2009-07-21 09:23:59 UTC

Have you looked atECL?
http://ecls.sourceforge.net/
I've used it only a little, so I can't vouch for its stability, but it
fits the threading and license requirements (well, some corporate
lawyers have trouble with the LGPL, but I think it's usable).

http://www.mail-archive.com/application-builder at lispniks.com/msg01069...

ECL suffers from fast development problems if this is what you mean.
People are advised to stay with certain releases and we announce when
some ports are broken due to progress along certain lines.

For instance, if I find that the generational garbage collector is
needed for Linux, FreeBSD, OpenBSD and OS X, and it works, I do not
mind dropping temporarily the mingw port until the garbage collector
library catches up. People who wanted to stay with mingw produced a
branch (see Samium's posts) with the old garbage collector.

Now this is not so dramatic. ECL now has a release cycle of ONE MONTH.
If you find that this month's release does not work on your platform
(and this is normally explicit in the announcement), then do not
upgrade and wait one or two months until the problem is solved.

OTOH, people only seem to notice problems when their petty platform is
temporarily broken, but nobody seems to notice the overall stability
and portability of the platform. See the list http://ecls.sourceforge.net/logs.html
which will soon expand including Solaris and regular builds on Windows
using the free Microsoft compiler. And once the ARM computer I have
been gifted by a happy arrives, then Debian-ARM as well.

Juanjo

milanj

2009-07-21 09:37:27 UTC

Post by Frank Buss
Python is not that bad. Unlike Lisp, there is much less undefined behavior,
there is one free unique implementation on the 3 major platforms Linux,
Windows and MacOS X, which is stable, support multithreading and has a
default GUI library binding, which is difficult to find for Lisp (e.g. I
don't know of a free modern and stable Lisp implemenation with
mulithreading support for Windows, with a licence with which you can use it
in closed source commercial programs, like you can do with Python). Many
problems in the Lispbuilder mailing list are related to problems due to
different operating systems and Lisp implementations.
Frank Buss, f... at frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de

Someone should mention Clozure CL - http://trac.clozure.com/openmcl
As you can see there is os x, freebsd, linux, solaris and windows port
and all of them use native threads (python still use green threads ?)
and development is pretty alive, they did planty of developing last
year[s], ccl licence permits you to deliver closed source programs ...
CCL is promising bright feature to CL since looks like the insist of
building stable implementation across most arch in use today

Raffael Cavallaro

2009-07-21 14:13:00 UTC

Post by milanj
Someone should mention Clozure CL - http://trac.clozure.com/openmcl
As you can see there is os x, freebsd, linux, solaris and windows port
and all of them use native threads (python still use green threads ?)
and development is pretty alive, they did planty of developing last
year[s], ccl licence permits you to deliver closed source programs ...
CCL is promising bright feature to CL since looks like the insist of
building stable implementation across most arch in use today

Hear, hear!

--
Raffael Cavallaro

Neil Hodgson

2009-07-21 23:06:02 UTC

Post by milanj
and all of them use native threads (python still use green threads ?)

Python uses native threads.

Neil

Raffael Cavallaro

2009-07-22 05:09:35 UTC

On 2009-07-21 19:06:02 -0400, Neil Hodgson

Post by Neil Hodgson
Python uses native threads.

So it can be teh-slowness on all ur cores!

<http://shootout.alioth.debian.org/u64q/benchmark.php?test=nbody&lang=all>

The global interpreter lock doesn't help much either.

--
Raffael Cavallaro

Isaac Gouy

2009-07-23 17:15:00 UTC

On Jul 21, 10:09?pm, Raffael Cavallaro

Post by Raffael Cavallaro
On 2009-07-21 19:06:02 -0400, Neil Hodgson

? ?Python uses native threads.

So it can be teh-slowness on all ur cores!
<http://shootout.alioth.debian.org/u64q/benchmark.php?test=nbody?=all>
The global interpreter lock doesn't help much either.

As you've linked to programs that /have not/ been written to use
threading or multiple cores (look at the "~ CPU Load" column) I get
the feeling I'm missing the joke?

Raffael Cavallaro

2009-07-23 17:45:52 UTC

Post by Isaac Gouy
I get
the feeling I'm missing the joke?

Yes, you are missing the joke. The point is that if python is 60x
slower than C, even if there were not a GIL, it would require running
the python program on a 60 core machine just reach parity with C. The
existence of the GIL means that in reality you'd probably need a
several hundred core machine running python just to equal what C can do
on one core. Hence the 13375p34k pseudo quote - "teh slowness on all ur
cores!"

--
Raffael Cavallaro

Jon Harrop

2009-07-23 21:49:13 UTC

Post by Raffael Cavallaro
Yes, you are missing the joke. The point is that if python is 60x
slower than C, even if there were not a GIL, it would require running
the python program on a 60 core machine just reach parity with C. The
existence of the GIL means that in reality you'd probably need a
several hundred core machine...

No, OCaml is in the same boat as Python. Spawning a parallel work item takes
20,000x longer in OCaml than in F#. Gathering the results is asymptotically
slower in general. Consequently, for most problems, Python or OCaml running
on an infinite number of cores cannot beat F# running on 2 or more (and I
already have 8) because the overheads are far too high for parallelism to
pay off.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

game_designer

2009-07-23 17:54:26 UTC

Perhaps like Xah Lee I find, after many years of Lisp programming,
these discussions increasingly frustrating and even, in some sense,
amazing. We can speculate all we want about syntax and semantics of
programing languages. What counts in the end are really the PRAGMATICS
of programming languages. How can I do something with a language that
is USEFUL to me? Will the result be good looking, and snappy or some
ugly, dated looking, crashing application? For instance, last time I
played with Scheme (drScheme) to explore some OpenGL 3D issue I was
not impressed at all. One can debate the syntax and semantics of
Scheme but in that particular instance all that was important to me
was the fact that the Scheme example performed terrible and the
threading fell completely apart when running more that a single OpenGL
window. Perhaps this was coded poorly but I don't care. Scheme left a
pretty bad impression.

alex

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

Paul Donnelly

2009-07-23 19:09:31 UTC

Post by game_designer
Perhaps like Xah Lee I find, after many years of Lisp programming,
these discussions increasingly frustrating and even, in some sense,
amazing. We can speculate all we want about syntax and semantics of
programing languages. What counts in the end are really the PRAGMATICS
of programming languages. How can I do something with a language that
is USEFUL to me? Will the result be good looking, and snappy or some
ugly, dated looking, crashing application? For instance, last time I
played with Scheme (drScheme) to explore some OpenGL 3D issue I was
not impressed at all. One can debate the syntax and semantics of
Scheme but in that particular instance all that was important to me
was the fact that the Scheme example performed terrible and the
threading fell completely apart when running more that a single OpenGL
window. Perhaps this was coded poorly but I don't care. Scheme left a
pretty bad impression.

One implementation of one dialect of Lisp worked poorly for one
particular project some unspecified number of years ago, judging by code
(written by you, no less) that may or may not have been terrible? I
appreciate that this was a frustrating experience, but I don't see what
lesson about Lisp programming we're supposed to be getting from this.

Ron Garret

2009-07-22 16:36:28 UTC

In article <uRr9m.6558$ze1.5162 at news-server.bigpond.net.au>,

Post by Neil Hodgson

Post by milanj
and all of them use native threads (python still use green threads ?)

Python uses native threads.

But then it adds the global interpreter lock, which completely
undermines the utility of native threads. So yes, it uses native
threads, but it does not actually realize the benefits of that use.

rg

Carl Banks

2009-07-22 17:01:31 UTC

In article <uRr9m.6558$ze1.5... at news-server.bigpond.net.au>,

Post by milanj
and all of them use native threads (python still use green threads ?)

? ?Python uses native threads.

But then it adds the global interpreter lock, which completely
undermines the utility of native threads. ?So yes, it uses native
threads, but it does not actually realize the benefits of that use.

Wrong. It only partially undermines the utility of native threads,
not completely. Native threading allows some threads to run while
others are blocked in a system call (as well as in a few other minor
cases), which can't be done with green threads.

Carl Banks

unknown

2009-07-22 17:20:20 UTC

Post by Carl Banks
Wrong. It only partially undermines the utility of native threads,
not completely. Native threading allows some threads to run while
others are blocked in a system call (as well as in a few other minor
cases), which can't be done with green threads.

Why is that such an advantage? Green threads work fine if you just
organize the i/o system to never block.

Carl Banks

2009-07-22 17:59:50 UTC

Wrong. ?It only partially undermines the utility of native threads,
not completely. ?Native threading allows some threads to run while
others are blocked in a system call (as well as in a few other minor
cases), which can't be done with green threads.

Why is that such an advantage? ?Green threads work fine if you just
organize the i/o system to never block. ?

Because then I don't have to organize the I/O system never to block.

Carl Banks

unknown

2009-07-22 19:04:07 UTC

Why is that such an advantage? ?Green threads work fine if you just
organize the i/o system to never block. ?

Because then I don't have to organize the I/O system never to block.

We're talking about what a language implementation does behind the
scenes, I thought.

Carl Banks

2009-07-22 19:35:52 UTC

Why is that such an advantage? ?Green threads work fine if you just
organize the i/o system to never block. ?

Because then I don't have to organize the I/O system never to block.

We're talking about what a language implementation does behind the
scenes, I thought.

No we're not, we are talking about the whether GIL completely or only
partially undermines the use of native threads on Python.

I don't think your fantasy async-only all-green-thread langauge
implementation is possible anyway. How would you wait on a pipe in
one thread, a socket in another, a semaphore in a third? (Are there
any popular OSes that offer a unified polling interface to all
possible synchronizations?) And what do you do about drivers or
libraries that make underlying blocking calls? What if you have a
busy calculation going on in the background?

Carl Banks

unknown

2009-07-23 00:27:23 UTC

Post by Carl Banks
I don't think your fantasy async-only all-green-thread langauge
implementation is possible anyway.

Erlang and GHC both work like that, quite successfully:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=threadring&lang=all

Post by Carl Banks
How would you wait on a pipe in one thread, a socket in another, a
semaphore in a third?

You can select on pipes and sockets, I think. Not sure about
semaphores.

Post by Carl Banks
(Are there any popular OSes that offer a unified polling interface to
all possible synchronizations?) And what do you do about drivers or
libraries that make underlying blocking calls? What if you have a
busy calculation going on in the background?

I don't think the concept of "drivers" applies to user-mode programs.
For FFI calls you would use an OS thread. The language runtime
switches between busy computation threads on a timer tick.

Carl Banks

2009-07-23 23:30:54 UTC

Post by Carl Banks
I don't think your fantasy async-only all-green-thread langauge
implementation is possible anyway.

?http://shootout.alioth.debian.org/gp4/benchmark.php?test=threadring&l...

I am not suggesting that you can't do a lot of things with async I/O.
But can you do *everything* that native threads can do? I don't think
so.

So when you asked:

"Why is that [native threading] such an advantage? Green threads work
fine if you just
organize the i/o system to never block."

Well, the answer is they don't always work fine. Just organizing the
I/O system never to block won't cut it, since things other than I/O
block. For green threads to work fine all the time you have to be
able organize your entire system never to block, and I don't think
it's possible on the common OSes in use today. Until that happens,
there will always be advantages to being able to use native threads on
a single core.

Post by Carl Banks
How would you wait on a pipe in one thread, a socket in another, a
semaphore in a third? ?

You can select on pipes and sockets, I think. ?Not sure about
semaphores. ?

So you made a claim that "green threads work fine", and rhetorically
suggested that native threads had no advantages, yet you're not even
100% sure you can select on both pipes and sockets (both common forms
of I/O), let alone semaphores?

[You can select on sockets and pipes in Unix, not in Windows, although
on Windows I think there are other ways to do it besides the select
call.]

Post by Carl Banks
(Are there any popular OSes that offer a unified polling interface to
all possible synchronizations?) ?And what do you do about drivers or
libraries that make underlying blocking calls? ?What if you have a
busy calculation going on in the background?

I don't think the concept of "drivers" applies to user-mode programs.
For FFI calls you would use an OS thread.

That's contrary to the hypothesis, isn't it?

?The language runtime
switches between busy computation threads on a timer tick.

This would seem to result in a tradeoff between performance and low-
latency. Well that happens at the OS-level too but the OS can respond
to interrupts and task switch between timer ticks at finer intervals.
Back in my DOS days I wrote user programs that responded to I/O
interrupts, but it doesn't seem to be common practice in modern OSes
to easily allow this.

And Paul, if I'm being a little hard on you here, it's not that I'm
taking issue with your own claim so much as with your dismissal of
mine.

Carl Banks

unknown

2009-07-23 23:57:10 UTC

Post by unknown
I don't think the concept of "drivers" applies to user-mode programs.
For FFI calls you would use an OS thread.

That's contrary to the hypothesis, isn't it?

Yeah, it would have been better to say, green threads are ok for most
typical forms of i/o concurrency, but OS threads are still necessary
for some things. An FFI call in particular isn't exactly under the
control of your language's runtime system; it has to be treated
more like an external program.

OS thread?switching is much more expensive than green thread
switching, so it's still preferable to use green threads when
possible.

Post by unknown
?The language runtime switches between busy computation threads on
?a timer tick.

This would seem to result in a tradeoff between performance and low-
latency.

GHC appears to use a 100 hz timer, which I'd expect to be fast enough
for interactive applications while still not causing too much cpu
load. I don't know if it has a way to assign priorities to
microthreads (e.g. if you have one running your program's GUI) though.

I don't think either Python or GHC can implement hard-real-time
latency because they both use stop-the-world garbage collection.
E.g. in Python, releasing the last reference to a large list or dict
can take a long time.

Post by Carl Banks
And Paul, if I'm being a little hard on you here, it's not that I'm
taking issue with your own claim so much as with your dismissal of
mine.

Well, the issue was why Python uses native threads pervasively. As
far as I can tell, it's just an implementation artifact that has no
really compelling justification.

Carl Banks

2009-07-24 03:11:23 UTC

Post by unknown
I don't think the concept of "drivers" applies to user-mode programs.
For FFI calls you would use an OS thread.

That's contrary to the hypothesis, isn't it?

Yeah, it would have been better to say, green threads are ok for most
typical forms of i/o concurrency, but OS threads are still necessary
for some things. ?An FFI call in particular isn't exactly under the
control of your language's runtime system; it has to be treated
more like an external program.
OS thread?switching is much more expensive than green thread
switching, so it's still preferable to use green threads when
possible.

That is reasonable. Thank you.

Post by Carl Banks
And Paul, if I'm being a little hard on you here, it's not that I'm
taking issue with your own claim so much as with your dismissal of
mine.

Well, the issue was why Python uses native threads pervasively. ?As
far as I can tell, it's just an implementation artifact that has no
really compelling justification.

Probably for this reason: "Because then they didn't have to arrange
for the I/O to never block."

Carl Banks

Grant Edwards

2009-07-22 18:49:58 UTC

Post by Ron Garret
In article <uRr9m.6558$ze1.5162 at news-server.bigpond.net.au>,

Post by Neil Hodgson

Post by milanj
and all of them use native threads (python still use green threads ?)

Python uses native threads.

But then it adds the global interpreter lock, which completely
undermines the utility of native threads. So yes, it uses native
threads, but it does not actually realize the benefits of that use.

Not all of the time. For library/extension calls that release
the GIL, it does.

--
Grant Edwards grante Yow! I was making donuts
at and now I'm on a bus!
visi.com

Tim Bradshaw

2009-07-21 17:41:59 UTC

Post by Frank Buss
(e.g. I
don't know of a free modern and stable Lisp implemenation with
mulithreading support for Windows, with a licence with which you can use it
in closed source commercial programs, like you can do with Python).

Openmcl seems reasonably stable to me, is LLGPL-licensed, and runs on
these platforms and Solaris x86.

It's kind of tragic, of course, that this kind of parasitic behaviour
(will not consider a commercial product to use in your commercial
system) has now become so common.

Pascal J. Bourguignon

2009-07-22 01:19:19 UTC

Post by Tim Bradshaw

Openmcl seems reasonably stable to me, is LLGPL-licensed, and runs on
these platforms and Solaris x86.
It's kind of tragic, of course, that this kind of parasitic behaviour
(will not consider a commercial product to use in your commercial
system) has now become so common.

GPL.

--
__Pascal Bourguignon__

Carl Banks

2009-07-19 21:46:42 UTC

How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

There was no reason to crosspost this here--looking at the original
thread on comp.lang.lisp it seems they were doing a surprisingly good
job discussing the issue.

I'm guessing it's because the fanboy Lispers like Ken Tifton were busy
with a flamewar in another thread (LISP vs PROLOG vs HASKELL).

Carl Banks

Tim Daneliuk

2009-07-19 23:29:07 UTC

How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

There was no reason to crosspost this here--looking at the original
thread on comp.lang.lisp it seems they were doing a surprisingly good
job discussing the issue.
I'm guessing it's because the fanboy Lispers like Ken Tifton were busy
with a flamewar in another thread (LISP vs PROLOG vs HASKELL).
Carl Banks

This is an incredibly important discussion and is much weaker because
it does not also include Pascal, BASIC, Ada, Oberon and Forth. In fact,
picking a computer language is the most important discussion in
Computer Science and eclipses even P=NP? in significance. I sure hope
we can keep this thread going for a few months. For guidance, see:

http://www.tundraware.com/Technology/How-To-Pick-A-Programming-Language/

--
----------------------------------------------------------------------------
Tim Daneliuk tundra at tundraware.com
PGP Key: http://www.tundraware.com/PGP/

Carl Banks

2009-07-20 00:45:01 UTC

Post by Tim Daneliuk

How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

There was no reason to crosspost this here--looking at the original
thread on comp.lang.lisp it seems they were doing a surprisingly good
job discussing the issue.
I'm guessing it's because the fanboy Lispers like Ken Tifton were busy
with a flamewar in another thread (LISP vs PROLOG vs HASKELL).
Carl Banks

This is an incredibly important discussion

It might be an important question but a discussion on Usenet about it
is utterly useless.

Post by Tim Daneliuk
and is much weaker because
it does not also include Pascal, BASIC, Ada, Oberon and Forth.

In the same way that a movie is weaker because the director edited out
the bad scenes.

Post by Tim Daneliuk
In fact,
picking a computer language is the most important discussion in
Computer Science and eclipses even P=NP? in significance. I sure hope
we can keep this thread going for a few months.

Please feel free to extend this flame-war along for a few months on
comp.lang.lisp. Not here.

Carl Banks

Tim Daneliuk

2009-07-20 05:18:58 UTC

Post by Tim Daneliuk

How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

There was no reason to crosspost this here--looking at the original
thread on comp.lang.lisp it seems they were doing a surprisingly good
job discussing the issue.
I'm guessing it's because the fanboy Lispers like Ken Tifton were busy
with a flamewar in another thread (LISP vs PROLOG vs HASKELL).
Carl Banks

This is an incredibly important discussion

It might be an important question but a discussion on Usenet about it
is utterly useless.

Post by Tim Daneliuk
and is much weaker because
it does not also include Pascal, BASIC, Ada, Oberon and Forth.

In the same way that a movie is weaker because the director edited out
the bad scenes.

Please feel free to extend this flame-war along for a few months on
comp.lang.lisp. Not here.
Carl Banks

Uh Carl ... are you familiar with the concept of mocking humor?

--
----------------------------------------------------------------------------
Tim Daneliuk tundra at tundraware.com
PGP Key: http://www.tundraware.com/PGP/

Carl Banks

2009-07-20 07:08:31 UTC

Post by Tim Daneliuk
Uh Carl ... are you familiar with the concept of mocking humor?

You got me, lip hurts bad. :)

Carl Banks

Grant Edwards

2009-07-20 14:59:17 UTC

Post by Tim Daneliuk

In fact, picking a computer language is the most important
discussion in Computer Science and eclipses even P=NP? in
significance. I sure hope we can keep this thread going for a
few months.

Please feel free to extend this flame-war along for a few
months on comp.lang.lisp. Not here.

Uh Carl ... are you familiar with the concept of mocking humor?

Irony on Usenet: always a bit of a gamble...

--
Grant Edwards grante Yow! Vote for ME -- I'm
at well-tapered, half-cocked,
visi.com ill-conceived and
TAX-DEFERRED!

Steven D'Aprano

2009-07-20 05:11:17 UTC

E.g. the number system: In many Lisp
implementations (/ 2 3) results in the fractional object 2/3. In Python
2.6 "2 / 3" results in "0". Looks like with Python 3.1 they have fixed
it, now it returns "0.6666666666", which will result in lots of fun for
porting applications written for Python <= 2.6.

How do you explain that something as inferior as Python beat Lisp in the
market place despite starting 40 years later.

http://www.jwz.org/doc/worse-is-better.html

Besides, one can legitimately disagree that 2/3 => 0 is the wrong thing
to do. It's the right thing to do if you're doing integer maths.

--
Steven

unknown

2009-07-20 06:13:15 UTC

Post by Steven D'Aprano
Besides, one can legitimately disagree that 2/3 => 0 is the wrong thing
to do. It's the right thing to do if you're doing integer maths.

I wonder whether 2/3 => ValueError is preferable.

vippstar

2009-07-20 12:29:40 UTC

Post by Steven D'Aprano
Besides, one can legitimately disagree that 2/3 => 0 is the wrong thing
to do. It's the right thing to do if you're doing integer maths.

I wonder whether 2/3 => ValueError is preferable.

Not all software wants this. It shouldn't be part of the language but
rather part of your code if you need such a feature. (for instance, to
distinguish between 2/3 and divisions with 0 dividend).

unknown

2009-07-20 16:50:56 UTC

Post by vippstar

Post by unknown
I wonder whether 2/3 => ValueError is preferable.

Not all software wants this. It shouldn't be part of the language but
rather part of your code if you need such a feature. (for instance, to
distinguish between 2/3 and divisions with 0 dividend).

I don't see how to implement such a thing in my code, if I believe
that the ring of integers doesn't have any concept of division and so
attempts to divide integers should be treated as errors. Yes of
course the present / operator is useful, but I could do just as well
with the divmod function which I think is more explicit.

vippstar

2009-07-20 18:31:08 UTC

Post by vippstar

Post by unknown
I wonder whether 2/3 => ValueError is preferable.

Not all software wants this. It shouldn't be part of the language but
rather part of your code if you need such a feature. (for instance, to
distinguish between 2/3 and divisions with 0 dividend).

I don't see how to implement such a thing in my code,

Write a function:

(if (< x y)
ValueError
(/ x y))

This will return 0 only if the dividend = 0, not in integer division x/
y with y > x, which will return ValueError. Of course, ValueError must
not be an integer, because that could be the result of an integer
division. If it's not possible to return multiple types, then the
function can make use of some error handling mechanism.

Post by unknown
if I believe that the ring of integers doesn't have any concept
of division and so attempts to divide integers should be treated
as errors.

Wouldn't that mean 3/2 would also evaluate to ValueError? But 3/2 = 1
in integer division, not 0, like 2/3. Regardless, it's a specialized
requirement, and thus should either be implemented by the programmer
or the language could provide it if it's specialized, (for instance, I
wouldn't require a language to provide text manipulation features, but
I expect them from perl because it's not a general all purpose
language [the name designates that, however it can be used as one -
like lisp])

Post by unknown
course the present / operator is useful, but I could do just as well
with the divmod function which I think is more explicit.

What? Python? Aww.

unknown

2009-07-20 22:22:20 UTC

Post by vippstar

Post by unknown
I don't see how to implement such a thing in my code,

(if (< x y)
ValueError
(/ x y))

I meant changing the behavior of integer division in python.

Post by vippstar
Wouldn't that mean 3/2 would also evaluate to ValueError?

Yes, the idea was that one can take the view that integer division
should not be allowed except through a 'div' function or some such.

vippstar

2009-07-20 22:48:51 UTC

Post by unknown
I don't see how to implement such a thing in my code,

? (if (< x y)
? ? ? ValueError
? ? ? (/ x y))

I meant changing the behavior of integer division in python.

You'd either have to hack an implementation or change the standard (I
just noticed python doesn't have one).

Wouldn't that mean 3/2 would also evaluate to ValueError?

Yes, the idea was that one can take the view that integer division
should not be allowed except through a 'div' function or some such.

You brought up 3/2 == ValueError as a more appropriate value for the
integer division to evaluate, rather than 0. I thought you meant
specifically those kinds of divisions.

greg

2009-07-22 00:47:35 UTC

Post by Steven D'Aprano
Besides, one can legitimately disagree that 2/3 => 0 is the wrong thing
to do. It's the right thing to do if you're doing integer maths.

True, but the question is how best to decide whether the
programmer wants to do integer maths.

Deciding based on the types of the operands is okay in a
statically typed language. But it's asking for trouble in
a dynamically-typed language, especially where it's common
practice to use ints as a substitute for floats that
happen to have integer values.

EIBTI in this case.

--
Greg

Marcus Wanner

2009-07-20 17:06:39 UTC

Post by Steven D'Aprano
Besides, one can legitimately disagree that 2/3 => 0 is the wrong thing
to do. It's the right thing to do if you're doing integer maths.

I wonder whether 2/3 => ValueError is preferable.

Not for me :(

Slobodan Blazeski

2009-07-21 14:42:18 UTC

How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

Worse is better?

Bobi
http://www.linkedin.com/in/slobodanblazeski

Jean-Paul Calderone

2009-07-22 20:53:17 UTC

Why is that such an advantage? ?Green threads work fine if you just
organize the i/o system to never block.

Because then I don't have to organize the I/O system never to block.

We're talking about what a language implementation does behind the
scenes, I thought.

No we're not, we are talking about the whether GIL completely or only
partially undermines the use of native threads on Python.
I don't think your fantasy async-only all-green-thread langauge
implementation is possible anyway. How would you wait on a pipe in
one thread, a socket in another, a semaphore in a third? (Are there
any popular OSes that offer a unified polling interface to all
possible synchronizations?)

Every OS I can think of can support the three examples you gave here.

Post by Carl Banks
And what do you do about drivers or
libraries that make underlying blocking calls?

Certainly a point to consider.

Post by Carl Banks
What if you have a busy calculation going on in the background?

What if you do? Are you suggesting this would somehow prevent I/O from
being serviced? I'm not sure why, as long as the implementation pays
attention to I/O events.

Jean-Paul

Carl Banks

2009-07-22 22:17:52 UTC

Post by Jean-Paul Calderone

Post by Jean-Paul Calderone

Why is that such an advantage? ?Green threads work fine if you just
organize the i/o system to never block.

Because then I don't have to organize the I/O system never to block.

We're talking about what a language implementation does behind the
scenes, I thought.

No we're not, we are talking about the whether GIL completely or only
partially undermines the use of native threads on Python.
I don't think your fantasy async-only all-green-thread langauge
implementation is possible anyway. ?How would you wait on a pipe in
one thread, a socket in another, a semaphore in a third? ?(Are there
any popular OSes that offer a unified polling interface to all
possible synchronizations?)

Every OS I can think of can support the three examples you gave here.

I guess you would know, but polling on all of these at once has got
use more obscure calls than I'm familiar with.

On Linux I can use select to wait for pipes and sockets, but not SysV
semaphores AFAIK. On Windows it's well known that select only works
for sockets.

So do all these OSes have some kind of __mega_unifying_poll system
call that works for anything that might possibly block, that you can
exploit from a user process?

Post by Carl Banks
And what do you do about drivers or
libraries that make underlying blocking calls?

Certainly a point to consider.

Post by Carl Banks
What if you have a busy calculation going on in the background?

What if you do? ?Are you suggesting this would somehow prevent I/O from
being serviced? ?I'm not sure why, as long as the implementation pays
attention to I/O events.

Using native theads with blocking allows one to run a background
calculation without burdening it to yield often enough to provide
sufficient response times for other operations (which may or may not
be convenient to do).

Even if it's possible to accomplish arbitrary background processing
without native threading (and it is not, because the background
calculations could be performed by a library you don't control whose
author didn't bother yielding at any point), you cannot reasonably
claim native threads have no advantage in this case.

Carl Banks

Nobody

2009-07-23 09:37:55 UTC

Post by Carl Banks
So do all these OSes have some kind of __mega_unifying_poll system
call that works for anything that might possibly block, that you can
exploit from a user process?

Threads ;)

They also have the advantage that one thread can run while another is
waiting on disk I/O, which isn't something which can be done with a
select/poll interface (even if select/poll worked for files, it doesn't
help for mapped files).

unknown

2009-07-23 22:06:22 UTC

Post by Nobody
They also have the advantage that one thread can run while another is
waiting on disk I/O, which isn't something which can be done with a
select/poll interface (even if select/poll worked for files, it doesn't
help for mapped files).

AIO can help with this, but I don't know any language runtimes that
use it right now. Really, this (and the similar issue of ram cache
misses) is basically why hardware hyperthreading exists too. To get
processor parallelism you do have to use OS threads, but green threads
are lighter weight and switch faster, so you want to use a combination
of both. Basically, use about as many OS threads as you have hardware
threads (i.e. CPU cores or hyperthreads), and then assign green
threads to OS threads in your application runtime.

Carl Banks

2009-07-23 22:39:35 UTC

Post by Nobody

Post by Carl Banks
So do all these OSes have some kind of __mega_unifying_poll system
call that works for anything that might possibly block, that you can
exploit from a user process?

Threads ;)

Yeah, well that was kind of my point, you'd need native threads to do
some of this.

Jean-Paul Calderone seemed to be suggesting that it was possible to
wait for events on sockets, pipes, and IPC semaphores at the same. I
pointed out that it isn't possible with well-known I/O polling calls
(like select), so there must be some other way, and I was wondering
what it was.

He's a proponent of Twisted, which is a major async framework, and I'd
have to figure that once or twice they've encounted issues like "how
to poll both a semaphore and a socket at the same time", so maybe
they've found a good solution to it.

Carl Banks

Дамјан Георгиевски

2009-07-28 14:17:45 UTC

Post by Carl Banks
So do all these OSes have some kind of __mega_unifying_poll system
call that works for anything that might possibly block, that you can
exploit from a user process?

On Linux at least, the select/poll/epoll is that system, the trick is to
use eventfd, timerfd and signalfd which are Linux specific system calls.

I think that covers everything needed. (eventfd is used for semaphores)

--
?????? ( http://softver.org.mk/damjan/ )

Give me the knowledge to change the code I do not accept,
the wisdom not to accept the code I cannot change,
and the freedom to choose my preference.

Rui Maciel

2009-07-24 00:52:00 UTC

Post by fft1976
How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

Probably due to similar reasons that lead php to become remotely relevant.

Rui Maciel

Carl Banks

2009-07-24 03:51:02 UTC

Post by fft1976
How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

Probably due to similar reasons that lead php to become remotely relevant.

Well, the only reason PHP became relevant because it was an easy to
deploy solution in a single application domain, the web, that happened
to explode.

The same thing happened to Python.

Oh, wait, no it didn't.

Carl Banks

Raffael Cavallaro

2009-07-24 18:06:32 UTC

Post by fft1976
How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

Probably due to similar reasons that lead php to become remotely relevant

.
Well, the only reason PHP became relevant because it was an
easy

^^^^^^^^
^^^^^^^^ (emphasis added)

Post by Carl Banks
to
deploy solution in a single application domain, the web, that happened
to explode.

i.e., Python "beat" lisp because it is ~70% of lisp in a form that is
much more palatable to the average programmer, just as php became
popular because it is powerful enough to do websites and, most
importantly, apprehensible to mediocre programmers and even some
non-programmers.

--
Raffael Cavallaro

ACL

2009-07-24 21:58:57 UTC

On Jul 24, 2:06?pm, Raffael Cavallaro

Post by fft1976
How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

Probably due to similar reasons that lead php to become remotely relevant

.
Well, the only reason PHP became relevant because it was an
easy

^^^^^^^^
^^^^^^^^ (emphasis added)

Post by Carl Banks
to
deploy solution in a single application domain, the web, that happened
to explode.

I actually think that the thing holding lisp back is 'bus factor'.

Lets assume I have a java project and a lisp project:

Java project:
I have maybe 10 or 12 people on my team working on various subsystems
of my project. There are probably one or two 'technical leader' types
in the group, and a bunch of others who are sort of 'serfs', banging
out java classes. Lets say one of my important guys gets totally
splattered by a bus... I've still got another one left! I can rely on
the other guy to keep things afloat while I train up a new leader
type.

Lisp project:
I don't need as many people. I have 3 or 4 people, and one person is
my technical leader and lisp guru. Guru is probably in charge of more
difficult macros and (because of that), also in charge of the overall
design (macros are design patterns embodied in code). Lets say he gets
totally annihilated by the bus. What do I do now? I had all my eggs in
one basket and my project is now stalled.

I think that (for example) when people are saying that lisp macros
make projects difficult to understand, or that lisp hackers are much
harder to find than other programmers, what they are really showing is
that because of the nature of the language, lisp projects get
organized in a different way. This different way of organization is
especially hard on corporate projects, because managers are expected
to plan for when some important guy drops dead.

The problem with lisp is that if you hire too many extra hackers, you
end up with a bunch of people sitting around twiddling their thumbs.

This may also explain why it gets touted as an academic language. In
academia if a professor who is leading some important research drops
dead, who cares? Most likely no one had interest as to whether the
university would make a profit on this particular research endeavor
(except maybe the deceased, as he would like to get grant funding).

So I guess then we can give some tips for making lisp more acceptable
for 'paying gigs'.
1.) If you are a lisp hacker, it is your duty to be lazier and write
less code. We need to make it so that these projects need sizable
teams of people to complete.

2.) Write down everything that you do, everything you are going to do.
Maybe draw some object diagrams of your important/fancy macros, make
sure these are stored with the source. (You'll note that an iterative
approach to programming isn't really conducive to making a lot of
diagrams of stuff...)

I don't know what this has to do with python or scheme or people
dumping scheme for python.
Honestly, I seriously doubt that any undergraduate programming course
will give you enough actual programming experience to make you
seriously proficient in the language (research projects not counted).
The language used to teach the material is a cursory detail.

Tayssir John Gabbour

2009-07-25 07:23:45 UTC

Post by ACL
I actually think that the thing holding lisp back is 'bus factor'.
I have maybe 10 or 12 people on my team working on various subsystems
of my project. There are probably one or two 'technical leader' types
in the group, and a bunch of others who are sort of 'serfs', banging
out java classes. Lets say one of my important guys gets totally
splattered by a bus... I've still got another one left! I can rely on
the other guy to keep things afloat while I train up a new leader
type.
I don't need as many people. I have 3 or 4 people, and one person is
my technical leader and lisp guru. Guru is probably in charge of more
difficult macros and (because of that), also in charge of the overall
design (macros are design patterns embodied in code). Lets say he gets
totally annihilated by the bus. What do I do now? I had all my eggs in
one basket and my project is now stalled.

A Clojure programmer mentioned interesting solutions to this used by
his company, such as partnerships with similarly Agile companies.
http://programmingtour.blogspot.com/2009/07/conversation-with-stuart-halloway.html

I agree that the bus factor -- as well as some other problems -- works
against Lisp's acceptance.

All the best,
Tayssir

Jon Harrop

2009-07-25 11:02:08 UTC

I don't need as many people...

Is there any actual evidence of that?

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Carl Banks

2009-07-25 04:55:26 UTC

On Jul 24, 11:06?am, Raffael Cavallaro

Post by fft1976
How do you explain that something as inferior as Python beat Lisp in
the market place despite starting 40 years later.

Probably due to similar reasons that lead php to become remotely relevant

.
Well, the only reason PHP became relevant because it was an
easy

^^^^^^^^
^^^^^^^^ (emphasis added)

Post by Carl Banks
to
deploy solution in a single application domain, the web, that happened
to explode.

That the two languages made something easier is the beginning and end
of the similarities between them.

PHP made hacking together a security-hole-ridden website easier.
Python made actual programming easier.

PHP became what it is because it rode on the coattails of a technology
that grew in spite of it (kind of like everything Microsoft has
shipped since Windows 3.1). Python became what it is because it
earned the respect of programmers, who contributed to it and spread
the word about it. That it is easy to use is only a part of why it
earned that respect. Two languages could not have come to prominence
by more different means.

I can handle Python being called inferior to Lisp or a language for
stupid people or a single-core-using dinosaur of a language or worse
than Perl.

But please don't put it on the same level as PHP. Their situations
have almost nothing in common.

Carl Banks

Xah Lee

2009-07-25 06:54:22 UTC

PHP is popular because it is geared for the server-side web scripting
lang, and simpler and easy to use, than popular free alternatives at
the time (such as Perl and Java's JSP).

Python became popular primarily because its ease-to-read syntax.

Btween the two, PHP is much easier to use, and much a pleasure to
program in. Python is a pain in the ass.

PHP is functional. The language is not elegant, lots of
inconsistancies. However, it's a joy to use for any practical task in
its web scripting field. PHP has one of the best documentation among
open source computer languages, i'd say top 5.

Python is a twist, with half-assed lambda, a culty community thinking
"computer science R us", and it has this OOP obsession. The Guido guy
do not understand functional programing, but has the pleasure to
actitively badmouth it.

References:

? Language, Purity, Cult, and Deception
http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html

? What Languages to Hate
http://xahlee.org/UnixResource_dir/writ/language_to_hate.html

? Lambda in Python 3000
http://xahlee.org/perl-python/python_3000.html

? Python Documentation Problems
http://xahlee.org/perl-python/python_doc_index.html

? Examples Of Quality Documentation In The Computing Industry
http://xahlee.org/perl-python/quality_docs.html

? Xah's Perl and Python Tutorial
http://xahlee.org/perl-python/index.html

? Xah's PHP Tutorial
http://xahlee.org/php/index.html

Xah
? http://xahlee.org/

?

Carl Banks

2009-07-25 11:49:09 UTC

On Jul 24, 11:54?pm, Xah Lee <xah... at gmail.com> wrote:
[snip]

Post by Xah Lee
? Language, Purity, Cult, and Deception
?http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html
? What Languages to Hate
?http://xahlee.org/UnixResource_dir/writ/language_to_hate.html
? Lambda in Python 3000
?http://xahlee.org/perl-python/python_3000.html
? Python Documentation Problems
?http://xahlee.org/perl-python/python_doc_index.html
? Examples Of Quality Documentation In The Computing Industry
?http://xahlee.org/perl-python/quality_docs.html
? Xah's Perl and Python Tutorial
?http://xahlee.org/perl-python/index.html
? Xah's PHP Tutorial
?http://xahlee.org/php/index.html
? Xah
?http://xahlee.org/

Wow, you leave no stone unturned.

Post by Xah Lee
"computer science R us"

I'm stealing this.

Carl BAnks

Dimiter "malkia" Stanev

2009-07-28 18:46:38 UTC

Post by Xah Lee
PHP is functional.

PHP is functional, as in "it functions!". PHP is not functional, as in
"it ain't functions!"

Raffael Cavallaro

2009-07-26 04:56:59 UTC

Post by Carl Banks
But please don't put it on the same level as PHP. Their situations
have almost nothing in common.

Their situations have much in common; Python attracted programmers away
from (for example) C++, becuse python is easier to master; Then php
came along and attracted programmers away from (for example) python,
because php is easier to master.

This doesn't mean they're on the same level - in fact, if you read
carefully you'll see my original post said as much: python attracted
average programmers; php attracted mediocre programmers and even some
non-programmers, which means that php is clearly a lesser language than
python.

--
Raffael Cavallaro

Aahz

2009-07-26 13:16:39 UTC

In article <h4gnmr$8cl$1 at news.eternal-september.org>,

Post by Carl Banks
But please don't put it on the same level as PHP. Their situations
have almost nothing in common.

No, Python attracted programmers away from C++ because it's easier to
write good programs in it, in less time. There are plenty of expert C++
programmers who switched to Python; your thesis only applies to the
legions of people who found it difficult to learn C++ in the first place.

Moreover, AFAIK PHP never attracted people away from Python; Python was
not particularly popular when PHP was in its heyday. PHP attracted
people away from Perl and Java and C++.

I'm curious, do you actually know Python at all? Have you used it for a
serious project?

--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)"
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-03-22

Raffael Cavallaro

2009-07-26 13:31:06 UTC

Post by Aahz
There are plenty of expert C++
programmers who switched to Python;

"plenty" is an absolute term, not a relative term. I sincerely doubt
that the majority of python users were formerly *expert* C++
programmers.

Post by Aahz
your thesis only applies to the
legions of people who found it difficult to learn C++ in the first place.

No, my thesis applies to the overwhelming majority of programmers who
found it more difficult to *master* (i.e., not merely use) C++ as
opposed to mastering python. BTW, this is a *complement* not a dis;
python is a better language than C++ precisely because it is more
sensibly and elegantly designed than C++ and therefore easier to master.

php represents the same process but farther down the ladder, as it
were. There's often a tradeoff between ease of mastery and power.
python hits a sweet spot for many tasks and many programmers,
especially as compared to C++ (or even lisp, which though more powerful
than python is more difficult to master. lisp beats C++ on both counts
imho - more powerful *and* easier to master). php hits a sweet spot
only in a very restricted domain. Beyond that, it is clearly inferior
to python which has greater power, but is more difficult to master.

--
Raffael Cavallaro

Rhodri James

2009-07-26 22:32:30 UTC

On Sun, 26 Jul 2009 14:31:06 +0100, Raffael Cavallaro

Post by Aahz
There are plenty of expert C++
programmers who switched to Python;

"plenty" is an absolute term, not a relative term. I sincerely doubt
that the majority of python users were formerly *expert* C++ programmers.

Nitpicking like this doesn't help your case.

Post by Aahz
your thesis only applies to the
legions of people who found it difficult to learn C++ in the first place.

It is perhaps more accurate to say that Python was designed where C++
aggregated. C was fundamentally the wrong place to have started from,
making C++ (as distinct from the subset of C++ that is really C) harder
to learn, never mind master, than it really needed to be.

Post by Raffael Cavallaro
php represents the same process but farther down the ladder, as it were.
There's often a tradeoff between ease of mastery and power. python hits
a sweet spot for many tasks and many programmers, especially as compared
to C++ (or even lisp, which though more powerful than python is more
difficult to master. lisp beats C++ on both counts imho - more powerful
*and* easier to master). php hits a sweet spot only in a very restricted
domain. Beyond that, it is clearly inferior to python which has greater
power, but is more difficult to master.

Fundamentally incorrect. PHP attracted many people because of where it
lives in the web application structure -- the part of the language that
was thought about very hard. Beyond that there's nothing much to master,
so the whole ease vs power debate is rather pointless.

--
Rhodri James *-* Wildebeest Herder to the Masses

Andrew Reilly

2009-07-26 23:28:53 UTC

Post by Aahz
There are plenty of expert C++
programmers who switched to Python;

"plenty" is an absolute term, not a relative term. I sincerely doubt
that the majority of python users were formerly *expert* C++
programmers.

Post by Aahz
your thesis only applies to the
legions of people who found it difficult to learn C++ in the first place.

Isn't it widely accepted that the number of people who have mastered C++
is about five? All of the rest of us just struggle...

[I know enough of C++ to avoid it whenever I can, and to not use it for
my own projects. I'm happy with a mix of C, python and lisp(or scheme).]

--
Andrew

David Robinow

2009-07-26 19:26:46 UTC

This doesn't mean they're on the same level - in fact, if you read carefully
you'll see my original post said as much: python attracted average
programmers; php attracted mediocre programmers and even some
non-programmers, which means that php is clearly a lesser language than
python.

I'm a mediocre programmer. Does this mean I should switch to PHP?

MRAB

2009-07-26 20:59:42 UTC

Post by David Robinow

I'm a mediocre programmer. Does this mean I should switch to PHP?

If you're a mediocre programmer who knows you're mediocre, but wants to
improve and is willing to learn, then stick with Python. You'll get
better. :-)

David Robinow

2009-07-27 12:20:48 UTC

Post by David Robinow

Post by Raffael Cavallaro
This doesn't mean they're on the same level - in fact, if you read

carefully

Post by David Robinow

Post by Raffael Cavallaro
you'll see my original post said as much: python attracted average
programmers; php attracted mediocre programmers and even some
non-programmers, which means that php is clearly a lesser language than
python.

I'm a mediocre programmer. Does this mean I should switch to PHP?

If you're a mediocre programmer who knows you're mediocre, but wants to
improve and is willing to learn, then stick with Python. You'll get
better. :-)

I doubt it. I remember when Guido moved to the U.S. and I've even used
stdwin. I've actually gotten worse over the years. Old age does that.
Nevertheless, I question the idea that a language that is easy to use
(I don't know if PHP qualifies) is somehow inferior.

Hendrik van Rooyen

2009-07-27 09:05:06 UTC

Post by David Robinow
I'm a mediocre programmer. Does this mean I should switch to PHP?

I have searched, but I can find nothing about this mediocre language.

Could you tell us more?

- Hendrik

Aahz

2009-07-27 14:49:25 UTC

In article <mailman.3765.1248685391.8015.python-list at python.org>,

Post by David Robinow
I'm a mediocre programmer. Does this mean I should switch to PHP?

I have searched, but I can find nothing about this mediocre language.
Could you tell us more?

:-P

(For anyone who is confused by Hendrik's humor, he is saying that David
was referring to a programming language named "mediocre". English
grammar is confusing!)

--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/

"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer

David Smith

2009-07-27 15:14:15 UTC

Post by Aahz
In article <mailman.3765.1248685391.8015.python-list at python.org>,

Post by David Robinow
I'm a mediocre programmer. Does this mean I should switch to PHP?

I have searched, but I can find nothing about this mediocre language.
Could you tell us more?

:-P
(For anyone who is confused by Hendrik's humor, he is saying that David
was referring to a programming language named "mediocre". English
grammar is confusing!)

LOL ... I'm an American and that wasn't all that clear :-)

David Robinow

2009-07-27 23:07:06 UTC

Post by Aahz
In article <mailman.3765.1248685391.8015.python-list at python.org>,

?I'm a mediocre programmer. Does this mean I should switch to PHP?

I have searched, but I can find nothing about this mediocre language.
Could you tell us more?

(For anyone who is confused by Hendrik's humor, he is saying that David
was referring to a programming language named "mediocre". ?English
grammar is confusing!)

Well, Aahz, I think it rather rude to spoil the fun with your explanation.
Just for that, I'm not going to post any mediocre code. You'll have to
figure it out yourself.
(Q: should the name of my favorite language be capitalized?)

Hendrik van Rooyen

2009-07-28 08:35:48 UTC

Post by Aahz
In article <mailman.3765.1248685391.8015.python-list at python.org>,

Post by David Robinow
I'm a mediocre programmer. Does this mean I should switch to PHP?

I have searched, but I can find nothing about this mediocre language.
Could you tell us more?

:-P
(For anyone who is confused by Hendrik's humor, he is saying that David
was referring to a programming language named "mediocre". English
grammar is confusing!)

This is true - I intended, when I started the post, to make a crack about
how he knew that he was mediocre - If there were some exam or test
that you have to pass or fail to be able to make the claim to mediocrity.
I was imagining a sort of devil's rating scale for programmers, that
could cause one to say things like: "I am studying hard so that I can
get my mediocre certificate, and one day I hope to reach hacker rank".

And then the similarity to "I am a COBOL programmer" struck me,
and I abandoned the ratings.

- Hendrik

MRAB

2009-07-28 15:11:02 UTC

Post by Aahz
In article <mailman.3765.1248685391.8015.python-list at python.org>,

Post by David Robinow
I'm a mediocre programmer. Does this mean I should switch to PHP?

I have searched, but I can find nothing about this mediocre language.
Could you tell us more?

:-P
(For anyone who is confused by Hendrik's humor, he is saying that David
was referring to a programming language named "mediocre". English
grammar is confusing!)

This is true - I intended, when I started the post, to make a crack about
how he knew that he was mediocre - If there were some exam or test
that you have to pass or fail to be able to make the claim to mediocrity.
I was imagining a sort of devil's rating scale for programmers, that
could cause one to say things like: "I am studying hard so that I can
get my mediocre certificate, and one day I hope to reach hacker rank".
And then the similarity to "I am a COBOL programmer" struck me,
and I abandoned the ratings.

If you were a "COBOL" programmer, would you want to shout about it? :-)

Hendrik van Rooyen

2009-07-29 08:08:24 UTC

Post by MRAB
If you were a "COBOL" programmer, would you want to shout about it? :-)

Hey don't knock it! - at the time, it was either COBOL or FORTRAN
or some assembler or coding in hex or octal.

And if code is data, where is Pythons ALTER statement?

*Ducks*

:-) Hendrik

greg

2009-07-30 01:09:14 UTC

Post by Hendrik van Rooyen
And if code is data, where is Pythons ALTER statement?

class Duck:

def quack(self):
print "Quack!"

def moo():
print "Moo!"

def ALTER(obj, name, TO_PROCEED_TO):
setattr(obj, name, TO_PROCEED_TO)

d = Duck()
ALTER(d, 'quack', TO_PROCEED_TO = moo)
d.quack()

--
Greg

Hendrik van Rooyen

2009-07-31 08:18:15 UTC

Post by greg

Post by Hendrik van Rooyen
And if code is data, where is Pythons ALTER statement?

print "Quack!"
print "Moo!"
setattr(obj, name, TO_PROCEED_TO)
d = Duck()
ALTER(d, 'quack', TO_PROCEED_TO = moo)
d.quack()

Nice, and I really appreciate the Duck,
but (there is always a but):

1) That is a function, not a statement.

2) The original changed a jump target address from
one address to another, and did not need the
heavy machinery of object oriented code.

So what you are doing is not quite the same.

It is actually not really needed in python, as
one can pass functions around, so that you can
call different things instead of jumping to them:

thing_to_call = moo
thing_to_call()

Does the equivalent without user level OO.

The original ALTER statement found use in building
fast state machines, where the next thing to do was
set up by the current state. In python one simply returns
the next state.

The equivalent python code is easier to read as it is
obvious what is happening - The COBOL source was
more obscure, as any jump could have been altered,
and you could not see that until you have read further
on in the program, where the ALTER statement was.

- Hendrik

greg

2009-07-31 09:02:08 UTC

Post by Hendrik van Rooyen
The COBOL source was
more obscure, as any jump could have been altered,
and you could not see that until you have read further
on in the program, where the ALTER statement was.

Well, in Python you can pretty much replace any
function with any other function, so you can
obfuscate things just as much if you really want!

--
Greg

magicus

2009-07-28 21:25:09 UTC

On Tue, 28 Jul 2009 16:11:02 +0100, MRAB <python at mrabarnett.plus.com>

Post by Aahz
In article <mailman.3765.1248685391.8015.python-list at python.org>,

Post by David Robinow
I'm a mediocre programmer. Does this mean I should switch to PHP?

I have searched, but I can find nothing about this mediocre language.
Could you tell us more?

:-P
(For anyone who is confused by Hendrik's humor, he is saying that
David was referring to a programming language named "mediocre".
English grammar is confusing!)

This is true - I intended, when I started the post, to make a crack
about how he knew that he was mediocre - If there were some exam or
test that you have to pass or fail to be able to make the claim to
mediocrity. I was imagining a sort of devil's rating scale for
programmers, that could cause one to say things like: "I am studying
hard so that I can get my mediocre certificate, and one day I hope to
reach hacker rank".
And then the similarity to "I am a COBOL programmer" struck me, and I
abandoned the ratings.

If you were a "COBOL" programmer, would you want to shout about it? :-)

The last time I wrote anything in COBOL was sometime in the early 80s.
Somehow that makes me feel good, heh.

ciao,
f

--
?Using words to describe magic is like using a screwdriver to cut roast
beef.?
-- Tom Robbins

MRAB

2009-07-28 22:22:29 UTC

Post by magicus
On Tue, 28 Jul 2009 16:11:02 +0100, MRAB <python at mrabarnett.plus.com>

Post by Aahz
In article <mailman.3765.1248685391.8015.python-list at python.org>,

Post by David Robinow
I'm a mediocre programmer. Does this mean I should switch to PHP?

I have searched, but I can find nothing about this mediocre language.
Could you tell us more?

:-P
(For anyone who is confused by Hendrik's humor, he is saying that
David was referring to a programming language named "mediocre".
English grammar is confusing!)

This is true - I intended, when I started the post, to make a crack
about how he knew that he was mediocre - If there were some exam or
test that you have to pass or fail to be able to make the claim to
mediocrity. I was imagining a sort of devil's rating scale for
programmers, that could cause one to say things like: "I am studying
hard so that I can get my mediocre certificate, and one day I hope to
reach hacker rank".
And then the similarity to "I am a COBOL programmer" struck me, and I
abandoned the ratings.

If you were a "COBOL" programmer, would you want to shout about it? :-)

The last time I wrote anything in COBOL was sometime in the early 80s.
Somehow that makes me feel good, heh.

COBOL: it feels good when you stop. :-)

(I was actually referring to the convention of all capitals representing
shouting.)

magicus

2009-07-28 22:26:28 UTC

On Tue, 28 Jul 2009 23:22:29 +0100, MRAB <python at mrabarnett.plus.com>

Post by magicus
On Tue, 28 Jul 2009 16:11:02 +0100, MRAB <python at mrabarnett.plus.com>

Post by Aahz
In article <mailman.3765.1248685391.8015.python-list at python.org>,

Post by David Robinow
I'm a mediocre programmer. Does this mean I should switch to PHP?

I have searched, but I can find nothing about this mediocre language.
Could you tell us more?

:-P
(For anyone who is confused by Hendrik's humor, he is saying that
David was referring to a programming language named "mediocre".
English grammar is confusing!)

This is true - I intended, when I started the post, to make a crack
about how he knew that he was mediocre - If there were some exam or
test that you have to pass or fail to be able to make the claim to
mediocrity. I was imagining a sort of devil's rating scale for
programmers, that could cause one to say things like: "I am studying
hard so that I can get my mediocre certificate, and one day I hope to
reach hacker rank".
And then the similarity to "I am a COBOL programmer" struck me, and I
abandoned the ratings.

If you were a "COBOL" programmer, would you want to shout about it? :-)

The last time I wrote anything in COBOL was sometime in the early 80s.
Somehow that makes me feel good, heh.

COBOL: it feels good when you stop. :-)

It certainly does!

Post by MRAB
(I was actually referring to the convention of all capitals representing
shouting.)

I rarely shout and I thought that to this day it was still referred to as
COBOL. I am still glad that I never pursued a career in dealing w/ such a
language.

ciao,
f

--
"What you resist, persists."

Roy Smith

2009-07-26 21:04:23 UTC

In article <h4gnmr$8cl$1 at news.eternal-september.org>,
Raffael Cavallaro <raffaelcavallaro at pas.espam.s.il.vous.plait.mac.com>

php is clearly a lesser language than python.

I'm as much of a Python bigot as anybody. Likewise, I put down php for all
the sorts of theoretical reasons people have been putting it down. Not to
mention that it looks like Perl, which is enough to make anybody go
screaming in the other direction.

However, it's hard to argue with success. A ton of very useful software
has been written in php (including MediaWiki, which drives Wikipedia). One
needs to have a very highly developed sense of theoretical purity to look
down their noses at the language that drives one of the highest volume web
sites on the planet.

Raffael Cavallaro

2009-07-26 21:41:31 UTC