[chongli]

explore the possibilities available in Haskell and then increase the complexity.

I'd caution against referring to all such explorations as complexity. Complexity is a highly overloaded term in our field. Sometimes it refers to the number of steps a given algorithm takes to compute (as a function of the input). Sometimes it refers to the depth and breadth of a program's syntax tree as well as its tendency to branch out and create cycles.

Sometimes it's mistakenly used to refer to concepts which are in reality simple but merely unfamiliar or non-intuitive. This last usage is a big problem for languages outside the mainstream which are trying to find better ways of writing software.

[skrebbel]

What the...? You know full well what kind of complexity the GP refers to, and it's not cyclomatic or algorithmic complexity, and definitely not unfamiliarity.

Is this a new kind of HN trolling? Instead of directly disagreeing with an argument on it's merits, you call a commenter out on possibly ambiguous terminology and use that to dismiss the entire comment?

Your entire lecture is true, but it does not apply to the sentence you quoted at all. That sentence is about some Haskellers' tendency to sacrifice readability in favor of better static checks. He could've written "difficult to understand" instead of "complex" and his comment wouldn't have changed meaning and your entire comment would've been void.

[munro]

> I'd caution against referring to all such explorations as complexity. Complexity is a highly overloaded term in our field.

The difference between complex & hard, easy & simple has been put very elegantly by Rich Hickey in Simple Made Easy [1]. That doesn't mean everyone agrees with his definitions, which is why he revives the word "complected" to mean objective interleaving of concepts, and pulls out "hard" from the way people use complex to mean something one is unfamiliar with. I like his definitions, so I use them. :)

> Sometimes it refers to the number of steps a given algorithm takes to compute

This can still create ambiguity since it could be either time or memory complexity, but still easy to infer, especially if there's a big O.

> depth and breadth of a program's syntax tree

Lisp overloads the parens for difference concepts, which is complex. This could also be hard if one's not familiar with the syntax.

> tendency to branch out and create cycles

Sounds like time complexity!

> Sometimes it's mistakenly used to refer to concepts which are in reality simple but merely unfamiliar or non-intuitive.

This is the ambiguity, is he saying Haskell complex because it has a lot of interleaving with it's concepts, that other languages do not? Or is it just unfamiliar? I would think it's simpler because it forces one to think about how time interleaves the program, which could make things harder! I'm guessing this is what the grand parent means, since ML is impure. Though, either case is empty without examples.

[1] http://www.infoq.com/presentations/Simple-Made-Easy

[chongli]

Yeah, I've seen that presentation. Rich's ideas were what I had in mind when I wrote my reply.

In general, use of highly overloaded words is ambiguous in these discussions.

[capisce]

Accidental complexity is one of the biggest enemies of productivity in the programming world.