3 ms·

I resisted replying to Don as I didn't think he presented any actual argument. The "Write two functions" crew haven't thought this through though. Ultimately,

I resisted replying to Don as I didn't think he presented any actual argument. The "Write two functions" crew haven't thought this through though. Ultimately, the scenario I came across this in was an atomic transaction decorated function. The data being provided to this function flows through a good 3 or 4 functions beforehand. I also require _single, _list and _listoflists behaviour. This would bloat a 4 function stack into something like 20 different functions. There are also issues with transaction decorators. It just seems crazy to me that Python can't manage this (to me trivial) use case.

deleted 11y ago
[deleted]
lmm 11y ago
> I also require _single, _list and _listoflists behaviour. So it sounds like your needs don't align exactly with perl's sigils anyway (and why should they? For different business requirements you'd categorize differently). > This would bloat a 4 function stack into something like 20 different functions. Not with good language/design. Separate your concerns. Let the difference in behaviour live somewhere more appropriate - either on an object that contains the data (OO style) or in a callback you pass into the function (functional style). > There are also issues with transaction decorators. Decorators have problems yes, that's why I prefer to have a type system handle that kind of thing.
- hahainternet 11y ago
  > So it sounds like your needs don't align exactly with perl's sigils anyway (and why should they? For different business requirements you'd categorize differently). Indeed but I can write constraints in my function signature to permit this. Hell I can even define something as SpecialList[SpecialKey] if I truly wanted. Perl has a type system. > Not with good language/design. Separate your concerns. Let the difference in behaviour live somewhere more appropriate - either on an object that contains the data (OO style) or in a callback you pass into the function (functional style). Doing this in Python is an exercise in horror, frustration and hatred. Doing it in Perl is the work of a few seconds. That is my point.
  - lmm 11y ago
    > Indeed but I can write constraints in my function signature to permit this. Hell I can even define something as SpecialList[SpecialKey] if I truly wanted. Perl has a type system. Interesting. Is this a new thing? > Doing this in Python is an exercise in horror, frustration and hatred. Doing it in Perl is the work of a few seconds. That is my point. Then what's the perl example without using sigils? Does that not translate directly into python?
    - raiph 11y ago
      > Interesting. Is this a new thing? What is the single "thing" you're referring to and what is "new" relative to? I interpret hahainternet's comment to refer to at least three new things in Perl 6 relative to Perl 5: Perl 6 has a carefully developed type system, roles support parametric polymorphism, and both static and dynamic type constraints on parameters are supported. ----- You earlier wrote "If you want two different behaviours, write two different functions". But hahainternet had written two different functions. This suggests you hadn't then yet taken on board what multidispatch is (a fundamental innovation -- from the 80s iirc -- related to declaring and calling functions). Then you responded to hahainternet's "This would bloat a 4 function stack into something like 20 different functions." with "Let the difference in behaviour live somewhere more appropriate ... on an object that contains the data (OO style) ..." without realizing that that's less appropriate, not more: "In the presence of multiple dispatch, the traditional idea of methods as being defined in classes and contained in objects becomes less appealing" (from https://en.wikipedia.org/wiki/Multiple_dispatch https://en.wikipedia.org/wiki/Multiple_dispatch). A similar argument applies to callbacks. All in all I'm guessing you haven't yet seen the light about multidispatch and a read of https://en.wikipedia.org/wiki/Multiple_dispatch#Perl_6 https://en.wikipedia.org/wiki/Multiple_dispatch#Perl_6 might help clear some things up.
      - lmm 11y ago
        > What is the single "thing" you're referring to and what is "new" relative to? The type system and perl 5. That would have been a much more constructive response to "why perl 6?" (if it's as good as you say) than this article. > You earlier wrote "If you want two different behaviours, write two different functions". But hahainternet had written two different functions. This suggests you hadn't then yet taken on board what multidispatch is (a fundamental innovation -- from the 80s iirc -- related to declaring and calling functions). No need to be rude. Rather than argue over whether the cases of a multimethod are different functions or the same function, let me just clarify that if you want two different behaviours then it is clearer to give them different names. > "In the presence of multiple dispatch, the traditional idea of methods as being defined in classes and contained in objects becomes less appealing" (from https://en.wikipedia.org/wiki/Multiple_dispatch https://en.wikipedia.org/wiki/Multiple_dispatch). That article is decidedly non-neutral. I'm well aware of multiple dispatch. I find it very bad for code maintainability, and often a sign of poor domain modeling. The interaction between two objects is an unnatural and opaque place for behaviour to live; usually the behaviour belongs to one or the other or on its own, or if their relationship is that complex it should probably be promoted to a first-class entity.

deleted 11y ago

[deleted]

lmm 11y ago

> I also require _single, _list and _listoflists behaviour. So it sounds like your needs don't align exactly with perl's sigils anyway (and why should they? For different business requirements you'd categorize differently). > This would bloat a 4 function stack into something like 20 different functions. Not with good language/design. Separate your concerns. Let the difference in behaviour live somewhere more appropriate - either on an object that contains the data (OO style) or in a callback you pass into the function (functional style). > There are also issues with transaction decorators. Decorators have problems yes, that's why I prefer to have a type system handle that kind of thing.

hahainternet 11y ago
> So it sounds like your needs don't align exactly with perl's sigils anyway (and why should they? For different business requirements you'd categorize differently). Indeed but I can write constraints in my function signature to permit this. Hell I can even define something as SpecialList[SpecialKey] if I truly wanted. Perl has a type system. > Not with good language/design. Separate your concerns. Let the difference in behaviour live somewhere more appropriate - either on an object that contains the data (OO style) or in a callback you pass into the function (functional style). Doing this in Python is an exercise in horror, frustration and hatred. Doing it in Perl is the work of a few seconds. That is my point.
- lmm 11y ago
  > Indeed but I can write constraints in my function signature to permit this. Hell I can even define something as SpecialList[SpecialKey] if I truly wanted. Perl has a type system. Interesting. Is this a new thing? > Doing this in Python is an exercise in horror, frustration and hatred. Doing it in Perl is the work of a few seconds. That is my point. Then what's the perl example without using sigils? Does that not translate directly into python?
  - raiph 11y ago
    > Interesting. Is this a new thing? What is the single "thing" you're referring to and what is "new" relative to? I interpret hahainternet's comment to refer to at least three new things in Perl 6 relative to Perl 5: Perl 6 has a carefully developed type system, roles support parametric polymorphism, and both static and dynamic type constraints on parameters are supported. ----- You earlier wrote "If you want two different behaviours, write two different functions". But hahainternet had written two different functions. This suggests you hadn't then yet taken on board what multidispatch is (a fundamental innovation -- from the 80s iirc -- related to declaring and calling functions). Then you responded to hahainternet's "This would bloat a 4 function stack into something like 20 different functions." with "Let the difference in behaviour live somewhere more appropriate ... on an object that contains the data (OO style) ..." without realizing that that's less appropriate, not more: "In the presence of multiple dispatch, the traditional idea of methods as being defined in classes and contained in objects becomes less appealing" (from https://en.wikipedia.org/wiki/Multiple_dispatch https://en.wikipedia.org/wiki/Multiple_dispatch). A similar argument applies to callbacks. All in all I'm guessing you haven't yet seen the light about multidispatch and a read of https://en.wikipedia.org/wiki/Multiple_dispatch#Perl_6 https://en.wikipedia.org/wiki/Multiple_dispatch#Perl_6 might help clear some things up.
    - lmm 11y ago
      > What is the single "thing" you're referring to and what is "new" relative to? The type system and perl 5. That would have been a much more constructive response to "why perl 6?" (if it's as good as you say) than this article. > You earlier wrote "If you want two different behaviours, write two different functions". But hahainternet had written two different functions. This suggests you hadn't then yet taken on board what multidispatch is (a fundamental innovation -- from the 80s iirc -- related to declaring and calling functions). No need to be rude. Rather than argue over whether the cases of a multimethod are different functions or the same function, let me just clarify that if you want two different behaviours then it is clearer to give them different names. > "In the presence of multiple dispatch, the traditional idea of methods as being defined in classes and contained in objects becomes less appealing" (from https://en.wikipedia.org/wiki/Multiple_dispatch https://en.wikipedia.org/wiki/Multiple_dispatch). That article is decidedly non-neutral. I'm well aware of multiple dispatch. I find it very bad for code maintainability, and often a sign of poor domain modeling. The interaction between two objects is an unnatural and opaque place for behaviour to live; usually the behaviour belongs to one or the other or on its own, or if their relationship is that complex it should probably be promoted to a first-class entity.