• (cs) in reply to loneprogrammer

    loneprogrammer:
    dubwai:
    This is nothing.  I was once conversing on a forum with someone who posted a date validation written entirely in regex.  Theoretically, it worked but it was uglier than sin.

    You sure it wasn't a email address validator?

    That's the output from make_rfc822re(), a function that is hidden inside the module.

    Huh, that's pretty nasty.  No, this was a full Gregorian date validator that even supported AD dates that come before that funny year in the 15 hundreds.

  • (cs) in reply to David
    Anonymous:

    Of course I'm not a perl programmer, so I have no idea how much worse this general method is than the built in module.

    One of the simplest, most readable, and least error prone ways of doing this in Perl is by using the DateTime module mentioned above:

    use DateTime;
    my $yesterday = DateTime->today->subtract(days => 1);

    That's it — Perl doesn't have to be unreadable if you don't want it to be ...

  • (cs) in reply to dubwai
    dubwai:
    even supported AD dates that come before that funny year in the 15 hundreds.


    But it's a different year for different places... in fact Russia didn't convert till the 1900s, and the USA converted after George Washington was born (he changed his birthday to compensate)
  • samwyse (unregistered) in reply to Andrew Medico

    I noticed that right away, but I was beginning to fear that no one else would.

  • samwyse (unregistered) in reply to Andrew Medico
    Anonymous:
    There's an additional WTF of calling /bin/date multiple times and expecting the date to be the same every time. Better not run this function at 23:59:59!

    I noticed that right away, but I was beginning to fear that no one else would.
  • (cs) in reply to mizhi
    mizhi:


    The more serious wtfery is the fact that this code is totally non-portable.  Try running it on Windows.


    I tried it; it worked fine:

    Cygwin> $ _

        -dZ.

  • (cs) in reply to loneprogrammer
    loneprogrammer:
    Second, it won't run on most versions of Unix.  Just because it works on Linux doesn't mean it's Unix.


    If this were a gaming form, I'd say that <font style="color: rgb(255, 0, 0);" size="5">J00 JU5T G0T PWN3D!!!!!111one</font>

  • (cs) in reply to DZ-Jay
    DZ-Jay:

    I tried it; it worked fine:

    Cygwin> $ _



    What about without cygwin?
  • (cs) in reply to Ross Day
    Ross Day:
    If this were a gaming form, I'd say that <font style="color: rgb(255, 0, 0);" size="5">J00 JU5T G0T PWN3D!!!!!111one</font>
    Be glad it’s not then – it saved you from looking like a moron. ;)
  • vhawk (unregistered)

    I hate scripting languages .... hate them .... hate them.  And even I would have used google to try and find some perl equivalent of date() - 1

  • Joe (unregistered)

    This is pretty F*ed, im not even an EECS Graduate or Major and I knew of better methods that would probably been GIVEN or open sourced...

    I still like the Url coding from yesterday better...

  • BogusDude (unregistered) in reply to Ross Day
    Ross Day:
    I've found that there is a pretty big difference between a Perl "programmer" and a Perl "scripter".  This Perl Guy definitely seems to fall in the latter category.

    Perl, although its syntax is awkward at times, does have good modularization, layering, and object-oriented capabilities.  Real Perl programs are written this way.

    Then you have the Perl scripter...who rights quick one file scripts.  These are the crontab and other quick-fix kings.  It's more about getting the little script to do exactly what it's supposed to do on this exact system at this time than it is about writing good portable modular reusable code.

    I'm not saying this isn't a WTF (with how the logic is just wrong), but that it's non-portable and haphazard doesn't really surprise me.


    Perl was originally meant to be a scripting language. Personally, I feel people are using the wrong tool for the job when they are looking for object orientation, modularisation etc. I think that should be done in another language (with stricter syntax.)
    I don't beleive there is such a thing as a "Real Perl program". My term for it is "Hack".
    I believe that perl is supposed to be used for those little "getting the little script to do exactly what it's supposed to do on this exact system at this time" jobs.


    ps. Could someone please tell me how to quote on this forum ? It looks fine in the preview and then screws up when I submit. :(

  • (cs) in reply to BogusDude
    Anonymous:
    Perl was originally meant to be a scripting language. Personally, I feel people are using the wrong tool for the job when they are looking for object orientation, modularisation etc. I think that should be done in another language (with stricter syntax.)

    That thinking, of course, would leave us without, among other things, spamassassin.
    Anonymous:
    I don't beleive there is such a thing as a "Real Perl program". My term for it is "Hack".

    Well, you've obviously never done any _real_ perl programming, then.  Just because it _can_ look like line noise, doesn't mean it _has_ to look like line noise.  _Good_ perl doesn't look like line noise.  It's object-oriented, dynamic and flexible.  It's platform-independent.  If written properly, it's as maintainable as any other language. It's actually pretty fucking fast, too.  And with careful use of CPAN, you don't have to write very much code to do most tasks.

    Now, of course it's possible to use it to write little hacks, and that is what people who don't understand perl tend to see it as being for. Using the same logic, I could say "I don't know how to use C properly, so all it's good for is obfuscated coding contests", completely disregarding all the good and maintainable C out there.  This approach could be taken for pretty much all languages with the exception of those that were written to be obfuscated: Befunge, Brainf*ck, and C++

    This is not to say that the code quoted is a non-wtf - the main wtf in the code is that it suffers from NIHS, a large part of it could be replaced using less buggy code direct from CPAN.

    Simon
  • (cs)
    [...]all languages with the exception of those that were written to be obfuscated: [...] C++

    *applause* ^^

    for everyone who's knocking perl for being eternally unreadable:

    use strict;
    use warnings 'all';
    use English;

    What's nice about perl (IMO) is that if you want to turn it into a B&D language, you can. It's dynamic and DWIM-y by default, but that very dynamic-ness also makes it possible to have modules that enforce stricture (English, the "Class::" heirachy, etc).

    Sure, it's not perfect ("only perl can parse Perl", etc), but that's what Perl 6 will be for.

  • (cs) in reply to Ross Day

    Perl having object-oriented capabilities.... Whatever weed you're on you gotta get off it!!

  • (cs) in reply to Maurits

    Maurits:
    dubwai:
    even supported AD dates that come before that funny year in the 15 hundreds.


    But it's a different year for different places... in fact Russia didn't convert till the 1900s, and the USA converted after George Washington was born (he changed his birthday to compensate)

    I could be wrong here but when a country converted to the Gregorian calendar doesn't really change the Gregorian system, does it?  The Gregorian calendar judges reevaluatd dates that came before it was created.  It's a just a calendar whether you or I follow it doesn't change how it is defined.

  • (cs) in reply to Alan

    I used to be a Perl guy, and then I discovered PHP and its infinitely superior readability and out-of-the-box goodness. Behold:

    <FONT face="Courier New">$yesterday = date("Y-m-d", strtotime("yesterday"));</FONT>

    Done.

    It works with

    <FONT face="Courier New">$tomorrow = date("Y-m-d", strtotime("tomorrow"));</FONT>

    too.

    Language wars are pointless, so starting one is not my intention, but I must say I don't really understand why Perl folks stay with Perl when PHP does pretty much everything Perl does, much more easily, and just as fast if not faster.

    Of course PHP is a terrible language if you're a beginner, because it solves all sorts of problems with built-in functions that are excellent exercises to solve yourself when you're learning to program, and anyone starting out with PHP is almost guaranteed to be WTF fodder a few years down the line. But when you know how to do this crap, there's really no point in having to do it all over again every time you need to, and a strong and complete built-in library like PHP's is a great boon to productivity. No need to troll CPAN, find and install modules, hunt for documentation, etc.

  • (cs) in reply to BogusDude
    Anonymous:
    Perl was originally meant to be a scripting language. Personally, I feel people are using the wrong tool for the job when they are looking for object orientation, modularisation etc. I think that should be done in another language (with stricter syntax.)

    I don't beleive there is such a thing as a "Real Perl program". My term for it is "Hack".


    I have a slightly different opinion:

    Java was originally meant to be an embedded language. Personally, I feel people are using the wrong tool for the job when they are looking for object orientation, modularisation etc. I think that should be done in another language like Perl (with a better syntax.)

    I don't believe there is such a thing as a "Real Java program". My term for it is "Hack".

  • (cs) in reply to loneprogrammer
    loneprogrammer:
    Anonymous:
    Perl was originally meant to be a scripting language. Personally, I feel people are using the wrong tool for the job when they are looking for object orientation, modularisation etc. I think that should be done in another language (with stricter syntax.)

    I don't beleive there is such a thing as a "Real Perl program". My term for it is "Hack".


    I have a slightly different opinion:

    Java was originally meant to be an embedded language. Personally, I feel people are using the wrong tool for the job when they are looking for object orientation, modularisation etc. I think that should be done in another language like Perl (with a better syntax.)

    I don't believe there is such a thing as a "Real Java program". My term for it is "Hack".

    Did you do that in Perl or did you switch the lgs by hand? [:)]

  • (cs) in reply to rogthefrog

    > I don't really understand why Perl folks stay with Perl when PHP does pretty much everything Perl does, much more easily, and just as fast if not faster.

    Give it time, my son, give it time and you'll see why.

    PHP is a dog, will always be a dog.

    The built in functions are a naming mess and the parameter order picked at random :

    mixed str_replace ( mixed needle, mixed new_needle, mixed haystack[, int &count] )
    int strpos ( string haystack, mixed needle [, int offset] )

    This, imho, is not a good sign!


  • (cs) in reply to loneprogrammer
    loneprogrammer:
    Anonymous:
    Perl was originally meant to be a scripting language. Personally, I feel people are using the wrong tool for the job when they are looking for object orientation, modularisation etc. I think that should be done in another language (with stricter syntax.)

    I don't beleive there is such a thing as a "Real Perl program". My term for it is "Hack".


    I have a slightly different opinion:

    Java was originally meant to be an embedded language. Personally, I feel people are using the wrong tool for the job when they are looking for object orientation, modularisation etc. I think that should be done in another language like Perl (with a better syntax.)

    I don't believe there is such a thing as a "Real Java program". My term for it is "Hack".

    I don't see why the fact that Java was designed to be an embedded language means it shouldn't be used for object-orientation or modularization.  It was oringinally intended to be a object-oriented language for embedded systems.

    You really think that Java programs are hacks?  If that's so, a large portion of the web is running on hacks.  If you really believe this, I have to think you don't really know much about Java.  Do you feel this way about C#?

  • (cs) in reply to maht
    maht:
    > I don't really understand why Perl folks stay with Perl when PHP does pretty much everything Perl does, much more easily, and just as fast if not faster.

    Give it time, my son, give it time and you'll see why.

    PHP is a dog, will always be a dog.

    The built in functions are a naming mess and the parameter order picked at random :

    mixed str_replace ( mixed needle, mixed new_needle, mixed haystack[, int &count] )
    int strpos ( string haystack, mixed needle [, int offset] )

    This, imho, is not a good sign!



    Just because you can do something in a language doesn't mean you have to do it.  I've seen this argument in pretty much every language flamewar ever, and frankly, it sucks.  Yes, there are languages out there that will allow you to do ridiculously stupid things.  However, there is nothing forcing you to use some of them;  I've found that most of the things people take as 'this language sucks because of X' almost never get used. 
  • (cs) in reply to dubwai
    dubwai:
    I don't see why the fact that Java was designed to be an embedded language means it shouldn't be used for object-orientation or modularization.  It was oringinally intended to be a object-oriented language for embedded systems.

    Well, I don't see why Perl's early days should have any bearing on what it is today, either.

    dubwai:
    You really think that Java programs are hacks?  If that's so, a large portion of the web is running on hacks.

    A large portion of the web runs on Perl, and we both know those are all hacks, right?

  • (cs) in reply to dubwai
    dubwai:

    I don't see why the fact that Java was designed to be an embedded language means it shouldn't be used for object-orientation or modularization.  It was oringinally intended to be a object-oriented language for embedded systems.



    To be honest, I don't see the validity of either argument (Perl meant for scripting, Java meant for embedded systems => hacks!).  Almost all languages were intended for a specific purpose until some sick bastard decided, "Hey, wouldn't it be cool to do X?"  That's when you get people writing Windows programs in assembly and vector math in VB.  [:)]
  • jrock (unregistered)

    TMTOWTDI.

  • (cs) in reply to loneprogrammer

    loneprogrammer:
    dubwai:
    I don't see why the fact that Java was designed to be an embedded language means it shouldn't be used for object-orientation or modularization.  It was oringinally intended to be a object-oriented language for embedded systems.

    Well, I don't see why Perl's early days should have any bearing on what it is today, either.

    Did I say it should?  I don't like Perl except for hacks because I don't like the fact that a cat can walk across a keyboard and create a working Perl application.  Cats are generally bad developers.  But that has nothing to do with the roots of the language.

    loneprogrammer:
    dubwai:
    You really think that Java programs are hacks?  If that's so, a large portion of the web is running on hacks.

    A large portion of the web runs on Perl, and we both know those are all hacks, right?

    Again, where did I argue that?

  • (cs) in reply to mizhi
    mizhi:
    dubwai:

    I don't see why the fact that Java was designed to be an embedded language means it shouldn't be used for object-orientation or modularization.  It was oringinally intended to be a object-oriented language for embedded systems.



    To be honest, I don't see the validity of either argument (Perl meant for scripting, Java meant for embedded systems => hacks!).  Almost all languages were intended for a specific purpose until some sick bastard decided, "Hey, wouldn't it be cool to do X?"  That's when you get people writing Windows programs in assembly and vector math in VB.  [:)]

    Where did I argue that Perl was a Perl was meant for scripting and therefore all Perl programs are hacks?

  • (cs) in reply to dubwai
    dubwai:

    Where did I argue that Perl was a Perl was meant for scripting and therefore all Perl programs are hacks?



    You didn't.  Someone else did, you just got caught up in the thread. [:)]
  • (cs) in reply to mizhi
    mizhi:
    dubwai:

    Where did I argue that Perl was a Perl was meant for scripting and therefore all Perl programs are hacks?



    You didn't.  Someone else did, you just got caught up in the thread. [:)]


    BogusDude was the one who originally said that all Perl programs were hacks.

    I wasn't implying that you made the argument.  (Or at least, wasn't trying to)
  • asdf (unregistered) in reply to mizhi
    mizhi:
    Hey now, this is the Perl Way: TIMTOWTDI!

    To be honest, 'Perl Guy' looks like a guy who enjoys his unix.  It's not uncommon to find code that captures the output of a command to be used in a program/script.

    That said, doing it for /bin/date is pretty silly.  Not to mention the fact that he does it incorrectly; ignoring leap years, and saying that the previous day of the first of the year is December 1st.  But those have already been mentioned.

    The more serious wtfery is the fact that this code is totally non-portable.  Try running it on Windows.


    Hmm, I'm sure those writing VB are very concerned about whether or not their code is portable.  I can hear it now:

    VB programmer: "You should be writing that Perl code to work on multiple platforms."
    Perl programmer: "So, since your code can't be ported, you don't have to take that extra step, but I do since my code can?"
    VB programmer: "Um, yeah..."
    Perl programmer: "Bullocks."
  • (cs) in reply to jrock
    Anonymous:
    TMTOWTDI.

    TUORWTDI
    --said the python fan
  • (cs) in reply to asdf
    Anonymous:


    Hmm, I'm sure those writing VB are very concerned about whether or not their code is portable.  I can hear it now:

    VB programmer: "You should be writing that Perl code to work on multiple platforms."
    Perl programmer: "So, since your code can't be ported, you don't have to take that extra step, but I do since my code can?"
    VB programmer: "Um, yeah..."
    Perl programmer: "Bullocks."



    VB programmer: "You should be writing that Perl code to work on multiple platforms."

    Perl programmer: "So, since your code can't be ported, you don't have to take that extra step, but I do since my code can?"

    VB programmer: "No, I don't have to because the system I'm working on doesn't need to work on multiple platforms, otherwise I wouldn't be using VB.  The system you're working on very well might, since it's written in Perl."

    Perl programmer: "Ass."

    VB programmer: "Punk."

    Perl programmer: "..."
    VB programmer: "..."

    Perl programmer: "So, drinks later?"

    VB programmer: "Too right!"

  • TomDLux (unregistered) in reply to th0mas

    or

    use POSIX;

    $date_str = strftime "%d/$m/%Y", localtime( time() - $seconds_per_day );

  • asdf (unregistered) in reply to UncleMidriff
    UncleMidriff:
    Anonymous:


    Hmm, I'm sure those writing VB are very concerned about whether or not their code is portable.  I can hear it now:

    VB programmer: "You should be writing that Perl code to work on multiple platforms."
    Perl programmer: "So, since your code can't be ported, you don't have to take that extra step, but I do since my code can?"
    VB programmer: "Um, yeah..."
    Perl programmer: "Bullocks."



    VB programmer: "You should be writing that Perl code to work on multiple platforms."

    Perl programmer: "So, since your code can't be ported, you don't have to take that extra step, but I do since my code can?"

    VB programmer: "No, I don't have to because the system I'm working on doesn't need to work on multiple platforms, otherwise I wouldn't be using VB.  The system you're working on very well might, since it's written in Perl."

    Perl programmer: "Ass."

    VB programmer: "Punk."

    Perl programmer: "..."
    VB programmer: "..."

    Perl programmer: "So, drinks later?"

    VB programmer: "Too right!"



    able to be ported != needs to be ported
    or, in VB
    able to be ported <> needs to be ported

    thus, calling this in any way a wtf for using a better OS's system calls is complete bs.

  • Eric (unregistered) in reply to asdf
    Anonymous:
    calling this in any way a wtf for using a better OS's system calls is complete bs.

    Calling a WTF when, er, more than one way to do it - and do it correctly - strictly within the language exists without any heavy lifting makes sense. Do it simply in Perl, or hack together something to access an OS-specific resource. ...Tough call, I guess.

  • (cs) in reply to JThelen

    > Just because you can do something in a language doesn't mean you have to do it.  I've seen this argument in pretty much every language flamewar ever, and frankly, it sucks.  Yes, there are languages out there that will allow you to do ridiculously stupid things.  However, there is nothing forcing you to use some of them;  I've found that most of the things people take as 'this language sucks because of X' almost never get used.


    So, you are saying that I shouldn't be using the built in string functions ?
    And that consistent subject/predicate parameter order is unimportant ?

    The language sucks because it has been built in a very ad-hoc manner. It is a macro language with delusions of grandeur.

    They even changed the name from
    "Personal Home Page" to the grander sounding PHP: Hypertext Preprocessor (yet fail to mention this backronym).

    How that applies to the CLI version no-one seems to have explained.

    You should have seen it before they tidied it up a bit for v.4

    They introduced the array_* functions because of the mess.

    That all said, I'd still rather use PHP than VBScript !!

    Although I should like I'm anti-php it's not so, I was just trying to temper some of the enthusiasm of the "use PHP not Perl" of the GP


    hehe see the fun I had even trying to report a bug
    http://bugs.php.net/bug.php?id=15130

    my note explaining related pathinfo bugs was expunged from history from

    http://www.php.net/manual/en/function.pathinfo.php







  • (cs) in reply to maht
    maht:
    > Just because you can do something in a language doesn't mean you have to do it.  I've seen this argument in pretty much every language flamewar ever, and frankly, it sucks.  Yes, there are languages out there that will allow you to do ridiculously stupid things.  However, there is nothing forcing you to use some of them;  I've found that most of the things people take as 'this language sucks because of X' almost never get used.


    So, you are saying that I shouldn't be using the built in string functions ?
    And that consistent subject/predicate parameter order is unimportant ?



    Did you read a flippin thing I wrote?  I said nothing about not using built in functions;  I said nothing about importance or unimportance of consitency.  I mad a generalized statement about horrid arguments for 'X Language sucks because of this shitty built in type/function/etc.'  And you know what?  I stand by it.  Saying a language has a shitty built in function is fine;  decrying it as the spawn of all evil because of that, which, as I stated, YOU ARE NOT FORCED TO USE, is bullshit in it's most pure form.

    Reading Comprehension.  You can have this.

  • (cs) in reply to asdf
    Anonymous:

    able to be ported != needs to be ported
    or, in VB
    able to be ported <> needs to be ported

    thus, calling this in any way a wtf for using a better OS's system calls is complete bs.


    The WTF specifically stated that the team wrote things for many different platforms.  If that doesn't sound like a call for things to be portable, then I don't know what does.
  • (cs) in reply to JThelen

    PHP is a dog and will always be a dog. It’s not about a particular set of builtins.

    • All the builtins are defined in a haphazard way. The ones shown above are just an example; the language doesn’t blow because of these two builtins, it blows because any list of cruddy builtins could be made arbitrarily long.
    • There are literally thousands of builtins all in a single namespace.
    • Many of them are duplicates with slightly varying functionality, spelling and parameters each.

    PHP is an overgrown template engine. It’s very nice as a template engine, but it’s bollocks as a programming language.

    Perl was always a language. It has adopted older cruft, which is why it can look so messy, but it was never single-purpose. If you actually know sed, awk and shell, you will recognize almost all the stuff that looks ad-hoc as coming from previous things. But as Larry said, he set out to create Perl because he didn’t want another “little language” do to one specific thing; he wanted something that overcomes the limitations of restricting yourself to the Unix toolbox. Perl’s pure spirit is far closer to LISP than to any of its seemingly-obvious ancestors.

    PHP is a long step back from that, abandoning first-class lists and closures and making references a strange language quirk and anonymous functions ridiculously difficult. Nor is the OO system a joy, exactly.

    The only thing where Perl really suffers is that its OO system is very ad-hoc, bolted on sideways, with peculiar quirks and no obvious, encapsulable data inheritance (the non-obvious but clean way is Abigail’s “inside-out objects” style). In some ways, the simplicity of this OO system at language level really appeals to both the minimalist and the hacker in me, but in practice I’d prefer if I could just get on with work instead.

    I’m not saying PHP sucks simply because I dislike it. I dislike Python too, and I even have some critique of it as a language, but then the same is true of Perl for Pythonistas and I can listen to their arguments. I love XSLT with all its massive annoyances and I greatly enjoy Javascript (no, I’m not joking.) Ruby is very cool, though I never found the time to give it a fair shot. I even love C (though not C++), and could in fact arrange myself with Java if pressed. I want to get into functional programming land for real at some point – Scheme, ML, Haskell and friends. I love Perl more than anything, indeed, but I’m not a bigot, and I know it has its warts (as do all languages). My saying that PHP sucks is based not on dislike, but on criteria that I consider rather objective.

  • Hank Miller (unregistered) in reply to dubwai
    dubwai:

    I could be wrong here but when a country converted to the Gregorian calendar doesn't really change the Gregorian system, does it?  The Gregorian calendar judges reevaluatd dates that came before it was created.  It's a just a calendar whether you or I follow it doesn't change how it is defined.



    Yes and no.   The problem is there are many old documents from before the conversion that are wrong.   George Washington's birth certificate (this likely never existed, but you get the idea) for example gives his birth date on an incorrect date.  

    Historians care about this.   The rest of us don't.  

    Historians generally care about day of the week more than any particular day of the month  (some days like the sabbath have religious significance, so knowing something happened on January 19th doesn't mean much, but if it was jews doing something on Saterday January 19th, it is interesting because they found it important enough to violate the sabbath to do!)

  • asdf (unregistered) in reply to mizhi

    So the Mozilla team writes Firefox for multiple platforms.  Does that call for every bit of code being constructed for any platform to be able to be dropped into another platform?  Methinks not.  Perl is commonly thought of as a scripting language, and the fact that this guy chose to use a fairly basic *nix function doesn't constitute a WTF in and of itself.

    However, I do agree that he is a chaunce for not researching other built-in solutions, I'm not arguing this.  I'm just saying that TMTOWTDI, so

  • (cs) in reply to asdf
    Anonymous:
    Perl is commonly thought of as a scripting language, and the fact that this guy chose to use a fairly basic *nix function doesn't constitute a WTF in and of itself.


    If you're going for portability, then it does constitute a wtf.
  • asdf (unregistered) in reply to mizhi
    mizhi:
    Anonymous:
    Perl is commonly thought of as a scripting language, and the fact that this guy chose to use a fairly basic *nix function doesn't constitute a WTF in and of itself.


    If you're going for portability, then it does constitute a wtf.


    Exactly, but we simply can't ascertain that here; thank you for clarifying my point.
  • (cs) in reply to asdf
    Anonymous:

    Exactly, but we simply can't ascertain that here; thank you for clarifying my point.


    Throughout this thread, I've noted that they work in a shop that writes software for many platforms.  That was where my gripe about the portability came in.

    Good reading comprehension.
  • (cs) in reply to loneprogrammer
    loneprogrammer:

    What does it output if you write it correctly?  The reason it prints the same thing twice is that you clobbered all the variables with the result of localtime($yesterday).



    Ouch. Had it right when running the example, but copypasted the thing in piecemeal fashion. Sorry.


    I will not "tidy up" sample code before posting.
    I will not "tidy up" sample code before posting.
    I will not "tidy up" sample code before posting.
    ...

  • (cs) in reply to mizhi
    mizhi:
    Throughout this thread, I've noted that they work in a shop that writes software for many platforms.  That was where my gripe about the portability came in.

    Actually, all we got was this:

    Alex Papadimoulis:
    Jeff D works on a team that develops applications on just about any platform under the sun.

    And well, I may be arguing semantics, but “develops applications on just about any platform” to me isn’t the same as “develops applications that run on just about any platform.”

    I guess only Alex could clear this one up.

  • (cs) in reply to Maurits

    Maurits:
    $daysinfebruary =
        $year % 400 == 0 ? 29 : # 1600, 2000, 2400 ...
        $year % 100 == 0 ? 28 : # 1800, 1900, 2100 ...
        $year % 4 == 0 ? 29 : # 2004, 2008, 2012 ...
        28; # 2005, 2006, 2007, ...

    @daysinmonth = (undef, 31, $daysinfebruary, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31);

    Looks like something I wrote in VB once. It was partly research, and I wrote all the functionality for date operations. This had to do with the fact that I needed to code in other calendar systems (Hijri, Maya, Julian, Roman, ...) and those functions were needed anyway.

    Yes, there's idiots writing code for the Maya and Roman calendar systems ... [:D]

  • BogusDude (unregistered) in reply to mizhi
    mizhi:
    mizhi:
    dubwai:

    Where did I argue that Perl was a Perl was meant for scripting and therefore all Perl programs are hacks?



    You didn't.  Someone else did, you just got caught up in the thread. [:)]


    BogusDude was the one who originally said that all Perl programs were hacks.

    I wasn't implying that you made the argument.  (Or at least, wasn't trying to)

    I did call Perl "programs" a hack. And I'll do it again :)

    I used to work for a company that wrote an RPC server (in C++) which would execute Perl scripts as "RPC Calls". This ended up being a bad idea for two reasons.

    1. The perl (5) interpreter takes about 20mb to run. In the RPC server, you needed to have a couple of interpreters to handle multiple simultaneous requests. So, if you had 20 interpreters, you ended up using 400 mb or ram. What also ended up happening is that some of these scripts had to make call to other scripts. That was fine until those scripts had to call back to the original script. Then it was a mess with the number of interpreters rapidly running out.

    2. It was decided to build our whole system on this platform. This meant Perl CGI that called the Perl RPC that called the Perl RPC that called some C++ RPC call somewhere etc. So the system got slow. I don't what they're doing now coz I left the company.

    My point being the following:

    1. Perl is fast
    2. Perl is good
    3. Perl has all the object orientation one could want, although I'm not overly fond of the implementation.
    4. XS files are evil, but sometimes necessary.
    5. Perl is ugly (I've seen good Perl code. It was MUCH better than bad or newbie perl code, but it was still ugly.)
    6. Perl has too many %$ and *& thingies (yes I know I can use English, but that seems even worse) They are not all bad, per se, I just think there are too many of them and the ones that change value depending on how you use them just scare me. And then some people even advocate that as good Perl !!

    I like perl, and for scripts it's still my first choice. I'm very glad to have had the opportunity to learn it. I just think that when it becomes big enough to be considered a program, and not a script anymore, then it's time to consider re-writing it in another language.

    And, yes, I happen to think similar things about Java (but that's just because I'm a C++ bigot, I can't claim any java experience) and nothing at all about #C.

  • (cs) in reply to mdecarle
    mdecarle:

    Yes, there's idiots writing code for the Maya and Roman calendar systems ... [:D]



    OMG what are they going to do about the 23 December 2k12 problem when the calendar wraps around back to 13.0.0.0.0 ????

    Please, just don't get in a plane on that fateful day!
  • jesse (unregistered) in reply to foxyshadis
    foxyshadis:


    $|  $!  $_  $/  $`  $'  $+  $*  $.  $,  $\  $"  $;  $#  $%  $=  $-  $~  $^  $:  $?  $@  $$  $<
    %!
    @+  @-

    And a lot more I'm not going to bother to list. 
    Every one of them has a more verbose version, but perl hackers prefer the meaningless line noise version most of the time.


    Amusingly enough, using the more verbose names for those variables causes a significant performance hit.

    As it says in the BUGS section of the perlvar docs--

    `Due to an unfortunate accident of Perl's implementation, "use English" imposes a considerable performance penalty on all regular expression matches in a program, regardless of whether they occur in the scope of "use English".  For that reason, saying "use English" in libraries is strongly discouraged.'

Leave a comment on “Perly Dates”

Log In or post as a guest

Replying to comment #:

« Return to Article