Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP: A fractal of bad design

me.veekun.com

Post reply on HN
Print view View original

331–340 of 514 posts

Re: PHP: A fractal of bad design

#331

Post by aGHz »

hardy263 wrote: post #304
ceol wrote: post #293

Earlier quoted context omitted.

> So your complaint is that when you use @ to suppress an error it... suppresses the error? From your edit, you've only been working with PHP for about 6 months, so you may not have seen some of the code most others have. Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on eve…

> Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on everything. You've turned something that's a person's fault into something that's the language's fault. Other languages have some sort of warning suppression as well, like Java's @SuppressWarnings or C#'s #pragma warning di…

The article tries to be a comprehensive list of problems with PHP and @ is a notorious one, even if you personally are disciplined enough to avoid it.

Not to mention that I have no idea why the original commenter picked on this. It was listed as one of the 7 or so things that can go wrong with that one single, not unusual line of code. It's not like he had a whole paragraph about why @ is bad.

Re: PHP: A fractal of bad design

#332

Post by TylerE »

BCM43 wrote: post #280
obituary_latte wrote: post #274

Earlier quoted context omitted.

It seems that many people disregard the fact that PHP is a very accessible language to a programming newcomer. You can quickly and easily install LAMP or MAMP and in minutes have a working, dynamic web page (albeit local) along with a plethora of examples and tutorials. This is huge. This shows the newcomer that this mysterious code stuff is actually accessible; that they can create something that works. That's a nic…

More programmers===better programs. How can this be a bad thing? I'm not sure this is true. Going with the articles example, that's like saying "the more people who know how to use a hammer, the better houses we will have".

It's true in the sense that giving everyone desktop publishing software in the early 90s led to lots of beautiful typography and well thought-out layouts.

Re: PHP: A fractal of bad design

#333

Post by white_devil »

zackzackzack wrote: post #279
white_devil wrote: post #272

Earlier quoted context omitted.

Sooo.. You mainly use PHP yourself, then?

Read his profile and you will see Java, Python, and C and he works at Google.

More than half of the top level comments are from people who use PHP. You can tell by how they rush into PHP's defense and try to argue against the article.

The original post just can't be sensibly called "anti-PHP snobbery". It just points out PHP's shortcomings. But when all these PHP-users can't really attack the truth, they attack how it's presented instead (and of course whip up some strawmen and generally just try to skirt around the issues).

The human ego is a sad thing.

(Disagree? How about commenting instead of downvoting with self-righteous indignation?)

Re: PHP: A fractal of bad design

#334

Post by smsm42 »

ceol wrote: post #293
cletus wrote: post #264

If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery. A selection from the OP: > Because of the @, the warning about the non-existent file won’t be printed. So your complaint is that when you use @ to suppress an error it... suppresses the error? > The language is full of global and implicit state. "Global" is one of those dogmatic points. Nothing is truly "global" in PHP. The "global" in PHP j…

> So your complaint is that when you use @ to suppress an error it... suppresses the error? From your edit, you've only been working with PHP for about 6 months, so you may not have seen some of the code most others have. Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on eve…

"This is the norm in PHP because, like the author said, it makes it incredibly easy to write bad code."

PHP makes it extremely easy to write ANY code. But since article saying "I've noticed this piece of good code in PHP" is not going to get on HN anytime soon, you get much more attention to bad one. That's like saying Internet is the source of filth because it makes easy to post bad stuff. It makes easy to post all stuff, that's the point.

"This was a great write-up for all of PHP's downfalls."

These "downfalls" are known and discussed 1000 times. Really, who needs another article about "PHP sucks because I can find 3 functions with inconsistent parameters"? How exactly it is going to make anything better? What exactly does it contribute to the world?

Re: PHP: A fractal of bad design

#335

Post by smsm42 »

BCM43 wrote: post #280
obituary_latte wrote: post #274

Earlier quoted context omitted.

It seems that many people disregard the fact that PHP is a very accessible language to a programming newcomer. You can quickly and easily install LAMP or MAMP and in minutes have a working, dynamic web page (albeit local) along with a plethora of examples and tutorials. This is huge. This shows the newcomer that this mysterious code stuff is actually accessible; that they can create something that works. That's a nic…

More programmers===better programs. How can this be a bad thing? I'm not sure this is true. Going with the articles example, that's like saying "the more people who know how to use a hammer, the better houses we will have".

Are you claiming less people should have access to programming? Should we have a guild with mandatory 10-year apprenticeship in Haskell?

Re: PHP: A fractal of bad design

#336

Post by Joeri »

mechanical_fish wrote: post #277
KaeseEs wrote: post #192

Earlier quoted context omitted.

PHP is not a good tool for quickly getting a minimum viable product. Despite its flaws it is a good weapon for fighting 'the last war' - that is to say, it makes it quick and easy to make what are essentially the CGI pages of 1996 - but if you're doing anything more complex than that (for instance interacting in any way with a database), and I would suggest that even relatively non-technical people looking to use com…

An important thing to remember about PHP is that it really isn't stuck in 1996: When we say PHP you need to think WordPress , or Drupal , or CakePHP or Symfony , since that's what one actually uses nowadays. Novices are steered away from code that pipes SQL injections directly to the database, and toward one of these frameworks, which does the heavy lifting for you so that you don't need to reinvent the wheel. For ye…

I actually find php well suited to client-side rendering. Implementing a web service in php is pretty easy. The only thing i use php for is building json-rpc and soap services using zend framework's service classes, wrapping around zend framework's database classes. The app itself is all javascript.

Re: PHP: A fractal of bad design

#337

Post by smsm42 »

guccimane wrote: post #276
cletus wrote: post #264

If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery. A selection from the OP: > Because of the @, the warning about the non-existent file won’t be printed. So your complaint is that when you use @ to suppress an error it... suppresses the error? > The language is full of global and implicit state. "Global" is one of those dogmatic points. Nothing is truly "global" in PHP. The "global" in PHP j…

> If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery. If there's one thing that annoys me on programmer forums in general, it's that pointing out PHP's giant flaws is conflated with snobbery. Design matters, and that is not the same thing as saying it's impossible to build anything good with PHP.

Pointing out "giant" flaws which don't really matter and can't be fixed for 1000th time is very useful for... remind me please, what exactly purpose?

Re: PHP: A fractal of bad design

#338

Post by corford »

losvedir wrote: post #269
corford wrote: post #242

Earlier quoted context omitted.

Why is PHP more likely than others to be vulnerable to SQL injection attacks? Most people (and likely All newbies) will be using PDO which automatically protects them.

This is why: http://www.google.com/search?q=php+mysql Searching for PHP and MySQL yields tons of tutorials, code examples, and documentation related to the now-deprecated mysql interface. When I wrote my first comprehensive PHP application last year I spent half a day trying to determine best practices before finally settling on PDO. Newbies won't go through that effort, and will naively land on mysql rather than PDO…

Actually, I agree with you and I think this is often missed as one of the main contributing factors to PHPs bad rep. If I had enough spare time (and a wider personal network of php pros to draw from) I'd love to make something like www.betterphp.org with short tutorials and guides teaching newbies the current best practices. As it is, anyone picking up PHP for the first time is confronted with a minefield of conflicting and out of date information, some of which is dangerous.

PHP has been around forever and Google has a long memory. Unfortunately, for every good blog post/tutorial on PHP development there are 100 or more bad or out of date ones.

Re: PHP: A fractal of bad design

#339

Post by corford »

Xylakant wrote: post #290
corford wrote: post #227

I'm not qualified to refute many of the programming points in this article but I can say that this is wrong: "Similarly, there is no easy way to “insulate” a PHP application and its dependencies from the rest of a system. Running two applications that require different versions of a library, or even PHP itself? Start by building a second copy of Apache." If you're running PHP via fastcgi (e.g. mod_fcgid on Apache), y…

But actually, then you're back to the deployment model that ruby apps used before switching to dedicated app servers and everybody said "oh, that's sooo complicated."

I'm not a ruby user so I might be missing your point but...

There's nothing stopping you running php on a separate dedicated machine from the web server. You'd just use mod_fastcgi and php-fpm.

You can run it in a webserver thread (mod_php), run it in its own process alongside the webserver (mod_fcgid), run it on a dedicated machine (mod_fastcgi) or run it from the command line.

That's the beauty of PHP, it lets you do what you want. The downside is that this flexibility can be dangerous in inexperienced / naive hands.

Re: PHP: A fractal of bad design

#340

Post by maratd »

aGHz wrote: post #331
hardy263 wrote: post #304

Earlier quoted context omitted.

> Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on everything. You've turned something that's a person's fault into something that's the language's fault. Other languages have some sort of warning suppression as well, like Java's @SuppressWarnings or C#'s #pragma warning di…

The article tries to be a comprehensive list of problems with PHP and @ is a notorious one, even if you personally are disciplined enough to avoid it. Not to mention that I have no idea why the original commenter picked on this. It was listed as one of the 7 or so things that can go wrong with that one single, not unusual line of code. It's not like he had a whole paragraph about why @ is bad.

> The article tries to be a comprehensive list of problems with PHP and @ is a notorious one

Nonsense. The @ error suppression is a tool, just like any other. It should be used sparingly, but it does have its uses. I have been writing in PHP for over a decade and I have used it exactly one time. And yes, it irritates me when I see it in other's code all over the place ... which is why I refactor all external PHP code before I place it inside of mine.

The amazing thing about PHP is that it has a plethora of tools available and the language doesn't force you to write code in some constrained manner according to what some snob perceives as the right way. The only right way is the way that works and works well.

You don't like a feature of PHP? Don't use that feature. Simple as that.

Post reply on HN