On 25/03/2022 21:29, Guillaume wrote:
> Le 25/03/2022 à 00:10, Ben Bacarisse a écrit :
>>> Here's another recent article on the subject written more
>>> passionately, which I suggest you don't click on either:
>>>
>>>    https://gankra.github.io/blah/c-isnt-a-language/
>>
>> Thanks for the advice -- I have followed it to the letter.
>
> You were well inspired. I had a look and it's even worse than the other
> article. It just looks like a kiddo throwing a tantrum while desperately
> trying to sound smart.

I suspect you guys just don't get the frustrations of not being or
wanting to be a C programmer, but still getting side-tracked into this
C-based API stuff whenever you want to talk to any OS, library or other
language outside the one you're using.

Either by using C, or mainstream languages where those details (like
creating portable, stable bindings) are taken care of for you, or simply
not exposed.

Otherwise you might well be writing colourful articles like that too.

Am 25.03.2022 um 21:19 schrieb Malcolm McLean:
> On Friday, 25 March 2022 at 18:20:16 UTC, Bonita Montero wrote:
>>> First, look at C's flexibility with pointers, which is one of the strong
>>> suits of C (in fact, it's a must have, something that makes C really
>>> good for some kind of programming):
>>> C allows you to declare a pointer to pointer to pointer to function
>>> returning a pointer to function returning a pointer to int.
>> And that's sufficient for you for assessing a language as powerful ???
>> C is for sure not a powerful language but is very rudiemental.
>>
> Indirection is one of the most powerful concepts in programming.

Lowlevel-indirection doesn't make a language powerful.
C belongs to the museum.

On 25/03/2022 20:16, Bart wrote:

> Typedefs should be used when they make sense for the project. If used to
> just to mitigate the awfulness of the type syntax, then something is wrong.
>
> You don't want to do so just to ensure you are declaring the correct
> type here:
>

Why not?

It is very common in programming languages that the basic language
provides some fundamental low-level features, and ways to build on top
of that. Having a logically simple and consistent low-level type system
is a good idea, but it can sometimes result in code that is hard to read
(that applies whether you have lots of asterisk symbols or lots of "ref"
keywords). Typedef lets you give names to the types, resulting in
clearer and more flexible code.

Typedef's are nothing more than an application of the most basic
principle of programming - divide your task into parts and give the
parts names, so that you can concentrate on the part of the code you are
interested in at the time, and so that you can reuse the parts. It's no
different from functions, or structs, or compilation units, or any other
named part of code.

Some languages are truly painful to work with at their fundamental
level, but far nicer at a higher level defined on top of that. If
you've ever looked at low-level "raw" TeX code, it is looks like a
contender for Wikipedia's page on esoteric programming languages. LaTeX
is vastly more friendly - yet it is built on TeX through nothing more
than macros.

Am 25.03.2022 um 20:27 schrieb rek2 hispagatos:

> LOL, this is all FUD people is been attacking C since I was born

People attacking C aren't afraid of sth. but just have
realized that C is a poor language.

Scott Lurndal <scott@slp53.sl.home> wrote:
> Richard Harnden <richard.nospam@gmail.com> writes:
> >"C: Everyone's favourite programming language isn't a programming language"
> >
> >Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
>
> The article doesn't make a whole lot of sense - it's basically just
> bitching because swift and rust can't do everything that C can.

Well, title has little sense. Rather it should be "C is more than
a programming language and it should not". AFAICS the article
takes a few cheap shot at C like taking about 'intmax_t'. IMO
concept of 'intmax_t' is brain-damaged so he has _some_ point.

Main point is that currently C is used to define system and
interlanguage interfaces. This IMO is problematic. But this
is not a fault of C. And it is hard to rectify: due to requirement
of binary compatiblity once introduced system interfaces tend
to stay semi-frozen, main change it gluing new stuff but
keeping rest the same. And due to requirement of source portabilty
new system tend to copy main aspects of older interfaces.

IMHO interface problem has little to do with programming
languages. What is needed is new format for binaries
and new linkers. This format should be abstractly typed
and have namespaces. AFAICS C would easily fit in such
model (but use only tiny part of available capabilities).
The problem is with other languages. More precisely, by
keeping types abstract any language in isolation could
do whatever it wants. But to cooperate nicely they
have to agree on meaning of low level stuff. Currently
C implementation works as a dictator, mostly because
other folks can not agree what to do...

--
Waldek Hebisch

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Guillaume <message@bottle.org> writes:
> > Le 24/03/2022 ? 16:45, Scott Lurndal a ?crit?:
> >> Richard Harnden <richard.nospam@gmail.com> writes:
> >>> "C: Everyone's favourite programming language isn't a programming language"
> >>>
> >>> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>
> >> The article doesn't make a whole lot of sense - it's basically just
> >> bitching because swift and rust can't do everything that C can.
> >
> > And you're putting it lightly.
> > Of course, first thing, without even reading it, is questioning the
> > relevance of such articles written by heavy proponents of
> > "alternative" languages. How much more biased can one be?
> >
> > Digging a bit deeper, there is nothing much to even take from this
> > short article. It's pretty shallow.
> >
> > - C is difficult to parse? C declarations are, for instance, not
> > exactly easy, but it's only very moderately difficult. You can have
> > fun with this to get an idea: https://cdecl.org/ . I has never made
> > it a problem to write a C compiler. There are more of them out there
> > than for any other language, I think. OTOH, there is, AFAIK, only one
> > implementation of Rust. Which to me is in itself a problem. I'm
> > curious to see if it ever even gets to the point of having other
> > competing implementations.
>
> It's probably referring to the typedef issue.
>
> In the absence of typedefs, type names consist of keywords and
> punctuation. A typedef (a feature that was added to the language
> after the syntax had been established) creates a type name that's an
> identifier. It's impossible to parse something that uses a typedef name
> without knowing that it's a typedef name. In effect a typedef adds a
> context-sensitive keyword to the grammar. The parser needs to query the
> symbol table.

Using symbol table is just one of possible solutions. Another
one is to note that true ambiguities are really semantic, so
parser can return tree faithful to all possible meaning. For
example, cast versus function call is semantic problem so
parser can return 'call_or_cast' and let semantic phase
to decide.

> But it's a solved problem and not that big a deal.

Yes.

--
Waldek Hebisch

Maybe this is the idea of clickbait: When the title makes no
sense, it might make you more curious to understand it.

I am in conflict with people who claim that HTML is not a
programming language, so I have written a German-language
text explaining why HTML is indeed a programming language.
But for C, I'm at a loss, I have no such text prepared for C!

PS: If you accept that C is a programming language than
compare:

|This International Standard specifies [...] the semantic
|rules for interpreting C programs[ and] [...] by a conforming
|implementation of C

from a C specification with

|An HTML user agent is any device that interprets HTML documents.

from a HTML specification.

In each case, we have a text (C program, HTML document) that
is being interpreted (by a conforming implementation of C,
by an HTML user agent). The author writes the text (C program,
HTML document) so as to get certain results upon interpretation.
This is programming. International Standards do not require
Turing completenes for a programming language.

An interactive game written in HTML:

web.archive.org/web/20040428174214/http://www.geocities.com/flo_kreidler/tictactoe.html

. Disclaimer: That URI used to work, but I have not checked
it again.

Supersedes: <programming-language-20220326131605@ram.dialup.fu-berlin.de>
["a HTML"->"an HTML","nes "->"ness "]

Maybe this is the idea of clickbait: When the title makes no
sense, it might make you more curious to understand it.

I am in conflict with people who claim that HTML is not a
programming language, so I have written a German-language
text explaining why HTML is indeed a programming language.
But for C, I'm at a loss, I have no such text prepared for C!

PS: If you accept that C is a programming language than
compare:

|This International Standard specifies [...] the semantic
|rules for interpreting C programs[ and] [...] by a conforming
|implementation of C

from a C specification with

|An HTML user agent is any device that interprets HTML documents.

from an HTML specification.

In each case, we have a text (C program, HTML document) that
is being interpreted (by a conforming implementation of C,
by an HTML user agent). The author writes the text (C program,
HTML document) so as to get certain results upon interpretation.
This is programming. International Standards do not require
Turing completeness for a programming language.

An interactive game written in HTML:

web.archive.org/web/20040428174214/http://www.geocities.com/flo_kreidler/tictactoe.html

. Disclaimer: That URI used to work, but I have not checked
it again.

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> I am in conflict with people who claim that HTML is not a
> programming language, so I have written a German-language
> text explaining why HTML is indeed a programming language.

What is the least that you would accept as a programming language? BBML
(Ben's Basic Markup Language) has only <em>emphasis</em> markup. Is
BBML a programming language? BBML2 won't even have that.

> But for C, I'm at a loss, I have no such text prepared for C!
>
> PS: If you accept that C is a programming language than
> compare:
>
> |This International Standard specifies [...] the semantic
> |rules for interpreting C programs[ and] [...] by a conforming
> |implementation of C
>
> from a C specification with
>
> |An HTML user agent is any device that interprets HTML documents.
>
> from a HTML specification.

Which one?

> In each case, we have a text (C program, HTML document) that
> is being interpreted (by a conforming implementation of C,
> by an HTML user agent). The author writes the text (C program,
> HTML document) so as to get certain results upon interpretation.
> This is programming. International Standards do not require
> Turing completenes for a programming language.

A BBML2 use agent is interpreted in order to display a document to the
reader.

--
Ben.

> I am in conflict with people who claim that HTML is not a
> programming language, so I have written a German-language
> text explaining why HTML is indeed a programming language.
> But for C, I'm at a loss, I have no such text prepared for C!

A program has a control flow.
HTML is a static data-structure without a control flow.
So you can't program in HTML.

On Sat, 26 Mar 2022 13:58:04 +0100, Bonita Montero wrote:

>> I am in conflict with people who claim that HTML is not a
>> programming language, so I have written a German-language
>> text explaining why HTML is indeed a programming language.
>> But for C, I'm at a loss, I have no such text prepared for C!
>
> A program has a control flow.
> HTML is a static data-structure without a control flow.
> So you can't program in HTML.

I disagree. In general, a "program" provides instructions to
automation (usually computer automation) and need not contain
control flow. HTML instructs a "web browser" (automated tool) on
how to display data. In that respect, you can write HTML, and the
resulting text will act as a "program" for a web browser. A
similar argument can be made for GCODE (the way 3D printers and
automated mills are "programmed") or even the punch cards used
to control a Jacquard loom.

However, most here (of which I am one) would probably first think
of code written in a Turing-complete language as a "program". A
Turing-complete language /does/ have control flow. If we restrict
"programming" to "writing in Turing-complete languages", then we
exclude HTML, GCODE, and a large number of other human-planned
automated process controls from "programming".

--
Lew Pitcher
"In Skills, We Trust"

On 26/03/2022 10:32, David Brown wrote:
> On 25/03/2022 20:16, Bart wrote:
>
>> Typedefs should be used when they make sense for the project. If used to
>> just to mitigate the awfulness of the type syntax, then something is wrong.
>>
>> You don't want to do so just to ensure you are declaring the correct
>> type here:
>>
>
> Why not?
>
> It is very common in programming languages that the basic language
> provides some fundamental low-level features, and ways to build on top
> of that. Having a logically simple and consistent low-level type system
> is a good idea, but it can sometimes result in code that is hard to read
> (that applies whether you have lots of asterisk symbols or lots of "ref"
> keywords). Typedef lets you give names to the types, resulting in
> clearer and more flexible code.
>
> Typedef's are nothing more than an application of the most basic
> principle of programming - divide your task into parts and give the
> parts names, so that you can concentrate on the part of the code you are
> interested in at the time, and so that you can reuse the parts. It's no
> different from functions, or structs, or compilation units, or any other
> named part of code.
>
> Some languages are truly painful to work with at their fundamental
> level, but far nicer at a higher level defined on top of that. If
> you've ever looked at low-level "raw" TeX code, it is looks like a
> contender for Wikipedia's page on esoteric programming languages. LaTeX
> is vastly more friendly - yet it is built on TeX through nothing more
> than macros.

I haven't argued against using typedefs in a language.

Only against being obliged to use them to overcome severe shortcomings
in the way types are expressed.

That doesn't make the problems go away; it merely papers over them.

And not everyone will actually use typedefs either, then you still have
to wheel out Cdecl.

This type syntax should have been strangled at birth. They were already
existing, /linear/ ways of expressing arbitrary types when C was
devised, and which were easier to parse too.

> I disagree. In general, a "program" provides instructions to
> automation (usually computer automation) and need not contain
> control flow. HTML instructs a "web browser" (automated tool)
> on how to display data.

Then a simple filename is also a program.

On Sat, 26 Mar 2022 15:22:45 +0100, Bonita Montero wrote:

>> I disagree. In general, a "program" provides instructions to
>> automation (usually computer automation) and need not contain
>> control flow. HTML instructs a "web browser" (automated tool)
>> on how to display data.
>
> Then a simple filename is also a program.

Oh? And what automated activity directly follows from "a simple filename"?

--
Lew Pitcher
"In Skills, We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> quotes and writes:
>>Then a simple filename is also a program.
>Oh? And what automated activity directly follows from "a simple filename"?

For example,

cat filename

. "cat" is an interpreter taking the program "filename".
The automatic activity ensues according to the manpage of "cat".

Lew Pitcher <lew.pitcher@digitalfreehold.ca> quotes and writes:
>>Then a simple filename is also a program.
>Oh? And what automated activity directly follows from "a simple filename"?

You may also have a preconception that operational semantics
is the only kind of semantics programming languages can have.
But there are also functional programming languages in which
values are expressed.

On 26/03/2022 14:36, Bart wrote:
> On 26/03/2022 10:32, David Brown wrote:
>> On 25/03/2022 20:16, Bart wrote:
>>
>>> Typedefs should be used when they make sense for the project. If used to
>>> just to mitigate the awfulness of the type syntax, then something is
>>> wrong.
>>>
>>> You don't want to do so just to ensure you are declaring the correct
>>> type here:
>>>
>>
>> Why not?
>>
>> It is very common in programming languages that the basic language
>> provides some fundamental low-level features, and ways to build on top
>> of that.  Having a logically simple and consistent low-level type system
>> is a good idea, but it can sometimes result in code that is hard to read
>> (that applies whether you have lots of asterisk symbols or lots of "ref"
>> keywords).  Typedef lets you give names to the types, resulting in
>> clearer and more flexible code.
>>
>> Typedef's are nothing more than an application of the most basic
>> principle of programming - divide your task into parts and give the
>> parts names, so that you can concentrate on the part of the code you are
>> interested in at the time, and so that you can reuse the parts.  It's no
>> different from functions, or structs, or compilation units, or any other
>> named part of code.
>>
>> Some languages are truly painful to work with at their fundamental
>> level, but far nicer at a higher level defined on top of that.  If
>> you've ever looked at low-level "raw" TeX code, it is looks like a
>> contender for Wikipedia's page on esoteric programming languages.  LaTeX
>> is vastly more friendly - yet it is built on TeX through nothing more
>> than macros.
>
> I haven't argued against using typedefs in a language.
>
> Only against being obliged to use them to overcome severe shortcomings
> in the way types are expressed.
>

Let's just agree to disagree about what shortcomings there might be in
C's type specifications, and those in other languages. IMHO,
consistency and lack of ambiguity are the most important points.

> That doesn't make the problems go away; it merely papers over them.

If typedef's let you use types in C without being bothered by the syntax
issues that you dislike, then then they /have/ made the problem go away.
Papering over them is fine.

In my code, I like to use size-specific types - "int32_t", "uint16_t",
etc. Some C programmers prefer to use "int" or "unsigned short", others
prefer types with shorter names like "i32" or "u16". Typedefs let you
do that, and use the names that suit you without concern for their
underlying definitions. Some people like to write out complicated mixes
of function pointers, arrays, pointers, const, explicitly in C - other
people like to name parts with typedefs and build them up that way.
Both work. In either case, the challenge to understanding the code is
figuring out what the complex type is for, and you'd have exactly the
same issue with types built up in a different syntax (such as in your
languages). At least with typedef's there's a chance the programmer
picked useful names that will give you a clue.

>
> And not everyone will actually use typedefs either, then you still have
> to wheel out Cdecl.
>

Like the vast majority of C programmers, I've never had the need for
Cdecl. Complicated types with more than a couple of levels of
indirection are quite rare, and understanding them is rarely the hard
part of understanding the code in question.

> This type syntax should have been strangled at birth. They were already
> existing, /linear/ ways of expressing arbitrary types when C was
> devised, and which were easier to parse too.

I'm not going to defend C's choice of type syntax as being particularly
nice, or necessarily the best way. But it /is/ consistent with the
language (types are specified in the same way they are used). And most
people manage to use them fine.

On 3/25/2022 8:16 PM, Bart wrote:
> On 25/03/2022 18:17, Manfred wrote:
[...]
>>
>> More in general, it is about indirection. If a language's declaration
>> syntax allows for any combination of indirection constructs, then
>> things may get convoluted, but it's the type itself that is
>> convoluted, not necessarily the syntax's fault.
>>
>> And, obviously, typedefs make things a /lot/ easier.
>
> Typedefs should be used when they make sense for the project. If used to
> just to mitigate the awfulness of the type syntax, then something is wrong.
>

Possibly, but.

When writing a program, you are effectively modeling a problem domain.
Defining the data types of the information items that the problem
revolves around is a key step in such process.
In this perspective typedefs, together with user defined types, play a
very useful role in software design.

If you come to a point where you have to handle some complex type only
once in your program, or you end up having a plethora of unrelated
cryptic types, then that is a good hint for looking at how good your
model is.

On 3/26/2022 2:29 PM, Lew Pitcher wrote:
> On Sat, 26 Mar 2022 13:58:04 +0100, Bonita Montero wrote:
>
>>> I am in conflict with people who claim that HTML is not a
>>> programming language, so I have written a German-language
>>> text explaining why HTML is indeed a programming language.
>>> But for C, I'm at a loss, I have no such text prepared for C!
>>
>> A program has a control flow.
>> HTML is a static data-structure without a control flow.
>> So you can't program in HTML.
>
> I disagree. In general, a "program" provides instructions to
> automation (usually computer automation) and need not contain
> control flow. HTML instructs a "web browser" (automated tool) on
> how to display data. In that respect, you can write HTML, and the
> resulting text will act as a "program" for a web browser. A
> similar argument can be made for GCODE (the way 3D printers and
> automated mills are "programmed") or even the punch cards used
> to control a Jacquard loom.
>
> However, most here (of which I am one) would probably first think
> of code written in a Turing-complete language as a "program". A
> Turing-complete language /does/ have control flow. If we restrict
> "programming" to "writing in Turing-complete languages", then we
> exclude HTML, GCODE, and a large number of other human-planned
> automated process controls from "programming".
>

A note about G-Code: even the basic language is sequential, so it can be
argued to have some control flow. I don't know if branch statements are
part of the standardized language, but many implementations do have
branches, loops and logical operators, so I'm not sure it can't be
qualified as Turing complete. In the CNC world it is definitely
considered a programming language.

> Oh? And what automated activity directly follows from "a simple filename"?

I wanted to take your statement into an extreme.
According to what you said every data-structure which is
programatically interpreted is a program.

On 26/03/2022 16:11, Manfred wrote:
> On 3/25/2022 8:16 PM, Bart wrote:
>> On 25/03/2022 18:17, Manfred wrote:
> [...]
>>>
>>> More in general, it is about indirection. If a language's declaration
>>> syntax allows for any combination of indirection constructs, then
>>> things may get convoluted, but it's the type itself that is
>>> convoluted, not necessarily the syntax's fault.
>>>
>>> And, obviously, typedefs make things a /lot/ easier.
>>
>> Typedefs should be used when they make sense for the project. If used
>> to just to mitigate the awfulness of the type syntax, then something
>> is wrong.
>>
>
> Possibly, but.
>
> When writing a program, you are effectively modeling a problem domain.
> Defining the data types of the information items that the problem
> revolves around is a key step in such process.
> In this perspective typedefs, together with user defined types, play a
> very useful role in software design.
>
> If you come to a point where you have to handle some complex type only
> once in your program, or you end up having a plethora of unrelated
> cryptic types, then that is a good hint for looking at how good your
> model is.

This is the kind of thing I'm talking about:

void (*)(void)
void (**)(void)
void (***)(void)
void *(*)(void)
void **(*)(void)

I wouldn't even know where to start with using typedefs to express these
more clearly; perhaps:

typedef void F(void);
typedef void* G(void);
typedef void** H(void);

F*
F**
F***
G*
H**

You start by first removing all the "*" inside the first set of
parentheses. Then creating named types for distinct combinations of
functions that follow. Then reinstating those "*" to each instance of
that new type.

However, this is rather going around the houses. It's also necessary to
locate all instances of 'void(*)(void)' in a program, to ensure they all
use the same typedef, even though they may be used for diverse purposes.

IMV this does not improve matters, since you are now hunting global
typedefs looking for what F or G might mean. It also doesn't help when
`void(*)(void)` is used in an imported header than you aren't allowed to
modify, or which employs its own typedef.

On 2022-03-26, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> I am in conflict with people who claim that HTML is not a
>> programming language, so I have written a German-language
>> text explaining why HTML is indeed a programming language.
>> But for C, I'm at a loss, I have no such text prepared for C!
>
> A program has a control flow.
> HTML is a static data-structure without a control flow.
> So you can't program in HTML.

this above. HTML is not a programming language.

--
https://hispagatos.org
Gemini://rek2.hispagatos.org
https://hispagatos.space/@rek2
https://portal.mozz.us/gemini/rek2.hispagatos.org/

On 26/03/2022 16:56, Bart wrote:
> On 26/03/2022 16:11, Manfred wrote:

>> Possibly, but.
>>
>> When writing a program, you are effectively modeling a problem domain.
>> Defining the data types of the information items that the problem
>> revolves around is a key step in such process.
>> In this perspective typedefs, together with user defined types, play a
>> very useful role in software design.
>>
>> If you come to a point where you have to handle some complex type only
>> once in your program, or you end up having a plethora of unrelated
>> cryptic types, then that is a good hint for looking at how good your
>> model is.
>
> This is the kind of thing I'm talking about:
>
>     void (*)(void)
>     void (**)(void)
>     void (***)(void)
>     void *(*)(void)
>     void **(*)(void)
>
> I wouldn't even know where to start with using typedefs to express these
> more clearly; perhaps:
>
>     typedef void F(void);
>     typedef void* G(void);
>     typedef void** H(void);
>
>     F*
>     F**
>     F***
>     G*
>     H**

This didn't even work: The "*"s added to the instance are related to the
number of indirections to the function itself, not the return type.

That last should be just H*.

So typedef here didn't just stop me getting it wrong; it made it even
more confusing, especially trying to remember what's baked into the
typedef and what still needs to be applied, and applied to each variable
here:

H *p, *q, *r;

Bake in too much, and the number of typedefs needed escalates.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>Lew Pitcher <lew.pitcher@digitalfreehold.ca> quotes and writes:
>>>Then a simple filename is also a program.
>>Oh? And what automated activity directly follows from "a simple filename"?
>
> For example,
>
>cat filename
>
> . "cat" is an interpreter taking the program "filename".
> The automatic activity ensues according to the manpage of "cat".
>

Cat, fundamentally, is a single while loop:

while (!eof(stdin)) putc(getc());

The shell is an interpreter. cat(1) is a filter.

On Thu, 2022-03-24, Richard Harnden wrote:
> "C: Everyone's favourite programming language isn't a programming language"
>
> Erm ... <https://www.theregister.com/2022/03/23/c_not_a_language>

After clicking around a bit, that seems to have been a typo for "C is
not just a programming language anymore" -- a completely different and
more sensible statement.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .