On January 2nd of this year I was banned from participating in the php.internals newsgroup. This was because of a request made in this post which was followed by this post. I was not informed that I was to be either suspended or banned, or for how long, nor was I informed about which post had violated which published rule. This strikes me as being a knee-jerk reaction that was both both unwarranted and unprofessional.
The newsgroup rules are documented in posting guidelines and also in mailing list rules. The latter also contains a link to the general purpose RFC 1855 - Netiquette Guidelines. In the interests of brevity I shall condense all those wordy and imprecise documents into simple language:
This particular newsgroup is for the discussion of proposed changes to the language. These proposals may later appear as a Request for Changes (RFC) which may then be voted on, and if passed may be implemented. It is possible for an RFC to be passed but not implemented due to the lack of a working patch.
The term "appropriate content" specifically excludes Spamming and Trolling, but also excludes posts which are not about proposed changes to the language. Posting bugs to this list would not be appropriate, nor would questions of how to use the language.
It should be understood that if someone makes a statement in this newsgroup (provided that it is related to the topic being discussed) that it is perfectly acceptable to respond to that statement. If something is said with which you disagree, and you do not voice that disagreement, then the author of that statement can claim that the lack of disagreement shows that everyone agrees with that statement.
This includes obscenities, crudities and expletives. The term "offensive language" does not include those instances where some delicate soul is offended by the fact that his opinions or beliefs are questioned, it only includes that terminology which the general population (or a reasonable person) would classify as being offensive. For example, the fact that some vegans are offended by the thought of killing animals for food does not mean that anyone who talks about preparing meals made of animal flesh is using offensive language.
If somebody makes a statement with which you disagree you may challenge the statement, but you should not make personal attacks on the person making the statement. For example, saying "I disagree with your statement because ..." is perfectly valid whereas "Everything you say is rubbish because you are an idiot" is not. Bearing in mind that the entire purpose of this newsgroup is to discuss proposed changes to the language some people will be in favour while others will not. A difference of opinion is therefore expected, so complaining that someone does not share your opinion is totally out of order.
While most people are able to discuss topics with others who may hold similar, divergent or even totally opposite views, there is a growing tendency among some, especially the younger generation, to be too emotionally insecure to be able to cope with views which challenge their own. They think that what they know is always right, and anyone who disagrees is always wrong. Their mantra seems to be I don't like what you are saying, therefore I want to ban you from saying it. These people have come to be known as snowflakes as they are so delicate and fragile they fall to pieces at the slightest hint of a different opinion. These people can find offense in the inoffensive. What is even worse are those who I call "snowflake appeasers" who rush to remove any trace of this pseudo-offensive material and end up by stifling any serious debate. By bending over backwards to appease the snowflakes they are showing a distinct lack of backbone and are throwing common sense out of the window. When I say "bending over backwards", in reality this is "forwards" because they are allowing themselves to be well and truly shafted. The end result will be that the inmates will be running the asylum. Instead of allowing adults to have adult conversations we will be led by children who throw tantrums whenever they don't get their own way - just like the British prime minister who threw his toys out of the pram when the electorate voted for brexit against his wishes. These appeasers should stop letting themselves be bossed around by a bunch of children, they should man up and grow some balls.
In the programming community I have encountered more than a few people who have been taught only one way of doing things, and they automatically assume that it is the "only" way, the "right" way, and that everyone who does not follow their beliefs is automatically wrong and their work is automatically inferior. They love to follow the "rules" (often labelled as "best practices") and they take great delight in coming up with new interpretations of old rules and act as if these new interpretations were carved in stone and brought down from the mountain top. They follow these rules with something akin to religious fervour and regard all non-believers as heretics. In the PHP community I have been regarded as a heretic since 2004. I ignore all accusations that my methods are wrong for the simple reason that they work, and anything that works cannot be wrong.
I started working with PHP in 2002 after working for several decades with languages such as COBOL and UNIFACE. I was drawn to it because of its inherent simplicity, its ability to allow me to get things done with the minimum of effort. Simple things were easy and difficult things were possible. I particularly liked the fact that it was dynamically typed which meant that I did not have to declare a variable before using it, and I could inspect and even change a variable's type at runtime. I had built frameworks in each of my two previous languages, and after I had rebuilt my framework in PHP I discovered that my productivity levels had increased quite dramatically. You could therefore say that I am a fan of dynamically/loosely typed languages, just like Robert C. Martin.
I was therefore not impressed when I saw discussions in the internals newsgroup which first introduced something known as type hinting as I strongly suspected that it would eventually be upgraded into type enforcement. And so it came to pass. I began to follow the discussions on the RFC for Scalar Pseudo-type. Below are the comments that I made in chronological order. I challenge any reasonable person to identify any post of mine which violated the the newsgroup rules.
>Am 29.12.2017 um 00:21 schrieb Larry Garfield:
>> Correct. Union types I've always seen presented as offering both union
>> intersection. There are cases where union is great, and where it's kinda
>> silly. There are cases where intersect is great, and where it's kinda
>> Most of the anti- arguments I've seen for "union types" have fixated on
>> "int &&
>> string is meaningless, and Foo || Bar is bad design, so union types are
>> Entirely ignoring the flip side, which is int || string (valid use cases)
>> Foo && Bar (many many valid use cases)
>well, that explains why the same person which has a usecase for a "scalar"
>pseudo-type donw-votes https://wiki.php.net/rfc/union_types but it makes
>his vote not logical at all
>frankly the only valid reasons to down-vote something should be technical
>ones which matters for the PHP core itself and not "i don't understand a
>feature hence nobody should have it"
You are missing the point. If an RFC is so badly written that someone does not understand it, or understand what benefits it is supposed to provide, then there is no point in up-voting it. You may contrive a use case where it provides a small benefit, but if that use case is so limited or so obscure that it does not apply to a significant number of developers then that RFC should be voted down simply because it does not provide any significant benefits.
>Am 29.12.2017 um 09:04 schrieb Tony Marston:
>> wrote in message news:email@example.com...
>>> Am 29.12.2017 um 00:21 schrieb Larry Garfield:
>> You are missing the point. If an RFC is so badly written that someone
>> does not understand it, or understand what benefits it is supposed to
>> provide, then there is no point in up-voting it
>if i don't undrstand it i don't vote at all - that's the point
If you can't understand it then you cannot tell what benefit it gives to the greater PHP community, and if you cannot see that it provides any benefit then you should vote it DOWN. Common sense should dictate that you only vote it UP when you are convinced that it will provide something of benefit. If you don't vote at all you are admitting that you are clueless, or don't care, in which case you are not preventing a bad idea from being accepted. If it later turns out that it was a crock of sh*t then you will be partly to blame because you didn't have the intelligence to see it as such and didn't speak up. If you don't understand an RFC then not only do you not understand the benefits that it can provide, you also don't understand the damage that it can cause.
>Am 30.12.2017 um 10:16 schrieb Tony Marston: >> wrote in message news:firstname.lastname@example.org... <snip>
>frankly, in the real world when you don't understand what some people are
>talking about you don't join and say "no, you are wrong" - you either shut
>up or ask again but you don't step in yelling "no!"
It is not about an idea being right or wrong, it is about adding something new to the language. If you are not convinced that it will add value to the language then you should vote it down. Not voting either way because you don't understand the RFC or its proposed benefits just shows that you aren't qualified to vote on anything.
>Am 30.12.2017 um 11:37 schrieb Lester Caine:
>> On 30/12/17 09:16, Tony Marston wrote:
>> The 'greater PHP community' I continue to support is still only looking
>> for a simply life, but each iteration of PHP7 is just making things more
>> and more complex, which is why I STILL have not switched off PHP5 and
>> 5.4 and earlier is still running a large percentage of sites. Just what
>> percentage of the wider community thinks that strict typing is giving an
>> essential benefit? If there was a groundswell for typing then perhaps we
>> would not have this continual debate on just how to jam a little more of
>> a move that way and get on with a version of PHP that is only typed.
>> Then for one can simply avoid it ...
>who thinks it don't give you a benefit?
>for new code it's the best you can do do get it as bugfree as possible and
>fro old code you still are not forec to any typehints and for migration you
>have weak types too
>sorry, but discuss end of 2017 if types was a goof d idea and talk about
>the 'greater community' but still run PHP5? in the meantime I have changed
>*everything* written in the last 15 yeas to strict_types=1 and type hints
>everywhere - you find so much potential bugs that it's worth
Some of us are clever enough to write code that doesn't have those types of bug in the first place. I developed my framework in PHP4 before type hints even existed, and I developed a large enterprise application with that framework which is now being sold to large corporations all over the world. That codebase has moved from PHP 4 through all versions of PHP 5 and is now running on PHP 7.1. During these upgrades I have only changed my code to deal with what has been deprecated, and I have never bothered with any of those new optional extras (such as typehints) unless I have been convinced that the effort of changing my code has measurable benefits.
The idea that typehints provide benefits to the whole PHP community is completely bogus. It only provides apparent benefits to those programmers who have moved from a strictly type language to PHP and who feel lost without the crutch that a strongly typed language seems to provide. I work faster with a dynamically and weakly typed language, so speed of development is far more important to me. Any so-called bugs are detected and fixed during the testing phase, so I don't want the language being slowed down performing checks that I don't want.
This message prompted a response from Lester Caine in http://news.php.net/php.internals/101464:
Thanks for that Tony ... almost exactly where I am as well ... I started
just as PHP5 came to final betas - from C++ - and never had a problem
with the flexibility that provided.
Lester Caine - G8HFL
This offended that serial snowflake Michael Morris so much that he sent Lester an email to which he replied with http://news.php.net/php.internals/101471:
On 31/12/17 22:45, Michael Morris wrote:
> Please do not quote large swaths of Tony Marston's crap. He's an
> unrepentant liar, braggart and trouble maker that most of the list has
> on ignore since the admins can't be bothered to do their job and kick him.
I'll ignore the slander ... but perhaps now it the time that I simply
cut my poor clients loose and leave it up to them to keep their websites
working. Certainly the amount of time wasted coping with CRAP windows
updates such as happened last week, the minefield these days of keeping
Linux servers actually working and the problems of prioritising just
where to spend the remaining time to just keep currently live sites
working leaves no time to do any NEW work! OH and the bastards in the US
who steal .com domains for porn crap and ICANN does nothing to protect
us from !!! At least non US controlled domains are honest when we PAY to
renew! Another job to waste time on this week :( So NO I DON'T NEED
STRICT TYPING ... THE DATABASE INTERFACE TAKES CARE OF LIMITS AND VALUES
THAT int DOES TOTALLY NOTHING FOR !!!!
Lester Caine - G8HFL
"Michael Morris" wrote in message
>On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine
>> Not being able to vote, many of us have no option to complain about the
>> way things are going. Currently there seems to be several styles of PHP
>> form the nice and simple untyped version I moved to from very strictly
>> typed hard compiled code I'd been using up until then, through to
>> current code which is reliant on third party things like PSR and
>> Composer and expects only strictly typed PHP.
>This is born of the fact that while ignoring datatype makes learning PHP
>easier, it makes using it harder - especially when testing.
I strongly disagree. I have been using PHP since 2001 and I have never used type hinting in any form whatsoever. Does it make testing more difficult? No, it does not.
>Am 31.12.2017 um 11:24 schrieb Tony Marston:
>> Some of us are clever enough to write code that doesn't have those types
>> of bug in the first place. I developed my framework in PHP4 before type
>> hints even existed, and I developed a large enterprise application with
>> that framework which is now being sold to large corporations all over the
>> world. That codebase has moved from PHP 4 through all versions of PHP 5
>> and is now running on PHP 7.1. During these upgrades I have only changed
>> my code to deal with what has been deprecated, and I have never bothered
>> with any of those new optional extras (such as typehints) unless I have
>> been convinced that the effort of changing my code has measurable
>well my codebase dates back to 2002 but is stricted-typed in the meantime -
PHP was never strictly typed from the start, and I have always loved the flexibility that this provided. I have never felt the urge to use typehints (or type enforcement that it has now become)and any potential bugs that this may create are quickly identified and resolved during my testing.>> The idea that typehints provide benefits to the whole PHP community is
>> completely bogus. It only provides apparent benefits to those programmers
>> who have moved from a strictly type language to PHP and who feel lost
>> without the crutch that a strongly typed language seems to provide. I
>> work faster with a dynamically and weakly typed language, so speed of
>> development is far more important to me. Any so-called bugs are detected
>> and fixed during the testing phase, so I don't want the language being
>> slowed down performing checks that I don't want.
>nosense - after 15 years PHP andmoved everything to strict_types in 2017
>(the current year) you can't accuse me that i have recebtly moved from a
>strongly typed language to PHP and felt lost all the years before
Just because a whole load of new features have been added to the language does not mean that I should use them. They are entirely optional, and I choose NOT to use them unless I am convinced that the benefits are worth the effort.>you think you work faster because you even don't realize small bugs until
>they become large enough that you sit there and debug for hours while a
>type-error with a stacktrace would have shown the mistake at the begin
>including the root cause
As I said previously, any such errors that may be caused by not using a strictly typed language are detected and fixed when I test my code. My main application has been in live use since 2008, and you can count on one hand the number of bugs which are reported each year.
>Am 31.12.2017 um 11:27 schrieb Tony Marston:
>> "Michael Morris" wrote in message
>>> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine
>> I strongly disagree. I have been using PHP since 2001 and I have never
>> used type hinting in any form whatsoever. Does it make testing more
>> difficult? No, it does not
>"I have never used type hinting in any form whatsoever" - so how can you be
>qualified at all to tell anything about the difference how it would be if
>you would have used it?
I know that it would take a HUGE amount of effort to go through my massive code base to put typehints on every function and method, but for what benefit? Unless I can measure a definite performance gain then the lack of benefits would not justify the cost.
"Dustin Wheeler" wrote in message news:A93010E9-7E52-4144-81B8-6FB6F47D85FF@ncsu.edu... <snip>
>Could the discussion be re-centered around the RFC at-hand rather than
>measuring "ego"? It seems that any thread that has both rhsoft and Tony
>involved devolves into a competition of opinion without much attempt to
>meet in the middle or understand one another.
Any attempt to make typehinting (or type enforcement as it has now become) is simply adding complications to the language which do not provide benefits to the greater PHP community, just a minority of poor coders who want the language to trap the bugs that they create in their code. There are some of us out there who are capable of writing bug-free code without type enforcement, so this RFC (and anything else connected with type hinting/enforcement) is something we don't need to use, therefore it has no benefits for us.
>Am 01.01.2018 um 10:21 schrieb Tony Marston:
>nobody is enforces anything to you
>just don't use features you don't want to use but fix your dirty attitude
>that everything you don't need should be voted down!
I never said that just because I personally won't use a proposed feature that it should be voted down. It should only be voted up if it can provide benefits to the greater PHP community and not just a few individuals. I specifically said that if you don't understand an RFC or the benefits that it is supposed to provide then you should vote it down, otherwise you could be held responsible for allowing the language to be corrupted.>"There are some of us out there who are capable of writing bug-free code"
>is a laughable argumentation anyways
Why is that laughable? You appear to want to make the language more complicated just to catch the bugs that you keep creating. Some of us have learned how not to write such buggy code in the first place.
>On 31/12/17 22:45, Michael Morris wrote:
>> Please do not quote large swaths of Tony Marston's crap. He's an
>> unrepentant liar, braggart and trouble maker that most of the list has
>> on ignore since the admins can't be bothered to do their job and kick
Just because you don't like what I write does not give you reason to call it crap.
You call me an unrepentant liar - can you point to anything that I have said that has proven to be a lie?
You call me a braggart - but at least I have a code base that is still going strong after 15 years without using any of those optional extras that have been added to the language starting with PHP 5.
You call me a trouble maker - what trouble have I made and for whom?
You should learn to keep your insults to yourself.
http://news.php.net/php.internals/101479 is the post which requested that I be banned or suspended.
This mail is going to both the systems group and internals mailing list.
I would like to request a mailing list suspension for the users email@example.com and firstname.lastname@example.org, who have recently been aggressively derailing the "Scalar Pseudo-type" thread, despite requests to moderate their participation both in that thread, and on a number of previous instances -- this is certainly not the first time these two users have converted an RFC discussion into a dick measuring contest.
If these users cannot be suspended, I would like to request specific instructions under what circumstances users can be suspended from the internals list, and what procedures need to be followed to achieve this.
This was followed by this post in which the list was informed that both of us had been banned:
Ok, both have been added to the ezmlm deny list for internals
I was never informed that I was to be banned or suspended from this list, nor for how long. It just happened. I see this as a gross infringement of the newsgroup protocol. I have complained via private email, but have not received any sort of reply.
I think the phrases "aggressively derailing" and "dick measuring" are gross exaggerations. rhsoft.net is explaining why he is in favour of this proposed change while I am explaining why I am not. What on earth is wrong with that? PHP became the Number 1 language of the internet without being strictly typed as that is more than compensated for by an increase in productivity. That is not just my opinion, it is also the opinion of Robert C. Martin who wrote about it in his article Are Dynamic Languages Going to Replace Static Languages?.
Note that not everyone was in favour of the banning. Take a look at the following posts:
Tony, you have a point in the sense that a proposed Code of Conduct -- which would have been binding on posts to lists @php.net -- provoked a fiery debate (to put it mildly) and was eventually withdrawn (http://news.php.net/php.internals/90726).
The dominant objections to the CoC did not focus on relatively apolitical cases like calling someone a habitual liar or implying non-augmented humans can write bug-free code. Yet the point remains that there is no doc whose letter or spirit can be debated, AFAIK.
As Stas points out, having a CoC for the list would not be a free speech issue in the wider sense. But in the *absence* of such a yardstick, I do agree with you that there's nothing to justify ejecting you from the list.
You obviously love using PHP and do not come here simply to bash the language (to me, that would be grounds for ejection because one would not legitimately be joining the community, in essence a spam signup). While I don't agree with your technical viewpoint in the recent flame war, perhaps you do still have the right to express it here without fear of suspension/ejection.
But consider this takeaway: while you may not realize it since you're in too deep at present, the (scalar-pseudo-type-related) war you're currently in with the other fellow has devolved into silliness. Neither of you are in my killfile; more the reverse, as it's become so over-the-top that it's funny.
I know, though, that you take this topic seriously -- but the way things are going are entirely comedic, with accusations of fabulism (I don't know where that's from) met by accusations of lack of coding skill (just as unlikely for a longtime Internals participant). Assuming you'd rather we take the technical aspects of the debate seriously, for that reason alone it's worth a reset and a rethink.
I am not in favor of anyone else deciding for me that I am not allowed to see Tony's (or anyone else's) messages on this list. I can make that decision myself, and revisit that decision myself should I choose.
If someone dislikes Tony's commentary for any reason (or no reason!) they are free to filter his messages themselves -- and then unfilter his messages when they see fit.
Paul M. Jones
I agree with Paul. It would be different if email clients that allowed filtering were expensive or hard to find. They aren't, though. Pretty much every email client not only allows filtering, but rather advanced filtering as well.
Instead of suspending users, no matter how egregious their offenses may be, let individual users filter them out as they see fit.
At first, I don't understand at all what the issue here at all. However, I'm -1 on this in general.
Who are going to decide what kind of discussion is correct or wrong?
In my opinion the whole idea of changing PHP so that it behaves just like other languages is something which should be kicked into the long grass, shown the door, or flushed down the toilet. PHP became a very popular language simply because it was different from all the others, and many programmers were able to embrace those differences and become very productive. Changes such as strict typing are not proposed because the greater PHP community actually wants it, but because a bunch of vociferous snowflakes want it to match their personal preferences. As far as I am concerned anyone who does not like the way that PHP works should stop using it and move to a language which matches their personal requirements or preferences. They should not try to change the language in a way which compromises its original design principles as this may have a detrimental effect on all the existing users.
Michael Morris tried to justify his support for this proposal by saying that he wanted it as an option, not a requirement, which solicited this reply from Rasmus Lerdorf which stated that it would still require a massive of amount of changes to the language.
On Wed, Jan 10, 2018 at 10:48 AM, Michael Morris
> On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf
> > If you stay away from trying to change a 25-year old loosely typed
> > language into a strictly typed one, then the RFC becomes much simpler.
> > -Rasmus
> I have REPEATEDLY stated that is not the goal. I don't misrepresent what
> you say, please do not do that to me.
> I want to see strict typing as an option, not a requirement.
But the point is that whether it is an option or not, it still has to touch
the zval. Which means everything changes whether the option is enabled or
not. If you store this information elsewhere, that other location has to be
checked on every zval access. Basically the work is identical to the work
required to make PHP strictly typed. Making it optional might actually be
harder because we have to build both and add more checks in that case.
The only viable place I see to store this optionally is outside the runtime
in a static analyzer like Phan (which already does this) which matches how
HHVM solved it. Of course, there may be a cleaner way to do it. But that is
why an RFC on this topic has to give a clear plan towards this cleaner
Now if the RFC was a plan for baking a compile-time static analysis engine
into PHP itself, that would be interesting. But that is a *massive* project.
This also prompted a similar response from Stanislav Malyshev in this post:
> I want to see strict typing as an option, not a requirement.
Now, you come in and say - let's make the compiler have *both* assumptions - that sometimes it's strict and sometimes it's not. Sometimes you need to track variable types and sometimes you don't. Sometimes you have type information and can rely on it, and sometimes you don't and have to type-juggle.
Having two options is not even twice as harder as having one. It's much more. So "optional" part adds all work that needs to be done to support strict typing in PHP, and on top of that, you also have to add work that needs to be done to support cases where half of the code is typed and the other half is not. And this is not only code writing work - this is conceptual design work, testing work, documenting work, etc.
Without even going to the merits of the proposal itself, it certainly looks to me like you are seriously underestimating what we're talking about, complexity-wise. I am not saying it's not possible at all - a lot of things are possible. It's just "it's merely an option" is exactly the wrong position to take.
> Create a symbol table that holds the strict variables and the types they
> are locked into. The strict keyword pushes them onto that table, the var
> keyword pulls them off. When an operation that cares about type occurs
> check that table - if the var appears there than authenticate it.
And now every function and code piece that works with symbol tables needs to be modified to account for the fact that there are two of them. Every lookup is now two lookups, and no idea how $$var would even work at all.
Something which adds complexity to the language which is only used by an extremely small number of programmers I would class as bloat, and that affects EVERY user of the language, not just those who use that feature. I am not the only one who has commented on this in the past. Take a look at the following posts:
... new syntax is hardly needed. Few, if anybody, are saying that PHP's syntax is preventing them from doing what they need to do. The argument is always that the new syntax can be useful here or helpful there - which even if we accept as true, would make the rating of these features as 'nice to have', and not 'important' let alone 'must'. Not having them is not a barrier to adoption, nor is it pushing anybody away from PHP. Plus, there's this whole theory that less is more, and in its more relevant form - more is less. So arguably, the added complexity may even hamper adoption.
It's of course a lot easier to implement a patch to the engine to add some new syntax, but that's not what the language needs. There's no need to add new stuff to PHP every year especially not at the language level, and we seem to be obsessed with that. If people focused their efforts on things that can truly move the needle, even if it took a lot longer, it would eventually pay off. Instead, we're not even investing in them - because we're in a 'vicious' yearly cycle of adding new syntax.
If you tell me that syntax like "foo() |> bar($$)" is more natural or intuitive or readily understandable to anyone with any programming and PHP background than "$fooResult = foo(); bar($fooResult); " then we indeed have exactly opposite understanding of what is natural and intuitive.
I think that overly clever is inventing cryptic syntax to save a couple of keystrokes and rearrange code in unusual pattern that looks unlike the code used to look before and resembles some other language (this time it's F#? how many languages PHP should be at once - can we get a dozen?)
I think constantly disrupting the language environment by pedantic tweaks that add BC and cognitive load but do not actually enable anything new, just move things around - is not only confusing, but harmful for the whole ecosystem.
> I agree the example code is readable, but it makes me feel the
> language is a little obsolete.
This is a mindset that I feel to be objectionable and take issue with. The idea that we have to constantly invent new syntax to replace working old one, just because old is somehow "obsolete", even though new syntax's only advantage is doing things slightly differently - it seems to me an exactly wrong idea. It may be exciting to invent new syntaxes - but for an industry programmer that has other priorities, like code stability, compatibility, maintainability, etc. "new" is not a positive things unless it gives them measurable or at least perceivable improvement on these qualities.
Existing syntax is not "obsolete" and works completely well. New syntax invents new magic variables (thing that never existed in PHP before, adding a whole new conceptual level to PHP mental model) and a new way of doing the same thing that is already perfectly doable right now with exactly the same effort. I personally strongly object to such changes.
There is a lot of ways in which PHP needs improvement, but right now I think inventing more syntax tricks in not one of them. Even in syntax department, PHP has areas where we could use improvement (e.g. to name named arguments as one) but this one doesn't seem to do much but doing the same thing in a shiny new way. Read: less comprehensible for people not watching "latest new 20 syntaxes PHP invented in the next version", more things to learn to read PHP code, more things to maintain, more complexity for the language that once was supposed to be accessible to beginners.
This is the price of all innovation, but sometimes benefits are much greater and the price is completely warranted. I do not feel this is the case here.
Rather than piling on language features with the main justification being that other languages have them, I would love to see more focus on practical solutions to real problems.
> A language that is usable primarily by beginners will only be useful for beginners. Non-beginners will shun it, or simply grow out of it and leave.
> A language that is usable only by PhDs will be useful only for PhDs. Beginners won't be able to comprehend it.
> A language that is usable by both beginners and PhDs, and can scale a user from beginner to PhD within the same language, will be used by both.
> Doing that is really hard. And really awesome. And the direction PHP has been trending in recent years is in that direction. Which is pretty danged awesome. :-)
I would argue that PHP was already doing that almost since inception. I think we have ample evidence that we've been seeing a lot of different types of usage - both beginners' and ultra advanced going on in PHP for decades.
I would also argue that in recent years, the trending direction has been focusing on the "PhDs", while neglecting the simplicity seekers (which I wouldn't necessarily call beginners). Making PHP more and more about being like yet-another-language, as opposed to one that tries to come up with creative, simplified ways of solving problems.
Last, I'd argue that a language that tries to be everything for everybody ends up being the "everything and the kitchen sink", rather than something that is truly suitable for everyone.
We also seemed to have dumped some of our fundamental working assumptions - that have made PHP extremely successful to begin with:
- Emphasis on simplicity
- Adding optional features makes the language more complex regardless of whether everyone uses them or not
It does seem as if we're trying to replicate other languages, relentlessly trying to "fix" PHP, which has been and still is one of the most successful languages out there - typically a lot more so than the languages we're trying to replicate.
As a whole, people don't realize that PHP does not need fixing. I'm NOT saying it's perfect and that it cannot be improved - of course it can - but I am saying that it's not broken; In fact, it's remarkably successful the way it is, and in fact, we have no evidence that since the RFC process was embraced and language-level features started making their way into it on a much faster pace - anything changed for the better in terms of popularity. People arguing to introduce radical changes to it (and making PHP a lot more of a typed language, optional or not, absolutely constitutes a radical change) should realize that it's not risk-free, and given that they tend to be advanced, top 5-10% coders - that they're catering not to just coders like them, but also the rest of the 90-95% of the world.
Introducing new syntax to PHP, with new semantics, adds a lot of cognitive load no matter how we spin it. Given how easy it is now to propose an RFC, and the general bias-for-change of internals, we're now doing this at a remarkable pace, with very few checks and balances. Every feature is evaluated context-free, on whether it's useful in some cases yes/no, and without taking into account in any way that 'less is more'. Just see how much discussion we're seeing here about open questions in this typing discussion. Whatever decision we take in each and every one of these discussions - means added cognitive load, as by definition that decision wasn't an intuitive one, but one that required much discussion, debate and sometimes compromise in order to reach.
Creating a generic feature that makes sense in a handful of situations, while at the same time being one that's waiting-to-be-abused in the vast majority of the rest (or as Tom put it, a 'footgun') is a pretty poor bargain IMHO.
It also seems to me that some measure of support for these features comes from the "coolness factor" - look, ma, we have complex types, just like those cool academic languages everybody is excited about! And I don't deny the importance of language having some coolness factor and getting people excited, but in this case I think it's a bit misplaced - in *PHP*, I believe, most of the use for this feature would be to hide lazy design and take shortcuts that should not be taken, instead of developing robust and powerful type system.
Now, PHP's origins are not exactly in "powerful type system" world, so it's fine if some people feel not comfortable with this rigidity and having to declare tons of interfaces, and so on. This is fine. But inserting shortcuts in the system to make it "strict, but not strict" seems wrong to me.
Nobody does that - that is not the *reason* for rejecting anything, it's just a marginal side note. I just try to turn our attention to the fact that not all cool features that exist in other languages can, or should be, in PHP, even if they do look cool. And I try to share my worry that some of the things being proposed include seriously complicating PHP's conceptual model while serving at best infrequent use cases. Simplicity is a virtue, and we have already lost significant amount of that virtue. Maybe we gained more - I don't know yet, as most of our user base isn't even on 5.5 by now. But it does worry me that we are not only losing it - we seem to be actively trying to get rid of it.
There used to be a rule of thumb on internals that finding some use cases for a given language-level feature hardly constituted grounds to add it. It had to be useful on a very wide range of situations, in order to be worth the trouble of implementing it, maintaining it, but most of all - of adding complexity layers to the language (both in terms of cognitive burden and likelihood of misuse). Now, the whole 'complexity' factor is almost ignored. Focus is on finding a use case or a handful of use cases where the feature can be useful - a task which is almost always doable - especially when borrowing features from other languages.
Regardless, at least as far as I can tell, it seems as if on internals, the sentiment is the 180 degrees opposite from Paul's statement. It's as if we feel PHP's syntax is never ever enough, and is in desperate need of extension - even though some amazingly advanced apps have been and are written on top of it. I'm not saying we should halt adding new syntax, but I am saying that (a) the pace at which we're discussing new syntax is mind boggling and way too fast, and (b) the bars we seem to be happy with in what constitutes 'need' are extremely low.
> In general, improving the type system provides a much more interesting and
> practical playground for any kind of tool that would rely on static
That's my point - "more interesting playground" does not sound like a reason enough to mess with the type system of the language used by millions. This sounds like a good description of a thesis project or an academic proof-of-concept language, not something a mature widely-used language prizing simplicity should be aiming for. I completely agree that *if* we added a ton of shiny things into PHP then there would be a lot of interesting stuff to play with. I am saying that is not reason enough to actually add them.
There are a lot of additions that may improve PHP in many practical ways. I just think right now there's a bit too much focus on adding new syntax that adds much more complexity than it's worth. I'm not against adding new syntax per se, I guess I just want more necessary capabilities enabled per complexity added ratio.
> This would mean, by an large, that people had tried a more recent version of
> PHP and found that their code was incompatible. I think on the contrary that
> they haven't tried because they have little motive. A lot of running apps are in
> maintenance mode with no significant investments in new code, without which
> it's easier to take the attitude that it's not broken so don't mess around with it.
It's more complicated than that - people don't actually have to try and upgrade in order to know (or think they know) that they'll have to invest time and efforts in getting their code to run on a new version. They guess as much.
That said, I don't think the issue with shiny new things is that they introduce incompatibilities. They rarely do - I think the biggest source of incompatibilities we have is removal of deprecated features and not introduction of new ones. Shiny new features have other issues - increased cognitive burden, increased code complexity, etc. - but typically introduction of incompatibilities is not one of them.
However, we can learn that the attractiveness of new features in PHP is not very high - or we'd see much faster adoption of new versions (which also leads me to believe that we're spending too much effort on the wrong things). I think we're going to see much faster adoption of 7.0 - but in my experience at least, it's predominantly the increased performance and reduced memory consumption that gets people excited - the new features are secondary if they play any role at the decision.
It is obvious to me from reading these posts that not everyone agrees that every proposed change to the language is a good idea, so why have I been banned from criticising such changes? Is this group populated with snowflakes who cannot handle criticism?
© Tony Marston
1st February 2018