• JimmyCrackedCorn (unregistered)

    The developer was the bosses' 14 year old nephew?

    This story is about someone too amateurish to even comment upon.

  • JimmyCrackedCorn (unregistered)

    Of course the bigger WTF is having a large important application written in Perl. Really. Wow.

  • Hasse (unregistered)

    A better solution : $blank1 = " "; $blank2 = " "; $blank4 = " "; $blank8 = " ";

    Now we can combine up to blank 15!

    Captcha: populus. The previous solution was too populus

  • Norman Diamond (unregistered) 
     # must be 4 blanks to fix bug
 # blank2 = "  ";
 $blank2 = "     ";
  • (cs)

    Pffft.... doesn't he know the correct way to do this is?:

    $blank1 = " "; $blank2 = "  "; $blank4 = "    "; $blank8 = "        "; $blank16 = "                "; $blank32 = "                                "; etc...

    Edit: sigh Fuck this website. Seriously.

    Edit 2: I see Hasse already had the same problem.

  • faoileag (unregistered) in reply to JimmyCrackedCorn
    JimmyCrackedCorn:
    Of course the bigger WTF is having a large important application written in Perl. Really. Wow.
    Perl was the defacto standard for web programming at the turn of the century. You don't throw away away thousands and thousands of lines of code, just because in the meantime other scripting languages have gained more followers.
  • JimmyCrackedCorn (unregistered) in reply to faoileag
    faoileag:
    JimmyCrackedCorn:
    Of course the bigger WTF is having a large important application written in Perl. Really. Wow.
    Perl was the defacto standard for web programming at the turn of the century. You don't throw away away thousands and thousands of lines of code, just because in the meantime other scripting languages have gained more followers.
    You're right. My bad. Was thinking about anything written in the last 5 years or so.
  • faoileag (unregistered) in reply to JimmyCrackedCorn
    JimmyCrackedCorn:
    The developer was the President's daughter?
    FTFY. SCNR.
    JimmyCrackedCorn:
    This story is about someone too amateurish to even comment upon.
    Not necessarily. At the end of the nineties, on the height of the dotcom bubble, companies sometimes hired programmers that where, how-to-put-it-nicely, a bit above par, on the assumption that a bad programmer is still better than no programmer at all.

    Could well be that someone discovered TDWTF just recently and wanted to share is eyes-rubbing-moment from 15 years ago with the rest of us.

  • (cs) in reply to faoileag

    Or, and I suspect this is far more likely- this code is still running in production. I maintain applications written in the late 90s. I have co-workers maintaining applications that were originally written for a Burroughs and then ported through the next several mainframe generations.

  • nimis (unregistered) in reply to JimmyCrackedCorn
    JimmyCrackedCorn:
    Of course the bigger WTF is having a large important application written in Perl. Really. Wow.
    There is absolutely nothing wrong with Perl, and you are a disgusting ignorant bigot.
  • Daniel Migowski (unregistered) in reply to eViLegion

    $blank1 = " "; $blank2 = " "; $blank4 = " ;"; $blank8 = " "; $blank16 = " "; $blank32 = " "; etc...

    Here you go...

  • Daniel Migowski (unregistered)

    Forget what I wrote..

  • faoileag (unregistered)

    Apart from the fact that the developer doesn't seem to be familiar with the wonderful regex capabilities of perl that make string literals consisting of blanks completely unnecessary, one string strikes me as odd: the my keyword is missing.

    So either the developer does not know about the advantages of use strict; (which is bad) or he/she is very old-school and at the same time doesn't know what a constant is and codes like this:

    my $blank1;
my $blank2;
...
(lots of other variable declarations)
...
$blank1 = " ";
$blank2 = "  ";

    Which is worse I don't know.

  • JimmyCrackedCorn (unregistered)

    I understand legacy applications, but I still wonder about any calculation that could determine when technical debt makes it worth it to do a re-engineering/refurbishing/rewriting project.

  • Grown up (unregistered)

    Sorry, some of us graduated from kindergarten years ago.

    Seriously, the FRIST meme was hackneyed on day one.

    Captcha: wisi :adj: "Smartah"

    I'm wisi than you.

  • faoileag (unregistered) in reply to Remy Porter
    Remy Porter:
    Or, and I suspect this is far more likely- this code is still running in production.
    Of course that's entirely possible, but then the ignorant developer a) is still around and still rather ignorant or b) the company recently hired someone (perhaps as an intern) without much programming experience and let him or her loose on the sources of a "very important, and very complex application". Both scenarios are equally scary :-)
    Remy Porter:
    I maintain applications written in the late 90s.
    So do I right now, and they are written in perl to boot :-)
  • (cs)

    Perl. I think that says it all.

  • Hannes (unregistered) in reply to Grown up
    Grown up:
    Sorry, some of us graduated from kindergarten years ago.

    And you still have your kindergarten certificate hanging at your wall, am I right?

  • JimmyCrackedCorn (unregistered) in reply to nimis
    nimis:
    JimmyCrackedCorn:
    Of course the bigger WTF is having a large important application written in Perl. Really. Wow.
    There is absolutely nothing wrong with Perl, and you are a disgusting ignorant bigot.
    I would agree that Perl can be very handy. I have developed on and off in Perl for 15 years. I have also seen some of the worst kind of code written in it, too. It always comes down to the skill of the developer. Scripted languages tend to give the novice a false sense of security...right up to the point where they wake up to the realization that their large scale complex and important application is unmanageable.

    Far from being a bigot, I see in the story signs of sending inexperienced developers off on unsupervised missions.

  • lar3ry (unregistered)

    Why not use the "x" operator, like any Perl monk?

  • Mike (unregistered) in reply to JimmyCrackedCorn

    Heh - Perl would be an improvement to ours. Critical app, written entirely in BASH script. Over 300 lines and takes around 4 hrs to run every day.

  • faoileag (unregistered) in reply to JimmyCrackedCorn
    JimmyCrackedCorn:
    I understand legacy applications, but I still wonder about any calculation that could determine when technical debt makes it worth it to do a re-engineering/refurbishing/rewriting project.
    As long as it is possible to fix even critical bugs (say, a memory leak in an embedded application written in c++) and new features are not only demanded by customers but can also be added, the pain of rewriting a large legacy app is usually far too great for most companies.

    The rewrite takes time and a lot of manpower. Think 1, 2 or more years until app 2.0 has the same functionality of app 1.0. From a business point of view that's a lot of money to invest, and you want to see some return on that investment.

    What can you gain from a rewrite in theorie? a) better maintenability, meaning a reduced headcount b) easier to implement new features, meaning increased competitiveness c) better support for newer technologies.

    For a) and b) to materialize, the quality of the resulting code must be far better than the existing one. Sadly, that is by no means guaranteed (been there, seen that, etc, blah, blah).

    Also, you need at least one developer who groks the application like no other and who is also a good architect. This key developer must be able to come up with a list of "user stories" that comprehensively describe the existing system and also be able to design the architecture for the next generation of the software. An architecture that makes it easy to implement the user stories.

    Such people are hard to come by but without them you will end up with the same spaghetti code you left, only in perhaps a different language.

    I've seen rewrites that did not really live up to the expectations on two occassions and a full rewrite being cancelled due to feature pressure by customers on one.

    So, all things considered, the cost of a rewrite for any legacy application might be too high for most companies.

    What seems to work is a modular apporach. If your application consists of several independent modules sharing data via well documented apis, then you can rewrite each module independently, and without interference with feature development / bug-fixing. If the modules are small enough, you rewrite them as part of the bug-fixing / feature development.

    But software that is that compartmentalized from the start usually doesn't need a rewrite anyway :-)

  • (cs) in reply to Grown up
    Grown up:
    Some of us graduated from kindergarten years ago.

    Your parents must be proud.

  • JimmyCrackedCorn (unregistered) in reply to faoileag
    faoileag:
    JimmyCrackedCorn:
    I understand legacy applications, but I still wonder about any calculation that could determine when technical debt makes it worth it to do a re-engineering/refurbishing/rewriting project.
    As long as it is possible to fix even critical bugs (say, a memory leak in an embedded application written in c++) and new features are not only demanded by customers but can also be added, the pain of rewriting a large legacy app is usually far too great for most companies.

    [redacted for space]

    But software that is that compartmentalized from the start usually doesn't need a rewrite anyway :-)

    Good comment. I would add that the maintenance process and discipline weigh heavily in on the need for rewrites. This is germane to my current position. The current practice is to leave old methods and functions in place, with no one responsible for cleaning up after the correction/enhancement goes into production. Other changes simply comment the old code out. Code that hasn't been used in 8 years is still part of the codebase.

  • Kevin (unregistered) in reply to nimis

    That escalated quickly.

  • (cs)

    You know, the unicorns make this better…

  • (cs)

    Y'all aren't thinking extensible enough.

    $blank = "<!-- BLANK_PLACEHOLDER -->"

    Then on the client side, fire off a bit of Javascript that will iterate over each .blank_placeholder, and for each of them fire off an async POST to a Blank Placeholder Generator webservice.

    That webserivce will do a database lookup to find out that particular client/user's blank preference, and return some XML that contains the blank string.

    xml:BlankPlaceholderConcrete<blank> </blank></xml>

    (Or it can be a space, or a or anything else you want! It's extensible.)

    The Javascript will then replace that instance of .blank_placeholder with the returned string, then loop to the next .blank_placeholder and repeat the ajax call.

    That way the processing can be crowdsourced on the client side, and the user's experience is fully customizable and extensible!

  • EvilSnack (unregistered) in reply to JimmyCrackedCorn
    JimmyCrackedCorn:
    faoileag:
    JimmyCrackedCorn:
    Of course the bigger WTF is having a large important application written in Perl. Really. Wow.
    Perl was the defacto standard for web programming at the turn of the century. You don't throw away away thousands and thousands of lines of code, just because in the meantime other scripting languages have gained more followers.
    You're right. My bad. Was thinking about anything written in the last 5 years or so.
    We still develop in COBOL. The last time I saw Java mentioned in a company document was in regard to a project to remove Java from an application. Dunno what it was replaced with.

    CAPTCHA distineo: Redneckese for "This tin A.O."

  • Pock Suppet (unregistered) in reply to JimmyCrackedCorn
    JimmyCrackedCorn:
    I understand legacy applications, but I still wonder about any calculation that could determine when technical debt makes it worth it to do a re-engineering/refurbishing/rewriting project.
    Why would you rewrite software that works? We're busy running from one emergency to another here - we don't have time to do development!

    Of course, the "emergencies" that aren't just FOTM are caused by running code that's been patched and hacked on for 2-3 decades, often by features that aren't used any more, if they were ever used in the first place. Oh, and if you do manage to get approval for a rewrite, good luck getting a feature freeze on the old code. "We can't tell a client 'no'!"

  • Bananafish (unregistered) in reply to nimis
    nimis:
    JimmyCrackedCorn:
    Of course the bigger WTF is having a large important application written in Perl. Really. Wow.
    There is absolutely nothing wrong with Perl, and you are a disgusting ignorant bigot.

    There's a lot "wrong" with Perl for some people - like me - but that still doesn't stop me from using it. I still put up small Perl utils on web sites. As much as I don't like it, it's occasionally the best tool for the job.

  • Brad Gilbert (unregistered)

    The less error prone way to write that is:

    for( 1..10 ){
  no strict 'refs';
  *{"blank$_"} = ' ' x $_;
}

    Of course that is still quite dumb.

    sub has_x_spaces{
  my ($x,$str) = @_;
  return !! $str =~ / {$x}/;
}

    Or if what you really want is the length of the longest match:

    use List::Util qw'max';
sub longest_match{
  my ($sub,$str) = @_;
  return max map{length} $str =~ /(\Q$sub\E+)/g;
}
my $longest = longest_match(' ',$string);
  • Andrew (unregistered)

    Oh I see the problem...

    $blank1 = " " x 1;
$blank2 = " " x 2;
$blank3 = " " x 3;
$blank4 = " " x 4;
$blank5 = " " x 5;
$blank6 = " " x 6;
$blank7 = " " x 7;
$blank8 = " " x 8;
$blank9 = " " x 9;
$blank10 = " " x 10;

    Fixed

  • Nigel Tufnel (unregistered)

    My space-check $blank variable list goes up to 11!

  • Abigo (unregistered)

    I think $d is the saddest of all variables.

  • Charles F. (unregistered) in reply to faoileag
    faoileag:
    Perl was the defacto standard for web programming at the turn of the century. You don't throw away away thousands and thousands of lines of code...
    Thousands and thousands of lines... of Perl?

    Every time I've seen Perl programmers look at Java code, they roll their eyes and say, "Dude! I could do that in three lines of Perl!"

    If, for example, JBoss were written in Perl, it would be -- at most -- about 25 lines of code.

  • golddog (unregistered)

    What faoileag said re: value of rewriting. One of our core applications is being rewritten. It really needed it; as I understand the story, we bought software from somebody many years ago. The organization from which we bought it was somebody who sort of hacked together a kind-of working application in classic ASP (pre-.NET).

    Anyway, it's being brought up to more modern technololgies (MVC, ajax, etc). We've had a team of between four and seven developers going at the rewrite for nearly a couple of years now. Easily spent > USD $1M. Closing in on wrapping up the rewrite currently.

    The new site is great--functional, responsive, easier to maintain, all the good things one hopes with a rewrite. I think it's going to make sales easier and draw business.

    Still, I'm not sure management realized the time and cost which would be undertaken when this project was set out upon.

    The point is, a for-profit organization cannot spend money on things which don't increase profitability, and we can't define the savings of a rewrite in terms of "fixes/changes will take x% less time afterwards."

  • Captain Oblivious (unregistered) in reply to Charles F.
    Charles F.:
    faoileag:
    Perl was the defacto standard for web programming at the turn of the century. You don't throw away away thousands and thousands of lines of code...
    Thousands and thousands of lines... of Perl?

    Every time I've seen Perl programmers look at Java code, they roll their eyes and say, "Dude! I could do that in three lines of Perl!"

    If, for example, JBoss were written in Perl, it would be -- at most -- about 25 lines of code.

    Java's type system is verbose and inexpressive. Personally, if I had to use an inexpressive type language, I'd prefer it to be concise.

    Better still, an expressive and concise type language, like Haskell's.

  • faoileag (unregistered) in reply to Charles F.
    Charles F.:
    Every time I've seen Perl programmers look at Java code, they roll their eyes and say, "Dude! I could do that in three lines of Perl!" If, for example, JBoss were written in Perl, it would be -- at most -- about 25 lines of code.
    Perl developers in that way resemble something like inverse anglers. Whereas the latter tend to increase the results of their labour, the former tend to decrease it ;-)

    Be that as it may, lines of code are a very bad measurement. I've just finished writing a rather complex web application, the front-end javascript of which is only 1 line of code! True, a rather long line, but still. Only one line. :-)

  • (cs) in reply to eViLegion
    eViLegion:
    Pffft.... doesn't he know the correct way to do this is?:

    $blank1 = " "; $blank2 = "  "; $blank4 = "    "; $blank8 = "        "; $blank16 = "                "; $blank32 = "                                "; etc...

    Edit: sigh Fuck this website. Seriously.

    Edit 2: I see Hasse already had the same problem.

    Newfags can't triforce
  • Peter (unregistered) in reply to Grown up
    Grown up:
    Seriously, the FRIST meme was hackneyed on day one.

    Captcha: wisi :adj: "Smartah"

    I'm wisi than you.

    And the meme of quoting your Captcha became hackneyed a couple of days later...

  • Chris P. Peterson (unregistered)

    At least he didn't say that he'll just add:

    $blank11 = " ";

  • Paula (unregistered)

    What happens when you need 12 spaces?

    $blank3 * $blank4

    FTW

  • (cs)

    OpenVMS BASIC version:

    option type=explicit
declare integer wspace
declare string foo
foo = "This is a test"
wspace = len(foo)-len(edit$(foo,2%))
  • (cs)

    I think that a big problem is the notion/perception that technology improvements don't affect the bottom line, and this is usually because most managers don't think beyond how the app looks/what can be sold.

    You often get companies that stick with old software because "It works" but really think of how much better it could work with modern practices and technologies? Sure, that app you wrote in the early 1990s in Delphi might work, but technology has evolved and there isn't any good reason not to move to .NET now - you would get a lot of new and powerful features and all the advances in technology since.

    Perl is the same thing: It works sure, but there are MUCH better alternatives now so there's no real reason to stick with Perl, as it's harder to find a Perl developer than say a PHP or even a Python developer. The big Perl app might work, but it would probably be BETTER if it was good PHP or Python or even Java.

  • Bananafish (unregistered) in reply to faoileag
    faoileag:
    Charles F.:
    Every time I've seen Perl programmers look at Java code, they roll their eyes and say, "Dude! I could do that in three lines of Perl!" If, for example, JBoss were written in Perl, it would be -- at most -- about 25 lines of code.
    Perl developers in that way resemble something like inverse anglers. Whereas the latter tend to increase the results of their labour, the former tend to decrease it ;-)

    Be that as it may, lines of code are a very bad measurement. I've just finished writing a rather complex web application, the front-end javascript of which is only 1 line of code! True, a rather long line, but still. Only one line. :-)

    So true, faoileag. A 25-line Perl script takes 38 hours to process 2,000,000 tiny little files. The same job can be done in 37 hours with a 69 line Java program, 28 hours with a 45 line Awk script, or 11 hours with a 700 line COBOL program.

    #Lines <> efficiency.

    Maybe that's why this statement would be a comment?

  • eros (unregistered)

    People trying (and failing) to get spaces into the comments is even more entertaining than the article. :-)

  • (cs) in reply to eros
    eros:
    People trying (and failing) to get spaces into the comments is even more entertaining than the article. :-)

    Yeeeeahhhp!

    I tried the technique that works on TDWTF forums... turns out that shit doesn't fly on the front page.

    Darn them.... darn them all to heck!

  • chernobyl (unregistered) 
    $blank1 = " "; # concatenate as needed

    There, fixed.

  • Anonymous (unregistered)

    I don't like Perl. I lost a bet when I predicted that the first Perl 6 interpreter will be released before Duke Nukem Forever.

  • vindico (unregistered) in reply to faoileag
    faoileag:
    JimmyCrackedCorn:
    I understand legacy applications, but I still wonder about any calculation that could determine when technical debt makes it worth it to do a re-engineering/refurbishing/rewriting project.
    As long as it is possible to fix even critical bugs (say, a memory leak in an embedded application written in c++) and new features are not only demanded by customers but can also be added, the pain of rewriting a large legacy app is usually far too great for most companies.

    The rewrite takes time and a lot of manpower. Think 1, 2 or more years until app 2.0 has the same functionality of app 1.0. From a business point of view that's a lot of money to invest, and you want to see some return on that investment.

    Wow, one or two years would be like a dream come true. At my job, the Big Rewrite is up to 5 years (and counting), but still has less than half the functionality of the original. The guy who was in charge of this massive brain-fart quit a few months ago, and now it looks like nobody is really interested in finishing it. ;-)

Leave a comment on “Drawing a Blank”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article