Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66125
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51263D89.5040308@lerdorf.com>
References: <alpine.DEB.2.02.1302201817350.5312@whisky.home.derickrethans.nl>
 <678597E6-E3A8-42E0-8DFC-F8382C9DFB41@strojny.net> <8d4e991084a1313844910ec0168eacdf@mail.gmail.com>
 <CAEZPtU5RZbVJS0txYRxxpTXzvk0ZvQdZBfx7qHTYwAd4cyn6Rw@mail.gmail.com> <51263D89.5040308@lerdorf.com>
Date: Thu, 21 Feb 2013 18:11:26 +0200
Message-ID: <CAA9esyQaWzUjFkjCKGvdjw8a+Xt6d7oC9NFKH7oQgshc6T8kLA@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)
From: florinpatan@gmail.com (Florin Razvan Patan)

Hello,


On Thu, Feb 21, 2013 at 5:30 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> In the slice of the "community" where I spend most of my time,
> medium-to-large companies using PHP with their own custom code on
> hundreds to thousands or even 10's of thousands of servers, neither
> annotations nor getter/setter are anywhere on their wishlist radar. What
> they most desire is performance, robustness and security. They would
> love to see a PHP release that had no syntax changes, no BC changes, but
> was twice as fast and crashed half as much. I realize this is just one
> (small?) slice of the community but so is the part of the community
> wanting annotations. This is the balancing act we have to perform. It is
> not stubbornness, nor living in the past, it is recognizing that each
> and every major feature addition has a destabilizing effect on the
> codebase and if the addition only serves a small slice of the userbase
> we have to think long and hard about the merits of it.

I couldn't agree with you more. While the company that I'm working on
just hit the hundred limit, this is one of our concerns as well.

And like I've said, stability is a key factor for us. Speed is also critical
and I agree that everyone needs more speed any time you ask them.

The examples I gave where just examples, not something that I'm crying
that is not added to the language but my company is also trying to be
open to any new things that would make our lives easier and help us
code faster, easier, better and so on.

I think it would be helpful to have something like a roadmap with various
features and changes both in regards to language and features as well
as performance.

Also, having a clear line of when features will be deprecated then removed
will go a long way to help out users while writing their software. That way,
people would know what to expect from the language and when it would
be the time to upgrade.

You could use the example of JetBrains and how they manage their
products via their issue tracker, http://youtrack.jetbrains.com/issues/WI
in which everyone that is not part of the core team can 'vote' for a feature
or bug or what not and participate in a threaded discussion in a simpler
manner.

This would bring you a nicer interface that the current ones while being
able to also gauge the community interest in certain issues.

I think if the PHP group would ask JetBrains for their software for free,
they wouldn't say no and I gave them as an example because I'm using
their beta software since it the second is out on their download servers
and I'm reporting every crash that I can as they made it really easy for
me to help them out.

And yes, I do feel like the current software stack of PHP.net is a bit out
of sync with the modern tools that are already there, sorry if I offend
someone.

That's why I think that the next major version of PHP should happen
sooner rather that later. I'm a strong believer that the current engine is
hard to maintain and document and very few people know most of it.

PHP 5.5 should be the last 5.X release then you should announce that
PHP 6 needs more volunteers for a better (faster) parser, people who
can help you on documenting it and so on.

Just make PHP 6.0 a PHP 5.5 that's clean under the hood, maybe
even brings some performance improvements along the way and that's
it. You already know what are the requirements for everything, you
already have feedback on what the community wants in the future,
so why not help yourself by doing something that's clean and along
the way will help you get more contributors?

Also please see my other suggestions on how you could get more
support from the users.



Best regards.
----
Florin Patan
https://github.com/dlsniper