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

Taking PHP Seriously

slack.engineering

Post reply on HN
Print view View original

471–480 of 673 posts

Re: Taking PHP Seriously

#471

Post by happyslobro »

oliverkyss wrote: post #436
codedokode wrote: post #425

Earlier quoted context omitted.

Try console.log([] * {}) and be surprised. At least in PHP you cannot multiply array by object. Type casting in PHP gets fixed gradually: https://wiki.php.net/rfc/invalid_strings_in_arithmetic .

Why would that be surprising? NaN as a result definitely means that you cannot multiply array by object in JS either. JavaScript uses IEEE 754 special values, not exceptions on arithmetic errors (eg 1/0 returns Infinity instead of throwing). If you bother to learn the language, it doesn't surprise you.

The problems start when you notice that your untyped key-value store has a bunch of NaNs where you were expecting a number. At this point, all you can do is pray that those numbers weren't very important, in the grand scheme of things.

Re: Taking PHP Seriously

#472

Post by Zachery »

Tehnix wrote: post #170

>Asynchronously curl’ing to localhost (or even another web server) provides a shared-nothing, copy-in/copy-out way of exploiting parallelism Wait, wait, wait, wait. Is he saying that to do async work he'll send a curl request to somewhere (spawning a thread for that request), not wait on the output and carry on? Last I used curl in php it was a synchronous action. Hell of a threading model there.

You can do some decidedly hacky stuff with PHP if you are smart about it. To get background tasks to run in a popular forum software, the system would send an ajax request to the cron script. The cron script would return a 1x1 clear gif and "close" the connection. The script would then be run in "in the background". It would be easy to do the same thing there. curl another script and have it instantly return nothing while it continues to process.

Re: Taking PHP Seriously

#473

Post by matthewking »

leeoniya wrote: post #4
rpeden wrote: post #2

I've had to do some PHP work recently, on a fairly old school PHP codebase for a high traffic website, after spending most oy my career working in Java and C# (and I still do most of my work in those languages). I've read a lot of PHP hate over the years, but I've found working with it in practice to be decidedly...not bad. Perhaps the codebase I inherited is better than most. But I've had to make some fairly major u…

The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C. The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3]). But PHP7 is both fast and productive with many modern first-class features. You can in fact write excellent code without much effort that will handily outperform Py…

> The Wordpress codebase [plugin api included], though, is utter garbage.

I've always heard this and never actually used Wordpress myself. Has anyone ever studied WHY its garbage? and how did it get to that state? is it getting better or are the latest additions and changes still garbage code?

Re: Taking PHP Seriously

#474

Post by apotheon »

guitarbill wrote: post #412
Gruselbauer wrote: post #405

Earlier quoted context omitted.

In Germany, we used to have a VK-like social network aimed exclusively at university students that was big before Facebook even appeared. To this day I have no idea how that died so fast and hard, and how Facebook managed to overtake it when it hadn't even translated the interface. Ze English izn't zecond nature to all ze Germans.

Ah yes, the * VZs. From my perspective, there's a few reasons. One, my friends were very privacy conscious and would often either not sign up or use a weird name (like some people do). This made it hard to find people. Two, the user experience sucked hard. Third, they had different domains for different subgroups (I remember one for school children and one for students). Finally, if you went travelling to any other c…

It's a testament to the poor state of the art in user experience for early social networking sites that Facebook had a (relatively) "good" user experience. It has always been horrible, except relative to most of its competitors.

Re: Taking PHP Seriously

#475

Post by stephenr »

toast0 wrote: post #157
mikey_p wrote: post #72

Earlier quoted context omitted.

The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. This is usually done on startup or at least cached in memory once it's loaded. This is something that you have to manage more carefully with a PHP app since you can't have anything initialize…

> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing…

> In my mind, auto-loader is a sign that nobody knows what's being loaded

Or that, you know. There is an extremely powerful language feature and the developers are taking advantage of it.

Re: Taking PHP Seriously

#476

Post by stephenr »

bpicolo wrote: post #187
leeoniya wrote: post #179

Earlier quoted context omitted.

I can't tell you how much more "runtime state" exists in PHP than in say Java. In both cases you need to initialize some sort of security-aware context. Once you've eliminated parsing, disk i/o and compilation phases. You should be on pretty even ground of bytecode vs bytecode. Java has a Hotspot JIT, so it will probably win there. I think a JIT is coming to PHP as well since the architectural rework that went into P…

There's more too it than that though, yeah? Say you use a service that uses oauth2 authentication. You need to do a request to pull in a oauth token. If you lose all state between requests, you waste time re-fetching tokens. In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality

> In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality

apc_fetch/apc_store hardly seems painful.

Re: Taking PHP Seriously

#477

Post by novaleaf »

yxhuvud wrote: post #392
ddw wrote: post #353

Earlier quoted context omitted.

But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.

Managers caring about technical debt? You must live in a parallel universe. They may care about maintenance costs, but that is not really the same thing.

the end result of technical debt ==> maintenance costs makes it same enough.

Re: Taking PHP Seriously

#478

Post by combatentropy »

Tehnix wrote: post #345
bkanber wrote: post #104

Earlier quoted context omitted.

> Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once. I mean, you're not reinitializing it, and it's not exactly slow. And when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to…

>when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere It's just as easy to scale with other languages, you would keep the data that needs to be persisted in a DB. The benefit comes from things that does not need to be persisted…

Look, if you want to use something other than PHP, don't let me get in your way. However, if PHP is one thing, it is fast and always has been.

  > Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory
We don't use any of that. We don't even use database connection pooling. Every request has to reopen the database. Every request has to reopen an LDAP connection to Active Directory for authentication. We are still on PHP 5.3 and we aren't using an opcache. We are using the memory-hungrier mod_php instead PHP-FPM, and we are using the slower, memory-hungrier Apache prefork instead of its newer event MPM. We are also running PostgreSQL on the same server. And yet PHP is connecting to the database over the slower network instead of UNIX domain sockets.

Every request takes just a split second. The server's processor is running at 1-2%, with about half a gigabyte of RAM in use, a lot of which is probably the database.

All those inefficient design decisions are artifacts of history that I hope eventually to revise out --- except for connection pooling, which I've read has its own problems. On my personal website I've been able to choose the newer and better things, but none of them were really more work to set up: Apache event MPM, Unix domain-socket connections, PHP-FPM, and PHP's OPcache.

Re: Taking PHP Seriously

#479

Post by apotheon »

bbcbasic wrote: post #380
eyelidlessness wrote: post #373

Earlier quoted context omitted.

What does PHP offer, now, that a static site generator doesn't? I'm going to guess Wordpress, WYSIWYG editor, simple uploads. But if that's not it, I'm genuinely curious.

Dynamic content.

For many use cases, this is not relevant to the end result.

For many use cases where it is relevant, static site generators like Jekyll can actually imitate "dynamic content" from the perspective of the people running the site.

The most important use cases for dynamic content these days are web applications, as distinct from "websites". On the other hand, web applications are also the most important use cases for better development ecosystems than are easily attained with PHP.

In my experience and observations, the cases where PHP's easy provision of dynamic content capabilities make the most difference are websites (as distinct from "web applications") on shared hosting platforms or bootstrapped by existing content management systems like WordPress and Drupal (which are, in turn, often easily used because of either hosting platforms specifically for those CMSes or shared hosting providers).

NOTE: I'm not sneering at "websites", as distinct from "web applications", as many people who draw such distinctions do. I'm just pointing out there is a distinction to be made between two different types of projects involving deployment of a codebase to a web server. Speaking only of the technology's proximate purpose: in one of these, the primary purpose of it is to make content accessible to the public; in the other, the primary purpose is to make functionality accessible to a userbase.

Re: Taking PHP Seriously

#480

Post by apotheon »

collyw wrote: post #390
anexprogrammer wrote: post #244

Earlier quoted context omitted.

PHP devs aren't expensive. Even good ones. It's easier to reroll in another language and retrain or recruit? No. So you probably mean for a new project. So now you've more maintenance and learning curve unless you just happen to have enough skilled in $NEWTHING. Not really easier. PHP is an inconsistent mess, everyone knows that, but it's cheap, widely understood, and it's perfectly possible to write decent maintaina…

True, I have seen one startup fail early because he couldn't find any (cheap) Django devs. He might have stayed around another year with the funding he had if he had gone PHP.

Lesson Learned: If you can't do it yourself, start with PHP (or something else with incredibly cheap devs, I suppose) until you get VC funding, then rewrite it using something other than PHP.
Post reply on HN