Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #85175
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Newsgroups | comp.lang.c, comp.lang.c++ |
| Subject | Re: H(P,P) is pure software engineering that correctly refutes the halting theorem |
| Message-ID | <20220714174829.00006c4a@reddwarf.jmc.corp> (permalink) |
| References | (18 earlier) <Xf2dnQq8xI0AGFL_nZ2dnUU7_8zNnZ2d@giganews.com> <20220714051854.00007268@reddwarf.jmc.corp> <4fidnYzcRIhcBlL_nZ2dnUU7_8xg4p2d@giganews.com> <20220714075236.000000ef@reddwarf.jmc.corp> <TPqdnZvCw81MaVL_nZ2dnUU7_8zNnZ2d@giganews.com> |
| Organization | Jupiter Mining Corporation |
| Date | 2022-07-14 17:48 +0100 |
Cross-posted to 2 groups.
On Thu, 14 Jul 2022 05:49:52 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/14/2022 1:52 AM, Mr Flibble wrote:
> > On Wed, 13 Jul 2022 23:29:53 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/13/2022 11:18 PM, Mr Flibble wrote:
> >>> On Wed, 13 Jul 2022 21:55:25 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/13/2022 9:21 PM, Richard Damon wrote:
> >>>>>
> >>>>> On 7/13/22 10:08 PM, olcott wrote:
> >>>>>> On 7/13/2022 8:55 PM, Richard Damon wrote:
> >>>>>>> On 7/13/22 9:34 PM, olcott wrote:
> >>>>>>>> On 7/13/2022 8:20 PM, Richard Damon wrote:
> >>>>>>>>>
> >>>>>>>>> On 7/13/22 8:06 PM, olcott wrote:
> >>>>>>>>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
> >>>>>>>>>>> On 7/13/22 8:19 AM, olcott wrote:
> >>>>>>>>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
> >>>>>>>>>>>>> On 7/12/22 10:52 PM, olcott wrote:
> >>>>>>>>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
> >>>>>>>>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
> >>>>>>>>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
> >>>>>>>>>>>>>>>>>>>>>> As you'd remember if you actually read this
> >>>>>>>>>>>>>>>>>>>>>> newsgroup, we discussed this nearly 4 months
> >>>>>>>>>>>>>>>>>>>>>> ago when the article came out.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot
> >>>>>>>>>>>>>>>>>>>>> called Olcott? He keeps
> >>>>>>>>>>>>>>>>>>>>> posting the same thing every two weeks and there
> >>>>>>>>>>>>>>>>>>>>> are two guys here who
> >>>>>>>>>>>>>>>>>>>>> keep responding to him, instead of kill-filing
> >>>>>>>>>>>>>>>>>>>>> him.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Olcott comes here because he is getting a
> >>>>>>>>>>>>>>>>>>>>> response; Olcott won't go
> >>>>>>>>>>>>>>>>>>>>> anywhere unless people stop responding to him
> >>>>>>>>>>>>>>>>>>>>> completely. Just ignore him;
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I won't go anywhere until my work is validated
> >>>>>>>>>>>>>>>>>>>> whether or not anyone responds. I just had a very
> >>>>>>>>>>>>>>>>>>>> extensive review (23 emails) by a leading
> >>>>>>>>>>>>>>>>>>>> computer scientist.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Because of this review I was able to simplify my
> >>>>>>>>>>>>>>>>>>>> presentation so that everyone here can easily
> >>>>>>>>>>>>>>>>>>>> verify that I have correctly refuted the halting
> >>>>>>>>>>>>>>>>>>>> theorem on this pure software engineering basis:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> OK, so now that we have easily verified that,
> >>>>>>>>>>>>>>>>>>> would you please stop posting this same thing
> >>>>>>>>>>>>>>>>>>> millions of times?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> For any program H that might determine if programs
> >>>>>>>>>>>>>>>>>> halt, a "pathological" program P, called with some
> >>>>>>>>>>>>>>>>>> input, can pass its own source and its input to H
> >>>>>>>>>>>>>>>>>> and then specifically do the opposite of what H
> >>>>>>>>>>>>>>>>>> predicts P will do. *No H can exist that handles
> >>>>>>>>>>>>>>>>>> this case*
> >>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It is not verified until it is understood that P
> >>>>>>>>>>>>>>>>>> and H implement the classical halting problem
> >>>>>>>>>>>>>>>>>> "impossible input" template (as shown above) and
> >>>>>>>>>>>>>>>>>> refutes this template in that H(P,P) correctly
> >>>>>>>>>>>>>>>>>> determines that its input never terminates
> >>>>>>>>>>>>>>>>>> normally.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *This is the key software engineering that I need
> >>>>>>>>>>>>>>>>>> validated* Most anyone here can easily verify that
> >>>>>>>>>>>>>>>>>> the simulated input to H(P,P) cannot possibly
> >>>>>>>>>>>>>>>>>> terminate normally.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The next level of pure software engineering is that
> >>>>>>>>>>>>>>>>>> H(P,P) correctly predicts that its simulated input
> >>>>>>>>>>>>>>>>>> cannot possibly terminate normally. It may be the
> >>>>>>>>>>>>>>>>>> case that only the top 5% of software engineers can
> >>>>>>>>>>>>>>>>>> validate this point.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>> int H(ptr p, ptr i);
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> if (H(x, x))
> >>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Simulating halt decider H detects that its
> >>>>>>>>>>>>>>>>>> simulated input is essentially calling H in
> >>>>>>>>>>>>>>>>>> infinite recursion. H aborts its simulation on
> >>>>>>>>>>>>>>>>>> this basis and rejects this input as non-halting.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The execution trace of function P() simulated by
> >>>>>>>>>>>>>>>>>> function H() shows:
> >>>>>>>>>>>>>>>>>> (1) Function H() is called from P().
> >>>>>>>>>>>>>>>>>> (2) With the same parameters to H().
> >>>>>>>>>>>>>>>>>> (3) With no instructions in P() that could possibly
> >>>>>>>>>>>>>>>>>> escape this infinitely recursive simulation.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *That was all of the software engineering that I
> >>>>>>>>>>>>>>>>>> need validated*
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Halting problem proofs refuted on the basis of
> >>>>>>>>>>>>>>>>>> software engineering
> >>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> And your property (3) is incorrect the way you use
> >>>>>>>>>>>>>>>>> it. The CORRECT version of (3) looks ALL the way
> >>>>>>>>>>>>>>>>> through the loop, which includes in H, and will
> >>>>>>>>>>>>>>>>> find the condtional there.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H(P,P) correctly predicts that its input cannot
> >>>>>>>>>>>>>>>> possibly terminate normally. (I have better words
> >>>>>>>>>>>>>>>> now).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Except that the program represented by the input, P(P)
> >>>>>>>>>>>>>>> DOES terminate normally if H(P,P) returns 0.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
> >>>>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that
> >>>>>>>>>>>>>> its correctly simulated input cannot possibly terminate
> >>>>>>>>>>>>>> normally.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> WHAT Change of subject?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> IT IS A VERIFIED FACT THAT
> >>>>>>>>>>>> Simulating halt decider H(P,P) correctly predicts that
> >>>>>>>>>>>> its correctly
> >>>>>>>>>>>> simulated input cannot possibly terminate normally.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The only possible correct rebuttal must show all the
> >>>>>>>>>>>> steps of exactly how the input to simulating halt
> >>>>>>>>>>>> decider H(P,P) does terminate normally when H correctly
> >>>>>>>>>>>> simulates this input.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Since I already proved that this is false entirely on the
> >>>>>>>>>>>> basis of verified fact this is impossible.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This requires that a function called in essentially
> >>>>>>>>>>>> infinite recursion to return a value to its caller this
> >>>>>>>>>>>> is impossible.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Most everyone here knows that every function called in
> >>>>>>>>>>>> infinite recursion never returns any value to its caller.
> >>>>>>>>>>>> There is no gibberish that you can say that would
> >>>>>>>>>>>> convince them otherwise.
> >>>>>>>>>>> That can't be a verified fact because the opposite is a
> >>>>>>>>>>> verified fact, that the CORRECT simulation of the input to
> >>>>>>>>>>> H(P,P), which is the correct simulation of P(P) will
> >>>>>>>>>>> actually Halt if H(P,P) returns 0, as you claim it does.
> >>>>>>>>>>
> >>>>>>>>>> I already gave Paul N a great explanation of that on
> >>>>>>>>>> comp.theory. I won't be able to see your reply there
> >>>>>>>>>> because I have you blocked there.
> >>>>>>>>>>
> >>>>>>>>>> My explanation to wjj even sums it up better:
> >>>>>>>>>>
> >>>>>>>>>> On 7/13/2022 3:51 PM, olcott wrote:
> >>>>>>>>>> > On 7/13/2022 3:47 PM, wij wrote:
> >>>>>>>>>> >> The property that an arbitrary program P will finish
> >>>>>>>>>> >> running or not is determined by running P as an
> >>>>>>>>>> >> independent program
> >>>>>>>>>>
> >>>>>>>>>> Because that would require that a halt decider must
> >>>>>>>>>> sometimes make its
> >>>>>>>>>> halt status decision on a basis other than the actual
> >>>>>>>>>> behavior of its actual input that long standing
> >>>>>>>>>> misconception has been refuted.
> >>>>>>>>>
> >>>>>>>>> No, because all the behavior of that program exists will be
> >>>>>>>>> encoded in the representation of the program given to the
> >>>>>>>>> decider.
> >>>>>>>>
> >>>>>>>> The reason that I stop talking to you is that you make false
> >>>>>>>> assumptions that are utterly impervious to all reasoning.
> >>>>>>>>
> >>>>>>>> It is a verified fact that the input that is correctly
> >>>>>>>> simulated by H(P,P) cannot possibly terminate normally. It is
> >>>>>>>> also a verified fact that the direct execution of P(P) does
> >>>>>>>> terminate normally.
> >>>>>>>>
> >>>>>>>> It is also common knowledge that the correct simulation of a
> >>>>>>>> program is a correct measure of the behavior of this program.
> >>>>>>>>
> >>>>>>>> This conclusively proves that H(P,P) is correct to reject its
> >>>>>>>> input as non-halting and the behavior of a non-input cannot
> >>>>>>>> possibly contradict this.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> YOU SAY THAT, but it is a FACT that you H doesn't correctly
> >>>>>>> simulate the input (since it aborts it to return 0) so it
> >>>>>>> doesn't MATTER that if it was a different program it wouldn't
> >>>>>>> be able to simulate to a final state.
> >>>>>>
> >>>>>>
> >>>>>> That you (and others) continue to lack the technical capacity
> >>>>>> to comprehend that H does correctly predict that its complete
> >>>>>> and correct simulation of its input would never result in this
> >>>>>> input terminating normally is far less than no rebuttal at
> >>>>>> all. Until you (and others) gain this technical capacity there
> >>>>>> is no sense continuing a dialogue.
> >>>>>
> >>>>> How is it correct when H(P,P) sayts P(P) is non-halting when a
> >>>>> direct exectuion of P(P) or a correct simulation by
> >>>>> simualte(P,P) (where P still calls the previous H) show that it
> >>>>> halts.
> >>>>
> >>>> Most everyone here can see: (from my updated simplified paper)
> >>>> It is a verified fact that the input that is correctly simulated
> >>>> by H(P,P) cannot possibly terminate normally.
> >>>
> >>> I have shown that a simulating halting decider needn't be
> >>> recursive in nature thus can terminate normally. You are wrong
> >>> on all fronts.
> >>>
> >>> /Flibble
> >>>
> >>
> >> You have shown that you don't fully understand the concept of
> >> unreachable code.
> >
> > Of course I understand the concept of unreachable code in fact I
> > recall giving you several examples of it.
> >
> > /Flibble
> >
>
> I did not say that you have no idea what unreachable code is, you
> simply do not understand that infinite recursion prevents all the
> code below the infinitely recursive function call to ever be reached.
Of course I have always understood that code after an infinite
recursion is unreachable, I have never claimed otherwise however what I
have claimed is that [Strachey 1965] is NOT recursive nor are the
proofs based on it; I have claimed that your solution is broken if it
invokes infinite recursion and I have shown that a simulating halting
decider needn't be recursive in nature (see my post in comp.theory).
Why don't you try acknowledging and addressing what people actually say
rather than misrepresenting what they say to try to make it fit with
your ongoing false narrative?
>
> There are a sequence of many posts that prove this where you believe
> that removing the infinite loop eliminates the pathological
> relationship.
Nope; see above - your solution is broken if it has an issue with
infinite recursion.
>
> You and Richard are at the bottom 10% of technical competence in this
> forum most everyone else could validate that I am correct.
Are you going to actually address our arguments or are you just going to
rely on ad hominem attacks?
/Flibble
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: "C: Everyone's favourite programming language isn't a programming language" Albert Arkwright <Albert.Arkwright@gmail.com> - 2022-07-11 22:13 +0100
H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-11 18:14 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Freethinker <freethinker@mymail.com> - 2022-07-12 16:14 +0200
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-12 20:49 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-12 22:26 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-12 21:29 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-12 22:39 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-12 21:52 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 07:51 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 07:19 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-13 18:27 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 19:51 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 19:06 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 21:20 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 20:34 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 21:55 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 21:08 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 22:21 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 21:55 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 05:18 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 23:27 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 07:53 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-14 05:43 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 07:08 -0400
Re: H(P,P) is pure software engineering that correctly refutes the Muttley@dastardlyhq.com - 2022-07-14 16:06 +0000
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-13 23:29 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 07:52 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem olcott <NoOne@NoWhere.com> - 2022-07-14 05:49 -0500
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 07:12 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-07-14 17:48 +0100
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 07:07 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem om@iki.fi (Otto J. Makela) - 2022-07-18 17:51 +0300
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-13 22:29 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-13 19:41 -0700
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem - Olcott <polcott2@gmail.com> - 2022-07-13 20:03 -0700
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Richard Damon <Richard@Damon-Family.org> - 2022-07-14 21:55 -0400
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-14 22:04 -0700
Re: H(P,P) is pure software engineering that correctly refutes the halting theorem Jens Schweikhardt <usenet@schweikhardt.net> - 2022-07-13 21:08 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Juha Nieminen <nospam@thanks.invalid> - 2022-07-12 09:52 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Vir Campestris <vir.campestris@invalid.invalid> - 2022-07-12 11:27 +0100
Re: "C: Everyone's favourite programming language isn't a programming language" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-12 13:01 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Manu Raju <MR@invalid.invalid> - 2022-07-12 22:19 +0100
Re: "C: Everyone's favourite programming language isn't a programming language" [Olcott] olcott <NoOne@NoWhere.com> - 2022-07-12 21:04 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Juha Nieminen <nospam@thanks.invalid> - 2022-07-13 10:02 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Muttley@dastardlyhq.com - 2022-07-13 15:24 +0000
Re: "C: Everyone's favourite programming language isn't a programming language" Manu Raju <MR@invalid.invalid> - 2022-07-13 19:00 +0100
Re: "C: Everyone's favourite programming language isn't a programming language" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-07-13 15:31 -0700
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-12 14:29 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-12 14:46 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" olcott <NoOne@NoWhere.com> - 2022-07-12 07:48 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Richard Damon <Richard@Damon-Family.org> - 2022-07-12 21:45 -0400
Re: "C: Everyone's favourite programming language isn't a programming language" Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-17 08:18 +0200
Re: "C: Everyone's favourite programming language isn't a programming language" olcott <NoOne@NoWhere.com> - 2022-07-12 07:45 -0500
Re: "C: Everyone's favourite programming language isn't a programming language" Richard Damon <Richard@Damon-Family.org> - 2022-07-12 21:39 -0400
Re: "C: Everyone's favourite programming language isn't a programming language" olcott <NoOne@NoWhere.com> - 2022-07-12 07:45 -0500
csiph-web