3 ms·
Ask HN: Why do most popular programming languages not have headers?
Header files are great. They let me, as a developer, tell both other developers and the compiler how to use my class in a clean and understandable format. Why do most popular languages not support this?
I'm an Objective-C developer at heart, and perhaps shockingly to most Cocoa novices, header files are the norm. My personal coding style involves only putting things that should be public in the header file, and keeping everything that doesn't have to be public in the implementation file. That includes all ivars, all internal methods (hidden inside a class extension in the implementation file). Headers are for public methods, protocols and public constants, typedefs and enums only.
Unfortunately, I also do quite a lot of coding in PHP, Ruby and even Java, and (especially when building re-usable libraries) find myself wishing for header files. People have gotten around it by inventing PHPDoc, JavaDoc and so on, using @keywords to awkwardly describe and document their code. But it's still a huge pain to figure out how to use a class, when you have to browse through all the implementation to be able to see the method signatures. We've built tools to make it easier for us—but it all seems like inventing a solution to an artificial problems.
Why not just design languages to support headers?
- maushu 15y agoIt's one more file that you have to support and keep in sync with the rest of the code. I absolutely hate header files. If I want to get the high view of a class I just collapse the code to definitions (eg: Alt+0 on notepad++), all decent editors are able to to do this.
- glimcat 15y agoFor one thing, talking to other developers is what comments are for. I tend to dislike header files because it means the information I need to grok a piece of code is squirreled away in more places. This is less a systems problem than the fact that developers often take it as an excuse not to adequately explain what I'm looking at where I'm looking at it. But I'll go with whatever the convention is for what I'm working with.
- pseudonym 15y agoI won't get into the debate of whether headers are required; it feels like something that's more personal preference, like the One True Bracket Placement Method. I will say that when it comes to well-documented code, your constraint is less the language than the people who make the code in the first place. Every non-header language I work with has at least one piece of automatic documentation parser that will grab the comment block directly above the method declaration and turn it into an easily-readable API. (I will note that for me personally, I prefer to keep well-commented and documented code in the one file, instead of needing to do odd window splits or jumping between open files to make sure my method declarations are in sync with my implementations. Header files seem, to me, to fly in the face of idea of not copy-pasting code-- function definitions that have to be modified by hand in multiple places just feel wrong.)
- marssaxman 15y agoWhat you're describing is an accidental feature; so far as I know it only exists in Objective-C, and it exists because of a historical accident. Obj-C inherits the use of header files from C, but its Smalltalk-derived use of dynamic dispatch means that you can call methods whether or not you have seen a declaration. Header files don't exist because someone once decided they were a great linguistic idea; they exist because they were a clever hack for making compile-time type checking work across source files on a machine with less than a megabyte of RAM. Objective-C has had little or no impact on language design. It has been around for over twenty years, but until recently it was just an obscure little branch of the C family tree that never went anywhere. Only after the iPhone took over the world did anyone start to pay attention - but that's because Objective-C is the only way to write iPhone apps, not because everyone suddenly decided the language itself was great. From a language design point of view, there's not much going on to inspire interest. It's an old familiar way of thinking about objects bolted onto an old familiar way of thinking about systems programming, and what's surprising is simply that it works smoothly despite the awkwardness of the marriage. The language design community isn't really interested in that stuff any more; they've moved on and are all about functional programming and algebraic data type theory now.
- dbattaglia 15y agoComing from C++ originally, I actually like header files for code organization, but that is mainly on smaller projects. Once you get to anything substantial I feel like they make life very difficult. Sometimes I feel like you end up literally coding around them just to allow for a circular reference between 2 classes. Its not the end of the world or anything of course but I can see why the world at large has moved away from them. I remember the first time I tried C# and saw the single .cs file per class and module/assembly level includes (via references) rather than header-level includes, it was like a revelation, and life felt so much simpler after!
- chc 15y agoAll languages "support" headers in the sense that you can write up the interface for your code in a separate file from the code itself. There's nothing stopping you from doing this is Ruby — it simply isn't required. Most people don't do this because it wouldn't be useful. The reason headers came into being has nothing to do with providing useful information to humans. Headers exist because the C compiler needs everything to be declared (but not necessarily defined) before it is used. That is the problem that headers solve. They also happen to be kind of handy to glance at and see the interface to some code, but that's just a positive externality. You describe documentation as "inventing a solution to an artificial problem," but it's actually the other way around: Headers are a poor man's documentation. At worst, generated documentation tells you exactly what would be written in a lazily-done header: the names and types of things in the accompanying code. But documentation can also include a lot more detail than that, and often does. Headers can't unless you simply embed your documentation in the header.