"C: Everyone's favourite programming language isn't a programming language"
https://www.theregister.com/2022/03/23/c_not_a_language/

"Aria Beingessner, a member of the teams that implemented both Rust and
Swift, has an interesting take on some of those (and other) language's
problems – that C isn't a programming language anymore."

"There are many problems with the C language. To pick just a few: it can
be difficult to parse; there are competing and subtly incompatible
variants; and then there are the complex ways C defines and handles
integers and other variables."

"For instance, after much deliberation, a bunch of companies called the
Aspen Group settled on a programming model for 64-bit Unix and Unix-like
OSes called LP64, also known as "4/8/8". Unfortunately, 64-bit Microsoft
Windows uses a different model, called LLP64 or "4/4/8"."
https://techmonitor.ai/technology/aspen_group_hands_over_specification_proposals_overspill_to_xopen_will_implement_common_64_bit
and
https://wiki.wireshark.org/Development/Win64

"And that's before the issues around intmax_t, which the C99 standard
defines as "a signed integer type capable of representing any value of
any signed integer type." As software engineer JeanHeyd Meneide pointed
out, this gets complicated.
https://thephd.dev/intmax_t-hell-c++-c

Lynn

Am 11.07.2022 um 07:44 schrieb Lynn McGuire:
> "C: Everyone's favourite programming language isn't a programming language"
>    https://www.theregister.com/2022/03/23/c_not_a_language/
>
> "Aria Beingessner, a member of the teams that implemented both Rust and
> Swift, has an interesting take on some of those (and other) language's
> problems – that C isn't a programming language anymore."
>
> "There are many problems with the C language. To pick just a few: it can
> be difficult to parse; there are competing and subtly incompatible
> variants; and then there are the complex ways C defines and handles
> integers and other variables."
>
> "For instance, after much deliberation, a bunch of companies called the
> Aspen Group settled on a programming model for 64-bit Unix and Unix-like
> OSes called LP64, also known as "4/8/8". Unfortunately, 64-bit Microsoft
> Windows uses a different model, called LLP64 or "4/4/8"."
>
> https://techmonitor.ai/technology/aspen_group_hands_over_specification_proposals_overspill_to_xopen_will_implement_common_64_bit
>
> and
>    https://wiki.wireshark.org/Development/Win64
>
> "And that's before the issues around intmax_t, which the C99 standard
> defines as "a signed integer type capable of representing any value of
> any signed integer type." As software engineer JeanHeyd Meneide pointed
> out, this gets complicated.
>    https://thephd.dev/intmax_t-hell-c++-c

C lacks almost anything a modern programming language needs.
Having no fixed size native types is almost no problem.

On 7/11/2022 12:33 AM, Bonita Montero wrote:
> Am 11.07.2022 um 07:44 schrieb Lynn McGuire:
>> "C: Everyone's favourite programming language isn't a programming
>> language"
>>     https://www.theregister.com/2022/03/23/c_not_a_language/
>>
>> "Aria Beingessner, a member of the teams that implemented both Rust
>> and Swift, has an interesting take on some of those (and other)
>> language's problems – that C isn't a programming language anymore."
>>
>> "There are many problems with the C language. To pick just a few: it
>> can be difficult to parse; there are competing and subtly incompatible
>> variants; and then there are the complex ways C defines and handles
>> integers and other variables."
>>
>> "For instance, after much deliberation, a bunch of companies called
>> the Aspen Group settled on a programming model for 64-bit Unix and
>> Unix-like OSes called LP64, also known as "4/8/8". Unfortunately,
>> 64-bit Microsoft Windows uses a different model, called LLP64 or
>> "4/4/8"."
>>
>> https://techmonitor.ai/technology/aspen_group_hands_over_specification_proposals_overspill_to_xopen_will_implement_common_64_bit
>>
>> and
>>     https://wiki.wireshark.org/Development/Win64
>>
>> "And that's before the issues around intmax_t, which the C99 standard
>> defines as "a signed integer type capable of representing any value of
>> any signed integer type." As software engineer JeanHeyd Meneide
>> pointed out, this gets complicated.
>>     https://thephd.dev/intmax_t-hell-c++-c
>
> C lacks almost anything a modern programming language needs.
> Having no fixed size native types is almost no problem.
>

Ahhh. Remember way back when C++ was translated into C, then compiled?

On Monday, 11 July 2022 at 06:44:31 UTC+1, Lynn McGuire wrote:
> "C: Everyone's favourite programming language isn't a programming language"
> https://www.theregister.com/2022/03/23/c_not_a_language/

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.

Am 11.07.2022 um 09:58 schrieb Chris M. Thomasson:
> On 7/11/2022 12:33 AM, Bonita Montero wrote:
>> Am 11.07.2022 um 07:44 schrieb Lynn McGuire:
>>> "C: Everyone's favourite programming language isn't a programming
>>> language"
>>>     https://www.theregister.com/2022/03/23/c_not_a_language/
>>>
>>> "Aria Beingessner, a member of the teams that implemented both Rust
>>> and Swift, has an interesting take on some of those (and other)
>>> language's problems – that C isn't a programming language anymore."
>>>
>>> "There are many problems with the C language. To pick just a few: it
>>> can be difficult to parse; there are competing and subtly
>>> incompatible variants; and then there are the complex ways C defines
>>> and handles integers and other variables."
>>>
>>> "For instance, after much deliberation, a bunch of companies called
>>> the Aspen Group settled on a programming model for 64-bit Unix and
>>> Unix-like OSes called LP64, also known as "4/8/8". Unfortunately,
>>> 64-bit Microsoft Windows uses a different model, called LLP64 or
>>> "4/4/8"."
>>>
>>> https://techmonitor.ai/technology/aspen_group_hands_over_specification_proposals_overspill_to_xopen_will_implement_common_64_bit
>>>
>>> and
>>>     https://wiki.wireshark.org/Development/Win64
>>>
>>> "And that's before the issues around intmax_t, which the C99 standard
>>> defines as "a signed integer type capable of representing any value
>>> of any signed integer type." As software engineer JeanHeyd Meneide
>>> pointed out, this gets complicated.
>>>     https://thephd.dev/intmax_t-hell-c++-c
>>
>> C lacks almost anything a modern programming language needs.
>> Having no fixed size native types is almost no problem.
>>
>
> Ahhh. Remember way back when C++ was translated into C, then compiled?

They didn't manage to port exceptions to C and they stopped developing
cfront further.

On 2022-07-11, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> Ahhh. Remember way back when C++ was translated into C, then compiled?

I seem to recall using cfront to build gperf to bootstrap GCC using the
extremely limited free-of-charge C compiler that came with HP-UX 9, i
think it was.

Ben Collver <bencollver@tilde.pink> writes:
>On 2022-07-11, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> Ahhh. Remember way back when C++ was translated into C, then compiled?
>
>I seem to recall using cfront to build gperf to bootstrap GCC using the
>extremely limited free-of-charge C compiler that came with HP-UX 9, i
>think it was.

We used cfront (2.1) to build a distributed operating system, first for the
Motorola 88100, and later for an intel based massivly parallel processor
(MPP) system in the mid 90's.

On Monday, July 11, 2022 at 11:38:40 AM UTC-3, Scott Lurndal wrote:
> Ben Collver <benco...@tilde.pink> writes:
> >On 2022-07-11, Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> >> Ahhh. Remember way back when C++ was translated into C, then compiled?
> >
> >I seem to recall using cfront to build gperf to bootstrap GCC using the
> >extremely limited free-of-charge C compiler that came with HP-UX 9, i
> >think it was.
> We used cfront (2.1) to build a distributed operating system, first for the
> Motorola 88100, and later for an intel based massivly parallel processor
> (MPP) system in the mid 90's.

How did you debug code using cfront?
Did you debug C or C++ code?

On 7/11/2022 5:28 AM, Mark Bluemel wrote:
> On Monday, 11 July 2022 at 06:44:31 UTC+1, Lynn McGuire wrote:
>> "C: Everyone's favourite programming language isn't a programming language"
>> https://www.theregister.com/2022/03/23/c_not_a_language/
>
> 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.

Do you have the date and time of the original posting ? I cannot find it.

I sure do not remember the posting but, I have slept since then.

Lynn

On Monday, July 11, 2022 at 10:24:51 PM UTC+3, Lynn McGuire wrote:
> On 7/11/2022 5:28 AM, Mark Bluemel wrote:
> > On Monday, 11 July 2022 at 06:44:31 UTC+1, Lynn McGuire wrote:
> >> "C: Everyone's favourite programming language isn't a programming language"
> >> https://www.theregister.com/2022/03/23/c_not_a_language/
> >
> > 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.
> Do you have the date and time of the original posting ? I cannot find it.
>
> I sure do not remember the posting but, I have slept since then.
>
> Lynn

From Mar 24, 2022, 5:36:11 PM to Apr 25, 2022, 9:05:03 PM
Your own post: Mar 28, 2022, 7:54:33 PM
https://groups.google.com/g/comp.lang.c/c/S5ygO3G3Jqg/m/usau9_tqAwAJ

Thiago Adams <thiago.adams@gmail.com> writes:
>On Monday, July 11, 2022 at 11:38:40 AM UTC-3, Scott Lurndal wrote:
>> Ben Collver <benco...@tilde.pink> writes:
>> >On 2022-07-11, Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
>> >> Ahhh. Remember way back when C++ was translated into C, then compiled?
>> >
>> >I seem to recall using cfront to build gperf to bootstrap GCC using the
>> >extremely limited free-of-charge C compiler that came with HP-UX 9, i
>> >think it was.
>> We used cfront (2.1) to build a distributed operating system, first for the
>> Motorola 88100, and later for an intel based massivly parallel processor
>> (MPP) system in the mid 90's.
>
>How did you debug code using cfront?
>Did you debug C or C++ code?

How did anyone debug code in 1990? It was an SMP operating system,
using the Chorus Systemes microkernel (written in C++) and a
distributed version of SVR4 (half in C++, half svr4 C code).

Like all good kernels, it had a built-in debugger. Type control-A
at the console serial terminal and the OS dropped into the debugger
(if enabled). Breakpoints, examining memory, stack tracebacks,
instruction disassembly, symbol table compiled into the kernel,
et alia.

Very similar to the kdb in-built kernel debugger I released to the linux mailing
list back in April of 1999. SUSE shipped it as part of the SLES releases and parts
of it still exist in the current linux kernel.

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;

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:

understanding that the simulated P essentially calls simulating halt
decider H in infinite recursion such that the simulated P cannot
possibly terminate normally.

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

*Any H that does handle this case refutes the halting theorem*

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.

*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

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 7/11/2022 2:40 PM, Michael S wrote:
> On Monday, July 11, 2022 at 10:24:51 PM UTC+3, Lynn McGuire wrote:
>> On 7/11/2022 5:28 AM, Mark Bluemel wrote:
>>> On Monday, 11 July 2022 at 06:44:31 UTC+1, Lynn McGuire wrote:
>>>> "C: Everyone's favourite programming language isn't a programming language"
>>>> https://www.theregister.com/2022/03/23/c_not_a_language/
>>>
>>> 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.
>> Do you have the date and time of the original posting ? I cannot find it.
>>
>> I sure do not remember the posting but, I have slept since then.
>>
>> Lynn
>
> From Mar 24, 2022, 5:36:11 PM to Apr 25, 2022, 9:05:03 PM
> Your own post: Mar 28, 2022, 7:54:33 PM
> https://groups.google.com/g/comp.lang.c/c/S5ygO3G3Jqg/m/usau9_tqAwAJ

Sorry, that posting was not me.

Lynn

In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
> Olcott comes here because he is getting a response; Olcott won't go
> anywhere unless people stop responding to him completely. Just ignore him;

Clearly you don't understand how obsessive compulsion works.

On Monday, 11 July 2022 at 22:16:29 UTC+1, 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 have some hope Lynn may take some notice. It's clear that Olcott won't.

On 12/07/2022 10:52, Juha Nieminen wrote:
> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>> Olcott comes here because he is getting a response; Olcott won't go
>> anywhere unless people stop responding to him completely. Just ignore him;
>
> Clearly you don't understand how obsessive compulsion works.

There are degrees of OCD. By normal standards we've all got it... It's
not normal to be able to spend hours at a time staring at code on a
screen looking for that annoying little error.

But yes, some are worse than others.

Andy

Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>> Olcott comes here because he is getting a response; Olcott won't go
>> anywhere unless people stop responding to him completely. Just ignore him;
>
> Clearly you don't understand how obsessive compulsion works.

I don't think he has OCD per se, because people like
that don't have that delusional sense of mission.

Am 12.07.2022 um 14:29 schrieb Bonita Montero:
> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>>> Olcott comes here because he is getting a response; Olcott won't go
>>> anywhere unless people stop responding to him completely. Just ignore
>>> him;
>>
>> Clearly you don't understand how obsessive compulsion works.
>
> I don't think he has OCD per se, because people like
> that don't have that delusional sense of mission.

What it has in common with OCD is that Pete only sees details
and is unable to see the big picture. This is also something
that there is in common with circles of thought.

On 7/12/2022 7:29 AM, Bonita Montero wrote:
> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>>> Olcott comes here because he is getting a response; Olcott won't go
>>> anywhere unless people stop responding to him completely. Just ignore
>>> him;
>>
>> Clearly you don't understand how obsessive compulsion works.
>
> I don't think he has OCD per se, because people like
> that don't have that delusional sense of mission.

Do you really have to go around and around with all this ad hominen
stuff instead of simply validating that the simulated input to H(P,P)
would never terminate normally ???

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 and would never terminate
normally. H aborts its simulation on this basis and rejects this input
as non-halting.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 7/12/2022 7:29 AM, Bonita Montero wrote:
> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>>> Olcott comes here because he is getting a response; Olcott won't go
>>> anywhere unless people stop responding to him completely. Just ignore
>>> him;
>>
>> Clearly you don't understand how obsessive compulsion works.
>
> I don't think he has OCD per se, because people like
> that don't have that delusional sense of mission.

Do you really have to go around and around with all this ad hominen
stuff instead of simply validating that the simulated input to H(P,P)
would never terminate normally ???

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 and would never terminate
normally. H aborts its simulation on this basis and rejects this input
as non-halting.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 7/12/2022 7:46 AM, Bonita Montero wrote:
> Am 12.07.2022 um 14:29 schrieb Bonita Montero:
>> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>>> In comp.lang.c++ Albert Arkwright <Albert.Arkwright@gmail.com> wrote:
>>>> Olcott comes here because he is getting a response; Olcott won't go
>>>> anywhere unless people stop responding to him completely. Just
>>>> ignore him;
>>>
>>> Clearly you don't understand how obsessive compulsion works.
>>
>> I don't think he has OCD per se, because people like
>> that don't have that delusional sense of mission.
>
> What it has in common with OCD is that Pete only sees details
> and is unable to see the big picture. This is also something
> that there is in common with circles of thought.

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

The big picture is that H(P,P) correctly determines that its input would
never terminate normally and H(P,P) does handle the above "impossible"
case.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

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?

Mark Bluemel <mark.bluemel@gmail.com> writes:
> On Monday, 11 July 2022 at 22:16:29 UTC+1, 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 have some hope Lynn may take some notice. It's clear that Olcott won't.

Lynn clearly made an honest mistake, posting a relevant link without
realizing that it had been discussed previously.

Olcott is a crank (take a look at comp.theory if you're curious). They
are not comparable.

My personal solution is to killfile olcott in this newsgroup, so I never
see his posts here. What I do see is other posters replying to him.

If you must reply to olcott here, at least don't quote his entire
article and continue arguing with him.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 7/12/2022 1:01 PM, Keith Thompson wrote:
> Mark Bluemel <mark.bluemel@gmail.com> writes:
>> On Monday, 11 July 2022 at 22:16:29 UTC+1, 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 have some hope Lynn may take some notice. It's clear that Olcott won't.
>
> Lynn clearly made an honest mistake, posting a relevant link without
> realizing that it had been discussed previously.
...
Thank you. I did not realize that the article was old and had already
been posted.

Lynn