Is python very slow compared to C

[diffuser78]

I have just started to learn python. Some said that its slow. Can
somebody pin point the issue.

Thans

[rtilley]

di********@gmail.com wrote:

I have just started to learn python. Some said that its slow. Can
somebody pin point the issue.

It depends on what you are doing. Much of Python is just wrapped C. So
many things are very fast.

[Robert Hicks]

Most languages are slow compared to "C". Python is fast enough for just
about anything you want to do with it.

Robert

[bearophileHUGS]

Yes this language is very slow, but frequently this isn't a problem,
because you are using fast functions/libraries written in C, or you are
doing I/O bound operations. And Psyco, numeric/numarray, ShedSkin can
help in some other cases (Pyrex and other solutions allow you to mix in
lower level languages). If you are looking for pure algorithmic speed
you probably have to go look for other languages, like C, C++, Ocaml,
typed Lisp code, etc.

Bye,
bearophile

[Larry Bates]

di********@gmail.com wrote:

I have just started to learn python. Some said that its slow. Can
somebody pin point the issue.

Thans

"Some" doesn't know what he/she/they are talking about.
Generalizations like that upset me because it shows someone
that has some predisposition to some other language and they
don't want to be confused by "facts". Many "compiled
language" programmers fall into this category. Many times
you can write, debug, execute, and document a Python program
before "compiled language" guys can even get started. Many
believe that Python is also more maintainable over time.
When you come back to it in 6 months you will ACTUALLY BE ABLE
TO READ THE CODE. Productivity cannot be measured by
benchmarks alone.

Give Python a try and I'll bet you find that it is fast enough
(that's all that is important right) for all but device
drivers and highly scientific applications (and even then
there are solutions). The parts of Python that need to be
fast have been rewritten as binary libraries. That way you
get the best of both worlds: high level language that has
fast libraries when required.

-Larry Bates

[Michael Tobis]

Experienced programmers learning Python should read this:

http://effbot.org/zone/python-objects.htm

Try to understand the advantages of this approach, and understand its
costs.

Essentially, everything you do in Python (or related languages)
involves resolving a name. Sometimes the number of dictionary look-ups
(name dereferences) required to do anything is very expensive in
runtime performance.

If your code is not compute-bound (as most codes are not; these days
communication-bound or limited by database performance are more common)
the increase in your own performance will be much more important. If
your code does do so much computing (as mine do) that performance
matters, you may still find Python useful, but it is less of a
slam-dunk.

mt

[Steven D'Aprano]

On Sat, 11 Feb 2006 12:49:32 -0800, diffuser78 wrote:

I have just started to learn python. Some said that its slow.
No, you can learn the basics of Python is only a few hours, and become
very proficient at it in days or weeks. It is much faster to learn Python
than to learn C.
Can somebody pin point the issue.

What is slow? Slow compared to what? Would you prefer to spend three days
writing a program that will run in twenty milliseconds, or three hours
writing the same program which runs in eighty milliseconds? Is the
computer's execution time more important than your development time? If
the computer's time is more valuable than your time, then you should be
writing in assembly language.

Python helps you write shorter code with fewer bugs, much quicker, than C.
If you discover a specific problem that runs too slow in Python, it is
possible to write a C extension to solve that specific problem, while
still having all the other advantages of Python.
--
Steven.

[Steven D'Aprano]

On Sat, 11 Feb 2006 13:52:03 -0800, bearophileHUGS wrote:

Yes this language is very slow,

Very slow to do what, compared to what? The decay time of the tau meson?

Slowness is not an absolute quantity. Slowness is relative, and comments
like "Python is very slow" just reinforces the meme that execution speed
is the only important factor -- even if you follow up with a good (and
correct) description of why raw CPU speed is rarely an issue, it is too
late, you've reinforced the meme "only C is good".

I would challenge the assertion that *any* serious modern language is
"very slow" on modern hardware in any meaningful sense. There are plenty
of *specific tasks* which are too slow when written in one language or
another, but that's not the same thing.
--
Steven.

[bearophileHUGS]

Steven D'Aprano>Very slow to do what, compared to what? The decay time
of the tau meson?<

Probably every answer I can give you is wrong for you, so answering is
almost useless... In this thread we have already given the most
pertinent answers to the original question from Diffuse.
I can show you this page, but I think this is useless too for you:
http://shootout.alioth.debian.org/gp...on&lang2=ocaml

And, by the way, this is false:
Robert Hicks>Python is fast enough for just about anything you want to
do with it.<

If you are on a Unix-like OS, then the page about Weave from SciPy can
show you that sometimes Python isn't quick enough.

Bye,
bearophile

[bonono]

be************@lycos.com wrote:

Steven D'Aprano>Very slow to do what, compared to what? The decay time
of the tau meson?<

Probably every answer I can give you is wrong for you, so answering is
almost useless... In this thread we have already given the most
pertinent answers to the original question from Diffuse.
I can show you this page, but I think this is useless too for you:
http://shootout.alioth.debian.org/gp...on&lang2=ocaml

This is even more interesting:

http://shootout.alioth.debian.org/gp...thon&lang2=lua

However, to me, the strength of python is the batteries that is
included(and there are more and more coming).

[Felipe Almeida Lessa]

Em Dom, 2006-02-12 Ã*s 03:03 -0800, be************@lycos.com escreveu:

Probably every answer I can give you is wrong for you, so answering is
almost useless... In this thread we have already given the most
pertinent answers to the original question from Diffuse.
I can show you this page, but I think this is useless too for you:
http://shootout.alioth.debian.org/gp...on&lang2=ocaml

What they were saying is that at most of the times your program is going
to sit and wait for things like network, hard drive, user input, etc.,
and these cannot be changed by any language. Those benchmarks test only
raw CPU performance.

Yes, sometimes you *need* raw CPU power, but nobody said that in this
case Python is good for you. Python is good at making your life as a
programmer easier, and every Python programmer knows that.

I wanted to see PyRex or C modules versions of that benchmarks, it would
be really nice. This is the approach used to create fast CPU-bound
algorithms in Python, and as such should be tested as thoroughly as
those Python-only counterparts.

And if it matters for you: Google says Python is fast for them, what
else do you want?

Cya,
Felipe.

--
"Quem excele em empregar a força militar subjulga os exércitos dos
outros povos sem travar batalha, toma cidades fortificadas dos outros
povos sem as atacar e destrói os estados dos outros povos sem lutas
prolongadas. Deve lutar sob o Céu com o propósito primordial da
'preservação'. Desse modo suas armas não se embotarão, e os ganhos
poderão ser preservados. Essa é a estratégia para planejar ofensivas."

-- Sun Tzu, em "A arte da guerra"

[Jarek Zgoda]

di********@gmail.com napisa³(a):

I have just started to learn python. Some said that its slow. Can
somebody pin point the issue.

So what? If you want fast code, go with assembly.

--
Jarek Zgoda
http://jpa.berlios.de/

[Felipe Almeida Lessa]

Em Dom, 2006-02-12 Ã*s 03:20 -0800, bo****@gmail.com escreveu:

However, to me, the strength of python is the batteries that is
included(and there are more and more coming).

So .NET is as good as Python? Hmmm... I think the language itself is the
best part of Python, its library is just a complement (a very good and
relevant one, though).

--
"Quem excele em empregar a força militar subjulga os exércitos dos
outros povos sem travar batalha, toma cidades fortificadas dos outros
povos sem as atacar e destrói os estados dos outros povos sem lutas
prolongadas. Deve lutar sob o Céu com o propósito primordial da
'preservação'. Desse modo suas armas não se embotarão, e os ganhos
poderão ser preservados. Essa é a estratégia para planejar ofensivas."

-- Sun Tzu, em "A arte da guerra"

[bonono]

Felipe Almeida Lessa wrote:

Em Dom, 2006-02-12 às 03:20 -0800, bo****@gmail.com escreveu:

However, to me, the strength of python is the batteries that is
included(and there are more and more coming).

So .NET is as good as Python? Hmmm... I think the language itself is the
best part of Python, its library is just a complement (a very good and
relevant one, though).

..NET is not a language, IMO.

[Luis M. González]

Steven D'Aprano wrote:

What is slow? Slow compared to what? Would you prefer to spend three days
writing a program that will run in twenty milliseconds, or three hours
writing the same program which runs in eighty milliseconds? Is the
computer's execution time more important than your development time? If
the computer's time is more valuable than your time, then you should be
writing in assembly language.

Python helps you write shorter code with fewer bugs, much quicker, than C.
If you discover a specific problem that runs too slow in Python, it is
possible to write a C extension to solve that specific problem, while
still having all the other advantages of Python.

You are right, we all know that, but I think the person who asked this
question doesn't want to hear a sales pitch. He asked a very specific
question regarding execution speed.

[Felipe Almeida Lessa]

Em Dom, 2006-02-12 Ã*s 04:33 -0800, bo****@gmail.com escreveu:

Felipe Almeida Lessa wrote:

Em Dom, 2006-02-12 Ã*s 03:20 -0800, bo****@gmail.com escreveu:

However, to me, the strength of python is the batteries that is
included(and there are more and more coming).

So .NET is as good as Python? Hmmm... I think the language itself is the
best part of Python, its library is just a complement (a very good and
relevant one, though).

.NET is not a language, IMO.

You talked about "batteries included", and that isn't related to the
language. I said .NET in reference to what you said. The part about the
language is my own opinion, I just didn't want to say anything about C#,
Boo, J#, Nemerle or any other language that targets the .NET framework.
In the case of Python, as well as Java, the language has the same name
as the framework, and this may have lead you to mistake me.

--
"Quem excele em empregar a força militar subjulga os exércitos dos
outros povos sem travar batalha, toma cidades fortificadas dos outros
povos sem as atacar e destrói os estados dos outros povos sem lutas
prolongadas. Deve lutar sob o Céu com o propósito primordial da
'preservação'. Desse modo suas armas não se embotarão, e os ganhos
poderão ser preservados. Essa é a estratégia para planejar ofensivas."

-- Sun Tzu, em "A arte da guerra"

[Björn Lindström]

Felipe Almeida Lessa <fe**********@gmail.com>:

In the case of Python, as well as Java, the language has the same
name as the framework, and this may have lead you to mistake me.

Not really, in either case. There's Python for both .NET and for the
Java VM.

--
Björn Lindström <bk**@stp.lingfil.uu.se>
Student of computational linguistics, Uppsala University, Sweden

[Steven D'Aprano]

On Sun, 12 Feb 2006 03:03:20 -0800, bearophileHUGS wrote:

Steven D'Aprano>Very slow to do what, compared to what? The decay time
of the tau meson?<

Probably every answer I can give you is wrong for you, so answering is
almost useless...

We do actually agree. You did explain why the speed of the language itself
is rarely the critical factor. My criticism is that whatever good your
post would have done was nullified by your opening comment stating that
Python is very slow -- a comment which I think is not only harmful, but
wrong, benchmarks like the one you linked to not withstanding.

I think it is wrong to call Python "very slow" just because it is slower
than some other language or languages, for the same reason it would be
wrong to describe the population of the UK as "very low" because 60
million people is a smaller number than China or India's one billion plus.
Doing so merely reinforces the premature optimizer's message that any
language that isn't C (and sometimes Lisp) is "not fast enough".

The benchmark you pointed to are of limited use for application
developers. (Their value to language designers is another story.) Given
that Ocaml is (say) 200 times faster than Python on average, it tells the
application developer virtually nothing about the performance of his
application. And that's what user's care about -- they couldn't care less
about binary trees or partial sums, they care about how long it takes to
render a JPEG, open an email, save their files, query the database,
display a window, and so forth. Few application level tasks are limited by
the speed of the language, not these days.

You don't believe me? Consider the following:

When you drag your mouse over text in a graphical text editor, the text
highlights. How much money would you be prepared to pay to make that
highlighting occur 200 times faster? $100? $1? One cent? Chances are you
wouldn't pay a thing, because it is already fast enough, and making it
faster is of zero value to you -- even if highlighting ten gigabytes of
text might be uncomfortably slow.

What about opening an email? How much would you pay to reduce the time it
takes to open and display an email from a hundredth of a second to
virtually instantaneously? I suggest that most people would consider 0.01s
to already be be "virtually instantaneously".

The important question isn't "is Python fast or slow?", it is "is Python
fast enough?". That's a question that doesn't have a simple answer,
because it depends. Fast enough to do what?

But, in general, more often than not, Python is fast enough. The extra
value of using something like Lua or Ocaml or even C is just not enough to
make up for the disadvantages of using those languages.

Of course Python isn't always fast enough. Please don't waste your time
coming up with practical examples where pure Python is objectively too
slow for a certain task, because you won't be telling me anything I don't
already know.

But the developer doesn't have to write pure Python, he can call a module
written in C, or change the algorithm, or find another way to accomplish
the same end result. Or even decide that for this specific task, Python is
not the language to use. These are all good solutions, but they don't mean
that Python is "very slow" in general. Even C is not always fast enough,
but we wouldn't say C is "very slow" just because it can't calculate the
first million Mersenne Primes in twenty milliseconds.
--
Steven.

[Steven D'Aprano]

On Sun, 12 Feb 2006 05:31:28 -0800, =?iso-8859-1?q?Luis_M._Gonz=E1lez?=
wrote:

You are right, we all know that, but I think the person who asked this
question doesn't want to hear a sales pitch. He asked a very specific
question regarding execution speed.

Read his post again. He didn't ask a specific question at all, and he
certainly didn't mention execution speed. He asked a vague, meaningless
question about whether Python was "slow compared to C".

Slow to learn? No, Python is easier to learn than C.

Slow to compile? No, Python handles compiling to byte-code transparently,
you will rarely even notice it.

Slow to debug? That depends on the nature of the bug, but generally no.
It is much easier to write correct code the first time in Python than in
C, and even if the code isn't correct, Python makes it easier (and
therefore faster) to debug it.

Slow to execute? No, for many common tasks execution speed is either fast
enough regardless of the language, or it is limited by things like user
input, I/O, memory or other factors independent of the language the code
is written in.

If the task is limited by the CPU and not I/O etc., pure Python code with
no C extensions or Psycho optimizations might be slower than C code, but
that tells us virtually nothing about whether it is too slow. After all,
my car is slower than a F-11 fighter plane, but my car is plenty fast
enough for driving to the shop and back, and a car is a far more practical
solution to the task even though a F-11 would be faster.

--
Steven.

[bonono]

Steven D'Aprano wrote:

But, in general, more often than not, Python is fast enough. The extra
value of using something like Lua or Ocaml or even C is just not enough to
make up for the disadvantages of using those languages.

What is the disavantage of Lua comparing with Python ? Or Ocaml
comparing with Python ?

[Cameron Laird]

In article <11*********************@g43g2000cwa.googlegroups. com>,
Luis M. González <lu*****@gmail.com> wrote:

[Steven D'Aprano]

On Sun, 12 Feb 2006 06:20:10 -0800, bonono wrote:

Steven D'Aprano wrote:

But, in general, more often than not, Python is fast enough. The extra
value of using something like Lua or Ocaml or even C is just not enough to
make up for the disadvantages of using those languages.

What is the disavantage of Lua comparing with Python ? Or Ocaml
comparing with Python ?

If your developer gets hit by a bus, you won't easily find a replacement.
This may not be a factor if you are programming for pleasure, but in the
commercial world of software development, availability of skilled
programmers is absolutely critical for the use of a language.

I realise that neither Lua nor Ocaml are entirely unknowns, both have been
used commercially, but I believe Python developers are more widely
available.

Google "python programming": 19,000,000 hits.
Google "lua programming": 574,000 hits.
Google "ocaml programming": 325,000 hits.

That will give you a rough estimate for the amount of resources out there
on the web for each language. By comparison, even Forth gives 13 million
plus hits, and who uses Forth?

Another rough measure of the availability of resources is the Dummies test:

Google "python for dummies": 323,000 hits.
Google "lua for dummies": 46,400 hits.
Google "ocaml for dummies": 693 hits.

Only Python For Dummies is an actual dead-tree book. I think it is safe to
conclude that Lua and Ocaml offer far fewer resources for somebody looking
to learn the language than does Python.

Lua appears to be *too* lightweight, without even classes or inheritance,
and a single data type where Python has dicts, sets, tuples and lists.

Ocaml seems to use more punctuation than I'm comfortable with (lots of
double semi-colons and -> symbols), but Python seems to be moving along
those lines too with list and generator comprehensions, and none of us
really want to return to Cobol's verbose arithmetic.

Wikipedia says "However, [Ocaml] also forces the programmer to conform to
the constraints of the type system, which can require careful thought and
close attention. ... effective use of OCaml's type system can require some
sophistication on the part of the programmer." That suggests that writing
Ocaml code may be more difficult than writing Python code. Wikipedia also
emphasises how hard it is for the compiler to generate good quality
machine code from Ocaml, which suggests that perhaps the compilation stage
could be slow.
--
Steven.

[bonono]

Steven D'Aprano wrote:

Lua appears to be *too* lightweight, without even classes or inheritance,
and a single data type where Python has dicts, sets, tuples and lists.

I believe Lua does have features to implement class/inheritance.

As for the distinction of dict/set/tuple/list or one single table data
type(which can be used as either dict or list and implemented as set,
not sure about tuple), it is up to debate.

Though I have mentioned in another post that the batteries in Python is
extremely appealing to solve real world problems as no matter how good
a language can be, re-implementing something from scratch is always a
pain(and error prone).

[diffuser78]

Thnaks everybody for their comments. I am an average programmer in C
and wanted to make a hop to python and was just trying to clear my mind
with the confusions. Bit I guess I will go ahead and spend some time
with python and do my next project in python.
thanks for the feedback

[PA]

On Feb 12, 2006, at 16:11, Steven D'Aprano wrote:

availability of skilled programmers is absolutely critical for the use
of a language.
By that measure, we should all be using Java, no?

"TIOBE Programming Community Index"
http://www.tiobe.com/tpci.htm
By comparison, even Forth gives 13 million plus hits, and who uses
Forth?
Anyone writing in English:

http://www.answers.com/forth&r=67
Lua appears to be *too* lightweight, without even classes or
inheritance,
Programming in Lua
Object-Oriented Programming
http://www.lua.org/pil/16.html
and a single data type where Python has dicts, sets, tuples and lists.

"Lua gives you the power; you build the mechanisms."
-- Roberto Ierusalimschy, "Programming in Lua", December 2003
http://www.lua.org/pil/12.1.2.html

Cheers

--
PA, Onnay Equitursay
http://alt.textdrive.com/

[Cameron Laird]

In article <pa****************************@REMOVETHIScyber.co m.au>,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

[Steven D'Aprano]

On Sun, 12 Feb 2006 17:44:50 +0100, PA wrote:

On Feb 12, 2006, at 16:11, Steven D'Aprano wrote:

availability of skilled programmers is absolutely critical for the use
of a language.
By that measure, we should all be using Java, no?

I said nothing about whether Lua or Ocaml were good languages to take up
if you want to learn a programming language. In fact, it follows from
simple economics that individual developers should avoid languages that
are too popular. No matter how good you are as a Visual Basic programmer,
the price you can command will be pushed downwards by competition with
millions of other VB programmers.

I was talking about the other side of the equation. If you are hiring
developers to work for you, it is absolutely critical that there is no
shortage of skillful programmers in the language(s) you use. "No shortage"
doesn't mean "only use Java" -- there are disadvantages to Java that
outweigh the fact that there is no shortage of developers.

"TIOBE Programming Community Index"
http://www.tiobe.com/tpci.htm

By comparison, even Forth gives 13 million plus hits, and who uses
Forth?

Anyone writing in English:

http://www.answers.com/forth&r=67

Which might be relevant if I searched for "forth", but I didn't. I googled
on "forth programming". Yes, there will be some false positives, but I
never claimed that this was anything more than a rough and imprecise
estimate of the availability of resources for the languages.

Lua appears to be *too* lightweight, without even classes or
inheritance,

Programming in Lua
Object-Oriented Programming
http://www.lua.org/pil/16.html

Did you actually bother to read the page you linked to? It describes how
you can emulate object-like behaviour for Lua tables. The following page
is even more explicit: "Lua does not have the concept of class".

That means that the object-oriented framework, which you get for free in
Python, has to be at least partially handled by the programmer in Lua.
Perhaps Lua makes it easy to do, but it is still something that doesn't
need to be done in Python because it is already there.

and a single data type where Python has dicts, sets, tuples and lists.

"Lua gives you the power; you build the mechanisms."
-- Roberto Ierusalimschy, "Programming in Lua", December 2003
http://www.lua.org/pil/12.1.2.html

Which is fine, but the more mechanisms you have to build, the longer it
will take you to actually get to the important work, which is putting it
all together to create your application.

--
Steven.

[Steven D'Aprano]

On Sun, 12 Feb 2006 17:08:02 +0000, Cameron Laird wrote:

In article <pa****************************@REMOVETHIScyber.co m.au>,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
.
.
.

on the web for each language. By comparison, even Forth gives 13 million
plus hits, and who uses Forth?

.
.
.
The programmers of, among other things, the FedEx bar-code reader,
the Sun boot loader, and parts of the Space Shuttle.

Okay, so that's three... *wink*

You missed Apple's boot loader.

I love Forth. I'm no good at thinking at that low count-the-bytes level,
but if I was, I'd much prefer to use Forth than C or assembly. I've got a
bunch of Forth books here, and when I'm bored I read them for
entertainment, and dream. I love the fact that Forth is still in use. But
I'm under no illusions that there are millions of Forth developers getting
paid to write in Forth.

--
Steven.

[PA]

On Feb 12, 2006, at 18:18, Steven D'Aprano wrote:

Did you actually bother to read the page you linked to?

I did 8^)

"Lua — Story of O"
http://alt.textdrive.com/lua/19/lua-story-of-o

Cheers

--
PA, Onnay Equitursay
http://alt.textdrive.com/

[Roy Smith]

Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

I love Forth. I'm no good at thinking at that low count-the-bytes level,
but if I was, I'd much prefer to use Forth than C or assembly. I've got a
bunch of Forth books here, and when I'm bored I read them for
entertainment, and dream. I love the fact that Forth is still in use. But
I'm under no illusions that there are millions of Forth developers getting
paid to write in Forth.

If you like Forth, take a look at PostScript. Most people think of
PostScript as a print file format and don't realize it's a real programming
language. Variables, functions, loops, if statements, and all that good
stuff. The syntax is very Forth-like.

[skip]

Roy> If you like Forth, take a look at PostScript.

I miss NeWS... :-(

Skip

[Michael Tobis]

> Read his post again. He didn't ask a specific question at all, and he certainly didn't mention execution speed.

agreed

He asked a vague, meaningless question about whether Python was "slow compared to C".

No, that is both wrong and gratuitously harsh. He had heard vague
meaningless complaints about whether Python was "slow compared to C"
and asked us to "pinpoint the issue", i.e., to determine in what sense
the allegation might be true. That is a precise and meaningful question
and being asked in a commendable fashion.

mt

[malv]

That's why Microsoft is bringing IronPython on board to have something
more decent available with .NET

[Daniel Ciesinger]

Steven D'Aprano schrieb:

On Sun, 12 Feb 2006 17:08:02 +0000, Cameron Laird wrote:

In article <pa****************************@REMOVETHIScyber.co m.au>,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

on the web for each language. By comparison, even Forth gives 13 million
plus hits, and who uses Forth?

13m hits for forth as in "set forth", "firth of forth" etc.
..The programmers of, among other things, the FedEx bar-code reader,
the Sun boot loader, and parts of the Space Shuttle.
You missed Apple's boot loader.

And LOTs of small tools, scripts, analyzers written in Forth, because it
has such a nice "evaluate", beating e.g. JavaScript "evaluate" by a
speed advantage around 1000 or more...
You can feed that with a datastream such as

123.50 MONITOR Rx 03 DC 0A 0D
124.00 COMMS Tx 01 A5

....and convert such stuff into XML, SVG or any representation you like.
Very useful (and fast) e.g. for automotive applications.
I love Forth. I'm no good at thinking at that low count-the-bytes level,
but if I was, I'd much prefer to use Forth than C or assembly. I've got a
bunch of Forth books here, and when I'm bored I read them for
entertainment, and dream. I love the fact that Forth is still in use. But
I'm under no illusions that there are millions of Forth developers getting
paid to write in Forth.

Maybe a few hundred - and then some thousands who write their utils in
Forth during their paid time...

Daniel

[bonono]

Steven D'Aprano wrote:

Programming in Lua
Object-Oriented Programming
http://www.lua.org/pil/16.html

Did you actually bother to read the page you linked to? It describes how
you can emulate object-like behaviour for Lua tables. The following page
is even more explicit: "Lua does not have the concept of class".

That means that the object-oriented framework, which you get for free in
Python, has to be at least partially handled by the programmer in Lua.
Perhaps Lua makes it easy to do, but it is still something that doesn't
need to be done in Python because it is already there.

Lua does not have a concept of class doesn't mean it doesn't have the
concept/framework of OO. It seems to be using a prototype based OO
framework similar to javascript. So one can have features like
inheritance without "class".

I can speak the same about Python if I view it from a prototype based
perspective, where one get them for free in Lua but need to implement
them in Python.

[Elizabeth D Rather]

"Cameron Laird" <cl****@lairds.us> wrote in message
news:1v************@lairds.us...

In article <pa****************************@REMOVETHIScyber.co m.au>,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
.
.
.

on the web for each language. By comparison, even Forth gives 13 million
plus hits, and who uses Forth?

.
.
.
The programmers of, among other things, the FedEx bar-code reader,
the Sun boot loader, and parts of the Space Shuttle.

We have several thousand customers, although we don't hear from them enough
to know how active they are. Most of them are doing embedded systems (such
as the FedEx package tracker), although there are also quite a few doing
Windows apps.

A lot of our embedded work is for aerospace and government customers, plus a
number in the private sector. All the DirecTV uplink antennas are
controlled by one of our systems made by VertexRSI,
http://www.tripointglobal.com/vertexrsi.html. Another really neat customer
is Sunrise Systems, http://www.sunrisesystems.com/index.htm. They make
moving displays, and are working on one for one of the rebuilt World Trade
Center bldgs, one to be installed in Switzerland next month, and something
for Disney World.

Open Firmware has already been mentioned, and I should add that IBM's
high-end servers also use it. I teach Forth courses there once or twice a
year, and have trained a couple hundred engineers in IBM alone.

You can get more info on our web site www.forth.com, including a link to a
paper presenting a history of Forth.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. [phone]
5155 W. Rosecrans Ave. #1018 Fax: [phone]
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Steven D'Aprano]

bo****@gmail.com wrote:

I can speak the same about Python if I view it from a prototype based
perspective, where one get them for free in Lua but need to implement
them in Python.

Sure. And if you need prototypes, then all else being
equal that would be a disadvantage of Python compared
to Lua.

On the other hand, I'd suggest that far more
programmers are familiar with classes than prototypes,
regardless of any objective advantages or disadvantages
of one over the other. Perhaps that's one of the
reasons why Lua is lacking the market penetration of
Python: programmers may look at it and say "No classes?
Prototyping? WTF is that? I don't have time to learn
something so different, better stick to languages which
have a smaller learning curve."

--
Steven.

[Steve Holden]

Steven D'Aprano wrote:

bo****@gmail.com wrote:

I can speak the same about Python if I view it from a prototype based
perspective, where one get them for free in Lua but need to implement
them in Python.

Sure. And if you need prototypes, then all else being
equal that would be a disadvantage of Python compared
to Lua.

On the other hand, I'd suggest that far more
programmers are familiar with classes than prototypes,
regardless of any objective advantages or disadvantages
of one over the other. Perhaps that's one of the
reasons why Lua is lacking the market penetration of
Python: programmers may look at it and say "No classes?
Prototyping? WTF is that? I don't have time to learn
something so different, better stick to languages which
have a smaller learning curve."

Or perhaps they'll see that Self demonstrated the advantages and
disadvantages of the prototyping approach long ago.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[bonono]

Steven D'Aprano wrote:

bo****@gmail.com wrote:

I can speak the same about Python if I view it from a prototype based
perspective, where one get them for free in Lua but need to implement
them in Python.

Sure. And if you need prototypes, then all else being
equal that would be a disadvantage of Python compared
to Lua.

On the other hand, I'd suggest that far more
programmers are familiar with classes than prototypes,
regardless of any objective advantages or disadvantages
of one over the other. Perhaps that's one of the
reasons why Lua is lacking the market penetration of
Python: programmers may look at it and say "No classes?
Prototyping? WTF is that? I don't have time to learn
something so different, better stick to languages which
have a smaller learning curve."

The "=" operator in Python is also quite different from many language
people had experience like C or VB etc. And using the same argument,
everyone may still be programming in COBOL now.

And if we use market penetration as measure, Perl seems to be easier
for people ?

[PA]

On Feb 13, 2006, at 06:44, bo****@gmail.com wrote:

And if we use market penetration as measure, Perl seems to be easier
for people ?

Perl: Shell scripts/awk/sed are not enough like programming languages.

Python: Perl is a kludge.

"What Languages Fix"
http://www.paulgraham.com/fix.html

Cheers

--
PA, Onnay Equitursay
http://alt.textdrive.com/

[bonono]

PA wrote:

On Feb 13, 2006, at 06:44, bo****@gmail.com wrote:

And if we use market penetration as measure, Perl seems to be easier
for people ?

Perl: Shell scripts/awk/sed are not enough like programming languages.

Python: Perl is a kludge.

"What Languages Fix"
http://www.paulgraham.com/fix.html

Cheers

Where is the entry for Lua and Haskell, both I found very interesting.

[Peter Hansen]

PA wrote:

On Feb 13, 2006, at 06:44, bo****@gmail.com wrote:

And if we use market penetration as measure, Perl seems to be easier
for people ?

Perl: Shell scripts/awk/sed are not enough like programming languages.

Python: Perl is a kludge.

"What Languages Fix"
http://www.paulgraham.com/fix.html

Cute. He's missing Assembly language though:

Assembly language: My fingers are numb.

;-)

[Alex Martelli]

<bo****@gmail.com> wrote:
...

The "=" operator in Python
....doesn't exist, since '=' is not an operator in Python (just like it
isn't, say, in VB). But, OK, you mean "assignment".
is also quite different from many language
people had experience like C
Yes, but quite similar to assignment in Java, which is apparently the
most widely taught language nowadays.
or VB
Not really, because VB had TWO assignment verbs: LET (assignment as a
copy) and SET (assignment by reference, like Java and Python). The past
"had" is important, because VB today has (among many other changes,
which overall bring its semantics much closer to what Python all along)
sort of revolutionized the area of assignment... while hiding the big
differences under syntax that's much like that of previous VB versions,
an arrangement that's guaranteed to cause trouble (one of the underlying
reasons why so many people and firms are sticking with the old version,
VB6, and refusing to move to the new one, VB.NET aka VB7; of course,
Microsoft can force the issue, by not selling VB6 any more and
eventually removing all traces of support for it).
etc. And using the same argument,
everyone may still be programming in COBOL now.
If Cobol's key underlying concepts had proved satisfactory to the needs
of contemporary software development, as the "class" concepts appears so
far to have, then no doubt Cobol would enjoy yet more widespread
continuing acceptance (instead, while still widely used, it's also
generally seen as being on its long, slow way out).
And if we use market penetration as measure, Perl seems to be easier
for people ?

Perl historically did gain enormous traction by leveraging the
familiarity effect, "sucking in" its early adopters from the ranks of
sh/ksh, awk, and sed programmers. Of course, that effect was most
important in Perl's early years -- once solidly established, a language
creates its own "familiarity effect".

Javascript has leveraged its early advantage in the Netscape browser to
become the only "universally available" language for client-side "in the
browser" execution, and thus established a foothold in a strong and
growing niche for prototype based, rather than class based, object
models. However, there doesn't appear to be further spreading of such
object models; "big" new languages like C# (and indeed the whole
underlying CLR framework, which also forced the semantics of VB) are
strongly class-based.
Alex

[Cameron Laird]

In article <1h***************************@yahoo.com>,
Alex Martelli <al*****@yahoo.com> wrote:

[rickman]

Cameron Laird wrote:

In article <pa****************************@REMOVETHIScyber.co m.au>,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
.
.
.

on the web for each language. By comparison, even Forth gives 13 million
plus hits, and who uses Forth?

.
.
.
The programmers of, among other things, the FedEx bar-code reader,
the Sun boot loader, and parts of the Space Shuttle.

The original post seems to be missing, but my answer to the title
question is, No, Forth is not real.

[fox]

rickman wrote:

The original post seems to be missing, but my answer to the title
question is, No, Forth is not real.

Not for real, for Integer.

[Isaac Gouy]

Steven D'Aprano wrote:

On Sun, 12 Feb 2006 03:03:20 -0800, bearophileHUGS wrote:

Steven D'Aprano>Very slow to do what, compared to what? The decay time
of the tau meson?<

Probably every answer I can give you is wrong for you, so answering is
almost useless...
We do actually agree. You did explain why the speed of the language itself
is rarely the critical factor. My criticism is that whatever good your
post would have done was nullified by your opening comment stating that
Python is very slow -- a comment which I think is not only harmful, but
wrong, benchmarks like the one you linked to not withstanding.

I think it is wrong to call Python "very slow" just because it is slower
than some other language or languages, for the same reason it would be
wrong to describe the population of the UK as "very low" because 60
million people is a smaller number than China or India's one billion plus.
Doing so merely reinforces the premature optimizer's message that any
language that isn't C (and sometimes Lisp) is "not fast enough".

There was some context: Is python very slow compared to C?

With similar context your example becomes: Is the population of the UK
very low compared to the population of China or India? (Which seems to
be a reasonable question.)

We can make the missing context in the OP's question more obvious like
this: Is the population of the UK very /slow/ compared to the
population of China or India?

The benchmark you pointed to are of limited use for application
developers. (Their value to language designers is another story.)
Limited use for what purpose?
(Yes it really is difficult to make all our assumptions explicit in our
writing.)
Given
that Ocaml is (say) 200 times faster than Python on average, it tells the
application developer virtually nothing about the performance of his
application. And that's what user's care about -- they couldn't care less
about binary trees or partial sums, they care about how long it takes to
render a JPEG, open an email, save their files, query the database,
display a window, and so forth. Few application level tasks are limited by
the speed of the language, not these days.
As in
http://shootout.alioth.debian.org/mi...d%20Benchmarks

You don't believe me? Consider the following:

When you drag your mouse over text in a graphical text editor, the text
highlights. How much money would you be prepared to pay to make that
highlighting occur 200 times faster? $100? $1? One cent? Chances are you
wouldn't pay a thing, because it is already fast enough, and making it
faster is of zero value to you -- even if highlighting ten gigabytes of
text might be uncomfortably slow.

What about opening an email? How much would you pay to reduce the time it
takes to open and display an email from a hundredth of a second to
virtually instantaneously? I suggest that most people would consider 0.01s
to already be be "virtually instantaneously".

The important question isn't "is Python fast or slow?", it is "is Python
fast enough?". That's a question that doesn't have a simple answer,
because it depends. Fast enough to do what?

But, in general, more often than not, Python is fast enough. The extra
value of using something like Lua or Ocaml or even C is just not enough to
make up for the disadvantages of using those languages.
Seems like you're having your cake and eating it too - if it's
meaningless for others to talk in generalities about fast or slow, and
it's just as meaningless to talk in generalities about 'more often than
not'.

Of course Python isn't always fast enough. Please don't waste your time
coming up with practical examples where pure Python is objectively too
slow for a certain task, because you won't be telling me anything I don't
already know.

But the developer doesn't have to write pure Python, he can call a module
written in C, or change the algorithm, or find another way to accomplish
the same end result. Or even decide that for this specific task, Python is
not the language to use. These are all good solutions, but they don't mean
that Python is "very slow" in general. Even C is not always fast enough,
but we wouldn't say C is "very slow" just because it can't calculate the
first million Mersenne Primes in twenty milliseconds.
--
Steven.

[Magnus Lycka]

Isaac Gouy wrote:

I think it is wrong to call Python "very slow" just because it is slower
than some other language or languages, for the same reason it would be
wrong to describe the population of the UK as "very low" because 60
million people is a smaller number than China or India's one billion plus.
Doing so merely reinforces the premature optimizer's message that any
language that isn't C (and sometimes Lisp) is "not fast enough".

There was some context: Is python very slow compared to C?

But that is a stupid context. It doesn't really tell us
anything. Slow at what?

No one writes a program for the purpose of doing loops,
comparing integers, setting up stack frames or jumping
between instructions.

The context for programming typically involves solving some
problem or executing a function that matters to the user.

It's just as database benchmarks. TPC C benchmarks tells us
how fast a certain database is at performing TPC C benchmarks.
Does that tell you anything about how fast it will be compared
to competing products for your real world problem? Probably
not. Which ever product you choose, you might end up with
situations where a particular function is too slow. You can
typically solve this either by changing the code or the
configuration of the server. Sometimes you have to rethink
your system and solve the problem in another way. Changing
from e.g. DB2 to Oracle is unlikely to have more impact than
these smaller changes. It's the same thing with most software
development.

The benchmark you pointed to are of limited use for application
developers. (Their value to language designers is another story.)

Limited use for what purpose?

They are more or less useless for anyone who wants to decide
what programming language to use in a real world situation.
It's simply stupid to implement sorting algorithms in Python.
It's there already. Solving Ackermann's is also rather far
from what people typically want to achieve. If people actually
had the time and resources to create real software products,
(i.e. things that take man-months to create) from the same
spec, and developed e.g. ten programs each each ten different
programming languages in cleanroom conditions, we'd probably
learn something useful about the usefulness of a certain type
of programs with certain programming languages in certain
conditions, but only in these conditions. I'm rather certain
that aspects such as team size, development methodology etc
will influence the relative ratings of programs.

I'm not saying that the typical toy benchmarks are completely
useless. They might tell us things about particular language
features that should be improved, or give us clues that a
certain way of solving a particular problem etc, but they
don't really help Joe Newbie Programmer who wants to write
yet another web site toolkit.

[igouy]

Magnus Lycka wrote:

Isaac Gouy wrote:

I think it is wrong to call Python "very slow" just because it is slower
than some other language or languages, for the same reason it would be
wrong to describe the population of the UK as "very low" because 60
million people is a smaller number than China or India's one billion plus.
Doing so merely reinforces the premature optimizer's message that any
language that isn't C (and sometimes Lisp) is "not fast enough".
There was some context: Is python very slow compared to C?

But that is a stupid context. It doesn't really tell us
anything. Slow at what?

As I said: We can make /the missing context/ in the OP's question more
obvious...


No one writes a program for the purpose of doing loops,
comparing integers, setting up stack frames or jumping
between instructions.

The context for programming typically involves solving some
problem or executing a function that matters to the user.

It's just as database benchmarks. TPC C benchmarks tells us
how fast a certain database is at performing TPC C benchmarks.
Does that tell you anything about how fast it will be compared
to competing products for your real world problem? Probably
not. Which ever product you choose, you might end up with
situations where a particular function is too slow. You can
typically solve this either by changing the code or the
configuration of the server. Sometimes you have to rethink
your system and solve the problem in another way. Changing
from e.g. DB2 to Oracle is unlikely to have more impact than
these smaller changes. It's the same thing with most software
development.

The benchmark you pointed to are of limited use for application
developers. (Their value to language designers is another story.)
Limited use for what purpose?

They are more or less useless for anyone who wants to decide
what programming language to use in a real world situation.

Good that's more explicit.

One of the program contributors told me they do something quite similar
to fasta, k-nucleotide and reverse-complement in their real world
situation.

Isn't it possible that someone would look through The Computer Language
Shootout programs and decide that language X was unusable convoluted
gobbledegook?

It's simply stupid to implement sorting algorithms in Python.
It's there already. Solving Ackermann's is also rather far
from what people typically want to achieve.
What "sorting algorithm" are you talking about?
There isn't one on http://shootout.alioth.debian.org/gp4/

Solving Ackermann's? Well if that was really the point then the
programs would be allowed to use memoization rather than simple
recursion.

If people actually
had the time and resources to create real software products,
(i.e. things that take man-months to create) from the same
spec, and developed e.g. ten programs each each ten different
programming languages in cleanroom conditions, we'd probably
learn something useful about the usefulness of a certain type
of programs with certain programming languages in certain
conditions, but only in these conditions. I'm rather certain
that aspects such as team size, development methodology etc
will influence the relative ratings of programs.

I'm not saying that the typical toy benchmarks are completely
useless. They might tell us things about particular language
features that should be improved, or give us clues that a
certain way of solving a particular problem etc, but they
don't really help Joe Newbie Programmer who wants to write
yet another web site toolkit.

[rickman]

fo*@ultratechnology.com wrote:

rickman wrote:

The original post seems to be missing, but my answer to the title
question is, No, Forth is not real.

Not for real, for Integer.

:-)