SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 72 of 72
  1. #51
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I know almost nothing about language internals, but there is something blindingly obvious here...
    Quote Originally Posted by Etnu
    The examples where this fails is in situations where you're returning a reference to something which is potentially a non-variable (e.g. a reference to the number 4, or 0 as is the more common case...). How do you handle a reference to a number? Should I be allowed to set the literal 4 to some other value? Of course not.
    One never could do something like:
    PHP Code:
    <?php

    class Thing {
        function &
    getWhatever() {
            return 
    4;
        }
    }

    ?>
    But the presence of the word 'new'...
    PHP Code:
    <?php

    class Whatever {}

    class 
    Thing {
        function &
    getAThing() {
            return new 
    Whatever;
        }
    }

    ?>
    ought to indicate that the returned variable is something to which a reference can be made. Forget the ideology... Why shouldn't PHP afford us this convenience?
    Zealotry is contingent upon 100 posts and addiction 200?

  2. #52
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    This is the core of the disagreement. By which standards do you assert "well-written" ?
    Standards brought about by years of experience and observation on what makes buggy code. Even without a memory leak, the examples cited previously can easily result in other bugs. What happens with my theoretical 'return 4' script, reference counting issues aside? PHP is a dynamically typed language, not a typeless language. There's a world of difference between a constant numeric value and a variable.

    In php4, any object will be implicitly cloned if you pass it by value. You can't seriously mean that is acceptable ?
    That's why you pass the *variables* by reference. The part that i'd deem unacceptable was the fact that php ever did things in such a silly manner anyway, and I'm firmly of the opinion that php4 was not very suitable for OOP in the first place -- but I digress. Something like:

    function &GetHandle()
    {
    return new Thing();
    }

    is typically only done for the sake of improved readability -- that is to say, just calling $blah = GetHandle() instead of $blah = new Thing(). the more like scenerio is something like this:

    PHP Code:
    function &GetHandle()
    {
       if(!
    $this->Handle)
       {
           
    $this->Handle =& new Thing();
       }
       return 
    $this->Handle;

    Which works on both php4 and php5 without issue.

    ought to indicate that the returned variable is something to which a reference can be made. Forget the ideology... Why shouldn't PHP afford us this convenience?
    It comes back to performance and avoiding bugs going forward. The only true instance that new Whatever() could fail would be in the case that the object couldn't be instantiated (failure to allocate memory, object doesn't exist, etc.), but that would throw a fatal error anyway (hence, it's a non-issue), and on that point I totally agree. The problem is that you'd have to write 2 different paths for returning values from a function call to accomodate this.

    Doing this would penalize the entire user base -- namely the 90%+ of PHP users who don't significantly use OOP anyway. This gentle nudge is a way to tell developers that they should go and start upgrading their packages before the next rollout.

    I will conceed that it's bad form to do this in a minor version, though, without a more significant warning. Many people upgraded to 4.4 to fix the XML RPC vulnerabilities, and a few of them may be getting notices now because of it (of course, if you have notices turned on on production web servers, that's another problem altogether...).

  3. #53
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    I don't want to pursue you, but you keep being so snotty to everyone whilst getting everything wrong. You make it hard to stop typing.

    Quote Originally Posted by Etnu
    What happens with my theoretical 'return 4' script, reference counting issues aside?
    At that time I would expect an error, but only for this case. For reasons already explained, this case is trivial to detect. So why do we have to add dummy variables all over the place, even though "good" developers will have used references correctly? After all you can return an integer in PHP5 or an object reference.

    Quote Originally Posted by Etnu
    is typically only done for the sake of improved readability -- that is to say, just calling $blah = GetHandle() instead of $blah = new Thing().
    Er...no . A factory adds a flex point for construction. This is one of the most basic of all OO patterns and I am surprised that you missed it in your "years of experience and observation on what makes buggy code".

    As an aside your supposedly more realistic example can cause problems. The automatic behind the scenes instantiation is fine if you need the lazy instantiation, because of a performance issue that you feel is worth the price. It could be dodgy practice to use it routinely...
    PHP Code:
    class UnnecessaryLazyLoader {
        private 
    $thing;

        function 
    doSomethingInvolvingThing() {
            
    $this->thing $this->getThing();
            ...
        }

        function 
    getThing() {
            
    $this->thing = ($this->_thing $this->thing : new Thing());
            return 
    $this->thing;
        }

    What happens if Thing throws an exception in it's constructor in PHP5, or sets some error state in PHP4? It means that doSomethingInvolvingThing() needs a try block or a load of error handling code on every usage. Also it will repeatedly instantiate on an exception every time it is called (the setting of the variable will have been skipped). This kind of stuff is better handled in the constructor of UnnecessaryLazyLoader. You shouldn't have half constructed objects that need to be finished off.

    There is an OO principle called "construction is initialisation" and another called the "Samurai principle". These two together can remove a lot of internal state and it's inevitable cognitive load.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  4. #54
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    The problem is that you'd have to write 2 different paths for returning values from a function call to accomodate this.

    Doing this would penalize the entire user base -- namely the 90%+ of PHP users who don't significantly use OOP anyway. This gentle nudge is a way to tell developers that they should go and start upgrading their packages before the next rollout.
    No matter how often you assert it, no-one would be "penalised". It's kind of insulting to be told we've been writing bad code and it's our responsibility to fix it. The goalposts have been moved; we've a right to be annoyed.

    If you were unit testing you'd realise that a lot of OOP code is filled with factory methods which do nothing more than return an object. I'd be more inclined to dump php, on principle, rather than edit my code. If the developers are going to spring surprises like this I don't have a reliable base to build on.

    What happens if a significant part of the 10% decide to abandon php as a mickey-mouse language? It's bad for php if talented programmers bail out. There'd be no-one around to show it off at its best and no-one to offer encouragement or advice to those amongst the 90% who want to raise their game.

  5. #55
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    If you don't care to know about the language's internals, you shouldn't be using the language.
    Going back to this statement, I think it's the central point of disagreement. Although I respect your opinion, I think that a programming language should be designed so that programmers don't need to know about the internals. Or, failing that, we should need to know as little as possible about them. That makes us more productive since it frees time to learn other things instead, such as the subject of this forum: application design.

    Edit: in fact, this is one of the big improvements PHP 5 brings. Since the way object references work is more intuitive, there is less need to understand their internal workings.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  6. #56
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    No matter how often you assert it, no-one would be "penalised". It's kind of insulting to be told we've been writing bad code and it's our responsibility to fix it. The goalposts have been moved; we've a right to be annoyed.

    If you were unit testing you'd realise that a lot of OOP code is filled with factory methods which do nothing more than return an object. I'd be more inclined to dump php, on principle, rather than edit my code. If the developers are going to spring surprises like this I don't have a reliable base to build on.

    What happens if a significant part of the 10% decide to abandon php as a mickey-mouse language? It's bad for php if talented programmers bail out. There'd be no-one around to show it off at its best and no-one to offer encouragement or advice to those amongst the 90% who want to raise their game.
    The extra code required to handle those situations would slow down all scripts, despite the fact that it's only fixing a problem encountered in a very small percentage of code.

    To answer my original question, you actually cause stack corruption when you return a variable that way. This is the main reason why so many php applications create seg faults (well, that and race conditions brought about by some internal bugs combined with opcode caches). It's also a common occurance in other languages, most of which aren't nice enough to give you a gentle warning about it (C# will typically crash in most situations, and Java handles it somewhat gracefully, though it's common to wind up with the garbage collector never freeing resources).

    Now, of course, the "right" way to do it would simply be to allow this, and throw an exception whenever you actually try to assign said "bad" reference. There are many problems with that solution, though -- mainly that PHP is not a strictly (or even predominantly) an OO language, and most developers don't even know how a try / catch block works in the first place.

    What happens if a significant part of the 10% decide to abandon php as a mickey-mouse language? It's bad for php if talented programmers bail out. There'd be no-one around to show it off at its best and no-one to offer encouragement or advice to those amongst the 90% who want to raise their game.
    They usually do, actually. One of the biggest problems that PHP has struggled with is more advanced developers realizing its limitations and abandoning it in favor of Java or C#. That was the primary motivating factor behind the creation of all the new OO features in PHP5. PHP4 had, quite simply, awful OO support. Very little development effort was put into it, and it was (by admission, just check Zend's website) little more than a hack for arrays.

    Of coruse, the biggest reason that people use PHP is *not* because of its great support for every CS professor's wet dream, it's elegance, or anything of the like. It's popular because it's extremely fast, easy to program with, and available just about everywhere.

    If the majority of development in PHP were done in an OO fashion, I'd suspect that they would go through the trouble of putting extra temp variables in place on every return, checking them, and then throwing errors / exceptions only when it was bad data. In practice, however, it's not, and it does add additional function overhead which could be avoided by simply changing how the code is written for that small percentage of the user base that does use those features.

    What happens if Thing throws an exception in it's constructor in PHP5, or sets some error state in PHP4? It means that doSomethingInvolvingThing() needs a try block or a load of error handling code on every usage. Also it will repeatedly instantiate on an exception every time it is called (the setting of the variable will have been skipped). This kind of stuff is better handled in the constructor of UnnecessaryLazyLoader. You shouldn't have half constructed objects that need to be finished off.
    In the vast majority of real-world instances, you don't encounter this problem in the first place. In principal, you're not supposed to know / care about implementation, but in practice, you wouldn't be using an object if you didn't know what it was supposed to be *doing*. I'd na'er advocate using the same technique in all instances. You use lazy loading where it makes sense, where it helps reduce code, or where it improves performance.

    Your example has an object directly exposing an internal construct (which it's relying on for other purposes) to outside functionality. Even without lazy loading, that's asking for headaches in implementation, usually involving adding extra validation checks each time you get a return value. I'd only use lazy loading for exposing things strictly to the outside world. If it were also used as an internal construct, I'd instantiate it in the constructor, and, yes, I would surround that with a try / catch block, and throw an appropriate exception if I couldn't initialize it. Of course, this would mean I'm working in php5, in which case the whole point that we're disagreeing on is moot anyway.

    I realize I came across as rude and condescending, and I apologize for that. The points I was trying to illustrate were simply these:

    1.) There is an actual problem with PHPs internals that can cause stack corruption when you return non-references by reference.
    2.) They (the php internals developers) made a concious decision to do this -- it's not a bug or something that's going to be "fixed" in another version. It was the most effective, safest way to handle these situations without hurting performance or writing ZE3.
    3.) The changes that they made make sense from an overall stability / performance / future-proofing standpoint.
    4.) The choice that they made to have it send out a notice is a simple, gentle enough way to get people to fix the problems without breaking a lot of code.
    5.) Nudging developers to fix these problems is good for the community as a whole, as it avoids having to worry about other areas where problems like this might occur.

    1 & 2 are facts. You can read all about it by reading the internals mailing list archives. 3, 4, & 5 are opinions, though casual observation indicates that they're shared by most of the people who didn't do heavy OO design in PHP4 (i.e. most of the PHP user base).

  7. #57
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    Going back to this statement, I think it's the central point of disagreement. Although I respect your opinion, I think that a programming language should be designed so that programmers don't need to know about the internals. Or, failing that, we should need to know as little as possible about them. That makes us more productive since it frees time to learn other things instead, such as the subject of this forum: application design.

    Edit: in fact, this is one of the big improvements PHP 5 brings. Since the way object references work is more intuitive, there is less need to understand their internal workings.
    In a perfect world, I'd agree with you, but we've all designed programs and, at one point or another, had to deal with performance limitations, bugs that we couldn't reproduce, and any number of simliar issues. My background previous to php was primarily in areas of high-performance (3d simulations, server-side applications, etc.), so maybe I'm a bit more "in tune" with the internals than the average php-er and more concerned about it, but I've discovered that it's a truth in every language. Two simple examples spring to mind off the top of my head from other languages as well: "unsafe" code blocks in C#, and mass string concatenation in Java. Both of these situations require some knowledge about the language-specific implementations.

    You'll never be able to not know anything about language internals. You can certainly argue that the engine implements this particular thing in a "bad" way, if you want, but ultimately developers are just as much at fault for not understanding how references are handled by PHP as the internals developers are at fault for implementing it like this. I'd argue that knowing your platform is going to go a lot further in aiding application development than any esoteric design pattern ever will.

  8. #58
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Etnu
    Even without lazy loading, that's asking for headaches in implementation, usually involving adding extra validation checks each time you get a return value.
    I was just pointing out that your replacement code is not "more common", even slightly peculiar, and highlighting the possible difficulties with the construct. the example was admittedly obscure. Still, I would expect a factory method to return an object straight. It certainly looks normal to me.

    Quote Originally Posted by Etnu
    I realize I came across as rude and condescending, and I apologize for that.
    Cool. Good enough for me.

    Quote Originally Posted by Etnu
    1.) There is an actual problem with PHPs internals that can cause stack corruption when you return non-references by reference.
    2.) They (the php internals developers) made a concious decision to do this -- it's not a bug or something that's going to be "fixed" in another version. It was the most effective, safest way to handle these situations without hurting performance or writing ZE3.
    As you say, these are the Zend statements in effect, although I cannot imagine the performance hit being anything other than negligible.

    Quote Originally Posted by Etnu
    3.) The changes that they made make sense from an overall stability / performance / future-proofing standpoint.
    If they don't fix the current broken syntax, where constructs like this fail...
    PHP Code:
    function &instance() {
        return new 
    Thing();

    ...then PHP will be rightly subject to ridicule. As I say, If they could not fix this problem then internals must be in more of a mess than we thought.

    This breaks:
    Old tutorials
    Almost every book
    Almost every library

    Quote Originally Posted by Etnu
    4.) The choice that they made to have it send out a notice is a simple, gentle enough way to get people to fix the problems without breaking a lot of code.

    5.) Nudging developers to fix these problems is good for the community as a whole, as it avoids having to worry about other areas where problems like this might occur.
    I think a better plan would have been to extend the E_STRICT level back down into the PHP4 code base. E_NOTICE also catches undefined variables, which can be handy to find in old libraries, and so most developers will run with notices on. Right now you get drowned in those reference notices.

    The problem right now is transitioning to PHP5. This means that we all have to write library code that works on both platforms. Application code too as we migrate servers. This current "fix", and the bugs that seem to be accompaning it (http://bugs.php.net/bug.php?id=33643), makes it really hard. It couldn't have come at a worst time.

    Quote Originally Posted by Etnu
    3, 4, & 5 are opinions, though casual observation indicates that they're shared by most of the people who didn't do heavy OO design in PHP4 (i.e. most of the PHP user base).
    Which is why this forum in particular is not happy about it. Unfortunately the Python/Ruby defection rate is espacially apparent on this forum and the current screw up won't help. That's a bad portent for a language trying to break into the enterprise domain.

    They really should have gone for the performance hit if that was the real reason.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  9. #59
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    If they don't fix the current broken syntax, where constructs like this fail...
    PHP Code:
    function &instance() {
        return new 
    Thing();

    ...then PHP will be rightly subject to ridicule. As I say, If they could not fix this problem then internals must be in more of a mess than we thought.
    1.) They don't fail, they just generate notices.

    2.) These constructs aren't even necessary in PHP5. People who are looking to develop *new* applications aren't likely looking at php4, so it's mostly a non-issue. The only people who actually are going to encounter this are those people maintaining a legacy php4 code base.

    This breaks:
    Old tutorials
    Almost every book
    Almost every library
    Not quite. How many php4 OO books are there out there? Virtually every php4 book (including the Zend Certification Exam) has little to no OO code in it in the first place. OO in php4 was mostly used for database abstraction and the occasional wrapper class. The impact rate on this issue is very, very low.

    I think a better plan would have been to extend the E_STRICT level back down into the PHP4 code base. E_NOTICE also catches undefined variables, which can be handy to find in old libraries, and so most developers will run with notices on. Right now you get drowned in those reference notices.
    Not really. I tested it out with the following software:

    vBulletin
    MediaWiki
    phpMyAdmin
    phpAdsNew

    And, while there were a *few* extra notices, it wasn't anything too bad. These are among the most popular php applications out there. (and, no, I won't argue that any of them are "good", because they're not -- but I will argue that they're the "common case" with regards to how most php4 applications are built).

    The problem right now is transitioning to PHP5. This means that we all have to write library code that works on both platforms. Application code too as we migrate servers. This current "fix", and the bugs that seem to be accompaning it (http://bugs.php.net/bug.php?id=33643), makes it really hard. It couldn't have come at a worst time.
    Debatable, and it depends on what exactly you're developing. If you're developing mass-consumer software (like the above mentioned products), then cross-development is more difficult. If you're developing strictly in-house stuff, then you can usually just upgrade to php5 and not worry about it (there really is very little that breaks; in fact, all of the previously mentioned apps run without issue). If you fall in between (I fit here), then you can usually just focus all "new" development on PHP5 while leaving the legacy stuff alone and only updating for major bugs & security fixes.

    Which is why this forum in particular is not happy about it. Unfortunately the Python/Ruby defection rate is espacially apparent on this forum and the current screw up won't help. That's a bad portent for a language trying to break into the enterprise domain.
    1.) PHP has already "broken in" to the enterprise domain. Aside from the most obvious one (Yahoo), many large companies have either already moved to php or are evaluating it now. I've interviewed with several of the biggest websites out there, and almost all of them were asking me about my php experience; not perl, not python, not ruby, not java, and not perl (the last one being extremely surprising considering that their current site is in perl). It's true that it hasn't caught on in non-tech circles (banks and the like), but those companies have never really been known for their smart tech decisions.

    2.) The "defection rate" (this isn't a war, you know) isn't significant at this point in time. Perhaps one day Ruby will surpass PHP as the web language of choice, although some other issues with the language (namely it's somewhat alien syntax) will prevent it's adoption. The reason why PHP is so popular is the same reason why Java is so popular: because they borrow C / C++ syntax. This may seem trivial, but it's important. It's much easier to get used to programming in a language that's structured similiarly to another one that you've used before. C++ has a lot of the same shortcomings as PHP, but it's still among the most popular languages in use today, primarily for performance. Nothing web-based comes close to php's performance (especially not when you're running PHP5.1), and that'll be a significant factor for some time to come.

  10. #60
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    >> People who are looking to develop *new* applications aren't likely looking at php4

    And who would those people be? People doing it as a hobby? maybe. Companies developing an in house solution? maybe.

    Anybody doing it as a business most likely has the business sense to know that it most likely doesn't make sense to cut PHP 4 out of the loop at this point in time. And if that doesn't make any sense, then I'm sorry you don't have the sense to make sense of it

  11. #61
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    >> The reason why PHP is so popular is the same reason why Java is so popular: because they borrow C / C++ syntax

    That would be probably 90-95% inaccurate. PHP didn't become so popular because it was easy to learn if you already knew C. There were many reasons PHP became so popular, but this one would be pretty far to the bottom of the list of reasons, especially considering if you look at the number of PHP programmers, the majority probably started programming with PHP.

  12. #62
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Etnu
    1.) They don't fail, they just generate notices.
    For the average developer with notices turned on, it's a failure of sorts. True you can wrap stuff in an error reporting call and wall off stuff, but the message is taht a basic construct is wrong. I have at least one Java colueage who will turn his nose up at this. I can almost sense his disgust from here and he hasn't even seen it yet.

    Quote Originally Posted by Etnu
    2.) These constructs aren't even necessary in PHP5.
    That's true, and I am looking forward to getting rid of them. Unfortunately I have a large codebase I am trying to get compatible for a server upgrade. As PHP5 porting is not going to happen for a while, I have to get it to PHP4.4. I spent all of yesterday clearing up the 600+ notices generated by the core unit tests.

    If you are writing library code, say something like SimpleTest, which has to work with everything then you end up with some real head scratching. I have 5.1 bugs that are driving me nuts right now.

    As a problem it cannot be so easily dismissed.

    Quote Originally Posted by Etnu
    People who are looking to develop *new* applications aren't likely looking at php4, so it's mostly a non-issue. The only people who actually are going to encounter this are those people maintaining a legacy php4 code base.
    Yeah, but it's these applications that are successful and makng a living for the developers.

    Quote Originally Posted by Etnu
    Virtually every php4 book (including the Zend Certification Exam) has little to no OO code in it in the first place. OO in php4 was mostly used for database abstraction and the occasional wrapper class. The impact rate on this issue is very, very low.
    OK, I was going by my own book collection there.

    Quote Originally Posted by Etnu
    If you're developing mass-consumer software (like the above mentioned products), then cross-development is more difficult. If you're developing strictly in-house stuff, then you can usually just upgrade to php5 and not worry about it (there really is very little that breaks; in fact, all of the previously mentioned apps run without issue).
    There are a lot of practical difficulties with this approach. With a complex application you don't want to role out PHP5 and change the codebase at the same time. One upgrade at a time is enough. And you need to roll back in a hurry if bugs are introduced on a PHP5 server. the code *must* be compatible during the transition, else it's too difficult to manage.

    The other problem is that the entire app. must be runnable on dev. boxes, for testing if nothing else. As it's difficult (without VMWare or fancy networking tricks and two Apaches) to run PHP4 and PHP5, everything must upgrade together.

    Zend really are making my life difficult right now.

    Quote Originally Posted by Etnu
    1.) PHP has already "broken in" to the enterprise domain.
    I don't agree, but then that's a whole other thread .

    Quote Originally Posted by Etnu
    2.) The "defection rate" (this isn't a war, you know) isn't significant at this point in time.
    It is for building the community. I have been on this forum for 2 years and I have seen almost every significant figure from then move on. It used to be Java, then Python and now Ruby. These people would otherwise go on to write the books and articles that will power PHPs adoption and sheppard the community through growth.

    I think these constant losses at the top are significant. There are no Addison-Wesley books with PHP code in.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  13. #63
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    In a perfect world, I'd agree with you, but we've all designed programs and, at one point or another, had to deal with performance limitations, bugs that we couldn't reproduce, and any number of simliar issues.
    Performance limitations: sure, you may need to find out something about the internals that's relevant to an actual performance problem. But if you need to know much about them ahead of time to program "correctly", that's ugly.

    Bugs that we can't reproduce: I've never done serious C/C++ programming, so I'm on somewhat thin ice in saying this, but this seems mostly relevant to C/C++ memory leaks. I don't think PHP applications tend to have hard-to-reproduce bugs that require knowledge of language internals to find or fix.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  14. #64
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I think these constant losses at the top are significant. There are no Addison-Wesley books with PHP code in.
    I haven't seen a lot of Ruby or Python in Addison-Wesley books either--yet. But you're right. Zend should have an "onsite customer" that's actually serious about the issues we discuss in this forum.

    (Ha ha.)
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  15. #65
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dreamscape
    >> People who are looking to develop *new* applications aren't likely looking at php4

    And who would those people be? People doing it as a hobby? maybe. Companies developing an in house solution? maybe.

    Anybody doing it as a business most likely has the business sense to know that it most likely doesn't make sense to cut PHP 4 out of the loop at this point in time. And if that doesn't make any sense, then I'm sorry you don't have the sense to make sense of it
    Very little PHP development is done "for sale". Most developers are either:

    1.) Developing custom solutions for clients.

    2.) Developing their own web sites.

    PHP is hard to *sell*. Yes, there are a few successful products (xcart & vbulletin come to mind immediately), but for the most part, php projects are either in-house, custom built, or open source.

    That would be probably 90-95% inaccurate. PHP didn't become so popular because it was easy to learn if you already knew C. There were many reasons PHP became so popular, but this one would be pretty far to the bottom of the list of reasons, especially considering if you look at the number of PHP programmers, the majority probably started programming with PHP.
    It's got nothing to do with new developers -- it's got to do with getting competent developers interested who are moving to the web. These are the people who are writing the tutorials, telling their friends, etc. I can name literally dozens of languages that were superior in many ways to these other languages, but they never caught on because of syntax oddities (LISP, anyone?).

    I can take just about any example code out there on how to implement (insert design pattern flavor of the month here) for C++ or Java and pretty much directly translate it to PHP, just by tacking on some dollar signs and a few minor keyword changes (somewhat of an oversimplification, I know, but I'm sure you see the point I'm making). Can the same be said for Perl? Python? Ruby? Lisp?

    PHP has other strengths, 'tis true, but most of the ones people cite aren't exclusive to PHP. Almost all of those libraries out there that make PHP so useful are just as easy to use in the other languages (after all, they're just wrappers around the C apis).

    Companies won't switch development until they see a truly compelling way to shift their developer talent. Java was easy -- programmers only needed to be trained on some language nuances, and the rest came with time. They already understood the basic way the language worked, because of their C/C++ backgrounds.

    How are companies going to make that jump to Ruby or Python or whatnot when they've got a horde of developers used to all the PHP-isms? Sure, you could fire all your developers, but that tends to put strain on your deadlines.

    Edit:

    Oh, and No books? You don't see PHP in the academic field, because it's not an academic language. It's a practical language designed to solve real-world problems, not go for CS purity. As such, it's *not* a language suitable for teaching. AW is primarily an academic publisher, and they focus on books that make them money, because Unversities want it. Hence, they sell millions of re-hashed Java books, but don't do much with PHP, Perl, or other languages that aren't suitable for academics.

    Re: PHP and the enterprise.

    The most popular websites on the Internet, according to Alexa (results may be slightly off because alexa is based largely on people dumb enough to install spyware)

    1.) Yahoo (PHP)
    2.) MSN (ASP)
    3.) Google (mixture of many languages)
    4.) Passport.net (part of MSN)
    5.) eBay (Java)
    6.) Microsoft.com (ASP)
    7.) Amazon (Perl [main site], Java [a9], PHP [software solutions])
    8.) MySpace.com (ColdFusion)
    9.) AOL.com (Dunno)
    10.) BBC (appears to be Perl)

    If we take the microsoft sites (MSN, Passport, and Microsoft.com) out of the mix (for obvious reasons; of course MS is going to use their own language), we're left with 1 site using PHP exclusively, 1 site using ColdFusion, 1 site using java, and 1 using perl. 2 sites have a mix of different languages.

    Looks to me like no single language is any more popular than others. If you're trying to argue about PHP's adoption in the non-web world, then I dunno what to say. It's a web language, not anything else. Of course Java is going to be more popular! These sites *are* "the enterprise" when it comes to web technology.

  16. #66
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    You don't see PHP in the academic field, because it's not an academic language. It's a practical language designed to solve real-world problems, not go for CS purity. As such, it's *not* a language suitable for teaching.
    Are you deliberately trying to miss the point? So far no-one has mentioned computer science purity except you. Best practices like OOP, testing and other things agile aren't any less important just because many php coders don't use them. These are very practical solutions which solve real problems far better than any alternative.

    I'd like to think that in future v4 updates the php developers won't just shrug their shoulders at the painful inconvenience they've created as you seem to do for the sake of a fix and alleged performance hit for which (I'd guess) you'd need an instrument as sensitive as the Hubble space telescope to detect.

  17. #67
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    >> we're left with 1 site using PHP exclusively

    Yahoo doesn't use PHP exclusively. At least not according to their press release from when they switched parts of their system from C/C++ to PHP. I haven't seen anything released since that says they are totally PHP.

    From their late 2002 press coverage:
    Radwin said the migration of existing sites would be slow and gradual. "We have no plans to rewrite the entire site," he said. Yahoo would spend the coming months mixing PHP, Apache DSOs, yScript1 and yScript2 pages, he said.
    Unless they've changed their game plan and totally dropped their own yScript1 and yScript2, they aren't exclusively using PHP.

    Also, I do believe to get extremely high performance where they need it, Yahoo writes their own PHP extensions in C/C++. Ok yeah, that is still in the end using PHP, but they're not limiting themselves to what is generally available for PHP. If they need an extension and none exists to satisfy them, from what I gather, they write their own.

    But then in an enterprise environment, one will never be able to utilize only PHP. It is designed for web, and you can also do some non-web things with the CLI, but it is a high level language. For other operations an enterprise may need, they'd still need to utilize other language options.

  18. #68
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    >> PHP is hard to *sell*.

    What is so hard to "sell" about PHP web applications? Maybe you tried, but just did not target the right market.

  19. #69
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    From bad impressions of that gathered within a Microsoft environmental press, to the lack of Unicode support.

    PHP is getting there, but it just isn't there yet, when you compare feature vs feature against Java and Dot Net, which are there as we speak. But in saying that, that is not to say that PHP isn't capable enough.

    In half of the cases, it proberly is but it just takes that bit more of an effort to be convincing. But I don't think punting PHP4.x onto an otherwise client who is new to the world of the Internet is wise either, kind of putting a loaded gun to your head, isn't it?

  20. #70
    SitePoint Addict
    Join Date
    May 2005
    Posts
    255
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Are you deliberately trying to miss the point? So far no-one has mentioned computer science purity except you. Best practices like OOP, testing and other things agile aren't any less important just because many php coders don't use them. These are very practical solutions which solve real problems far better than any alternative.

    I'd like to think that in future v4 updates the php developers won't just shrug their shoulders at the painful inconvenience they've created as you seem to do for the sake of a fix and alleged performance hit for which (I'd guess) you'd need an instrument as sensitive as the Hubble space telescope to detect.
    A great many OO principals and practices are more cumbersome in real-world development than the supposed benefits that they bring, and many of them are devised by CS professors and the like who, while certainly not inexperienced or incompetent, tend to focus more on principal than on practice. The problem that typically arises is that you spend a lot of extra time implementing a more complex solution and launch 6 months later than if you'd just gone with the simple script. This is much more true of the web world than the traditional application world. The main problem is ultimately that the code that forms your framework tends to be an overwhelmingly small portion of your overall system. The parts that change drastically tend to require more rewriting because the actual business logic behind them changes. Obviously this isn't a universal truth, as most experienced developers typically fall somewhere in between the purity for purity's sake side of things and the "all hacks, all of the time" type of design typically seen by novice programmers.

    As far as "the best alternative", that's pretty subjective, and largely not reflected in the real world. If there were that much of a difference, you'd see larger variations in release cycles and quality of projects of a similiar caliber when they're developed under OO vs. some other design system. Writing awful code is just as easy to do in a language that enforces OO principals (C# or Java) as it is in one that doesn't (C++ or PHP), and writing good code isn't any easier either way.

    I personally prefer an OO approach to things in most cases, but many developers far more experienced and knowledgeable than myself do not. Good application design is not dictated by paradigm, it's dictated by the quality of the people doing the development in the first place. And there's certainly plenty of cases where OO has just plain gone too far to the point of making development MORE difficult than it needs to be.

    For the web, most applications don't really rely on high degrees of complexity. I'd personally argue that for most applications that do, PHP is simply not the best language to implement these sorts of things in. I'd look towards Java or C# instead.

    Yahoo doesn't use PHP exclusively. At least not according to their press release from when they switched parts of their system from C/C++ to PHP. I haven't seen anything released since that says they are totally PHP.
    I was mostly focusing on the web-oriented stuff for comparison, as virtually every major site relies on multiple pieces of technology (i'd bet large sums of cash that every company out there uses at least 2 languages for different purposes, even if they don't do the bulk of their development in it). But that's hardly the point. PHP is the single most popular development platform for the web, on both the high and the low end, and is used by some of the largest web sites around, including *the* largest. By that token, if PHP isn't "enterprise ready", then no language is.

  21. #71
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Etnu
    A great many OO principals and practices are more cumbersome in real-world development than the supposed benefits that they bring, and many of them are devised by CS professors and the like who, while certainly not inexperienced or incompetent, tend to focus more on principal than on practice.
    You might be right - I've never met one - but maybe we don't need to invite them to this dicussion.
    As far as "the best alternative", that's pretty subjective, and largely not reflected in the real world. If there were that much of a difference, you'd see larger variations in release cycles and quality of projects of a similiar caliber when they're developed under OO vs.
    Actually I meant to shift the focus away from OOP slightly towards modern, agile ideas. It's the combination of OOP and testing which is really powerful. You can't just "fire and forget": applications have to be maintained over their life cycle. Automated tests, regression testing & continuous integration make you much more efficient.

    I wouldn't even say that it's initially slower. I do take longer to write something than I did when I was taking my first steps with programming but little of that is being wasted hunting down bugs. Mainly the time is going into better, more robust code ie I'm just taking the time required to do it properly. "Hacking" stuff together might get to the finish line quicker but look closely and you'll probably find a fair few problems. When people apply tests to legacy code they always find some bugs they didn't know about.

    In a way the XP idea of write just-enough-to-pass-the-test is a kind of hacking but it's guided by tightly focussed constraints. It's a fantastic way to work which aims to avoid some of the problems you've mentioned. To my mind it's extremely practical and grounded.

    And it does mean I often need to partially mock methods which return objects...

  22. #72
    SitePoint Wizard dreamscape's Avatar
    Join Date
    Aug 2005
    Posts
    1,080
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    >> By that token, if PHP isn't "enterprise ready", then no language is.

    I never said, tried to imply, or even indicated that I thought that PHP wasn't enterprise ready, so you can just stop shoving words into other people's mouths, and be more careful of the one's in your own.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •