[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 Tue, Jan 18, 2011 at 11:05 AM, Tim Harig <usernet at ilthio.net> wrote:
>> 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.
>
> You clearly have no idea what you're talking about regarding PyPy. You
> could at least have googled it before speaking about it.

No, I have watched several such projects over the years.  Pysco, Unladen
Swallow, Cython, PyPy, Shedskin, etc.  Source to source translators, JITs,
and C language integration all just add to complexity.  You can't do this,
you can't do that, you have to learn a new way of doing something else,
ad nauseum.

So when something new that provided Python like capabilities without many
of Python's drawbacks came along, I jumped on it.  It provides a much
cleaner solution to the problem without kludges.  I will use Python for
what it does well and cleanly.  For the rest, there are now better tools.
Once again, its about the right tool for the right job.

> Again, you don't know what you're talking about WRT PyPy.

Nor do I really want to.  I have found a much simpler solution
to the problem.  I would recommend it to many others that like the
Python language but who occassionaly struggle with its implementation
constraints.

I would say that I am sorry that it doesn't work for you; but, you seem
to prefer Java and Pypy anyway so we are both happy.

>> 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.
>
> Even if that binding is done for performance reasons?

Yep, that is pretty much the summation of my dual language argument.
I don't expect a pure Python implementation of curses since there is a
perfectly good C library available to bind to.  Why reinvent the wheel.

Resorting to writing packages in another language or compiling Python
code into another source language is a kludge necessary because of
the performance characteristics of the language.  I suppose that is
an acceptable kludge when that is your only alternative.  For me it no
longer is.