6 ms·

Haskell I've seen often looks a lot like mathematical equations to me, where the tradition is that the notation is terse, with single letter variables (possibly

by x1798DE 10y ago

Haskell I've seen often looks a lot like mathematical equations to me, where the tradition is that the notation is terse, with single letter variables (possibly with primes or other modifiers) is the norm.

dpc_pw 10y ago
Very clever way to make sure the programming language never gains any significant traction. ;)
- gizmo686 10y ago
  Haskell: avoid success at all costs.
  - Ixiaus 10y ago
    Only if your program doesn't type-check ;)
  - bitwize 10y ago
    Obviously the solution is to encode success into the type system, such that functions which increase the chance Haskell will become a mainstream programming language fail to type-check.
  - Magnap 10y ago
    People keep saying this as if it were meant to be parsed "(avoid success) (at all costs)", but in fact it's supposed to be "avoid (success at all costs)", in other words "principles > popularity".
    - dllthomas 10y ago
      I've always understood it to be, simultaneously, jokingly the former and seriously the latter.
- mrkgnao 10y ago
  https://xkcd.com/1312/ https://xkcd.com/1312/
bloaf 10y ago
I've thought that Haskell should consider resurrecting the old convention of putting a commented header at the beginning of their code that explains the single-letter notation in a more friendly way. Then they can have their terse syntax but make things a little friendlier for newcomers.
- mrkgnao 10y ago
  Javadoc-like comments ("Haddocks") are pretty widely used, and Hackage (the Haskell library index) let's you browse them and so on. See [0] for a good example of well-commented but idiomatic Haskell (a snippet from the popular Megaparsec parser library), which includes things like: data ParsecT e s m a ParsecT e s m a is a parser with custom data component of error e, stream type s, underlying monad m and return type a. Admitted, that is a monad transformer, but one-character type variables with human-readable docs are both good for newcomers as well as low-friction for people who are used to the library in question. (Strawman alert.) It is significantly more work to parse (ha) something like ExceptT fooException (StateT fooWorldState underlyingMonad) a when compared to ExceptT e (StateT s m) a [0]: https://hackage.haskell.org/package/megaparsec-5.2.0/docs/Text-Megaparsec.html https://hackage.haskell.org/package/megaparsec-5.2.0/docs/Te...
  - dllthomas 10y ago
    It's also worth noting that there are conventions around type variable names. If you see an `m`, it's probably a Monad; if you see an `s`, it's probably a stream or a struct or state; `i` is likely being indexed over; the code probably doesn't care what `a` is - the surrounding code can pick it freely. If you need another, advance to the next letter (`b`, `c`, less often `n`, `o`). Of course, Edward Kmett had a story about winding up with his code telling him `i m a s t a b u`...
    - mrkgnao 10y ago
      f for a functor is also very common, as is k for "continuations", very generally speaking (I think this is a borrowing from Lisps?): one often sees monadic bind defined as m >>= k = ... In a somewhat more esoteric vein, I love the use of w for comonads: the rationale is apparently that it looks like an upside-down m. > Of course, Edward Kmett had a story about winding up with his code telling him `i m a s t a b u`... Is that an indexed lens ... parameterized over a monadic type? I'd like a link to the video/article.
Ixiaus 10y ago
It certainly inherits a lot from that culture but there's a fast-growing number of industry programmers using Haskell that are bringing more approachable styles to the language; most notably: using partial functions as little as possible, using let bindings more often, using applicative-do, making variables names a bit more descriptive when it makes the waters clearer, using descriptive data type names, documenting the fields of records, documenting the arguments to a function if the types don't make it crystal clear, etc.
- zzleeper 10y ago
  Is there a style guide for that? Looks incredibly useful (i.e. a Haskell pep8)
  - mrkgnao 10y ago
    https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md https://github.com/tibbe/haskell-style-guide/blob/master/has...
- girvo 10y ago
  Interestingly, what you've described sounds a lot like most of the OCaml I've come across (and written). I suppose that makes sense, really!
  - fmap 10y ago
    That's a relief. All the OCaml that I've seen has been a horrible mess of single character identifiers without comments or type annotations...
ansgri 10y ago
That is, they inherit the worst aspect of math notation.

by x1798DE 10y ago

dpc_pw 10y ago

Very clever way to make sure the programming language never gains any significant traction. ;)

gizmo686 10y ago
Haskell: avoid success at all costs.
- Ixiaus 10y ago
  Only if your program doesn't type-check ;)
- bitwize 10y ago
  Obviously the solution is to encode success into the type system, such that functions which increase the chance Haskell will become a mainstream programming language fail to type-check.
- Magnap 10y ago
  People keep saying this as if it were meant to be parsed "(avoid success) (at all costs)", but in fact it's supposed to be "avoid (success at all costs)", in other words "principles > popularity".
  - dllthomas 10y ago
    I've always understood it to be, simultaneously, jokingly the former and seriously the latter.
mrkgnao 10y ago
https://xkcd.com/1312/ https://xkcd.com/1312/

bloaf 10y ago

I've thought that Haskell should consider resurrecting the old convention of putting a commented header at the beginning of their code that explains the single-letter notation in a more friendly way. Then they can have their terse syntax but make things a little friendlier for newcomers.

mrkgnao 10y ago
Javadoc-like comments ("Haddocks") are pretty widely used, and Hackage (the Haskell library index) let's you browse them and so on. See [0] for a good example of well-commented but idiomatic Haskell (a snippet from the popular Megaparsec parser library), which includes things like: data ParsecT e s m a ParsecT e s m a is a parser with custom data component of error e, stream type s, underlying monad m and return type a. Admitted, that is a monad transformer, but one-character type variables with human-readable docs are both good for newcomers as well as low-friction for people who are used to the library in question. (Strawman alert.) It is significantly more work to parse (ha) something like ExceptT fooException (StateT fooWorldState underlyingMonad) a when compared to ExceptT e (StateT s m) a [0]: https://hackage.haskell.org/package/megaparsec-5.2.0/docs/Text-Megaparsec.html https://hackage.haskell.org/package/megaparsec-5.2.0/docs/Te...
- dllthomas 10y ago
  It's also worth noting that there are conventions around type variable names. If you see an `m`, it's probably a Monad; if you see an `s`, it's probably a stream or a struct or state; `i` is likely being indexed over; the code probably doesn't care what `a` is - the surrounding code can pick it freely. If you need another, advance to the next letter (`b`, `c`, less often `n`, `o`). Of course, Edward Kmett had a story about winding up with his code telling him `i m a s t a b u`...
  - mrkgnao 10y ago
    f for a functor is also very common, as is k for "continuations", very generally speaking (I think this is a borrowing from Lisps?): one often sees monadic bind defined as m >>= k = ... In a somewhat more esoteric vein, I love the use of w for comonads: the rationale is apparently that it looks like an upside-down m. > Of course, Edward Kmett had a story about winding up with his code telling him `i m a s t a b u`... Is that an indexed lens ... parameterized over a monadic type? I'd like a link to the video/article.

Ixiaus 10y ago

It certainly inherits a lot from that culture but there's a fast-growing number of industry programmers using Haskell that are bringing more approachable styles to the language; most notably: using partial functions as little as possible, using let bindings more often, using applicative-do, making variables names a bit more descriptive when it makes the waters clearer, using descriptive data type names, documenting the fields of records, documenting the arguments to a function if the types don't make it crystal clear, etc.

zzleeper 10y ago
Is there a style guide for that? Looks incredibly useful (i.e. a Haskell pep8)
- mrkgnao 10y ago
  https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md https://github.com/tibbe/haskell-style-guide/blob/master/has...
girvo 10y ago
Interestingly, what you've described sounds a lot like most of the OCaml I've come across (and written). I suppose that makes sense, really!
- fmap 10y ago
  That's a relief. All the OCaml that I've seen has been a horrible mess of single character identifiers without comments or type annotations...

ansgri 10y ago

That is, they inherit the worst aspect of math notation.