4 ms·

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 li

by 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
      > Sorry to mishear your prior point about omitting the field entirely.. That's OK. Forum discussions are not the highest fidelity communication medium. What I mean about Rich Hickey's philosophy and Haskell are things like the quotations below. I think they're great insights and they apply really well to Haskell, at least to Haskell written in the way that a significant subset of us like to write it. On the other hand I'm not much convinced by arguments about the "natural way of thinking about the world". Firstly, imperative programming proponents are convinced that the world is imperative and it is natural for humans to think imperatively. Secondly, I became a much better programmer using Haskell that using Python, despite Python naturally "fitting my brain" (a popular, and valid, quote amongst Python programmers) and me having to "fit my brain to" Haskell. Anyway, that's mostly just my opinion. On the other hand, an objective technical innovation that could bring a huge amount of ergonomic benefit to Haskell is a type system feature called "row types". That would allow us to have anonymous records which we could add fields to and delete fields from at will, just like in an untyped language, whilst also providing the type system guarantees that we're used to. I think that would be hugely beneficial but for some reason that doesn't seem to be on the horizon. ==== Are We There Yet? * "Someone who's building houses out of bricks does not have to worry about the insides of the bricks" * "The best units for that are the pure functions. Takes immutable values, does something with them, has no effect on the outside world. Returns another immutable value." * "Mutable state - it makes no sense. Mutable objects - they make no sense." The Value of Values * "Place itself has no role in an information model. It is only an implementation detail." * "Values can be shared freely and the way you share them is by aliasing them." * "Reproducible results are another great benefit of values." * "Easy to fabricate" * "Values make the best interface" * "Values aggregate ("compose") PLOP doesn't compose" The Language Of The System * "What's wrong with SQL is that there's no machine interval to SQL. They only designed a human interface to sequel." (foreshadowing embedded domain specific languages) * "We want to seek out and build libraries and languages that are like instruments in all the ways I just talked about, in particular the simplicity aspect." ====

by tome 7y ago

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
    > Sorry to mishear your prior point about omitting the field entirely.. That's OK. Forum discussions are not the highest fidelity communication medium. What I mean about Rich Hickey's philosophy and Haskell are things like the quotations below. I think they're great insights and they apply really well to Haskell, at least to Haskell written in the way that a significant subset of us like to write it. On the other hand I'm not much convinced by arguments about the "natural way of thinking about the world". Firstly, imperative programming proponents are convinced that the world is imperative and it is natural for humans to think imperatively. Secondly, I became a much better programmer using Haskell that using Python, despite Python naturally "fitting my brain" (a popular, and valid, quote amongst Python programmers) and me having to "fit my brain to" Haskell. Anyway, that's mostly just my opinion. On the other hand, an objective technical innovation that could bring a huge amount of ergonomic benefit to Haskell is a type system feature called "row types". That would allow us to have anonymous records which we could add fields to and delete fields from at will, just like in an untyped language, whilst also providing the type system guarantees that we're used to. I think that would be hugely beneficial but for some reason that doesn't seem to be on the horizon. ==== Are We There Yet? * "Someone who's building houses out of bricks does not have to worry about the insides of the bricks" * "The best units for that are the pure functions. Takes immutable values, does something with them, has no effect on the outside world. Returns another immutable value." * "Mutable state - it makes no sense. Mutable objects - they make no sense." The Value of Values * "Place itself has no role in an information model. It is only an implementation detail." * "Values can be shared freely and the way you share them is by aliasing them." * "Reproducible results are another great benefit of values." * "Easy to fabricate" * "Values make the best interface" * "Values aggregate ("compose") PLOP doesn't compose" The Language Of The System * "What's wrong with SQL is that there's no machine interval to SQL. They only designed a human interface to sequel." (foreshadowing embedded domain specific languages) * "We want to seek out and build libraries and languages that are like instruments in all the ways I just talked about, in particular the simplicity aspect." ====