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
On Apr 18, 2006, at 6:25 AM, 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. ;)
Cheers!
M.T.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
