As I read reactions from people to JT Smith’s Perl is Dead. Long live Perl. I see the usual knee-jerk claims that Perl inherently leads to unmaintainable code.
In my vast experiences in dealing with difficult-to-maintain code, I’ve noticed that nearly all of the messes I’ve seen had comments, documentation, and identifiers written in English. English is not an easy language to learn. It has inconsistencies (irregular verbs! homophones! homonyms!) and quirks (idioms! punctuation styles! possessive marks!) which make writing perfectly correct English–or even succinct and direct English–difficult.
There’s one good reason it’s difficult to produce correct and successful software from a full specification written at the start of a project.
Yet somehow it’s acceptable to allow programmers, presumably smart people with the ability to juggle small details, to write terrible, horrible, incomprehensible English but not comprehensible, concise, and correct code in languages which are orders of magnitude simpler than English. Hey, if you can use the pronoun “it” appropriately in English, Perl’s topic variable $_ should give you absolutely no trouble!
If (perceived) simplicity and regularity of the language were truly an important factor toward the maintainability of software, we should all be using Esperanto or Lojban to talk about our software. It’s not as if we don’t expect programmers to be able to learn new programming languages where appropriate.
Perhaps the true source of maintenance problems lies elsewhere.
It's not so much readability or maintainability that puts me off Perl nowadays, it's rally just getting the m/(i.*?s)/; thing to work in the first place.
But then I'm not a full time, professional developer. I'm just a sysadmin type that needs to write some scripts now and then. For almost a decade I used Perl and shell for that, but for me and people like me the idiosyncrasies of Perl are just too much.
I'm sure you're absolutely right that Perl is a great language for large scale projects, maintained by people who live and breathe Perl day in day out. Frankly I wouldn't use Java or C£ (effing Mac keyboard!) either because they are too much effort for the kinds of things I do as well.
As the article points out there are just more choices now. As a casual programmer, I find Perl is too much hard work and I think the odd looking syntax puts off new learners, but if you're keeping up over the learning curve it's an incredibly powerful toolkit. I wish Perl well, but I think like a lot of people I've moved on.
@Simon, that's a useful perspective. What kinds of idiosyncrasies do you run into that make dabbling in Perl for SA work difficult? I'm curious if they're mostly language features or difficult APIs in some of the most useful modules.
(It'd be nice to start fixing them, but first we have to identify them.)
I am just an SA as well but I love Perl for doing everything I can scripting wise. I wouldn't want to SA without it. Every language has its idosyncrasies. I find that Perl comes with or has via CPAN everything I need. I have always run short with Python and Ruby. I think it may be a mindset thing.
+1 :)
Sometimes, if more folks followed some form of a standard those unmaintainable programs would be 1000 times more maintainable.
I've seen tons of perl programs that were absolutely terrible that were written by folks who even had books published.
The worst offenders are those that aren't commented, don't follow any standard, and worse yet those authors aren't available to ask questions.
Ain't programming fun :)
chromatic hit's the spot here.
Either you can write clear maintainable code or not, in any language - I haven't seen any anti-pattern that is prevented by the "super maintainable/readable" python or ruby.
I've written clear and well organised vbscript, and I *hated* using that language. I've also seen and worked with utterly opaque and unreadable code in PHP, C#, and python.
The perl 5 base is well designed... but the moment one gets into modules... the code becomes hopelessly illegible. The human mind thinks by pattern matching... and so ideally when looking at a page of written work - what the author of that code sees ought to give him an overview of what that code is about. And each smaller segment should give more detail, as to what is involved. This is how english works. Unfortunately, with computer instructions, one has loops, and all sorts of technical clutter... because the computer needs a series of instructions... it does not think by pattern matching... it is not helped by overviews - it could not comprehend nuance, metaphor, inference, or style.
Whilst I'm not a professional developer, I am an English teacher and reading your comments about the English language was interesting. Learning English is hard (Teaching English as a Foreign Language, or TEFL is a huge industry the world over). But then learning any language is hard. The inconsistencies and quirks you mention are matched by similar problems in other languages (think about Czech with its seven noun cases, or Finnish with fifteen!). So whilst English is hard, it's not that hard. It hasn't become an international language for nothing.
You mention perfectly correct English: there is no such thing! In its absence, it seems the problem you've identified is people's inability to write clearly and succinctly. And surely that makes the English language just the same as a programming language.
I think most linguists would agree that artificial languages that are devoid of irregularities are less suitable to the human brain than natural ones, which all have quirky idiosyncrasies. Perhaps the analogy is not completely appropriate, but the point may not be completely irrelevant either.
What evidence would convince you that Perl had problems with maintainability, or that it was less maintainable than similar programs written in other languages?
The massive rejection in the marketplace isn't convincing you? So do you think people are just born with prejudices against Perl? Keep in mind that the industry standard for maintainability is C++, so the bar is not exactly high here.
And there's nothing about Perl syntax that's unnecessarily difficult? If that's so, why are they changing even the sigils, in Perl 6?
The fact, is most people who do not code Perl all day long simply cannot keep all of the syntax in their head. I think we can agree that the reference syntax is a complete botch, and then there's stuff bolted on top of that to make it work for object orientation. I am not surprised that most people run away screaming.
Computer languages are not like natural languages. Especially for maintenance programmers, it has to be easy to keep the rules in your head, even if you only have a passing familiarity with the language. Often, Perl demands great expertise just to understand what's going on.
Perl was and is a great language. But if you think it's that flawless I doubt you know much about other languages. Dont get sucked into advocacy; it tends to blind you.
@Neil, verifiable facts and statistics rather than anecdotal evidence and argument by assertion could convince me. (That means back up "massive rejection in the marketplace", "industry standard for maintainability", and both "most people" assertions. Alternately, withdraw them.)
If you think I think Perl is flawless, you should read just about anything else I've ever written about Perl. (It's a strawman argument anyway.)
(If you think computer languages aren't like natural language, I'm not sure we'll ever find any agreement. I completely agree with Larry Wall who said that computer scientists should pay attention to linguists, who actually have some research on how people communicate.)
If you think hiring barely-competent maintenance programmers who aren't familiar with both the language and the problem domain is a good idea, well, I'm not surprised you couldn't make Perl work for you. It wouldn't surprise me if you couldn't make any language work for you.
I suppose I deserve that -- I made it personal. I apologize, I should not have taken that tack, particularly in the last paragraph.
Let me give you a bit of background -- I was once as fierce an advocate of Perl as you are. I attended YAPCs. I worked for ActiveState and my knowledge of Perl trivia enabled me to win in-house golf challenges. I own lots of Perl books, from Damian and MJD and more. I continue to use Perl, professionally, almost every day, and I believe it has characteristics that have not yet been equalled by other languages.
The problem is, along the way, I've learned and been paid for Python, Ruby, Java, and PHP coding, and in my spare time I've dabbled with Scheme and Haskell. And I now realize that many of the beliefs held within the Perl community are complete hokum. I find it exasperating that people in the (dwindling) Perl community continue to repeat them, not because I hate Perl, but because you're all driving yourselves off a cliff.
It might take me several pages to deconstruct the lies that the Perl community tells itself, so I will just limit myself to a few comments.
If you want statistics about the decline of Perl, O'Reilly has them:
http://radar.oreilly.com/archives/2007/05/state_of_the_co_10.html
And I used to see similar surveys when I worked for ActiveState, which is six years ago now. My information here is more than anecdotal, although I find it confirmed daily. I am usually well-known in whatever shop I work as the go-to guy for Perl stuff. When I have to explain Perl OO to a Java guy (or even a *PHP* guy), they look at me like I'm insane, and I find Perl's approach difficult to defend.
As for maintenance programmers finding Perl daunting -- you yourself found the point credible, when someone else brought it up in this thread. (He was less combative than I was, but that's more of a lesson for me.)
Neil used the ORA book sales figures to make claims about Perl usage is declining, which shows a pretty poor understanding of what's happening in the industry.
Firstly, developers tend to buy a book once, not every quarter, so if you've sold a gazillion books last year, and only a few thousand this year, you have a gazillion plus a few thousand users (see my next point).
Book sales market share are a nice indicator of what newbies and dabblers find interesting - advanced technical books sales are lost in the noise - but they don't tell you anything about what people are actually using.
So, if Rails is selling a lot of books, that doesn't mean a lot of people are using it for work.
It's much better to look at jobs (Python and Ruby jobs combined in the UK are less than 10% of the Perl jobs), user contributed code (CPAN growth is accelerating) and community growth (perl.org beginner lists are increasingly popular, the number of perl projects, modules, contributors and perl monger groups are increasing).
Perl is the cinderella of computer languages, it does the hard unglamourous work while others slap on the make up and exclaim as loudly as possible about how pretty and popular they are.
Much as I like activestate's komodo, they took their eye off the ball when it came to Perl a long time ago - the PPM repository is years behind the curve, and CPAN has moved forward with new features and cpanplus. I haven't seen much useful Perl work from activestate in a long long time, but I'd love to see them getting more involved in the community.
As for Perl OO - I can't remember the last time I used bless for anything other than dynamically creating an arbitary object, Java people don't just use plain core Java, why would I just use plain Perl Core when I can use ORMs that provide object persistance as well as defining methods fore me - Looking at Java and C++ OO I think to myself how much more work they are to define each method and attribute - with Class::Accessor I can define my attributes, with Class::DBI or DBIx::Class I can define my attributes and get searching and persistence for free.
From Neil: "It might take me several pages to deconstruct the lies that the Perl community tells itself, so I will just limit myself to a few comments."
Kind of a cop out isn't it? Everyone knows Perl's built-in OO is very basic, and has issues (at least compared to something like Java or Ruby). Please provide a link showing people arguing that Perl OO is great. Of course, with the myriad of class builders now available, Perl OO is much more useable. Not to mention the built-in goodies we'll get in Perl 6 (which, contrary to the belief of some ill-informed people, is by no means vapourware).
I'd be really interested to know what you think are the areas where the Perl community is deluding itself about. From where I stand (somewhere on the outskirts) it seems to be one of the most introspective programming language communities around. I'm sure every community has it's blind spots, Perl's don't seem to be as bad as PHP (with their pages of security issues), and Ruby (which is currently riding on the hype).
You can make unmaintainable code in any language. "idiosyncrasies" are part of any community and the Perl community has it's own based mostly on natural selection; sorry, it is not for the mediocre programmers. It's for the artistic programmers, those who can see the art in coding. Java and Python on the other hand, were designed to do things in "One Best Way", I suspect, to be able to accomodate all the mediocre programmers that come out of our universities these days. Yes, it's true, with Java or Python you can actually produce reasonably good or "corporate" (ugh!) code with a large team of robotic programmers, but with Perl (and it's "idiosyncrasies") you can make "dream-code" with just a few smart easy going fellows. And the best part is, that they are actually having fun, and fun makes, good and _interesting_ code.
Furthermore if things like regexps are so cryptic, then why have they been ported to so many "clean cut" or "corporate" (ugh!) languages like Java or the more popular ones like PHP aka JADPC (Just Another Dumb Perl Clone). Worse yet, their regexps ports clearly and shamelessly say "a la Perl"! (is preg_ not clear enough?).
Nevertheless, there are some excellent guidelines you can always follow without losing the beauty of TIMTOWTDI, for example, "Perl Best Parctices" by Damian Conway - O'Reilly 2005 - ISBN 0-596-00173-8. So, even though we _could_ make obfuscated code, we usually make very maintainable, albeit _interesting_, code (or else CPAN would not be what it is). It could perhaps be speculated that the Perl "idiosyncrasies" are much more effective than that of any other communities, since testing is enforced by peer pressure and "Best Practices", and it is probably the only community that actually enforces testing (and it's "idiosyncrasies") this way.
Anyway, what I _really_ wanted to say (and sorry for my bad English as it is not my native toungue) is that one must not confuse "interesting" with "obfuscated", although with Perl and probably any other language, you can do both (as you have probably seen with this non-native English posting ;-) )
From Mutant: "Kind of a cop out isn't it? Everyone knows Perl's built-in OO is very basic, and has issues (at least compared to something like Java or Ruby). Please provide a link showing people arguing that Perl OO is great."
Have to disagree. Perl OO is probably more formal and definitively more interesting than that of Java's. For starters, it directly supports multiple inheritance, and of course the all-time favorite, fidling with the symbol table in run-time - not even in your dreams could you do this with Java. The fact that Perl does not follow the usual idiom for Objects does not by any means imply that is weaker or less formal than that of other programming languages, it is just more interesting and flexible.
Alejandro,
Couldn't agree more. I find it annoying that the features that have people raving about Python and Ruby and Common Lisp are regarded as bad things in Perl. A quick glance at "Higher Order Perl" is in order.
I guess "defective object model" should be understood to mean "different than C++ and Java."
There is a huge difference between the usage of Perl and the usage of English. English was developed naturally, as a language for dialect and communication between humans who both understood the language. Other languages have different roots, different words, and therefore are hard to learn once a first language has naturally set in.
On the other hand, programming languages were developed on purpose. They are designed for communication between a human and a computer. While the human must understand the language, the computer does not need to-all communication is done through an interpreter (compiler). The goal is that as long as you have access to an interpreter that understands the language of your processor and Perl, communication works fine. Perl is not a language for natural speech. It is a language for instruction command. A comparison of the two is like apples and oranges-they are both fruit, but both inherently too different to add together.
English allows ambiguity. Perl does not-it is static typed. All programming languages disallow ambiguity outside of variables. Perl is much harder to use and maintain then Python-but it leads to much faster code. If you already know Perl, you may still want to use it, but newer languages, while they may not kill Perl, will get a higher volume of new users.
I read an excellent article a while back on how the problems with Perl arose from the fact that Larry Wall treated it like a natural language, which it is not. A computer programming language cannot be like a natural language. The differences are critical to proper language design.
You may state that Perl's fallacies are acceptable because they are shared with English, but I'm not convinced. Maybe if they were shared with a mass accepted computer instructional language, like C. Me, I'm sticking to Python.
@Dylan, thanks for taking the time to respond, but I can't let unsupported assertions stand without comment.
Not everyone believes Sapir-Whorf--including quite a few linguists. Besides that, plenty of languages share common roots. If you learn one Romance language, it's easier to pick up some of the others. If you learn Latin or Greek, it's easier to learn many of the words in several languages.
Among plenty of others, SICP's preface disagrees, saying:
Now you're welcome to disagree, but it's not clear that you're taking a majority position here among PL designers and theorists.
Citations please, of data and not anecdotes.
This is an argument by assertion. Please list the differences, if any, and explain why they are critical to proper language design. It might also be useful for you to define what "proper language design" is.
Where did I state that? (I didn't.)
This one's subtle; it's a sideways assertion that Perl is not a "mass accepted computer instructional language". I think you're begging the question, but without a solid definition of what you mean by "mass accepted computer instructional language", I really can't say.
Come now, chromatic. Perl is by no means easy for the human eye to read. Honestly, there should be metatools developed for people to use a graphical interface to design programs. We could even return to our roots, and use machine language, if we had graphical metatools which would help us get the overview of our work, properly. I was reading someone the other day who said that vi is his cms web software. This is a profound statement. Metatools are very important for efficient programming, or for constructing html formatting code. I use Fookes Notetab software to make my work easier... although it doesn't have a REPL in it - which is unfortunate when it comes to scripting.
Perl is a great experiment. It's wonderful to have so many options and ways to do things built into the language. It's nice to be able to write things in a very concise way. But it's more valuable as an idea and a vision, than it is as a practical way to give computers instructions. Perl was the first language I learned, after many long years away from programming. My previous language was BASIC. I was head over heels in love with perl for some time. But eventually, I realized that I couldn't do anything complex which involved a gui, or other modules, because when I woke up in the morning, after a long night of coding, I couldn't read what I had written. It's the way the language is constructed, which makes creating legible code, difficult.
My favorite language currently is Tcl/Tk - now there's a language where humans can read the text after it's written. Especially this is true, because it's very easy to create your own commands, which have the same standing as natural built-in commands in the language. I use the word "write" instead of "puts" for instance. And the word "imprint" instead of "set." Tcl/Tk is like using clay - you can mold the language to fit your own purposes.
I am looking forward to sitting down and learning Lisp or scheme someday. It seems to also have promise, as a tool which can easily be molded to fit one's grip.
@Christopher, thanks for the comment. I do want to explore one thing, however. You wrote:
What features of the language--especially the language design--prevented you from understanding your code?
How complete was your test coverage?
Do you have coding standards?
Did you refactor?
When you used a new feature you had to look up in the manual, or find as a code example somewhere else, did you add a comment in the code?
I suspect--and I'm willing to cast the aspersion--that you poked and prodded at things without really understanding how they worked. That's fine. Perl allows that. Many good Perl programmers started by doing just that. Many good programmers of whatever language start programming that way.
If that's the case, then it's a little bit dishonest to generalize from your personal experience as a novice or a dilettante to the claim that "Perl is by no means easy for the human eye to read."
I could accept "It was difficult for me to write good Perl". Implying that it's impossible for anyone to write readable Perl is... well, I like to think I've written a few lines here and there.
Well, thanks for your very warm reply, chromatic.
Honestly, I think I can say that I got to be an intermediate perl programmer. I have not done anything with objects, and have not fully learned references. But I stopped focusing on learning perl 5, because I saw that legibility was going downhill quickly, the more I added in the new stuff I was learning. It was heartbreaking for me, because much of perl's beauty is in the CPAN modules which people have contributed. The features go on forever. The essay I linked to from my name, shows my conclusions at the point where I left off with using perl. I have hope for perl 6, but it still hasn't come out, and I've now become very enthusiastic about tcl/tk.
With perl, I did refactor... and sometimes it made it even harder to read. Breaking up the flow to simplify the legibility is really a bad mistake, I've discovered.
Coding standards? I don't believe in falling into a mold with anything I do. I'm self taught, and so I wouldn't have learned those... but being a very avid writer, I'm a linguist of sorts and so I chafe at the bit, when I cannot get a computer language to be as beautiful as I can get english to be.
My initial goal was to become proficient with gui creation - and the perl/tk interface just seemed very very awkward. And when I compare it to tcl/tk - the fluidity is indeed much better over here, with tcl/tk.
Something about english which is very special - is that it evolves over time. People develop new words and phrasings - they change the spelling, they change the meaning of words. In this way, the language begins to fit the human mind very well. By contrast, German seems to be a language which was designed and tested by the collegiate crowd, and then given to the masses. It's quite mechanical and doesn't have quite the depth, that a more rubbery language like english does (Of course, the development of all languages around the world has slowed to a crawl, since the majority of people became skilled in reading and writing). Tcl/tk allows this kind of language development, and of course Scheme/Lisp does as well.
I've just recently been acquainting myself with SmallTalk, and a couple other object oriented languages. And that's a whole 'nother level of interesting issues to think about. It seems to me that computer languages like C, which are designed to be easy for the computer to deal with, are somehow harder for humans to deal with. Humans who use C too long, develop awkward personalities. The opposite is true with SmallTalk, it seems. Object oriented languages, which are organized around the structure of the human mind, cause the computers which try to run the code to develop flaws in their personality.
@Christopher, I worked on a large Perl/Tk project once. I completely agree that Tk is more fluid with Tcl than it is in Perl, at least with Perl's most popular Tk bindings. (I've heard that Tk::Zinc addresses a lot of the shortcomings, most of which in my experience are that the Tk module isn't very Perlish, but I haven't used it.)
I don't really understand the rest of your comment. If your refactorings made the code more difficult to read and if you don't have any coding standards to follow, the only surprise to me is that you don't have similar trouble in every programming language you try.
Perhaps you're falling into what I've heard Ward Cunningham describe as Smalltalk's biggest failing: it's easy to write beautiful code in the small that turns into a big ball of mud in the large.
I'm pretty sure that every good Perl programmer I know would say that writing a maintainable program over a hundred lines requires a certain amount of discipline, especially in abstracting away duplication and taking advantage of Perl idioms... but it's also clear that a lot of people never learn enough Perl to do so.
I still remain unconvinced that people who don't learn that much of a language will somehow magically write maintainable code in any language.
I tend to pack a lot of ideas into a small paragraph, when it looks like I have a good conversation partner, chromatic. ;-) I apologize for that. The premise behind my statement that "Breaking up the flow to simplify the legibility is really a bad mistake" is that it's like breaking up a stained glass window, or a porcelain painting, or a jigsaw puzzle. Even though each piece of code is easier to read, for what it is, the overview of the code is much harder to grasp. What I'm talking about here: is using lots of subroutines to contain processes which you aren't going to use more than once.
I still insist that visual metatools are the way forward for programming. It'd be easy, perhaps, to make an elegant timeline using macromedia flash... This would take the tangle out of flow charts. The key is to be able to get an overview of your work, by glancing at the page. Then you can think clearly about it, as you work on it, and as you maintain it.
foreach (@zeilen) {
s/\w<([^>]+)>/\U$1/g;
print "$_";
You find perl code good? Maintainable?
I was coding quite some perl years ago. Then i switched to ruby.
Although ruby is only a 99% perfect language, and I actually
avoid more complex subsets of the language if possible, trying to
remain as simple as possible and as elegant as possible, I must
tell you - perl is _UGLY_ ;)
You can shout that its not ugly all you want. Compared to ruby, it
feels like 20 years difference in syntax alone, yet alone
thinking WITH clean objects.
@she,
You can shout that Perl's ugly all you want, but the ugliness in the code you provided is regular expressions, and not Perl in particular.
Besides that, beauty and aesthetics are personal choices. We were talking about maintainability, which has at least some degree of measure.
I find well-written code maintainable. I find poorly written code less maintainable. I find that no language prevents the writing of poor code.
@she: can you write your code example in Ruby to demonstrate how much easier it is to read?
It surprises me that many people complain about the ugliness of Perl and always refer in their examples to regexps instead of things like Obfuscation, JAPHs, Golf, Poetry, Acme::* or any other of the fun things you can do with Perl. Far from ugly, these things are quite interesting and challenging for the sharp and curious mind. Nevertheless, are you going to find an obfucated code in a CPAN module? Probably not. Are you going to find well written, tested code in CPAN? Probably Yes (most of the time anyway).
Back to regexps, if they are so ugly then why does every language imitate Perl in their implementations, many of the shamelessly stating Perl-like regexp support and things of the sort.
Regarding the ease of use and maintainability, many a PHP programmer would probably agree that PHP is easy to learn and easy to maintain. If they knew that PHP came directly from Perl[1] they would probably throw a hissy fit and tell you off otherwise. Why has PHP has become so popular if it is very similar to Perl? I have always wondered to this day why Rasmus Lerdorf would create his own language basing much of the syntax directly from Perl, instead of contributing to CGI, MASON, TT, CGI::Application and many of the excellent tools that the Perl community has given birth to (not to mention Catalyst which is a relatively new addition). Was he mad at Larry? ...who knows...
The truth is that much of the PHP code out there is really, really, really bad. Not because the language itself is bad, but because only recently do you start seeing decent design patterns like MVC being deployed in PHP. Some frameworks such as Symfony have really given good thought to atomizing and structuring code in a way that can even allow for several programmers to work on one controller at the same time, in different files. Using Symfony, it is hard to produce bad and unmaintainable code. Is it the PHP language that makes Symfony great mommy? NO, it's the design pattern, stupid.
Can you code like this in Perl? You bet! Can you do it in C? Yeap. Can you implement objects in C? Yeap. Does a C lib with structs and code have to end in ".class" to say that it's Object Oriented? NO, it doesn't.
Folks, it's the programmer, not the language, that makes good code. And finally, is Perl the greatest language there is? Of course it is, why would anybody challenge that. (C, of course being the king of the hill. Why, you ask? well because XS rules! ;-) - there, take that recursive function!)
Cheers,
Alejandro Imass
[1] Many PHP programmers I have met have never read the history of their favorite language: http://www.php.net/history
@she,
If you weren't a beginner, you might written this instead:
s,\w<(.+?)>,\U$1,g + print for @zeilen;
And the only "ugly" part here is the regex in the first half. Regexes are a mini-language in its own. It's included in perl and many other languages and their "uglyness" can't be blamed on perl. Besides, writing the same thing without using regexes can take ten times as much code if not more. Regexes are compact, powerful and very useful.
Although you can write bad code in any language, Perl obviously encourages that. For lots of other more modern languages, one can easily understand the code, with much less English comments.
@Guo Pei, it's indeed not obvious to me. Can you provide examples of code which is confusing to non-novice Perl programmers?
Well it has been a long time since I participated in the "language wars" of the 70's and 80's, but it seems as though we are all there again.
Everyone tries to make these discussions "non-personal" by spouting some data points to make their position incredibly obvious and rational. I'll do that too and right away to get it out of the way.
I love perl.
I find it incredibly flexible and capable. I have been programming for more than 35 years. I have written C since approximately 1980. Up until about 1998, it was my language of choice for any programming project, significant in size or otherwise.
Then I met perl with the Tk option. With my previous employer, we used this combination to write significant size applications that worked across the platform spectrum of HP and Sun unix as well as the windows world, all without recompiling, porting or otherwise caring.. These applications were used across a 12 location enterprise which spanned from the Far East to the United States to Europe.
In my current environment I have continued the use of perl with Tk as a suitable platform for doing similar types of programs.
So what bugs me?
As I said, I'll get my personal biases out of the way quickly. I enjoy using perl but am offended by people who think that it is tool that is not worth their bother because it is a "scripting" language (whatever that really is...) compared to (you pick YOUR favorite language and insert it here). People take surveys and list C, Java, Python, Visual Basic and a box for "Other".
I mentioned the I was a hard core C programmer before meeting perl in a big way. Having the language take care of garbage collection and having hashes as a built in part of the language totally changed the way that I could look at problems. Having a workable GUI scheme based on Tk make it possible to write complete applications that people could use very easily.
So what's all the fuss? Each language that has been invented since the dawn of computing has been created to either solve a particular application problem or to address various technical issues (such as speed, complilation capabilities, coding efficiency or code density). There is nothing fundamentally wrong with this. This is our life as technology driven people.
What we do do wrong is totally bash any previous "solution" as uncool or unworkable because 1) we don't understand some aspect of it; 2) we didn't think of it; 3) it doesn't have some feature without which we believe it to be uncool or unworkable (even if we have no use for this feature most or all of the time).
The biggest "feature" (if I can call it that...) that falls into this last category is OO. You can discuss object oriented programming till we are all blue in the face. You can talk about how this program or that program does it and at what level various -isms are supported. However, at the end of the day, unless you are a pure acedemic (no shots intended here...), the reason that this approach was "invented" and developed was to increase the functionality, maintainability and faithfullness of intent to the programming process.
I am not against object oriented programming!!
The reason this issue has caused so much angst over the years is that there are many things that influence these attributes. We have all had to contend with programs which are (speaking kindly here) rather raw uncooked spagetti. And I am not talking about the use of the GOTO command here. We can create all the wonderful languages that we want, but there is still a certain art to programming as it does require a disciplined thought process. Unfortunately, not all people who practice programming exhibit this ability.
The perl community has the expression "There is more than one way to do it". People who like to pick usually bring up that it makes for confusion. They bring up the obfuscated code contests (okay, some of them aren't contests, they are simple examples of people who have not thought through the problem they are trying to solve). And they bring of the regular expression syntax.
If you want the ultimate in non-obvious programming language to the casual observer, go back and look at APL.
So where are we? At the end of the day, we all have to use tools that meet the requirements of the task at hand. And I believe that there will always be several choices that may work for a given task. There will always be constraints that force us to pick something we are not as comfortable with. That is life.
For the casual programmer, any language has it hurdles. It doesn't matter if you are taking BASIC, FORTRAN, perl or Java. If you don't want to learn at least some of these hurdles, then get someone else to write the program for you.
For the more experienced practitioner, do a better job of documenting what you write and keep the flow of your programs more logical so that others can understand them in whatever language that you write in. People actually read these things and learn from them. What you write, others will copy.
You SHOULD look at the capabilities and the total support environment that would enable you to accomplish your task. On the perl end of the world, you may think the language is dying, but the CPAN library and it's continued growth would argue otherwise. There are somewhat equivalent schemes out there for some of the other languages, but the size of this archive of solutions is not to be dismissed.
And in the end ... be helpful and nice!!
I would say that for a beginning-intermediate programmer, the dereference system is very confusing.
I came to perl from a C background where the operator precedence and associativity is very well defined and explicitly stated. I didn't find any such table for perl. To be more specific, I found no reference to the fact that the sigils on the left hand side bind more tightly than the structures on the right hand side and to override this, you need to use brackets. It may be that I haven't looked very closely or diligently, but it was a major source of pain till I understood it. I wouldn't call it the language's fault. But it should have been pointed out more prominently in the existing literature as this is exactly opposite to the convention in C. I realize that I faced this problem because I came from a C background and maybe others wouldn't really face this problem.
I've used the argument before that the concepts behind "Information Theory" can be applied in many fields. Essentially it says that any information can be successfully sent in a noisy environment by either increasing signal amplitude/redundancy or by decreasing noise.
I like Perl, but Perl does seem like a noisy environment. CPAN and TIMTOWTDI are two great examples of redundancy but to some people it may be noise because humans can't always prune the possible choices available down to something manageable. Sometimes "it's all too much".
Plus, since the language isn't immediately mappable to human language concepts then a new learner has to correctly discern what to ignore and what MUST be anchored in the mind.
Until the Perl concepts are correctly selected and mapped to human language concepts, learning can't begin. As a counter-example, Rubyists love to point to the "Principle of Least Surprise" (PoLS) as being one of Ruby's selling points. And it usually works.
Quick example: It is REALLY important that any programmer get that $, @, and % all are really important to learn right away. But what if a new person gets into Perl, hears about CPAN, and dives in without realizing how important it is to grok $, @, and %?
Back in '92 when I first saw Perl, it took me a couple of weeks to realize that I *really* needed to grok those three prefixes. And I didn't have CPAN in the way!
It is almost as if Perl's success has created so much content that *never* goes away, that the language has become too heavy for new users.
Just my $/50.
@Nimish, I completely agree. Dereferencing in Perl 5 is one of my least favorite parts of the language.