Hacker News Reader

Comment by hn_submit | Hacker News Reader

C is literally "high level assembly" and therefore lacks any guard rails you'd expect in a programming language. It's just unfortunate that so many software developers embraced C for its speed, even when it wasn't strictly needed.

I always remind people that C is a systems programming language and not fit for regular application programming. For that you need an application programming language like Pascal or Java.

View on HN

yea, we certainly wouldn’t want regular user applications to run fast or respect user resources. can’t have that

I, for one, can't see any speed difference between a program written in Pascal (Total Commander, which I use every day) and one written in C++ (Windows Explorer).

File browsers are probably the worst example you could use here. The actual file manipulations are handled by the OS. The rest of it is just displaying lists of files, so no real speed difference would be noticed in different languages/programs. Most of the time the file browser is just sitting there waiting for user interaction.

The programs that do benefit from speed aren't file browsers.

There are a lot of applications like that though, only they're all being rewritten for electron.

It's the only example I could come up with. There aren't that many programs written in Pascal.

You can’t compare apples to elephants here.

You can have that without writing them in C or C++.

you sure can. i recommend forth

Even if that was the tradeoff, your average C/C++ program isn't notably fast or lean.

The C programs I use daily are generally very fast, very lean and very stable: Programs such as linux, terminals, shells, vim, etc.

Most programmers don’t have 30 years to perfect their code

It had no crash during 30 years, not after 30 years.

I did, in Linux. It was pretty common too. It got fix. But, every now and then, I still get an occasional panic.

I also recall having my shell crashing (zsh or bash, I don't remember).

I certainly also remember the kernel crashing, but this was in the 90s. Later perhaps once or twice on faulty hardware. Shell, I don't think I have seen this ever.

In my case, the crashes were from last year to the start of this one. Some were related to AMDGPU, others to my WiFi card driver, so they're pretty recent.

I don't quite remember the details of the shell crash, I only remember it being on a tool that've never seem crash due to a fault signal. It was somewhat amusing.

I’ll take a Qt application over the Electron garbage that we see all the time nowadays.

It could be worse but that's not much of an argument for C in particular. There's a lot of ways to do UI that don't involve web engines.

10-100x develop & maintain cost.

good. browser uis always end up sucking more

false dichtonomy

C should be considered powerful, more than fast. Part of that power is that it doesn't try to stop you from going so fast it's unsafe. But that's just one way you can choose to use your power.

>therefore lacks any guard rails you'd expect in a programming language

This is simply not true. Guardrails are enforced by the compiler, and both gcc and clang have a myriad of flags to make C safe, not to mention Fil-C.

How is it high level assembly? Have you written much assembly recently?

C is very much a "high level/portable assembly" type language still and there's really no sign that it'll change from that. Even if it has ostensibly has abstract semantics, many operations map to 1 or a few assembly instructions and much C code, even when not strictly conforming (as all but the most trivial examples are), is conforming enough that it's portable amongst most relevant targets

For example, I kinda know that the code

    for (size_t i = 0; i < 64; i++) {
        // ...
    }

...will map to something that roughly that, on x86 will (in most cases) probably do a compare and jump, etc, for the loop body, vectorization and some other optimizations notwithstanding. I know a similar thing will happen on PPC, ARM, etc.

This relationship breaks down a bit with a lot of higher level languages where what you want to occur is higher level. This can be both a blessing and a curse; it can enable easier opportunities for optimization but may also may make automatic things downright pessimizied with very very very large effort and expenditure to get things close to usable.

No, you don't know what that code will do. Depending on the inner block, it'll most likely be vectorized. Like I said, it's significantly higher level than assembly.

I don't really agree here. Setting aside the question of how often a compiler can vectorize a loop, because I do think it's not totally relevant here, as you still don't really have the language builtin stuff that other languages do.

You really do have to write the code that iterates over a list and applies a transformation, you can't just do

    [x + y for a.x, a.y in b]

...in C, you have to iterate over the array. And you don't tend to have that much to help you. Most dialects of C don't have exceptions for instance (unless you invent your own). And in general, most of the time, non-trivial loops just... won't autovectorize and it can be a bit finnicky to nudge it in the right direction.

Take, for example, Ghidra. It has a feature to decompile blocks of code into C(++). Other reverse engineering tools follow suit. Even in C, it's very possible to model assembly instructions that don't have a 1-to-1 mapping to a particular language construct as a function call (and this is what these do).

But, there is a reason that, even with all of the architectural differences in the world, whether it be x86, x86-64, PPC, ARM, RISC-V, Xtensa, MIPS, etc, that you can provide a mapping that goes in 1 way (from source to object code) and also the other way (from object code to """source"""). It'd be much more difficult to do that with other languages, especially in an idiomatic fashion.

Reply on news.ycombinator.com