Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66099
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8d4e991084a1313844910ec0168eacdf@mail.gmail.com>
References: <alpine.DEB.2.02.1302201817350.5312@whisky.home.derickrethans.nl>
	<678597E6-E3A8-42E0-8DFC-F8382C9DFB41@strojny.net>
	<8d4e991084a1313844910ec0168eacdf@mail.gmail.com>
Date: Thu, 21 Feb 2013 11:09:00 +0100
Message-ID: <CAEZPtU5RZbVJS0txYRxxpTXzvk0ZvQdZBfx7qHTYwAd4cyn6Rw@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Lars Strojny <lars@strojny.net>, Derick Rethans <derick@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
From: pierre.php@gmail.com (Pierre Joye)

hi Zeev,

On Thu, Feb 21, 2013 at 10:56 AM, Zeev Suraski <zeev@zend.com> wrote:
> What you're bringing up is not at all about adapting.  Adapting is
> something we do at the extensions, frameworks and tools levels.  I'm happy
> to say PHP's ecosystem here is very healthy, in my opinion.

Yes, most of the time. But the language needs evolution, must have evolution.

F.e., how long have we been battled for annotations? With all
respects, it is about being blind and stubborn to say that PHP should
not have annotations. But due to some "I'm happy with what we have
now" way of doing things, we are very unlikely to have them any time
soon, even if any major projects out there are waiting for it, for
years. Even the ZendFramework leads want them now (changed their mind
since the last attempt).

This is not about borking the language with useless features. This is
not about being on the cutting edge. this is about catching up with
the competition.

> Adapting is not what we're dealing with here.  We're talking about Adding.

Adding? Surely a matter of wording. I'd to say evolve and catch up.

> By adding more and more, we're making the language more and more complex,
> less and less accessible to both new and existing developers, thereby
> hurting its #1 appeal - simplicity.

I heard that in php 4 > 5 and OO, and all we rejected back then have
been introduced since then. Not sure what is the best way, trying to
stop with all four feet (to take your analogy) any kind of
additions/evolution/catching up and then still doing it but years
later, or trying to get a bit more open minded and listen to our
communities.

> As we thrust forward towards 5.5,
> more than half of the community is still on 5.2.  5.4 is virtually
> nonexistent in terms of real world usage, and yet we thrust forward to
> 5.5, as if the community at large cares about all these new features.  The
> community is voting with its feet, and that is probably the best survey
> we're ever going to get.

Excuse me? Voting with its feet? Dare to explain the underlying
meaning of this comment?


> I'm not saying we shouldn't add new features.  But I am saying that we
> shouldn't add many of them.  The very few we should add - should have
> exceptional 'return on investment'.  To be clear, the investment isn't
> just the effort to develop or even maintain the implementation - that's
> not even the main point.  It's the increased complexity that each and
> every new language construct brings with it, whether we like it or not.

Yes, totally agree here. Annotation and usable getter/setter syntax
have a huge ROI. Discuss with any application or framework
developers/users will bring you to the same conclusion.

> There used to be a language that was the Queen of the Web.  It was full of
> clever syntax.  It prided itself on having a variety of expressive ways of
> doing the same thing.  You're on the mailing list of the language that
> dethroned it.

You are living in the past glory. We are not willing to make PHP more
complex or kill it. We are willing to make compromises between the
2000s simplicity and the needs of modern application developments.
These compromises are not only required but possible.


Cheers,
--
Pierre

@pierrejoye