To continue the laugh, back then due to the fact I didn't go to college or Uni (fully self taught) I had no concept of Db's, flatfile or relational and for the big giggle I'd sussed array's but had no idea what the hell a hash was (in those days known as an associative array).

It was truly awful, no security, no error checking and certainly no sanity checking. I hadn't heard of CPAN yet either (not to mention POD, so yup, comments like "# This sub does stuff" were in there too).

So ++ to you for bringing this up, I have learnt much since, from work colleagues and from the monastery. I'm still chuckling now with some of the syntax that I remember from "back in the day" that 'seemed' logical at the time but "oh dear" was just "wrong, wrong, wrong".

That's made my day that has, thank you.

Speaking of POD... up until now, I've been just using comments, as I would in any other language. Is there a very simple tutorial I could pick up someplace that would show me how to write my comments as POD, in a fashion that would be mostly transparent during coding but potentially useful later on? POD has been on my to-learn list for a few months now... maybe it's time to pick it up...

---

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

Hiya jonadab,
Here's a quick online POD page link (which I printed off and stuck to my wall as a reference tool).

As for POD coding style, that's something you'll have to develop yourself.

HTH

POD has been on my to-learn list for a few months now... maybe it's time to pick it up...

See POD in 5 minutes...

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Forgive me mine, for it scares me some nights to think it may survive still.

The one that scares me the most thinking about it was a script I wrote about 4-5 years ago (well before I knew of the Monastery). At the time, a gentleman who did web design asked if I could write a replacement for CGI he used to send submitted web form input to a site's owner via email. (The CGI he had previously used was a compiled binary, and would not work on the new platform he was moving to.) The list of scary features (that I can recall) included:

• No warnings
• No strict
• No subroutines-everything in main
• Global variables
• No useful comments
• No consistent coding style
• No checking of user input
• Address information (to/from/subject) from hidden tags
• E-mail piped out to the copy of sendmail on the box, and
• It even retained the name it had during testing.

Probably the only saving grace for it was that it did not try to parse its own form input, instead using CGI.pm.

While I do not yet know the proper pentience for that monstrosity (or even if it still exists), I think the note it placed against my karma may take some time still to requite.

I created my first public Perl script when i wanted to build a site. With over 2000 pages it would have been a nightmare to maintain, and initially I was searching for a free host which supported ASP (shudder at the thought now) and came with a database. In 1997 those were pretty scarce and i went searching for an alternative.

I found Perl.

Back then I didn't know about Activestate, CPAN, pod, perldoc and what not. I learned Perl by examining Matt Wright's scripts, occasionally dialing in to find some how-to's and test the scripts i wrote, because the only Perl interpreter i had access to was on that server.

That's how I learned Perl and it was a mess. I wrote my own flat-file db something, no strict, no input validation, all vars were global as I couldn't figure out how to pass arguments to a perl sub. But it worked and i was happy.

In 99 I got another brief encounter with Perl when I needed to customize someone elses code. I bought 'Mastering Perl 5' to help me with that (big mistake). I learned a lot from that book, I found CPAN but didn't grok it, also learned a lot from hacking away at the existing script.

I didn't write decent perl until at least early 2002. I joined perlmonks this summer and learned so much, that every script i wrote before I joined looks bad to me.

Abigail,
I think by describing your personal experience, you have shed light on the answer. You had formal training in "proper" coding technique and style. Personally, I was self-taught BASIC. I used goto at every point I realized my design was flawed and it would require me re-working to make it right. My variable names started with $a, $b, .. $z where I would then start with $aa, $ab (if I was consistent at all). I would write a map of what the variables were on a sheet of paper and promptly throw it away as soon as the program was running.

Sure the docs are there. Sure there are plenty of forums that will direct you on the right path to go. The vast majority of people are not interested in why or how. They want instant gratification. "I don't care if it isn't the right way to do it - it works".

Some people never drop this mentality. They stay perpetual newbies. Some people change. I hope that I am one of those people - though I still have never had any formal training in proper "programming".

Cheers - L~R

I have to agree with Abigail-II - I started out teaching myself, from example BASIC programs on the Acorn Electron (out of user magazines), but I don't think I coded too badly in spite of that.. Later I learned formally and didnt need to change much of my style that I remember. I should find some of my early BASIC to try and prove/disprove that :)

Anyway, only started Perl mid-2002, and had been programming a while before that (must be 15 yrs now), so my original perl wasn't that bad in terms of indenting, modularizing etc. (And I still don't use strict, but I don't consider that a bad thing :)

*wonders where those early BASIC tapes might be.. good job the ole Electorn still works.. :)*

C.

I am glad you are strict enough with yourself to follow your formal training. However for the many people out there I imagine it is hard to stick with The Right Way(tm) to do it when faced with time-line pressures or simply laziness. While the benefits of doing it The Right Way(tm) far out weigh the initial time invested that doesn't make it any easier to stick to it. Adopting a mind set of
"How will this effect me X days from now?"
"When I revisit this code in X (days|weeks|years) will I remember that I was thinking?"
"Will someone else find this to be The Right Way(tm) and if so why?"
then we can help ourselves to improve. For those of us that aren't blessed with strictness we can only hope that over time we stay commited to refining our process until our actions follow The Right Way(tm) without being forced.

However for the many people out there I imagine it is hard to stick with The Right Way(tm) to do it when faced with time-line pressures or simply laziness. While the benefits of doing it The Right Way(tm) far out weigh the initial time invested that doesn't make it any easier to stick to it.

I fail to see how deviating from "the right way" would mean you program faster. Does it really save time not to do proper indentation? (If you set ':set ai' in vi, most of the work is done for you anyway). Do you save significant time not using properly scoped variables? Saving time using symbolic references is something I find hard to believe. I'm not taking any future consideration into account, I'm talking about programming right now, with a 5 pm deadline.

Abigail

Are there beginners courses that promote their use?

Yes.

Anyway, I guess I didn't realise some people got good training :)

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

My code telnetted to the web server on port 80 using Net::IO, Net::Socket, or something like that, manually issued an HTTP get command, retrieved the response into an array, and rewrote the page to sort by who had been available to take a new call the longest (i.e., when your name was at the top of the list, you would get the next call).

Naturally I shared it with a couple buddies, and we would all wait until our name got close to the top, then put our phones in idle, and then back into available, moving us down to the bottom of the list again.

Management caught on eventually, but I had the foresight to add in useful tracking information, like each CSRs ratio of available+call time to idle time, total number of inbound and outbound calls, etc. These are stats that CSRs needed, but would normally have to take their phone out of available in order to view. I had it on a web page, and it would help out the call center by not having CSRs need to stop working to check their times, calls, etc. So I was praised instead of repremanded/fired.

Anyway, the code. Scheisse. The whole thing was wrapped in a while(1) loop with a sleep(10) at the end, and ran on Active state Perl on my Windows 98 machine. It had no way to recover from a timeout connecting to the web server, and I had to share a folder on my local drive so that people could access the re-written HTML file as //curtis's machine/web stuff/stats.html. Between my poor coding, Win 98 lockups, and my machine taking constant share hits in addition to its other duties, the thing was down almost as much as it was up.

I eventually abandoned the project and the maintainer of the page I was stealing added my stats to his page. After that I had to start doing my job again.

That was about 4 years ago. My code is much better now, and so is my job.

#!/usr/local/bin/perl

#################################################
# hanoi.pl
# translated from C++ to Perl by Jeff Anderson
# original C++ code by Brenda Parker
#################################################

#recursive function
sub Hanoi {
    local($number, $from, $to, $aux);
    ($number, $from, $to, $aux) = @_;

    if ($number == 1) {
        print "Move 1 from $from to $to<BR>";
    }
    elsif ($number != 0) {
        &Hanoi($number-1,$from,$aux,$to);
        print "Move $number from $from to $to<BR>";
        &Hanoi($number-1,$aux,$to,$from);
    }
}
        
#this library contains the function &GetFormInput which reads
#and parses the form data
require('libs/forms-lib.pl');


#read input from the form
%input = &GetFormInput();

print "Content-type: text/html\n\n";

$number = $input{'pegs'};

unless ($number =~ /^[0-1]?[0-9]$/) {
    print "Numeric, not alpha-numeric!<BR>";
    exit;
}
    

print <<"EOM";
<HTML>
<HEAD>
<TITLE>Towers Result</TITLE>
</HEAD>
<BODY>
EOM

if ($number < 1) {
    print "You are really cruel, zero pegs. Go away.<BR>";
} elsif ($number > 15) {
    print "I said 15 is the max, go tie up your own processor!<BR>";
} else    {
    print "For $number pegs:<P>";
    &Hanoi($number,'A','B','C');
}

print <<"EOM";
</BODY>
</HTML>
EOM
[download]

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

And now, the re-write:

use strict;
use warnings;
use CGI qw(header param);
use HTML::Template;

my @solution;
my $tmpl = HTML::Template->new(filehandle => \*DATA);

if (param('go')) {
   my $discs = param('discs');
   $discs = 1 if $discs < 1 or $discs > 15;
   
   hanoi($discs,'A','B','C');
   
   $tmpl->param(
      solution => \@solution,
      discs    => $discs,
   );
}

print header, $tmpl->output;

# original algorithm learned from Brenda Parker
sub hanoi {
   my ($number, $from, $to, $aux) = @_;

   if ($number == 1) {
      push @solution, {step => "Move 1 from $from to $to"};
   }
   elsif ($number != 0) {
      hanoi($number-1,$from,$aux,$to);
      push @solution, {step => "Move $number from $from to $to"};
      hanoi($number-1,$aux,$to,$from);
   }
}

__DATA__
<html>
<head>
<title>Towers of Hanoi</title>
</head>
<body>

<form>
<p>
Enter number of discs desired (15 is MAX):
<input type="text" name="discs" size="2" />
</p>
<input type="submit" name="go" value="Solve" />
</form>

<tmpl_if solution>
<hr/>
Solving for <tmpl_var discs> discs:
<ol>
<tmpl_loop solution>
   <li><tmpl_var step></li>
</tmpl_loop>
</ol>
</tmpl_if>

</body>
</html>
[download]

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

By the time I picked up Perl, my programming style wasn't nearly as bad as you describe. It wasn't as good as now, and I tended to use globals a little too much, and I tended to think procedurally rather than in terms of context, but I had already come a long way.

This may be because my style had already been improved by using various other languages. From GW-BASIC I learned to use RENUM instead of a lot of extraneous GOTO (though some GOTO is virtually unavoidable in that language, due to lack of nested conditionals). From Pascal I learned even more structure, which revolutionised the way I wrote BASIC. Then I took college courses in assorted other languages, and I'm sure I learned from those too, though I can't point to anything specific (except the data structures and algorithm analysys class). By this time, of course, I was already a prolific commenter, and my comments were starting to have some minimal level of quality. In my spare time I picked up the Inform Designer's Manual, which revolutionised the way I think about objects. Inform was the second language (after BASIC) that I was able to think in. Later the Gnu Emacs Lisp Reference Manual again greatly expanded the way I think about programming, and elisp became the third language I think in. Perl is the fourth, and the best so far, though I have a special fondness for each of these four languages. (The other languages, which I never thought in, but only translated to, I have no special fondness for. Some of them, such as C++, I actively dislike.)

I did write some Perl code I'm not terribly proud of, e.g., the code behind the list of uses for peanut butter (one of my very first projects in Perl), but even that is not nearly as horrific as your description. If you want truly horrible code from me, I'll have to go back to my early years, when I was writing in other languages. I believe I had a word scrambler program in BASIC at one point that was going on a thousand lines and had lots and lots of GOTO statements. At the time, I was proud of it, because it was so much work to write. Now, of course, I'd write it as one line of Perl and play golf with it.

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]

If you feel that strongly about it's insecurities and it's abilities then do the web and its users a favour and take the bloody thing offline!

- wil

do the web and its users a favour and take the bloody thing offline!

Insecurities have been fixed. We took it offline once and people didn't like what we did. Besides, it Works™. It's not broken. It just lacks some common features and is coded in a very bad style.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

# Mundane C style "for" loop
for ($i = 0; $i < 100; $i++)
{
   print "$i\n";
}
[download]

# Perl style "for" loop
print "$_\n" for 0..99;

# or this
map { print "$_\n" } 0..99;
[download]

My first one was a script I wrote straight out of a perl class that was geared for people who didn't know a damn thing about perl, a category I in which I fit quite well. It was a replacement for some web based tools that we used to look up accounts and such at the isp where I worked. The original one that someone wrote was a bourne shell script. Talk about slow.

So, there I was, throwing together a script that made Matt's scripts look quite conscienscious of security. brian d foy himself jeered me on the code I was using to parse a form, which I got from someone else, no clue where he had dug it up. HTML right in my code, lots of heredocs. 80 columns? HA! I have one line in there that was 560 characters long. Truly the Anti-Golf.

My "authentication" (I hate to sully the good name of authentication by calling it that) scheme was simply displaying certain menu items for certain people. Even at the time I knew that was a joke, but I didn't know any other way, I was just in a hurry to get it up and running. It did a lot of nifty things, but man, I cringe at the site of the code. It eventually grew to over 2000 lines as I added more and more features and stuff.

One of the funniest thing I did... I didn't know how to do much as far as outputting a bunch of matched text from a large list with multiple columns and sort it and all that. So I actually used the perl script to inhale the whole list into a temporary mysql database, and then just do a simple select out of there. Man, talk about killing a rabbit with an H-Bomb...

You can tell that I did eventually learn about localizing things because you can see some my statements in some of the subs. It's pretty sad overall. I just looked at it again, good gracious, I wish no one ever saw it. When they hired Kanji back where I used to work, one of my first thoughts when I found out was "OMG... he's going to see That Script™!"

Well to be honest, I believe that everything I've written that's >6 months old sucks. In 6 months the stuff I write today will suck.

Oh I practice every "Right Way" metholodogy I know. I've been writing software professionally for 10+ years now, and as a hobbyist for >25 years. But I learn new ways to think about problems every day. And therefore better ways to do things constantly present themselves.

I might aliken writing code to how Picasso viewed painting. A Painting is never finished. Once it's finished it's dead - it ceases to be relevant. The same is far more true for code.

A long time ago I did Really Terrible Things. I didn't use strict, I parsed HTML 'by hand' with poorly conceived & inefficient regexes, I used arrays when hashes would do more nicely, I never used modules, I hard-coded String values directly, any many many more grievous sins. Why? Because to program & to learn are parallel pursuits. The more I learn, the better my code is.

That's the main draw perlmonks has for me. I learn by example things that I don't have time to explore personally. Sometimes this backfires, but mostly it helps.

If I look at old code I've written I usually think "what the hell was I thinking" and then I think "this would be better if I did this..." and then I remember why it got done that way in the first place and my stomach usually turns.

I'd love to say that I also always have time to do things the Right Way. But with programming salaries shrinking, industry competition growing, overseas outsourcing increasing, my managers don't always see the merit in delivering bulletproof code when simply paintball proof code will suffice in their minds.

YES, it takes longer to do things properly. If you don't realize that then you live in coder-luxury-land where deadlines are reasonable and your bosses believe in quality products instead of using endusers as beta-testers.

I've always had a habit of pursing projects in this way, especially when solving new kinds of problems:

1. Make it work
2. Make it fast
3. Make it sexy

I find it utterly mind-boggling that too many of my managers over the years don't see the benefits of going past stage 1 on the list. More often than not, they take the project away from me (usually by dumping more work on me & calling it higher priority or some other such management trick.) and then come back later with complaints, to which I must respond "If you had let me do what I reccomneded in the first place..." - which you know NO ONE ever wants to hear, since it's the analog of "I told you so"

When I've lead teams in the past I tried to be the boss I wanted to have. Maybe I pissed people off by telling them: Yes, this works great. Now go back & make it run fast. Then later, I'd say hey this works great & it's wicked fast, very nice, now go clean it up so it adheres to conventions, includes these minor feature creep items & acts better as a component in our overall system. Maybe they thought I was too demanding. But I didn't ride people, I tried to give them the room to be creative & tried very hard not to micro-manage. It's very tempting to go back & rewrite it yourself in a pinch, especially when you're the one ultimately responsible. But when you delegate properly - you learn to step back & listen more. You let people LEARN. That's what it's all about.

And that's my point. There's ALWAYS a better way to do something. If I've learned anything from the likes of Brother Merlyn and other indigeous monks of rank and reputation, then that's it.

And that's why everything I've ever written in the past sucks, and nothing is ever truly finished, until it stops being used.

- gregor42

Wait! This isn't a Parachute, this is a Backpack!

When I was first learning Perl, what I had to look at was a very early version of what later became Slash. I'm not kidding, it was horrible (but I didn't know that then). I can say without hyperbole that what I created as a newbie geek, using that as a base, turned out to be about a billion times worse.

Have you ever played a game called Assassin? Basically, there are N people playing the game, and each person has the name of someone else in the group that they are supposed to "kill". No one knows who has which name. Once you kill someone, your next assignment is to kill the person they were supposed to kill. The last person left alive is the winner. The way we played it in college, you could "kill" someone by shooting them with a water gun, with various caveats such as "you can't shoot someone while they are in class or in their room". Oh yeah, and you can also get killed by specially-appointed "Mafia" if you're taking too long to kill your own victim. This game tends to induce massive paranoia.

Anyway, I wrote a little CGI program to generate the assassination assignments, allow players to log in and register their kills, keep track of the current status of the game, allow discussion in the "morgue" among all the players who had been killed, etc. I was really proud of it, and it actually ran pretty smoothly, with a few minor problems (such as never checking for HTML in posts, which allowed the more technically inclined dead players to do all sorts of clever things in the morgue).

I hadn't looked at the code in about five years, but just last week I came across it again. I laughed out loud several times at what I had done. There were hundreds of hardcoded (and frequently duplicated) strings and numbers. Global variables galore. And just about every subroutine (at least I had subroutines!) had something like this in it:

... of which only one or two of those variables were used. But sometimes they were all used, and heaven help you if you wanted to figure out what $pt or $m is supposed to represent. A couple of guys wanted to add some more features to the code after I left, so I let them have it. They kept emailing with questions like, "Hey Mike, do you remember what $tdh does in the subroutine findMyData? It's the one between $p and $yo." I feel bad for those guys.

If I were to do it differently? I'd use variables with meaningful names and small scope. I'd eliminate duplication and magic numbers/strings. I'd use the CGI module. I'd write subroutines of fewer than 1000 lines. And I'd ask to look at some code other than CmdrTaco's. :-)

-- Mike

--
XML::Simpler does not require XML::Parser or a SAX parser. It does require File::Slurp.
-- grantm, perldoc XML::Simpler

I think the worst things I've ever done was in attempting to write my own content management about 3 years ago. I rolled my own CGI replacement by taking bits of cgi-lib.pl and changing them to suit my needs. My pages would send out a ton of cookies (at least 4, although maximum on one page was 17, I believe). Probably the worst part of it all was that I'd put sql statements in cookies (yes, I know...I'll even give you the bat with which you may beat me in the head). I relied HEAVILY on javascript to do a lot of things such as input checking. I never checked any values coming in because javascript is such a good input checking tool (ah darn, javascript disabled? oops...). There were a few places where I blindly used incoming parameters to execute external scripts. My user authentication scheme worked...sometimes. A lot of times, the system would just let anyone look at what were supposed to be heavily guarded parts of the site. I had a ton of scripts and not a single module in the entire system. I would just call do "file". Each time I reached a critical next step (i.e. the profiles are finally working, yay!) I would print the entire thing out on dead trees. I wouldn't bother keeping old versions because, well, seriously...who wants to go back to the older versions? Half of my variables in any of the scripts were $tempX. The other half would just be $X. I had a couple of variables with somewhat descriptive names, although some contained explicit language because I had problems with the fact that they weren't working correctly at some point. I had a script called util.pl which contained, among other amusing things, a quicksort subroutine, a date subroutine that would call out to the shell, a directory listing subroutine that also called out to the shell, and a subroutine that did almost what grep does. You name an embarassing coding blunder, I probably did it.

But alas, a programmer buddy from Sweden pointed out many of the errors in my ways when I showed him the source. He laughed at me. I was ashamed of my efforts -- all tha time I pissed away doing stupid crap. I buried my print outs in my backyard (along with my sister's tae bo tapes...*shudder*) and decided to learn how to do things the right way. I spent weeks looking at random nodes as well as reading merlyn's articles on his site. This is why I think so highly of him. I've grown to love CPAN and can even quote perldoc with little effort.

...at least that's how I made my way out of the darkness and into the light.

Each and every one of these perl plugins to chimera have been rightfully castigated, but OTOH I had learned perl to write them ... hardcoded paths, no comments, no use of CPAN ... sigh, I'd feel bad that my name was attached if they weren't still out there. At least I put some rudimentary docs in the release. No such thing as bad publicity, I guess.

• finger.pl
• mailto.pl
• news.pl
• post.pl
• postto.pl
• show.pl

Sure, Juerd, you might have thought you were being dramatic above, by my first Perl project did everything you listed, except for the part where it actually runs.

At the time, I was playing a lot of X-Wing vs. TIE Fighter online at zone.com, and I wanted to make a CGI for various clans to rank players in compititions. I put my not-even-working code on a Xoom.com homepage. Xoom.com eventually got merged into some other company (I forget who), and in the shuffle, my homepage got lost, and the code with it. I think I'm glad.

Mail::Sender

I've written worse code than the first public versions of the module, but nevertheless it was released too early and I made quite a few incorrect design choices. OTOH I think the docs were quite OK (except spelling errors) even in the first public version. Shame I lost that version.

Another ugly beast worth notice is Template::RTF. RTF is a crazy enough format by itself, but when you start hacking on it with regexps ...

Edit by castaway: Closed small tag in signature