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

[geremy condra]

On Mon, Jan 17, 2011 at 1:12 AM, Tim Harig <usernet at ilthio.net> wrote:
> On 2011-01-16, geremy condra <debatem1 at gmail.com> wrote:
>> On Sun, Jan 16, 2011 at 3:03 AM, Tim Harig <usernet at ilthio.net> wrote:
>>> On 2011-01-16, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>>>> If the author thinks that Go is a "tried and true" (his words, not mine)
>>>> language "where programmers can go to look for work", I think he's
>>>> fooling himself.
>>>
>>> No I wouldn't say that it has reached market penetration yet; but, it
>>> has more momentum then any language I am familiar with.  I wouldn't be
>>> at all surprised to see it becoming quite common in the next five years.
>>
>> I would be very surprised if this were the case. As you point out,
>> languages typically have very long incubation times before they reach
>> any kind of serious market penetration. This seems doubly true for a
>> relatively narrowly targeted language that is in many ways on the
>> wrong side of history.
>
> I wouldn't say Go is narrowly targeted.  It's a systems language that can
> compete in the same domain with scripting languages.  It is true that most
> languages have long incubation periods; but, corporate support can change
> that quite a bit.  C#, being backed by Microsoft, managed to go mainstream
> pretty quickly.

This seems... shall we say, overly optimistic. I've seen no evidence
at all that Go is even trying to compete with scripting languages, and
I don't know of anyone who would actually use it where a shell script
might do. AFAICS, it is an unabashedly concurrency-centric systems
language for people who are willing to sacrifice some speed and
control for legible code. That's not an impossibly narrow niche (and
it certainly has deep pockets) but it *is* narrow compared to a
general purpose language like Java or Python.

I'd also note that the .NET languages received much, much more in the
way of support than Go seems to be.

>>> How long has it taken Python to reach its present level of market
>>> penetration?  And, I still don't see a huge amount of professional Python
>>> use outside of web developement.  Go has only been public for less then
>>> a year.
>>
>> Python's very widely used for scripting and related tasks, and has a
>> pretty big user base in academia and the sciences.
>
> Python has been widely used by people like us that happen to like the
> language and found ways to use it in our workplaces; but, most of the
> time it is an unofficial use that the company.  You still don't see many
> companies doing large scale internal development using Python and you
> definately don't see any doing external developement using a language
> that gives the customers full access to the source code.

Right, I mean, it's not like the company that wrote Go would *ever*
stoop to using Python ;)

Seriously, I see a lot of Python in use in the sciences, HPC, etc.
It's also a major part of nearly every linux distro, is widely used by
defense and intelligence contractors for what they consider to be
critical infrastructure, etc etc etc. Even if none of that were true
though, the fact is that you can be a successful language and only
deal with the web, and even you admit that Python is widely used in
that context.

>>> Personally, I think the time is ripe for a language that bridges the
>>> gap between ease of use dynamic languages with the performance and
>>> distribution capabilities of a full systems level language.
>>
>> I agree. That does not make Go that language, and many of the choices
>> made during Go's development indicate that they don't think it's that
>> language either. I'm speaking specifically of its non-object model,
>> lack of exceptions, etc.
>
> 1. Go has an object model.  What it lacks is an object hierarchy where all
>        object are decended from a single root "object" since it does
>        not support object inheritance as it is used in most languages.
>        In Go we simply adapt an object to meet the needs of the newer
>        object by adding whatever new functionality is needed.

Go has structs. Its structs are not objects, principally because they
can't do real inheritance. You can do similar things ('structural
inheritance') to C structs, and nobody argues that C is OO.

> 2. Go has a similar mechanism to exceptions, defer/panic/recover.  It does
>        downplay

Defer, panic, and recover only allow you to build a recovery stack.
That's like saying that try/except isn't needed anymore because you
have the with statement. Do you think you could get through a rewrite
of Django without ripping out some hair over that?

>>>This is after all the promise the VM based languages made but never
>>> really fulfilled. It is also high time for a fully concurrent language fully
>>> capable of taking advantage of multicore processors without having to
>>> deal with the inherent dangers of threading.  There are several good
>>> choices available for both a even a few that fit both bills; but, few of
>>> them have the support of a company like Google that is capable of the
>>> push required to move the language into the mainstream.
>>
>> You might be right, but I doubt we'll know one way or the other in the
>> next 5 years. Personally, I'm hoping that functional language use
>> continues to grow.
>
> I personally doubt that purely functional languages will ever make it
> mainstream.  Functional programming has been around for a long time and
> never really ever managed to break out of academic research.

I doubt it as well. Doesn't mean I can't hope for it- I would really
like to see something a little more readable out of that community, a
kind of hybrid between haskell's writability and python's readability.

> The current
> interest in functional programming stems merely because some announced
> that it would be *the* way to utilize multicore computers.  Having looked
> into the space somewhat, there is more hype then substantiation for
> purely functional concepts.  What the hype did do was return attention
> to SCP style concurrency using actors and MPI and I think that will be
> the direction taken for concurrent programming into the future.

I'm not an expert in concurrency and can't evaluate the claims many
are making in that space. I know that I still find writing highly
parallel programs easier in C and Python than I do in Haskell, but I
seldom wind up thinking that concurrency was the hard part of the
problem I was solving.

> I believe functional programming will make an impact in the mainstream in
> the form of functionally enabled multiparadigm but not purely functional
> languages.  I think you will see code that uses more functional concepts
> as guidelines to better code.

Ditto.

Geremy Condra