in reply to Re: Re: Re: Often Overlooked OO Programming Guidelines
in thread Often Overlooked OO Programming Guidelines
Hi ysth,
"Hackish" is kind of vague, perhaps intentionally. I don't think anyone is saying perl's OO is bad, just quick and dirty. The implications of what it is are more interesting than what it is. Implications:
Not default. Programs aren't forced to use it. Good,
in my book.
Not helpful.
Doesn't encourage good style.
Negitives, point by point:
Not Helpful:: That is, completely unhelpful in diagnostics and debugging compared with virtually any other OO implementation. Privacy levels, prototypes/typechecking, and so on exist to help a programmer who can't keep a large project in his head (or a team of programmers who can't). If a method doesn't exist I'm trying to call, I want to know about it at compile time, not a month down the road when a client clicks on things in the wrong order and some corner case runs.
Doesn't encourage good style:: Java is adding multiple inheritance grudgingly, and a lot of people say they shouldn't. It has willfully not so far. So, Java makes good style easy and bad style possible. Perl makes bad style easy and good style possible. Privacy, finalization, data hiding, strict typechecking (yes, you heard me) and so on are all possible in Perl, but they aren't easy. They require additional syntax and sometimes don't mesh well with other language features. On the other hand, breaking encapsulation, multiple inheritance, and other things of questionable style are all easy in Perl. This doesn't matter if you know your way around, but a novice programmer assumes that is easy is what they are supposed to be doing. If the langauge encourages you to multiple inherit and encourages you to access data in a class as if it were a hash, then it must be the best way. People don't read documentation until and unless all other things fail. This is a well known principle =)
So, when I say Perl's OO is hackish, what I personally mean is it is something that kind of happened through tinkering and building (hacking), not something designed, specified, tested on focus groups, with second opinions from industry experts. But that doesn't mean that we can't continue to hack on it in future versions (eg, 6) and do RFC processes to form a coherent design, learn from feedback, visiting Java programmers, and so on. Hackish isn't fundamentally bad. It fits with "release early, release often". We just need to hack on it some more so it is less hackish =)
-scott
"Hackish" is kind of vague, perhaps intentionally. I don't think anyone is saying perl's OO is bad, just quick and dirty. The implications of what it is are more interesting than what it is. Implications:
Negitives, point by point:
Not Helpful:: That is, completely unhelpful in diagnostics and debugging compared with virtually any other OO implementation. Privacy levels, prototypes/typechecking, and so on exist to help a programmer who can't keep a large project in his head (or a team of programmers who can't). If a method doesn't exist I'm trying to call, I want to know about it at compile time, not a month down the road when a client clicks on things in the wrong order and some corner case runs.
Doesn't encourage good style:: Java is adding multiple inheritance grudgingly, and a lot of people say they shouldn't. It has willfully not so far. So, Java makes good style easy and bad style possible. Perl makes bad style easy and good style possible. Privacy, finalization, data hiding, strict typechecking (yes, you heard me) and so on are all possible in Perl, but they aren't easy. They require additional syntax and sometimes don't mesh well with other language features. On the other hand, breaking encapsulation, multiple inheritance, and other things of questionable style are all easy in Perl. This doesn't matter if you know your way around, but a novice programmer assumes that is easy is what they are supposed to be doing. If the langauge encourages you to multiple inherit and encourages you to access data in a class as if it were a hash, then it must be the best way. People don't read documentation until and unless all other things fail. This is a well known principle =)
So, when I say Perl's OO is hackish, what I personally mean is it is something that kind of happened through tinkering and building (hacking), not something designed, specified, tested on focus groups, with second opinions from industry experts. But that doesn't mean that we can't continue to hack on it in future versions (eg, 6) and do RFC processes to form a coherent design, learn from feedback, visiting Java programmers, and so on. Hackish isn't fundamentally bad. It fits with "release early, release often". We just need to hack on it some more so it is less hackish =)
-scott
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re: Re: Re: Re: Often Overlooked OO Programming Guidelines
by Anonymous Monk on Dec 31, 2003 at 08:26 UTC |
In Section
Meditations