Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106494
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=MR6vt54blr1J7CZaQJXkyHD5dif2GRCiEUtd/NQdnviDo+x1J8PQKrg493M6Xv
	G22gwEQU1xwvZfhUfcPiIiryCimQVlmt9ufzXHRLBBZ+IR4S9y4gvr9d4aO1d9FT
	mmSZwONLSqhzezgBVRf19eZYtmry0n70U6gOQT6T7TA8Q=;
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com> <CA+kxMuRm3zzC8aQBnfZhFweo78vCw6he4Eo7dWz42848k28s0A@mail.gmail.com>
In-Reply-To: <CA+kxMuRm3zzC8aQBnfZhFweo78vCw6he4Eo7dWz42848k28s0A@mail.gmail.com>
Date: Fri, 9 Aug 2019 16:41:26 +0300
Message-ID: <CAJHtznzu=2rULYv75B7Orap41w401App5qK_dP2BOQ+GU3iaiA@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005e28d8058faf554a"
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: zeev@php.net (Zeev Suraski)

--0000000000005e28d8058faf554a
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 9, 2019 at 4:12 PM Dan Ackroyd <Danack@basereality.com> wrote:

> On Thu, 8 Aug 2019 at 21:17, Zeev Suraski <zeev@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

--0000000000005e28d8058faf554a--