15 ms·

These are things in PHP which make me sad

• gburt 15y ago
  This is by far my (least?) favorite: http://ca.php.net/empty http://ca.php.net/empty ----- The following things are considered to be empty: - "" (an empty string) - [...] --> "0" (0 as a string) <-- - [...] - var $var; (a variable declared, but without a value in a class) ----- Why the heck is "0" considered empty?
  • PaulHoule 15y ago
    there's something wrong with the == and coercion in the if() statement in any language. making the switch in if() be a boolean only pushes the problem off to the programmer, who will often choose the wrong function or expression to do the conversion
    • seabee 15y ago
      > making the switch in if() be a boolean only What exactly is the alternative? If there's any problem here it's automatic coercion.
      • JonnieCache 15y ago
        Nothing wrong with automatic coercion, as long as the rules are sane. In ruby, everything except false and nil is true. Easy. Unless you override the == method of course. With great power...
        • PaulHoule 15y ago
          PHP's rules, like Perl, does what the programmer wants a high fraction of the time. Except when they don't. For instance, 0 == false isn't too crazy, it's like C. But automatic coercion of string values to ints makes "0" == false which is sometimes what you want and sometimes not. Practically this burns people in form validation code because often you want to test if a field is an empty string and if you do the obvious thing you can end up kicking out "0". When I write PHP I have my own "PHP on nails" library that has functions that smooth out most of the things that are wrong with the language, and one of them is a comparison operator that is somewhere between "==" and "===" that most frequently does what you want it to do.
      • PaulHoule 15y ago
        in statically typed languages like Java, C#, Scala and C++ people are always screwing this up most languages have some screwed-uppedness about collections, both intrinsic to the language and that gets introduced by people who make APIs that aren't well designed. for instance, arrays and Lists are often not quite perfectly uniform (and it's often a thoughtless arbitrary choice if people decide to return you one or the other) Scala introduces it's own collections that provide more confusion when you're working with Java. The .NET framework has a great implementation of generics (makes Java and Scala look like a joke) but there are still many legacy APIs in the .NET framework that use non-generic collections. One result is that it's not always obvious what the right way to test for "empty" is. One of the worst of them is that pretty frequently APIs will give you a null when they ought to be sending you an empty collection, so you need to check for null.
        • samfoo 15y ago
          How does scala make this more confusing? Either the types that are returned are scala collections, or they're java collections. If you want to treat java collections like scala collections you can always `import JavaConversions._` and huzzah, shallow conversions and collection uniformity. Finally, if something has the possibility of being null, you can use the option construct, e.g. if (Option(someListThatMightBeNull).getOrElse(List()).isEmpty) { ... } Or more likely: Option(someListThatMightBeNull) match { case Some(list) => // do something... case None => // do something else... } More than likely if you're dealing with scala libs, things that can be "null" are returning options anyway.
          • PaulHoule 15y ago
            Option[X] is a crock. It's forcing you to write same bulky if-statements that you need to write for null checks. I want something like NOT NULL in SQL. Can't static typing make it completely impossible that I'll get a null in a situation where it should be completely impossible? For instance if something is typed as a collection, I'd like to never see null, I'd rather always get an empty collection. If I have to test for None, I'm just adding more bulky code where errors can hide, particularly when the type inference system in Scala is always doing strange things behind my back. In my mind, automatic conversions make the problem worse in Scala, not better. Code "just works" for the programmer in certain situations no matter how inconsistent people are in the types they use. The trouble I see is that Scala programmers seem to be pretty random if they're going return an Array, a java.util.List or a scala.util.List. This is really a pain in the ass when I'm trying to access some Scala objects from Java and I don't have automatic conversion available. I'm also sure that these different choices have all kinds of effects when you consider inheritance, variance, type inference and all that. It adds to the problem of spooky action at a distance in Scala.
  • code_duck 15y ago
    You should check out JavaScript - the type coercion is similar but even worse.
    • VMG 15y ago
      but JS isn't behaving weirdly with return values. Overall, JavaScript is much less WTF than php.
      • code_duck 15y ago
        It's impressive how they managed to do that, given that PHP is a single open source platform with one major implementation, in contrast to JS.
• betageek 15y ago
  PHP's single greatest advantage is ubiquity - would love to see a CoffeeScript compiler for PHP that smooths out these issues.
  • PaulHoule 15y ago
    you could say that all other web platforms are blub because they don't see the value that PHP brings to the table. a total idiot can install PHP and get a system that will meet the performance and reliability needs of 99.5 of web sites out there. tomcat, mod_perl, the ten different ways people host Ruby sites and all that make a lot more trouble for you. I've run PHP-based web servers for hundreds of sites that have served billions and billions of hits over the years and never once had to restart Apache because an application server got lodged. read that again because if you skip it, you're sysadminning blub. every other system requires that you make choices, and the truth about choices is that faced with a binary choice there are two common outcomes: (i) a person freezes up like a deer in the headlights or (ii) a person makes a random choice that they're 50% likely to get right. (i)'s probably the better option. i can complain about things wrong with PHP forever and i've got plenty of reasons to get off the PHP train. however, if you want to kill PHP, it's not enough to attack what's wrong with PHP, you've got attack what's right with PHP... You've got to make a better PHP than PHP.
    • rmason 15y ago
      A better PHP than PHP: You mean like Railo? http://www.getrailo.com/com/index.cfm/whyrailo/developers/ http://www.getrailo.com/com/index.cfm/whyrailo/developers/ (Scroll to bottom where they address why for PHP devs)
      • PaulHoule 15y ago
        that article is strikingly inarticulate. if you've got to tell me to scroll to the bottom, then it's a complete failure at selling railo, whatever it is
        • 15y ago
• programminggeek 15y ago
  Before everyone goes all "why don't you switch to language X or platform Y or lisp variant Z" I just want to say good job on this. These all seem to be sane critiques of PHP without being all doomsday world-ending inflamatory. Kudos. Also, I think that this is another example of how hard it is to build up a large and widely-used language/framework without having lots of warts. Especially since PHP wasn't originally designed with the intention of powering everything from a simple blog/cms to facebook.
  • iphoneedbot 15y ago
    yeah.. php really has gotten a bad rap.. nearing ASP proportions
    • lmz 15y ago
      By ASP you mean VBScript, right? Because ASP pages can be written in JScript as well, and I remember JScript was quite nice.
• thinkcomp 15y ago
  I've definitely run into #1 on the list. "Paamayim Nekudotayim" is a transliterated version of פעמיים נקודתיים‎, which means "double colon" in Hebrew. Zeev and Andi are Israeli, which kind of explains it, but the error message is still pretty useless.
  • koenigdavidmj 15y ago
    Even in Hebrew, that is a useless error message...token names should mean what the token means, not what it looks like.
    • gburt 15y ago
      For unexpected token I think what it looks like is more valuable. Unfortunately most English PHP developers don't speak Hebrew. =\
    • archivator 15y ago
      Presumably, the tokenizer doesn't know anything about the meaning of the tokens it's extracting. It's the parser's job to attach meaning to tokens.
      • burgerbrain 15y ago
        Presumably, the programmers should pick reasonable token names for the sake of other programmers. They're all just numbers to the tokenizer...
  • p4bl0 15y ago
    This should disappear soon[1], it seems the patch has been accepted (or is on a good way to be), according the internals@ mailing list[2]. [1] https://wiki.php.net/rfc/improved-parser-error-message https://wiki.php.net/rfc/improved-parser-error-message [2] http://news.php.net/php.internals/52436 http://news.php.net/php.internals/52436
    • Leynos 15y ago
• jcampbell1 15y ago
  php -r 'array("a","b")[0];' results in a parse error.
  • gburt 15y ago
    Resolving arrays like that causes parse errors in a range of contexts. Anything that is a "function" cannot also pick one array key... leaving a lot of XML-parsing code that looks like $xml = getXpathWhatever(); $xml = $xml[0]; Stranger yet, is that it works perfectly fine with resolving objects... for example $xml = funct()->something->somethingelse()->a Works fine...
    • birken 15y ago
      Array brackets after function calls are fixed in PHP 5.4: ~/php_source/php-src-5.3$ ./sapi/cli/php -r "function a() { return array(1,2); } print a()[0];" Parse error: syntax error, unexpected '[' in Command line code on line 1 ~/php_source/php-src-5.4$ ./sapi/cli/php -r "function a() { return array(1,2); } print a()[0];" 1
    • z92 15y ago
      I usually write it as $xml = reset(getXpathWhatever()); which returns the first element from array.
• ckoning 15y ago
  While it doesn't detract from the point of your post, the behavior of private is correct and intended. If you wish to override an internal method of a class in PHP, like Java, you must declare it protected, not private. This is the difference between private (completely internal, not inherited) and protected (internal, but inherited by subclasses).
• kalleboo 15y ago
  Where are the links to his bug reports for these so we can vote on them to be fixed?
  • ryan-allen 15y ago
    The PHP bug report tool is at http://python.org http://python.org. To file a bug, click 'Download Python'.
• pornel 15y ago
  There's a lot of valid points there, but "#33 Cannot override private methods with a subclass" is the right behavior. That's exactly what private is for, and it's important to know that such names are non-colliding and you can rely on their implementation. Use protected for overridable methods. You shouldn't mock or directly test private methods in unit tests — they're not part of the interface!
  • mrspandex 15y ago
    "#41 Cannot create a final abstract class" is borderline too
    • lox 15y ago
      Yup, wouldn't a final class with a private constructor be more appropriate there?
    • pornel 15y ago
      Indeed. In 5.3 you could have regular functions in a namespace, so there's no need to abuse class for that any more. Other than that it smells like a variation of the singleton antipattern.
    • glenjamin 15y ago
      I like to think that declaring a class as "final" is simply a lack of imagination.
  • jrockway 15y ago
    public/protected/private is a dumb idea in dynamic languages. If you don't want someone calling your method, prefix it with an underscore and say "the results are undefined if you call methods that start with an underscore". Done. Easier to maintain, easier to test, less code to type in. Come to think of it... public/protected/private is a dumb idea in C++ and Java, too.
    • wvenable 15y ago
      > public/protected/private is a dumb idea in dynamic languages. PHP is mostly a static language; it has more in common with Java than with say Ruby. > prefix it with an underscore Oh god, really. Next you'll be telling us we don't need namespaces, we can just use an underscore as a separator! > and say "the results are undefined if you call methods that start with an underscore". Done. Easier to maintain, easier to test, less code to type in. Or you could just build that all into the language itself so it's self documenting and provides a nice concise error message when used incorrectly! I'm amazed that people would argue for naming conventions over actual features. Hell, nobody is saying you have have to use it; if you'd rather use underscores the languages will let you.
• MostAwesomeDude 15y ago
  What makes me sad is that people will defend this horrible language to the death, regardless of how many problems there are with it. I don't get it; we know how bad PHP is, so why do people fight so hard? Oh, and to demonstrate: "PHP has no native Unicode type, no native Unicode handling, and cannot treat Unicode strings as strings." This true statement, composed of three observations about deficiencies in the language, gets me flamed every time I mention it. Why?
  • petervandijck 15y ago
    It's bad, but it's also very, very good.
    • tjogin 15y ago
      What aspect of PHP is "very very good"? Genuinely curious to know.
      • petervandijck 15y ago
        It's bad for language purists, but it's very, very good for getting stuff done fast, easy and good-enough. See Facebook etc. A lot of programmers don't believe that a shoddy language (in terms of language design) can be effective, but it is. I also happen to think that PHP scales really, really well the range that most sites need (say, from 1 to 50 servers). In that range, PHP is almost never the bottleneck.
        • tjogin 15y ago
          > "very good for getting stuff done fast, easy and good-enough" You're saying PHP facilitates a faster development process than most other popular web development platforms? This was probably true, ten years ago. Today, we have several platforms that facilitates a fast development process without the language weaknesses and inconsistencies that PHP is burdened with.
  • dexen 15y ago
    > "PHP has no native Unicode type, no native Unicode handling, and cannot treat Unicode strings as strings." ... gets me flamed every time I mention it. Why? perhaps because statement of of fact (``PHP has pluggable Unicode support'') beats wrong statement of oppinion (``PHP is bad because has no support for it''). It's borderline trolling to insist PHP does not, when people have been using it successfully in production for years now. http://pl2.php.net/manual/en/book.mbstring.php http://pl2.php.net/manual/en/book.mbstring.php in case your google is broken.
• gergles 15y ago
  The ridiculously terrible behavior of == is what makes me the saddest. http://www.php.net/manual/en/types.comparisons.php http://www.php.net/manual/en/types.comparisons.php We then have === which does what == is really supposed to do, but even that still sometimes does the Wrong Thing.
  • gergles 15y ago
    Wow, a downvote within 30 seconds of posting? "php" == 0 returns true, and this makes sense how?
    • cag_ii 15y ago
      Because the string is first converted to an integer. "==" makes the comparison after converting types (see: Type Juggling in the docs) where "===" requires that the types be the same in order to be equal. Kind of weird the first time you see it, but it's a language design choice and does make sense once you understand it.
      • Zak 15y ago
        I think the reason people object to this behavior, even when they do understand it is that it makes the obvious default (==) dangerous. It's especially dangerous in the hands of the sort of non-experts for whom it's intended to make life easier.
        • wvenable 15y ago
          == really isn't that dangerous unless you use it dangerously. Comparing non-numeric strings to numbers is already odd.
      • jessedhillon 15y ago
        What doesn't make sense is the rationale for designing it this way.
      • jwatzman 15y ago
• larrik 15y ago
  What makes ME sad is no keyword arguments. Helper/wrapper functions either get an annoying and difficult-to-grok-at-glance associative-array for it's params (bad), or a huge list of rarely-used parameters (worse), or a huge set of wrapper functions to set their own paramters (even worse), or outright duplicated functions for similar-but-not-quite tasks (worst). This happens to me while producing something like a jqGrid, or other javascript/html hybrid stuff that need a few extra options sometimes. Django/Python? No problem! Just use the keywords you need. (More Info: The difference between a single associative param standing in for keywords arguments, or a huge list of regular arguments is a choice in complexity/readability IN the function vs. calling it. For the single dictionary approach, you lost the built-in parameter defaults nicety, which means you need to handle the case of a missing parameter manually. This kind of sucks, especially if you hate seeing PHP Notices during development (which kill JSON/XML output anyway). This makes your function often twice as big (or more) than it needs to be. For the other approach, you wind up with calling foo("","","","real value", true, true, 2, false, false, "option I want");* which just about invites all sorts of hard-to-find bugs, and you have to look at the function definition every time you want to change an option. Also, it's flat-out rude if you aren't the one calling the function.)
  • dexen 15y ago
    compact() + extract() is the closest you get. $foo = 123; $bar = getSomeBar(); myFunction(compact('foo', 'bar')); function myFunction($kwargs) { $foo = SOME_DEFAULT_VALUE; extract($kwargs); if ($foo > 5) { ... } } If you want to `sanitize' which arguments can be passed that way, use extract(array_intersect_key($allowed, $kwargs)); ((EDIT: or use EXTR_IF_EXISTS)). Nb., extract() works on any associative array, you don't have to use compact().
    • cag_ii 15y ago
      Why would this be any better than just passing in a map of the parameters as the sole parameter? myFunction($parms=array()) { ... } $parms = array('foo' => 'bar', 'baz' => 'yaz'); test($parms);
• deleted 15y ago
  [deleted]
• mikey_p 15y ago
  Related: http://www.phpwtf.org/ http://www.phpwtf.org/
• cgranade 15y ago
  I'd love to see similar lists for other languages. I've been coding in MATLAB as of late, for instance, and rediscovered my hatred for the fact that you can't index the output of a function without assigning to a temporary variable. For instance, `foo(args)(:)` causes an error. You have to use `X = foo(args); X(:)` instead. That makes me just as sad as some of these PHP sadnesses.
  • eru 15y ago
    Yes. Though Matlab has gotten massively better in recent years. It's just that the defaults, for backwards compatibility are still The Wrong Thing (TM). Look at function handles, and cells for string handling.
  • shuzchen 15y ago
    That's called array dereferencing. It doesn't work in php either, you need to assign to a temporary variable. I've been following a patch in the works (at https://wiki.php.net/rfc/functionarraydereferencing https://wiki.php.net/rfc/functionarraydereferencing ) but there doesn't seem to be much progress on it.
  • nimrody 15y ago
    MATLAB does get one thing right: Function arguments are always passed by value. This "referential transparency" really makes it easier to reason about functions and test them. It's the one thing I hate about SciPy. Passing by reference for performance reasons should be automatically handled by the compiler. I.e., A=sort(A) should be handled in-place without requiring a new function sort!(A).
    • cgranade 15y ago
      I'm not so sure I agree. Python in general is very consistent about pass-by-value versus pass-by-reference semantics, whereas MATLAB infers things in ways that are far from transparent. Look at, for instance, the way the `parfor` loop construct differentiates between "broadcast," "sliced" and other such variables, and how fragile that inference is. Maybe I haven't thought clearly enough about this particular issue, but I don't think of MATLAB as being transparent.
• snorkel 15y ago
  Mandatory function arguments: function foo($arg1,$arg2) { return; } foo('bar'); Warning: Missing argument 2 for foo() Lame. But omitting arg2 is allowed if you give it a default value: function foo($arg1,$arg2=FALSE) { return; } Blah. Instead I'd rather make arg2 truly optional just by testing if it's defined.
  • eru 15y ago
    I see this as a feature. (I'd never thought I come around to defend PHP. Issue #21 has bitten me in practice.)
  • rokhayakebe 15y ago
    What would the ideal language return for your function call foo('bar'). It would seem to me that missing an argument should return some sort of notice, like in the case where someone else is using it.
    • snorkel 15y ago
      I prefer Javascript for example: JQuery's calling conventions would not be possible if function args were mandatory.
      • nawariata 15y ago
        You can always use func_get_args() if you truly want it that way.
        • ryan-allen 15y ago
          Or you could just use a real programming language that has some kind of design.
      • wvenable 15y ago
        I'm curious as what PHP couldn't do? You have default argument values and you can pass more arguments to any function. Seems that covers all the cases.
• BruceForth 15y ago
  things about php that make me sad: 1. it exists 2. it's used 3. many of its users make more money than me 4. it has poisoned the market, clients have learned to expect and even demand php-braindeath
  • code_duck 15y ago
    I can't even imagine how many developers out there started with WordPress and think the ramshackle way it's put together is normal.
    • jasonlotito 15y ago
      Probably the same type of developer that assumes WordPress is an example of professional PHP code.
      • code_duck 15y ago
        It's true. The problem is it's often the only PHP code they know. Many people do assume it's an example of good code, since it's so popular and essentially works. WordPress is really an excellent companion to PHP itself - created by beginners who had no idea about how to design a language or framework. They have each since become somewhat respectable, but are shackled by the attempts they made to preserve backwards compatibility in the early days.
  • snorkel 15y ago
    I often find that PHP coders lack a total understanding of the LAMP stack. "Apache configuration? Huh? I don't know, our admins do that." "MySQL? I don't know, I'm not a DBA. I'm a developer." "UNIX commands?!! I don't like going in the terminal. I'm a developer." No, sorry, you're not a developer. You're a glorified web page editor.
    • ceejayoz 15y ago
      Bullshit. You don't have to be a sysadmin to be a developer. Web devs often know the whole stack, but you're still a web dev if someone else in your company handles those parts..
• sparkygoblue 15y ago
  This horse has been beaten, mutilated, and buried.
  • ryan-allen 15y ago
    Obviously not quite buried yet.
• jrockway 15y ago
  I hate PHP, but this article isn't very good. It's strange that there is an "implications for the internals" reason. Guess what, you can just read the internals. It's open source. The parser emits weird error messages because it is a very simple yacc grammar. (And because they turn off yacc's "produce better error messages" mode.) If you want good error messages, it's going to cost you -- just read perl's toke.c if you don't believe me. Good error messages cost a lot.
  • generalk 15y ago
    You can just read the internals, but that doesn't mean that the criticism is wrong. Certain problems do suggest deeper internal issues. "Good error messages cost a lot" and "They turned off yacc's 'produce better error messages' mode" seem to contradict one another. And no, in a lot of cases the parser emits weird error messages because the internal variables are named weird things. If you're telling me it's unreasonably difficult for PHP to produce a better error message than "Unexpected CONSTANT_NAME" than why name your constants unintuitively?
• Androsynth 15y ago
  Programming languages are tools. Some tools are better than others, some are better for certain situations. For all non-contractors, no one is forcing you to write in one language over another (or stay employed at a php shop). It seems like the only point of having threads like this is for the leet programmers to look down on php. What's the point? This isn't constructive, its condescending and back-patting. (the reason this makes me mad is that the sadness list is just a bunch of minor gripes. Every language has minor problems. PHP has fundamental flaws and that causes sadness, not this crap.)
• EamonLeonard 15y ago
  PHP is Open Source. Compiling a list like this is nice, but contributing something back, and getting involved in making improvements to PHP, would be nicer.
  • code_duck 15y ago
    Raising awareness of what needs to be fixed is the first step.
    • EamonLeonard 15y ago
      Agreed, but if you're going to put the energy into picking out what doesn't work, you probably have spent time thinking about how it should be done, so following through is worthwhile for all concerned.
  • dexen 15y ago
    There's an outstanding request for better array syntax. It's been out there for over 3 years and received a lot of support from the community. At least one implementation has been submitted. But the core dev team rejected the idea, as they are convinced having second syntax available would harm ease of use (and thus popularity) of the language. In general, some aspects of PHP will not be fixed/improved for reasons of either: * backward compatibility, or * incompatibility with the vision of the language by the core dev team. http://marc.info/?t=121142259100001&r=1&w=2 http://marc.info/?t=121142259100001&r=1&w=2 http://marc.info/?t=119995974300003&r=1&w=2 http://marc.info/?t=119995974300003&r=1&w=2
    • EamonLeonard 15y ago
      Indeed, one of the downsides of Open Source... politics etc, it doesn't help, but tends to come with the territory.
    • philolson 15y ago
      This is being revisited as per the PHP 5.4 TODO. My guess is it'll happen this time around, and I voted against it previously (but changed said vote). https://wiki.php.net/todo/php54 https://wiki.php.net/todo/php54
• stevep98 15y ago
  For an illustration how PHP is 'different' from other languages, consider 'implode': implode — Join array elements with a string string implode ( string $glue , array $pieces ) Note: implode() can, for historical reasons, accept its parameters in either order. WTF! What other library has a major function which doesn't care about the parameter order? It goes against every notion of good design. http://us.php.net/manual/en/function.implode.php http://us.php.net/manual/en/function.implode.php
• wvenable 15y ago
  As usual, when one of these lists comes out about PHP there are some real issues, some non-issues, some have been fixed, and a few things that are just different. I'm surprised these sorts of posts keep getting voted up here; haven't we seen it all before? I do a lot of PHP development but not exclusively and rarely does these sorts of deficiencies in PHP ultimately matter.
• jwatzman 15y ago
  My favorite PHP design misfeature: what does the following code do? <?php $foo = array("a", "b", "c"); foreach ($foo as &$bar) echo $bar; echo "\n"; foreach ($foo as $bar) echo $bar; echo "\n"; The "&" is a foreach-by-reference, for those not familiar with the language. When you think you've figured it out, you can execute the code at http://www.contrib.andrew.cmu.edu/~jwatzman/foreach.php http://www.contrib.andrew.cmu.edu/~jwatzman/foreach.php
  • pornel 15y ago
    unset($bar) after the first loop is highly recommended.
  • unfletch 15y ago
    I filed that bug 7 years ago and they wouldn't fix it: http://bugs.php.net/29992 http://bugs.php.net/29992 I had it a little wrong in the initial report, but it was cleared up in the comments. The reluctance to fix stuff like this because "people might use this for some weird reason" is one of the reasons I'm glad I don't write much PHP anymore.
    • wvenable 15y ago
      It's not a bug though, it's how references work. The code is exactly right. You might not expect the output but that doesn't mean it's logically incorrect.
      • unfletch 15y ago
        Yeah, I understand the cause. Just because those steps make logical sense doesn't mean it's not a bug. My real point was about the WONTFIX tendencies of the PHP dev team at the time (I've been gone a while; maybe it's better now). It's absolutely the thing I miss least about that community. I mean, when I filed that bug PHP 5 -- the first version to support foreach with references -- was less than 2 months old. The "people might be relying on it" argument doesn't hold much weight with me today, but it certainly didn't hold any for a 2-month-old feature.
• jessedhillon 15y ago
  #40 is a major WTF. They are outright removing the ability to create a length 1 buffer, so that someone who wants to create a 4096 unit buffer can save 3 keystrokes? (Also, what if the length argument is dynamically generated, say from the size of a file?)
• ars 15y ago
  So how do I contact the author with updates? I clicked on a random item - the complaint that explode() doesn't take the empty string and return an array of each letter. But of course you can just use the str_split() function to do that (which is way more logical than passing an empty string). So how do I contact the author and reduce his sadness level? Or is this one of those websites that don't want to remove items, even if they are wrong?
• DCoder 15y ago
  Missed one: foobar() is the same as FOOBAR() $foobar is completely separate from $FOOBAR
• chernevik 15y ago
  I grok none, but of Python they make me glad
• SeoxyS 15y ago
  What makes me sad is that even though I feel affronted by PHP's crudeness, inelegance and inconsistencies… I keep using it for a lack of another language that suits me personally. I hate PHP's runtime and core libraries. But I really like the C-inspired syntax. I use Objective-C as my main other language, and something about Ruby and Python's syntaxes seem to rub me the wrong way. I'm giving Node.JS a whirl these days—and while I might be able to get used to closures everywhere, I don't know how to feel about the lack of true object orientation.
• fauigerzigerk 15y ago
  The function chaining issue (#21) has to be the single most idiotic thing I ever encountered in any language (other than maybe t-sql).
• DisposaBoy 15y ago
  I couldn't find any way of contacting the author or leaving a comment(except on twitter) so commenting here... Before I start I must say it would have been nice if a proper set-up was done for the screenshots, white-marks(censor) on the images just distract from the point you're trying to make. I personally disagree with some of these points... on point #2 > Class definitions should not result in the execution of any code, period. Whether or not that warrants a syntax error is up for debate, but that code does not look very constant from here and is some-sort-of an error in my view. on point #37 > `"a" . "b"` doesn't make sense as useful code... `__DIR__ . "/file"` could be useful, but as already argued, it's not a constant and therefore should not be getting any special treatment. If it did, then I'd consider it a bug - as it leads to more inconsistency, ambiguity and bugs. on point #8 > I guess we could argue this one all day. Personally I don't think it should ever return true as an object is not an array and vice versa. likewise, property_exists should not work on an array(). It's documented that array_key_exists no longer works with objects as-of php 5.3, whether or not id did before that I don't know. I can't really think of a use-case for that function when you have isset(). on point #18 > I think this one can go either way, for what purpose is a static variable useful on an object instance? on point #33 > I feel so strongly about this one that I think it should be removed entirely. Unlike the other points I don't think this one is open for discussion in any case. I simply can't understand why this code should ever be valid. It completely goes against the point of OO and information hiding. You'll take care to note that it works as expected if you make it protected as opposed to private. That's the idea of having private and protected. Furthermore, you say pretty much the same thing. In the code, it does override it - no question. Call `$obj->b();` and see what happens. The reason you think it doesn't work is because `a()` unless overriden, is comes from `class super` and is therefore tied to `class super`. In other words, it's never supposed to work... on point #41 > Yeah... I don't get it. on point #28 > I'm pretty sure empty() is not a function which renders the rest of the point moot. Inconsistent behaviour? I think so. Again with the function chaining and need for a temporary variable. Provide snippets if you can, please. Otherwise it's hard to understand things from your POV. The whole bugs section is moot - they're bugs and are therefore implementation dependent - i.e has nothing to with the language. on point #11 > This isn't so-much a disagreement so I'll use it to ask what's up with the numbering... Anyway I don't understand the part about memory use - I wouldn't be surprised if the memory-use on the main page increased more than 30KiB simply by including that point. So in theory, leaving it out would in-fact be saving memory :p on point #14 > I think it's a good thing, in the same vein on throwing in destructors. It's not funny in C++ and it damn sure ain't funny in PHP either. on point #38 > I think that's a good thing - if you know you can't catch a fatal error then if forces you to write better code. on point #20 > I must admit that I've never seen use of `\e` for this - only `\033` and `\x1b`. on point #35 > It shouldn't - that's like setting a bear trap in from of your doorway and then go out to get drunk so you can come back and step on it. on point #26 > Maybe it makes sense to me coming from C/C++ and GCC but E_STRICT doesn't report errors and therefore doesn't belong in E_ALL. Contrast GCC's `-Wall` and `-Wall -Wextra`
• Topaz2078 15y ago
  By popular demand, I've added a discussion board to phpsadness.com. Join the discussion!
• voidr 15y ago
  > Standard libc process control (fork/exec/etc) > The libc fork() and exec() functions are not present in PHP by default. > http://www.phpsadness.com/sad/17 http://www.phpsadness.com/sad/17 Why would anyone writing a PHP app need those? The page just calls it a missing feature without explaining why this is a bad thing.
• winestock 15y ago
  Don Hopkins gave a thorough list of things which are wrong with PHP. http://www.jwz.org/blog/2011/05/computational-feces/#comment-90658 http://www.jwz.org/blog/2011/05/computational-feces/#comment...