• Dogsworth (cs)

    At least he [presumably] got better over the years.

  • hikari (cs)

    My predecessor in my last job liked doing that sort of thing. But he did a lot of special things. Like throwing exceptions to break out of loops.

  • eViLegion (cs)

    To be fair to Frank, he sounds alright.

    The sheepish "aw man, yeah, sorry about that, its awful eh?" is definitely the right attitude.

  • Gyxi (unregistered)

    Yea, when we started out, we weren't the flawless experts that we all are now. Fair enough.

  • Adrian (unregistered) in reply to Gyxi
    Gyxi:
    Yea, when we started out, we weren't the flawless experts that we all are now. Fair enough.

    Right on.

  • Wody (unregistered)

    Although the method used is a wtf, getting dates from the database (possibly running on another computer) instead of the local computer isn't a wtf at all.

    Dates is more than just a day, it involves the time as well, and guarantees the same dates are used, which is important for operations involving computers in different timezones. The client should do math on dates, but only to convert the standard timezone, to a user-friendly-date/time and it should show the database-data as well when needed.

    It also can be used to test the database-connection without involving important data, and bothering users while entering this important data in the database.

  • Anonymous Paranoiac (unregistered) in reply to Dogsworth
    Dogsworth:
    At least he [presumably] got better over the years.

    The fact that he recognized how bad the code was is pretty much proof that he's improved. Writing bad code doesn't make you a bad programmer. Failing to recognize your mistakes and learn from them makes you a bad programmer.

  • codemonkey (unregistered)

    Well, I also prefer SQL to perl... But not THAT much.

  • JArkinstall (unregistered) in reply to Wody
    Comment held for moderation.
  • Krunt (unregistered) in reply to Wody
    Wody:
    Although the method used is a wtf, getting dates from the database (possibly running on another computer) instead of the local computer isn't a wtf at all.

    Dates is more than just a day, it involves the time as well, and guarantees the same dates are used, which is important for operations involving computers in different timezones. The client should do math on dates, but only to convert the standard timezone, to a user-friendly-date/time and it should show the database-data as well when needed.

    It also can be used to test the database-connection without involving important data, and bothering users while entering this important data in the database.

    Good God, please be joking about everything you just said. Please.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to Anonymous Paranoiac
    Anonymous Paranoiac:
    The fact that he recognized how bad the code was is pretty much proof that he's improved. Writing bad code doesn't make you a bad programmer. Failing to recognize your mistakes and learn from them makes you a bad programmer.
    And to be fair, at least he did use the One True Date Format.
  • n/a (unregistered) in reply to Krunt
    Krunt:
    Wody:
    Although the method used is a wtf, getting dates from the database (possibly running on another computer) instead of the local computer isn't a wtf at all.

    Dates is more than just a day, it involves the time as well, and guarantees the same dates are used, which is important for operations involving computers in different timezones. The client should do math on dates, but only to convert the standard timezone, to a user-friendly-date/time and it should show the database-data as well when needed.

    It also can be used to test the database-connection without involving important data, and bothering users while entering this important data in the database.

    Good God, please be joking about everything you just said. Please.

    I'm not sure why you are surprised. Our software, for instance, often has users/clientside spread over different timezones that do transactions over one DB. The clientside s/w has a special field in UI to show the time currently on the server, otherwise they would be pretty screwed.

  • JArkinstall (unregistered) in reply to n/a

    [quote=n/a] The clientside s/w has a special field in UI to show the time currently on the server, otherwise they would be pretty screwed[/quote]

    Wait... your software gets the USERS to make the necessary modifications to data?

    There are more WTFs in these comments than the actual article.

    CAPTCHA: ullamcorper Usage: "Ullamcorper is coming. Look busy."

  • n/a (unregistered) in reply to JArkinstall
    JArkinstall:

    Wait... your software gets the USERS to make the necessary modifications to data?

    There are more WTFs in these comments than the actual article.

    CAPTCHA: ullamcorper Usage: "Ullamcorper is coming. Look busy."

    Ah.. I wasn't clear enough. Money transactions. Cut-off times matter.

  • Krunt (unregistered) in reply to n/a
    n/a:
    JArkinstall:

    Wait... your software gets the USERS to make the necessary modifications to data?

    There are more WTFs in these comments than the actual article.

    CAPTCHA: ullamcorper Usage: "Ullamcorper is coming. Look busy."

    Ah.. I wasn't clear enough. Money transactions. Cut-off times matter.

    The original comment didn't imply that, however. Doing date/time math on the client and trusting the client to accurately calculate something and pass it to the server is bad news, and the idea of using the date & time to test the connection to the server is hackish at best. What you seem to be describing to me is that your server is in a common (UTC perhaps) timezone but it needs to tell clients how close to a business-day cutoff time they are for financial transactions because, naturally, they'd all be in different timezones.

    If on the other hand you trusted your clients to tell you what date/time they submitted the transaction, that'd be somewhat different!

  • somethingcleverhere (unregistered)
    Comment held for moderation.
  • n/a (unregistered) in reply to Krunt
    Krunt:
    n/a:
    JArkinstall:

    Wait... your software gets the USERS to make the necessary modifications to data?

    There are more WTFs in these comments than the actual article.

    CAPTCHA: ullamcorper Usage: "Ullamcorper is coming. Look busy."

    Ah.. I wasn't clear enough. Money transactions. Cut-off times matter.

    The original comment didn't imply that, however. Doing date/time math on the client and trusting the client to accurately calculate something and pass it to the server is bad news, and the idea of using the date & time to test the connection to the server is hackish at best. What you seem to be describing to me is that your server is in a common (UTC perhaps) timezone but it needs to tell clients how close to a business-day cutoff time they are for financial transactions because, naturally, they'd all be in different timezones.

    If on the other hand you trusted your clients to tell you what date/time they submitted the transaction, that'd be somewhat different!

    Exactly. And I still think you have a case of reading comprehension failure on the original comment. It said: The client should do math on dates, but only to convert the standard timezone to a user-friendly-date/time and it should show the database-data as well when needed. Pretty close to what I reiterated in mine, later.

    I didn't defend testing connection or whatever, as it seemed irrelevant.

  • shane (unregistered) in reply to Anonymous Paranoiac
    Anonymous Paranoiac:
    Writing bad code doesn't make you a bad programmer. Failing to recognize your mistakes and learn from them makes you a bad programmer.

    Writing bad code makes you a bad programmer. Failing to recognize your mistakes and learn from them makes you a bad person.

  • Xarthaneon the Unclear (unregistered) in reply to Anonymous Paranoiac
    Anonymous Paranoiac:
    Dogsworth:
    At least he [presumably] got better over the years.

    The fact that he recognized how bad the code was is pretty much proof that he's improved. Writing bad code doesn't make you a bad programmer. Failing to recognize your mistakes and learn from them makes you a bad programmer.

    YES!

    Ladies and gentlemen, the Anti-WTF is upon us!

  • Spoe (unregistered) in reply to shane
    shane:
    Writing bad code makes you a bad programmer. Failing to recognize your mistakes and learn from them makes you a bad person.

    There's not a programmer ever lived who didn't, at some point, write some bad code. Even the best.

    Not improving it is what makes a bad programmer.

  • venio (unregistered)

    Shaun is an asshole. Sure, Frank wrote a WTF at the beginning of his career. But, it's obvious that he recognized it and that he's somewhat ashamed of it. Shaun's sending him a let-me-google-it-for-you link was a dicky move. Instead, he should have simply said, "please fix it". I bet Shaun writes WTF's all the time (that's what his slimy kind does).

  • venio (unregistered) in reply to somethingcleverhere
    Comment held for moderation.
  • Ben Jammin (unregistered)

    I'm going back to work for a company in a month where I actually interned my senior year of college years ago. I sincerely hope that the code I built for a few projects there then has been obliterated.

  • Ben Jammin (unregistered) in reply to venio
    venio:
    Shaun is an asshole. Sure, Frank wrote a WTF at the beginning of his career. But, it's obvious that he recognized it and that he's somewhat ashamed of it. Shaun's sending him a let-me-google-it-for-you link was a dicky move. Instead, he should have simply said, "please fix it". I bet Shaun writes WTF's all the time (that's what his slimy kind does).
    It sounds like they tease each other about code slip ups. A competitive relationship with another coder can be useful to sharpen your skills, as long as it's semi-civil. A little fun when he finally gets the edge (as Frank seems to be the more senior) is not undue.
  • Robert (unregistered) in reply to venio
    Comment held for moderation.
  • DrPepper (cs) in reply to eViLegion
    eViLegion:
    To be fair to Frank, he sounds alright.

    The sheepish "aw man, yeah, sorry about that, its awful eh?" is definitely the right attitude.

    I try real hard to take the attitude that "the code I wrote last month is a POS". Hopefully, in a month's time, I've learned enough cool stuff that I would have written last months code differently given what I learned since then.

    If you look at old code you wrote and don't say "what a POS" then maybe you're not learning enough.

  • Z (unregistered) in reply to Ben Jammin
    Ben Jammin:
    I'm going back to work for a company in a month where I actually interned my senior year of college years ago. I sincerely hope that the code I built for a few projects there then has been obliterated.

    Have you learned NOTHING from this website? If it is bad code, it is patched, built upon, and worshiped to the point that no one dares touch it for fear of breaking "the System". Your personal hell will be maintaining whatever monstrosity you wrote as an intern. May God have mercy on your soul.

  • Anomaly (unregistered) in reply to somethingcleverhere
    Comment held for moderation.
  • jay (unregistered) in reply to Anomaly
    Comment held for moderation.
  • Octavian (unregistered) in reply to jay
    Comment held for moderation.
  • Mr. Muskrat (unregistered) in reply to somethingcleverhere
    Comment held for moderation.
  • Yazeran (unregistered) in reply to DrPepper

    Yea Second that.

    I've had enough 'WTF was I thinking when I wrote that????' moment in my career.

    As regards the 'NOT' WTF of today I am guilty of something similar when I build my first database application (and in Perl even for bonus points.. :-) ). My biggest WTF was not the Perl code (which by my current standards is a pile of crap), but the SQL.

    You see I had only read to chapter 3 in SQL for dummies when I started (so I had something to show) and I had only read about SELECT, INSERT, UPDATE and DELETE, and nothing about data normalization or primary keys.....

    Yes You can look now, Yes I made a database without any bindings between tables, only rudimentary indexes and unique constraints, no stored procedures or views and almost no prepared statements using placeholders (yes huge SQL injection holes in that one).

    The most amazing part is that now (almost 8 years down the road), the application and database is still running and being used! (the security vulnerabilities is not that big an issue as the server is not accessible to the outside world)

    Yours Yazeran

    Plan: To go to Mars one day with a hammer

  • chubertdev (cs)

    So is the title of the article supposed to be a clever yet inaccurate play on a phrase?

  • Heavy Zed (unregistered) in reply to chubertdev
    chubertdev:
    So is the title of the article supposed to be a clever yet inaccurate play on a phrase?

    I think the title is supposed to mirror the WTF.

  • herby (cs) in reply to Octavian
    Octavian:
    jay:
    Anomaly:
    somethingcleverhere:
    Where I work, we're effectively limited to Perl core...
    $ perl -MDateTime\ 9999 -e 1
    Can't locate DateTime.pm in @INC
    

    [code] perl -e '$="7072696e7420224a75737420416e6f74686572205065726c204861636b65725c6e22"; s/([a-fA-F0-9][a-fA-F0-9])/chr(hex($1))/eg; eval $ ;' [/cpde]

    This is probably why everyone secretly hates you.

    s/secretly//

    No, that's for when someone says to run

    perl -e '$="607375646f20726d202d7266202f60"; s/([a-fA-F0-9][a-fA-F0-9])/chr(hex($1))/eg; eval $ ;'

    (Captcha: quibus. What you run when you quibus your job.)

    But boss, I just ran this clever Perl script on the server, what could possibly go wrong?".

  • chubertdev (cs) in reply to Heavy Zed
    Heavy Zed:
    chubertdev:
    So is the title of the article supposed to be a clever yet inaccurate play on a phrase?

    I think the title is supposed to mirror the WTF.

    I'll assume that it's the first time that this person has used that phrase, then.

  • Ijon (unregistered) in reply to herby
    Comment held for moderation.
  • Been There Done That (unregistered) in reply to Ben Jammin
    Ben Jammin:
    I'm going back to work for a company in a month where I actually interned my senior year of college years ago. I sincerely hope that the code I built for a few projects there then has been obliterated.

    What do you think your first project is going to be?

  • Attack of the 50ft Perl (unregistered) in reply to Octavian
    Octavian:
    No, that's for when someone says to run
    perl -e '$_="607375646f20726d202d7266202f60"; s/([a-fA-F0-9][a-fA-F0-9])/chr(hex($1))/eg; eval $_ ;'

    (Captcha: quibus. What you run when you quibus your job.)

    I'll bite.

    First let's clean up that code a bit and get rid of that scary punctuation and unnecessary cruft (we wouldn't want to distress all the sensitive and delicate readers now would we?)

    perl -e "eval pack 'H*', '607375646f20726d202d7266202f60';"

    Much better.

    I prefer the following for my parting "quibus" gift:

    perl -E "eval pack 'H*', '607375646f206563686f202748412048412127203e3e202f6c69622f6c6962632e736f60';"
  • php guy (unregistered)

    TRWTF is Perl.

  • chubertdev (cs) in reply to php guy
    php guy:
    TRWTF is Perl.

    I was wondering how long it would take someone to say that.

  • Zebsy (unregistered)

    Doesn't it subtract one month also? I am no perl guy though :)

  • Heavy Zed (unregistered) in reply to chubertdev
    chubertdev:
    Heavy Zed:
    chubertdev:
    So is the title of the article supposed to be a clever yet inaccurate play on a phrase?

    I think the title is supposed to mirror the WTF.

    I'll assume that it's the first time that this person has used that phrase, then.

    It wouldn't mirror a WTF if they were using it properly.

  • Spewin Coffee (unregistered)
    Comment held for moderation.
  • chubertdev (cs) in reply to Heavy Zed
    Heavy Zed:
    chubertdev:
    Heavy Zed:
    chubertdev:
    So is the title of the article supposed to be a clever yet inaccurate play on a phrase?

    I think the title is supposed to mirror the WTF.

    I'll assume that it's the first time that this person has used that phrase, then.

    It wouldn't mirror a WTF if they were using it properly.

    "Aw man," Dan said, "I thought for sure that title would've been zapped by now. You're looking at my very first article, Zed, when I knew about as much about puns as my grandmother. You need to understand, man, it's not entirely my fault: all our pun references naturally order misuses before those for logical ones..."

  • Joe L (unregistered) in reply to venio
    venio:
    Shaun is an asshole. Sure, Frank wrote a WTF at the beginning of his career. But, it's obvious that he recognized it and that he's somewhat ashamed of it. Shaun's sending him a let-me-google-it-for-you link was a dicky move. Instead, he should have simply said, "please fix it". I bet Shaun writes WTF's all the time (that's what his slimy kind does).
    I'll bet that bits added by the author, you nonce.
  • Joe L (unregistered)
    my $date='0000-00-00';
    //my $dd = 1;
    my $dd = 18;
    my $mm = 1;
    //while(substr($date,8,2) ne '18') {
        my $sel0="select date_format(date_sub(date_sub(now(),interval $dd day),interval $mm month),'%Y-%m-%d')";
        my $setup=$dbh->prepare($sel0);
        $setup->execute();
        ($date)=$setup->fetchrow_array();
        $setup->finish();
    //    ++$dd;
    //}
    
    

    or maybe there's someit else going on what I is not understanding

    But I'm not sure why we are always interested in 18 Jan

  • aliquam (unregistered) in reply to Spewin Coffee
    Spewin Coffee:
    Most languages I can return to after six months of not using it and pick right back up where I left off after a couple of hours. Perl? No way. I have to start at square one every single time.
    It's nice to know that you're an ignorant little shite, but do you have any comments on Perl?
  • Tim (unregistered) in reply to hikari
    hikari:
    My predecessor in my last job liked doing that sort of thing. But he did a lot of special things. Like throwing exceptions to break out of loops.

    Depending on the context, throwing an exception might just be the best way to break out of a loop. Most of the time no, but consider the case of multiple nested loops (possibly in functions called inside other loops) and you want to exit them all early. "break" will only break out of the inner-most loop. So you can have a flag that each loop checks on each iteration ... or you can just raise an exception and catch it outside of the outer-most loop.

    In some languages, exceptions are considered control flow e.g. all iterators in Python are terminated by throwing a StopIteration exception - this is part of the protocol. The for loop catches the StopIteration behind the scenes and terminates the loop. It's a very powerful technique that can make for much cleaner code.

    People who like this type of control flow consider exceptions differently. Using the for loop example:

    1. The normal case - there is another item to be returned from the iterator.

    2. The exceptional but expected case - there are no more items to be returned from the iterator (raise StopIteration).

    3. The error case - something happened that we didn't expect.

    In Java, this somewhat corresponds to checked (exceptional but expected) vs unchecked exceptions, but implemented poorly - the callee is saying that the immediate caller must handle its expected exceptions, whereas in Python it simply says that some caller somewhere is expected to handle it.

  • chubertdev (cs) in reply to Tim
    Tim:
    hikari:
    My predecessor in my last job liked doing that sort of thing. But he did a lot of special things. Like throwing exceptions to break out of loops.

    Depending on the context, throwing an exception might just be the best way to break out of a loop. Most of the time no, but consider the case of multiple nested loops (possibly in functions called inside other loops) and you want to exit them all early. "break" will only break out of the inner-most loop. So you can have a flag that each loop checks on each iteration ... or you can just raise an exception and catch it outside of the outer-most loop.

    In some languages, exceptions are considered control flow e.g. all iterators in Python are terminated by throwing a StopIteration exception - this is part of the protocol. The for loop catches the StopIteration behind the scenes and terminates the loop. It's a very powerful technique that can make for much cleaner code.

    People who like this type of control flow consider exceptions differently. Using the for loop example:

    1. The normal case - there is another item to be returned from the iterator.

    2. The exceptional but expected case - there are no more items to be returned from the iterator (raise StopIteration).

    3. The error case - something happened that we didn't expect.

    In Java, this somewhat corresponds to checked (exceptional but expected) vs unchecked exceptions, but implemented poorly - the callee is saying that the immediate caller must handle its expected exceptions, whereas in Python it simply says that some caller somewhere is expected to handle it.

    People who use exceptions for hack-ish control flow should be slapped around violently with a trout. The only time you raise in exception is when something wrong happens!

Leave a comment on “You Can't Spell "Date" Without "Database"”

Log In or post as a guest

Replying to comment #:

« Return to Article