Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91519
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.28.126 cause and error)
Reply-To: internals@lists.php.net
References: <1F.91.55238.41F10D65@pb1.pair.com>
 <CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
 <CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com>
 <FA.10.10408.29514D65@pb1.pair.com> <56D42CD3.6020602@gmail.com>
 <DB.E1.07778.3D165D65@pb1.pair.com> <56D57DF4.8000906@gmail.com>
 <56D5D2AD.6070805@gmail.com> <56D5DDA6.4080607@fleshgrinder.com>
 <40.73.36499.548B6D65@pb1.pair.com> <56D6BBD0.5010505@gmail.com>
 <56D73386.3000903@fleshgrinder.com> <86.68.21983.A2508D65@pb1.pair.com>
 <56D86C00.6000904@fleshgrinder.com> <12.FB.08749.AF759D65@pb1.pair.com>
 <56DAC26C.50304@fleshgrinder.com> <56DAE00F.2030203@lsces.co.uk>
 <56DAF480.7030508@fleshgrinder.com>
 <CAMPTd_B6VNQymDJo2MX03KrOWd1Mcfjg6gNY=GO1swxV8snrKQ@mail.gmail.com>
 <0B.E0.29316.019CBD65@pb1.pair.com>
To: internals@lists.php.net
Message-ID: <56DBFDB5.1010806@fleshgrinder.com>
Date: Sun, 6 Mar 2016 10:51:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <0B.E0.29316.019CBD65@pb1.pair.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="86GO46fXh2I0hT3VMRWlv4U1eRUHTxSqw"
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: php@fleshgrinder.com (Fleshgrinder)

--86GO46fXh2I0hT3VMRWlv4U1eRUHTxSqw
Content-Type: multipart/mixed; boundary="7UsXd6NPGJecXDxTLxAbHlS6CFhXKDdMk"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: internals@lists.php.net
Message-ID: <56DBFDB5.1010806@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
References: <1F.91.55238.41F10D65@pb1.pair.com>
 <CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
 <CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com>
 <FA.10.10408.29514D65@pb1.pair.com> <56D42CD3.6020602@gmail.com>
 <DB.E1.07778.3D165D65@pb1.pair.com> <56D57DF4.8000906@gmail.com>
 <56D5D2AD.6070805@gmail.com> <56D5DDA6.4080607@fleshgrinder.com>
 <40.73.36499.548B6D65@pb1.pair.com> <56D6BBD0.5010505@gmail.com>
 <56D73386.3000903@fleshgrinder.com> <86.68.21983.A2508D65@pb1.pair.com>
 <56D86C00.6000904@fleshgrinder.com> <12.FB.08749.AF759D65@pb1.pair.com>
 <56DAC26C.50304@fleshgrinder.com> <56DAE00F.2030203@lsces.co.uk>
 <56DAF480.7030508@fleshgrinder.com>
 <CAMPTd_B6VNQymDJo2MX03KrOWd1Mcfjg6gNY=GO1swxV8snrKQ@mail.gmail.com>
 <0B.E0.29316.019CBD65@pb1.pair.com>
In-Reply-To: <0B.E0.29316.019CBD65@pb1.pair.com>

--7UsXd6NPGJecXDxTLxAbHlS6CFhXKDdMk
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 3/6/2016 7:07 AM, Stephen Coakley wrote:
> That is correct; there are many, many old codebases of many different
> languages out there. However, you need to consider in what way such
> software is maintained. Let's start with Linux and Apache. Both of thos=
e
> pieces of software are _not_ in "maintenance" mode. They are both in
> active development, and as such are living, changing codebases that are=

> being continually updated to have new features, bugfixes, and
> compatibility with newer compilers, systems, and libraries.
>=20
> Now consider some in-house software that is in maintenance only, as
> there are also many of those. Assume one such software is written in C.=

> Let me ask you: are you going to compile such software with the latest
> version of libc and using the C11 standard with the compiler? Of course=

> not! The likelihood of it compiling bug- and error-free is too common,
> with functions removed in C11 and memory layouts changing in the last 3=
0
> years of libc. You would compile such a program with the appropriate
> versions of its dependencies.
>=20
> Now I'm not saying any of this is good or bad, I'm just saying it the
> way it is. If you have 40+ year old software that you can't afford to
> continually update, you should continue to use the best versions of
> stuff that are still compatible. If you can afford to update small part=
s
> to be compatible with newer systems, then do so. (I'm talking like
> changing a few lines of code or maybe more to use a new function instea=
d
> of an old, deprecated one.)
>=20
> In the PHP world (which is a tad bit different, since you can't ship
> "binaries" compiled 10 years ago), the equivalent would be to run
> 10-year-old software on the best version of PHP that it is compatible
> with; 5.6 (hopefully; maybe older, maybe newer -- depends on the
> program). Now how long we backport security and bug fixes to old
> versions is a completely different discussion, but I hope you get my
> meaning.

This explanation matches my experience at companies as well. They either
use old systems (e.g. Windows XP is still in use at many companies in
Germany because there software was programmed against it) or old
software (Java 8 broke with Java 7, so did Java 7 with Java 6, so did
=2E..) and they simply do not bother to update at all. Not the code, not
the system, nor the software.

@Tony Marston: you are always saying that "this is "longevity" [...]
they will move on to another language" but I do not see such a language,
not a single one. There are those who break with every release
(node.js), those who break hard with a major release (Python), and those
who are carefully crafted to contain proper CHANGELOGs, upgrade paths,
deprecations, ... (Java, C derivatives) and then there is PHP where it
is completely random based on the people who saw the actual thread on
the mailing list and shouted the loudest.

Removing old or bad features is absolutely normal and it is what is
being done in good languages. You want to keep your interfaces clean and
easy to understand. You do not want them to be cluttered with
unnecessary features, aliases, argument swapping, ...

Expecting to write some code without any kind of maintenance while
expecting the systems and software to ensure it runs for the next
decades without any kind of issues is naive.

--=20
Richard "Fleshgrinder" Fussenegger


--7UsXd6NPGJecXDxTLxAbHlS6CFhXKDdMk--

--86GO46fXh2I0hT3VMRWlv4U1eRUHTxSqw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW2/2+AAoJEOKkKcqFPVVrtUgP/3C5KX8QY0oACIu/bpAHRPeS
SH2UmQ+ajY3QP4gQnSw8R5r79dbBepTkJvFj3BpyaKCbQacr2prYjPirgVAyq6W5
4WwEeCw5cEDTIIW3mTiVNYjQhzHmRcJssCXZfK5dy7ZO1rUkV2JzbW3eN5CwtZb3
RQkHnm9Y2oqp+QkXINM605mIZS0YGoFBbyySgWP7n/RLKKeMviV1KGxX7ntfklpq
jF2C9Hh/uKeDl+B7rXZMN7pdsg2/2ds5vsNlffFu68VQ6YGlAVvrXVkbmFyAgTLx
sWLhjsFZi7ajV/zIicOKoSFCpsDp6N09/Ucjs8vartiEcK7GDhxyQFt3ZTTrEuAk
K2S5nwGHNxXA5aelz7NVPmCWf8THf+7/M0N58xvMEAwXRBtjOXaTK2je/S2eYw+H
KyvSdKsn1P+YYDyebguX1swfkIuBnZ551JDZ/zc+lGNPy7NZ6+9rRXsX1HqGMPZ9
cO/yYYlfpINl0D+LF338rtKiUo8Ngowm35IOOAobX8M+AswOc7q7/rE/yVOZzHyU
0t9ZuA8wC1FCj7A8JCUlXbQ3kBnFMiQ5QcYuxDaQqJ6YCQ6OM7s+RZK6l8sAMKjF
CJO5U8KNNmeU5H1sBXDpI5QgYudpTCONVoRHq9FzyWHpEFM7FXApRWxXaj1pJANM
30UGyyP3sfDJNrHMGcaD
=o8nv
-----END PGP SIGNATURE-----

--86GO46fXh2I0hT3VMRWlv4U1eRUHTxSqw--