-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This is all generic advice which is nice and well if we would be
designing language anew. As it is, we are not - we already have
lots of code using var. For code not using var, removing var does
not do anything. For code using var, removing var means no upgrade.
It is unnecessary breakage for the sake of feeling that we follow
the advice somebody put on the website. That feeling is not worth
very real work that people would have to do to achieve what they
already have now.
I would not say that the information that the Nielsen Norman Group
puts on their website falls in the category of "somebody putting
something on a website".
https://www.nngroup.com/about/
https://en.wikipedia.org/wiki/Nielsen_Norman_Group
Additionally there is other scientific work that supports what I
stated, e.g.:
http://www.eecs.yorku.ca/research/techreports/1999/CS-1999-08.pdf
Yes, PHP has aliases. Nothing wrong with that, provided you bother
to look in the manual once, and then you are enlightened forever.
[...] It only wastes their time if they don't read the manual but
instead chat on Stackoverflow :) Which I have nothing against, it's
just not the reason to introduce BC breaks because somebody asked a
question about it.
A lot of things are wrong with this (see above reasons) and the RTFM
argument is a thought-terminating cliché. Duplication harms the
overall design of a language, it results in a maintainability burden
for the developers, hell, even this discussion is only happening and
wasting our time due to these duplications.
I am not saying that your arguments about breaking changes and more
complicated upgrades for a small user base are wrong; I am saying that
these are weak arguments compared to the scientific facts and the
overall progress for the PHP programming language.
After all, we are talking about an upgrade path of several years.
Anyone should be able to adopt by that time and they probably have
other problems until then with their old systems.
Richard "Fleshgrinder" Fussenegger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWx3V1AAoJEOKkKcqFPVVrc4cQAINj1zV9lXZAaMGCHrTWjtK8
RC04cjsYzG0XMUa+8wexxmQCkgMSBkRLOWaDa8VyCTbUabHSHi70Zf2mj0qyFQcM
rv6DxYVorWDx5ty0odnv+8vgnBra2LHc4OntRGe0GWsM0Z4aQ2QfriMzaAt+diBn
gSCC5yPxfE3jjqi4TYuT7eshQ3Kz0SeTAarY19fApi7f80JDwChHeerUiGFMZE3x
GUUJi02NeKUnfqliAM0k9VGgAP4qGjmPiVFWjoQKZ9rYPvGRqztLO7c2V+65DlY7
He/vibZDsmvbQZXVcszi2cWNhhzn43XXTwF+jiFuKhlXNLwJJDcJbanfJtQJpEiI
MB5adPIROxTtgJdrOBTZ8PMT0IKk4P1i19IUqL6sne4AJtcn3UYEoNUiUiO2TJfP
1zgNfTOAnlmf14jtij2g1wj8XPscjA38zo/2QWzGxadqgsQX6m2NgqlzMV+D6WbH
C5KToC5EiF/WNWd/vsViYLCEPusuFzHDx8qWFH0ZiNBdhsMTX6yB+Rt5mKZ2hauY
o4+5z4308JPrI8Ao6oroVJ3TqiGN7R8nWUlE3J5/v9psgYVdFMyIe1vXmhtROBo9
N382klHxZHVISis0290HnmdlP8t/g6AevdF3uGHbLEUA8Jzs9LwzrAlUtSBkCNlx
3Yeby46U03XVb3zCZzm3
=1iGy
-----END PGP SIGNATURE
Hi!
I would not say that the information that the Nielsen Norman Group
puts on their website falls in the category of "somebody putting
something on a website".
I think you are trying for an argument of "I agree with some guys that I
consider being an authority so you should agree with me". It works only
if these guys are established as unerring God-like authority and they
spoke on the particular case we are discussing. I don't think either of
this is true. So let's dispense with authority appeals for now.
A lot of things are wrong with this (see above reasons) and the RTFM
argument is a thought-terminating cliché. Duplication harms the
It is cliche because it's true. You do not need any deep thought to know
what aliases are, there is no deep insight to be had there, there is
just a thing to know - these two things are two ways of saying the same.
It's not really hard or "confusing".
overall design of a language, it results in a maintainability burden
for the developers, hell, even this discussion is only happening and
wasting our time due to these duplications.
Wait, so the fact of you arguing for removal of aliases is the proof of
you being right? That's neat.
Stas Malyshev
smalyshev@gmail.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I think you are trying for an argument of "I agree with some guys
that I consider being an authority so you should agree with me". It
works only if these guys are established as unerring God-like
authority and they spoke on the particular case we are
discussing. I don't think either of this is true. So let's dispense
with authority appeals for now.
No, I just wanted to remark that it is not just an opinion based blog
post that I was referring to and that the link points to a valid
argument.
It is cliche because it's true. You do not need any deep thought to
know what aliases are, there is no deep insight to be had there,
there is just a thing to know - these two things are two ways of
saying the same. It's not really hard or "confusing".
Old cellphones were shipped with a user manual that contained precise
instructions on how to deal with the installed OS.
New smartphones do not contain a user manual because the OS is so
intuitive that nobody has a need for them.
I never read the manual for any of those old cellphones and was still
able to achieve my goals. However, other people apparently had
problems and that is why a manual was shipped along with them.
Do not apply your intelligence and knowledge on others and approach
topics by weighting pros and cons and not opinions.
Wait, so the fact of you arguing for removal of aliases is the
proof of you being right? That's neat.
No and I did not imply this, again, we are collecting arguments and I
am on the pro side so I contribute pro arguments. Your comments on the
other hand are passive aggressive and do not contribute to the overall
discussion because you simply say no and do not even allow a
discussion. I received your actual arguments and I acknowledge them
but I personally consider them weak (if that is true cannot be
judged by either of us) and I personally think that the arguments
others and me brought to the table are more extensive and thus add
more to the pro side even if your arguments count fully on the con side.
Richard "Fleshgrinder" Fussenegger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWx4SWAAoJEOKkKcqFPVVraPcQAJ7h/R4qmB/BhIgsVIWUVdYY
TrMffjrO1Mz8DaFhVsjjDhjj2oQ9OHvcGOTZ/WRVsMRxO6wh1C3QCuQFrE/uCO4z
2oLV54MRcs4DyNUzIflS/iPrpfLI1aplQZDlDhB1Q470rr7sj3p69dqAhnHEIQdE
jD4DePDIRIe4b7tfOYfC4HF3mGXyufisiLPGXrYxAEKNmy+4DewnhnN7nnP2Zst4
gXxzDtzNlQbQS/R3TFu8xPZZ4S8e71wn0KdNhSULgM5m4rDQBGFisgHuJe8eLTxJ
9Y0XLNZh4L7uUcAyfi6yqZ61krhvZcm2J234xxgS6425NKyQ+qAI7kWshv2dNZdi
Xwm2asgOOmwmNpXhO2JOJpf+1K459nL8k7Po2qckdFqD332iEkEKirNZp/YpDuzx
gClz4oriS3ygH9AVgvy+EtZ+dUkzdLxXFWtN6MX1UzQ1zYRc1gIIgiTvLuoraupJ
d2Qp4ZbiFEtS3YQm+lInpDgarIKGqNQ1zXMEnRogENy8UC0FtzYP3n0Sx+J08Sxd
CeQ7/9aLneONFOTKYK/Ea+3YyXVjBWtq7JJqVZdwearkqaUn5+TTNSczAyfV968I
GB96lk2R4voTfrD9nTmrPot5FPZA/acGKPFpvSQNFjNi/AG/UNR+WTsK4JnWpq2I
gUE4PXwx3AFxZBHCh5Zg
=HMPP
-----END PGP SIGNATURE
Hi!
Old cellphones were shipped with a user manual that contained precise
instructions on how to deal with the installed OS.
You don't really need a whole manual to know two things are the same.
You only need one line from that manual. It's a minimal effort, well
within expected of what may be required of a person learning new
language - I think reading a couple of lines is not excessive.
New smartphones do not contain a user manual because the OS is so
intuitive that nobody has a need for them.
Or so the marketing team would love us to believe ;)
If you think a programming language somehow can be so "intuitive" that
you never need to actually know anything to use it - you're in for a
somewhat unpleasant surprise, unfortunately. We can make learning it
easi-er - and having aliases is part of it - but we can never make it so
easy as never having to actually touch the manual or any other learning
media.
discussion because you simply say no and do not even allow a
That is not correct. I say no with substantiation - namely, that
removing aliases would cause code breakage and would not add anything to
actual functionality. Your argument seems to be generic "redundancy is
bad" argument, and treating somebody asking questions on stackoverflow
as evidence that we have a problem. Both are wrong - redudancy can be
both good and bad, and in our case I think it is good because it lets
people continue to rely on their previous experience both in PHP and
other languages. Also, somebody asking questions is not a reason to
change the language - there always will be people asking questions, and
that's fine as long as we have good easily accessible answers, which we do.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
Hey there. :)
Old cellphones were shipped with a user manual that contained precise
instructions on how to deal with the installed OS.You don't really need a whole manual to know two things are the same.
You only need one line from that manual. It's a minimal effort, well
within expected of what may be required of a person learning new
language - I think reading a couple of lines is not excessive.New smartphones do not contain a user manual because the OS is so
intuitive that nobody has a need for them.Or so the marketing team would love us to believe ;)
If you think a programming language somehow can be so "intuitive" that
you never need to actually know anything to use it - you're in for a
somewhat unpleasant surprise, unfortunately. We can make learning it
easi-er - and having aliases is part of it - but we can never make it so
easy as never having to actually touch the manual or any other learning
media.
My example seems to be bad or to abstract. I am not thinking that a
programming language can become that intuitive; the contrary.
Programming languages are already so complicated that it is harmful to
start littering them with thousands of ways to achieve one thing. It
also makes users uncertain when the manual entry says that something is
an alias. They fear that it might be removed. They create project rules
that forbid the usage of aliases ...
Science shows that it is harmful, let's clean it up!
discussion because you simply say no and do not even allow a
That is not correct. I say no with substantiation - namely, that
removing aliases would cause code breakage and would not add anything to
actual functionality. Your argument seems to be generic "redundancy is
bad" argument, and treating somebody asking questions on stackoverflow
as evidence that we have a problem. Both are wrong - redudancy can be
both good and bad, and in our case I think it is good because it lets
people continue to rely on their previous experience both in PHP and
other languages. Also, somebody asking questions is not a reason to
change the language - there always will be people asking questions, and
that's fine as long as we have good easily accessible answers, which we do.
In Germany we say "jain" (yes and no). You are right that you brought up
that argument and I acknowledged it but put it like you did not bring up
one in my last message. I am sorry for that. You are not right that
Stackoverflow is my only argument. I provided scientific proof that
those aliases harm the design of a language and a more general proof in
regards to usability and duplication.
People often rely on side effects but that does not mean that this is a
good practice. We are talking here about a feature that was added in PHP
4 in order to support OO coding. The feature is not used anymore by a
major part of the community and it is considered best practice to use
the proper access modifiers (namely public in this case). We are talking
about a future version of PHP (probably 8) and not about removing it
from PHP 4, 5, nor 7.
There is only one constant in life and that is change. Insisting on not
changing means to stop; especially in a context of software development
and engineering (which actually implies constant change in its own name).
--
Richard "Fleshgrinder" Fussenegger
wrote in message news:56CDEB49.5040006@fleshgrinder.com...
Hi!
Hey there. :)
Old cellphones were shipped with a user manual that contained precise
instructions on how to deal with the installed OS.You don't really need a whole manual to know two things are the same.
You only need one line from that manual. It's a minimal effort, well
within expected of what may be required of a person learning new
language - I think reading a couple of lines is not excessive.New smartphones do not contain a user manual because the OS is so
intuitive that nobody has a need for them.Or so the marketing team would love us to believe ;)
If you think a programming language somehow can be so "intuitive" that
you never need to actually know anything to use it - you're in for a
somewhat unpleasant surprise, unfortunately. We can make learning it
easi-er - and having aliases is part of it - but we can never make it so
easy as never having to actually touch the manual or any other learning
media.My example seems to be bad or to abstract. I am not thinking that a
programming language can become that intuitive; the contrary.
Programming languages are already so complicated that it is harmful to
start littering them with thousands of ways to achieve one thing. It
also makes users uncertain when the manual entry says that something is
an alias. They fear that it might be removed.
That fear is unjustified. They need to learn the difference between
"duplicated" and "deprecated". Unless a function is marked as "deprecated"
it cannot be removed.
They create project rules that forbid the usage of aliases ...
We cannot stop stupid people from creating stupid rules.
Science shows that it is harmful, let's clean it up!
Your "proof" is not scientific, it is just personal opinion. There is no
evidence that use of the "var" keyword is harmful in any way.
discussion because you simply say no and do not even allow a
That is not correct. I say no with substantiation - namely, that
removing aliases would cause code breakage and would not add anything to
actual functionality. Your argument seems to be generic "redundancy is
bad" argument, and treating somebody asking questions on stackoverflow
as evidence that we have a problem. Both are wrong - redudancy can be
both good and bad, and in our case I think it is good because it lets
people continue to rely on their previous experience both in PHP and
other languages. Also, somebody asking questions is not a reason to
change the language - there always will be people asking questions, and
that's fine as long as we have good easily accessible answers, which we
do.In Germany we say "jain" (yes and no). You are right that you brought up
that argument and I acknowledged it but put it like you did not bring up
one in my last message. I am sorry for that. You are not right that
Stackoverflow is my only argument. I provided scientific proof that
those aliases harm the design of a language and a more general proof in
regards to usability and duplication.
Again, your "proof" is NOT scientific, it is merely a personal opinion.
People often rely on side effects but that does not mean that this is a
good practice. We are talking here about a feature that was added in PHP
4 in order to support OO coding. The feature is not used anymore by a
major part of the community and it is considered best practice to use
Where is your proof? You say "not used by a major part of the community"
which means that it is still being used by a minor part, but exactly how
"minor"? I don't see why I should be forced to make a totally unnecessary
change to vast numbers of my scripts just to fall in line with your personal
opinions.
the proper access modifiers (namely public in this case). We are talking
about a future version of PHP (probably 8) and not about removing it
from PHP 4, 5, nor 7.
There is no reason to remove it from ANY version of PHP. It does no harm, it
would take effort to take it out and amend the documentation, but for what
benefit?
There is only one constant in life and that is change. Insisting on not
changing means to stop; especially in a context of software development
and engineering (which actually implies constant change in its own name).
Change for change's sake is never a good idea. I have been developing in
several languages for 40 years, and I can tell you point blank that while
programmers expect new features to be added they do NOT expect old features
to disappear. Once a piece of code has been written and has proved to work
as designed it is expected to work with all future versions. The only
exception to this is to plug holes in security. This is called "forwards
compatibility", and was a major selling point of all my previous languages.
If developers fear that they will have to rewrite huge swathes of code each
time a new version is released they will quickly give up and move to a
"professional" language which offers long term stability.
--
Tony Marston
Science shows that it is harmful, let's clean it up!
Your "proof" is not scientific, it is just personal opinion. There is no
evidence that use of the "var" keyword is harmful in any way.
I think the diverged from talking about the "var" keyword in particular
towards duplication in general a long time ago. However, I still think
that DRY is empirically proven.
Where is your proof? You say "not used by a major part of the community"
which means that it is still being used by a minor part, but exactly how
"minor"? I don't see why I should be forced to make a totally
unnecessary change to vast numbers of my scripts just to fall in line
with your personal opinions.
It is true that I did not provide this proof because Colin O'Dell did
claim this fact in the very initial message of this thread and I believe
him.
There is no reason to remove it from ANY version of PHP. It does no
harm, it would take effort to take it out and amend the documentation,
but for what benefit?
I stick to the main reason I gave, DRY. Duplication needs to be managed
and removing it removes the maintenance burden.
Change for change's sake is never a good idea. I have been developing in
several languages for 40 years, and I can tell you point blank that
while programmers expect new features to be added they do NOT expect old
features to disappear. Once a piece of code has been written and has
proved to work as designed it is expected to work with all future
versions. The only exception to this is to plug holes in security. This
is called "forwards compatibility", and was a major selling point of all
my previous languages. If developers fear that they will have to rewrite
huge swathes of code each time a new version is released they will
quickly give up and move to a "professional" language which offers long
term stability.
I did not say that we should change for change's sake. I only stated
that trying hard to prevent change by all means is wrong. Again, this
diverged away from the "var" keyword alone a long time ago and was more
a general statement.
TL;DR Thanks for yet another aggressive/provocative email, I stick to my
+1. However, you all have valid points to keep it.
--
Richard "Fleshgrinder" Fussenegger
Hi all,
Science shows that it is harmful, let's clean it up!
Your "proof" is not scientific, it is just personal opinion. There is no
evidence that use of the "var" keyword is harmful in any way.I think the diverged from talking about the "var" keyword in particular
towards duplication in general a long time ago. However, I still think
that DRY is empirically proven.
I'm 0 for this change. Although it's close to +1.
Those who are willing to remove "var" from PHP should write conversion
script that scans PHP scripts and converts "var" to "public". Then there
will be more supporters for removing "var". We have tokenizer. It
should not be difficult. Tokenizier may be extended to make this kind
of conversion script easier. i.e. Get offset of tokens also. If there
is offset, writing conversion script is trivial. It seems some work is required
to return offset, though.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
wrote in message news:56CF439F.2040506@fleshgrinder.com...
Science shows that it is harmful, let's clean it up!
Your "proof" is not scientific, it is just personal opinion. There is no
evidence that use of the "var" keyword is harmful in any way.I think the diverged from talking about the "var" keyword in particular
towards duplication in general a long time ago. However, I still think
that DRY is empirically proven.Where is your proof? You say "not used by a major part of the community"
which means that it is still being used by a minor part, but exactly how
"minor"? I don't see why I should be forced to make a totally
unnecessary change to vast numbers of my scripts just to fall in line
with your personal opinions.It is true that I did not provide this proof because Colin O'Dell did
claim this fact in the very initial message of this thread and I believe
him.
So just because someone else states an opinion you are prepared to convert
this to a "fact"?
There is no reason to remove it from ANY version of PHP. It does no
harm, it would take effort to take it out and amend the documentation,
but for what benefit?I stick to the main reason I gave, DRY. Duplication needs to be managed
and removing it removes the maintenance burden.
What maintenance burden? How much time is taken up by the language
developers in maintaining the code that deals with the "var" keyword? How
many bugs have been reported on this word since PHP was released?
Change for change's sake is never a good idea. I have been developing in
several languages for 40 years, and I can tell you point blank that
while programmers expect new features to be added they do NOT expect old
features to disappear. Once a piece of code has been written and has
proved to work as designed it is expected to work with all future
versions. The only exception to this is to plug holes in security. This
is called "forwards compatibility", and was a major selling point of all
my previous languages. If developers fear that they will have to rewrite
huge swathes of code each time a new version is released they will
quickly give up and move to a "professional" language which offers long
term stability.I did not say that we should change for change's sake. I only stated
that trying hard to prevent change by all means is wrong.
You are contradicting yourself. On the one hand you are saying that change
for change's sake is wrong, and on the other hand you are saying that we
should not block change for any reason.
Again, this
diverged away from the "var" keyword alone a long time ago and was more
a general statement.TL;DR Thanks for yet another aggressive/provocative email, I stick to my
+1. However, you all have valid points to keep it.
--
Tony Marston