soem people say it possibly it (by some people i mean polish coder ans security enginer gynvael coldwind, but he laso says it rather outthrone c++ coz c++ has so many unresolvable problems thet rust may be cure for them)

as to c i wouldnt like it..but i must say i tried for soem moment learn this rust but looked at this source fragments in wikipedia page on it and resigned...doeas not seem just to sparkle any interest in me..

so i personally doubt... (most of this 'new; languagess adds not so much 'new' walue and if do something they mix it with a soup of worse than c syntax and things..so it adds some piece of new but a t the cost that not justify it imo)

​Ain't nothing gonna dethrone C until a total revolution of the modern
computing ecosystem; in other words, replacing C would require replacing
everything else all at once.
--
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Bitches stole my whole ass ␔🭖᷿᪳𝼗᷍⏧𒒫𐻾ࣛ↉�⃣ quoted-printable, can't
have shit in Thunderbird 😩

Blue-Maned_Hawk ha scritto:
>
> ​Ain't nothing gonna dethrone C until a total revolution of the modern
> computing ecosystem; in other words, replacing C would require replacing
> everything else all at once.

+++

czwartek, 13 lipca 2023 o 07:39:23 UTC+2 Blue-Maned_Hawk napisał(a):
> ​Ain't nothing gonna dethrone C until a total revolution of the modern
> computing ecosystem; in other words, replacing C would require replacing
> everything else all at once.
>
why? i dont get it

systems are in fact based on abi it is a module-conventions (dll on windows) but they are language agnostic, so in fact c dont pass in there

this abi btw probably still need standarisation...for me most sane abi for modules maybe is like that:

contain symbol and enumeration of abi-convention used (which may be many).... the two i find sane
are like that function uuses input static record say

int x,y foo(int x,y,z)
uses 12 bytes static input record and 8 bytes static output record, thiose static records may
lie inside thsi function as its ram or both outside the function and belong to its parent caller..
really what you should pass is 2 pointers (on input or output record) or nothing if im not wrong
- thsi nothing may be better so probably the convention where thiose static records are inside
the foo are better - this is pass nothing convention

czwartek, 13 lipca 2023 o 13:27:28 UTC+2 fir napisał(a):
> czwartek, 13 lipca 2023 o 07:39:23 UTC+2 Blue-Maned_Hawk napisał(a):
> > ​Ain't nothing gonna dethrone C until a total revolution of the modern
> > computing ecosystem; in other words, replacing C would require replacing
> > everything else all at once.
> >
> why? i dont get it
>
> systems are in fact based on abi it is a module-conventions (dll on windows) but they are language agnostic, so in fact c dont pass in there
>
> this abi btw probably still need standarisation...for me most sane abi for modules maybe is like that:
>
> contain symbol and enumeration of abi-convention used (which may be many).... the two i find sane
> are like that function uuses input static record say
>
> int x,y foo(int x,y,z)
> uses 12 bytes static input record and 8 bytes static output record, thiose static records may
> lie inside thsi function as its ram or both outside the function and belong to its parent caller..
> really what you should pass is 2 pointers (on input or output record) or nothing if im not wrong
> - thsi nothing may be better so probably the convention where thiose static records are inside
> the foo are better - this is pass nothing convention

overally imo this symbol names list should look like this i guess

"symbolname", ENUM_CALL_CONVENTION (int or short ot byte, depending on module format on gven system), {agruments_list} (this argument list in a form of enums like
{ENUM_INT, ENUM_INT, ENUM_FLOAT, ENUM_CHAR_POINTER etc} some special enums probably
would be to make soem notations like ENUM_OUTPUT_ARGS (probably better than using bite flags and OR them with other enums)

structures could be also defined as such list of enums and be puttd in symbol list

On 2023-07-13, Blue-Maned_Hawk <bluemanedhawk@gmail.com> wrote:
>
> ​Ain't nothing gonna dethrone C until a total revolution of the modern
> computing ecosystem; in other words, replacing C would require replacing
> everything else all at once.
>

I agree with this, I am a old C programmer that started in the late
80's for the last 10 years I been playing with GO and lately with RUST
but they have a long way to even been able to replace C, why ? C is
everywhere and is still faster. You find C in all network routers,
infrasctructure, kernels, libs, devices, heck Unix and C are brothers
and Unix son Linux and BSD's are still promident all over. Nothing
speaks Unix better than C since they were created for each other,
network protocols and such all tied down to unix and C.
And one can keep on going...

Happy Hacking

--
{gemini,https}://{,rek2.}hispagatos.org
https://hispagatos.space/@rek2

On 2023-07-13, rek2 hispagatos <rek2@hispagatos.org.invalid> wrote:
> On 2023-07-13, Blue-Maned_Hawk <bluemanedhawk@gmail.com> wrote:
>>
>> ​Ain't nothing gonna dethrone C until a total revolution of the modern
>> computing ecosystem; in other words, replacing C would require replacing
>> everything else all at once.
>>
>
> I agree with this, I am a old C programmer that started in the late
> 80's for the last 10 years I been playing with GO and lately with RUST
> but they have a long way to even been able to replace C, why ? C is
> everywhere and is still faster. You find C in all network routers,
> infrasctructure, kernels, libs, devices, heck Unix and C are brothers
> and Unix son Linux and BSD's are still promident all over. Nothing
> speaks Unix better than C since they were created for each other,
> network protocols and such all tied down to unix and C.
> And one can keep on going...

The rabid fanatics of newer programming languages overemphasize C
reliability issues. There is an ocean of C code running out there, yet
the sky isn't falling.

C is easy to work in. You form a picture in your mind of how you want
the memory to be shaped and manipulated, and then just describe that in
the most obvious C.

You don't have to deal with someone's incomphrehensible opinions about
why you shouldn't do what you want, but instead do something else
(that something else being a puzzle for you to figure out, one
compiler diagnostic at a time).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> C is easy to work in. You form a picture in your mind of how you want
> the memory to be shaped and manipulated, and then just describe that in
> the most obvious C.

I cannot agree with that claim. C is a very
dangerous language and some people have likened
it to using a chainsaw: It is highly efficient
provided that you know how to use it properly, but
you can cut your leg off if you are ignorant or
careless.

Luckily modern C compilers can help a lot when
all warnings are enabled.

C allows you to write code that may work as
intended, but relies on undefined behaviour.
It can be a nightmare.

Many years ago, K&R book said that C is a small
language and it is best served by a small book.

Since those times, many things have changed. In
order to use C in the real world, you have to be
familiar with C standards like ISO and POSIX/SUS.

br,
KK

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> C is easy to work in. You form a picture in your mind of how you want
>> the memory to be shaped and manipulated, and then just describe that in
>> the most obvious C.
>
>I cannot agree with that claim. C is a very
>dangerous language

Hyperbole, to be sure.

> and some people have likened
>it to using a chainsaw: It is highly efficient
>provided that you know how to use it properly, but
>you can cut your leg off if you are ignorant or
>careless.

Which anecdote doesn't actually mean anything. Just
like most professional chainsaw users are very productive
and modern saws have a plethora of safety features,
so most C programmers are very productive and produce
productive code. There are exceptions of course, but
both tools continue to be useful regardless of the fact
that they can be improperly used.

Scott Lurndal <scott@slp53.sl.home> wrote:
> Which anecdote doesn't actually mean anything.

It does have a ring of truth in it.

> Just like most professional chainsaw users are very productive
> and modern saws have a plethora of safety features,
> so most C programmers are very productive and produce
> productive code. There are exceptions of course, but
> both tools continue to be useful regardless of the fact
> that they can be improperly used.

To be clear, I am not against the use of C. It is one
of the first programming languages I have learned and
I am confident enough to do *something* with C. But
it is quite a demanding language for most people.

On comp.lang.c, day after day, I still come across
very difficult C questions concerning unusual
corner cases or something like that. To use C
in a safe way, you have to memorize lots of
rules that the C standards dictate. If you don't,
you might invoke undefined behaviour and be
screwed.

Writing portable C code can also be challenging
as it also requires lots of knowledge about
C standards. I am not saying it cannot be done,
just that it is not easy.

With languages like Python or Java, you don't have
to manually take care of memory management, or worry
about corrupting memory with incorrect pointer
usage. Portability is not difficult to achieve,
either. They are much safer and easier to use
than C.

The only language that I consider more dangerous
than C is assembly. And raw machine code in case
someone still likes to use just numbers to express
their ideas. My former colleague did that with
8-bit ORIC-1 back in the 1980s.

Hmmm. I probably have to say that C++ is more
dangerous than C as well. That language is so
bloated and full of features that who can
know what is all right and what causes UB?

br,
KK

On 2023-07-13, Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Which anecdote doesn't actually mean anything.
>
> It does have a ring of truth in it.
>
>> Just like most professional chainsaw users are very productive
>> and modern saws have a plethora of safety features,
>> so most C programmers are very productive and produce
>> productive code. There are exceptions of course, but
>> both tools continue to be useful regardless of the fact
>> that they can be improperly used.
>
> To be clear, I am not against the use of C. It is one
> of the first programming languages I have learned and
> I am confident enough to do *something* with C. But
> it is quite a demanding language for most people.
>
> On comp.lang.c, day after day, I still come across
> very difficult C questions concerning unusual
> corner cases or something like that. To use C
> in a safe way, you have to memorize lots of
> rules that the C standards dictate. If you don't,
> you might invoke undefined behaviour and be
> screwed.
>
> Writing portable C code can also be challenging
> as it also requires lots of knowledge about
> C standards. I am not saying it cannot be done,
> just that it is not easy.

Most people don't need to write absolutely portable C code. Just
portable enough.

Most programmers who believe who are writing portable C, with
demonstrated success, probably don't know that pointers don't all have
to be the same size.

A rigrous unit test and integration test suite will go a long
way toward flushing out actual portability problems; just not
ISO C academic ones.

> With languages like Python or Java, you don't have
> to manually take care of memory management, or worry
> about corrupting memory with incorrect pointer
> usage. Portability is not difficult to achieve,
> either. They are much safer and easier to use
> than C.

If we crack open the internals of Python, we can easily find grotty C
code that is not absolutely portable.

I doub that CPython would run on a machine where sizeof (char *) and
sizeof (struct foo *) are different.

> The only language that I consider more dangerous
> than C is assembly. And raw machine code in case
> someone still likes to use just numbers to express
> their ideas. My former colleague did that with
> 8-bit ORIC-1 back in the 1980s.

But assembly is also less dangerous because instruction sets for
machines tend to have way less undefined behavior (if any).

In many assembly languages, you can add two signed numbers and check for
overflow very easily, either by checking a flag, or handling some
processor exception.

Evaluation orders are carefully specified, so that programs for the
oldest members of an architectural family work unmodified on newer
members, whose cores do a lot more stuff in parallel.

Processors optimize code dynamically, in a way that preserves the
instruction-by instruction interpretation of their effects.

(There may be exceptions for that, but as a generalization it
is broadly true.)

All the situations in which undefined behavior turns into a predictable
crash like SIGFPE, SIGBUS or SIGSEGV are courtesy of the hardware being
better defined and safer than C.

It's the instruction set that protects kernels from user spaces, and
user spaces from each other, so that C programs can go rampant.

> Hmmm. I probably have to say that C++ is more
> dangerous than C as well. That language is so
> bloated and full of features that who can
> know what is all right and what causes UB?

The thing about C++ is that if you are an expert solo developer (or
small team) doing a completely greenfield project, you can choose C++
features that make programming utterly safe.

Instead of "int", you can write some integer class that throws
exceptions on overflow, and is almost as convenient to use as the native
int.

You can use safely bounded arrays, reference counted strings (such
things being in the standard library).

Smart pointers to prevent leaks and use-after-free errors;
RAII to ensure locks are unlocked ...

If you have to inherit legacy C++ code written and maintained by
generations of random goofballs, all bets are off.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 13/07/2023 21:30, Kalevi Kolttonen wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Which anecdote doesn't actually mean anything.
>
> It does have a ring of truth in it.
>
>> Just like most professional chainsaw users are very productive
>> and modern saws have a plethora of safety features,
>> so most C programmers are very productive and produce
>> productive code. There are exceptions of course, but
>> both tools continue to be useful regardless of the fact
>> that they can be improperly used.
>
> To be clear, I am not against the use of C. It is one
> of the first programming languages I have learned and
> I am confident enough to do *something* with C. But
> it is quite a demanding language for most people.
>
> On comp.lang.c, day after day, I still come across
> very difficult C questions concerning unusual
> corner cases or something like that. To use C
> in a safe way, you have to memorize lots of
> rules that the C standards dictate. If you don't,
> you might invoke undefined behaviour and be
> screwed.

So the answer is to do constant battle with the Rust Borrow Checker?

Which I understand doesn't guarantee it will solve all memory problems,
while to do useful things you need to switch to Unsafe mode, the mode
that C operates in.

Or maybe there's Zig. That's got its own problem: until 2019, it refused
to accept source files with CRLF line endings (deliberately spiting MS),
and it still doesn't support hard tabs, only spaces for identation.

So you're already doing battle with it just to write source code!

Then apparently it doesn't have a for-loop to do a simple iteration. And
printing something out involves code like this:

const std = @import("std");

try std.io.getStdOut().writer().print("Hello, {s}!\n", .{"world"});

The C equivalent is:

#include <stdio.h>

printf("Hello, %s\n", "world");

And I thought `printf` was fiddly enough!

There is a huge amount that can be improved in C without radically
changing the kind of language it is, its complexity, level, or size
(this is what I've spent a lot of time doing, privately).

But these new languages try too hard, and are too ambitious.

> Writing portable C code can also be challenging
> as it also requires lots of knowledge about
> C standards. I am not saying it cannot be done,
> just that it is not easy.

Portable C is a myth. Even C you wrote 5 minutes ago might not work,
even on the exact same machine and OS, if someone uses a different set
of compiler options.

However C will work on unusual architectures, even if the program you
write is not so portable, while Rust likely won't work at all since it's
designed for desktop-class processors, like most other alternatives.

> With languages like Python or Java, you don't have
> to manually take care of memory management, or worry
> about corrupting memory with incorrect pointer
> usage. Portability is not difficult to achieve,
> either. They are much safer and easier to use
> than C.

Python is a different class of language for different applications.
CPython is also implemented in C; you'd have trouble implementing it in
itself. (Do people think CPython is unsafe because it's written in C?)

(I don't know Java. Does it really take care of memory management?)

> The only language that I consider more dangerous
> than C is assembly.

If the only choice I had to write a program was Rust, C or assembly, I
would choose C first. If that wasn't available, I would choose assembly
over Rust (and use that to write a simple HLL first then use that to
write the program).

Bart <bc@freeuk.com> wrote:
> On 13/07/2023 21:30, Kalevi Kolttonen wrote:
> So the answer is to do constant battle with the Rust Borrow Checker?

I make no recommendations. I just observed the fact that
in order to write safe C code, you need considerable amount
of knowledge about the C standards in order to avoid the
pitfalls.

I am sure Kaz and Scott are very talented programmers and
they probably have many years of experience with C, so the
language is indeed easy for them.

When Rust came out, I read about its features and selling points,
but I never bothered to write any Rust code. I don't remember
that much anymore, but I guess Rust compilers are able to do
some additional checking compared to C compilers, and this is
due to the fact that Rust language is different than C.

Some people have suggested that Linux kernel modules should
be allowed to be written in Rust, too. I do not know whether
that suggestion was ever accepted by the Linux kernel developers.

> Portable C is a myth. Even C you wrote 5 minutes ago might not work,
> even on the exact same machine and OS, if someone uses a different set
> of compiler options.

No. Lots of C programs are quite portable. That includes e.g. Linux
kernel, BSD kernels, PostgreSQL, Apache, Postfix, and many,
many other Unix daemons. PostgreSQL runs not only on Unix
but even on Windows. Possibly OpenLDAP does, too.

The kernels of course require a certain amount of assembly tweaking
for new CPU architectures, but the huge majority of the codebase
is C. Well, I have to admit the Linux kernel's C code uses some
GNU extensions and may require GCC to compile.

>> With languages like Python or Java, you don't have
>> to manually take care of memory management, or worry
>> about corrupting memory with incorrect pointer
>> usage. Portability is not difficult to achieve,
>> either. They are much safer and easier to use
>> than C.
>
> Python is a different class of language for different applications.

Yes, agreed, but I only compared safety and difficulty to use.

However, I have heard that Python can be very fast. They do some
serious number crunching with it.

> CPython is also implemented in C; you'd have trouble implementing it in
> itself. (Do people think CPython is unsafe because it's written in C?)

I know nothing about that.

> (I don't know Java. Does it really take care of memory management?)

Yes, it has automatic garbage collection. Those who have started
programming using Java can have considerable difficulties with
manual memory management in C. They are not used to it at all.

>> The only language that I consider more dangerous
>> than C is assembly.
>
> If the only choice I had to write a program was Rust, C or assembly, I
> would choose C first. If that wasn't available, I would choose assembly
> over Rust (and use that to write a simple HLL first then use that to
> write the program).

Well, I understand what you are saying, but your point misses
the mark.

Saying that you would use assembly to create a HLL first
and then use that HLL is equivalent to saying: I would use C first
to implement Python and then I would write in Python. Yes, you
could do that, but in that case you wouldn't be writing your
program in C any longer, but you would write it in Python.

It is well-known that you can use assembly or C to implement
*any* programming language, but that was not discussed here now.

br,
KK

On 13/07/2023 22:30, Kalevi Kolttonen wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Which anecdote doesn't actually mean anything.
>
> It does have a ring of truth in it.
>
>> Just like most professional chainsaw users are very productive
>> and modern saws have a plethora of safety features,
>> so most C programmers are very productive and produce
>> productive code. There are exceptions of course, but
>> both tools continue to be useful regardless of the fact
>> that they can be improperly used.

Any tool that can be used, can be abused. And the more powerful the
tool, the more scope for damage if you don't use it properly. This is
especially true if you want an efficient language.

>
> To be clear, I am not against the use of C. It is one
> of the first programming languages I have learned and
> I am confident enough to do *something* with C. But
> it is quite a demanding language for most people.
>
> On comp.lang.c, day after day, I still come across
> very difficult C questions concerning unusual
> corner cases or something like that. To use C
> in a safe way, you have to memorize lots of
> rules that the C standards dictate. If you don't,
> you might invoke undefined behaviour and be
> screwed.

No, you don't actually have to memorize lots of rules - you need to know
a few, then write code sensibly. You can get on fine with C without
ever knowing the precedence of && and <<, or how signed integer overflow
works (or doesn't work), or which formats for function declarations are
compatible with each other. You write clear, sensible code that is
easily read by humans. You avoid unnecessarily complicated expressions,
and use brackets to make things clearer. You do one thing at a time,
step by step. You think about your calculations and use types that are
big enough.

/Some/ people need to know all the rules. That includes:

1. Pedants on comp.lang.c and other forums ("pendant" is not an insult -
it's a badge of honour for those that help others with their awkward
questions).

2. People working on C tools.

3. Smart-arses who think it is cool to make code as compact as humanly
possible.

4. People who have to understand code written by smart-arses.

5. People who really need to squeeze that absolute maximum out of their
code, or are writing very specialised low-level code.

Of course you have to know the basics, and you may have to know more
details in some aspects of the language and standard library if your
programming tasks require it. But the idea that every C programmer must
memorize the C standards or face nasal demons is simply not credible.

>
> Writing portable C code can also be challenging
> as it also requires lots of knowledge about
> C standards. I am not saying it cannot be done,
> just that it is not easy.

Few people need to write C code that is significantly portable. Writing
code that works across similar targets is easy, but almost no one (as a
fraction of C programmers) has to write code that works on targets with
16-bit chars, or with ones' complement signed integers, or any of the
other oddities that challenge extreme portability.

>
> With languages like Python or Java, you don't have
> to manually take care of memory management, or worry
> about corrupting memory with incorrect pointer
> usage. Portability is not difficult to achieve,
> either. They are much safer and easier to use
> than C.
>

Different languages are good for different purposes. It makes no sense
to compare Python and C and say which is "easier" - it's like comparing
a lorry and a motorcycle. They do different things.

Of course, if you are working on a program that is a good fit for
Python, it will be much harder to write it in C - and vice versa.

It is fair to say, however, that some languages make it easier to make
mistakes than others, and some have better tools than others to help
developers. Python has a bit more help built in (though you can make
all kinds of mistakes with it - they are just different mistakes than
you make with C). For C, you do need to know more about how to use your
tools - and some C programmers don't.

> The only language that I consider more dangerous
> than C is assembly. And raw machine code in case
> someone still likes to use just numbers to express
> their ideas. My former colleague did that with
> 8-bit ORIC-1 back in the 1980s.
>
> Hmmm. I probably have to say that C++ is more
> dangerous than C as well. That language is so
> bloated and full of features that who can
> know what is all right and what causes UB?
>

Many people happily use C++ to write very good code. But as Spiderman
says, with great power comes great responsibility. You can write
marvellous things in C++, but there's plenty of scope for writing train
wrecks.

David Brown <david.brown@hesbynett.no> wrote:
> Many people happily use C++ to write very good code. But as Spiderman
> says, with great power comes great responsibility. You can write
> marvellous things in C++, but there's plenty of scope for writing train
> wrecks.

I have heard that C++ projects must usually limit their
use of C++ features to some subset because the whole
language is simply too big to comprehend. If you allowed
all features to be used, then it would be likely that
not all programmers in the team could understand the
code.

I wonder are there *any* languages you would call
dangerous, or do you consider all of them as equals,
provided that the programmers know what they are
doing?

br,
KK

>
> Many people happily use C++ to write very good code.  But as Spiderman
> says, with great power comes great responsibility.  You can write
> marvellous things in C++, but there's plenty of scope for writing train
> wrecks.
>
>

Apart from that it was extracted from the concept of the sword of
Damocle, it was the uncle Ben who said this to Peter Parker (Spiderman).

On 14/07/2023 07:43, Kalevi Kolttonen wrote:
> Bart <bc@freeuk.com> wrote:
>> On 13/07/2023 21:30, Kalevi Kolttonen wrote:

> When Rust came out, I read about its features and selling points,
> but I never bothered to write any Rust code. I don't remember
> that much anymore, but I guess Rust compilers are able to do
> some additional checking compared to C compilers, and this is
> due to the fact that Rust language is different than C.

So what do you you use to code in? I'm guessing Python and/or Java.

> Some people have suggested that Linux kernel modules should
> be allowed to be written in Rust, too. I do not know whether
> that suggestion was ever accepted by the Linux kernel developers.
>
>> Portable C is a myth. Even C you wrote 5 minutes ago might not work,
>> even on the exact same machine and OS, if someone uses a different set
>> of compiler options.
>
> No. Lots of C programs are quite portable. That includes e.g. Linux
> kernel,

The Linux kernel is at least 26 million lines of code. It's not all
found in the same machine! There are lots of different files for
different hardware.

So a driver for one device will be different from that for another: you
write dedicated C code for each, so portability is not needed.

>> Python is a different class of language for different applications.
>
> Yes, agreed, but I only compared safety and difficulty to use.
>
> However, I have heard that Python can be very fast. They do some
> serious number crunching with it.

With Numpy? I believe that is a library written in unsafe C, that's why
it's fast.

>> CPython is also implemented in C; you'd have trouble implementing it in
>> itself. (Do people think CPython is unsafe because it's written in C?)
>
> I know nothing about that.
> It is well-known that you can use assembly or C to implement
> *any* programming language, but that was not discussed here now.

You're agreeing that you can use unsafe C to create a safe language. So
why not a safe application?

On 14/07/2023 09:58, Kalevi Kolttonen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> Many people happily use C++ to write very good code. But as Spiderman
>> says, with great power comes great responsibility. You can write
>> marvellous things in C++, but there's plenty of scope for writing train
>> wrecks.
>
> I have heard that C++ projects must usually limit their
> use of C++ features to some subset because the whole
> language is simply too big to comprehend. If you allowed
> all features to be used, then it would be likely that
> not all programmers in the team could understand the
> code.
>

I have never heard of a (real) general-purpose language in which anybody
uses the whole language. And certainly you always use a subset of the
language - that is what is called a "coding standard". You might not be
using a formal written standard, but you will be using one - a project
style, a company standard, personal habits. Maybe your standard for C
says "never use the comma operator", or "do not use goto", or "put all
your #include's at the head of the file". There are countless ways in
which you limit the way you write code in any language used for real work.

So the question is really a matter of extent - do people restrict
themselves /more/ for C++ than for other languages?

I think for many languages, people and projects restrict themselves a
great deal, but perhaps don't think about it. How many Python
programmers understand metaclasses? How many use slots in their
classes? If you add the standard library for languages, how many Python
or Java programmers are familiar and confident with more than a few
percent of their standard libraries?

But it is not unfair to say that you have to be more restrictive with
C++ than with C. For one thing, it is a /much/ bigger language than C,
and it is highly unlikely that everyone in a team will be familiar with
the whole language, never mind the standard library. You also have
significant differences between versions, and any given project has to
pick a standard (say, C++17). And there's no doubt that some aspects of
C++ programming give a lot of scope for confusion, more than in the
smaller and simpler C.

> I wonder are there *any* languages you would call
> dangerous, or do you consider all of them as equals,
> provided that the programmers know what they are
> doing?
>

Of course there are. I agree that assembly is pretty dangerous!

I think any general-purpose language that can be used for serious work
can be "dangerous" when used incorrectly, or without sufficient
knowledge. But I think it is primarily the way people use languages
that makes them dangerous, not the languages themselves. I don't
believe, for example, that C is inherently dangerous and Rust inherently
safer - not even for memory safety. But I think that the people who
write new versions of old C code in Rust at the moment do so with safety
and correctness more in focus than the people that wrote old code in
the first place, and they use better tools for it. I believe that these
same people could write equally safe versions in C if they wanted.

More advanced or higher level languages can free you from possible
mistakes, but they always give you new ways to make other sorts of errors.

Bart <bc@freeuk.com> wrote:
> So what do you you use to code in? I'm guessing Python
> and/or Java.

Bash, AWK, Python, C. My University courses had to be
completed using Java, but that was over 20 years ago.

>> Some people have suggested that Linux kernel modules should
>> be allowed to be written in Rust, too. I do not know whether
>> that suggestion was ever accepted by the Linux kernel developers.
>>
>>> Portable C is a myth. Even C you wrote 5 minutes ago might not work,
>>> even on the exact same machine and OS, if someone uses a different set
>>> of compiler options.
>>
>> No. Lots of C programs are quite portable. That includes e.g. Linux
>> kernel,
>
> The Linux kernel is at least 26 million lines of code. It's not all
> found in the same machine! There are lots of different files for
> different hardware.

As far as I know, the "different files" are mostly CPU architecture
speficic assembly code. I could be wrong, though. Maybe you can offer
some proof?

> So a driver for one device will be different from that for another: you
> write dedicated C code for each, so portability is not needed.

Ummm...What? I just don't get it. Of course you write dedicated
code for different devices. What does that have to do with portability?

>>> Python is a different class of language for different applications.
>>
>> Yes, agreed, but I only compared safety and difficulty to use.
>>
>> However, I have heard that Python can be very fast. They do some
>> serious number crunching with it.
>
> With Numpy? I believe that is a library written in unsafe C, that's why
> it's fast.

Probably. All I know is that even phycists can use Python for their
demanding simulation tasks.

It seems to me that some folks are almost offended if C is criticized
in any way. I have no problem admitting that C is not a safe language.

>>> CPython is also implemented in C; you'd have trouble implementing it in
>>> itself. (Do people think CPython is unsafe because it's written in C?)
>>
>> I know nothing about that.
>> It is well-known that you can use assembly or C to implement
>> *any* programming language, but that was not discussed here now.
>
> You're agreeing that you can use unsafe C to create a safe language. So
> why not a safe application?

I never said C cannot be used for creating safe applications.

You are missing the entire point.

Look, if you say: I prefer to write in assembly, then do so. Write
in assembly by all means.

But do not *twist the argument* by saying that you prefer assembly, and
then immediately ditch your assembly preference by saying you would use
it to create a HLL. If you use assembly to create an entirely different
language, then you automatically admit that your preference is the newly
*HLL*, not assembly. This should be pretty obvious.

br,
KK

In article <u8qqpv$3v3pg$1@dont-email.me>,
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
....
>> (I don't know Java. Does it really take care of memory management?)
>
>Yes, it has automatic garbage collection. Those who have started
>programming using Java can have considerable difficulties with
>manual memory management in C. They are not used to it at all.

Much the same could be said about people who start out programming Excel
macros. When they start programming in C, they find it very strange that
you have to do memory management at all.

--
This is the GOP's problem. When you're at the beginning of the year
and you've got nine Democrats running for the nomination, maybe one or
two of them are Dennis Kucinich. When you have nine Republicans, seven
or eight of them are Michelle Bachmann.

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <u8qqpv$3v3pg$1@dont-email.me>,
> Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> ...
>>> (I don't know Java. Does it really take care of memory management?)
>>
>>Yes, it has automatic garbage collection. Those who have started
>>programming using Java can have considerable difficulties with
>>manual memory management in C. They are not used to it at all.
>
> Much the same could be said about people who start out programming Excel
> macros. When they start programming in C, they find it very strange that
> you have to do memory management at all.

You are quite right. The point is that manual memory management
is an additional burden to the programmer.

Creating serious memory leaks is one of the dangerous possibilities
when coding in C. That danger can be avoided altogether when writing
in e.g. Java.

br,
KK

On 14/07/2023 12:47, Bart wrote:
> On 14/07/2023 07:43, Kalevi Kolttonen wrote:
> > Bart <bc@freeuk.com> wrote:
> >> On 13/07/2023 21:30, Kalevi Kolttonen wrote:
>
>
> > When Rust came out, I read about its features and selling points,
> > but I never bothered to write any Rust code. I don't remember
> > that much anymore, but I guess Rust compilers are able to do
> > some additional checking compared to C compilers, and this is
> > due to the fact that Rust language is different than C.
>
> So what do you you use to code in? I'm guessing Python and/or Java.
>
> > Some people have suggested that Linux kernel modules should
> > be allowed to be written in Rust, too. I do not know whether
> > that suggestion was ever accepted by the Linux kernel developers.
> >
> >> Portable C is a myth. Even C you wrote 5 minutes ago might not work,
> >> even on the exact same machine and OS, if someone uses a different set
> >> of compiler options.
> >
> > No. Lots of C programs are quite portable. That includes e.g. Linux
> > kernel,
>
> The Linux kernel is at least 26 million lines of code. It's not all
> found in the same machine! There are lots of different files for
> different hardware.
>
> So a driver for one device will be different from that for another: you
> write dedicated C code for each, so portability is not needed.

Most Linux drivers are portable code - only a relatively small
proportion are platform specific. And the real target-specific stuff at
the low level is kept as small as practically possible.

However, none of the code needs to be /widely/ portable. All targets
have 32-bit int, 8-bit char, either 32-bit or 64-bit pointers, use ASCII
basic character sets, and have many other aspects in common.

>
>
> >> Python is a different class of language for different applications.
> >
> > Yes, agreed, but I only compared safety and difficulty to use.
> >
> > However, I have heard that Python can be very fast. They do some
> > serious number crunching with it.
>
> With Numpy? I believe that is a library written in unsafe C, that's why
> it's fast.
>

Yes, that's the way it is done.

> >> CPython is also implemented in C; you'd have trouble implementing it in
> >> itself. (Do people think CPython is unsafe because it's written in C?)
> >
> > I know nothing about that.
> > It is well-known that you can use assembly or C to implement
> > *any* programming language, but that was not discussed here now.
>
> You're agreeing that you can use unsafe C to create a safe language. So
> why not a safe application?
>

I fully agree.

David Brown <david.brown@hesbynett.no> wrote:
> However, none of the code needs to be /widely/ portable. All targets
> have 32-bit int, 8-bit char, either 32-bit or 64-bit pointers, use ASCII
> basic character sets, and have many other aspects in common.

I suppose one can argue pretty endlessly about the true
meaning of "portable code". How many platforms must it run
on in order to quality as portable? I think there is no
single correct answer to that question.

I don't know about other people's definitions, but I never
thought that portable code would mean that it would run
forever on absolutely every imaginable platform possible.

It seems like a far-fetched, extremist position to take.

NetBSD has been known for great portability and it runs
on quite many platforms. Those who claim that the portability
of C code is "a myth" would do well to check out this page:

http://www.netbsd.org/ports/

To me, NetBSD kernel and userland software is a clear
proof that carefully written C is indeed very portable.

Pretty much the same can be said about Linux.

br,
KK

piątek, 14 lipca 2023 o 13:30:33 UTC+2 Kalevi Kolttonen napisał(a):
> Kenny McCormack <gaz...@shell.xmission.com> wrote:
> > In article <u8qqpv$3v3pg$1...@dont-email.me>,
> > Kalevi Kolttonen <kal...@kolttonen.fi> wrote:
> > ...
> >>> (I don't know Java. Does it really take care of memory management?)
> >>
> >>Yes, it has automatic garbage collection. Those who have started
> >>programming using Java can have considerable difficulties with
> >>manual memory management in C. They are not used to it at all.
> >
> > Much the same could be said about people who start out programming Excel
> > macros. When they start programming in C, they find it very strange that
> > you have to do memory management at all.
> You are quite right. The point is that manual memory management
> is an additional burden to the programmer.
>
> Creating serious memory leaks is one of the dangerous possibilities
> when coding in C. That danger can be avoided altogether when writing
> in e.g. Java.
>
imo you write a lot of nonsenses in this thread (many belifs not much real)
to teh extent i somewhat feel sorry i stated the question - i forgot that quite
usulally people when some wtate soem question not give answer but produce
a stream of nonsenses.. i thought maybe i will learn something on this
rust maybe (this one i cant learn) instead nonsenses on c..but well you may
continue ofc

In article <u8rbk9$lv9$1@dont-email.me>,
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <u8qqpv$3v3pg$1@dont-email.me>,
>> Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
>> ...
>>>> (I don't know Java. Does it really take care of memory management?)
>>>
>>>Yes, it has automatic garbage collection. Those who have started
>>>programming using Java can have considerable difficulties with
>>>manual memory management in C. They are not used to it at all.
>>
>> Much the same could be said about people who start out programming Excel
>> macros. When they start programming in C, they find it very strange that
>> you have to do memory management at all.
>
>You are quite right. The point is that manual memory management
>is an additional burden to the programmer.
>
>Creating serious memory leaks is one of the dangerous possibilities
>when coding in C. That danger can be avoided altogether when writing
>in e.g. Java.

Or, e.g., Excel.

FWIW, I think the modern trend is just to accept memory leaks as a part of
life. Every web browser I've ever used leaks memory like a sieve; they
always need to be periodically re-started.

--
You know politics has really been turned upside down when you have someone in the
government with a last name of Cheney (Liz, Senator from Wyoming) who is the voice of
reason.