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

Groups > comp.lang.c > #93534 > unrolled thread

Continue with learning C

Back to article view | Back to comp.lang.c

Contents

  Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-15 05:11 -0700
    Re: Continue with learning C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-15 05:29 -0700
    Re: Continue with learning C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-15 15:01 +0100
    Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-15 15:32 +0100
      Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-15 08:10 -0700
      Re: Continue with learning C luser droog <luser.droog@gmail.com> - 2016-09-15 12:06 -0700
        Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-15 21:38 +0100
          Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 21:02 -0700
            Re: Continue with learning C "Osmium" <r124c4u102@comcast.net> - 2016-09-17 08:03 -0500
            Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-17 22:38 +0100
              Re: Continue with learning C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-17 18:14 -0400
                Re: Continue with learning C raltbos@xs4all.nl (Richard Bos) - 2016-09-18 10:47 +0000
                Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-19 01:25 -0700
                  Re: Continue with learning C Ian Collins <ian-news@hotmail.com> - 2016-09-19 20:51 +1200
                  Re: Continue with learning C James Kuyper <jameskuyper@verizon.net> - 2016-09-19 09:49 -0400
                  Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-19 15:15 +0100
                  Re: Continue with learning C Keith Thompson <kst-u@mib.org> - 2016-09-19 11:39 -0700
                    Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 09:55 +0800
                      Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 08:50 +0200
                        Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 18:04 +0800
                          Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 13:25 +0200
                            Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 20:18 +0800
                              Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 15:25 +0200
                      Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-20 08:45 -0400
                        Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 22:05 +0800
                          Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-20 10:56 -0400
                  Re: Continue with learning C Rosario19 <Ros@invalid.invalid> - 2016-09-19 18:55 +0200
                  Re: Continue with learning C Anton Shepelev <anton.txt@gmail.com> - 2016-09-25 01:08 +0300
              Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-17 17:08 -0700
                Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-18 01:11 +0100
                  Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-17 21:32 -0400
                    Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-18 16:27 +0200
                      Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-18 16:08 -0400
                    Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 07:30 -0700
                      Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-18 16:07 -0400
                  Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-18 16:38 +0200
                    Re: Continue with learning C BartC <bc@freeuk.com> - 2016-09-18 16:37 +0100
                      Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-18 23:54 +0800
                        Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 16:56 -0700
                      Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-18 17:05 +0100
                        Re: Continue with learning C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 12:28 -0400
                          Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 17:00 -0700
                        Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-19 01:40 -0700
                          Re: Continue with learning C "Osmium" <r124c4u102@comcast.net> - 2016-09-19 08:55 -0500
                      Re: Continue with learning C "Osmium" <r124c4u102@comcast.net> - 2016-09-18 11:31 -0500
                        Re: Continue with learning C Ian Collins <ian-news@hotmail.com> - 2016-09-19 07:25 +1200
                        Re: Continue with learning C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 20:36 +0100
                        Re: Continue with learning C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 15:45 -0400
                        Re: Continue with learning C Rosario19 <Ros@invalid.invalid> - 2016-09-19 18:58 +0200
                      Re: Continue with learning C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-18 09:55 -0700
                        Re: Continue with learning C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-18 10:12 -0700
                        Re: Continue with learning C luser droog <luser.droog@gmail.com> - 2016-09-18 13:11 -0700
                      Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-18 21:54 +0200
                        Re: Continue with learning C supercat@casperkitty.com - 2016-09-18 15:58 -0700
                          Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-19 07:09 +0100
                          Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-19 10:04 +0200
                            Re: Continue with learning C BartC <bc@freeuk.com> - 2016-09-19 10:38 +0100
                              Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-19 13:29 +0200
                            Re: Continue with learning C supercat@casperkitty.com - 2016-09-19 08:04 -0700
                              Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 09:33 +0800
                                Re: Continue with learning C supercat@casperkitty.com - 2016-09-19 20:47 -0700
                                  Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 09:00 +0200
                                    Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 17:59 +0800
                                      Re: Continue with learning C Ike Naar <ike@iceland.freeshell.org> - 2016-09-20 17:24 +0000
                              Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 08:57 +0200
                                Re: Continue with learning C supercat@casperkitty.com - 2016-09-20 10:53 -0700
                        Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-19 13:19 +0800
                      Re: Continue with learning C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-19 01:30 +0100
        Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-19 01:15 -0700
    Re: Continue with learning C Barry Schwarz <schwarzb@dqel.com> - 2016-09-15 12:38 -0700
    Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-21 11:42 -0700
      Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-21 12:40 -0700
        Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-21 12:49 -0700
        Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-23 14:47 -0700
          Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-23 14:59 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#93534 — Continue with learning C

Hello!

It's been a while since I have posted here and since I have done C exercises. I was doing the course
I have mentioned here a few times, and have also been overwhelmed with other matters. 

It's time to get back to C and to try to learn as much as I can. I will be grateful, as usual, for your guidance,
for your opinion on the best way to choose. 

1) At the moment I have completed chapter 4 of K&R.
2) My main issues, which do not allow me to write correct code, are inability to find concise solutions and
  inability to eliminate redundant code (too much loops, etc), which derives from the first issue; most likely,
  both come from the lack of practice in doing logical exercises and finding solutions.

I have the following books:
K&R
C: a reference manual 5th edition http://careferencemanual.com/

Shall I continue with K&R and simultaneously read through and do exercises in C: A reference book,
or can you recommend a way you think will better serve the goal of learning good coding habits 
(I understand that the main way is to practice as much as possible). 

Thank you very much!

PS: I don't promise that form time to time I will not get into doing something that might be beyond 
my current level, but, please, don't scold me for that. Also, I would like to write my final project in C,
a small arithmetic game. 

During this time I have scratched the surface of Java and php languages, and, well, C is by far the best
one; I do hope that people who learn other languages start with C, and move further only upon mastering
this low level language - I believe it's essential.

PS2: I will be able to move on starting from the beginning of the next week; I will not have access to the 
internet during a few days starting tomorrow. 

[toc] | [next] | [standalone]

#93536

On Thursday, September 15, 2016 at 8:11:31 AM UTC-4, Alla _ wrote:
> It's time to get back to C and to try to learn as much as I can. I will be grateful, as usual, for your guidance,
> for your opinion on the best way to choose. 

If you are looking for general programming in C-like form, then you're
welcome to come and help me on my various projects:

    https://github.com/RickCHodgin/libsf

I have an operating system kernel, xbase programming language, CAlive
compiler (a combination of C and C++ plus some new things), built atop
a new compiler framework I'm constructing called RDC (Rapid Development
Compiler):

    LSA is a simple assembler, LSC is a simple C compiler (both are
    under development):
    https://github.com/RickCHodgin/libsf/tree/master/exodus/tools

    Exodus is the kernel (now called ES/2, plans to be an OS/2 clone):
    https://github.com/RickCHodgin/libsf/tree/master/exodus/source

    VFrP and VJr (xbase languages):
    https://github.com/RickCHodgin/libsf/tree/master/source/vfrp/core
    https://github.com/RickCHodgin/libsf/tree/master/source/vjr/source

    CAlive and RDC:
    https://github.com/RickCHodgin/libsf/tree/master/books/rdc
    https://github.com/RickCHodgin/libsf/tree/master/source/rdc
    https://github.com/RickCHodgin/libsf/tree/master/exodus/tools/rdc

The order I plan to work on them is:

    1)  LSA assembler
    2)  ES/2 kernel
    3)  LSC compiler
    4)  RDC and CAlive (these are built atop each other)
    5)  VJr
    6)  VFrP

I plan on this taking me through about 2022.  I also have hardware projects
I am designing which I intend to begin working on in 2019:

    LibSF 386-x40 CPU:
    https://github.com/RickCHodgin/libsf/tree/master/li386

    Logician hardware 3D source code editor (like Blender for Verilog):
    https://github.com/RickCHodgin/libsf/tree/master/li386/logician

Logician will use an interface similar to this for hardware layout and
design:

    https://www.youtube.com/watch?v=5uxORaVc6sg&t=6m40s

Lots of goals.  Lots of work in moving forward.  So far I'm the only ongoing
contributor.  Here is my license model.  It's basically a public domain
license with one self-accountability caveat unto God, that you will keep
the source code open as per my request (that you will honor God in honoring
my request):

    http://www.libsf.org/licenses/

-----
You'd be welcome if you'd like to look at my source code base (I code in C
with a C++ compiler so there are some constraints and some relaxations at
work compared to standard C, which is a nod to my planned future CAlive
compiler which will code more in this way, with some additional constraint
and relaxations not present in C or C++ today), or if you would like to
contribute you'd be welcome as well.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#93539

Alla _ <modelling.data@gmail.com> writes:
<snip>
> It's time to get back to C and to try to learn as much as I can. I
> will be grateful, as usual, for your guidance,
> for your opinion on the best way to choose. 
>
> 1) At the moment I have completed chapter 4 of K&R.
> 2) My main issues, which do not allow me to write correct code, are
> inability to find concise solutions and
>   inability to eliminate redundant code (too much loops, etc), which
> derives from the first issue; most likely,
>   both come from the lack of practice in doing logical exercises and
> finding solutions.

The trick is to keep re-doing the exercises.  It's hard, because having
struggled to get something working, you don't often feel like doing it
again, but maybe move on to a new exercise before coming back again to
an earlier one.  Set yourself the target of finding a new solution which
will be simpler or clearer or more concise.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#93541

On 15/09/16 13:11, Alla _ wrote:
> Hello!
>
> It's been a while since I have posted here and since I have done C
> exercises. I was doing the course I have mentioned here a few times,
> and have also been overwhelmed with other matters.
>
> It's time to get back to C and to try to learn as much as I can. I
> will be grateful, as usual, for your guidance, for your opinion on
> the best way to choose.
>
> 1) At the moment I have completed chapter 4 of K&R. 2) My main
> issues, which do not allow me to write correct code, are inability to
> find concise solutions and inability to eliminate redundant code (too
> much loops, etc), which derives from the first issue; most likely,
> both come from the lack of practice in doing logical exercises and
> finding solutions.

Ben has addressed this point already.

> I have the following books: K&R C: a reference manual 5th edition
> http://careferencemanual.com/

Normally known as H&S (for "Harbison and Steele"). A good book.

> Shall I continue with K&R and simultaneously read through and do
> exercises in C: A reference book,

Yes, absolutely. Try to keep the two books roughly in synchronisation
wrt what's being taught. (That might not always be possible, but try
anyway, at least a bit.)

> or can you recommend a way you think will better serve the goal of
> learning good coding habits (I understand that the main way is to
> practice as much as possible).

Again, Ben has addressed this.

>
> Thank you very much!
>
> PS: I don't promise that form time to time I will not get into doing
> something that might be beyond my current level, but, please, don't
> scold me for that.

You /will/ get scolded for that, because that's precisely what's got you 
into trouble before.

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

[toc] | [prev] | [next] | [standalone]

#93543

<snip>
Ben and Richard, 
Thank you very much for your answers! Heeded ) I will dive into doing exercises as soon as I am back 
at my computer on Sunday or on Monday. 

[toc] | [prev] | [next] | [standalone]

#93562

On Thursday, September 15, 2016 at 9:32:42 AM UTC-5, Richard Heathfield wrote:
> On 15/09/16 13:11, Alla _ wrote:

> > PS: I don't promise that form time to time I will not get into doing
> > something that might be beyond my current level, but, please, don't
> > scold me for that.
> 
> You /will/ get scolded for that, because that's precisely what's got you 
> into trouble before.
> 

It's not avoidable, IMO. If you're really writing code to expand your skills,
you /will/ sometimes be on this side of the line and sometimes on the other 
side. I think the important point is /it's okay to get scolded/. 
If you learned what to do better from the scolding, then say "I see. Thanks."
If you don't see then you say "I don't see. What about ...? Didn't I 
already ...?"

I'll say that when you get through K&R, I highly recommend van der Linden's
Deep C Secrets. It will refine your understanding, and it's a very 'fun' book.
Told in a light-hearted tone with tons of diverting anecdotes.

[toc] | [prev] | [next] | [standalone]

#93574

On 15/09/16 20:06, luser droog wrote:
> On Thursday, September 15, 2016 at 9:32:42 AM UTC-5, Richard Heathfield wrote:
>> On 15/09/16 13:11, Alla _ wrote:
>
>>> PS: I don't promise that form time to time I will not get into doing
>>> something that might be beyond my current level, but, please, don't
>>> scold me for that.
>>
>> You /will/ get scolded for that, because that's precisely what's got you
>> into trouble before.
>>
>
> It's not avoidable, IMO. If you're really writing code to expand your skills,
> you /will/ sometimes be on this side of the line and sometimes on the other
> side.

No, that's fine. I have no problem with that. The problem comes when you 
try to implement a nuclear power station emergency shutdown program when 
you're still struggling with the while-loop. (I exaggerate, of course.)

One can't stretch one's skills without learning new things. But the pace 
is important. Those who rush ahead without learning the basics properly 
end up being the people who get paid to put bugs in code. We have enough 
of such people already, and need no more.

> I think the important point is /it's okay to get scolded/.
> If you learned what to do better from the scolding, then say "I see. Thanks."

If experienced people are constantly telling you you're going too fast 
and you keep going faster, eventually they'll give up trying to advise 
you. By all means go as fast as you can, but not any faster. That way 
lies slapdash make-do-and-mend programming.

> I'll say that when you get through K&R, I highly recommend van der Linden's
> Deep C Secrets. It will refine your understanding, and it's a very 'fun' book.
> Told in a light-hearted tone with tons of diverting anecdotes.

I'd agree that it's a fun read, but actually it doesn't contain all that 
much generally useful information.

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

[toc] | [prev] | [next] | [standalone]

#93678

On Thursday, September 15, 2016 at 9:38:10 PM UTC+1, Richard Heathfield wrote:
>
> If experienced people are constantly telling you you're going too fast 
> and you keep going faster, eventually they'll give up trying to advise 
> you. By all means go as fast as you can, but not any faster. That way 
> lies slapdash make-do-and-mend programming.
> 
Depends. You can normally sell software with a few bugs in it.
Maybe not to nuclear power plant operators or avionics. But you
can ship a wordprocessor that crashes out when you load in a text
consisting of mixed English and Hebrew. Happens all the time. You
won't sell many copies in Israel, but that's maybe 1% of your 
market.

It's a lot harder to sell unfinished software. If the wordprocessor
won't load or save files at all, because someone is writing a
whizzy load / save system that correctly handles Englsih/Hebrew
mixed texts, it's useless to anyone, including monoglot Anglophones.
You won't sell any copies at all until the work is done.

So let's say we project that the software will sell for 50 months,
or about four years. 1% of those sales will be in Israel. It follows
that getting the mixed English/Hebrew bug out is worth it if and
only if it delays product launch by less than two weeks.

[toc] | [prev] | [next] | [standalone]

#93680

"Malcolm McLean" wrote:

> On Thursday, September 15, 2016 at 9:38:10 PM UTC+1, Richard Heathfield 
> wrote:
>>
>> If experienced people are constantly telling you you're going too fast
>> and you keep going faster, eventually they'll give up trying to advise
>> you. By all means go as fast as you can, but not any faster. That way
>> lies slapdash make-do-and-mend programming.
>>
> Depends. You can normally sell software with a few bugs in it.
> Maybe not to nuclear power plant operators or avionics. But you
> can ship a wordprocessor that crashes out when you load in a text
> consisting of mixed English and Hebrew. Happens all the time. You
> won't sell many copies in Israel, but that's maybe 1% of your
> market.
>
> It's a lot harder to sell unfinished software. If the wordprocessor
> won't load or save files at all, because someone is writing a
> whizzy load / save system that correctly handles Englsih/Hebrew
> mixed texts, it's useless to anyone, including monoglot Anglophones.
> You won't sell any copies at all until the work is done.
>
> So let's say we project that the software will sell for 50 months,
> or about four years. 1% of those sales will be in Israel. It follows
> that getting the mixed English/Hebrew bug out is worth it if and
> only if it delays product launch by less than two weeks.

I don't think Alla has expressed any interest in becoming a professional 
programmer.  For some reason this thread makes me think of those ads that 
used to be in _Popular Science_, "Learn meat cutting at home". 

[toc] | [prev] | [next] | [standalone]

#93697

On 17/09/16 05:02, Malcolm McLean wrote:
> On Thursday, September 15, 2016 at 9:38:10 PM UTC+1, Richard Heathfield wrote:
>>
>> If experienced people are constantly telling you you're going too fast
>> and you keep going faster, eventually they'll give up trying to advise
>> you. By all means go as fast as you can, but not any faster. That way
>> lies slapdash make-do-and-mend programming.
>>
> Depends. You can normally sell software with a few bugs in it.

Don't you find that to be rather embarrassing?

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

[toc] | [prev] | [next] | [standalone]

#93707

On 09/17/2016 05:38 PM, Richard Heathfield wrote:
> On 17/09/16 05:02, Malcolm McLean wrote:
>> On Thursday, September 15, 2016 at 9:38:10 PM UTC+1, Richard Heathfield wrote:
>>>
>>> If experienced people are constantly telling you you're going too fast
>>> and you keep going faster, eventually they'll give up trying to advise
>>> you. By all means go as fast as you can, but not any faster. That way
>>> lies slapdash make-do-and-mend programming.
>>>
>> Depends. You can normally sell software with a few bugs in it.
>
> Don't you find that to be rather embarrassing?

If there was any significant amount of software being sold that was 
entirely bug-free, I'd be embarrassed.
Every piece of software I can remember using has had at least one bug, 
if not many. Of course, there's a selection effect here - if some 
obscure piece of software never has a bug, I'm not likely to notice. But 
that applies only to software that's obscure, for instance device 
drivers, which I never use directly, so I wouldn't notice if they always 
worked well.

[toc] | [prev] | [next] | [standalone]

#93726

"James R. Kuyper" <jameskuyper@verizon.net> wrote:

> On 09/17/2016 05:38 PM, Richard Heathfield wrote:
> > On 17/09/16 05:02, Malcolm McLean wrote:

> >> Depends. You can normally sell software with a few bugs in it.
> >
> > Don't you find that to be rather embarrassing?
> 
> If there was any significant amount of software being sold that was 
> entirely bug-free, I'd be embarrassed.

All software has bugs; and whatever software doesn't have bugs can be
made to have them by changing the specification behind the programmer's
back.

Richard

[toc] | [prev] | [next] | [standalone]

#93783

On Sunday, September 18, 2016 at 1:14:58 AM UTC+3, James R. Kuyper wrote:
> On 09/17/2016 05:38 PM, Richard Heathfield wrote:
> > On 17/09/16 05:02, Malcolm McLean wrote:
> >> On Thursday, September 15, 2016 at 9:38:10 PM UTC+1, Richard Heathfield wrote:
> >>>
> >>> If experienced people are constantly telling you you're going too fast
> >>> and you keep going faster, eventually they'll give up trying to advise
> >>> you. By all means go as fast as you can, but not any faster. That way
> >>> lies slapdash make-do-and-mend programming.
> >>>
> >> Depends. You can normally sell software with a few bugs in it.
> >
> > Don't you find that to be rather embarrassing?
> 
> If there was any significant amount of software being sold that was 
> entirely bug-free, I'd be embarrassed.
I wonder why is that so? Why are bugs staying in final drafts? If, for example,
you print a school textbook on grammar with typos in it, I'll think that it's 
defective and not suitable for sale/use. Why all programs contain bugs? 
Isn't it an indication of a poor quality? Can one allow himself a defect in,
say, building an apartment building, or in building a nuclear factory? 

> Every piece of software I can remember using has had at least one bug, 
> if not many. Of course, there's a selection effect here - if some 
> obscure piece of software never has a bug, I'm not likely to notice. But 
> that applies only to software that's obscure, for instance device 
> drivers, which I never use directly, so I wouldn't notice if they always 
> worked well.

[toc] | [prev] | [next] | [standalone]

#93785

On 09/19/16 08:25 PM, Alla _ wrote:
> On Sunday, September 18, 2016 at 1:14:58 AM UTC+3, James R. Kuyper wrote:
>> On 09/17/2016 05:38 PM, Richard Heathfield wrote:
>>> On 17/09/16 05:02, Malcolm McLean wrote:
>>>> On Thursday, September 15, 2016 at 9:38:10 PM UTC+1, Richard Heathfield wrote:
>>>>>
>>>>> If experienced people are constantly telling you you're going too fast
>>>>> and you keep going faster, eventually they'll give up trying to advise
>>>>> you. By all means go as fast as you can, but not any faster. That way
>>>>> lies slapdash make-do-and-mend programming.
>>>>>
>>>> Depends. You can normally sell software with a few bugs in it.
>>>
>>> Don't you find that to be rather embarrassing?
>>
>> If there was any significant amount of software being sold that was
>> entirely bug-free, I'd be embarrassed.

> I wonder why is that so? Why are bugs staying in final drafts?

Cost.  Quality costs, so a trade off has to be made as to what is 
considered acceptable quality.  If software is safety critical, the high 
cost in both time and money of validation and testing is unavoidable and 
accepted.  Apply the same rigour to something trivial like a game would 
not be acceptable.

> If, for example,
> you print a school textbook on grammar with typos in it, I'll think that it's
> defective and not suitable for sale/use. Why all programs contain bugs?
> Isn't it an indication of a poor quality? Can one allow himself a defect in,
> say, building an apartment building, or in building a nuclear factory?

As above.  Even with the rigorous checking, buildings (as those of us 
who have experienced big earthquakes know only too well) aren't always 
perfect..

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#93798

On 09/19/2016 04:25 AM, Alla _ wrote:
> On Sunday, September 18, 2016 at 1:14:58 AM UTC+3, James R. Kuyper wrote:
>> On 09/17/2016 05:38 PM, Richard Heathfield wrote:
>>> On 17/09/16 05:02, Malcolm McLean wrote:
>>>> On Thursday, September 15, 2016 at 9:38:10 PM UTC+1, Richard Heathfield wrote:
>>>>>
>>>>> If experienced people are constantly telling you you're going too fast
>>>>> and you keep going faster, eventually they'll give up trying to advise
>>>>> you. By all means go as fast as you can, but not any faster. That way
>>>>> lies slapdash make-do-and-mend programming.
>>>>>
>>>> Depends. You can normally sell software with a few bugs in it.
>>>
>>> Don't you find that to be rather embarrassing?
>>
>> If there was any significant amount of software being sold that was 
>> entirely bug-free, I'd be embarrassed.
> I wonder why is that so? Why are bugs staying in final drafts? If, for example,
> you print a school textbook on grammar with typos in it, I'll think that it's 
> defective and not suitable for sale/use. Why all programs contain bugs? 
> Isn't it an indication of a poor quality? Can one allow himself a defect in,
> say, building an apartment building, or in building a nuclear factory? 

I suspect that most published books contain at least one typo.
Electronic submission of text and automated spell-checkers have reduced
the number of errors, but have not eliminated them. A key difference
between software and a textbooks is that a single error in the actual
code will generally cause some malfunction, whereas people read text
with fault-tolerant processing - they might not even notice the typo
(which is why they are so hard to detect), and if they do notice it,
they'll often make a reasonable (and hopefully, correct) guess about
what was intended, and go on without bothering to complain to the
publisher about it.

Have you ever bought a house? I bought a brand-new house from a
reputable builder three years ago. We walked through the house twice
during construction, and once again just before signing the papers. We
hired a professional inspector to join us for the first and last walk
through. We had a home warranty that covered most of the items in the
house for 1 full year, and some items for two. We did further
inspections a few months before the 1 year mark, and again before the 2
year deadline. These inspections were all recommended by the builder's
own guide for buyers. We found several minor problems in every case;
which they generally fixed promptly. This is completely normal for new
home construction, all the guides for new home buyers emphasize the
importance of inspecting the home before and after purchasing it, and
the fact that you don't need to panic just because you find something
during the inspection.

For an apartment building, multiply that by the number of units in the
building. For a nuclear factory (do you mean a nuclear power plant, or
perhaps a uranium enrichment facility?), there's probably a LOT more
inspections before the facility starts operation, and many additional
ones at regular intervals afterwards for as long as it's operating, and
less frequently after it's been shutdown but still radioactive. I
suspect that most of those inspections turn up at least one minor
problem that needs to be addressed.

You may be unaware of this, but virtually every major construction
project has taken the lives of at least one of the construction workers.

In some ways, software is much harder to make error-free than many other
products. A key reason is that every program is a new design; if it
wasn't a new design, there would have been no need to write it, since
you could use an existing program instead. A wise programmer seldom
writes code serving the same purpose twice, and even less often does it
three times - they abstract the repeating part into a separate
sub-routine or macro  or header file and re-use it. Since each program
is new, previous experience isn't as helpful as it can be in other
professions.

[toc] | [prev] | [next] | [standalone]

#93800

On 19/09/16 09:25, Alla _ wrote:
<snip>
> Why all programs contain bugs?

Partly it's because programming is hard. But a large part of it is that 
people are in too much of a hurry to get on with programming something 
cool, so they don't take the time to learn things properly. Does that 
sound familiar?

> Isn't it an indication of a poor quality?

Yes.

> Can one allow himself a defect in,
> say, building an apartment building, or in building a nuclear factory?

The answer to both of those is an unequivocal "yes". If the question 
were "Should..." rather than "Can...", however, the answer is "no".

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

[toc] | [prev] | [next] | [standalone]

#93810

Alla _ <modelling.data@gmail.com> writes:
> On Sunday, September 18, 2016 at 1:14:58 AM UTC+3, James R. Kuyper wrote:
[...]
>> If there was any significant amount of software being sold that was 
>> entirely bug-free, I'd be embarrassed.
> I wonder why is that so? Why are bugs staying in final drafts? If, for example,
> you print a school textbook on grammar with typos in it, I'll think that it's 
> defective and not suitable for sale/use. Why all programs contain bugs? 
> Isn't it an indication of a poor quality? Can one allow himself a defect in,
> say, building an apartment building, or in building a nuclear factory? 
[...]

Before you decide to fix a bug, you have to consider the costs of fixing
it -- and that includes the risk of introducing new bugs.

My house has a triple light switch panel with one of the switches
installed upside down; to turn off all the lights, you have to
flip two of the switches down and one up.  I presume it could be
fixed with essentially no risk of breaking anything else (something
that's rarely the case with software bugs), but it's not worth the
time and effort to do so.  (I don't remember whether the problem was
there from the beginning.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#93833

AT Tuesday 20 September 2016 02:39, Keith Thompson wrote:

> Alla _ <modelling.data@gmail.com> writes:
>> On Sunday, September 18, 2016 at 1:14:58 AM UTC+3, James R. Kuyper wrote:
> [...]
>>> If there was any significant amount of software being sold that was
>>> entirely bug-free, I'd be embarrassed.
>> I wonder why is that so? Why are bugs staying in final drafts? If, for
>> example, you print a school textbook on grammar with typos in it, I'll
>> think that it's defective and not suitable for sale/use. Why all programs
>> contain bugs? Isn't it an indication of a poor quality? Can one allow
>> himself a defect in, say, building an apartment building, or in building
>> a nuclear factory?
> [...]
> 
> Before you decide to fix a bug, you have to consider the costs of fixing
> it -- and that includes the risk of introducing new bugs.
> 
> My house has a triple light switch panel with one of the switches
> installed upside down; to turn off all the lights, you have to
> flip two of the switches down and one up.  I presume it could be
> fixed with essentially no risk of breaking anything else (something
> that's rarely the case with software bugs), but it's not worth the
> time and effort to do so.  (I don't remember whether the problem was
> there from the beginning.)

Your point about estimating the costs - all costs - is exactly on the point.
 For software whose malfunction will not do any real harm it can be 
economically prohibitive to fix a bug. Even if it is just the correction of 
typo fixing that and recompile may introduce another problem. Addresses in 
the program will change, "activating" another bug that has escaped all 
testing and probably never would have lead o a malfunction without the 
change. The does not need to be in the application itself but can be in the 
OS. The change may even trigger a bug in the build chain.

To give a recent example to what this leads with even medium critical 
software in avionics (DO-178 level D): 
The software had been integrated into the final hardware.
The testers went through all 150 test cases over the course of 5 days.
All is passed and I look at one screen and see a typo. Everybody was just 
focused on the functionality and did not see it (and I had not noticed it in 
the months before).
We decided is not acceptable even if it does not lead to any malfunction. 
Just because we asked ourselves how can a customer trust that our software 
is sufficiently safe if we are not even able to put a correct label on the 
screen.
So a problem report was created with the proposed solution (fix the text), 
went through all stages of approval.
The typo was fixed and the software rebuilt and integrated into the hardware 
(this took about 15 minutes)
The testers went again through all test cases for another 5 days.
And that time they also checked every text ;-)

So that is about 10 man days to fix a typo, which by itself just took 15 
minutes.

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#93837

On 20/09/16 03:55, Reinhardt Behm wrote:
> AT Tuesday 20 September 2016 02:39, Keith Thompson wrote:
> 
>> Alla _ <modelling.data@gmail.com> writes:
>>> On Sunday, September 18, 2016 at 1:14:58 AM UTC+3, James R. Kuyper wrote:
>> [...]
>>>> If there was any significant amount of software being sold that was
>>>> entirely bug-free, I'd be embarrassed.
>>> I wonder why is that so? Why are bugs staying in final drafts? If, for
>>> example, you print a school textbook on grammar with typos in it, I'll
>>> think that it's defective and not suitable for sale/use. Why all programs
>>> contain bugs? Isn't it an indication of a poor quality? Can one allow
>>> himself a defect in, say, building an apartment building, or in building
>>> a nuclear factory?
>> [...]
>>
>> Before you decide to fix a bug, you have to consider the costs of fixing
>> it -- and that includes the risk of introducing new bugs.
>>
>> My house has a triple light switch panel with one of the switches
>> installed upside down; to turn off all the lights, you have to
>> flip two of the switches down and one up.  I presume it could be
>> fixed with essentially no risk of breaking anything else (something
>> that's rarely the case with software bugs), but it's not worth the
>> time and effort to do so.  (I don't remember whether the problem was
>> there from the beginning.)
> 
> Your point about estimating the costs - all costs - is exactly on the point.
>  For software whose malfunction will not do any real harm it can be 
> economically prohibitive to fix a bug. Even if it is just the correction of 
> typo fixing that and recompile may introduce another problem. Addresses in 
> the program will change, "activating" another bug that has escaped all 
> testing and probably never would have lead o a malfunction without the 
> change. The does not need to be in the application itself but can be in the 
> OS. The change may even trigger a bug in the build chain.
> 
> To give a recent example to what this leads with even medium critical 
> software in avionics (DO-178 level D): 
> The software had been integrated into the final hardware.
> The testers went through all 150 test cases over the course of 5 days.
> All is passed and I look at one screen and see a typo. Everybody was just 
> focused on the functionality and did not see it (and I had not noticed it in 
> the months before).
> We decided is not acceptable even if it does not lead to any malfunction. 
> Just because we asked ourselves how can a customer trust that our software 
> is sufficiently safe if we are not even able to put a correct label on the 
> screen.
> So a problem report was created with the proposed solution (fix the text), 
> went through all stages of approval.
> The typo was fixed and the software rebuilt and integrated into the hardware 
> (this took about 15 minutes)
> The testers went again through all test cases for another 5 days.
> And that time they also checked every text ;-)
> 
> So that is about 10 man days to fix a typo, which by itself just took 15 
> minutes.
> 

In a less dramatic example (since the system was not safety critical in
any way), I once fixed a bug in an embedded system where it took about
half an hour to identify the problem and make a change in the code to
fix it - but more than a day to re-arrange other code in order to save
the couple of extra bytes the fix required.  Economically, fixing that
bug was probably not justified.

(Sometimes resource constrained systems really are constrained!)

[toc] | [prev] | [next] | [standalone]

#93843

AT Tuesday 20 September 2016 14:50, David Brown wrote:

> On 20/09/16 03:55, Reinhardt Behm wrote:
>> AT Tuesday 20 September 2016 02:39, Keith Thompson wrote:
>> 
>>> Alla _ <modelling.data@gmail.com> writes:
>>>> On Sunday, September 18, 2016 at 1:14:58 AM UTC+3, James R. Kuyper
>>>> wrote:
>>> [...]
>>>>> If there was any significant amount of software being sold that was
>>>>> entirely bug-free, I'd be embarrassed.
>>>> I wonder why is that so? Why are bugs staying in final drafts? If, for
>>>> example, you print a school textbook on grammar with typos in it, I'll
>>>> think that it's defective and not suitable for sale/use. Why all
>>>> programs contain bugs? Isn't it an indication of a poor quality? Can
>>>> one allow himself a defect in, say, building an apartment building, or
>>>> in building a nuclear factory?
>>> [...]
>>>
>>> Before you decide to fix a bug, you have to consider the costs of fixing
>>> it -- and that includes the risk of introducing new bugs.
>>>
>>> My house has a triple light switch panel with one of the switches
>>> installed upside down; to turn off all the lights, you have to
>>> flip two of the switches down and one up.  I presume it could be
>>> fixed with essentially no risk of breaking anything else (something
>>> that's rarely the case with software bugs), but it's not worth the
>>> time and effort to do so.  (I don't remember whether the problem was
>>> there from the beginning.)
>> 
>> Your point about estimating the costs - all costs - is exactly on the
>> point.
>>  For software whose malfunction will not do any real harm it can be
>> economically prohibitive to fix a bug. Even if it is just the correction
>> of typo fixing that and recompile may introduce another problem.
>> Addresses in the program will change, "activating" another bug that has
>> escaped all testing and probably never would have lead o a malfunction
>> without the change. The does not need to be in the application itself but
>> can be in the OS. The change may even trigger a bug in the build chain.
>> 
>> To give a recent example to what this leads with even medium critical
>> software in avionics (DO-178 level D):
>> The software had been integrated into the final hardware.
>> The testers went through all 150 test cases over the course of 5 days.
>> All is passed and I look at one screen and see a typo. Everybody was just
>> focused on the functionality and did not see it (and I had not noticed it
>> in the months before).
>> We decided is not acceptable even if it does not lead to any malfunction.
>> Just because we asked ourselves how can a customer trust that our
>> software is sufficiently safe if we are not even able to put a correct
>> label on the screen.
>> So a problem report was created with the proposed solution (fix the
>> text), went through all stages of approval.
>> The typo was fixed and the software rebuilt and integrated into the
>> hardware (this took about 15 minutes)
>> The testers went again through all test cases for another 5 days.
>> And that time they also checked every text ;-)
>> 
>> So that is about 10 man days to fix a typo, which by itself just took 15
>> minutes.
>> 
> 
> In a less dramatic example (since the system was not safety critical in
> any way), I once fixed a bug in an embedded system where it took about
> half an hour to identify the problem and make a change in the code to
> fix it - but more than a day to re-arrange other code in order to save
> the couple of extra bytes the fix required.  Economically, fixing that
> bug was probably not justified.
> 
> (Sometimes resource constrained systems really are constrained!)

The fix of my typo even saved 2 bytes. :-)

But I know what you mean. Having been limited myself to just 1k EPROM and 32 
bytes of RAM (not in the above case).

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web