3 ms·

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 req

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".

whateveracct 5y ago
> 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.
- visualradio 5y ago
  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) But nothing more, everything else is handled by compiler.
  - whateveracct 5y ago
    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.
    - visualradio 5y ago
      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.
- gspr 5y ago
  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.
  - shawxe 5y ago
    You should take a look at Zig.

whateveracct 5y ago

> 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.

visualradio 5y ago
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) But nothing more, everything else is handled by compiler.
- whateveracct 5y ago
  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.
  - visualradio 5y ago
    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.
gspr 5y ago
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.
- shawxe 5y ago
  You should take a look at Zig.