[OT] Python like lanugages [was Re: After C++, what with Python?]
Tim Harig
usernet at ilthio.net
Tue Jan 18 15:44:20 EST 2011
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.
More information about the Python-list
mailing list