How not to spend your hours





  • As posted by Admin. Awesome.



  •  One day he'll look back at this and laugh. We, on the other hand, can start now... hehehehehehe



  • From the comments on the site:

     

    @Admin said:

    Thanks for all the comments.

    I like your ideas and i will definitely use them

     

    ALL AT ONCE.

     



  • $Minutes = $Minutes .“0″;

    so 4 minutes would become 00:40

    That's the only actual bug that I see, aside from it being bloatware.   

    // this should print 3:40

    What you're not sure?  did you actually test your code?



  • You know you're in good territory when a simple mathematical function requires use of explode. 



  • @bstorer said:

    You know you're in good territory when a simple mathematical function requires use of explode. 

    This made my day.  I want a t-shirt with that printed on it.  You, sir, win array_sum(explode(' ', str_repeat('1000 ', 1000))) Internets!



  • Any time someone introduces "a code", especially "a PHP code", you know it's going to be worth reading.



  • @belgariontheking said:

    That's the only actual bug that I see, aside from it being bloatware.   
     

    The first comment on that post is even better for bloatware, obviously written by someone who's never ever heard of sprintf():

    return str_repeat(’0′, 2 - strlen($hours)) . $hours . ‘:’ . str_repeat(’0′, 2 - strlen($minutes)) . $minutes;

    I really wonder what it is about PHP posts that makes people show off how bad their coding skills are by filling the comments section with useless blather. Especially useless blather of the "reimplementing the wheel by using square rocks" type. Must be something about the "PHP is so easy, even a braindead rotten paramecium can do it!" mentality. Everyone has to show off their latest/greatest "ooooh shiny!" construction.




  • @MarcB said:

    The first comment on that post is even better for bloatware, obviously written by someone who's never ever heard of sprintf():

    return str_repeat(’0′, 2 - strlen($hours)) . $hours . ‘:’ . str_repeat(’0′, 2 - strlen($minutes)) . $minutes;

    I really wonder what it is about PHP posts that makes people show off how bad their coding skills are by filling the comments section with useless blather. Especially useless blather of the "reimplementing the wheel by using square rocks" type. Must be something about the "PHP is so easy, even a braindead rotten paramecium can do it!" mentality. Everyone has to show off their latest/greatest "ooooh shiny!" construction.

     

    Wait... so PHP == Java now?

    *ducks*



  • @MasterPlanSoftware said:

    @MarcB said:

    The first comment on that post is even better for bloatware, obviously written by someone who's never ever heard of sprintf():

    return str_repeat(’0′, 2 - strlen($hours)) . $hours . ‘:’ . str_repeat(’0′, 2 - strlen($minutes)) . $minutes;

    I really wonder what it is about PHP posts that makes people show off how bad their coding skills are by filling the comments section with useless blather. Especially useless blather of the "reimplementing the wheel by using square rocks" type. Must be something about the "PHP is so easy, even a braindead rotten paramecium can do it!" mentality. Everyone has to show off their latest/greatest "ooooh shiny!" construction.

     

    Wait... so PHP == insert language of choice to bash now?

    *ducks*

    Yes, I can see its similarity to VB.  

    Java and PHP and COBOL (yes) being my languages of choice, I would not argue that there are many yahoos out there creating things like this in my favorite languages.



  • @MarcB said:

    I really wonder what it is about PHP posts that makes people show off how bad their coding skills are by filling the comments section with useless blather. Especially useless blather of the "reimplementing the wheel by using square rocks" type. Must be something about the "PHP is so easy, even a braindead rotten paramecium can do it!" mentality. Everyone has to show off their latest/greatest "ooooh shiny!" construction.

    As a PHP developer it is because I honestly believe 99% of PHP devs are complete retards.  It's the VB of Web 2.0.  It's fairly easy to grasp, has good online documentation, is installed on almost any shared host and has lots of free tools, plugins and libraries.  That means it attracts the lowest common developer.  There are so many code samples available for free that you can copy-and-paste your way to a buggy, slow web app in a matter of hours.

     

    I think the language itself is pretty strong, though.  It's fast and has a pretty clean syntax.  It has tons of good extensions, is great at string manipulation and has primitve vectors/hashes.  I think of it as perl without the cruft and obfuscation.  It has an object model similar to Java's but with bits of Python-esque dynamism.  PHP 6 is shaping up to be a trainwreck, though.  We get goto statements (yes, goto) and namespaces (how the fuck is that gonna work?) but still no 64-bit ints.  Fantastic.



  • @morbiuswilters said:

    I think the language itself is pretty strong, though.  It's fast and has a pretty clean syntax.
     

    I've got lots of quibbles with PHP, but mostly to do with the core design of the language - not the functionality it provides, but how it's provided. Especially the total lack of cohesiveness in function naming: is_array (note the _), isset (note the lack of _), gettype, etc... The error reporting needs a lot of work too. I If you have an unbalanced bracket/brace, PHP will happily run to the end of the file and tell you that you've reached a premature EOF. Perl's much more intelligent and can backtrack and suggest a possible location for the start of the unbalancing.

    Then there's the outright moronic stupidity the
    language had in earlier revisions - I'm looking at YOU,
    register_globals and magic_quotes_gpc(). At least register_globals
    defaults to off now, and I hope like hell will be sliced out of the
    language with a rusty scapel and buried face down in a cask of holy
    water.

    Also, there's the variable scoping business. Is there any other in-use language out there that doesn't automatically variables from a higher scope visible in the current scope? I can't really see the reason for this, unless it's some kind of bad outgrowth of register_globals, keeping those auto-globals from stomping on in-function vars.

    @morbiuswilters said:
    I think of it as perl without the cruft and obfuscation.

    Not to get into a War of the Most Holy Language, but I think Perl's got at least major thing going for it that PHP should have implemented from the get-go: seperate name spaces for arrays, hashes, and scalars.

    'course, I haven't tried version 6 yet. The last time I did anything of consequence in Perl was back in the 5.005 or so days.

    @morbiuswilters said:

    PHP 6 is shaping up to be a trainwreck, though.

    I've deliberately avoided looking at any of the PHP6
    wishlists/roadmaps, because I'm sure there's enough idiocy out there
    that the best of the list will get thrown out, and the stupidest ideas promoted
    as the greatest thing since sliced bread.

    @morbiuswilters said:

    We get goto statements (yes, goto)

    Excellent. Maybe Swampie will be able to convert SSDS to PHP so it can pretend to be a web app and finally be entered into that Mashup. If a language doesn't support GOTO, it's not a real language, you see. And scary as it sounds (brown-trousers moment... oy), SSDS is by far better quality code than some of the example comments you see in the PHP docs pages.

    @morbiuswilters said:

    namespaces (how the fuck is that gonna work?)

    I'll guess the namespaces will be a sort of pseudo-object notation. $namespace::variable != $othernamespace::variable



  • @MarcB said:

    Especially the total lack of cohesiveness in function naming: is_array (note the _), isset (note the lack of _), gettype, etc...

    Agreed.  There are also too many "convenience" functions that do nothing useful, pollute the namespace and bloat the executable.

     

    @MarcB said:

    I If you have an unbalanced bracket/brace, PHP will happily run to the end of the file and tell you that you've reached a premature EOF.

    That's pretty silly.  PHP will catch almost any unbalanced bracket, brace or parens because there is sure to be an invalid bit of syntax on one of the next few lines.  Also, most IDEs will find that type of thing for you.  I use vim and even it shows me when I'm missing a delimiter.

     

    @MarcB said:

    Then there's the outright moronic stupidity the
    language had in earlier revisions - I'm looking at YOU,
    register_globals and magic_quotes_gpc().

    Yeah, that was just unbelievable.  You have to wonder what the hell the PHP devs were thinking..

     

    @MarcB said:

    Also, there's the variable scoping business. Is there any other in-use language out there that doesn't automatically variables from a higher scope visible in the current scope? I can't really see the reason for this, unless it's some kind of bad outgrowth of register_globals, keeping those auto-globals from stomping on in-function vars.

    This is actually one of the things I love about PHP.  Variable scoping is extremely clear and you don't have to go tromping through dozens of files to see where a variable is changed.  It makes using global variables a lot cleaner and less error-prone, so long as you actually use it right.  Obviously, that easiness has the side effect of rampant global variable abuse by idiots..

     

    @MarcB said:

    Not to get into a War of the Most Holy Language, but I think Perl's got at least major thing going for it that PHP should have implemented from the get-go: seperate name spaces for arrays, hashes, and scalars.

    Wow, I almost mentioned that as one of my favorite PHP features but was too lazy to try to fit it in.  I guess it's a case of different strokes for different folks, but I like that variable access is always done the same way.

     

    @MarcB said:

    I've deliberately avoided looking at any of the PHP6
    wishlists/roadmaps, because I'm sure there's enough idiocy out there
    that the best of the list will get thrown out, and the stupidest ideas promoted
    as the greatest thing since sliced bread.

    I've been following it for a two years and you're basically right on the mark. 64-bit ints are "not the PHP way" but gotos are.  Great.

     

    @MarcB said:

    If a language doesn't support GOTO, it's not a real language, you see.

    Sadly, this was pretty much the rationale used by the core developers.  They admitted goto is awful, has no place in a procedural scripting language and will likely be abused.  However, they are including it for "completeness".

     

    @MarcB said:

    I'll guess the namespaces will be a sort of pseudo-object notation. $namespace::variable != $othernamespace::variable

    That's basically it, but they have to introduce a new bit of syntax to handle it since they've already used the double-semicolon for statics.  I see a real mess with this, though, because PHP has such flexible scoping rules.  You include an external file and now it's in your scope, whatever that scope is.  If the namespaces are to prevent function/class name collisions, this will really complicate things.  They will probably work their way out of it somehow, but it just feels like another useless feature.  I've never had a problem with name collisions and if I did it would take a simple script to find-and-replace the offending names with unique ones.



  • Syntax-wise, I think the perfect language is somewhere between Perl and PHP. Perl could stand to lose some of the weird functions and stuff that looks Linux-specific, and I'm not sure if arrays and hashes really need to be separate data types, but I like its variable scoping much better than PHP's. PHP, however, actually has a sane way of taking parameters in a function. They both have a lot of strange workarounds that have built up over the years.

    @MarcB said:

    @morbiuswilters said:

    We get goto statements (yes, goto)

    Excellent. Maybe Swampie will be able to convert SSDS to PHP so it can pretend to be a web app and finally be entered into that Mashup. If a language doesn't support GOTO, it's not a real language, you see. And scary as it sounds (brown-trousers moment... oy), SSDS is by far better quality code than some of the example comments you see in the PHP docs pages.

    I just had to go check and make sure there was no Inline::VisualBasic module.



  • @MarcB said:

    Also, there's the variable scoping business. Is there any other in-use language out there that doesn't automatically variables from a higher scope visible in the current scope?

    Even more confusingly, it automatically brings variables from a lower scope (e.g., vars declared inside "if" statements) into the higher, something I haven't seen any other languages do.

    Anybody have thoughts on this?



  • @morbiuswilters said:

    That's pretty silly.  PHP will catch almost any unbalanced bracket,
    brace or parens because there is sure to be an invalid bit of syntax on
    one of the next few lines.

    I'm not saying it doesn't catch it - it does, it just spews out totally useless diagnostic information in the error report. For instance, on the 400+ line script I'm noodling around on for work, I stuck an unbalanced "if (TRUE) {" at line 85 and PHP's diagnostic output is: 

    PHP Parse error:  syntax error, unexpected $end in scriptname.php on line 402 

    (this is PHP 5.1.6). 

    From the "unexpected $end" you can infer there's an unbalanced bracket somewhere, but all you can do is hop back into vi and bounce around with % until you find one where you bounce into a brick wall. I can't recall Perl's exact syntax, but it would say something like "Unbalanced {, possibly around line 80". It may not always have been right about the line number, but at least it explicitly tells you it's an unbalanced bracket.

    The exact same thing happens if you forget to close a heredoc (or have
    a typo in the opening/closing delimeter) or a string. On the plus side, any decent
    syntax highlighter will show you exactly where things blew up because
    of the unterminated heredoc/string - just look for where the expected rainbow goes wonky.

    @boolean said:

    Even more confusingly, it automatically brings variables from a lower scope (e.g., vars declared inside "if" statements) into the higher, something I haven't seen any other languages do.
     

    I refuse to dig into the PHP guts, but I'll postulate that this is due to PHP's scoping not being granular enough. Perl et-al will treat an if() or switch() block as its own little closure/subroutine, with its own scope (ignoring how vars were declared, as my() or local()). PHP's scoping begins/ends with function() and therefore everything within a function is within the same scope, except for nested functions, which again have their own scope.

    A thought: Imagine PHP's scoping as granular as other languages. Do you think having to declare globals would last very long if you had to declare them every time you enter an if/switch block?

    $x = 'blah';
    if ($x == 'blah') {
        global $x;
        do_something($x);
    }

    .... scary. 



  • @boolean said:

    Even more confusingly, it automatically brings variables from a lower scope (e.g., vars declared inside "if" statements) into the higher, something I haven't seen any other languages do.

    Anybody have thoughts on this?

    I don't think it's that confusing, just a little different.  In PHP, there is no lower scope in blocks -- any encountered variables are automatically added to the executing scope.  Any function or class declarations are automatically global as soon as their declaration is encountered in execution.

     

    function func1($bool) {

        if ($bool) {

            function func2() { echo("wheee!\n"); }

        } 

    }

     

    func1($bool);

    func2();

    func1($bool); 

     

    In this example, if $bool is false func2() will not exist and  the program will fatal on the call to func2().  If $bool is true, func2() will exist in the global scope and the string will be printed but it will fatal on the second call to func1() because it tries to redeclare func2().  This can lead to some pretty sloppy code, but it's all a matter of discipline -- you can write garbage in any language.  You just don't define functions inside other functions and you don't provide alternate definitions for functions.  One neat trick with this is that you can check to see if a function that was added in a later version of PHP exists and if not, provide your own implentation.  This is useful when writing libraries that need maximum compatibility.

     

    I like the fact that PHP makes you explicitly reference variables by scope.  There is no ambiguity that $GLOBALS['foo'] is global, $_GET[' foo'] is from the query string, $this->foo is an instance member, self::$foo is a static class member and $foo is a local variable.  I find that it keeps things very clear and readable, but to each his own.



  • @MarcB said:

    I'm not saying it doesn't catch it - it does, it just spews out totally useless diagnostic information in the error report.

    I know what it does.  Normally I don't run into this because I'm writing classes and the open brackets are caught closer to the source instead of at the end of the file.  It is a tad annoying, though, but the only way to know where the problem is is to assume a standard formatting.  Most IDEs will flag stuff like this.  Since you are using vim, you can always use auto-format to quickly locate the unbalanced bracket.  Just highlight the entire section and hit '='.  It will reformat the code block.  Then you can just scan down your code and look for sections improperly contained within a block.  It should be pretty apparent when you have half your function contained within a while loop that was only supposed to be 3 lines that that is the source of the problem.  Just 'u' to undo the auto-format and correct the problem.  It's not the most elegant solution, but if you're pretty good with PHP and vim it shouldn't take much time or effort and it's a lot better than iterating over every bracket in the file with '%'.  I've had to work on lots of garbage legacy code written by braindead morons who couldn't be bothered to even indent correctly and this trick has saved me tons of time tracking down bugs. 



  • @morbiuswilters said:

    Just highlight the entire section and hit '='.
     

    Ah, if only I could. All my development is done on a remote server via ssh shells only. No vnc, no remote X, etc... Editing locally and then uploading takes far too long, especially when I'm doing layout tweaks. 2 seconds in vim on the remote server to change a css style parameter or whatever, v.s. 15+ to change locally + upload. It adds up quickly.

    I've never resorted to the vim formatting options. There's been a few places where I had to format stuff crazily due  to code demands, but 99.99% of the time, everything's properly indented and auto-formatting would probably undo something I use as my normal style anyways.



  • @MarcB said:

    From the "unexpected $end" you can infer there's an unbalanced bracket somewhere

    Don't assume too much. The first time I got that message I went looking for what the hell this special variable $end was and how it got in my code. And if you're mocking PHP errors, [url=http://www.webmasterworld.com/forum88/5127.htm]you can't forget this one[/url].



  • @MarcB said:

    Ah, if only I could. All my development is done on a remote server via ssh shells only. No vnc, no remote X, etc...

    What does that have to do with anything?  I do all of my editing in local terminals, the command should still work if you are using vim.  And a GUI on a UNIX server?  Blech..

     

    @MarcB said:

    I've never resorted to the vim formatting options. There's been a few places where I had to format stuff crazily due  to code demands, but 99.99% of the time, everything's properly indented and auto-formatting would probably undo something I use as my normal style anyways.

    I'm not saying you use vim to format your code, just use the feature to locate the bug.  Below is a very simple example. 

     if ($cond1) {

        while ($cond2) {

        if ($cond3) {

        }

    }

     

    Now, obviously you can see the error in that because it's such a simple example.  Using vim to auto-format the code block will result in the following.

     if ($cond1) {

        while ($cond2) {

            if ($cond3) {

             }

       }

     

    Now as you skim through the code the error should be much more visible.  Obviously everything after the while loop wasn't supposed to be in the while loop.  This is usually much easier to notice with a larger block of code because some condition or loop will contain every part of the function after it.  Now just hit 'u' to undo the auto-format.  Your code will revert and you can go in and add the bracket at the appropriate place.  There is no reason this shouldn't work in a local vim, a remove vim or gvim.  It's not perfect but it's a pretty quick way to locate the error.  Most graphical IDEs provide better support for catching formatting bugs, but I prefer vim personally.  Since this is ultimately a formatting issue (the parser has no way of knowing you didn't mean for all of that code to be in the while loop), I think it's better handled by developer tools and not the runtime parser.  Just my $0.02.



  • @MarcB said:

    @morbiuswilters said:

    Just highlight the entire section and hit '='.
     

    Ah, if only I could. All my development is done on a remote server via ssh shells only. No vnc, no remote X, etc...

    Have you not heard of v and V (visual and line visual mode)? Also, if your terminal emulator has been set up correctly for Xterm mode, right mouse button is a shortcut for visual mode.

    :help visual, it will save you so much time.



  • @Cap'n Steve said:

    PHP, however, actually has a sane way of taking parameters in a function.
    Yes, Perl was my friend until the day I tried to make a function in Perl.

    @boolean said:

    Even more confusingly, it automatically brings variables from a lower scope (e.g., vars declared inside "if" statements) into the higher, something I haven't seen any other languages do.
    Yes this annoys me to no end.  I think the only way a variable can be out of scope in PHP is within a function call.



  • @MarcB said:

    @morbiuswilters said:

    Just highlight the entire section and hit '='.
     

    Ah, if only I could. All my development is done on a remote server via ssh shells only. No vnc, no remote X, etc... Editing locally and then uploading takes far too long, especially when I'm doing layout tweaks. 2 seconds in vim on the remote server to change a css style parameter or whatever, v.s. 15+ to change locally + upload. It adds up quickly.

    I've never resorted to the vim formatting options. There's been a few places where I had to format stuff crazily due  to code demands, but 99.99% of the time, everything's properly indented and auto-formatting would probably undo something I use as my normal style anyways.

    Get an editor that supports SFTP.  Then you can edit files on any server you have SSH access to.  The download/edit/upload process is then handled for you, transparently.  Takes under a second.   I get so much more done in a WYSIWYG editor, that the 500 ms SSH handshake on every save is well worth it.

     Personally, I use JEdit 'cause it has a decent SFTP plugin, and functions more or less identically in OS X and Windows.



  • @MarcB said:

    Is there any other in-use language out there that doesn't automatically
    variables from a higher scope visible in the current scope?

    I suppose I'm beating a dead horse here, but Tcl doesn't do that. I'm not sure about the "in-use" part, though.



  • @morbiuswilters said:

    I think the language itself is pretty strong, though.  It's fast and has a pretty clean syntax.  It has tons of good extensions, is great at string manipulation and has primitve vectors/hashes.  I think of it as perl without the cruft and obfuscation. 
     

    Funny, I think of Perl as "The fast and pretty PHP, with standardized calling conventions, native regexp support, and without redundant library functions, bloat, and nasty quote escape needs". 

        -dZ. 



  • 22:26:28 < SpComb> "I think the language itself is pretty strong, though.  It's fast and has a pretty clean syntax.  It has tons of good extensions, is great at string manipulation and has primitve vectors/hashes. It has an object model similar to Java's but with bits of Python-esque dynamism"
    22:28:27 <&Japsu> :o
    22:28:33 <&Japsu> SpComb: mikä kieli? :o
    22:28:41 < SpComb> arvaa oikein ja voita hymiö
    22:28:46 <&Japsu> ;hmm
    22:28:50 <&Japsu> Ruby?
    22:28:56 < SpComb> ei
    22:28:58 <&Japsu> :<
    22:29:06 < SpComb> falettaa ainakin ton "fast" kriteerin
    22:29:09 <&Japsu> C#?
    22:29:13 < SpComb> nein
    22:29:32 <&Japsu> perl?
    22:29:45 < SpComb> eip
    22:29:48 <&Japsu> örrör
    22:30:04 <&Japsu> Object Pascal?
    22:30:07 < SpComb> False
    22:30:13 <&Japsu> JavaScript?
    22:30:15 < SpComb> njet
    22:31:09 <&Japsu> Groovy? Boo? Scala?
    22:31:14 < SpComb> !true
    22:31:29 <&Japsu> loppuu kohta kielet kesken
    22:31:36 <&Japsu> Visual Basic?
    22:31:37 <&Japsu> :D
    22:31:43 < SpComb> hah, ei sentään
    22:32:23 < SpComb> voin paljastaa vielä yhden lauseen jonka karsin tosta sitaatista pois
    22:32:28 < SpComb> "I think of it as perl without the cruft and obfuscation"
    22:33:19 <&Japsu> ;hmm
    22:33:27 < SpComb> pelottaako jo?
    22:33:31 <&Japsu> eijeijeijei
    22:33:32 <&Japsu> eiiii
    22:33:35 <&Japsu> VADE RETRO SATANA
    22:33:37 <&Japsu> php?
    22:33:43 < SpComb> kyllä
    22:33:46 <&Japsu> UAAAARGH



  •  Man, I thought I was on an english language forum.  Turns out that everyone's been speaking finnish but it looked enough like english that it was entertaining to me.



  • @DZ-Jay said:

    Funny, I think of Perl as "The fast and pretty PHP, with standardized calling conventions, native regexp support, and without redundant library functions, bloat, and nasty quote escape needs". 

    Yeah, perl is fast as well, but I never claimed that it wasn't as fast as PHP.  Pretty?  Well, beauty is subjective, but a lot of people would disagree with you.  If it works for you, cool.  The native regexp support is cool, but it's not like using PCRE in PHP is dramatically different.  The redundant and useless library functions suck, as I mentioned.  I tend to strip unused functions from the runtime to cut down on executable size.  I wouldn't say PHP is otherwise terribly bloated, though.  PHP 6 looks like it will add a few more useless features, but it's also going to come out before perl 6.  What nasty quote escape needs are you referring to?  PHP has a bad history of trying to protect coders from their own stupidity, but they have long since depracated most of that functionality and any decent developer avoids it.  Otherwise, it's pretty similar to perl in that respect, unless you are referring to something specific I am unaware of.

     

    Oh, and obviously the 'P' in PCRE refers to perl.  The 'P' in LAMP refers to PHP and always has.  It has somewhat grown to encompass perl and python, but that's not what it started as.

     

    Edit: One thing I forgot to mention is that perl 5 is a lot more stable in long-term scenarios than PHP.  Most PHP scripts can't seem to run more than a month without getting stuck on some syscall or developing a slow memory leak that takes them down, whereas perl is pretty rock solid.  There are pretty easy ways to work around this in PHP, but it does kind of bite. 



  • @morbiuswilters said:

    I wouldn't say PHP is otherwise terribly bloated, though.  PHP 6 looks like it will add a few more useless features, but it's also going to come out before perl 6. 
     

    PHP 37 will probably come out before Perl 6.  Hell, Duke Nukem Forever will come out before Perl 6. 



  • @bstorer said:

    PHP 37 will probably come out before Perl 6.

    PHP 37: Now with pointers and inline assembly!

     

    @bstorer said:

    Hell, Duke Nukem Forever will come out before probably be written in Perl 6.

    FTFY.

     

    Perl 6 is the perfect example of "second system syndrome".  Perl 5 is a great language, although I find a few of its conventions annoying or useless.  The problem is that perl 5 started getting long in the tooth and lacked some useful features from new languages.  Larry Wall then went crazy and stuffed every conceivable feature into the language spec.  Many of them are interesting, but I think the perl developers have made a big mistake by both starting from scratch with the runtime and by focusing on speccing out the "perfect" language instead of integrating the new features in steps and responding to feedback from people who actually have to use perl to develop.  It makes me sad because increasingly I don't touch perl because I can do most things I need to in PHP (and the things I can't aren't really feasible in perl either -- I need to use C), I use PHP so much that I can develop much more quickly with it and I can draw on my massive existing PHP codebase.  Perl 5 is still a great language, but I would almost always choose PHP for new development at this point.  I maintain a few legacy apps written in perl and it's still great for constructing system image build scripts because it's already needed for any Linux compilation and it's far more expressive than BASH.



  • @morbiuswilters said:

    Larry Wall then went crazy and stuffed every conceivable feature into the language spec.
     

    Seriously.  It's like some said, "Sure, the static types, revamped sigils that'll completely invalidate Perl 5 code, and macros seem like a lot, but let's create a brand-fucking-new virtual machine to run it all on!" 



  • The new VM wasn't as batshit insane then as it seems now.  There was talk back then by the Zend folks about replacing the Zend Engine with Parrot when it became mature enough.  Honestly, that would have been awesome to see, because what I really want is the goodness of perl with the virtual-hosting-friendlyness of mod_php.

    Unfortunately the chances of this happening nowadays are about nil, which makes me sad.   



  • @Charles Capps said:

    The new VM wasn't as batshit insane then as it seems now.

    I think the main thing is that they bit off more than they could chew.  A lot of people saw that this was doomed to vaporware status from the beginning.  I think they would have done better to make incremental improvements.

     

    @Charles Capps said:

    There was talk back then by the Zend folks about replacing the Zend Engine with Parrot when it became mature enough.

    Hmm.. never heard this before.  Also, you probably mean the PHP folks because Zend has a stake in sticking with their VM as they make money from providing add-ons and tools for it.



  • @morbiuswilters said:

    Hmm.. never heard this before.  Also, you probably mean the PHP folks because Zend has a stake in sticking with their VM as they make money from providing add-ons and tools for it.
     

    You'd think.  [url=http://www.technetra.com/writings/archive/2004/01/09/interview-rasmus-lerdorf]Rasmus expressed interest in 2004 though[/url] - see heading "What about PHP 6?"  Then again, he works for Yahoo instead of Zend.



  • @Charles Capps said:

    You'd think.  Rasmus expressed interest in 2004 though - see heading "What about PHP 6?"  Then again, he works for Yahoo instead of Zend.

    Ahh, yeah, Rasmus is PHP, not Zend.  He also does APC which is an open source alternative to Zend's extremely expensive opcode cache.  It will be included by default in PHP 6 (one of the only useful features) which will significantly cut into Zend's profits. 



  • @boolean said:

    Even more confusingly, it automatically brings variables from a lower scope (e.g., vars declared inside "if" statements) into the higher, something I haven't seen any other languages do.
     

     

    You haven't been programming in ColdFusion :) ...

    All variables are global there, unless you specifically declare them as scope locals ...

    I had problems wih recursive functions before I figured this one out ...

    For example : 

    <cffunction name="xxx" access="public" returntype="void" output="false">

        <cfset somevar = "test"> 

        <cfset yyy()>  

    <cffunction> 

     

    <cffunction name="yyy" access="public" returntype="void" output="false">

        <cfoutput>#somevar#</cfoutput><!--- this prints "test" --->

    <cffunction>

     



  • @morbiuswilters said:

    @Charles Capps said:

    The new VM wasn't as batshit insane then as it seems now.

    I think the main thing is that they bit off more than they could chew.  A lot of people saw that this was doomed to vaporware status from the beginning.  I think they would have done better to make incremental improvements.

    It seems like everybody considers it vaporware except the Perl 6 community, and, strangely, a lot of the Ruby world.  Why the Ruby people are so intrigued, I don't know.  They freaking moved to YARV.  Are they planning each release to have a different damned VM? 

    @Charles Capps said:
    There was talk back then by the Zend folks about replacing the Zend Engine with Parrot when it became mature enough.

    Hmm.. never heard this before.  Also, you probably mean the PHP folks because Zend has a stake in sticking with their VM as they make money from providing add-ons and tools for it.

    Interesting, didn't hear about that one, either.  I've heard a lot of talk about moving Python to Parrot, but most of that talk is from the Parrot side.  Is it because they see the writing on the wall that Perl's heyday is over?  I say yes.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.