Re: Re: Re:: Adam:: Re:: OO-style question

Its not a question of "does it work, can we do it?" Thats a given, I wouldn't be hanging around this site if I didn't think that Perl works and that it can an amazing amount of stuff (almost anything, really...)

The question is, "Should we use it for this?" and, in my opinion, there are places where the answer is "No." That has been my opinion for some time now, and it hasn't changed. I think that large scale OO projects are a perfect example of where Perl just doesn't cut it. OO methods need to be short and simple while garaunteeing correctness. They need to be able to throw named exceptions which the caller can choose to catch or not. die is the closest thing to an exception in Perl, and eval is a long way from a try block. Worse, perl's sub routine simplicity of having subroutines take a variable number of arguments and always return some value make for a large amount of additional code involved in checking arguments and returning undef when you want a void method.

Large projects involve multiple programmers from various backgrounds and skill levels. You have to write the code so that the least experienced programmer can work on it with-out breaking everything. And lets face it, Perl just doesn't provide that level of support. Is that a bad thing? NO. That's what makes Perl so much fun - its flexability. But that's also what makes it innappropriate in a large scale project. Sure, an extensive set of coding standards and a crack team of programmers could do it, but eventually some fresh out of highschool skill-less kid is going to have to add a minor feature, and the whole thing will come crashing down. That's why people like C++ and Java and those other languages, they make for maintainable code.

Comment on Re: Re: Re:: Adam:: Re:: OO-style question

Replies are listed 'Best First'.
Perl vs Other Languages by tilly (Archbishop) on Dec 31, 2000 at 08:45 UTC
I agree with you that Perl is not always the right tool for the job. I even agree with you on some of what its weaknesses are. However I have to disagree on your belief that somehow other languages are necessarily better. My opinions have come up before. For instance I state them at length in RE (tilly) 1: Java vs. Perl from the CB. More (IMO good) points at RE (tilly) 3 (disaster): Java vs. Perl from the CB. There is no silver bullet for maintainability, and indeed it is a sore spot for the whole industry. That said, the kid you see breaking a Perl project will cause pain on a Java project as well. IMO the only good ways to use incompetent people are move them to someone you don't like, put them on data entry problems where you don't really care what they do, or invest the time and energy to make them competent. I prefer the last option but YMMV. But I don't consider it a good criticism of a language that it gives people who shouldn't be given responsibility the ability to cause damage if they are given that responsibility. To me that is, "Well, duh. Don't give them responsibility." But I would diss a language for making competent people unproductive... Now, Perl is not right for all problems. I agree that large OO projects are an example of a problem it is bad for. Another is complex GUIs. Another is anything where tight space/time optimizations matter. (Just ask jcwren for more on that.) So learn its strengths and weaknesses, then use it where it fits.	[reply]
Re: Perl vs Other Languages by mkmcconn (Chaplain) on Jan 01, 2001 at 02:43 UTC
says tilly Now, Perl is not right for all problems. I agree that large OO projects are an example of a problem it is bad for. Another is complex GUIs. Another is anything where tight space/time optimizations matter. (Just ask jcwren for more on that.) So learn its strengths and weaknesses, then use it where it fits. Being very new to programming -- self-taught and not a fast learner -- much of my time has been spent trying to decide which language to work on the most. Perl wins my time, not because of a technological benchmark, but because it proves itself the most practical solution. That is, as I've begun to conclude: the most important aspect of any language's practical value is, there must be a community practicing the language. It's from their use of it, that I've learned its usefulness. I learn from the users of the language, the mode of thought that taps into the power of its expressions. I observe from them how the language itself structures their thoughts and coaxes out new ideas. I observe how the language shapes, and is shaped by the ethic of the community. I learn in this way not only how to speak, but how to think that way. I'm discovering that a programming language is something like a natural language in that way. It does not consist only of its terms and syntax, its design and structure, its parts. Besides these low-level issues, a language is its users and the use they make of it. So, the aspect of Perl that most commends it to me as the best solution to most problems is, the way it's used by people to solve their problems. As long as Perl continues to be characterized by this push to improve, and helps others to improve (which includes an ethic capable of discerning who shouldn't be helped), it will continue to be the most natural choice for people looking for a practical solution, and the language itself will continue to improve. mkmcconn	[reply]
Re: Perl OO, exceptions, etc. by btrott (Parson) on Dec 31, 2000 at 08:04 UTC
When speaking of OO methods, you wrote: `> They need to be able to throw named exceptions which the > caller can choose to catch or not. die is the closest thing to a +n > exception in Perl, and eval is a long way from a try block.` [download] Have you tried using a custom Perl solution for this? Graham Barr's Error module (direct doc link) lets you use standard try and catch semantics for exception handling. I've not used it, because I've always just stuck w/ eval, because it works for me. :) You might also take a look at Exception::Class, a base exception class on which you can base any exceptions your system wishes to throw. You also wrote: `> Worse, perl's sub routine simplicity of having subroutines > take a variable number of arguments ...` [download] Have you ever looked at Class::MultiMethods? It might help you in this area, if you like that sort of structured stuff. :)	[reply] [d/l] [select]
(tye)Re:: Adam:: Re:: OO-style question by tye (Sage) on Dec 31, 2000 at 11:01 UTC
Gee, `eval {}` seems nearly identical to a "try" block to me. It is the "catch" part that you need to add, but several people have already done so. I think if more people were to try more of these modules then soon we'd have some improvement to some of them and then some agreement as to which ones work best and we might even end up with a "standard" module that ships with Perl and modules could start using structured exceptions and things would snowball from there... The lack of good subroutine prototypes is certainly a problem. Though there are modules that provide different replacements for that (Class::Contract is one that I don't think has been mentioned in this thread yet). A worse problem is the clumsy nature of Perl's inheritance. Books teaching OO tend to make a big deal of inheritance. Books teaching how to write good code in C++ make a big deal about avoiding inheritance (not avoiding it altogether, just avoiding it unless it is really called for, which it usually isn't). The case for this avoidance is much, much stronger for Perl. You can't inherit only the API (unless you use some module for that -- and the only API Perl defines is a list of method names anyway). You can't have subroutines that aren't also inherited. You can't inherit members (aka member data to those who like to call methods "member functions") (unless you use a module and the ones I've seen still leave much to be desired here). You can't do useless inheritance of useless class data (: - tye (but my friends call me "Tye")	[reply] [d/l]