I wrote nearly all of https://apps.apple.com/us/app/two-birds-one-stone/id15396463... on a train without internet. It was about a half hour journey, and I found that in such a short amount of time, I would set a small goal and work in a very distraction free way to achieve it. It was very good for doing small things, but sometimes doing larger things (like big refactors) is a bit more difficult. On occasion, I would also dedicate a train ride to just writing up a todo list.
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)
Not really a shell one liner, but ctrl+r (a readline command to do an incremental search backwards through history) is something that has been present on every shell I've used for decades without realising it, One day I decided to take the time to read all the magic readline commands because I wanted a way to quickly edit the N-th argument of a command with lots of arguments, and there were way too many of them. There were so many commands that I had no hope of remembering them all, but I figured I could just remember a few useful ones - and ctrl+r was one of them (ctrl+w and alt+b were the other two)
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.
Perhaps I am wrong, but the videos on this channel seem to have scripts that seem like they are very much AI written.
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.
The game was 2d, and I just used the stuff in SDL_render.h for doing the graphics.
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.
If you just want to write C and are ok linking to stuff that is in other languages, then I used SDL2 for my game which I wrote in C and is on the app store. It was a very pleasant experience, and if I were doing an iOS thing again, I would likely do something similar.
I think I had one objective C file in there for calling a library function I needed, but otherwise I just wrote C code.
Thanks for the constructive example of the rust doc.
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.
That's an interesting assertion, but not one that matches the experience I've had.
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).
Personally, I'm happy to just let a Sufficiently Advanced Compiler do link time optimizations to deal with that level of optimization and either take the hit, or make more things public while that compiler doesn't exist.
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.
This is probably something where it comes down to preference and familiarity. I would much prefer a simple text file for documentation that I can grep, open in my text editor, modify easily without switching context (oh, I should have been more explicit in the documentation I wrote - let me just fix that now), etc. All the features you mentioned "nice interface, fully searchable API interface, whole public API" are exactly what you get if you open a well written header file in any old text editor.
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.
Right, but as soon as you have private stuff in your header file, that is leaking implementation details. Yes it is kind of true that these are compile time checked to make sure that people don't do the wrong thing, but it is still an implementation detail that is leaking.
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.
You will be pleased to know that you are not the only one who does this.
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 <assert.h> to make sure NDEBUG is not defined (in case someone builds in a "release mode" which disables asserts)
That is less about header files, and more about how machine code works.
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.
Header files are one of the things I miss the most about languages that aren't C. Having a very clear distinction between public and private, and interface and implementation is one of my favourite things about C code (at least the way I write it).
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.
I used to like having nice strings to go with my asserts and would often do something like: assert(condition && "explanation of assert"). Now I think that the whole point of an assert is that it is for errors that require a code change (i.e. it is not recoverable at runtime) and so the very first thing that will happen in the investigation will be looking at the code with the assert - so a comment will do just fine if things aren't obvious. We also know that the programmer is going to need to understand the code that they are changing, and we also know that whoever wrote the code must have had a wrong assumption, so while their documentation is a good clue, it is also to be treated with some level of suspicion. As a result, I go for a simple assert, occasionally with a comment that explains why the assert should never fail.
Being able to use the value asserted is nice sugar though. I will take that :)
Volume controls also shouldn't just be a flat wideband gain - they should respect how we actually perceive sound so the timbre doesn't change as the level changes (when you turn the volume down, you are typically left with just the stuff in the vocal frequency range, and lose all the bass etc).
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 have a pretty simple game on the iOS app store. It is simple enough that I have probably written it about three times. One of the times I tried to do everything the "apple happy path", but the final iteration in the app store completely rejected it (and was written in C, primarily on Linux then ported to iOS as a final step). I know that familiarity plays a huge part, but the experience of just writing it in plain C (and using SDL2 as the platform abstraction) was so much simpler and nicer. The things I had to implement myself instead of "coming for free" (simple physics, app lifecycle stuff etc) were relatively easy to do.
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)