Typing system vs. Java

[Donn Cave]

Quoth anamax at earthlink.net (Andy Freeman):
| Christopher Barber <cbarber at curl.com> wrote in message news:<psoitg1md4l.fsf at jekyll.curl.com>...
|> anamax at earthlink.net (Andy Freeman) writes:
|>| Only if you've already exhausted algorithm/architecture/infrastructure
|>| improvements and "decrease run-time at any cost" really is the primary
|>| consideration.
|> 
|> It could be pretty expensive to move all of your code to a faster language if
|> you discover that Python is not good enough.  Sometimes you can write C
|> extensions for the slow parts, but in some cases you will have to start over.
|
| If experience is much of a guide, writing first in python and then
| in C tends to be cheaper/faster than writing in C from the beginning.
| Heck, writing in C then writing in C is often cheaper than writing in C.
|
| BTW - I would like to see an application that doesn't have significant
| hotspots.  I doubt that there are very many.

That's only one of the issues, though.  No doubt you can identify
a hotspot or two, depending on your criteria for significance.
You still have to ask whether it's worthwhile to write an extension -
maybe it would be not much harder to just write the whole thing in
a faster language.

I have tried the "write C after first writing in Python" route, when
an application was too big and slow.  It was a small application (but
one that is run often), and I'm not sure the Python version saved me
any great amount of time - C's storage is so different from Python's
that you can't just add curly braces, you have to rethink the architecture
at a fairly basic level to accommodate C.

There are lots of cases to the contrary, and in general partial or
full migration to C is an important option for various reasons.

But it isn't a good enough option to make Python's performance
unimportant.  When it's too slow, fixing that can waste a lot of
time, and that bites the programmer who decided to use Python,
and the organization that went along with that programmer, etc.
The moral is not that you should be using C instead, but that
Python should be faster.  When I want a more efficient solution,
I don't want to hear that I have to go to C, I want to know what
language has what I need, including efficient execution.

I think it's questionable how relevant Moore's law is here.  Interpreted
languages have been around pretty much all along, and all along have
presented the same kind of tradeoffs.  Twenty years ago our basement
was full of one or two computers, with computing power embarrassingly
surpassed by a common PC clone today.  Today, our basement is still
full of computers - hundreds of much faster computers - and they're
still expensive.  Moore's law is another symptom of denial, "your
program isn't really slow - just wait, it will be fast someday!"

	Donn Cave, donn at u.washington.edu