Live data from Hacker News

Why I Write Games in C

jonathanwhiting.com

171–180 of 303 posts

Re: Why I Write Games in C

#171

What about Rust?

Maybe in ten years. Great thing about old mature technology such as C is that all gotchas have been tripped over innumerable times and are all well known and codified. Meanwhile new exciting technology like Rust contains unknown number of bugs like http://www.wabbo.org/blog/2014/22aug_on_bananas.html , undiscovered antipatterns and subtleties. My comment is not meant to bash Rust, on the contrary it is very promising…

That bug was almost a year before Rust 1.0 was released. At this point, Rust is being used in production outside of Servo- for example Dropbox is even using it for their core data storage code.

It's certainly not as old-and-boring stable as C, but it's a lot closer than you'd think.

Re: Why I Write Games in C

#172
post #155
post #149

Earlier quoted context omitted.

Yeah, and what's left is not much of C++. See my post about runtime recompiling for arguments to use C compiler instead of a very limited subset of C++. (References make the type system more complex for little benefit. Templates create massive amounts of complexity and slow down my iteration loop. Already explained what's wrong with std::vector and std::unordered_map.)

- Compile times with templates are on my system under 10 seconds. - I missed your vector and unordered_map discussion. - "more complex" is not a useful metric to compare the language systems. Similar, I can easily say, that C pointer arithmetic is creates more complex situations when verifying that code is safe to use.

Compile times are not a problem in small codebases. Try to compile a 100kloc codebase using templates generously. Even your link times will easily grow over 10 seconds. Maybe even a minute. And 100kloc is still a pretty small codebase in terms of AAA development.

It's true that complexity somewhat depends on the context. Complexity of a language is a useful metric when talking about mental overhead of the programmer (which translates to productivity), and when writing custom tools for the language, both of which are relevant when developing a game engine. Safety has traditionally been a quite small priority in gamedev. I assumed this was the context.

Re: Why I Write Games in C

#173
Flash is not dead. It's the ONLY plugin left that works in all desktop browsers, and works on Mobile phone. Facebook supports it, more and more who have started in HTML5 have lived to regret the day. For many years I was a C++ snob who totally dismissed Flash, but now I really enjoy actionscript

I am working with a client who is write a phone app in Flash because of the low level cross platform abilities and it is awesome! It also lets me build web based admin tools for the backend really quickly. Only negative thing I can say about it is the garbage collection is slow...

Re: Why I Write Games in C

#174
post #65

Well into C++14, but yet this outdated myth of an unbearable "complexity". This is not the language you knew.

C++11 and 14 make it possible to avoid or ignore much of the complexity of old-style C++, but they also introduce plenty of complexity of their own and they don't deprecate any of the old stuff. It's not a myth.

Re: Why I Write Games in C

#175
post #23

If by "strict typing" you mean strongly typed then you are factually incorrect. By virtue of casting C is weakly typed, as is Java, C++ et al. If your understanding of strict typing is statically typed, i.e. that types are checked at compile time then C still has some flaws as you could write a whole slew of C that is "typeless" using void * although that would be terribly misguided. I understand your intent, but I d…

> By virtue of casting C is weakly typed, as is Java, C++ et al. Java's casts are dynamically checked, memory-safe and only work through the inheritance hierarchy, if you try to cast to an invalid type you'll get an error. Putting it in the same class as a C-style cast makes your usage of "weakly typed" as meaningless as it ever is. For C++ — ignoring C-style casts — it depends which cast you use, dynamic_cast requir…

There's also a valid distinction to be made between weak typing through implicit conversions and weak typing through reinterpret_cast. C++ has both unfortunately, but the second one is often necessary for a low-level language.

Re: Why I Write Games in C

#176
post #75
post #66

How about Nim? [1] [2] To me it is in many ways a "nicer and safer C". Sure it's not as mature as C, but what is? What it does have going for it is portability (it compiles to C so it shares C's portability), a soft real-time GC which can be manually controlled [3], generics, AST macros and much more. 1: http://nim-lang.org 2: https://github.com/nim-lang/nim 3: http://nim-lang.org/docs/gc.html#realtime-support

I can't speak for the article writer of course, but the Python-like syntax / significant indentation would be a deal-breaker for me. I'd suffer through a lot to avoid that. And back when I used C a lot myself, I found that even more objectionable. I often care more about syntax than many other language features - with a good syntax you can sugar over a lot of other deficiencies, but a syntax you dislike will stare yo…

If I ever invent a language for anything more than personal use, I swear I'll provide several syntaxes, and an automatic translator. To each his own? FINE!

(I'll also shoot whoever tells me having several syntaxes is a deal breaker.)

Re: Why I Write Games in C

#177
post #100

Earlier quoted context omitted.

Sure, although I don't have a separate server. Explanation here: http://pastebin.com/Nm6Qta4u

Very interesting approach, and pretty straight-forward as you said. Thanks for sharing that. Have you considered letting the compiler produce DWARF-formatted debug information and using an existing DWARF library to handle the symbol to address mapping? I've had good success with this method for controlling embedded systems from a desktop PC, though not when the host and target are the same computer.

I started thinking about it, but quite fast decided to roll my own self-contained system. Not because it was an informed decision, but felt more fun :P

Re: Why I Write Games in C

#178

Flash is not dead. It's the ONLY plugin left that works in all desktop browsers, and works on Mobile phone. Facebook supports it, more and more who have started in HTML5 have lived to regret the day. For many years I was a C++ snob who totally dismissed Flash, but now I really enjoy actionscript I am working with a client who is write a phone app in Flash because of the low level cross platform abilities and it is aw…

Flash doesn't work in most installations of desktop Safari, nor does it work on iPhones. Many others are fleeing it because of massive ongoing security problems with it. If you're content with the audience that remains then great, but it's far from "all."

Re: Why I Write Games in C

#179
C is super slow when it comes to compiling, if you really want fast compiling take a look at Pascal, around 10 times faster the last time I checked. There is Free Pascal that is open source and also has a great IDE called Lazarus. Both much better as a language compared to C and C++ and still close to their speed.

Re: Why I Write Games in C

#180
post #75

Earlier quoted context omitted.

I can't speak for the article writer of course, but the Python-like syntax / significant indentation would be a deal-breaker for me. I'd suffer through a lot to avoid that. And back when I used C a lot myself, I found that even more objectionable. I often care more about syntax than many other language features - with a good syntax you can sugar over a lot of other deficiencies, but a syntax you dislike will stare yo…

If I ever invent a language for anything more than personal use, I swear I'll provide several syntaxes, and an automatic translator. To each his own? FINE! (I'll also shoot whoever tells me having several syntaxes is a deal breaker.)

hehe. It's funny, Nim's creator had a plan to do that actually.
Post reply on HN