Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Switching to C over 'Modern' Programming Languages

devtails.xyz

Post reply on HN
Print view View original

81–90 of 170 posts

Re: Switching to C over 'Modern' Programming Languages

#81

Post by jacquesm »

coldtea wrote: post #73
ChrisRR wrote: post #36

Earlier quoted context omitted.

I'm a C programmer by day and I disagree with them, C is only simple if you're trying to do simple tasks with it. The very common thing I want to use in C is some sort of variable size string object. But no, I have to dynamically allocate a buffer that I know will be at least the right size for any text I ever put into it, or do I create a buffer that's the correct size for that string but re-alloc if I ever change i…

> The very common thing I want to use in C is some sort of variable size string object. But no, I have to dynamically allocate a buffer that I know will be at least the right size for any text I ever put into it, or do I create a buffer that's the correct size for that string but re-alloc if I ever change it to a longer string. But then how do I store the buffer size? As a C programmer shouldn't you have a library ab…

It's funny how both C and LISP programmers seem to suffer from NIH to the point that they'll roll their own just for the heck of it rather than to first see if there is a library that they can use.

The long term cost of those decisions as well as the number of really bad bugs (and security issues) that can be traced back to one-off code is likely much larger than the same figure for well used libraries. But it all sort of evens out whenever a bug in such a library is found because then it is so widespread that lots of systems will suffer.

Weird how that works.

Re: Switching to C over 'Modern' Programming Languages

#82

Post by jacquesm »

coldtea wrote: post #69
hnarn wrote: post #16

Is this becoming a thing now (or maybe it was always a thing), where a language, like Rust, has become popular enough that instead of everyone talking about learning it, they now want to talk about how “simple” and “beautiful” C is for no other reason than signaling how different you are from the zeitgeist? Rust exists for a reason, and it solves specific problems. That’s the “magic”, just like any abstraction in any…

> they now want to talk about how “simple” and “beautiful” C is for no other reason than signaling how different you are from the zeitgeist? Given that this has been an argument for 3 decades or so, e.g. compared to C++ especially, I don't think so. Even more so since C is not just some trendy language you pick up quickly, but needs quite a lot of time and effort to be profficcient in, to the point of appreciating it…

I think the main mistake that the Rust people made in their initial promotion of the language was to position it as 'a replacement for C'. No programming language has ever replaced another completely, it always ended up as just another language with its own trade offs and quirks. This even holds within a single language eco system if it isn't managed carefully, Python comes to mind.

Re: Switching to C over 'Modern' Programming Languages

#83

Post by flohofwoe »

jacquesm wrote: post #74
flohofwoe wrote: post #59

Earlier quoted context omitted.

> when everyone was coding assembly.. This was before my time, but I think it's a common misconception (only true for operating system development). When C was created, there was already Lisp, Cobol, Fortran, Algol, Simula, BASIC... and SmallTalk and Prolog were just around the corner - and most of those are much higher level than C).

Sure, but none of those were for systems programming which is squarely the domain that C was aimed at, case in point: the first thing that C was used to write was UNIX (before then it was BCPL and this was iirc before C even had structs which made that a very tricky job, once structs were in place it got a lot easier). Probably Don Hopkins has more knowledge about this.

> before C even had structs which made that a very tricky job...

...interesting that you mention that, I think that functions and structs are the essential 'core abstraction tools' that get you to at least 80% of any higher level abstractions that were invented since then, and this is exactly the reason why C is still quite popular. Its feature set is just enough to be considered a high level language which enables abstractions, but not more (especially no fads and fashions that came and disappeared again).

Re: Switching to C over 'Modern' Programming Languages

#84

Post by Someone »

flohofwoe wrote: post #63
weinzierl wrote: post #44

Earlier quoted context omitted.

"Rust forces me to think a little bit more [..]" My reaction to that has always been that it forces us to think about the things we would have had to think anyways if we wanted to create reasonably reliable and secure software. So in the end if saves work, even if it doesn't appear like that at first.

The other side of the medal (especially for game development), is that in the higher level parts of game code you need quick turnaround times for experimentation and tweaking, and most of that code won't even make it into the final product (so all the upfront time you spent thinking about proper architecture and ownership details is wasted up there). The traditional solution is to have different languages for differe…

> The traditional solution is to have different languages for different code layers

Isn’t the rust solution to wrap Q&D/experimental code in “unsafe {}”? I think that’s superior for the parts where you don’t need the fast iterations of an interpreter.

Re: Switching to C over 'Modern' Programming Languages

#85

Post by flohofwoe »

jacquesm wrote: post #75
ChuckNorris89 wrote: post #38

Earlier quoted context omitted.

>I'm a C programmer by day and I disagree with them, C is only simple if you're trying to do simple tasks with it. C gives you enough rope to shoot yourself in the foot. And rightfully so. It came out in a time when everyone was coding assembly. It's meant not to hold you back from doing voodoo with low-level stuff, therefore it won't hold your hand. Not very practical in the world of today when we've been spoiled by…

> C gives you enough rope to shoot yourself in the foot. If this was intended to illustrate the unexpected consequences of undefined behavior it succeeded remarkably well!

Undefined Behaviour was a very late 'addition' to C, it only became necessary when C was standardised around 1990. And only after two more decades passed, UB became an actual problem when compiler vendors decided that it's fine to exploit it for optimization tricks.

Re: Switching to C over 'Modern' Programming Languages

#86

Post by coldtea »

jacquesm wrote: post #81
coldtea wrote: post #73

Earlier quoted context omitted.

> The very common thing I want to use in C is some sort of variable size string object. But no, I have to dynamically allocate a buffer that I know will be at least the right size for any text I ever put into it, or do I create a buffer that's the correct size for that string but re-alloc if I ever change it to a longer string. But then how do I store the buffer size? As a C programmer shouldn't you have a library ab…

It's funny how both C and LISP programmers seem to suffer from NIH to the point that they'll roll their own just for the heck of it rather than to first see if there is a library that they can use. The long term cost of those decisions as well as the number of really bad bugs (and security issues) that can be traced back to one-off code is likely much larger than the same figure for well used libraries. But it all so…

>It's funny how both C and LISP programmers seem to suffer from NIH to the point that they'll roll their own just for the heck of it rather than to first see if there is a library that they can use.

Well, not sure about the LISP programmers, but C programmers have a good reason: they work under different environments (from embedded to Windows, legacy UNIX, the latest Ubuntu, ...) and also have different needs, regarding allocation, string management, etc. So one-size-fits-all lib might not cut it for everybody. It can also be as simple as having an inherited codebase which uses something else.

Still, there are popular string libraries, and C programmers do use them when they can.

Re: Switching to C over 'Modern' Programming Languages

#87

Post by kaba0 »

flohofwoe wrote: post #21
shrimp_emoji wrote: post #4

Earlier quoted context omitted.

Yep. You think C is "low level", but it was once considered "high level", and the compiler does many things you don't want, and the standard's ambiguously-worded, and implementers have their own interpretations about the ambiguity, and also bugs in their compilers, and you eventually arrive at: "If you really want those instructions to happen in this function, without fear of magic, write them in assembly."

> but it was once considered "high level" C's position in the "low- vs high-level" hierarchy arguable hasn't changed much since it was created. There were already higher level languages in the 60's (e.g. languages which abstracted the underlying hardware much more than C, but those weren't useful for writing an operating system in).

From what I have seen, there are two “contending” definitions for what is high-low level languages: one considers anything above assembly languages high-level, the other is less concrete, and would put for example managed languages into the high level category/towards that end of the spectrum, while C, Rust, C++ would be on the lower end, assembly even lower.

I prefer the latter definition, as the former is, while objective, quite useless. The second definition could be expanded by a partial order between languages by “feature X can be emulated in it” with some caveats[1], and then we might even get Rust/C++ beat C for low-levelness, since C don’t have any way to force vectorization (compiler-specific intrinsics don’t count!).

[1] since most languages employ FFI/linking, not even this definition is too specific — would probably have to write it as the “idiomatic language can emulate feature”

Re: Switching to C over 'Modern' Programming Languages

#88

Post by flohofwoe »

Someone wrote: post #84
flohofwoe wrote: post #63

Earlier quoted context omitted.

The other side of the medal (especially for game development), is that in the higher level parts of game code you need quick turnaround times for experimentation and tweaking, and most of that code won't even make it into the final product (so all the upfront time you spent thinking about proper architecture and ownership details is wasted up there). The traditional solution is to have different languages for differe…

> The traditional solution is to have different languages for different code layers Isn’t the rust solution to wrap Q&D/experimental code in “unsafe {}”? I think that’s superior for the parts where you don’t need the fast iterations of an interpreter.

Not sure, I haven't tried Rust for gamedev stuff. But I think unsafe{} is still very picky. It just removes some borrow checker restrictions, but still requires a lot of 'correctness', and I guess it also doesn't magically improve compilation time.

One other 'modern' solution is to use a compiled language for the whole 'stack', but with a hot code reload solution, so you can change the code on the running game - which also tremendously reduces turnaround times.

Re: Switching to C over 'Modern' Programming Languages

#89

Post by kaba0 »

coldtea wrote: post #86
jacquesm wrote: post #81

Earlier quoted context omitted.

It's funny how both C and LISP programmers seem to suffer from NIH to the point that they'll roll their own just for the heck of it rather than to first see if there is a library that they can use. The long term cost of those decisions as well as the number of really bad bugs (and security issues) that can be traced back to one-off code is likely much larger than the same figure for well used libraries. But it all so…

> It's funny how both C and LISP programmers seem to suffer from NIH to the point that they'll roll their own just for the heck of it rather than to first see if there is a library that they can use. Well, not sure about the LISP programmers, but C programmers have a good reason: they work under different environments (from embedded to Windows, legacy UNIX, the latest Ubuntu, ...) and also have different needs, regar…

What exactly is a problem with C++’s strings, or especially Rust’s? Everything you mentioned can be controlled as explicitly as you want.

The only problem is C is simply not expressive enough to have proper abstractions like that.

Re: Switching to C over 'Modern' Programming Languages

#90

Post by camgunz »

flohofwoe wrote: post #32
hnarn wrote: post #16

Is this becoming a thing now (or maybe it was always a thing), where a language, like Rust, has become popular enough that instead of everyone talking about learning it, they now want to talk about how “simple” and “beautiful” C is for no other reason than signaling how different you are from the zeitgeist? Rust exists for a reason, and it solves specific problems. That’s the “magic”, just like any abstraction in any…

I'm a programmer since the early 90's, but I have seen this problem only ever with Rust so far (where people are eager to learn something new, pick Rust, and then quickly get jaded - case in point, that's also me - I learned enough Rust to write a home computer emulator but in the process realised that it is not the right language for me, even though it should be from its feature set). It feels a bit like a speed run…

> It feels a bit like a speed run of C++

I've felt that way too, and it's been enough to push me away even as I've tried to build things in Rust in earnest. Along the same lines, I've found it hard to say exactly why I like C and super dislike C++. I guess I have to say it's simplicity--like I won't argue C is by itself simple (integer promotion by itself is not simple) but it's definitely simpler than C++, and the simplicity and power of its core conceit (everything is a number) is just enrapturing. I think it's just an ethos thing: Rust doesn't strive to be simple and I find that makes it impossible for it to delight me.

I also think that's broadly why newer languages have failed to capture the je ne sais quoi of C: you really can't get away with "everything is a number" these days.

Post reply on HN