[OT] Python like lanugages [was Re: After C++, what with Python?]

[Tim Harig]

On 2011-01-18, geremy condra <debatem1 at gmail.com> wrote:
> On Mon, Jan 17, 2011 at 4:02 PM, Tim Harig <usernet at ilthio.net> wrote:
>> I really question that you get Java anywhere even close to C performance.
>> Google reports they get within the same order of magnitude as C for
>> their long-lived server processes where the JIT has had time to optimize
>> its results.  For shorter term processes such as desktop applications,
>> Java performance stinks -- even after you discount the JVM starup time.
>
> I'm sorry, but you're wrong on this. Java's performance can be
> excellent, particularly when it comes to mathematical functions. I
> recall reading a pretty smug paper a few years ago describing how they
> managed to beat C on a number of numerical benchmarks.

I have no doubt that Java *can* occasionally beat *some* C for *some*
benchmarks; but, overall, Java has a terrible reputation for performance.

I worked with a company a few years ago that tried replacing a C VNC
client with a Java one so that its technical support contractor's wouldn't
need to have the VNC client installed on the agent's workstations.
Several of the contracters had to upgrade their systems in order to
use the Java version because it slowed down the machines so much that
the agents could not perform their jobs effectively; and that is pretty
typical from what I have seen with Java overall.

Java performs very well with some select tasks.  For others, it does
exceedingly poor.  That kind of hit or miss is pretty typical for JIT
compilers in general.  That isn't usually the case for fully compiled
langauges where you are pretty much guaranteed to get decent, if not
always the absolute top, performance.

>> Ada is capable of C++ like performance *if* you compile it to remove *all*
>> of runtime checking.  Depending what checks you enable, it can run much
>> slower.
>
> No idea, never used it.
>
>>> in line with the work of others. You can argue that it's good enough-
>>> it is, for most cases- but taking a 20% performance hit rules it out
>>> of a lot of systems work, and the C-Go gap in many cases is much
>>> larger than that.
>>
>> I don't work anything that involves and absolute need for performance.
>
> Then don't argue about performance, it makes you look like a hack just
> eager to shill for your language.

What you don't seem to realize is there is often a performance level that
is good enough.  For many things, Python is good enough.  Many others,
where Python is insufficient, may still be acceptable to use Java.
Some things require the absolute best performance and will probably
always need C/C++ or equivilantly low level language.

>> I could probably accept penalty several times that of C for higher
>> level functionality; but, sometimes the penalty for Python is just
>> too much.  Many of my programs are very quick lived such that even
>> loading an interpeter or VM can eclipse the actual runtime.  Given less
>> developmental effort required, I also find that I have more time to look
>> for ways to optimize Go.  There are many things (such as using alternate
>> data structures rather then the build in slices and immutable strings)
>> that can be used to accelerate Go when time permits and I suspect many
>> more will be found as the language matures.
>
> This is inconsistent with your argument about PyPy. See my earlier comment.

I can accept 2 to 3 times the overall performance of C for almost all of
the problems that I deal with.  When that multiple gets into the double
digits, it can start to cause some real headaches for some problems.  When
that number reaches the upper double digits, it is acceptable for even
fewer problems.

Python is great for those problems where performance isn't critical and I
make extensive use of it.  Different methods of mixing Python and C
(including manual, PyPy, SWIG, boost, etc) can extend Python's useful
range; but, I have not seen the kind of speed improvements that bring it to
less then an order of magnitude of C's speed overall.

Even assuming that PyPy does actually manage to reach within a magnitude
of C with the extra effort required to leverage two languages, why
would I bother when I can do it with one?  PyPy and similar methods
where great when there was no other mid level alternative that supported
Python like features.  Now it just seems like using Python as a hammer
for every problem whether or not it is the right tool for the job.

>>> Go is also not an ideal language for enterprise development. It
>>> provides no compatibility or support guarantees; in fact, the website
>>> describes it as 'an experiment' and recommends it for 'adventurous
>>
>> There is no doubt that it is a young project and there are a number of
>> things that will need to be improved to be effective for some branches
>> of programming; but, that isn't a language restriction.
>
> It will nevertheless preclude its use in most enterprise software
> development. That's most systems software.

So you conclude that because it is not quite ready for prime time yet that it
never will be?  I can remember when people said C++ would never amount to
anything either.

>> Database bindings are another weak link outside of the more common
>> open source databases.  In both cases, Go readily capable of C library
>> functions as a stop-gap until a native wrapper is available.  Yes it will
>> be nice once community has filled in the gaps; but, I am rather impressed
>> at what is already available in less then a years time.  There are a few
>> libraries you may have missed here:
>
> Sounds like a two-language solution, ie, the thing you criticized Python for.

Not quite.

1. My arguments for dual language solutions where never directed at Python
	proper.   They were directed at PyPy.  I am rather amazed at
	the number of things that can be accomplished in Python without
	having to bind to C.

2. There is a difference in binding to a solution that is already written
	in another language so as to not reinvent a wheel and implementing
	a *new* library in another language to be used exclusively
	with Python.