When will Java go mainstream like Python?

[John Nagle]

Gregory Ewing wrote:
> Lawrence D'Oliveiro wrote:
>> And then there’s caching. Modern CPUs owe most of their speed to 
>> assumptions that programs will obey locality of reference. 
>> Pointer-chasing is a cache-
>> hostile activity.
> 
> Another thing to consider is the rate at which garbage is
> created. Java's fundamental types (ints, floats, etc.) are
> unboxed, and objects are only used for relatively heavyweight
> things. So you can do quite a lot of useful computation in
> Java without creating any objects or leaving behind any
> garbage.
> 
> In Python, on the other hand, you can't even do arithmetic
> without creating and destroying intermediate objects at
> every step. 

     This is really a CPython implementation problem.  Face it,
CPython is a "naive interpreter".  It pretty much does the obvious.
In other words, the code for the worst case is used for all cases.
It doesn't optimize out reference count updates, do type inference
to avoid unnecessary boxing, or figure out at compile time which
objects could be "slotted" and don't need dictionary lookups for
fields.  Plus, of course, there's the GIL problem.

     Reference counts aren't inherently slow.  About 90% of reference
count updates could be optimized out.  The compiler needs to understand
what's a temporary object and what isn't.  See

http://blogs.msdn.com/abhinaba/archive/2009/02/09/back-to-basics-optimizing-reference-counting-garbage-collection.aspx

     The language isn't inherently slow, but CPython is.

     The Shed Skin developer has shown what's possible.  He
doesn't have enough resources to finish a full implementation,
but he's on the right track.  There's grumbling about the
restrictions in Shed Skin, but only some of Shed Skin's
restrictions are inherently necessary.  The one Shed Skin
developer has accomplished far more than the PyPy army of ants.

				John Nagle