Daniel Berger isn't keen on the future of traits.
Okay, so I'm the Perl 6 designer most excited by them (and the one most to blame for them, though that's only by plurality of blame and not majority), but I've used them and they've solved real problems in my code with regard to duplication, typing, and genericity.
Daniel makes this comment in relation to someone on a Smalltalk mailing list mentioning that they didn't know of anyone using traits in production. Admittedly, this was Avi Bryant, the developer of Seaside, but still, let's think about it. The Smalltalk community is a much smaller community than Perl. In the Perl community, we have some relatively well-known people evangelizing traits -- yourself, Stevan Little (to an extent) and myself, to name a few -- and we have routinely written blog entries, articles, Perlmonks posts, etc., to help break the resistance against trying something new.
The result is that traits seem to be used more widely in Perl than I think people suspect (one can see my reply to Daniel for more info). Does Smalltalk have an equivalent community with equivalent evangelists? I couldn't say, but then, Smalltalk has been around long enough that it may have more inertia to overcome to convince developers that traits are worthwhile.
One thing I find frustrating about all of this is that class-based systems are one way of building OO systems. The first time I saw prototyped OO I scratched my head and didn't understand. I suspect this is what's happening with traits for many folks. As far as they are concerned, if you can't get code reuse from a class, there are plenty of handy (*cough*) design patterns they can use to overcome this limitation. It doesn't seem to occur to them that their way might not be the best (if only I earned a dollar for every time someone asks me why I think Perl 5's OO system is limited).
Interestingly, the pattern backlash of a couple of years ago exposed an important point of patterns: they're often used to get around limitations in a programming language. Delegation is a design pattern which works around composition limitations in OO systems and traits eliminate that limitation. I'm still shocked that people find them difficult, but OO inertia is surprisingly difficult to overcome. I think it's largely a matter of finding the right way of describing them. I'm thinking "collision-free mixins" might be a good way to start, even if it is rather inaccurate. That might fly better with Ruby programmers than Perl programmers, though.
Re:Smalltalk Traits
chromatic on 2007-06-08T18:14:22
Plenty of OO programmers who really ought to know better think that inheritance is The Important Point of OO.
In the interests of better software, I give everyone reading this permission to slap anyone who talks that way in apparent seriousness.
Re:Not sure if that is the same traits
Stevan on 2007-06-08T18:23:22
I have looked over this one a couple of times, and I am still not sure it is really related to the Smalltalk Traits which chromatic is talking about. There might be some similarities, but beyond that I am not sure.
- StevanRe:Not sure if that is the same traits
chromatic on 2007-06-08T18:50:46
Funny; I almost posted the same thing. It looks similar in a familiar way, but I don't understand it well enough to say "Yep, that's it!"
Re:Not sure if that is the same traits
sigzero on 2007-06-08T21:59:06
On first pass it looks like they are using it for "glorified" assertions. I would have to look deeper to know.
I suspect the users of Class::Trait have similar stories.
There has been a recent boost in role usage in the Moose community, so I suspect we will have some stories as well. I have submitted a roles talk to YAPC::EU, which takes a "how roles can solve problems in the real world" approach and I think provides a pretty compelling use case (based on actual experince using roles in a production system).
- Stevan