These are things in PHP which make me sad

http://www.phpsadness.com/

by johnkary • 15 years ago

243 212 15 years ago

phpsadness.com

gburt3• 15 years ago

This is by far my (least?) favorite:

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?

PaulHoule11• 15 years 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• 15 years 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.

code_duck8• 15 years ago

You should check out JavaScript - the type coercion is similar but even worse.

VMG• 15 years ago

but JS isn't behaving weirdly with return values. Overall, JavaScript is much less WTF than php.

betageek• 15 years ago

PHP's single greatest advantage is ubiquity - would love to see a CoffeeScript compiler for PHP that smooths out these issues.

PaulHoule11• 15 years 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.

rmason4• 15 years ago

A better PHP than PHP: You mean like Railo?

http://www.getrailo.com/com/index.cfm/whyrailo/developers/

(Scroll to bottom where they address why for PHP devs)

Leynos2• 15 years ago

I won't defend PHP as a language, but from an accessibility point of view, other platforms could certainly make things easier.

Coming from a PHP background, the first time I tried Django, I was rather dismayed at the amount of set up involved. I think after following a few tutorials, I was able to more or less get a running mod_WSGI setup, though the only way I could seem to get the web site to refresh was by restarting Apache.

After I got over the fear of using an http daemon written in the same language as my web app, I discovered Ruby / Sinatra, which gave me more or less the same immediacy I was used to from PHP.

Even so, I doubt I could explain Heroku to a non-technical friend in the same way I could convey an understanding of uploading a php web page to a LAMP host. (Ubuntu's broken support for RubyGems didn't do much to help my migration from PHP either).

It seems to me that until Python and Ruby have an infrastructure that's as friendly to novices as PHP is, we'll be seeing the same "PHP ghetto" effect that we've been seeing for the past decade.

jerf3• 15 years ago

"you could say that all other web platforms are blub because they don't see the value that PHP brings to the table."

I do not recall at any point in Beating the Averages [1] in which pg used "ease of installation" as part of the definition of a blub language.

Blub has a specific meaning. It's not a synonym for "bad".

There are plenty of other technologies that are as reliable as PHP. Ruby was not really one of them. Ruby went through a bad hype cycle a couple of years ago and was never quite as good as it was sold to be, especially on the reliability front. It's a great anecdote but a bad argument.

[1] http://www.paulgraham.com/avg.html

jrockway3• 15 years ago

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.

This is like living in a house where the builders were "total idiots" and hammered in all the screws with a hammer instead of screwing them in with a screwdriver. Sure, it holds together. It might not even collapse in a light breeze.

But one day, you'll want to reshingle the roof, or there will be a thunderstorm, and then your house collapses, killing your entire family. Good engineering requires good implementation. PHP makes good implementations too hard.

Theoretically, this is why you hire people with experience. They picked randomly the first time, and then gathered data. Their random choice either worked or it didn't. Repeat a few times and you have "senior system administrator" and "senior engineer" instead of "random dumbass we found on the street corner", and then this part of the equation goes away.

Now, if your goal is to produce something that sometimes works with the least amount of money possible... yes, you should outsource your development and deployment to some high school kids in India. If your goal is to produce something that works...

(Also, the days of PHP's deployment superiority are nearly over. With mongrel2, I can restart my app instances without losing a single request!)

programminggeek• 15 years 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• 15 years ago

yeah.. php really has gotten a bad rap.. nearing ASP proportions

lmz2• 15 years 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• 15 years 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• 15 years ago

Even in Hebrew, that is a useless error message...token names should mean what the token means, not what it looks like.

gburt3• 15 years ago

For unexpected token I think what it looks like is more valuable. Unfortunately most English PHP developers don't speak Hebrew. =\

archivator• 15 years 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.

p4bl02• 15 years 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

[2] http://news.php.net/php.internals/52436

Leynos2• 15 years ago

I'm actually surprised it's still there. I remember WTFing at that about four years ago.

qeorge• 15 years ago

Its only a "bug" because there's an unspoken rule that all programming languages should be written in English, and English doesn't have a proper word for this symbol.

Pretend that English had no representation of an ellipsis, but Hebrew did. Should the language author say "Expected: dot-dot-dot" in the error message to appease native English speakers, or should (s)he use the unambiguous form?

rudiger• 15 years ago

In this case, the Hebrew word literally is T_DOUBLE_COLON, so not much is gained by its use. Perhaps reporting an "unexpected scope resolution operator" error would be better.

georgieporgie• 15 years ago

Pretend that English had no representation of an ellipsis, but Hebrew did. Should the language author say "Expected: dot-dot-dot"

Yes. It's not about appeasement, it's about consistency.

jeffreymcmanus• 15 years ago

It's not an unspoken rule, it's an established convention.

This isn't about whether we use English or not, or whether that's the right choice or not, it's about consistency. If you want to create a language that has all-Hebrew tokens and error messages, knock yourself out. Just do it consistently.

rmc• 15 years ago

The rest of PHP is in English. A language should be consistant with itself.

Someone• 15 years ago

OK, let's pretend that. Then, we have someone designing a programming language with English keywords that uses a token for which English does not have a name (not merely a well-known name, not even an obscure one, but no name at all)

IMO, that would only be a good idea when taking part in a obfuscated programming language context.

user24• 15 years ago

> the error message is still pretty useless.

not at all. A google search for "Paamayim Nekudotayim" gives you thousands of pages relating to exactly the error you're experiencing. It's WAY more useful than "Illegal operation" or "Syntax error".

generalk3• 15 years ago

  > It's WAY more useful than "Illegal operation" or "Syntax error".

Wut.

"Syntax error on line 14" -- Okay, time to look at line 14 for a mistyped semicolon or something. These two words Mean Something.

"Unexpected T_PAAMAYIM_NEKUDOTAYIM on line 14" -- means absolutely nothing unless you've already looked it up. It's essentially easily-googleable nonsense. It might as well say "Error 0x444F808E". You can google that, too, and it also tells you nothing useful.

julioc• 15 years ago

I still prefer something like "illegal scope operator"

code_duck8• 15 years ago

Right, because there are thousands of people going to ask on mailing lists WTF that means. Given the small fraction of developers worldwide who speak Yiddish or Hebrew or whatever, 'double colon' might be a better phrase to use.

lox2• 15 years ago

I'm actually quite fond of that particular quirk. At least it's easy to search for!

alanh• 15 years ago

Of all these complaints, I’m most forgiving of the name of T_PAAMAYIM_NEKUDOTAYIM. You only need to look it up once; the cost is a few seconds of Googling and the payoff is you learn a fun random fact. It gives the language a bit of color.

Still, glad I’m not doing much PHP anymore.

phillmv• 15 years ago

Actually, I kind of like the feeling that I'm building a golem when working on webapps.

jcampbell1• 15 years ago

php -r 'array("a","b")[0];' results in a parse error.

gburt3• 15 years 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• 15 years 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];"

z92• 15 years ago

I usually write it as

$xml = reset(getXpathWhatever());

which returns the first element from array.

ckoning• 15 years 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• 15 years ago

Where are the links to his bug reports for these so we can vote on them to be fixed?

ryan-allen6• 15 years ago

The PHP bug report tool is at http://python.org. To file a bug, click 'Download Python'.

pornel4• 15 years 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• 15 years ago

"#41 Cannot create a final abstract class" is borderline too

lox2• 15 years ago

Yup, wouldn't a final class with a private constructor be more appropriate there?

pornel4• 15 years 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.

glenjamin2• 15 years ago

I like to think that declaring a class as "final" is simply a lack of imagination.

jrockway3• 15 years 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.

wvenable16• 15 years 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.

ch0wn• 15 years ago

Agreed. When I started using python I thought that I would miss protected/public methods, but I was wrong. Conventions are the better solution and make testing incredibly easier.

pornel4• 15 years ago

I don't see how dynamic languages make it dumb.

Dynamic or not, objects have interfaces and this is a way of defining the public interface and catching violations of it.

> Easier to maintain, easier to test, less code to type in

My impression is opposite. They add friction to changing visibility. I like to start with everything private and then unprotect as needed.

It's extra character to type and it interferes with autocomplete.

Accessibility of "private" methods shouldn't be help in tests — you'll end up creating tests that depend on implementation. If class is too impenetrable to test, then refactor it (split concerns, add dependency injection, etc.), don't unprotect it.

fleitz• 15 years ago

No kidding, I hate having to write some reflection BS in C# just to call a 'private method' as if addresses in memory cared about such things. The worst is some of the MS extensions for WIN32 that have private constructors designed to prevent obvious functionality. (Basically the constructors are private for political reasons). IIRC, it was something to do with reading COM streams from .msg files. It really ticked me off.

Jach• 15 years ago

Totally agree. Of course, because PHP has the public/protected/private idea, it's correct in not redefining those for its own meaning, so the complaint is missing the point.

I think the worst villains of the public/protected/private family are getter/setter methods, it bugs me when I see them in Python code. We use enunciate ( http://enunciate.codehaus.org ) at work, and we bundle AMF endpoints with our stuff. Unfortunately the Java-to-actionscript step complained when our data objects don't have getters/setters (since I like just using public attributes), so now I have two Python scripts: one generating the Java code for a data object along with annotations, the other adding getter/setter methods.

Tomek_2• 15 years ago

Recently at my company we're writing a lot of JS and its' lack of "public/protected/private" doesn't make it easier to maintain or test. Actually, it's quite frustrating because you know you can't test it properly - everything public? it's a ticking timebomb, someone at some point will simply override your method somewhere and hell will broke loose

MostAwesomeDude2• 15 years 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?

petervandijck2• 15 years ago

It's bad, but it's also very, very good.

tjogin2• 15 years ago

What aspect of PHP is "very very good"? Genuinely curious to know.

dexen5• 15 years 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 in case your google is broken.

MostAwesomeDude2• 15 years ago

I knew you were going to point out mbstring. I am talking about an actual Unicode string type. I am talking about using regular string functions on Unicode strings without caring whether or not they contain characters not in ASCII or Latin-1. I expect you'll next talk about how the function overloading "feature" is the correct thing to do, and you'll conveniently ignore how the documentation recommends against it and warns of undefined behavior.

Here's a fun question: How do you strtok(), implode(), or explode() mbstrings?

encoderer2• 15 years ago

Are you serious? You can't figure out why this is?

Seems logical to me. These defenders are presumably professional PHP developers. They're presumably supporting their families by coding PHP. The more widely-spread the language is, the more it's used for new projects, the more lucrative and interesting their work will be.

And here you are, making a fuss, and many of these people may know ONLY PHP. And you're trying to argue that their most valuable skill should be put on the trash heap.

That's why THEY fight so hard: They're feeding themselves with the language.

Now, why do YOU fight so hard against them?

jerf3• 15 years ago

I fight against technologies I perceive as bad choices in an attempt to convince younger developers with less of an experience base that they should pick up something else that will give them the same or better capabilities for much less pain. My contribution to the community, as it were, as I have in turn benefited in my career from such signposting.

You can carve out a decent subset of PHP, but there's this painful and dangerous beginning and middle part where you're still learning this subset and in the meantime you're writing grossly insecure code. Perl has much the same problem. There are no languages I know where you are immediately writing brilliant code, but there's certainly ones you can learn faster, cut down the danger period, and also have many of the worst dangers ameliorated by much better design decisions at the API and language level. (How much of PHP and all similar languages would have been better if only the default interpolation HTML escaped everything and you had to especially ask for direct interpolation, instead of the other way around?)

gergles2• 15 years ago

The ridiculously terrible behavior of == is what makes me the saddest.

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.

gergles2• 15 years ago

Wow, a downvote within 30 seconds of posting?

"php" == 0 returns true, and this makes sense how?

cag_ii2• 15 years 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.

jmathai• 15 years ago

It doesn't make sense unless you understand how PHP works - at which point you'd use ===.

tzs• 15 years ago

It makes sense for the same reason it makes sense in Perl: use a string as a number and you get the number that is at the start of the string. E.g., "12" == 12, and "12php" == 12.

qntm• 15 years ago

Except when you're comparing objects!

I want to make sure that object A and object B are instances of the same class. Also, I want to make sure that they are equal i.e. that every attribute is equal. Also, since I'm now used to always using === instead of == for such comparisons, I use === to make the comparison. I would think that == would perform an == comparison on every attribute, whereas === would perform an === comparison on every attribute.

Nope! Using === actually verifies that the A and B are in fact references to the same object in memory, just like the "is" operator in Python. Got me again, PHP! How do I do my === comparison? Manually, that's how!

webignition• 15 years ago

Object equality is non-trivial matter and subjective. Java delegates the consideration of object equality to Object.equals(), intended to be implemented by yourself as required.

That PHP chooses not to try and provide a means of determining object equality is not a poor choice. Using the === operator to test whether two variables are references to the same object is then also not a poor choice.

danudey• 15 years ago

The way I've explained this (braindead) behaviour to people is that == is the 'equivalence' operator, and === is the 'equality' operator.

This sort of 'well, close enough' behaviour has bitten me in the past as well. While writing a JSON bridge between an older PHP backend system and a newer Rails frontend, we kept getting exceptions on the Rails end.

It turns out that the JSON library uses isnumeric() to determine if a value is a number or not - which makes sense, in some respects. The problem is that we had a parameter (the external vendor's product SKU) which was a string that, in some cases, consisted entirely of digits. On those few occasions, the JSON library would say 'Oh, this is a number' and encode it as such in the JSON.

When Rails tried to unpack it, we got an exception because our Rails model was validating the data on the remote end and choked on getting an integer instead of a string.

We ended up having to actually modify the JSON library we were using (everything else we tried either didn't work or had the same bug) to modify the check. Completely ridiculous.

larrik• 15 years 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.)

dexen5• 15 years 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_ii2• 15 years 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);

blake8086• 15 years ago

Isn't a wrapper function the solution to this? Or even... a wrapper function that takes an associative array of options as an argument.

steve-howard3• 15 years ago

You can use the @ symbol to suppress errors when you're aware that the variable may be empty and you've considered the possible effects. When I used to write PHP, I'd often write something like

    do_something(@$_GET['foobar']);

There are ways to suppress PHP notices without just turning off the E_NOTICE output.

samdalton2• 15 years ago

It shouldn't be ok to write code that is known to throw an error, and handle it by suppressing that error. Silently failing code is just a bug waiting to happen.

It's also making the interpreter do unnecessary error handling work when a simple "if ($_GET['foobar'])" would suffice.

code_duck8• 15 years ago

It's inefficient to do that, as from what I understand PHP actually sets the error level to none, processes that line, sets it back, and continues. Also it would suppress any other warnings from that line, which could be unrelated to the supplied argument value.

Instead, I use a 'get or else' function, as in some functional languages. For arrays, it goes

    function get_or_else($array,$key,$default=null)
       { return isset($array[$key]) ? $array[$key] : $default; }

This avoids any warnings, and also allows you to specify a default.

shaunxcode• 15 years ago

Hey, in case you are interested I constructed a reply to your post here: http://commonphp.blogspot.com/2011/05/keyword-functions-in-p...

In a nut shell though it's essentially a write up of my library which allows for creating keyword function wrappers so you can do stuff like:

   myStrPos(
       needle, 'peter', 
       haystack, 'is peter in here?'
   );

mikey_p• 15 years ago

Related: http://www.phpwtf.org/

cgranade2• 15 years 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.

eru3• 15 years 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• 15 years 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 ) but there doesn't seem to be much progress on it.

nimrody• 15 years 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).

cgranade2• 15 years 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.

snorkel3• 15 years 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.

eru3• 15 years 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• 15 years 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.

snorkel3• 15 years ago

I prefer Javascript for example: JQuery's calling conventions would not be possible if function args were mandatory.

headShrinker• 15 years ago

I really don't mind this, I have more more control because of it. If I want the function to error out upon arg omissions, I will demand arguments.

If I don't require args: function foo($arg1=null, $arg2=null) {return;} foo(); // return no error

This is great for me, when I am writing an API and have some args that are required and others that are optional.

BruceForth• 15 years 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_duck8• 15 years 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• 15 years ago

Probably the same type of developer that assumes WordPress is an example of professional PHP code.

snorkel3• 15 years 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.

ceejayoz4• 15 years 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..

rimantas• 15 years ago

Is PHP that different from other platforms in this regard? Any Java programmer knows ins and out of Tomcat, any ASP programmer is MSSQL expert?

sparkygoblue• 15 years ago

This horse has been beaten, mutilated, and buried.

ryan-allen6• 15 years ago

Obviously not quite buried yet.

jrockway3• 15 years 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.

generalk3• 15 years 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• 15 years 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.)

EamonLeonard3• 15 years 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_duck8• 15 years ago

Raising awareness of what needs to be fixed is the first step.

EamonLeonard3• 15 years 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.

dexen5• 15 years 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=119995974300003&r=1&w=2

EamonLeonard3• 15 years ago

Indeed, one of the downsides of Open Source... politics etc, it doesn't help, but tends to come with the territory.

philolson• 15 years 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

jessedhillon12• 15 years ago

The core team has it's own priorities, and has a history of ignoring the requests of the dev community. A couple of examples: in version 5.3, they added `goto`. WTF. Who, after five major releases, decides that what a language really needs is `goto`.

In the same release, they decided to finally add namespaces. But, despite the tired claim that PHP takes cues from C/C++/Java, they did not reuse :: (aka paamayim nekudotayim) as the scope resolution operator. Instead, they devised a new operator: '\'.

There is an IRC log somewhere where you can read the painful arguments back and forth over what this operator should have been. One of the rationalizations for the backslash was that it makes sense to Windows developers, as they are already familiar with the idea of '\' being used to separate elements of a hierarchy.

The end result:

Java:

Attribute/Method access: foo.bar

Static method access: Foo.bar

Package access: foo.bar.baz

C#:

Attribute/Method access: foo.bar

Static method access: Foo.bar

Namespace access: foo.bar.baz

Python:

Attribute/Method access: foo.bar

Static method access: Foo.bar

Module access: foo.bar.baz

PHP:

Attribute/Method access: $foo->bar

Static method access: Foo::bar

Namespace access: foo\bar\baz

wvenable16• 15 years ago

None of these languages except for PHP have their own string concatenation operator. They overload + for that purpose. They're also all strong typed languages while PHP is weakly typed. Overloading + for string concatenation in a weakly typed language is a recipe for disaster (see JavaScript).

> Who, after five major releases, decides that what a language really needs is `goto`.

It makes it a much easier compilation target.

> But, despite the tired claim that PHP takes cues from C/C++/Java, they did not reuse ::

They couldn't because unlike C/C++/Java the entire project isn't compiled at once. At compile time, PHP has no idea that the symbol preceding the operator is a class name or namespace from one run to the next. It might have been possible to resolve that with major changes to the underlying engine or maybe not. I absolutely hated the idea of the backslash when proposed but after using it for a while it seems fairly comfortable.

zokier• 15 years ago

Many flaws in PHP are unfixable without breaking compatibility, and if you break compatibility you lose the only advantage that PHP has these days.

stevep98• 15 years 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

wvenable16• 15 years 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.

jwatzman2• 15 years 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

pornel4• 15 years ago

    unset($bar)

after the first loop is highly recommended.

unfletch2• 15 years ago

I filed that bug 7 years ago and they wouldn't fix it: 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.

wvenable16• 15 years 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.

jessedhillon12• 15 years 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• 15 years 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• 15 years ago

Missed one:

    foobar() is the same as FOOBAR()
    $foobar is completely separate from $FOOBAR

chernevik• 15 years ago

I grok none, but of Python they make me glad

SeoxyS• 15 years 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• 15 years 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).

Topaz2078• 15 years ago

By popular demand, I've added a discussion board to phpsadness.com. Join the discussion!

voidr• 15 years 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

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• 15 years ago

Don Hopkins gave a thorough list of things which are wrong with PHP.

http://www.jwz.org/blog/2011/05/computational-feces/#comment...

These are things in PHP which make me sad

Related Stories