

Python vs Haskell : An unsatisfying exercise in comparative code linguistics - mbrubeck
http://sandersn.com/blog//index.php/2010/01/05/python-vs-haskell-an-unsatisfying-exerci

======
jrockway
Adding type constraint checks to dynamic languages is not "horrifying". It's
merely using the language to extend the language; where you want type checks,
you can have type checks.

~~~
baguasquirrel
It's pretty horrifying from a performance perspective.

~~~
jrockway
It's pretty nice from a correctness perspective. If you cared about
performance, you would not be using Python (or Ruby, or Perl).

~~~
nudded
If you cared about type constraints you would not be using Python (or Ruby, or
Perl).

~~~
kingkilr
Far more interesting (IMO), would be a constrains based library based on
predicates (iterable, hashable, arithmatic-able?)

~~~
nudded
In ruby you can ensure this by calling responds_to?(:method).

So for example to see if some object is iterable, you just check if it
responds to each.

    
    
       obj.responds_to?(:each)

~~~
jrockway
That doesn't guarantee that "each" is actually the right "each".

------
JabavuAdams
This was interesting to me. I'm learning Haskell right now, after using Python
as my main prototyping / glue / tools language (I get paid to write in C++ and
Objective-C).

The horrifyingly broken performance of the Python Global Interpreter Lock
(GIL) on multi-core has me looking for an alternative for performance-
sensitive higher-level code.

Typically I experiment with a new higher-level language, and then fall back on
"I'll meta-program in the high-level language, and emit portable C code."
Sigh.

