Breaking backwards compatibility - good or bad?

[tony@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>> You are not improving the language, you are killing it.
[color=blue]
> On the contrary. PHP could be a *lot* more strict in my opinion. I like[/color]
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.
[color=blue]
> If you following "design by contract", you either[/color]
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.
[color=blue]
> I don't want that covered up by the[/color]
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@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>> ... Please notice that 'breaking existing features' does NOT appear in that list.
[color=blue]
> Times change. Live with it. Acient DOS programs do not run under[/color]
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@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>> ... Providing an elegantly-coded solution, or a technically pure solution, is secondary.
[color=blue]
> Where have you been for the last 20 years? In the 80s, we programmed so[/color]
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.
[color=blue]
> So, PHP makers, if you are reading this:[/color]
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@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>> If it ain't broke, don't fix it
[color=blue]
> Again, where have you been in the last 20 years? If a statement does not[/color]
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@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>>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?
[color=blue]
> The PHP syntax is based on C and C++ -- it's doesn't really have it's[/color]
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.

[tony@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>> "Removing function aliases does nothing except annoy users."
[color=blue]
> It increases the documentation and the confusion.[/color]

Having function aliases does not confuse me. I have seen it in several
languages, and it has never caused me or my fellow developers any
problems. As for documentation, "Function X is an alias of Function Y"
does not take up much room, does it?
[color=blue]
> Aliases should be deprecated, warnings issued for several versions, and then removed.[/color]
It's relatively simple and painless process -- it's search & replace
for godsakes.

You are assuming that each of the 23 million sites that use PHP have
programming staff on hand to perform these "clean up" operations with
every new release of PHP. How wrong you are! A large number do not
have any programming staff at all, they just use open source scripts
and expect them to work. If they have to spend a fortune in buying new
scripts they might as well switch to a new and reliable language. I
hear Ruby on Rails is getting *very* good reviews.

[tony@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>> "One of the biggest recent problems has been caused by a 'fix' which rejects the incorrect usage of references."
[color=blue]
> Oh yes. I recently came across that. I had to fix several bugs in my[/color]
software due to that. I never even noticed how wrong some of these
functions were until that error came up -- sure they worked, but they
weren't "correct" by any stretch of the imagination.

But wouldn't you agree that it was initially a documentation fault for
not adequately identifying what was *correct* and *incorrect* usage?
And was it not a language fault for not trapping some of this
*incorrect* usage much earlier instead of letting it carry on and cause
memory corruptions?

[tony@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>> "If it is possible to detect where some application code is wrong and
work around it instead of rejecting it completely, then this should be
implemented."
[color=blue]
> Bzzzt. Wrong. Nothing causes more bugs than having a language[/color]
silently do something unintented. The hardest single bug to find in
PHP is a variable typo on assignment -- instead of an error you
silently create a new variable and the variable you intended to change
goes unchanged. You want to add more silent errors to PHP programs?!?

Again you are missing the point. I am not talking about the language
doing something unintended, I am talking about where the programmer has
used a variable reference which used to work but which now fails. It
has been stated that it would be possible for the language to detect
this situation but, instead of rejecting it outright, could work around
it without producing a memory corruption and produce an E_NOTICE or
E_STRICT to warn the programmer of the dodgy code. If it is possible to
allow existing code to continue working but *without* causing a memory
corruption, then this surely has a greater priority than making an
unknown number of existing scripts to fail outright.

[tony@marston-home.demon.co.uk]

Re: Breaking backwards compatibility - good or bad?

>> "None of the operating systems I have encountered on mainframe,
mini-computer and personal computer systems I have used in the past 30
years has been case-sensitive, nor has any of the compilers (apart
from PHP and its variable names), text and document editors, and
database query tools."
[color=blue]
> What the hell?!? Case-sensitive variables/function exist in C, C++,[/color]
Java, C#, Pascal, Delphi, Javascript, PERL, Ruby, Python, Smalltalk,
Objective-C and so on. Most everything in Unix is case-sensitive
including the file system. I'm not sure what you've been doing for
the past 30 years but the vast majority of the computing world is
case-sensitive. You're out of the loop.

For your information I have worked on UNIVAC mainframes, mini-computers
from Data General and Hewlet Packard, and PCs running Windows. None of
these have been case-sensitive. I have programmed in assember, COBOL,
FORTRAN, SPL, QUIZ, QUICK, QTP, INSIGHT, TRANSACT and UNIFACE. None of
these languages has ever been case-sensitive. I have spent most of my
career working in software houses providing business applications for
business customers, so I would not consider myself to be out of the
loop.

My point is that for 30 years I have worked with tools which were
totally insensitive to case, but some morons seem to think that case is
important. For God's sake WHY! What problem existed in the
case-insensitive world that needed to be fixed?

[R. Rajesh Jeba Anbiah]

Re: Breaking backwards compatibility - good or bad?

Chung Leong wrote:
<snip>[color=blue]
> The ad hoc manner by which it
> developed is the source of its strength, not its weakness.[/color]

At that time PHP wasn't used in big projects, IMHO. When you start
using PHP in bigger projects (say, more than at least 5 person team),
you start facing problems because of ad hoc invention. Person A uses
different documentation style, Person B uses different function alias,
etc--that's the reason for the "standards" in companies. Well,
companies can bring a coding standards saying that don't use funcX, use
funcXAlias; but it's certainly an err at PHP end.

BTW, it's really funny to name a person works in ad hoc manner
(*just* getting things done) with "Engineer":-)

<OT>Aren't you Academician? IIRC, you're with University?</OT>

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[Wayne]

Re: Breaking backwards compatibility - good or bad?

On 21 Dec 2005 01:03:48 -0800, tony@marston-home.demon.co.u k wrote:
[color=blue]
>Inconsistenc y is not a "real" problem as it does not cause the program
>to produce wrong results.[/color]

Correct. But I would argue that programs are meant to be read by
humans at least as much as by the computer. Humans see a variable
called $foo and $foO to be different.
[color=blue]
>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.[/color]

I see no reason not to force it on others. There is no legitimate
reason to have variables named $foo, $foO, $FOO all refering to the
same thing.

I will however concede that there is also no reason that $foo, $foO,
and $FOO should point to different things either! Which is your main
objection and I agree.

I'm not sure why you've chosen to break your response into multiple
usenet postings. I'm going to coalese them in my response:
[color=blue]
>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.[/color]

I'd like you to give me an example of this! I mean what changes do
people want? PHP already looks like C, C++, PERL, and Java? Do they
want to include some Haskel or Lisp syntax in there too?
[color=blue]
>As for documentation, "Function X is an alias of Function Y"
>does not take up much room, does it?[/color]

Yes it does, in the index! Each duplicated function takes up twice as
much room in any list of available functions. Anyone learning PHP
will have to wade through even more documentation even if half of it
says "Function X is an alias of Function Y"
[color=blue]
>You are assuming that each of the 23 million sites that use PHP have
>programming staff on hand to perform these "clean up" operations with
>every new release of PHP.[/color]

I would assume that only major x.x releases would have such changes
and in the history of PHP those have been pretty rare. PHP4 has only
had 4 major releases in it's many-year lifespan.

Either the 23 million sites that use PHP have programming staff on
hand or they are using some commercial or open source software. If
they are using commercial or open source software I would assume that
those projects would be updated. Given that many products have kept
up to date with the many changes in PHP4 (including good 'ol
register_global s) it doesn't seem like a huge task.
[color=blue]
>If they have to spend a fortune in buying new
>scripts they might as well switch to a new and reliable language.[/color]

If they spend a fortune buying scripts in the first place, I'd expect
those scripts not to use depreciated features. It's not like things
would be yanked out without plenty of notice.
[color=blue]
>But wouldn't you agree that it was initially a documentation fault for
>not adequately identifying what was *correct* and *incorrect* usage?[/color]

In my case, it was *clearly* incorrect usage. The function should not
even have been defined to return a reference. It was just plain
wrong. In fact, I imagine you would only encounter this problem with
functions are returning references when it makes absolutely no sense
to do so. This isn't really a documentation issue.
[color=blue]
>And was it not a language fault for not trapping some of this
>*incorrect* usage much earlier instead of letting it carry on and cause
>memory corruptions?[/color]

Clearly it was a bug -- and a long standing one at that. They fixed
the bug. Fixing the bug caused some incorrect scripts to break. It
seems pretty cut and dried to me. I'm not sure I'm willing to
sacrifice performance of every single function call just to ensure
that incorrect script continue to work correctly -- because that's the
alternative.
[color=blue]
>Again you are missing the point. I am not talking about the language
>doing something unintended, I am talking about where the programmer has
>used a variable reference which used to work but which now fails.[/color]

You're missing the point. For the programmer to have a problem, he
would have to be using references in a situation that clearly doesn't
make sense to use references.
[color=blue]
>It
>has been stated that it would be possible for the language to detect
>this situation but, instead of rejecting it outright, could work around
>it without producing a memory corruption and produce an E_NOTICE or
>E_STRICT to warn the programmer of the dodgy code.[/color]

....And eat up considerable CPU cycles for each and every function
call. You can't just keep throwing more code at problems! Even the
smallest overhead in the function call mechanism can waste a
considerable amount of CPU cycles.

[Wayne]

Re: Breaking backwards compatibility - good or bad?

On 21 Dec 2005 02:16:11 -0800, tony@marston-home.demon.co.u k wrote:
[color=blue]
>My point is that for 30 years I have worked with tools which were
>totally insensitive to case, but some morons seem to think that case is
>important. For God's sake WHY! What problem existed in the
>case-insensitive world that needed to be fixed?[/color]

Unicode.

In order to determine if two strings match entirely based on case you
have to take a lot of things into consideration. It's no longer
sufficient to say A-Z maps to a-z.

The only reason languages like Fortran are case-insensitive is because
punch cards and many early terminals only had uppercase characters.

[Martin Lucas-Smith]

Re: Breaking backwards compatibility - good or bad?



On Wed, 21 Dec 2005, tony@marston-home.demon.co.u k wrote:
[color=blue][color=green]
> > So, PHP makers, if you are reading this:[/color]
> 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.[/color]


Why? Once you know it exists, it makes coding certain things very much
more efficient, e.g.


echo "You have $total " . (count ($total) == 1 ? 'item' : 'items') . '.';


rather than the verbose


if (count ($total) == 1) {
$tempWord = 'item';
} else {
$tempWord = 'items';
}
echo "You have $total {$tempWord}.";
unset ($tempWord);



or

$foo = (isSet ($_GET['foo']) ? $_GET['foo'] : 'default');


It's not as if this construct only exists in PHP.



Martin

[Dikkie Dik]

Re: Breaking backwards compatibility - good or bad?

tony@marston-home.demon.co.u k wrote:[color=blue][color=green][color=darkred]
>>>If it ain't broke, don't fix it[/color][/color]
>
>[color=green]
>>Again, where have you been in the last 20 years? If a statement does not[/color]
>
> 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.
>[/color]

Not at all. If a refactoring breaks something, it is by definition not a
refactoring. But that is beside the point. I encountered far too much
code that was beyond maintenance.
"Don't touch that code. It works, OK?"
"What does it do then exactly?"
"We don't know, but it works!"
I heared this conversation at least 200 times. It is exactly my
definition of broken software. Working software (if I create or maintain
it) is something I have control of. I know the state of my code, because
the unit tests tell me what state it is in. When I change a line of
code, even if I have a less then bright day, I still know the
consequences just by running the tests. Working software is not some
cute image on my screen, but proof that the components do what they are
supposed to. And that they obey their contract. If the code has become a
minefield it is definitely broke. Worse even. You can't repair what you
can't touch.
It is absolutely not irrelevant to the customers wether the code can be
maintained or not. Or how dangerous that is, or how much time it would cost.
Especially when environments change. The OS changes, the language
changes, the computer hardware changes, the goal or use of the
application changes and all those changes can call for maintenance. I
think no company or programmer can afford to say to a customer that a
piece of code is declared "not broke" and, oh, beyond fixing. A dirty
hack is a time bomb. It is only safe to use one if you are 100% sure you
disarm it in time. If not, it is guaranteed to blow in your face when
you least expect it.

Best regards

[Oli Filth]

Re: Breaking backwards compatibility - good or bad?

Chung Leong wrote:[color=blue]
> Oli Filth wrote:
>[color=green]
>>Normally, it might be true that aesthetics and principles are secondary,
>>but in the case of a computer language, these two qualities are often
>>intrinsical ly related to the semantics, structure and useability, and so
>>can't be ignored. Ignoring them is what led to PHP 4.[/color]
>
> "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.[/color]

Hmm, "ignored" was a bit strong. I think "put to one side" or "added as
an after-thought" was what I meant. ;)
[color=blue]
>
> By most measures PHP 4 has been a great engineering success so I don't
> know what you're hinting at.[/color]

I agree, it's a widespread success, but its also a big sprawling heap of
hacks, afterthoughts, inconsistent function names and parameter lists,
function aliases, issues with references that no-one really knows how to
deal with, version incompatibiliti es, nonsense like magic quotes, ...
That's what I was hinting at.

[color=blue][color=green]
>>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.[/color]
>
>
> 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.[/color]

I wasn't referring to "critics" in the sense of academics, but to
real-world programmers who might have wanted to use PHP if it weren't
such a mess (compared to other languages).

The support and interest of professional software developers is crucial
for the continued advancement of PHP, IMO.

[color=blue][color=green]
>>Unfortuante ly (well, maybe not, depending on your opinion), that may be
>>at the expense of the "PHP is great for hacking together any old
>>unprogrammati c 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...[/color]
>
>
> Bad coding won't get you any closer to a working program so I don't see
> the logic in this prophecy of your.[/color]

Bad coding *can* get you closer to a working (in one sense of the word)
program - I've seen countless posts in PHP newsgroups where newbies have
asked things like "How can I loop through my variables $thing1,
$thing2...?", to which the answer is "use arrays instead", to which
their response is "well, my variables do the job, so why should I?". If
people don't take the time to learn good practice, they'll never see
*why* the things they were doing before were bad practice - that's what
I meant by self-fulfilling prophecy. If the language can help enforce
some aspects of good practice, then that's a good thing IMO.

[color=blue]
> 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.
>[/color]

How about C or C++? They're immensely successful, far more widely used
than PHP, and comparatively they're set in stone - you don't get Bjarne
Stroustrup (chief mind behind C++) going "oh, I think we'll change the
semantics of pointers and references" every 5 minutes. Yes, these
languages get new features added from time to time, but because they
were planned so well in the first place, they very rarely lead to
backwards incompatibility .

The "ad hoc" manner in which PHP has been developed is indisuptably the
source of many of its weaknesses. It might also be the source of its
strengths, but possibly because many of those strengths are aspects
which should have been thought of in the first place.


--
Oli