Live data from Hacker News

PHP: A fractal of bad design

me.veekun.com

281–290 of 514 posts

Re: PHP: A fractal of bad design

#281
post #280

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

OK, say there were only 2 people working on the (any open-source project). How do you think it would look today?

I think it pretty basic an assumption that the more eyes looking at something, the better the chances of finding (and fixing) mistakes as well as finding room for improvement.

Re: PHP: A fractal of bad design

#283
post #190

Earlier quoted context omitted.

Because it's late and took such a long time to do! I've posted it in another reply. My wife is actually wondering why I haven't gone to bed yet.

Makes me immediately thinking of http://xkcd.com/386/ ;-)

Actually, it made me think the same thing when I wrote it.

Re: PHP: A fractal of bad design

#284
post #13

Since my day job is PHP-centric and I was already aware that PHP is awful, this is theoretically helpful to me, but oh lord, it makes my liver hurt. If I could get away with it, I'd never again trust my credit card number to a system based on PHP, but I suspect that that's about as easy as never trusting your credit card to an ATM/point-of-sale machine based on Windows.

That PHP logo trick is going to make it easy to spot companies with a wobbly PHP stack. http://www.0php.com/php_easter_egg.php

Per the docs[1], this can be turned off in the ini by setting expose_php to Off. So if you tell PHP to hide its presence, it will do so.

1. http://www.php.net/manual/en/ini.core.php#ini.expose-php

Re: PHP: A fractal of bad design

#285
post #75

Earlier quoted context omitted.

You can blame Larry Wall (Perl) for that one. It's amazingly powerful but also the stuff of nightmares in the wrong hands.

Nope. This works as you'd expect in Perl: the replacement is treated as code and executed like an inline function, never eval'd.

If you're implying that `/e` is more dangerous in PHP than in Perl, then that is truly terrifying.

Re: PHP: A fractal of bad design

#286
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…

> I, for one, hate throwing an exception when an item isn't found. This sucks:

You can always do:

    index = a_list.index(a_value) if a_value in a_list else -1

Re: PHP: A fractal of bad design

#287

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…

What? I find working with databases in PHP (using PDO) far more enjoyable and fast than, say, working in Python.

I'm not surprised. A big advantage of PHP's database layer is that it doesn't reinvent the SQL wheel.

[set Greenspun Cynicism Level to MEDIUM HOT]

Other platforms wrap up SQL to the extent that you are encouraged to pretend it does not exist. This is an irreplaceable killer feature if you are trying to encourage new programmers to design things that will eventually prove difficult for them to optimize, or are trying to drum up membership in the NoSQL-silver-bullet-of-the-month club, but in the end what was good for 1996 is still pretty good for 2012: Pull the data from the database using classic SQL from the 1970s, loop through the result set, paste each row into the template, and ship it out to Apache.

PHP does this transparently, which makes it relatively easy to figure out what is going on. Of course, what is going on may be "the novice PHP programmer is staring directly at the SQL but still cannot optimize it", but hey, at least now you can see the problem.

[set Greenspun Cynicism Level to LOW]

Re: PHP: A fractal of bad design

#288

Earlier quoted context omitted.

"Sticking a php file in a directory" is just a matter of server config, not languages. There is no reason why you can't put a quick Python web app in a single file which exposes just one WSGI application object named 'application' - so if the server complied, you could indeed just stick the .py file in a certain magical directory.

Then why haven't anyone done it? Cause as a designer who programs (mainly php) that is the number one reason why I haven't been learning a new language. They all require way too much. Php just works for my needs. If I get bigger needs then I am sure I will make the switch to another language.

> Then why haven't anyone done it?

It's been done times and times again. Look at Sinatra for an example in the ruby world (http://www.sinatrarb.com/), I'm sure python has something similar. Maybe a static site generator such as octopress or push would be an option as well.

The problem is that the simple php approach does not scale. Sticking files in directories will only get you a small step, you'll need includes to share code soon. And then the mess starts if you're not using a framework. And good PHP frameworks go a long way beyond sticking a file in a directory - you'll have the same steep learning curve as with rails or something similar.

Re: PHP: A fractal of bad design

#289
post #163

Earlier quoted context omitted.

> Operators are very fragile in the parser; foo()[0] and foo()->method() are both syntax errors. The former is allegedly fixed in PHP 5.4, but I can’t find mention of a fix for the latter. The latter doesn't need a fix because it always worked. Honestly, how hard is it to test that foo()->method() works? > == is useless. Actually, it's not useless. It does have a few stupid edge-cases and I will admit that. But in mo…

Only a couple of these things are outright wrong; I removed the offending bullet points earlier tonight. A few things I listed because they're weird, not outright wrong, and I stand by those. For the most part you've defended PHP's behavior as design decisions or offered workarounds. Workarounds just demonstrate that the language is Turing-complete. Design decisions are only okay if they actually make a useful tradeo…

> A few things I listed because they're weird, not outright wrong, and I stand by those.

But a few things are weird to you but not some objective view of weird. Many of your points I didn't comment on are not unique to PHP at all (such as octal numbers)

> For the most part you've defended PHP's behavior as design decisions or offered workarounds.

You could say that unifying PHP error codes and exceptions is a "workaround" but the language provides specific support for it (The ErrorException class) so it's pretty much a standard pattern. The end developer has the choice of development style.

> PHP doesn't need a module system? What?

I have projects with thousands of files -- as someone else said, Namespaces and Autoloaders covers this.

Re: PHP: A fractal of bad design

#290

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