On Tue, 5 Dec 2000, kyle dawkins wrote:
[1. two types of developer]
agreed.
[2. Perl4 / Perl5 ]
This is also true. Although a lot of "Perl programmers" haven't got a clue
about the object orientation stuff in Perl5 either. On the other side of
the coin, too many people are jumping on the "It's object oriented, it
must be reusable" and "The only way to solve problems is using objects"
bandwagons. Java and C++ both play to these. And unfortunately they've
convinced management, in general. Plus, big corporates like to deal with
corporates - Java is defined by Sun, a corporate. This is always going to
make our life hard...
> 3. Installation/setup
> Ok, so if you have Linux, it's a piece of cake... download all the sources,
OK. but s/Linux/a UNIX or UNIX-alike/g.
> follow the README's, and go. But what if you don't have Linux? Or you
> aren't root, and what if you need access to httpd.conf to keep changing
Then you don't necessarily do it on port 80. This is the only reason you
need to be root.
> stuff? And developers are going to need to cycle the server all the time, so
> they need the ability to do that, too... it's definitely a weak point. I can
> install any one of the Java-based web application frameworks and be
> developing immediately.
I disagree. The webserver stuff still needs to be run as root, or you run
it on a different port. Although I would also suggest having a look at
userv (http://www.chiark.greenend.org.uk/~ian/userv/), although there are
some security holes opened up by using mod_perl.
> 4. Isolation
> A lot of mod_perl projects (or even Perl projects in general) tend to be
> one-person shows... maybe I'm wrong, and I'd love it if people could correct
> me! But in my observation, we have a lot of programmers working in
> isolation. This is bad.
<plug>http://codix.net/</plug>.
> 5. Foundation libraries
> Because of the open nature of the CPAN community, there are a lot of great
> modules floating around out there. However, there is no real API consistency
> in them, and this will cause newcomers to Perl a fair amount of trouble.
> Moreover, we're not going to get anywhere in the enterprise if people insist
> on using HTML templating systems that allow the embedding of code within
> HTML. It's straight up and down a total disaster and no right-minded
> software architect would ever consider it.
Agreed.
> 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....
> 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.
> --> SO <--
> I hope you guys can give these points some thought. I could be "smoking
> grass" but I think I'm on target on most of my points and I'd love to hear
> what you guys think too. In the meantime, here are some ideas that might go
> down well (or not!):
Not entirely.
> * 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.
> * 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.
> * We need to drop-kick DBI out of the park... it's not that it's bad (it's
> actually great... kudos to the DBI crew) but kind of the opposite; it's so
> easy to use that most people don't think beyond it. How many of you have
> ever thought about implementing an Object-Relational middleware layer using
> mod_perl? We could create a set of generic OR classes as part of our
> foundation framework.
DBI is actually quite a hassle to use sensibly, and I've got my own
library functions that call the DBI ones, and return errors in a way that
is consistent. I also have the run object open DB connections. (YATS)
<another plug>http://codix.net/ASPerl/</plug>.
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
Genius may have its limitations, but stupidity is not thus handicapped.
-- Elbert Hubbard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
