Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #72122

Re: [OT] programming

Show all headers | View raw

On 07/10/15 09:06, asetofsymbols@gmail.com wrote:
> I said that because people seems
> to me use their intelligence
> for make more difficult than what
> could be something...

Undoubtedly some people do. Unfortunately, though, very often it is not 
the case that people are making things more difficult than they need to 
be, but that things are more difficult than first meets the eye.

Consider, for example, a program that will find out the bit distribution 
of a file, by which I mean the number of times each particular bit is 
used within the file.

What could be simpler?

Okay, how are we going to find out the name of the file? Command line? 
Good idea. But what if we're on a platform where command line arguments 
are not supported? (I don't know if there is such a platform, but the C 
Standard certainly doesn't forbid it: argc is allowed to be 0.) Okay, so 
we could read the filename from standard input. But that opens the 
possibility of EOF, so we have to test for that. Once we've got a 
filename (and stripped off any trailing newline if we used fgets to read 
it, and what do we do if the newline isn't there?), how can we be sure 
that it's a legal filename? Does the file exist? Does the program have 
permission to read it? Of course, we could just try opening it and 
seeing what happens, but if we fail we ought to be able to tell the user 
/why/ we failed.

Now we need an array to store the results. Will an unsigned long int for 
each bit be sufficient? Large files are becoming more common, and it 
would only take a 32GB+1byte file to break 32-bit unsigned longs. But 
that assumes there are 8 bits in a byte. On most systems that's true, 
but at least one 32-bit byte platform does exist, so maybe we need to 
cater for that.

And so on, and so on. For such a simple task, there are so many tiny 
complications. And they all add up.

The complications are real. They are not invented for the sake of making 
things difficult. And when we write a "simple" program, very often it is 
because we are conveniently ignoring a vast number of complications, 
hand-waving them away because we only want to solve the problem that is 
in front of us, without worrying too much about the complexities because 
we're fairly sure they won't matter.

A week or three ago, I blew away an important file (well, not that 
important now, but it was important /then/) because I put it in the 
wrong place in the command line of a program I'd written. I had a 
backup, obviously, but it turned out that I'd blown that away too, 
because I'd run the program with the wrong argument /twice/, and so the 
backup became corrupted.

I had to reconstruct the file using handwritten records. Painfully slow, 
but it taught me to be even more careful about validation than I already 
was. I had over-simplified, and I paid the price for that. What I should 
have done was to check to see whether the file I was overwriting already 
existed and, if so, double-check with the user that it was okay to 
destroy the previous contents of that file. Had I seen such a message, 
I'd have been able to back out before any damage was done.

Having said that, I think you still have a point of sorts. I see people 
arguing over this or that, and thinking "why are they bothering to fight 
over whether method A should be done this way or that way, when surely 
the obvious thing to do is to use method B instead, which is a lot 
simpler and a lot cleaner?"

But much of the time the complication is there because life is 
complicated, and we have to deal with that complicated reality instead 
of the simple reality that many of us would prefer, but which few of us 
seem to be able to agree on.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[OT] programming asetofsymbols@gmail.com - 2015-10-07 00:37 -0700
  Re: [OT] programming mark.bluemel@gmail.com - 2015-10-07 00:49 -0700
    Re: [OT] programming asetofsymbols@gmail.com - 2015-10-07 01:06 -0700
      Re: [OT] programming Richard Heathfield <rjh@cpax.org.uk> - 2015-10-07 10:02 +0100
        Re: [OT] programming Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-07 02:18 -0700
        Re: [OT] programming "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-08 19:07 -0400
          Re: [OT] programming Richard Heathfield <rjh@cpax.org.uk> - 2015-10-09 00:20 +0100
            Re: [OT] programming Bartc <bc@freeuk.com> - 2015-10-09 00:48 +0100
              Re: [OT] programming Keith Thompson <kst-u@mib.org> - 2015-10-08 17:48 -0700
                Re: [OT] programming David Brown <david.brown@hesbynett.no> - 2015-10-09 10:38 +0200
                Re: [OT] programming Keith Thompson <kst-u@mib.org> - 2015-10-09 09:31 -0700
                Re: [OT] programming Richard Damon <Richard@Damon-Family.org> - 2015-10-09 08:34 -0400
                Re: [OT] programming Keith Thompson <kst-u@mib.org> - 2015-10-09 12:05 -0700
              Re: [OT] programming Richard Heathfield <rjh@cpax.org.uk> - 2015-10-09 08:28 +0100
                Re: [OT] programming David Brown <david.brown@hesbynett.no> - 2015-10-09 10:50 +0200
                Re: [OT] programming Keith Thompson <kst-u@mib.org> - 2015-10-09 09:26 -0700
                Re: [OT] programming David Brown <david.brown@hesbynett.no> - 2015-10-11 20:30 +0200
                Re: [OT] programming Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 12:09 -0700
                Re: [OT] programming Bartc <bc@freeuk.com> - 2015-10-09 10:40 +0100
                Re: [OT] programming Keith Thompson <kst-u@mib.org> - 2015-10-09 09:23 -0700
                Re: [OT] programming Bartc <bc@freeuk.com> - 2015-10-09 17:35 +0100
                Re: [OT] programming Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-09 22:50 -0700
            Re: [OT] programming David Brown <david.brown@hesbynett.no> - 2015-10-09 10:34 +0200
          Re: [OT] programming glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-09 00:20 +0000
      Re: [OT] programming "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-07 09:37 -0700

csiph-web