Help with a C program

[SK]

Hi
I am trying to teach myself how to program in C. I am a physician
hoping to be able to help restructure my office. Anyhow, I amhoping
that the porblem I am having is simple to those much more experienced
in programming. I am trying to use the concept of arrays to calculate
the hours of my backoffice staff, however I am getting a ridiculous
amount of error lines. If any one has time to help me that would be
great. I am using the free devc++ compiler.
Thanks in advance to anyone who offers some advice.
SK
//Specs to be added later

//C Libraries
#include <stdio.h>
#include <math.h>
#include <string.h>


//Global Constants
# define FULLNAME[20]
# define EMPLOYEES[1000]



/*Define the structure.*/
struct EMP_WeeklyPay
{
char first_name[FULLNAME];
char last_name[FULLNAME];
float RegHr;
float wage;
float OTHr;
float OTHrPay;
float GrossPay;
}


/*Rename the structure syntax.*/
typedef EMP_WeeklyPay EWP;


/*Create an array of structures.*/
EWP emp[EMPLOYEES];

/*Counters*/
int n, numemp;
int count = 0;

/*Strings in input*/
char department[20], fn[FULLNAME], ln[FULLNAME], char again;

/*temporary float*/
float wage, float OTwage, float hours, float RegHr,
float OTHrPay, float OTHr, float GrossPay;


printf("\n\nMountain Pacific Corporation\n");
printf("Department Salary Program\n\n");
printf("Please enter the name of the department: ");
scanf("%s", department);


/*Loop to read in employee wage data*/
for (n = 0; n < EMPLOYEES; ++n){

printf("\nEnter employee # %d: ", count_EMP);
scanf("%s %s", &Fname, &Lname);

printf("\nPlease enter the hourly wage for the employee:
");
scanf("%f", &wage);

printf("\nPlease enter the number of hours worked this"
" week: ");
scanf("%f", &hours);

printf("\nThank you. Process another employee?");
scanf("%s", &again);

}


/*Read in the input*/
numemp = scanf("%11s%11s%f%f%f%f%f", fn, ln, &RegHr,
&wage, &OTHr, &OTHrPay, &GrossPay);


/*Check if user is done*/
printf("\nThank you. Process another employee?");
scanf("%s", &again);

while(again == 'Y' || again == 'y');

if(again != 'Y' && again !='y');
printf("End of processing\n\n\n");


/*Process the input*/
if(num == 7)
{

if (RegHr > 40)
{
OTHr = hours - 40;
OTHrPay = OT * OTHr * wage;
RegHrPay = 40.0 * wage;
}

else
{
RegHrPay = hours * wage;
OTHrPay = 0.0;

}

GrossPay = RegHrPay + OTHrPay;



strncpy(employee[n].first_name, fn, FULLNAME-1);
employee[n].first_name[FULLNAME-1] = '\0';

strncpy(employee[n].last_name, ln, FULLNAME-1);
employee[n].last_name[FULLNAME-1] = '\0';

employee[n].regularhours = RegHr;
employee[n].wage = wage;
employee[n].overtimehours = OTHr;
employee[n].overtimepay = OTHrPay;
employee[n].GrossPay. = GrossPay;


++count;
}



/*Print Table*/

printf("\n\nMountain Pacific Corporation\n");
printf("Department Salary Program\n\n");

printf("Employee Reg Hrs "
"Overtime Hrs Gross\n");

printf("-----------------------------------------"
"-------------------------\n\n");




for(n=0; n < count; ++n) {
printf("%-35s%-17s%12f%10f%12f%10f%%5f",
employee[n].first_name,
employee[n].last_name, employee[n].RegHr,
employee[n].wage, employee[n].OTHr, employee[n].OTHrPay,
employee[n].GrossPay);
}


}

 

[Jack Klein]

Hi

First things first, good manners. Don't post the same message
separately to different groups. If you are sure it belongs in more
than one group, cross-post it.

I am trying to teach myself how to program in C. I am a physician
hoping to be able to help restructure my office. Anyhow, I amhoping
that the porblem I am having is simple to those much more experienced
in programming. I am trying to use the concept of arrays to calculate
the hours of my backoffice staff, however I am getting a ridiculous
amount of error lines. If any one has time to help me that would be
great. I am using the free devc++ compiler.
Thanks in advance to anyone who offers some advice.
SK
//Specs to be added later

//C Libraries
#include <stdio.h>
#include <math.h>
#include <string.h>


//Global Constants
# define FULLNAME[20]
# define EMPLOYEES[1000]

"Doctor, it hurts when I do this!"

"Then don't do it."

Please provide your instructor's email address and we'll send you
completed assignment directly.

 

[Mark McIntyre]

//Global Constants
# define FULLNAME[20]
# define EMPLOYEES[1000]

I assume you're trying to create a constant FULLNAME with value 20.
#define FULLNAME 20

/*temporary float*/
float wage, float OTwage, float hours, float RegHr,
float OTHrPay, float OTHr, float GrossPay;

Strongly recommend you don't use floats for any mathematical
calculations. They're not accurate enough in most cases.

scanf("%f", &wage);

Strongly recommend you don't use scanf. To explore why, try typing in
unexpected things such as "two thousand", nothing at all, etc.

fgets() is a much safer function. You can sscanf the string
afterwards.

printf("\nPlease enter the number of hours worked this"
" week: ");
scanf("%f", &hours);

printf("\nThank you. Process another employee?");

Don't you need to do someething with wage and hours before you process
the next employee? Store them perhaps?

scanf("%s", &again);
}


/*Read in the input*/

You didn't prompt the user for any input - he won't know what to
type...

while(again == 'Y' || again == 'y');

whats this while doing here? There should be a do somewhere

do {
// stuff
while(condition);


at this point, "core dumped, too many errors, correct those ones and
try again"....

 

[pete]

comp.lang.c:

Please provide your instructor's email address and we'll send you
completed assignment directly.

I wonder if the assignment was stated as
"You are a physician, and hoping ..."?

 

[Richard Heathfield]

SK said:

Hi
I am trying to teach myself how to program in C. I am a physician
hoping to be able to help restructure my office. Anyhow, I amhoping
that the porblem

I believe you. Your spelling is bad enough that you could well be a doctor.
Please understand, however, that you won't be in a position to write good
programs until you've been a programmer for much longer than you were in
medical school.

I am having is simple to those much more experienced
in programming. I am trying to use the concept of arrays to calculate
the hours of my backoffice staff, however I am getting a ridiculous
amount of error lines.

Use a spreadsheet. Or an accounts package. You'll find it much simpler than
writing a C program, and much quicker, and less error-prone. By all means
learn C, but don't do so using "live" data such as staff hours. That's just
plain daft.

After a few years of diligent plugging away on your programming, you'll
possibly be in a position to write a real payroll program in C. But by that
point, you won't want to, because there's much more excitement involved in
writing new programs than in writing programs other people have already
written.

 

[Skarmander]

SK said:




I believe you. Your spelling is bad enough that you could well be a doctor.
Please understand, however, that you won't be in a position to write good
programs until you've been a programmer for much longer than you were in
medical school.

You're laying it on a little thick. Your statements also imply that
becoming a good programmer is harder than becoming a good doctor, a
statement I doubt you are qualified to make, unless indeed you are
experienced in both -- but then I would have expected you to mention that.

There's also the fact that writing "good" programs is not half as hard
as it's made out to be. Writing good programs that meet challenging
requirements is; likewise, writing good programs when you're used to
writing bad ones.

After a few years of diligent plugging away on your programming, you'll
possibly be in a position to write a real payroll program in C. But by that
point, you won't want to, because there's much more excitement involved in
writing new programs than in writing programs other people have already
written.

If you get to be so lucky to do that in the first place, as opposed to
just having to *maintain* programs other people have written, which is
by far the most common and unrewarding kind of job for programmers...
but that's another story.

S.

 

[Richard Heathfield]

Skarmander said:

You're laying it on a little thick.

I don't think so. What I said is, I think, accurate.

Your statements also imply that
becoming a good programmer is harder than becoming a good doctor,

I didn't actually mention "good doctor" at all.

a
statement I doubt you are qualified to make, unless indeed you are
experienced in both -- but then I would have expected you to mention that.

Well, I'm not a doctor. But in fact programming is vastly more complicated
than general medical practice. The doctor has just one (admittedly very
complex) system to worry about, and he can devote years to studying just
that one system. The programmer has to deal with a great many complex
systems at many different levels of abstraction - far more than the doctor
will ever face. (It is normally the case, however, that the stakes are
higher for doctors, since a mistake can cost a patient's life; whilst some
programmers do deal with safety-critical systems, this tends to be the
exception rather than the rule.)

There's also the fact that writing "good" programs is not half as hard
as it's made out to be.

Hmmm. You'd think people would be able to write "Hello, world", wouldn't
you? Most C programmers I encounter can't do this without my being able to
find at least one hole to pick, and usually several.

Writing good programs that meet challenging
requirements is;

Agreed - but I think you'll find that most people find even non-challenging
programs hard to write well.

If you get to be so lucky to do that in the first place, as opposed to
just having to *maintain* programs other people have written, which is
by far the most common and unrewarding kind of job for programmers...

I don't think the OP intends to seek employment in the programming field, so
I don't suppose this applies to him.

 

[Walter Roberson]

Well, I'm not a doctor. But in fact programming is vastly more complicated
than general medical practice. The doctor has just one (admittedly very
complex) system to worry about, and he can devote years to studying just
that one system. The programmer has to deal with a great many complex
systems at many different levels of abstraction - far more than the doctor
will ever face.

I came across an appropriate quotation on this a few days ago:

"If physicians would read two articles per day out of the
six million medical articles published annually, in one year,
they would fall 82 centuries behind in their reading."

-- Miser WF, Critical Appraisal of the Literature,
J Am Board Fam Pract., 12(4):315-333, 1999

 

[pete]

What I said is, I think, accurate.

Even this?: "I believe you."

LOL!

Handwriting, is what doctors are notorious for.

Results 1 - 10 of about 12,800 for "doctor's handwriting".
Results 1 - 10 of about 45 for "doctor's spelling". (0.78 seconds)

 

[Skarmander]

Skarmander said:

I'll mark it OT now for the benefit of people who like to ignore these
things before reading them, though I'm not apologetic about posting
them.

I don't think so. What I said is, I think, accurate.



I didn't actually mention "good doctor" at all.

Hence my use of "imply". Though "allude to" might have been preferable.
Given the rest of your reply, the general sentiment does seem to be that.

Well, I'm not a doctor. But in fact programming is vastly more complicated
than general medical practice. The doctor has just one (admittedly very
complex) system to worry about, and he can devote years to studying just
that one system. The programmer has to deal with a great many complex
systems at many different levels of abstraction - far more than the doctor
will ever face.

This also ignores that the complexity programmer's face is man-made, and
nearly always reflects human thought processes at one step or
another. To a very large extent, we have only ourselves to blame when we
are mired in "a great many complex systems at many different levels of
abstraction" -- and those levels of abstraction, might I add, were
designed to *solve* problems of complexity.

Software is so complex because there are (almost) no physical laws
restraining us; only we can prevent things from spiraling out of
control, by doing the restraining ourselves.

In this sense, comparing the complexity of medicine with that of
programming is not easy. Some parallels can be drawn, but the ultimate
applications of either field will mean some things will never compare well.

Programmers in *particular* should be wary of thinking they are more
versed in understanding and mastering complexity better than other
professions, because they themselves create much of the complexity in
their own field, and thus cannot escape a certain cognitive bias.

(It is normally the case, however, that the stakes are higher for
doctors, since a mistake can cost a patient's life; whilst some
programmers do deal with safety-critical systems, this tends to be
the exception rather than the rule.)

Yes, this is another factor that complicates comparison. I have never
run the risk of killing someone because I made an off-by-one error in a
loop (notwithstanding that a small number of programmers no doubt have);
consequently, while I of course try to do everything to avoid making
such a mistake, I would not give it such a high priority that it
drastically reduces overal effectiveness (however this is defined in
practice).

Doctors had better give some things very unreasonable priorities under
all circumstances, from a programmer's point of view, because they don't
get to restore things from backups. This skews standard operating
procedures somewhat.

Hmmm. You'd think people would be able to write "Hello, world", wouldn't
you? Most C programmers I encounter can't do this without my being able to
find at least one hole to pick, and usually several.

Really? Of the "ha ha, you used void main()" kind? "Hello, world" is the
archetypical example where it's not essentially possible to commit a
design error, because the thing to be done is practically an atomic
operation.

I'd say these errors occur because the C programmers in question are not
sufficiently enamored with the complexities of C. If they were, they
would see them as natural. Try to imagine someone making a mistake in
"Hello, world" in Python -- this would reduce to one's ability to read
and type, which, while essential, don't exactly seem to be
representative of a programmer's skill set.

Whether this reflects on programmers as they program or as how they
construct their tools is another matter. I think that as an illustration
of how programming is tough it's rather poor, because it's exactly the
kind of "single complex system" knowledge doctors (and programmers)
should find so easy to master.

Agreed - but I think you'll find that most people find even non-challenging
programs hard to write well.

This is because the restrictions put into place to manage the complexity
of programming usually allow one to write bad code quickly, and with a
modicum of functionality. That in turn encourages the "make a rough
draft and tweak until it appears to work" approach, which most tools in
fact support and promote, even though it's antithetical to the very
nature of programming (but very compatible with common human thought
processes, and catered to for this very reason).

Programming is not a game of Mastermind, but the way that it's taught
and promoted often allows people to pick up unproductive mental
roadblocks. We could also go for "people are stupid", but that will only
take you so far. (Even though we all know it's true.)

There is also, of course, always a minimum of natural aptitude needed to
master any field; it is true that not any person could just become a
doctor, no more than anyone would be qualified to program a computer if
they just studied long enough. But if good programmers are rarer than
good doctors (and I doubt this, though it's impossible to quantify),
this wouldn't necessarily imply programming is harder in an objective
sense, only that less people are suitable for it.

It is true that the challenge of programming lies not in mastering the
languages or the tools or the systems that are given, even though these
are important practical skills; they lie in cultivating effective
thought processes. Changing the way you think is one of the most
difficult things to do, and programming typically requires a lot of it.
Perhaps it is this that would truly allow us to claim a greater
difficulty factor for programming than most other things.

S.

 

[Richard Heathfield]

pete said:

Even this?: "I believe you."

LOL!

Handwriting, is what doctors are notorious for.

Oops. Touche'. Note, however, that I have never yet met a doctor who could
spell. Some have even got my name wrong, despite having a correct template
from which to copy.

 

[Richard Heathfield]

Skarmander said:

This also ignores that the complexity programmer's face is man-made,

No, it doesn't. The source of the complexity is irrelevant to the person who
has to deal with that complexity. It doesn't matter, from a doctor's point
of view, whether God invented the human body or whether it's a chance
collection of enzymes and cells - he still has to deal with the reality of
its current state. Same for programmers. And computer systems can be way
more complex than human beings (except, perhaps, for the brain, but the
doctor doesn't really know how to deal with that anyway, except for
chopping bits out on special occasions).

Software is so complex because there are (almost) no physical laws
restraining us; only we can prevent things from spiraling out of
control, by doing the restraining ourselves.

Yeah, and we don't, which is why programmers have such a rough time. It
doesn't particularly help the situation that programming is a creative
discipline, and creative people do so love to create stuff!

In this sense, comparing the complexity of medicine with that of
programming is not easy. Some parallels can be drawn, but the ultimate
applications of either field will mean some things will never compare
well.

Programmers in *particular* should be wary of thinking they are more
versed in understanding and mastering complexity better than other
professions, because they themselves create much of the complexity in
their own field, and thus cannot escape a certain cognitive bias.

The cognitive bias is inevitable. We know what we do, and we know what we're
doing. The source of the complexity is irrelevant, and in any case most of
the complexity I face is not complexity I created myself, but complexity
created by other programmers. So the fact that *a* human created it is no
consolation, since it wasn't *this* human that created it.

Doctors had better give some things very unreasonable priorities under
all circumstances, from a programmer's point of view, because they don't
get to restore things from backups. This skews standard operating
procedures somewhat.

(Ring ring, ring ring, ring ring...)

D: Hello?
W: Is that the doctor?
D: Yes, Mrs Wilson, how can I help?
W: It's my husband. I brought him his morning cup of coffee, but he won't
wake up!
D: Hmmm. Fresh or instant?
W: Instant.
D: Do you have any fresh?
W: No.
D: Okay. Could you please bring him his morning cup of coffee again? And
just tell me what happens.
(pause - over the phone, the doctor can just hear "Darling? Darling? Wake
up!")
W: No, he's not responding at all.
D: Okay. We're going to try a little experiment. I'd like you to put on your
wellies or some Doc Martens or something, climb up onto the bed, and give
him a good kicking.
W: Um, is that a good idea?
D: Trust me, I'm a doctor.
W: Okay.
(pause - over the phone, various grunting noises can be heard)
W: Well, I've done that.
D: Okay. Now try the coffee again.
W: Still no response.
D: Oh dear. Tell me, when you acquired your husband, did you happen to
receive a CD-ROM at the same time?

Really? Of the "ha ha, you used void main()" kind? "Hello, world" is the
archetypical example where it's not essentially possible to commit a
design error, because the thing to be done is practically an atomic
operation.

Well, I don't normally laugh at them unless there's a good reason (e.g. "I
want to"), but yeah, that's what I mean. The thing is, if we can't write
"Hello, world" without at least giving people cause for comment, what
chance have we of writing a "real" program properly? The problem, I think,
is that we don't treat the writing of software seriously enough. Because we
can cobble something together and it'll sort of work, kinda, we say "fine,
that's done, now on to the next thing", and the engineering quality is -
well, not zero, but pretty low.

This is because the restrictions put into place to manage the complexity
of programming usually allow one to write bad code quickly, and with a
modicum of functionality. That in turn encourages the "make a rough
draft and tweak until it appears to work" approach, which most tools in
fact support and promote, even though it's antithetical to the very
nature of programming (but very compatible with common human thought
processes, and catered to for this very reason).

Um, precisely. If I'd read that before, I could have saved myself a
paragraph!

It is true that the challenge of programming lies not in mastering the
languages or the tools or the systems that are given, even though these
are important practical skills; they lie in cultivating effective
thought processes. Changing the way you think is one of the most
difficult things to do, and programming typically requires a lot of it.

And, alas, it is not just difficult but extremely rare. I was once asked
whether I knew how to play a particular rock song on guitar. I thought I
did, but I played a particular section in 4/4 (no, that's not a fraction,
just a notational convenience), and my expert guitarist friend shook his
head and said, "no, that's not it". I said, "well, how should it be played
then?" He answered, "it's no good - you've learned to play it in 4/4, so
you'll never be able to adapt to 7/8, which is what it should be". So I
played that section again, this time in 7/8. He was somewhat appalled with
the ease with which I could do it. (No, I'm not a terribly good guitarist -
but I do know how to count up to 7!) People are not, generally speaking,
good at adapting, once they've invested a certain amount of effort in
learning to do - or think - things in a particular way.

 

[Skarmander]

Skarmander said:




No, it doesn't. The source of the complexity is irrelevant to the person who
has to deal with that complexity. It doesn't matter, from a doctor's point
of view, whether God invented the human body or whether it's a chance
collection of enzymes and cells - he still has to deal with the reality of
its current state.

You're missing my point. It matters where the complexity came from
insofar as this dictates the nature of the complexity. A program and the
human body may both be complex, but they're complex in different ways,
and it's not just a difference in how many layers of abstraction there are.

In this sense it *would* matter if "God invented the human body", if we
approximately knew how God thought. (For a naturalistic explanation, we
can substitute "how evolution has worked over the years", which is
likely to be almost as unfathomable.) No matter how complicated and
bizarre a program seems to us, at the far end, eventually, some human
being thought up some abstraction of the code you're looking at now.
This may not help you much in individual cases, but it's something you
implicitly rely on.

Doctors would not get very far, in turn, if they implicitly relied on a
working model of God's mind.

Same for programmers. And computer systems can be way
more complex than human beings (except, perhaps, for the brain, but the
doctor doesn't really know how to deal with that anyway, except for
chopping bits out on special occasions).

You have an almost disdainful idea of the complexity of the human body.
If a computer system is way more complex than a human body, something is
terribly wrong. You think you know complexity when you hear about
millions of lines of code, but a computer program is a child's toy
compared to a genetic blueprint, and tracking a core dump of a running
system to an obscure bug in an ill-understood module is a trivial
exercise compared to determining the root cause of a disease.

What may be accurate (and I really can't tell) is that the complexity of
a human body from the doctor's (or even specialist's) point of view may
be "relatively simple" compared to the actual complexity of the system
as a whole (i.e. he doesn't worry about enzyme folding or mitochondria
but whether it "hurts when I do this"). At *that* level we may perhaps
compare doctors and programmers, but we will probably find out more
about how effective humans can organize complexity than about the actual
measure of complexity involved -- intuitively speaking, since an
objective measure of complexity is a tricky thing.

Yeah, and we don't, which is why programmers have such a rough time. It
doesn't particularly help the situation that programming is a creative
discipline, and creative people do so love to create stuff!

Programmers are like jazz musicians, except that for jazz musicians, it
works.

The source of the complexity is irrelevant, and in any case most of
the complexity I face is not complexity I created myself, but
complexity created by other programmers. So the fact that *a* human
created it is no consolation, since it wasn't *this* human that
created it.

But you do realize how this is a self-perpetuating situation?
Programming is complex because people make it complex, and they're not
overly concerned with simplifying it because everyone has to be smart
enough to deal with someone else's complexity anyway. It's almost the
programmer's equivalent of the Peter principle.

If programmers then point out that programming is so tough and how
nobody is really to blame individually, should we sympathize with them
or mock them? Perhaps both -- but they should be none too eager to draw
this kind of attention.
[section that could be called "what if doctors were tech support"]

Great stuff.

Um, precisely. If I'd read that before, I could have saved myself a
paragraph!

It can be annoying to discuss things with people who agree with you...

People are not, generally speaking, good at adapting, once they've
invested a certain amount of effort in learning to do - or think -
things in a particular way.

"Nothing so needs reforming as other people's habits", as Mark Twain put
it...

S.

 

[icub3d]

(Ring ring, ring ring, ring ring...)

D: Hello?
W: Is that the doctor?
D: Yes, Mrs Wilson, how can I help?
W: It's my husband. I brought him his morning cup of coffee, but he won't
wake up!
D: Hmmm. Fresh or instant?
W: Instant.
D: Do you have any fresh?
W: No.
D: Okay. Could you please bring him his morning cup of coffee again? And
just tell me what happens.
(pause - over the phone, the doctor can just hear "Darling? Darling? Wake
up!")
W: No, he's not responding at all.
D: Okay. We're going to try a little experiment. I'd like you to put on your
wellies or some Doc Martens or something, climb up onto the bed, and give
him a good kicking.
W: Um, is that a good idea?
D: Trust me, I'm a doctor.
W: Okay.
(pause - over the phone, various grunting noises can be heard)
W: Well, I've done that.
D: Okay. Now try the coffee again.
W: Still no response.
D: Oh dear. Tell me, when you acquired your husband, did you happen to
receive a CD-ROM at the same time?

This made reading this OT thread worth it.

 

[Steve]

Skarmander wrote:
[snip]

Perhaps it is this that would truly allow us to claim a greater
difficulty factor for programming than most other things.

One question:

Did you type while using one or both hands?


Regards,

Steve

 

[Skarmander]

Skarmander wrote:
[snip]

Perhaps it is this that would truly allow us to claim a greater
difficulty factor for programming than most other things.

One question:

Did you type while using one or both hands?

Oh, sorry, I forgot.

"But what the **** do I know, I'm just this guy. And English isn't my
native language."

Both hands, definitely. But I *do* like sounding like a pompous ass.

S.

 

[Steve]

Skarmander wrote:
[snip]

Perhaps it is this that would truly allow us to claim a greater
difficulty factor for programming than most other things.

One question:

Did you type while using one or both hands?

Oh, sorry, I forgot.

"But what the **** do I know, I'm just this guy. And English isn't my
native language."

Both hands, definitely. But I *do* like sounding like a pompous ass.

Just checking. I just fell off the turnip truck and I'm not always
sure how I should take some posters. I stand corrected.


Regards,

Steve

 

[Richard Heathfield]

Skarmander said:

You have an almost disdainful idea of the complexity of the human body.

Actually, I think the design of the human body is astoundingly clever.

If a computer system is way more complex than a human body, something is
terribly wrong.

Then something is terribly wrong.

You think you know complexity when you hear about
millions of lines of code, but a computer program is a child's toy
compared to a genetic blueprint,

Oops, paradigm clash. How many GPs do genetics research as part of their
daily work? I thought we were talking about doctors, not propeller-heads.

and tracking a core dump of a running
system to an obscure bug in an ill-understood module is a trivial
exercise compared to determining the root cause of a disease.

"Mrs Wilson, I think your husband has sleepitis. Just on the off-chance that
I'm right, get him to take these pills twice a day, and tell him to stop
doing anything he enjoys. My diagnosis is probably wrong, but you're not a
doctor so how could you possibly catch me out? If he's not better in two
weeks, come back and see me, and we'll go round the whole mill again, with
slightly different pills."

Sounds a lot like most people's approach to debugging, doesn't it?

What may be accurate (and I really can't tell) is that the complexity of
a human body from the doctor's (or even specialist's) point of view may
be "relatively simple" compared to the actual complexity of the system
as a whole (i.e. he doesn't worry about enzyme folding or mitochondria
but whether it "hurts when I do this").

Ah, we are re-approaching reality (admittedly from a slightly unexpected
direction).

At *that* level we may perhaps
compare doctors and programmers, but we will probably find out more
about how effective humans can organize complexity than about the actual
measure of complexity involved -- intuitively speaking, since an
objective measure of complexity is a tricky thing.

A doctor generally refers anything even mildly tricky to a specialist,
whereas a maintenance programmer chasing a bug generally has to deal with
whatever he finds, no matter how scary. About the best he can hope for is
that the guy in the next office (or cubicle, or whatever) will be able to
help out if he gets stuck.

Programmers are like jazz musicians, except that for jazz musicians, it
works.

......
DE 01 00 00 02 0D 00 00 14 00 00 00 01 02 00 00
20 00 00 00 01 02 00 00 4C 07 00 00 01 0B 00 00
3C 08 00 00 01 0F 00 00 CC 08 00 00 01 10 00 00
5C 09 00 00 01 11 00 00 EC 09 00 00 01 02 00 00
......and that's code, man!

But you do realize how this is a self-perpetuating situation?
Yes.

Programming is complex because people make it complex, and they're not
overly concerned with simplifying it because everyone has to be smart
enough to deal with someone else's complexity anyway. It's almost the
programmer's equivalent of the Peter principle.
Yup.

If programmers then point out that programming is so tough and how
nobody is really to blame individually, should we sympathize with them
or mock them?

We should find ways of reducing the complexity that don't just involve
slapping on another layer.

It can be annoying to discuss things with people who agree with you...

I agree!

 

[Skarmander]

Skarmander said:



Oops, paradigm clash. How many GPs do genetics research as part of their
daily work? I thought we were talking about doctors, not propeller-heads.

We were, but then you started comparing program complexity to the
complexity of the human body. You clashed your own pair of dimes.

I think we can wrap up this thread by concluding that I had a nice time
arguing for the sake of arguing, and you were kind enough to indulge me.

S.

 

[Richard Heathfield]

Skarmander said:

We were, but then you started comparing program complexity to the
complexity of the human body.

Only the bits the doctor pokes and prods.