Re: Will role-based programming be part of the standard Perl 6 distribution?

[scrottie]

OO has existed for 30 years but hasn't been well understood by a significant group of programmers until now - and probably only 5 of them program Perl. Every bit of modern literature you'll pick up - "Refactoring: Improving the Design of Existing Code", "Design Patterns: Elements of Reusable Object Oriented Code", "Object Orienged Design Heuristics", or any other book written in the last 10 years that has sold well on the subject, all agree: delegation, not composition, is the only way to fly. That is, the only way to code with any sembelence of structure, modularity, robustness, and run-time and compile-time dynamicness.

"does" muddies the water, trying to make essentially inheritance (composition) more "powerful", but it isn't the right kind of power, and like computed symbol table entries and eval, the power lures programmers into doing things the wrong way because the wrong way is just SO easy, atleast initially.

The problem with inheritance, in a nutshell, is as you compose and compose, you wind up with one huge object that is an amalgamation of now no longer distinct parts - an "everything". Sort of like "everything" in the "Everything Engine". Each node is an embodiment of potentially everything. It includes all of the code. When one node relates to another, it relates to another everything. This isn't a critism of the everything engine - many programmers accidentaly discover that they've written exactly this through constant promotation of objects or records in a database. Saying to yourself over and over again "well, this is kind of like that, and sometimes it might need to do that, so we'll just make them both the same thing". Do you see where this is going? There is no relationship between parts, no structure. Aggregation (considering a structure of several objects) becomes almost impossible. Multiplicity (where one object has several of a subpart rather than just the one it gets through inheritance) becomes impossible.

This isn't bizarre and it isn't the least bit of a surprise to anyone who sticks their head out of the perl camp now and then. This is known as the God Object, and Perl programmers are infamous for repeating this sin over and over and over. We're called amatures and hacks because of our gross and sustained ignorance. Perl projects seldom stay maintainable as they grow large and are often thrown away and replaced with Java because of this blind spot in our collective software engineering know-how.

In Perl 4, when you used a "toolbox" module that had all of your routines in one place - that was a god object. In Perl 5, when you download a CPAN module that tries to be OO but is actually itself one huge object with no decomposition, that's a god object. Most fit this description - DBI, LWP/HTTP::*, and a few others are notable exceptions.

Adding more and more logic to a given class to compose something that embodies all of the behavior you want is also known as Mix Ins. This is one mechanism that god objects are arrived at by and one that Perl 6 is quite proud of. Hello?

And Perl 6 is formalizing all of this after two generations of Perl. When it should be making delegation easier.

Delegation is, in a word, structure. Rather than objects being (isa) other things, they reference them. The other object is seperate. Messages are propogated across the structure according to the Law of Demeter, which says that objects in a structure should only depend on the interface of objects immediately next to them, and those objects should depend on those immediately next to it, and messages should be propogated. The opposite is one object knowing and being dependent and hardcoded to the structure of the entire jumbled of objects - a trait of god objects and the only practise of Perl programmers.

Perl can't do objects right. It isn't a problem anywhere in C code - it is a cultural one. It is like trying to teach apes to hold tea parties. Perl will never stand on the same ground as Java, C++, C#, or any other language currently in fashion for thier object support. Larry Wall asked that the cultural be reinvented along with the language - very astute indeed. I've been evangalizing, doing PerlMongers presentations, blathering on IRC, trying to explain to perlers what type safety is, why 80% of new code written is in a language that has it, and why they should understand how it works even if they don't use it. You know how far I've gotten? No where. Perlers have their heads up their arses just as far as any Atari or Amiga users ever had and more and more it seems like Perl is going to go the way of the Atari ST. I'm sorry, I try really hard not to be inflamitory, but if I didn't *try* to sound a wake-up call, I wouldn't be doing my part.

So, for once, princepawn is right on - there is very little advantage to making inheritance more complex. It is a strawman for the real problem, but the problem stems from an ignorance that perlers will do nothing about.

-scott

(edited repeatedly to make use of terminology consistent, include the link to mixins, re-arrange the slurs slightly)

[chromatic]

"does" muddies the water, trying to make essentially inheritance (composition) more "powerful"

Roles have *nothing* to do with inheritance, except that you can describe inheritance as a degenerate case of role-based programming. They're an attempt to solve the exact problem you describe. Did you read the Traits paper?

[princepawn]

Did you read the Traits paper?

I did and even though they mentioned prototype-based programming as related work, they did not mention any shortcomings of it or how traits (Perl roles) improves on it.

[simonm]

... the Traits paper... did not mention ... how traits (Perl roles) improves on ... prototype-based programming. (paraphrased)

Note that the approach described by the Traits paper is a fairly general concept, and Perl 6 will not be blindly following their recipe.

I would expect that Perl 6 will support a delegation scheme that looks like a prototype-based system. The problem/goal is to enable this approach and others, so that you can combine a logging aspect and an exception-handling role with a access-control proxy, or whatever.

[scrottie]

chromatic, form your own assessment and espouse its relative virtues. This is the formula:

1. Take something that needs to be said. "You're wrong!" or "You missed a some nit!" aren't things that need be said. The impact on the world is negligable.

2. Explain it. Paint a picture of what, why, and how. Why is it good? What do people need to know? What tricks are there? What pitfalls?

3. When other people do this, don't pretend that their argument is propped up on one leg and try to kick the leg out when it isn't. Specifically, if there are flaws in their logic that lead to a faulty conclusion, it may or may not be worth pointing that out. If their premise is wrong, same. Attacking one point as if it to invalidate everything said is naive and misleading to readers. In this case, my post was a survey of issues. Though you question one of my premises, it is not a critical one - in fact, it was an issue I wanted readers to make up their own minds about. You've only managed to state something that should be obvious.

4. As long as we're talking about elemetary formal logic, if one thing can't be proved (it was never said that traits are mixins for certain, though it was implied by Piers atleast, therefore there is no confession) that doesn't automatically make the opposite true. Truth and provability are seperate things. The modest writer will post opinions as opinions, not as an interpretation of anothers words, and not as something infinately defensible. I've tried to follow in the modest writers footsteps. Again, the reader should find their own truth - this is only evidence and opinion, some mine, some popular. The reader that limits themselves to what is provable does nothing but this sort of political nitpicking. You're asking me to take issue with a source - the traits document (which ghostview/ghostscript renders flawlessly). I'd ask you to do the same - I've summerized popular opinion on the topic and made a classification that is correct according to an outsiders view of perl. Your turn - go read "Object Oriented Design Hueristics". And don't cop that "I graduated from college, I know everything there is to know about OO" attitude. I hate that. C++ programmers used to do that before the designpatterns/refactoring revoluation. Now everyone studiously improves their skills without boast or complain after college - except Perl programmers and other script kiddies.

5. Get a life. I don't mean to single you out, chromatic - I'm addressing everyone that mindlessly replies to posts. Do you have the same attitude in real life, walking around, trying to push everything over just to see if maybe it will fall, or to make people think that maybe it will fall? If you only want to chime in as agreeing or disagreeing, upvote or downvote.

I hate this sort of henclucking. Since I haven't formally renounced it yet, I thought I would do so once, just so that I'm on record. So, anytime that you reply to a post of mine in the future and I fail to resond in a never-ending contest of one-upmanship, do me a favor, and just assume that the lack of reply means "I've said what I have to say, and I don't like how you work". Now, in the past, other poeple have pointed out things that were useful and interseting - not just to me, but to anyone reading - and to those people - you know who you are - I'm grateful.

-scott

Addendum: PS - okey, maybe I don't like you for other reasons, haven't had my coffee, am just bitter because no one uses typesafety.pm and am probably wrong. I'll take a more careful look - if they do infact allow delegation I'll be seriously impressed. Still, I really really need the negitive exp - I'm starting to itch past level 4 and there are too many exp whores here. Whores! Whores!

[chromatic]

I'm sorry you're offended, but as far as I understand your argument, it's that:

• Perl programmers don't understand good OO programming.
• Perl 6 won't improve this.
• Perl 6 is adding roles for some reason.
• Roles complicate inheritance.
• Roles don't solve the real problem.
• Perl is doomed because Perl users are willfully ignorant.

I don't really care to argue whether I understand OO, because that's pointless. I don't particularly agree that Perl is doomed. I'm not thrilled when you imply that my head is "up my arse". It's not really worth replying to those points, though.

I do care that you seem to be confusing roles with inheritance, because the point of roles is to escape the oft-broken fascination with inheritance that seems to plague the popular object systems these days. That's why I've been arguing for them in Perl 6.

Again, I'm sorry if you're offended by me saying "Your conclusion seems wrong because your supporting argument is wrong." But what do you expect when your arguments are both insulting and wrong? If you wander around punching people, some of them are going to react.

[TimToady]

Please don't assume that Perl 6 will not support delegation. (At least, don't assume it so hard...)

[Anonymous Monk]

Maybe if typesafety ran on as many platforms as perl, perl users may be more inclined to give it a try.
• http://testers.cpan.org/show/B-Generate.html

[Anonymous Monk]

Sort of like "everything" in the "Everything Engine". Each node is an embodiment of potentially everything.

I don't think you understand how the Everything Engine works, and furthermore, I don't think that presenting a false understanding in order to draw an even more flawed analogy will bring you closer to proving your thesis.

Rather, it makes you look foolish and ignorant.