4 ms·

There's nothing a priori clear about punctuation like [ ] { }, you're just used to seeing lots of syntactic markers.

• lmm 12y ago
  Sure. But many languages have a standard way of defining what's a function declaration, what's a function definition, what's a type definition, what's a function parameter, what's a type parameter, what's a function call, what's a type instantiation; it doesn't really matter what the specifics are, what matters is that there are standard indicators that stand out from the code (and I think there is a sense in which []{} are a priori more visible in the middle of a paragraph than letters are). Haskell doesn't seem to have that; any piece of Haskell code tends to look like a smooth surface of words separated by spaces. Function? Words separated by spaces. Type? Words separated by spaces. Instance? Words separated by spaces. There are no visual handles to latch onto, nothing to help you realise how this stream of words separated by spaces forms a tree structure (AST).
  • dons 12y ago
    > There are no visual handles to latch onto Haskell uses syntax and context to distinguish identifiers as follows: - variables, lower case initial letter - constructors, upper case initial letter - type variables, lower case initial letter - type constructor, upper case initial letter and similarly for classes and modules. And of course, white space is function application. So you know if it is a variable or a constructor by looking at the first letter. And you know if it is a value-level variable or a type-level variable (or constructor) by context (types can only appear in certain places, e.g. on the right hand side of `::`). But, yes, they all look like words. They're not ambiguous though. :)
  • sbergot 12y ago
    I understand this feeling, but it goes away after a bit of practice. In java/go/c#, there are lots of statement and small expressions. In haskell expressions tends to be longer and are broken down in multiple local definitions (with let or where). You learn to recognize important words (fmap, forM_, $, etc). You also learn to recognize how those words are associated, and how data is passed around. Granted, there are people who abuse point-free notation to build complex and hard to read expressions. However I find that a codebase with rich informative types and a reasonable coding rule set is very pleasant to read.
    • codygman 12y ago
      Point free can be used to have something similar to Unix pipelines as well though, resulting in simple, fast, and readable code.