[Gllug] re: OSS CMSs
Aaron Trevena
aaron.trevena at gmail.com
Thu Apr 28 14:56:31 UTC 2005
On 4/28/05, Tethys <tet at createservices.com> wrote:
>
> Aaron Trevena writes:
>
> >Dependancy handling is also automated when you install via CPAN.
>
> Which of course you wouldn't be doing in any halfway sane commercial
> environment...
Of course any halfway sane commercial environment uses a staging
server, on which you test not only Perl Module updates, but OS and
other library updates.
Also perl allows you to run different installations side by side,
specify to follow dependancies or not, specify to allow
uninstallation, and your own trusted local production code only cpan
mirror, or you could rsync from staging to live.
So I get managed dependancies and I get a reliable production server.
It's quite civilised.
> >I'm surprised people still trot out the myths about perl being
> >unmaintainable and hard to read. Any language can be made
> >unmaintainable and hard to read.
>
> Oh agreed. The perl that I've written is clean and obvious (then again,
> ask any programmer and they'll probably say the same thing). It's just
> that perl makes it so much easier to write unmaintainable code than most
> other languages (although PHP is heading in that direction too).
> Perl doesn't have to be impenetrable.
No, in it fact ensures that you can write clearer code than PHP,
python, or Java. Only somebody with no perl and no real programming
skills will find even the most mediocre and pedestrian perl hard to
read and understand.
Perl makes it easy to write clear code, you have to be a fool or doing
something stupid to make unreadable or unmaintainable perl code. Perl
allows you to write to your ability or needs - if you are coding
problems beyond your ability it will show, if you try and use the
wrong idiom or syntax for a job it will show.
If you are a competent programmer and made even the slightest effort
to implement any of the abundant good practice and methodology
available, then your perl code will be clear, concise and
maintainable. Tests and inline documentation help with this as do the
many other tools available for a perl programmer from perl mongers to
books, to regular workshops.
There is no excuse for writing inpenetrable perl, only those who can't
code blame perl for their own problems.
> But empirical evidence shows it to be so far more frequently
> than code written in other languages.
Thats bollocks. For every Slash there is a Bricolage and a Kerrang,
for every Matt's Script Archive there is a NMS and a dozen tutorials
and books.
Other languages have a far bigger abundance of bad code - PHP has a
handful of good applications but the language and inexperience of the
developers makes them unmaintainable and a car-crash to view in any
editor. Python lacks the expressiveness leading to code that looks
like either unreadably terse LISP or overly-verbose Java, and it
suffers from OnlyOneWayToDoIt and NotInventedHere - no standardised
API's between modules like perl's Email:: or DBI:: or Class::
namespaces, so python coders have to code around whitespace
limitations as well as the lack of libraries.
Java is too verbose to ever be managable without thousands of pounds
worth of Library's, IDE's and other tools and the same applies to C#.
So - have you got any facts to back up these claims about the
ubundance of bad code or are you talking out of your arse like doug?
A.
--
Gllug mailing list - Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
More information about the GLLUG
mailing list