[OT] Python like lanugages

[Tim Harig]

On 2011-01-17, Paul Rubin <no.email at nospam.invalid> wrote:
> geremy condra <debatem1 at gmail.com> writes:
>> 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 ....
>> 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.
>
> You know, the functional programming community seems to think of OOP as
> a 1990's thing that didn't work out.  Most things that can be done with
> OOP, can be done with higher-order functions and bounded polymorphism
> like in Haskell.

Which is rather interesting because the OOP community had traditionally
though of functional programming as a 1960's thing that didn't work out.
Functional programming has been around a long time; but, it only regained
conciousness outside of academia because of its hyped abilities to
make threading easier.  Unfortunately for functional programming,
much of that ability actually traces back to MPI and the actor model.
Using the actor model, it is possible to reap the benefits of easier
multiprocessing without using any functional programming concepts.

That isn't to say that the injection of functional programming into the
mainstream will not have some good affects overall.  I expect to see
functional programming concepts being incorporated into guidelines for
imperative language use.

> I'm not sure, but I don't think Erlang has exceptions in the sense we're
> used to.  Someone mentioned Erlang uses a VM, but I think there is a

Erlang has exceptions that look very much like Python exceptions.

> native compiler called HIPE.  Of course there is still a fairly
> substantial runtime system, but that's true of any language with a
> garbage collector and so forth.

Which is why I say Erlang doesn't compile to a native binary.  HIPE has
been available through the standard OTP for some time now.  HIPE generates
native machine OP codes where possible; but, the generated product must
still run on the BEAM runtime system.  The end result is much faster then
Python and often faster then Java with a JIT; but, still doesn't rival
C code.  It is possible to optimize things quite a bit by integrating with
C code; but, then you loose much of the safety provided by Erlang and BEAM.

This isn't such a tragedy Erlang as it is for other managed VMs because
Erlang/BEAM makes powerful usage of its VM for fault tolerance mechanisms.  I
don't know of any other VM that allows software upgrades on a running system.