Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66127 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53687 invoked from network); 21 Feb 2013 17:29:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Feb 2013 17:29:47 -0000 X-Host-Fingerprint: 217.114.211.68 unknown Date: Thu, 21 Feb 2013 12:29:46 -0500 Received: from [217.114.211.68] ([217.114.211.68:14830] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 48/19-05272-A8956215 for ; Thu, 21 Feb 2013 12:29:46 -0500 To: internals@lists.php.net References: <678597E6-E3A8-42E0-8DFC-F8382C9DFB41@strojny.net> <8d4e991084a1313844910ec0168eacdf@mail.gmail.com> <51263D89.5040308@lerdorf.com> User-Agent: slrn/0.9.9p1 (SunOS) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-Posted-By: 217.114.211.68 Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd) From: dsp@php.net (David Soria Parra) On 2013-02-21, Rasmus Lerdorf wrote: > Personally I would love to see more RFCs focusing on performance and > less on syntax changes. Of course, a syntax change RFC, and even the > initial (often shaky) implementation of a syntax-related change is much > much easier to whip up than the deep analysis, profiling and creativity > required to find and come up with ways to make a complex piece of code > faster or use less memory. +1. I think that the RFC process did the project very good and enabled new people and their patches into the project. Nevertheless we should be aware that a scripting language needs to be robust and fast. The more language syntax we add, the more complex the language gets and therefore it's quality as a very good beginners language. Also we just end up in the troubles we had over the last years when one could just hope that xdebug will catch up with new language changes (thanks to derick it usually does), and one knew that APC will not work. A lot of the language features in the last years didn't just make some people happy but also made others unhappy as they couldn't use the new language in production (and thats what counts). People are stuck with 5.3 atm because there is no opcode cache for 5.4 and the only good news for them is that the ZO+ RFC focuses and robustness and performance so the users will still have an opcache for a new version once 5.3 is EOL (in a year). (and i am not even talking about the headache everyone is already talking about because they used a lot of apc caching functions in their code and therefore are stuck with 5.3 for another 2 years and can just rely on distros for patching). So plesae when one talks about the userbase, make sure you just dont see you part of the bubble but all the others who are struggling with recent changes already.