Live data from Hacker News

These are things in PHP which make me sad

phpsadness.com

171–180 of 217 posts

Re: These are things in PHP which make me sad

#171
post #82

Earlier quoted context omitted.

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

You can always use func_get_args() if you truly want it that way.

Or you could just use a real programming language that has some kind of design.

Re: These are things in PHP which make me sad

#172
post #28

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 jqGr…

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.

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.

Re: These are things in PHP which make me sad

#173

Earlier quoted context omitted.

Also, the days of PHP's deployment superiority are nearly over. So I've been hearing since 2000 or so, when I chose RXML/Pike over PHP because PHP was a complete mess. PHP has gotten considerably better since then; now it's only painfully messy, rather than unusable. Sometimes it seems like every competitor has been busy building castles in the sky full of magic and wonder -- as long as you want to do exactly what th…

> Wow, what an achievement! This is the one thing that PHP really, seriously got right: no application server. I think you mean PHP has no 'apparent'. It damn well does have an application server, it's called mod_php embedded in Apache processes or php-fcgi backends. The thing is, that PHP apps DO fail after a certain number of requests, it's just hidden from you. Internally PHP ships with a MAX_REQUESTS (which defau…

Well, if you're considering Apache+plugin to be an application server, then I guess I need to say: no additional application server other than the web server. Most modern systems have a web server and a separate process for the application server (proxied to over HTTP or fed by FastCGI or WSGI or a neat otherwise unused protocol). The standalone application server (back when I was mostly using those languages) always seemed to have a bunch of quirks and to fail at every insult. Compared to the Rube Goldberg nature of some of these stacks of servers and protocols, PHP is delightfully simple, conceptually.

Re: These are things in PHP which make me sad

#174
post #133

Earlier quoted context omitted.

You missed the point: they are talking about people who do not know those aspects of the LAMP stack, not the ones who can afford delegating them to DBAs and sysadmins. The first group are indeed glorified web page editors.

Again, bullshit. I've had PHP projects that were entirely command-line with no Apache and MySQL. If you want to argue that those projects weren't development, that's absurd. Systems and database administration are hugely complimentary skills, but someone who doesn't know anything about setting either one up is still developing.

I agree with you in a literal sense. I'd add the adjective 'extremely poorly' to 'developing' for any developer who doesn't have a thorough grasp of the system for which they are developing.

Re: These are things in PHP which make me sad

#175

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.

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 nekudo…

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.

Re: These are things in PHP which make me sad

#176
post #82

Earlier quoted context omitted.

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.

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

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.

Re: These are things in PHP which make me sad

#177

Earlier quoted context omitted.

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 "…

It's not a bug because it's not a bug. How would you propose they fix this non-bug anyway? At the end of the first loop, $item contains a reference to the last item in the array. Just as $item would contain the value of the last item in the array if you weren't using references. In the next loop, $item still contains that reference so now you're overwriting the value of that reference. You can't assume the second loo…

The fix for this is that foreach should create a new iterator variable which overwrites the existing one. That would preserve expected behavior.

I think you should pause for a minute and summarize all of the WTFs you've rationalized on this post. Just the volume of it makes me incredulous that you don't think PHP == FAIL (or perhaps === if you like).

Re: These are things in PHP which make me sad

#178

Earlier quoted context omitted.

> Wow, what an achievement! This is the one thing that PHP really, seriously got right: no application server. I think you mean PHP has no 'apparent'. It damn well does have an application server, it's called mod_php embedded in Apache processes or php-fcgi backends. The thing is, that PHP apps DO fail after a certain number of requests, it's just hidden from you. Internally PHP ships with a MAX_REQUESTS (which defau…

Well, if you're considering Apache+plugin to be an application server, then I guess I need to say: no additional application server other than the web server. Most modern systems have a web server and a separate process for the application server (proxied to over HTTP or fed by FastCGI or WSGI or a neat otherwise unused protocol). The standalone application server (back when I was mostly using those languages) always…

> Compared to the Rube Goldberg nature of some of these stacks of servers and protocols, PHP is delightfully simple, conceptually.

I agree that what you could call it's deployment API (or whatnot), that it is very simple. I think the reason for it's success is it allowed HTML/CSS 'programmers' to progress to simple scripting within their existing deployment metaphor (upload via FTP, use a PHP file extension, wrap PHP in However, there's no reason that you couldn't design a similar thing in say, Ruby or Python, where people upload files with a specific extention FTP and it runs some templating language (like ERB or Pythons equivalent). You'd need some web api to allow triggering reloads of files (or reloads on every request if the server is being used for development).

PHP out of the box re-parses _every single script on every single request_, which is what you'd expect a development environment to do, but 'in production' that's what PHP has always done.

Hence were born the optcode caches (which work rather well now), like APC. But still, on every request, every file that is required has a stat performed on it (you can turn this off, though).

It's all very lowest common denominator, and the high end stuff is severely lacking and poorly documented. It's possible to have the best of both worlds (well designed language, pragmatic libraries and toolset out of the box, simple deployment AND well defined high end high traffic considerations), but PHP ain't it.

Re: These are things in PHP which make me sad

#179

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.

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).

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.

Re: These are things in PHP which make me sad

#180

Earlier quoted context omitted.

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 nekudo…

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…

I know that there are reasons for this behavior. None of them are good, however. Why couldn't they reuse the same resolution operator for all three, even if it's not the period character?

Looking at your responses all over this post, there is a big disconnect. Other people -- who probably use and enjoy other languages -- raise issues with PHP that point at poor design. Then you respond with a rationale for why the well-designed thing couldn't be done. (Or, why the poorly-designed thing was done.)

But all designs have rationales. The point is that the people who make design decisions for PHP choose poorly. Even if you give us the rationale, that doesn't make it a good decision in retrospect.

Also, could you explain this statement please:

> It makes it a much easier compilation target.

Do you mean that other languages can be compiled to PHP more easily? Because I have never heard this rationalization before.

Post reply on HN