Typing system vs. Java

[Donn Cave]

Quoth anamax at earthlink.net (Andy Freeman):
| Donn Cave <donn at u.washington.edu> wrote in message news:<9kpdm3$hhk$1 at nntp6.u.washington.edu>...
|> Quoth anamax at earthlink.net (Andy Freeman):
|>| 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.
|
| Let's do the arithmetic.
...
| Now, I haven't accounted for the time to find that 20%, but I'm
| ahead 4 to 10, so I'm somewhat skeptical that it would be generally
| faster to have written it in C from the beginning.

You aren't accounting for the trouble of managing a program that
now has both Python's and C's problems - it's platform dependent
object code, and at the same time it needs an interpreter.  And
note that your C extension requires extra work and some special
skills to write.  Factoring out your 20% may not be as easy as
you hope.

But anyway, did I say you should write the whole thing in C?
I should bite my tongue, but actually I did not say that.
I stay away from C when I can, and you should too.  I only
said "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
|
| Hmm, the application was "too big" and yet "small"....

Exactly.  For a relatively trivial application, the Python implementation
had a big "footprint".

|> The moral is not that you should be using C instead, but that
|> Python should be faster.
|
| At what cost?  Be explicit - what would you change, and what would the
| other side effects of those changes be?

Well, that's a good question.  Do we agree that it's worth the trouble
to sort that stuff out, or does Moore's law make such things recede in
importance faster than anyone can address them?

We got here talking about static type checking, and there is some reason
to think that could open up some opportunities for optimization.

|> still expensive.  Moore's law is another symptom of denial, "your
|> program isn't really slow - just wait, it will be fast someday!"
|
| Hmm.  Let's look at what this "moore's law denial" has gotten us.
| 3D games.  OCR.  Sound, photo and movie editing.  Sound, image, and
| movie generation.  Digital control of mechanical things in general.
| Primitive voice recognition.
|
| Computers are "fast enough" for those applications, and they weren't
| before.  Every year, more and more things become possible, because
| newer computers tend to be faster for the same $.  Yet, recognizing
| that fact is "denial".  Curious.

That's all true, but what I want you to recognize is that these are
the moving target that software has to meet.  As the capability
expands, so do the expectations, and if your software is slower
than its competitors, that hurts.

Honestly, it does make sense to program in Python.  I have been
doing it for years and it hasn't killed me.  But you have to be
careful where you go with it, and performance is one of the reasons.
That's a problem, and for the moment that's all I want to say -
there's a difference between a problem for which we currently
have no solution, and a non-problem.

	Donn Cave, donn at drizzle.com