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 to >> implement them. Sorry, but that would be a clear sign that the features >> are good and should be used. > > 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, but > 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 blamed > on needing to 'modernise' the code. Now I DID keep my own copies of both > 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 prevents > the optimisations from giving their best. The 'improvements' to ADOdb > and Smarty are claimed to help this process but unfortunately the people > 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. > > I do not accept the statement that 'You do not have to use it'! That may > have been true in the past, but today one has to live with the fact that > 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. >
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. 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-programmers/ [2] This applies to switching from PHP to HHVM/Hack as well. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
