4 ms·

What I find crazy about these conversations is that I will say “I don’t like that I have to do X...” And the response is always “But that’s easy you just do X.

What I find crazy about these conversations is that I will say “I don’t like that I have to do X...” And the response is always “But that’s easy you just do X...” The argument is not that you can’t do some task in Haskell. With enough time you can do anything in any language. That’s the given. The argument is I want throughput. If I’m doing X I want to do it because it is necessary to the problem solution. This is why you hear these laments from Clojure programmers. Because when we code we are doing the minimal amount of work to produce correct programs. Strongly typed systems add fanfare that Clojure programmers have found no need for.

tome 7y ago
Thank you for your response. I'm afraid I don't understand. Your point seems backwards. On the specific point in question you said (paraphrasing) you don't like filling in a field of an ADT if you can prove it's not used. I pointed out that in Haskell you indeed need not fill it in. You said (paraphrasing) you don't like matching on a constructor if you can prove it's not used. I pointed out that in Haskell you indeed need not match on it. You don't want to do X. I'm telling you that you don't need to do X! Anyway, I'm more interested in the general point. Where do Clojurians get these ideas about Haskell? Are there specific blog posts or videos you can point me too? I'd rather confront the general case than specific instances buried deep down in forum threads.
- wellpast 7y ago
  Thanks for your reply, as well. But there’s no indoctrination going on. It’s right there: > If you know that a field of a data type is going to be unused you can fill it in with an `error` I don’t want to fill anything in. I don’t want to have to tell the checker what I know and the world already knows just because it thinks it needs to know it. There’s no indoctrination. We don’t have to “fill in” anything in Clojure. I wonder sometimes if this is a thing where you can’t see the air because it’s all around you? In static-type space you are (by definition) a slave to the type checker. Sometimes static-type enthusiasts will say they lean on the checker, it helps them. But I have a weird sense that this is a kind of Stockholm Syndrome. Sorry I’m a bit caustic sometimes, but it’s all good natured I promise - the hope is it draws out a point that will prove me wrong. You clearly know your domain well, and I appreciate the back & forth. But I do stand by my position (until knocked out of it.)
  - tome 7y ago
    > Thanks for your reply, as well. I'm glad we're still going deep down in this comment thread after everyone else has gone home. > > If you know that a field of a data type is going to be unused you can fill it in with an `error` > I don’t want to fill anything in. You don't have to! I said as much a couple of comments back "You can even omit the field entirely!". I gave a code example demonstrating that. Anyway, (what I assume to be) your larger point still stands, i.e. that you don't even want to have to define the data type upfront. I'm a huge fan of Rich Hickey's talks "Simple Made Easy", "Are We There Yet?", etc.. Haskell is such a good implementation of his philosphy yet he doesn't seem to realise it. Clojure fans are some of the most vociferously opposed to Haskell.
    - wellpast 7y ago
      Sorry to mishear your prior point about omitting the field entirely.. But let's set that aside and focus on the pre-declaring of your ADTs, as you suggest. This is no trivial matter. In fact this is the crux of the issue if not a large part of the issue. Pre-declaring what knowledge is "allowed" to flow through your system -- if you throw all other objections away -- this one is a enormous blocker still for the Clojurist. (Well, I should only speak for myself at least..but I suspect.) Clojurists rely almost universally across the board on ad hoc knowledge (ie dynamic maps) with zero ceremony required before getting to introduce and capitalize on this knowledge .... and Clojure is the perfect 'glove' for handling these ad hoc packets of knowledge..it was explicitly designed afaict on this exact way of handling data. So if Haskell is not oriented around this same construct then I don't think your read that Hickey's philosophy is much-realized by Haskell is accurate. You can take this further and make the very obvious point that in real life we never ever have to go through any pre-declarations or ceremony like this. And in my experience if productivity in coding is a function of anything it is _how close the programming model is to your natural way of thinking about the world_. When that cognitivie impedence is reduced massive creativity is unleashed.
      - tome 7y ago

tome 7y ago

Thank you for your response. I'm afraid I don't understand. Your point seems backwards. On the specific point in question you said (paraphrasing) you don't like filling in a field of an ADT if you can prove it's not used. I pointed out that in Haskell you indeed need not fill it in. You said (paraphrasing) you don't like matching on a constructor if you can prove it's not used. I pointed out that in Haskell you indeed need not match on it. You don't want to do X. I'm telling you that you don't need to do X! Anyway, I'm more interested in the general point. Where do Clojurians get these ideas about Haskell? Are there specific blog posts or videos you can point me too? I'd rather confront the general case than specific instances buried deep down in forum threads.

wellpast 7y ago
Thanks for your reply, as well. But there’s no indoctrination going on. It’s right there: > If you know that a field of a data type is going to be unused you can fill it in with an `error` I don’t want to fill anything in. I don’t want to have to tell the checker what I know and the world already knows just because it thinks it needs to know it. There’s no indoctrination. We don’t have to “fill in” anything in Clojure. I wonder sometimes if this is a thing where you can’t see the air because it’s all around you? In static-type space you are (by definition) a slave to the type checker. Sometimes static-type enthusiasts will say they lean on the checker, it helps them. But I have a weird sense that this is a kind of Stockholm Syndrome. Sorry I’m a bit caustic sometimes, but it’s all good natured I promise - the hope is it draws out a point that will prove me wrong. You clearly know your domain well, and I appreciate the back & forth. But I do stand by my position (until knocked out of it.)
- tome 7y ago
  > Thanks for your reply, as well. I'm glad we're still going deep down in this comment thread after everyone else has gone home. > > If you know that a field of a data type is going to be unused you can fill it in with an `error` > I don’t want to fill anything in. You don't have to! I said as much a couple of comments back "You can even omit the field entirely!". I gave a code example demonstrating that. Anyway, (what I assume to be) your larger point still stands, i.e. that you don't even want to have to define the data type upfront. I'm a huge fan of Rich Hickey's talks "Simple Made Easy", "Are We There Yet?", etc.. Haskell is such a good implementation of his philosphy yet he doesn't seem to realise it. Clojure fans are some of the most vociferously opposed to Haskell.
  - wellpast 7y ago
    Sorry to mishear your prior point about omitting the field entirely.. But let's set that aside and focus on the pre-declaring of your ADTs, as you suggest. This is no trivial matter. In fact this is the crux of the issue if not a large part of the issue. Pre-declaring what knowledge is "allowed" to flow through your system -- if you throw all other objections away -- this one is a enormous blocker still for the Clojurist. (Well, I should only speak for myself at least..but I suspect.) Clojurists rely almost universally across the board on ad hoc knowledge (ie dynamic maps) with zero ceremony required before getting to introduce and capitalize on this knowledge .... and Clojure is the perfect 'glove' for handling these ad hoc packets of knowledge..it was explicitly designed afaict on this exact way of handling data. So if Haskell is not oriented around this same construct then I don't think your read that Hickey's philosophy is much-realized by Haskell is accurate. You can take this further and make the very obvious point that in real life we never ever have to go through any pre-declarations or ceremony like this. And in my experience if productivity in coding is a function of anything it is _how close the programming model is to your natural way of thinking about the world_. When that cognitivie impedence is reduced massive creativity is unleashed.
    - tome 7y ago