Breaking backwards compatibility - good or bad?

[tony]

If you have any PHP scripts which will not work in the current releases
due to breaks in backwards compatibility then take a look at
http://www.tonymarston.net/php-mysql...verything.html and see if
you agree with my opinion or not.

Tony Marston
http://www.tonymarston.net

[Wayne]

On 20 Dec 2005 13:52:17 -0800, "Chung Leong"
<ch***********@ hotmail.com> wrote:

I guess I'm not the only one who's unhappy about the direction that PHP
is going. It's larger issue that goes beyond backward compatibility. I
see it as a conflict between two points of view: an academic's vs. an
engineer. An engineer sees a problem and tries to solve it. The
outcome is what matters, while aesthetics and principles are secondary.

I don't agree that an engineer's don't care for aesthetics! In fact,
the products with the best aesthetics are often considered good
engineering.

But I do see a conflict between "solving a problem" and doing it "the
PHP way". I loved the early years of PHP (after switching from ASP)
because each new revision would include some feature I desperately
wanted in the previous version. There were solving problems as fast
as I was coming up with them.

Lately, things have been leaning away from solving problems and more
towards to trying to do things "the PHP way" -- whatever that is. For
example, I want type-hints for all the variable types so I don't have
to double check the parameters to my functions are, for example,
actually integers! That would be USEFUL! But that feature is ignored
because it's not "PHP like".. what the hell. So we have to write
type-checking code over and over because they don't want to pollute
the language with a useful feature? That's far from the only example.

I think PHP5 was a good step in the right direction in principle. We
need the features that it provides. But then there's lots of
overengineering going on as well -- especially with respect to the
built-in classes; there's a dozen different iterator types but I've
never used a single one of them -- and I haven't seen any code that
does either. What problem is all this code trying to solve?

[Wayne]

On 20 Dec 2005 23:53:00 GMT, "Default User" <de***********@ yahoo.com>
wrote:

If you deprecate something, and no one cares, then it can be removed
quickly. On the other hand, if it will have a huge affect, then it's
smart to wait and see.
Of course, given that PHP issues a warning (under E_STRICT) for
depreciated elements the effect is pretty huge always. Unlike
compiled languages like C/C++ were the warning exists only at compile
time, PHP warnings have a much bigger effect.
How much time? THAT is the question. There are some deprecated elements
in C and C++ that expect will outlive me.

PHP should move at a much faster pace than C/C++. There are
significant differences between the platforms, the applications, and
the environments that they aren't entirely comparable. Since PHP5
breaks so much backwards compatibility anyway I don't think
depreciated elements should stick around as long -- it's not as if you
have as much legacy code around that is running that is not already
being modified.

PHP also has way more mistakes in it than, for example C/C++, that
should be corrected. PHP started out as a big ball of hacks!!

[Chung Leong]

Oli Filth wrote:

Engineering isn't just about finding the first thing that works, it's
about finding the best solution given particular constraints, and
hopefully thinking about aspects such as long-term maintenance as well.

Normally, it might be true that aesthetics and principles are secondary,
but in the case of a computer language, these two qualities are often
intrinsically related to the semantics, structure and useability, and so
can't be ignored. Ignoring them is what led to PHP 4.
"Secondary" hardly means "it should be ignored." To spell out the
obvious, secondary means "not primary" and objectives that are
secondary do not take precedent over those that are primary. The
primary objective of PHP is to run PHP code. If a new version of PHP
cannot run a piece of existing code, then it fails. In engineering, of
course, failures aren't always avoidable and might be acceptable
provided that they're small or happen rarely. To argue though, that if
we fail once we should fail some more, is simply crazy.

By most measures PHP 4 has been a great engineering success so I don't
know what you're hinting at.
I think the developers have realised, however, that there are millions
of programmers out there who are used to OO features (for example) in
more "structured " languages, but laughed at PHP 4's attempt at OO, and
still laugh at the mish-mash nonsense of inconsistency that litters PHP
5. To attract these hardened programmers who are used to the formalities
of, for instance, Java, and view PHP as a toy not to be used for any
serious purpose, the developers know that from now on, the future of PHP
needs to be *planned* rather than *hacked*, and some of the embarrassing
legacy swept under the carpet.
Well, implementing something because critics are laughing at you is not
exactly good engineering now is it? Embarassment is hardly a technical
parameter either. Vanity is a trait of many an academics, so I think
you're proving my point.
Unfortuantely (well, maybe not, depending on your opinion), that may be
at the expense of the "PHP is great for hacking together any old
unprogrammatic atrocity" ethos. But then again, that ethos is the
self-fulfilling prophecy that fosters the liberal use of eval(),
numbered variables rather than arrays, dynamic class definitions, code
replication and nested-ifs instead of polymorphism, etc., etc...
Bad coding won't get you any closer to a working program so I don't see
the logic in this prophecy of your. What I do know is this: a working
program is better than a non-working one with polymorphism.
To properly design a language, it necessarily involves a large amount of
"academic" input - in the sense that it involves sitting down for a
*long* time and working out the whole plan in fine detail.

Computer languages are called languages for a reason. Fundamentally,
that's how they're used: a programmer is communicating his desires to
the computer. A good language allows its user to efficiently express
the widest range of ideas. As no one can anticipate what others will be
thinking, a language developed unguided by usage will inevitably be
overly introspective that cramps people's thought. It's no accident
that PHP is as successful as it is. The ad hoc manner by which it
developed is the source of its strength, not its weakness.

That was the linguist in me speaking :-)

[Jerry Stuckle]

Wayne wrote:

On 20 Dec 2005 23:53:00 GMT, "Default User" <de***********@ yahoo.com>
wrote:

If you deprecate something, and no one cares, then it can be removed
quickly. On the other hand, if it will have a huge affect, then it's
smart to wait and see.

Of course, given that PHP issues a warning (under E_STRICT) for
depreciated elements the effect is pretty huge always. Unlike
compiled languages like C/C++ were the warning exists only at compile
time, PHP warnings have a much bigger effect.

How much time? THAT is the question. There are some deprecated elements
in C and C++ that expect will outlive me.

PHP should move at a much faster pace than C/C++. There are
significant differences between the platforms, the applications, and
the environments that they aren't entirely comparable. Since PHP5
breaks so much backwards compatibility anyway I don't think
depreciated elements should stick around as long -- it's not as if you
have as much legacy code around that is running that is not already
being modified.

PHP also has way more mistakes in it than, for example C/C++, that
should be corrected. PHP started out as a big ball of hacks!!

Wayne,

I agree with you. Deprecated elements should be removed eventually. Not
necessarily the next release, but they shouldn't be kept around forever,
either.

And if Default User needs the function that badly, he can always
recreate it. Most deprecated functions can be recreated with other PHP
code. And if it can't, he can always go back to the previous version's
PHP source and compile that section of the code into the new PHP version
(or at least something which does the same). A definite advantage of
having the source!

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[tony]

Q: "Can you name me one single problem where introducing
case-sensitivity was the solution?"

A: Consistency.

Inconsistency is not a "real" problem as it does not cause the program
to produce wrong results. The fact that you personally like all
variables and function names to be in one case or the other is nothing
but a personal view and should NOT be forced upon others.

The idea of consistency might be good in theory, but the fact that this
allows the SAME word to have DIFFERENT meanings just because of a
slight change in case is far more serious. But that's just my opinion.

[tony]

>> You are not improving the language, you are killing it.

On the contrary. PHP could be a *lot* more strict in my opinion. I like the type hinting in PHP 5, as it saves me a *huge* amount of work in
parameter checking.

Type hinting is good, but this is an *addition* to the laguage that has
no effect on existing code.
If you following "design by contract", you either accept a parameter as valid and do something with it or reject it. Most

legacy code I encounter just accepts anything and hopes it does not
explode. Yuck. I even don't like the automatic string-number
conversion.
If I pass a string to a numeric function, there's something
fundamentally wrong with my code.

Automatic string-number conversion is there for a very good reason -
all input received from the HTML form is delivered as a string
regardless of whether it's supposed to be a date, a number or whatever.
The *feature* means that the programmer does not have to waste time
performing manual type conversions before being able to process each
field.
I don't want that covered up by the

language, I want to get a decent error message. *Off course* foreach
should give an error when something other than an array is passed!

If you give it a string or a number, yes. But insisting that a null
value cannot automatically be treated as an empty array is going over
the top.

[tony]

>> ... Please notice that 'breaking existing features' does NOT appear in that list.

Times change. Live with it. Acient DOS programs do not run under

Windows. Lots of Windows 3.1 drivers are totally useless for Windows
95.

Comparing a computer language with an operating system or device driver
is wandering off track. Expecting an ancient DOS program to run under
the latest version of Windows is unrealistic. I would, however, expect
a DOS program to run under *any* version of DOS just as I would expect
PHP code that I wrote last year to run under next year's version of
PHP.

[tony]

>> ... Providing an elegantly-coded solution, or a technically pure solution, is secondary.

Where have you been for the last 20 years? In the 80s, we programmed so the computer could understand it. Now we program so your computer *and
your colleague* can understand it. Code has grown larger and larger and

is rarely written anymore by one lonely hacker who stays with the
company for 30 years. Legibility is everything.

You are missing the point. Writing code that satisfies the end users
takes a higher priority than writing code that satisfies the
programmers. Clean code that does not satisfy user requirements is
useless. Code that *does* satisfy user requirements, whether clean or
dirty, is a step in the right direction. Having code which is both
useful and clean would be perfect, but in this cruel world nothing is
ever perfect.
So, PHP makers, if you are reading this:

Please, please, please, *PLEASE* drop the ternary operator from future
PHP versions! Just read the legacy code I'm confronted with and you
understand why.

Now there I would agree 100%. Every time I see the ternary operator I
want to puke.

[tony]

>> If it ain't broke, don't fix it

Again, where have you been in the last 20 years? If a statement does not

appear to be executed because it "silences" any error condition, you
have a hell of a time finding bugs. PHP code can be very hard to read
because of its un-strictness. When I see a parameter initialised as
FALSE, I assume it is a boolean. I mean, the initialization is also
documentation. You see the parameters in your editor wherever you use
them. But it may be an array, a string, or whatever. But FALSE will not

break the code. You can write monstrous code that coincidentally works
with the parameter types you pass. Now code that is illegible is not
legible by your collegue either, *SO IT IS BROKE*. And, *YES, IT NEEDS
TO BE FIXED*.

You are missing the point. I'm talking about the situation where a
developer looks at an existing function which works in thousands (if
not millions) of scripts, and decides that the code is not elegant or
clean enough for his taste, so he decides to refactor it, but this
refactoring then breaks a lot of scripts. The argument that the code is
now *cleaner* or *purer* is irrelevant to the customers - all they know
is that previously valid scripts do not work any more. They do not care
if the code is clean or dirty, just that it keeps on working as
expected.

[tony]

>>When you speak of 'proper' languages you mean 'languages that you are used to'. But why should the syntax of PHP be changed just to suit the preferences of a few individuals?

The PHP syntax is based on C and C++ -- it's doesn't really have it's

own syntax. Every syntax element in PHP is borrowed, in some way,
from other languages. I'm really not sure what you're arguing against
here.

The origins of PHP syntax are irrelevant. What I am objecting to is
that people moving to PHP from other languages look at the current PHP
syntax and see that it is different from what they are used to, and
they want it to change so that they do not have to cope with the
differences. If they cannot learn to cope with the differences then
they should not bother trying to use a different language.