why python is slower than java?

[Alex Martelli]

Re: why python is slower than java?

Maurice LING <mauriceling@ac m.org> wrote:
[color=blue][color=green]
> > Not really. It's an impression you could easily get from several
> > books about Python (e.g. O'Reilly's "Learning Python"), which
> > make a rather big deal about Python being slow to execute, but
> > fast to develop in.[/color]
>
> Come to think of it, yes, "Python, The Complete Reference", "Programmin g
> Python" and "Learning Python" all seems to have that "speed warning" tag
> in the beginning chapters.
>
> If this seems to be the wrong impression, should the authors do something?[/color]

I guess they should, if they care about what they're communicating.
This is how I put the issue in "Python in a Nutshell":

'''
Good compilers for classic compiled languages can often generate binary
machine code that runs much faster than Python code. However, in most
cases, the performance of Python-coded applications proves sufficient.
When it doesn't, you can apply the optimization techniques covered in
Chapter 17 to enhance your program's performance while keeping the
benefits of high programming productivity.
'''

I'm biased, having written this, but it seems a balanced set of
assertions which tries hard not to leave either wrong impression.


Alex

[Brian Beck]

Re: why python is slower than java?

Pythogoras wrote:[color=blue]
> OK. I will rewrite it in Java.
>
> ///
> long t = currentTimeMill is();
> tryCopyFile("in .txt","out.txt" );
> out.println( (currentTimeMil lis() - t) / 1000);
> ///
>
> You lost. The Java-version is shorter!
> I didn't count import- and import static-statements
> because Eclipse cares about imports automatically.[/color]

I don't know what version of Java they're using in this troll's fantasy
land, but tryCopyFile does not, and has never existed in any Java
implementation. The real code for copying a file would look something
like the contents of this function (which is not a part of the standard
library):

public static void copy(File source, File dest) throws IOException {
FileChannel in = null, out = null;
try {
in = new FileInputStream (source).getCha nnel();
out = new FileOutputStrea m(dest).getChan nel();

long size = in.size();
MappedByteBuffe r buf = in.map(FileChan nel.MapMode.REA D_ONLY,
0, size);

out.write(buf);

} finally {
if (in != null) in.close();
if (out != null) out.close();
}
}

[Alex Martelli]

Re: why python is slower than java?

Maurice LING <mauriceling@ac m.org> wrote:
[color=blue][color=green]
> >
> > dude that "comparisio n" from twistedmatrix you refrence is ANCIENT!!![/color]
>
> I am wondering the impact when IBM decided that the base memory to not
> exceed 64kb, in the late 1960s...[/color]

??? IBM in the '60s was developing the then-revolutionary concept of a
*family of computers* -- several models able to run the same codes with
different performance and price. "360 degrees computing", whence came
the idea of calling that family "IBM 360". Out of the 32 bits of a
register's width, only 24 bits were in fact used for addressing, so the
limit was *16 megabytes* of base memory -- 40 years ago, that not only
SEEMED huge, it WAS huge. To the point that Motorola in the late
'70s/early '80s took exactly the same architectural decision regarding
*their* (less-revolutionary.. .) 16-bit microprocessor, the 68000: again
32-bit registers, but, again, 24-bit addresses. The point being that,
about 15+ years later (10 doublings by Moore's Law!!!), IBM's crucial
architectural decision STILL seemed quite reasonable, albeit when
thinking of microcomputers rather than mainframes.

If you're thinking of IBM PC's, the key architectural decision there had
come from intel (8086 then 8088), again in the late '70s, and it _was_
way too restrictive -- just 1MB of addressability (in 64-k segments), vs
the unsegmented 16 MB of IBM earlier and Motorola at about the same
time. IBM when designing the IBM PC shortly afterwards decided to pick
1/3 of that MB for I/O and special extension cards' memories rather than
general base RAM -- leaving 640K, not 64K!, for the latter -- and the
difference betwen 640K and 1MB never really had any big impact.

The machines with 64-K byte limits I know of were early 16-bit minis
(such as PDP-11, despite later kludges to push that limit up) and just
about all 8-bit micros (intel, Motorola, and just about all others).

[color=blue][color=green]
> > it is comparing versions that are YEARS out of date and use![/color]
>
> Are the codebase of Python 1.5.2 and Java 1.1 totally replaced and
> deprecated?[/color]

No, there's a lot of code from that era still working happily.
[color=blue]
> Lisp compiler is the 1st compiler to be created (according to the
> Red-Dragon book, I think) and almost all others are created by[/color]

I'm sure Aho, Hopcroft and Ullmann would never be so ignorant or
insensitive as to detract from Backus' (and IBM Research's) epoch-making
result in making the first production compiler -- exactly 50 years ago,
quite a bit earlier than LISP, for the language first known as Formula
Translation, a name which was soon shortened to ForTran. Lisp has quite
some "first"s, but "first compiler" ain't among them.
[color=blue]
> bootstrapping to LISP compiler. What are the implications of design
> decisions made in LISP compiler then affecting our compilers today? I
> don't know. I repeat myself, I DO NOT KNOW.[/color]

I can't think of even a single one, although I fancy myself as quite
knowledgeable in the history of computing -- neither from Formula
Translation, nor from LISt Processor, not one design decision whose
implications are still affecting compilers being written today. Same
goes for computers of the same era, the '50s. If you move to the '60s
then some things do suggest themselves -- at least in computers: general
registers that are not part of the addressable memory, memory
addressable by the byte, 8-bit bytes with significant 16-bit and 32-bit
halfwords and fullwords too -- all parts of the IBM-360 legacy; not so
obvious in languages and compilers, maybe. Maybe the concepts of
grammar, tokenizers and parsers -- all stuff that wasn't in evidence in
the '50s, at least not in ForTran or Lisp. The ambitious concept of a
language good for all kinds of problems, commercial AND scientific, much
like IBM's "360 degrees computing" was breaking down the barriers
between scientific and commercial computers in the HW field. The very
first emergence of "bytecodes" , partly from trying to emulate yet-older
computers on those of the time, to keep running old applications on new
hardware where IBM's revolutionary concept of "a family of computers"
didn't apply. Pretty thin stuff, IMHO... you have to get to the '70s to
find the emergence of a more solid legacy, I think.


Alex

[Alex Martelli]

Re: why python is slower than java?

Pythogoras <noreal@email.o rg> wrote:
[color=blue]
> But maybe you want to have something more fun?
> How about that?
> read autoexec.bat,
> sort the lines
> create sorted_autoexec .bak[/color]

file('sorted_au toexec.bak','w' ).writelines(so rted(file('auto exec.bat')))

73 chars in one line. Yeah, I cheated -- I _would_ normally put a space
after the comma, making the real total into seventyFOUR...
[color=blue]
>
> ///
> File source = new File("c:/autoexec.bat");
> File destination = new File("c:/sorted_autoexec .bak");
>
> String[] lines = readLines(sourc e);
> lines = sort(lines);
> write(destinati on,lines);[/color]

How delightfully quaint and redundant. I do recall a time where Python
would take such a roundabout approach too -- of course, the Python code,
even at that time, was elegantly object-oriented, with the reading,
sorting and writing all neatly expressed as methods of file and list
objects, rather than these weird 'readLines' and 'sort' and 'write'
apparently-global functions taking the objects as arguments. Still, all
of those mysterious 'globals' does enhance the retrocomputing taste of
your code -- one can almost see you writing it with a quill dipped in
ink, at a carved oak desk, on your steam-powered computer. Charming!

Should you ever decide to move into the 21st century, though, don't
worry: Python will be there to help you do so.


Alex

[Mike Meyer]

Re: why python is slower than java?

Maurice LING <mauriceling@ac m.org> writes:
[color=blue][color=green][color=darkred]
>>>>it is comparing versions that are YEARS out of date and use!
>>>
>>> Are the codebase of Python 1.5.2 and Java 1.1 totally replaced and
>>> deprecated?[/color]
>> For new development, yes, Python 1.5.2 has been totally replaced.
>> There
>> are legacy applications running in Python 1.5.2 that aren't worth the
>> trouble to upgrade.
>>[color=darkred]
>>> Lisp compiler is the 1st compiler to be created (according to the
>>> Red-Dragon book, I think) and almost all others are created by
>>> bootstrapping to LISP compiler.[/color]
>> That's just silly. It is true that LISP was one of the pioneers of
>> the
>> compiled languages, but other compilers were not written in LISP. Almost
>> without exception, compilers were all written in assembly language until
>> Pascal came around.[/color]
>
> I'm wrong again. I suppose what I am trying to suggest is that design
> decisions made in the last may have a longer effect than what we
> consciously think. At least this is the impression I get while reading
> James Gosling's argument that Java should be object-oriented from day
> 1 (and not added onto the language, like in C++) in The Java
> Programming Environment: A white paper.[/color]

The design decisions about the syntax and grammar of the languages may
have a longer effect (thought it's not clear how much of Java can be
blamed on CPL). The design decisions about the implementation tend to
vanish every time the language is implemented, and to vanish over time
as an implementation evolves. I'd be surprised if all the 1.5.2 code
has vanished from the complete python distribution. On the other hand,
the core compiler and VM may well have been completely replaced since
then.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Roy Smith]

Re: why python is slower than java?

aleaxit@yahoo.c om (Alex Martelli) wrote:
[color=blue]
> file('sorted_au toexec.bak','w' ).writelines(so rted(file('auto exec.bat')))
>
> 73 chars in one line. Yeah, I cheated -- I _would_ normally put a space
> after the comma, making the real total into seventyFOUR...[/color]

I understand what you're doing with the above one-liner, but I don't
think that's the best way to write it. Unless there's some over-riding
efficiency requirement, I'm always going to vote for easier to read over
fewer characters.

Chaining all those operations together into one big line makes it (IMHO)
more difficult to understand what's going on, especially since it's a
mix of method calls and global function calls. To understand the
sequence of operations, you need to read from the inside-out starting
from two different places, then put those two conceptual units together
from left-to-right.

You could refactor this in a multitude of ways, with varying levels of
compactness or verbosity, depending on how many intermediate variables
you want to use. I think I would go for something like:

inFile = file ('autoexec.bat' )
outFile = file ('sorted_autoex ec.bak', 'w')
outFile.writeli nes (sorted (inFile))

Some would say that the intermediate variables just add bulk, but I
think they provide conceptual punctuation, i.e. a place for the reader
to say, "OK, I understand that chunk, now let's see what the next chunk
does".
[color=blue]
> one can almost see you writing it with a quill dipped in
> ink, at a carved oak desk, on your steam-powered computer. Charming!
>
> Should you ever decide to move into the 21st century, though, don't
> worry: Python will be there to help you do so.[/color]

I know you didn't write those lines with me in mind, but I can't help
chuckle over them. I'm tagged as a luddite by my co-workers because I
still don't have a cell phone or a palm pilot or an MP-3 player, not to
mention that I know what the program drum is used for on an 029 card
punch. I am however typing this from my wireless PowerBook :-)

[Alex Martelli]

Re: why python is slower than java?

Roy Smith <roy@panix.co m> wrote:
[color=blue]
> aleaxit@yahoo.c om (Alex Martelli) wrote:
>[color=green]
> > file('sorted_au toexec.bak','w' ).writelines(so rted(file('auto exec.bat')))
> >
> > 73 chars in one line. Yeah, I cheated -- I _would_ normally put a space
> > after the comma, making the real total into seventyFOUR...[/color]
>
> I understand what you're doing with the above one-liner, but I don't
> think that's the best way to write it. Unless there's some over-riding
> efficiency requirement, I'm always going to vote for easier to read over
> fewer characters.[/color]

I agree, and efficiency is just the same if you _do_ give names to
intermediate objects. Terseness is worthy as long as it _helps_ reading
the code, by avoiding violations of Occam's Razor (introducing entities
without necessity).

[color=blue]
> Chaining all those operations together into one big line makes it (IMHO)
> more difficult to understand what's going on, especially since it's a
> mix of method calls and global function calls. To understand the
> sequence of operations, you need to read from the inside-out starting
> from two different places, then put those two conceptual units together
> from left-to-right.[/color]

It's actually right-to-left, as that's the way the inside-out order
works out. But if you read left->right, it's "to file
sorted_autoexec .bak, write lines from sorted file autoexec.bat", which
doesn't scan all THAT badly in English, I think;-). It's right-left if
you think of things HAPPENING, of IMPERATIVE code, but it's not
necessarily that way if you think of the code as descriptive;-).

[color=blue]
> You could refactor this in a multitude of ways, with varying levels of
> compactness or verbosity, depending on how many intermediate variables[/color]

Right.
[color=blue]
> you want to use. I think I would go for something like:
>
> inFile = file ('autoexec.bat' )
> outFile = file ('sorted_autoex ec.bak', 'w')
> outFile.writeli nes (sorted (inFile))
>
> Some would say that the intermediate variables just add bulk, but I
> think they provide conceptual punctuation, i.e. a place for the reader
> to say, "OK, I understand that chunk, now let's see what the next chunk
> does".[/color]

My preference here might be to have a name for the output file variable
and not for the input one, but that's a pretty thin consideration. Your
version lets one close both files explicitly, which is good.

[color=blue][color=green]
> > one can almost see you writing it with a quill dipped in
> > ink, at a carved oak desk, on your steam-powered computer. Charming!
> >
> > Should you ever decide to move into the 21st century, though, don't
> > worry: Python will be there to help you do so.[/color]
>
> I know you didn't write those lines with me in mind, but I can't help
> chuckle over them. I'm tagged as a luddite by my co-workers because I
> still don't have a cell phone or a palm pilot or an MP-3 player, not to
> mention that I know what the program drum is used for on an 029 card
> punch. I am however typing this from my wireless PowerBook :-)[/color]

Heh -- you're a notch up from me, since the wireless Mac laptop I'm
using is a humble iBook 12";-).


Alex

[Fábio Mendes]

Re: why python is slower than java?

what about:[color=blue][color=green][color=darkred]
>>> fat = lambda n: reduce(lambda x,y: x*y, range(1,n))
>>> int = lambda f,a,b,dx: sum([f(x) for x in arange(a,b,dx)])*dx/(b-a)[/color][/color][/color]

Thoss (poorly) implements the factorial and integration function in just
one line. So what does my pet examples show us? Nothing! The same goes
for yours. So your poor affirmation about java compactness is the mere
statement that the only kind of code you can produce is autoexec.bat
sorting and the kinds. Every language has it's pros and cons, and having
a compact expressive syntax is NOT one place where Java outshines
python, ask any serious person.
[color=blue]
>
> You lost.
> You Pythonistas are a bunch of losers.
> And your language is dog-slow.
> Eeeeeek.
>
> And try to write Eclipse with your Mickey-Mouse-language!
>
> <j>
> Pythogoras
>
>
>[/color]

[Terry Hancock]

Re: why python is slower than java?

On Saturday 06 November 2004 09:07 pm, Roy Smith wrote:[color=blue]
> Terry Hancock <hancock@anansi spaceworks.com> wrote:[color=green]
> > And I have certainly written some extremely poorly optimized
> > Python programs that positively *crawled*.[/color]
>
> My guess is the poor performance had nothing to do with the language you
> wrote it in, and everything to do with the algorithms you used.[/color]

Wrong guess. ;-)

There was nothing wrong with the *algorithms* when considered apart
from the language. But considered *with* the language, they were
very bad choices.

Consider the case that you want to perform a string operation which
is not quite covered by the standard library. How do you solve that?

In C, you might very well write a function from scratch that does
what you want and nothing else. Usually this will be faster than
calling some standard library function that gets you halfway there
and then another that tries to fix the mistakes the first one made.

Not so in Python. Anything you write from scratch is going to be
interpreted, and therefore goes at a snail's pace compared to the
C code running in various built-ins and modules (consider the re
module, for example!). In fact, you might very well write a
regular expression solution that could have been done by less
impressive means in C, but would take much longer if you literally
translated the code from C to Python. The re solution will actually
do a lot more work "below the waterline" than the literally
translated version, but it won't have the loop overhead and such
to slow it down.

Generally speaking the simplest *conceptual* way to solve a problem
in Python is also the fastest.

I certainly learned this lesson. In a way, it's a good thing,
because the simplest conceptual way is probably the easiest for
a reader of your code to understand, too.

The reason why this is relevant is NOT because I'm saying "Python
is slow", but rather that it can be very slow if poorly programmed.
Thus an experienced Java programmer who tries Python may very well
find it to be "slow", since they will not necessarily make the
right choices in re-implementing a program in Python.

That's probably true for any two languages -- the one you are
most familiar with has a significant home-team advantage. ;-)

Cheers,
Terry

--
Terry Hancock ( hancock at anansispacework s.com )
Anansi Spaceworks http://www.anansispaceworks.com

[Bengt Richter]

Re: why python is slower than java?

On Sun, 07 Nov 2004 10:33:01 +1100, Maurice LING <mauriceling@ac m.org> wrote:
[color=blue]
>[color=green]
>>
>> dude that "comparisio n" from twistedmatrix you refrence is ANCIENT!!![/color]
>
>I am wondering the impact when IBM decided that the base memory to not
>exceed 64kb, in the late 1960s...
>
>I suppose more experienced people in this list can agree that certain
>decisions made can be almost an edict. So, there is a re-building
>process every now and then, hopefully to by-pass such edicts. Python
>itself is already such an example.
>[color=green]
>>
>> it is comparing versions that are YEARS out of date and use![/color]
>
>Are the codebase of Python 1.5.2 and Java 1.1 totally replaced and
>deprecated?
>
>Lisp compiler is the 1st compiler to be created (according to the
>Red-Dragon book, I think) and almost all others are created by
>bootstrappin g to LISP compiler. What are the implications of design
>decisions made in LISP compiler then affecting our compilers today? I
>don't know. I repeat myself, I DO NOT KNOW.
>[/color]
google is your friend. I would suggest prefixing "UIAM" to statements
or strong implications of "fact" that you are not really sure of ;-)
Perhaps you are not familiar with the various typical ways of softening
the assertiveness of statements in English? I notice several statements
above that start out looking like authoritative statements of fact, but
which you qualify in your way, yet it seems you were unsatisfied with
the effect, and added the last sentence.

"We are all ignorant, only on different subjects", as (UIAM ;-) Will Rogers
said. But here at c.l.py it is unlikely that all are totally ignorant on a
particular computer language subject, so if you post an unqualified statement
of "fact" (or slip an implicit statement of "fact" into a question, as in the
subject line of this thread ;-) that may not be so, someone will notice,
and wonder why you are doing that (since you haven't annnounced that you're
a political candidate ;-)

One reason might be language difficulties, but your English is too good
for that to jump immediately to mind.

Another reason might be forgetting that posting here is actually engaging other
human beings, and thinking of c.l.py posts as a kind of automated google
mechanism which has no feelings about how it is being used. But humans do care,
and provocative techniques of eliciting response do "provoke." Kids intent on
their immediate goals sometimes forget, but generally respond to a gentle reminder.

Another reason might be to spread disinformation for some private reason,
e.g. as a sleazy way to discredit competition. I don't think that applies here.
Or are you heavily invested in particular stocks? ;-)

Anyway, I think the best we can do is to help each other find out what the
real facts are, which requires not presenting suppositions as fact, while
recognizing that appearances are often deceiving to even the most experienced.
In that spirit, we wind up expressing doubts without bruising egos, and thanking
each other for contributions to improved understanding instead of defending against
feeling a fool for having believed something that was not so, or being annoyed
at careless spread of disinformation.

(of course, I haven't personally verified the "facts" stated in the
following sites ;-)

http://www.emacswiki.org/cgi-bin/wiki/CommonLisp

"""
The first Lisp compiler was developed by JohnMcCarthy at Dartmouth College
between 1955 and 1959. This makes it the second oldest programming language
in common use today (only Fortran is older, developed between 1954 and 1957).
"""

http://www.ibiblio.org/pub/languages/fortran/ch1-1.html

"""
This wonderful first FORTRAN compiler was designed and written from
scratch in 1954-57 by an IBM team lead by John W. Backus and staffed with
super-programmers like Sheldon F. Best, Harlan Herrick, Peter Sheridan,
Roy Nutt, Robert Nelson, Irving Ziller, Richard Goldberg, Lois Haibt
and David Sayre. By the way, Backus was also system co-designer of the
computer that run the first compiler, the IBM 704.
"""

http://www.latrobe.edu.au/philosophy/phimvt/sympas/s49hiteco.html

http://www.moorecad.com/standardpascal/pcom.pas

Regards,
Bengt Richter

[Roger Binns]

Re: why python is slower than java?

Alex Martelli wrote:[color=blue]
> Roger Binns <rogerb@rogerbi nns.com> wrote:
> ...[color=green]
>> I/O is one area where Java is *very* different than other
>> environments. Java emphasises the ability to select at runtime
>> (typically from[/color]
>
> Python's dynamism at runtime is definitely one of its fortes.[/color]

We are talking about different things. Once you have written
some nice big Java "Enterprise " app, you'll see the difference.
I am not talking about the type system. It is more about how
Java applications are constructed. There are multiple JAR files,
many many properties files and the end user/adminstrator can
change what happens and plumb them together by changing the
properties files.

You could do *exactly* the same thing in Python, but people don't.
That doesn't make either language right or wrong, just that the
emphasis and what is considered "normal" is different.
[color=blue]
> Sure, since the semantics are different. Which is why we have the
> makefile method of socket objects: for those occasions in which you
> want signature-polymorphism at the expense of the overhead of
> adaptation.[/color]

Yes. The point is that Java I/O is always done in that polymorphic
way, whereas Python doesn't. In both cases, you can do what the
other language does, but people usually don't. But it does mean
that if you want to measure I/O performance, you have to decide
if you want to do it with code optimised for speed, or what is "normal"
in each language.
[color=blue]
> Generators are a reasonably recent addition to Python, and I have no
> idea what you mean by stating that Python emphasizes typing more than
> Java does[/color]

I meant Python's typing mechanism ("duck typing"). Python programs
take advantage of that, just as Java programs take advantage of
the Java typing mechanism. Python's is more defined by the absence
of pervasive programmer defined typing, whereas the Java one requires
the specification of type information for all names, and interfaces
are used a lot.
[color=blue]
> Python frameworks. And factory-based design patterns are everywhere
> in Python, of course; indeed, it's in Java that you see lots of 'new
> ThisClass' constructs which build an instance of some hardwired
> concrete class --[/color]

Java programs have *way* more factory stuff. Just a different emphasis.
[color=blue]
> Python's default makes it trivially easy to read most files in a
> single gulp, so it's appropriate in many cases; Java's makes it hard
> and slow to read ANY file, so it's never appropriate.[/color]

Your Java code was not representative of what an average programmer
would do in Java. In fact it was a spectacularly bad example of
Java programming. You can find bad examples of programming in
every language on the web.
[color=blue][color=green]
>> If the language code is the same, then that claim boils down to
>> the Java Native Interface vs the Python C API. In the case of
>> Java, I can see the claim having some relevance in multi-threaded
>> code since Java doesn't have the GIL.[/color]
>
> Python does, but drops it during blocking I/O operations so that the
> relevance should be just about the same in both cases.[/color]

Python will be worse with the penalty being based on how much concurrent
I/O is happening and how many processers the host has. This is due to
the serialisation of the Python bytecode, and non-serialisation of the
Java bytecode. My best guess that this will be a few percentage points
at a low number of concurrent I/O and probably up to 20% with
thousands.

(At this moment at work I am in fact dealing with this very thing in some
Python code and a form of proxy server).
[color=blue]
> I did observe (at some point along the substantial chain of small
> benchmarks I and some other posters exchanged) that the 4:1 ratio in
> runtime in favour of Python exactly matched the 4:1 ratio in
> pagefaults, again in favour of Python, btw.[/color]

Page faults aren't a valid way of measuring this. You don't incur page
faults for malloced/brk memory but you do for executable pagein, and
for mmap (usually). Using executable pagein and mmap is better when
you have multiple instances of programs since they will share
system memory. Again this all comes down to what the runtime
environment is optimised for.
[color=blue]
> However, firms that choose not to release their business critical
> applications as open source are likely to require at the very least a
> non-disclosure agreement before they show you those sources, making it
> impractical to use those sources to meet your wishes.[/color]

That is missing my point completely. If I wanted to write a ray tracer
and I could find them all over the net and in business success stories
in all languages, I would want to examine the innards of them to see
if I could do the same thing.

We have all heard the Yahoo Stores/Paul Graham/Lisp story. I don't
think many people have seen that code. Do you think you could do something
similar in Lisp? Could you write a ray tracer in Lisp? If you could
see examples of even unrelated applications, and their code, you would
have a better idea. You would be able to judge if you could achieve
it with a team of 10 average programmers. But without being able to
see the internals of at least some examples, your guess would have a
very high margin of error.
[color=blue]
> As for your latter sentence, I've never met a programmer whose default
> assumption was that they would NOT be able to write code just as good
> as most anybody else's.[/color]

That only applies to languages they know or know about, and in many
cases also libraries (eg SQL, Persistence, Networking, Transactions).
Any programmer who believes they can write Yahoo Stores in Lisp just
as good as what Paul Graham and co did, when they don't know Lisp, have
no experience in that type of application, have never done credit
card processing etc is kidding themselves. They may be able to
do so eventually, but it will take much time to learn. They are
unlikely to be able to accurately estimate that time at the begining.

Using another example, do you think everyone who reads this group
could just go ahead and write Zope?

Roger

[Israel Raj T]

Re: why python is slower than java?

Roy Smith <roy@panix.co m> writes:
[color=blue]
> mention that I know what the program drum is used for on an 029 card
> punch. I am however typing this from my wireless PowerBook :-)[/color]

I hate to say this, but my kids have had 802.11g on their notebooks since
the age of 12 ( ie : nearly 2 years now).

[Maurice LING]

Re: why python is slower than java?

Mainly to Alex and the rest of the adjitated community,

[snip about Melbourne club scene]

I do understand what you meant. There are restrictions in giving out
data (codes) in many cases and I seek your understanding.

Nevertheless, I do feel that you had unfairly made use of this case to
voice out your accumulated dissatisfaction with answering newbies
questions.

In later parts of this thread (after your post), it was suggested that
my errorous impressions might have been formed by books and publications
(such as "learning python", as suggested)..... . I do not seek to place
blame on anyone for my misconceptions. But considering a person trying
to learn a new programming language, it is common that the person takes
in what is presented in the face, especially from books such as,
"Learning python" and "Python, the complete reference".
[color=blue]
> Does this imply you now believe that the unquestioned-assumptions behind
> your "why" questions were unfounded?
>[/color]
Now I will say that Python is comparable to Java in terms of disk I/O.

[color=blue]
>
> Forming a wrong impression is always a possibility. It's proceeding to
> take it for granted as an obvious fact, that is quite questionable. If
> you had phrased your observation in terms such as "I have gotten the
> impression, without having done any measurement myself, that" etc, the
> reactions would have been vastly different; your choice to express
> yourself by implying an unquestionable fact existed and only required
> explanations of its reasons, is a good part of the reaction's cause.
>[/color]
My apologies for raising your blood pressure, take care.
[color=blue]
>
>
> False: not all knowledge in the world can be usefully embodied in print
> (text, images, even videos and sound recordings actualy). An important
> part of human knowledge is experiential, and only a shadow of that
> important part can be captured in libraries, including multimedia ones.
>
> Many universities, as a part of their mission, conduct research and
> therefore presumably generate new knowledge. This entirely self-evident
> and obvious fact, even by itself, makes your assertion doubly absurd:
> "all knowledge is out there" readily implies there is no knowledge to be
> added, and "all universities are complete waste of money" similarly
> implies no university is generating new knowledge, or what they do
> generate is utterly worthless.[/color]

Perhaps I should rephase it as known knowledge so far.[color=blue]
>
> Your assertion that "by my argument" (which had never touched anywhere
> upon the research role of universities) research is nonexistent, futile,
> or entirely worthless, is at the same time absurd and deeply insulting.
> If and when I want to criticize university research, I will do so
> myself, and I do not AT ALL appreciate this attempt to put words in my
> mouth, even though any reader with a 3-digits IQ can see it as the
> insulting absurdity it is.
>
> If we stick to the _teaching_ role of universities, the reasons my
> arguments imply nothing like you're stating are both more interesting
> and subtler. On one hand, there is the experiential side of knowledge.
> By conducting experiments in a laboratory under proper guidance, even
> though those experiments are not novel, students acquire knowledge
> experientially -- a very different learning mechanism from reading books
> and articles, or listening to lectures. Of course, good high schools
> have laboratories etc, too, but in University, at least in scientific
> and technical disciplines, the experiential learning process _should_
> blossom to a far higher degree (if it doesn't -- if a university skimps
> on labs and overwhelms students with just books and lectures -- then
> that may well be a valid ground for criticism, _of that particular
> university's choice in didactics_, of course, not "of all
> universities"). In other disciplines, experiential learning may be less
> obvious, but if the university is any good, it will be there.
>
> And then, there is the issue of selection and structuring. I have
> posted about that recently, in a thread asking whether there was a book
> about large-scale software development with Python, and you can easily
> look it up on google groups. To summarize: I have lots of materials on
> the subject. I find I'm easily able to organize these materials into
> courses and workshops that are specifically aimed at an identified group
> of students, with certain backgrounds and interests. Organizing the
> same material into a _book_ is a far harder task, one which I can't take
> the time off to undertake at present... which ties back to a _part_ of
> the reason why not all knowledge is in books or other printed or
> otherwise 'frozen' (recorded, filmed, ...) forms. A vast majority of
> the materials I collected IS out there -- over the years, I've posted a
> goodly fraction of it. But it's generally unselected and unstructured,
> making the learning task far more daunting than proper structuring and
> selection can potentially make it.
>
> A good university course has selection and structuring, and is
> interactive in a way a book can never be, thus potentially making the
> s&s more appropriate and effective for the specific individual students
> who are taking that course wrt books (or some other well-organized
> subset of info from the net). Of course, if you throw 500 students at a
> poor professor, no matter how good he is, his ability to teach a really
> good course will be impaired -- smaller classes are MUCH better that way
> (another valid criticism of the way many universities are structured).
>
> Usenet does have the interactivity advantage, but normally not the
> structuring one, with rare exceptions, and only to some extent the
> selection one. Thus, it can complement rather than substitute for
> books, courses, and information search on the raw net. It has little
> experiential value, though not zero -- _some_ of the interaction on it
> does work to stimulate and vaguely guide/aim some experiences.
>
>
>[color=green]
>>As mentioned, the discussion is heading else where and my misconceptions
>>cleared before your replies. If I've indeed forgotten, my sincere
>>apologies and hereby thank you for your time and efforts.[/color]
>
>
> Thanks, this is appreciated. I take it then that you do not any longer
> opine that on disk-I/O intensive programs Python is self-evidently
> slower than Java?
>
>[color=green]
>>You still have the right to remain solemn.[/color]
>
>
> Heh, nice. Well, it's a right I surely exercise far more often than the
> more traditional one of remaining silent;-).
>
>
> Alex[/color]

All in all, through all these discussions, I can safely assert that
Python and Java are comparable in disk I/O. And a part of the original
misconceptions might have been formed possibly out-dated printed
materials which are still references for new python programmers. It is
then my concern that such misconceptions may be perpentuated.

I admit and apologise for my poor phrasing of questions which sparked
this chain of events. We had all lost some cool along the way and some
harsh words flew. Alex, I do hope you will accept my apologies. I
suppose I am pissed off when the flare is targetted towards myself and
not the situation. Anyway, my apologies...

maurice

[Roy Smith]

Re: why python is slower than java?

In article <87vfcgkd3e.fsf @pop-server.bigpond. net.au>,
Israel Raj T <rambam@bigpond .net.au> wrote:
[color=blue]
> Roy Smith <roy@panix.co m> writes:
>[color=green]
> > mention that I know what the program drum is used for on an 029 card
> > punch. I am however typing this from my wireless PowerBook :-)[/color]
>
> I hate to say this, but my kids have had 802.11g on their notebooks since
> the age of 12 ( ie : nearly 2 years now).[/color]

That's OK. I once went for a job interview that really made me feel
antiquated. The kid who was interviewing me looked at my resume, saw
that I had started using Unix in 1977, and said, "Wow, you've been doing
Unix longer than I've been alive!".

The key to avoiding becoming a dinosaur is to keep learning. If you
don't learn something major (a new language, operating system, etc)
every year, it won't be too long before you start to sink into the tar
pits.

[Ian Bicking]

Re: why python is slower than java?

Roger Binns wrote:[color=blue]
> We are talking about different things. Once you have written
> some nice big Java "Enterprise " app, you'll see the difference.
> I am not talking about the type system. It is more about how
> Java applications are constructed. There are multiple JAR files,
> many many properties files and the end user/adminstrator can
> change what happens and plumb them together by changing the
> properties files.
>
> You could do *exactly* the same thing in Python, but people don't.
> That doesn't make either language right or wrong, just that the
> emphasis and what is considered "normal" is different.[/color]

FWIW, this is something they are doing in Zope 3. ZCML (an XML markup)
is used to define the relationship of various components, in a role that
is probably similar to Java properties, jars, etc.

--
Ian Bicking / ianb@colorstudy .com / http://blog.ianbicking.org