I gave myself the rule of no internet while on the train, so sometimes I would just accumulate a list of questions I wanted to answer later.

There is definitely something to it, and you can get heaps done, but it needs to be supported with some non-train time (e.g. for me, it was all the app store stuff, debugging with real hardware, etc)

More to the letter of the question, I use "cd -" frequently, "ps -e | grep some_process_i_would_like_the_pid_for", and while I don't use it frequently, I didn't know about "ssh-copy-id" for a long time, and would do it manually with a text editor in the past. Sorry if they are not sufficiently fancy - but for things to get used day to day for me, they will need to be short and sweet.

I watched this video a week or so ago, and a few more on the channel because they were promising to answer other interesting questions (interesting for me at least).

However, it seemed like there was something off with all the content. The best explanation I have for it is that it is AI generated scripts (I recall a real lack of coherence in the video about which side you put the fuel door on a car), so I just stopped watching.

I'd be curious if anyone else has a similar feeling or a better way of expressing it, because I am not feeling very eloquent here.

SDL2 has input stuff built in, so that is easy.

I didn't need networking for my game, so I didn't have it, but networking is not particularly difficult to do cross platform (I'm assuming iOS lets you just use the "normal" sockets API?)

I also used SDL2 for the sound stuff, which was mostly playing back prerecorded things, but also a little bit of stuff synthesized on the fly.

I think I had one objective C file in there for calling a library function I needed, but otherwise I just wrote C code.

I am not making things up when I say that the very first question I had about how to use this module, either is not answered, or I couldn't find the answer. That question was "what regular expression syntax is supported?". This is such a fundamental question, yet there is no answer provided.

As a preference thing, I don't really like examples in APIs (it is supposed to be a reference in my opinion) and I find them to be mostly noise.

> Why would I want to edit the documentation of an external library I'm consuming when I'm reading it? And even if I do then the effort to make a PR changing those docs pales in comparison to the effort it takes to open the original source code with the docs and edit it.

Right, this is possibly where our experiences differ. I'm frequently pulling in loads of code, some of which I've written, some of which other people have written, and when I pull in code to a project I take ownership of it. Doesn't matter who wrote it - if it is in my project, then I'm going to make sure it is up to the standards I expect. A lot of the time, the code is stuff I've written anyway, which means that when I come back in a few months time and go to use it, I find that things that seemed obvious at the time might not be so obvious, and a simple comment can completely fix it. Sometimes it is a comment and a code change ("wouldn't it be nice if this function handled edge case X nicely? I'll just go in there and fix it").

The distinction between external and internal that you have looks pretty different to me, and that could just be why we have different opinions.

In this specific case, your tool requires a web browser (though I'm assuming that there is a non-web browser form of what is being sold here). Maybe you are in a situation where you only have terminal access to the machine.

Maybe you are on your phone just browsing github looking for a library to use

I'm sure people can continue to imagine more examples. It is entirely possible that we have different experiences of projects and teams.

It is one of those things that sounds "obviously true", but in practice I've found that it doesn't really live up to the promise. As a concrete example of this, having a plain text header file as documentation tends to mean that when people are reading it, if they spot a mistake or see that something isn't documented that should be documented, they are much more likely to fix it than if the documentation is displayed in a "prettier" form like HTML.

The problem with header files that aren't "well-written" tends to be that the actual content you are looking for isn't in there, and no amount of language tooling can actually fix that (and can be an impediment towards fixing it).

Let the header files be written for people to read first, and only if there is actually a big performance issue, and the problem is the interface do you need to revisit it (and I'm not just saying this - I will frequently and happily go back and modify interfaces to allow for less data movement etc, but most of the time it really isn't important).

I think you are probably right to disagree with me though - I think I should have said that it is more of a limitation on how object files work, rather than how machines work. Object files aren't the only way things can work.

I used to be a big fan of doxygen etc, but for the stuff I've worked on, I've found that "pretty" documentation is way less important than "useful" documentation, and that the reformatting done by these tools tends to lead towards worse documentation with the people I have worked with ("Oh, I need to make sure every function argument has documentation, so I will just reword the name of the argument"). Since moving away from doxygen I have stopped seeing this behaviour from people - I haven't tried to get a really good explanation as to why, but the quality of documentation has definitely improved, and my (unproven) theory is that keeping the presentation as plain as possible means that the focus turns to the content.

I don't know if rust doc suffers the same issues, but the tooling you are mentioning just seems to add an extra step (depending on how you count steps I suppose, you could perhaps say it is the same number of steps...) and provide no obvious benefit to me (and it does provide the obvious downside that it is harder to edit documentation when you are reading it in the form you are suggesting).

But with all these things, different projects and teams and problem domains will probably tend towards having things that work better or worse.

It comes down to a cost benefit thing - is the cost of poorer readability worth it for mitigating the risk of people doing the wrong thing? My experience says no, other people's experience says yes. Probably we are working on different problems and with different teams.

I previously went down the rabbit hole of fancy unit test frameworks, and after a while I realised that they didn't really win much and settled on something almost identical to what you have (my PRINT_RUN macro has a different name, and requires the () to be passed in - and I only ever write it if the time to run all the tests is more than a second or so, just to make it really convenient to point the finger of blame).

The thing that I do which are potentially looked upon poorly by other people are:

1) I will happily #include a .c file that is being unit tested so I can call static functions in it (I will only #include a single .c file)

2) I do a tiny preprocessor dance before I #include to make sure NDEBUG is not defined (in case someone builds in a "release mode" which disables asserts)

If you want to have some abstract type where you don't let people know anything about the innards, but you do have an explicit interface which enumerates what you can do with it, then yes - you can only really pass around pointers to these things and people outside your abstraction can only pass references not values.

If you want people to be able to pass your abstract type by value (among other things), then either you need to let them know how big the thing is (an implementation detail) or you have to expose the copy implementation in such a way that it could be inlined (more implementation details).

Sometimes, the "pure abstraction" approach is best where you only ever deal with pointers to things, and other times the "let's pretend that people do the right thing" approach is best. I don't see this as a header file thing though.

Being able to just read through a library's .h files to know how to use it is really nice. Typically, my .h files don't really look like my .c files because all the documentation for how to use the thing lives in the .h file (and isn't duplicated in the .c file). It would be entirely possible to put this documentation into the .c file, but it makes reading the interface much less pleasant for someone using it.

Being able to use the value asserted is nice sugar though. I will take that :)

Doing this stuff well is pretty hard (e.g. designing filters that can do that kind of volume adjustment is hard because you want to be constantly adjusting them, which means you need to be super careful with your filter state) but I have heard what it sounds like, and once you hear it you get angry at all other volume controls.

I haven't ported it to android, but I expect it to be simple too.

What I don't understand from the article is the moving goalposts. I had one threat of store removal because of a lack of sales and updates, so I found some stuff I didn't need to ship and removed it and pushed that as an update. Not so. I think it has been in the store 4 years or so now, so this doesn't seem too much work. I guess it could be churn in the areas that I deliberately avoid (e.g. I have no networking and only use the screen and audio out)