Re:Show HN: I wrote my own RTS game engine in C
by visualradio on Wednesday May 12, 2021 @04:13PM
(#27134587)
If a project requires an open API like OpenGL, SDL, Vulkan which is documented and defined using ANSI C or C99 language constructs, then some amount of C is required regardless of the merits of the language. With high level language with large community maybe someone writes and maintains wrapper, library, or FFI binding for you but this relies on economy of scale and out-sourcing work. If a programmer doesn't understand a C API then writing a binding to a function they don't understand in order to test it is a point of friction which encourages returning to plain C. Ideally more of the "Better C" languages would retain ability to parse and compile vanilla C header files without manual binding. Zig attempts this but reduces the cognitive simplicity of the language by using structs as namespaces for holding local function definitions rather than as "plain old data".
[ Parent
| on HN ]
Re:Show HN: I wrote my own RTS game engine in C
by whateveracct on Wednesday May 12, 2021 @04:49PM
(#27135004)
> Ideally more of the "Better C" languages would retain ability to parse and compile vanilla C header files without manual binding.
I've been doing a lot of zero-copy FFI work in Haskell. It became quite mechanical to create 100% literal bindings to C libs (Pointers and all), and it's nice to use it directly in Haskell as-is. I'm hoping I can write a simple tool to do exactly what you describe.
Re:Show HN: I wrote my own RTS game engine in C
by gspr on Thursday May 13, 2021 @07:41AM
(#27140981)
Indeed. For a language that strives to be as different as Haskell does, the FFI experience is absolutely stellar. The only other language I've seen come close in terms of C interoperability is perhaps Rust.
Re:Show HN: I wrote my own RTS game engine in C
by shawxe on Thursday May 13, 2021 @11:01AM
(#27142848)
You should take a look at Zig.
Re:Show HN: I wrote my own RTS game engine in C
by visualradio on Wednesday May 12, 2021 @06:00PM
(#27135674)
For programmers which need to consume C APIs ideally the tool is the standard compiler. Eeverything gets handled at compile time without the need for community-maintained cache of bindings. New language designers start with a C compiler which handles header files, then extend compiler to also parse NewLang files. The in-memory representation is loaded from both source types, without throwing away the C functionality. In NewLang there is some standard namespace and calling convention.
@importc "stdio.h"
num : I32 : 123456789
fd : c:int : c:open(c:"file.txt", c:O_RDONLY)
:: c:print("file:%d number:%d\n", fd, num)
Re:Show HN: I wrote my own RTS game engine in C
by whateveracct on Wednesday May 12, 2021 @06:04PM
(#27135716)
For a "Better C" language, that would be wonderful.
For my Haskell ideas, generating Haskell from headers automatically feels like the best route. Especially if it's configurable to some degree. It's common that you can better type a C API with Haskell than C ever could. Usually with techniques like IO, phantom types, GADTs, and the new linear types.
Re:Show HN: I wrote my own RTS game engine in C
by visualradio on Wednesday May 12, 2021 @06:24PM
(#27135898)
The chicken-and-egg problem is where programmers don't know how the C API works well enough to provide function-specific type annotation or library-specific configuration settings, but want to try calling the API anyway because they are following a tutorial written in C or C++. In this situation if there is no "dumb" binding mode builtin to the language the programmer is likely to abandon the language and go back to writing C or C++ until they get the IO working and something displayed on screen.