I found an anti-perl rant that's worth looking at, by using the RSS feed searcher at Feedster (which is a useful bookmark).
He makes an interesting point. Most of the "tough" tasks are "too easy" in Perl, and the view from the outside is that we simply wouldn't know how to solve things "the hard way" which he seems to think is the only way that will survive the test of maintainability.
He also claims that it's impossible to write code that is large and maintainable. Hmm. That doesn't seem to fit the experience of many of my clients.
Quote
jdavidb on 2003-03-28T19:10:30
how do you tell when a regexp has a false positive match?
Well, I don't know. Could it be that your inability to tell reflects more on you than the language?
Got that far and gave up since it was clear the man described himself sitting around stuck on problems not knowing what to do because he was inexperienced, and attributed it to the language.
Relevance...
Terje Bless on 2003-03-28T19:19:09
Note that while that message was apparently posted in 2000, Erik's antipathy for Perl and his original rant on the subject dates back several years previous AFAIK (I wouldn't be surprised if 1996 or 1997, or even earlier, were the case). It also presupposes that only one set of values and goals are valid.
Re:Relevance...
chromatic on 2003-03-28T19:59:13
It also presupposes that only one set of values and goals are valid.
That, to me, is a reasonable critique of many things that come out of MIT, Lisp among them.
I'd like to think that I'm a force for quality, maintainability, and sanity in coding in the Perl community, so I do appreciate elegance and correctness in code. Still, it's most important to get the job done. If that means writing a one-liner I'll never use again, so be it.
What people don't understand ...
johanvdb on 2003-03-28T22:10:05
What people don't understand, they destroy.
Let's face it, Perl is not the easiest language to master in a correct way. It is a natural language and in that sense, it gives a lot of freedom to do stuff.
People with a sysadmin background often use Perl as their first step into 'real' programming. Most of these will keep their shell style scripting habits, but wrap them in a Perl syntax. Eagerly using the extra features they find, especially hashes.
Other IT bonzos that come from an OO background will not appreciate the - to their eyes - clutter that has been produced by the sysadmins. Also, lets face it, OO in Perl is painfull to get right when you see it for the first time. The amount of structural code needed to create a class is huge. But once you know the basics of 'how to do OO in Perl', you'll see it is actually liberating and you can do a lot of stuff that the java guys can only dream off. You have to see their faces when after 10 minutes you have produced a fully functional class with 20 or more getters and setters and they are typing as hell to write all those accessors down ( Hail to AUTOLOAD! ). And again the hashes seem to have a strange attraction on the OO crowd as well.
A total other camp seems to be the functional guys. Again they will shiver when confronted with the procedural style of the sysadmins, because everything needs to be a list, not? Well, without any guidance, these people will not be attracted to Perl, because not enough functional examples exist (Except from the Schwartzian transform). But once confronted with methods like 'map', 'grep' or concepts like 'closures' they open up and start to see the benefits. And again, these people also seem to be attracted by the hashes, like flies to a light bulb.
That makes me wonder, when I was first introduced to Perl I also had a strange atrraction to the hash datatype. Trying to conceive difficult data structures, tying them to files etc
... In the end, they indeed grew into a kind of mutant monster, conceived in dark places in the brain
...
The Erik guy also found a strange attraction to the hash-phenomenon, as we read in the rant:
"incredibly braindamaged uses of hash tables"
Anyway, back to topic now
...
So maybe, the freedom in Perl is the doom of Perl. I guess a bit of guidance can help here for the uninitiated. Try to convince them that the freedom they get is a good thing! (Although, this is also disputable. History points out that most people need guidance in there life and actively seek guidance. But that is good, because this allowed human kind to evolve into the complex social individual beings we think we are)
Another problem is that there are too much bad examples of Perl code out there. But there is hope, as there are also a lot of beautifull examples of Perl code. Especially in the recent years, as more and more people are getting into the deep details of understanding the Perl language
...
maintainable and scalable
TeeJay on 2003-03-29T00:34:25
I have worked on several very large perl code-bases, I am currently working on avery large code base.
It is being refactored and like any code that was developed up to 4 years ago it is a bit rough around the edges, but with Test suites, log4perl, SQL Phrasebooks, Autodia generated API documentation, Good use of modules, and templates to seperate code from presentation it is fairly managable
It will be even more managable once we finish moving all the suitable SQL into the phrasebook and refactor out the dubious code in the darker corners, but a) it works and b) we have not been bogged down when developing new features ( directors don't tend to view refactoring and abstraction as a good way to spend development time, when clients and staff are requesting changes, fixes and features ).
Eventually we might move parts of the system to TT, but there is a large investment in HTML::Template and apart from jumping thru a couple of hoops to munge data into something that H::T can use is easier than rewriting hundreds of templates and hundreds of cgi's.
one point
wickline on 2003-03-30T16:13:36
As I read that rant, the 'Big Problem' with perl is that it makes it easy to work with bad data (particularly poorly-formated data), and so perl programmers will tend to work with bad data rather than working to change whatever process produced the bad data so that they can work with good data.
Suppose I grant that it is a flaw to work with bad data rather than to work to fix the process which produced that data. Suppose further that I grant that there is a correlation between languages which allow programmers to work with bad data and the tendancy of programmers using those languages to work with bad data rather than to work to fix the process which produced the bad data.
Granting those premises does not allow me to conclude that those languages are flawed. Instead I can only conclude that overly many programmers are falsely lazy. The rant should be focused on the lack of discipline in the perl programmer population. As many perl programmers come from a diverse set of backgrounds, frequently with little formal programming education, this is not really a shock.
My understanding of Lisp is that most practitioners come from computer science and AI/cogsci backgrounds, or approach Lisp as a second/third/Nth language after learning that they enjoy playing with neat languages. The population of Lisp programmers probably has more programmers with formal training, or at least with more prior programming experience.
So, Erik may be comming from that background and seeing the Perl programmer population as a horde of amatures with no discipline. Maybe he's right. Perl lets programmers speak 'baby talk' as they learn the language. However, the fact that one can get work done after learning a tiny fraction of the language is not a flaw in the language. If a manager hires someone who only knows a tiny fraction of the language and expects them to work on critical projects, the flaw is with the management.
Erik is witnessing managment flaws combined with a language which has a shallow learning curve, and incorrectly (IMO) drawing the conclusion that the language is fundamentally flawed. If O'Reilly were to publish as many Lisp books as they have Perl books, and Lisp were to have a CLAN as cool as CPAN, then I suspect it would only take a few years for Erik to become equally disgusted with Lisp.
-matt
P.S.: CLAN is a cool acronym... maybe they really should do that
;)
