Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92385
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 212.232.25.164 cause and error)
Reply-To: internals@lists.php.net
References: <CAKSD0w7JcGxcYrf7anZeGxGd4+U9BbSREnKfzW0eEpaoP0aWoQ@mail.gmail.com>
 <57136573.7070802@fleshgrinder.com> <57137F66.3080608@lsces.co.uk>
 <57138312.7020003@fleshgrinder.com> <57138848.70303@lsces.co.uk>
To: Lester Caine <lester@lsces.co.uk>, internals@lists.php.net
Message-ID: <57138F9B.4030600@fleshgrinder.com>
Date: Sun, 17 Apr 2016 15:28:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <57138848.70303@lsces.co.uk>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="4RfghIGWqXhDwWFimtv5gBhDmObp3T6pb"
Subject: Re: [PHP-DEV] Re: Improving PHP's type system
From: php@fleshgrinder.com (Fleshgrinder)

--4RfghIGWqXhDwWFimtv5gBhDmObp3T6pb
Content-Type: multipart/mixed; boundary="oq1hMp7nbHLJ7TuuI0LxTuIDCOGHMTQmJ"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Lester Caine <lester@lsces.co.uk>, internals@lists.php.net
Message-ID: <57138F9B.4030600@fleshgrinder.com>
Subject: Re: [PHP-DEV] Re: Improving PHP's type system
References: <CAKSD0w7JcGxcYrf7anZeGxGd4+U9BbSREnKfzW0eEpaoP0aWoQ@mail.gmail.com>
 <57136573.7070802@fleshgrinder.com> <57137F66.3080608@lsces.co.uk>
 <57138312.7020003@fleshgrinder.com> <57138848.70303@lsces.co.uk>
In-Reply-To: <57138848.70303@lsces.co.uk>

--oq1hMp7nbHLJ7TuuI0LxTuIDCOGHMTQmJ
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 4/17/2016 2:57 PM, Lester Caine wrote:
> On 17/04/16 13:35, Fleshgrinder wrote:
>> If you are only afraid that usage of your libraries declines because
>> users demand these new features to be part of it and you do not want t=
o
>> implement them. Sorry, but that would be a clear sign that the feature=
s
>> are good and should be used.
>=20
> I have two major libraries I have used since day one of PHP5 ... ADOdb
> and Smarty ... both of these have provided the core of my framework, bu=
t
> have needed a lot of work simply keeping my code in sync with them, and=

> the latest 'improvements' to both are not BC for reasons that are blame=
d
> on needing to 'modernise' the code. Now I DID keep my own copies of bot=
h
> for many years to keep the PHp5.2 code working, and perhaps I should
> simply close the door on PHP7 and stay with what is currently working.
> But PHP7 ... ignoring any of the new features ... does provide
> improvements in some areas if you REMOVE the legacy stuff which prevent=
s
> the optimisations from giving their best. The 'improvements' to ADOdb
> and Smarty are claimed to help this process but unfortunately the peopl=
e
> pushing those changes are 'new school' and expect all the new stuff as
> well. So exactly where is PHP heading? Do we keep with the original
> simple flexible language that even today still works fine, or do we
> accept that everything that is being demanded should also be included
> and just roll over.
>=20
> I do not accept the statement that 'You do not have to use it'! That ma=
y
> have been true in the past, but today one has to live with the fact tha=
t
> legacy code and modern hosting simply do not co-exist. One HAS to take
> care that the key third party bits still work, and it's libraries like
> the mapping extensions which relied on many key elements that HAVE now
> been removed from PHP.
>=20

The situation you describe is a pain that I know myself and I agree.
There are too many libraries that try to solve things in the most
possible generic way and abuse OO to ridiculous excesses instead of just
solving a single, simple problem with a few functions (as our old but
gold Unix philosophy has taught us). The simple rule "If it ain't broke
don't fix it" is also violated too much.

The reasons for this are manifold and hard to grasp from time to time. I
guess most often the problem boils down to "my library is not cool if it
does not use the latest language features". Ignoring completely if those
language features are actually appropriate for the problem. E.g.
excessive usage of exceptions without a single assertion spread all over
a code base to validate developer input.

However, you should seek the discussion with the maintainers of these
libraries and have a serious talk about BC, stability, and appropriate
usage of language constructs to solve problems. Instead of trying to
block advancement and evolution within the language itself.

Most features that are currently discussed are aiming at enterprise
applications that require more built-in functionality to ensure
correctness, reduce the amount of tests (unit as well as runtime) to
detect bugs, and where many developers work together at the same code
base. Most features can increase agility and productiveness of such
teams and allow them to implement new features and A/B tests faster. Of
course many features require more knowledge about programming. This can
also be bad for such teams because big teams almost always suffer from a
huge knowledge gap. Despite that, it helps the more advance developers
to create richer APIs that are harder to abuse and in turn allow the
overall design to achieve previously mentioned goals.

This is the sole reason why new language like Rust and Ceylon were
invented in the last years. Of course there are also projects that aim
at the novice user, e.g. Golang[1]. PHP currently achieves both in the
context of web projects and support for enterprise was grew and grew and
big companies like Facebook or my employee trivago who decided to go for
PHP do not want to invest a shitload of money into rewriting everything
from scratch in another language[2] like Twitter did (and exchange all
their developers who were already extremely hard to find in the first
place with new ones) just to get enterprise features. No, they want to
see advances in PHP to support exactly those features.

Facebook did not see those advancements and sent out their OCaml/C++
team to create something that has exactly those enterprise features
while we at trivago plan to upgrade to PHP 7, while I am writing these
lines, to get more performance out of the language and strict type checks=
=2E

There are always pros and cons and it is hard to satisfy everyone but
the type system of PHP is definitely one of its main weak spots and it
must be improved to support enterprise requirements better.

[1]
http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-pro=
grammers/
[2] This applies to switching from PHP to HHVM/Hack as well.

--=20
Richard "Fleshgrinder" Fussenegger


--oq1hMp7nbHLJ7TuuI0LxTuIDCOGHMTQmJ--

--4RfghIGWqXhDwWFimtv5gBhDmObp3T6pb
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

iQIcBAEBCAAGBQJXE4+fAAoJEOKkKcqFPVVrWgYP/jXcYdnRCLLQgtjKEQCNRoji
CUk0hXxmk3X1Uxit2IocWYi2UBt+M5wJs5DWLmI70Pqlpdk+RWABgVjKIa4zG2aO
RW6Y+2eZqB/WK9JeFBjGuG/d3ftYylqr77hRtcrKk+FEspGKn461nXK4+P/xuKA/
xQHjpVFF2aE4ySJRnahWGNxXqPrbSt1IvXAzabtFtDLT1aAUoRSaKWUrh6svwtyA
8uvl2/uBCpwJZrmEHvEfqGR1Hax7kCXeDlcu8XjbMMO9LoOfZEK0DS5lKXVmKNvY
rcF3/Gs0/ByEjJkYqXLSBRDsgaDJCqtGNQ/lufOBRMdoo+KwQuweTUpPR8GN+dr9
4L7EfT4n82GM4BTAsUff5idM2lYZ0GcVc3VhtQ3teiaRCDH33uzO5VOWguXNsvzN
KrY/8RXjDM7+iTMxio6tJgddfQ6n0mklfKCo3Jv+S3ZXFhCX6fW93Z3SQux4QJdP
h6TFPFc0cxPcRIPtKmjOfbH5dezH06qxBQJgIESg6QzuFwSrRAO2R7DxI5yhq0Uw
n/bml6YliJ6dg+ATT2K56vDA9n8XpXJdujjVNn9uaInYHT/osZ5E+I1XtHmB98KP
EljyM969yhdn1OeQ1tNXypZ1Dm0dRqfJBem+uRne7WtgkYjJWZimEBVhRphpUc11
oYrumWzoJkWKFYU8eJzt
=WjeY
-----END PGP SIGNATURE-----

--4RfghIGWqXhDwWFimtv5gBhDmObp3T6pb--