On Fri, Aug 9, 2019 at 4:12 PM Dan Ackroyd <dan...@basereality.com> wrote:
> On Thu, 8 Aug 2019 at 21:17, Zeev Suraski <z...@php.net> wrote: > > > > My goal is to have two sister languages, with both PHP and P++ > > being equal among equals > > PHP internals is already lacking programming resources to do > everything we want to be doing. > > Maintaining two versions at once would be more work, so this idea is > not feasible without a dramatic increase in the number of people > working on PHP core. > No, it won't. It will take no additional resources, and in fact, unless I'm missing something - Nikita's approach would in fact take more resources in the long run - as we'd have to maintain not just two dialects, but an open ended number of them. Much like it's hardly more work for us to maintain both strict and weak type hints, it shouldn't be significantly more work to maintain both dialects. The vast majority of work would be the one going into actually implementing the changed behavior and new features. Since even with Nikita's idea he's talking about providing a migration path, this is really not any more work *at all*. The only valid concern as far as efforts go, is whether we can pull off the main fundamental changes - the ones which will likely break any app if we don't introduce them from the get go - within a reasonable timeframe. I think it can be, but it remains to be seen. > I think that we should do our very best to get this > > "P++" right the first time, > > That's a fundamentally bad approach to designing a system. That's true, but we're not designing a system. We're designing a language. And to be more accurate - we're *re*designing a language, with ample experience, data and opinions on what we should have done differently. This is a lot closer to designing an API. And to keep the analogy working - it's like designing v2 of an API, after you've had a remarkably popular v1 and collected an endless amount of feedback about both what's good in it and what's bad. You'd be hard pressed to convince anybody that trying to get v2 - a version that breaks compatibility significantly and requires everyone to audit and refactor their code - right from the get go isn't a good idea that's well worth investing efforts in. Sure, you may not get around to implementing everything people are asking for - but if you're forced to break compatibility and are essentially asking people to partially rewrite their apps - you'd better make sure you do your best so that you don't have to ask them again a couple of years later down the line. With language design, it's actually a much bigger deal than with APIs (few APIs have the level of coupling with someone's code as their programming language does - hence the cost associated with fixing language-design mistakes is typically much, much bigger). Zeev
