4 ms·

Python vs Haskell : An unsatisfying exercise in comparative code linguistics

38 points by mbrubeck 17y ago

jrockway 17y ago
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 17y ago
  It's pretty horrifying from a performance perspective.
  - jrockway 17y ago
    It's pretty nice from a correctness perspective. If you cared about performance, you would not be using Python (or Ruby, or Perl).
    - nudded 17y ago
      If you cared about type constraints you would not be using Python (or Ruby, or Perl).
      - kingkilr 17y ago
        Far more interesting (IMO), would be a constrains based library based on predicates (iterable, hashable, arithmatic-able?)
        nudded 17y ago
        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 17y ago
        That doesn't guarantee that "each" is actually the right "each".
    - dagw 17y ago
      Just because you are using python doesn't mean that you have no interest in performance. Most apps don't need to be as fast as possible, but only fast enough. Adding a bunch of stuff that slows down python will decrease the set of problems where python is fast enough and thus usable. A large app I recently worked on is a python app interacting with a bunch of C++ libraries. The faster I could make my python code the more I can move stuff from C++ to python, which greatly decreases the time it takes to develop and change the app.
    - baguasquirrel 17y ago
      I will concede this point. Well put.
JabavuAdams 17y ago
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.
deleted 17y ago
[deleted]

38 points by mbrubeck 17y ago

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 17y ago
It's pretty horrifying from a performance perspective.
- jrockway 17y ago
  It's pretty nice from a correctness perspective. If you cared about performance, you would not be using Python (or Ruby, or Perl).
  - nudded 17y ago
    If you cared about type constraints you would not be using Python (or Ruby, or Perl).
    - kingkilr 17y ago
      Far more interesting (IMO), would be a constrains based library based on predicates (iterable, hashable, arithmatic-able?)
      - nudded 17y ago
        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 17y ago
        That doesn't guarantee that "each" is actually the right "each".
  - dagw 17y ago
    Just because you are using python doesn't mean that you have no interest in performance. Most apps don't need to be as fast as possible, but only fast enough. Adding a bunch of stuff that slows down python will decrease the set of problems where python is fast enough and thus usable. A large app I recently worked on is a python app interacting with a bunch of C++ libraries. The faster I could make my python code the more I can move stuff from C++ to python, which greatly decreases the time it takes to develop and change the app.
  - baguasquirrel 17y ago
    I will concede this point. Well put.

JabavuAdams 17y ago

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.

deleted 17y ago

[deleted]