On January 2nd of this year I was banned from participating in the php.internals newsgroup. This was because somebody did not like what I said, they complained in this post, and without further ado I was banned from the list in 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:
Do not post inappropriate content.
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.
Do not use profane language.
This includes obscenities, vulgarities 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.
Attack the message, not the messenger.
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.
The purpose of this newsgroup is to discuss proposed changes to language and obtain the opinions of others, and it should be obvious to anyone that those opinions can be many and varied. This is what Sara Golemon said in this post:
"hurt" is subjective here, and for every X participants to this thread
you'll get X+1 answers on what that means. :p
Some of these opinions may support the proposed change, some will oppose it. Some may say that it goes too far while others may say that it does not go far enough. The important thing to note is that anyone should be able to express any opinion on the topic being discussed without being told "You are not allowed to express an opinion which is unpopular with members of this group". This principle was echoed in this post from Stanislav Malyshev:
And don't get me wrong, having an opinion, including one different from any other people in the community, is completely fine.
So what exactly was my "crime"? Did I violate the rules and post something with inappropriate content? Did I use foul language? Did I attack someone personally? Or did I merely say something that someone did not like? If you look at the original complaint you will see that it contains expressions such as "aggressively derailing" and "a dick measuring contest". If you look in this post you will see that I am also accused of being "an unrepentant liar, braggart and trouble maker". You should note that none of these complaints points to a particular post which broke a particular rule, it merely says "I don't like what he says, so he should be banned from saying it".
As for the accusation of "aggressively derailing" you should see from the posts to which I refer below that all I am doing is contradicting the opinions of a person known as lists@rhsoft.net. He cannot understand why anyone would vote against this change while I suggest that unless you can see the benefits of the change you should vote it down. He seems to think that changing his code to implement type enforcement (static typing) has made him a better programmer while I prefer the speed and flexibility that dynamic typing in PHP has always provided. He is arguing for the proposed change while I am arguing against, so what is wrong with that?
As for the accusation of "dick measuring" where did this come from? lists@rhsoft.net says that he prefers to write code with strict typing turned on while I (like many others) am using a code base which was started many years ago before the option even existed. I refuse to update my code to incorporate this feature (and other features like it) for several reasons:
The feature is optional, not mandatory.
It would take a considerable amount of time to update and test my code, but as there would be no measurable benefit I deem the exercise be be not cost effective but a complete waste of time. Unless the result is an improvement which is visible to the users of my software then where exactly is the improvement?
By saying that I have code which I started way back in the days of PHP 4 which is now being sold all over the world I am not bragging, I am simply saying that I have a mature (some would say "legacy") application which is still being used by paying customers, and being sold to new customers, to this day. I am not stuck with using PHP 4 as I have migrated my growing code base through all versions of PHP 5 up to version 7 with the minimum of effort simply by ignoring most of the changes and additions. Apart from dealing with those features which were deprecated I have ignored 99% of the new features simply because I cannot find a use for them. Changing my code to do what it already does but only differently is not my idea of a cost-effective change. My code works because of the benefits of dynamic typing, and converting it to use static typing would be an expensive waste of time. Show me a solution which uses less code or runs faster and I will take note, otherwise I will stick to spending my time in adding features that my paying customers will appreciate.
In response to the message which called for my suspension from the newsgroup I replied with this post:
You may not like what I have to say, but that is no reason to ban me from
saying it. I believe in democracy and free speech, and by banning or
suspending me you are effectively banning the right to free speech. As a
long time user of PHP I earn a living by selling my software all over the
world, so I have a vested interested in seeing that the language is not
changed in a detrimental way. I have seen too many RFCs which do not provide
genuine benefits for the greater PHP community, instead they pander to the
personal whims of a vociferous minority who want to change the language to
suit their personal coding style, or to fit their idea of purity.
As for all this so-called "dick measuring" if you bothered to read the posts
you should see that I try to keep my comments as civil as possible, but when
some prat attacks me personally on this list then I have the right to defend
myself. You should focus your attention of those who make personal attacks
and not those who are defending themselves.
> You may not like what I have to say, but that is no reason to ban me
> from saying it. I believe in democracy and free speech, and by banning
> or suspending me you are effectively banning the right to free speech.
This has nothing to do with free speech. You are welcome to exercise
your rights to free speech any way you like. But you don't have the
rights to be in the list if the community does not want it and if your
behavior is unhelpful and un-conductive to the discussion. In that case,
you'd have to exercise your rights to free speech somewhere else. I am
sure the world of democracy will survive this. This, of course, is not
specific to anybody personally - anybody who does not think they can
abide by the rules of civilized discussion on the list could exercise
their free speech rights in other venues, of which there's always an
abundance. Polite, substantial, productive discussion is welcome - we do
not have any barriers or prerequisites for participation. Noise is not
welcome.
Nobody wants to see the noise on the list, and nobody wants to see yet
more noise by discussing who started it and who kicked or spat first and
who broke whose sand castle. Everybody must behave, or take a time out
and relax and think about more pleasant matters until they are able to
be polite again. Again, not about anybody personally, applies to all.
--
Stas Malyshev
Please note his statement "you don't have the rights to be in the list if the community does not want it". This does not specify that I have to break a published rule in order to be banned, all that is required is to say something that "someone does not want". Democracy is dead! Free speech is dead! Long live the snowflakes!
By "your behavior is unhelpful and un-conductive to the discussion" I assume he means "non-conducive", but that is a far cry from posting inappropriate content, foul language or personal attacks. I'm afraid "non-conducive" is too vague a term and can mean different things to different people. I repeat, can you point to any specific rule in the group's Code of Conduct which I broke?
If anyone posts an argument in this newsgroup, either in favour or against the proposed change, surely it is perfectly valid to challenge that argument? If an argument goes unchallenged then its author can assume that it has no critics and is the winning argument. By preventing me (or others) from challenging such arguments you are effectively destroying the purpose of this newsgroup which is to gather opinions both for and against the proposed change. Some of the opinions may be unpopular, but that is only to be expected in a proper grown-up debate.
>This has nothing to do with free speech. You are welcome to exercise
>your rights to free speech any way you like. But you don't have the
>rights to be in the list if the community does not want it and if your
>behavior is unhelpful and un-conductive to the discussion.
I can understand you banning or suspending someone because of personal abuse
or offensive/foul language, but banning someone simply because you don't
like what they say is a step too far. If this is allowed to happen then soon
you will get to stage where someone says "Anyone who disagrees with my point
of view is an idiot and should be banned from this list".
> In that case,
>you'd have to exercise your rights to free speech somewhere else. I am
>sure the world of democracy will survive this. This, of course, is not
>specific to anybody personally - anybody who does not think they can
>abide by the rules of civilized discussion
Define "civilised". Anything which does not use foul or abusive language
should be regarded as civilised. Expressing an unpopular opinion is still
civilised. Anyone who tries to ban unpopular opinions should not be welcome
on any list as this prevents proper discussion.
> on the list could exercise
>their free speech rights in other venues, of which there's always an
>abundance. Polite, substantial, productive discussion is welcome - we do
>not have any barriers or prerequisites for participation. Noise is not
>welcome.
There are too many delicate people on this list who regard any opinion which
differs from theirs as "noise".
>Nobody wants to see the noise on the list, and nobody wants to see yet
>more noise by discussing who started it and who kicked or spat first and
>who broke whose sand castle.
I suggest you start by aiming your wrath at those who move off-topic and
start making personal attacks instead of those who defend themselves from
such attacks.
--
Tony Marston
Snowflakes
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 up the behind. 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
>> and
>> 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
>> silly.
>>
>> 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
>> bad!"
>> Entirely ignoring the flip side, which is int || string (valid use cases)
>> and
>> Foo && Bar (many many valid use cases)
>
>well, that explains why the same person which has a usecase for a "scalar"
>pseudo-type down-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:4b55eed1-8656-ff70-e4e9-ad5e40213405@rhsoft.net...
>>>
>>> Am 29.12.2017 um 00:21 schrieb Larry Garfield:
<snip>
>> 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
>
>not up
>not down
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:f48976dd-589f-e88e-37ba-38096c3a3602@rhsoft.net...
<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:
<snip>
>>
>> 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.
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.
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 !!!!
"Michael Morris" wrote in message
news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com...
>
>On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine wrote:
>
>>
>> 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
>> benefits.
>
>well my codebase dates back to 2002 but is stricted-typed in the meantime -
>and now?
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
>> news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com...
>>>
>>> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine
>>> wrote:
<snip>
>> 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.
>
>Thanks. =
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:
<snip>
>
>breaking news:
>
>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
>> him.
>
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.
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
tonymarston@hotmail.com and lists@rhsoft.net, 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.
Regards,
Nikita
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
Rasmus Lerdorf
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.
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?
--
Yasuo Ohgaki
Footnote
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 wrote:
> On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf
> wrote:
>
> > 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
implementation.
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.
-Rasmus
This also prompted a similar response from Stanislav Malyshev in this post:
> I want to see strict typing as an option, not a requirement.
You seem to be under impression that this somehow makes things easier.
It does not. To explain: let's say you design a strictly typed language,
like Java. The compiler knows which variable is of which type at every
point, and if it's not clear for some reason, it errors out. You can
build a compiler on top of those assumptions.
Now let's say you design a loosely typed language, like Javascript. The
compiler knows variables have no types, only values have it, and builds
on top of that (as in, it doesn't need to implement type tracking for
variables).
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.
Do you really think this just made things *easier*? To implement both
Java and Javascript inside the same compiler, with radically different
types of assumption? If you have desire to answer "yes", then a) please
believe me it is not true b) please try to implement a couple of
compilers and see how easy it is.
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.
--
Stas Malyshev
smalyshev@gmail.com
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.
<snip>
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.
Zeev Suraski
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?