I think Perl is a little like chess...it's easy to learn the basics, but it takes time to become a master.

Since most people are satisfied with "good enough," it's not surprising there are a lot of poor Perl programmers. However, I think there are a lot of poor programmers in every language.

It's more obvious with Perl, because Perl makes the simple stuff easy and the hard stuff doable...it also makes it very easy to bark up the wrong tree.

If you're not comfortable with that, take a look at what people outside the Perl/[Li|U]nix/O'Reilly community have to work with. Do some simple searches and look at the quality of the examples you'll find. Granted, there are notable exceptions, but those are few and far between. Sturgeon's Law applies to Perl information sites as well.

It's not a problem with Perl; it's with ourselves. If we are dissatisfied with certain assessments of our community, dislike certain Perl script archives, or decry the lack of attention given to the most basic security measures, good programming practises, and so on, then would it not be wise to do better? To create and post that which we would rather see? To truly lead by example?

I don't think we'll help all the poor programmers, but we can help the ones that want to be better, the ones that can become better--but only if we become part of the solution.

To be fair, I'm fully aware that some are trying to solve the problem:

• davorg's efforts to rewrite MW's cr@p,
• your efforts to present a good CGI tutorial,
• KM's (and BM's) efforts to write a good example book,
• Dominus's untiring efforts,
• tilly's continued efforts,
• and so on.

I applaud these and encourage them. I think the Monastery and the Perl Community at large would benefit if we'd focus less on what's wrong with whatever and focus more on making sure that we're all doing what's right.

--f

Well what I noticed is that most people think perl is a scripting language and not a *real* programming language...

Sadly but true most perl programmers I met only script in perl...



--
My opinions may have changed,
but not the fact that I am right

Once you know Perl, why should you want to script in other languages. The number of times I've started to write a Bash script or a DOS bat file, only to finish it in Perl...

Portability, flexibility, power and expressability count in scripts as well!

I see two major problems with Perl

The ease with which you can get a Perl script to run is both a blessing and a curse. Because you can get some code running easily and, once you discover CGI.pm etc, actually generate useful applications it is easy for people to convince themselves they are programmers and then go on to try to make all 101 of the 101 all time worst programing snafus. Unfortunately the explosion of the web has seen what I have heard described as "English majors who have been promoted to positions as database engineers". Their chosen weapon has typically been Perl.

The second problem is TIMTOWDI. Most languages have 1 major loop construct. Perl has dozens of ways to write a simple loop, depending on how you count:

for ($i=0; $i<=10; $i++) # old faithful!
for (0..10)
for (@array)
for (0..$#array)
print $_ for 0..10
print $_ for @array
print $array[$_] for 0..$#array
print $i++ while $i<10

Not to mention
foreach (same as for but...)
foreach my $element (@array)
map {print} 0..10

Throw in a few infinite loop constructs
for (;;)
1 while 
while (1)
[download]

sub getArrayIndex {
    map{return --$_ if $_[0] eq $_[$_]}(1..@_-1) and -1
}
[download]

I did note that generating this code in a production environment was unlikely to amuse the boss. The ability to get the job done in a really terse manner as demonstrated above is amusing to a Perl hacker but probably gives the sh*ts to people who are less familiar with Perl. Especially if they have to maintain this sort of code.

I love Perl anyway. It is a great language and Perl geeks are good geeks. What more could you want? You can't please all of the people all of the time.

cheers

tachyon

I've seen one programmer avoiding arrays because he thought they were broken (He had bad input, and didn't know how to debug CGI code from the command line - he'd only run it from the browser). And he didn't use hashes because he didn't know what they were. Update: and he didn't use placeholders in DBI...now there was a weird issue where directly pasting the value in the SQL worked ok, but using placeholders it did not because of a newline in the data. Again, it was another place where debugging in the browser was insufficient (Gee, I printed the variable, and it looks ok...).

Bad programming is possible in any language (see How to Write Unmaintainable Code), but perl lets you be really bad if you want to be or don't know any better.

Well, many people who program in perl don't come from a strong programming background; mabey they know html and dabble in JavaScript, and their boss wants them to do a quick script in perl, so they learn as much as they need to and get started, not fully understanding what they need. I think that perl has so many people from that type of background becuase of it's easiness to learn, which I think is a good thing. Now, perl does have many people from a strong cs background, coming from languages such as C/C++,Pascal,etc. I don't think we're as bad as some people say, probably in the middle somewhere. But, anyone who would dismiss a whole language merely because he has run across a few people who don't program in it very well is not very fair.

The 15 year old, freshman programmer,
Stephen Rawls

tachyon's comments are right on the mark as far as what I've seen and heard, especially TIMTOWTDI.

An item left out is that Perl is the choice of sysadmins, as such, they learn code without peer-review (Their peers only know that the code works and makes their life easier). Only those who aspire to more than just system administration scripts discover the importance of good coding practices.

A new trend that is putting a bad light on Perl is what I'm labeling the NTification of Unix. More and more applications are being developed on NT and ported to Unix. The dependency on NT GUI developement by the so-called educated programmers is separating the fundamental knowlege of the power of TCPIP and Unix from these 'skilled' coders. Therefor in the eyes of those that do review code 'Perl sucks'. Around our organization anyone that develops at a command line is said to enjoy coding in 'the dark places'.

In metaphoric over simplification; A person that learns an instrument from a teacher and studies music theory can develop the ability to write music that will find a degree of approval from other educated musicians. But the kid that learns how to play a single instrument by banging on it till it sounds the way want it to, will never be accepted by that same crowd as a real musician. Ironically these unreal musicians have the opportunity to make more $$$ than classically trained musicians because of the unique intimacy they have with their instrument and their music.

I think, or at least that's the way it was for me, Perl has a bad reputation is because a) if someone who you know is good at confusers says so, then you're likely to believe him without checking it out yourself, and b) because of its use of operators and special characters like regexps where other languages use word-like terms. And what at first put me off as being very complex and mind-boggling I have now come to like as being simple and elegant.

What's more, the guy you met there says he's sick of maintaining badly written code. Well, doesn't that (apart from just badly written code) also imply that most of the code we encounter, be it Perl, be it any other language, is just not commented enough? I myself sometimes find that even though I try to comment my programmes concisely but clearly, after some time I still have to think hard at what exactly the code does. Even more so when it's someone else's code.

So, sometimes it's complicated looking code, maybe together with having been created by someone who didn't think of the most elegant ways to code, which creates and cements a reputation which is entirely unfair to the language. However, as srawls points out, someone who dismisses a whole language because of badly written code is not at all being fair. Any language is difficult if you haven't at least had a look at it. And the fact that it's often people who don't know anything or not much about confusers who make decisions - well, we're used to that, aren't we.

--cs

I'm exactly the sort of self-taught, problem-driven perl programmer that people are talking about here, and i'm acutely aware that I'm still dragging my knuckles in many ways. Looking back at work that i did two years ago is always excruciating - i started by adapting MW scripts and didn't untaint for a long time - and a lot of that stuff is still in use.

So i think it probably is true that there are a disproportionate number of bad perl programmers around. i look forward to leaving their ranks one day.

But I think this is a good thing. There's a reactionary quality to CS elitism which reminds me of old landscape painters mouldering in the Royal Academy and deploring the fact that people make something they call art without even knowing how to stretch a canvas. They're right - and most of what gets produced without discipline and education is bad, or at least tedious - just as most 'i can do it' programming is somewhere between dreary and dangerous.

But what they're really saying is 'who let this rabble in?'. There's a new medium opening here and it's populated almost entirely by people like me. not the boring old internet: programming has recently become an accessible way of interacting with other people, of communicating and even sometimes of producing art.

programming used to be an elite activity, arcane and hidden, practised only by indoctrinated adepts. Like medicine or welding, we would just place our trust in the programming and rely on it to deliver us to our intended outcome. The internet has broken all that: now everyone thinks they're a programmer because they know some html, and thinks less of programming as a result.

I can see how that must chafe on people who have the refined sensibilities and deep understanding to see how crude our scribbles are, but surely it's a good thing to make programming accessible to everyone? because from the crop of muddlers-through there will emerge a few inspired and inspiring individuals who would never otherwise be seen, because empowerment and self-expression are a priori good things, and because temple priesthoods ossify and decline without being vigorously shaken now and then.

One of my favourite things about perl is that it's approachable: the rabble can have a go. I suspect that's the real reason why proper programmers dislike it. You don't have to know what an algorithm is to write one in perl.

My other favourite thing is that it has all the qualities of a proper language; idiom, slang, allusion, humour. it can be spoken by tourists and infants well enough to make things happen, but in the hands of virginia woolf or flann o'brien it becomes something magical. In my opinion, without the openness to outsiders we'd get very poor literature.

and my favourite thing about perlmonks is that it drops a ladder into the rabble and invites all who will to climb out.

• the first is that Perl can be naturally obfuscated ($@#*&{}[]()!~). It leads to people not taking the time to read code.
• the second is, that Perl was, at first, simply a scripting language, and oftentimes it still is. Not everyone who uses Perl is a developer, and even they are not always developing when using it. Thus the code tends to be less rigorously maintained.
• the third is (as was rightly mentioned) diversity (or TMTOWTDI). Perl as a language, and the community it has grown around it encourage this, leading Perl code to be as diverse as any language I have seen.

All of these have been described as bringing about the misconception, and yet, each of them also gives Perl its power. All we can do is try our best to write readably, and, if we are lucky, convey that habit to others.

Oh, and I hope your leg feels better :) !

--- New Test Leper

using "select * from ..." in embedded SQL statements, etc.

What is wrong with that? If I am writing a general-purpose SQL statement which will display the contents of any table that is exactly the construct I should use.

Naturally, I come up with an example and someone finds the loophole :)

Though exceptions to every rule exist (as you've demonstrated), using "select * from ..." is terrible programming practice. Here are a few ways that can botch things:

• Column gets deleted.
• Column gets added (possibly throwing off the order or columns).
• Columns get reordered.

Virtually any of the above situations have a strong potential to corrupt data in your program. If the "access_level" column gets deleted and moved into a new table, your script won't know that. It won't die on the select and the data may propagate quite a a while through the system before the corruption is detected. Of course, proper validation might stop that, but then, selecting the proper column names will help, too.

The other problem with "select * from..." is that it is usually inefficient. If you only need one or two fields, selecting them directly as opposed to all 30 in a table is going to slow things down.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.