3 ms·

The problem may be not headers itself, but that there are so many ways to split the compilation and build artefacts in a project. Java and (Turbo/Free) Pascal

by sqrt17 8y ago

The problem may be not headers itself, but that there are so many ways to split the compilation and build artefacts in a project. Java and (Turbo/Free) Pascal try to have few ways of dividing the materials: Java has class files (and Jar files, and modules), Turbo Pascal has Units. Both involve having a certain namespace correspond to some file the compiler can find and compile, and where you then use the definition from the compiled file. Python and JavaScript/TypeScript have modules as namespaces that correspond to one source file - if you import a symbol from a module "bar/foo", the compiler will look in "bar/foo.js" (or a dozen places in node_modules, or in a dozen eggs), and if foo.js doesn't have that symbol you know something is wrong instead of wondering if there are other files that contribute to that namespace. Lisp and C/C++ have a tradition that goes back far enough that compilation units and namespaces (packages in Common Lisp) are disjoint things. C++ is on the path to making this more complicated with the addition of modules that create another portioning of the compiled stuffs without forcing the others (headers, namespaces, source files) to agree with it. So, headers are not the problem - it's that for a given entity in the source code (namespace, class, function, whatever) it's not automatically clear to the compiler where to look for it. Which effectively leads to the funky ball of dependencies between source files being variously manually specified in (auto-, C-)make files as well as extracted automatically and still being error-prone.

Waterluvian 8y ago
I think you hit on what I've felt about learning Python then trying to learn c++. In python, all code paths are "statically discoverable". Meaning if a symbol exists in a file, I can find where that symbol comes from in that file. And if it's an import, the import tells me where to look for it in another library or relative path. In c++ when I was trying to learn it was a lot of, "okay so why is 'foo' available here?" "Because it's imported by the 'bar' library that you're importing at the top of the header."
- beagle3 8y ago
  > In python, all code paths are "statically discoverable". That's not exactly true. modules can monkey-patch themselves and other modules; they can override the import mechanism to do all sorts of things. It's usually considered bad form, but .. it's possible, and some people like it that way.
  - Waterluvian 8y ago
    Yes you're right. But in the first five years of learning I've never run into that conventionally. Where I have, it was made painfully obvious by comments. Practically speaking, when it comes to learning by reading code, it's invaluable.

by sqrt17 8y ago

Waterluvian 8y ago

I think you hit on what I've felt about learning Python then trying to learn c++. In python, all code paths are "statically discoverable". Meaning if a symbol exists in a file, I can find where that symbol comes from in that file. And if it's an import, the import tells me where to look for it in another library or relative path. In c++ when I was trying to learn it was a lot of, "okay so why is 'foo' available here?" "Because it's imported by the 'bar' library that you're importing at the top of the header."

beagle3 8y ago
> In python, all code paths are "statically discoverable". That's not exactly true. modules can monkey-patch themselves and other modules; they can override the import mechanism to do all sorts of things. It's usually considered bad form, but .. it's possible, and some people like it that way.
- Waterluvian 8y ago
  Yes you're right. But in the first five years of learning I've never run into that conventionally. Where I have, it was made painfully obvious by comments. Practically speaking, when it comes to learning by reading code, it's invaluable.