Comment by jakobnissen a day ago
There is a cost to writing documentation - it takes time, which could be used to improve Zig in other areas. For code that is work-in-progress, it can make sense to not document until things are more settled.
Of course documentation is good. But if you have to prioritize either a new feature, or a critical bugfix, or documentation, you often can't have it all
This really struck a chord with me. Writing documentation is an act of explaining something to others. Explaining something to others is a great way to test your own understanding. If it's hard to explain to someone else, then maybe it's the wrong design.
If you don't through that exercise, you're much more likely to build confusing, difficult-to-use APIs.
> you're much more likely to build confusing, difficult-to-use APIs.
have not found this to be the case with zig in general. you could easily make the opposite argument, that documenting things (especially quirks) can give you license to build confusing APIs.
I think some documentation and a handful of examples would have helped the author of the article. How is the experience when porting to the new standard library improved by not including documentation?
On the other hand, not writing documentation also has a cost.
Code is rarely written from start to finish in a single session. Would you rather spend 5 minutes before you do a git commit to write down some very basic documentation, or spend an hour rediscovering it when you pick up development two weeks later?
Nobody is expecting extensive and well-polished documentation here, but is a "Flags X, Y, and Z are mandatory, buffer A is required: I tested with 10MB, smaller might be fine too" really too much to ask for?
Is the time you saved by not writing that one line worth someone else spending several hours figuring out how to do a "hello world"?
This is a good point, but one could make a point for the usefulness of documentation in “thinking like a user” which is a valuable exercise.
I do very much prefer moving fast though, so I get it, docs-later is obviously a very valid way of doing things.
If someone is excited about Zig and wanted to make a difference I guess it’s now obvious where they could have outsized impact!
Then they should not have relead the new api at all. Why release half finnished library.
Breaking changes and limited support is one thing. But docs is not something you add at at the end. Lacking docs and Lacking tests is code that should not be released.
They target embedded c market. Limited support and features is expected and common. But being lax with docs and testing is not acceptable.
> But being lax with docs and testing is not acceptable.
First: Those two things are not the same. The Zig stdlib and compiler have tons of tests, and it's actually quite rare to stumble over implementation bugs.
Second: I'd rather take no docs at all than per-function or per-type doc-headers which just repeat what the code does in natural language (and then may quickly get stale). Some parent wrote about generating docs with an LLM which is just a laughably bad idea, since even with perfect results you'll just get a redundant reiteration of what the code below does, just in imprecise human language, it would literally just be redundant noise.
Documentation mostly makes sense up on the systems level to explain high level concepts, not as 'this function does this and that...' level, this information already exists in much more precise form in the source code below the doc header.
But this sort of high level documentation doesn't make sense as long as a project is in the experimentation phase, and Zig is still one big experiment.
I fundamentally disagree on code readability. A comment on the function header can save an hour of code reverse engineering for a complex library. Reading code is a last resort, and stale code docs is itself a red flag.
This post itself is a great example. The code is not self explanatory unless you understand the library below. So if this was library code; you would have to reverse through two abstraktion walls to understand it.
And as for high level documentation... it would be very helpful to have that DURING the development process to discuss the implementation, and quickly get people up-to-speed in the plan during code review. Id write that before the code.
I mention tests, because they are 10x more work to write than docs. So if the developer skips out on docs, my trust in their testing is also destroyed.
Because the language is not stable at this point and hasn't reached 1.0?
Are you saying one should never make anything half finished available to the public? This post proves why it is valuable to do so, they are getting valuable feedback and a discussion on hacker news for free.
There's an alternative of being much more up front about the status. For example the project page doesn't really say it's unstable/experimental. It only says "Zig has not yet reached v1.0" on the "getting started" page, which doesn't really mean that much - for example Putty is still at 0.83 after 26 years.
If the project invites me to use it "for maintaining robust, optimal and reusable software." without putting "super unstable, we don't even care about docs" on the same page... that's also saying something.
AIUI the team has a geberal consensus on what is left tp do before 1.0, there's even a tracking list of requirements on the github.
if you have that attitude about docs, then likely you are being gatekept from the project until it hits 1.0.
I tend to actually disagree with this attitude, because I see writing documentation as really effective "rubber-ducking". If it's hard and time-consuming to properly document, it's probably hard to use, so extra effort should be spent to actually justify the design, not least to yourself in 6 months. If you can't justify it, it's probably wrong.