On Wed, 06 Dec 2000 05:52, Matthew Byng-Maddick wrote:
> > 6. Engineering
> > The Perl community is made up of a truly eclectic group of people, which
> > is an amazing strength. However, it's also an amazing weakness: I get
> > the impression that very few programmers in the Perl community spend a
> > lot of time *reading* books on software engineering and techniques
> > thereof... and
>
> I'm not convinced about this. Although from my limited experience, I'm not
> very fond of them....
Hmmm, I'm not sure if you're talking about the programmers or the books. Ha.
But seriously, I lose a lot of respect for people who don't continually
study software engineering yet call themselves developers. Our craft is
constantly evolving, and to ignore the material that's available to us to
learn new techniques is completely irresponsible and it leads to some of the
problems that we are bemoaning in this very thread.
> > that lack of knowledge tends to bleed over into a lot of code out there.
> > We have a HUGE problem in the community of the "coder superstar"
> > mentality...
>
> yup.
>
> > which is very dangerous. Perl allows far too many tricks, and often code
> > ends up totally unmaintainable and unreadable because some coding yahoo
> > put in some glory-code. It happens in many languages, true, but Perl is
> > the ideal environment for it.
>
> Not necessarily. You can get coder superstars who write maintainable and
> understandable code.
OK, terminology problem... I wouldn't call them "coder superstars" *if* they
write maintainable and understandable code. Perhaps I should have called
them "glory coders" instead. You're totally right, there are plenty of great
coders out there who conform to coding standards and don't write tricky code.
But what I mean is that there is an abundance of glory-coders in the Perl
community because, in a way, the community encourages it. That doesn't fly
in a large-scale project and greatly reduces the chances of mod_perl being
adopted in the enterprise (IMHO).
> > * We implement a "mode" under mod_perl, kind of like "use strict", that
> > suddenly forces Perl to behave well from an object-oriented standpoint.
> > By this, I mean taking some of the power away from Perl that causes
> > trouble, like allowing anyone to write instance data on an arbitrary
> > instance of a class...
>
> No. no no no. Forcing perl to behave as "Object oriented" is entirely the
> wrong thing. This is why Java sucks so much. "Everything is an object"
> (excepting, obviously, the language primitives). Perl is nice because you
> can write it functionally or object oriented depending on the problem
> you're trying to solve. Also this functionality is more core Perl than
> mod_perl.
Ok, you're missing my point but that's partially my fault for not explaining.
First, let me agree: Java's "everything is an object" mentality sucks
balls. And yes, Perl's duality of functional/OO is really nice. Taking that
away is not what I am advocating... I think there should be the *option* in
Perl to disable certain features that make Perl a dangerous language for OO
development. First and foremost, the lack of true encapsulation is
disastrous. There is no concept of private data because instance data is
stored in a blessed hash (typically) that's open wide to the world. It makes
it tough to create a true interface/implementation dichotomy that is
important in the OO world.
> > * We "homogenise" some foundation classes. This means we create a
> > *suite* of classes that have consistent API, are designed together as a
> > framework, and are easy to learn
>
> I think you need to get out of the "object-oriented-only" mentality. But
> yes, sort of, agreed.
Ummmm, remember, this thread is about mod_perl advocacy. In my mind, we will
have huge problems encouraging enterprise adoption of mod_perl without some
fundamental changes. No enterprise in its right mind would choose a platform
that is not OO for any large project these days. Regardless of whether you
like this or not (and I can tell that you don't), it's the truth... you said
it yourself. In order to fight the Java juggernaut, we have to beat them at
their own game. Perl has so many advantages over Java that that shouldn't be
a problem, yet it is. Primarily, it's one of perception... Perl is a
scripter's language, Perl is for hackers, Perl is great for sysadmin tasks...
but it's also a technical one. Java has a set of foundation classes that
everyone uses. They suck festering balls, but they're there. We can learn
from that and build a set of consistent classes that allow developers to
build web *apps*, not a shitload of scripts that kinda work together as
glorified CGI, which is what we get all too often now.
Yes, Java is a sorely broken language, but it's being adopted, partially
because of Sun's hype but also because it offers enterprise developers real
ways to encapsulate their business logic properly. There are a few reasons
why mod_perl can't fill the same role, and I think we should endeavour to fix
those things.
Cheers
kyle
--
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
