TheNewAndy

One obvious benefit for a header only library is that it suppresses the warning you get when a static function isn't used.

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.

If you believed the pointers didn't alias and they actually did then you replaced slow incorrect code with fast incorrect 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.

"Never" is a big call.

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.

The opal app will do what you want. It isn't exactly what you wanted, but it is certainly possible to do

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)

How do European timezone rules bother you?

How does putting NFC in the tickets prevent this?

I would consider a proof to be a "repeatable argument". One you could show to someone and expect them to be convinced by it. I think it is a defensible viewpoint that a proof in coq is not 100% convincing. If you think otherwise, then how can you reconcile the existence of falso (a coq verified proof of "false")?

https://github.com/clarus/falso

Proof and belief I think are pretty strongly intertwined, but I'm not going to pretend to have a particularly rigorous philosophy on the matter. Similarly, when the proof of Fermat's last theorem was published, I don't know if I should consider that to be a proof because it is well beyond my comprehension. I have no reason to question it, but should I consider it a proof? I know that people smarter than me (e.g. Wiles) thought the original version of it was a proof, but it had a subtle error in it which required a fix. While I haven't looked at the proof and revision, I would be surprised if I could look at the two versions as labelled and tell which one is the correct version.

How does it solve the Byzantine generals problem?

The user of the build system defines boolean variables for any aspect of the build system that they think might be helpful. There are booleans for types of compiler flags (e.g. should I include debug symbols?) and booleans for specific chunks of code (e.g. should I build the unit test code) and booleans for how the thing is being built (e.g. am I building for linux? am I writing a makefile?)

The build system is then able to figure out a starting set of booleans which must be true (e.g. "I am writing the makefiles for the unit test project so it builds on linux in a debug build"). This translates into some starting assignment of boolean values to the boolean variables.

However, it is most likely, that this assignment will not satisfy every horn clause. For example: "if (debug build) then (include debug symbols = TRUE)" might be a clause, and so known that we have a debug build implies we need to set our boolean for including debug symbols to be true (we can break this out so we can then easily have things like optimized builds with debug symbols). Then once you know that you have debug symbols, we might have a clause like "if (debug symbols AND compiling with gcc AND writing a makefile) then (<magic side effect goes here>)"

Similar stuff happens for dependencies. If some code uses the maths library, then the place where the magic side effect says "add this file to the list of files being compiled" will also have a "link with maths library = TRUE" part to it, so then anyone who sets the boolean to get that file, will magically also be told that they need the maths library, and some other part of the system will be responsible for figuring out what that means (e.g. adding "-lm" to some makefiles)

The syntax for it is all simplified down so it doesn't really look like you are doing boolean arithmetic everywhere, but the semantics are mostly what I'm describing.

Actually, Turing completeness would make it worse. This system means that when you pull in things from multiple places and multiple teams, the interactions between the different things would be really trivial to understand. e.g. if you want to know "why is this preprocessor macro being set?" then the tooling can tell you exactly why - even if the answer spans multiple modules from different teams. But the other side effect was that people tended to not do anything crazy or even just different (compare with the whole find_package business in cmake where different packages do things in different ways and frequently have conflicting compile/link requirements)

I am very familiar with embedded stuff, and this whole system was built precisely because of that. Some people are developing in visual studio so give them a good visual studio project that works well, some are working with a proprietary garbage toolchains, so you need to let them write makefiles and have enough flexibility to let them encode how to do that in the build system (e.g. all the different quirks you get for figuring out header file dependencies). The policy I used was "every toolchains needs some lowest common denominator support" and then "once you have that, let every toolchains be as good as possible with equivalences given abstractions". It did appear to work.

I think you may have misinterpreted me on the multiple build system thing. There is one build system and it produces files that each ide/toolchains can work with. So it can make xcode, visual studio, makefile, etc. No one edits those by hand, just like cmake, gyp, etc

No, it is just a finite set of variables. The problem being solved is "given a known set of variables that are true, find the minimal set of other variables that need to be true" and this is basically a flood fill algorithm.

Horn clauses just mean you can have a whole bunch of things saying "if x then y is true" where X is constrained to be a monotonic (i.e. no negation) Boolean function (i.e. OR and AND).

Given some starting known true values in the system (e.g. debug_build=true, platform_is_windows=true, build_curl_library=true) you solve to find the minimum set of other variables that need to be true.

Each variable can then have some effects tied to it (e.g. if build_curl_library is true, then make sure curl.c is compiled and curl/include is in the include path)

Being Horn Clauses, the solving is basically a flood fill - as soon as you know a variable is true, it is locked in as true. If there was negation, then you can have weird contradictions and reasoning about the system starts being really difficult.

I have made a (internal only unfortunately) meta build system for my work. Instead of being Turing complete is uses Horn Clauses as the primary mode of logic. This means that the problem of determining "is this compiler flag set" or "is this file used in this build" is always solvable in polynomial time.

It has been in use for over ten years by multiple teams around the world for all sorts of whacky toolchaims and projects.

I don't believe anyone has missed Turing completeness.

Despite all that, I agree that if you need a metabuild system then things are probably too complicated. I guess the main reason I would argue for one is when building a cross platform thing, it is nice if developers using toolchain X don't need to modify build files for all the toolchains that aren't X - making Linux developers have to fight Visual Studio just to add a new file to a build is not ideal. But in principle - I still agree that the resulting question of "how do I build this thing from scratch?" Should probably be answerable in 2 sentences (e.g. "Compile and link all the C files with the top level directory in the include path. Don't compile files that have an operating system in their name unless you are building for that os")

Linux ships with all the drivers installed (for a fairly high value of "all") (typically)