Questions about Java

[xlinuks]

Translation: Python cannot do that that fast, one has to find/write a C library and let that library do the job for Python because otherwise it would be painfully slow.

Have you done any app that does lots of animation with "pure" Python or one has to (once again) pull out a good old C library to do the job for Python?
I mean, have you done anything that I can have a look at and say kinda "cool, I was wrong, Python _can_ be as fast as Java or even faster".

Here's an animation I did with Java (just for fun), can you do that with Python alone - or is it too slow (like I said lots of time before) for something like this and Python needs C's help?

The .jar file runs at double click:
http://xlinuks.googlepages.com/anim.jar

[LaRoza]

Translation: Python cannot do that that fast, one has to find/write a C library and let that library do the job for Python because otherwise it would be painfully slow.

Have you done any app that does lots of animation with "pure" Python or one has to (once again) pull out a good old C library to do the job for Python?
I mean, have you done anything that I can have a look at and say kinda "cool, I was wrong, Python _can_ be as fast as Java or even faster".

Python (the most common implementation) is written in C, as are many of its modules. Python is a tool. It is an easy to use tool, and fast to code. It is also easily used with other tools, namely, C. One can use the ctypes in Python, embed C code in the Python code, and write modules in C.

The point is, speed has to be managed, not micromanaged. pmasiar's saying that most of the waiting is for IO and database/server connections, there is no point in trying to speed it up. Nature itself limits it. For something like animations, Python can be used.

A good old C library is very common in Python. Are you diminishing Python by saying it isn't just all pure Python? Very odd. C is a great language, it is the backbone of the open source world.

[xlinuks]

I said that Python is like 20 times slower, and pmasiar hijacked my words by moving to the usage of other languages through libs: "Optimizing code which spends 90% of the time in library call is meaningless" - I wasn't talking about calling libraries of other langs, but about what these 2 languages can do by themselves and the speed they can perform at.
"a good old C library" I mean that the libraries written in C are good and widely used.

[pmasiar]

Translation: Python cannot do that that fast, one has to find/write a C library and let that library do the job for Python because otherwise it would be painfully slow.

... but all real-life programs use libraries?

It's other way around. Python programmers live in the world where single-language purity is not of the utmost importance: They accepted that mixing languages is fact of life. They decide to implement most of the application in a language which allows to implement application 10 times faster than "traditional" statically compiled language, because Python runtime system takes care of many issues slowing down "traditional" programmers.

But even if I have to reimplement parts of code in C, I will know (1) exactly which part (2) have stable API (3) do not waste time implementing in static language 90% of the code which speedup will not benefit application as a whole.

BTW you might be surprised that recent advances in compilation suggest that runtime optimization might have better results (because at runtime, we *know* which type is used). PyPy and IronPython are efforts in this direction, and because MSFT can invest a lot into it, and change underlying engine, IronPython's speed after JIT compilation is almost C# (while keeping all Python's flexibility).

Dynamic languages strike back

[Quikee]

BTW you might be surprised that recent advances in compilation suggest that runtime optimization might have better results (because at runtime, we *know* which type is used). PyPy and IronPython are efforts in this direction, and because MSFT can invest a lot into it, and change underlying engine, IronPython's speed after JIT compilation is almost C# (while keeping all Python's flexibility).

Dynamic languages strike back

Well yes.. also Sun has The Da Vinci Machine, which is a playground for VM features to make the JVM more multi-language and dynamic languages "friendly".

(Multiple) Coexisting dynamic and static languages on a common VM are the future (and also support for features of functional languages - like continuations for example) - everybody is starting to get this and moving towards this goal.


Also is one of my fellow developers would write..

for( int i=myVector.size()-1; i>=0; i-- ) {
//do stuff
}

.. (or any other stupid upfront optimization like that) with a excuse that it is presumably faster than the plain and cleaner..

for( WhateverObject each : myVector) {
//do stuff
}

.. I would just go nuts and slap his head.

[xlinuks]

.. I would just go nuts and slap his head.

If my boss would do that to me or anyone else I know I would make sure he (if he is lucky) goes to jail, believe me (or I'll just make sure he can't ever do that again by removing the/his (body) parts he used to do that).

And sooner or later you _will_ see code like that so prepare your feeble mind, because (flash news!) sometimes you have to iterate backwards!

[Quikee]

If my boss would do that to me or anyone else I know I would make sure he (if he is lucky) goes to jail, believe me (or I'll just make sure he can't ever do that again by removing the/his (body) parts he used to do that).

Its good that I am nobody's boss.. and my fellow developers are also my friends so even if I would do something like that nobody would sue me.. but anyway this was just an abstraction of how bad I think the idea really is.

And sooner or later you _will_ see code like that so prepare your feeble mind, because (flash news!) sometimes you have to iterate backwards!

Of course.. what do you think a ListIterator is primarily used for? Also I was referring to do some obscure upfront optimization you were suggesting.

If you have a list of elements and it is a higher chance to find and process the right element iterating backwards I think this is of course OK. But if you do code "optimization" just because the compiler might (or not) produce a more optimal compiled code (in one version.. but who knows what happens in the future version) and sacrifice code cleanses then this is just stupid.