5 ms·

> arcane toxic names Oh come on. It's not "arcane" and I don't see how "toxic" has anything to do with the names of these patterns. Just an inflammatory comme

by dkn 10y ago

> arcane toxic names Oh come on. It's not "arcane" and I don't see how "toxic" has anything to do with the names of these patterns. Just an inflammatory comment.

mavelikara 10y ago
Yes, and quite rich coming from the crowd which throws around Functors, Applicatives, Monads, Kiesli, CoYoneda etc.
- js8 10y ago
  I downvoted you - these are, unlike design patterns, very well-defined mathematical objects, but furthermore, you shouldn't use such a broad brush.
  - mavelikara 10y ago
    > these are, unlike design patterns, very well-defined mathematical objects IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field. OO design patterns do not have mathematical foundations, but that does not make them arcane or toxic. > you shouldn't use such a broad brush Probably not, I agree.
    - js8 10y ago
      > IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field. I disagree. Why not call a duck a duck, and instead invent your own terminology, just because you're in a different field? Mathematicians invented those concepts first, whether you like it or not. It's actually one of my three criticisms of (OOP) design patterns. Often they are just another names for a contrived way of how to pass functions as arguments, so they are actually bad abstractions (too little bang for the buck). (The other two criticisms are lack of formal definition and lack of representation in the computer language.)
      - mavelikara 10y ago
        > I disagree. Why not call a duck a duck, and instead invent your own terminology, just because you're in a different field? Mathematicians invented those concepts first, whether you like it or not. Mathematicians discovered the existence of these structures first and gave them names. Programers also came across them, and there is no shame in giving the structures better names more appropriate to their own field - whether mathematicians like it or not. > It's actually one of my three criticisms of (OOP) design patterns. Often they are just another names for a contrived way of how to pass functions as arguments, so they are actually bad abstractions. They are not, and have been employed by couple of generations of programmers to create useful software.
        js8 10y ago
        > Mathematicians discovered the existence of these structures first and gave them names. Programmers also came across them, and there is no shame in giving the structures better names more appropriate to their own field - whether mathematicians like it or not. Actually this is not what happened here - when programmers added the concepts you mentioned, they were very much aware of the mathematical counterparts. Regardless, I think it is a shame to call the same thing differently just for the sake of it. > They are not, and have been employed by couple of generations of programmers to create useful software. I can somewhat recommend this presentation: https://www.youtube.com/watch?v=Rmer37g9AZM https://www.youtube.com/watch?v=Rmer37g9AZM The concepts presented are very sound, however the presentation could be a little better.
        mavelikara 10y ago
        > Actually this is not what happened here - when programmers added the concepts you mentioned, they were very much aware of the mathematical counterparts. Yes, I am aware of it. I have read Wadler's papers pointing out that list comprehensions are a specific instance of a Monad and proposing Monads as a way to structure functional programs. But I wish the Haskell did not directly copy the term Monad into the language, setting off this bad precedent. Like CAR and CDR in Lisp, unfortunately, this one will stay in Haskell. Hopefully future languages will introduce more sensible terminology, like how Lisps have evolved over the years. > Regardless, I think it is a shame to call the same thing differently just for the sake of it. We have to agree to diasgree on this. IMO the intended usage of a concept should dictate its name, not how humans first arrived at it.

by dkn 10y ago

> arcane toxic names Oh come on. It's not "arcane" and I don't see how "toxic" has anything to do with the names of these patterns. Just an inflammatory comment.

mavelikara 10y ago

Yes, and quite rich coming from the crowd which throws around Functors, Applicatives, Monads, Kiesli, CoYoneda etc.

js8 10y ago
I downvoted you - these are, unlike design patterns, very well-defined mathematical objects, but furthermore, you shouldn't use such a broad brush.
- mavelikara 10y ago
  > these are, unlike design patterns, very well-defined mathematical objects IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field. OO design patterns do not have mathematical foundations, but that does not make them arcane or toxic. > you shouldn't use such a broad brush Probably not, I agree.
  - js8 10y ago
    > IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field. I disagree. Why not call a duck a duck, and instead invent your own terminology, just because you're in a different field? Mathematicians invented those concepts first, whether you like it or not. It's actually one of my three criticisms of (OOP) design patterns. Often they are just another names for a contrived way of how to pass functions as arguments, so they are actually bad abstractions (too little bang for the buck). (The other two criticisms are lack of formal definition and lack of representation in the computer language.)
    - mavelikara 10y ago
      > I disagree. Why not call a duck a duck, and instead invent your own terminology, just because you're in a different field? Mathematicians invented those concepts first, whether you like it or not. Mathematicians discovered the existence of these structures first and gave them names. Programers also came across them, and there is no shame in giving the structures better names more appropriate to their own field - whether mathematicians like it or not. > It's actually one of my three criticisms of (OOP) design patterns. Often they are just another names for a contrived way of how to pass functions as arguments, so they are actually bad abstractions. They are not, and have been employed by couple of generations of programmers to create useful software.
      - js8 10y ago
        > Mathematicians discovered the existence of these structures first and gave them names. Programmers also came across them, and there is no shame in giving the structures better names more appropriate to their own field - whether mathematicians like it or not. Actually this is not what happened here - when programmers added the concepts you mentioned, they were very much aware of the mathematical counterparts. Regardless, I think it is a shame to call the same thing differently just for the sake of it. > They are not, and have been employed by couple of generations of programmers to create useful software. I can somewhat recommend this presentation: https://www.youtube.com/watch?v=Rmer37g9AZM https://www.youtube.com/watch?v=Rmer37g9AZM The concepts presented are very sound, however the presentation could be a little better.
        mavelikara 10y ago
        > Actually this is not what happened here - when programmers added the concepts you mentioned, they were very much aware of the mathematical counterparts. Yes, I am aware of it. I have read Wadler's papers pointing out that list comprehensions are a specific instance of a Monad and proposing Monads as a way to structure functional programs. But I wish the Haskell did not directly copy the term Monad into the language, setting off this bad precedent. Like CAR and CDR in Lisp, unfortunately, this one will stay in Haskell. Hopefully future languages will introduce more sensible terminology, like how Lisps have evolved over the years. > Regardless, I think it is a shame to call the same thing differently just for the sake of it. We have to agree to diasgree on this. IMO the intended usage of a concept should dictate its name, not how humans first arrived at it.