@Tony Marston: I feel directly attacked and offended and others have the feeling too, that is the definition of an insult. That being said, I am staying constructive the whole time and do not avoid communication with you or anyone else because I think we are discussing an important topic. BUT! As Rowan Collins said, keep your emotions aside.
On 3/8/2016 10:47 AM, Tony Marston wrote: > "Rowan Collins" wrote in message news:56dd68c0.1090...@gmail.com... >> >> Out of curiosity, which languages are you referring to? It would be >> interesting to see if there are specific lessons we can learn from >> their development and compatibility processes, even if the ecosystem >> they exist in is very different to ours. > > COBOL and UNIFACE. > The history of COBOL shows that it was completely overhauled very often and major changed and breaks had to be made in order to rescue the language from being a mess. Later the designers of COBOL faced the same problems as we face them here right now, people complained about changes. In the 1990s the language started declining in popularity and was replaced by others. Pay special attention to the fact that over 300 dialects of COBOL exist and that compatibility issues was one of its major criticized points: https://en.wikipedia.org/wiki/COBOL#Compatibility_issues Uniface is not a programming language like PHP but they also had multiple breaking changes between releases. All documented publicly and easy to find, e.g.: http://unifaceinfo.com/docs/0905/Uniface_Library_HTML/ulibrary/Migration_5C39D681F0922AFC1A7859CF394AC2F7.html I am actually not trying to deface Tony Marston here, I am just saying that it is unavoidable to deprecate and delete features at some point in order to keep a language tidy and comprehensible while still offering people and easy way to upgrade. On 3/8/2016 11:23 AM, Rowan Collins wrote: > Clearly, there is a difference of opinion, and that difference > probably isn't going to go away by repeating the same points in > different words, so let's try to think of productive ways forward. > > You have mentioned stability as a good aim, and have given the > examples of COBOL and UNIFACE which we might learn something from; > Richard has mentioned that lack of consistency being a frequent > criticism of PHP. Is there some way we can formulate a policy, based > on experience elsewhere, of how to balance those two aims? > It would be awesome if we could open up a thread were we discuss these topics more in-depth. I think that this is really important to help our language of love to spread and grow further. :) On 3/8/2016 2:05 PM, Lester Caine wrote: > [...] > I'll have to do the same exercise again later for PHP7. Don't say > "Just switch off the warnings" ... THAT is what has built up the > backlog of work from PHP5.2 ... so adding even more warnings is not > helping improve PHP ... > I am not sure if I wrote that warnings should be simply switched off but I definitely wrote that this is a possible "solution" for people who know about the actual problem but do not want their logs to be littered with them. It definitely should not be the course of action for normal users. Your point however is very important because we really have to be very sensible about such changes. Introducing too many clean-ups is a problems. We saw PHP 6 simply ceasing to exist because the changes were too enormous and we saw it happening to Python 3 were the changes were not well received by the community and now they have to support two major versions (I do not know the details here). Which brings me too ... On 3/8/2016 7:17 PM, Lester Caine wrote: > [...] It all takes time that perhaps need not have been wasted since > ALL that changed was some ones preference of coding style :( > That we should definitely avoid. I do not consider the *var* keyword being a discussion about coding style preferences---this decision was already made in PHP 5! The *public* keyword was introduced and it superseded the *var* keyword including an E_STRICT error. Hence, this discussion is not about whether this was good, correct, or whatever decision: it is already done! This is about clean-up of the old unwanted way of doing it and by now maybe even a discussion about clean-up in general. TL;DR Clean-up is important but there must be an easy to follow migration path and enough time. We have both here, still +1 -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature