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

[Tim Harig]

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.

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

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

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

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