3 ms·

I'm in a similar boat... Been programming python for ages, and now working on a huge, shared "hyper-agile" (yes they really call it that) code base. It's consta

I'm in a similar boat... Been programming python for ages, and now working on a huge, shared "hyper-agile" (yes they really call it that) code base. It's constantly breaking, even with unit tests! Personally, I'd love to be doing multi person large project stuff in Haskell... I can dream :-)

bsaul 13y ago
I had a look at Haskell, but i wonder whether Haskell couldn't become an abstraction mess either once the project reaches a certain size. Every time i have a look at Haskell snippets, i feel like i'm reading math. I'd like to read code like i read english...
- marcosdumay 13y ago
  I guess it was meant to read like math. I think Haskell has the same problem as Lisp. Since you can abstract lots and lots of things away, there are tons of codebase specific abstractions that developers must keep on their heads before they can start coding. That said, the Haskell situation is better than Lisp's, because it has a big set of "default" abstractions that become part of the language, reducing the number of codebase specific ones.
- kruipen 13y ago
  Interesting that you would say that. To me Haskell often feels like the most reads-like-English language; e.g. Parsec parsers written in applicative style, or function in pointfree style. Of course that is not true of all Haskell constructs...
- boothead 13y ago
  I find that the unit of abstraction is smaller and more manageable in Haskell. What I mean by that it that there are a core set of abstractions based on mathematical laws that are ubiquitous and compose-able. Once you understand them and how they work together you see them everywhere and can very quickly understand new code you see. Contrast this with python or other more mainstream languages; you have similar "patterns" with inconsistent naming and implementation details which you first have to grok - every time mind - before you can start to understand the code.
- FreeFull 13y ago
  To see what Haskell is like for larger projects, you could go and have a look at GHC's or xmonad's code, although GHC does use some conventions that most Haskell code doesn't.

bsaul 13y ago

I had a look at Haskell, but i wonder whether Haskell couldn't become an abstraction mess either once the project reaches a certain size. Every time i have a look at Haskell snippets, i feel like i'm reading math. I'd like to read code like i read english...

marcosdumay 13y ago
I guess it was meant to read like math. I think Haskell has the same problem as Lisp. Since you can abstract lots and lots of things away, there are tons of codebase specific abstractions that developers must keep on their heads before they can start coding. That said, the Haskell situation is better than Lisp's, because it has a big set of "default" abstractions that become part of the language, reducing the number of codebase specific ones.
kruipen 13y ago
Interesting that you would say that. To me Haskell often feels like the most reads-like-English language; e.g. Parsec parsers written in applicative style, or function in pointfree style. Of course that is not true of all Haskell constructs...
boothead 13y ago
I find that the unit of abstraction is smaller and more manageable in Haskell. What I mean by that it that there are a core set of abstractions based on mathematical laws that are ubiquitous and compose-able. Once you understand them and how they work together you see them everywhere and can very quickly understand new code you see. Contrast this with python or other more mainstream languages; you have similar "patterns" with inconsistent naming and implementation details which you first have to grok - every time mind - before you can start to understand the code.
FreeFull 13y ago
To see what Haskell is like for larger projects, you could go and have a look at GHC's or xmonad's code, although GHC does use some conventions that most Haskell code doesn't.