5 ms·

> 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

• 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.
  • raiph 11y ago
    >> What is the single "thing" you're referring to and what is "new" relative to? > The type system and perl 5. Gotchya. Perl 6 is not a Perl 5 update. There are reasons it shares the name Perl, which usually become obvious if you know both langs, but for non-users it's best to think of Perl 6 as a completely new language. > That would have been a much more constructive response to "why perl 6?" I think the OP article was a mostly good humored response to the reality that a lot of responses to Perl 6 are absurd. Like individuals sincerely asserting that it should not be taken seriously by anyone for any commercial purpose -- because of perceived problems with the logo chosen by the language design team! > (if it's as good as you say) Uhoh. Did I say Perl 6 is good? I think, right now, it's a lot of fun if you're in to all sorts of PLs. But let me restore balance in the force. The language isn't equational and its type system isn't Hindley Milner. Compiled code is very slow and consumes a lot of RAM and fully fixing that is going to take many years worth of engineering. The doc needs tons more work. There are only a handful of modules. It's a new and unproven language. Balance restored? > No need to be rude. My apologies. I didn't mean to be rude. (I looked over your other responses in this thread prior to posting my comment and none suggested to me that you were claiming familiarity with multidispatch and several suggested to me that you did not really have a feel for how they work out when properly used in Perl 6.) > 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. Gotchya. Nit: multidispatch in Perl 6 works for any function and (almost) any operator (operators are actually just functions), not just methods. The Perl 6 view is that multi functions/ops/methods have both a "short" name and a "long" name. The short name is the bit that goes before the parameters. The long name includes the signature. It's a different perspective on naming and I find it works well for me. > 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. I hear you've encountered use of multiple dispatch that you don't like, and that it's often signaled poor design, and that you think that the code placement for a multimethod is fundamentally unnatural. But I don't hear that you've encountered multiple dispatch for functions and/or operators rather than methods; or that you've seen the scenarios in which it is a good fit for coding (I presume you don't think there's literally no sweetspot use-case); or that you've had a chance to work with a language like Perl 6 in which multimethod placement is as you suggest. So it sounds like you have only encountered limited and perhaps poorly designed and/or used multiple dispatch and that's colored your perspective. Anyhoo, thanks for the exchange, and I hope you get another chance to use Perl 6 for something it's good at and see that, whatever else may be true, it is a lot of fun. :)