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

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

Re: while loop vs do while loop reading from the file issue

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:25 -0800
    Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:48 +1300
      Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 16:46 -0800
        Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-30 13:51 +1300
          Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 17:22 -0800
            Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 02:45 -0800
        Re: while loop vs do while loop reading from the file issue BartC <bc@freeuk.com> - 2016-12-30 01:01 +0000
          Re: while loop vs do while loop reading from the file issue Ian Collins <ian-news@hotmail.com> - 2016-12-30 14:04 +1300
          Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 17:23 -0800
    Re: while loop vs do while loop reading from the file issue asetofsymbols@gmail.com - 2016-12-30 00:56 -0800
    Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 02:41 -0800
      Re: while loop vs do while loop reading from the file issue Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 09:59 -0800
        Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-13 18:48 +0000
          Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 12:08 -0800
            Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-15 23:09 +0000
              Re: while loop vs do while loop reading from the file issue Richard Heathfield <rjh@cpax.org.uk> - 2017-01-15 23:18 +0000
                Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-15 23:37 +0000
                Re: while loop vs do while loop reading from the file issue raltbos@xs4all.nl (Richard Bos) - 2017-01-18 11:32 +0000
                  Re: while loop vs do while loop reading from the file issue Gareth Owen <gwowen@gmail.com> - 2017-01-18 21:25 +0000
        Re: while loop vs do while loop reading from the file issue Keith Thompson <kst-u@mib.org> - 2017-01-13 11:54 -0800
        Re: while loop vs do while loop reading from the file issue Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 11:58 -0800

Page 1 of 2  [1] 2  Next page →

#100488 — Re: while loop vs do while loop reading from the file issue

On Thursday, December 29, 2016 at 8:05:20 PM UTC, Tim Rentsch wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> > On Tuesday, December 20, 2016 at 11:17:00 AM UTC, Richard Bos wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> >>
> >>> On Friday, December 16, 2016 at 8:31:27 PM UTC, Keith Thompson wrote:
> >>>
> >>>> Whether it's strictly structured or not, I'd say that my equivalent
> >>>> version (which you inexplicably snipped):
> >>>>
> >>>>     while ((line = getline()) != endofdata) {
> >>>>         processline(line);
> >>>>     }
> >>>>
> >>>> is more *nearly* "structured" than yours, and that it's much clearer
> >>>> (at least to someone reasonably familiar with C, and such readers
> >>>> are usually my only target audience for C code).
> >>>>
> >>>> Why exactly did you feel the need to post your version with goto
> >>>> statements?  What point were you trying to make?
> >>>
> >>> A structured program should remain a structured program after
> >>> the compiler translates it to machine code.
> >>
> >> That is a.  impossible for most machine languages;  b.  undesirable anyway,
> >> for reasons of optimisation;  and c.  simply ludicrous.  What a compiler
> >> does with high-level source code has no import on how high-level or
> >> well-written the source code is.
> >> The other way 'round, yes:  a badly structured program is bad not only
> >> for human reasons but also because it is often badly optimisable.  But a
> >> well structured program can be optimised at least partly because it
> >> allows a compiler to pull all the tricks in the book.
> >>
> >>> But I think yours and Ben's code violates some rule.
> >>
> >> "Some" rule.  More intentionally vague bluster.  _Name it_.
> 
> Having read through most or all of the postings in this (sub-)
> thread, I would like to make a few general remarks.
> 
> "Structured programming" doesn't have a formal definition.  To
> the extent that it has a definition at all, that derives from
> Dijkstra's monograph "Notes on Structured Programming", which
> introduced both the term and various ideas associated with it.
> 
> Only a small part of NoSP deals with compositional forms (eg,
> while, if, etc) in programs.  In fact, most of NoSP is concerned
> not with programs but with the act of creating programs, which is
> to say the activity of programming.  This makes sense considering
> the title:  it is Notes on Structured Programming, not Notes on
> Structured Programs.
> 
> In the matter of the thread topic, the discussion in NoSP admits
> the possibility that conditions (eg, in while's or if's) could
> have side-effects.  A C-style while() loop, with a controlling
> expression having an action and then a test, satisfies the form
> of while loops that NoSP describes.  Are such things "truly
> structured"?  There is no definitive answer to that question, but
> they do fall into the set of constructs that NoSP considers.
> Moreover I don't see any reason to suppose that the particular
> compositional forms mentioned in NoSP are meant to be exclusive;
> what matters is the properties a compositional form preserves,
> which would for example be satisfied by a "loop-and-a-half"
> construct (which in C could be a while(1) with a single break 
> somewhere in the body of the loop).
> 
> In summary, two points:  the question of whether a C-style while
> loop is "structured" is much ado about nothing;  and the key
> question to ask is not whether a _program_ is structured but
> whether the person who wrote it is using the ideas of structured
> _programming_.
> 
> 
> > I don't have a perfect understanding of structured programming,
> > [...]
> 
> Based on your comments in this and other postings in the thread,
> I would say that is a vast understatement.
>
Present company excepted, people use "structured program" as a synonym
for "well-designed program". They hear "goto is bad". That's typical
of mass thinking, everything (foods, political ideas, medical treatments)
are either "good or bad", and all words eventually degenerate into 
either "hurrah words" or "boo words". 

You can't have a "loop and a half" and still have a structured program.
Sorry, that is abundantly clear to me. The result is not a totally
unstructured program, or a "bad" program necessarily, but one which
violates a property of structured programming, and essential property,
that each block have one point of entry and one point of exit.

Putting square boxes into the expansions of diamonds seems to me
another violation, having thought about it for a while.

[toc] | [next] | [standalone]

#100507

On 12/30/16 10:25 AM, Malcolm McLean wrote:
>
> You can't have a "loop and a half" and still have a structured program.
> Sorry, that is abundantly clear to me. The result is not a totally
> unstructured program, or a "bad" program necessarily, but one which
> violates a property of structured programming, and essential property,
> that each block have one point of entry and one point of exit.

So something like

while( something )
{
   if( doSomething() !=0 )
     goto error;
   doSomethingElse();
}

error:

breaks that rule?

-- 
Ian

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

#100587

On Thursday, December 29, 2016 at 9:48:54 PM UTC, Ian Collins wrote:
> On 12/30/16 10:25 AM, Malcolm McLean wrote:
> >
> > You can't have a "loop and a half" and still have a structured program.
> > Sorry, that is abundantly clear to me. The result is not a totally
> > unstructured program, or a "bad" program necessarily, but one which
> > violates a property of structured programming, and essential property,
> > that each block have one point of entry and one point of exit.
> 
> So something like
> 
> while( something )
> {
>    if( doSomething() !=0 )
>      goto error;
>    doSomethingElse();
> }
> 
> error:
> 
> breaks that rule?
> 
Exactly.

The mistake a lot of people make is to think that since structured
programming is "good", "good" programs are structured (in the sense
intended) whilst bad programs are not. 

The while block has two point of exit. So not a "block" in structured
programming terms.

Use of the term "structured" is confusing, since a program written 
according to a different paradigm isn't necessarily "unstructured"
in the sense that it is spaghetti code or has no discernible structure.

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

#100589

On 12/30/16 01:46 PM, Malcolm McLean wrote:
> On Thursday, December 29, 2016 at 9:48:54 PM UTC, Ian Collins wrote:
>> On 12/30/16 10:25 AM, Malcolm McLean wrote:
>>>
>>> You can't have a "loop and a half" and still have a structured program.
>>> Sorry, that is abundantly clear to me. The result is not a totally
>>> unstructured program, or a "bad" program necessarily, but one which
>>> violates a property of structured programming, and essential property,
>>> that each block have one point of entry and one point of exit.
>>
>> So something like
>>
>> while( something )
>> {
>>     if( doSomething() !=0 )
>>       goto error;
>>     doSomethingElse();
>> }
>>
>> error:
>>
>> breaks that rule?
>>
> Exactly.
>
> The mistake a lot of people make is to think that since structured
> programming is "good", "good" programs are structured (in the sense
> intended) whilst bad programs are not.
>
> The while block has two point of exit. So not a "block" in structured
> programming terms.
>
> Use of the term "structured" is confusing, since a program written
> according to a different paradigm isn't necessarily "unstructured"
> in the sense that it is spaghetti code or has no discernible structure.

Didn't you advocate the use of goto over other control structures in 
structured programming?

-- 
Ian

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

#100596

On Friday, December 30, 2016 at 12:51:09 AM UTC, Ian Collins wrote:
> 
> Didn't you advocate the use of goto over other control structures in 
> structured programming?
> 
Yes.
Structured programming is a paradigm. Understanding the paradigm isn't 
the same as advocating or using it. 

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

#101594

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Friday, December 30, 2016 at 12:51:09 AM UTC, Ian Collins wrote:
>
>> Didn't you advocate the use of goto over other control structures in
>> structured programming?
>
> Yes.
> Structured programming is a paradigm.  Understanding the paradigm isn't
> the same as advocating or using it.

I believe you have some words confused here.  Structured
programming is a programming methodology, not a paradigm.  In
the programming world, areas like procedural programming,
functional programming, or logic programming, are what are
normally referred to as paradigms.

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

#100592

On 30/12/2016 00:46, Malcolm McLean wrote:
> On Thursday, December 29, 2016 at 9:48:54 PM UTC, Ian Collins wrote:
>> On 12/30/16 10:25 AM, Malcolm McLean wrote:
>>>
>>> You can't have a "loop and a half" and still have a structured program.
>>> Sorry, that is abundantly clear to me. The result is not a totally
>>> unstructured program, or a "bad" program necessarily, but one which
>>> violates a property of structured programming, and essential property,
>>> that each block have one point of entry and one point of exit.
>>
>> So something like
>>
>> while( something )
>> {
>>    if( doSomething() !=0 )
>>      goto error;
>>    doSomethingElse();
>> }
>>
>> error:
>>
>> breaks that rule?
>>
> Exactly.
>
> The mistake a lot of people make is to think that since structured
> programming is "good", "good" programs are structured (in the sense
> intended) whilst bad programs are not.
>
> The while block has two point of exit. So not a "block" in structured
> programming terms.

Can't you just wrap the whole thing up in a block?

{while (something){... goto error;...}; error:;}

One entry point, one exit point.

-- 
Bartc

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

#100593

On 12/30/16 02:01 PM, BartC wrote:
> On 30/12/2016 00:46, Malcolm McLean wrote:
>> On Thursday, December 29, 2016 at 9:48:54 PM UTC, Ian Collins wrote:
>>> On 12/30/16 10:25 AM, Malcolm McLean wrote:
>>>>
>>>> You can't have a "loop and a half" and still have a structured program.
>>>> Sorry, that is abundantly clear to me. The result is not a totally
>>>> unstructured program, or a "bad" program necessarily, but one which
>>>> violates a property of structured programming, and essential property,
>>>> that each block have one point of entry and one point of exit.
>>>
>>> So something like
>>>
>>> while( something )
>>> {
>>>     if( doSomething() !=0 )
>>>       goto error;
>>>     doSomethingElse();
>>> }
>>>
>>> error:
>>>
>>> breaks that rule?
>>>
>> Exactly.
>>
>> The mistake a lot of people make is to think that since structured
>> programming is "good", "good" programs are structured (in the sense
>> intended) whilst bad programs are not.
>>
>> The while block has two point of exit. So not a "block" in structured
>> programming terms.
>
> Can't you just wrap the whole thing up in a block?
>
> {while (something){... goto error;...}; error:;}
>
> One entry point, one exit point.

The inner block is still a block.

-- 
Ian

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

#100597

On Friday, December 30, 2016 at 1:01:34 AM UTC, Bart wrote:
> On 30/12/2016 00:46, Malcolm McLean wrote:
> > On Thursday, December 29, 2016 at 9:48:54 PM UTC, Ian Collins wrote:
> >> On 12/30/16 10:25 AM, Malcolm McLean wrote:
> >>>
> >>> You can't have a "loop and a half" and still have a structured program.
> >>> Sorry, that is abundantly clear to me. The result is not a totally
> >>> unstructured program, or a "bad" program necessarily, but one which
> >>> violates a property of structured programming, and essential property,
> >>> that each block have one point of entry and one point of exit.
> >>
> >> So something like
> >>
> >> while( something )
> >> {
> >>    if( doSomething() !=0 )
> >>      goto error;
> >>    doSomethingElse();
> >> }
> >>
> >> error:
> >>
> >> breaks that rule?
> >>
> > Exactly.
> >
> > The mistake a lot of people make is to think that since structured
> > programming is "good", "good" programs are structured (in the sense
> > intended) whilst bad programs are not.
> >
> > The while block has two point of exit. So not a "block" in structured
> > programming terms.
> 
> Can't you just wrap the whole thing up in a block?
> 
> {while (something){... goto error;...}; error:;}
> 
> One entry point, one exit point.
> 
Yes, part of the strength of structured programming is that blocks
themselves don't need to be structured. It's robust to people
chipping away at the system.

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

#100633

Structured programming
:
Each block of code
 has one entry point
 but multiple exit 
 (to the next entry block)

Because if is no in this way
"break" in a loop, or "continue"
or multiple return in a function
are not allowed 

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

#101592

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Thursday, December 29, 2016 at 8:05:20 PM UTC, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>>> On Tuesday, December 20, 2016 at 11:17:00 AM UTC, Richard Bos wrote:
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>>>
>>>>> On Friday, December 16, 2016 at 8:31:27 PM UTC, Keith Thompson wrote:
>>>>>
>>>>>> Whether it's strictly structured or not, I'd say that my equivalent
>>>>>> version (which you inexplicably snipped):
>>>>>>
>>>>>>     while ((line = getline()) != endofdata) {
>>>>>>         processline(line);
>>>>>>     }
>>>>>>
>>>>>> is more *nearly* "structured" than yours, and that it's much clearer
>>>>>> (at least to someone reasonably familiar with C, and such readers
>>>>>> are usually my only target audience for C code).
>>>>>>
>>>>>> Why exactly did you feel the need to post your version with goto
>>>>>> statements?  What point were you trying to make?
>>>>>
>>>>> A structured program should remain a structured program after
>>>>> the compiler translates it to machine code.
>>>>
>>>> That is a.  impossible for most machine languages;  b.  undesirable anyway,
>>>> for reasons of optimisation;  and c.  simply ludicrous.  What a compiler
>>>> does with high-level source code has no import on how high-level or
>>>> well-written the source code is.
>>>> The other way 'round, yes:  a badly structured program is bad not only
>>>> for human reasons but also because it is often badly optimisable.  But a
>>>> well structured program can be optimised at least partly because it
>>>> allows a compiler to pull all the tricks in the book.
>>>>
>>>>> But I think yours and Ben's code violates some rule.
>>>>
>>>> "Some" rule.  More intentionally vague bluster.  _Name it_.
>>
>> Having read through most or all of the postings in this (sub-)
>> thread, I would like to make a few general remarks.
>>
>> "Structured programming" doesn't have a formal definition.  To
>> the extent that it has a definition at all, that derives from
>> Dijkstra's monograph "Notes on Structured Programming", which
>> introduced both the term and various ideas associated with it.
>>
>> Only a small part of NoSP deals with compositional forms (eg,
>> while, if, etc) in programs.  In fact, most of NoSP is concerned
>> not with programs but with the act of creating programs, which is
>> to say the activity of programming.  This makes sense considering
>> the title:  it is Notes on Structured Programming, not Notes on
>> Structured Programs.
>>
>> In the matter of the thread topic, the discussion in NoSP admits
>> the possibility that conditions (eg, in while's or if's) could
>> have side-effects.  A C-style while() loop, with a controlling
>> expression having an action and then a test, satisfies the form
>> of while loops that NoSP describes.  Are such things "truly
>> structured"?  There is no definitive answer to that question, but
>> they do fall into the set of constructs that NoSP considers.
>> Moreover I don't see any reason to suppose that the particular
>> compositional forms mentioned in NoSP are meant to be exclusive;
>> what matters is the properties a compositional form preserves,
>> which would for example be satisfied by a "loop-and-a-half"
>> construct (which in C could be a while(1) with a single break
>> somewhere in the body of the loop).
>>
>> In summary, two points:  the question of whether a C-style while
>> loop is "structured" is much ado about nothing;  and the key
>> question to ask is not whether a _program_ is structured but
>> whether the person who wrote it is using the ideas of structured
>> _programming_.
>>
>>
>>> I don't have a perfect understanding of structured programming,
>>> [...]
>>
>> Based on your comments in this and other postings in the thread,
>> I would say that is a vast understatement.
>
> Present company excepted, people use "structured program" as a synonym
> for "well-designed program".  They hear "goto is bad".  That's typical
> of mass thinking, everything (foods, political ideas, medical treatments)
> are either "good or bad", and all words eventually degenerate into
> either "hurrah words" or "boo words".
>
> You can't have a "loop and a half" and still have a structured program.
> Sorry, that is abundantly clear to me.  The result is not a totally
> unstructured program, or a "bad" program necessarily, but one which
> violates a property of structured programming, and essential property,
> that each block have one point of entry and one point of exit.
>
> Putting square boxes into the expansions of diamonds seems to me
> another violation, having thought about it for a while.

I hope this isn't going to lead to another one of those idiotic
conversations where you insist on a point of terminology and
how "most people" use it, only to have pushback from most or
all of the people who respond.  In case you've forgotten here
is a list to help refresh your memory:

    Malcolm-style
    Malcolm-functions
    Malcolm-logic
    Malcolm-structured-programming
    Malcolm-structure
    Malcolm-class-tree
    Malcolm-call-tree
    Malcolm-speak
    Malcolm-procedures
    Malcolm-blocks
    Malcolm-tree
    Malcolm-constant-character-pointer

So to be clear, my comments are about "structured programming",
and (explicitly) given in the context of Dijkstra's monograph
"Notes on Structured Programming", it having been brought up in
the thread before any posting of mine.  And in that context, a
"loop-and-a-half" fits in with other structuring forms like
while, if-then-else, etc.  Yes, it isn't among the set of forms
that Dijkstra gives in his monograph.  But it does satisfy the
various properties he lists, /like I already said/, and since the
properties are more what NoSP focuses on, it's reasonable to
identify a "loop-and-a-half" as structured /in the sense that the
monograph talks about such things/ -- which is what I did.

I understand you have your own ideas about what certains terms
mean, or ought to mean, or how "most people" use them, but I'm
not saying anything about any of those.  What I am saying is
about how "Notes on Structured Programming" talks about such
things, and my previous comments are made from this perspective
(again - like I already said!).

IMO you would be well advised to pay more attention to what other
people are saying, rather than insisting on imparting your own
world view - no matter how strongly or subconsciously you might
believe it - on what are basically unimportant questions of
terminology.

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

#101630

On Friday, January 13, 2017 at 10:41:29 AM UTC, Tim Rentsch wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 

> I hope this isn't going to lead to another one of those idiotic
> conversations where you insist on a point of terminology and
> how "most people" use it, only to have pushback from most or
> all of the people who respond.  In case you've forgotten here
> is a list to help refresh your memory:
> 
>     Malcolm-style
>     Malcolm-functions
>     Malcolm-logic
>     Malcolm-structured-programming
>     Malcolm-structure
>     Malcolm-class-tree
>     Malcolm-call-tree
>     Malcolm-speak
>     Malcolm-procedures
>     Malcolm-blocks
>     Malcolm-tree
>     Malcolm-constant-character-pointer
> 
> So to be clear, my comments are about "structured programming",
> and (explicitly) given in the context of Dijkstra's monograph
> "Notes on Structured Programming", it having been brought up in
> the thread before any posting of mine.  And in that context, a
> "loop-and-a-half" fits in with other structuring forms like
> while, if-then-else, etc.  Yes, it isn't among the set of forms
> that Dijkstra gives in his monograph.  But it does satisfy the
> various properties he lists, /like I already said/, and since the
> properties are more what NoSP focuses on, it's reasonable to
> identify a "loop-and-a-half" as structured /in the sense that the
> monograph talks about such things/ -- which is what I did.
> 
> I understand you have your own ideas about what certains terms
> mean, or ought to mean, or how "most people" use them, but I'm
> not saying anything about any of those.  What I am saying is
> about how "Notes on Structured Programming" talks about such
> things, and my previous comments are made from this perspective
> (again - like I already said!).
> 
> IMO you would be well advised to pay more attention to what other
> people are saying, rather than insisting on imparting your own
> world view - no matter how strongly or subconsciously you might
> believe it - on what are basically unimportant questions of
> terminology.
>
Loop and a half is your invention. Malcolm-functions are not my invention,
nor is structured programming. I was maybe the first to explicitly say
that except for recursion (which s rare in most structured programs)
a structured program forms a tree, but I can't really claim it as a 
great insight because other people have traditionally used tree-like
notation for the nested blocks. Malcolm-style is my invention or
personality. The rule of three is mine. B64 is my proposal for a near
sub-set of C. The idea of separating IO from functions is mine, though
I doubt I'll prove to have been the first person to make such a proposal.

But loop and a half is your invention. It's your contribution to our understanding
of what structured programming should be.

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

#101646

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> But loop and a half is your invention. It's your contribution to our
> understanding of what structured programming should be.

Here's someone in 1998 discussing loop-and-a-half, and its clear from
context they consider it a well-known idiom
https://users.cs.duke.edu/~ola/patterns/plopd/loops.html#loop-and-a-half

If Tim did invent it, he did so a long time ago, and it really caught on.

Of course, Tim's depth of knowledge of experience does suggest that he's
been programming since the time that punch cards were made of papyrus,
so its not out of the question.

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

#101874

Gareth Owen <gwowen@gmail.com> writes:

> Of course, Tim's depth of knowledge of experience does suggest that he's
> been programming since the time that punch cards were made of papyrus,
> so its not out of the question.

Yes, it's a little known fact that the ancient Egyptians
developed the world's first computers around the time
of Julius Caesar and Cleopatra.  And they had a heck of
a time keeping those papyrus punch card readers working,
I can tell you.

Fortunately they had some oracles who could forsee the
later developments of FORTRAN and System/360 assembly,
so those were available for my first programming course.

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

#101891

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Gareth Owen <gwowen@gmail.com> writes:
>
>> Of course, Tim's depth of knowledge of experience does suggest that he's
>> been programming since the time that punch cards were made of papyrus,
>> so its not out of the question.
>
> Yes, it's a little known fact that the ancient Egyptians
> developed the world's first computers around the time
> of Julius Caesar and Cleopatra.  And they had a heck of
> a time keeping those papyrus punch card readers working,
> I can tell you.

Exacerbated by having to use variable names like "picture of bird",
"two reeds" and "sheaf of corn".

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

#101893

On 15/01/17 23:09, Gareth Owen wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Gareth Owen <gwowen@gmail.com> writes:
>>
>>> Of course, Tim's depth of knowledge of experience does suggest that he's
>>> been programming since the time that punch cards were made of papyrus,
>>> so its not out of the question.
>>
>> Yes, it's a little known fact that the ancient Egyptians
>> developed the world's first computers around the time
>> of Julius Caesar and Cleopatra.  And they had a heck of
>> a time keeping those papyrus punch card readers working,
>> I can tell you.
>
> Exacerbated by having to use variable names like "picture of bird",
> "two reeds" and "sheaf of corn".

And, famously, they had no way to indicate to the calling environment a 
successful termination of their C programs.

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

#101897

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 15/01/17 23:09, Gareth Owen wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>
>>> Gareth Owen <gwowen@gmail.com> writes:
>>>
>>>> Of course, Tim's depth of knowledge of experience does suggest that he's
>>>> been programming since the time that punch cards were made of papyrus,
>>>> so its not out of the question.
>>>
>>> Yes, it's a little known fact that the ancient Egyptians
>>> developed the world's first computers around the time
>>> of Julius Caesar and Cleopatra.  And they had a heck of
>>> a time keeping those papyrus punch card readers working,
>>> I can tell you.
>>
>> Exacerbated by having to use variable names like "picture of bird",
>> "two reeds" and "sheaf of corn".
>
> And, famously, they had no way to indicate to the calling environment
> a successful termination of their C programs.

True, but their interest in pyramids meant that most of their
implementations were free-standing.

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

#102107

Richard Heathfield <rjh@cpax.org.uk> wrote:

> On 15/01/17 23:09, Gareth Owen wrote:
> > Tim Rentsch <txr@alumni.caltech.edu> writes:
> >
> >> Gareth Owen <gwowen@gmail.com> writes:
> >>
> >>> Of course, Tim's depth of knowledge of experience does suggest that he's
> >>> been programming since the time that punch cards were made of papyrus,
> >>> so its not out of the question.
> >>
> >> Yes, it's a little known fact that the ancient Egyptians
> >> developed the world's first computers around the time
> >> of Julius Caesar and Cleopatra.  And they had a heck of
> >> a time keeping those papyrus punch card readers working,
> >> I can tell you.
> >
> > Exacerbated by having to use variable names like "picture of bird",
> > "two reeds" and "sheaf of corn".

Not to mention those fiendish connecting walls.

> And, famously, they had no way to indicate to the calling environment a 
> successful termination of their C programs.

Sure they did: EXIT_SUCCESS need not be 0.

Richard

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

#102155

raltbos@xs4all.nl (Richard Bos) writes:

> Not to mention those fiendish connecting walls.

DNTK NWWHT YR TLKNG BT

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

#101653

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, January 13, 2017 at 10:41:29 AM UTC, Tim Rentsch wrote:
[...]
>> IMO you would be well advised to pay more attention to what other
>> people are saying, rather than insisting on imparting your own
>> world view - no matter how strongly or subconsciously you might
>> believe it - on what are basically unimportant questions of
>> terminology.
>>
> Loop and a half is your invention.

No, it certainly is not.  I suggest you feed the phrase "loop and a
half" to the search engine of your choice.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web