Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Worst thing you ever made with Perl

by Juerd (Abbot)
on Sep 28, 2003 at 16:03 UTC ( #294758=perlmeditation: print w/replies, xml ) Need Help??

What was the worst Perl code you ever wrote? You know, that code that was one of your first Perl projects and you just had to put online somewhere. You hadn't learned about strict back then and did not know why symbolic references are evil. Or even that they are called symbolic references.

It is using lots of globals, maybe even shared throughout multiple modules. Because you didn't realise the importance of style, not everything is indented correctly and the style is inconsistent at best. No external database is used, everything is serialized and stored as strings. If there was a database at all, then it used a table per record because you didn't bother to learn about databases.

If there was any documentation at all, it would not be enough for future maintenance. But there probably was no documentation at all. Comments were absent, just like error checking and sanity checks. The Perl 5 code could probably be run in Perl 4 without too many modifications.

Many Perl Monks have made bad stuff like what I described above. Of course, this is a somewhat dramatic view, but I'd like to ask you to be honest.

What code did you create years ago that you are ashamed of now? Why is it that bad, what would you do differently now?

Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }

P.S. I will of course post my own Worst Perl Project too, but before that I need to deal with the worst security issues :)

Replies are listed 'Best First'.
Re: Worst thing you ever made with Perl
by jdtoronto (Prior) on Sep 28, 2003 at 16:39 UTC
    Well, back in the Perl 4 days, my then partner, now wife, was doing things with a heathen beast called Access. She had a whole lot of records for the same person, each one with different fields in it. So, in th eprocess of writing seomthing that would look at each record and make a single record with the data taken from all of the records. Basically to get a single record as complete as possible.

    I cannot even recall if Perl 4 had the use strict prgama. If it did, I sure as hell hadn't figured out how to use it! It took days and days, I think I discovered every possible way of slicing anything rather than getting at an element. I hadn't figured out how to talk to the database, so we exported a CSV format file which was in sorted order, then we ran the script. It actually worked, which amazed me more than a little.

    Over the next few years I spent a lot of time studying Perl. My local bookstore was a problem, they didn't carry O'Reilly! So I tried all sorts of strange books until eventually I found a store that did and then I was off. I have given away some of the O'Reilly books, but right up to today I can proudly say that I have purchased every O'Reilly Perl related book as it came out. They haven't always been the best possible thing, but they have all been useful in one way or another!

    Now I have discovered the monastery. What a revelation! By reading here, asking questions and working hard I think my programming style has improved beyond measure. Now I can look back on code only a year or two old ans say "well, thats pretty bad!".

    In the old days I was scared of strict, scared of modules, didn't understand references and OO was more of an OOps thing.

    Now, I always use trict, always enable warnings, use modules wherever I can. OO is now becoming a happy paradigm, references roll of my tongue easily and I feel my own code quality improves day by day. Thats why I love Perl!


Re: Worst thing you ever made with Perl
by barrd (Canon) on Sep 28, 2003 at 16:39 UTC
    Hi Juerd,
    That's kinda freaky as just today I looked at some code I wrote 10 years ago. It was my first public facing script capturing input from a HTML form page. I couldn't stop laughing, it was 500+ lines long, today I could condense it to 40 lines (or less with a bit of golf).

    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$/
        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.


Re: Worst thing you ever made with Perl
by atcroft (Abbot) on Sep 28, 2003 at 17:00 UTC

    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

    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.

Re: Worst thing you ever made with Perl
by deliria (Chaplain) on Sep 28, 2003 at 18:32 UTC

    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.

Re: Worst thing you ever made with Perl
by Abigail-II (Bishop) on Sep 28, 2003 at 16:33 UTC
    You hadn't learned about strict back then and did not know why symbolic references are evil. Or even that they are called symbolic references.

    It is using lots of globals, maybe even shared throughout multiple modules. Because you didn't realise the importance of style, not everything is indented correctly and the style is inconsistent at best. No external database is used, everything is serialized and stored as strings. If there was a database at all, then it used a table per record because you didn't bother to learn about databases.

    Sorry to disappoint you, but I never did program that way. Not in Perl, nor in any other language. When I was taught programming, more than 10 years before I learned Perl, the importance of lexical variables, style, indentation, etc, was stressed from day 1. I had programmed in Perl for quite a while before I even considered using symbolic references. Or local for that matter. That's why I'm always baffled if newbies happily use, or want to use, symbolic references. Most mainstream languages don't use them, so where do they get it from? It's buried deep enough in the documentation. Are there beginners courses that promote their use? I certainly never discussed symbolic references or 'local' in beginners courses that I taught.


      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.. :)*


      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.


      Are there beginners courses that promote their use?


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

      Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }

Re: Worst thing you ever made with Perl
by delirium (Chaplain) on Sep 28, 2003 at 22:45 UTC
    The worst thing I ever coded in Perl was also done for the worst reason: avoiding doing my job. I worked in a call center that had a web page showing how long each CSR had been in their current state (on a call, in idle, available to take a new call). It was organized alphabetically by CSR name, and refreshed every 10 seconds using an ASP link to an Aspect database.

    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.

Re: Worst thing you ever made with Perl
by jeffa (Bishop) on Sep 28, 2003 at 23:06 UTC
    Took a while to dig up ... i think i wrote this in early 1997:
    #!/usr/local/bin/perl ################################################# # # 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/'); #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


    (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>


      (the triplet paradiddle with high-hat)
Re: Worst thing you ever made with Perl
by jonadab (Parson) on Sep 28, 2003 at 18:13 UTC

    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$/
Re: Worst thing you ever made with Perl
by LazerRed (Pilgrim) on Sep 28, 2003 at 21:14 UTC
    Well, considering that I'm currently living the "Back Then" period, I've got some doosies fresh in hand :-) I've not had any formal edumacation(heh) in programming techniques. I'm all self taught(With many books), My first start was with GW on an old 286. I lost interest for the most part, eventually joined the military, became a *nix admin, left the military, began to write scripts to make my job easier. I got frustrated with the limitations of the various shell scripts, and began my search for a language. I really don't know the "exact" reason I chose Perl... Maybe it was that I've been told it was difficult, and I like a challange. I've been playing with Perl now for about 4 months, nothing I've done to this point really keeps me up at night. I found the monastery early in my studies (I think I got the link from the llama book? I don't remember for sure) and the kind monks here have kept me from forming too many bad habbits. My thanks to the monks who took the time to answer my "uneducated" questions :-) Even though it's not Perl, there are some bourne shell scripts that I still think about and shudder (Think lots of rsh calls and .rhosts, and the fact that I'm sure that they are still in use).


    Whip me, Beat me, Make me use Y-ModemG.
Re: Worst thing you ever made with Perl
by Juerd (Abbot) on Sep 29, 2003 at 06:52 UTC

    My First Worst would be Wappy. It's not my first Perl code, but it was the first Perl code I used on a website that got a reasonable amount of visitors.

    At, people can make their own WAP sites. For those who don't know: WAP stands for Wireless Application Protocol and many find writing valid XML hard. Anyway, Wappy was made to be the first free WAP redirection service and the second free easy WAP site builder. The second, because the first was also made by me. That one did not even have user accounts. Pages would be saved once and then be read-only.

    So Wappy needed to have a database. I thought SQL was hard back then and didn't know of abstraction. This resulted in a GDBM_File that holds all user data, serialized by hand, not dealing with bad user input. This file is 38M now.

    I think you can guess how to break that :)

    But things are worse than just this. The sub above is in a .pm file, but it has no package of its own. Actually, we had some issues with global variables and didn't know about local and my. So there are variables like $foo_12523, just to make sure we got a fresh variable :)

    Of course (?), we didn't use We benchmarked it and it made everything even slower than it already was. So I came up with something we have all seen before:

    The worst thing about this is not that we hand-parsed things, I'm still reasonably comfortable with that. Not even that we used split in void context. No, the worst thing is that it uses the magic ARGV. Which with a query string of /dev/urandom means there is a problem. Did I mention that I set $/ to undef before we did anything else?

    The mail sending thing could be used as a spam gateway. And it was used for that. I don't want to talk about this ;)

    On non-Perl side, this site still has some things that the users don't like. There is no way to have your user account deleted. Or to retrieve your lost password. The site still uses another website to do image conversion. It could just have used Imager or Image::Magick, of course.

    Wappy gets no attention. It should be re-written from scratch. We changed the design recently to test a new worker's design capabilities, but apart from that not much has happened in the past few years. User mail is usually moved to /dev/null, since 99% of all mail we get on that address is spam.

    Wappy has 54464 registered users, of which 1500 signed up in the last 30 days. The number of visitors is still growing. The site now has 2100 visits per day, according to webalizer. Wappy has been featured in printed magazines several times, last time was three months ago. The site got its last technical change in March 2000. (Okay, I'm not counting the security fixes I did before writing this)

    All those people don't realize how awful the code behind Wappy really is. People should stop using it (and stop writing about it in magazines) so we can let it die peacefully.

    If I had to re-code this today, I'd use PLP, Class::DBI, MIME::Lite and of course strict.

    Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }

      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 => '', plp_site => '', do_not_use => 'spamtrap' }

Re: Worst thing you ever made with Perl
by Roger (Parson) on Sep 29, 2003 at 01:20 UTC
    Ummm, interesting topic... Everyone has unique programming experience. I will include mine here as well.

    When I first started using Perl, I already had years of experience with Basic, Pascal, C and Assembly.

    I taught myself programming trough trial and error, and sheer quriosity. So before I went to Uni in 91, I have already experienced a lot of good and bad programming, so I know the benifit of having a clean coding style. The skills I aquired through hacking got formalized at Uni, where I learnt that most of the solutions I came up with during hacking were already invented by greats even earlier. I sat down and began reading books on programming.

    I was introduced to the great language of LISP (for the "real" programmers :-D ) at 1st year Uni, where I quickly aquired the skills of toying with algorithms, such as solving symbolic equations progmatically with recursion and parsing.

    I picked up Perl as a small part of my first job after graduation, where I mainly used C on the Solaris system. I was reluctant at first with Perl for its speed, but then gradually replaced all my shell/awk/hack with Perl for its simplicity and elegance.

    I can think of a lot of "bad" programs I wrote in Perl in early days, here is one of them -

    # Mundane C style "for" loop for ($i = 0; $i < 100; $i++) { print "$i\n"; }
    Then I found out I can do this -
    # Perl style "for" loop print "$_\n" for 0..99; # or this map { print "$_\n" } 0..99;
    Recently, doing a Schwartzian Transform on a huge hash table that thrashed the machine.

    And my worst ever experience in Computer Science -

    When I entered Uni, I wasn't a big fan on algorithm, I "thought" I knew how to program. Once during a class back in Uni, the professor was just about to start on the Heap Sort algorithm, having finished on sequencial sort. I quietly made a comment that if I wanted to make sorting go faster, all I have to do was to rewrite the sequencial sort in assembly.

    Somehow my professor heard what I said, and that was it. He was so furious with me, and spent the next half an hour "educating" me, explaining to me that having a good algorithm is far more efficient than coding a bad algorithm in assembly. He was drawing comparison graphs on the board between C version of sequencial sort, assembly version of sequencial sort, heap sort and quick sort... I learnt my lesson.

    The conclusion: what makes a good program tick is not about what programming language it is written in, not about the coding style, not about how much comment in the code (even though it is very important), it's all about the algorithm. A good algorithm alone does not make a good program, but a good program can not be without a good algorithm. A great algorithm combined with clean coding makes a great program. Always look for ways to enhance algorithm and make it run better and faster.

Re: Worst thing you ever made with Perl
by naChoZ (Curate) on Sep 29, 2003 at 01:29 UTC

    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™!"

    "I just read perlman:perlboot," said Tom, objectively.

Re: Worst thing you ever made with Perl
by gregor42 (Parson) on Sep 29, 2003 at 16:31 UTC

    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!

Re: Worst thing you ever made with Perl
by thelenm (Vicar) on Sep 29, 2003 at 16:41 UTC

    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:

                    ($u,$p,$f,$l,$n,$e,$a,$y,$s,$r,$v,$td,$i,$m,$t,$lo,$c,$k,$pt,$lg) = split(/\n/,$_);

    ... 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

Re: Worst thing you ever made with Perl
by antirice (Priest) on Sep 30, 2003 at 01:37 UTC

    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 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 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. least that's how I made my way out of the darkness and into the light.

    The first rule of Perl club is - use Perl
    ith rule of Perl club is - follow rule i - 1 for i > 1

Re: Worst thing you ever made with Perl
by idsfa (Vicar) on Sep 29, 2003 at 05:41 UTC

    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.

    Remember, when you stare long into the abyss, you could have been home eating ice cream.
Re: Worst thing you ever made with Perl
by hardburn (Abbot) on Sep 29, 2003 at 13:56 UTC

    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, and I wanted to make a CGI for various clans to rank players in compititions. I put my not-even-working code on a homepage. 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.

    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

Re: Worst thing you ever made with Perl
by IOrdy (Friar) on Sep 30, 2003 at 01:22 UTC
    Using regular expressions for XML Parsing and Templating all in the one script because I still didn't know of the CPAN. Apart from some 'hello world' scripts this was the first script I wrote (2001).

    Good or Bad the script is still used today on my little brothers website

    The code:
Re: Worst thing you ever made with Perl
by Jenda (Abbot) on Oct 02, 2003 at 11:47 UTC


    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 ...

    Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
       -- Rick Osborne

    Edit by castaway: Closed small tag in signature

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://294758]
Approved by broquaint
Front-paged by bart
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2022-09-30 09:14 GMT
Find Nodes?
    Voting Booth?
    I prefer my indexes to start at:

    Results (125 votes). Check out past polls.