Live data from Hacker News

These are things in PHP which make me sad

phpsadness.com

131–140 of 217 posts

Re: These are things in PHP which make me sad

#132
post #46

Earlier quoted context omitted.

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

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

You would prefer, when encountering an incorrectly used double colon operator, PHP said "Syntax error"? Even when I'm directed to look only at the surrounds of the double colon, it has been difficult to understand the problem in some cases... it looks like valid syntax. Now, you might say that this is a problem with PHP's syntax, and I have no defense against that, but rolling this into "invalid syntax" with no further explanation would cause no end of trouble for those new to OO in PHP.

Re: These are things in PHP which make me sad

#133
post #81

Earlier quoted context omitted.

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.

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

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.

Re: These are things in PHP which make me sad

#134
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.

Re: These are things in PHP which make me sad

#135
post #85

Earlier quoted context omitted.

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

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

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.

Re: These are things in PHP which make me sad

#136
post #22

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.

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?

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

Re: These are things in PHP which make me sad

#137

Earlier quoted context omitted.

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…

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

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 the creators of your framework wanted to do, and as long as you're willing to stop by and maintain your app. PHP is more of a fire-and-forget language for apps... you can write it and then ignore the app for years without worrying about memory leaks or crashes or that it's taking up resources on your virtual server...

With mongrel2, I can restart my app instances without losing a single request!

Wow, what an achievement! This is the one thing that PHP really, seriously got right: no application server. There are applications out there that need the extra efficiency of not starting up on every request, but the vast majority of webapps do not. The additional robustness and sanity provided by not having to wonder why your app server fails after 292744 requests, or what went wrong when it just stopped responding, or whether, indeed, you might lose requests when restarting -- that helps me sleep at night. Few webapp-oriented languages have this, preferring instead to try over and over to get the application server paradigm right, this time, for sure! We just have to add a little shim here, and build another layer over these layers to interface with that one...

Re: These are things in PHP which make me sad

#138

Earlier quoted context omitted.

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.

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

"PHP is mostly a static language; it has more in common with Java than with say Ruby."

Can you expand on that point a bit? I see PHP as far more similar to Ruby than Java when it comes to dynamic vs static.

Re: These are things in PHP which make me sad

#139
post #133

Earlier quoted context omitted.

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

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.

Re: These are things in PHP which make me sad

#140
post #16

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!

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.

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
Post reply on HN