Top 10 most common hard skills listed on resumes...

[John Forkosh]

I came across
https://www.fastcompany.com/91169318/
where I was quite surprised, and very happily so,
to see C listed as #3 on its list of
"Top 10 most common hard skills listed in 2023"
(scroll about halfway down for that list). Moreover,
C++ doesn't even make it anywhere in that top-10 list.
So is that list sensible??? I'd personally be delighted
if so, but I'm suspicious it may just be wishful thinking
on my part, and some kind of goofiness on the list's author.

[Lawrence D'Oliveiro]

Post by John Forkosh
So is that list sensible???

On the one hand, I would like to think so, since it lists Python at number
1.

On the other hand, it can’t be, because it includes Excel. What a
laugh ...

[Keith Thompson]

Post by Lawrence D'Oliveiro

Post by John Forkosh
So is that list sensible???

On the one hand, I would like to think so, since it lists Python at number
1.
On the other hand, it can’t be, because it includes Excel. What a
laugh ...

Perhaps you could explain humor to the rest of us.

[Lawrence D'Oliveiro]

Post by Keith Thompson

On the other hand, it can’t be, because it includes Excel. What a laugh
...

Perhaps you could explain humor to the rest of us.

https://arstechnica.com/tech-policy/2020/10/excel-glitch-may-have-caused-uk-to-underreport-covid-19-cases-by-15841/
https://www.theregister.com/2023/06/06/austria_election_excel_blunder/
https://www.theregister.com/2023/10/12/excel_anesthetist_recruitment_blunder/
https://arstechnica.com/cars/2024/03/formula-1-chief-appalled-to-find-team-using-excel-to-manage-20000-car-parts/

What lessons have been learned since the Great Renaming of genes to
avoid Excel misinterpreting them as dates? Seemingly, none:
https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1008984

[David Brown]

Post by John Forkosh
I came across
https://www.fastcompany.com/91169318/
where I was quite surprised, and very happily so,
to see C listed as #3 on its list of
"Top 10 most common hard skills listed in 2023"
(scroll about halfway down for that list). Moreover,
C++ doesn't even make it anywhere in that top-10 list.
So is that list sensible??? I'd personally be delighted
if so, but I'm suspicious it may just be wishful thinking
on my part, and some kind of goofiness on the list's author.

As far as I see, the article is about what people put on their CV's -
not what they /should/ put, or what potential employers want.
Basically, it is pretty useless - you could use it to argue that people
think (rightly or wrongly) that C skills are useful for getting a job,
or that people with C skills are regularly out of a job and needing to
apply for a new one.

And you can also expect that the people behind the article don't know
the difference between C, C++ and C#.

[John Forkosh]

Post by David Brown

Post by John Forkosh
I came across
https://www.fastcompany.com/91169318/
where I was quite surprised, and very happily so,
to see C listed as #3 on its list of
"Top 10 most common hard skills listed in 2023"
(scroll about halfway down for that list). Moreover,
C++ doesn't even make it anywhere in that top-10 list.
So is that list sensible??? I'd personally be delighted
if so, but I'm suspicious it may just be wishful thinking
on my part, and some kind of goofiness on the list's author.

As far as I see, the article is about what people put on their CV's -
not what they /should/ put, or what potential employers want.
Basically, it is pretty useless - you could use it to argue that people
think (rightly or wrongly) that C skills are useful for getting a job,
or that people with C skills are regularly out of a job and needing to
apply for a new one.
And you can also expect that the people behind the article don't know
the difference between C, C++ and C#.

Yeah, I guess "C is #3" was just unlikely wishful thinking
on my part (I'm now hoping my lottery ticket is a winner).
So, is there any reasonably reliable such "Top 10" list?
If so, where? If not, where would C fall on it if it did
exist? (I'd probably guess C>10, so make that a "Top 100"
list, as needed.)

[Michael S]

On Sun, 25 Aug 2024 12:09:40 -0000 (UTC)

Post by John Forkosh

Post by David Brown

Post by John Forkosh
I came across
https://www.fastcompany.com/91169318/
where I was quite surprised, and very happily so,
to see C listed as #3 on its list of
"Top 10 most common hard skills listed in 2023"
(scroll about halfway down for that list). Moreover,
C++ doesn't even make it anywhere in that top-10 list.
So is that list sensible??? I'd personally be delighted
if so, but I'm suspicious it may just be wishful thinking
on my part, and some kind of goofiness on the list's author.

As far as I see, the article is about what people put on their CV's
- not what they /should/ put, or what potential employers want.
Basically, it is pretty useless - you could use it to argue that
people think (rightly or wrongly) that C skills are useful for
getting a job, or that people with C skills are regularly out of a
job and needing to apply for a new one.
And you can also expect that the people behind the article don't
know the difference between C, C++ and C#.

Yeah, I guess "C is #3" was just unlikely wishful thinking
on my part (I'm now hoping my lottery ticket is a winner).
So, is there any reasonably reliable such "Top 10" list?

By which criterion exactly?

Post by John Forkosh
If so, where? If not, where would C fall on it if it did
exist? (I'd probably guess C>10, so make that a "Top 100"
list, as needed.)

[James Kuyper]

On 8/25/24 08:09, John Forkosh wrote:
...

Post by John Forkosh
Yeah, I guess "C is #3" was just unlikely wishful thinking
on my part (I'm now hoping my lottery ticket is a winner).
So, is there any reasonably reliable such "Top 10" list?
If so, where? If not, where would C fall on it if it did
exist? (I'd probably guess C>10, so make that a "Top 100"
list, as needed.)

If you're just looking for a Top 10 list, and don't care "Top 10 what?",
then the Tiobe index <https://www.tiobe.com/tiobe-index/> might satisfy.
There's lots of controversy about their methodology, despite which I
think it is the least controversial attempt to rank all computer languages.

[Michael S]

On Sun, 25 Aug 2024 10:54:22 -0400

Post by James Kuyper
...

Post by John Forkosh
Yeah, I guess "C is #3" was just unlikely wishful thinking
on my part (I'm now hoping my lottery ticket is a winner).
So, is there any reasonably reliable such "Top 10" list?
If so, where? If not, where would C fall on it if it did
exist? (I'd probably guess C>10, so make that a "Top 100"
list, as needed.)

If you're just looking for a Top 10 list, and don't care "Top 10
what?", then the Tiobe index <https://www.tiobe.com/tiobe-index/>
might satisfy. There's lots of controversy about their methodology,
despite which I think it is the least controversial attempt to rank
all computer languages.

Methodology published is a plus, methodology is bad is a minus.
Come on, Javascript never higher than #6 ?!

[Vir Campestris]

Post by James Kuyper
If you're just looking for a Top 10 list, and don't care "Top 10 what?",
then the Tiobe index<https://www.tiobe.com/tiobe-index/> might satisfy.
There's lots of controversy about their methodology, despite which I
think it is the least controversial attempt to rank all computer languages.

Thank you, very interesting.

I'm glad to see it doesn't have APL. I had to use it on a project once,
and I still bear the scars. 40 years later...

BTW this debate about high level/low level languages? It doesn't really
matter, and doesn't really have a clear unambiguous answer - any more
than the line between a hot day and a cold one.

And

[David Brown]

Post by John Forkosh

Post by David Brown

Post by John Forkosh
I came across
https://www.fastcompany.com/91169318/
where I was quite surprised, and very happily so,
to see C listed as #3 on its list of
"Top 10 most common hard skills listed in 2023"
(scroll about halfway down for that list). Moreover,
C++ doesn't even make it anywhere in that top-10 list.
So is that list sensible??? I'd personally be delighted
if so, but I'm suspicious it may just be wishful thinking
on my part, and some kind of goofiness on the list's author.

As far as I see, the article is about what people put on their CV's -
not what they /should/ put, or what potential employers want.
Basically, it is pretty useless - you could use it to argue that people
think (rightly or wrongly) that C skills are useful for getting a job,
or that people with C skills are regularly out of a job and needing to
apply for a new one.
And you can also expect that the people behind the article don't know
the difference between C, C++ and C#.

Yeah, I guess "C is #3" was just unlikely wishful thinking
on my part (I'm now hoping my lottery ticket is a winner).

You wished to fine C rated at number three on a list, without much
concern about the relevance of the list to anything? That's an odd
wish, but I'm happy it was fulfilled for you!

Post by John Forkosh
So, is there any reasonably reliable such "Top 10" list?

Reliable for what?

Post by John Forkosh
If so, where? If not, where would C fall on it if it did
exist? (I'd probably guess C>10, so make that a "Top 100"
list, as needed.)

If you are talking about a list of programming languages people probably
should have on their CV's, it depends totally on the job. When people
are applying to work as software developers at my company, if they don't
have C on their list, it's unlikely we will bother with an interview.
C++ would be good, assembly would be good. Listing "Excel" in
programming languages would count negatively.

[Chris M. Thomasson]

Post by David Brown

Post by John Forkosh

Post by David Brown

Post by John Forkosh
I came across
       https://www.fastcompany.com/91169318/
where I was quite surprised, and very happily so,
to see C listed as #3 on its list of
       "Top 10 most common hard skills listed in 2023"
(scroll about halfway down for that list). Moreover,
C++ doesn't even make it anywhere in that top-10 list.
So is that list sensible??? I'd personally be delighted
if so, but I'm suspicious it may just be wishful thinking
on my part, and some kind of goofiness on the list's author.

As far as I see, the article is about what people put on their CV's -
not what they /should/ put, or what potential employers want.
Basically, it is pretty useless - you could use it to argue that people
think (rightly or wrongly) that C skills are useful for getting a job,
or that people with C skills are regularly out of a job and needing to
apply for a new one.
And you can also expect that the people behind the article don't know
the difference between C, C++ and C#.

Yeah, I guess "C is #3" was just unlikely wishful thinking
on my part (I'm now hoping my lottery ticket is a winner).

You wished to fine C rated at number three on a list, without much
concern about the relevance of the list to anything?  That's an odd
wish, but I'm happy it was fulfilled for you!

[...]

No shit. Job Description:

Wanted: A talented and creative C / C++ programmer

;^)

[Bonita Montero]

Post by John Forkosh
I came across
https://www.fastcompany.com/91169318/
where I was quite surprised, and very happily so,
to see C listed as #3 on its list of
"Top 10 most common hard skills listed in 2023"
(scroll about halfway down for that list). Moreover,
C++ doesn't even make it anywhere in that top-10 list.
So is that list sensible??? I'd personally be delighted
if so, but I'm suspicious it may just be wishful thinking
on my part, and some kind of goofiness on the list's author.

I guess C++ is used much more often because you're multiple times
more produdtive than with C. And programming in C++ is a magnitude
less error-prone.

[Bart]

Post by Bonita Montero

Post by John Forkosh
I came across
      https://www.fastcompany.com/91169318/
where I was quite surprised, and very happily so,
to see C listed as #3 on its list of
      "Top 10 most common hard skills listed in 2023"
(scroll about halfway down for that list). Moreover,
C++ doesn't even make it anywhere in that top-10 list.
So is that list sensible??? I'd personally be delighted
if so, but I'm suspicious it may just be wishful thinking
on my part, and some kind of goofiness on the list's author.

I guess C++ is used much more often because you're multiple times
more produdtive than with C. And programming in C++ is a magnitude
less error-prone.

C++ incorporates most of C. So someone can write 'C++' code but can
still have most of the same problems as C.

Meanwhile real C++ code has several times more boilerplate than C. HTF
you can even discern your actual program amidst all that crap is beyond me.

There /are/ proper higher level languages than both C and C++. You can
use one to help develop a working application, then porting that part to
C is a quicker, simpler and safer process.

[Vir Campestris]

Post by Bart
C++ incorporates most of C. So someone can write 'C++' code but can
still have most of the same problems as C.
Meanwhile real C++ code has several times more boilerplate than C. HTF
you can even discern your actual program amidst all that crap is beyond me.
There /are/ proper higher level languages than both C and C++. You can
use one to help develop a working application, then porting that part to
C is a quicker, simpler and safer process.

Up there someone is asking about a valgrind leak they can't find.

Over in comp.lang.c++ we write wrappers around the memory management if
we can't find a system class that will do it for us, and that's no
longer an issue.

(There are still all sorts of memory problems, but if you are leaking
you are doing Something Wrong.)

Andy

[Thiago Adams]

Post by Vir Campestris

Post by Bart
C++ incorporates most of C. So someone can write 'C++' code but can
still have most of the same problems as C.
Meanwhile real C++ code has several times more boilerplate than C. HTF
you can even discern your actual program amidst all that crap is beyond me.
There /are/ proper higher level languages than both C and C++. You can
use one to help develop a working application, then porting that part
to C is a quicker, simpler and safer process.

Up there someone is asking about a valgrind leak they can't find.

I developed a static analyzer that can detect such types of leaks and
make C code safer than C++ (better than RAII). The author did not
provide the complete source; otherwise, I could have demonstrated the
static analysis working on the code.

[John Forkosh]

Post by Bart

Post by Bonita Montero

Post by John Forkosh
I came across
https://www.fastcompany.com/91169318/
where I was quite surprised, and very happily so,
to see C listed as #3 on its list of
"Top 10 most common hard skills listed in 2023"
(scroll about halfway down for that list). Moreover,
C++ doesn't even make it anywhere in that top-10 list.
So is that list sensible??? I'd personally be delighted
if so, but I'm suspicious it may just be wishful thinking
on my part, and some kind of goofiness on the list's author.

I guess C++ is used much more often because you're multiple times
more produdtive than with C. And programming in C++ is a magnitude
less error-prone.

C++ incorporates most of C. So someone can write 'C++' code but can
still have most of the same problems as C.
Meanwhile real C++ code has several times more boilerplate than C. HTF
you can even discern your actual program amidst all that crap is beyond me.
There /are/ proper higher level languages than both C and C++. You can
use one to help develop a working application, then porting that part to
C is a quicker, simpler and safer process.

I recall C as originally characterized as a "portable assembly language",
as opposed to a "higher level language". And I'd agree with that
assessment, whereby I think you're barking up the wrong tree by trying
to evaluate its merits/demerits vis-a-vis higher-level languages.
Consider it with respect to its own objectives, instead.

[James Kuyper]

...

Post by John Forkosh
I recall C as originally characterized as a "portable assembly language",
as opposed to a "higher level language". And I'd agree with that
assessment, whereby I think you're barking up the wrong tree by trying
to evaluate its merits/demerits vis-a-vis higher-level languages.
Consider it with respect to its own objectives, instead.

C has been mischaracterized as a "portable assembly language", but that
has never been an accurate characterization. It has, from the very
beginning, been defined by the behavior that is supposed to result from
translating and executing the C code, not the assembly language that's
supposed to be produced by the translation process.
C is a high level language. It is a very low-level high-level language,
but it's not in any sense an assembler.

There's a famous bug that involved unconditionally derefencing a pointer
returned by malloc() before checking whether or not that pointer was
null. The people who wrote that bug knew that the assembly code which
they naively expected to be generated by translating their program would
be perfectly safe on the platform they were working on: a null pointer
pointed at a specific location in memory, and it was safe to access that
location.

But C is not defined as producing the assembly language they naively
expected it to produce. It's defined by the behavior of the resulting
code when executed. Dereferencing a null pointer has undefined behavior,
so the compiler just assumed that the fact that they were dereferencing
the pointer meant that they knew, for a fact, for reasons unknown to the
compiler itself, that the pointer would never be null. Therefore, the
compiler optimized away the code that was supposed to be executed if the
pointer was null.
This is a perfectly legal optimization - since the standard imposes no
requirements on the behavior of a program when the behavior is
undefined, nothing the program could do when the pointer was null could
be incorrect behavior. Furthermore, this optimization was not on by
default, it applied only if you turned it on explicitly, which the
developers had done. It's OK to write code with behavior that is not
defined by the standard, so long as some other document does define the
behavior. But you need to be very sure you know what behavior that other
document defined - this compiler defined the behavior as causing
optimizations based upon the assumption that the pointer was not null.

[fir]

Post by James Kuyper
...

Post by John Forkosh
I recall C as originally characterized as a "portable assembly language",
as opposed to a "higher level language". And I'd agree with that
assessment, whereby I think you're barking up the wrong tree by trying
to evaluate its merits/demerits vis-a-vis higher-level languages.
Consider it with respect to its own objectives, instead.

C has been mischaracterized as a "portable assembly language", but that
has never been an accurate characterization. It has, from the very
beginning, been defined by the behavior that is supposed to result from
translating and executing the C code, not the assembly language that's
supposed to be produced by the translation process.
C is a high level language. It is a very low-level high-level language,
but it's not in any sense an assembler.

c is mid level language - i mean it has more sense to call c that way
than call it low level or high level

[Bart]

Post by fir

Post by James Kuyper
...

Post by John Forkosh
I recall C as originally characterized as a "portable assembly language",
as opposed to a "higher level language". And I'd agree with that
assessment, whereby I think you're barking up the wrong tree by trying
to evaluate its merits/demerits vis-a-vis higher-level languages.
Consider it with respect to its own objectives, instead.

C has been mischaracterized as a "portable assembly language", but that
has never been an accurate characterization. It has, from the very
beginning, been defined by the behavior that is supposed to result from
translating and executing the C code, not the assembly language that's
supposed to be produced by the translation process.
C is a high level language. It is a very low-level high-level language,
but it's not in any sense an assembler.

c is mid level language - i mean it has more sense to call c that way
than call it low level or high level

So what language goes between Assembly and C?

There aren't many! So it's reasonable to consider C as being at the
lowest level of HLLs.

Putting C at mid-level would make for a very cramped space above it as
99% of languages would have to fit in there.

[Michael S]

On Sun, 25 Aug 2024 16:30:17 +0100

Post by Bart

Post by fir

Post by James Kuyper
...

Post by John Forkosh
I recall C as originally characterized as a "portable assembly language",
as opposed to a "higher level language". And I'd agree with that
assessment, whereby I think you're barking up the wrong tree by
trying to evaluate its merits/demerits vis-a-vis higher-level
languages. Consider it with respect to its own objectives,
instead.

C has been mischaracterized as a "portable assembly language", but
that has never been an accurate characterization. It has, from the
very beginning, been defined by the behavior that is supposed to
result from translating and executing the C code, not the assembly
language that's supposed to be produced by the translation process.
C is a high level language. It is a very low-level high-level
language, but it's not in any sense an assembler.

c is mid level language - i mean it has more sense to call c that
way than call it low level or high level

So what language goes between Assembly and C?

Popular today? Not many. In the past? PL/M, BLISS. Although the former
is at almost the same level as C.

Post by Bart
There aren't many!

Because C is seen as good enough.

Post by Bart
So it's reasonable to consider C as being at the
lowest level of HLLs.
Putting C at mid-level would make for a very cramped space above it
as 99% of languages would have to fit in there.

Why is it a problem?

[Bart]

Post by Michael S
On Sun, 25 Aug 2024 16:30:17 +0100

Post by Bart

Post by fir

Post by James Kuyper
...

Post by John Forkosh
I recall C as originally characterized as a "portable assembly language",
as opposed to a "higher level language". And I'd agree with that
assessment, whereby I think you're barking up the wrong tree by
trying to evaluate its merits/demerits vis-a-vis higher-level
languages. Consider it with respect to its own objectives,
instead.

C has been mischaracterized as a "portable assembly language", but
that has never been an accurate characterization. It has, from the
very beginning, been defined by the behavior that is supposed to
result from translating and executing the C code, not the assembly
language that's supposed to be produced by the translation process.
C is a high level language. It is a very low-level high-level
language, but it's not in any sense an assembler.

c is mid level language - i mean it has more sense to call c that
way than call it low level or high level

So what language goes between Assembly and C?

Popular today? Not many. In the past? PL/M, BLISS. Although the former
is at almost the same level as C.

Post by Bart
There aren't many!

Because C is seen as good enough.

Because it's seen off most of the competition, partly thanks to the
dominance of Unix.

Lots of younger people now think that C is what a lower level, systems
language is supposed to look like.

Post by Michael S

Post by Bart
So it's reasonable to consider C as being at the
lowest level of HLLs.
Putting C at mid-level would make for a very cramped space above it
as 99% of languages would have to fit in there.

Why is it a problem?

It's only a problem if the aim is to classify languages according to
perceived level say from 1 to 100. Then you don't start by classifying
one of the lowest level ones as 50.

If plotting such a chart (say level vs. year of introduction), half of
it would be empty.

[tTh]

Post by Bart
So what language goes between Assembly and C?

Forth ?

[Bart]

Post by Bart
So what language goes between Assembly and C?

   Forth ?

I had in mind languages classed as 'HLLs'. I'm not sure if Forth counts.

Otherwise there was a HLA I once worked with (that looks a lot more like
a HLL than Forth ever will).

Plus various Intermediate Languages that I've devised. These are higher
level than assembly, but are clearly not HLLs either. Especially
stack-based ones like this actual example for a Hello program:

proc main*
loadimm u64 "Hello, World"
callp puts 1 0
stop 0
end

extproc void puts
extparam u64
extend

These are designed to be machine generated, but this one you could write
manually if you had to. It's easier than ASM and it's portable.

[Lawrence D'Oliveiro]

Post by Bart
So what language goes between Assembly and C?
There aren't many!

Quite a few, actually. Elsewhere I mentioned B (the precursor of C), BCPL
and BLISS.

[Bart]

Post by Lawrence D'Oliveiro

Post by Bart
So what language goes between Assembly and C?
There aren't many!

Quite a few, actually. Elsewhere I mentioned B (the precursor of C), BCPL
and BLISS.

BLISS is a rather strange language. For something supposedly low level
than C, it doesn't have 'goto'.

It is also typeless.

There is also a key feature that sets it apart from most HLLs: usually
if you declare a variable A, then you can access A's value just by
writing A; its address is automatically dereferenced.

That doesn't happen in BLISS. If you took this program in normal C:

int a, b, c;
b = 10;
c = 20;
a = b + c;

int* p;
p = &a;

then without that auto-deref feature, you'd have to write it like this:

int a, b, c;
*b = 10;
*c = 20;
*a = *b + *c;

int* p;
*p = a;

(The last two lines are interesting; both would be valid in standard C;
but the first set initialises p; the second set, compiled as normal C,
stores a's value into the uninitialised p's target.)

[Ben Bacarisse]

BLISS is a rather strange language. For something supposedly low level than
C, it doesn't have 'goto'.
It is also typeless.
There is also a key feature that sets it apart from most HLLs: usually if
you declare a variable A, then you can access A's value just by writing A;
its address is automatically dereferenced.

Not always. This is where left- and right-evaluation came in. On the
left of an assignment A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place. CPL used the terms and
C got them via BCPL's documentation. Viewed like this, BLISS just makes
"evaluation" a universal concept.

[Bart]

Post by Ben Bacarisse

BLISS is a rather strange language. For something supposedly low level than
C, it doesn't have 'goto'.
It is also typeless.
There is also a key feature that sets it apart from most HLLs: usually if
you declare a variable A, then you can access A's value just by writing A;
its address is automatically dereferenced.

Not always. This is where left- and right-evaluation came in. On the
left of an assignment A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place. CPL used the terms and
C got them via BCPL's documentation. Viewed like this, BLISS just makes
"evaluation" a universal concept.

That doesn't explain why one language requires an explcition dereference
in the source code, and the other doesn't.

By "access A's value" I mean either read or write access.

Post by Ben Bacarisse
A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place.

This /is/ confusing as it suggests a different rank for A depending on
whether it is an lvalue or rvalue, eg. some difference in level of
indirection. In fact that is the same on both sides.

My point was that HLLs typically read or write values of variables
without extra syntax. Given a declaration like 'int A' then:

BLISS C

Read or write A's value .A A
Get A's address A &A

[Keith Thompson]

Bart <***@freeuk.com> writes:
[...]

Post by Bart
By "access A's value" I mean either read or write access.

Write access does not access the value of an object. Whatever value is
stored in the object is ignored. The value can even be indeterminate or
a trap representation.

[Tim Rentsch]

[...]

Post by Bart
By "access A's value" I mean either read or write access.

Write access does not access the value of an object. [...]

Bart is explaining what he means by the phrase. There is nothing
wrong with pointing out that the C standard doesn't use that
phrase with the same meaning, but that doesn't make what Bart
said wrong, especially since he is comparing semantics in two
different languages.

[Ben Bacarisse]

Post by Ben Bacarisse

BLISS is a rather strange language. For something supposedly low level than
C, it doesn't have 'goto'.
It is also typeless.
There is also a key feature that sets it apart from most HLLs: usually if
you declare a variable A, then you can access A's value just by writing A;
its address is automatically dereferenced.

Not always. This is where left- and right-evaluation came in. On the
left of an assignment A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place. CPL used the terms and
C got them via BCPL's documentation. Viewed like this, BLISS just makes
"evaluation" a universal concept.

That doesn't explain why one language requires an explcition dereference in
the source code, and the other doesn't.

It does for me. If you think I can help, maybe you could ask some more
questions as I don't know what else to say. BLISS uses addresses
explicitly, so the rvalue/lvalue distincion is not a perfect match for
what's going on, but it's close enough that I find it helpful.

By "access A's value" I mean either read or write access.

Post by Ben Bacarisse
A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place.

This /is/ confusing as it suggests a different rank for A depending on
whether it is an lvalue or rvalue, eg. some difference in level of
indirection. In fact that is the same on both sides.

I don't know what you mean by rank here. The whole point of two
different evaluations -- as an rvalue or an lvalue -- can be seen
(rather too crudely I fear) as adding one more level of indirection so
that what we expect to happen (when we've got used to modern programming
languages), happens.

My point was that HLLs typically read or write values of variables without
extra syntax.

Indeed, and BLISS is not like that. I had hoped to shed some light on
why there is some logic to BLISS's rather idiosyncratic design.

BLISS C
Read or write A's value .A A

I don't think that's right. To change the value at address A (what I
think you mean by "write A's value") you write

A = 42;

in BLISS. And to add one to the value at address A you write

A = .A + 1;

Get A's address A &A

[Bart]

Post by Ben Bacarisse

Post by Ben Bacarisse

BLISS is a rather strange language. For something supposedly low level than
C, it doesn't have 'goto'.
It is also typeless.
There is also a key feature that sets it apart from most HLLs: usually if
you declare a variable A, then you can access A's value just by writing A;
its address is automatically dereferenced.

Not always. This is where left- and right-evaluation came in. On the
left of an assignment A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place. CPL used the terms and
C got them via BCPL's documentation. Viewed like this, BLISS just makes
"evaluation" a universal concept.

That doesn't explain why one language requires an explcition dereference in
the source code, and the other doesn't.

It does for me. If you think I can help, maybe you could ask some more
questions as I don't know what else to say. BLISS uses addresses
explicitly, so the rvalue/lvalue distincion is not a perfect match for
what's going on, but it's close enough that I find it helpful.

By "access A's value" I mean either read or write access.

Post by Ben Bacarisse
A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place.

This /is/ confusing as it suggests a different rank for A depending on
whether it is an lvalue or rvalue, eg. some difference in level of
indirection. In fact that is the same on both sides.

I don't know what you mean by rank here. The whole point of two
different evaluations -- as an rvalue or an lvalue -- can be seen
(rather too crudely I fear) as adding one more level of indirection so
that what we expect to happen (when we've got used to modern programming
languages), happens.

My point was that HLLs typically read or write values of variables without
extra syntax.

Indeed, and BLISS is not like that. I had hoped to shed some light on
why there is some logic to BLISS's rather idiosyncratic design.

BLISS C
Read or write A's value .A A

I don't think that's right. To change the value at address A (what I
think you mean by "write A's value") you write
A = 42;
in BLISS. And to add one to the value at address A you write
A = .A + 1;

OK. That's just makes it more bizarre than I'd thought. The example I
saw included these lines:

GETNUM(X); ! returns a value via X
Y = STEP(.X);
PUTNUM(.Y)

So in an rvalue context: X reads its address; while .X reads its value.

But in an lvalue one: Y writes its value; .Y may not be defined

It looks asymmetric. C like most languages is symmetric, you write 'A =
A' with the same syntax on both sides.

I assume that in BLISS, A = A is legal, but does something odd like copy
A's address into itself.

[Keith Thompson]

Post by Ben Bacarisse

BLISS is a rather strange language. For something supposedly low level than
C, it doesn't have 'goto'.
It is also typeless.
There is also a key feature that sets it apart from most HLLs: usually if
you declare a variable A, then you can access A's value just by writing A;
its address is automatically dereferenced.

Not always. This is where left- and right-evaluation came in. On the
left of an assignment A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place. CPL used the terms and
C got them via BCPL's documentation. Viewed like this, BLISS just makes
"evaluation" a universal concept.

As I recall, the terms "lvalue" and "rvalue" originated with CPL. The
'l' and 'r' suggest the left and right sides of an assignment.

Disclaimer: I have a couple of CPL documents, and I don't see the terms
"lvalue" and "rvalue" in a quick look. The PDFs are not searchable. If
someone has better information, please post it. Wikipedia does say that
the notion of "l-values" and "r-values" was introduced by CPL.

An expression could be "evaluated for its lvalue", which means
determining what object it designates, or "evaluted for its rvalue",
which C just calls evaluating the expression. An expression like 2+2
that does not designate an object does not have an lvalue.

So given `int foo = 42;`, in CPL terms evaluating `foo` for its lvalue
yields the identity of that object, and evaluating `foo` for its rvalue
yields the value 42.

C changed the meanings, so that a C lvalue is a kind of expression, not
the result of evaluating an expression. C doesn't use the term "rvalue"
except in one footnote: "What is sometimes called "rvalue" is in this
document described as the "value of an expression"."

C has implicit *lvalue conversion* which converts an lvalue (expression)
to the value stored in the designated object. Apparently BLISS requires
this conversion to be done explicitly. (I don't hate the idea.)

[Lawrence D'Oliveiro]

Post by Keith Thompson
As I recall, the terms "lvalue" and "rvalue" originated with CPL.

And very useful they have proven, too.

CPL was kind of a rival to PL/I. But as I recall from the design papers
and stuff, they spent most of their effort on coming up with alternative
syntaxes for features, rather than on the features themselves.

[Ben Bacarisse]

Post by Keith Thompson

Post by Ben Bacarisse

BLISS is a rather strange language. For something supposedly low level than
C, it doesn't have 'goto'.
It is also typeless.
There is also a key feature that sets it apart from most HLLs: usually if
you declare a variable A, then you can access A's value just by writing A;
its address is automatically dereferenced.

Not always. This is where left- and right-evaluation came in. On the
left of an assignment A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place. CPL used the terms and
C got them via BCPL's documentation. Viewed like this, BLISS just makes
"evaluation" a universal concept.

As I recall, the terms "lvalue" and "rvalue" originated with CPL. The
'l' and 'r' suggest the left and right sides of an assignment.
Disclaimer: I have a couple of CPL documents, and I don't see the terms
"lvalue" and "rvalue" in a quick look. The PDFs are not searchable. If
someone has better information, please post it. Wikipedia does say that
the notion of "l-values" and "r-values" was introduced by CPL.

I presume, since I mentioned the concepts coming from CPL, you are
referring to specifically the short-form terms l- and r-values?

I can't help with those specific terms as the document I have uses a
mixture of terms like "the LH value of...", "left-hand expressions" and
"evaluated in LH mode".

[Keith Thompson]

Post by Ben Bacarisse

Post by Keith Thompson

Post by Ben Bacarisse

BLISS is a rather strange language. For something supposedly low level than
C, it doesn't have 'goto'.
It is also typeless.
There is also a key feature that sets it apart from most HLLs: usually if
you declare a variable A, then you can access A's value just by writing A;
its address is automatically dereferenced.

Not always. This is where left- and right-evaluation came in. On the
left of an assignment A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place. CPL used the terms and
C got them via BCPL's documentation. Viewed like this, BLISS just makes
"evaluation" a universal concept.

As I recall, the terms "lvalue" and "rvalue" originated with CPL. The
'l' and 'r' suggest the left and right sides of an assignment.
Disclaimer: I have a couple of CPL documents, and I don't see the terms
"lvalue" and "rvalue" in a quick look. The PDFs are not searchable. If
someone has better information, please post it. Wikipedia does say that
the notion of "l-values" and "r-values" was introduced by CPL.

I presume, since I mentioned the concepts coming from CPL, you are
referring to specifically the short-form terms l- and r-values?
I can't help with those specific terms as the document I have uses a
mixture of terms like "the LH value of...", "left-hand expressions" and
"evaluated in LH mode".

The documents I have are unsearchable PDFs; they appear to be scans of
paper documents.

https://comjnl.oxfordjournals.org/content/6/2/134.full.pdf
https://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf

Do you have friendlier documents?

[Chris M. Thomasson]

Post by Keith Thompson

Post by Ben Bacarisse

Post by Keith Thompson

Post by Ben Bacarisse

BLISS is a rather strange language. For something supposedly low level than
C, it doesn't have 'goto'.
It is also typeless.
There is also a key feature that sets it apart from most HLLs: usually if
you declare a variable A, then you can access A's value just by writing A;
its address is automatically dereferenced.

Not always. This is where left- and right-evaluation came in. On the
left of an assignment A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place. CPL used the terms and
C got them via BCPL's documentation. Viewed like this, BLISS just makes
"evaluation" a universal concept.

As I recall, the terms "lvalue" and "rvalue" originated with CPL. The
'l' and 'r' suggest the left and right sides of an assignment.
Disclaimer: I have a couple of CPL documents, and I don't see the terms
"lvalue" and "rvalue" in a quick look. The PDFs are not searchable. If
someone has better information, please post it. Wikipedia does say that
the notion of "l-values" and "r-values" was introduced by CPL.

I presume, since I mentioned the concepts coming from CPL, you are
referring to specifically the short-form terms l- and r-values?
I can't help with those specific terms as the document I have uses a
mixture of terms like "the LH value of...", "left-hand expressions" and
"evaluated in LH mode".

The documents I have are unsearchable PDFs; they appear to be scans of
paper documents.
https://comjnl.oxfordjournals.org/content/6/2/134.full.pdf

I can search this for sure.

Post by Keith Thompson
https://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf
Do you have friendlier documents?

[Ben Bacarisse]

Post by Keith Thompson

Post by Ben Bacarisse

Post by Keith Thompson

Post by Ben Bacarisse

BLISS is a rather strange language. For something supposedly low level than
C, it doesn't have 'goto'.
It is also typeless.
There is also a key feature that sets it apart from most HLLs: usually if
you declare a variable A, then you can access A's value just by writing A;
its address is automatically dereferenced.

Not always. This is where left- and right-evaluation came in. On the
left of an assignment A denotes a "place" to receive a value. On the
right, it denotes a value obtained from a place. CPL used the terms and
C got them via BCPL's documentation. Viewed like this, BLISS just makes
"evaluation" a universal concept.

As I recall, the terms "lvalue" and "rvalue" originated with CPL. The
'l' and 'r' suggest the left and right sides of an assignment.
Disclaimer: I have a couple of CPL documents, and I don't see the terms
"lvalue" and "rvalue" in a quick look. The PDFs are not searchable. If
someone has better information, please post it. Wikipedia does say that
the notion of "l-values" and "r-values" was introduced by CPL.

I presume, since I mentioned the concepts coming from CPL, you are
referring to specifically the short-form terms l- and r-values?
I can't help with those specific terms as the document I have uses a
mixture of terms like "the LH value of...", "left-hand expressions" and
"evaluated in LH mode".

The documents I have are unsearchable PDFs; they appear to be scans of
paper documents.
https://comjnl.oxfordjournals.org/content/6/2/134.full.pdf
https://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf
Do you have friendlier documents?

The earliest that is searchable has this title page:

UNIVERSITY OF LONDON INSTITUTE OF COMPUTER SCIENCE
*************************************************
THE UNIVERSITY MATHEMATICAL LABORATORY, CAMBRIDGE
*************************************************
CPL ELEMENTARY PROGRAMMING MANUAL
Edition I (London)

This document, written by the late John Buxton, was preserved by Bill
Williams, formerly of London University’s Atlas support team. Bill has
generously made it available to Dik Leatherdale who has OCRed and
otherwise transcribed it for the Web. All errors should be reported to
***@leatherdale.net. The original appearance is respected as far as
possible, but program text and narrative are distinguished by the use of
different fonts. Transcriber’s additions and “corrections” are in red,
hyperlinks in underlined purple. A contents list and a selection of
references have been added inside the back cover.

March 1965

I don't know where I got it from. The other searchable one is just a
PDF is the oft-cited paper "The main features of CPL" by Barron et. al.

[Keith Thompson]

[...]

Post by Ben Bacarisse

Post by Keith Thompson
The documents I have are unsearchable PDFs; they appear to be scans of
paper documents.
https://comjnl.oxfordjournals.org/content/6/2/134.full.pdf
https://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf
Do you have friendlier documents?

UNIVERSITY OF LONDON INSTITUTE OF COMPUTER SCIENCE
*************************************************
THE UNIVERSITY MATHEMATICAL LABORATORY, CAMBRIDGE
*************************************************
CPL ELEMENTARY PROGRAMMING MANUAL
Edition I (London)

[...]

Post by Ben Bacarisse
I don't know where I got it from. The other searchable one is just a
PDF is the oft-cited paper "The main features of CPL" by Barron et. al.

It's likely you have the same documents I have. And the first one is
searchable (my mistake), while the second is not.

https://comjnl.oxfordjournals.org/content/6/2/134.full.pdf
"The main features of CPL"
985322 bytes, sha1sum b21f12f964aa4145f984c667862548943fdbf864

https://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf
3626287, sha1sum b007dd5e284cd8cf101a475cae2374eb121892c6

Quoting the former:

"""
6. Expressions

There are two possible modes of evaluation of an expression in CPL,
known as the left-hand (LH) and right-hand (RH) modes. All expressions
can be evaluated in RH mode, but only certain kinds of expression are
meaningful in LH mode. When evaluated in RH mode an expression is
regarded as being a rule for the computation of a value (the RH
value). When evaluated in LH mode an expression effectively gives an
address (the LH value): the significance of this is discussed further in
Section 8.
"""

I speculate that the terms "LH value" and "RH value" evolved to
"l-value" and "r-value", and later to "lvalue" and "rvalue".

And quoting <https://www.cl.cam.ac.uk/~mr10/cpl2bcpl.pdf> :

"""
3.1.
Left and Right hand values

In Fortran, function arguments are passed by reference, that is they are
a collection of pointers to the memory locations where the values can be
found. In Algol, the programmer can specify that some arguments are to
be passed by value, the remaining ones being passed by name, a somewhat
subtle mechanism specified in terms of run time copying of the actual
parameters of a call modifying the function body. Strachey coined the
terms Lvalue and Rvalue to describe the kind of value passed by
reference and value parameters, respectively. These terms were derived
from the kind of values needed when evaluating expressions on the left
and right hand sides of assignment commands. Lmode evaluation could be
performed on simple variables, subscripted expressions and, perhaps more
surprisingly, on functions calls.
"""

Christopher Strachey was the primary designer of CPL.

[Tim Rentsch]

Post by Ben Bacarisse

Post by Ben Bacarisse

Post by Keith Thompson

Post by Ben Bacarisse

BLISS is a rather strange language. For something supposedly
low level than C, it doesn't have 'goto'.
It is also typeless.
usually if you declare a variable A, then you can access A's
value just by writing A; its address is automatically
dereferenced.

Not always. This is where left- and right-evaluation came in.
On the left of an assignment A denotes a "place" to receive a
value. On the right, it denotes a value obtained from a place.
CPL used the terms and C got them via BCPL's documentation.
Viewed like this, BLISS just makes "evaluation" a universal
concept.

As I recall, the terms "lvalue" and "rvalue" originated with CPL.
The 'l' and 'r' suggest the left and right sides of an
assignment.
Disclaimer: I have a couple of CPL documents, and I don't see
the terms "lvalue" and "rvalue" in a quick look. The PDFs are
not searchable. If someone has better information, please post
it. Wikipedia does say that the notion of "l-values" and
"r-values" was introduced by CPL.

I presume, since I mentioned the concepts coming from CPL, you are
referring to specifically the short-form terms l- and r-values?
I can't help with those specific terms as the document I have uses
a mixture of terms like "the LH value of...", "left-hand
expressions" and "evaluated in LH mode".

The documents I have are unsearchable PDFs; they appear to be
scans of paper documents.
https://comjnl.oxfordjournals.org/content/6/2/134.full.pdf
https://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf
Do you have friendlier documents?

UNIVERSITY OF LONDON INSTITUTE OF COMPUTER SCIENCE
*************************************************
THE UNIVERSITY MATHEMATICAL LABORATORY, CAMBRIDGE
*************************************************
CPL ELEMENTARY PROGRAMMING MANUAL
Edition I (London)
This document, written by the late John Buxton, was preserved by
Bill Williams, formerly of London University?s Atlas support team.
Bill has generously made it available to Dik Leatherdale who has
OCRed and otherwise transcribed it for the Web. All errors should
respected as far as possible, but program text and narrative are
distinguished by the use of different fonts. Transcriber's
additions and 'corrections' are in red, hyperlinks in underlined
purple. A contents list and a selection of references have been
added inside the back cover.
March 1965
I don't know where I got it from. The other searchable one is just
a PDF is the oft-cited paper "The main features of CPL" by Barron
et. al.

My understanding is the terms l-value and r-value, along with
several other terms widely used in relation to programming
languages, became widely used following a summer(?) course taught
by Christopher Strachey. Some of the other terms are referential
transparency and parametric polymorphism, IIRC.

https://en.wikipedia.org/wiki/Fundamental_Concepts_in_Programming_Languages

I believe it is possible to track down the notes from that course,
if a diligent web search is employed. I remember reading a copy
some years ago after finding one on the internet.

[Lawrence D'Oliveiro]

Post by Bart
BLISS is a rather strange language. For something supposedly low level
than C, it doesn't have 'goto'.

BLISS is proof that you don’t need goto to write well-structured, yet low-
level code.

Post by Bart
There is also a key feature that sets it apart from most HLLs: [variable
references are always L-values]

Another key feature: scoped macros. And the variations on that concept,
like the way aggregate types are defined in an essentially macro-like
fashion.

[Lawrence D'Oliveiro]

c is mid level language ...

In 1980s terms, it was.

Since the prevalence of languages at a higher level than what was
considered “high-level” then, you could say it has dropped a level.

[Bonita Montero]

Post by James Kuyper
C is a high level language. It is a very low-level high-level language,
but it's not in any sense an assembler.

C is almost the lowest-level of all high level lanugages.
I don't know any further language which lacks nearly every abstraction.

[Michael S]

On Sun, 25 Aug 2024 17:59:49 +0200

Post by Bonita Montero

Post by James Kuyper
C is a high level language. It is a very low-level high-level
language, but it's not in any sense an assembler.

C is almost the lowest-level of all high level lanugages.
I don't know any further language which lacks nearly every
abstraction.

Define "abstraction".
In my book this API is abstract.

struct bar_implementation;
typedef struct bar_implementation* bar;
typedef const struct bar_implementation* cbar;

bar* bar_make();
void bar_set_abra(bar x, int abra);
void bar_set_cadabra(bar x, double cadabra);
void bar_foo(bar x, int y);
int bar_get_abra(cbar x);
etc...

[Bonita Montero]

Post by Michael S
Define "abstraction".

OOP, functional programming, generic programming, exceptions.

[Bart]

Post by Bonita Montero

Post by Michael S
Define "abstraction".

OOP, functional programming, generic programming, exceptions.

That isn't surprising. The code you constantly post always uses the most
advanced features, uses every toy that is available, and the most
elaborate algorithms.

And it is always utterly incomprehensible.

I suspect that most of the time this is unnecessary and you just write
this way because you can. Or to show off. Or to write stuff it is
impossible to write in C (good!).

This is where having fewer such features helps. If I port an algorithm
to some new language X, then if it was originally in C, I'd have a
fighting chance.

In C++ written by you, then forget it. I don't even need to look at the
code. If you wrote novels, you'd be using a vocabulary 20 or 30 times
bigger than any normal person understands. It really doesn't help.

[Bonita Montero]

Post by Bart
That isn't surprising. The code you constantly post always uses the
most advanced features, uses every toy that is available, and the
most elaborate algorithms.
And it is always utterly incomprehensible.

No, it saves work and it is nearly optimal in terms of performance.

[Janis Papanagnou]

Post by Bart

Post by Bonita Montero

Post by Michael S
Define "abstraction".

This could have been looked up online (e.g. in a Wikipedia article).

Post by Bart

Post by Bonita Montero
OOP, functional programming, generic programming, exceptions.

(And there are yet more.)

Post by Bart
That isn't surprising. The code you constantly post always uses the most
advanced features, uses every toy that is available, and the most
elaborate algorithms.

I'm not sure in what bubble you lived the past decades. The listed
abstraction examples date back to the 1960's. They were realized in
many programming languages, including long existing ones as well as
many contemporary ones. I suggest to try to understand the concepts
if you want to reach the next experience level. :-)

Janis

Post by Bart
[...]

[Bart]

Post by Janis Papanagnou

Post by Bart

Post by Bonita Montero

Post by Michael S
Define "abstraction".

This could have been looked up online (e.g. in a Wikipedia article).

Post by Bart

Post by Bonita Montero
OOP, functional programming, generic programming, exceptions.

(And there are yet more.)

Post by Bart
That isn't surprising. The code you constantly post always uses the most
advanced features, uses every toy that is available, and the most
elaborate algorithms.

I'm not sure in what bubble you lived the past decades. The listed
abstraction examples date back to the 1960's. They were realized in
many programming languages,

Perhaps not so much in the ones people used. Assembly? Fortran? Cobol?
There have always been academic languages.

including long existing ones as well as

Post by Janis Papanagnou
many contemporary ones. I suggest to try to understand the concepts
if you want to reach the next experience level. :-)

I sometimes use (and implement) such features in scripting code which
has the support to use them effortlessly.

I've rarely needed them for systems programming.

My comments were in connection with their clunky and abstruse
implementations in C++, and BM's habit of posting C++ code full of
gratuitous uses of such features.

[Bonita Montero]

Post by Bart
My comments were in connection with their clunky and abstruse
implementations in C++, and BM's habit of posting C++ code full
of gratuitous uses of such features.

It's not gratitious: it reduces code size and makes the code more
readable.

[David Brown]

Post by Bart

Post by Janis Papanagnou

Post by Bart

Post by Bonita Montero

Post by Michael S
Define "abstraction".

This could have been looked up online (e.g. in a Wikipedia article).

Post by Bart

Post by Bonita Montero
OOP, functional programming, generic programming, exceptions.

(And there are yet more.)

Post by Bart
That isn't surprising. The code you constantly post always uses the most
advanced features, uses every toy that is available, and the most
elaborate algorithms.

I'm not sure in what bubble you lived the past decades. The listed
abstraction examples date back to the 1960's. They were realized in
many programming languages,

Perhaps not so much in the ones people used. Assembly? Fortran? Cobol?
There have always been academic languages.
 including long existing ones as well as

Post by Janis Papanagnou
many contemporary ones. I suggest to try to understand the concepts
if you want to reach the next experience level. :-)

I sometimes use (and implement) such features in scripting code which
has the support to use them effortlessly.
I've rarely needed them for systems programming.

As a counterpoint, I /have/ seen at least some of these in systems
programming - namely my own, and that of colleagues, customers and
suppliers. (Small-systems embedded and microcontroller programming is
pretty much all "systems programming".)

But it is also fair to say that abstractions are less than you might see
on "big" systems. For systems programming, there is more concern about
the efficiency of the results, leading to a different balance with
respect to speed or ease of coding, maintainability, code re-use, etc.

In this field, C++ usage is on the way up, C usage has peaked and is
going down, assembly is mostly dead (at least as a language for entire
programs), and newcomers such as Rust and Micropython are emerging.

We very rarely see exceptions in this field, but OOP is certainly common
now. Classes with non-virtual inheritance are basically cost-free, and
provide structure, safety, encapsulation and flexibility. Virtual
functions have overhead, but can be a solid alternative to call-backs or
function pointers. I use generic programming - templates - regularly,
with inheritance and CRTP for compile-time polymorphism. I've even used
lambdas.

Yes, abstractions are, and always have been, vital to systems
programming. They have always been important to systems programming in
C too, using the limited tools available in C ("void*" pointers, typedef
"handle" types, struct pointers so that client code does not see the
struct contents, etc.). C++ gives you a lot more tools here, and lets
you get more efficient results in the end (if you use it appropriately).

But you certainly can use a range of abstractions in C programming too.
Every time you use an enumerated type instead of an int, it's an
abstraction. You can encapsulate your data and functions in structs.
You can do generic coding with macros. C++ makes it easier to get
right, and harder to get wrong (while still compiling), but you can
still do abstractions in C.

And yes, C++ gives more opportunities to write incomprehensible code
than C, and the language suffers from having been built up gradually
over time by adding features to a base (roughly C). It is no more a
"perfect" language than any other language.

Post by Bart
My comments were in connection with their clunky and abstruse
implementations in C++, and BM's habit of posting C++ code full of
gratuitous uses of such features.

I don't think BM's posts are generally good or clear examples of uses of
C++. And I don't think continuously posting "C++ would be ten times
easier" in c.l.c is helpful to anyone.

[Bonita Montero]

Post by David Brown
But it is also fair to say that abstractions are less than you might see
on "big" systems.  For systems programming, there is more concern about
the efficiency of the results, ...

C++ is efficient and abstract in one.

Post by David Brown
We very rarely see exceptions in this field, but OOP is certainly common
now.

You have to accept exceptions with C++ since there are a lot of places
where C++ throws a bad_alloc or system_error.

Post by David Brown
Classes with non-virtual inheritance are basically cost-free, and provide
structure, safety, encapsulation and flexibility. Virtual functions have
overhead, ...

The virtual function overhead isn't notwworthy and not much more over
manual dispatch.

Post by David Brown
But you certainly can use a range of abstractions in C programming too.

C doesn't supply features to have abstractions like in C++.

Post by David Brown
I don't think BM's posts are generally good or clear examples of uses
of C++. And I don't think continuously posting "C++ would be ten times
easier" in c.l.c is helpful to anyone.

C is just too much work.

[David Brown]

Post by Bonita Montero

Post by David Brown
But it is also fair to say that abstractions are less than you might
see on "big" systems.  For systems programming, there is more concern
about the efficiency of the results, ...

C++ is efficient and abstract in one.

Any simple one-line claim here is clearly going to be wrong.


C++ code can be efficient, or abstract, or both, or neither. The
language supports a wide range of coding practices, including bad ones.

Some types of abstraction inevitably have run-time costs (speed or code
space), which can be highly relevant in resource-constrained systems or
other situations where efficiency is paramount (games programming is a
fine example). These abstractions may or may not be worth the cost in
the overall picture - it is up to the software developer to figure that
out, regardless of the language.

Post by Bonita Montero

Post by David Brown
We very rarely see exceptions in this field, but OOP is certainly
common now.

You have to accept exceptions with C++ since there are a lot of places
where C++ throws a bad_alloc or system_error.

Incorrect. Like most low-level or systems programmers using C++, I have
exceptions disabled and never use them.

Post by Bonita Montero

Post by David Brown
Classes with non-virtual inheritance are basically cost-free, and
provide
structure, safety, encapsulation and flexibility.  Virtual functions have
overhead, ...

The virtual function overhead isn't notwworthy and not much more over
manual dispatch.

Incorrect.

You simply don't know what you are talking about for programming at this
level - whether it is in C or C++.

Virtual function overhead will sometimes be worth the cost, and in some
circumstances it can be less than more manual dispatch methods. But it
is not cost-free, and the overhead can most certainly be relevant if it
is used inappropriately.

Post by Bonita Montero

Post by David Brown
But you certainly can use a range of abstractions in C programming too.

C doesn't supply features to have abstractions like in C++.

As I said, you can use a lot of abstractions in C programming, but C++
can make many types of abstraction easier, safer, and more efficient.

Post by Bonita Montero

Post by David Brown
I don't think BM's posts are generally good or clear examples of uses
of C++. And I don't think continuously posting "C++ would be ten times
easier" in c.l.c is helpful to anyone.

C is just too much work.

Feel free to unsubscribe from the Usenet group dedicated to a language
you so strongly dislike.

[Bonita Montero]

Post by David Brown

Post by Bonita Montero
C++ is efficient and abstract in one.

Any simple one-line claim here is clearly going to be wrong.

90% of the C++-abstractions are zero-cost abstractons.

Post by David Brown
C++ code can be efficient, or abstract, or both, or neither.

Of course it can. Imagine functional programming with a std::sort.
It's abstract since you won't have to deal with the details of the
sort and supply only a comparison function object, but it's still
optimally performant.

Post by David Brown

Post by Bonita Montero
You have to accept exceptions with C++ since there are a lot of places
where C++ throws a bad_alloc or system_error.

Incorrect.  Like most low-level or systems programmers using C++, I have
exceptions disabled and never use them.

You won't be able to change the runtime's behaviour with that. The
runtime trows bad_alloc or system_error everywhere and if you disable
exceptions the application simply terminates if this is thrown.

Post by David Brown
Incorrect.

I just measured the tim of a ...

virtual int fn( int, int )

... which adds only two ints. The overhead is about one nanosecond
on my Zen4-CPU. And usually you do complex tasks inside the virtual
function so that the call itself doens't participate much in the
overall computation time.

Post by David Brown
Virtual function overhead will sometimes be worth the cost, and in some
circumstances it can be less than more manual dispatch methods.  But it
is not cost-free, and the overhead can most certainly be relevant if it
is used inappropriately.

If the destination of the dispatch varies the overhead is nearly the
same as with static dispatch since most of the time takes the mispre-
dicted branch.

[David Brown]

Post by Bonita Montero

Post by David Brown

Post by Bonita Montero
C++ is efficient and abstract in one.

Any simple one-line claim here is clearly going to be wrong.

90% of the C++-abstractions are zero-cost abstractons.

90% of statistics are plucked from the air, including that one.

Post by Bonita Montero

Post by David Brown
C++ code can be efficient, or abstract, or both, or neither.

Of course it can. Imagine functional programming with a std::sort.
It's abstract since you won't have to deal with the details of the
sort and supply only a comparison function object, but it's still
optimally performant.

What part of "or both" in my comment caused you such confusion?

Post by Bonita Montero

Post by David Brown

Post by Bonita Montero
You have to accept exceptions with C++ since there are a lot of places
where C++ throws a bad_alloc or system_error.

Incorrect.  Like most low-level or systems programmers using C++, I
have exceptions disabled and never use them.

You won't be able to change the runtime's behaviour with that. The
runtime trows bad_alloc or system_error everywhere and if you disable
exceptions the application simply terminates if this is thrown.

As I said, you have no idea what you are talking about in the context of
low-level programming. People use C++ without exceptions on embedded
systems, resource-constrained systems, high-reliability systems, and
low-level code.

Post by Bonita Montero

Post by David Brown
Incorrect.

I just measured the tim of a ...
    virtual int fn( int, int )
... which adds only two ints. The overhead is about one nanosecond
on my Zen4-CPU. And usually you do complex tasks inside the virtual
function so that the call itself doens't participate much in the
overall computation time.

Again, you demonstrate your total ignorance of the topic.

Post by Bonita Montero

Post by David Brown
Virtual function overhead will sometimes be worth the cost, and in
some circumstances it can be less than more manual dispatch methods.
But it is not cost-free, and the overhead can most certainly be
relevant if it is used inappropriately.

If the destination of the dispatch varies the overhead is nearly the
same as with static dispatch since most of the time takes the mispre-
dicted branch.

The vast majority of processors produced and sold do not have any kind
of branch prediction.

[Bonita Montero]

Post by David Brown
90% of statistics are plucked from the air, including that one.

With C++ this fits. Most abstractions don't have an additional overhead
over a manual implementation.

Post by David Brown
As I said, you have no idea what you are talking about in the context of
low-level programming.

I told you why it isn't practicable to suppress exceptions in C++
since the runtime uses a lot of exceptions.

Post by David Brown
Again, you demonstrate your total ignorance of the topic.

Most of the time a nanosecond more doesn't count, especiailly because
usually you do more complex things in a virtual function.

Post by David Brown
The vast majority of processors produced and sold do not have any kind
of branch prediction.

Not today.

[David Brown]

Post by Bonita Montero

Post by David Brown
90% of statistics are plucked from the air, including that one.

With C++ this fits. Most abstractions don't have an additional overhead
over a manual implementation.

Again, you are wrong to generalize. It depends on the situation, the
abstraction in question, and the code.

Post by Bonita Montero

Post by David Brown
As I said, you have no idea what you are talking about in the context
of low-level programming.

I told you why it isn't practicable to suppress exceptions in C++
since the runtime uses a lot of exceptions.

And you were completely wrong when you said that. Perhaps in /your/
field of programming you are correct - but you are ignoring the rest of
the world.

Post by Bonita Montero

Post by David Brown
Again, you demonstrate your total ignorance of the topic.

Most of the time a nanosecond more doesn't count, especiailly because
usually you do more complex things in a virtual function.

Often that is correct. Often it is /not/ correct. The only thing we
can all be sure of is that your laughable attempt at a benchmark here
bears no relation to the real world - especially not the real world of
small-systems programming.

Post by Bonita Montero

Post by David Brown
The vast majority of processors produced and sold do not have any kind
of branch prediction.

Not today.

For every one of your favourite big x86 chips sold, there will be a
hundred small microcontrollers - none of which has branch prediction.

[Vir Campestris]

Post by Bonita Montero

Post by David Brown
90% of statistics are plucked from the air, including that one.

With C++ this fits. Most abstractions don't have an additional overhead
over a manual implementation.

Hmm. I'll pass on that.

Post by Bonita Montero

Post by David Brown
As I said, you have no idea what you are talking about in the context
of low-level programming.

I told you why it isn't practicable to suppress exceptions in C++
since the runtime uses a lot of exceptions.

There are quite a lot of places in low level programming where you have
to manage without them. Sometimes you have to do without the runtime as
well. That doesn't mean you can't use C++ itself.

Post by Bonita Montero

Post by David Brown
Again, you demonstrate your total ignorance of the topic.

Most of the time a nanosecond more doesn't count, especiailly because
usually you do more complex things in a virtual function.

Post by David Brown
The vast majority of processors produced and sold do not have any kind
of branch prediction.

Not today.

The vast majority of processors in desktop computers and above, sure.
But do you think the one in my watch has one? My thermostat? The alarm
clock? I've got at least a dozen devices with processors in this room
with me right now.

There are an awful lot of these small things. Where power usage and cost
matters far more than performance.

Andy

[Scott Lurndal]

Post by Vir Campestris

Post by Bonita Montero
I told you why it isn't practicable to suppress exceptions in C++
since the runtime uses a lot of exceptions.

There are quite a lot of places in low level programming where you have
to manage without them. Sometimes you have to do without the runtime as
well. That doesn't mean you can't use C++ itself.

Indeed. I've worked on two hypervisors and one large OS written
in C++ (no RTTI, no exceptions).

[Chris M. Thomasson]

Post by David Brown

Post by Bonita Montero

Post by David Brown
But it is also fair to say that abstractions are less than you might
see on "big" systems.  For systems programming, there is more concern
about the efficiency of the results, ...

C++ is efficient and abstract in one.

Any simple one-line claim here is clearly going to be wrong.
C++ code can be efficient, or abstract, or both, or neither.  The
language supports a wide range of coding practices, including bad ones.
Some types of abstraction inevitably have run-time costs (speed or code
space), which can be highly relevant in resource-constrained systems or
other situations where efficiency is paramount (games programming is a
fine example).  These abstractions may or may not be worth the cost in
the overall picture - it is up to the software developer to figure that
out, regardless of the language.

Post by Bonita Montero

Post by David Brown
We very rarely see exceptions in this field, but OOP is certainly
common now.

You have to accept exceptions with C++ since there are a lot of places
where C++ throws a bad_alloc or system_error.

Incorrect.  Like most low-level or systems programmers using C++, I have
exceptions disabled and never use them.

[...]

Ditto. Usually, that is the way to go.

[Michael S]

On Sun, 25 Aug 2024 20:12:47 +0200

Post by Bonita Montero

Post by Michael S
Define "abstraction".

OOP, functional programming, generic programming, exceptions.

I don't see why any of those are abstractions.
Not that I am particularly fond of abstractions when I do see them.

[Lawrence D'Oliveiro]

On Sun, 25 Aug 2024 20:12:47 +0200 Bonita Montero

Post by Bonita Montero

Post by Michael S
Define "abstraction".

OOP, functional programming, generic programming, exceptions.

I don't see why any of those are abstractions.

OOP -- a form of data type abstraction
functional programming -- abstraction away from control sequencing
generic programming -- abstraction away from specific types
exceptions -- abstraction away from explicit exit jumps

[Tim Rentsch]

Michael S <***@yahoo.com> writes:

[..concerning "abstraction"..]

Post by Michael S
Not that I am particularly fond of abstractions when I do see
them.

A most unexpected comment. IMO choosing the right abstractions
to define may be the most important skill in developing large
systems.

[Bonita Montero]

Post by Tim Rentsch
A most unexpected comment. IMO choosing the right abstractions
to define may be the most important skill in developing large
systems.

Tell this someone who think C++ doen't provide sth. useful over C.

[Lawrence D'Oliveiro]

Post by Bonita Montero

A most unexpected comment. IMO choosing the right abstractions to
define may be the most important skill in developing large systems.

Tell this someone who think C++ doen't provide sth. useful over C.

Linus Torvalds?

[Bonita Montero]

Post by Lawrence D'Oliveiro

Post by Bonita Montero

A most unexpected comment. IMO choosing the right abstractions to
define may be the most important skill in developing large systems.

Tell this someone who think C++ doen't provide sth. useful over C.

Linus Torvalds?

That's hopeless to persuade him.

[Lawrence D'Oliveiro]

Post by Bonita Montero

Post by Lawrence D'Oliveiro

Post by Bonita Montero

A most unexpected comment. IMO choosing the right abstractions to
define may be the most important skill in developing large systems.

Tell this someone who think C++ doen't provide sth. useful over C.

Linus Torvalds?

That's hopeless to persuade him.

I thought you were going to question the competence of someone who had
that attitude ... clearly not.

[Bonita Montero]

Post by Lawrence D'Oliveiro
I thought you were going to question the competence of someone who had
that attitude ... clearly not.

That's not the question of competence but attitude. Torvalds has
a minimalistic mindset and cant't handle abstractions in code.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
I thought you were going to question the competence of someone who had
that attitude ... clearly not.

That's not the question of competence but attitude. Torvalds has a
minimalistic mindset and cant't handle abstractions in code.

On the contrary, the Linux kernel is full of abstractions: the device
layer, the network layer, the filesystem layer, the security layer ...

You can’t do an OS kernel without abstractions. And Linux does it better
than any other.

[Michael S]

On Tue, 27 Aug 2024 07:23:17 +0200

Post by Bonita Montero

Post by Lawrence D'Oliveiro

Post by Bonita Montero

A most unexpected comment. IMO choosing the right abstractions to
define may be the most important skill in developing large
systems.

Tell this someone who think C++ doen't provide sth. useful over C.

Linus Torvalds?

That's hopeless to persuade him.

There were times when I tried to defend your position against Linus.
https://www.realworldtech.com/forum/?threadid=84931&curpostid=84931
But it was 16 years ago.

[Michael S]

On Tue, 27 Aug 2024 07:10:57 +0200

Post by Bonita Montero

Post by Tim Rentsch
A most unexpected comment. IMO choosing the right abstractions
to define may be the most important skill in developing large
systems.

Tell this someone who think C++ doen't provide sth. useful over C.

That's not me.
But things that I appreciate about C++ likely form small strict subset
of the things that you appreciate.

[Michael S]

On Mon, 26 Aug 2024 17:16:06 -0700

Post by Tim Rentsch
[..concerning "abstraction"..]

Post by Michael S
Not that I am particularly fond of abstractions when I do see them.

A most unexpected comment. IMO choosing the right abstractions
to define may be the most important skill in developing large
systems.

You are probably right, but me being me, I am rarely able to grasp
pure abstract things. Most typically, first read about abstract
concept goes straight above my head. It can't be helped by few
examples, but success is not guaranteed.
Even after I seemingly grasped the principle, when I start using
an instance of abstract thing, it's hard for me to stop thinking about
gears and toothed wheels rotating under the hood.

[Lawrence D'Oliveiro]

Most typically, first read about abstract concept goes
straight above my head.

This is why you need good examples. Generalization is all very well,
until your audience fails to grasp why the generalization is actually
useful.

Consider the “descriptor” concept in Python
<https://docs.python.org/3/reference/datamodel.html#implementing-descriptors>.
Can you appreciate, from that bare-bones description in §3.3.2.2 and
§3.3.2.3, how useful they are? I certainly didn’t.

But on further study, I discovered that descriptors are key to how the
whole class system works in Python. Every function is a descriptor.
And then you discover that builtin functions like “classmethod” and
“property” are just conveniences: you could write them yourself in
regular Python code if you wanted to, since they don’t rely on any
magic internal to the particular Python implementation.

A similar thing applies to metaclasses.

[Janis Papanagnou]

Post by Bonita Montero
C is almost the lowest-level of all high level lanugages.
I don't know any further language which lacks nearly every abstraction.

Do languages like Brainfuck, Intercal, Whitespace, etc. count?

Janis

[Lawrence D'Oliveiro]

Post by Bonita Montero
I don't know any further language which lacks nearly every abstraction.

Look at where C came from: its immediate ancestor was an adaptation of
BCPL to cope with byte addressability. BCPL had no types: everything was a
“word”.

The DEC folks were fond of a language called BLISS, which was similar to
BCPL but a bit more advanced. Instead of conventional types, it had
abstractions for accessing various memory layouts, including dynamic ones,
right down to the bit level.

[Janis Papanagnou]

Post by James Kuyper
...

Post by John Forkosh
I recall C as originally characterized as a "portable assembly language",
as opposed to a "higher level language". And I'd agree with that
assessment, whereby I think you're barking up the wrong tree by trying
to evaluate its merits/demerits vis-a-vis higher-level languages.
Consider it with respect to its own objectives, instead.

C has been mischaracterized as a "portable assembly language", but that
has never been an accurate characterization. It has, from the very
beginning, been defined by the behavior that is supposed to result from
translating and executing the C code, not the assembly language that's
supposed to be produced by the translation process.
C is a high level language. It is a very low-level high-level language,
but it's not in any sense an assembler.

I wouldn't take above characterization literally - literally it's a
wrong assessment (as I think you rightly say). But given its origin,
its intended uses for systems programming, its machine-orientation,
its low-level constructs, and lacking any high-level constructs, the
absence of abstraction that was already existing these days in various
forms in quite some other HLLs, all the software bugs and hassles with
it as a consequence of its design, and whatnot...

We can dispute about informal classifications; whether it's a "very
low-level high-level language" or rather a "very high-level low-level
language".

It's just that many folks consider(ed) that language within the zoo of
HLLs as a lousy representative. The title "portable assembly language"
always appeared to me as being just a disrespectful accentuated formula
used in discussions with naive fans of new hypes that were not aware of
state-of-the-art language developments existing these days, and still.

When thinking about the "level" of languages there's always an image
of the economic damage forming in my mind by the actual consequences
of using a language. (Just recently I tried soothing someone that he
shouldn't take his desperate error-tracking too personal in the light
that the damage of the given C-issue certainly caused billions of
dollars already and that he's certainly not alone with that problem.)

Janis

Post by James Kuyper
[...]

[Bonita Montero]

Post by John Forkosh
I recall C as originally characterized as a "portable assembly language",

With complex instruction sets like SSE, AVX and so on it's not really
easy to imagine what code the compiler might generate from the code
you write. The only part where I agree that C is similar to assembly
that it easy to layout data structures in a way that their physical
layout is 100% controllable (platform-depenendent).
Some time ago I had the idea that if C would be invented today not
much people would use it.

[David Brown]

Post by John Forkosh

Post by Bart

Post by Bonita Montero

Post by John Forkosh
I came across
https://www.fastcompany.com/91169318/
where I was quite surprised, and very happily so,
to see C listed as #3 on its list of
"Top 10 most common hard skills listed in 2023"
(scroll about halfway down for that list). Moreover,
C++ doesn't even make it anywhere in that top-10 list.
So is that list sensible??? I'd personally be delighted
if so, but I'm suspicious it may just be wishful thinking
on my part, and some kind of goofiness on the list's author.

I guess C++ is used much more often because you're multiple times
more produdtive than with C. And programming in C++ is a magnitude
less error-prone.

C++ incorporates most of C. So someone can write 'C++' code but can
still have most of the same problems as C.
Meanwhile real C++ code has several times more boilerplate than C. HTF
you can even discern your actual program amidst all that crap is beyond me.
There /are/ proper higher level languages than both C and C++. You can
use one to help develop a working application, then porting that part to
C is a quicker, simpler and safer process.

I recall C as originally characterized as a "portable assembly language",

You recall incorrectly. Or, rather, you correctly recall people
incorrectly characterizing it that way.

One of C's original intents (and it has been extraordinarily successful
at it) is to reduce the need to write assembly language.

Post by John Forkosh
as opposed to a "higher level language". And I'd agree with that
assessment,

Then you'd be wrong. Dangerously wrong - people who think C is a kind
of "portable assembly language" regularly write incorrect code and miss
much of the point of the language.

Post by John Forkosh
whereby I think you're barking up the wrong tree by trying
to evaluate its merits/demerits vis-a-vis higher-level languages.
Consider it with respect to its own objectives, instead.

That's word salad without content. You are saying that C should be
treated like C.

[Janis Papanagnou]

Post by Bart

Post by Bonita Montero
I guess C++ is used much more often because you're multiple times
more produdtive than with C. And programming in C++ is a magnitude
less error-prone.

C++ incorporates most of C. So someone can write 'C++' code but can
still have most of the same problems as C.

It's true that C++ decided to inherit unsafe C designs as C being
sort of its base. But a sophisticated programmer would knowingly
avoid the unsafe parts and use the existing safer C++ constructs.
Only that a language allows that you *can* write bad code doesn't
mean you cannot avoid the problems. Of course it would have been
(IMO) better if the unsafe parts were replaced or left out, but
there were portability consideration in C++'s design.

Janis

Post by Bart
[...]

[Michael S]

On Sun, 25 Aug 2024 18:36:46 +0200

Post by Janis Papanagnou

Post by Bart

Post by Bonita Montero
I guess C++ is used much more often because you're multiple times
more produdtive than with C. And programming in C++ is a magnitude
less error-prone.

C++ incorporates most of C. So someone can write 'C++' code but can
still have most of the same problems as C.

It's true that C++ decided to inherit unsafe C designs as C being
sort of its base. But a sophisticated programmer would knowingly
avoid the unsafe parts and use the existing safer C++ constructs.
Only that a language allows that you *can* write bad code doesn't
mean you cannot avoid the problems. Of course it would have been
(IMO) better if the unsafe parts were replaced or left out, but
there were portability consideration in C++'s design.
Janis

Post by Bart
[...]

Safe HLLs without mandatory automatic memory management tend to fall
into two categories:
1. Those that already failed to become popular
2. Those for which it will happen soon
That despite at least one language in the 1st category being pretty
well designed, if more than a little over-engineered.

[Tim Rentsch]

Post by Michael S
On Sun, 25 Aug 2024 18:36:46 +0200

Post by Janis Papanagnou

Post by Bart

Post by Bonita Montero
I guess C++ is used much more often because you're multiple times
more produdtive than with C. And programming in C++ is a magnitude
less error-prone.

C++ incorporates most of C. So someone can write 'C++' code but can
still have most of the same problems as C.

It's true that C++ decided to inherit unsafe C designs as C being
sort of its base. But a sophisticated programmer would knowingly
avoid the unsafe parts and use the existing safer C++ constructs.
Only that a language allows that you *can* write bad code doesn't
mean you cannot avoid the problems. Of course it would have been
(IMO) better if the unsafe parts were replaced or left out, but
there were portability consideration in C++'s design.

Post by Bart
[...]

Safe HLLs without mandatory automatic memory management

I'm not sure what you mean by this description. Do you mean
languages that are otherwise unsafe but have a safe subset?
If not that then please elaborate. What are some examples of
"safe HLLs without mandatory automatic memory management"?

Post by Michael S
tend to fall
1. Those that already failed to become popular
2. Those for which it will happen soon

It's been amusing reading a discussion of which languages are or are
not high level, without anyone offering a definition of what the
term means. Wikipedia says, roughly, that a high-level language is
one that doesn't provide machine-level access (and IMO that is a
reasonable characterization). Of course no distinction along these
lines is black and white - almost all languages have a loophole or
two - but I expect there is general agreement about which languages
clearly fail that test. In particular, any language that offers
easy access to raw memory addresses (and both C and C++ certainly
do), is not a high-level language in the Wikipedia sense.

Second amusement: using the term popular without giving any
kind of a metric that measures popularity.

Third amusement: any language that has not yet become popular
has already failed to become popular.

Post by Michael S
That despite at least one language in the 1st category being
pretty well designed, if more than a little over-engineered.

Please, don't keep us in suspense. To what language do you refer?

[Michael S]

On Sun, 25 Aug 2024 17:48:14 -0700

Post by Tim Rentsch

Post by Michael S
On Sun, 25 Aug 2024 18:36:46 +0200

Post by Janis Papanagnou

Post by Bart

Post by Bonita Montero
I guess C++ is used much more often because you're multiple times
more produdtive than with C. And programming in C++ is a
magnitude less error-prone.

C++ incorporates most of C. So someone can write 'C++' code but
can still have most of the same problems as C.

It's true that C++ decided to inherit unsafe C designs as C being
sort of its base. But a sophisticated programmer would knowingly
avoid the unsafe parts and use the existing safer C++ constructs.
Only that a language allows that you *can* write bad code doesn't
mean you cannot avoid the problems. Of course it would have been
(IMO) better if the unsafe parts were replaced or left out, but
there were portability consideration in C++'s design.

Post by Bart
[...]

Safe HLLs without mandatory automatic memory management

I'm not sure what you mean by this description. Do you mean
languages that are otherwise unsafe but have a safe subset?
If not that then please elaborate.

That is nearly always a case in practice, but it does not have to be.
I can't give a counterexample, but I can imagine language similar to
Pascal that has no records with variants and no procedure Dispose and
also hardens few other corners that I currently forgot about.

Post by Tim Rentsch
What are some examples of
"safe HLLs without mandatory automatic memory management"?

The most prominent examples are Ada and Rust.
It seems that Zig tries the same, but I was not sufficiently interested
to dig deeper. Partly because last time when I tried to play with Zig it
refused to install on Wit7 machine.

Post by Tim Rentsch

Post by Michael S
tend to fall
1. Those that already failed to become popular
2. Those for which it will happen soon

It's been amusing reading a discussion of which languages are or are
not high level, without anyone offering a definition of what the
term means. Wikipedia says, roughly, that a high-level language is
one that doesn't provide machine-level access (and IMO that is a
reasonable characterization).

I don't like this definition. IMHO, what language does have is at least
as important as what it does not have for the purpose of estimating its
level.

Post by Tim Rentsch
Of course no distinction along these
lines is black and white - almost all languages have a loophole or
two - but I expect there is general agreement about which languages
clearly fail that test. In particular, any language that offers
easy access to raw memory addresses (and both C and C++ certainly
do), is not a high-level language in the Wikipedia sense.
Second amusement: using the term popular without giving any
kind of a metric that measures popularity.

Precise definitions of everything are hard.
May be, popular == 1st or close second choice for particular sort of
programming job? Plus, somehow add popularity points for being used in
many fields?

Post by Tim Rentsch
Third amusement: any language that has not yet become popular
has already failed to become popular.

There is also "heir apparent' type - languages that are recognized as
not particularly popular now, but believed by many, including press, to
become popular in the future.

Post by Tim Rentsch

Post by Michael S
That despite at least one language in the 1st category being
pretty well designed, if more than a little over-engineered.

Please, don't keep us in suspense. To what language do you refer?

I thought, that every reader understood that I meant Ada.

[Tim Rentsch]

Post by Michael S
On Sun, 25 Aug 2024 17:48:14 -0700

Post by Tim Rentsch

Post by Michael S
On Sun, 25 Aug 2024 18:36:46 +0200

[...]

Post by Michael S

Post by Tim Rentsch

Post by Michael S

Post by Janis Papanagnou
It's true that C++ decided to inherit unsafe C designs as C being
sort of its base. But a sophisticated programmer would knowingly
avoid the unsafe parts and use the existing safer C++ constructs.
Only that a language allows that you *can* write bad code doesn't
mean you cannot avoid the problems. Of course it would have been
(IMO) better if the unsafe parts were replaced or left out, but
there were portability consideration in C++'s design.

[...]

Safe HLLs without mandatory automatic memory management

I'm not sure what you mean by this description. Do you mean
languages that are otherwise unsafe but have a safe subset?
If not that then please elaborate.

That is nearly always a case in practice, but it does not have to
be. I can't give a counterexample, but I can imagine language
similar to Pascal that has no records with variants and no
procedure Dispose and also hardens few other corners that I
currently forgot about.

Does this description mean anything different than saying "Pascal
with all the unsafe parts taken out", without saying what all the
unsafe parts are?

Post by Michael S

Post by Tim Rentsch
What are some examples of
"safe HLLs without mandatory automatic memory management"?

The most prominent examples are Ada and Rust.

I don't think of either Ada or Rust as safe languages. I expect
there are some barriers in both languages to using unsafe features,
but also that it's easy to get around the barriers if one chooses
to do so. (I should add that I have little to no "real world"
experience in either Ada or Rust.)

Post by Michael S

Post by Tim Rentsch

Post by Michael S
tend to fall
1. Those that already failed to become popular
2. Those for which it will happen soon

It's been amusing reading a discussion of which languages are or are
not high level, without anyone offering a definition of what the
term means. Wikipedia says, roughly, that a high-level language is
one that doesn't provide machine-level access (and IMO that is a
reasonable characterization).

I don't like this definition. IMHO, what language does have is at
least as important as what it does not have for the purpose of
estimating its level.

I think Wikipedia means to give a definition in the dictionary
sense of the word, namely, presenting the most commonly held view,
or sometimes the most commonly held views plural, of how the word
or term is used. It is in this dictionary sense that I say the
definition is a reasonable characterization. In particular I don't
mean to say that this meaning is "good", only that it is common
(and also has reasonably high historical fidelity).

Post by Michael S

Post by Tim Rentsch
Of course no distinction along these
lines is black and white - almost all languages have a loophole or
two - but I expect there is general agreement about which languages
clearly fail that test. In particular, any language that offers
easy access to raw memory addresses (and both C and C++ certainly
do), is not a high-level language in the Wikipedia sense.
Second amusement: using the term popular without giving any
kind of a metric that measures popularity.

Precise definitions of everything are hard. [...]

Sure. But that shouldn't stop someone from giving an imprecise
or informal definition. Any attempt to give a useful definition
is infinitely better than no definition.

Post by Michael S

Post by Tim Rentsch
Third amusement: any language that has not yet become popular
has already failed to become popular.

There is also "heir apparent' type - languages that are recognized
as not particularly popular now, but believed by many, including
press, to become popular in the future.

Ahhh, so now we have a new metric to consider, whether a language
is _expected to become_ popular in the future (and an indeterminate
future at that).

Please forgive me if that comment comes across as snarky. Mostly I
just find the whole concept amusing... I don't mean to do that at
your expense.

Post by Michael S

Post by Tim Rentsch

Post by Michael S
That despite at least one language in the 1st category being
pretty well designed, if more than a little over-engineered.

Please, don't keep us in suspense. To what language do you refer?

I thought, that every reader understood that I meant Ada.

I expect many readers did. If I had had to guess I would have
guessed Rust.

[Michael S]

On Mon, 26 Aug 2024 17:55:21 -0700

Post by Tim Rentsch

Post by Michael S
On Sun, 25 Aug 2024 17:48:14 -0700

Post by Tim Rentsch

Post by Michael S
That despite at least one language in the 1st category being
pretty well designed, if more than a little over-engineered.

Please, don't keep us in suspense. To what language do you refer?

I thought, that every reader understood that I meant Ada.

I expect many readers did. If I had had to guess I would have
guessed Rust.

It means that derogatory overtones of my past comments about Rust were
too subtle.

[Tim Rentsch]

Post by Michael S
On Mon, 26 Aug 2024 17:55:21 -0700

Post by Tim Rentsch

Post by Michael S
On Sun, 25 Aug 2024 17:48:14 -0700

Post by Tim Rentsch

Post by Michael S
That despite at least one language in the 1st category being
pretty well designed, if more than a little over-engineered.

Please, don't keep us in suspense. To what language do you refer?

I thought, that every reader understood that I meant Ada.

I expect many readers did. If I had had to guess I would have
guessed Rust.

It means that derogatory overtones of my past comments about Rust were
too subtle.

It could just be my memory. I don't try to keep track of who
likes (or dislikes) which programming languages.

[James Kuyper]

Post by Michael S
On Sun, 25 Aug 2024 17:48:14 -0700

...

Post by Michael S

Post by Tim Rentsch
It's been amusing reading a discussion of which languages are or are
not high level, without anyone offering a definition of what the
term means. Wikipedia says, roughly, that a high-level language is
one that doesn't provide machine-level access (and IMO that is a
reasonable characterization).

I don't like this definition. IMHO, what language does have is at least
as important as what it does not have for the purpose of estimating its
level.

That's not a particularly useful response. It would have been more
useful to identify what features a language should have to qualify as
low level or high level.
Defining a level solely in terms of what the language has, without
regard to what it doesn't have, leads to a potential ambiguity: what if
a language, let's call it A/C, which has every feature that you think
should qualify it as a low level language, AND every feature that you
think should qualify it as a high level language? If you define those
terms solely in terms of what the language has, then A/C must be called
both a low-level language and an high-level language.
If, on the other hand, you define the level of a language both in terms
of what it has, and what it doesn't have, A/C would be unclassifiable,
which I think is a more appropriate way of describing it. Every time
that someone says "low level languages can't ...", that statement will
be false about A/C, and similarly for "high level languages can't ...".

One principle that should be kept in mind when you're defining a term
whose definition is currently unclear, is to decide what statements you
want to make about things described by that term. In many cases, the
truth of those statements should be a logical consequence of the
definition you use.

[David Brown]

Post by Tim Rentsch
It's been amusing reading a discussion of which languages are or are
not high level, without anyone offering a definition of what the
term means.

That is an important point.

Post by Tim Rentsch
Wikipedia says, roughly, that a high-level language is
one that doesn't provide machine-level access (and IMO that is a
reasonable characterization).

No, that's not what Wikipedia says. To get the full picture, read the
links:

<https://en.wikipedia.org/wiki/Low-level_programming_language>
<https://en.wikipedia.org/wiki/High-level_programming_language>

Roughly speaking, they define a "high-level language" as one with a
strong abstraction from the underlying machine, while a "low-level
language" has little or no abstraction.

Wikipedia classifies C as a high-level language that also supports a
degree of low-level programming, which I think is a fair assessment.

Post by Tim Rentsch
Of course no distinction along these
lines is black and white - almost all languages have a loophole or
two - but I expect there is general agreement about which languages
clearly fail that test.

Agreed - trying to make such binary classifications is usually a bad idea.

Post by Tim Rentsch
In particular, any language that offers
easy access to raw memory addresses (and both C and C++ certainly
do), is not a high-level language in the Wikipedia sense.

That is simply incorrect, based on the Wikipedia articles.

I think it is perhaps better to first talk about low-level and
high-level coding or functionality, rather than the language.
High-level coding deals with abstractions, defined by their
specifications rather than the hardware (or virtual machine) running the
code. Low-level coding is tightly tied to the hardware - access to
arbitrary memory (subject to OS or hardware restrictions), features
based on the instruction set of the computer, and so on.

C clearly supports high-level programming - you can write very portable
code that is independent from the underlying hardware. (Most C
/programs/ require a least a small amount of implementation-dependent
behaviour or external library code, but a lot of C /code/ does not.) It
also clearly supports low-level programming.

Whether a programming language is considered "high level" or "low level"
is, IME, determined by one question - is the language mainly defined in
terms of abstract specifications or by the hardware implementing it? C
does have implementation-specific behaviour, and is thus not "pure"
high-level language, but there can be no doubt that it is primarily
defined as a high-level language.

Both C and C++ also /support/ a limited (but very useful in practice)
subset of low-level programming. That does not make them low-level
programming languages, any more than C++ is a functional programming
language just because it has lambdas. And even if one were to classify
them as low-level languages, it would not stop them /also/ being
high-level languages.

And note that Wikipedia classifies it as a high-level language, and
lists it along with other high-level languages. (I don't consider
Wikipedia to be authoritative, but it's usually a reasonable and
objective source for many purposes.)

Post by Tim Rentsch
Third amusement: any language that has not yet become popular
has already failed to become popular.

Or it could be a new language that is gaining traction.

[Lawrence D'Oliveiro]

Post by David Brown
Wikipedia classifies C as a high-level language that also supports a
degree of low-level programming, which I think is a fair assessment.

The same could be said of Python.

[David Brown]

Post by Lawrence D'Oliveiro

Post by David Brown
Wikipedia classifies C as a high-level language that also supports a
degree of low-level programming, which I think is a fair assessment.

The same could be said of Python.

Python does not support any significant degree of low-level programming.

A key example of low-level programming is control of hardware, which on
most systems means accessing memory-mapped registers at specific
addresses, reading and writing in specific orders. Python has no means
to do any of that - C and C++ both provide this ability. (Micropython,
a subset of Python targeting microcontrollers and small systems, has
library modules that can do this.)

[Keith Thompson]

Post by David Brown

Post by Lawrence D'Oliveiro

Post by David Brown
Wikipedia classifies C as a high-level language that also supports a
degree of low-level programming, which I think is a fair assessment.

The same could be said of Python.

Python does not support any significant degree of low-level programming.
A key example of low-level programming is control of hardware, which
on most systems means accessing memory-mapped registers at specific
addresses, reading and writing in specific orders. Python has no
means to do any of that - C and C++ both provide this ability.
(Micropython, a subset of Python targeting microcontrollers and small
systems, has library modules that can do this.)

I've used Python's mmap module to access /dev/kmem on an embedded
Linux system, accessing fixed addresses defined by an FPGA image.
(The mmap module happens to be part of the core Python distribution.)

This is one of several reasons why we have different newsgroups for
different langauges.

[David Brown]

Post by Keith Thompson

Post by David Brown

Post by Lawrence D'Oliveiro

Post by David Brown
Wikipedia classifies C as a high-level language that also supports a
degree of low-level programming, which I think is a fair assessment.

The same could be said of Python.

Python does not support any significant degree of low-level programming.
A key example of low-level programming is control of hardware, which
on most systems means accessing memory-mapped registers at specific
addresses, reading and writing in specific orders. Python has no
means to do any of that - C and C++ both provide this ability.
(Micropython, a subset of Python targeting microcontrollers and small
systems, has library modules that can do this.)

I've used Python's mmap module to access /dev/kmem on an embedded
Linux system, accessing fixed addresses defined by an FPGA image.
(The mmap module happens to be part of the core Python distribution.)

There are /always/ ways to get around things (especially on Linux, where
you have such "backdoors"). That is why I said Python does not support
low-level programming to any /significant/ degree. "low-level" vs.
"high-level" is not a binary distinction. Typically if you have Python
code controlling some hardware, it is via a Python module with a C
implementation, or with ctypes and an external shared library - not
directly from Python.

Post by Keith Thompson
This is one of several reasons why we have different newsgroups for
different langauges.

Sure. It's not really the place to get into details of other languages,
but it is a thread that compares C to other languages.

[Lawrence D'Oliveiro]

... or with ctypes and an external shared library - not
directly from Python.

ctypes is a standard Python library module, and it has low-level
capabilities (like type-punning) that can be exercised independently of
actually using it to load any external C code.

[Lawrence D'Oliveiro]

Post by David Brown
Python does not support any significant degree of low-level programming.
A key example of low-level programming is control of hardware, which on
most systems means accessing memory-mapped registers at specific
addresses, reading and writing in specific orders. Python has no means
to do any of that - C and C++ both provide this ability.

I’ve got news for you: this kind of thing is perfectly doable in Python
<https://docs.python.org/3/library/ctypes.html>.

[Bart]

Post by Lawrence D'Oliveiro

Post by David Brown
Python does not support any significant degree of low-level programming.
A key example of low-level programming is control of hardware, which on
most systems means accessing memory-mapped registers at specific
addresses, reading and writing in specific orders. Python has no means
to do any of that - C and C++ both provide this ability.

I’ve got news for you: this kind of thing is perfectly doable in Python
<https://docs.python.org/3/library/ctypes.html>.

It's Python calling a special module to do the dirty work. That's not
far removed from Python just invoking an external C program to do the job.

By contrast, my scripting language can directly do the low level stuff.
If there is a byte value at a certain address, it can access it like this:

p:=makeref(0x40'0000, byte)
println p^

[Bart]

Post by Tim Rentsch

Post by Michael S
On Sun, 25 Aug 2024 18:36:46 +0200

Post by Janis Papanagnou

Post by Bart

Post by Bonita Montero
I guess C++ is used much more often because you're multiple times
more produdtive than with C. And programming in C++ is a magnitude
less error-prone.

C++ incorporates most of C. So someone can write 'C++' code but can
still have most of the same problems as C.

It's true that C++ decided to inherit unsafe C designs as C being
sort of its base. But a sophisticated programmer would knowingly
avoid the unsafe parts and use the existing safer C++ constructs.
Only that a language allows that you *can* write bad code doesn't
mean you cannot avoid the problems. Of course it would have been
(IMO) better if the unsafe parts were replaced or left out, but
there were portability consideration in C++'s design.

Post by Bart
[...]

Safe HLLs without mandatory automatic memory management

I'm not sure what you mean by this description. Do you mean
languages that are otherwise unsafe but have a safe subset?
If not that then please elaborate. What are some examples of
"safe HLLs without mandatory automatic memory management"?

Post by Michael S
tend to fall
1. Those that already failed to become popular
2. Those for which it will happen soon

It's been amusing reading a discussion of which languages are or are
not high level, without anyone offering a definition of what the
term means. Wikipedia says, roughly, that a high-level language is
one that doesn't provide machine-level access (and IMO that is a
reasonable characterization). Of course no distinction along these
lines is black and white - almost all languages have a loophole or
two - but I expect there is general agreement about which languages
clearly fail that test. In particular, any language that offers
easy access to raw memory addresses (and both C and C++ certainly
do), is not a high-level language in the Wikipedia sense.

So, which language do you think is higher level, C++ or Python? Where
might Lisp fit in, or OCaml?

Language 'level' is a linear concept, but the various characteristics of
languages are such that there is really a multidimensional gamut.

But among 'systems languages' (something else that needs defining as so
many are claiming they are in that category), I think most would agree
that C is near the bottom, but I don't think that C++ is that much
higher, given how much cruft you still have to write to get anything done.

[Tim Rentsch]

Post by Bart

Post by Tim Rentsch
It's been amusing reading a discussion of which languages are or
are not high level, without anyone offering a definition of what
the term means. Wikipedia says, roughly, that a high-level
language is one that doesn't provide machine-level access (and IMO
that is a reasonable characterization). Of course no distinction
along these lines is black and white - almost all languages have a
loophole or two - but I expect there is general agreement about
which languages clearly fail that test. In particular, any
language that offers easy access to raw memory addresses (and both
C and C++ certainly do), is not a high-level language in the
Wikipedia sense.

So, which language do you think is higher level, C++ or Python?
Where might Lisp fit in, or OCaml?

I find it hard to imagine that anyone cares about my answer to
this question.

Post by Bart
Language 'level' is a linear concept, but the various characteristics
of languages are such that there is really a multidimensional gamut.

I think you're confusing the notions of "high-level" and "powerful".
For example, in the Wikipedia entry sense of the term, the original
BASIC is a high-level language, but I think most people would agree
that it is not a very powerful language.

[Lawrence D'Oliveiro]

Language 'level' is a linear concept ...

Not strictly. For example, consider that many assembly languages
traditionally had more advanced macro facilities (e.g. arguments passed by
keyword) than C.

[Bonita Montero]

Post by Tim Rentsch
It's been amusing reading a discussion of which languages are or are
not high level, without anyone offering a definition of what the
term means. Wikipedia says, roughly, that a high-level language is
one that doesn't provide machine-level access (and IMO that is a
reasonable characterization). Of course no distinction along these
lines is black and white - almost all languages have a loophole or
two - but I expect there is general agreement about which languages
clearly fail that test. In particular, any language that offers
easy access to raw memory addresses (and both C and C++ certainly
do), is not a high-level language in the Wikipedia sense.

C++ is a lanugage which addresses the lowest level as well as medium
abstactions. I like to combine both.

[Vir Campestris]

Post by Bonita Montero
C++ is a lanugage which addresses the lowest level as well as medium
abstactions. I like to combine both.

Your view of lowest probably differs from mine.

Once upon a time I had to write a BIOS for a computer from scratch.

You turn it on, and it starts executing code. OK, you can be sure you
have a ROM and a processor. Have you got any RAM? Best to be sure it's
functioning OK before you start using it. I'll just call this test
function and ... oh. Well, I can put the return address in SP, we're not
using that yet.

That code had to be written in assembler. No other language gives you
sufficient control. And it was actually quite fun doing it!

ANdy

[Lawrence D'Oliveiro]

Post by Michael S
Safe HLLs without mandatory automatic memory management tend to fall
1. Those that already failed to become popular
2. Those for which it will happen soon
That despite at least one language in the 1st category
being pretty well designed, if more than a little over-engineered.

Which category does Rust fall into? Given that it has already won
acceptance in the world’s most successful software project -- the Linux
kernel.