Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22381
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Mon, 13 Mar 2006 15:31:50 -0500
In-reply-to: <7.0.1.0.2.20060309124054.06c31238@zend.com>
To: <internals@lists.php.net>
Message-ID: <002601c646dd$28bd9e30$d0a8a8c0@xpdt>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Thread-index: AcZDaFp2L7VhFtPTSlStFpki4JfMzwDbEgFw
Subject: RE: [PHP-DEV] Give the Language a Rest motion
From: saguyer@verizon.net ("Scott A. Guyer")
References: <7.0.1.0.2.20060309124054.06c31238@zend.com>


FWIW, I support this motion.

I am never a fan of the software lifecycle that looks like
"here's a useful technology, now we just need this, 
and this...etc. ad nausea".  Why?

(1) Adds complexity
(2) You often get pulled out of your original design philosophy 
    which puts the code's architectural integrity at risk.  Sometimes
    this evolves into a proper code restructuring, but more often, it
    does not.  Throughout history we have seen that things are the 
    victim of their own success.  This end may well be inevitable, but
    continually adding features and growing the system would only serve
    to expedite that end.
(3) I favor small, simple, highly expressive languages that focus on
    productivity in a stated problem domain.  Not large domain-independent
    languages that do nothing exceptionally well.

I think the question needs to be asked repeatedly and often, "what
is our design philosophy for PHP, and is proposed feature X consistent
with that philosophy?"  If not, no feature X. 
(NOTE: it may be reasonable to separate PHP from Zend, or executor from
compiler, when asking this question.  Consider MSFT's CLR model,
for example.)


PHP = "PHP: Hypertext Preprocessor"  

I'll wager we have grown well beyond what that name suggests already.
And I'll ask the question, what the heck does jump have to do with that?
(not to insult any proponents, nor do I want to single that one out, 
it's just the one I know at the moment)

To be quite frank, I'm not sure object orientation has a place in
scripting.  Objects are great for organizing architectures (not necessary,
but useful).  But should we be concerned about organizing architectures in
script languages?  Aren't scripts supposed to be synonymous with "small set
of automation instructions" ?  Reasonable question.

Why is PHP still in play in the industry?  Because of it's perceived
productivity edge over Java (excluding ASP.NET at the moment since it's
single vendor status is the principal cause for it being ignored by
many companies).  If that perception is lost, it's over (developers who
are fans will still cling to it for some time, but the industry will 
move on).

Give the language a rest?...aye!  
Focus on automation and productivity?...aye!

Cheers,
-Scott