Switching to C over 'Modern' Programming Languages • Hacker News Board

Re: Switching to C over 'Modern' Programming Languages

#101

Post by Brian_K_White » Thu, Apr 13, 2023, 12:49 PM UTC

flohofwoe wrote: post #56

KyeRussell wrote: post #49

Earlier quoted context omitted.

It’s pretty reasonable to argue that were these things written again, less than 100% of it would be in C[++]. It’d also pretty reasonable to argue that that percentage will be even smaller 5 years from now.

Sure, but that's a theoretical scenario, because this type of applications won't be written anymore. Anything that's relevant in those areas had been started in the early to mid 90's (even the 'newcomer' Blender had been released first in 1995).

You accuse "theoretical scenario" and then make the most ridiculous unfounded assertion yourself.

Re: Switching to C over 'Modern' Programming Languages

#102

Post by Brian_K_White » Thu, Apr 13, 2023, 12:56 PM UTC

Fell wrote: post #51

I used to love C for its simplicity. There was just no surprises, and the limited feature set enforced a certain programming style that also happens to run very well on modern CPUs. But the C standard library is just awful. It's so inconsistent and full of quirks you just have to know. Like how some string functions allow you to specify a size, while others don't. And how strtok keeps track of an internal state and b…

It is as much the case that modern cpus have been designed to facilitate c semantics. C was designed for the cpu initially, but a lot of generations have happened since then, and there have been attempts to try other things, and by now the cpu is designed for c to run well on it.

Re: Switching to C over 'Modern' Programming Languages

#103

Post by Brian_K_White » Thu, Apr 13, 2023, 1:00 PM UTC

throwawaymaths wrote: post #6

GianFabien wrote: post #3

Other than assembly language, all languages embody abstractions. I find understanding certain abstractions hard going because they don't mesh well with my view of the problem domain and my design for solution's implementation.

This is silly. Assembly is an abstraction too. Do you think the CPU actually runs the code you give it? Of course not. There's microcode, register aliasing, speculative execution, etc. Even assembly itself has symbols and labels, which are themselves abstractions.

Assembly is about as much abstraction as rot13 is encryption.

Re: Switching to C over 'Modern' Programming Languages

#104

Post by tialaramex » Thu, Apr 13, 2023, 1:03 PM UTC

tourmalinetaco wrote: post #98

kaba0 wrote: post #94

Earlier quoted context omitted.

Like what? C++ and Rust can do everything C can.

They literally cannot. For one, neither C++ or Rust conform to standard C, meaning they already deviate from what C does on a basic level. Their industry uses are highly different as well. C is almost a requirement for embedded systems, and while C++/Rust can be used there, they’re simply too complex and in Rust’s case additionally too young to be adopted. C++, and possibly Rust (if it can get its act together), are…

Linux isn't written in standard C. Not only does it not accept C's aliasing rules (hence the kernel is compiled with them disabled, which the standard doesn't offer), it doesn't even accept the memory model, because it had its own memory model first and it likes that one better.

As a result to some extent GCC and Clang are also compilers for some sort of "Linux C" which is strongly reminiscent of the ISO standard language but distinct.

And there's no reason you would choose C++ for a project where you'd otherwise use C on account of the (exaggerated) relationship between the two languages, the reason you'd do it would be that you want C++ features, and Linus doesn't want C++ features. Projects to "just" compile the existing Linux code but with C++ compilers failed AFAIK.

Re: Switching to C over 'Modern' Programming Languages

#105

Post by flohofwoe » Thu, Apr 13, 2023, 1:06 PM UTC

Brian_K_White wrote: post #101

flohofwoe wrote: post #56

Earlier quoted context omitted.

Sure, but that's a theoretical scenario, because this type of applications won't be written anymore. Anything that's relevant in those areas had been started in the early to mid 90's (even the 'newcomer' Blender had been released first in 1995).

You accuse "theoretical scenario" and then make the most ridiculous unfounded assertion yourself.

> unfounded assertion

...which unfounded assertion would that be? As far as I'm aware there are no contenders which would even attempt to throw tools like Maya, 3DSMax, Blender, ... from their throne. And all those tools hail from the 90's.

The only exception in recent time which gained some traction might be Figma for 2D design, but even though it runs in browsers the important parts are also written in C++.

Re: Switching to C over 'Modern' Programming Languages

#106

Post by Brian_K_White » Thu, Apr 13, 2023, 1:11 PM UTC

chongli wrote: post #66

jacquesm wrote: post #15

Earlier quoted context omitted.

Did you really not understand the point the GP was trying to make or is this an attempt to be clever? Of course assembly is an abstraction, but it is the lowest level programming language that ordinary mortals can still write code in, which was the point the GP was making. Exactly nobody writes applications in microcode. Register aliasing and speculative execution have under normal circumstances no effect other than…

If you’re trying to understand the behaviour of the computer then all of the layers of abstraction matter, right down to the logic gates. Spectre and Meltdown proved that software developers can’t just “trust the CPU to do the right thing.” Besides the issue of security, performance is also a thing. If you’re trying to squeeze every last cycle out of your program then you need to understand CPU cache hierarchies at t…

Child, assemler mnemonic representations of opcodes are not hiding anything.

You could make the same, useless, argument about the raw binary. If you looked at an executable you are still actually only looking at a transcoded representation in ascii in an editor. The cpu doesn't actually know what 0A is, those are glyphs for numbers and letters in a human language.

Assembler mnemonics are not materially different, and even macros don't change this because the macros are macros, built out of other visible assembler not hidden magic.

You are not conducting useful argument or communication with this silliness.

Re: Switching to C over 'Modern' Programming Languages

#107

Post by kaba0 » Thu, Apr 13, 2023, 1:11 PM UTC

tourmalinetaco wrote: post #98

kaba0 wrote: post #94

Earlier quoted context omitted.

Like what? C++ and Rust can do everything C can.

They literally cannot. For one, neither C++ or Rust conform to standard C, meaning they already deviate from what C does on a basic level. Their industry uses are highly different as well. C is almost a requirement for embedded systems, and while C++/Rust can be used there, they’re simply too complex and in Rust’s case additionally too young to be adopted. C++, and possibly Rust (if it can get its act together), are…

So your answer is “because they are not C”…?

What does language complexity has to do with anything? It will get compiled down to machine code, and both can be and are used for embedded. They occupy the exact same low-level niche as C, hell, they may be even more level as they can also do things like SIMD.

Linux kernel is C because Linus doesn’t like C++, it’s that easy. And usually no, why would you use multiple languages in a project if you don’t have a good reason?

Re: Switching to C over 'Modern' Programming Languages

#108

Post by Brian_K_White » Thu, Apr 13, 2023, 1:19 PM UTC

Dylan16807 wrote: post #65

mprovost wrote: post #53

Earlier quoted context omitted.

Meltdown/Spectre pulled back the curtain and revealed just how much magic is going on with modern CPUs.

But it only really manifests as timing.

This.

The cpu magic doesn't do things you didn't ask for, or can't figure out how to ask for through a bunch of indirection.

All the cpu magic means is that you don't know how it did exactly what you expected. It still produced exactly and only the expected output from the given input.

High level language magic means it does things you didn't expect, and that you can have a hard time figuring out how to get it to do something you want if that doesn't happen to be one of the things the language designers predicted and decided for you that you should ever need to do.

Re: Switching to C over 'Modern' Programming Languages

#109

Post by Brian_K_White » Thu, Apr 13, 2023, 1:31 PM UTC

tsimionescu wrote: post #8

GianFabien wrote: post #3

Other than assembly language, all languages embody abstractions. I find understanding certain abstractions hard going because they don't mesh well with my view of the problem domain and my design for solution's implementation.

Actually, x86 assembly also embodies plenty of abstractions. Not sure on ARM or RISC-V, but x86 assembly instructions are not executed the way you'd think by any modern processor. Essentially the processor reads a while bunch of instructions at once, splits each in the raw microinstructions, arranges them in a graph of dependencies, and then solves an optimization problem to find the best way to schedule nodes from t…

Scheduling and implementation are irrelevant to the complaint being made about high level languages.

No matter what the cpu does internally to arrive at producing the requested output from the supplied instructions, it DOES produce exactly the reqested and expected output from the given instructions.

What it does not do is for example maybe a + operator doesn't mean the same thing after some unknowable prior step changed the definition of +, or flatly not provide a means to manipulate some data in a way that a language author thought was crazy and no one could ever have a valid reason to do $thing like idk execute a string or something. Sure there are now optional settings and features you could consciously use, for example to enforce that data/exec seperation, but it doesn't just do it by it's own magic according to someone else's rules instead of your own code.

Re: Switching to C over 'Modern' Programming Languages

#110

Post by Brian_K_White » Thu, Apr 13, 2023, 1:38 PM UTC

flohofwoe wrote: post #100

Brian_K_White wrote: post #97

Earlier quoted context omitted.

Don't games work by an engine which doesn't have a lot of rando changing user facing features, that could be rust. And the engine provides a dsl that is the high level user facing rapid change thing?

Yeah, Rust may be a good choice for a game engine, but at the same time not a good choice for the actual game code.

To counter myself, I could also easily imagine that game engines are also full of dirty hacks to get things that the front end people want done, now, by hook or by crook. Ie, if a nice sane interface doesn't exist, and woukd take more than 11 minutes to add the right way, then just butcher in any kind of tight coupling and to hell with worrying about it breaking for the next game.