Page 1 of 3 123 Last
  • Jump to page:
    #1
  1. Sarcky
    Devshed Supreme Being (6500+ posts)

    Join Date
    Oct 2006
    Location
    Pennsylvania, USA
    Posts
    10,908
    Rep Power
    6351

    PHP is a fractal of bad design? Hardly.


    Jacques' signature has been changed to:

    PHP is a fractal of bad design. Use Ruby or Python.
    As I've seen this article a number of times, I'd like to go through it to see what everyone has to say on the subject. Warning: This is just stupidly, ludicrously long. it takes an existing 5-page article and tears it apart nearly sentence-by-sentence.

    First, let me say that PHP isn't perfect. There's a lot of weirdness to it, a lot of examples of a language that grew organically by a large multinational team instead of being designed by a small committee of English-speaking developers. But that doesn't mean it's bad design, just that there's quirks, like any well used system.

    Now, onto the article itself. We're first presented with his toolbox analogy. This ridiculous piece of prose seems to be insinuating that the basic control structures of PHP are somehow non-standard and don't work like every other language. A hammer with a peen on both ends? A screwdriver which only works with specialty screws? How is this an analogy for the most popular web language in the world? He goes on to say that the builders who use these tools make things that don't work and fall down at the slighest provocation. Now, having read this before, I know that he goes into defense mode over this statement later, but I'll go ahead and attack it now: Show me the faults in facebook. Show me where wikipedia falls down when you touch it. Find the design flaws in vbulletin, wordpress, or any of the other toolsets that would be at all analogous to a house "where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards."

    Stance

    After his analogy, we get his stances. These are almost all wrong, and illustrate his basic misunderstanding of languages in general. He believes languages shoudld be:

    Predictable - The author states that it's the language's responsibility to be understood by everyone who uses it, rather than the builder's responsibility to understand their tools. He doesn't understand why PHP does something, so instead of investigating and learning more, he declares PHP "broken" and "badly designed." This is a recurring theme in the article. Much of his problems with PHP stem from him not understanding symbol tables or loosely typed languages. Just look at his list of "surprises": mysql_real_escape_string? OH MY GOD! SHOCKING! What the hell is he talking about?

    And E_ALL? How is a constant name a "surprise"? The list of error-level constants is in the manual. they all begin with E_ and then give what they describe. I will grant that E_ALL spent a couple years not being absolutely every error. However, I think the choice was to make E_ALL provide only functional errors, and not strict warnings like deprecated function names. Some disagree.

    Consistent - Apparently things that look the same should work the same in a programming language? And if you know one part you should be able to understand other parts? This appears to be a dig at PHP's ecclectic naming conventions, and I will certainly give him that. htmlentities should have underscores like its counterpart, html_entity_decode. Of course, the counterpart of every function is in that function's manual page, but "the manual is right there and it's free and it's integrated into the free IDEs" still isn't an excuse. The language needs to be cleaned up from a naming perspective. He gets one point.

    Concise - He makes statements about "boilerplate" a number of times, but never defines the term or tells us what he's talking about. PHP is very concise. It includes time-saving functions like usort(), file_get_contents(), and other functions which in C++ would take pages of code. Of course, it also requires error checking, which seems to be what he's complaining about. He lists error-checking as boilerplate. I don't know how Python handles it, but generally as a programmer I'd like to know if a file operation failed. His point here seems to be that low-level functions return false instead of throwing an exception, which is honestly a holdover from when PHP was young and didn't have exceptions. However, which is more boilerplate: if ( !( $file = fopen('file.txt', 'w') ) ) or a try-catch block?

    Reliable - This, again, is him assuming that it's the language's responsibility to be understood, rather than his responsibility to understand it. He goes into what he considers "gotcha" events later in the article, but (spoiler alert) they all stem from his fundamental understanding of the language. You can tell because his two examples perfectly illustrate his misunderstanding. The == operator is listed as "flaky." The == operator is the core of loosely typed languages, and is immensely powerful. He thinks it's flaky because he can't wrap his brain around loose comparisons. His second example is a by-ref loop, something which exists in all programming languages. The only "gotcha" here is that his understanding of the way variables work in this language is simply wrong.

    Debuggable - Now this I'll give him. PHP's error handling is atrocious. I mean, look at the errors some of these new users are getting on DevShed. Who can solve any problem when given just the error type, line number, function name, data type, prose description of the error, and potential fix? That's ridiculous! [/sarcasm] Maybe Python's error handling is much more robust than I remember, but PHP's has thus far been fine for me. Better than the error handling of things like Oracle, with 'cannot bind' being the only error I got yesterday. His examples require a stack trace, which I guess could be handy some of the time, but honestly I've rarely used the stack traces we build into our error-handling at work (which is easily overridden in the PHP core with a set_error_handler call)

    Arguments

    Now, our author goes into a list of arguments he automatically discards. Luckily, my argument of "you don't understand PHP and it's not PHP's job to get into your brain and force you to understand things you choose not to" isn't on the list. He does say that it's not his responsibility to "memorize a thousand strange exceptions." I agree with him on that, strpos should be renamed. However, it is his responsibility to come to an understanding of how programming languages work, and he has failed to do so. He also uses a wonderful straw man with "you should just use C if PHP handles 5% of its operations the way C does." Just because fopen returns false in C and in PHP doesn't mean PHP is a net loss. Finally, his argument of "the largest and most popular websites in the world, designed and written by the smartest programmers in the world, don't prove anything" is laughable. The conscious choices of almost every single web engineering team worth a damn do, in fact, count as proof that the tool they've chosen is worthwhile. (He also says not to argue with him at all, because he's just stomping his little feet and nothing will change his mind. I'm writing this for the DevShed community, not this guy who can't figure out how PHP works.)


    Philosophy

    PHP was designed to be easy to understand, because at the time the thought of full-featured web applications was silly. An item's source doesn't discredit what it's become. What if someone told you "America was founded to be a colony (and, reading between the lines, not a country); it has not well escaped its roots. This is why I believe nobody should take America seriously as a country." Stupid, right? Good, glad we agree.

    PHP is built to keep chugging along at all costs.
    MY GOD! HOW LUDICROUS! PHP is a web language with very little ability to recover from a crash the way you would in a desktop environment. It will keep doing its best and instead of a blank screen (or a blue one) maybe a bad programmer will get her site's navigation bar with some errors underneath it. But she WILL get something. The fact that PHP doesn't crash and burn as easily as the other languages doesn't have me crying myself to sleep at night.

    There’s no clear design philosophy.
    Yes, we know. He still has one point.

    PHP takes vast amounts of inspiration from other languages, yet still manages to be incomprehensible to anyone who knows those languages. (int) looks like C, but int doesn’t exist. Namespaces use \. The new array syntax results in [key => value], unique among every language with hash literals.
    So wait...you're telling me...different languages can build on each other, but an expert in one isn't automatically an expert in the other? Alert NASA, we have a breakthrough in human understanding. Languages are different. That's the point of making new languages. Sorry if Perl's regex format is confusing to a C guru. Perhaps he should learn Perl before complaining that the syntax of a language he doesn't know is confusing.

    Weak typing (i.e., silent automatic conversion between strings/numbers/et al) is so complex that whatever minor programmer effort is saved is by no means worth it.
    This is the closest he comes to outright saying "I don't understand it and therefore it's wrong." If you want to understand how weak typing conversions work, you could look in the manual for the chart, or you could read my article on it.

    Little new functionality is implemented as new syntax;
    From the man who complained about the syntax of arrays, namespaces, and type conversions literally 2 sentences prior.

    Code example: fopen

    First of all, let me start by saying that when he said the line he discovered was "somewhere in the manual," it was deep into the manual entry for complex system-level error-handling functions and was specifically designed to suppress errors in a weird way so that you could see how error-screaming works. The fact that he pulled this frankly BS example out of a manual entry on weird and complex error handling shows just how hard he was reaching to make a point, but since his misunderstanding of PHP is well illustrated here I'll continue.

    (Docs don’t say what “won’t work” means; returns null, throws exception?) [...] If allow_url_fopen is disabled in php.ini, this still won’t work. (How? No idea.)
    Except the docs DO say what happens when the function fopen fails: it returns false. It's in a nice blue box labeled "returns." Can't miss it.

    Because of the @, the warning about the non-existent file won’t be printed.
    Line-level error suppression is a powerful feature, I'm glad to use a language which supports it.

    But it will be printed if scream.enabled is set in php.ini.
    System-level forcing of all errors is another powerful feature, I'm glad I don't have to go find ever @ sign in my code when I'm debugging something weird.

    If it is printed, exactly where it goes depends on display_errors
    I'm beginning to think he's never used a programming language at all. Is it just me, or should every web language have server-level error reporting configuration? What does Python do? Just spit all errors to the screen no matter what? If you want to log to a file, you have to do that by hand for every error? That sounds awful. Or he's full of it.

    Back to individual complaints

    The language is full of global and implicit state
    Server-level configurations are pretty handy and remove a lot of boilerplate, don't you think? Good thing removing boilerplate was one of his biggest criteria back at the beginning.

    register_tick_function sets a global function to run every tick—what?!
    Shame the manual on that function isn't 4 pages with explanations and usage examples or he might learn something.

    There is no threading support whatsoever.
    It's purely a web language, and nothing else. Websites don't need threads, because if they take longer than a second to run they've failed. Again, fundamental lack of understanding.

    json_decode returns null for invalid input, even though null is also a perfectly valid object for JSON to decode to—this function is completely unreliable unless you also call json_last_error every time you use it.
    He gets another point here, json_decode really should throw an exception. Though to be fair, if I ever get a json object which resolves to null, I'm going to handle it as an error regardless.

    array_search, strpos, and similar functions return 0 if they find the needle at position zero, but false if they don’t find it at all.
    Once again, if this person would take 10 minutes to attempt to understand loosely typed languages, this would all make sense. These functions return the index of the item found. if no item is found, they return false. That sounds really powerful, and I'm not sure why it's even a complaint. Luckily for the reader, he goes on to explain his ignorance:

    In C, functions like strpos return -1 if the item isn’t found. If you don’t check for that case and try to use that as an index, you’ll hit junk memory and your program will blow up. [...] In, say, Python, the equivalent .index methods will raise an exception if the item isn’t found. If you don’t check for that case, your program will blow up.
    C and Python crash fatally, potentially destroying the memory space of other programs. Got it.

    In PHP, these functions return false. If you use FALSE as an index, or do much of anything with it except compare with ===, PHP will silently convert it to 0 for you. Your program will not blow up; it will, instead, do the wrong thing with no warning, unless you remember to include the right boilerplate around every place you use strpos and certain other functions.
    So basically, if you don't include the right boilerplate around other languages, they fatally crash and destroy their state, potentially also destroying neighboring programs in memory. However, if you do the same erroneous code in PHP, it continues to work with slightly unexpected results. Tell me again why "keeps working" is a problem? Plus, for what might be the 10th time, he just plain doesn't understand loosely typed languages. Yes, false == zero. That's actually an incredibly powerful feature of the language. The boilerplate he's comparing about isn't exactly onerous either. Look, here it is: "!== false". Oh man, look out. That nearly broke my fingers I typed for so long.

    So I have to fit this in here, because it bears repeating: PHP is a community of amateurs.
    And they're all stupid heads and not invited to my birthday party. I love how he "had to fit in" an ad hominem attack against an entire community of developers. He even states further up in the article that facebook and wikipedia run PHP, and still manages to claim that those people are amateurs.

    "Back to the facts" (and by "facts" we mean "opinions borne of fundamental misunderstandings")

    == is useless [...] Comparison isn’t much better.
    Blah blah doesn't understand loosely typed blah.

    PHP does not overload +
    Quite literally damned if you do, damned if you don't. He simultaneously complains about PHP doing something, then not doing that same thing.

    There is no way to declare a variable.
    I really should make a hotkey for "he doesn't understand loosely typed languages."

    Global variables need a global declaration before they can be used. This is a natural consequence of the above, so it would be perfectly reasonable, except that globals can’t even be read without an explicit declaration—PHP will quietly create a local with the same name, instead. I’m not aware of another language with similar scoping issues.
    PHP has strict function scope, and globals aren't automatically imported for reading and writing. His complaint seems to be that all globals aren't read-only inside all functions, which I personally think is confusing if it's done that way. Why should I be able to read $foo but not write to it? Doesn't that seem more confusing?

    There are no references. What PHP calls references are really aliases; there’s nothing that’s a step back, like Perl’s references, and there’s no pass-by-object identity like in Python.
    His second fundamental misunderstanding finally rears its head here: Symbol tables. PHP doesn't use variables like other languages, it uses symbol tables. PHP does in fact have references, and pass-by-identity (objects are always passed by reference).

    Once a variable is made a reference (which can happen anywhere), it’s stuck as a reference. There’s no obvious way to detect this and un-referencing requires nuking the variable entirely.
    I'm willing to grant him another point here (which makes three). If you, for instance, make $a a reference to the third item in array $b, then any modifications to $a modify the inner structure of $b, though $a still looks like a stand-alone variable. Perhaps another symbol would be good, but then you get into the problem of perl, where $a and #a and &a are all confusing and conflicting things. Difficult problem to solve, but most programmers just don't use references unless they need them.

    (integer) is a synonym for (int). There’s also (bool)/(boolean) and (float)/(double)/(real). [...] There’s redundant syntax for blocks: if (...): ... endif;, etc.
    "PHP is too confusing, I have to memorize so many things! Waaaaaah! In addition, there's aliases for things so if I forget and use the wrong one it will still work! PHP IS AWFUL!!"

    Most error handling is in the form of printing a line to a server log nobody reads and carrying on.
    "I don't read my log files, what kind of programmer would ever use error logs to debug? That's stupid! My website should just die with a white screen and a 'Sorry!' message whenever there's an error so I know to go try to remember where I put the error logs"

    E_STRICT is a thing, but it doesn’t seem to actually prevent much and there’s no documentation on what it actually does.
    As stated above, E_STRICT is an error-level constant (hence the E_) and is well defined in the manual.

    Weirdly inconsistent about what’s allowed and what isn’t.
    The things he listed as "silent" are not errors in the least, they're all valid PHP operations. He seems to think E_STRICT should mean "work more like another programming language." Probably because he doesn't understand PHP.

    PHP errors and PHP exceptions are completely different beasts
    Are there interpreted languages which throw in-application exceptions instead of language-level errors when they encounter fatal or parse errors? I don't think there are, I think the author doesn't understand interpreted languages vs compiled ones.

    Some built-in functions interact with reference-returning functions in, er, a strange way.
    The one example he has of this shows someone attempting to create an anonymous (unreferenced) array, put a variable in it, and then have it immediately destroyed. Not sure why that's even something someone would do, but...err...you got me.

    OO

    I’ve yet to find a global function that even has a capital letter in its name
    Anyone else feel like scrolling up to where he complains about function names being case-insensitive? No?

    Perl, Python, and Ruby all have some concept of “property” access via code; PHP has only the clunky __get and friends. (The documentation inexplicably refers to such special methods as “overloading”.)
    Our dear author has not yet discovered the simplicity of $foo->bar. Either that or he has absolutely no understanding of how objects work in ANY language.

    Classes have something like variable declaration (var and const) for class attributes, whereas the procedural part of the language does not.
    Aside from demonstrating the "var" syntax (deprecated over a decade ago), this doesn't understand the complexities of designing a real system in PHP.

    Despite the heavy influence from C++/Java, where objects are fairly opaque, PHP often treats objects like fancy hashes—for example, the default behavior of foreach ($obj as $key => $value) is to iterate over every accessible attribute of the object.
    Still not getting why he complains about additional functionality he doesn't even have to use. So you can foreach over an obect to get its public variables (or, if it implements arrayaccess, some other variable of the author's choosing). If you don't like that, don't use it. It's like saying "unlike C, Python allows me to have tuples." So?

    Object attributes are $obj->foo, but class attributes are Class::$foo. ($obj::$foo will try to stringify $obj and use it as a class name.) Class attributes can’t be accessed via objects; the namespaces are completely separate, making class attributes completely useless for polymorphism.
    None of this makes any sense at all. I'm willing to give him the benefit of the doubt and assume he hit his head or something.

    I’m aware this is more personal taste, but I don’t know why this stuff is necessary in a dynamic language—in C++ most of it’s about compilation and compile-time name resolution.
    Wow, that's an excellent point. I'm glad we're talking about a compiled language and not, for instance, PHP.

    Arrays

    Despite that this is the language’s only data structure, there is no shortcut syntax for it
    Once again, who wants to volunteer to scroll up to where he complained about the shortcut array syntax? It's like this article was written in 2004, and then he updated it with more complaints, many of the complaints being about the fixes to his previous complaints. It's like the room is filthy, and the maid used floor polish that smells too strongly. One or the other.

    it’s the only language in its niche that has no vetted way to create a hash without quoting string keys.
    Because it's a loosely typed language perhaps? Because it's possible to use a variable without defining it, even constants, and therefore an unquoted bare string literal is assumed to be an undefined constant? Becuase you don't understand loosely typed languages?

    Missing Features

    No XSS filter. No, “remember to use htmlspecialchars” is not an XSS filter. This is.
    So "remember to use htmlspecialchars" doesn't count, but "remember to use marksupsafe" does? Gotcha. Good to know that the criteria for language functionality can just change mid-sentence.

    No CSRF protection. You get to do it yourself.
    Because his last example was a function call you had to wrap arounde every string, I'm going to go ahead and assume that's what he'd use to "prove" this point as well, if such a library is even available.

    No generic standard database API. Stuff like PDO has to wrap every individual database’s API to abstract the differences away.
    There's no standard database API. Except for the standard one. But that one doesn't count because deep down below where you can see it, it doesn't call the same functions for each database.

    No authentication or authorization.
    This one I actually know nothing about. Do other languages have built-in user authentication which can work as a login system? So if I want to write a web login system in Python, there's a built-in language core module for that?

    Security

    PHP’s poor security reputation is largely because it will take arbitrary data from one language and dump it into another. This is a bad idea. "<script>" may not mean anything in SQL, but it sure does in HTML.
    Again, I'm going to have to ask how Python does that. Does Python automatically sanitize plaintext output? How would you print a <script> tag in python if that's the case? Or is this, like most of his complaints, just how languages work?

    PHP outright encourages “sanitizing”: there’s an entire data filtering extension for doing it.
    Could this be because PHP interacts with half a dozen other languages? Sure, you can use "placeholders" (bound parameters) with SQL, but can you use "placeholders" with HTML forms? No, you need to sanitize your output. Good thing PHP includes those functions.

    register_globals. It’s been off by default for a while by now, and it’s gone in 5.4. I don’t care. This is an embarrassment.
    PHP was originally written to be super easy to use. As the featureset grew, they disabled some of the easier things. Register_globals is stupid today, which is why it's been deprecated for 10 years.

    include accepting HTTP URLs. Likewise.
    There's a PHP.ini command to disable this, which is off by default. He even complained about a similar command above.

    Conclusion

    If you got all the way down here, I assumed you agreed with me before you started
    Or you had a morbid fascination with the awful arguments being presented and were unable to turn away, like a car crash.

    Comments on this post

    • Northie agrees : mainly in part due to your efforts in responding. I just didn't have the energy
    • huyaroo agrees
    Last edited by ManiacDan; August 29th, 2012 at 09:16 AM.
    HEY! YOU! Read the New User Guide and Forum Rules

    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin

    "The greatest tragedy of this changing society is that people who never knew what it was like before will simply assume that this is the way things are supposed to be." -2600 Magazine, Fall 2002

    Think we're being rude? Maybe you asked a bad question or you're a Help Vampire. Trying to argue intelligently? Please read this.
  2. #2
  3. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4123
    Jacques' signature has been changed to:

    PHP is a fractal of bad design. Use Ruby or Python.
    I read the post last week...or should I say I started to read it on a smart phone then got angry at the author for not understanding loosely typed languages...figured that wasn't my problem and moved on with my life.

    Also, did you notice if Jacques1 was actually the author of that? s/he posts in here quite a bit and seems to know quite a bit about PHP....even is s/he did disagree with me about something

    It's true, PHP isn't perfect...but show me a language that is....

    It's true that there are lot of amateurs who build insecure systems by copying and pasting code from the manual.

    PHP is very well suited to building HTML content for web sites and web apps because that's what it was designed to do

    Java is very well suited to programming washing machines

    It's also often said that PHP is easy to learn and therefore too many non programmers write insecure and/or poor code.

    I disagree: PHP is easy to use, but difficult to learn to use properly.

    Like wood working tools. I can pick up a chisel or a saw and chip away or cut wood. However, my cabinet disintegrates when I put a mug in it

    (actually I'm quite good at woodwork, but you get the point!)
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  4. #3
  5. Sarcky
    Devshed Supreme Being (6500+ posts)

    Join Date
    Oct 2006
    Location
    Pennsylvania, USA
    Posts
    10,908
    Rep Power
    6351
    Also, did you notice if Jacques1 was actually the author of that? s/he posts in here quite a bit and seems to know quite a bit about PHP....even is s/he did disagree with me about something
    That article has been banging around the internet for quite some time. I encountered it on reddit a few months ago. I doubt Jacques is the author, though they do spend a hell of a lot of time helping people in a language they think is awful. Edit: Someone identifying himself as the author has arrived on the scene.


    Like wood working tools. I can pick up a chisel or a saw and chip away or cut wood. However, my cabinet disintegrates when I put a mug in it
    I dislike his original tool analogy, but if we're going to use one: PHP is like a toolkit originally designed for making tables and chairs. Small planes, maybe a lathe, a router, some screwdrivers, a wrench, a sander, etc. People liked it so much that they started trying to build sheds with it, then cabins, then houses. The toolkit maintainer kept adding things ad-hoc as they were desired, and now people are using the toolkit to build skyscrapers. Other people come in and say "what the hell do you need a hand-held plane for if you're building skyscrapers, MORONS!?" We don't use that bit for skyscrapers, but we might when we build a playhouse for our kids.
    Last edited by ManiacDan; August 29th, 2012 at 09:12 AM.
    HEY! YOU! Read the New User Guide and Forum Rules

    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin

    "The greatest tragedy of this changing society is that people who never knew what it was like before will simply assume that this is the way things are supposed to be." -2600 Magazine, Fall 2002

    Think we're being rude? Maybe you asked a bad question or you're a Help Vampire. Trying to argue intelligently? Please read this.
  6. #4
  7. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2012
    Posts
    9
    Rep Power
    0
    Hello! I'm the author. I don't know why I keep typing things someone please stop me.

    Originally Posted by ManiacDan
    First, let me say that PHP isn't perfect. ... But that doesn't mean it's bad design, just that there's quirks, like any well used system.
    This is a preface to many a rebuttal, and you've made the same subtle mistake: you've declared PHP not to be "bad", but not redefined what you consider "bad" to be. Is there a bad programming language? If yes, what is it and why? If no, you are wearing quite powerful rose-colored glasses and this entire discussion is pointless.

    Originally Posted by ManiacDan
    Now, having read this before, I know that he goes into defense mode over this statement later, but I'll go ahead and attack it now: Show me the faults in facebook. Show me where wikipedia falls down when you touch it.
    I don't use Facebook. For an anecdote about Wikipedia: a number of common templates are locked, because editing any of them would apparently cause so much load it would effectively take the site down.

    Originally Posted by ManiacDan
    Find the design flaws in vbulletin, wordpress, or any of the other toolsets that would be at all analogous to a house "where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards."
    I am, at this very moment, looking at a page whose URL is "newreply.php?do=newreply&p=2816580".

    Wordpress doesn't have a great reputation for security. A lot of that is the fault of its plugin ecosystem, but it's all still PHP.

    Originally Posted by ManiacDan
    Predictable - The author states that it's the language's responsibility to be understood by everyone who uses it, rather than the builder's responsibility to understand their tools.
    Well, um. Yes, I do. Languages are tools, as you say, and tools exist to help me solve problems. Some learning is obviously required to use a tool effectively, but there comes a point where the tool is introducing novel and unnecessary problems of its own.

    Originally Posted by ManiacDan
    Just look at his list of "surprises": mysql_real_escape_string? OH MY GOD! SHOCKING! What the hell is he talking about?
    The fact that there's a function called mysql_escape_string which categorically does the wrong thing, and the solution was to introduce a new function rather than fix the old one (which was entirely possible to do: the "real" function comes from C where there's no overloading, but PHP is not bound by such constraints).

    Originally Posted by ManiacDan
    And E_ALL? How is a constant name (which resolves to -1 anyway) a "surprise"? The list of error-level constants is in the manual. they all begin with E_ and then give what they describe. E_ALL is all. E_STRICT is strict. E_WARNING is warings. This is surprising?
    You've unwittingly stumbled across exactly what I'm complaining about: E_ALL is not all. It's everything except E_STRICT.

    Originally Posted by ManiacDan
    This guy should stay away from haunted houses.
    Are you saying PHP is a haunted house?

    Originally Posted by ManiacDan
    Consistent - Apparently things that look the same should work the same in a programming language? And if you know one part you should be able to understand other parts?
    This is written sarcastically, yet you conclude that I'm correct.

    Originally Posted by ManiacDan
    Concise - He makes statements about "boilerplate" a number of times, but never defines the term or tells us what he's talking about.
    The meat is below. I tried to keep this stuff short. Ish.

    Originally Posted by ManiacDan
    It includes time-saving functions like usort(), file_get_contents(), and other functions which in C++ would take pages of code.
    How much C or C++ have you written? Either of these operations would take half a dozen lines. Not particularly terse, but not pages either.

    Originally Posted by ManiacDan
    Of course, it also requires error checking, which seems to be what he's complaining about. He lists error-checking as boilerplate. I don't know how Python handles it, but generally as a programmer I'd like to know if a file operation failed.
    You have again stumbled into agreeing with me. In Python, if I open a file and forget to check whether it succeeded, an exception is raised. I am forced to know if a file operation failed. In PHP, I get a falsey value, which will merrily continue through the rest of my code producing more falsey values unless I explicitly check for it everywhere.

    Originally Posted by ManiacDan
    However, which is more boilerplate: if ( !( $file = fopen('file.txt', 'w') ) ) or a try-catch block?
    That's the point: the try block is zero boilerplate, because it's optional. If I leave it out and an error occurs, my program stops. In PHP, my program continues and likely does the wrong thing, with results that may range from confusing to disastrous.

    Originally Posted by ManiacDan
    Reliable - This, again, is him assuming that it's the language's responsibility to be understood, rather than his responsibility to understand it.
    I do not understand why you think this is unreasonable. Of course a language should strive to be understood. Languages are meant for humans.

    Originally Posted by ManiacDan
    The == operator is listed as "flaky." The == operator is the core of loosely typed languages, and is immensely powerful. He thinks it's flaky because he can't wrap his brain around loose comparisons.
    Weak comparisons are only occasionally what you want, and the rest of the time, they pile a lot of semantics onto what should be a very simple operation. JavaScript's == is somewhat less weak than PHP's, yet every JS best-practices or style guide I've ever seen has strongly advised never using == anywhere.

    Originally Posted by ManiacDan
    His second example is a by-ref loop, something which exists in all programming languages.
    This is patently false. No such concept exists in Python, C, Ruby, Haskell, shell, OCaml, Java...

    Originally Posted by ManiacDan
    Who can solve any problem when given just the error type, line number, function name, data type, prose description of the error, and potential fix? That's ridiculous!
    Python provides stack traces out of the box. If you get along without them just fine, that's great, but dying in library code without the slightest clue how you even got there will make you miss them real quick.

    Originally Posted by ManiacDan
    Finally, his argument of "the largest and most popular websites in the world, designed and written by the smartest programmers in the world, don't prove anything" is laughable. The conscious choices of almost every single web engineering team worth a damn do, in fact, count as proof that the tool they've chosen is worthwhile.
    Almost every single web engineering team? Google is Python, Java, Go. GitHub is Ruby. Yelp is Python. Reddit is Python. Amazon is Java and a smattering of various others. Instagram is Python. eBay is Java. Slashdot is Perl. Quora is Python. LiveJournal is Perl. Twitter is Ruby. YouTube is Python. PayPal is Java. Pinterest is Python. Blogspot is Python. Craigslist is Perl. Disqus is Python. Dropbox is Python. bit.ly is Python. Foursquare is Scala.

    The vast majority of PHP-powered websites (like, for example, this one) are just based on a package that happens to be written in PHP. I rarely see big new interesting projects started in PHP.

    Originally Posted by ManiacDan
    It will keep doing its best and instead of a blank screen (or a blue one) maybe a bad programmer will get her site's navigation bar with some errors underneath it.
    My error pages all include the site's navigation, too. Yet I know for certain that my program won't do something wrong.

    Originally Posted by ManiacDan
    So wait...you're telling me...different languages can build on each other, but an expert in one isn't automatically an expert in the other? Alert NASA, we have a breakthrough in human understanding. Languages are different. That's the point of making new languages.
    Short of a compelling reason otherwise, languages tend to reuse syntax from each other to facilitate learning them. Adding the same functionality with different syntax from every other similar language is highly questionable.

    Originally Posted by ManiacDan
    I don't understand it and therefore it's wrong." If you want to understand how weak typing conversions work, you could look in the manual for the chart, or you could read my article on it.
    I emphasize here that == necessitates both a chart and an article explaining how it works.

    Originally Posted by ManiacDan
    From the man who complained about the syntax of arrays, namespaces, and type conversions literally 2 sentences prior.
    Sure. PHP could use more syntax, and the syntax they're adding is wacky. These are consistent beliefs.

    Originally Posted by ManiacDan
    First of all, let me start by saying that when he said the line he discovered was "somewhere in the manual," it was deep into the manual entry for complex system-level error-handling functions and was specifically designed to suppress errors in a weird way so that you could see how error-screaming works.
    I was not aware that opening files is such a complex and perilous affair in PHP.

    Originally Posted by ManiacDan
    Except the docs DO say what happens when the function fopen fails: it returns false. It's in a nice blue box labeled "returns." Can't miss it.
    So is there no way to discern between a failure related to php.ini lockdown and a failure related to a missing file, short of adding a custom error handler function for the sake of this one function call and immediately removing it?

    Originally Posted by ManiacDan
    Line-level error suppression is a powerful feature, I'm glad to use a language which supports it.

    System-level forcing of all errors is another powerful feature, I'm glad I don't have to go find ever @ sign in my code when I'm debugging something weird.
    I'm not sure how to respond to this. You're glad you can suppress errors by line, but admit that it causes problems when your program goes wrong and you don't know why. This is exactly the situation I have a problem with: it's easier to wave errors away than to do anything useful with them or even detect where they happened.

    Originally Posted by ManiacDan
    Is it just me, or should every web language have server-level error reporting configuration? What does Python do? Just spit all errors to the screen no matter what? If you want to log to a file, you have to do that by hand for every error? That sounds awful. Or he's full of it.
    Most platforms will dump a stack trace to your terminal and/or show you a big screenful of debugging information in-browser. Some (generally Python, I believe Perl and Ruby, surely others) also have interactive web debuggers that show local variables in every stack frame and let you examine the state of your program when it died. It's pretty slick.

    Are you not familiar with anything besides PHP? It's strange you keep knocking on me for presumably not knowing PHP, yet you make wild guesses about a language you admit you don't understand and bash it on those imagined grounds.

    Originally Posted by ManiacDan
    Server-level configurations are pretty handy and remove a lot of boilerplate, don't you think? Good thing removing boilerplate was one of his biggest criteria back at the beginning.
    Boilerplate is useless noise. There's such a thing as useful noise.

    But this is about implicit global state within the language itself, not php.ini.

    Originally Posted by ManiacDan
    It's purely a web language, and nothing else. Websites don't need threads, because if they take longer than a second to run they've failed. Again, fundamental lack of understanding.
    Why does this pure web language expose low-level socket functionality?

    People, tragically, do write things besides websites in PHP. I'd rather they didn't, but if they're going to, it's strange to not give them useful tools for doing so.

    Originally Posted by ManiacDan
    Once again, if this person would take 10 minutes to attempt to understand loosely typed languages, this would all make sense. These functions return the index of the item found. if no item is found, they return false. That sounds really powerful, and I'm not sure why it's even a complaint.
    The error value is equal (==) to a valid return value. That is bad. That is very nearly the same problem json_decode has (a problem you just agreed with), except that === can save you from it. But you also began this rebuttal by singing the praises of ==.

    Originally Posted by ManiacDan
    C and Python crash fatally, potentially destroying the memory space of other programs. Got it.
    What? Not only is this totally impossible (kernel memory protection, etc.), but any language higher-level than C handles exceptions by unwinding the stack, not just exploding everywhere.

    "Blow up" is a euphamism for "raise an exception", not "literally make your CPU explode". Somewhere in here lies a gross misunderstanding of how computers work.

    Originally Posted by ManiacDan
    So basically, if you don't include the right boilerplate around other languages, they fatally crash and destroy their state, potentially also destroying neighboring programs in memory. However, if you do the same erroneous code in PHP, it continues to work with slightly unexpected results. Tell me again why "keeps working" is a problem?
    It doesn't keep working. You just said it produces unexpected results. That's the opposite of "working". You are arguing for a language that helps your program do something other than what you wrote it to do.

    Most languages in PHP's niche will detect the error and expect you to deal with it. If you don't, they will stop, rather than do something potentially disastrous like delete the first item from a list when the item you search for doesn't exist.

    Originally Posted by ManiacDan
    Plus, for what might be the 10th time, he just plain doesn't understand loosely typed languages. Yes, false == zero. That's actually an incredibly powerful feature of the language.
    You have said this multiple times now, but have not yet demonstrated why or how it's powerful. I believe I gave enough examples to the contrary in my article.

    Originally Posted by ManiacDan
    Look, here it is: "!== false". Oh man, look out. That nearly broke my fingers I typed for so long.
    More extra code to remember to add every time you do something as simple as look for a thing in a group of things.

    Yes, I'm sure you'll remember. Most of the time. But people are fallible, and we invented computers so that they could do boring useless work for us.

    Originally Posted by ManiacDan
    Quite literally damned if you do, damned if you don't. He simultaneously complains about PHP doing something, then not doing that same thing.
    I pointed this out not because I like overloaded +, but because it's an odd inconsistency. Even PHP doesn't want to drink all the weak typing Kool-Aid.

    Originally Posted by ManiacDan
    His second fundamental misunderstanding finally rears its head here: Symbol tables. PHP doesn't use variables like other languages, it uses symbol tables.
    Yes, yes. So does Perl. So does Python (more or less).

    Originally Posted by ManiacDan
    PHP does in fact have references, and pass-by-identity (objects are always passed by reference).
    Perl's references are not C++'s references; they are more like pointers that you can't do arithmetic on. PHP has no such concept.

    Originally Posted by ManiacDan
    "PHP is too confusing, I have to memorize so many things! Waaaaaah! In addition, there's aliases for things so if I forget and use the wrong one it will still work! PHP IS AWFUL!!"
    Similar things should look similar; different things should look different. In C (the source of this syntax), "float" and "double" are different things. PHP's use of both would seem to suggest that they're different things here, too, but they aren't; they're just aliases that add more special junk to the language.

    Originally Posted by ManiacDan
    "I don't read my log files, what kind of programmer would ever use error logs to debug? That's stupid! My website should just die with a white screen and a 'Sorry!' message whenever there's an error so I know to go try to remember where I put the error logs"
    Clearly you don't remember the bad old days of CGI, which had precisely this same behavior, and which confused no end of beginning programmers.

    Originally Posted by ManiacDan
    As stated above, E_STRICT is an error-level constant (hence the E_) and is well defined in the manual.
    No, it isn't. There is no comprehensive list of what triggers E_STRICT. Compare to Perl's "strict" module (likely inspiration for E_STRICT), which has a long list of exactly what problems it prevents in its documentation, and even lets you turn certain checks on or off.

    Originally Posted by ManiacDan
    Are there interpreted languages which throw in-application exceptions instead of language-level errors when they encounter fatal or parse errors? I don't think there are
    I'm glad you bothered to check on this before making a broad statement about dozens of languages. Yes, for what it's worth, Python raises a SyntaxError when it encounters... um, a syntax error.

    Originally Posted by ManiacDan
    I think the author doesn't understand interpreted languages vs compiled ones.
    Are you suggesting that compiled languages could throw exceptions at runtime for syntax errors? Interpreted languages are the only ones where this is even possible!

    Originally Posted by ManiacDan
    Anyone else feel like scrolling up to where he complains about function names being case-insensitive? No?
    They clearly have canonical names: the ones in the manual. If they were intended to be camel-cased, they'd be documented as such, and certainly wouldn't have underscores more often than not.

    Originally Posted by ManiacDan
    Our dear author has not yet discovered the simplicity of $foo->bar. Either that or he has absolutely no understanding of how objects work in ANY language.
    I suspect you have no idea what I'm talking about here.

    When you say `$foo->bar`, many other languages can make "bar" be a special kind of thing that still looks like a regular attribute, but that runs code when read from or written to. This eliminates the need for boilerplate Java-style setters and getters; you can just let calling code assign to attributes normally, and do whatever validation you want transparently.

    The only way I could find to do the same thing in PHP is to implement __get and __set, which get called for any access of a non-existent attribute, and then have a big `if` tree checking the name.

    Originally Posted by ManiacDan
    Aside from demonstrating the "var" syntax (deprecated over a decade ago), this doesn't understand the complexities of designing a real system in PHP.
    Yes, I'm used to languages where designing a real system is not so complex.

    Originally Posted by ManiacDan
    Wow, that's an excellent point. I'm glad we're talking about a compiled language and not, for instance, PHP.
    Precisely. These features came from a compiled language, where they are almost kind of useful. Why do they exist in PHP?

    Originally Posted by ManiacDan
    Once again, who wants to volunteer to scroll up to where he complained about the shortcut array syntax?
    Valid. This was assembled right around PHP 5.4's release and uptake, and it got some heavy editing in the following weeks as a result. I'll fix this.

    Originally Posted by ManiacDan
    It's like the room is filthy, and the maid used floor polish that smells too strongly. One or the other.
    Both of those conditions can exist simultaneously. In PHP, they often do. A shiny floor does not a clean room make.

    Originally Posted by ManiacDan
    Because it's a loosely typed language perhaps? Because it's possible to use a variable without defining it, even constants, and therefore an unquoted bare string literal is assumed to be an undefined constant? Becuase you don't understand loosely typed languages?
    Weak typing has nothing to do with variable declaration.

    The point here is that this is another small way that the language is made awkward by its own... "flexibility".

    For what it's worth, even Perl (without strict) has the same bareword behavior, yet it allows creating a hash without quotes. That's why the => operator exists in Perl in the first place.

    Originally Posted by ManiacDan
    So "remember to use htmlspecialchars" doesn't count, but "remember to use marksupsafe" does? Gotcha.
    You misunderstand. There is nothing to remember: every value that gets put in your template gets HTML-escaped, unless you actively specify otherwise. You very rarely have to think about it at all, and when you make a mistake, you're going to over-escape something (and notice in development) rather than leave yourself an XSS hole.

    Originally Posted by ManiacDan
    Because his last example was a function call you had to wrap arounde every string, I'm going to go ahead and assume that's what he'd use to "prove" this point as well, if such a library is even available.
    Yes, libraries exist to do this, and it's usually built into the session support as well. I usually use the template system to add a csrf element to every opening POST form tag automatically.

    Originally Posted by ManiacDan
    There's no standard database API. Except for the standard one. But that one doesn't count because deep down below where you can see it, it doesn't call the same functions for each database.
    I was nitpicking something architectural here, but it seems my nitpick was wrong anyway.

    Originally Posted by ManiacDan
    This one I actually know nothing about. Do other languages have built-in user authentication which can work as a login system? So if I want to write a web login system in Python, there's a built-in language core module for that?
    Whatever web library you use for Python will likely have some kind of auth built in, sure. PHP, famed for being a web language, has nothing in the box. Though the recently-announced password API is a good start.

    Originally Posted by ManiacDan
    Again, I'm going to have to ask how Python does that. Does Python automatically sanitize plaintext output?
    Python template languages tend to.

    Originally Posted by ManiacDan
    Could this be because PHP interacts with half a dozen other languages? Sure, you can use "placeholders" (bound parameters) with SQL, but can you use "placeholders" with HTML forms? No, you need to sanitize your output.
    Sanitizing is entirely the wrong approach, but that's well beyond the scope of this squabble.

    Originally Posted by ManiacDan
    PHP was originally written to be super easy to use. As the featureset grew, they disabled some of the easier things. Register_globals is stupid today, which is why it's been deprecated for 10 years.
    It was stupid then, too.

    Originally Posted by ManiacDan
    There's a PHP.ini command to disable this, which is off by default.
    "Likewise."




    So.

    The bulk of your counter-arguments are that I don't understand weak typing (with no explanation of why weak typing is good), I don't understand PHP (with no explanation of why PHP is good), or I'm a stupid dumbface. The rest meanders from fatal misunderstandings of modern operating system architecture to tripping over exactly the same PHP pitfalls I'm complaining about. You also skipped over vast chunks of the original article. D+, see me after class.
  8. #5
  9. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4123
    Eevee, do you actually understand the HTTP protocol and specification?

    If so, you will probably see why php has been developed in the manor it has been. If not, then....well we'll probably have to agree to disagree and leave it there.

    The reason I ask that is because I saw this in your response to dan:

    I am, at this very moment, looking at a page whose URL is "newreply.php?do=newreply&p=2816580".
    That's http for you, not php. And to think it is to do with php shows that you have a fundamental lack of understanding in what http and php is trying to achieve.

    I have no doubt that you know a lot about Java, C (++) and python but PHP has not been designed as a general purpose go-anywhere do-anything language. It was geared towards generating dynamic textual content to be delivered over http and in this respect it has excelled beyond all expecations

    Then, as an open source popular language it has grown and evolved and can be used elsewhere. Whether it is the right tool for the job or not is down to the job, not the tool.

    However, delivering text over http is not the only possible use of php, so why should a language cover up XSS and XSRF and prevent SQL Injection? These are application-specific issues and not a requirement of a language.

    PHP's loosely typed structure gives it its power and its flexibility.
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  10. #6
  11. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2012
    Posts
    9
    Rep Power
    0
    Originally Posted by Northie
    Eevee, do you actually understand the HTTP protocol and specification?
    Sure. I've read most of it, piecemeal.

    Originally Posted by Northie
    That's http for you, not php. And to think it is to do with php shows that you have a fundamental lack of understanding in what http and php is trying to achieve.
    It has nothing to do with HTTP. The URL could just as well be /threads/1234/reply. HTTP doesn't care.

    It's a leaky abstraction, exposing that PHP still runs similarly to CGI by default. The application doesn't control its own URLs; they're a result of various interactions between the filesystem and web server. That's unfortunate.

    Originally Posted by Northie
    It was geared towards generating dynamic textual content to be delivered over http and in this respect it has excelled beyond all expecations...

    However, delivering text over http is not the only possible use of php, so why should a language cover up XSS and XSRF and prevent SQL Injection? These are application-specific issues and not a requirement of a language.
    How can you say both of these things in the same breath? PHP is designed for the web, and it's excelled at that despite missing crucial web-related features? But it's okay that those features are missing because PHP isn't just for the web?

    Either I judge PHP as a web language and thus criticize the incomplete web features, or I judge it as a general-purpose language and thus ignore the web features.
  12. #7
  13. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2012
    Posts
    1
    Rep Power
    0
    Originally Posted by Eevee
    Wordpress doesn't have a great reputation for security. A lot of that is the fault of its plugin ecosystem, but it's all still PHP.
    So if a car manufacturer makes a model with some defects then is every model that company ever makes instantly dangerous? Are all cars bad now? WordPress has suffered from a lot of holes that their team coded into the application.

    Lets not blame PHP for the shortcomings of that team in securing their application. It's not exactly an epic effort to make a PHP app secure, but they still screwed up.

    Originally Posted by Eevee
    Python provides stack traces out of the box. If you get along without them just fine, that's great, but dying in library code without the slightest clue how you even got there will make you miss them real quick.
    Using the error handler you can easily make PHP throw extensions for everything if you wish. I do this locally, then have it silently email me when things go wrong on the live server. The fact that I don't have to try and catch every potential everywhere means much less boilerplate code, I can just check for false values - but while developing I get a massive ERROR IN MY FACE, which is what I like about developing in Ruby.

    Originally Posted by Eevee
    I emphasize here that == necessitates both a chart and an article explaining how it works.
    No just a quick RTFM would suffice, but beginners need tutorials.

    Originally Posted by Eevee
    When you say `$foo->bar`, many other languages can make "bar" be a special kind of thing that still looks like a regular attribute, but that runs code when read from or written to. This eliminates the need for boilerplate Java-style setters and getters; you can just let calling code assign to attributes normally, and do whatever validation you want transparently.

    The only way I could find to do the same thing in PHP is to implement __get and __set, which get called for any access of a non-existent attribute, and then have a big `if` tree checking the name.
    Agreed, this can be rough at the moment and I do like how Ruby can let you assign methods as properties that look like property values, but some of this functionality is already proposed for 5.5 and looks a fair way along. I don't suffer for a lack of attr_accessor and soon I'll be able to use it anyway. Winner.

    Originally Posted by Eevee
    Both of those conditions can exist simultaneously. In PHP, they often do. A shiny floor does not a clean room make.
    Objection: Evasive?

    Originally Posted by Eevee
    Python template languages tend to.
    This is the crux of many of your arguments. Python ITSELF does not sanitise output, but the templating libraries do. So do templating libraries for Ruby, PHP and JavaScript. Mustache for example, will work the same in all languages. So how does that make Python better?

    You cannot say one language A is better, because it has a library that you could use. That argument is then instantly less valid if the language B has an identical library, or similar. That is just utterly ridiculous.

    Python has authentication? Believe it or not, there are PHP authentication systems too.

    I'd love it if you could redact those points from your blog.

    I'll leave you guys to hash out the rest of the meat in there, but those few points had me tickled after reading this.

    Comments on this post

    • Northie agrees
    • ManiacDan agrees : Holy crap it's Phil Sturgeon. Thanks for the backup!
  14. #8
  15. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2012
    Posts
    9
    Rep Power
    0
    Originally Posted by philsturgeon
    So if a car manufacturer makes a bad car, all cars are bad? WordPress has suffered from a lot of holes that their team coded into the application. So lets blame PHP?
    Figuring out what to blame is not an exact science, certainly.

    On the other hand, given that WordPress is one of the poster boys for how great and popular PHP is, it's at least worth some pause that WordPress has also been plagued by problems. If PHP can take all the credit for WordPress's existence and popularity, can it not take some of the blame for WordPress's faults? Surely a tool meant to make a whole microverse of programming more accessible is responsible for doing so safely as well.

    Originally Posted by philsturgeon
    Using the error handler you can easily make PHP throw extensions for everything if you wish. I do this locally, then have it silently email me when things go wrong on the live server.
    This seems like useful behavior to have as a default.

    I wince every time someone proposes I "just" rig a whole error/exception mechanism myself; I've spent more than enough time trying to make Perl's exception handling work reliably (including working with various incompatible exception handling mechanisms in third-party libraries all in use at the same time). I'm surprised the PHP community doesn't run into similar problems, but then again Perl has a huge code reuse culture. To a fault, even.

    I just want to throw stuff and maybe catch it, man.

    Originally Posted by philsturgeon
    The fact that I don't have to try and catch every potential everywhere means much less boilerplate code, I can just check for false values
    That sounds pretty boilerplatey. It's what you do in C, and is a large part of why writing C is monumentally tedious. The lack of return codes is possibly the #1 bragging point of C++.

    Consider that I don't actually care about most errors—for example, if my configuration file is missing, my program can't really do anything to fix it, so it might as well just die. Stopping the program is what you want more often than not, but in PHP you either have to remember to check return values and bail manually or let your program limp along and hope it leaves a useful trail of warnings so you can figure out what happened.

    Originally Posted by philsturgeon
    ...which is what I like about developing in Ruby.
    Since you bring it up, Ruby's inline `rescue` is pretty neat. Terrible shame that it can't filter out only particular exceptions, though.

    Originally Posted by philsturgeon
    This is a big crux of a lot of things too. Python ITSELF does not sanitise output, but the templating libraries do. So do templating libraries for Ruby and PHP. Mustache funnily enough works the same in all languages.

    For starters: You cannot say one language A is better, because it has a library that you could use.

    That argument is then instantly less valid if the language B has an identical library, or similar. That is just utterly ridiculous.
    I'm not saying Python is better because its templates do X Y Z.

    PHP has a default template language: itself. Python (for example) has no default template language.

    A beginner, or perhaps an intermediate, or anyone who just wants to Get Stuff Done right quick, will most likely tend towards PHP's default: PHP.

    Someone using Python in the same situation will (by necessity) use a little framework like Flask and whatever template system it comes with.

    The PHP dev will have to escape all untrusted data manually. The Python dev doesn't have to think about it.

    The problem is not that PHP doesn't have this cool auto-escaping. The problem is that PHP comes with an extremely accessible default templating system that lacks it. PHP provides a solution that's incomplete in subtle and dangerous ways. If PHP had no templating built in, I may not have even brought templating up.

    Originally Posted by philsturgeon
    I'd love it if you could redact those points from your blog.
    Doing so would be dishonest. One of the major things people praise PHP for is that it has web development stuff built in, and it's entirely fair to judge those features against the baseline of web development in other ecosystems. Especially when the built-in stuff causes genuine real-world problems.
  16. #9
  17. Sarcky
    Devshed Supreme Being (6500+ posts)

    Join Date
    Oct 2006
    Location
    Pennsylvania, USA
    Posts
    10,908
    Rep Power
    6351
    This is a preface to many a rebuttal, and you've made the same subtle mistake: you've declared PHP not to be "bad", but not redefined what you consider "bad" to be. Is there a bad programming language? If yes, what is it and why? If no, you are wearing quite powerful rose-colored glasses and this entire discussion is pointless.
    I'll use your definition of a "bad programming language" when you provide one. Don't get into a burden of proof argument with me, you started this conversation.

    For an anecdote about Wikipedia: a number of common templates are locked, because editing any of them would apparently cause so much load it would effectively take the site down.
    And excel maxed out at 65535 rows for more than a decade. So? Users sometimes can't be trusted to do things. I bet those templates involve recursion or looping, or are used so commonly that to allow random nobodies to edit them would be disastrous in any language.


    I am, at this very moment, looking at a page whose URL is "newreply.php?do=newreply&p=2816580".
    GET parameters? OH MY STARS!! Seriously, is there a point there? You were even asked directly about this and didn't say anything to back it up. Does Python have some magical way of changing the way the webserver accesses files?

    Wordpress doesn't have a great reputation for security. A lot of that is the fault of its plugin ecosystem, but it's all still PHP.
    A lot of it is the fault of the fact that they allow third party code, but you still blame the underlying language, got it. PHP is written in C, so we can blame C directly. I'm with you.

    there comes a point where the tool is introducing novel and unnecessary problems of its own.
    You don't want to take the time to learn how interpreted and loosely type languages work. That's ok. I just think you're silly for deriding an entire language and community because you can't be bothered to learn something you don't understand.

    The fact that there's a function called mysql_escape_string which categorically does the wrong thing,
    Citation needed on "does the wrong thing." It escapes real mysql strings. As for the "real," the first version of the function is deprecated, but to maintain backwards compatibility they made a new one. Are you really complaining about backwards compatibility? Honestly?

    You've unwittingly stumbled across exactly what I'm complaining about: E_ALL is not all. It's everything except E_STRICT.
    Perhaps this would be true if the date wasn't right on your article, but since PHP 5.4 it WAS everything. Strict warnings aren't functionality warnings, they're more specific than that. E_ALL gave you warnings that would affect the functionality of your system, and that's all. E_STRICT would give you much more. Now they've made ALL include STRICT, mostly because of people whining about the definition of the word "all" meaning "everything" rather than "everything that's important to development." Past functionality which used "ALL" to mean "everything important" which has now been patched doesn't really smack of great arguments. In fact, much of your article is actually evidence that PHP is improving by leaps and bounds. "It was awful before but now it's great" isn't the best critique of something.

    Are you saying PHP is a haunted house?
    Oh, you got me. I was totally saying PHP was a haunted house, and not making fun of your inability to read the manual.

    The meat is below. I tried to keep this stuff short. Ish.
    And yes, like "bad language", you never bother to give a formal definition of "boilerplate." Do you mean error checking? That's how you use it in one paragraph. Or do you mean class constructs? Or maybe function declarations? You use an ambiguous term without defining it.

    How much C or C++ have you written? Either of these operations would take half a dozen lines. Not particularly terse, but not pages either.
    I've written a LOT of C and C++. I graduated to PHP because I believe it's a superior language. I've written sorting functions in C and C++, none of them were 6 lines, especially not sorting functions which sort nested lists of objects, which PHP can do in just a few lines.

    You have again stumbleYou have again stumbled into agreeing with me. In Python, if I open a file and forget to check whether it succeeded, an exception is raised. I am forced to know if a file operation failed.
    I'm not sure why you consider "the application died entirely" to be the desired behavior. If that's your personal preference, that's fine. PHP, as you've said, is designed to soldier on despite programmer error. It's more forgiving than the languages you prefer. Again, your personal preference for more unforgiving languages doesn't make everyone other than you a moron. PHP forgives errors. Python does not. You prefer an application which halts entirely on error. Good for you.

    the try block is zero boilerplate,
    Now we're getting into exactly why you need to define "boilerplate." I was under the impression that six lines of exception handling code around every operation was boilerplate. You've invented a new definition for the term. Please share with the group.

    I do not understand why you think this is unreasonable. Of course a language should strive to be understood. Languages are meant for humans.
    Your argument here is that programming languages are meant for humans? Not computers? Honestly? Doesn't FORTRAN have prose-style commands? Can't you stick to that? Why aren't you complaining about the Catch{} construct? Why is it called "catch"? That's so confusing! It should be called "fail," since the thing you "try"'d has failed. That makes more sense for humans, yet I don't see that argument anywhere on your site.

    Weak comparisons are only occasionally what you want,
    Says a man who prefers strongly typed languages. I prefer loosely typed languages, and honestly I don't care if the return value is "", 0, null, or false. "Not something useful" is what I care about. You disagree. That doesn't make either of us stupid. You seem to think I and my friends are stupid. You're sorely mistaken.

    JavaScript's == is somewhat less weak than PHP's, yet every JS best-practices or style guide I've ever seen has strongly advised never using == anywhere.
    JavaScript is not a loosely typed language. Maybe if it was, the imaginary best practices guides you faux-cite would have warnings about ==.

    This is patently false. No such concept exists in Python, C, Ruby, Haskell, shell, OCaml, Java...
    Really? You can't loop through a list/array/hash by reference in those languages? Sounds like a failure of those languages.

    dying in library code without the slightest clue how you even got there will make you miss them real quick.
    What PHP errors did you get that couldn't be solved in just a few minutes? I'm honestly asking. I even read all your hat-tip sites. The "worst" error I came up with is "unexpected << (T_SL)".

    Almost every single web engineering team? Google is Python, Java, Go. GitHub is Ruby. Yelp is Python. Reddit is Python
    Hooray, you found popular websites using other languages. All of your examples also prove that C++ is bull and nobody should use it. Half of them argue against python. Care to argue that? You're missing the point entirely, probably on purpose because you know your statement of "the wikimedia and facebook teams willingly chose an inferior language" is patently false.

    The vast majority of PHP-powered websites (like, for example, this one) are just based on a package that happens to be written in PHP. I rarely see big new interesting projects started in PHP.
    textbook confirmation bias. I've worked for 5 major companies in the last 10 years. Social networks, hosting companies, payment processors, auction houses, a ll of them written in PHP from the ground up.

    My error pages all include the site's navigation, too. Yet I know for certain that my program won't do something wrong.
    Define "wrong." You seem to think it means "rendering something that you didn't expect." As a user of your website, I would consider it "dying with nothing but an error." You have a different definition of "doing it wrong" than I do. And again, that doesn't make you a moron.

    I emphasize here that == necessitates both a chart and an article explaining how it works.
    Well with loosely typed languages, it's a complex topic. You yourself linked to a book about python. Python, by your logic, is therefore too complicated. Right? Or maybe programming is hard and you haven't taken the time to understand loosely typed languages.

    Sure. PHP could use more syntax, and the syntax they're adding is wacky
    Again, damned if you do, damned if you don't. You complain that they need new syntax. You make zero recommendations. The add new syntax. You complain it's not "right." Boo hoo for you.

    I was not aware that opening files is such a complex and perilous affair in PHP.
    Go read again. The function chosen was completely random. the purpose of the manual entry you found was not to illustrate file opening.

    So is there no way to discern between a failure related to php.ini lockdown and a failure related to a missing file, short of adding a custom error handler function for the sake of this one function call and immediately removing it?
    Wait..what? When the function fails to open the file, FALSE is returned. Always. Always. An error is printed to the end-user's screen if you have error_reporting set to the proper level and the error is not specifically suppressed, but basic error functionality of the language is not affected. You get that, right?

    I'm not sure how to respond to this. You're glad you can suppress errors by line, but admit that it causes problems when your program goes wrong and you don't know why. This is exactly the situation I have a problem with: it's easier to wave errors away than to do anything useful with them or even detect where they happened.
    I admit that when I write code in which the error condition doesn't matter, it's ok to ignore them. If you can honestly swear in court you've never writen an empty catch{} block, this point counts. Otherwise, you're still grasping at straws.

    Most platforms will dump a stack trace to your terminal and/or show you a big screenful of debugging information in-browser.
    This is a massive, major security flaw. Can you not turn that off in Python, ruby, and other languages? That's awful. The end-user gets to see your directory structure, file names, and stack trace? How do these sites survive?

    Unless you mean that they do have a server-level variable to turn that information off, just like PHP does. Which would make your point entirely nonsensical. You can't possibly mean that though.

    Are you not familiar with anything besides PHP? It's strange you keep knocking on me for presumably not knowing PHP, yet you make wild guesses about a language you admit you don't understand and bash it on those imagined grounds.
    I'm proficient in a dozen languages. If you haven't figured out I'm lampooning you by now, ignorance of PHP is not your biggest problem.


    But this is about implicit global state within the language itself, not php.ini.
    shame you complained about in-language boilerplate directly, like C API error checking, etc. Read your own article again before you reply.

    Why does this pure web language expose low-level socket functionality?
    I've used it before. Why does Python have access to files? Why does Perl access memory? Why are you making these points? The universe's ineffable questions.

    The error value is equal (==) to a valid return value. That is bad.
    And, like I said, you get a point for this specifically as it relates to json_decode. Core functions don't throw exceptions, it's one of the design philosophies of the language. In the extremely specific case of json_decode, you've made a valid counter-argument to that rule. I said you were right, and you're still arguing. You are not correct, however, for strpos. It's not possible, ever, for strpos to return FALSE as a valid return value, because FALSE is not a number. json_decode is the only example which provides a counter-point to "core functions don't throw exceptions." The rest represent, again, your misunderstanding/dislike of loosely typed languages.

    What? Not only is this totally impossible (kernel memory protection, etc.), but any language higher-level than C handles exceptions by unwinding the stack, not just exploding everywhere.
    You have just declared buffer overflow attacks impossible. Congratulations.

    It doesn't keep working. You just said it produces unexpected results. That's the opposite of "working". You are arguing for a language that helps your program do something other than what you wrote it to do.
    Maybe you don't write websites. "content printing" is the most important thing. We need content. Google indexes content. If google indexes 50,000 warnings and then the original post in this thread, it's better than a "whoops" page. That's what I mean by "keeps working." It continues executing. If it can't figure out the navigation, it moves on to something else. Much like an industrious human worker would, in fact. If I had employee who left for the day every time he couldn't understand a ticket, even with other tickets in his queue, I would fire him.

    Most languages in PHP's niche will detect the error and expect you to deal with it. If you don't, they will stop, rather than do something potentially disastrous like delete the first item from a list when the item you search for doesn't exist.
    Most languages in PHP's niche? I'll admit I'm not a Ruby expert, but to my knowledge that's the only language in the "primarily designed to be a web language" niche. Does Ruby die the instant it encounters something unexpected? Seems like PHP is more able to make stuff appear on the screen. Remember, "stuff appearing on the screen" is the core goal of web languages, as long as said "stuff" isn't errors which convey critical system security information.

    You have said this multiple times now, but have not yet demonstrated why or how it's powerful. I believe I gave enough examples to the contrary in my article.
    The concept of "not something useful" is very powerful. "some kind of failure" is equally powerful. Loosely typed languages, especially those designed for the web, need some sort of "close enough" comparison. Every single user input has to be a string, that's how web servers work. Casting strings to int to compare them to other ints is useless in a web language. Compare the string to the int.

    Also, you absolutely have not provided any examples about how loosely typed languages aren't powerful, all you've done is complained about the concept being difficult for you personally.

    More extra code to remember to add every time you do something as simple as look for a thing in a group of things.
    You have an editor which wraps every line of executable code in a try/catch block automatically? That's pretty awesome! What editor do you use? Because I'm pretty sure you've been making the argument that catching exceptions is somehow easier than checking for a FALSE return value, your editor must be inserting the 4-6 lines of try/catch around all your statements for you.

    I pointed this out not because I like overloaded +, but because it's an odd inconsistency. Even PHP doesn't want to drink all the weak typing Kool-Aid.
    Once again you've used "not like a language I like" as proof PHP is bad. Prove . vs + is bad. Otherwise, this argument makes no sense. All you're doing in this point is whining that it's not like Perl. Which, incidentally, makes a distinction between 10.2 and 10 . 2. PHP's dot operator is for concatenation, and plus is for addition. Believe it or not, because the variables are loosely typed, the operator determines the operation and not the variable type (since there isn't one). If PHP were to make dot and plus both do the same thing, you wouldn't be able to add an integer to a numeric string. Currently, I can do that in PHP, which is yet another benefit of a loosely typed language.

    Yes, yes. So does Perl. So does Python (more or less).
    More or less? So...not?

    Perl's references are not C++'s references; they are more like pointers that you can't do arithmetic on. PHP has no such concept.
    PHP is a higher level language than the ones you prefer. It has no direct memory access. Sorry if that upsets you, but it's not a design flaw, it's a conscious decision. You don't control the memory access in PHP any more than you control the memory access of Excel.

    Similar things should look similar; different things should look different. In C (the source of this syntax), "float" and "double" are different things.
    And yet, you still haven't grasped that your hatred of PHP stems from your fundamental misunderstanding of loosely typed languages. PHP has a "numeric" type. If you, the programmer, need it to be more specific than "a number," you have that option. Otherwise, it's a number.

    PHP's use of both would seem to suggest that they're different things here, too, but they aren't; they're just aliases that add more special junk to the language.
    "PHP's use of two words to mean the same thing seems to suggest that they're different, but they're actually the same." Welcome to language. This is a big|huge|colossal|gigantic|gargantuan|large|ample|sizable|prodigious|elephantine|extensive|grand|hug e|enormous|major misunderstanding on your part. Again: different words can mean the same thing. You're not allowed to complain about esoteric syntax as well as forgiving synonyms in the same post. Either you hate that "float" and "double" are the same, or they represent unnecessary graft, not both.

    Clearly you don't remember the bad old days of CGI
    Because we should base modern language decisions on ancient problems, right? that's how progress is made: through focusing on problems in the infancy of the field.

    I'm glad you bothered to check on this before making a broad statement about dozens of languages. Yes, for what it's worth, Python raises a SyntaxError when it encounters... um, a syntax error.
    Python, an interpreted language, throws an in-language catchable exception for bad syntax? You're right, I did not know that. If I did:
    Code:
    try { e89212j2 @&*#$(*#YNFf eff }
    in Python, I could catch the error in a catch{} block? That's handy, you're right. I never tried that when I was writing python. Another point, if this is in fact accurate. I attempted to do this in the python interpreter, but it bombed out the instant I input invalid syntax and wouldn't allow me to get to the except.

    Are you suggesting that compiled languages could throw exceptions at runtime for syntax errors? Interpreted languages are the only ones where this is even possible!
    You stated that compiler errors are separate from exceptions. I noted that interpreted languages (being NOT COMPILED) are not able to throw compile errors. Not sure why you think I was suggesting the opposite, but the opposite of things tends to be your theme.

    When you say `$foo->bar`, many other languages can make "bar" be a special kind of thing that still looks like a regular attribute, but that runs code when read from or written to. This eliminates the need for boilerplate Java-style setters and getters; you can just let calling code assign to attributes normally, and do whatever validation you want transparently.
    Is there a language which can override setters without...overriding setters (Edit: I see Mr Sturgeon speaks to Ruby's ability to make a function into an attribute directly)? PHP allows direct setting and getting of attributes. If you wish to override them, that functionality is also available. What is your point here? Oh wait:

    __get and __set, which get called for any access of a non-existent attribute, and then have a big `if` tree checking the name.
    One of the functions you complained about for checking existence does, in fact, check for object attribute existence as well. No big IF tree required.

    Yes, I'm used to languages where designing a real system is not so complex.
    Someone call Gabe Newell. C++ is not complex. He should change his keynote. Really? You're making this
    Weak typing has nothing to do with variable declaration.
    Except it absolutely does. This is the part you still don't get. Everything is weakly typed, even undeclared/undefined variables. They're all 'null' until proven otherwise.

    For what it's worth, even Perl (without strict) has the same bareword behavior
    "I wish PHP had a strict mode" is the core of your argument. I admit, when I went from VBA to PHP in high school, I said the same thing. Doesn't mean PHP is wrong.


    You misunderstand. There is nothing to remember: every value that gets put in your template gets HTML-escaped, unless you actively specify otherwise. You very rarely have to think about it at all, and when you make a mistake, you're going to over-escape something (and notice in development) rather than leave yourself an XSS hole.
    So you complain about PHP's ease-of-use features, then complain about PHP not making plaintext output automatically encoded? Choose one.

    Whatever web library you use for Python will likely have some kind of auth built in, sure. PHP, famed for being a web language, has nothing in the box
    Whichever outside-the-box python library you use will have one, but PHP doesn't have one in the box. Really? You keep talking about third party python solutions being better than first party PHP solutions, then discounting the third party PHP solutions as invalid.

    Python template languages tend to.
    Outside the box solutions. You complain about those ad nauseum for PHP, but they're valid arguments for python.

    The bulk of your counter-arguments are that I don't understand weak typing (with no explanation of why weak typing is good), I don't understand PHP (with no explanation of why PHP is good), or I'm a stupid dumbface.
    Why weak typing (and therefore PHP) are good are "outside the scope of this squabble" (as you said about one of your points earlier). Weak typing, as I've said, is very useful for web languages where everything is a string anyway since it comes from string headers. PHP is good because it allows for rapid prototyping, fast new user integration, and ease of use. Whether or not you disagree with these points is irrelevant, since as you said it's outside the scope of this discussion.

    The rest meanders from fatal misunderstandings of modern operating system architecture to tripping over exactly the same PHP pitfalls I'm complaining about
    Where?

    You also skipped over vast chunks of the original article. D+, see me after class.
    I skipped any bits that could have been summarized by "PHP is not like python and that makes my panties bunch." sorry if I didn't provide a literal sentence-by-sentence critique of why you're wrong. I replied to at least half, making your statement patently false.

    Northie and others provide more...but I'll reply anyway!!

    It has nothing to do with HTTP. The URL could just as well be /threads/1234/reply. HTTP doesn't care.
    Are you trying to say that other languages provide a method for overriding file-access methods for Apache? I admit, I've never tried mod_rewrite in other languages. Do they provide a way to opaquely modify apache's file access functionality? If so, that seems to be the kind of opaque functionality you hate in PHP.

    Figuring out what to blame is not an exact science, certainly.

    On the other hand, given that WordPress is one of the poster boys for how great and popular PHP is, it's at least worth some pause that WordPress has also been plagued by problems.
    Given the widespread distribution of Windows, it's at least worth some pause that Windows is written in C and is plagued by problems.

    PHP has a default template language: itself. Python (for example) has no default template language.

    A beginner, or perhaps an intermediate, or anyone who just wants to Get Stuff Done right quick, will most likely tend towards PHP's default: PHP.
    Are you suggesting that Python is incapable of string output? that seems like a pretty major limitation of a language if it can't echo plaintext output without importing a third party framework. Unless of course you're inventing new definitions for "templating languages."

    Sick of this. Dinner is ready. You've derided one of the most popular languages in the world because, frankly, you don't understand it. That's not our fault. Your defenses are admirable, but most of them still stem from pre-conceived hatred for PHP or misunderstandings of how it works.

    Comments on this post

    • Northie agrees : your points are valid, but rep (out of rep for you) mainly for the effort
    Last edited by ManiacDan; August 29th, 2012 at 09:00 AM. Reason: spelling, quote tags, language.
    HEY! YOU! Read the New User Guide and Forum Rules

    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin

    "The greatest tragedy of this changing society is that people who never knew what it was like before will simply assume that this is the way things are supposed to be." -2600 Magazine, Fall 2002

    Think we're being rude? Maybe you asked a bad question or you're a Help Vampire. Trying to argue intelligently? Please read this.
  18. #10
  19. Did you steal it?
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,072
    Rep Power
    9398
    I still think this thread can do good. I'mma unlock it in the morning when everyone is back to normal.

    Comments on this post

    • ManiacDan agrees : We're never normal.
  20. #11
  21. Sarcky
    Devshed Supreme Being (6500+ posts)

    Join Date
    Oct 2006
    Location
    Pennsylvania, USA
    Posts
    10,908
    Rep Power
    6351
    The thread is now unlocked, for those who were waiting.
    HEY! YOU! Read the New User Guide and Forum Rules

    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin

    "The greatest tragedy of this changing society is that people who never knew what it was like before will simply assume that this is the way things are supposed to be." -2600 Magazine, Fall 2002

    Think we're being rude? Maybe you asked a bad question or you're a Help Vampire. Trying to argue intelligently? Please read this.
  22. #12
  23. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Hi,

    I don't quite get the purpose of this thread. Is this fishing for compliments? Because in a PHP forum, it's pretty obvious that most will agree with you. Is this an angry expert discussion about every little detail of the article?

    I think it would be more interesting for others to get to some kind of essence.

    The reason I don't like PHP is because it's sloppy in every aspect. It's like a bad piece of code you just throw together to move on. Yes, it does work in the end. But it's stupid and ugly.

    Look at how carefully the object system of Ruby has been developed (or stolen from Smalltalk). You can actually see that some smart people have spend their effort on doing this properly. When I look at PHP, I just see a big pile of procedures carelessly thrown together.

    I'm also not aware of any other language that featured such brain farts as register_globals or magic_quotes or has so many deprecated functions rotting in its core. Isn't that yet another proof of how carelessly this languages was "designed"?

    Again: PHP does work -- just like bad code may work. But is that really all you expect from a language? That it somehow works? Aren't you seeking for more?

    I also doubt the assertion that sloppiness is user friendly. Well, if you're a kid and just started programming, then it may be nice if you at least see some output and not just a bunch of error messages. But the rest of your life as a programmer you'll fight sloppiness. Even hobby programmers today are rarely satisfied with only half of their page being displayed. Which means they have to struggle with .ini files and bit operations with strange integer constants.

    If PHP is really the best you can think of, I'm sorry for you.
    Last edited by Jacques1; August 29th, 2012 at 03:01 PM.
    The 6 worst sins of securityHow to (properly) access a MySQL database with PHP

    Why can’t I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  24. #13
  25. Sarcky
    Devshed Supreme Being (6500+ posts)

    Join Date
    Oct 2006
    Location
    Pennsylvania, USA
    Posts
    10,908
    Rep Power
    6351
    Look at how carefully the object system of Ruby has been developed (or stolen from Smalltalk). You can actually see that some smart people have spend their effort on doing this properly
    Ruby is dangerously random with objects. A ruby gem can alter the functionality of other objects, "patching" them to add or remove functions. From a friend of mine far more well versed in Ruby than I am:

    In PHP, you can have Pet, Dog, and Cat, right? Dog and Cat descend from Pet, and Dog has bark() and cat has meow(), right?

    Pet also has poopInYourShoe().

    So, in PHP, if you have a Dog, and a Dog extends Pet, you can Dog->poopInYourShoe() with impunity.

    In Ruby, you can have another module, called PooperScooper, that dynamically patched Pet to no longer have a poopInYourShoe().

    Completely unrelated.

    Including in a submodule of a submodule.

    Anywhere.

    BAM. Pet is now != Pet.

    SURPRISE

    So, Rails apps totally abuse this.

    Some dude installs version 1.5.89 of the Poop gem instead of 1.5.76, and that version of Poop patched Pet and Human to no longer have a poopInYourShoe() but the Cities object depends on this function for cop cars, what do you get?

    Cannot call poopInYourShoe in context copCar

    I'm also not aware of any other language that featured such brain farts as register_globals or magic_quotes or has so many deprecated functions rotting in its core. Isn't that yet another proof of how carelessly this languages was "designed"?
    PHP grew, it wasn't designed by a single committee of engineers. It responded to a changing web environment and adapted to new technologies. Quite successfully, since it powers the vast majority of websites. Things like magic_quotes were a good idea at the beginning of the language, and are now no longer a good idea, so they're deprecated. Rather than break everyone's code, deprecated functions live on in the code base heavily decked out in warnings so people know not to use them. The first result for "deprecated perl functionality" shows that perl has deprecated functionality that's still in the language for 15+ years, many of which represent seriously flawed thinking. And yet, Perl is still a very popular and absurdly powerful language.


    Again: PHP does work -- just like bad code may work. But is that really all you expect from a language? That it somehow works? Aren't you seeking for more?
    If this was a discussion about a language which wasn't far and away the most popular in the world, these arguments would make sense. Yes, I'm seeking more than "just works." As are facebook, wikipedia, drupal, wordpress, etc etc etc.

    I also doubt the assertion that sloppiness is user friendly
    Luckily nobody said that, so we can move on.

    Well, if you're a kid and just started programming, then it may be nice if you at least see some output and not just a bunch of error messages. But the rest of your life as a programmer you'll fight sloppiness.
    For some reason you've chosen to use the word "sloppy" instead of "resilient." PHP is capable of graceful degradation more than any other language, because even if it encounters something which other languages may die entirely on, it continues. I've seen websites render their main content without rendering navigation, social features, etc. But the content showed up and, most importantly, got seen by the customers and the indexing bots. This is the core argument, I think. You say "perfection or nothing." PHP devs like me say "get something out there." That's why PHP wins. First to market wins. Rapid prototyping wins. Getting something relevant on the screen wins. While you're busy trying to get your Ruby app to display your site 100% perfectly, mine is crapping out the main article contents with a weirdly misshappen sidebar and getting clicks and googlebot hits. "Perfection or nothing" is a valid design philosophy, I just don't think it applies to the web. It works great for the iPhone, but then again the iPhone didn't do MMS messaging for 5 years.


    If PHP is really the best you can think of, I'm sorry for you.
    While you're pitying us from your crystal tower, we'll be writing most of the websites in the world. Condescension doesn't work too well when you're talking about how dumb PHP is on a PHP powered website.

    There's plenty wrong with PHP. Loose typing is a double edged sword. The function library is awfully named and organized. It uses a bit too much memory, especially arrays. But it's still a better choice than everything else out there, in my personal opinion as well as in the statistics. Maybe in 10 years Ruby or Python will have more than a 5% market share of the web, and if that's the case I'll move on to those languages. Until then, PHP remains the workhorse of the web development community, and has only a few flaws, none of which prevent me from loving the language. For some, the underscores in html_entity_decode and the loose typing are enough to declare tens of millions of developers morons and 70% of webservers in the world wrong. I think that's a silly position, but at this point it's just you guys yelling "ya huh" over and over.
    Last edited by ManiacDan; August 29th, 2012 at 03:33 PM.
    HEY! YOU! Read the New User Guide and Forum Rules

    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin

    "The greatest tragedy of this changing society is that people who never knew what it was like before will simply assume that this is the way things are supposed to be." -2600 Magazine, Fall 2002

    Think we're being rude? Maybe you asked a bad question or you're a Help Vampire. Trying to argue intelligently? Please read this.
  26. #14
  27. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2012
    Posts
    9
    Rep Power
    0
    I came because I genuinely enjoy discussing programming language design, and I would direly like to do so, but this response is still full of needless vitriol to deflect criticism of (by your own repeated admission) the only language in this family you understand. I will happily play along as long as there is some useful content to respond to, but you would do well to learn something about Ruby or Python or even Perl so you have a basis of comparison against which to gauge PHP.


    Originally Posted by ManiacDan
    I'll use your definition of a "bad programming language" when you provide one.
    That was the point of the "stances" section.

    Originally Posted by ManiacDan
    I bet those templates involve recursion or looping, or are used so commonly that to allow random nobodies to edit them would be disastrous in any language.
    Difficult to say. But again, if PHP gets all the credit for Wikipedia's existence, it gets at least some of the blame for Wikipedia's problems.

    Originally Posted by ManiacDan
    GET parameters? OH MY STARS!! Seriously, is there a point there? Does Python have some magical way of changing the way the webserver accesses files?
    Non-PHP web applications generally don't map URLs to files at all; the application controls an entire branch of the hierarchy and gets to do whatever it wants. Your code can be arranged however you please.

    Originally Posted by ManiacDan
    A lot of it is the fault of the fact that they allow third party code, but you still blame the underlying language, got it.
    I was under the impression that the third-party ecosystem is a large part of Wordpress's success.

    Originally Posted by ManiacDan
    Citation needed on "does the wrong thing." It escapes real mysql strings. As for the "real," the first version of the function is deprecated, but to maintain backwards compatibility they made a new one. Are you really complaining about backwards compatibility? Honestly?
    mysql_escape_string does the wrong thing. The only problem with it was that it doesn't take a connection argument, so it can't take the current connection's character set into account when escaping. The C API had to add a new function to handle this, because C functions can't be overloaded. But PHP was under no such obligation, and in fact, most PHP mysql functions already assume a default connection if you don't provide one. PHP could have added this same behavior to mysql_escape_string and instantly fixed 99% of existing code; instead, they added the new function—which still doesn't require a connection argument—and left existing code to fix itself and future generations to trip over the historical wart.

    Originally Posted by ManiacDan
    Perhaps this would be true if the date wasn't right on your article, but since PHP 5.4 it WAS everything.
    Hey! I'm glad to hear it.

    Originally Posted by ManiacDan
    I've written sorting functions in C and C++, none of them were 6 lines, especially not sorting functions which sort nested lists of objects, which PHP can do in just a few lines.
    A few...?

    Code:
    items.sort(key=lambda item: item['name'].lower())
    I don't remember your elided challenge precisely, but hopefully close enough.

    Originally Posted by ManiacDan
    I'm not sure why you consider "the application died entirely" to be the desired behavior. If that's your personal preference, that's fine. PHP, as you've said, is designed to soldier on despite programmer error. It's more forgiving than the languages you prefer. Again, your personal preference for more unforgiving languages doesn't make everyone other than you a moron.

    I was under the impression that six lines of exception handling code around every operation was boilerplate. You've invented a new definition for the term. Please share with the group.
    You appear to believe, simultaneously, that every operation takes down my entire program and every operation has a try/except block around it.

    If you care about handling an error, sure, you can wrap it in a try block. If you don't care, it'll go up the stack until something does handle it or your program dies. My programs contain relatively few try blocks; the advantage is when I don't have one, the default behavior is to stop there and tell me what went wrong.

    Yes, my personal preference is for my program to stop running when it knows something unintended has happened. This is so fundamentally obvious to me that I hardly know how to argue it.

    Originally Posted by ManiacDan
    Your argument here is that programming languages are meant for humans? Not computers? Honestly?
    Of course they're for humans. If we only cared that computers could understand them, we could've stopped at assembly. New programming languages are invented to help humans express themselves more easily. Your processor doesn't care about weak typing or memory protection or even function calls.

    Originally Posted by ManiacDan
    Why aren't you complaining about the Catch{} construct? Why is it called "catch"? That's so confusing! It should be called "fail," since the thing you "try"'d has failed. That makes more sense for humans, yet I don't see that argument anywhere on your site.
    That doesn't make much sense. "Fail", as a verb, would suggest that it causes your program to fail. "Catching" an error is common programmer vernacular.

    Though for what it's worth, I don't use any languages where "catch" is the name of a block; Python uses "except", which reads slightly better, Ruby uses "rescue", and Perl... well, it's Perl.

    Originally Posted by ManiacDan
    Says a man who prefers strongly typed languages. I prefer loosely typed languages, and honestly I don't care if the return value is "", 0, null, or false.
    In these cases, you don't need ==. Even your own example code above merely used ! to test true vs false, which works just as well in a strongly-typed language.

    Weak comparisons primarily come into play when dealing with string input that you want to be a number. It's a miniscule burden to just parse the numbers when you get them and carry on with strong typing. Most of the time this is even done for you by a parser or form validator or database layer. I write strongly-typed code all the time and I very, very, very rarely care about conversions.

    Originally Posted by ManiacDan
    You seem to think I and my friends are stupid. You're sorely mistaken.
    I am sorry you take personal offense to criticism of a tool you use, but the only one throwing around insults to intelligence here is you.

    Originally Posted by ManiacDan
    JavaScript is not a loosely typed language. Maybe if it was, the imaginary best practices guides you faux-cite would have warnings about ==.
    This is completely wrong. Of course JavaScript is weakly-typed. Try it yourself.

    Code:
    console.log("3" + 4);    // "34"
    console.log(3 + "4");    // "34"
    console.log(3 + 4);      // 7
    console.log("5" * "6");  // 30
    console.log(3 == "3");   // true
    I'm apparently not allowed to post URLs, but have a look at jQuery's internal style guide or jslint and jshint's default settings.

    I see Mozilla explicitly recommends against ===, which is fascinating, but there's no explanation given.

    Originally Posted by ManiacDan
    Really? You can't loop through a list/array/hash by reference in those languages? Sounds like a failure of those languages.
    You just said you're familiar with C. I don't know why this would surprise you.

    I note you agreed with me that the infectious behavior of references is a sour point of PHP.

    Originally Posted by ManiacDan
    What PHP errors did you get that couldn't be solved in just a few minutes? I'm honestly asking. I even read all your hat-tip sites. The "worst" error I came up with is "unexpected << (T_SL)".
    I am thinking of Perl errors I've had to diagnose, because Perl also has the default behavior of merely spitting out the error message and file/line. When the file and line happen in some generic thing like a database library (or, worse, in C code), they are not all that useful.

    Originally Posted by ManiacDan
    Hooray, you found popular websites using other languages. All of your examples also prove that C++ is bull and nobody should use it.
    I'm okay with that.

    Is this sarcasm? Websites aren't usually written directly in C++. Some backend services, maybe, and Facebook has their compiler, but otherwise it's pretty rare.

    Originally Posted by ManiacDan
    Half of them argue against python. Care to argue that?
    Why would I? I don't expect everyone to use Python. Ruby is a decent language too. Java is certainly not for me, but there are plenty of people who get stuff done efficiently in it. Scala seems kind of neat. I don't mind that people use different tools.

    I'm actually pleasantly surprised by how often Python appeared on that list.

    Originally Posted by ManiacDan
    You're missing the point entirely, probably on purpose because you know your statement of "the wikimedia and facebook teams willingly chose an inferior language" is patently false.
    You said "almost every single web engineering team worth a damn". I found you some web engineering teams that I consider to be worth a damn but that don't use PHP.

    The Wikimedia and Facebook teams didn't choose the language at all. The guy who first sat down and started cranking out code chose the language. Everyone else has merely been adding to it. I don't fault them for not wanting to rewrite untold thousands of lines of code in another language. PHP isn't that bad.

    Originally Posted by ManiacDan
    textbook confirmation bias. I've worked for 5 major companies in the last 10 years. Social networks, hosting companies, payment processors, auction houses, a ll of them written in PHP from the ground up.
    Yes, what you just said is textbook confirmation bias. If you only know one web stack, of course all your web development jobs would be for PHP products.

    My worthless anecdotal evidence is based solely on what new things become popular enough to reach my ears. That's not inherently tied to what programming language they're written in.

    Originally Posted by ManiacDan
    Define "wrong." You seem to think it means "rendering something that you didn't expect."
    Well, yes. I wrote a program to render things that I expect. If it does otherwise, that's wrong.

    I have seen my fair share of weak typing bugs where a null value was treated as a zero and the program attempted to do something with that valid integer. If you take an algorithm and put in useless data, you will get useless (i.e., wrong) answers. Or you might get something dangerous, like querying mysql for your null and getting back an actual row. You don't know what will happen. It might be innocuous, it might be a severe logic error, it might be a security hole.

    Originally Posted by ManiacDan
    As a user of your website, I would consider it "dying with nothing but an error."
    I don't know how you see this playing out in practice, but when I encounter a PHP site that hit an error and tried to limp along anyway, it usually renders three lines of warnings, part of the site layout with no content, and three more lines of warnings. This isn't robust error handling; it's just whatever bits of the program weren't set ablaze by the original fire. It's certainly not any more useful to me than an error page, and it's a good bit uglier. I'd be mortified to serve my users such an ugly and useless page.

    Originally Posted by ManiacDan
    Well with loosely typed languages, it's a complex topic. You yourself linked to a book about python. Python, by your logic, is therefore too complicated. Right?
    Equality is conceptually simple to humans and ought to be conceptually simple in programming languages. Languages are rich things to humans and it's no surprise that programming languages follow suit.

    Originally Posted by ManiacDan
    Wait..what? When the function fails to open the file, FALSE is returned. Always. Always. An error is printed to the end-user's screen if you have error_reporting set to the proper level and the error is not specifically suppressed, but basic error functionality of the language is not affected.
    Yes, exactly. So if you want to know why the function failed—perhaps you want to fix it if it's a simple missing file error, but give up if it's a permission error—you have to add an error handler to intercept the string that would be printed, parse it to see what happened, then remove the error handler after the call.

    Originally Posted by ManiacDan
    I admit that when I write code in which the error condition doesn't matter, it's ok to ignore them. If you can honestly swear in court you've never writen an empty catch{} block, this point counts.
    Hmm. Maybe three times, total?

    But I can decide which errors to throw away, and then I don't need to disable error-ignoring globally to debug my program when something else goes wrong.

    Originally Posted by ManiacDan
    This is a massive, major security flaw. Can you not turn that off in Python, ruby, and other languages?
    Don't be silly. Such things are usually bound to localhost and only work when you're running the development server.

    Originally Posted by ManiacDan
    Unless you mean that they do have a server-level variable to turn that information off, just like PHP does.
    They do not. Live debugging is an extra feature added for development, not a default removed in production.

    Originally Posted by ManiacDan
    I've used it before. Why does Python have access to files? Why does Perl access memory?
    Because Python and Perl are general-purpose programming languages and these are general-purpose features.

    I didn't claim Python and Perl are intended for any particular purpose. You excused the lack of a feature in PHP on the grounds that you shouldn't need it for what PHP is meant for.

    I don't even like threads.

    Originally Posted by ManiacDan
    You are not correct, however, for strpos. It's not possible, ever, for strpos to return FALSE as a valid return value, because FALSE is not a number.
    But it does return 0 as a valid return value, because 0 is a number. And FALSE == 0. If you merrily accept strpos's return value and try to use it as a string index, PHP will allow it without warning.

    Code:
    error_reporting(E_ALL);
    $haystack = "hello world!";
    $needle = "foo";
    $pos = strpos($haystack, $needle);
    echo substr_replace($haystack, "bar", $pos, strlen($needle));
    # barlo world!
    I can easily envision more subtle problems in, say, parsing code.

    Originally Posted by ManiacDan
    You have just declared buffer overflow attacks impossible. Congratulations.
    Buffer overflow attacks target the program whose buffers are overflowing.

    Originally Posted by ManiacDan
    We need content. Google indexes content. If google indexes 50,000 warnings and then the original post in this thread, it's better than a "whoops" page. That's what I mean by "keeps working." It continues executing. If it can't figure out the navigation, it moves on to something else.
    Not necessarily better. If Google sees a "whoops" page (and corresponding 500), it's likely to try again later. If it sees 50,000 warnings, they'll drown out most of the thread and drop your pagerank.

    That aside, if you want to try very very hard to print out anything at all in any language, just slap a try block around the whole thing with some wimpy fallback (and logging!). You're guaranteed not to show something wrong, you have fine-grained control over what "navigation" means, and you can stop errors from propagating too far.

    You imply this is a big advantage, but even those few massive PHP sites—Wikipedia, Facebook, Tumblr—don't rely on this behavior. I've seen plenty of error pages from them, but I have never seen warning spew followed by a half-rendered skeleton of a page.

    Originally Posted by ManiacDan
    Much like an industrious human worker would, in fact. If I had employee who left for the day every time he couldn't understand a ticket, even with other tickets in his queue, I would fire him.
    I would certainly fire an employee who worked dutifully on ticket after ticket, despite never knowing what the problem was or how he should fix it.

    Originally Posted by ManiacDan
    Most languages in PHP's niche?
    High-level, procedural, dynamic, more-or-less-interpreted languages. PHP, Perl, Python, Ruby.

    Originally Posted by ManiacDan
    Remember, "stuff appearing on the screen" is the core goal of web languages, as long as said "stuff" isn't errors which convey critical system security information.
    It's funny you say that, since most PHP warnings I've seen reach my screen have revealed the directory tree and the host/port/name of the database.

    Originally Posted by ManiacDan
    Casting strings to int to compare them to other ints is useless in a web language. Compare the string to the int.
    Turn your string into an int as soon as you get it. This isn't uncommon advice in PHP, anyway. Now you know it's an integer, and you never have to worry about == doing something weird.

    Originally Posted by ManiacDan
    Also, you absolutely have not provided any examples about how loosely typed languages aren't powerful, all you've done is complained about the concept being difficult for you personally.
    I don't know how you reached that conclusion. I never said it isn't powerful; I said it's needlessly complex and causes unintuitive results, like that MD5 hashes might compare equal even when they're not, because PHP thinks they should be compared as floats.

    Originally Posted by ManiacDan
    You have an editor which wraps every line of executable code in a try/catch block automatically? That's pretty awesome! What editor do you use? Because I'm pretty sure you've been making the argument that catching exceptions is somehow easier than checking for a FALSE return value, your editor must be inserting the 4-6 lines of try/catch around all your statements for you.
    I have been, and continue to be, making the argument that the default behavior is more robust. If you don't check a return value, the rest of your program could do any crazy thing. If you don't catch an exception, whatever, maybe something further up the stack will.

    This isn't just me. A large part of C++'s very existence is owed to the tedium of checking return values in C—and the dangers of not doing so. Early Perl relied on return values, and now there are popular modules that replace all the builtin functions to make them automatically die on failure. Rust uses return values, but exploits its own type system to force you to check for failure. The return-value pattern is just not human-friendly.

    You direly need a new editor if that behavior would be difficult to implement, though.

    Originally Posted by ManiacDan
    Once again you've used "not like a language I like" as proof PHP is bad. Prove . vs + is bad. Otherwise, this argument makes no sense. All you're doing in this point is whining that it's not like Perl.
    Perl has a . operator. That's almost certainly where PHP got the idea.

    Originally Posted by ManiacDan
    If PHP were to make dot and plus both do the same thing, you wouldn't be able to add an integer to a numeric string. Currently, I can do that in PHP, which is yet another benefit of a loosely typed language.
    JavaScript is weakly typed and uses + for both operations, as shown above.

    Having two separate operators is stronger; it reduces the reliance on the types of the operands.

    Originally Posted by ManiacDan
    More or less? So...not?
    There are optimizations which skip the symbol table lookup. The use of a symbol table is just an implementation detail (and useful black-magic tool), not a highly-touted feature.

    Originally Posted by ManiacDan
    PHP is a higher level language than the ones you prefer. It has no direct memory access.
    Nor does Perl. Or Python, or Ruby. Again, please put a modicum of effort into learning something about other languages before drawing comparisons to them.

    Originally Posted by ManiacDan
    Because we should base modern language decisions on ancient problems, right? that's how progress is made: through focusing on problems in the infancy of the field.
    The rest of the sentence you quoted made clear that the very problem is that PHP is still handling errors the same way CGI did.

    Originally Posted by ManiacDan
    Python, an interpreted language, throws an in-language catchable exception for bad syntax? You're right, I did not know that. If I did:
    Code:
    try { e89212j2 @&*#$(*#YNFf eff }
    in Python, I could catch the error in a catch{} block?
    Not quite. (How would it reliably know where the try block ends?) Code is parsed, then executed. SyntaxError is thrown during parsing, but try blocks apply during execution. You can catch a SyntaxError when importing a module, or when manually parsing a string of code.

    Originally Posted by ManiacDan
    I attempted to do this in the python interpreter, but it bombed out the instant I input invalid syntax and wouldn't allow me to get to the except.
    You may notice that it bombed out with a SyntaxError.

    Originally Posted by ManiacDan
    You stated that compiler errors are separate from exceptions. I noted that interpreted languages (being NOT COMPILED) are not able to throw compile errors.
    You don't understand what's going on here. PHP (et al.) don't compile to a binary executable, but they do internally compile to their own flavor of bytecode before executing. That's why a syntax error anywhere in a file prevents the whole thing from running: PHP discovers the syntax error while compiling. Hence, compilation error.

    Strictly speaking, none of the languages we're talking about are interpreted. A truly interpreted language has no compile step; it's parsed and executed at the same time, and you'll only discover a syntax error if the program tries to run that line. Shell scripts are the only real mainstream example:

    Code:
    $ cat 0.sh
    echo foo
    
    echo bar
    
    echo "
    $ zsh 0.sh
    foo
    bar
    0.sh:6: unmatched "
    In most languages, this would refuse to run at all.

    Originally Posted by ManiacDan
    Is there a language which can override setters without...overriding setters (Edit: I see Mr Sturgeon speaks to Ruby's ability to make a function into an attribute directly)?
    Are you not aware of this feature at all? I'm talking about hooking the getting and setting of a single attribute:

    Code:
    class Foo(object):
        @property
        def bar(self):
            print "getting bar"
            return 3
    
        @bar.setter
        def bar(self, value):
            print "you're trying to set bar to", value
    
    foo = Foo()
    print foo.bar   # -> getting bar
                    # -> 3
    foo.bar = 5     # -> you're trying to set bar to 5
    print foo.bar   # -> getting bar
                    # -> 3
    
    foo.quux = 5    # regular attribute, nothing happens
    print foo.quux  # -> 5
    This pattern is used all over the place (and can do more powerful things than shown here). Ruby has similar. Perl has sort of an ancient warty hack that makes this possible, but it's rarely used since attribute access is already done with methods. JavaScript is getting it; I think Java might be too, but I don't really keep up with it.

    I couldn't find an equivalent for PHP.

    Originally Posted by ManiacDan
    Someone call Gabe Newell. C++ is not complex. He should change his keynote. Really? You're making this
    What gives you the impression I'm talking about C++? I don't much like C++.

    Originally Posted by ManiacDan
    Except it absolutely does. This is the part you still don't get. Everything is weakly typed, even undeclared/undefined variables. They're all 'null' until proven otherwise.
    Weak-vs-strong typing is about values, not variables. You could have a strongly-typed language where undeclared variables were automatically null, too, but still didn't compare equal to zero or empty string.

    Originally Posted by ManiacDan
    Whichever outside-the-box python library you use will have one, but PHP doesn't have one in the box. Really? You keep talking about third party python solutions being better than first party PHP solutions, then discounting the third party PHP solutions as invalid.
    As I said in the last post: the problem isn't that PHP's first-part solution isn't as good, the problem is that it very easily leads to serious security problems. Having no templating built in would be better.

    Originally Posted by ManiacDan
    Weak typing, as I've said, is very useful for web languages where everything is a string anyway since it comes from string headers.
    Everything is only a string at the entry point to your program. The rest of your code, the part that does actual work, does not benefit from weak typing.

    Originally Posted by ManiacDan
    PHP is good because it allows for rapid prototyping, fast new user integration, and ease of use.
    Why do you believe it's better at these things than any other language? What have you compared it to?

    Originally Posted by ManiacDan
    Are you trying to say that other languages provide a method for overriding file-access methods for Apache? I admit, I've never tried mod_rewrite in other languages.
    I'm genuinely sad that you believe the mod_php approach is the only one that exists.

    How do you think Twitter's URLs work? They sure aren't using mod_rewrite.

    Other languages are generally deployed so when you request "/myapp/foo/bar/123", your app receives "/foo/bar/123" and can do whatever it wants with that. (Most of the time "/myapp" is really just "/" and your app controls all traffic to the domain.) You attach a pattern like "/foo/bar/{id}" to some function, and then the function is called when your app gets that URL, and you get the id. Depending on the implementation, the id might already be an integer.

    You can also combine the name of your function with an id and generate the URL, so you never have to hardcode it anywhere in your app and changing URLs only requires touching one line. If you want, anyway. I don't think most devs bother doing it, but it's a neat idea.

    The web server setup varies, but it's usually a line or three along the lines of "when I get a request to anything under /myapp, just pass it along to fastcgi or this socket or whatever".

    Originally Posted by ManiacDan
    Do they provide a way to opaquely modify apache's file access functionality? If so, that seems to be the kind of opaque functionality you hate in PHP.
    No. Well, I guess mod_python and mod_perl exist, but mod_python is dead and the Perl community is moving away from mod_perl. The general trend is away from having web applications rely on the web server any more than is absolutely necessary.

    Originally Posted by ManiacDan
    Given the widespread distribution of Windows, it's at least worth some pause that Windows is written in C and is plagued by problems.
    Sure. C is a good language for what it is, but what it is is razor wire. It's an unfortunate state of affairs, but there aren't a whole lot of systems languages around. I have high hopes for Rust.

    Count yourself lucky: PHP actually has alternatives.

    Originally Posted by ManiacDan
    Are you suggesting that Python is incapable of string output?
    Python has no built-in templating system that allows embedding loops and conditions within a template itself. You are free to print out chunks of HTML manually, but you will rapidly come to hate yourself and go snag a tool that does it for you.

    Originally Posted by ManiacDan
    Your defenses are admirable, but most of them still stem from pre-conceived hatred for PHP or misunderstandings of how it works.
    You seem to think you could impart upon me some deep secret wisdom that would make me love PHP. I assure you that I understand it just fine and still genuinely dislike it, no matter how much you wish to believe otherwise.



    It's a shame this post no longer effectively ends with "your move" followed by locking the thread; that was the best part.
    Last edited by Eevee; August 29th, 2012 at 03:50 PM. Reason: durr this sentence is backwards
  28. #15
  29. Sarcky
    Devshed Supreme Being (6500+ posts)

    Join Date
    Oct 2006
    Location
    Pennsylvania, USA
    Posts
    10,908
    Rep Power
    6351
    You seem to think you could impart upon me some deep secret wisdom that would make me love PHP. I assure you that I understand it just fine and still genuinely dislike it, no matter how much you wish to believe otherwise.
    I still don't think you do understand it, but you've demonstrated that you will insist that your opinions on it are fact and therefore your view is correct. You hate it, and your opinion of it will never change. There were many wrong statements in your post (like how you continue to insist on the existence of some sort of built-in templating engine in PHP), but continuing to say "nu-uh" at each other is a losing proposition.

    Much of your original article was ludicrous, so I responded to it. You've gone back on a lot of it, but still stuck with "PHP is bad." Don't use it then.

    I believe loose typing is powerful. I believe PHP is easy to use and allows for very rapid prototyping. PHP is the 11th language I learned, and it's the one I liked the best because it was the easiest to get things working and it was sufficiently powerful to turn prototypes into full applications. there are some problems with every language. PHP's problems are mostly "I have to look in the manual for this function name." It's error handling is different from Python's. That's not enough to spawn hatred in me.

    It's a shame this post no longer effectively ends with "your move" followed by locking the thread; that was the best part.
    The person who locked the thread (and stated he was the one locking the thread) was not me. We have different avatars and everything.
    HEY! YOU! Read the New User Guide and Forum Rules

    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin

    "The greatest tragedy of this changing society is that people who never knew what it was like before will simply assume that this is the way things are supposed to be." -2600 Magazine, Fall 2002

    Think we're being rude? Maybe you asked a bad question or you're a Help Vampire. Trying to argue intelligently? Please read this.
Page 1 of 3 123 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo