January 08, 2023
On Sunday, 8 January 2023 at 02:15:27 UTC, areYouSureAboutThat wrote:
> 
> C is not just a programming language anymore. It's a complete (and very diverse) ecosystem.

No progress has been made for decades but that doesn't mean progress is impossible. Maybe the academia will take note that imperative code with goto, void* and static types are nessary and stop making meme language.

The unix stack was fair from prefect and the api of shells and stdin/out should be typed and semi graphical, hot take.
January 08, 2023

On Sunday, 8 January 2023 at 03:18:27 UTC, monkyyy wrote:

>

On Sunday, 8 January 2023 at 02:15:27 UTC, areYouSureAboutThat wrote:

>

C is not just a programming language anymore. It's a complete (and very diverse) ecosystem.

No progress has been made for decades but that doesn't mean progress is impossible.

C has a very large and diverse ecosystem exactly thanks to "no progress". Each and every compatibility breaking change in the language flushes a part of the ecosystem down the toilet.

So the recipe for success is to get most of the things right from the very beginning (this is partly based on skill and partly based on luck). And then try to avoid breaking changes as much as possible. C language is a great example of this.

January 08, 2023

On Sunday, 8 January 2023 at 03:58:43 UTC, Siarhei Siamashka wrote:

>

On Sunday, 8 January 2023 at 03:18:27 UTC, monkyyy wrote:

>

On Sunday, 8 January 2023 at 02:15:27 UTC, areYouSureAboutThat wrote:

>

C is not just a programming language anymore. It's a complete (and very diverse) ecosystem.

No progress has been made for decades but that doesn't mean progress is impossible.

C has a very large and diverse ecosystem exactly thanks to "no progress".

I was referring to all programming languages and computer science

January 08, 2023
On 1/7/2023 2:25 PM, areYouSureAboutThat wrote:
> In fact, C can be used in a perfectly memory safe manner.

Yes, as long as you don't make any mistakes. A table saw won't cut your fingers off if you never make a mistake, too.


> The problem is that too few programmers know how to do that, and even very experienced C programmers can get it wrong sometimes. Both tools and compilers have come along way over the last decade, and it's getting increasingly 'harder' to write memory unsafe C, but in the end, in C, its the programmer that has the control.

Buffer overflows are trivial to have in C, and C has no mechanism to prevent them. Buffer overflows are consistently the #1 security problem with production C code.


> But C will always be the language that gives the programmer the flexibilty and control needed, when all the other languages will not.

There's nothing you can do in C that you cannot express in D, with the same code being generated.

Even bitfields!


> To be 'C like', the language needs to provide the same flexibility and control as C, and map to the hardware and its instructions set as well as C. In other words, it's going to end up being C anyway.

Or DasBetterC!

January 09, 2023

On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:

>

Buffer overflows are trivial to have in C, and C has no mechanism to prevent them.

ASAN, Valgrind, Clang Static Analyzer and plenty of other tools are the practical mechanisms to prevent buffer overflows. Yes, they are not baked into the ISO language standard. But D has no ISO language standard at all.

January 09, 2023

On Monday, 9 January 2023 at 04:31:48 UTC, Siarhei Siamashka wrote:

>

On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:

>

Buffer overflows are trivial to have in C, and C has no mechanism to prevent them.

ASAN, Valgrind, Clang Static Analyzer and plenty of other tools are the practical mechanisms to prevent buffer overflows. Yes, they are not baked into the ISO language standard. But D has no ISO language standard at all.

The best part of memory safe systems programming languages is that many of those tools don't even have to exist, they are part of language semantics!

January 08, 2023
On 1/8/2023 8:31 PM, Siarhei Siamashka wrote:
> On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:
>> Buffer overflows are trivial to have in C, and C has no mechanism to prevent them.
> 
> ASAN, Valgrind, Clang Static Analyzer and plenty of other tools are the practical mechanisms to prevent buffer overflows.

And yet C buffer overflows are consistently the #1 problem in production C code. Valgrind, etc., only detect overflow if there's a test case that causes overflow. That's why it's not as good as static checks.

Clang Static analyzer can only detect a small subset of buffer overflows.


> Yes, they are not baked into the ISO language standard.

They can't be because the C semantics make it impossible.


> But D has no ISO language standard at all.

Neither does Rust.

D can do everything C can. And more. Valgrind works with D code, too.
January 08, 2023
On 1/8/2023 10:34 PM, Paulo Pinto wrote:
> The best part of memory safe systems programming languages is that many of those tools don't even have to exist, they are part of language semantics!

Exactly! I once annoyed the Coverity folks by telling them that my goal with D was to make Coverity irrelevant.
January 09, 2023

On Monday, 9 January 2023 at 06:34:23 UTC, Paulo Pinto wrote:

>

On Monday, 9 January 2023 at 04:31:48 UTC, Siarhei Siamashka

>

ASAN, Valgrind, Clang Static Analyzer and plenty of other tools are the practical mechanisms to prevent buffer overflows. Yes, they are not baked into the ISO language standard. But D has no ISO language standard at all.

The best part of memory safe systems programming languages is that many of those tools don't even have to exist, they are part of language semantics!

Memory safe systems programming language is an oxymoron. To be suitable for systems programming, the language has to provide a mechanism to opt out of safety at least for some parts of the code. These parts of code may have memory safety bugs. The compiler of the safe language itself may have bugs. Valgrind is very useful for troubleshooting D issues and this usefulness won't go away any time soon. Here's one example: https://forum.dlang.org/post/msjrcymphcdquslfgbrn@forum.dlang.org

January 09, 2023
On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:
>
> Yes, as long as you don't make any mistakes. A table saw won't cut your fingers off if you never make a mistake, too.
>

And yet, people keep using them (table saws).

Don't underestimate the level of risk humans are happily willing to accept, in exchange for some personal benefit.