just kill it

Posted Mar 24, 2010 17:08 UTC (Wed) by b7j0c (guest, #27559)
Parent article: Resetting PHP 6

actually "fixing" php would require creating a language syntax and a runtime incompatible with php5, in which case rasmus et al might as well cede the future to a better-designed general purpose scripting language like python or even javascript

as it stands, the php world is already fracturing. facebook, the most prominent user of php, is moving to their own c++ based hiphop toolchain...which effectively means they have forked php and can make language-level changes if they want. i presume the abysmal memory bloat and performance of the stock php runtime have induced this change. i doubt facebook devs even care what rasmus does at this point.

but lets not leave the language syntax out here. php's enthusiastically juvenile syntax is only appropriate for the most novice coders. everyone else with any experience rapidly hits the wall with the language. i don't even want to know how the php team would fix this, their current language syntax decisions indicate they have no business designing languages.

rasmus, its time to admit that php has reached the end of its effective life. put php5 into support mode and encourage the use of better languages with better runtimes.

just kill it

Posted Mar 24, 2010 17:45 UTC (Wed) by clump (subscriber, #27801) [Link] (1 responses)

rasmus, its time to admit that php has reached the end of its effective life. put php5 into support mode and encourage the use of better languages with better runtimes.

Seems a little harsh. Can you point to any examples where what you suggest has happened?

just kill it

Posted Mar 24, 2010 18:31 UTC (Wed) by b7j0c (guest, #27559) [Link]

i'm not sure what you mean by examples. my basic point is that fixing php would mean effectively scrapping it. considering the debacle over basic language decisions like namespaces, its clear that php5 cannot be "patched"

just kill it

Posted Mar 24, 2010 18:48 UTC (Wed) by ikm (guest, #493) [Link] (1 responses)

I think PHP began as a simple preprocessing language. In C/C++, when you have an .h file you want to include into each and every .c file, you use the preprocessor directive "#include". What if you want the same thing for html? Say, have all pages the same header or footer? That's right, put "include" or "require" statement inside of your .html, rename it to have the .php extension - and you're done. That's the actual originating use of PHP, I presume. Of course it continued from then, but I think it never really evolved into an actual programming language -- rather than that, it stated the preprocessing one.

So basically, when you have a lot of html and only need simple structuring (e.g. make them use a single header or footer), you use PHP. If you're doing something much more complex, you'd probably be better with some other language. Therefore I think php have its niche and it isn't going anywhere.

just kill it

Posted Mar 25, 2010 4:25 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

SSI already provided 'include' functionality. People wanted more features and PHP provided them, sadly without much of an overall design.

just kill it

Posted Mar 24, 2010 19:07 UTC (Wed) by jwarnica (subscriber, #27492) [Link] (1 responses)

There are lots of things wrong with "PHP", but syntax is hardly one of them.

PHP syntax is far more expressive then, say, Java. And far less annoying then the sigi hell of Perl.

It sucks that the core libraries seem to have random parameter ordering. It sucks that there are a lot of brain-dead php apps out there. It sucks that there are a lot of brain-dead PHP coders out there. But syntax? That is the least of PHPs problems.

just kill it

Posted Mar 24, 2010 22:07 UTC (Wed) by elanthis (guest, #6227) [Link]

The PHP syntax sucks, and I say that as someone who has worked with it
professionally since 2000. Saying that some other languages are worse is
irrelevant; by that kind of reasoning, PHP is perfect in every way because
some other language out there has surely done it all even worse.

PHP 5.3 namespace syntax? The fact that it _just_ finally got real
closures? Unknown identifiers are treated as strings? Function calls
can't be used in any general expression (e.g., foo()->bar() does not work,
but $tmp = foo(); $tmp->bar() does) ? No pass-by-name function parameters
(for no logical reason, just "it's not the PHP way") ? Type hinting for
objects and arrays only? Inconsistent special operator names?

Granted, you're right, the syntax is not PHP's biggest problem. The entire
implementation is its biggest problem. The compiler is crap, buggy,
unpredictable, and can't deal with any kind of failure (no way to catch and
gracefully fail on a parse error when including another file, for example).
The language is slow. The C API is hideous. Many of those syntax warts
are all but forced by the internal implementation, which itself grew out of
a lack of abstraction between the crappy original syntax and the runtime
engine.

If I were to do a PHP 6, it would be just a cleanup of the internals, all
deprecated APIs removed, and something very clean and easy to build upon so
that 6.1, 6.2, 6.3, etc. can start delivering at a higher quality.

That is basically what PHP 5 ended up being, and look how much life that
breathed into PHP.

just kill it

Posted Mar 24, 2010 19:19 UTC (Wed) by robla (subscriber, #424) [Link] (10 responses)

"...their current language syntax decisions indicate they have no business designing languages.

In your world, who should decide who gets to design programming languages?

just kill it

Posted Mar 25, 2010 5:11 UTC (Thu) by b7j0c (guest, #27559) [Link] (9 responses)

anyone else

I guess I'm just not so cavalier....

Posted Mar 25, 2010 5:42 UTC (Thu) by robla (subscriber, #424) [Link] (8 responses)

...about trash-talking other people's hard work. PHP allowed a lot of
people to start programming who might not have ever gotten slurped into
programming. The apps created by those new developers (e.g. Wordpress,
MediaWiki, Drupal, etc) are applications that are running some of the
highest traffic websites in the world. While those applications could have
been written by "real" programmers in "good" programming languages, the
fact of the matter is that the "real" programmers just didn't have the time
or inclination to write those apps. So, now we have a lot of great
applications that may not be so pretty under the hood, but they often still
do the job better than any other application out there, and may not have
otherwise existed had PHP not been around.

Want to see something kinda funny? Check out http://www.haskell.org/ I
doubt you're going to find too many people out there that would lump
Haskell in with the "bad" languages. In fact, it could very well be
something a lot of us are writing production apps in a decade from now.
However, guess what they're using to host haskell.org...:
http://www.haskell.org/haskellwiki/Special:Version

I guess I'm just not so cavalier....

Posted Mar 25, 2010 14:22 UTC (Thu) by Simetrical (guest, #53439) [Link] (6 responses)

Please don't cite MediaWiki as an example of a great app written in PHP.
Pretty much all of us MediaWiki developers hate the language passionately
and wish we were using something else. (Although, not all of us agree on
what that something else should be.)

PHP is *not* easier to learn than, say, Python. That's just not true IMO.
And it's definitely not true that MediaWiki wouldn't have existed if not for
PHP. phase2 was written in Perl, IIRC, and it was a couple of people's
decision to pick PHP for phase3 -- it would have been written either way.

I guess I'm just not so cavalier....

Posted Mar 25, 2010 18:21 UTC (Thu) by robla (subscriber, #424) [Link] (5 responses)

Sorry, I'd forgotten about the UseModWiki days, though I'm going to bet that the anti-PHP crowd here doesn't really have a higher opinion of Perl. At any rate, Wordpress and Drupal still qualify, and there's a ton of other really useful software that falls into that category.

The thing that PHP has historically had going for it is mod_php, which was for a very long time way better than mod_perl and mod_python. It had the added benefit of being turned on by default in many contexts (e.g. cheap web hosts). That sort of availability made web programming a lot more accessible to a lot more people. That's not really a triumph of language design so much as interpreter design, but I do find it peculiar that Perl and Python couldn't beat PHP in this area, given the long headstarts they had.

Speaking of interpreter design, I think Python's Global Interpreter Lock is something that bears every bit as much scrutiny as any of PHP's deficiencies. While I'm not interested in starting a PHP vs Python flamewar (I happen to be primarily programming in Python these days), I think this just goes to show you that there's always tradeoffs in picking languages.

I guess I'm just not so cavalier....

Posted Mar 25, 2010 19:58 UTC (Thu) by Simetrical (guest, #53439) [Link] (4 responses)

If PHP hadn't existed, web hosts would be using something else instead. Probably something based on Unix permissions instead of things like open_basedir and max_timeout that try to enforce permissions or resource limits in userspace, thereby prohibiting perfectly sane things like shelling out to other programs.

If web hosts used something else, web apps would be written in something else. It's that simple. Wordpress and Drupal are web apps that happen to be written in PHP, not consequences of PHP's existence. I'd bet that they're written in PHP because that's how you reach the largest audience, because that's what webhosts use.

The Python GIL is a nonissue if you're running single-threaded code. Does PHP support multithreaded execution at *all*?

I guess I'm just not so cavalier....

Posted Mar 25, 2010 21:18 UTC (Thu) by foom (subscriber, #14868) [Link] (1 responses)

> The Python GIL is a nonissue if you're running single-threaded code.

Not really...Python doesn't properly support multiple distinct interpreters within a process -- you
can do it, but they aren't properly isolated from each-other. One important way they aren't isolated:
they all share the same GIL. So, you can't even properly run multiple single-threaded python
interpreters within a multithreaded process. It works, but only one thread can actually run at a time,
across all interpreters.

So of course that means you can't run python (efficiently) within a threaded apache.

I guess I'm just not so cavalier....

Posted Mar 25, 2010 22:31 UTC (Thu) by Simetrical (guest, #53439) [Link]

As far as I know, many/most PHP modules don't work at all with a threaded
Apache, and it's generally advised that mod_php users stick to prefork or
FastCGI. So this isn't a big advantage for PHP.

I guess I'm just not so cavalier....

Posted Mar 25, 2010 23:29 UTC (Thu) by JoeF (guest, #4486) [Link] (1 responses)

Does PHP support multithreaded execution at *all*?

Yes, it does.
But a large part of the third-party modules are not thread-safe, so unless you limit yourself to what you can run (and test the hell out of things), you are better off not running a multithreaded build of Apache.

I guess I'm just not so cavalier....

Posted Mar 26, 2010 13:51 UTC (Fri) by foom (subscriber, #14868) [Link]

I've kinda wondered how exaggerated this problem is. I mean, the default on windows is threaded -
- do most modules blow up by default on windows? That seems like a problem that their authors
would want to fix.

I guess I'm just not so cavalier....

Posted Mar 25, 2010 17:12 UTC (Thu) by b7j0c (guest, #27559) [Link]

you're getting offtopic

is it possible to write a great app in php? yes

have some people done it? yes

do most people who have done it want to consign php to the dustbin of history? YES

just kill it

Posted Mar 25, 2010 14:25 UTC (Thu) by Simetrical (guest, #53439) [Link]

Wikipedia is one of the other biggest users of PHP, and we're probably going
to move to Hiphop when it matures somewhat. Domas Mitzuas, volunteer
performance engineer for Wikipedia for the last several years, also happens
to be a DBA at Facebook. Since MediaWiki is used so widely, though, we'd
have to still be compatible with stock PHP.

(This is just a guess, though, not any official statement -- I have nothing
to do with Wikipedia systems administration, only MediaWiki development.)