|
in reply to Re: OO-style question
in thread OO-style question
I think Perl still needs to be explored in large projects, and a comment about Perl being kludgy. It's Perl's kludginess I like. In comparison, Java seems so steril. The problem with Perl code on large projects is the level of efficiency demanded by the base functions(ok all of them).
Perl's freedoms come at a price when coding in OO. The demands on the quality of every function begin to make exponential performance variations. In fact in the end (come on Perl 6!!) many of the exponetial problems that occur now may lessen with improved garbage collection, or is it that my code is just that sloppy ... hmmm
Anyway I really think in the end Perl OO has a shot at Enterprise Acceptence even by the more conservative houses. C++ will always be highly demanded in such organizations, but Perl OO could open up even at the developer level in such corporations if it's objects could be of proven value in the enterprise's reusable component library.
coreolyn Duct tape devotee.
-- That's OO perl, NOT uh-oh perl !-) |
Re: Re:: Adam:: Re:: OO-style question
by merlyn (Sage) on Dec 30, 2000 at 09:03 UTC
|
| [reply] |
|
|
It's not the usability of Perl that is in as much doubt, as it is Perl's maintenance, administration, and re-usability that keeps it out of reach for developers in mainframe centric organizations.
I have spent this last year writing white papers and giving lectures on Open Source and Perl in particular for my 'mainframe centric' company. We now have passed proof of concept for linux on the mainframe and have two internal clients (out of hundreds) that are pushing foward with Perl dependent projects.
However, Perl is still stuck in the legal offices. This company has been able to collect money for every CPU cycle and re-use of every script from every project. Code that is neither owned by the corporation or liable by another company is kept out of production. Open Source is in total opposition to decades old philosophies and practices.
I'd also like to point out that behind most of the sites you list as proof, are corporations that are being the clearing house for all the credit card transactions (and credit bureau checks) they process. You WANT a conservative organization managing such processes. Furthermore, none of the sites you list above, manage projects that span the number of various simultaneous projects, protocols, security and support issues that mainframe centric organizations tackle daily as a matter of course. (I'm not even going to get into the diametrically oposed mindset/culture of Open Source developers and Mainframe developers).
Until Perl can prove it's feasability in managing reusable components accross diverse achitectures and projects as Java (i.e., Application Servers), it will remain just limited to 'duct-tape' operations in the Enterprise.
This is not a goal that is too far off the horizon. Another part of my job is to evaluate Java Application Servers, and I can tell you they are all seriously overpriced, overbloated, over acronymed monstrostities that are little more than J2EE enabled webservers with high pressure marketing departments working harder than their technical departments are to support or develop them.
coreolyn -- Duct tape devotee and corporate Open Source choir boy.
| [reply] |
|
|
ActiveState, to pull a vendor out of a hat, offers support contracts for their distribution of Perl. That should satisfy your legal folks as far as the actual Perl environment is concerned. It's not a large leap to make the developer liable for the code used in the 3rd-party modules themselves, but that seems like an imperfect solution.
| [reply] |
|
|
|
|
| |
|
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.
| [reply] |
|
|
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] |
|
|
|
|
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.
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 ...
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] |
|
|
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] |
|
|
