Why I Write Games in C (yes, C) • Hacker News Board

Re: Why I Write Games in C (yes, C)

#301

Post by unnouinceput » Sat, Sep 21, 2019, 11:22 PM UTC

jchw wrote: post #31

unnouinceput wrote: post #14

Quote: "I want to produce less bugs, so I want strict typing, strong warning messages and static code analysis". Yeah, at strict typing you lost me buddy. Let's just go with somebody else reply, as in you like C and that's why you do your hobbies in. Nothing wrong with that in the end.

Implying that typing does not prevent bugs is the strangest programming meme I’ve ever heard, and its proponents push it so hard that I wonder if there’s somewhere I can sign up to be paid for it. We rarely are able to directly compare the cost/benefit of strict typings vs loose typings, but with JS vs TS you get a pretty direct comparison, and it is absolutely unsurprising that TS is eating the JS world; it does pre…

I implied that he chose C for strong typing, which is not. C is weak typing. You want strong typing, you go with Pascal instead for example, that's a strong typing language.

Re: Why I Write Games in C (yes, C)

#302

Post by maxharris » Sat, Sep 21, 2019, 11:24 PM UTC

detaro wrote: post #238

maxharris wrote: post #213

Earlier quoted context omitted.

So I dug some more, and it turns out that while he does have something to say about Rust, I'm not sure I'm convinced by his conclusion about safety: "Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introdu…

how do you know the article by Drew DeVault represents the opinion of the author of the article above? Did he link it somewhere?

D'oh! Different person! whoops! So that really underscores my point, then. The "Why I Write Games in C" guy doesn't mention Rust anywhere!

Re: Why I Write Games in C (yes, C)

#303

Post by inimino » Sat, Sep 21, 2019, 11:24 PM UTC

prewett wrote: post #109

xamuel wrote: post #67

Earlier quoted context omitted.

For a program about classroom-scheduling, it would be nice if you could use "class" as a structure name. Then you could declare a function as taking a "class" as an argument. But if "class" is a reserved keyword in the language, you have to come up with some other name like "_class" or "ClassStruct". I didn't mean to say it's an earth-shattering obstacle. Just one minor additional nitpick to add to the gigantic pile…

The use of "clazz" by Java programmers always seemed like a good solution to me.

Clazzy. Is there a name for this design pattern when the name you wanted was already taken by a language keyword?

Re: Why I Write Games in C (yes, C)

#304

Post by blunte » Sat, Sep 21, 2019, 11:24 PM UTC

This is a surprisingly eloquent essay on the state of modern programming languages (and obviously why the author things that sticking with C is a better choice... and I'm fairly persuaded.)

Re: Why I Write Games in C (yes, C)

#305

Post by rootVIII » Sat, Sep 21, 2019, 11:26 PM UTC

This line is pretty funny: "C++ is still the most common language for writing games, and not without reason. I still do almost all of my contract work in it. I dislike it intensely." hahaha poor guy

Re: Why I Write Games in C (yes, C)

#306

Post by aetherspawn » Sat, Sep 21, 2019, 11:26 PM UTC

GuB-42 wrote: post #278

Skunkleton wrote: post #251

Earlier quoted context omitted.

Its not just pauses either. Non-deterministic memory usage is a big deal too.

I have actually worked on a system where malloc() was forbidden. In fact it always returned null. Buffers were all statically allocated and stack usage was kept to a minimum (it was only a few kB anyways). The software was shipped with a memory map file so you know exactly what each memory address is used for. A lot of test procedures involved reading and writing at specific memory locations. It was for avionics BTW.…

I’d be interested in knowing more if you care to write more about this. I’m currently costing/scoping out what’s required in writing software at that level but don’t really have some real industry insight into what other people do

Static memory is something we already do but we’re pretty interested whether industry actually adopts redundant code paths, monitors, to what extent watchdogs (how many cycles can be missed?), etc.

Re: Why I Write Games in C (yes, C)

#307

Post by hackits » Sat, Sep 21, 2019, 11:27 PM UTC

GuB-42 wrote: post #278

Skunkleton wrote: post #251

Earlier quoted context omitted.

Its not just pauses either. Non-deterministic memory usage is a big deal too.

I have actually worked on a system where malloc() was forbidden. In fact it always returned null. Buffers were all statically allocated and stack usage was kept to a minimum (it was only a few kB anyways). The software was shipped with a memory map file so you know exactly what each memory address is used for. A lot of test procedures involved reading and writing at specific memory locations. It was for avionics BTW.…

Sounds very similar to NASA C programming guidelines. Each module during the initialization period would allocate its static memory size. Every loop had a upper bound's max iteration to prevent infinite loops.

I think they posted the guidelines and it was a wonderful read about how they developed real time systems.

Re: Why I Write Games in C (yes, C)

#308

Post by omaranto » Sat, Sep 21, 2019, 11:30 PM UTC

weberc2 wrote: post #186

majewsky wrote: post #107

Earlier quoted context omitted.

> It is also possible to allocate a large block of memory and then manage it yourself. At which point you're mostly just writing C in Go.

You’re writing in a much improved C. Strong type system (including closures/interfaces/arrays/slices/maps), sane build tooling (including dead simple cross compilation), no null-terminated strings, solid standard library, portability, top notch parallelism/concurrency implementation, memory safety (with far fewer caveats, anyway), etc. Go has it’s own issues and C is still better for many things, but “Go with manuall…

Does Go really let you use closures, arrays, slices and maps when you disable the garbage collector? If so, does that just leak memory?

Re: Why I Write Games in C (yes, C)

#309

Post by blunte » Sat, Sep 21, 2019, 11:31 PM UTC

We see articles not so different from this concept all the time on HN. Recently it's about ORM vs SQL.

The core interfaces are really not terrible at all. They do have danger zones, but their complexities are relatively low. As the author of this article suggests, it's within the realm of something we can remember. That's a BIG deal.

I haven't done C in a very long time. But with C, my recollection is that the biggest issue is to make sure you keep track of your memory allocation and releasing. Sure this is significant, but it's a direct concern. And if you abstract by one level your management of memory, it's a lot easier (especially if you include some testing).

I think it's important to periodically evaluate if our efforts to simplify a situation have actually alleviated or simplified real issues that were hurting us.

Re: Why I Write Games in C (yes, C)

#310

Post by tomxor » Sat, Sep 21, 2019, 11:32 PM UTC

RobertKerans wrote: post #282

tomxor wrote: post #170

Earlier quoted context omitted.

Once I wrote a very small vector library in JS for this very reason: almost all JS vector libraries out there tend to dynamically create new vectors for every vector binary operation, this makes JS GC go nuts. It's also prohibitively expensive to dynamically instantiate typedarray based vectors on the fly, even though they are generally faster to operate on... most people focus on fixing the latter in order to be abl…

You wouldn't have this still up somewhere like GH would you? I'm currently writing a toy ECS implementation and have somewhat similar needs, and I've been trying to build up a reference library of sorts covering novel ways of dealing with these kind of JS issues

No sorry, this is from more than 5 years ago and it was never FOSS, but I only implemented rudimentary operators anyway, you could easily adapt existing libraries or write your own, the above concept is more valuable than any specific implementation details... the core concept being, never implicitly generate objects, e.g operate directly on parameter objects, or re-use them for return value, or return persistent internal objects (potentially dangerously since they will continue to be referenced and used internally).

All of these ideas require more care when using the library though.