"Pushing PHP Into The Web 2.0 Generation" View as Markdown

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.

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

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 from5'? 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" thanfor( $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.