4 ms·

> The idea that this composability is unique to Haskell is false. Haskell is one of the rare language/community where composability is the default. Even purel

> The idea that this composability is unique to Haskell is false. Haskell is one of the rare language/community where composability is the default. Even purely technically, few languages do composability as well as Haskell. The Gang of Four pattern you mention most likely work around weaknesses of Java. As such, they demonstrate the shortcomings of Java, not it's strengths. If you need a pattern that badly, make it a language feature, dammit. (Even without Lisp-style macros, source-to-source transformation is quite viable.) > But in my experience, the bigger part often has slightly different properties, behaviours, or uses which warrant a different type with more features. I'd say most of the time, you just failed to capture the commonalities. More specifically, you seek generality through exhaustiveness, when you should use genericness instead. If you stumble upon something that looks like a monoid, except for such and such detail, then the details probably need to be either removed (they're could be design bug), or integrated into a generic bucket or something. > For example, […] Those specs suck. Whoever asked you this don't understand their own needs, or are struggling with a legacy behemoth that should eventually be replaced. (EDIT: or, as mightybyte suggested, you just approached the problem the wrong way. Which strengthen my point about failing to see the commonalities.)

tel 13y ago
> I'd say most of the time, you just failed to capture the commonalities. More specifically, you seek generality through exhaustiveness, when you should use genericness instead. THIS is one of the most important things I've ever learned from programming Haskell[0]. The way to make things generic is to whittle away all of the sharp edges and implement them as compositions atop base patterns. Those base patterns arise out of polymorphism, not exhaustiveness. You don't make lists generic by realizing that you need a list type to have all the properties of a string, a tree, a vector... You make it generic by realizing that much of its structure arises by forgetting what's inside. [0] Which is not to say you can't learn it elsewhere, or that you cannot do it elsewhere. Instead, Haskell has the facility, the philosophy, and the community to do it really effectively all the time and so if you read Haskell code you'll be floored by some of the great examples possible there.
- loup-vaillant 13y ago
  Fun fact: I have known this intuitively since forever, but only recently realized that when I say "generic", most programmers I know tend to hear "exhaustive", and recoil in horror; while I really meant "generic". Now, I also know why I like parametric polymorphism, and dislike subclass polymorphism: the first is generic, while the second is exhaustive.
  - mushly 13y ago
    What's the difference between "generic" and "exhaustive," and where can I read more about all this stuff?
    - loup-vaillant 13y ago
      Imagine you want to process a list of foobarbaz, where elements can be foos, bars, or bazes. Exhaustion is when you write foo specific code, bar specific code, and baz specific code. Then your list-processing facility is general because it handles all the cases. A typical way to do that in practice is to use subtype polymorphism, with the class inheritance mechanism: have a foobarbaz interface, a foo class that implements it, a bar class that implements it, and a baz class that implements it. Each with their own code. Genericness is when you ignore the foobarbaz specifics altogether: your code doesn't even mention the types. A typical way to do that in practice is to use parametric polymorphism (generics in Java, templates in C++). See C++'s Algorithm library for an example, or the standard Prelude from Haskell, or the OCaml standard library.
  - tel 13y ago
    > Now, I also know why I like parametric polymorphism, and dislike subclass polymorphism: the first is generic, while the second is exhaustive. I'm going to steal that. I love it.
twic 13y ago
> Those specs suck. Whoever asked you this don't understand their own needs, or are struggling with a legacy behemoth that should eventually be replaced. That may or may not be true, but presumably you're not suggesting that Haskell is unsuitable for writing software for users whose specs suck, or don't understand their needs?
- marcosdumay 13y ago
  No language is suitable for writing badly specked software. And whatever language you are using, you'll get into troubles if not technical people start to make too many requirements about the way you organize your code (but don't despair, the first such requirement will be to not use Haskell).
  - seanmcdirmid 13y ago
    This doesn't really excuse the fact that Haskell is a harsh mistress that demands elegance. Many production languages are much more pragmatic about the quality of the spec, the quality of the developer, time constraints, and so on.
    - gridaphobe 13y ago
      One of my favorite quotes about Haskell is "We cannot afford QA teams, so we use a sadistic compiler".
    - Silhouette 13y ago
      This doesn't really excuse the fact that Haskell is a harsh mistress that demands elegance. I don't know how true that remains for expert Haskell programmers, but I agree that it's the way most introductory to intermediate material comes across. In academia, you are often looking for the most elegant tool in clean situations. In industry, you are often looking for the least clumsy tool in messy situations. Perhaps Haskell is a good choice in one context but a poor choice in the other, at least for those first learning it.
  - alkonaut 13y ago
jbooth 13y ago
The gang of four book predates Java the language. FYI. The book's written in Smalltalk.
- loup-vaillant 13y ago
  Now that is a surprise. Lemme check… https://en.wikipedia.org/wiki/Design_Patterns https://en.wikipedia.org/wiki/Design_Patterns Indeed. Written in 1994, and includes examples in Smaltalk… and C++. Now I know why it didn't rely on first class functions. It wasn't written in Smaltalk. It was written in the intersection of Smaltalk and C++. Sounds like Java, even though it didn't exit yet. Come to think of it, I wonder if they didn't have hints about this upcoming language from Sun. Java came out in 1995, but was in the works since 1991… So my point stands. If it were really written in Smaltalk, it wouldn't have needed insanities such as the Visitor pattern to work around the lack of closures. It would have used Smaltalk Blocks directly.
  - jbooth 13y ago
    Well, I'm glad you've concluded that you're still right.
    - loup-vaillant 13y ago
      Lose the sarcasm, please. If you still believe I'm wrong despite my documented arguments, I suggest you put forth documented counter-arguments. It will have two benefits: 1: You may convince me. I'm serious. I do not anticipate any strong counter arguments, but if they come, I will listen. (I did listen to your first argument. It troubled me, really, I was certain the book was written in Java. So I checked.) 2: You may show the other readers the error of my ways. Since my arguments are documented and relatively articulate, they will likely sway anyone who isn't committed to a particular position. You wouldn't want me to put false ideas in their heads.
      - deleted 13y ago
        [deleted]
deleted 13y ago
[deleted]
pjmlp 13y ago
> The Gang of Four pattern you mention most likely work around weaknesses of Java. Except it was written with Smalltalk and C++ in mind.
- GeneralMayhem 13y ago
  ...which, for relevant purposes, have the same basic flaws as Java.

tel 13y ago

> I'd say most of the time, you just failed to capture the commonalities. More specifically, you seek generality through exhaustiveness, when you should use genericness instead. THIS is one of the most important things I've ever learned from programming Haskell[0]. The way to make things generic is to whittle away all of the sharp edges and implement them as compositions atop base patterns. Those base patterns arise out of polymorphism, not exhaustiveness. You don't make lists generic by realizing that you need a list type to have all the properties of a string, a tree, a vector... You make it generic by realizing that much of its structure arises by forgetting what's inside. [0] Which is not to say you can't learn it elsewhere, or that you cannot do it elsewhere. Instead, Haskell has the facility, the philosophy, and the community to do it really effectively all the time and so if you read Haskell code you'll be floored by some of the great examples possible there.

loup-vaillant 13y ago
Fun fact: I have known this intuitively since forever, but only recently realized that when I say "generic", most programmers I know tend to hear "exhaustive", and recoil in horror; while I really meant "generic". Now, I also know why I like parametric polymorphism, and dislike subclass polymorphism: the first is generic, while the second is exhaustive.
- mushly 13y ago
  What's the difference between "generic" and "exhaustive," and where can I read more about all this stuff?
  - loup-vaillant 13y ago
    Imagine you want to process a list of foobarbaz, where elements can be foos, bars, or bazes. Exhaustion is when you write foo specific code, bar specific code, and baz specific code. Then your list-processing facility is general because it handles all the cases. A typical way to do that in practice is to use subtype polymorphism, with the class inheritance mechanism: have a foobarbaz interface, a foo class that implements it, a bar class that implements it, and a baz class that implements it. Each with their own code. Genericness is when you ignore the foobarbaz specifics altogether: your code doesn't even mention the types. A typical way to do that in practice is to use parametric polymorphism (generics in Java, templates in C++). See C++'s Algorithm library for an example, or the standard Prelude from Haskell, or the OCaml standard library.
- tel 13y ago
  > Now, I also know why I like parametric polymorphism, and dislike subclass polymorphism: the first is generic, while the second is exhaustive. I'm going to steal that. I love it.

twic 13y ago

> Those specs suck. Whoever asked you this don't understand their own needs, or are struggling with a legacy behemoth that should eventually be replaced. That may or may not be true, but presumably you're not suggesting that Haskell is unsuitable for writing software for users whose specs suck, or don't understand their needs?

marcosdumay 13y ago
No language is suitable for writing badly specked software. And whatever language you are using, you'll get into troubles if not technical people start to make too many requirements about the way you organize your code (but don't despair, the first such requirement will be to not use Haskell).
- seanmcdirmid 13y ago
  This doesn't really excuse the fact that Haskell is a harsh mistress that demands elegance. Many production languages are much more pragmatic about the quality of the spec, the quality of the developer, time constraints, and so on.
  - gridaphobe 13y ago
    One of my favorite quotes about Haskell is "We cannot afford QA teams, so we use a sadistic compiler".
  - Silhouette 13y ago
    This doesn't really excuse the fact that Haskell is a harsh mistress that demands elegance. I don't know how true that remains for expert Haskell programmers, but I agree that it's the way most introductory to intermediate material comes across. In academia, you are often looking for the most elegant tool in clean situations. In industry, you are often looking for the least clumsy tool in messy situations. Perhaps Haskell is a good choice in one context but a poor choice in the other, at least for those first learning it.
- alkonaut 13y ago

jbooth 13y ago

The gang of four book predates Java the language. FYI. The book's written in Smalltalk.

loup-vaillant 13y ago
Now that is a surprise. Lemme check… https://en.wikipedia.org/wiki/Design_Patterns https://en.wikipedia.org/wiki/Design_Patterns Indeed. Written in 1994, and includes examples in Smaltalk… and C++. Now I know why it didn't rely on first class functions. It wasn't written in Smaltalk. It was written in the intersection of Smaltalk and C++. Sounds like Java, even though it didn't exit yet. Come to think of it, I wonder if they didn't have hints about this upcoming language from Sun. Java came out in 1995, but was in the works since 1991… So my point stands. If it were really written in Smaltalk, it wouldn't have needed insanities such as the Visitor pattern to work around the lack of closures. It would have used Smaltalk Blocks directly.
- jbooth 13y ago
  Well, I'm glad you've concluded that you're still right.
  - loup-vaillant 13y ago
    Lose the sarcasm, please. If you still believe I'm wrong despite my documented arguments, I suggest you put forth documented counter-arguments. It will have two benefits: 1: You may convince me. I'm serious. I do not anticipate any strong counter arguments, but if they come, I will listen. (I did listen to your first argument. It troubled me, really, I was certain the book was written in Java. So I checked.) 2: You may show the other readers the error of my ways. Since my arguments are documented and relatively articulate, they will likely sway anyone who isn't committed to a particular position. You wouldn't want me to put false ideas in their heads.
    - deleted 13y ago
      [deleted]

deleted 13y ago

[deleted]

pjmlp 13y ago

> The Gang of Four pattern you mention most likely work around weaknesses of Java. Except it was written with Smalltalk and C++ in mind.

GeneralMayhem 13y ago
...which, for relevant purposes, have the same basic flaws as Java.