469,271 Members | 1,690 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,271 developers. It's quick & easy.

Why Case Sensitive?

Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.

In real life such a situation would be ridiculous (eg. the 16 ways of
writing my name) and, in some cases, frightening.

Is it to avoid having to think up new identifiers? And how would you
distinguish case when reading out bits of code over the phone for
example?

Bart

Jul 19 '07 #1
38 12503
On Thursday 19 Jul 2007 3:19 pm, Bart <bc@freeuk.comwrote in
message <11**********************@m37g2000prh.googlegroups .com>:
Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be
far more advantages in ignoring letter case in source code.

In real life such a situation would be ridiculous (eg. the 16 ways
of writing my name) and, in some cases, frightening.

Is it to avoid having to think up new identifiers? And how would
you distinguish case when reading out bits of code over the phone
for example?
C is case sensitive because computing systems are naturally case
sensitive. It takes extra effort to *not* be case sensitive. Input
devices like keyboards need to distinguish between cases, as do
output devices, text utilities, typesetting systems etc.

Real world is case sensitive and so are computers.

Jul 19 '07 #2
Bart wrote:
Why is C case sensitive?
Because there's no good reason to make it case-insensitive, case
sensitivity comes for free, and case sensitivity allows some
useful conventions such as UPPERCASE macros and having a convenient
distinction between Types and objects.
And how would you distinguish case when reading out bits of code
over the phone for example?
Whatever worked. The nice thing about having real people at the
other end of the phone is that you can sort out a protocol in
the cases where it matters. ("I'll email you the source" is one
such.)

I don't know about you, but I pronounce INT and int differently
when I think it might matter.

--
Kris "with an English accent" DOLL-inn

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Jul 19 '07 #3

"Bart" <bc@freeuk.comwrote in message
news:11**********************@m37g2000prh.googlegr oups.com...
Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.

In real life such a situation would be ridiculous (eg. the 16 ways of
writing my name) and, in some cases, frightening.

Is it to avoid having to think up new identifiers? And how would you
distinguish case when reading out bits of code over the phone for
example?
It can be a problem, because humans remember words, not punctuation.

I use the convention that if a function depends on the standard library and
nothing else then it is all lowercase, whilst if it calls platform-specific
functions it starts with an uppercase letter.

Fortran 77 is case insensitive, and this contributes to Fortran 77 code
being quite hard to read.

Jul 19 '07 #4
On Friday 20 Jul 2007 1:38 am, Malcolm McLean
<re*******@btinternet.comwrote in message
<Ae*********************@bt.com>:
>
"Bart" <bc@freeuk.comwrote in message
news:11**********************@m37g2000prh.googlegr oups.com...
>Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be
far more advantages in ignoring letter case in source code.
[ ... ]
It can be a problem, because humans remember words, not
punctuation.
The do remember case. Case is used to indicate context specific
information in the written language. Computers that don't support
case sensitivity are like the "l33t" and "sms" type posters - ugly
and confusing to understand.
I use the convention that if a function depends on the standard
library and nothing else then it is all lowercase, whilst if it
calls platform-specific functions it starts with an uppercase
letter.
What about functions that don't call any external code, or code
that's neither platform specific nor part of the Standard C library?
Jul 19 '07 #5
Malcolm McLean skrev:
I use the convention that if a function depends on the standard library
and nothing else then it is all lowercase, whilst if it calls
platform-specific functions it starts with an uppercase letter.
If the implementation changes you may end up with naming inconsistency.
August
Jul 19 '07 #6

"August Karlstrom" <fu********@comhem.sewrote in message
news:_w****************@newsb.telia.net...
Malcolm McLean skrev:
>I use the convention that if a function depends on the standard library
and nothing else then it is all lowercase, whilst if it calls
platform-specific functions it starts with an uppercase letter.

If the implementation changes you may end up with naming inconsistency.
If a function does no IO then there is no reason for it to call any
platform-specific functions, except very rarely when for efficiency reasons
a calcualtion cannot be coded in C. So separate your functions from your
procedures, and the situation cannot arise.

Unfortunately reality sometimes kicks in. For instance a lot of long
procedures work fine in development, but for commercial use they need to
support progress bars and user cancels. Error conditions can also be a
problem, as can dependencies on big datasets. Generally however the system
works.
Then of course the standard does provide methods for basic IO, which can
break.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Jul 19 '07 #7
Bart skrev:
Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.

In real life such a situation would be ridiculous (eg. the 16 ways of
writing my name) and, in some cases, frightening.
Exactly, but on the other hand, with case insensitivity the compiler
will accept 16 different ways to refer to the object designated by BART
which imho. is even more confusing.
Is it to avoid having to think up new identifiers? And how would you
distinguish case when reading out bits of code over the phone for
example?
E.g. by spelling out each character prefixed by upper/lower or by saying
"in lower case", "in UPPER CASE", "in camelCase", "in PascalCase" etc.
before the name of the identifier.

A third alternative is to allow only one "spelling" of an identifier,
that is if an identifier is declared as Bart

1. it must be referred to as Bart and

2. the identifiers BART, bart, bArt etc. can not exist in the same scope.
August
Jul 19 '07 #8
On Thu, 19 Jul 2007 15:37:17 +0530, in comp.lang.c , santosh
<sa*********@gmail.comwrote:
>On Thursday 19 Jul 2007 3:19 pm, Bart <bc@freeuk.comwrote in
message <11**********************@m37g2000prh.googlegroups .com>:
>Why is C case sensitive?
C is case sensitive because computing systems are naturally case
sensitive.
This is true NOW, but was not generally true prior to 1970 or so. The
first computers I worked with didn't have much in the way of lowercase
letters. There's a reason why Basic wasn't case-sensitive, and I
recall that F66 required all upper case.
>Real world is case sensitive
Not entirely true either... The Romans and Greeks lived in
case-insensitive worlds.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jul 19 '07 #9
In article <ob********************************@4ax.comMark McIntyre <ma**********@spamcop.netwrites:
On Thu, 19 Jul 2007 15:37:17 +0530, in comp.lang.c , santosh
<sa*********@gmail.comwrote:
On Thursday 19 Jul 2007 3:19 pm, Bart <bc@freeuk.comwrote in
message <11**********************@m37g2000prh.googlegroups .com>:
Why is C case sensitive?
C is case sensitive because computing systems are naturally case
sensitive.

This is true NOW, but was not generally true prior to 1970 or so. The
first computers I worked with didn't have much in the way of lowercase
letters.
The first computers *you* worked with... In 1965 Ascii was standardized
for the second time and that version had lower case letters. And in
1959 IBM Stretch (7030) was first purchased, which also had lower case
letters. I think around 1970 almost *all* computers had lowercase
letters. Whether you could print them on the line printers of that time
is questionable, but they could certainly be displayed on the terminals
when they were tube terminals. The first computer I worked on (back in
1969) was case sensitive. But have a look at
<http://homepages.cwi.nl/~dik/english/codes/7tape.html#start>
and find a host of very old papertape codes that include lower case
letters. The MC Flexowriter code was the first code I did use.

But the actual question is easy to answer. C ultimately derives from
Algol, and that was case sensitive. And the reason for that is easy
to explain, the computers to implement Algol were mostly in Europe, and
there case distinction was quite common in the paper-tape codes (the
most frequently used device to input programs). Using additional
translations in the compiler to make it case insensitive was prohibitive,
as memory space was scarce.
There's a reason why Basic wasn't case-sensitive, and I
recall that F66 required all upper case.
F66 derives from a much older language, and I think that even F66 allows
both cases in strings. Basic probably is single case (yes, originally it
*was* single case), because that was much easier.
Real world is case sensitive

Not entirely true either... The Romans and Greeks lived in
case-insensitive worlds.
Oh. There are many scripts that still are used and do not even have a
case distinction. But that is entirely different.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jul 20 '07 #10
>Why is C case sensitive?
>
I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.

In real life such a situation would be ridiculous (eg. the 16 ways of
writing my name) and, in some cases, frightening.
Some people are trying to use this feature of English to claim that they
are not subject to the US income tax.
>Is it to avoid having to think up new identifiers? And how would you
distinguish case when reading out bits of code over the phone for
example?
You don't read out bits of code over the phone. If you ever read out
*passwords* over the phone, you can take a long time doing it, and it's
still horribly error-prone. ("Upper case B as in Bastard, open square
bracket, control lowercase R as in Retard, digit nine, ....")

Some case-related questions for Standard C:

What is the maximum number of cases allowed? What is the maximum
number of cases actually implemented in a locale for a real language?
(e.g. Tholian doesn't count. Klingon might as some people have
tried to flesh it out as a complete language. Real human languages
count, even ones that are dead like ancient Egyptian.)
Is it permissible in a standard C implementation that (where c is a char)
c != toupper(c) for all values of c where isalpha(c) != 0,
c != tolower(c) for all values of c where isalpha(c) != 0,
and c == toupper(toupper(toupper(c))) for all values of c where isalpha(c) != 0?

(in other words: there's three cases, toupper() does a "circular
right rotate case", and tolower() does a "circular left rotate
case". There's no "uppermost case" or "lowermost case".)

Jul 20 '07 #11
On Friday 20 Jul 2007 4:17 am, Mark McIntyre
<ma**********@spamcop.netwrote in message
<ob********************************@4ax.com>:
On Thu, 19 Jul 2007 15:37:17 +0530, in comp.lang.c , santosh
<sa*********@gmail.comwrote:
>>On Thursday 19 Jul 2007 3:19 pm, Bart <bc@freeuk.comwrote in
message <11**********************@m37g2000prh.googlegroups .com>:
>>Why is C case sensitive?
[ ... ]
>Real world is case sensitive

Not entirely true either... The Romans and Greeks lived in
case-insensitive worlds.
Yeah I know, as is my native language, but I was talking about
English, since it comes closest to a global language, if there ever
was one.

Jul 20 '07 #12
Malcolm McLean wrote, On 19/07/07 22:34:
>
"August Karlstrom" <fu********@comhem.sewrote in message
news:_w****************@newsb.telia.net...
>Malcolm McLean skrev:
>>I use the convention that if a function depends on the standard
library and nothing else then it is all lowercase, whilst if it calls
platform-specific functions it starts with an uppercase letter.

If the implementation changes you may end up with naming inconsistency.
If a function does no IO then there is no reason for it to call any
platform-specific functions, except very rarely when for efficiency
reasons a calculation cannot be coded in C. So separate your functions
from your procedures, and the situation cannot arise.
What does separating functions and procedures have to do with it? Apart
from implying you are using the term function in a non-C way which means
you should have stated that up front if you want to be understood.
Unfortunately reality sometimes kicks in. For instance a lot of long
procedures work fine in development, but for commercial use they need to
support progress bars and user cancels. Error conditions can also be a
problem, as can dependencies on big datasets. Generally however the
system works.
If you think any of the above don't come in to play in development then
you should not be involved in SW development, since everything you
mention should have been in the requirements and design before you even
consider starting your source code editor.
Then of course the standard does provide methods for basic IO, which can
break.
Anyone with any knowledge knows that any IO operation can fail. This is
why where it is really critical you have multiple physical IO paths. So
of course the standard C IO functions can fail.
--
Flash Gordon
Jul 20 '07 #13
Gordon Burditt said:

<snip>
You don't read out bits of code over the phone.
Well, maybe *you* don't. I have done so on several occasions.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 20 '07 #14
On Fri, 20 Jul 2007 00:57:24 GMT, in comp.lang.c , "Dik T. Winter"
<Di********@cwi.nlwrote:
>In article <ob********************************@4ax.comMark McIntyre <ma**********@spamcop.netwrites:
On Thu, 19 Jul 2007 15:37:17 +0530, in comp.lang.c , santosh
first computers I worked with didn't have much in the way of lowercase
letters.

The first computers *you* worked with... In 1965 Ascii was standardized
for the second time and that version had lower case letters.
Quite possibly. However the terminals (?VT52 and Tek4100?) on our Vax
cluster didn't provide any trivial way to enter lower case, and
neither VMS nor Fortran gave a hoot anyway.....
>they could certainly be displayed on the terminals
when they were tube terminals.
The keyboards I used in Oxford in the early *eighties* didn't even
HAVE lowercase letters on the keyboards - and the teletype paper only
printed Ucase anyway....
>But the actual question is easy to answer. C ultimately derives from
Algol, and that was case sensitive.
There's a reason why Basic wasn't case-sensitive, and I
recall that F66 required all upper case.

F66 derives from a much older language, and I think that even F66 allows
both cases in strings.
Yes, thats true. As far as I recall F66 required all code to be
uppercase. I recall being very happy when we got an upgrade which
allowed mixed case because by that time most of my coding was done via
a terminal emulator running on a Sun-1 or PCXT which of course /did/
have mixed case...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jul 20 '07 #15

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
>Unfortunately reality sometimes kicks in. For instance a lot of long
procedures work fine in development, but for commercial use they need to
support progress bars and user cancels. Error conditions can also be a
problem, as can dependencies on big datasets. Generally however the
system works.

If you think any of the above don't come in to play in development then
you should not be involved in SW development, since everything you mention
should have been in the requirements and design before you even consider
starting your source code editor.
If you program business logic then you have requirements and design. If you
are doing scientific programming then the interest is in proving the
algorithm. So you are not interested in UI issues, only if the general
approach works. However eventually the function will have to be packaged for
a non-programming user.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jul 20 '07 #16
Malcolm McLean wrote, On 20/07/07 21:44:
>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
Please don't snip attributes for still included text. You wrote the below.
>>Unfortunately reality sometimes kicks in. For instance a lot of long
procedures work fine in development, but for commercial use they need
to support progress bars and user cancels. Error conditions can also
be a problem, as can dependencies on big datasets. Generally however
the system works.

If you think any of the above don't come in to play in development
then you should not be involved in SW development, since everything
you mention should have been in the requirements and design before you
even consider starting your source code editor.
If you program business logic then you have requirements and design. If
you are doing scientific programming
Then you also have requirements (or you are not required to write the
code), and the code still needs to be designed.
then the interest is in proving the
algorithm. So you are not interested in UI issues, only if the general
approach works. However eventually the function will have to be packaged
for a non-programming user.
So you design it to be able to but in a fancier user interface. It's
what is called designing for expected extensions and saves a lot of work.

In any case, you *still* need to handle errors, because if you don't you
don't know if the results you get are due to uncaught errors or not.
--
Flash Gordon
Jul 20 '07 #17

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:39************@news.flash-gordon.me.uk...
>If you program business logic then you have requirements and design. >>
If you are doing scientific programming

Then you also have requirements (or you are not required to write the
code), and the code still needs to be designed.
It doesn't work like that.
I've had this before from people who work in businessy type systems and
think that games can be formally specified using the same techniques. They
can't and no games company does that, for lots of reasons. One is that no
one cares if output is correct, just whether it plays. Another is that you
don't know how well the program is going to perform until it is in quite an
advanced stage of development, at which point you decide how much geometry
to throw at the rasteriser.
Scientific programming is a bit different to games, but again you can't
generally specify the program and then write it. If you can do that then
it's not reasearch.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jul 20 '07 #18
Flash Gordon wrote:
Malcolm McLean wrote, On 20/07/07 21:44:
>>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message

Please don't snip attributes for still included text. You wrote the below.
>>>Unfortunately reality sometimes kicks in. For instance a lot of long
procedures work fine in development, but for commercial use they
need to support progress bars and user cancels. Error conditions can
also be a problem, as can dependencies on big datasets. Generally
however the system works.

If you think any of the above don't come in to play in development
then you should not be involved in SW development, since everything
you mention should have been in the requirements and design before
you even consider starting your source code editor.
If you program business logic then you have requirements and design.
If you are doing scientific programming

Then you also have requirements (or you are not required to write the
code), and the code still needs to be designed.
But the design may be done in code...

--
Ian Collins.
Jul 20 '07 #19
Ian Collins wrote, On 20/07/07 23:11:
Flash Gordon wrote:
>Malcolm McLean wrote, On 20/07/07 21:44:
>>"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
Please don't snip attributes for still included text. You wrote the below.
>>>>Unfortunately reality sometimes kicks in. For instance a lot of long
procedures work fine in development, but for commercial use they
need to support progress bars and user cancels. Error conditions can
also be a problem, as can dependencies on big datasets. Generally
however the system works.
If you think any of the above don't come in to play in development
then you should not be involved in SW development, since everything
you mention should have been in the requirements and design before
you even consider starting your source code editor.

If you program business logic then you have requirements and design.
If you are doing scientific programming
Then you also have requirements (or you are not required to write the
code), and the code still needs to be designed.
But the design may be done in code...
You still have some vague idea of a design before you start writing
code, after all how can you write anything if you don't know what you
are writing?
--
Flash Gordon
Jul 20 '07 #20
Malcolm McLean wrote, On 20/07/07 23:08:
>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:39************@news.flash-gordon.me.uk...
>>If you program business logic then you have requirements and design.
If you are doing scientific programming

Then you also have requirements (or you are not required to write the
code), and the code still needs to be designed.
It doesn't work like that.
I've had this before from people who work in businessy type systems and
think that games can be formally specified using the same techniques.
I've worked on lots of different things.
They can't and no games company does that, for lots of reasons.
Doesn't sound like scientific programming to me!
One is
that no one cares if output is correct, just whether it plays.
The people I've met in the games industry have the game planned (story
boarding or whatever) before they start writing it. This game plan/story
board/etc is what some would call a simple set of requirements.
Another
is that you don't know how well the program is going to perform until it
is in quite an advanced stage of development, at which point you decide
how much geometry to throw at the rasteriser.
It is easy to design systems such that you can change parameters, such
as how much detail. In fact, since games are often made to run on
systems with vastly different capabilities they have to allow for such
things or have the expense of writing the game from scratch several times!
Scientific programming is a bit different to games, but again you can't
generally specify the program and then write it. If you can do that then
it's not reasearch.
Just because you don't know if something will work does not mean you
don't have requirements for it. I've worked on projects where the entire
point of the project was to see if something would work, or to compare
different approaches to doing things etc, and we still had requirements
for them. It's just that the requirements did not specify how well the
algorithm would work. Oh, and in some cases the research reached the
conclusion things were not viable, at least not with the defined approach.

I'm not saying all requirements are nailed down to the last detail, and
indeed with business SW they are often not nailed down that tightly, but
even if the requirement is just "implement this type of neural network
of this size to be trained like this and then see if it can do the job"
it is still a requirement. If a requirement is to add a nice user
interface *if* the method proves worthy of further testing, then that is
still an extensibility requirement.
--
Flash Gordon
Jul 20 '07 #21
Bart <bc@freeuk.comwrote:
# Why is C case sensitive?

Why not? The decision is arbitrary.

# In real life such a situation would be ridiculous (eg. the 16 ways of
# writing my name) and, in some cases, frightening.

Writing programs is not the same as writing novels.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
God's a skeeball fanatic.
Jul 21 '07 #22

"Ian Collins" <ia******@hotmail.comwrote in message
news:5g**************@mid.individual.net...
Flash Gordon wrote:
>Ian Collins wrote, On 21/07/07 00:16:
>>>
You start writing tests, concreting up your initial requirements.

Your tests are still have to be designed if they are to be worth having.

You use the tests to drive the design.
You do need some idea what you are going to achieve, as Flash points out. No
point writing endless Windows GUI code if you plan a website backend, or
efficient matrix routines if you are writing a text adventure.

However generally you know you are going to need some components, and these
will be reuseable. For instance I was writing a few utilities to back up the
protein folding. These needed command-line arguments.

getopt() is non-standard, so I needed a options parser built on top of ANSI
C. Looking at the getopt interface, I thought "this isn't all that
well-designed, I'm sure I could do better". I also didn't find exactly what
I wanted on the web. So options.c was born, designed to make life easy for
the programmer whilst still providing a reasonably high standard of parsing.
There is a very difficult problem when a long option is an anagram of
allowed flags (eg we allow flags a-f and r for recursive, but also long
option -fred).

So the module is written, tested, seems to be OK. The exact API is sorted
out in testing and coding, because all I want to do is write a parser. At
this stage I am in control, there is no legacy code that has to be
maintained, I haven't promised any interface or even functionality to any
other person. Often,as with the anagram problem, it is only when you start
testing and coding that you realise some inherent problems, and that affects
the design. I didn't want to demand a flags parameter in the option
constructor, because you pass that information in anyway in the queries.
However there is simply no easy way of avoiding it if you allow a list of
one-letter flags in option 1 as well as long options, and that is such a
convention that you can't break it.

That's just one little module, a jigsaw piece. Unfortunately the programs
cannot be simply an assembly of precut pieces. You always need specialised
pieces, sometimes you need to modify a piece.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jul 21 '07 #23
Malcolm McLean wrote:
>
"Ian Collins" <ia******@hotmail.comwrote in message
news:5g**************@mid.individual.net...
>Flash Gordon wrote:
>>Ian Collins wrote, On 21/07/07 00:16:

You start writing tests, concreting up your initial requirements.

Your tests are still have to be designed if they are to be worth having.

You use the tests to drive the design.
You do need some idea what you are going to achieve, as Flash points
out. No point writing endless Windows GUI code if you plan a website
backend, or efficient matrix routines if you are writing a text adventure.
True, but what you don't need to do is to spend time working out the
details before you start to code.

--
Ian Collins.
Jul 21 '07 #24
Ian Collins wrote, On 21/07/07 08:29:
Malcolm McLean wrote:
>"Ian Collins" <ia******@hotmail.comwrote in message
news:5g**************@mid.individual.net...
>>Flash Gordon wrote:
Ian Collins wrote, On 21/07/07 00:16:
You start writing tests, concreting up your initial requirements.
Your tests are still have to be designed if they are to be worth having.
You use the tests to drive the design.
You do need some idea what you are going to achieve, as Flash points
out. No point writing endless Windows GUI code if you plan a website
backend, or efficient matrix routines if you are writing a text adventure.
True, but what you don't need to do is to spend time working out the
details before you start to code.
Not all design is going down to pseudo-code with a 1:1 mapping to the
actual code. If you think that designing SW means always reducing it to
the nth degree then you need to learn more bout designing SW.
--
Flash Gordon
Jul 21 '07 #25
On 19 Jul., 11:49, Bart <b...@freeuk.comwrote:
Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.
I have seen Pascal (which has case insensitive identifiers)
programs, which try to use camel case in an inconsistant way.
IMHO it looks ugly when you write identifiers different with
every use:

CamelCase, camelCase, camelcase, Camelcase, cameLcase, ...

Case sensitivy forces you to write the identifiers
always the same.

Max

Jul 21 '07 #26
In article <11*********************@r34g2000hsd.googlegroups. com>,
<ma***********@gmx.netwrote:
>On 19 Jul., 11:49, Bart <b...@freeuk.comwrote:
>Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.

I have seen Pascal (which has case insensitive identifiers)
programs, which try to use camel case in an inconsistant way.
IMHO it looks ugly when you write identifiers different with
every use:

CamelCase, camelCase, camelcase, Camelcase, cameLcase, ...

Case sensitivy forces you to write the identifiers
always the same.

Max
Yes. As I always use to tell the story, in the original 'vi' editor
(that is, before the full-functioned clones came out) there wasn't any
simple way to search case-insensitively. So, whenever I was dealing
with a case-insensitive language, it was necessary to do something like:

/[Ss][Oo][Mm][Ee][Dd][Uu][Mm][Bb][Ii][Dd][Ee][Nn][Dd][Tt][Ii][Ff][Ii][Ee][Rr][Tt][Hh][Aa][Tt][Mm][Ii][Gg][Hh][Tt][Bb][Ee][Ii][Nn][Aa][Nn][Yy][Cc][Aa][Ss][Ee]/

Because, of course, I could never trust the other programmers working on
the project to capitalize in a consistent way.

Now that vim (and others) have built-in support for this, it's not such
a big deal, but it is still a PIA. As it turns out, one of the
languages in which I currently program *is* case-insensitive and I still
find it quaint that I need to turn the "ic" option on when editing.

Jul 21 '07 #27
>>>>"FG" == Flash Gordon <sp**@flash-gordon.me.ukwrites:

FGSometimes continually changing requirements have forced a
FGproject to fail, although not any project I have been involved
FGin.

The only project failures I've seen due to changing requirements have
involved non-technical managers not understanding the cost of change,
and fiddling with the requirements until the cost of the project
exceeded not only the budget they had originally set (which would
probably have been sufficient) but twice that.

FGThe customer may well not require that these things be
FGchangeable, but from my knowledge of the application domain I
FG*know* they will change over the life of the project, so I
FGdesign the system in such a way that the can be changed in a
FGnice isolated way without impacting on the rest of the code.

When I've run into things like this, I've asked. With the worse sort
of client, they say "no, it will never change," and then come back to
you before the project's even done with a list of changes. It's one
thing if it's a domain that I know about, so that I can know that tax
rates are likely to change year-to-year; if it's a domain I don't know
about, I have no choice but to trust the client.

Charlton
--
Charlton Wilbur
cw*****@chromatico.net
Jul 22 '07 #28
Charlton Wilbur wrote, On 22/07/07 16:58:
>>>>>"FG" == Flash Gordon <sp**@flash-gordon.me.ukwrites:

FGSometimes continually changing requirements have forced a
FGproject to fail, although not any project I have been involved
FGin.

The only project failures I've seen due to changing requirements have
involved non-technical managers not understanding the cost of change,
and fiddling with the requirements until the cost of the project
exceeded not only the budget they had originally set (which would
probably have been sufficient) but twice that.
I was thinking of certain defence projects where yes, non-technical
people kept fiddling and extending.
FGThe customer may well not require that these things be
FGchangeable, but from my knowledge of the application domain I
FG*know* they will change over the life of the project, so I
FGdesign the system in such a way that the can be changed in a
FGnice isolated way without impacting on the rest of the code.

When I've run into things like this, I've asked. With the worse sort
of client, they say "no, it will never change," and then come back to
you before the project's even done with a list of changes. It's one
thing if it's a domain that I know about, so that I can know that tax
rates are likely to change year-to-year; if it's a domain I don't know
about, I have no choice but to trust the client.
If it's not a domain you know then you really need to get in someone who
does know the domain and trust them. In my experience the client does
not normally know what is likely to change.
--
Flash Gordon
Jul 22 '07 #29

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:qk************@news.flash-gordon.me.uk...
If it's not a domain you know then you really need to get in someone who
does know the domain and trust them. In my experience the client does
not normally know what is likely to change.
But the programmer does. Separate the source files into "this program only"
and "any program". "Any program" means a routine useful in any program in
the same type of area, "this program only" is all the rest, including at
least the main function. Try to put as much code as possible into "any
program".
The "any program" routines are unlikely to need modification, "this program
only" routines you can expect to alter.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Jul 22 '07 #30
Malcolm McLean wrote, On 22/07/07 19:44:
>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:qk************@news.flash-gordon.me.uk...
>If it's not a domain you know then you really need to get in someone
who does know the domain and trust them. In my experience the client >
does not normally know what is likely to change.
But the programmer does.
Had you actually read what I was replying to you would know that we are
talking about when the programmer does NOT know. If a pre-condition to
the discussion is a programmer not knowing, then how can you say the
programmer knows?
Separate the source files into "this program
only" and "any program".
What does this have to do with when the requirements for "this program
only" change? If the requirements for "this program only" change then it
could impact on code designed to be generic that turns out to not be
generic enough, or on code designed not to be generic. For example my
generic frequency response test only tests for drop-off, not boost
(because there was no requirement for such a test so no need to spend
money writing it) but now there is such a requirement. So my generic
code has to change to allow for the new requirement and the "this
program" code has to as well to tell the generic code the limit. Of
course, because the SW was all designed decently these were small
changes, but they were *real* changes to a *real* generic library and
*real* application specific code.
"Any program" means a routine useful in any
program in the same type of area,
That does not mean there will not be additional requirements on them later.
"this program only" is all the rest,
including at least the main function. Try to put as much code as
possible into "any program".
That does not mean the requirements changes will be limited to the "this
program only" code.
The "any program" routines are unlikely to need modification,
That shows how little you know about programming in the real world. In
the real world you only write the bits of the "any program" routines you
need now, but you design and implement them to allow for the inevitable
future changes in requirements. Or why do you think the revision of the
X library (to take a favourite of yours) is so high? Even the standard C
library itself has changed.
"this
program only" routines you can expect to alter.
Actually, on one project I did most of the changes were to the "generic"
libraries which meant that all of the customers got the benefit of them.
On the SW I'm currently working on we also keep extending the generic
libraries to provide us with additional functionality to allow us to
more easily meet the new customer requirements.

This discussion is not about the split between library and application
specific code, it is about how much rewrite you have to do when the
requirements change, whether that rewrite is in application specific or
library code is completely irrelevant to the problem.
--
Flash Gordon
Jul 22 '07 #31

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:26************@news.flash-gordon.me.uk...
Malcolm McLean wrote, On 22/07/07 19:44:
That shows how little you know about programming in the real world. In
the real world you only write the bits of the "any program" routines you
need now, but you design and implement them to allow for the inevitable
future changes in requirements. Or why do you think the revision of the X
library (to take a favourite of yours) is so high? Even the standard C
library itself has changed.
Let's take a real example.
I've got code that has to compile under pure ANSI C, and I want to pass in a
couple of optional parameters and three filenames.
Now I could write a custom routine that would parse the options and extract
the filenames.

typedef struct
{
int window;
int keep;
char *protein;
char *ramaangleset;
char *chiangleset;
} ARGS;

int fillargc(int argc, char **argv)

Or I could say - "most of this code can be any program". Parsing commandline
options is hardly an unusual requirement.
getopt is the obvious choice, but it isn't in the standard library. I could
have downloaded some code from the web. But actually I don't really like the
interface and I think I can do better. Rightly or wrongly, options.c is
born.

So the heart of it is a routine.

int opt_get(OPTIONS *opt, char *name, char *fmt, ...);

example usage

int window;

opt_get(opt, "-window -win", "%d", &window);

Now I've added more functionality than I strictly require. You can have
several parameters of integer, real or string types per option. It also
returns a value for parameterless flag options. The option name is passed in
and you can have aliases.

That's because it is an "any program" routine. So it will handle a wide
range of options. Not everything possible, of course, but everything that
can be reasonably foreseen and doesn't require excessive coding effort.

Now if the command line options change, which they are quite likely to do,
all I've got to do is add a call to opt_get(). If I want to write another
program, I've got options.c, and I don't have to write it again.
If someone really insists on -f123 (flag and parameter run together) format
it will need a rewrite, because that was a foreseeable demand that would
have required "excessive coding" to support. It wouldn't be the end of the
project, but it would mean that the plan had broken down. However normally I
would expect to control the options format myself.

That's "any program" status should also mean "don't change me". The
options.c module shouldn't change. If it needs changing then that's a
failure on my part. The calls to it will change as options are added or
removed, but normally that change will be only one or two lines of source.
Obviously you can't expect to change the behaviour of the program with not
changes at all to its source.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jul 22 '07 #32
Malcolm McLean wrote, On 22/07/07 22:51:
>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:26************@news.flash-gordon.me.uk...
>Malcolm McLean wrote, On 22/07/07 19:44:
That shows how little you know about programming in the real world. >
In the real world you only write the bits of the "any program"
routines you need now, but you design and implement them to allow for
the inevitable future changes in requirements. Or why do you think the
revision of the X library (to take a favourite of yours) is so high?
Even the standard C library itself has changed.
Let's take a real example.
Oh, so you think that neither the X library nor the standard C libraries
are examples? How about libxml at 2.2.26 which has had a lot of changes,
or almost any other library on the machine I'm currently using. All of
them have had to be changed as requirements changed.
I've got code that has to compile under pure ANSI C, and I want to pass
in a couple of optional parameters and three filenames.
<snip>
returns a value for parameterless flag options. The option name is
passed in and you can have aliases.
Then someone comes up and says they need --floogle as an option when you
only allowed for single character options because that was all that was
required.
That's because it is an "any program" routine. So it will handle a wide
range of options. Not everything possible, of course, but everything
that can be reasonably foreseen and doesn't require excessive coding
effort.
Ah, so you are getting vaguely near the point that Ian and I were
discussing at last.
Now if the command line options change, which they are quite likely to
do, all I've got to do is add a call to opt_get(). If I want to write
another program, I've got options.c, and I don't have to write it again.
So? We were not talking about code reuse. We were talking about changing
requirements within *one* project. Whether you have taken one part of
the code and put it in a library has exactly ZERO effect on whether you
have to change code, and how much you have to change, when your
requirements are changed. The code can be just as well factorised even
if the code is not placed in a separate library, just a seperate
function within the program.
If someone really insists on -f123 (flag and parameter run together)
format it will need a rewrite, because that was a foreseeable demand
that would have required "excessive coding" to support. It wouldn't be
the end of the project, but it would mean that the plan had broken down.
That depends on how you have designed and implemented it. If you had
considered that other ways of doing options might come in to play and
had coded accordingly then you don't need a rewrite even though you had
not coded for that specific way, if you had not then you might need a
complete rewrite.
However normally I would expect to control the options format myself.
This shows that you do not live in the real world. In the real world SW
has to meet real requirements that are not under the control of the
developer because they are the *customers* requirements, not the developers.
That's "any program" status should also mean "don't change me".
Oh, you have not understood the point of the discussion after all.
The
options.c module shouldn't change. If it needs changing then that's a
failure on my part.
If yo think that then you do not understand real-world SW development.
This might explain why you did not address the point that the X library
has undergone many revisions *despite* being a general purpose library.

In the real world you do not write the code to handle what you don't
need today, because that delays you getting the product out, what you do
is allow for the code to be extended *without* writing those extensions
until they are needed.
The calls to it will change as options are added or
removed, but normally that change will be only one or two lines of
source. Obviously you can't expect to change the behaviour of the
program with not changes at all to its source.
Well, seeing as I was the one arguing that if the SW is well designed
allowing for possible future changes you don't have to do a rewrite only
comparatively small changes, and that is what you are now saying, I
don't see why you started arguing with my position. Of course, you
snipped those parts and the real world example (and when I mean real
world, I mean a project that was several man years over the time I was
involved) where a general purpose library had to be changed (but not
rewritten) and the calling code had to be changed (but not rewritten).
--
Flash Gordon
Jul 22 '07 #33
In article <11*********************@r34g2000hsd.googlegroups. comma***********@gmx.net writes:
On 19 Jul., 11:49, Bart <b...@freeuk.comwrote:
Why is C case sensitive?

I know it's a bit late to change it now but there would seem to be far
more advantages in ignoring letter case in source code.

I have seen Pascal (which has case insensitive identifiers)
The reason for that can (again) be explained. The first Pascal compiler
was case insensitive because it allowed only one case (it was developed
for the CDC 6600 which in normal operation had only one case, I have
once upon a time adapted the compiler to use both cases, but it was
not easy, even when I did want it only in strings and character constants).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jul 23 '07 #34
On 2007-07-20 17:32, Mark McIntyre <ma**********@spamcop.netwrote:
On Fri, 20 Jul 2007 00:57:24 GMT, in comp.lang.c , "Dik T. Winter"
<Di********@cwi.nlwrote:
>>In article <ob********************************@4ax.comMark McIntyre <ma**********@spamcop.netwrites:
On Thu, 19 Jul 2007 15:37:17 +0530, in comp.lang.c , santosh
first computers I worked with didn't have much in the way of lowercase
letters.

The first computers *you* worked with... In 1965 Ascii was standardized
for the second time and that version had lower case letters.

Quite possibly. However the terminals (?VT52 and Tek4100?) on our Vax
cluster didn't provide any trivial way to enter lower case,
Don't know about tghe Tektronics, but the VT52 terminals did provide a
trivial way to enter lower case: Just don't press the caps lock key :-).

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Jul 23 '07 #35
On 2007-07-21 12:35, Kenny McCormack <ga*****@xmission.xmission.comwrote:
Yes. As I always use to tell the story, in the original 'vi' editor
(that is, before the full-functioned clones came out) there wasn't any
simple way to search case-insensitively.
:set ignorecase

worked with real vi on Ultrix in 1987. I don't remember ever
encountering a version of vi which didn't support it.

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Jul 23 '07 #36

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:8a************@news.flash-gordon.me.uk...
Malcolm McLean wrote, On 22/07/07 22:51:
>returns a value for parameterless flag options. The option name is passed
in and you can have aliases.

Then someone comes up and says they need --floogle as an option when you
only allowed for single character options because that was all that was
required.
You can have --floogle, -fl, -f, even /floogle as aliases.
However you can't have -floogle1234. It's got to be -floogle 1234. It's
inherently hard to support a flag concatenated with an option unless you
pass in a list of options before extracting them, which makes the interface
harder use use.
>
So? We were not talking about code reuse. We were talking about changing
requirements within *one* project. Whether you have taken one part of the
code and put it in a library has exactly ZERO effect on
whether you have to change code, and how much you have to change, when
your requirements are changed. The code can be just as well factorised
even if the code is not placed in a separate library, just a seperate
function within the program.
"factorised?" You mean manufactured / made / written?
It's a common misconception that the main reason for making code portable or
reusable is to run it on another system. That's a useful side-effect. The
real reason is to improve your design.
>
This shows that you do not live in the real world. In the real world SW
has to meet real requirements that are not under the control of the
developer because they are the *customers* requirements, not the
developers.
I'm certainly a real perosn, not, as you might have imagined, a Markov
model. I don't have any customers, however.
In scientific programming is very unlikely that a user would insist
on --froogle1234 instead of --froogle 1234, and I've got control anyway,
because they don't pay me to use my stuff. I get a block grant and it's
understood that everything I produce is for the benefit of the community.
However that is a limitation of options.c.
>
If yo think that then you do not understand real-world SW development.
This might explain why you did not address the point that the X library
has undergone many revisions *despite* being a general purpose library.
That's true. It could be a counter-example. if they don'e a really sterling
job they could have held it constant, except that for a very low-level
library like X there is no predicting hardware changes.
>
In the real world you do not write the code to handle what you don't need
today, because that delays you getting the product out, what you do is
allow for the code to be extended *without* writing those extensions
until they are needed.
I am a real person. Generally I find it's better to make code "any program",
which means making it more general, which means some additional coding
effort. However the benefits tot he design and structure of the program
virtually always pay off. And as an added bonus you've a module you can put
on your website.
Well, seeing as I was the one arguing that if the SW is well designed
allowing for possible future changes you don't have to do a rewrite only
comparatively small changes, and that is what you are now saying, I don't
see why you started arguing with my position. Of course, you snipped those
parts and the real world example (and when I mean real world, I mean a
project that was several man years over the time I was
involved) where a general purpose library had to be changed (but not
rewritten) and the calling code had to be changed (but not rewritten).
If a general purpose library has to be changed, except for harware reasons,
it wasn't well written to start with. Good software lasts forever. It never
needs maintenance because bits don't wear out.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jul 24 '07 #37
Malcolm McLean wrote, On 24/07/07 20:52:
>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:8a************@news.flash-gordon.me.uk...
>Malcolm McLean wrote, On 22/07/07 22:51:
>>returns a value for parameterless flag options. The option name is
passed in and you can have aliases.

Then someone comes up and says they need --floogle as an option when
you only allowed for single character options because that was all
that was required.
You can have --floogle, -fl, -f, even /floogle as aliases.
However you can't have -floogle1234. It's got to be -floogle 1234. It's
inherently hard to support a flag concatenated with an option unless
you pass in a list of options before extracting them, which makes the
interface harder use use.
So you refuse to change your SW to meet the customers requirement. That
looses you sales and stops you getting paid. Not a good plan.
>So? We were not talking about code reuse. We were talking about
changing requirements within *one* project. Whether you have taken one
part of the code and put it in a library has exactly ZERO effect on
whether you have to change code, and how much you have to change, when
your requirements are changed. The code can be just as well
factorised even if the code is not placed in a separate library, just
a seperate function within the program.
"factorised?" You mean manufactured / made / written?
My brain slipped a notch. I meant modularised, or otherwise broken down.
It's a common misconception that the main reason for making code
portable or reusable is to run it on another system. That's a useful
side-effect. The real reason is to improve your design.
I was not claiming anything about portability or reuse in the
discussion. It is *you* who brought up libraries and has now brought up
portability and reuse.
>This shows that you do not live in the real world. In the real world
SW has to meet real requirements that are not under the control of the
developer because they are the *customers* requirements, not the
developers.
I'm certainly a real perosn, not, as you might have imagined, a Markov
model. I don't have any customers, however.
In scientific programming is very unlikely that a user would insist on
--froogle1234 instead of --froogle 1234,
Pick any other example that they *would* demand then. Requirements
change, the nature of those changes depends on you customer base.
and I've got control anyway,
because they don't pay me to use my stuff.
According to some definitions they are customers if they are using your
stuff, whether they are paying customers is another matter. If not I
want my money back, and being a UK tax payer it is my money.
I get a block grant and it's
understood that everything I produce is for the benefit of the community.
Well, I hope you are better at what you get paid for than you are at
understanding SW development.
However that is a limitation of options.c.
So you only survive because you get paid even if you don't meet the
requirements of your uses.
>If yo think that then you do not understand real-world SW development.
This might explain why you did not address the point that the X
library has undergone many revisions *despite* being a general purpose
library.
That's true. It could be a counter-example. if they don'e a really
sterling job they could have held it constant,
Ah, so any counter-example anyone gives does not count because obviously
the developers are useless because they had to change the library.
except that for a very
low-level library like X there is no predicting hardware changes.
Check your facts. The specification for X Windows has changed over the
years.

You also snipped other real example of libraries changing due to changes
in requirements. Libraries which have nothing to do with hardware. Such
as libxml and libxslt. Are you claiming the authors of those libraries
did bad jobs because they had to change them due to requirements
changes, said requirements changes including changes to the XSLT
specification.
>In the real world you do not write the code to handle what you don't
need today, because that delays you getting the product out, what you
do is allow for the code to be extended *without* writing those
extensions until they are needed.
I am a real person. Generally I find it's better to make code "any
program", which means making it more general, which means some
additional coding effort.
So you think I should spend an extra 6 months on a 3 month project
writing all the other functionality that someone might require from a
library even though I only have finances for 3 months work? Personally I
would rather my company makes a profit and can afford to pay me, so I'll
just write the SW so that it can be extended when required.
However the benefits tot he design and
structure of the program virtually always pay off.
Show me where I've said the program should not be structured? In fact,
if anything I've said the exact opposite.
And as an added bonus
you've a module you can put on your website.
<sarcasm>
I'm sure my employer would love it if I gave away all the SW.
</sarcasm>
>Well, seeing as I was the one arguing that if the SW is well designed
allowing for possible future changes you don't have to do a rewrite only
comparatively small changes, and that is what you are now saying, I
don't see why you started arguing with my position. Of course, you
snipped those parts and the real world example (and when I mean real
world, I mean a project that was several man years over the time I was
involved) where a general purpose library had to be changed (but not
rewritten) and the calling code had to be changed (but not rewritten).
If a general purpose library has to be changed, except for harware
reasons, it wasn't well written to start with. Good software lasts
forever. It never needs maintenance because bits don't wear out.
As stated multiple times, REQUIREMENTS CHANGE. I will even give you
ANOTHER REAL example.

I've written a set of interfacing libraries for some commercial SW that
companies pay a lot of money for. The first version did not support FTP
because there was no requirement for FTP. However, a while later there
was a requirement, but as I had DESIGNED the libraries to ALLOW for
future enhancements, including the likelihood of FTP, I was able to
modify the LIBRARIES and suddenly the application, with no change to the
application, supported FTP. Now, do you think I should have made my
company make a loss on the first contract AND piss off our customer
because we delivered late, or do you think we should deliver to cost and
time but in a way that when a later requirement comes along we can
change the SW to meet it? I know which my customers prefer (getting
their SW) and I know which my boss prefers (making a profit). By the
way, there was another requirement on the library initially, support for
encrypted XML, however that requirement went away before project
completion and we currently don't have a requirement for it, so I've not
finished implementing that, but IF it later becomes a requirement again
(which is not certain) THEN I will change the libraries to properly
support it.

I've ALREADY given you a REAL example of a change to a general purpose
frequency response test where a requirement was added to test for a
boost in the frequency response.

Then there are the changes to the QT library to support additional
widgets and all sorts of other things.

Then there are the changes to openssl to support new encryption methods,
or do you think they should have coded up encryption methods that had
not been invented when they first wrote it?

Then there was...

Well, I could keep going and if I tried probably find changes of
requirements to all of the over 2000 libraries installed on this machine
that are nothing to do with hardware changes.

However, based on your responses so far in this thread you will snip all
but one and claim that one was either badly written on a exception
despite the fact that EVERY library I have looked at that has been in
serious use for a year has had requirements change.

To everyone else no the group, sorry, I should not have let Malcolm drag
me in to this off topic argument, so this will be my last post on the
subject.
--
Flash Gordon
Jul 24 '07 #38
On Mon, 23 Jul 2007 15:58:37 +0200, "Peter J. Holzer"
<hj*********@hjp.atwrote:
On 2007-07-20 17:32, Mark McIntyre <ma**********@spamcop.netwrote:
On Fri, 20 Jul 2007 00:57:24 GMT, in comp.lang.c , "Dik T. Winter"
<Di********@cwi.nlwrote:
>The first computers *you* worked with... In 1965 Ascii was standardized
for the second time and that version had lower case letters.
Quite possibly. However the terminals (?VT52 and Tek4100?) on our Vax
cluster didn't provide any trivial way to enter lower case,

Don't know about tghe Tektronics, but the VT52 terminals did provide a
trivial way to enter lower case: Just don't press the caps lock key :-).
And if using full-duplex with computer-controlled echo, as TTBOMK all
DEC systems did and many others as well, turn off (or don't turn on)
any OS feature that converts to uppercase -- if you can.

And it was/they were spelled Tektronix, and numbered 401n -- I
remember 4011 and 4014 for certain, and I think 4016 also. I
definitely recall at least _some_ Tek's I used having lowercase, but
it might well have been model-dependent and/or extra-cost-option.

- formerly david.thompson1 || achar(64) || worldnet.att.net
Aug 26 '07 #39

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

32 posts views Thread by Elliot Temple | last post: by
2 posts views Thread by Matthew Louden | last post: by
2 posts views Thread by J. Muenchbourg | last post: by
1 post views Thread by benhoefer | last post: by
6 posts views Thread by Derik | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.