Weekly Edition
Return to the Development page
| |||||||||||||
Cracks in the Foundation (PHP Advent)
The 2011 PHP Advent site has an
article by Gwynne Raskind on the challenges facing PHP and how they
are being addressed. "PHP has always been an evolving,
almost-organic language. It has been rewritten from the bottom up at least
four times, with massive internal changes to the engine at least twice
more. Through all these mutations, however, its external interface - the
language itself - has remained quite similar for a long time. Nearly
everything that can be pointed to as different between PHP 3 and PHP 5.4 is
an addition or extension to the language, not a change in existing
behavior. There are exceptions, such as the new object model, but by and
large, a PHP coder looking at PHP 5 code will be able to make complete
sense of PHP 3, and vice versa. All of these versions share one flaw: there
is no single specification of the language!"
(Log in to post comments)
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 16:17 UTC (Sun) by niner (subscriber, #26151) [Link]
Funny how though the article clames that the language didn't change, we've had compatability problems with every single upgrade we've made in the past 8 years. I'll celebrate the day when we replaced the last piece of PHP code on our systems.
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 17:08 UTC (Sun) by HelloWorld (guest, #56129) [Link]
I also have to admire how the guy lists up quite a number of royal fuckups in the PHP language (lack of unicode support, idiotic syntax and others), yet later on claims that PHP "withstood the test of time better than any other language of its kind".
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 17:22 UTC (Sun) by smurf (subscriber, #17840) [Link]
Not to mention the absence of core security features. Even where they exist, it's simpler to ignore them.
Take SQL Injection, for instance. The database interface is one of many areas where it's FAR easier to write broken than good code in PHP. Quote
The very next article on the site aptly demonstrates this by calling a shell command like "command $var1 $var2". No quoting whatsoever. Fun.
PHP may still be the most-used programming language on the web. So what?
(Speaking of Unicode: LWN still uses ISO-8859-1 encoding
I tried to use ≠ here, but no luck.)
Unicode != UTF-8 Posted Dec 18, 2011 18:32 UTC (Sun) by khim (subscriber, #9252) [Link] (Speaking of Unicode: LWN still uses ISO-8859-1 encoding I tried to use ≠ here, but no luck.) You mean this one: ≠ ? Works fine for me. What I'm doing wrong?
Unicode != UTF-8 Posted Dec 18, 2011 19:57 UTC (Sun) by tetromino (subscriber, #33846) [Link] > You mean this one: ≠ ? Works fine for me. What I'm doing wrong?In "plain text" comment format, Unicode input and character entities both fail for me (LWN displays them as escaped character entities). In "HTML" comment format, Unicode input (e.g. Ctrl+Alt+u2260 in Firefox → ≠) as well as named (≠ → ≠) and decimal (≠ → ≠) character entities work correctly. However, the presence of a hex character entity (e.g. ≠) in a comment breaks all Unicode parsing in that comment, leaving all Unicode characters as escaped character entities, like in plain text format. This seems to be a bug in the LWN comment engine.
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 21:29 UTC (Sun) by oldtomas (guest, #72579) [Link] Take SQL Injection, for instance. The database interface is one of many areas where it's FAR easier to write broken than good code in PHPI think it's at least as much a cultural as it is a language design problem. Nowadays, PHP has prepared statements. But you don't see that used often "out in the wild". The best you get is some variations on "sql escape" which, given its interface, just can't get it right (on a short PHP stint I was horrified to see that even big frameworks like Joomla do it that way). Then, beginning hackers copy that. So, to "fix" PHP it would be necessary to "fix" all the code out there first, just to give beginners a chance to pick up good idioms.
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 7:18 UTC (Mon) by sxpert (subscriber, #19738) [Link]
imho, the problem comes from the fact that the mysql binding doesn't have a "mysql_query_params" function.
the Postgresql binding has "pg_query_params", which does the right thing...
the solution is pretty simple... stop using mysql !
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 7:52 UTC (Mon) by smurf (subscriber, #17840) [Link]
An alternate solution would be to use a programming language whose authors (and users) cared enough about security that they'd implement the thing sometime during the last N years.
A reasonable database layer allows one to switch database backends as needed. It allows me to change the backend driver (a one-line edit), and everything should still work afterwards.
A global replace of s/mysql_/pg_/ is not reasonable.
PHP includes such "reasonable database layer"... Posted Dec 19, 2011 8:17 UTC (Mon) by khim (subscriber, #9252) [Link] A reasonable database layer allows one to switch database backends as needed. It's called PDO and PHP had it for years. It allows me to change the backend driver (a one-line edit), and everything should still work afterwards. It allows you to change the backend driver and this starts long arduous task of fixing the code. Even trivial tasks (like addition of one row) is done differently with different servers. For example in mysql you usually add row using insert and then call PDO::lastInsertId to find the ID, but in Postgresql it does not work and the best alternative is to use INSERT RETURNING foo_id. Or you can use PDO::lastInsertId, but this is slower and requires changes anyway (you must specify name of a sequence object with Postgresql). Sorry, but magic wand does not work with SQL servers: they all are so different that "multiple backends" paradigm works only if you test your program with all of them. Or you can use some kind of ORM library, but this creates it's own problems.
PHP includes such "reasonable database layer"... Posted Dec 19, 2011 11:36 UTC (Mon) by alankila (subscriber, #47141) [Link]
I agree that the requirement that *everything works afterwards* is probably too steep. But having to change a few selects to return the last insert id, or just use currval('foo_id_seq') in a few queries is the sort of price that seems acceptable. Much better, anyway, than using database-specific functions.
PHP includes such "reasonable database layer"... Posted Dec 19, 2011 13:28 UTC (Mon) by nix (subscriber, #2304) [Link]
Well, the example you gave (RETURNING versus ::lastInsertId) looks like the sort of trivial-yet-important thing that any reasonable RDBMS-independent database driver really should abstract over. If it doesn't bother, that says volumes...
Heh Posted Dec 19, 2011 14:28 UTC (Mon) by khim (subscriber, #9252) [Link] Well, the example you gave (RETURNING versus ::lastInsertId) looks like the sort of trivial-yet-important thing that any reasonable RDBMS-independent database driver really should abstract over. s/reasonable/unreasonable/. If it's database driver and not ORM then it's good idea to give you access to raw functions of SQL database. For example ODBC just does not give access to these capabilities so you need to use two SQL requests instead of one. Hardly an improvement. If it doesn't bother, that says volumes... Sure. It spokes volumes about unreasonable expectations.
Duh? Posted Dec 19, 2011 14:46 UTC (Mon) by smurf (subscriber, #17840) [Link]
Returning the last_insert_id is something every reasonable SQL database must do. It therefore makes sense to have a common interface for that, just as you have a common interface for opening a cursor and emitting a SELECT statement -- no matter how cursors are implemented internally or whether the database is a file or a network connection.
I have no problem with getting access to the raw functions. But that kind of implementation detail wants to be abstracted. It's not something a Web programmer should have to think about.
Wrong again... Posted Dec 19, 2011 15:05 UTC (Mon) by khim (subscriber, #9252) [Link] Returning the last_insert_id is something every reasonable SQL database must do. Puhlease. Oracle offers totally different way of doing the same thing. You never pull last_insert_id to your program at all: instead you use currval in the next use insert (update, etc). I have no problem with getting access to the raw functions. But that kind of implementation detail wants to be abstracted. Well, it only makes sense if you don't care about resource usage. Because practially the only way to abstract these kind of things is to create interface which works awfully slow for all supported databases. Perhaps some wizard can invent something which will support all common databases in the same fashion and still will work fast - but on practice I'm yet to see such implementation.
Wrong again... Posted Dec 19, 2011 16:27 UTC (Mon) by nix (subscriber, #2304) [Link]
Your belief that RETURNING doesn't work in Oracle is untrue. It does (though you have to RETURNING a .nextval, indeed), and is the recommended approach rather than using .currval, because it saves a roundtrip to the database.
Writing an abstraction layer which abstracts over all SQL differences is of course over the top... but abstracting over trivial, always-needed stuff like 'what is the sequence number of the row I just inserted' is, well, trivial. I've written such an abstraction layer myself more than once, and that was a little one-man thing, and it was not very much effort. That PHP couldn't do it says volumes.
This is funny... Posted Dec 20, 2011 0:04 UTC (Tue) by khim (subscriber, #9252) [Link] Your belief that RETURNING doesn't work in Oracle is untrue. It does (though you have to RETURNING a .nextval, indeed), and is the recommended approach rather than using .currval, because it saves a roundtrip to the database. Of course RETURNING works, but... how exactly will it save the roundtrip? When you use nextval/currval idiom you can just batch all your operation in one statement using BEGIN/END - thus using one single roudtrip. How exactly last_insert_id emulation can beat this is mystery to me. Sure, sometimes you want to do some manipulations in your application before continuing - and in this case it's natural to use last_insert_id with MySQL (but not with Oracle). Writing an abstraction layer which abstracts over all SQL differences is of course over the top... but abstracting over trivial, always-needed stuff like 'what is the sequence number of the row I just inserted' is, well, trivial. Actually it's not trivial. In MySQL LAST_INSERT_ID only gives you one number but in Postresql or Oracle you can generate few different numbers. And since one roundtrip can include quite a few elemental operations it's not easy or simple to transform one to another. I've written such an abstraction layer myself more than once, and that was a little one-man thing, and it was not very much effort. WOW! Cool. How exactly have you processed Oracle's insert statements which used two distinct sequences in MySQL? That PHP couldn't do it says volumes. About your unreasonable expectations? Sure. About SQL driver? Not much. DBI example which produces suboptimal results does not expire confidence: I'd rather handle such problems at the application level rather then in intense debugging session which will show that that my perfectly tuned code on some other database uses insert over unindexed table "because driver had no other choice". Thnks... but no, thnks.
This is funny... Posted Dec 20, 2011 11:38 UTC (Tue) by nix (subscriber, #2304) [Link]
As for last_insert_id et al, well, every abstraction layer has costs. One cost of this one was that you had to use a not-completely-disgusting data model, i.e., that having more than one sequence tracking a single table was not supported. I never felt the lack: compound PKs are all very well, but if you use a sequence (mysql: autoincrement) as a PK it means that nothing else would do. Why on earth would you want to use a compound PK consisting of multiple sequences? That smacks of very bad table design to me. I thought of various more or less ugly ways to fix this but never implemented them because of a total lack of need.
(It was not a very pleasant abstraction layer to write, I'll grant you that. But, still, abstracting over this sort of thing *is* the job of an abstraction layer.)
Heh Posted Dec 19, 2011 14:54 UTC (Mon) by niner (subscriber, #26151) [Link]
Perl's DBI offers a last_insert_id Method which works with pretty much all database drivers. So while it is available and in practice works, the interface still has to live with the complete lack of standardisation among DBMS. A quote from the DBI man page:
There are several caveats to be aware of with this method if you want to use it for portable applications:
* For some drivers the value may only available immediately after the insert statement has executed (e.g., mysql, Informix).
* For some drivers the $catalog, $schema, $table, and $field parameters are required, for others they are ignored (e.g., mysql).
* Drivers may return an indeterminate value if no insert has been performed yet.
* For some drivers the value may only be available if placeholders have not been used (e.g., Sybase, MS SQL). In this case the value returned
* Some drivers may need driver-specific hints about how to get the value. For example, being told the name of the database 'sequence' object
* If the underlying database offers nothing better, then some drivers may attempt to implement this method by executing ""select max($field)
* If no insert has been performed yet, or the last insert failed, then the value is implementation defined.
Given all the caveats above, it's clear that this method must be used with care.
Yup Posted Dec 19, 2011 16:19 UTC (Mon) by khim (subscriber, #9252) [Link] Given all the caveats above, it's clear that this method must be used with care. It must only be used with MySQL, really. If you want to use Oracle and Postgresql then it's much better to use sequences and their nextval and currval directly (not sure about other databases, but they probably have their own ways to do that). So while it is available and in practice works, the interface still has to live with the complete lack of standardisation among DBMS. Right. This just shows that SQL driver is completely wrong level of abstraction to try to unify different databases. It's [relatively] easy for ORM layer or application-specific layer to deal with these differences. If you try to do that on SQL driver layer you'll waste huge amount of resources and and the end result will sometimes still not usable (If the underlying database offers nothing better, then some drivers may attempt to implement this method by executing ""select max($field) from $table""). NOT a way to go. PHP has many problematic warts, but PDO is not one of them.
Yup Posted Dec 19, 2011 19:35 UTC (Mon) by fatrat (subscriber, #1518) [Link]
Have you seen Python's SQLAlchemy? It provides an ORM layer but also a really good SQL level layer.
Good try... Posted Dec 20, 2011 0:35 UTC (Tue) by khim (subscriber, #9252) [Link] No, I've never used SQL from python so I never used SQLAlchemy. Looks like fine ORM toolkit, though. As for SQL as any good SQL driver it includes dialects. This is where you can specify sequences in Oracle, disable autoincrement in MySQL, etc. Even so: I can not see how exactly you can chain multiple INSERTs in one BEGIN/END Oracle statement or execute multiquery in MySQL (like you can do with PHP).
Yup Posted Dec 20, 2011 7:38 UTC (Tue) by niner (subscriber, #26151) [Link]
"It must only be used with MySQL, really. If you want to use Oracle and Postgresql then it's much better to use sequences and their nextval and currval directly."
Not really. It covers the simple case quite well which is the vast majority in our applications. If I want to use PostgreSQL features, I'd use returning to get the new ID back to the application without an additional roundtrip.
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 22:21 UTC (Mon) by adamg (subscriber, #42260) [Link] A reasonable database layer allows one to switch database backends as needed. It allows me to change the backend driver (a one-line edit), and everything should still work afterwards.That always makes me wonder, what kind of argument is that anyway? Do you really find yourself so often in situations where in the middle of the project you decide to switch database backend? If a project developers write SQL queries that are so portable that it as easy to switch to another database backend as doing the mentioned s/my_/pg_/g (or equivalent), my guess is that they are not using much of the initial database features. .. or maybe there is an easy way (which I don't know) to write stored procedures in a portable way.
This is the most ridiculous commentary... Posted Dec 19, 2011 8:01 UTC (Mon) by khim (subscriber, #9252) [Link] Actually there are plenty of ways to use prepared statements with MySQL. You can use mysqli::prepare/mysqli_stmt::bind_param/mysqli_stmt::execute or PDO::prepare/PDOStatement::bindParam/PDOStatement::execute. People are using "good old" mysql_query because not all ISPs provide mysqli or PDO - but Postgresql is even rarer thus obviously not an option. There is one thing PHP did right: it was ridiculously easy to add mod_php to the Apache server from the very beginning - and overhead was negligible when it was not in use thus a lot of ISPs offered mod_php and very few offered mod_perl or mod_python. This is what made PHP popular and this is what keeps it alive.
This is the most ridiculous commentary... Posted Dec 19, 2011 10:06 UTC (Mon) by drag (subscriber, #31333) [Link]
It helps.
Also it's trivial to make a PHP script by taking some HTML code and putting PHP statements in it.
So it suckers developers in by trivial hello world type demos. More people come from a HTML editing background then a programming background so this sort of thing makes it easier to approach.
This is the most ridiculous commentary... Posted Dec 19, 2011 21:58 UTC (Mon) by job (guest, #670) [Link]
As a side note, I believe what was important about mod_php was safe_mode. It is a rudimentary file i/o sandbox that only allows you to open files with the same UID your script was created with. That enabled shared script hosting, you don't have to use one process per user which was important for the nascent "web hotel" businesses.
Performance was worse than Perl (which was the dominant language at the time, and had decent template frameworks too), security was worse, the language itself was a stripped down Perl 4, but deployment was so easy you just had to install it and you had yourself a shared web hosting environment.
I see now that safe_mode is removed from PHP 5.4 so perhaps we're full circle now. I wonder what shared hosts are supposed to replace it with?
This is the most ridiculous commentary... Posted Dec 20, 2011 10:17 UTC (Tue) by smurf (subscriber, #17840) [Link]
FastCGI and separate PHP processes per user, of course.
It doesn't make any sense at all to bloat your Apache with mod_php. If you have 200 Apache processes, of which 10 are needed for PHP, the (non-trivial, these days) memory space of 190 PHP interpreters sits idle. It can't even be swapped out because the set of Apache processes working on PHP requests constantly changes.
Using FastCGI, you have 10 busy PHP interpreters and 190 "normal" Apache (or lighttp or
) processors, and you get to run each customer's PHP stuff under their own UID instead of having global access to anything that's readable by www_data when (not if) the next security hole is discovered.
This is the most ridiculous commentary... Posted Dec 20, 2011 11:09 UTC (Tue) by job (guest, #670) [Link]
For large web apps this is (and has always been) true. But the issue here is altogether different.
A large shared webhost has many thousands of web sites and only a few of them are active at any time. It is unreasonable to keep thousands of idle PHP processes around (and that is without room for concorrency which would be required in production).
That is what the web hotel business is all about, very cheap hosting, and this is what made PHP popular.
This is the most ridiculous commentary... Posted Dec 20, 2011 12:23 UTC (Tue) by smurf (subscriber, #17840) [Link] Sure it's unreasonable to keep them around. So let them die when they're no longer useful.Large sites increase the likelihood that somebody, somewhere on your system, is running code with a security hole or two. So it's even more important to shield individual customers from each other. Your decision, of course. But the web servers I am responsible for will never load mod_interpreter, much less mod_php.
This is the most ridiculous commentary... Posted Dec 20, 2011 16:14 UTC (Tue) by job (guest, #670) [Link]
When the number of idle sites are order of magnitudes larger than the number of active sites at any given moment that solution is equivalent to running PHP as CGI. That would price you out of the market. (And spare me the morals please, as much as I'd like to see mod_php dead it is still an important market which drove PHP's success.)
PHP won because of mod_php, but mod_php won the low end market because of safe_mode. My question still stands, what should replace it? Maybe SELinux can?
This is the most ridiculous commentary... Posted Dec 21, 2011 12:02 UTC (Wed) by andresfreund (subscriber, #69562) [Link]
> When the number of idle sites are order of magnitudes larger than the number of active sites at any given moment that solution is equivalent to running PHP as CGI. That would price you out of the market. (And spare me the morals please, as much as I'd like to see mod_php dead it is still an important market which drove PHP's success.)
Right, because idle sites cause that much load that cgi is actually a problem... Its the website that actually use their allotted bandwith/load/whatever that are a problem not the thousand with 3 visitors a day.
This is the most ridiculous commentary... Posted Dec 22, 2011 0:22 UTC (Thu) by job (guest, #670) [Link]
On a large shared web host, a very small percentage of the sites are have traffic at any given time, but it's still a lot in absolute numbers.
The only possible way to cram as many sites as possible on your host is to run them with a common interpreter, which can pose security problems. That's where mod_php succeeded.
(By the way, I got the answer to my specific question below, which is that other restrictions still apply.)
This is the most ridiculous commentary... Posted Dec 20, 2011 22:58 UTC (Tue) by hholzgra (subscriber, #11737) [Link]
Being able to define memory and cpu time limits, and maybe open-basedir restrictions, were (AFAIR) more important to shared hosters than safe-mode (which was never that safe anyway), and all of these still exist.
This is the most ridiculous commentary... Posted Dec 21, 2011 8:48 UTC (Wed) by job (guest, #670) [Link]
That explains it. I thought basedir restrictions was part of safe_mode.
Cracks in the Foundation (PHP Advent) Posted Dec 20, 2011 23:02 UTC (Tue) by hholzgra (subscriber, #11737) [Link]
The old ext/mysql extension did indeed not support prepared statements (just as the MySQL client protocol did not support them either at the time when ext/mysql created)
The newer ext/mysqli extension fixed that around 2003 already when prepared statement support became in MySQL, but somehow lots of people prefer to stay with the "classic" extensions API ...
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 19:48 UTC (Sun) by imgx64 (guest, #78590) [Link]
I tried to write a comment, but no matter how much I tried to rephrase it, I keep sounding like a troll. I think PHP defies my ability to not rant. It's just not possible to talk about it without starting a flame war.
I guess I'll just disable the rant then.
<?php if("0" == false){ ?>
The supposed advantage of PHP is "ease of use for beginners". They can write PHP code right between HTML! It also never complains, it just does something magical that "makes sense"! How easy!
The irony is that no high-quality project (if that's even possible) actually embeds HTML. They wrap the whole page with '<?php' and '?>' and use a fancy framework to output the HTML. Also, no one ever uses ==; === is used everywhere instead.
And the worse part, by never complaining on clearly stupid code, they spoil the beginner programmers, who need to be told about their mistakes the most. This is probably why PHP has its bad reputation.
<?php } ?>
Anyway, my point is that someone needs to kill that monstrosity already. Trying to "fix" it is just pointless, for exactly the same reasons mentioned in the article. People should abandon it for other languages, even if it takes more than a decade.
I haven't had to look at PHP code for over a year now. I just realized how much happier I am because of it.
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 21:05 UTC (Sun) by Kit (guest, #55925) [Link]
It seems to me that all the web scripting languages are pretty horrible in some (or several) regard. PHP, somehow, has managed to survive (and thrive!), despite making pretty much every single 'easy way' to do things a security nightmare.
Are there really any out there that can ACTUALLY scale up well to a huge number of concurrent users without having to spend a massive amount of time planning? (or writing your own VM!) I've not really kept up to date on the latest developments, but node.js seemed like it was promising to make it easier to make scalable websites without intense planning and design (at least from the language side- data storage scaling is still left to the user/library/DB devs).
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 21:54 UTC (Sun) by Richard_J_Neill (subscriber, #23093) [Link]
Actually, being able to quickly swap from PHP to HTML (especially using short-tags <? ... ?> ) can be useful. One way to create, imho, legible code is to do all the processing first, and then write out the bulk of the HTML, inserting <?=$variable;?> as needed. Like any language feature, this can be abused.
Also, the distinction between == and === is a really useful one. Again, it requires proper understanding, but it can save a lot of time. Consider strpos() which normally returns an integer (perhaps zero), but false on error. This is compact, clear, and avoids the problem of error-handling in C's atoi() or the horrible workaround in strtol().
The key advantage of PHP is the documentation, which is excellent.
BTW, ironically, you *didn't* disable your rant. String "0" IS equal (==) to false, though it isn't identically equal (===). If you wanted to complain, you'd have to complain that "0.0" is considered true; "0.0" is considered equal to 0.0, and that 0.0 is considered false. Sadly there is no perfect way to write automatic-casting rules.
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 22:05 UTC (Sun) by alankila (subscriber, #47141) [Link]
So you are saying that 0 == strpos($x, $y) will do the wrong thing when the string is not found at beginning. Other languages show remarkably more sense by returning -1 or something. Sorry, but this specific example you picked is full of fail.
Cracks in the Foundation (PHP Advent) Posted Dec 21, 2011 2:37 UTC (Wed) by Richard_J_Neill (subscriber, #23093) [Link]
Perhaps using strpos() wasn't quite such a good example, because -1 could never be a valid answer, and is therefore potentially OK as an error-flag.
This is in the same spirit as, for example, C's write() .
BUT, what do you do with an integer-function that normally returns an integer (negative, positive, or zero) when it needs to return an error?
There are several ways to do it; of which I think that C's strtol() is the worst possible. Some might suggest returning an object, but that's logically equivalent. PHP has adopted the general convention that any function that fails will return false; I think this is actually quite sensible once one knows to expect it.
As for the casting rules of "0.0" vs 0.0, it's rather a perverse example, which shouldn't happen in real-life.
Cracks in the Foundation (PHP Advent) Posted Dec 21, 2011 4:26 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
> BUT, what do you do with an integer-function that normally returns an integer (negative, positive, or zero) when it needs to return an error?
Return success or failure (or a more specific error code), and store the result in a reference parameter? That's the standard C approach. If the possibility of failure exists, you'll need to check for that first anyway before using the result. For uncommon failure modes, in languages which support it, alternate continuations (including, but not limited to, C++-style exception handling) offer a more efficient solution.
> PHP has adopted the general convention that any function that fails will return false; I think this is actually quite sensible once one knows to expect it.
That's great so long as you don't need to return false in a non-failure situation... The Common Lisp solution to this is rather elegant: return two values, the first being the result or false, and the second (which you can ignore) indicating success or failure. If you know that successful results can't be false you can use the normal return value, but the extended status is there if you need it.
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 22:49 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> Consider strpos() which normally returns an integer (perhaps zero), but false on error.
That is the kind of idiotic type mess that dynamic typing encourages. Just say no to that kind of crap.
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 3:52 UTC (Mon) by imgx64 (guest, #78590) [Link]
I'd attribute this to the lack of proper exceptions and/or multiple return values than dynamic typing. For example, the C standard library is terrible when it comes to returning errors, and it's statically-typed.
Of course it can be improved (assuming PHP has proper exceptions), but it requires a change in the culture of PHP programmers. Something I highly doubt is possible.
Cracks in the Foundation (PHP Advent) Posted Dec 22, 2011 11:20 UTC (Thu) by justincormack (subscriber, #70439) [Link]
Multiple return values is the real answer here. Exceptions are probably overkill. Dont suppose php will get them though.
Cracks in the Foundation (PHP Advent) Posted Dec 22, 2011 11:59 UTC (Thu) by etienne (subscriber, #25256) [Link]
> Multiple return values
Sometimes, in C, I would like a function to return a value (like now) *and* the (processor) flags - for instance the "zero" flag would mean no error occured. Very fast and simple...
Cracks in the Foundation (PHP Advent) Posted Dec 23, 2011 10:09 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> Sometimes, in C, I would like a function to return a value (like now) *and* the (processor) flags - for instance the "zero" flag would mean no error occured. Very fast and simple...
You mean like the errno variable?
Cracks in the Foundation (PHP Advent) Posted Jan 3, 2012 12:41 UTC (Tue) by etienne (subscriber, #25256) [Link]
>> returning flags from functions
> You mean like the errno variable?
Not really, errno is a global variable - I was thinking of something very fast at the asssembly level, for the million of use case.
unsigned mybitfield, bitindex;
Translated in ia32 assembler by:
You can replace ffs by strchr or any basic function which may not be inlined.
Why is it a mess? Posted Dec 19, 2011 7:06 UTC (Mon) by khim (subscriber, #9252) [Link] Actually this is time-honored way of doing things (think SQL and nullable types in C#). Of course in a language where the most natural operator will happily declare 0 identical to false it's a disaster, but in LISP-derived languages (where eq?, eqv?, and equal? - all agree that 0 and #f are different and if treats both 0 and 1 and kind-of-true) it works just fine. In languages like perl, php and python (which try to "guess" what you meant and "help" you) it's disaster, obviously.
Why is it a mess? Posted Dec 19, 2011 10:11 UTC (Mon) by HelloWorld (guest, #56129) [Link]
I don't see the point in allowing anything that isn't either true or false in an if statement/expression.
I happen to like the way the STL solved this problem in std::find. If an element is found, return an iterator to it. If it's not found, return a past-the-end iterator. In Haskell, one would typically return a 'Maybe' value, which is either "Nothing" or "Just x", where x is the number you're looking for. One then uses pattern matching to distinguish the cases.
Hmm... Posted Dec 19, 2011 10:32 UTC (Mon) by khim (subscriber, #9252) [Link] I don't see the point in allowing anything that isn't either true or false in an if statement/expression. The point is expressiveness, as usual. You can do anything you want without such things (see Turing tarpit), but this kind of misses the point. I happen to like the way the STL solved this problem in std::find. If an element is found, return an iterator to it. If it's not found, return a past-the-end iterator. This is good kludge for the statically typed language with a lot of limitations. They could not use just plain NULL because they wanted to make sure iterators may be anything, so they invented this scheme. Still not sure why you think it's better then simple "iterator or #f": in C++ case you often need to process iterator somehow (if caller which needs the iterator does not want to know about your map), in case of LISP you can just return result as is. In Haskell, one would typically return a 'Maybe' value, which is either "Nothing" or "Just x", where x is the number you're looking for. One then uses pattern matching to distinguish the cases. And all thus additional unneeded manipulations are good exactly why? I dislike languages without static typing because they leave too much to the runtime, but then if we are already in realm of dynamic languages it's stupid not to use the fact that you can return objects of different types to your advantage: why do you use language with dynamic typing or duck typing if you only use things available in statically typed language???
Hmm... Posted Dec 19, 2011 12:15 UTC (Mon) by alankila (subscriber, #47141) [Link]
In general it's acceptable to return different types, I guess, as long as it is driven by some kind of compelling necessity or resulting convenience. This FALSE is just not convenient because of the confusion with 0; I think it just shows remarkably poor taste. When designing an API, the designer should take full responsibility about the anguish the API's hapless user must endure.
Hmm... Posted Dec 19, 2011 12:45 UTC (Mon) by HelloWorld (guest, #56129) [Link] The point is expressiveness, as usual.[...] And all thus additional unneeded manipulations are good exactly why?I don't see any gain in expressiveness here, nor do I see any "unneeded manipulations". PHP: $z = strpos($x, $y); if ($z === false) do_something(); else do_something_else($z);C++: auto z = boost::search(x, y); if (it == x.end()) do_something(); else do_something_else(z); I dislike languages without static typing because they leave too much to the runtime, but then if we are already in realm of dynamic languages it's stupid not to use the fact that you can return objects of different types to your advantage: why do you use language with dynamic typing or duck typing if you only use things available in statically typed language???Well, you're raising a good point, and the answer is that one just shouldn't use a dynamically typed language for anything but throw-away stuff. Doing stuff like returning either an int or a boolean spoils the way people think. They start to think that in order to obtain a convenient solution to this problem they need dynamic typing, even though that isn't so.
Hmm... Posted Dec 19, 2011 12:49 UTC (Mon) by HelloWorld (guest, #56129) [Link] Oh by the way, that reminds me of an old quote by Dijkstra:It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.Needless to say, the same applies to PHP.
Hmm... Posted Dec 19, 2011 13:00 UTC (Mon) by mpr22 (subscriber, #60784) [Link] I'm inclined to think that that particular Dijkstra quote probably says at least as much about Dijkstra's ability to teach as it does about BASIC.
Hmm... Posted Dec 19, 2011 13:27 UTC (Mon) by nix (subscriber, #2304) [Link]
I think it has more to say about what Dijkstra wanted to teach. Once you've been exposed to a language that just lets you get simple stuff done without much effort, the preferred Dijkstra way of formally proving as much as possible starts to seem incredibly long-winded, even if in theory it does eventually produce better results. (It is, of course, a good idea in some domains -- just not everywhere, as Dijkstra sometimes seems to have wished.)
For very large programs, particularly in safety-critical domains, formal proof, particularly of core components, starts to seem reasonable -- but when you're teaching you're going to be using small examples, because you have to. And those small examples are typically too small to need formal methods of any kind. Expose someone to BASIC, or another similar language which is good for quickly whipping up something small that works but that falls apart on larger scales, and they are likely to think 'why bother with formal methods?' when exposed to little teaching examples of their use, for which, to be blunt, any random language would often suffice with no use of formal methods at all.
Why is it a mess? Posted Dec 19, 2011 13:18 UTC (Mon) by ekj (guest, #1524) [Link]
If the language is object-oriented and allows objects to override operators, it makes sense to also let them answer the question of being true or false.
This is essentially what happens in python: An empty string is considered false while all other strings are considered true. That's just sugar offcourse, you could do if mystring.length() > 0 instead of if mystring and get the same result, but it's a useful shortcut.
Considering integers different from zero to be true, and zero to be false is also very common although the same tradeoff applies if myint could always be rewritten to if myint <> 0 which does have the advantage of being more explicit.
automagick type-conversion like PHP have is nuts though, they consider "0" to be false because the integer 0 is false. (but "0.0" is not false, despite the fact that 0.0 *is* false.
Why is it a mess? Posted Dec 25, 2011 14:09 UTC (Sun) by juliank (subscriber, #45896) [Link]
> myint <> 0
Use myint != 0. That other form is deprecated in Python 2, and removed in Python 3.
Why is it a mess? Posted Dec 20, 2011 23:32 UTC (Tue) by pboddie (subscriber, #50784) [Link] In languages like perl, php and python (which try to "guess" what you meant and "help" you) it's disaster, obviously. Python doesn't "guess" anything. There's a protocol that all classes support which indicates whether an instance is considered true or false.
Why is it a mess? Posted Dec 21, 2011 7:37 UTC (Wed) by ekj (guest, #1524) [Link]
Yeah. But even python considers boolean false and integer zero to be equivalent, and all other integers to be true. Indeed the method to override to define your own behaviour for if object is object.__nonzero__ or object.__len__
From the naming alone it's clear that being "true" by convention means "having length" or "not being zero". (why is the method __nonzero__ and not __zero__ (with opposite semantics) by the way, seems an odd kind of superfluous negation. Returning false hear means that the object is *not* *nonzero* i.e. that it's zero.
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 3:30 UTC (Mon) by imgx64 (guest, #78590) [Link]
> Actually, being able to quickly swap from PHP to HTML (especially using short-tags <? ... ?> ) can be useful. One way to create, imho, legible code is to do all the processing first, and then write out the bulk of the HTML, inserting <?=$variable;?> as needed. Like any language feature, this can be abused.
Yes, this is called a template engine. Every other web language has one, and it's by no means PHP specific. Even statically-typed languages like Java and Go have template engines (Go even has two in the standard library, although the older one will be deleted before Go1 is released).
On the other hand, making the whole language a template engine is just wrong IMO.
> BTW, ironically, you *didn't* disable your rant. String "0" IS equal (==) to false, though it isn't identically equal (===).
Yes, that was the intention.
> If you wanted to complain, you'd have to complain that "0.0" is considered true; "0.0" is considered equal to 0.0, and that 0.0 is considered false. Sadly there is no perfect way to write automatic-casting rules.
Wow. PHP is even worse than I remember.
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 13:21 UTC (Mon) by nix (subscriber, #2304) [Link] If you wanted to complain, you'd have to complain that "0.0" is considered true; "0.0" is considered equal to 0.0, and that 0.0 is considered false.Who the hell thought that was sane? It makes C++'s loop-avoidance rules on user-defined implicit casting ('no more than one') look sensible. I know, I know, nobody thought it was sane -- the string-equals-number rule was added because it might be useful without considering its effect on the semantics of the language. "Pile in useful features without much global consideration" works for a lot of software. It really really does not work for languages. Does PHP have nothing like the PEP process, where the badly-thought-out ideas can quietly die?
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 22:19 UTC (Sun) by kragilkragil2 (guest, #76172) [Link]
That may be true, but the biggest website there is somehow proves you wrong.
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 22:44 UTC (Sun) by HelloWorld (guest, #56129) [Link]
No it doesn't. People have been writing working applications in spite of PHP, not because of it.
Love-Hate Relationship Posted Dec 18, 2011 23:32 UTC (Sun) by dskoll (subscriber, #1630) [Link] The web interface to our product is written in PHP, so I work with it every day. I really hate PHP. I agree with the parent's statement People have been writing working applications in spite of PHP, not because of it. On the other hand, PHP is really easy to deploy (everybody packages mod_php) and the documentation is pretty good providing you ignore all the dumb advice from programmer-wannabees in the comments on the PHP manual.
Cracks in the Foundation (PHP Advent) Posted Dec 18, 2011 23:33 UTC (Sun) by xxiao (subscriber, #9631) [Link]
using drupal for years which is php-based, it appears to be a fine project.
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 2:00 UTC (Mon) by dskoll (subscriber, #1630) [Link] I love Drupal; it's terrific. But I think it's the epitome of in spite of PHP.
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 8:55 UTC (Mon) by kragilkragil2 (guest, #76172) [Link]
I have no idea what you are talking about, I didn't respond to you.
I responded to imgx64 and he/she claimed that you cannot build big websites in PHP. Facebook proves him wrong. And it might be in spite of PHP, but the fact remains that you can build just about anything in it.
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 9:57 UTC (Mon) by HelloWorld (guest, #56129) [Link]
> I responded to imgx64 and he/she claimed that you cannot build big websites in PHP.
No he didn't. He said that PHP is unsuitable for building big websites. That doesn't mean it's impossible. And I actually wonder why I have to explain this to you.
turing complete Posted Dec 19, 2011 13:15 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Indeed.
It plainly couldn't be /impossible/ because PHP is Turing Complete. Worst case you write some horrible software to translate from a real language to PHP, and indeed various outfits have done this over the years precisely because (as noticed elsewhere in this discussion) PHP is horrible but it's installed on practically every tupenny-hapenny web host, so offering a version of your software "for PHP" is as key to making small web customers happy as writing i386 compatible Windows software is if you want lots of SOHO customers.
turing complete Posted Dec 19, 2011 13:25 UTC (Mon) by HelloWorld (guest, #56129) [Link] It plainly couldn't be /impossible/ because PHP is Turing Complete.That's nonsense, you're one of the many people who talk about Turing Completeness, yet have no idea what it actually means. Turing Completeness means that you can compute the value of every computable function, it does *not* mean you can "do anything" with it. The untyped lambda calculus is Turing Complete, and yet you can't write web sites with it as it doesn't provide any I/O facilities.
turing complete Posted Dec 19, 2011 14:28 UTC (Mon) by ekj (guest, #1524) [Link]
That's true, but PHP *does* contain all the primitives needed to implement any other language.
It'd be totally possible (though not nessecarily sane) to implement Python, Java or Ruby in PHP. (or any other langauge you happen to like)
Being able to compute any expression, as any Turing-complete language can, is a pretty big part of that, the missing piece is, as you say, IO as in which mechanisms are available for communicating with the outside world.
turing complete Posted Dec 19, 2011 14:45 UTC (Mon) by HelloWorld (guest, #56129) [Link]
Well, it's all nitpicking by now. The point is that PHP is unsuitable for writing large-scale web applications despite the fact that people have done it anyway.
turing complete Posted Dec 19, 2011 17:10 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
It's not nonsense, of course you can write web sites with the untyped lambda calculus.
The input to your web-site function is a number representing an HTTP request and a magic cookie value, and the result of the function is a number representing the new magic cookie value and the HTTP result. See?
Now, you'd be right that you can implement the lambda calculus on a machine with spinning cogs that spits out the answer as a stream of jelly beans, and this would not, in and of itself, make your web site accessible to the Internet, but the same is true of PHP running on some toy machine that lacks a TCP stack, Ethernet drivers, etc.
turing complete Posted Dec 19, 2011 20:14 UTC (Mon) by HelloWorld (guest, #56129) [Link] It's not nonsense, of course you can write web sites with the untyped lambda calculus.No you can't. The input to your web-site function is a number representing an HTTP request and a magic cookie value, and the result of the function is a number representing the new magic cookie value and the HTTP result. See?Yes, I indeed see you didn't get the point. In PHP, the APIs for accessing the HTTP request data and for setting HTTP response headers and sending data are part of the language; in the untyped lambda calculus, they aren't. Of course, you can alter the language specification of the untyped lambda calculus to include side effects by specifying that your program will be passed an HTTP request and its output will be sent to the client. But if you alter the language that way, it's not the untyped lambda calculus any longer.
turing complete Posted Dec 19, 2011 20:49 UTC (Mon) by nybble41 (subscriber, #55106) [Link]
> In PHP, the APIs for accessing the HTTP request data and for setting HTTP response headers and sending data are part of the language; in the untyped lambda calculus, they aren't.
That's just a matter of standard libraries, which can exist in the untyped lambda calculus just as easily as in PHP. These APIs are a convenience, nothing more.
> Of course, you can alter the language specification of the untyped lambda calculus to include side effects by specifying that your program will be passed an HTTP request and its output will be sent to the client. But if you alter the language that way, it's not the untyped lambda calculus any longer.
Neither the PHP language nor the lambda calculus define the semantics of the input and output, which depend on the lower software layers and hardware and are outside the scope of language specifications. Applying an additional semantic layer where none existed before is an extension to the specification, not an alteration to the language. There is no such thing as a meaningful program in either the lambda calculus or more common languages like PHP *without* exactly this sort of semantic extension, which is always defined by the implementation, not the abstract language.
Note that PHP programs can exist which have nothing to do with HTTP; witness the php-cli command-line environment. The HTTP CGI I/O semantics are one way to interact with PHP programs, but not the only way.
turing complete Posted Dec 19, 2011 20:56 UTC (Mon) by HelloWorld (guest, #56129) [Link]
Sorry, this this pointless, you're clearly confused. Find someplace else to troll.
turing complete Posted Dec 19, 2011 23:37 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Accusing people of "trolling" when they explain why you're wrong is poor form.
The general idea you had was fine, there are indeed applications which necessarily involve side effects and the lambda calculus doesn't have side effects. But answering individual HTTP requests (remember PHP isn't a web server, it doesn't need to care about the details of how those requests are made, where they come from, or how answers are returned) isn't really one of those applications. Thus the lack of side effects isn't a deal breaker, and my explanation deliberately didn't use them.
All you need are some conventions. The same sort of conventions you'd need if you wanted to write pow() in the lambda calculus, or isalpha().
It's also fine that you didn't understand that, and needed to have it spelled out. The problem arises when you discover, oops, that you were wrong and rather than say "Ah, I see, that's not what I thought was going on" you insist that you're being trolled.
turing complete Posted Dec 20, 2011 0:57 UTC (Tue) by HelloWorld (guest, #56129) [Link] Accusing people of "trolling" when they explain why you're wrong is poor form.I'm not. The general idea you had was fine, there are indeed applications which necessarily involve side effects and the lambda calculus doesn't have side effects. But answering individual HTTP requests (remember PHP isn't a web server, it doesn't need to care about the details of how those requests are made, where they come from, or how answers are returned) isn't really one of those applications. Thus the lack of side effects isn't a deal breaker, and my explanation deliberately didn't use them.Yeah, except that it *is* a deal breaker because you need a lot more than just the contents of the HTTP request in order to do anything meaningful (i. e. something that couldn't be done just as well with JavaScript on the client side). You know, things like access the database or communicate with other hosts. OK, you can get the database thing to work by passing the entire contents of the database to your lambda expression and have it return a tuple containing the response and the complete new database contents. Not only may one consider that "cheating" (as you need a more and more elaborate machinery outside of the lambda calculus expression, to the point that you can't actually claim to have done anything meaningful in said expression any longer), but that approach also quickly leads to a dead end where you'd need to pass the state of the whole world to the lambda expression in order to obtain the desired answer. And actually, even that wouldn't suffice. Imagine a web server with a hardware random number generator and a web application that allows you to query the xth number generated from now on (where x is supplied by the client). Due to Heisenberg's uncertainty principle, you can't possibly measure the state of the RNG well enough to predict what the xth generated number will be, so you clearly need some kind of side effect for that kind of application. The reason I didn't write all this stuff earlier is that I just couldn't be bothered to argue with a troll like nybble41. There's simply no value at all in this discussion, and nothing enlightening is going to come out of it (not for me, anyway). The only reason I engaged in it at all is that I don't like being told I'm wrong when I'm not.
turing complete Posted Dec 20, 2011 4:23 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
So your main complaint now is that the untyped lambda calculus can't pretend to be a hardware random number generator? Are you even paying attention to the discussion? Hardware random number generators aren't a PHP feature. The question wasn't "can a lambda expression correctly simulate the hardware of an entire web server?".
Your objection to state cookies is spurious. The state cookie is opaque outside of the lambda expression, all the hard work happens _inside_ the lambda expression. If the state held between requests is small and client-specific you can sidestep this altogether by asking the user agent to hold on to it for you, in your HTTP response. In fact you may recall that recently Microsoft ASP.NET was found to have introduced a serious security vulnerability by transmitting inadequately encrypted session state in user-accessible HTTP cookies.
It's certainly not fair to pretend that most, or even many web sites depend somehow upon the "state of the whole world". Usually there's a modest database, and perhaps some files stored on disk. A pure functional system could easily wrap all that material into the state cookie. Many sites _appear_ to integrate content from several other systems, but actually that's usually done client side in the user agent these days, the "integration" from the point of view of PHP or our hypothetical lambda expression is just a few lines of unchanging plain text returned in the HTTP response.
There are numerous _practical_ problems which keep web sites from being built out of say, pure Lisp, but theoretically there's no real obstacle.
turing complete Posted Dec 20, 2011 9:50 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> So your main complaint now is that the untyped lambda calculus can't pretend to be a hardware random number generator?
No, it's not. But your response shows yet again that this discussion is utterly pointless. You don't want to get the point, fine with me. Have a nice life.
turing complete Posted Dec 20, 2011 10:39 UTC (Tue) by smurf (subscriber, #17840) [Link]
Please engage brain.
A PHP without external state is as powerful as a pure Lambda calculus. That's a fact.
PHP has features to talk to the external worls, save state, and whatnot, because it's designed to be (mostly) useful. A pure lambda calculus has not, because it's designed to prove computability theorems and related stuff.
From a mathematical PoV, that's rather superficial. You can write a Web server in COBOL or Intercal or even Brainfuck if you add the required features somehow, and you can write a Prolog theorem prover in them too.
Doesn't mean that doing any of this makes any practical sense whatsoever.
turing complete Posted Dec 22, 2011 3:18 UTC (Thu) by bronson (subscriber, #4806) [Link]
If you're going to concede, why not concede gracefully?
turing complete Posted Dec 22, 2011 5:32 UTC (Thu) by raven667 (subscriber, #5198) [Link]
Where's the fun in that? Go out guns blazing.
turing complete Posted Dec 20, 2011 14:16 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Heh. Check Ur ( http://www.impredicative.com/ur/ ) one day. It works by treating HTML as a state.
turing complete Posted Dec 20, 2011 14:22 UTC (Tue) by HelloWorld (guest, #56129) [Link]
I had actually considered to learn that language, as it seems to be pretty much the only language with first-class cases. I'm pretty busy with other things right now though.
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 14:09 UTC (Mon) by anselm (subscriber, #2796) [Link] It is also worth mentioning that Facebook isn't using stock PHP. They may be writing their stuff in PHP syntax but what is executed on their servers is emphatically not PHP code.
Cracks in the Foundation (PHP Advent) Posted Dec 20, 2011 1:26 UTC (Tue) by andreasb (subscriber, #80258) [Link]
Specifically, they used to compile PHP to C++ then to native binaries. Now they are deploying a PHP to virtual machine code compiler with a JIT compiling virtual machine.
https://www.facebook.com/note.php?note_id=101504151779289...
Cracks in the Foundation (PHP Advent) Posted Dec 20, 2011 12:55 UTC (Tue) by sorpigal (subscriber, #36106) [Link] Am I the only one who thinks this is crazy? At what point do you get so much NIHitis that you think you should be writing your own compilers and VMs for a crappy web language instead of switching to a non-crappy one? The first time it was done could be seen as an emergency measure to help along legact code, but at that point shouldn't your lesson be learned and shouldn't you be trying to find the useful replacement for PHP and not just bandaiding it again and again?
Cracks in the Foundation (PHP Advent) Posted Dec 20, 2011 15:32 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> At what point do you get so much NIHitis that you think you should be writing your own compilers and VMs for a crappy web language instead of switching to a non-crappy one?
Well, if it's easier/cheaper to write a better implementation of the language than to switch the language, it's clearly the right thing to do, isn't it?
Cracks in the Foundation (PHP Advent) Posted Dec 21, 2011 13:59 UTC (Wed) by andreasb (subscriber, #80258) [Link]
[wildspeculation]Maybe Facebook found that they get off cheaper by investing in a handful of people who know how to write compilers and virtual machines so that they can continue to let dime-a-dozen PHP coders do the bulk of the frontend work.[/wildspeculation]
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 9:48 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]
Is facebook now the biggest site? Wow.
It not only survives in the face of PHP, but also in the face of just getting crappier and crappier....
Seriously, I know it sounds trollish, but I have yet to meet one user that likes how the facebook ui has changed over the past year or so....
A lot of people I know have pretty much just given up trying to figure out the randomly changing interface, and put their accounts on life support... although they still get more heartbeats than google+...
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 9:56 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]
Oh noes, I just realised I screwed up.. you must have been talking about how that unstoppable force that will stand the test of time - friendster - solved all its performance issues with PHP.. there's no way that it would crumble, and let some other bundle of PHP crappiness take it's overly-hyped, bored self-important, SF VC wank-inspiring, social-networking crown. ;)
(yeah, it's bash on social networking day for me..)
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 2:09 UTC (Mon) by cortana (subscriber, #24596) [Link]
Hey, it could be worse. Imagine if people tried to use JavaScript to implement web applications! Oh wait...
Cracks in the Foundation (PHP Advent) Posted Dec 19, 2011 11:52 UTC (Mon) by valyala (guest, #41196) [Link]
Server-side javascript is the future of the web thanks to fast js engines like V8 :)
|
|||||||||||||