9 ms·

I wasn't really trying to convince anyone to use Haskell at their day job: I am just a college student, after all, so I would have no idea what I was talking ab

by oisdk 7y ago

I wasn't really trying to convince anyone to use Haskell at their day job: I am just a college student, after all, so I would have no idea what I was talking about! I wrote the article a while ago after being frustrated using a bunch of Go and Python at an internship. Often I really wanted simple algebraic data types and pattern-matching, but when I looked up why Go didn't have them I saw a lot of justifications that amounted to "functional features are too complex and we're making a simple language. Haskell is notoriously complex". In my opinion, the `res, err := fun(); if err != nil` (for example) pattern was much more complex than the alternative with pattern-matching. So I wanted to write an article demonstrating that, while Haskell has a lot of out-there stuff in it, there's a bunch of simple ideas which really shouldn't be missing from any modern general-purpose language. As to why I used a binary tree as the example, I thought it was pretty self-contained, and I find skew heaps quite interesting.

reificator 7y ago
> > functional features are too complex and we're making a simple language. Haskell is notoriously complex This is a true statement. (Opinion yada objective yada experience yada) > In my opinion, the `res, err := fun(); if err != nil` (for example) pattern was much more complex than the alternative with pattern-matching. This is also a true statement. (yada yada) The insight I think you're missing is this piece right here: `we're making a simple language`. Their goal is not necessarily to make simple application code. That's your job, and you start that process by selecting your tools. For certain tasks, pattern matching is a godsend. I'm usually very happy to have it available to me when it is. And I do often curse not having it available in other languages to be honest. But Go users typically have different criteria for what makes simple/reliable/maintainable/debugable/"good" code than Haskell users have. Which is why the two languages are selected by different groups of people handling different tasks. You're making a tradeoff between features and limitations of various languages. And the language designers have an even different criteria for those things. In this case, adding pattern matching would absolutely make the language itself more complex, and they apparently don't believe that language complexity is worth the benefits of pattern matching. I think that's a perfectly reasonable stance to take.
- oisdk 7y ago
  I'm not sure if I understand you: the `res, err := fun(); if err != nil` pattern shows up everywhere in most Go code, and I think that pattern-matching would be a better fit for it. Swift does it pretty well, as does Rust, both of which occupy a similar space to Go. I get that there's a tradeoff with including certain features, I suppose I disagree that the tradeoff is a negative one when it comes to things as simple as pattern-matching, and I think it should be included in languages like Go.
  - deleted 7y ago
    [deleted]
  - reificator 7y ago
    I'm not arguing against pattern matching. Like I said, I prefer it where possible. I'm also not arguing in favor of multiple return with mandatory checked err values. (Though I prefer either over the collective insanity that went into making exceptions the default approach to handling errors in most languages.) I'm just pointing out that I think you're missing a key word in the stance of the go language developers. They're not saying that if err != nil is better or worse, simpler or more complex, etc... than pattern matching for application code. They're saying that supporting pattern matching makes the language itself more complex, and they're not in favor of that tradeoff. You're focusing on application complexity, and that's a very different thing. Both the go language authors as well as the kind of developers that choose to use go think of the relative simplicity of the language itself as a feature. Even if it causes the application code to be slightly more complex. It's just another dimension that can be used when comparing programming languages, and one that group tends to value more than other groups.
    - oisdk 7y ago
      Oh ok, I understand. I don't really buy the idea that go is a simple language, I have to say. A lot of go's design choices read (to me) as needlessly complex, like features were added to address corner cases one by one instead of implementing the fundamental feature in the first place. "Multiple return values" instead of tuples; several weird variations on the c-style for-loop; special-cased nil values instead of `Maybe` or `Optional`; `interface {}` and special in-built types instead of generics, etc. ADTs and pattern-matching would obviate "multiple return values", nils, and greatly simplify error handling.

by oisdk 7y ago

reificator 7y ago

> > functional features are too complex and we're making a simple language. Haskell is notoriously complex This is a true statement. (Opinion yada objective yada experience yada) > In my opinion, the `res, err := fun(); if err != nil` (for example) pattern was much more complex than the alternative with pattern-matching. This is also a true statement. (yada yada) The insight I think you're missing is this piece right here: `we're making a simple language`. Their goal is not necessarily to make simple application code. That's your job, and you start that process by selecting your tools. For certain tasks, pattern matching is a godsend. I'm usually very happy to have it available to me when it is. And I do often curse not having it available in other languages to be honest. But Go users typically have different criteria for what makes simple/reliable/maintainable/debugable/"good" code than Haskell users have. Which is why the two languages are selected by different groups of people handling different tasks. You're making a tradeoff between features and limitations of various languages. And the language designers have an even different criteria for those things. In this case, adding pattern matching would absolutely make the language itself more complex, and they apparently don't believe that language complexity is worth the benefits of pattern matching. I think that's a perfectly reasonable stance to take.

oisdk 7y ago
I'm not sure if I understand you: the `res, err := fun(); if err != nil` pattern shows up everywhere in most Go code, and I think that pattern-matching would be a better fit for it. Swift does it pretty well, as does Rust, both of which occupy a similar space to Go. I get that there's a tradeoff with including certain features, I suppose I disagree that the tradeoff is a negative one when it comes to things as simple as pattern-matching, and I think it should be included in languages like Go.
- deleted 7y ago
  [deleted]
- reificator 7y ago
  I'm not arguing against pattern matching. Like I said, I prefer it where possible. I'm also not arguing in favor of multiple return with mandatory checked err values. (Though I prefer either over the collective insanity that went into making exceptions the default approach to handling errors in most languages.) I'm just pointing out that I think you're missing a key word in the stance of the go language developers. They're not saying that if err != nil is better or worse, simpler or more complex, etc... than pattern matching for application code. They're saying that supporting pattern matching makes the language itself more complex, and they're not in favor of that tradeoff. You're focusing on application complexity, and that's a very different thing. Both the go language authors as well as the kind of developers that choose to use go think of the relative simplicity of the language itself as a feature. Even if it causes the application code to be slightly more complex. It's just another dimension that can be used when comparing programming languages, and one that group tends to value more than other groups.
  - oisdk 7y ago
    Oh ok, I understand. I don't really buy the idea that go is a simple language, I have to say. A lot of go's design choices read (to me) as needlessly complex, like features were added to address corner cases one by one instead of implementing the fundamental feature in the first place. "Multiple return values" instead of tuples; several weird variations on the c-style for-loop; special-cased nil values instead of `Maybe` or `Optional`; `interface {}` and special in-built types instead of generics, etc. ADTs and pattern-matching would obviate "multiple return values", nils, and greatly simplify error handling.