• asdf (unregistered) in reply to mizhi

    You're trying to bash ME for reading comprehension?  I love how you actually quoted half of my response mentioning Mozilla and the fact that having to do portability doesn't mean every piece of code must be portable, yet you dare to accuse me of not comprehending.  Fool.

  • Suomynona (unregistered) in reply to tufty
    tufty:
    This approach could be taken for pretty much all languages with the exception of those that were written to be obfuscated: ... C++


    So true! One of my favorite examples is BigInteger arithmetic in Java. C++ libraries like GMP obfuscate

    a.multiply(b).add(c.multiply(d));

    to

    a * b + c * d

    Unreadable!

  • Suomynona (unregistered) in reply to BogusDude
    Anonymous:

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


    You mean, like, there was a way to work around the innumerable WTFs in the forum software?

  • (cs) in reply to Suomynona
    Anonymous:
    Anonymous:

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


    You mean, like, there was a way to work around the innumerable WTFs in the forum software?


    You mean there was a problem with the way that the forum software quotes?  Never noticed it myself.

    As to how you quote, there's a neat little button on each post that says 'Quote'.  I'd imagine that'll do the trick.

  • (cs) in reply to Aristotle Pagaltzis
    Aristotle Pagaltzis:

    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.



    Point granted.
  • (cs) in reply to asdf
    Anonymous:
    You're trying to bash ME for reading comprehension?  I love how you actually quoted half of my response mentioning Mozilla and the fact that having to do portability doesn't mean every piece of code must be portable, yet you dare to accuse me of not comprehending.  Fool.


    The part I quoted doesn't have the stuff about mozilla; which I understood just fine, thank you.  The platform specific bits of firefox would only deal with parts that _had_ to be platform specific.  In general, you would want to use functionality that extends across as many platforms as possible and reduce the amount of platform specific code as much as possible, correct?  Since perl has that sort of platform independent functionality available for date/time and this snippet of code seems to be part of a larger program, I maintain that relying on a system dependent executable is bad form in this case.
  • Gabriel (unregistered) in reply to mizhi

    In Perl, there is no "number" or "string": only scalars. If your code tries to treat a scalar as a number, and the scalar contains the representation of a number ("3.2"), then it treats itas a number when you add 1, divide by Pi, etc. If the scalar contains something like "Apple" and you ask it to treat it as a number (e.g., $apple += 1), then it treats the scalar's numeric value as zero.

    Sometimes, this is annoying. shrugs Languages that are not strongly typed usually face similar problems, IIRC. Usually, however, it's transparent, since the code usually Does What You Meant It To.

  • (cs) in reply to Gabriel
    Anonymous:
    If the scalar contains something like "Apple" and you ask it to treat it as a number (e.g., $apple += 1), then it treats the scalar's numeric value as zero.


    $a = 'apple';
    $a++;
    print $a; # prints "applf"
    $a += 1;
    print $a; # prints "1"
  • asdf (unregistered) in reply to mizhi

    How is it exactly that you have magically come to the conclusion that this code snippet is part of one of those pieces that can be cross platform?  If it were part of, say, a homemade logger for cron jobs, well, I see no point in taking the extra step, unless M$ has ripped off that idea as well.  You wouldn't want to make sure every single program you ever wrote was functional across multiple platforms if the program is simply an extension of another program that is rooted in one platform.  Just because you are using a language that can be cross-platform, doesn't mean that all the pieces you are interfacing with are cross-platform.

  • Sam (unregistered) in reply to mizhi

    Okay, I'll respond to your "point".  Simply because they work in a shop that "writes software for many platforms" doesn't mean that<FONT color=#ffa500> </FONT><FONT color=#ff0000>this</FONT> piece had to work on multiple platforms.  

    Though generally, if I worked somewhere where multiple platforms were used, I'd probably try to pay a little attention to portability and I'd prefer to use a module for this rather than trying to roll my own date function.

    As it is, I write all my perl code pretty much just for Windows (my firm's chosen platform).  Most of it does tend to be scripting and not full application programming, but this is more simply because I frequently get asked for things that can be solved without a full suite of applications, not because of any inherent deficiency in perl.

  • (cs) in reply to asdf
    Anonymous:
    How is it exactly that you have magically come to the conclusion that this code snippet is part of one of those pieces that can be cross platform?  If it were part of, say, a homemade logger for cron jobs, well, I see no point in taking the extra step, unless M$ has ripped off that idea as well.  You wouldn't want to make sure every single program you ever wrote was functional across multiple platforms if the program is simply an extension of another program that is rooted in one platform.  Just because you are using a language that can be cross-platform, doesn't mean that all the pieces you are interfacing with are cross-platform.


    In this case, making it work cross-platform would actually be less effort and less confusing.

    I'm tired of arguing this with you.  Since neither of us is going to concede, and I can make better use of my time doing just about anything else, I'm dropping this.
  • (cs) in reply to Rustam

    At what point does "newbie please learn the language" code become WTF code? 

    I, for one, have made many similar mistakes over the years...  sometimes only to be corrected by a someone who said "haven't you ever heard of xyz() function?!?"  For the life of me, I tried to look stuff up, but couldn't find the obvious even tho it was right under my nose.

  • (cs) in reply to jesse
    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.

    That’s because only about a half-dozen of those ever see much use in actual code (and of them, $_ is used by far the most frequently), and thus you quickly memorize them if you write Perl with any regularity. At that point it’s just less convenient but no more to readable to use the long versions.

    jesse:

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

    That is only due to the $`, $', and $& variables, whose use always causes that problem. You are quoting from an old version of the module, though, the section now reads

    This module can provoke sizeable inefficiencies for regular expressions, due to unfortunate implementation details. If performance matters in your application and you don’t need $PREMATCH, $MATCH, or $POSTMATCH, try doing

    use English qw( -no_match_vars );

    It is especially important to do this in modules to avoid penalizing all applications which use them.

  • Alan (unregistered) in reply to rogthefrog

    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>

    We do it, perhaps, because we realize that a language that provides builtins for simple one/twoliners is probably not very well structured. PHP has functions for even very simple things like case insensitive comparisons.

    PHP is for people who google answers for every problem. I imagine that sort of snippets turn up when you type things into google with a query like "php yesterday's date". What you have there is not a good design, because there's a few hardcoded constants. What would you do if you need to get the day after tomorrow or the date of next week? You need to probably come up with the real solution later on anyway. (If PHP had something like strtotime("+1d") then I think that would be pretty good in practice, though.)

    Also, can you trust the PHP designers that they are actually adding 1 day and not 86400 seconds? You know, sometimes you'd skip a day due to the daylight savings time, and sometimes fail to advance...

  • (cs) in reply to Alan
    Anonymous:
    What would you do if you need to get the day after tomorrow or the date of next week? You need to probably come up with the real solution later on *anyway*. (If PHP had something like strtotime("+1d") then I think that would be pretty good in practice, though.)

    You know, I’ve registered my dislike of PHP in this thread, but that criticism is just silly. Did you even check to see what the function really does? Because, you know, that example you gave is part of the documentation almost verbatim. In fact, according to the docs the function accepts anything that a GNU /bin/date will.

  • Suomynona (unregistered) in reply to JThelen
    JThelen:
    You mean there was a problem with the way that the forum software quotes?  Never noticed it myself.

    As to how you quote, there's a neat little button on each post that says 'Quote'.  I'd imagine that'll do the trick.


    Oh, really? Damn, you're so smart.

    I never noticed a problem with that particular feature of the forum software myself, but then, I'm probably still short of a dozen posts, so given all the other WTFs it seems safe to say that other people might have trouble quoting, for example when they are using daylight saving time in a country South of the equator, or when they are trying to post an even number of words on New Year's Eve, or when they use a nickname which contains a prime number, or whatever it takes to trigger one of the countless WTFs in the forum software.

  • Suomynona (unregistered) in reply to tufty
    tufty:
    _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.


    Thanks, YMMD! Perl is faster than Python, but that says just about nothing because Python is sluggish as a creep (no pun intended). The only way to get Perl anywhere towards competitive speeds, is to use XS and pass the real work on to a native C/C++ method. Which is for example what Perl regular expressions do. And for a reason.

    As I don't expect Parrot to be nearly as heavily optimised as any decent JVM, a more interesting approach would be a Perl compiler that targets Java bytecode. I, for one, am looking forward to Jerl.

  • (cs) in reply to Suomynona
    Anonymous:
    JThelen:
    You mean there was a problem with the way that the forum software quotes?  Never noticed it myself.

    As to how you quote, there's a neat little button on each post that says 'Quote'.  I'd imagine that'll do the trick.


    Oh, really? Damn, you're so smart.

    I never noticed a problem with that particular feature of the forum software myself, but then, I'm probably still short of a dozen posts, so given all the other WTFs it seems safe to say that other people might have trouble quoting, for example when they are using daylight saving time in a country South of the equator, or when they are trying to post an even number of words on New Year's Eve, or when they use a nickname which contains a prime number, or whatever it takes to trigger one of the countless WTFs in the forum software.



    I see a lot of bitching and moaning from people who have issues quoting, replying, etc.  None of them seem to preview their posts;  they all seem to be anonymous cowards. 

    As for WTFs in the site itself, I'd say most of them deal with javascript and site navigation.  Things like getting sent to the top of page 2 instead of the last post on page 3 when there's only 2-3 posts on that third page. 

    As to 'all the other WTFs' I haven't encountered a single one that everyone else seems to complain about, from HTML in posts to javascript getting blocked out.  I've seen the javascript one, however;  that's something you'll find universally on any forum.  using the BBcode 'code' tags should fix that problem, but noone seems to do that.  I'd put those WTFs in a PEBKAC column and not having anything to do with the site in particular.
  • (cs) in reply to Suomynona
    Anonymous:
    The only way to get Perl anywhere towards competitive speeds, is to use XS and pass the real work on to a native C/C++ method. Which is for example what Perl regular expressions do. And for a reason.

    Err, are you trying to crunch numbers with Perl? If not, it’s cheaper to throw more CPU at a Perl programmer than to throw more C programmers at the existing CPU. No different from the strategy of dealing with a bunch of JVMs – noone in their right mind will hire C programmers to write core algorithms as JNI extensions, instead it’s memory, memory and more memory.

    As I don't expect Parrot to be nearly as heavily optimised as any decent JVM, a more interesting approach would be a Perl compiler that targets Java bytecode. I, for one, am looking forward to Jerl.

    Err, if you say so. Jerl is highly unlikely to ever happen. Meanwhile, if you don’t know about Parrot, please do yourself a favour and don’t remove doubts by talking about. There are lots of reasons why Parrot is not comparable to the JVM in terms of what determines performance anyway, but FWIW, the stated goal for Perl6 on Parrot is to be at least twice as fast as Perl5 at anything it does.

  • Suomynona (unregistered) in reply to Aristotle Pagaltzis
    Aristotle Pagaltzis:

    Err, are you trying to crunch numbers with Perl? If not, it’s cheaper to throw more CPU at a Perl programmer than to throw more C programmers at the existing CPU.


    This is correct as long as the number of systems on which your software will run is way below 10. By the way, C++, Java, (Object) Pascal, .NET languages are ALL so much faster than perl. And that includes Mono.

    Aristotle Pagaltzis:

    No different from the strategy of dealing with a bunch of JVMs – noone in their right mind will hire C programmers to write core algorithms as JNI extensions, instead it’s memory, memory and more memory.


    Noone in their right mind will use JNI because it's a stinking pile of dog poop.

    Aristotle Pagaltzis:

    Err, if you say so. Jerl is highly unlikely to ever happen.


    Glad to see that your irony meter's still working.

    Aristotle Pagaltzis:

    Meanwhile, if you don’t know about Parrot, please do yourself a favour and don’t remove doubts by talking about. There are lots of reasons why Parrot is not comparable to the JVM in terms of what determines performance anyway, but FWIW, the stated goal for Perl6 on Parrot is to be at least twice as fast as Perl5 at anything it does.


    Now that would make Perl so much more competitive - another 6.5 speed doublings for the "The Computer Language Shootout Benchmark" Ackermann test, and it'll be as fast as C on my machine.* Go, perl, go!

    *) Yes, it's really 181 times slower at the present. I was shocked, too.

  • (cs) in reply to Suomynona
    Anonymous:
    Yes, it's really 181 times slower at the present. I was shocked, too.

    Lies, damn lies, etc. 181× slower at what? Obviously, it’s colder in the night than when I’m outside. C is certainly not 181× faster in terms of development and maintenance time.

    Somehow, writing high-performance web apps as mod_perl modules is much more popular than writing them directly as Apache modules in C. Gee, surprising. LiveJournal pushes a huge amount of data over the wire every day, served from a self-developed clustering solution, all written in Perl. Perl keeps the terrabytes of data at Google and archive.org in shape. Visible or not, there’s still a huge demand for developers; check jobs.perl.org.

    As for the speed of Parrot… we’ll see, won’t we?

  • Thinker (unregistered) in reply to Rick
    Rick:
    I only caught 2 failures. Did Jeff have to step in on the day after February 29th or on January 1st???


    Here is another one: Imagine the script still runs in 2101. :-) More Exact, in 2101 the script will be broken the whole january.
  • Thinker (unregistered) in reply to Thinker
    Anonymous:

    Here is another one: Imagine the script still runs in 2101. :-) More Exact, in 2101 the script will be broken the whole january.


    Sorry, My bad... Missed a $
  • Suomynona (unregistered) in reply to JThelen

    <c>

    JThelen:

    I see a lot of bitching and moaning from people who have issues quoting, replying, etc.  None of them seem to preview their posts;  they all seem to be anonymous cowards.



    Translation: If the WTF only happens to unregistered users, it isn't a WTF.

    Now how's that for a list? And it's growing. Quickly.

    </c>
    1. Though the "CAPTCHA" graphic typically appears in lowercase, I have to enter the word in ALL CAPS, otherwise it'll be rejected. WTF?

    2. The first "CAPTCHA" will always be rejected, I have to enter another before I can preview or post. WTF?

    3. Mere previewing requires entering a captcha. WTF?

    4. The captcha is "forgotten" once you re-edit a post after previewing. Preview 3 times, and you have to enter 3 (rsp. 4, see above) captchas. WTF?

    5. Earlier today, it seems I forgot a closing "code"-tag when previewing. I edited the text, entered such a tag in the correct location, and previewed again. At that time, I saw it appear literally in the preview. I clicked to re-edit, didn't change anything, and just previewed again, and the tag was finally accepted. WTF

    6. Drag an emoticon into the text field, type some text, and it'll appear highlighted as a link. WTF?

    7. At least once, the result looked different than in the preview. WTF?



    JThelen:

    using the BBcode 'code' tags should fix that problem, but noone seems to do that.  I'd put those WTFs in a PEBKAC column and not having anything to do with the site in particular.


    I don't know about the JavaScript WTF, but two wrongs still don't make a right. Maybe next year.

    (Oh, I'm sorry about listing all the captcha-related WTFs. Since I'm an unregistered PEBKAC-Untermensch, I have no right to complain. Real, registered people don't need to enter captchas anyway, so none of these WTFs is actually a WTF.)

  • Suomynona (unregistered) in reply to Aristotle Pagaltzis
    Aristotle Pagaltzis:
    Anonymous:
    Yes, it's really 181 times slower at the present. I was shocked, too.

    Lies, damn lies, etc. 181× slower at what? Obviously, it’s colder in the night than when I’m outside.


    Suomynona:
    "The Computer Language Shootout Benchmark" Ackermann test ... on my machine

    Why don't you try reading comprehension for a change, brickhead? Especially before you call other people liars.

    BTW, the Ackermann benchmark is about testing the speed of plain old integer arithmetic.

    Aristotle Pagaltzis:

    C is certainly not 181× faster in terms of development and maintenance time.


    Which no one actually claimed, anyway. Did you benefit from a special offering for red herrings? Methinks you are wilfully trying to divert the attention from perl5's pathetic run-time performance.

    Aristotle Pagaltzis:

    Somehow, writing high-performance web apps as mod_perl modules is much more popular than writing them directly as Apache modules in C. Gee, surprising. LiveJournal pushes a huge amount of data over the wire every day, served from a self-developed clustering solution, all written in Perl. Perl keeps the terrabytes of data at Google and archive.org in shape. Visible or not, there’s still a huge demand for developers; check jobs.perl.org.

    High-performance apps in mod_perl - now that's funny! Let's rather put it this way: If your application is dominated by I/O (e.g. to/from database or HTTP client), or spends most of its time in C extensions (such as the regex engine), then perl5's interpretation speed, or let's rather say lack thereof, doesn't matter anyway.

    Gentoo Portage is mostly implemented in GNU bash. Does that make bash a high-performance application runtime, too?

    Aristotle Pagaltzis:

    As for the speed of Parrot… we’ll see, won’t we?



    I'm afraid that if the speed doesn't increase at least thirtyfold, we won't see much in terms of competitive run-time performance for general application programming.

  • (cs) in reply to Suomynona
    Anonymous:
    Why don't you try reading comprehension for a change, brickhead? Especially before you call other people liars.

    That was an allusion to the “lies, damn lies, and statistics” bonmot which is generally used to say that statistics can often be interpreted any way you want them to. Maybe I should write in simpler language, you “brickhead.” (Are we going to flame each other now?)

    Methinks you are wilfully trying to divert the attention from perl5's pathetic run-time performance.

    I already said, further up, that Perl5 is not exactly for crunching numbers.

    High-performance apps in mod_perl - now that's funny! Let's rather put it this way: If your application is dominated by I/O (e.g. to/from database or HTTP client), or spends most of its time in C extensions (such as the regex engine), then perl5's interpretation speed, or let's rather say lack thereof, doesn't matter anyway.

    Exactly.

    [:)]

    Gentoo Portage is mostly implemented in GNU bash. Does that make bash a high-performance application runtime, too?

    No, it means the performance of bash is over-adequate for the job it’s used for. Even if bash scored lowest on that computer language shootout. It also makes implementing Portage in C a stupid idea, even if C scores among the top 10 or wherever it is.

    Aristotle Pagaltzis:
    As for the speed of Parrot… we’ll see, won’t we?

    I'm afraid that if the speed doesn't increase at least thirtyfold, we won't see much in terms of competitive run-time performance for general application programming.

    Really? That’s interesting. Somehow I doubt we’ll see glorified assemblers like C displaced from numbercrunching jobs anytime soon, and I doubt we’ll see “slow” languages like Perl displaced from any other job.

    That some shootout says “this language is faster than the other at some arbitrary task” makes very little difference at anything.

Leave a comment on “Perly Dates”

Log In or post as a guest

Replying to comment #:

« Return to Article