• @INeedMana
    link
    29 months ago

    If I write my whole application/library in C, user interaction is part of the application nonetheless

    That’s my point. Human facing interface needs a lot of code that does not really do much, only needs to be there to cover all the edge cases of mixed parameters, cancel buttons, trying to click “next” without filling important textbox… And writing all this in C (I mean the actual user-end program interface, not the general GUI library, like GTK for example) only makes it worse to debug and maintain. You most often don’t get any gain from manual memory management. If an operation is taking too long maybe it’s time to put it inside the backend library. But if you’re optimizing that operation you’ve already moved away from comparing strings inside - it’s the first one to go when a loop takes too long. And once we are speaking about more than one program that we want to have consistent behavior across that might need to change in the future - C is only slowing you down.
    Do you really need to reference the “Cancel” button via pointer when checking if the user should be allowed to go back?

    Write a general backend library for your important stuff and optimizations in C, so you can easily load it in other languages. And then use something higher level for the interpreter/GUI where sanitizing user input is 5 lines of different libraries from the language (I mean like re or zip in Python - these are not external, these are Python’s STL), instead of 50 lines of juggling pointers, which in C you would be doing even if the input was all ints.

    You don’t care about stack height and jumping to previous frame after being in a procedure (assembler level of looking at the code) - that’s what C does for you
    So why care about the pointers and structs when resizing a GUI? - Let some higher level language manage that for you