Why Case Sensitive?

[Flash Gordon]

Ian Collins wrote, On 21/07/07 23:42:

Then you have been lucky, my crystal ball is more opaque.
Possibly.

Many of the systems I have worked on have grown and changed
significantly from their original requirements, one I still support was
due for "completion" three years ago and it's still growing as the
market changes. If we had designed it for the current market
conditions, it would never have sold four years ago when it was
originally released.

Sometimes continually changing requirements have forced a project to
fail, although not any project I have been involved in.

A few examples of where I would allow for change are...
You know the tax rates and thresholds will change, so allow for it
You know tax exemptions will appear and disappear, so allow for it
You know the systems you have to interface to will change

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

My way of doing things has probably been influenced by one of the
projects early in my career, which is also a reason I say "almost
always" not always. One look at the code was enough for me to say it was
badly designed, and the project in question was to redesign and
implement it properly. Over the next 10 years after the rewrite there
were several changes to requirements, and none of them involved
significant rewrites because it was designed so that we could change and
adapt it. It was actually a piece of 2nd line test equipment, and is
probably part of why I am heavy on the need to design tests

"Some" is a fair compromise!

That's good then
Even when I worked in the defence industry not all projects required the
same level of documentation, so I certainly do not expect all industries
and all situations to require the same amount. Sometimes the back of a
fag packet is sufficient

 

[Flash Gordon]

Malcolm McLean wrote, On 22/07/07 08:47:

By even trying to document "how a system fits together or the data
flows" you are making the same mistake as a Soviet central planner.

I seriously hope that you are not teaching SW at your university if that
is what you think. Or teaching any form of engineering if it comes to
that. A lot of biology is about understanding (and therefore
documenting) complex systems as well.

Now tell me how a manager if going to get a report on the financial
state of a project if no one has planned the SW systems so that the
information is in one place instead of, for example, scattered over 50
spreadsheets on 20 peoples computers. Or how you expected your post to
reach me if someone had not designed how packets would flow through the
internet and how Usenet would work on top of that flow. Tell me how you
expect your car to work if no one has designed how all the components
will fit together, since without that design your petrol pump might not
be able to deliver enough petrol to your engine and the fuel pipe might
not reach from the fuel tank.

Bits are not people and nor are instructions, this is why you are
allowed to have your computer execute instructions at an incredible rate
but you are not even allowed to execute one person.

 

[Charlton Wilbur]

FG> Malcolm McLean wrote, On 22/07/07 08:47:

FG> I seriously hope that you are not teaching SW at your
FG> university if that is what you think. Or teaching any form of
FG> engineering if it comes to that. A lot of biology is about
FG> understanding (and therefore documenting) complex systems as
FG> well.

Given the tenor of his other technial posts, I think he meant it
exactly as you're interpreting it.

But what he says is true, in one sense: Big Design Up Front almost
never works (and when it does, it's in spite of itself), no matter how
hard you try. Complicated systems either grow from simple systems or
are made up of smaller complicated systems that grew from simple
systems and communicate with other complicated systems; designing and
building a big complicated system without understanding that and
taking pains to understand the underlying simpler systems means your
project is likely to fail.

On the other hand, once a system exists, it's certainly possible to
document how it works. There's even a name for this, in the
non-technical world: ISO 9000, and for something that Mr McLean thinks
is imposible and irrelevant, there seem to be a heck of a lot of
people doing it successfully.

Charlton

 

[Charlton Wilbur]

FG> Sometimes continually changing requirements have forced a
FG> project to fail, although not any project I have been involved
FG> in.

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.

FG> The customer may well not require that these things be
FG> changeable, but from my knowledge of the application domain I
FG> *know* they will change over the life of the project, so I
FG> design the system in such a way that the can be changed in a
FG> nice 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

 

[Flash Gordon]

Charlton Wilbur wrote, On 22/07/07 16:58:

FG> Sometimes continually changing requirements have forced a
FG> project to fail, although not any project I have been involved
FG> in.

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.

FG> The customer may well not require that these things be
FG> changeable, but from my knowledge of the application domain I
FG> *know* they will change over the life of the project, so I
FG> design the system in such a way that the can be changed in a
FG> nice 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]

Charlton Wilbur wrote, On 22/07/07 16:51:

FG> Malcolm McLean wrote, On 22/07/07 08:47:


FG> I seriously hope that you are not teaching SW at your
FG> university if that is what you think. Or teaching any form of
FG> engineering if it comes to that. A lot of biology is about
FG> understanding (and therefore documenting) complex systems as
FG> well.

Given the tenor of his other technial posts, I think he meant it
exactly as you're interpreting it.

That was my fear. However, I can't remember which department he works in.

But what he says is true, in one sense: Big Design Up Front almost
never works (and when it does, it's in spite of itself), no matter how
hard you try.

I've already said was does not necessarily have to document to the Nth
degree, but if you don't know where you are going you won't know which
components to grab.

> Complicated systems either grow from simple systems or
are made up of smaller complicated systems that grew from simple
systems and communicate with other complicated systems;

Yes, and the systems that work well had people looking at it at each
stage designing what the next stage was and thinking about where it was
likely to go in the longer term.

> designing and
building a big complicated system without understanding that and
taking pains to understand the underlying simpler systems means your
project is likely to fail.

Yes, I agree.

On the other hand, once a system exists, it's certainly possible to
document how it works.

Or even build up the documentation as you go. Then you can discus your
plans with others and make sure that they appear sane

> There's even a name for this, in the
non-technical world: ISO 9000, and for something that Mr McLean thinks
is imposible and irrelevant, there seem to be a heck of a lot of
people doing it successfully.

Yup.

 

[Malcolm McLean]

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.

 

[Flash Gordon]

Malcolm McLean wrote, On 22/07/07 19:44:

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.

 

[Malcolm McLean]

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.

 

[Flash Gordon]

Malcolm McLean wrote, On 22/07/07 22:51:

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.

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

 

[Dik T. Winter]

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

 

[Peter J. Holzer]

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]

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

 

[Malcolm McLean]

Malcolm McLean wrote, On 22/07/07 22:51:

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.

 

[Flash Gordon]

Malcolm McLean wrote, On 24/07/07 20:52:

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.

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

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.

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.

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.

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.

 

[David Thompson]

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