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/bc-is-everything.html and see if
you agree with my opinion or not.

Tony Marston
http://www.tonymarston.net

.... Add support for goto. ....
*AAAAAAAAAAAAAARRRGGGHHHHH!*

How can anyone match that with an object-oriented language? Most 
object-oriented laguages that have a goto statement only have it as an 
ancient left-over. Something to clean out in a cleaner version of the 
language. NOT to put it in!
Let me clarify:
In an object-oriented language, you have two independent "axes" of 
controlled software modification. "Controlled" meaning that you change 
software without introducing bugs in existing software:
- The Open Closed Principle (first axis). "Software should be open to 
extension, but closed to modification". In OO languages, this is 
implemented through inheritence. If you want to modify something, you 
can inherit from an existing class instead of breaking it. So you don't 
introduce new bugs in EXISTING code.
- Refactoring (second axis). The structure is changed with Refactoring, 
but not the behaviour. And this is tested (with automated tests, called 
"unit tests") in every single little step. So you don't introduce new 
bugs in existing code because you test it thouroughly on component and 
function basis.

If there is one thing that makes simple refactorings overly difficult, 
it is goto statements and disguised goto statements like "return" (= 
goto end).

But in reaction to your comment:
 > If you want PHP to be considered as more than a 'toy' language
 > then you must stop behaving like petulant children.
Like Microsoft when they introduced VB .NET? The compatibility between 
PHP4 and 5 is far, far better than between Visual Basic and VB .NET. In 
fact, I did not encounter one function or statement yet that refused to 
run under PHP5.

 > 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. 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. 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!

 > ... That means that you are outnumbered ...
You don't speak for me. My provider supports both PHP4 and PHP5 and I 
came in time to get into PHP5 only. Alas, at my work they still use 
PHP4. It is taking a giant step back in OO functionality. And, wether 
you like it or not, it's their product. You are not in charge. You are 
free to start your own open source project. How would YOU like it when 
somebody starts shouting you are not even allowed to run your own project?

 > ... 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. 
AutoCAD's ENDSV command now only gives an error message: "Discontinued 
command". And THAT's an _awfully_ backwards compatible program. Java has 
lots of "deprecated" methods. Even the off-switch of you PC may start a 
shutdown sequence instead of just disconnecting the power. You must be 
angry every day.
Oh, and I don't expect an update. I'm not surprised if there is one 
either, but I don't require it as you seem to do. I don't expect updates 
for Windows 98, VB6 or whatever old versions of old programs. Likewise, 
I don't expect updates for PHP4. Not even for 5. But as even the PHP 
makers are human, there may be some.

 > Note here that the removal of undocumented features can
 > only be justified ...
No one has to justify a change in a side effect. Undocumented features 
are side effects. There is and has never been any guarantee about 
undocumented features. It would mean that you were never allowed to fix 
bugs!

 > The customer is always right
Thanx. I know I am. ;)
Oh, you were speaking about yourself? Well, there are a *LOT* of 
customers, so "the customer" does not exist. If he did, it was taylor 
made software and you could just pick up the phone.

 > ... 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.
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.

 > 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*.

Sorry to disappoint you.

Best regards


tony@marston-home.demon.co.uk wrote:
> 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/bc-is-everything.html and see if
> you agree with my opinion or not.
> 
> Tony Marston
> http://www.tonymarston.net
> 

On 20 Dec 2005 06:45:14 -0800, tony@marston-home.demon.co.uk wrote:

>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/bc-is-everything.html and see if
>you agree with my opinion or not.

100% disagree.  The changes in PHP5 have been a *very* long time
coming and are needed to anything really big and useful in PHP.

Comments on your comments:

>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.

"Removing deprecated or duplicated functions may sound like a good
idea, but if any of those functions are still widely used then they
should be left alone."

Deprecated
(adj.) Used typically in reference to a computer language to mean a
command or statement in the language that is going to be made invalid
or obsolete in future versions.

BY DEFINITION Deprecated functions should be removed -- that's why
there are deprecated in the first place!  Maybe you should be arguing
for less deprecated functions otherwise I think you miss the meaning
of the word.  In any case, deprecated functions should issue warnings
for a few versions before they are removed from the language giving
people plenty of time to remove them.

"Instead of wasting time on unnecessary "clean-up" operations which
will achieve nothing but aggravation for existing customers..."

The cleanup operations help new users and help with the overall
maintainence of code written in the language.  A constant newbie
question is whether one should use ereg or preg!  PHP code can be
filled with calls to different functions which do nearly the same
thing yet are subtly different (ausing maintainence headaches and
subtle bugs.  The cleanup is meant to make the language simpler for
all.  Simple language = good language.

"Removing function aliases does nothing except annoy users."

It increases the documentation and the confusion.  Aliases should be
deprecated, warnings issued for several versions, and then removed.
It's relatively simple and painless process -- it's search & replace
for godsakes.

"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."

Bzzzt.  Wrong.  Nothing causes more bugs than having a language
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?!?

"One of the biggest recent problems has been caused by a 'fix' which
rejects the incorrect usage of references."

Oh yes.  I recently came across that.  I had to fix several bugs in my
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.

"The point is that if a solution is available which will resolve the
memory corruption AND not break thousands of existing scripts..."

The PHP team tries very hard not to break CORRECT scripts.  INCORRECT
scripts should be broken because the problem was always with the
script and not the language -- it's just the language didn't check for
that problem.  Anywhere that I had used references correctly worked
perfectly on the newest version of PHP4.

"The idea that I should have to initialise a variable with array()
before using any array functions on it is a stupid idea. The existing
code treats a null value and an empty array as one and the same thing,
and there must be countless lines of code out there in userland which
rely on this behaviour."

Unfortunately null and Array() are not interchangable everywhere in
the language otherwise I would agree with you.  The problem is that
you end up with more silent unintented bugs making scripts overall
less reliable.  If I have a choice in breaking backwards compatibility
in such a simple-to-fix way or decreasing the reliablity of all
scripts written in PHP, the choice is pretty simple.

"Statically typed languages may insist that a variable's type is set
before it can be accessed by functions that will only work on a
variable of that type, but dynamically types languages do not."

We're not talking about the type of variable -- we're talking about
the type of the value of the variable.  You can't call number_format()
on an array (or a string that doesn't contain a number) why should you
be able to call array functions on non-arrays?  Functions care about
the types of variables passed to them -- this has always been true!  

"I do not have to declare a variable as being numeric before using a
numeric function on it"

But the value still has to be a number!!!

"Introducing the goto statement is not a good idea."

Agreed.  And it doesn't look like the goto movement is going anywhere
(no pun intended).

"Introducing case-sensitivity for variables and functions names has
always struck me as the worst possible decision in the entire history
of computing."

I used to agree with you -- as a Visual Basic programmer I never
understood why anyone would bother to clutter up the language with
case-sensitivity.  However, Visual Basic (and even QBasic for DOS) had
a feature that really made their case-insensitivity work -- no matter
what case you typed the variable in, it would automatically convert it
to the case it was declared in.  So in Basic code, you never had
variables like foobar, FooBar, and FOOBAR -- it was always consistent.

The case for case-sensitivity is consistency.  I don't want my code
litered with all different kinds of cased variables with the same damn
name.  I want it to be consistent.  Have it error out in that case is
a good thing. 

"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."

What the hell?!?  Case-sensitive variables/function exist in C, C++,
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.

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

Consistency.

"By claiming that each combination of upper and lower case for the
SAME WORD has a different meaning you are actually opening yourself
up..."

I agree.  However, the problem is exceedingly rare when you ever even
have two variables or functions with the same name that vary only in
case.  Generally case-sensitivity is in fact used to enforce a single
case spelling of a language word.  I'd prefer that you couldn't
redeclare a variable/function with the same name but with a difference
case and yet not be able to use a variable/function unless you use the
case it was declared with -- I think we'd both be happy with that.

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.
As my professor used to say, "Ask not why you do something, but HOW you
do it." An academic, on the other hand, seeks the recognition and
approval of his peers. Practical implications are irrelevant when the
main objective is to impress.

More and more, the academic is winning the fight.

Wayne wrote:

 
> "Removing deprecated or duplicated functions may sound like a good
> idea, but if any of those functions are still widely used then they
> should be left alone."
> 
> Deprecated
> (adj.) Used typically in reference to a computer language to mean a
> command or statement in the language that is going to be made invalid
> or obsolete in future versions.
> 
> BY DEFINITION Deprecated functions should be removed 

I disagree with this. As deprecated elements may be removed, no new
code should be written that uses them. However, if removal of the
deprecated construct will cause significant breakage of existing code,
then an overriding reason should be present for immediate removal.



Brian

-- 
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

Default User said the following on 20/12/2005 22:36:
> Wayne wrote:
> 
>  
> 
>>"Removing deprecated or duplicated functions may sound like a good
>>idea, but if any of those functions are still widely used then they
>>should be left alone."
>>
>>Deprecated
>>(adj.) Used typically in reference to a computer language to mean a
>>command or statement in the language that is going to be made invalid
>>or obsolete in future versions.
>>
>>BY DEFINITION Deprecated functions should be removed 
> 
> 
> I disagree with this. As deprecated elements may be removed, no new
> code should be written that uses them. However, if removal of the
> deprecated construct will cause significant breakage of existing code,
> then an overriding reason should be present for immediate removal.
> 

But by that argument, deprecated features would *never* *ever* get 
removed, and so rendering the term "deprecated" redundant.

-- 
Oli

Chung Leong said the following on 20/12/2005 21:52:
> 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.

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.

(Note that I'm not saying that backwards compatibility isn't important.)


> As my professor used to say, "Ask not why you do something, but HOW you
> do it." An academic, on the other hand, seeks the recognition and
> approval of his peers. Practical implications are irrelevant when the
> main objective is to impress.
> 
> More and more, the academic is winning the fight.
> 

PHP is *never* going to win recognition as some clever, beautifully 
thought-out, academic language, so I think that saying "the academic is 
winning the fight" is somewhat erroneous - I don't think that's what the 
developers are trying to do (not as a main priority, anyway).

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.

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...

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.

-- 
Oli

Oli Filth wrote:

> Default User said the following on 20/12/2005 22:36:
> > Wayne wrote:
> > 
> > 
> > > "Removing deprecated or duplicated functions may sound like a good
> > > idea, but if any of those functions are still widely used then
> > > they should be left alone."
> > > 
> > > Deprecated
> > > (adj.) Used typically in reference to a computer language to mean
> > > a command or statement in the language that is going to be made
> > > invalid or obsolete in future versions.
> > > 
> > > BY DEFINITION Deprecated functions should be removed 
> > 
> > 
> > I disagree with this. As deprecated elements may be removed, no new
> > code should be written that uses them. However, if removal of the
> > deprecated construct will cause significant breakage of existing
> > code, then an overriding reason should be present for immediate
> > removal.
> > 
> 
> But by that argument, deprecated features would never ever get
> removed, and so rendering the term "deprecated" redundant.


How do you figure? There has be a review of the benefits versus
detriments. Conversely, if all deprecated elements are removed
immediately, there's also no need for the term.



Brian

-- 
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

On 20 Dec 2005 23:45:13 GMT, "Default User" <defaultuserbr@yahoo.com>
wrote:


>> But by that argument, deprecated features would never ever get
>> removed, and so rendering the term "deprecated" redundant.
>
>How do you figure? There has be a review of the benefits versus
>detriments.

Obviously the review has already been done on depreciated elements
hence why they are depreciated.  If there is no reason to remove them
at all, they wouldn't be depreciated!  

>Conversely, if all deprecated elements are removed
>immediately, there's also no need for the term.

Agreed.  Depreciated is the stage before the item is to be removed --
to give everyone time to stop using it (and to prevent new people from
using it).  Once you've given everyone enough time to stop using it,
you remove it.  I don't see the problem here.

Wayne wrote:

> On 20 Dec 2005 23:45:13 GMT, "Default User" <defaultuserbr@yahoo.com>
> wrote:
> 
> 
> >> But by that argument, deprecated features would never ever get
> >> removed, and so rendering the term "deprecated" redundant.
> > 
> > How do you figure? There has be a review of the benefits versus
> > detriments.
> 
> Obviously the review has already been done on depreciated elements
> hence why they are depreciated.  If there is no reason to remove them
> at all, they wouldn't be depreciated!  

Deprecated. The reason elements are deprecated rather than removed
outright is to let people know and to do the evaluations that determine
when, if ever, those elements will be removed.

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.


> > Conversely, if all deprecated elements are removed
> > immediately, there's also no need for the term.
> 
> Agreed.  Depreciated is the stage before the item is to be removed --
> to give everyone time to stop using it (and to prevent new people from
> using it).  Once you've given everyone enough time to stop using it,
> you remove it.  I don't see the problem here.

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



Brian

On 20 Dec 2005 13:52:17 -0800, "Chung Leong"
<chernyshevsky@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? 

On 20 Dec 2005 23:53:00 GMT, "Default User" <defaultuserbr@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!!

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 :-)

Wayne wrote:
> On 20 Dec 2005 23:53:00 GMT, "Default User" <defaultuserbr@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.
jstucklex@attglobal.net
==================

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.

>> 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.

>> ... 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.

>> ... 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.

>> 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.

>>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.

>> "Removing function aliases does nothing except annoy users."

> It increases the documentation and the confusion.

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?

> Aliases should be deprecated, warnings issued for several versions, and then removed.
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.

>> "One of the biggest recent problems has been caused by a 'fix' which rejects the incorrect usage of references."

> Oh yes.  I recently came across that.  I had to fix several bugs in my
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?

>> "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."

> Bzzzt.  Wrong.  Nothing causes more bugs than having a language
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.

>> "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."

> What the hell?!?  Case-sensitive variables/function exist in C, C++,
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?

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

    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/

On 21 Dec 2005 01:03:48 -0800, tony@marston-home.demon.co.uk wrote:

>Inconsistency is not a "real" problem as it does not cause the program
>to produce wrong results. 

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.

>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.

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:

>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.

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?

>As for documentation, "Function X is an alias of Function Y"
>does not take up much room, does it?

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"

>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.  

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_globals) it doesn't seem like a huge task.

>If they have to spend a fortune in buying new
>scripts they might as well switch to a new and reliable language.

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.

>But wouldn't you agree that it was initially a documentation fault for
>not adequately identifying what was *correct* and *incorrect* usage?

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.

>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?

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.

>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. 

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.  

>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. 

....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.

On 21 Dec 2005 02:16:11 -0800, tony@marston-home.demon.co.uk wrote:

>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?

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.

On Wed, 21 Dec 2005, tony@marston-home.demon.co.uk wrote:

> > 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.


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

tony@marston-home.demon.co.uk wrote:
>>>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.
> 

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

Chung Leong wrote:
> Oli Filth wrote:
> 
>>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.

Hmm, "ignored" was a bit strong. I think "put to one side" or "added as 
an after-thought" was what I meant. ;)

> 
> By most measures PHP 4 has been a great engineering success so I don't
> know what you're hinting at.

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 incompatibilities, nonsense like magic quotes, ...
That's what I was 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.

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.


>>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.

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.


> 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.
> 

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

Jerry Stuckle wrote:


> 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. 


This merely demonstrates that you didn't follow what I said. Likely
that's my fault. My point was that the removal of deprecated elements
in any programming language has to be weighed against the overall
effect of both retention and removal.




Brian

tony@marston-home.demon.co.uk wrote:

 
> 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.

I guess C, C++, and UNIX are not particularly popular.

> For God's sake WHY! What problem existed in the
> case-insensitive world that needed to be fixed?

Ask Dennis Ritchie.


Brian

Wayne wrote:
> On 21 Dec 2005 01:03:48 -0800, tony@marston-home.demon.co.uk wrote:
> 
> 
>>Inconsistency is not a "real" problem as it does not cause the program
>>to produce wrong results. 
> 
> 
> 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.
> 
Er ... no. Only if they have been exposed to case-sensitive languages or 
systems.

In my view, case sensitivity was one of the biggest mistakes the Unixers 
made in the first place.

However, it is now pretty common, though not universal.

Oddly, having argued this, I'm going to say something in favour of PHP5. 
I'm not aware of all the ramifications (I haven't done a great deal of 
PHP5 yet), but it always stuck in my craw having to say (in PHP 4):

class MyName ....



if (get_class($thing) == 'myname') ...


Now I've no objection to being *able* to do that, but being forced to 
(because get_class($thing) will *never* equal 'MyName', which is what I 
called the class) is wrong. So in this instance anyway, I prefer PHP5's 
approach.

Colin

Oli Filth wrote:
> 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 incompatibilities, nonsense like magic quotes, ...
> That's what I was hinting at.

Aesthetics. Aesthetics. Perhaps one of these days you will come to grip
with the nature of this world. The ugly win because they do what it
takes to win, while the beautiful disappear into oblivion. Just look at
how Windows has prosper while the BeOS is in the technology wastebin.

Incidently, I say the same thing to my historian friend, who, despite
all empirical evidence to the contrary, thinks that the principled
politician would always carry the day.

> 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).

Let them use whatever language they were using then. What's this crazy
obsession with needing to "convert" people?! PHP is not a religion--it
is a tool. It is useful to me and thousands of other developers. If you
don't want to use it, well, it's your loss. From an engineer's point of
view you wouldn't alter a product to suit the desires of people who
aren't even using it--because it's goddamn stupid. Only idle academics
live for this kind of vainglory.

> 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...?"

That's just igorance. We all know that using an array in this
particular situation is easier. And once someone learn an easy way to
do something, he/she wouldn't go back.

> to which the answer is "use arrays instead", to which
> their response is "well, my variables do the job, so why should I?".

Very good question to ask in fact. If all you can offer is a
non-technical value-judgement: "it's good practice," then you're a sort
of priest of programming, not a software engineer.

> 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 changes in PHP 5 were driven from above, without regards to the
needs of the user community. That gets us back to the original topic of
backward compatibility. Do you really think longtime PHP programmers
want their existing code to break? You yourself said that these changes
are made to please people are not programming in PHP. Now what benefits
do I get if Bob Bobinski the Java guru is converted to PHP? Does it
make my job easier? My programs run faster? Are my sites more secured?

t...@marston-home.demon.co.uk wrote:
>> 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.

> I guess C, C++, and UNIX are not particularly popular.

They may be popular in some circles, but I have never travelled in
those circles.

>> For God's sake WHY! What problem existed in the
>> case-insensitive world that needed to be fixed?

> Ask Dennis Ritchie.

No, I'm asking you. What problem existed in the case-insensitive world
that could ONLY be solved by introducing case-sensitivity?

On 21 Dec 2005 01:03:48 -0800, t...@marston-home.demon.co.uk wrote:

>> Inconsistency is not a "real" problem as it does not cause the program
>> to produce wrong results.

> 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.

I disagree. I have worked for decades with case-insensitive languages
and I have always treated $FOO and $foo as the same variable. It does
not matter to me whether it is written all upper case or all lower
case, it is exactly the same thing. I have worked with different teams
who had had entirely different standards - some like all upper case,
some like all lower case, all for different reasons. What I object to
is being told that I MUST use one case or the other just to be
*consistent* with everyone else, especially when I disagree with their
reason for choosing one case over the other in the first place. The
language has no difficulty in recognising a word regardless of its
case, and neither do I.

By introducing case-sensitivity you are suddenly saying that $FOO and
$foo are now different, which goes against the grain of everything that
I have been taught since my first day at school way back in the last
century.

The person who dreamed up case-sensitivity is a sadist and a moron who
should be publicly flogged. But that's just my opinion.

> 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.

Your second statement contradicts the first, but at last you agree that
having $FOO and $foo point to different things is not a good thing. If
this is as a result of introducing case-sensitivity, then
case-sensitivity must itself be "not a good thing".

>> 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?

> Unicode.

Explain. I write scripts with an editor that stores in unicaode without
any problem, so what exactly is the problem?

> 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.

You are talking about the *contents* of variables, whereas I am talking
about the *names* of variables. There is a BIG difference between the
two.

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

True, but when punched cards where replaced by terminals and keyboards
which had the capability of both upper and lower case it made no
difference which case was used as they were treated exactly the same.
Thus programmers could take their original code which was all upper
case and change it if they wanted to. Changing case was a matter of
human readability or personal taste, but the computer did not care -
the name of a function or a variable was exactly the same regardless of
which case was used.

That is what I have been used to for decades, and I see absolutely no
advantage in being forced to switch.

On 22 Dec 2005 01:35:31 -0800, tony@marston-home.demon.co.uk wrote:

>On 21 Dec 2005 01:03:48 -0800, t...@marston-home.demon.co.uk wrote:
>
>>> Inconsistency is not a "real" problem as it does not cause the program
>>> to produce wrong results.
>
>> 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.
>
>I disagree. I have worked for decades with case-insensitive languages
>and I have always treated $FOO and $foo as the same variable.

But I didn't say $FOO or $Foo.  I said $foo and $foO!  People have no
trouble will all caps or the first letter capitalized.  What about the
difference between setsLower() and setSlower()?  To a human reader
those have different meanings, to a case-insensitive compiler they are
the same.

>some like all upper case,

My god.  I wouldn't want my code constantly shouting at me.  All upper
case is harder to read, too.

>What I object tois being told that I MUST use one case or the other just to be
>*consistent* with everyone else, especially when I disagree with their
>reason for choosing one case over the other in the first place.

The majority of programmers disagree with you on this.  Consistency
and conventions are preferred when working on a particular project or
platform --  it cuts down on errors and allows one to convey greater
meaning.

>By introducing case-sensitivity you are suddenly saying that $FOO and
>$foo are now different, which goes against the grain of everything that
>I have been taught since my first day at school way back in the last
>century.

A common Java idiom is:

Foo foo  = new Foo();

The convention in Java is that class names begin with an upper-case
letter and variables begin with a lowercase variable.  I can clearly
see what is happening here.

To get the same meaning if it was case-insensitive, you'd have to do
something like:

FooClass fooInstance = new FooClass() 

Which makes readability worse, not better.

On 22 Dec 2005 01:40:17 -0800, tony@marston-home.demon.co.uk wrote:

>> 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.
>
>Your second statement contradicts the first, but at last you agree that
>having $FOO and $foo point to different things is not a good thing.

It's not exactly a contradiction...  I wouldn't allow both $foo and
$FOO in the same program.  In a case-insentive language that's
allowed.  I would want that completely disallowed.

That's a bit difficult in a free-form language like PHP but in
languages with variable declarations, the variable would have to match
the declared case otherwise it would be an error.

On 22 Dec 2005 01:51:24 -0800, tony@marston-home.demon.co.uk wrote:

>> 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.
>
>You are talking about the *contents* of variables, whereas I am talking
>about the *names* of variables. There is a BIG difference between the
>two.

Umm, no I'm not.  All languages are written in English and ASCII.
Java, for example, is written in Unicode (UTF-8). 

>That is what I have been used to for decades, and I see absolutely no
>advantage in being forced to switch.

So you're main argument is that it's not what you're used to -- so it
should be changed.  Isn't that the attitude that your entire article
was arguing against??

On 22 Dec 2005 01:21:40 -0800, tony@marston-home.demon.co.uk wrote:

>> Ask Dennis Ritchie.
>
>No, I'm asking you. What problem existed in the case-insensitive world
>that could ONLY be solved by introducing case-sensitivity?

Many many years ago it was done for compiler performance reasons.  It
does require lots of extra cycles to lower-case every single
identifier in a large C application.

Might seem like a poor reason now, but as a COBOL/Mainframe programmer
should appreciate it -- It was only 2 extra bytes to store the entire
year but somebody decided that was too much.

Chung Leong wrote:
> Oli Filth wrote:
> 
>>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 incompatibilities, nonsense like magic quotes, ...
>>That's what I was hinting at.
> 
> Aesthetics. Aesthetics. Perhaps one of these days you will come to grip
> with the nature of this world. The ugly win because they do what it
> takes to win, while the beautiful disappear into oblivion.

In the 21st Century, where programming is as much about team-based 
development and code maintenance planning as it is about knocking out 
lines of code, aesthetics *are* massively important, IMO. Code that's 
more consistent and easier to read is easier to understand, and easier 
to hand over to another team member.


Note that despite the stance I appear to be taking, I definitely don't 
agree with all the changes between 4 and 5, nor the proposed changes in 
6. I see no advantage in changing constructor names to __construct, 
changing the name of $this, continually changing string indexing syntax 
back and forth, nor adding polymorphism of statics, for instance.


> Incidently, I say the same thing to my historian friend, who, despite
> all empirical evidence to the contrary, thinks that the principled
> politician would always carry the day.

I wish it were true...!


>>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).
> 
> Let them use whatever language they were using then. What's this crazy
> obsession with needing to "convert" people?! PHP is not a religion--it
> is a tool.

It's not a matter of trying to "convert" people, no-one's going to go 
"oh, I've seen the light, PHP is better than C++, what have I been doing 
all these years". But a large user-base (and incoming users with skills 
and techniques from a different language) will benefit the PHP community 
and existing users. A more focused language with better OO support and 
less inconsistency will benefit existing users doing new development.


> From an engineer's point of
> view you wouldn't alter a product to suit the desires of people who
> aren't even using it--because it's goddamn stupid.

Umm, if you were trying to sell a product and there was an untapped 
market, of course you would try to make future versions of your product 
more attractive to them. Now obviously, PHP isn't being made for money, 
but the developers probably have much the same goals as if they were 
indeed selling it.

In the same way that hosts have to make a decision - do we want to keep 
our existing customers happy by sticking with PHP 4 and push away 
potential customers to other hosts that run ASP .NET or Java, or do we 
want to attract new customers by running PHP 5 (or 6, when the time 
comes), at the expense of making our customers make some trivial 
revisions to their code? (When I say trivial, I mean that the actual 
replacements themselves are trivial, the scale of the job may not be...)

Personally, I can't see why hosts can't run both 4 and 5, and keep 
everyone happy.


>>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...?"
> 
> That's just igorance. We all know that using an array in this
> particular situation is easier. And once someone learn an easy way to
> do something, he/she wouldn't go back.

It's not necessarily about ignorance about individual issues. Being a 
good programmer/software designer is about being able to take a top-down 
view and work out, a priori, why certain approaches are better/more 
applicable than others, rather than having to be told on a case by case 
basis.


>>to which the answer is "use arrays instead", to which
>>their response is "well, my variables do the job, so why should I?".
> 
> Very good question to ask in fact. If all you can offer is a
> non-technical value-judgement: "it's good practice," then you're a sort
> of priest of programming, not a software engineer.

You're right, it is a good question.

We all know that there are sound reasons behind most "good practice" 
paradigms. The problem is that they're often quite hard to explain 
concisely to relative newbies whose first and only exposure to 
programming is PHP, and this is their only frame of reference. A frame 
of reference where so many things are allowable, many of which will kick 
them up the arse at a later date when their projects get larger and more 
complex, and they realise that there's more to creating software than 
just getting any old thing to work.

If someone's new to OO, for instance, but have found that there's this 
neat thing called classes, if they discover classes through PHP then 
more often than not they seem to end up trying to do things like using 
classes as glorified arrays ("how can I loop through my class 
members?"), or some bizarre reverse-polymorphism ("how can I find the 
name of the function that called/created my object, so that I can get it 
to different things accordingly?"). Completely missing the point, and 
therefore the benefits, of OO. Trying to explain to them why abstract 
base classes are beneficial, or why a class with only static members 
isn't the same as a singleton, or why polymorphism is better than 
dynamically defining classes, is extremely difficult.


-- 
Oli

Wayne wrote:
> A common Java idiom is:
>
> Foo foo  = new Foo();
>
> The convention in Java is that class names begin with an upper-case
> letter and variables begin with a lowercase variable.  I can clearly
> see what is happening here.
>
> To get the same meaning if it was case-insensitive, you'd have to do
> something like:
>
> FooClass fooInstance = new FooClass()
>
> Which makes readability worse, not better.

In Delphi, the convention is to begin class name with the letter T.

foo :TFoo
[...]
foo := TFoo.Create();

The readability here is superior here than what you have in Java,
especially for letters where capitalization involves only a size
change: "Window window," "Vector vector," "Stream stream," etc.

>> I disagree. I have worked for decades with case-insensitive languages
>> and I have always treated $FOO and $foo as the same variable.

> But I didn't say $FOO or $Foo.  I said $foo and $foO!

Any programmer who deliberately mixes case like that is a candidate for
the unemployment queue.

>  People have no
> trouble will all caps or the first letter capitalized.  What about the
> difference between setsLower() and setSlower()?  To a human reader
> those have different meanings,

Not to me, they don't. When writing a program I am writing in a
language that a computer understands, so I have to *think* like a
computer. To a computer the case of a word is irrelevant, and so is
it's pronunciation.

> to a case-insensitive compiler they are
> the same.

And to a person who has been using case-insensitive compilers for 30
years they are the same.

>> some like all upper case,

> My god.  I wouldn't want my code constantly shouting at me.  All upper
> case is harder to read, too.

In my current (non-PHP) contract the convention is that everything
which is part of the language (variable and function names) is
lowercase while evreything created by a programmer is in UPPER case.
Different organisations have different conventions, but if the compiler
is case-insensitive I really don't see the point. The argument that the
use of case *must* be consistent doesn't hold water. It's so low on the
scale of things which are *imporatnt* that it doesn't even register.

>> What I object to is being told that I MUST use one case or the other just to be
>> *consistent* with everyone else, especially when I disagree with their
>> reason for choosing one case over the other in the first place.

> The majority of programmers disagree with you on this.  Consistency
> and conventions are preferred when working on a particular project or
> platform --  it cuts down on errors and allows one to convey greater
> meaning.

I disagree. The majority of programmers that I have worked with on
case-insensitive languages do NOT like being told that case is suddenly
important, that you must use one in preference to the other. It is like
saying that although the language allows you to do something either
*this* way or *that* way from now on everybody MUST do it *that* way
for no other reason than to be consistent.

>> By introducing case-sensitivity you are suddenly saying that $FOO and
>> $foo are now different, which goes against the grain of everything that
>> I have been taught since my first day at school way back in the last
>> century.

> A common Java idiom is:

> Foo foo  = new Foo();

> The convention in Java is that class names begin with an upper-case
> letter and variables begin

Who gives a toss about how java does it? This is a PHP topic.

>> Your second statement contradicts the first, but at last you agree that
>> having $FOO and $foo point to different things is not a good thing.

> It's not exactly a contradiction...  I wouldn't allow both $foo and
> $FOO in the same program.  In a case-insentive language that's
> allowed.  I would want that completely disallowed.

So you are forcing your personal preferences upon everyone else. That
sucks.

>> That is what I have been used to for decades, and I see absolutely no
>> advantage in being forced to switch.

> So you're main argument is that it's not what you're used to -- so it
> should be changed.  Isn't that the attitude that your entire article
> was arguing against??

So why should I have to change MY programming habits just to match YOUR
programming habits? Who put you in charge?

>> You are talking about the *contents* of variables, whereas I am talking
>> about the *names* of variables. There is a BIG difference between the
>> two.

> Umm, no I'm not.  All languages are written in English and ASCII.
> Java, for example, is written in Unicode (UTF-8).

It does not matter what character set any language or tool is written
in, it can easily perform case insensitive searches. Introducing
case-sensitivty is an entirely artificial and (IMHO) unnecessary
restriction.

>> No, I'm asking you. What problem existed in the case-insensitive world
>> that could ONLY be solved by introducing case-sensitivity?

> Many many years ago it was done for compiler performance reasons.  It
> does require lots of extra cycles to lower-case every single
> identifier in a large C application.

On all the hardware I have worked on for the past 30 years the extra
processing cycles for performng case-insensitive searches was never
deemed to be significant. Certainly not important enough to remove the
ability for case-insensitive searches.

If it was done in the C compiler then I can only surmise that the C
compiler was written by idiots.

> Might seem like a poor reason now, but as a COBOL/Mainframe programmer
> should appreciate it -- It was only 2 extra bytes to store the entire
> year but somebody decided that was too much.

Back in those days it was the enormous cost of data storage that made
people store years in 2 bytes instead of 4. But nobody even thought of
reducing processing cycles by eliminating case-insensitive searches as
the loss of that functionality was deemed too great.

tony@marston-home.demon.co.uk wrote:
>>>I disagree. I have worked for decades with case-insensitive languages
>>>and I have always treated $FOO and $foo as the same variable.
> 
> 
>>But I didn't say $FOO or $Foo.  I said $foo and $foO!
> 
> 
> Any programmer who deliberately mixes case like that is a candidate for
> the unemployment queue.
> 
> 
>> People have no
>>trouble will all caps or the first letter capitalized.  What about the
>>difference between setsLower() and setSlower()?  To a human reader
>>those have different meanings,
> 
> 
> Not to me, they don't. When writing a program I am writing in a
> language that a computer understands, so I have to *think* like a
> computer. To a computer the case of a word is irrelevant, and so is
> it's pronunciation.
> 
> 
>>to a case-insensitive compiler they are
>>the same.
> 
> 
> And to a person who has been using case-insensitive compilers for 30
> years they are the same.
> 

Sorry, Tony, this last statement is incorrect.

I first learned Fortran back in the 60's.  Much more than 30 years ago.

Yet when I converted to one of the more modern languages (C in my case) 
I didn't have any trouble getting used to the case sensitivity.  Sure, 
at first it was awkward.  But not any more.

Since then I've also gotten into C++, Java, JavaScript and PHP, among 
other languages.  All are case sensitive.  And I have no problems with 
them.  And I still do some Fortran and a couple of other non-case 
sensitive languages.

So - as a person who has been using case-insensitive compilers for over 
30 years, they are NOT the same.

Hey - get over it.  It's called progress.  Someone earlier pointed out - 
in the 60's everything was upper case because punch cards only handled 
upper case.  I'll add that most printers only had upper case chars on 
their chains.  But we don't have that artificial limitation any more. 
And case sensitivity can make programs more readable, if used properly.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

tony@marston-home.demon.co.uk wrote:
>>>What I object to is being told that I MUST use one case or the other just to be
>>>*consistent* with everyone else, especially when I disagree with their
>>>reason for choosing one case over the other in the first place.
> 
> 
>>The majority of programmers disagree with you on this.  Consistency
>>and conventions are preferred when working on a particular project or
>>platform --  it cuts down on errors and allows one to convey greater
>>meaning.
> 
> 
> I disagree. The majority of programmers that I have worked with on
> case-insensitive languages do NOT like being told that case is suddenly
> important, that you must use one in preference to the other. It is like
> saying that although the language allows you to do something either
> *this* way or *that* way from now on everybody MUST do it *that* way
> for no other reason than to be consistent.
> 

He didn't say "The majority of programmers that you have worked with on
 > case-insensitive languages".

He said "The majority of programmers" - a much larger group.  And I have 
to agree with him.

I've also taught C, C++ and Java to COBOL programmers.  Sure, they had 
trouble getting used to the case sensitivity.  But most got used to it. 
  Only those who refused to change didn't.

But then if they had their way we'd probably still be programming with 
switches on the front panel.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

tony@marston-home.demon.co.uk wrote:
>>>That is what I have been used to for decades, and I see absolutely no
>>>advantage in being forced to switch.
> 
> 
>>So you're main argument is that it's not what you're used to -- so it
>>should be changed.  Isn't that the attitude that your entire article
>>was arguing against??
> 
> 
> So why should I have to change MY programming habits just to match YOUR
> programming habits? Who put you in charge?
> 

You don't have to change your programming habits to match my programming 
habits.  You do, however, need to match the requirements of the language.

In PHP, for instance, you don't have an IDENTIFICATION-DIVISION (Cobol) 
nor a FORMAT statement (Fortran).

Don't like it?  Don't use it.  But don't expect the rest of the world to 
change just because YOU don't like it.  Nobody put you in charge!

Or, create your own language which is case insensitive, build 
compilers/interpreters needed to use it, and get people to use it.  Then 
you will be in charge, and can make the rules.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle said the following on 22/12/2005 16:38:
> tony@marston-home.demon.co.uk wrote:
> 
<SNIP ARGUMENTS FOR CASE-INSENSITIVITY>
>>
> 
<SNIP ARGUMENTS FOR CASE-SENSITIVITY>


I think the issue of case sensitivity/insensitivity is one where 
everyone just has to agree to disagree. It's one of those issues that 
everyone prefers what they're used to, and there's no fundamental 
arguments either way, just like for indent style.

Personally, I prefer the consistency that case-sensitivity imposes, but 
that's probably because I spend most of my time using case-sensitive 
languages. Whenever I see HTML, PHP or whatever where there's 
inconsistency within the same file, then I immediately assume that the 
author is lazy or sloppy, but again, that's probably down to what I'm 
used to.


-- 
Oli

tony@marston-home.demon.co.uk wrote:

> t...@marston-home.demon.co.uk wrote:
> >> 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.
> 
> > I guess C, C++, and UNIX are not particularly popular.
> 
> They may be popular in some circles, but I have never travelled in
> those circles.

That's pretty dumb. That's like saying, "Fords are not popular cars
because I never drive them." Whether you like it or not, current
programming is dominated by C and C derivatives.

> >> For God's sake WHY! What problem existed in the
> >> case-insensitive world that needed to be fixed?
> 
> > Ask Dennis Ritchie.
> 
> No, I'm asking you. What problem existed in the case-insensitive world
> that could ONLY be solved by introducing case-sensitivity?

I don't know, and don't really care. It's a pretty pointless
discussion. Languages that are case sensitive are not going to change
because a minority of programmers dislikes that feature.


Brian

-- 
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.

On 22 Dec 2005 08:05:57 -0800, tony@marston-home.demon.co.uk wrote:

>>> By introducing case-sensitivity you are suddenly saying that $FOO and
>>> $foo are now different, which goes against the grain of everything that
>>> I have been taught since my first day at school way back in the last
>>> century.
>
>> A common Java idiom is:
>
>> Foo foo  = new Foo();
>
>> The convention in Java is that class names begin with an upper-case
>> letter and variables begin
>
>Who gives a toss about how java does it? This is a PHP topic.

You're the one talking about case-insensitive languages!  I toss a
case-sensitive language in and you get all touchy.

On 22 Dec 2005 07:54:07 -0800, tony@marston-home.demon.co.uk wrote:

>> But I didn't say $FOO or $Foo.  I said $foo and $foO!
>
>Any programmer who deliberately mixes case like that is a candidate for
>the unemployment queue.

So then, why should the programming language allow it?!?

>The majority of programmers that I have worked with on
>case-insensitive languages do NOT like being told that case is suddenly
>important, that you must use one in preference to the other. 

Ok...  so let me get this straight.  First you say that mixing cases
is bad and then you say that programmers don't like being told that
case is suddenly important.  Those two things are contradictory.
Either case isn't important and programmers can mix case at will or
case is importantant.  Give me one good reason why the language should
not enforce solid industry practices and keep poor unknowning
programmers out of the unemployment queue?

>*this* way or *that* way from now on everybody MUST do it *that* way
>for no other reason than to be consistent.

You just argued for that consistency in the first line of your post.

>>  People have no
>> trouble will all caps or the first letter capitalized.  What about the
>> difference between setsLower() and setSlower()?  To a human reader
>> those have different meanings,
>
>Not to me, they don't. 

So lets say we're in a case-insensitive language and the function I
described above is listed in the program with both those cases.  Tell
me, please, what does that function do?

>And to a person who has been using case-insensitive compilers for 30
>years they are the same.

Sadly, you're in the minority.  Majority rules.

On 22 Dec 2005 08:08:53 -0800, tony@marston-home.demon.co.uk wrote:

>>> Your second statement contradicts the first, but at last you agree that
>>> having $FOO and $foo point to different things is not a good thing.
>
>> It's not exactly a contradiction...  I wouldn't allow both $foo and
>> $FOO in the same program.  In a case-insentive language that's
>> allowed.  I would want that completely disallowed.
>
>So you are forcing your personal preferences upon everyone else. That
>sucks.

No, I'd be making the language safer by disallowing stupid mistakes
and inconsistency.

Do you actually have an argument for the alternative or is it all just
personal perferences for you?

>> >> For God's sake WHY! What problem existed in the
>> >> case-insensitive world that needed to be fixed?

From my point of view, the case-sensitive world existed
first.

>> > Ask Dennis Ritchie.
>> 
>> No, I'm asking you. What problem existed in the case-insensitive world
>> that could ONLY be solved by introducing case-sensitivity?

What problem existed in the case-sensitive world that could only be
solved by introducing case-insensitivity?

>I don't know, and don't really care. It's a pretty pointless
>discussion. Languages that are case sensitive are not going to change
>because a minority of programmers dislikes that feature.

Ok, here's one problem that case-insensitivity has that case-sensitivity
doesn't:  determine whether or not two characters are the same
(except possibly for case) for all characters in ISO 10646, on a
machine with a 64k address space.  Do all countries even AGREE on
what character codes correspond to 'a' except for case?  It would
be VERY BAD for two variable names to represent the same variable
in some countries and not in others.  How often will it be necessary
for this software to be updated?  (Of course, C wimps out on this
by not allowing most of those characters in variable names anyway.)

					Gordon L. Burditt

Oli Filth wrote:
> I think the issue of case sensitivity/insensitivity is one where
> everyone just has to agree to disagree. It's one of those issues that
> everyone prefers what they're used to, and there's no fundamental
> arguments either way, just like for indent style.

Agreeing to disagree isn't a terribly good solution here, as it's a
zero-sum game. Case-sensitivity precludes using identifiers in
different cases to refer to the same thing, while case-insensitivity
makes it impossible to use identifiers in different cases to refer to
different things. Since I do neither, I don't feel strongly one way or
the other. If we forgo the "4 out of 5 dentists prefer..." style of
arguments though and look at the what each system allows, I think we
can come to some kind of a conclusion.

Case-sensitivity let you use identical tokens spelled in different
cases to refer to different things. I don't think I have heard a single
argument in favor of this practice, aside from an "oh, the Java folks
are doing it." Capitalization is a device usually used for emphasis and
conveying emotion. It's a poor choice for as a signifier, as it's not
easy to see in print and cannot be communicated at all vocally.

Case-insensitivity let you use identical tokens in different cases to
refer to the same thing. Is there any practical use of this? As I said,
capitalization is a device usually used for emphasis and conveying
emotion. A programmer could potentially use it to draw attention to
particular places in the code. For instance, I could see a convention
whereby a variable name is capitalized when its value is being altered.
Not a usage I'd promote, but intriguing nonetheless.

Thus, I would say that a case-insensitive language is marginally more
useful.

Oli Filth wrote:
> In the 21st Century, where programming is as much about team-based
> development and code maintenance planning as it is about knocking out
> lines of code, aesthetics *are* massively important, IMO. Code that's
> more consistent and easier to read is easier to understand, and easier
> to hand over to another team member.

Put two fellows in a room thinking aesthetics are massively important
and you will see how productive that is. Office politics is detrimental
as it is. The last thing I would want to do is to inject more
subjective issues into the mix. Tolerance for different approaches and
the acceptance that different people think differently are what makes a
productive team.

As I said before, computer languages are not unlike human languages.
Speak in a straight forward manner and to the point--you will be
understood. It's not that hard. Pepper your speech with the latest
buzzwards and citations then neither the computer or your colleagues
will understand you.

> It's not a matter of trying to "convert" people, no-one's going to go
> "oh, I've seen the light, PHP is better than C++, what have I been doing
> all these years". But a large user-base (and incoming users with skills
> and techniques from a different language) will benefit the PHP community
> and existing users. A more focused language with better OO support and
> less inconsistency will benefit existing users doing new development.
>
> Umm, if you were trying to sell a product and there was an untapped
> market, of course you would try to make future versions of your product
> more attractive to them. Now obviously, PHP isn't being made for money,
> but the developers probably have much the same goals as if they were
> indeed selling it.

Your logic doesn't quite follow there. If these programmers of yours,
those who are laughing at PHP as we speak, if they don't see that it is
better than what they're currently using, then where do you find these
experienced warm bodies to swell the user-base?

A community of programmers who is strongly attached to the
characteristics of a particular language (so much so that they laugh at
languages that don't have them) is a very tapped market I would say.

> Personally, I can't see why hosts can't run both 4 and 5, and keep
> everyone happy.

Because you can't, at least not in Apache.

> It's not necessarily about ignorance about individual issues. Being a
> good programmer/software designer is about being able to take a top-down
> view and work out, a priori, why certain approaches are better/more
> applicable than others, rather than having to be told on a case by case
> basis.

Engineering as a discipline is largely based on a posteriori knowledge.


> We all know that there are sound reasons behind most "good practice"
> paradigms.

Not really. There are genuine good practices that make your life
easier, and there are persuasions by vain individuals trying to get you
to do things their way.

> If someone's new to OO, for instance

And why is he "new to OO?" It is a mystery isn't it? Here we have an
individual trying to write a script that does something. Out of blue he
suddenly thinks that OO is the way--then proceed to get it completely
wrong. What was going on in his head? Why did he choose OO when he
doesn't actually know it? And what is compelling the poor guy to
persist in this futile exercise? You would think, after trying
unsuccessfully to loop through an object, he would wisen up and use a
real array instead. Hmmm...

Jerry Stuckle wrote:
> tony@marston-home.demon.co.uk wrote:
> >>>What I object to is being told that I MUST use one case or the other just to be
> >>>*consistent* with everyone else, especially when I disagree with their
> >>>reason for choosing one case over the other in the first place.
> >
> >>The majority of programmers disagree with you on this.  Consistency
> >>and conventions are preferred when working on a particular project or
> >>platform --  it cuts down on errors and allows one to convey greater
> >>meaning.
> >
> > I disagree. The majority of programmers that I have worked with on
> > case-insensitive languages do NOT like being told that case is suddenly
> > important, that you must use one in preference to the other. It is like
> > saying that although the language allows you to do something either
> > *this* way or *that* way from now on everybody MUST do it *that* way
> > for no other reason than to be consistent.
> >
>
> He didn't say "The majority of programmers that you have worked with on
>  > case-insensitive languages".
>
> He said "The majority of programmers" - a much larger group.  And I have
> to agree with him.
>
> I've also taught C, C++ and Java to COBOL programmers.  Sure, they had
> trouble getting used to the case sensitivity.  But most got used to it.
>   Only those who refused to change didn't.

There is a big difference between *allowing* the programmer to choose
which case to use, and *forcing* the programmer to use a particular
case.

What I find annoying is the potential for case-sensitive languages to
allow the same variable or function name to exist AND BE DIFFERENT
ENTITIES. If the language could automatically correct what I typed in
to be in the same case (or mixture of case when camelcaps are used) as
the entity I was referring to I would have less reason to object. But
this is only possible with statically typed languages where everything
has to be declared up front. That doesn't work with dynamically typed
languages, therefore introducing case-sensitivity creates more problems
than it causes and should be avoided.

> But then if they had their way we'd probably still be programming with
> switches on the front panel.

At least the switches weren't case sensitive.

Jerry Stuckle wrote:
> tony@marston-home.demon.co.uk wrote:
> > So why should I have to change MY programming habits just to match YOUR
> > programming habits? Who put you in charge?
> >
>
> You don't have to change your programming habits to match my programming
> habits.  You do, however, need to match the requirements of the language.

The current requirement of PHP is that only variable names are
case-sensitive. What I am doing is arguing against the proposal that
function names also be made case-sensitive for no other reason than "to
bring it into line with other languages".

I will never, ever agree that case matters. It was only introduced in
the first place because those stupid unix programmers didn't know any
better. Bungling amateurs!

Wayne wrote:
> On 22 Dec 2005 07:54:07 -0800, tony@marston-home.demon.co.uk wrote:
>
> >> But I didn't say $FOO or $Foo.  I said $foo and $foO!
> >
> >Any programmer who deliberately mixes case like that is a candidate for
> >the unemployment queue.
>
> So then, why should the programming language allow it?!?
>
> >The majority of programmers that I have worked with on
> >case-insensitive languages do NOT like being told that case is suddenly
> >important, that you must use one in preference to the other.
>
> Ok...  so let me get this straight.  First you say that mixing cases
> is bad and then you say that programmers don't like being told that
> case is suddenly important.  Those two things are contradictory.

What I'm saying is that some teams like their variable names in all
upper case, while others like them all lower case. Either is
acceptable, but mixing case in the same variable name is frowned upon
by both camps.

> Either case isn't important and programmers can mix case at will or
> case is importantant.  Give me one good reason why the language should
> not enforce solid industry practices and keep poor unknowning
> programmers out of the unemployment queue?
>
> >*this* way or *that* way from now on everybody MUST do it *that* way
> >for no other reason than to be consistent.
>
> You just argued for that consistency in the first line of your post.
>
> >>  People have no
> >> trouble will all caps or the first letter capitalized.  What about the
> >> difference between setsLower() and setSlower()?  To a human reader
> >> those have different meanings,
> >
> >Not to me, they don't.
>
> So lets say we're in a case-insensitive language and the function I
> described above is listed in the program with both those cases.  Tell
> me, please, what does that function do?

The function name is listed only once, but it can be invoked in either
upper or lower case. Any language that deliberately allowed the same
function name to do different things just because of a change in case
would be rejected by most programmers. I am fighting AGAINST
introducing case-sensitivity for the simple reason that it would allow
that situation to happen.

Default User wrote:
> tony@marston-home.demon.co.uk wrote:
>
> > >> For God's sake WHY! What problem existed in the
> > >> case-insensitive world that needed to be fixed?
> >
> > > Ask Dennis Ritchie.
> >
> > No, I'm asking you. What problem existed in the case-insensitive world
> > that could ONLY be solved by introducing case-sensitivity?
>
> I don't know, and don't really care. It's a pretty pointless
> discussion. Languages that are case sensitive are not going to change
> because a minority of programmers dislikes that feature.

But why should a language which currently has case-insensitive function
names be forced to change? Especially when this would allow the
potentially confusing and dangerous situtation where the same function
name could be declared more than once with different mixtures of case,
thereby creating totally different functions. Are you saying this would
be a good idea? It appears that you are.

Wayne wrote:
> On 22 Dec 2005 08:08:53 -0800, tony@marston-home.demon.co.uk wrote:
>
> >So you are forcing your personal preferences upon everyone else. That
> >sucks.
>
> No, I'd be making the language safer by disallowing stupid mistakes
> and inconsistency.

You would allow a situation where the SAME function name could be
declared in different places with different mixtures of case, thereby
creating DIFFERENT functions, and you call this SAFER? What planet do
you live on?

Gordon Burditt wrote:
> >> >> For God's sake WHY! What problem existed in the
> >> >> case-insensitive world that needed to be fixed?
>
> From my point of view, the case-sensitive world existed
> first.

I disagree. The first computers allowed nothing but upper case, but
when lower case became available neither the operating systems nor the
compilers cared which case was used because they were totally
insensitive. None of the mainframe, mini or micro computers that I have
ever worked on has been case-sensitive.

> >> > Ask Dennis Ritchie.
> >>
> >> No, I'm asking you. What problem existed in the case-insensitive world
> >> that could ONLY be solved by introducing case-sensitivity?
>
> What problem existed in the case-sensitive world that could only be
> solved by introducing case-insensitivity?

Your question is rubbish as computers were case-insensitive to begin
with. Case sensitivity only arose because of a stupid mistake by those
bungling unix programmers.

> >I don't know, and don't really care. It's a pretty pointless
> >discussion. Languages that are case sensitive are not going to change
> >because a minority of programmers dislikes that feature.
>
> Ok, here's one problem that case-insensitivity has that case-sensitivity
> doesn't:  determine whether or not two characters are the same
> (except possibly for case) for all characters in ISO 10646, on a
> machine with a 64k address space.  Do all countries even AGREE on
> what character codes correspond to 'a' except for case?  It would
> be VERY BAD for two variable names to represent the same variable
> in some countries and not in others.  How often will it be necessary
> for this software to be updated?  (Of course, C wimps out on this
> by not allowing most of those characters in variable names anyway.)

I am not talking about any character string that can be entered by any
user in any language, I am talking about what the language will allow
for function names and variable names. I think you will find this to be
more restrictive, therefore less of a problem when case-insensitive
matching is required.

<tony@marston-home.demon.co.uk> wrote in message 
news:1135328348.078891.300880@g49g2000cwa.googlegroups.com...
>
> Jerry Stuckle wrote:
>> tony@marston-home.demon.co.uk wrote:
>> >>>What I object to is being told that I MUST use one case or the other 
>> >>>just to be
>> >>>*consistent* with everyone else, especially when I disagree with their
>> >>>reason for choosing one case over the other in the first place.
>> >
>> >>The majority of programmers disagree with you on this.  Consistency
>> >>and conventions are preferred when working on a particular project or
>> >>platform --  it cuts down on errors and allows one to convey greater
>> >>meaning.
>> >
>> > I disagree. The majority of programmers that I have worked with on
>> > case-insensitive languages do NOT like being told that case is suddenly
>> > important, that you must use one in preference to the other. It is like
>> > saying that although the language allows you to do something either
>> > *this* way or *that* way from now on everybody MUST do it *that* way
>> > for no other reason than to be consistent.
>> >
>>
>> He didn't say "The majority of programmers that you have worked with on
>>  > case-insensitive languages".
>>
>> He said "The majority of programmers" - a much larger group.  And I have
>> to agree with him.
>>
>> I've also taught C, C++ and Java to COBOL programmers.  Sure, they had
>> trouble getting used to the case sensitivity.  But most got used to it.
>>   Only those who refused to change didn't.
>
> There is a big difference between *allowing* the programmer to choose
> which case to use, and *forcing* the programmer to use a particular
> case.
>
> What I find annoying is the potential for case-sensitive languages to
> allow the same variable or function name to exist AND BE DIFFERENT
> ENTITIES.

But it's not the same variable or function name, it's different!! If I had 
variables $foo and $FOO, the other would be 0x66 0x6F 0x6F as ascii codes, 
the other 0x46 0x4F 0x4F. Those aren't the same.

In some spoken languages there are no upper and lower case, japanese for 
instance. In such a language it really doesn't matter which case you want to 
use, because there is no upper or lower.

If you've ever studied physics, you might've noticed how symbols are used in 
equations all the time. In that case, small and uppercase is everything. 
it's hell of a difference to write E=mc^2 than e=MC^2. The other is the 
Einsteins most famous equation Energy = mass * speed of light to second 
power, and the other is just non-sense, Napier's constant = mass of earth * 
capacitance to second power, or something like that.

In physics upper- and lower case symbols have totally different meanings. 
This is not directly applicable to php, but the world of physics with all 
the symbols and equations is a language that is globally understood 
regardless of it being case-sensitive. I don't expect to convince you that 
php should be case-sensitive, all I'm saying is that physics as well as 
mathematics sets an example of a case-sensitive language that really works. 
And it's been that way for quite a long time now, the history of math goes 
way back, thousands of years, before programming was even a concept.

-- 
"En ole paha ihminen, mutta omenat ovat elinkeinoni." -Perttu Sirvi�
antaatulla.sikanautaa@gmail.com.NOSPAM.invalid 

tony@marston-home.demon.co.uk wrote:
> Wayne wrote:
> 
>>On 22 Dec 2005 07:54:07 -0800, tony@marston-home.demon.co.uk wrote:
>>
>>
>>>>But I didn't say $FOO or $Foo.  I said $foo and $foO!
>>>
>>>Any programmer who deliberately mixes case like that is a candidate for
>>>the unemployment queue.
>>
>>So then, why should the programming language allow it?!?
>>
>>
>>>The majority of programmers that I have worked with on
>>>case-insensitive languages do NOT like being told that case is suddenly
>>>important, that you must use one in preference to the other.
>>
>>Ok...  so let me get this straight.  First you say that mixing cases
>>is bad and then you say that programmers don't like being told that
>>case is suddenly important.  Those two things are contradictory.
> 
> 
> What I'm saying is that some teams like their variable names in all
> upper case, while others like them all lower case. Either is
> acceptable, but mixing case in the same variable name is frowned upon
> by both camps.
> 
> 
>>Either case isn't important and programmers can mix case at will or
>>case is importantant.  Give me one good reason why the language should
>>not enforce solid industry practices and keep poor unknowning
>>programmers out of the unemployment queue?
>>
>>
>>>*this* way or *that* way from now on everybody MUST do it *that* way
>>>for no other reason than to be consistent.
>>
>>You just argued for that consistency in the first line of your post.
>>
>>
>>>> People have no
>>>>trouble will all caps or the first letter capitalized.  What about the
>>>>difference between setsLower() and setSlower()?  To a human reader
>>>>those have different meanings,
>>>
>>>Not to me, they don't.
>>
>>So lets say we're in a case-insensitive language and the function I
>>described above is listed in the program with both those cases.  Tell
>>me, please, what does that function do?
> 
> 
> The function name is listed only once, but it can be invoked in either
> upper or lower case. Any language that deliberately allowed the same
> function name to do different things just because of a change in case
> would be rejected by most programmers. I am fighting AGAINST
> introducing case-sensitivity for the simple reason that it would allow
> that situation to happen.
> 

Tony,

You're fighting a war you've already lost.  As others have said - the 
majority of programmers disagree with you.  Most of the newer languages 
are case sensitive.  And this is not going to change.

I'd suggest you move on with your life.  You are not going to win any 
converts to your antiquated thoughts here.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

tony@marston-home.demon.co.uk wrote:
> Jerry Stuckle wrote:
> 
>>tony@marston-home.demon.co.uk wrote:
>>
>>>>>What I object to is being told that I MUST use one case or the other just to be
>>>>>*consistent* with everyone else, especially when I disagree with their
>>>>>reason for choosing one case over the other in the first place.
>>>
>>>>The majority of programmers disagree with you on this.  Consistency
>>>>and conventions are preferred when working on a particular project or
>>>>platform --  it cuts down on errors and allows one to convey greater
>>>>meaning.
>>>
>>>I disagree. The majority of programmers that I have worked with on
>>>case-insensitive languages do NOT like being told that case is suddenly
>>>important, that you must use one in preference to the other. It is like
>>>saying that although the language allows you to do something either
>>>*this* way or *that* way from now on everybody MUST do it *that* way
>>>for no other reason than to be consistent.
>>>
>>
>>He didn't say "The majority of programmers that you have worked with on
>> > case-insensitive languages".
>>
>>He said "The majority of programmers" - a much larger group.  And I have
>>to agree with him.
>>
>>I've also taught C, C++ and Java to COBOL programmers.  Sure, they had
>>trouble getting used to the case sensitivity.  But most got used to it.
>>  Only those who refused to change didn't.
> 
> 
> There is a big difference between *allowing* the programmer to choose
> which case to use, and *forcing* the programmer to use a particular
> case.
> 
> What I find annoying is the potential for case-sensitive languages to
> allow the same variable or function name to exist AND BE DIFFERENT
> ENTITIES. If the language could automatically correct what I typed in
> to be in the same case (or mixture of case when camelcaps are used) as
> the entity I was referring to I would have less reason to object. But
> this is only possible with statically typed languages where everything
> has to be declared up front. That doesn't work with dynamically typed
> languages, therefore introducing case-sensitivity creates more problems
> than it causes and should be avoided.
> 
> 
>>But then if they had their way we'd probably still be programming with
>>switches on the front panel.
> 
> 
> At least the switches weren't case sensitive.
> 

Nobody is forcing you to choose which case to use.  You can use upper 
case, lower case or a mixture of cases for any of your function or 
variable names.

And sure, $Foo and $fOO can be different variables.  So what?  THAT'S 
HOW IT WORKS!

As for the language "automatically correct what I typed in"... No way. 
What if I WANT $Foo and $fOO to point to different variables?  Note that 
I am NOT saying this is "good programming" - but sure, it's possible. 
And I might at some time need that.

What you don't see is you're trying to force the rest of the world to 
conform to YOUR ideas of how programming should be.  Get a life - it 
ain't going to happen.  You're outnumbered too much.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Chung Leong said the following on 23/12/2005 03:27:
> Oli Filth wrote:
> 
>>I think the issue of case sensitivity/insensitivity is one where
>>everyone just has to agree to disagree. It's one of those issues that
>>everyone prefers what they're used to, and there's no fundamental
>>arguments either way, just like for indent style.
> 
> 
> Agreeing to disagree isn't a terribly good solution here, as it's a
> zero-sum game.

Much in the same way as it is for indentation style. In this case, there 
are differences, but the arguments presented aren't very convincing 
either way. It's not an argument that anyone's going to win, is it? So 
it's almost a waste of time even talking about it.

(However, I will say that PHP as it stands is a bit retarded, having 
case-sensitive variable names, but case-insensitive function names. How 
does that help anyone??)


> Case-sensitivity let you use identical tokens spelled in different
> cases to refer to different things. I don't think I have heard a single
> argument in favor of this practice, aside from an "oh, the Java folks
> are doing it." Capitalization is a device usually used for emphasis and
> conveying emotion. It's a poor choice for as a signifier, as it's not
> easy to see in print and cannot be communicated at all vocally.

Although I just said arguing about it is pointless, I will interject 
here anyway!

Kimmo made a good point elsewhere that capitalisation is used all the 
time in maths equations. A lot of what I do is maths-based, and base my 
code variable names on the variable names in the equation, 
capitalisation and all. e.g. if the maths is:

	        N
	F[k] = Sum (f[n].g[k])
	       n=1

i.e. the sum from 1 to N of f[n].g[k], I'll do:

	for (int n = 1; n <= N; ++n)
	{
		F[k] += f[n] * g[k];
	}

i.e. using both n and N (and f and F) to refer to different things. If 
one knows the maths that the code is implementing (if one didn't, then 
there'd be no point trying to read/debug/maintain the code), then one 
would know exactly what these variables meant.



-- 
Oli

tony@marston-home.demon.co.uk wrote:
> Jerry Stuckle wrote:
> 
>>tony@marston-home.demon.co.uk wrote:
>>
>>>So why should I have to change MY programming habits just to match YOUR
>>>programming habits? Who put you in charge?
>>>
>>
>>You don't have to change your programming habits to match my programming
>>habits.  You do, however, need to match the requirements of the language.
> 
> 
> The current requirement of PHP is that only variable names are
> case-sensitive. What I am doing is arguing against the proposal that
> function names also be made case-sensitive for no other reason than "to
> bring it into line with other languages".
> 
> I will never, ever agree that case matters. It was only introduced in
> the first place because those stupid unix programmers didn't know any
> better. Bungling amateurs!
> 

Then create your own language.

And no, it was NOT "introduce in the first place because those stupid 
unix programmers didn't know any better".  They knew what they were 
doing, and had a lot more experience than you did.  They were also able 
to create a language, compiler and operating system - all of which are 
amongst the most popular around even today.  "Bungling amateurs"?  I 
think not.

You go ahead and do the same. Then you can create a case-insensitive 
language.

But don't expect it it to be widely accepted.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On 23 Dec 2005 01:15:37 -0800, tony@marston-home.demon.co.uk wrote:

>Wayne wrote:
>> Ok...  so let me get this straight.  First you say that mixing cases
>> is bad and then you say that programmers don't like being told that
>> case is suddenly important.  Those two things are contradictory.
>
>What I'm saying is that some teams like their variable names in all
>upper case, while others like them all lower case. Either is
>acceptable, but mixing case in the same variable name is frowned upon
>by both camps.

Ok.  But that was my point.  What's the point of having
case-insensitivity if mixing cases is frowned upon.  Clearly you only
want to one case spelling of a function or variable to be valid.

>> >>  People have no
>> >> trouble will all caps or the first letter capitalized.  What about the
>> >> difference between setsLower() and setSlower()?  To a human reader
>> >> those have different meanings,
>> >
>> >Not to me, they don't.
>>
>> So lets say we're in a case-insensitive language and the function I
>> described above is listed in the program with both those cases.  Tell
>> me, please, what does that function do?
>
>The function name is listed only once, but it can be invoked in either
>upper or lower case. 

You didn't answer my question!  -5 points for you!

Saying that the programmer must go find the original declared version
of the function to determine what it does, doesn't answer the
question.

On 23 Dec 2005 01:04:06 -0800, tony@marston-home.demon.co.uk wrote:

>> You don't have to change your programming habits to match my programming
>> habits.  You do, however, need to match the requirements of the language.
>
>The current requirement of PHP is that only variable names are
>case-sensitive. What I am doing is arguing against the proposal that
>function names also be made case-sensitive for no other reason than "to
>bring it into line with other languages".

Do you know why PHP functions are case-insensitive in the first place?
The original reason was because HTML tags were case-insensitive they
decided to also make PHP functions case-insensitive because it was
common (back in the day) to call PHP functions like tags <B><?php
somefunction() ?></B>

But guess what, in XHTML (and XML) tags are now case-sensitive too!
So even the original reason for PHP case-insensitive functions is now
gone.

>I will never, ever agree that case matters. 

For the next 100 years, you're going to be really disappointed.  Every
modern programming language of any consequence is case-sensitive.  You
might not like it, but you're going to have to live with it.

Kimmo Laine wrote:
> <tony@marston-home.demon.co.uk> wrote in message 
> news:1135328348.078891.300880@g49g2000cwa.googlegroups.com...

>>
>>There is a big difference between *allowing* the programmer to choose
>>which case to use, and *forcing* the programmer to use a particular
>>case.
>>
>>What I find annoying is the potential for case-sensitive languages to
>>allow the same variable or function name to exist AND BE DIFFERENT
>>ENTITIES.
> 
> 
> But it's not the same variable or function name, it's different!! If I had 
> variables $foo and $FOO, the other would be 0x66 0x6F 0x6F as ascii codes, 
> the other 0x46 0x4F 0x4F. Those aren't the same.
> 
This is proof by blatant assertion.
That it what you are trying to establish, and what Tony is challenging.

> In some spoken languages there are no upper and lower case, japanese for 
> instance. In such a language it really doesn't matter which case you want to 
> use, because there is no upper or lower.
> 
In no spoken language is there upper and lower case. Case is an aspect 
of (some) writing systems, not languages.

I don't think that my point is nitpicking, for the following reason:

Consider dictating a command, or some lines of a program, to somebody 
over the telephone (a fairly frequent activity in my software support 
job). You can dictate every individual character, but when there are 
words or number you usually don't have to - you can say "minus product" 
and most users will know to type "-product".
But when they are using a case-sensitive system, this is not enough. You 
(may) have to say "minus product in capitals" or "minus product with 
capital p".
I'm not talking particularly the inconvenience and possibility for error 
in this (though they are there) - after all, there's nothing to stop me 
saying "minus capital-p little-r little o ..." etc.
What I'm doing is supporting Tony's contention that to people "PRODUCT", 
"product" and "Product" are the same thing.

As I said in a previous post, I have long thought that case sensitivity 
was an utterly bad idea. In the case of PHP I nevertheless felt that 
PHP5 marked a step forward over PHP4, but Tony has changed my mind.
The one place where it has improved things (that I can now say
class MyClass
....
if get_class($var, 'MyClass') ...
and have it work)
is not enough to justify the change.

> If you've ever studied physics, you might've noticed how symbols are used in 
> equations all the time. In that case, small and uppercase is everything. 
> it's hell of a difference to write E=mc^2 than e=MC^2. The other is the 
> Einsteins most famous equation Energy = mass * speed of light to second 
> power, and the other is just non-sense, Napier's constant = mass of earth * 
> capacitance to second power, or something like that.
> 
> In physics upper- and lower case symbols have totally different meanings. 
> This is not directly applicable to php, but the world of physics with all 
> the symbols and equations is a language that is globally understood 
> regardless of it being case-sensitive. I don't expect to convince you that 
> php should be case-sensitive, all I'm saying is that physics as well as 
> mathematics sets an example of a case-sensitive language that really works. 
> And it's been that way for quite a long time now, the history of math goes 
> way back, thousands of years, before programming was even a concept.
> 
This is a feeble argument. The symbols used in physics are almost always 
single letters. This is a very different case from multi-letter 
identifiers (which are in many cases words, or made of parts of words).

Colin

Jerry Stuckle wrote:
> tony@marston-home.demon.co.uk wrote:
> 
>>>> What I object to is being told that I MUST use one case or the other 
>>>> just to be
>>>> *consistent* with everyone else, especially when I disagree with their
>>>> reason for choosing one case over the other in the first place.
>>
>>
>>
>>> The majority of programmers disagree with you on this.  Consistency
>>> and conventions are preferred when working on a particular project or
>>> platform --  it cuts down on errors and allows one to convey greater
>>> meaning.
>>
>>
>>
>> I disagree. The majority of programmers that I have worked with on
>> case-insensitive languages do NOT like being told that case is suddenly
>> important, that you must use one in preference to the other. It is like
>> saying that although the language allows you to do something either
>> *this* way or *that* way from now on everybody MUST do it *that* way
>> for no other reason than to be consistent.
>>
> 
> He didn't say "The majority of programmers that you have worked with on
>  > case-insensitive languages".
> 
> He said "The majority of programmers" - a much larger group.  And I have 
> to agree with him.
> 
> I've also taught C, C++ and Java to COBOL programmers.  Sure, they had 
> trouble getting used to the case sensitivity.  But most got used to it. 
>  Only those who refused to change didn't.
> 
> But then if they had their way we'd probably still be programming with 
> switches on the front panel.
> 

The unsupported assumption - or insinuation - that the other party in an 
argument is somehow on the side of the past is a worthless and rather 
despicable kind of argument.

Colin

Jerry Stuckle wrote:
> tony@marston-home.demon.co.uk wrote:
> 
>> Jerry Stuckle wrote:
>>
>>> tony@marston-home.demon.co.uk wrote:
>>>
>>>> So why should I have to change MY programming habits just to match YOUR
>>>> programming habits? Who put you in charge?
>>>>
>>>
>>> You don't have to change your programming habits to match my programming
>>> habits.  You do, however, need to match the requirements of the 
>>> language.
>>
>>
>>
>> The current requirement of PHP is that only variable names are
>> case-sensitive. What I am doing is arguing against the proposal that
>> function names also be made case-sensitive for no other reason than "to
>> bring it into line with other languages".
>>
>> I will never, ever agree that case matters. It was only introduced in
>> the first place because those stupid unix programmers didn't know any
>> better. Bungling amateurs!
>>
> 
> Then create your own language.
> 
> And no, it was NOT "introduce in the first place because those stupid 
> unix programmers didn't know any better".  They knew what they were 
> doing, and had a lot more experience than you did.  They were also able 
> to create a language, compiler and operating system - all of which are 
> amongst the most popular around even today.  "Bungling amateurs"?  I 
> think not.
> 
More argument by blatant assertion. Nobody is disputing the achievements 
of the unix developers, but that doesn't mean that everything they did 
was perfect. I agree with Tony that case sensitivity was an enormous 
mistake.


> You go ahead and do the same. Then you can create a case-insensitive 
> language.
> 
> But don't expect it it to be widely accepted.
> 
You're probably right. But don't suppose that popularity has very much 
to do with merit.

Colin

Colin Fine wrote:
> Jerry Stuckle wrote:
> 
>> tony@marston-home.demon.co.uk wrote:
>>
>>>>> What I object to is being told that I MUST use one case or the 
>>>>> other just to be
>>>>> *consistent* with everyone else, especially when I disagree with their
>>>>> reason for choosing one case over the other in the first place.
>>>
>>>
>>>
>>>
>>>> The majority of programmers disagree with you on this.  Consistency
>>>> and conventions are preferred when working on a particular project or
>>>> platform --  it cuts down on errors and allows one to convey greater
>>>> meaning.
>>>
>>>
>>>
>>>
>>> I disagree. The majority of programmers that I have worked with on
>>> case-insensitive languages do NOT like being told that case is suddenly
>>> important, that you must use one in preference to the other. It is like
>>> saying that although the language allows you to do something either
>>> *this* way or *that* way from now on everybody MUST do it *that* way
>>> for no other reason than to be consistent.
>>>
>>
>> He didn't say "The majority of programmers that you have worked with on
>>  > case-insensitive languages".
>>
>> He said "The majority of programmers" - a much larger group.  And I 
>> have to agree with him.
>>
>> I've also taught C, C++ and Java to COBOL programmers.  Sure, they had 
>> trouble getting used to the case sensitivity.  But most got used to 
>> it.  Only those who refused to change didn't.
>>
>> But then if they had their way we'd probably still be programming with 
>> switches on the front panel.
>>
> 
> The unsupported assumption - or insinuation - that the other party in an 
> argument is somehow on the side of the past is a worthless and rather 
> despicable kind of argument.
> 
> Colin
> 

Nope. That's exactly where he is.  The (old) languages he's used are not 
case sensitive, so no language should be.

If that's not being "on the side of the past", what it?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Colin Fine wrote:
> Jerry Stuckle wrote:

> More argument by blatant assertion. Nobody is disputing the achievements 
> of the unix developers, but that doesn't mean that everything they did 
> was perfect. I agree with Tony that case sensitivity was an enormous 
> mistake.
>

Well, it's a hell a lot more than you've done, isn't it?  And since they 
created the language, they get to set the rules.

It really doesn't matter if you agree or not.  The fact is the vast 
majority of programmers in this world disagree with you.

Progress ALWAYS has its detractors.

> 
>> You go ahead and do the same. Then you can create a case-insensitive 
>> language.
>>
>> But don't expect it it to be widely accepted.
>>
> You're probably right. But don't suppose that popularity has very much 
> to do with merit.

If a language has enough merit, it will become popular.  Examples 
include C, C++, Java and PHP.  All have significant merit in what their 
areas, and all have become widely accepted.

> 
> Colin


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Colin Fine wrote:
> 
>> Jerry Stuckle wrote:
>>
>>> tony@marston-home.demon.co.uk wrote:
>>>
>>>>>> What I object to is being told that I MUST use one case or the 
>>>>>> other just to be
>>>>>> *consistent* with everyone else, especially when I disagree with 
>>>>>> their
>>>>>> reason for choosing one case over the other in the first place.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> The majority of programmers disagree with you on this.  Consistency
>>>>> and conventions are preferred when working on a particular project or
>>>>> platform --  it cuts down on errors and allows one to convey greater
>>>>> meaning.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I disagree. The majority of programmers that I have worked with on
>>>> case-insensitive languages do NOT like being told that case is suddenly
>>>> important, that you must use one in preference to the other. It is like
>>>> saying that although the language allows you to do something either
>>>> *this* way or *that* way from now on everybody MUST do it *that* way
>>>> for no other reason than to be consistent.
>>>>
>>>
>>> He didn't say "The majority of programmers that you have worked with on
>>>  > case-insensitive languages".
>>>
>>> He said "The majority of programmers" - a much larger group.  And I 
>>> have to agree with him.
>>>
>>> I've also taught C, C++ and Java to COBOL programmers.  Sure, they 
>>> had trouble getting used to the case sensitivity.  But most got used 
>>> to it.  Only those who refused to change didn't.
>>>
>>> But then if they had their way we'd probably still be programming 
>>> with switches on the front panel.
>>>
>>
>> The unsupported assumption - or insinuation - that the other party in 
>> an argument is somehow on the side of the past is a worthless and 
>> rather despicable kind of argument.
>>
>> Colin
>>
> 
> Nope. That's exactly where he is.  The (old) languages he's used are not 
> case sensitive, so no language should be.
> 
> If that's not being "on the side of the past", what it?
>

So your logic is "this is how we do it now, therefore it must be better"?
Perhaps it's not progress - perhaps it's nothing more than fashion.

Nobody's given a convincing reason why case sensitivity is better. (The 
nearest to it is the stuff about the cost of doing the comparisons. That 
might have been an issue when Unix and C started up, but it's not very 
convincing today.).


You may well be right that it will become increasingly difficult to find 
systems that aren't case insensitive. But I've yet to hear a reason why 
this is to be welcomed, while I do know a couple of reasons not to 
welcome it.

Colin

Jerry Stuckle wrote:
> Colin Fine wrote:
> 
>> Jerry Stuckle wrote:
> 
> 
>> More argument by blatant assertion. Nobody is disputing the 
>> achievements of the unix developers, but that doesn't mean that 
>> everything they did was perfect. I agree with Tony that case 
>> sensitivity was an enormous mistake.
>>
> 
> Well, it's a hell a lot more than you've done, isn't it?  And since they 
> created the language, they get to set the rules.
> 
> It really doesn't matter if you agree or not.  The fact is the vast 
> majority of programmers in this world disagree with you.
> 
> Progress ALWAYS has its detractors.
> 
WHY IS IT PROGRESS?????

PHP5 is a vast improvement on PHP4 in a number of ways. But they could 
equally well have resolved the inconsistency between variable and 
function names by removing case sensitivity for the former.
>>
>>> You go ahead and do the same. Then you can create a case-insensitive 
>>> language.
>>>
>>> But don't expect it it to be widely accepted.
>>>
>> You're probably right. But don't suppose that popularity has very much 
>> to do with merit.
> 
> 
> If a language has enough merit, it will become popular.  Examples 
> include C, C++, Java and PHP.  All have significant merit in what their 
> areas, and all have become widely accepted.
> 
You've chosen four popular languages and said, look they're popular. 
What about the hundreds of language you've never heard of. I have no 
doubt some of them had considerable merit.

Colin

Colin Fine wrote:
> Jerry Stuckle wrote:
> 
>> Colin Fine wrote:
>>
>>> Jerry Stuckle wrote:
>>>
>>>> tony@marston-home.demon.co.uk wrote:
>>>>
>>>>>>> What I object to is being told that I MUST use one case or the 
>>>>>>> other just to be
>>>>>>> *consistent* with everyone else, especially when I disagree with 
>>>>>>> their
>>>>>>> reason for choosing one case over the other in the first place.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The majority of programmers disagree with you on this.  Consistency
>>>>>> and conventions are preferred when working on a particular project or
>>>>>> platform --  it cuts down on errors and allows one to convey greater
>>>>>> meaning.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I disagree. The majority of programmers that I have worked with on
>>>>> case-insensitive languages do NOT like being told that case is 
>>>>> suddenly
>>>>> important, that you must use one in preference to the other. It is 
>>>>> like
>>>>> saying that although the language allows you to do something either
>>>>> *this* way or *that* way from now on everybody MUST do it *that* way
>>>>> for no other reason than to be consistent.
>>>>>
>>>>
>>>> He didn't say "The majority of programmers that you have worked with on
>>>>  > case-insensitive languages".
>>>>
>>>> He said "The majority of programmers" - a much larger group.  And I 
>>>> have to agree with him.
>>>>
>>>> I've also taught C, C++ and Java to COBOL programmers.  Sure, they 
>>>> had trouble getting used to the case sensitivity.  But most got used 
>>>> to it.  Only those who refused to change didn't.
>>>>
>>>> But then if they had their way we'd probably still be programming 
>>>> with switches on the front panel.
>>>>
>>>
>>> The unsupported assumption - or insinuation - that the other party in 
>>> an argument is somehow on the side of the past is a worthless and 
>>> rather despicable kind of argument.
>>>
>>> Colin
>>>
>>
>> Nope. That's exactly where he is.  The (old) languages he's used are 
>> not case sensitive, so no language should be.
>>
>> If that's not being "on the side of the past", what it?
>>
> 
> So your logic is "this is how we do it now, therefore it must be better"?
> Perhaps it's not progress - perhaps it's nothing more than fashion.
> 
> Nobody's given a convincing reason why case sensitivity is better. (The 
> nearest to it is the stuff about the cost of doing the comparisons. That 
> might have been an issue when Unix and C started up, but it's not very 
> convincing today.).
> 
> 
> You may well be right that it will become increasingly difficult to find 
> systems that aren't case insensitive. But I've yet to hear a reason why 
> this is to be welcomed, while I do know a couple of reasons not to 
> welcome it.
> 
> Colin
> 

Neither I nor anyone else needs to "give a convincing reason...". The 
bottom line is - that's the way things are, and it is supported by a 
vast majority of programmers.

However, there have been other reasons mentioned in this topic.  But I 
suspect none of them are "good enough" for you.

And I haven't heard any good reasons why NOT to welcome it.  Just saying 
$Foo and $fOO shouldn't point to different variables doesn't make it. 
To me they ARE different variables (although I wouldn't do this myself).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Colin Fine wrote:
> Jerry Stuckle wrote:
> 
>> Colin Fine wrote:
>>
>>> Jerry Stuckle wrote:
>>
>>
>>
>>> More argument by blatant assertion. Nobody is disputing the 
>>> achievements of the unix developers, but that doesn't mean that 
>>> everything they did was perfect. I agree with Tony that case 
>>> sensitivity was an enormous mistake.
>>>
>>
>> Well, it's a hell a lot more than you've done, isn't it?  And since 
>> they created the language, they get to set the rules.
>>
>> It really doesn't matter if you agree or not.  The fact is the vast 
>> majority of programmers in this world disagree with you.
>>
>> Progress ALWAYS has its detractors.
>>
> WHY IS IT PROGRESS?????
>

Because it's better, IMHO.  And if the majority of programmers didn't 
think it was progress, it wouldn't have caught on.

> PHP5 is a vast improvement on PHP4 in a number of ways. But they could 
> equally well have resolved the inconsistency between variable and 
> function names by removing case sensitivity for the former.
> 

And I could ask you why it's a vast improvement.  You'd have your 
opinions, but I wouldn't have to agree with them.

>>>
>>>> You go ahead and do the same. Then you can create a case-insensitive 
>>>> language.
>>>>
>>>> But don't expect it it to be widely accepted.
>>>>
>>> You're probably right. But don't suppose that popularity has very 
>>> much to do with merit.
>>
>>
>>
>> If a language has enough merit, it will become popular.  Examples 
>> include C, C++, Java and PHP.  All have significant merit in what 
>> their areas, and all have become widely accepted.
>>
> You've chosen four popular languages and said, look they're popular. 
> What about the hundreds of language you've never heard of. I have no 
> doubt some of them had considerable merit.
> 

Yep.  But about those other languages you mentioned.  Name some and 
their merits.  And if you can, why they failed.

> Colin


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Wayne" <not@here.com> wrote in message 
news:bteoq15jeoqlc2hka2k21jgoca2edmvbhj@4ax.com...
> On 23 Dec 2005 01:15:37 -0800, tony@marston-home.demon.co.uk wrote:
>
>>Wayne wrote:
>>> Ok...  so let me get this straight.  First you say that mixing cases
>>> is bad and then you say that programmers don't like being told that
>>> case is suddenly important.  Those two things are contradictory.
>>
>>What I'm saying is that some teams like their variable names in all
>>upper case, while others like them all lower case. Either is
>>acceptable, but mixing case in the same variable name is frowned upon
>>by both camps.
>
> Ok.  But that was my point.  What's the point of having
> case-insensitivity if mixing cases is frowned upon.  Clearly you only
> want to one case spelling of a function or variable to be valid.

By mixing case I mean mixing case in the same word. Some organisations like 
all upper case, some like all lower case, but NOBODY likes a mixture of case 
in the same word.  That is the difference.

>>> >>  People have no
>>> >> trouble will all caps or the first letter capitalized.  What about 
>>> >> the
>>> >> difference between setsLower() and setSlower()?  To a human reader
>>> >> those have different meanings,
>>> >
>>> >Not to me, they don't.
>>>
>>> So lets say we're in a case-insensitive language and the function I
>>> described above is listed in the program with both those cases.  Tell
>>> me, please, what does that function do?
>>
>>The function name is listed only once, but it can be invoked in either
>>upper or lower case.
>
> You didn't answer my question!  -5 points for you!

You name me any language that has the same function name listed more than 
once in a different case. You cannot because there is none. When you see a 
function name in a program and you check the manual for its description it 
doesn't matter whether it's expressed in upper case, lower case, or a 
mixture of case - that function name only has one entry. Just like in any 
language dictionary a word is only defined once, and it has exactly the same 
meaning whether it is written in upper or lower case.

> Saying that the programmer must go find the original declared version
> of the function to determine what it does, doesn't answer the
> question.

Any language that deliberately allows the same variable or function name to 
exist in more than one case, and to have different meanings for each 
combination of case would be immediately slammed as being a VERY BAD 
language. If a language enforces case-sensitivity by auto-correcting each 
name as you key it in, that is acceptable 

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:W5SdnSa__OoDxDDeRVn-ig@comcast.com...
> Colin Fine wrote:
>> Jerry Stuckle wrote:
>>
>>> tony@marston-home.demon.co.uk wrote:
>>>
>>
>
> Nope. That's exactly where he is.  The (old) languages he's used are not 
> case sensitive, so no language should be.
>
> If that's not being "on the side of the past", what it?

I never said that NO language should be case-sensitive, I said that a 
previously case-insensitive language should not be changed to being 
case-sensitive for no good reason other than "to be consistent with all the 
others". This is especially a BAD idea if the language then allows the SAME 
variable or function name to me different things just because of a change in 
case. As has already been stated by others, some languages are 
case-sensitive, but they detect the wrong case when the variable or function 
name is being typed in and auto correct it. 

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:_ZKdnVmWBtTBOTDenZ2dnUVZ_sCdnZ2d@comcast.com...
> Colin Fine wrote:
>> Nobody's given a convincing reason why case sensitivity is better. (The 
>> nearest to it is the stuff about the cost of doing the comparisons. That 
>> might have been an issue when Unix and C started up, but it's not very 
>> convincing today.).
>>
>>
>> You may well be right that it will become increasingly difficult to find 
>> systems that aren't case insensitive. But I've yet to hear a reason why 
>> this is to be welcomed, while I do know a couple of reasons not to 
>> welcome it.
>>
>> Colin
>>
>
> Neither I nor anyone else needs to "give a convincing reason...". The 
> bottom line is - that's the way things are, and it is supported by a vast 
> majority of programmers.
>
> However, there have been other reasons mentioned in this topic.  But I 
> suspect none of them are "good enough" for you.
>
> And I haven't heard any good reasons why NOT to welcome it.  Just saying 
> $Foo and $fOO shouldn't point to different variables doesn't make it. To 
> me they ARE different variables (although I wouldn't do this myself).

Why wouldn't you do it yourself? Because it would lead to confusing and 
unmentionable code, that's why. Any language that allows a programmer to 
create confusing and unmaintainable  code is a BAD language in my book. 

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:LYmdnewR-c7gxzDenZ2dnUVZ_sydnZ2d@comcast.com...
>
> It really doesn't matter if you agree or not.  The fact is the vast 
> majority of programmers in this world disagree with you.

Are you saying that the vast majority of programmers would agree with a 
language that allowed the same variable or function name to exist in 
different mixtures of upper and lower case, and for each combination of case 
to have a different meaning? That would make it far easier to write 
unmaintainable code. Would that be a good or a bad thing? 

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:nOKdneaa2_GSODDeRVn-og@comcast.com...
> Colin Fine wrote:
>>> Well, it's a hell a lot more than you've done, isn't it?  And since they 
>>> created the language, they get to set the rules.
>>>
>>> It really doesn't matter if you agree or not.  The fact is the vast 
>>> majority of programmers in this world disagree with you.
>>>
>>> Progress ALWAYS has its detractors.
>>>
>> WHY IS IT PROGRESS?????
>>
>
> Because it's better, IMHO.

Exactly why is case-sensitivity better? No human language allows a word to 
have a different meaning just by canging its case, so why should a computer 
language be different, espeically when that difference allows for 
unmaintainable code?

>  And if the majority of programmers didn't think it was progress, it 
> wouldn't have caught on.

Mere programmers don't have a choice, it's only the language authors that 
have a choice. And what was their reason for choosing case-sensitivity when 
all previous languages, whether human or computer, were entirely and 
completely case-insensitive? There is no good reason, which leads me to the 
conclusion that it was a STUPID MISTAKE that you are trying to perpetuate. 

Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:_ZKdnVmWBtTBOTDenZ2dnUVZ_sCdnZ2d@comcast.com...
> 
>>Colin Fine wrote:
>>
>>>Nobody's given a convincing reason why case sensitivity is better. (The 
>>>nearest to it is the stuff about the cost of doing the comparisons. That 
>>>might have been an issue when Unix and C started up, but it's not very 
>>>convincing today.).
>>>
>>>
>>>You may well be right that it will become increasingly difficult to find 
>>>systems that aren't case insensitive. But I've yet to hear a reason why 
>>>this is to be welcomed, while I do know a couple of reasons not to 
>>>welcome it.
>>>
>>>Colin
>>>
>>
>>Neither I nor anyone else needs to "give a convincing reason...". The 
>>bottom line is - that's the way things are, and it is supported by a vast 
>>majority of programmers.
>>
>>However, there have been other reasons mentioned in this topic.  But I 
>>suspect none of them are "good enough" for you.
>>
>>And I haven't heard any good reasons why NOT to welcome it.  Just saying 
>>$Foo and $fOO shouldn't point to different variables doesn't make it. To 
>>me they ARE different variables (although I wouldn't do this myself).
> 
> 
> Why wouldn't you do it yourself? Because it would lead to confusing and 
> unmentionable code, that's why. Any language that allows a programmer to 
> create confusing and unmaintainable  code is a BAD language in my book. 
> 
> 

You can create confusing and unmaintainable code in ANY language - even 
COBOL.  Case sensitivity has NOTHING to do with it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Tony Marston wrote:
>>Because it's better, IMHO.
> 
> 
> Exactly why is case-sensitivity better? No human language allows a word to 
> have a different meaning just by canging its case, so why should a computer 
> language be different, espeically when that difference allows for 
> unmaintainable code?
>

I'm not going to bite on that one any more.  Several people have tried 
to tell you.  Go back through this thread.  I'm not going to repeat 
their arguments.

The one exception I will make - when computers can understand verbal 
instructions (or even written instructions) like people do, then you can 
compare computer and human languages.  Until then, you are talking 
apples and oranges.

> 
>> And if the majority of programmers didn't think it was progress, it 
>>wouldn't have caught on.
> 
> 
> Mere programmers don't have a choice, it's only the language authors that 
> have a choice. And what was their reason for choosing case-sensitivity when 
> all previous languages, whether human or computer, were entirely and 
> completely case-insensitive? There is no good reason, which leads me to the 
> conclusion that it was a STUPID MISTAKE that you are trying to perpetuate. 
> 
> 

Horse Hockey.  EVERY programmer has a choice as to which language to use.

And quite frankly, most programmers I know would put you in the 
"old-timer-has-been-who-refuses-to-change-but-wants-everyone-else-to-change-to-suit-him" 

category.

And quite frankly, I really don't give a damn what you think.  So I'm 
not going to waste any more of my time.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:LYmdnewR-c7gxzDenZ2dnUVZ_sydnZ2d@comcast.com...
> 
>>It really doesn't matter if you agree or not.  The fact is the vast 
>>majority of programmers in this world disagree with you.
> 
> 
> Are you saying that the vast majority of programmers would agree with a 
> language that allowed the same variable or function name to exist in 
> different mixtures of upper and lower case, and for each combination of case 
> to have a different meaning? That would make it far easier to write 
> unmaintainable code. Would that be a good or a bad thing? 
> 
> 

They would agree with a languages that allows the same variable or 
function name to exist in different mixtures of case.  After all, 'a' is 
NOT the same character as 'A'.

They even agree that each combination of case could have a different 
meaning.

But they do not agree that it makes it far easier to write 
unmaintainable code.  You can do that in ANY language.

In fact, I find mixed case makes code MORE maintainable.

But I digress.  You're not worth any more of my time.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:4Lmdnd9W-pNukTPenZ2dnUVZ_tGdnZ2d@comcast.com...
> Tony Marston wrote:
>>>Neither I nor anyone else needs to "give a convincing reason...". The 
>>>bottom line is - that's the way things are, and it is supported by a vast 
>>>majority of programmers.
>>>
>>>However, there have been other reasons mentioned in this topic.  But I 
>>>suspect none of them are "good enough" for you.
>>>
>>>And I haven't heard any good reasons why NOT to welcome it.  Just saying 
>>>$Foo and $fOO shouldn't point to different variables doesn't make it. To 
>>>me they ARE different variables (although I wouldn't do this myself).
>>
>>
>> Why wouldn't you do it yourself? Because it would lead to confusing and 
>> unmentionable code, that's why. Any language that allows a programmer to 
>> create confusing and unmaintainable  code is a BAD language in my book.
>
> You can create confusing and unmaintainable code in ANY language - even 
> COBOL.  Case sensitivity has NOTHING to do with it.

Case-sensitivity is the whole point of this thread. Any language that has a 
feature which can be abused and which produces unmaintainable code is a BAD 
language. Any language that allows the same variable or function name to 
exist in different combinations of upper and lower case, and to give a 
different meaning to each of those combinations, is a BAD language. Case is 
irrelevant in all human languages, so it should be irrelevant in all 
computer languages.

Why do most modern languages exclude the GOTO statement? Because it is 
considered BAD.

Jus because some computer languages have case-sensitivity does not make it a 
good idea It is just a bad idea that is being perpetuated against all logic 
and reason. 

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:TomdnQ0jLryikzPenZ2dnUVZ_tOdnZ2d@comcast.com...
> Tony Marston wrote:
>>>Because it's better, IMHO.
>>
>>
>> Exactly why is case-sensitivity better? No human language allows a word 
>> to have a different meaning just by canging its case, so why should a 
>> computer language be different, espeically when that difference allows 
>> for unmaintainable code?
>>
>
> I'm not going to bite on that one any more.  Several people have tried to 
> tell you.  Go back through this thread.  I'm not going to repeat their 
> arguments.

Their arguments don't hold water. Saying that "it is this way becauseit's 
always been this way" is not an argument.

> The one exception I will make - when computers can understand verbal 
> instructions (or even written instructions) like people do, then you can 
> compare computer and human languages.  Until then, you are talking apples 
> and oranges.

Humans communicate with other humans using human language. Humans 
communicate with computers using a computer language, one that translates 
high-level commands into low-level machine instructions. Human and computer 
languages thereore have a single point of origin, and to say that they are 
like apples and oranges just shows the depth of your ignorance.

The first computer languages were case-insensitive, just like human 
languages. Then some UTTER MORON decided to break with a tradition that had 
existed since human language first appeared in written form and insisted 
that the SAME word in a DIFFERENT case now has a DIFFERENT meaning. The 
reason for this was probaby because he was too stupid or too lazy to perform 
case-insensitive searches of variable and function names.

>>
>>> And if the majority of programmers didn't think it was progress, it 
>>> wouldn't have caught on.
>>
>>
>> Mere programmers don't have a choice, it's only the language authors that 
>> have a choice. And what was their reason for choosing case-sensitivity 
>> when all previous languages, whether human or computer, were entirely and 
>> completely case-insensitive? There is no good reason, which leads me to 
>> the conclusion that it was a STUPID MISTAKE that you are trying to 
>> perpetuate.
>
> Horse Hockey.  EVERY programmer has a choice as to which language to use.

Most programmers have no choice. They have to use what their employer tells 
them to use.

> And quite frankly, most programmers I know would put you in the 
> "old-timer-has-been-who-refuses-to-change-but-wants-everyone-else-to-change-to-suit-him" 
> category.

I am not asking that all other languages be changed to suit MY taste, I am 
just asking that PHP not be changed to suit YOUR taste. I have worked for 30 
years with operating systems and compilers which were ALL case-insensitive, 
and I see no advantage in making the change, only disadvantages.

> And quite frankly, I really don't give a damn what you think.  So I'm not 
> going to waste any more of my time.

Just as I don't give a damn what you think. 

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:TomdnQwjLrxvkzPenZ2dnUVZ_tOdnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:LYmdnewR-c7gxzDenZ2dnUVZ_sydnZ2d@comcast.com...
>>
>>>It really doesn't matter if you agree or not.  The fact is the vast 
>>>majority of programmers in this world disagree with you.

I think not.

>> Are you saying that the vast majority of programmers would agree with a 
>> language that allowed the same variable or function name to exist in 
>> different mixtures of upper and lower case, and for each combination of 
>> case to have a different meaning? That would make it far easier to write 
>> unmaintainable code. Would that be a good or a bad thing?
>
> They would agree with a languages that allows the same variable or 
> function name to exist in different mixtures of case.

What do you mean by 'same'?

Are you saying that 'box', 'Box' and 'BOX' point to the same variable, or 3 
different variables?

Are you saying that 'dosomething()', 'doSomething()' and 'doSomeThing()' 
point to the same function, or 3 different functions?

Which would lead to confusing and unmaintainable code, and shuld therefore 
be avoided?

> After all, 'a' is NOT the same character as 'A'.

It may not be the same combination of bits in a computer language, but to a 
human it is the letter 'a' wit case bein irrelevant.

> They even agree that each combination of case could have a different 
> meaning.

I think not. Can you name me any computer language where the authors have 
deliberately created their own variable and function names in different 
mixtures of upper and lower case with a different meaning for each mixture? 
Why not? Because it would be confusing. You have already stated yourself 
that even though the language allows it you would not deliberately use 
different case on the same word to give different meanings. Why not? Because 
it would be confusing. So if there is a "feature" in the language that you 
would not use, and you agree that usig it would lead to confusing code, then 
why on earth do you want this "feature" to remain in the laguage. Why do you 
continue to insist that such a "feature" is a good idea? It does not sound 
very logical to me.

> But they do not agree that it makes it far easier to write unmaintainable 
> code.  You can do that in ANY language.

Yes, but as languages continue to evolve those constructs which are 
considered tooharmful, and which allow programmers to shoot themselves in 
the foot and produce spagetti or unmaintainale code are gradually 
eliminated. That is why the ALTER verb was removed from the COBOL standard. 
That is why GOTO was removed from subsequent languages. Remember, I 
programmed with COBOL for 16 years so I have direct experience of these.

> In fact, I find mixed case makes code MORE maintainable.

How? You have already stated that you would never personally write code that 
contained the same variable or function name in different mixtures of case, 
so you are avoiding something which you consider to be MORE maintainable, 
thereby producing code which is LESS mantainable. Your logic just boggles 
the mind.

> But I digress.  You're not worth any more of my time.

That's funny. I have the same opinion about you. 

Tony Marston wrote:
> 
> Case-sensitivity is the whole point of this thread. Any language that has a
> feature which can be abused and which produces unmaintainable code is a BAD
> language. Any language that allows the same variable or function name to

Then any language is bad by your definition.

> exist in different combinations of upper and lower case, and to give a
> different meaning to each of those combinations, is a BAD language. Case is
> irrelevant in all human languages, so it should be irrelevant in all
> computer languages.

That's not true. Anyone proficient in german can assure you that "Helft
den armen V�geln." and "Helft den Armen v�geln." means something
*completely* different! ;-)

> Why do most modern languages exclude the GOTO statement? Because it is
> considered BAD.

Do they? The last time I checked all modern languages get translated to
machine code at compile time and all machine languages I know have an
equivalent to GOTO, which is usually called JMP in Assembler.

Bye!

Tony Marston wrote:
>
> > I'm not going to bite on that one any more.  Several people have tried to
> > tell you.  Go back through this thread.  I'm not going to repeat their
> > arguments.
> 
> Their arguments don't hold water. Saying that "it is this way becauseit's
> always been this way" is not an argument.

I can agree with that, but...

> > The one exception I will make - when computers can understand verbal
> > instructions (or even written instructions) like people do, then you can
> > compare computer and human languages.  Until then, you are talking apples
> > and oranges.
> 
> Humans communicate with other humans using human language. Humans
> communicate with computers using a computer language, one that translates
> high-level commands into low-level machine instructions. Human and computer
> languages thereore have a single point of origin, and to say that they are
> like apples and oranges just shows the depth of your ignorance.

.... now you are getting ridiculous. Human languages and computer
languages might share the same origin, but they du not share the same
purpose.

Human languages developed over time. Words changed meanings and
spelling, the grammar changed, too. On top of that humans communicate
differently than machines. We have a lot of words that communicate
vagueness or uncertainty. How much is 'a lot of'?

Computer languages on the other hand were designed from the bottom up
and their only purpose is to eliminate any vagueness in communication so
that a machine that only knows logical states (0 or 1) can follow a set
of instructions in a concise and repeatable way.

That is why computer and human languages are *very* different. If it
were not so nobody would need programmers.

> The first computer languages were case-insensitive, just like human
> languages. Then some UTTER MORON decided to break with a tradition that had
> existed since human language first appeared in written form and insisted
> that the SAME word in a DIFFERENT case now has a DIFFERENT meaning. The
> reason for this was probaby because he was too stupid or too lazy to perform
> case-insensitive searches of variable and function names.

Complete nonsense. The first computer languages were case insensitive
because the first computers only had upper case letters. Human languages
on the other hand never were case insensitive.

> I am not asking that all other languages be changed to suit MY taste, I am
> just asking that PHP not be changed to suit YOUR taste. I have worked for 30
> years with operating systems and compilers which were ALL case-insensitive,
> and I see no advantage in making the change, only disadvantages.
> 

Don't make me laugh. I've been into computers for only about 22 years,
but I know computers like C64, VIC20 and PET and know why they were case
insensitive. Simply because they lacked lower case.

Bye!

Anonymous said the following on 25/12/2005 12:21:
> Tony Marston wrote:
> 
>>Why do most modern languages exclude the GOTO statement? Because it is
>>considered BAD.
> 
> 
> Do they? The last time I checked all modern languages get translated to
> machine code at compile time

Like C#, Java, PHP, VB, VBScript, JavaScript, Python and MATLAB do?


> and all machine languages I know have an
> equivalent to GOTO, which is usually called JMP in Assembler.

Yes, but the low-level constructs are usually completely abstracted by 
the high-level language, that's the point of a high-level language. The 
machine-code that a compiler/interpreter produces/invokes is just a 
method of implementing each of the high-level constructs - the fact that 
there's a GOTO construct at the machine level has no influence on 
whether there's a GOTO construct at the language level.


-- 
Oli

"Anonymous" <anonymous@nowhere.invalid> wrote in message 
news:43AE8ECF.54D24C7C@nowhere.invalid...
> Tony Marston wrote:
>>
>> Case-sensitivity is the whole point of this thread. Any language that has 
>> a
>> feature which can be abused and which produces unmaintainable code is a 
>> BAD
>> language. Any language that allows the same variable or function name to
>
> Then any language is bad by your definition.

Any language that allows stupid mistakes is a bad language. That's why some 
programmers say that statically-typed and compiled languages are better that 
dynamically-typed interpretted languages.

> That's not true. Anyone proficient in german can assure you that "Helft
> den armen V�geln." and "Helft den Armen v�geln." means something
> *completely* different! ;-)

Trust the bloody square-head sausage-eaters to throw a spanner in the works. 
But in ENGLISH, which is the universal language, there is no difference. 
Just check out any dictionary. Does it have separate entries in each case? 
No? I wonder why.....

"Anonymous" <anonymous@nowhere.invalid> wrote in message 
news:43AE9D06.62D24AE3@nowhere.invalid...
> Tony Marston wrote:
>>
>> > I'm not going to bite on that one any more.  Several people have tried 
>> > to
>> > tell you.  Go back through this thread.  I'm not going to repeat their
>> > arguments.
>>
>> Their arguments don't hold water. Saying that "it is this way becauseit's
>> always been this way" is not an argument.
>
> I can agree with that, but...
>
>> > The one exception I will make - when computers can understand verbal
>> > instructions (or even written instructions) like people do, then you 
>> > can
>> > compare computer and human languages.  Until then, you are talking 
>> > apples
>> > and oranges.
>>
>> Humans communicate with other humans using human language. Humans
>> communicate with computers using a computer language, one that translates
>> high-level commands into low-level machine instructions. Human and 
>> computer
>> languages thereore have a single point of origin, and to say that they 
>> are
>> like apples and oranges just shows the depth of your ignorance.
>
> ... now you are getting ridiculous. Human languages and computer
> languages might share the same origin, but they du not share the same
> purpose.

Yes they do, it's called *communication*. A computer language is used so 
that a human can tell a computer what instructions to follow. That is why 
COBOL was constructed around subjects, verbs, predicates, sentences and 
paragraphs.

> Human languages developed over time.

Having been in IT for over 30 years I have noticed that computer languages 
and operating systems evolve over time as well.

> Words changed meanings and
> spelling, the grammar changed, too. On top of that humans communicate
> differently than machines. We have a lot of words that communicate
> vagueness or uncertainty. How much is 'a lot of'?
>
> Computer languages on the other hand were designed from the bottom up
> and their only purpose is to eliminate any vagueness in communication so
> that a machine that only knows logical states (0 or 1) can follow a set
> of instructions in a concise and repeatable way.
>
> That is why computer and human languages are *very* different. If it
> were not so nobody would need programmers.

You would still need a method of allowing a human to communicate his wishes 
to the computer.

>> The first computer languages were case-insensitive, just like human
>> languages. Then some UTTER MORON decided to break with a tradition that 
>> had
>> existed since human language first appeared in written form and insisted
>> that the SAME word in a DIFFERENT case now has a DIFFERENT meaning. The
>> reason for this was probaby because he was too stupid or too lazy to 
>> perform
>> case-insensitive searches of variable and function names.
>
> Complete nonsense. The first computer languages were case insensitive
> because the first computers only had upper case letters. Human languages
> on the other hand never were case insensitive.

But when those early computers changed to character sets which allowed both 
upper and lower case they did not enforce one case or the other, thus 
becoming case-insensitive. How do I know this? BECAUSE I WAS THERE, DUMMY!

>> I am not asking that all other languages be changed to suit MY taste, I 
>> am
>> just asking that PHP not be changed to suit YOUR taste. I have worked for 
>> 30
>> years with operating systems and compilers which were ALL 
>> case-insensitive,
>> and I see no advantage in making the change, only disadvantages.
>>
>
> Don't make me laugh. I've been into computers for only about 22 years,
> but I know computers like C64, VIC20 and PET and know why they were case
> insensitive. Simply because they lacked lower case.

My experience is with *business* computers, not *hobby* computers. Before 
personal computers (known originally as micro-computers) came out I worked 
on mainframes and mini-computers, all of which had both upper and lower case 
and were insensitive to case. 

Tony Marston wrote:
> "Anonymous" <anonymous@nowhere.invalid> wrote in message 
> news:43AE8ECF.54D24C7C@nowhere.invalid...
> 
>>Tony Marston wrote:
>>
>>>Case-sensitivity is the whole point of this thread. Any language that has 
>>>a
>>>feature which can be abused and which produces unmaintainable code is a 
>>>BAD
>>>language. Any language that allows the same variable or function name to
>>
>>Then any language is bad by your definition.
> 
> 
> Any language that allows stupid mistakes is a bad language. That's why some 
> programmers say that statically-typed and compiled languages are better that 
> dynamically-typed interpretted languages.
> 
> 
>>That's not true. Anyone proficient in german can assure you that "Helft
>>den armen V�geln." and "Helft den Armen v�geln." means something
>>*completely* different! ;-)
> 
> 
> Trust the bloody square-head sausage-eaters to throw a spanner in the works. 
> But in ENGLISH, which is the universal language, there is no difference. 
> Just check out any dictionary. Does it have separate entries in each case? 
> No? I wonder why.....
> 
> 

Gee, another American who thinks he's the center of the universe...


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:Srednav30uFcmy3enZ2dnUVZ_s-dnZ2d@comcast.com...
> Tony Marston wrote:
>> "Anonymous" <anonymous@nowhere.invalid> wrote in message 
>> news:43AE8ECF.54D24C7C@nowhere.invalid...
>>
>>>Tony Marston wrote:
>>>
>>>>Case-sensitivity is the whole point of this thread. Any language that 
>>>>has a
>>>>feature which can be abused and which produces unmaintainable code is a 
>>>>BAD
>>>>language. Any language that allows the same variable or function name to
>>>
>>>Then any language is bad by your definition.
>>
>>
>> Any language that allows stupid mistakes is a bad language. That's why 
>> some programmers say that statically-typed and compiled languages are 
>> better that dynamically-typed interpretted languages.
>>
>>
>>>That's not true. Anyone proficient in german can assure you that "Helft
>>>den armen V�geln." and "Helft den Armen v�geln." means something
>>>*completely* different! ;-)
>>
>>
>> Trust the bloody square-head sausage-eaters to throw a spanner in the 
>> works. But in ENGLISH, which is the universal language, there is no 
>> difference. Just check out any dictionary. Does it have separate entries 
>> in each case? No? I wonder why.....
>>
>>
>
> Gee, another American who thinks he's the center of the universe...

No, I'm English, not American. And there was a time when we WERE the center 
of the universe. That's why English is the universal language. 

Jerry Stuckle wrote:
>> So your logic is "this is how we do it now, therefore it must be better"?
>> Perhaps it's not progress - perhaps it's nothing more than fashion.
>>
>> Nobody's given a convincing reason why case sensitivity is better. 
>> (The nearest to it is the stuff about the cost of doing the 
>> comparisons. That might have been an issue when Unix and C started up, 
>> but it's not very convincing today.).
>>
>>
>> You may well be right that it will become increasingly difficult to 
>> find systems that aren't case insensitive. But I've yet to hear a 
>> reason why this is to be welcomed, while I do know a couple of reasons 
>> not to welcome it.
>>
>> Colin
>>
> 
> Neither I nor anyone else needs to "give a convincing reason...". The 
> bottom line is - that's the way things are, and it is supported by a 
> vast majority of programmers.
> 
How's that again?

So "because most people like it that way" is a valid philosophical argument?

I'm not expecting, or suggesting, that case sensitivity is going to 
disappear. But that has no bearing at all on whether or not it is a 
thoroughly bad idea.

> However, there have been other reasons mentioned in this topic.  But I 
> suspect none of them are "good enough" for you.
> 
Really? The only reasons I can find in the trail (apart from the appeal 
to the  majority*, and the scurrilous insinuation that case insensitive 
is somehow of the past and therefore worthless) are a barely relevant 
point from physics and a specific operational issue in PHP (which is in 
any case dependent on case sensitivity in the OS).

* Did the majority ever vote on the topic? And don't say they did so by 
choosing C/Java/Perl: any of these could have been made case insensitive 
and there would have been essentially no difference; but they weren't 
offered.

> And I haven't heard any good reasons why NOT to welcome it.  Just saying 
> $Foo and $fOO shouldn't point to different variables doesn't make it. To 
> me they ARE different variables (although I wouldn't do this myself).
> 
The argument is that to people (you remember people? the things that 
write programs) 'project', 'Project' and 'PROJECT' *are* the same thing, 
and we all have to learn that we must always make a new distinction 
(which you have yet to demonstrate is useful) when we program.

Colin

Tony Marston wrote:
> "Anonymous" <anonymous@nowhere.invalid> wrote in message 
> news:43AE8ECF.54D24C7C@nowhere.invalid...
> 
>>Tony Marston wrote:
>>
>>>Case-sensitivity is the whole point of this thread. Any language that has 
>>>a
>>>feature which can be abused and which produces unmaintainable code is a 
>>>BAD
>>>language. Any language that allows the same variable or function name to
>>
>>Then any language is bad by your definition.
> 
> 
> Any language that allows stupid mistakes is a bad language. That's why some 
> programmers say that statically-typed and compiled languages are better that 
> dynamically-typed interpretted languages.
> 
> 
>>That's not true. Anyone proficient in german can assure you that "Helft
>>den armen V�geln." and "Helft den Armen v�geln." means something
>>*completely* different! ;-)
> 
> 
> Trust the bloody square-head sausage-eaters to throw a spanner in the works. 
> But in ENGLISH, which is the universal language, there is no difference. 
> Just check out any dictionary. Does it have separate entries in each case? 
> No? I wonder why.....
> 
> 
Umm - I think you are putting a bit of a spanner in your own argument 
here, Tony (witness the replies you got).

Yes, there are occasional cases where the case makes a difference, even 
in English (consider 'reading', 'polish' and 'natal'). But in most 
languages which use the Roman, Greek or Cyrillic alphabets the case is 
hardly ever significant. German is a sort of exception because all nouns 
are capitalised, but if I write V�GELN you can't tell whether it's the 
noun or the verb. And most other scripts don't have capitals (I think 
Armenian does, and Georgian uses a sort of capital for titles).

But this looks like the "I can't counter this argument so I'll pick him 
up on a triviality" defense from 'Anonymous'.

Colin

Jerry Stuckle wrote:
> Tony Marston wrote:
> 
>>> Because it's better, IMHO.
>>
>>
>>
>> Exactly why is case-sensitivity better? No human language allows a 
>> word to have a different meaning just by canging its case, so why 
>> should a computer language be different, espeically when that 
>> difference allows for unmaintainable code?
>>
> 
> I'm not going to bite on that one any more.  Several people have tried 
> to tell you.  Go back through this thread.  I'm not going to repeat 
> their arguments.
> 
> The one exception I will make - when computers can understand verbal 
> instructions (or even written instructions) like people do, then you can 
> compare computer and human languages.  Until then, you are talking 
> apples and oranges.
> 
No. Because it's apparently escaped your notice that most programs are 
written by people.

>>
>>> And if the majority of programmers didn't think it was progress, it 
>>> wouldn't have caught on.
>>
>>
>>
>> Mere programmers don't have a choice, it's only the language authors 
>> that have a choice. And what was their reason for choosing 
>> case-sensitivity when all previous languages, whether human or 
>> computer, were entirely and completely case-insensitive? There is no 
>> good reason, which leads me to the conclusion that it was a STUPID 
>> MISTAKE that you are trying to perpetuate.
>>
> 
> Horse Hockey.  EVERY programmer has a choice as to which language to use.
> 
Yes. But if all the languages they are being offered are case sensitive, 
that is what we may call a stacked deck.

> And quite frankly, most programmers I know would put you in the 
> "old-timer-has-been-who-refuses-to-change-but-wants-everyone-else-to-change-to-suit-him" 
> 
> category.
> 
I'm sorry? I think you mean the 
'old-timer-who-doesnt-see-the-need-to-change-something-that-works' category.

> And quite frankly, I really don't give a damn what you think.  So I'm 
> not going to waste any more of my time.
> 
You didn't have to reply to Tony's critique in the first place. But for 
some reason you took it as an attack you had to defend against.

Happy new year

Colin

Tony Marston wrote:

>>>
>>
>>I'm not going to bite on that one any more.  Several people have tried to 
>>tell you.  Go back through this thread.  I'm not going to repeat their 
>>arguments.
> 
> 
> Their arguments don't hold water. Saying that "it is this way becauseit's 
> always been this way" is not an argument.
> 
> 
>>The one exception I will make - when computers can understand verbal 
>>instructions (or even written instructions) like people do, then you can 
>>compare computer and human languages.  Until then, you are talking apples 
>>and oranges.
> 
> 
> Humans communicate with other humans using human language. Humans 
> communicate with computers using a computer language, one that translates 
> high-level commands into low-level machine instructions. Human and computer 
> languages thereore have a single point of origin, and to say that they are 
> like apples and oranges just shows the depth of your ignorance.
> 
> The first computer languages were case-insensitive, just like human 
> languages. Then some UTTER MORON decided to break with a tradition that had 
> existed since human language first appeared in written form and insisted 
> that the SAME word in a DIFFERENT case now has a DIFFERENT meaning. The 
> reason for this was probaby because he was too stupid or too lazy to perform 
> case-insensitive searches of variable and function names.
> 
Again you are allowing hyperbole (and vituperation) to pollute your 
argument. Case goes back not much more than a thousand years, and is 
only found in scripts developed in Europe.
Your point nevertheless stands, since the people in question were 
English speakers.
And I suspect that a major driver for case sensitivity in Unix was a 
demand for short options on the command line, so they chose to make '-b' 
and '-B' different in that context, and extended it to everywhere else.


Colin

Jerry Stuckle wrote:
> Tony Marston wrote:
> 
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:LYmdnewR-c7gxzDenZ2dnUVZ_sydnZ2d@comcast.com...
>>
>>> It really doesn't matter if you agree or not.  The fact is the vast 
>>> majority of programmers in this world disagree with you.
>>
>>
>>
>> Are you saying that the vast majority of programmers would agree with 
>> a language that allowed the same variable or function name to exist in 
>> different mixtures of upper and lower case, and for each combination 
>> of case to have a different meaning? That would make it far easier to 
>> write unmaintainable code. Would that be a good or a bad thing?
>>
> 
> They would agree with a languages that allows the same variable or 
> function name to exist in different mixtures of case.  After all, 'a' is 
> NOT the same character as 'A'.
> 
True. But 'a' is the same WORD as 'A'. And most variable names are (or 
are made of) words.

Colin

Colin Fine wrote:
> Jerry Stuckle wrote:
> 
>>
>> Neither I nor anyone else needs to "give a convincing reason...". The 
>> bottom line is - that's the way things are, and it is supported by a 
>> vast majority of programmers.
>>
> How's that again?
>
> So "because most people like it that way" is a valid philosophical 
> argument?
>

When the vast majority of programmers support the same philosophy, yes.

> I'm not expecting, or suggesting, that case sensitivity is going to 
> disappear. But that has no bearing at all on whether or not it is a 
> thoroughly bad idea.
> 
>> However, there have been other reasons mentioned in this topic.  But I 
>> suspect none of them are "good enough" for you.
>>
> Really? The only reasons I can find in the trail (apart from the appeal 
> to the  majority*, and the scurrilous insinuation that case insensitive 
> is somehow of the past and therefore worthless) are a barely relevant 
> point from physics and a specific operational issue in PHP (which is in 
> any case dependent on case sensitivity in the OS).
> 

You should read again.

> * Did the majority ever vote on the topic? And don't say they did so by 
> choosing C/Java/Perl: any of these could have been made case insensitive 
> and there would have been essentially no difference; but they weren't 
> offered.
>

But that's exactly how they voted.  They used the language.  If they 
wouldn't have liked case sensitivity, they didn't have to use the language.

And don't give me any "They had to because their boss made them" crap.

C++ followed C in its case sensitivity.  However, Java, PHP, etc. didn't 
need to be case sensitive.  They are because the original developers of 
these languages saw the advantages and popularity of other case 
sensitive languages.

>> And I haven't heard any good reasons why NOT to welcome it.  Just 
>> saying $Foo and $fOO shouldn't point to different variables doesn't 
>> make it. To me they ARE different variables (although I wouldn't do 
>> this myself).
>>
> The argument is that to people (you remember people? the things that 
> write programs) 'project', 'Project' and 'PROJECT' *are* the same thing, 
> and we all have to learn that we must always make a new distinction 
> (which you have yet to demonstrate is useful) when we program.
> 

Not to computers they aren't.  And when I'm programming, they aren't the 
same thing to me at all.

> Colin

Here's a suggestion.  Don't try to argue your philosophy in this 
newsgroup.  You can't win, and it just shows how stubborn, old fashioned 
or just plain out of date you really are.

Don't like PHP's case sensitivity?   DON'T USE IT!


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Colin Fine wrote:
> Jerry Stuckle wrote:
> 
>>
> No. Because it's apparently escaped your notice that most programs are 
> written by people.
>

So, what's your point?  They have to be understood by computers.  Why 
not just write in machine code?

>>
>> Horse Hockey.  EVERY programmer has a choice as to which language to use.
>>
> Yes. But if all the languages they are being offered are case sensitive, 
> that is what we may call a stacked deck.
>

Not at all.   There are a lot of languages which are not case dependent. 
  And if you don't like the options, create your own!

>> And quite frankly, most programmers I know would put you in the 
>> "old-timer-has-been-who-refuses-to-change-but-wants-everyone-else-to-change-to-suit-him" 
>>
>> category.
>>
> I'm sorry? I think you mean the 
> 'old-timer-who-doesnt-see-the-need-to-change-something-that-works' 
> category.
>

Nope, I meant *exactly* what I said.

>> And quite frankly, I really don't give a damn what you think.  So I'm 
>> not going to waste any more of my time.
>>
> You didn't have to reply to Tony's critique in the first place. But for 
> some reason you took it as an attack you had to defend against.
> 
> Happy new year
> 
> Colin

No, and I didn't have to reply to yours either.  But I did reply for the 
benefit of new people here.

I didn't take it as an attack.  I took it as a stupid statement by an 
uninformed, past-his-prime or too stubborn to change programmer.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Colin Fine wrote:
> Jerry Stuckle wrote:
> 
>> Tony Marston wrote:
>>
>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>> news:LYmdnewR-c7gxzDenZ2dnUVZ_sydnZ2d@comcast.com...
>>>
>>>> It really doesn't matter if you agree or not.  The fact is the vast 
>>>> majority of programmers in this world disagree with you.
>>>
>>>
>>>
>>>
>>> Are you saying that the vast majority of programmers would agree with 
>>> a language that allowed the same variable or function name to exist 
>>> in different mixtures of upper and lower case, and for each 
>>> combination of case to have a different meaning? That would make it 
>>> far easier to write unmaintainable code. Would that be a good or a 
>>> bad thing?
>>>
>>
>> They would agree with a languages that allows the same variable or 
>> function name to exist in different mixtures of case.  After all, 'a' 
>> is NOT the same character as 'A'.
>>
> True. But 'a' is the same WORD as 'A'. And most variable names are (or 
> are made of) words.
> 
> Colin

Not in C, C++, Java, etc. they aren't.  And we're talking COMPUTER 
languages here - not HUMAN languages.  Or can't you figure out the 
difference?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Don't like PHP's case sensitivity?   DON'T USE IT!

Errr...PHP is case insensitive in regards to function names. That some
people are agitating to make it case sensitive was the original point
of this dicussion.

"Colin Fine" <news@kindness.demon.co.uk> wrote in message 
news:dp6k28$cbr$1$8302bc10@news.demon.co.uk...
> Tony Marston wrote:
>> "Anonymous" <anonymous@nowhere.invalid> wrote in message 
>> news:43AE8ECF.54D24C7C@nowhere.invalid...
>>
>>>Tony Marston wrote:
>>>
>>>>Case-sensitivity is the whole point of this thread. Any language that 
>>>>has a
>>>>feature which can be abused and which produces unmaintainable code is a 
>>>>BAD
>>>>language. Any language that allows the same variable or function name to
>>>
>>>Then any language is bad by your definition.
>>
>>
>> Any language that allows stupid mistakes is a bad language. That's why 
>> some programmers say that statically-typed and compiled languages are 
>> better that dynamically-typed interpretted languages.
>>
>>
>>>That's not true. Anyone proficient in german can assure you that "Helft
>>>den armen V�geln." and "Helft den Armen v�geln." means something
>>>*completely* different! ;-)
>>
>>
>> Trust the bloody square-head sausage-eaters to throw a spanner in the 
>> works. But in ENGLISH, which is the universal language, there is no 
>> difference. Just check out any dictionary. Does it have separate entries 
>> in each case? No? I wonder why.....
>>
>>
> Umm - I think you are putting a bit of a spanner in your own argument 
> here, Tony (witness the replies you got).
>
> Yes, there are occasional cases where the case makes a difference, even in 
> English (consider 'reading', 'polish' and 'natal'). But in most languages 
> which use the Roman, Greek or Cyrillic alphabets the case is hardly ever 
> significant. German is a sort of exception because all nouns are 
> capitalised, but if I write V�GELN you can't tell whether it's the noun or 
> the verb. And most other scripts don't have capitals (I think Armenian 
> does, and Georgian uses a sort of capital for titles).

The fact that some human languages have words which can be either a noun or 
a  verb, with different capitalisation to distinguish between the two,  is 
irrelevant. In all computer languages variables and function names are 
easily distinguishable, therefore different capitalisation is irrelevant.

> But this looks like the "I can't counter this argument so I'll pick him up 
> on a triviality" defense from 'Anonymous'.

You are using elements of human language which do not exist in any computer 
language and are therefore irreevant.

Tony Marston 

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:oaSdnefEW7U0nirenZ2dnUVZ_tqdnZ2d@comcast.com...
> Colin Fine wrote:
>> Jerry Stuckle wrote:
>>
>>>
>> No. Because it's apparently escaped your notice that most programs are 
>> written by people.
>>
>
> So, what's your point?  They have to be understood by computers.  Why not 
> just write in machine code?

That argument is so stupid it is not worthy of reply. Except to point out 
that it IS stupid.

Tony Marston 

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:oaSdnebEW7VynirenZ2dnUVZ_tqdnZ2d@comcast.com...
> Colin Fine wrote:
>> Jerry Stuckle wrote:
>>
>>> Tony Marston wrote:
>>>
>>>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>>>> news:LYmdnewR-c7gxzDenZ2dnUVZ_sydnZ2d@comcast.com...
>>>>
>>>>> It really doesn't matter if you agree or not.  The fact is the vast 
>>>>> majority of programmers in this world disagree with you.
>>>>
>>>>
>>>>
>>>>
>>>> Are you saying that the vast majority of programmers would agree with a 
>>>> language that allowed the same variable or function name to exist in 
>>>> different mixtures of upper and lower case, and for each combination of 
>>>> case to have a different meaning? That would make it far easier to 
>>>> write unmaintainable code. Would that be a good or a bad thing?
>>>>
>>>
>>> They would agree with a languages that allows the same variable or 
>>> function name to exist in different mixtures of case.  After all, 'a' is 
>>> NOT the same character as 'A'.
>>>
>> True. But 'a' is the same WORD as 'A'. And most variable names are (or 
>> are made of) words.
>>
>> Colin
>
> Not in C, C++, Java, etc. they aren't.  And we're talking COMPUTER 
> languages here - not HUMAN languages.  Or can't you figure out the 
> difference?

But the point of this argument is that variable names such as 'box', 'Box' 
and 'BOX' should all indicate the same variable, not different variables. If 
you really want to have three different boxes you would use names such as 
'box1', 'box2' and 'box3' to avoid any confusion.

Is there any computer language which has built-in function and variable 
names which come with different capitalisation to me different things? If 
they do not make use of this feature, then why provide it in the first 
place?

Would any sensible programmer deliberately create the same function and 
variable names with different capitalisation to me different things? Would 
this make the program more or less maintainable? If no sensible programmer 
would use this feature, then why provide it in the first place?

Your argument seems to be "It exists, therefore it must be good".

My argument is "It is not good, therefore it should not exist".

Tony Marston 

Chung Leong wrote:
> Jerry Stuckle wrote:
> 
>>Don't like PHP's case sensitivity?   DON'T USE IT!
> 
> 
> Errr...PHP is case insensitive in regards to function names. That some
> people are agitating to make it case sensitive was the original point
> of this dicussion.
> 

Yep.  And some people would rather take away the case sensitivity for 
variables than add case sensitivity for functions.

I'm for consistency.  And I'm for case sensitivity in functions.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
> news:oaSdnebEW7VynirenZ2dnUVZ_tqdnZ2d@comcast.com...
> 
>>
>>Not in C, C++, Java, etc. they aren't.  And we're talking COMPUTER 
>>languages here - not HUMAN languages.  Or can't you figure out the 
>>difference?
> 
> 
> But the point of this argument is that variable names such as 'box', 'Box' 
> and 'BOX' should all indicate the same variable, not different variables. If 
> you really want to have three different boxes you would use names such as 
> 'box1', 'box2' and 'box3' to avoid any confusion.
> 
> Is there any computer language which has built-in function and variable 
> names which come with different capitalisation to me different things? If 
> they do not make use of this feature, then why provide it in the first 
> place?
> 
> Would any sensible programmer deliberately create the same function and 
> variable names with different capitalisation to me different things? Would 
> this make the program more or less maintainable? If no sensible programmer 
> would use this feature, then why provide it in the first place?
> 
> Your argument seems to be "It exists, therefore it must be good".
> 
> My argument is "It is not good, therefore it should not exist".
> 
> Tony Marston 
> 

You keep rehashing the same argument.  It's gone beyond stupid to inane, 
and soon to go beyond that.  I and others have already responded to 
these trite statements.  Yet you keep on.

Give it up, Tony.  You're showing how big of an ass you really are.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Yep.  And some people would rather take away the case sensitivity for
> variables than add case sensitivity for functions.

Personally, I would rather have case sensitivity in function name, but
only because it'd make things easier when you have to make calls from
Java/EMCAscript into PHP. I don't buy the argument that
case-sensitivity is inherently superior. And I'm definitely against
breaking backward compatibility.

> I'm for consistency.  And I'm for case sensitivity in functions.

That's a bogus association. Case-sensitivity does not equal
consistency. If you don't like identifiers spelled in different cases,
then don't do it. I don't see how you can, on one hand, defer to
programmers' good judgement in choosing reasonable case-sensitive names
(e.g. using Kool() and kooI() for different functions), yet not trust
them to use case in a reasonable manner in a case-insensitive scenario.
You argument is, if you please, inconsistent.

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
news:tYqdncSAJczKZyrenZ2dnUVZ_sqdnZ2d@comcast.com...
> Tony Marston wrote:
>> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message 
>> news:oaSdnebEW7VynirenZ2dnUVZ_tqdnZ2d@comcast.com...
>>
>>>
>>>Not in C, C++, Java, etc. they aren't.  And we're talking COMPUTER 
>>>languages here - not HUMAN languages.  Or can't you figure out the 
>>>difference?
>>
>>
>> But the point of this argument is that variable names such as 'box', 
>> 'Box' and 'BOX' should all indicate the same variable, not different 
>> variables. If you really want to have three different boxes you would use 
>> names such as 'box1', 'box2' and 'box3' to avoid any confusion.
>>
>> Is there any computer language which has built-in function and variable 
>> names which come with different capitalisation to me different things? If 
>> they do not make use of this feature, then why provide it in the first 
>> place?
>>
>> Would any sensible programmer deliberately create the same function and 
>> variable names with different capitalisation to me different things? 
>> Would this make the program more or less maintainable? If no sensible 
>> programmer would use this feature, then why provide it in the first 
>> place?
>>
>> Your argument seems to be "It exists, therefore it must be good".
>>
>> My argument is "It is not good, therefore it should not exist".
>>
>> Tony Marston
>
> You keep rehashing the same argument.  It's gone beyond stupid to inane, 
> and soon to go beyond that.  I and others have already responded to these 
> trite statements.  Yet you keep on.
>
> Give it up, Tony.  You're showing how big of an ass you really are.

I refuse to give it up for the simple reason that have yet to answer a 
simple question regarding case-sensitivity.

Would any sensible programmer deliberately create variable or function names 
in different mixtures of upper and lower case to mean different things? If, 
as I strongly believe, no sensible programmer would do this, then why allow 
the language to provide such a useless "feature" in the first place?

It's such a simple question, yet all you do is talk around it.

Tony Marston 

Wayne wrote:
> Do you know why PHP functions are case-insensitive in the first place?
> The original reason was because HTML tags were case-insensitive they
> decided to also make PHP functions case-insensitive because it was
> common (back in the day) to call PHP functions like tags <B><?php
> somefunction() ?></B>
>
> But guess what, in XHTML (and XML) tags are now case-sensitive too!
> So even the original reason for PHP case-insensitive functions is now
> gone.

Yeah, seeing how XHTML has taken the world by storm...

> For the next 100 years, you're going to be really disappointed.  Every
> modern programming language of any consequence is case-sensitive.  You
> might not like it, but you're going to have to live with it.

Well, SQL is not exactly inconsequential. Neither is Visual Basic or
Delphi--outside of academia in any event.