Your evaluation is pretty anecdotal. I agree with some points but you need some solid evidence if you are going to rate these languages. Also do you have a list of all the functions you would like to rename or is this a sweeping lets just change everything so it matches and deprecate all the old stuff. Your matrix is a very weak push to do so. If you want to make these changes it would be better to choose a select set such as the array functions and try and push that through or see what that change might look like and if it's really beneficial to userland.
On Tue, Mar 3, 2015 at 7:46 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi Rowan, > > On Wed, Mar 4, 2015 at 7:12 AM, Rowan Collins <rowan.coll...@gmail.com> > wrote: > > > You are measuring the wrong cost. The cost of adding new names is to > > people writing code: > > > > - additional confusion for new users about why everything has two names > > and which they should use > > - extra effort for new developers to learn the new names, even if they > > only read them in other people's code (it slows me down every time I see > > sizeof() and have to remember it's just an alias of count()) > > - awkward decision for project leaders: use the old names for familiarity > > and compatibility with older versions, or the new ones because they're > > arguably better names > > - if an existing project does choose the new names, the overhead of > > converting all the existing code, with the risk of bugs introduced by > > incorrect automation, noise in commit logs, merge conflicts, etc > > - if a project needs to run on PHP 5, the vigilance required to avoid > > accidentally using the new names when developing on PHP 7 > > > > That's not an exhaustive list, and some of these aren't huge costs, but > > collectively they outweigh the benefit of a slightly more consistent set > of > > names for things. > > > > This is why a more radical change - an OO-style API for scalars and basic > > modules, a fundamentally new set of functions which fulfil a specific > need, > > etc - has the potential for acceptance, and this proposal does not. The > > costs are mostly fixed, so we need to increase the benefits to outweigh > > them. > > > > This is fair discussions. We should care these also. I agree these costs > exist > and shouldn't ignored. > > I have different point of views. It's long term view or new user point of > view. > For me, it outweighs costs you've mentioned. > > Whether we like it or not, people evaluate languages by matrix like > > PHP Ruby Python > OO support 5 5 5 > Flexible syntax 3 5 5 > AOP support 3 3 3 > DbC 1 2 2 > API consistency 1 3 3 > API richness 4 4 4 > 3rd Party Libs 4 4 4 > Performance 4 3 3 > Security 1 4 4 > Type Safety 1 4 3 > > Although this is rough evaluation by me, people would have somewhat similar > matrix. > > API consistency 1 3 3 > > The reasons why people evaluate PHP like this are > > - PHP has API inconsistency even for most basic APIs like phpversion(), > htmlspecialchars(), etc > - Even bundled modules have non standard function names. > - API parameter ordering is inconsistent. > - Return type for errors are inconsistent. e.g. Wrong number of param > returns NULL, while others return FALSE mostly. > - Some basic internal classes do not raise exception for instantiation > failure. > - and so on. > > I'm not saying Ruby's APIs are organized very well. For example, user has > to search > around proper API even for URI escape provided by various modules. > Therefore, I > evaluate it as 3. > > Having this kind of evaluation matrix is not good for PHP in the long run. > IMHO. > > > BTW, > > Security 1 4 4 > > I evaluate like this because PHP is to weak against fatal security breach. > i.e. Script Inclusions. > You'll see my view and the reason why I focus in some area strongly from > the matrix. Although > I didn't participate scalar type hint RFC discussion much, I cannot wait to > have StrictSTH also. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net >
