6 ms·

How much of it was haskell, and how much of it was just working with a statically typed language?

ujal 9y ago
In my case the verbosity of Typescript or Flow stops me from adopting it. Still waiting for Elm/Haskell-style type signatures for Javascript.
szatkus 9y ago
Considering that Haskell type system is much more advanced than others (Java or C++ for example) I think it's a lot.
Jeff_Brown 9y ago
I used Java, C and C++ before coming to Python. Unlike theirs, Haskell's type system is complete -- even a function of functions can specify exactly what kinds of functions it uses for inputs and outputs. That makes higher order programming much safer -- and higher-order programming might be the best way to move fast. Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on a page, full of redundancies and boilerplate. In Haskell if you want to make, say, a data type that is either an X or an O (suppose you're writing tic-tac-toe), you could do it in four words: 'data XO = X | O'. (Notice that there's not even a natural way to do that in Java or C, because they don't have sum types; you'd have to make a type that has a flag to indicate whether it is an X or an O. That gets really complicated if they're supposed to have different data associated with it -- but in Haskell, if the X is supposed to carry a float and the O is supposed to carry a string, you just add two more words.) Pattern matching also helps with terseness. I don't have time even to write the last paragraph so I'll skip this one. Purity keeps you from tripping up on IO-related errors. It lets you be much more certain that things are working. It also forces you to keep the IO in a thin top-level layer of your program, which might sound like a pain but once it feels natural you'll find yourself moving faster than you could before. To be sure, Haskell has features that I don't use. But purity, sum types, pattern matching, and the unusually rigorous (it's complete!) type system are all critical to its value to me.
- woolvalley 9y ago
  That complicated type system w/ type inference does come with it's own costs, usually bad compile speed issues. It's what I've noticed when looking at languages like swift, rust, scala & haskell. I'm currently dealing with it in a large swift project, and I would much rather go back to the extra verbosity of objective-c than have type inference at this point. But that was insightful, thank you!
  - Jeff_Brown 9y ago
    Have you noticed slow compiling with Haskell specifically?
    - woolvalley 9y ago
      I've only used swift at that size, but I've heard stories with all of those languages once you have a large code base. I remember vaguely reading about how at a haskell conference people were basically cornering compiler maintainers about compile speed, but that was several years ago.
      - Jeff_Brown 9y ago
        When I have to recompile, it's usually because I've only modified a few files, and it's usually really fast. I particularly enjoy that if I refactor things without actually making any changes in the way it works, GHC won't blink; it knows there's nothing to do. My codebase is only a few thousand lines, though.
        woolvalley 9y ago
        Yeah the codebases I'm talking about are something around 1 million lines over several apps, libraries, all of the tests and codegened models, mocks and network services.
  - yawaramin 9y ago
    Check out OCaml (BuckleScript or ReasonML on the frontend, depending on which syntax you prefer). It has a super-fast compiler with almost total global type inference. The Facebook Messenger team report incremental builds of less than a second.

ujal 9y ago

In my case the verbosity of Typescript or Flow stops me from adopting it. Still waiting for Elm/Haskell-style type signatures for Javascript.

szatkus 9y ago

Considering that Haskell type system is much more advanced than others (Java or C++ for example) I think it's a lot.

Jeff_Brown 9y ago

I used Java, C and C++ before coming to Python. Unlike theirs, Haskell's type system is complete -- even a function of functions can specify exactly what kinds of functions it uses for inputs and outputs. That makes higher order programming much safer -- and higher-order programming might be the best way to move fast. Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on a page, full of redundancies and boilerplate. In Haskell if you want to make, say, a data type that is either an X or an O (suppose you're writing tic-tac-toe), you could do it in four words: 'data XO = X | O'. (Notice that there's not even a natural way to do that in Java or C, because they don't have sum types; you'd have to make a type that has a flag to indicate whether it is an X or an O. That gets really complicated if they're supposed to have different data associated with it -- but in Haskell, if the X is supposed to carry a float and the O is supposed to carry a string, you just add two more words.) Pattern matching also helps with terseness. I don't have time even to write the last paragraph so I'll skip this one. Purity keeps you from tripping up on IO-related errors. It lets you be much more certain that things are working. It also forces you to keep the IO in a thin top-level layer of your program, which might sound like a pain but once it feels natural you'll find yourself moving faster than you could before. To be sure, Haskell has features that I don't use. But purity, sum types, pattern matching, and the unusually rigorous (it's complete!) type system are all critical to its value to me.

woolvalley 9y ago
That complicated type system w/ type inference does come with it's own costs, usually bad compile speed issues. It's what I've noticed when looking at languages like swift, rust, scala & haskell. I'm currently dealing with it in a large swift project, and I would much rather go back to the extra verbosity of objective-c than have type inference at this point. But that was insightful, thank you!
- Jeff_Brown 9y ago
  Have you noticed slow compiling with Haskell specifically?
  - woolvalley 9y ago
    I've only used swift at that size, but I've heard stories with all of those languages once you have a large code base. I remember vaguely reading about how at a haskell conference people were basically cornering compiler maintainers about compile speed, but that was several years ago.
    - Jeff_Brown 9y ago
      When I have to recompile, it's usually because I've only modified a few files, and it's usually really fast. I particularly enjoy that if I refactor things without actually making any changes in the way it works, GHC won't blink; it knows there's nothing to do. My codebase is only a few thousand lines, though.
      - woolvalley 9y ago
        Yeah the codebases I'm talking about are something around 1 million lines over several apps, libraries, all of the tests and codegened models, mocks and network services.
- yawaramin 9y ago
  Check out OCaml (BuckleScript or ReasonML on the frontend, depending on which syntax you prefer). It has a super-fast compiler with almost total global type inference. The Facebook Messenger team report incremental builds of less than a second.