One thing that I really like about Haskell's practice of naming interfaces after mathematical constructs is that it makes it clear what t...
One thing that I really like about Haskell's practice of naming interfaces after mathematical constructs is that it makes it clear what the rules for those interfaces "should be" and changes the character of a few kinds of discussion. If we called them "Mappable", "Applicable", "FlatMappable" (yuck), "AssociativeAppendableWithIdentity"... then there would be disagreement about whether some new construct "is really" Applicable. Is summation really "Appending"? And these arguments are high stakes, because the most important thing about an interface is that it tells the user what they can expect. If I ask for an Appendable, and get something that doesn't follow the rules I think Appendable should have, then... whose code is broken? In Haskell, it's entirely clear whether a new type "is really" a Monoid or Functor - does it obey the laws? Okay! Whether "container" is a good way to think of Functor is recognized as a purely pedagogic question (not that there's never drama in pedagogy, but those people getting work done can opt out without worry that it will break their code when they try to interface with others).
Posted by dllthomas on Jul 15, 2015, 4:09 PM
Tags
Related issues
- This is my biggest problem with agents, they constantly defensively code for cases that have no chance of happening and in most cases a p...
- I wish there was something like LEAN for biology.
- The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
- I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
- I hate that I'm in deep enough to know what you mean.
- The biggest problem with “AI” is that big corps are shoving it down our throats.
Raise real-world problems, find people facing the same issue, and discuss solutions.5,500 issues0 comments
reliability (Other)
This is my biggest problem with agents, they constantly defensively code for cases that have no chance of happening and in most cases a p...
NewI wish there was something like LEAN for biology.
NewThe issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).
I probably could have beared with it if it was only limited to programming, but it showing up in creative fields has made me feel all sor...
I hate that I'm in deep enough to know what you mean.
The biggest problem with “AI” is that big corps are shoving it down our throats.
in the middel of a coding session with 5.6 sol.
[Hero Run] 535B-A23B on 18T tokens
One thing that I really like about Haskell's practice of naming interfaces after mathematical constructs is that it makes it clear what t...
One thing that I really like about Haskell's practice of naming interfaces after mathematical constructs is that it makes it clear what the rules for those interfaces "should be" and changes the character of a few kinds of discussion. If we called them "Mappable", "Applicable", "FlatMappable" (yuck), "AssociativeAppendableWithIdentity"... then there would be disagreement about whether some new construct "is really" Applicable. Is summation really "Appending"? And these arguments are high stakes, because the most important thing about an interface is that it tells the user what they can expect. If I ask for an Appendable, and get something that doesn't follow the rules I think Appendable should have, then... whose code is broken? In Haskell, it's entirely clear whether a new type "is really" a Monoid or Functor - does it obey the laws? Okay! Whether "container" is a good way to think of Functor is recognized as a purely pedagogic question (not that there's never drama in pedagogy, but those people getting work done can opt out without worry that it will break their code when they try to interface with others).
Comments (0)
No comments yet. Start the discussion.