# "Pushing PHP Into The Web 2.0 Generation" - Thread: https://externals.io/message/22826 - Original archive: https://news-web.php.net/php.internals/22826 - Started by James Crane on 2006-04-18T10:25:55+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #22826 — James Crane — 2006-04-18T10:25:55+00:00 URL: https://externals.io/message/22826#22826 I've written a short paper on the future of PHP and I'd appreciate it if you folks would take a look at it and exchange your thoughts with me. http://www.maraby.com/papers/pushing_php_into_the_web_20_generation Don't be too skeptical. ;) Cheers! M.T. --- ## #22828 — Gareth Ardron — 2006-04-18T10:53:29+00:00 URL: https://externals.io/message/22826#22828 · In reply to: #22826 James Crane wrote: > I've written a short paper on the future of PHP and I'd appreciate it > if you folks would take a look at it and exchange your thoughts with > me. > > http://www.maraby.com/papers/pushing_php_into_the_web_20_generation > > Don't be too skeptical. ;) > Not being funny, but the one thing you seem to suggest is "everything as objects within php" - Quite aside from totally disagreeing with your logic in this, I don't see the point. One of the strengths of php is that it can be used both as a procedural and OO language (or anywhere inbetween) - what you're arguing for can all be accomplished within userspace. I really dont' get what you're trying to achieve with this - maybe I've just totally missed the point, but just saying that PHP is blind to inherent dangers without saying either why they are dangers or in what way php is blind to them doesn't do anything to convince me that this is anything more than your personal preference on how you would like to see the language working. "web2.0" or whatever is afterall, bloody hard to impliment in a real-world situation when dealing with corporate clients. Fine for home users but it's all high-level client side stuff like javascript doing the real interface stuff. Given that loads of corporations outright ban javascript, this causes quite a problem. I don't see why php needs to do anything on this front really, it's a userspace issue. --- ## #22830 — Marco — 2006-04-18T12:20:47+00:00 URL: https://externals.io/message/22826#22830 · In reply to: #22826 > I've written a short paper on the future of PHP and I'd appreciate it > if you folks would take a look at it and exchange your thoughts with > me. I agree with Gareth, the premise that everything as objects and web 2.0 is the future is a little short sighted IMO and possibly a little blinded by the hype surrounding Web 2.0. Regards Mark --- ## #22831 — Evan Priestley — 2006-04-18T12:36:07+00:00 URL: https://externals.io/message/22826#22831 · In reply to: #22826 I'm not sure if this whole thing is supposed to be tongue-in-cheek or not, but "making the language more human" seems, to me, to be a fairly weak argument for making numeric and string literals like `5' and `"smile"' into objects, adding closures, and altering array syntax. The given examples seem particularly unconvincing -- how does `5->times()' differ from `5'? Does Socket.new "know" that port 80 is HTTP, and implement a full server for the protocol? How do you set blocking or timeouts on the socket, or respond with anything but a static string, or describe whether or not the connection is closed afterward? What about when you need a new protocol? It's easy to transform trivial concepts like this port 80 responder into English (or something near to it), but English is poorly suited for describing the solutions to many programming problems. To give an example, RFC822 is 47 pages[1] long, and a good portion of it deals just with what an e-mail address looks like. In fact, the document opts /not/ to use English to specify its information, but to reference /another/ document which uses English to define BNF[2], a grammar notation. RFC822 then uses a mixture of BNF and English to describe the format of an e-mail address. English is quite poorly suited to many of the problem domains commonly encountered in software development. Languages like PHP (and, particularly, regular expressions) are terse because they need to be -- English will never be able to differentiate between valid and invalid e-mail addresses in much less than 47 pages. And describing, say, the matrix algebra behind a 3D graphics engine in English would be a daunting task. I also disagree that `do { smile() } ( 5->times() );' (or whatever you're suggesting) is more "human" than `for( $ii = 0; $ii < 5; $ii+ + ) { smile(); }'. It may be more immediately understandable to an untrained English speaker, but PHP developers aren't untrained English speakers -- they have invested time in learning a language which is more terse, powerful, and capable than English in a specific set of problem domains (that is, PHP is probably better for serving web pages, while English is probably better for talking about your feelings or writing poetry or ordering a beer). To a PHP developer, a for loop is a familiar idiom, even if its meaning isn't obvious to an English speaker. The onus to "push PHP into the web 2.0 generation" is on the PHP application developer, not the PHP language developer. As an example, take 30boxes.com, an Ajax Calendar written in PHP. You can type "eat pie every thursday until june 22" into the box and it will schedule the event properly. In my mind, this is very user-friendly and "human", but it's at the interface level, not at the implementation level. In my mind, PHP *language* developers should focus on making PHP the best language it can be for /developers/ (who work in PHP), while PHP *application* developers should focus on making /their applications/ the best applications they can be for /users/ (who work in English). The time required to learn PHP is relatively small compared to the time someone may spend developing in it, so changes which lower the barrier to entry (which is already very, very low) but are detrimental to the long-term user need much stronger justification than is present here. There may be good arguments for making strings into objects, but any argument for such a drastic change to the language needs to be circumspect and pragmatic, and consider performance impact (probably excruciating), how it would work with loose typing (`$a = 'pie'; $a- >times();'), how much work is required (a lot) and who is actually going to do the work (you), etc., and offer concrete advantages if it endeavors to be convincing. In my mind, metaphors about icebergs fail to do this. Anyway, I laughed, but I wasn't sure if I was supposed to. Evan [1] http://www.ietf.org/rfc/rfc0822.txt?number=822 [2] http://cui.unige.ch/db-research/Enseignement/analyseinfo/ AboutBNF.html > I've written a short paper on the future of PHP and I'd appreciate it > if you folks would take a look at it and exchange your thoughts with > me. > > http://www.maraby.com/papers/pushing_php_into_the_web_20_generation > > Don't be too skeptical. ;) > > Cheers! > > M.T.