☭
Looking at what æscling and Bumby are talking about and thinking "wow, JavaScript is a big mess", but also, that's probably inevitable for anything that has been actively developed for more than 20 years...
I'm sure that there are corners of C that are also a big mess? Not sure what exactly they would be, though...
@vaporeon_ I am not a C expert by any means, but my exploration of C++ has taught me a few things. Header files in C++ have proven to be a headache in a lot of situations, and these are more or less fully inherited from C
Since you pull in everything present in a header file you pollute namespaces which can be a nightmare to manage in large projects
Plus header files induce some code repetition
For reasons I don't understand header files also make it difficult for C++ programs to compile quickly
@wallhackio @vaporeon_ well namepsace pollution is purrevented by #ifndef guards but the compiler still has to read the entire header file, even if the entirety of the content is guarded as therefur won't be inlined because it's being read a second or third or tenth time. now imagine deeply nested include chains repeatedly inlining the same header files over and over again
@wallhackio @vaporeon_ in the early days of go the development team credited their fast compile times to the fact that they had entirely banned importing a dependency twice
@aescling @vaporeon_ in C++ land you avoid this sort of thing with namespaces
In my work's C++ code everything, and I mean everything, was namespaced like nebula::ffph::doAlgo so that there were no namespace collisions
@aescling @vaporeon_ it was a pain in the ass to write and read but this is what industry standard c++ looks like
@aescling @wallhackio Just to make sure I understand you correctly: The preprocessor reads it again, removes all the parts between
#ifndefand#endif, but the pre-processor re-reading the file is still costly enough that a deeply nested chain is slow?