Earlier quoted context omitted.
> 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 han…
I take your point that all of these Hickey comments resonate with ideals of Haskell. The last piece of the puzzle would be to discuss why Hickey -- in addition to these points -- also is overtly against static typeing and the kinds of idioms that show up in static-type-oriented programming (like ADTs and Maybes etc--he rails against these as well. See "Effective Programs" talk just for once citation.) So we may be at…
Haskell in Production
241–242 of 242 posts
Re: Haskell in Production
#242Earlier quoted context omitted.
> 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 han…
I take your point that all of these Hickey comments resonate with ideals of Haskell. The last piece of the puzzle would be to discuss why Hickey -- in addition to these points -- also is overtly against static typeing and the kinds of idioms that show up in static-type-oriented programming (like ADTs and Maybes etc--he rails against these as well. See "Effective Programs" talk just for once citation.) So we may be at…
> In my dynamic code base these changes are severely localized so that a creative decision over here does not cause a production capability over there to fall over.
This is a very specific claim which it might be helpful to dig into further. How can you ensure that removing a record from a field at the start of a pipeline will not cause a function at the end of the pipeline to fall over, since it was expecting to see it but didn't (and the intermediate parts of the pipeline were completely agnostic to it)?