[Gllug] re: OSS CMSs

Aaron Trevena aaron.trevena at gmail.com
Thu Apr 28 12:49:30 UTC 2005


Doug Winter pulled from his arse :
> > Ian Norton wrote:
> > Thats a pretty sweeping comment, what exactly so readily springs up in 
> > your mind as being the problem with perl?
> > what are these serious flaws? perl was designed as a text processing 
> > language (afaik), and it seems to do that
> > pretty well when rendering a good proportion of the worlds web pages.

> It's very hard to write good perl, and most people don't.  The standard 
> libraries (CPAN) are a nightmare.  The code is very difficult to read at 
> the best of times, and is almost completely unmaintainable.  It actively 
> discourages object orientation, it encourages invisible side-effects and 
> uses obscure punctuation to actively disguise what it's doing.  It 
> converts between datatypes invisibly and with an almost cavalier 
> disregard for good practice.  In fact, it seems to be a language that 
> goes out of it's way to make it difficult to write reliable software.

Sorry Doug but you (and a couple others here who ought to know better)
are talking out of your arse.

It is quite trivial to write good perl. There are modules and
documentation explaining how, and most people do.

Thats why you see Jobs in banks moving important financial data around
asking for perl not python or php or lisp or ruby or whatever new
trendy language is fashionable with the slashdotters these days.

CPAN works well, particularly if you know how to use it and perl. The
standard libraries install in a standard way, have standard packaging,
documentation and tests. Modules are rated and have optional QA - You
can check ratings, reviews, bugs and Quality easily through the cpan
website. Dependancy handling is also automated when you install via
CPAN.

Much of the common and popular code on CPAN is written by experienced
perl developers with good API's both functional and object-oriented.
There are frequently choices of packages for a particular task
depending on your needs and you can view the API and any feedback
before you download.

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.

PHP and ASP make it often nearly impossible to make head or tail of a
complex project as it lacks namespaces and is often written by
inexperienced developers who lack design and organisation experience.

Perl on the other hand provides more expressiveness than python so
that scary stuff can be organised or broken into smaller chunks for
easier testing, debugging, commenting and reading while also allowing
you to write trivial functionality without wasting space.

Perl also has a wide variety of libraries that take the drudgery out
of object oriented programming - you have always been able to write
Object Oriented Perl easily (well since 5.0 and that was over 10 years
ago) and now Class::Accessor, Class::DBI, etc provide tools to make
powerful reliable OO that makes Java and C# look rickety and rough
around the edges.

A choice of Application Servers from Maypole to Catalyst and dozens of
proven commercial Content Management Systems are available that put
Rails, Zope and Spring to shame.

Current perl practice is actually providing a very high quality of
code. You can choose to write bad code in any language but you can
choose to use the right level of validation, strict typing of object
attributes, persistance, etc in Perl.

All this bullshit about quality makes me ask - so doug how many unit
tests and application tests have you written this week - I bet most
perl developers have written more tests and documentation that you,
and I know who's code I would rather maintain.

A.
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list