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

[geremy condra]

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.

>>>> 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.

We're a year past the initial announcement that it was ready. It's
still 'an experiment'. It doesn't have a ratified standard, committee,
or governing body. The company that developed it seems to have no
interest in enterprise support. They haven't done any serious
marketing for it since the initial release. Five years is, to put it
mildly, an overly enthusiastic timeline for the development of
broad-based industry support under those conditions.

>>> 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.

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

> 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?

Geremy Condra