Re: Case sensitivity in programming languages.


"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message
news:RIGdnW6rU-wXbUzZnZ2dnUVZ_uWdnZ2d@xxxxxxxxxxxxxx
Tony Marston wrote:
"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message
news:44D105AB.20103@xxxxxxxxxxxxxxxx

Tony Marston wrote:

"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message
news:Cd-dne2roPe8tFLZnZ2dnUVZ_qudnZ2d@xxxxxxxxxxxxxx


Tony Marston wrote:


"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message
news:PO-dnZ9kL4xhvFPZnZ2dnUVZ_vKdnZ2d@xxxxxxxxxxxxxx



Tony Marston wrote:


<snip>

Case sensitivity can lead to unmaintainable code. For example, if
there is a variable called $foo I expect $Foo and $FOO to mean the
same thing, not different things. The fact that they are not can lead
to unexpected results. Programmers who deliberately create different
variables with the same name but different case are bad programmers,
but a *proper* language (such as COBOL) removes the possibility for
such bad programming by ignoring case and treating all the variables
as a single variable. Any language which deliberately allows
programmers to wrte unmaintainable code is a bad language. After all,
that is why most modern languages do not include GOTO because f the
problems it can cause.



Yes, I can see where having $foo, $Foo and $FOO be the same thing could
be very confusing. I would never code something like that, and it
would lead to terribly unmaintainable code in a case-insensitive
language. I don't know why anyone would ever want to do that.


Having $foo, $Foo and $FOO which mean the same thing in a
case-insensitive language does NOT lead to unmaintable code as much as
it does in a case sensitive language which makes them separate things. I
say his because I have worked for 25+ years with case insensitive
languages and seen different case used on different projects, and it has
never been a problem.


Using different case to mean the same thing throughout your code is
completely moronic.


Any programmer who deliberately changes case in a single program is an
idiot. However, there is and never has been a univesal standard for the
use of case. I have worked on many projects with many different teams who
have had totally different ideas:
(a) everything should be in lower case
(b) everything should be in lower case except database table and column
names
(c) everything should be in upper case except database table and column
names
(d) everything should be in lower case except calls to different
functions
(e) everything which is part of the core language should be in lower case
while everything defined by the programmer should be in upper case
(f) everything which is part of the core language should be in upper case
while everything defined by the programmer should be in lower case


I'm glad you admit someone who changes case in a single program is an
idiot. It shows you're an even bigger idiot because you fight so hard for
the ability to do it.

Wrong again. I am most defintely NOT fighting for the right to deiberately
use the same spelling but different case to produce different objects. I am
saying that where the spelling is the same but the case is different they
should e treated as the SAME object. It is YOU who wants the ability for
different case to crate different objects.

And yes, there are standards out there. But standards in modern languages
are typically more well defined and accepted than those in COBOL.

There are standards which are requirements of a particular language, and
standards which are simply the conventions and personal choices of one group
of programmers. I do not like the personal choices of one group of
programmers being turned into "standards" which are then forced upon all
prgrammers. I am big enouh (and ugly enough) to make my own choices, and I
choose to dislike the problems that case sensitve software causes.

How many more possibilities are there? The point is that if the lanuage
is insensitive to case there is no reason to pick on any one of those
conventions and make it a rule. Having a rule for the use of case does
not serve any useful purpose, just as the EU rule on the shape of bananas
does not serve any useful pupose. I never had any problem in reading the
code that was written to all those eifferent conventions, and neither did
anybody else. The only *problem* was when some officious twit would point
out that a piece of code did not follow his personal conventions. I would
always ask the question "What problem does it cause?" His answer would
always be "None, but it does not follow the stadards". I would then ask
him if he had any problem reading the code, or if the computer had any
problem executing the code. If his response was "No" then I would inform
hm that this was in fact a non-problem and not wort wasting any time
over.


Standards are important. It seems you're a rogue. I've had idiots like
you on teams before - didn't want to follow standards, etc. None of them
were worth a damn as a programmer - they used the standards as an excuse
for writing poor code. But that wasn't the problem.

And none of them stayed very long on my projects.

There is no such thing as a universal set of standards, and there never will
be. I've worked on many different projects with many different teams, and
the variety of diferent "standards" I have seen has been truly amazing. The
only common feature I can recall in all these different standards is that
they are littered with "do it this way" without explaining the reason why,
or giving any jusification. With standards such as these it is often
different to write good code AND fllow the standards. The two usually end up
being mutually exclusive.

Your idea of "standards" would probably make me vomit.


I learned that even when I was doing case-insensitive languages such as
FORTRAN and PL/I. Anyone who did that was considered to be either a
noob or a piss-poor programmer.


People who invent rules which serve no useful purpose other than to have
a rule are far worse (IMHO) than the people who break those stupid rules.


And people stick to archaic practices just because they're too stupid or
stubborn to change to new ways of doing things. Which are you?

I have seen the problems that case sensitive languages cause, and I have
seen the coplete absence of these problems in case insensitive languages. I
prefer the languages which have the ability to cause fewer problems. If that
is your definition of "stupid" then you have a real problem.

Fortunately, in a case-sensitive language such as PHP, C, Java and many
others, that's not a problem. It makes those languages much more
maintainable.


I disagree. Having $foo, $Foo and $FOO mean different things causes more
problems than it solves, as does haing different functions called
readfile(), readFile() and ReadFile(). Nobody in their right minds would
deliebrately write such obfuscated code, therefore the language should
protect the programmer from making such a stupid mistake by being
insensitive to case. Afetr all, most languages deliberetel do not incude
the GOTO verb for that very same reason.


But they are completely different things.


'box', 'Box' and 'BOX' are the same thing in the english language, and
they mean the same thing in case insensitve languages. It is only case
sensitive languages that make it an issue.


In COBOL, yes. And YOUR example is true in English. However, you
completely ignore cases where that isn't true (like Shelly's example).

But first of all, the world doesn't run on English. It's not even the
most widely spoken language in the world. And as has been pointed out to
you, other languages have different rules.

Why not write everything in German in lower case?

I am not advocating for all human languages to be caseless. Stop creating
pointless arguments.

Then you can be taken as a complete idiot by Germans, also - just as you
are here.

And BTW - we're not writing English. There is no word such as "fopen" in
English, for instance. We're writing PHP. Different language, different
rules.


As for your function names - often times readfile() will be a global
function, while readFile() would be a member of a class. Most
programmers I know wouldn't use ReadFile().


That is only by programmer convention, it is not a language reqirement.
Besides, PHP does not have such issues:
foobar() is a function
$foobar is a variable
$object->foobar() is a class method
$object-foobar is a class property

PHP does not need to use different mxtures of case to provide the means
to differentiate between those different types.


No, it doesn't NEED to. But it takes advantage of the ABILITY TO.

And you agree that the ability to have functions such as readfile(),
readFile() and ReadFile() is a GOOD THING? Are you KIDDING?

It's a good thing modern languages have gone beyond the arbitrary
restrictions of older languages like COBOL and FORTRAN.


Since when does being insenstive to case become an arbitrary
restriction?


It means you can't have readfile() and readFile().


But if the language IS case sensitive then you CAN. readfile(),
readFile() and ReadFile() become totally differet functions. How
confusing is that?


Only to you. They would be in different contexts, and therefore have
different meanings.

Hands up all those programmers who would be happy working on a project which
had different functions called readfile(), readFile() and ReadFile()

And I wouldn't say a language which allows programmers to write
unmaintainable code is a bad language.


Then why do most languages not allow the unstructured GOTO? Surely for
clever programmers who need such a verb, the fact that it is not allowed
is much more of a restriction than case insensitivity?


Actually, most languages DO allow unstructured GOTO. It's just not used
much in structured languages. There are much better ways of doing it.


But some, like PHP, do not. Even if it were intoduced I would probably
avoid it conflicts with the idea of structured code. But the point is,
even in those languages which provide GOTO its use is *optional* and not
a *requirement*. The use of case started of as an option, but suddenly
became a requirement, and THAT is what I oject to.


No problem. Go back to your beloved COBOL. No one is forcing you to
write PHP. And the world isn't going to change just because one stoopid
Neanderthal named Tony Marston wants it to change.

But now you're changing your argument again - because another one fell
apart. ROFLMAO!

No, I'm not changing my argument. I still think case senstive languages
suck, and I always will. Having case sensitivity never solved any problems,
it only created them.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org


.

Relevant Pages

  • Re: RAC or Large SMP...?
    ... the lack of good support in many ... The few languages that provide such support ... towards programmers that are API driven code monkeys that have little ... parallelized applications will have to do the analysis and design work that ...
    (comp.databases.oracle.server)
  • Re: Linux in Forth?
    ... tendency to mix applications together so it takes work ... The advantage that Forth has over other languages ... >things the way programmers in other languages do them. ... But I think for that to happen the C/Forth ...
    (comp.lang.forth)
  • Re: Quality assurance for CNC programs - Help needed.
    ... problem could be that G code programmers have never programmed in any ... What "standards" might these be for actual computer languages? ... There exist standards which *define* most languages but ... ... The management of the code writing procedure is another thing ...
    (alt.machines.cnc)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... and that all it takes is more or better marketing to be successful. ... uncomfortable to curly-brace programmers, while C++, Java, and C# are not. ... investigate languages providing even more OO features? ... Imagine if the only things on TV were those that appealed to the mass market. ...
    (comp.programming)
  • Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
    ... and that all it takes is more or better marketing to be successful. ... uncomfortable to curly-brace programmers, while C++, Java, and C# are not. ... investigate languages providing even more OO features? ... Imagine if the only things on TV were those that appealed to the mass market. ...
    (comp.object)