Hacker News Reader

Comment by lmm | Hacker News Reader

Agree with a lot of this, but I find the lack of any punctuation one of the most confusing things about Haskell code.

    Map String Any

Is that a function call? A type declaration? What's a parameter to what? The go style

    map[string]interface{}

is, much as I love to hate on all things go, much clearer.

View on HN

I disagree. You are merely used to different conventions. In haskell, symbols starting with an uppercase are types (or Constructors). You can think about Map as a type constructor which takes two other types as its arguments. So Map Foo Bar is a Map with Foo as keys and Bar as values.

In the go version [] is used for both indexing and type definition.

> Is that a function call, A type declaration?

If its following a "::" then its part of a type signature and its a type constructor application. Otherwise, its part of an expression and its a regular function call.

BTW, Haskell capitalization is significant in Haskell. Identifiers starting with lower case are always regular functions. Types and type constructors always start with upper case.

> What's a parameter to what?

Application in Haskell is left associative so its

    ((Map String) Any)

Haskell is a functional language and programs are filled with function applications so using spaces for function application avoids a lot or syntactic noise. The only time I find this really bites me is that, due to automatic currying, passing the wrong number of arguments to a function can lead to hairy type errors. This is not a big deal if you use add a healthy amount of type annotations to your code though.

  Application in Haskell is left associative so its

  ((Map String) Any)

You seem to have stumbled on the exact conflict. Anybody who's seen the theory of lambda calculus will recognize the significance of what you've written, and how it applies to partial binding of functions.

Anybody who hasn't will either be thinking of lisp or just be totally confused.

This is where the conflict is. Many developers actually know some programming theory and find Go woefully insufficient for anybody calling himself a programmer. And the ones that just fiddle around with things and make barely working programs without really knowing what they're doing are very happy that they don't have to know this in Go.

What's really going on is that people with real programming background find that Go forces them to think at the lowest possible level of abstraction, with no way up. And people without any programming background say "that's GREAT !".

I'd find it depressing if there was any programmer out there who had trouble understanding the concept of "left associativity". I think I learned it in high school.

He's talking about the concept of currying, not left-associativity.

Original question:

> What's a parameter to what?

Answer:

> Application in Haskell is left associative so its

> ((Map String) Any)

Which looks crystal clear to me. This is also the part of the answer that user waps later quoted.

GHC type errors are far from ideal.

But if you give too few or too many arguments, you usually do get an error like: "Perhaps `foo` is applied to too [many|few] arguments?"

The reason Map String Any does not contain any special symbols specific to that certain type is because it is not a built in special type like the Go map[string]interface{}.

It is just a regular type parametrized over two other types. And kinda that is the point - being expressive enough to describe a map type without explicit support.

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

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).

> 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. :)

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.

Point free can be used to have something similar to Unix pipelines as well though, resulting in simple, fast, and readable code.

Reply on news.ycombinator.com