- cross-posted to:
- programming
- cross-posted to:
- programming
You must log in or register to comment.
As a gamer, I couldn’t agree more. Put all the video and audio settings in the options menu; especially if they are things easily changed by editing an .ini file in the install directory. I’m also big on having modding tools like the Creation Kit for modifying the game without having to edit code or use command line conversion tools. It’s just a massive time-saver.
This wouldn’t apply to that criticism. An ini is a configuration file, not really source code.
…which is why they’re agreeing with op and simply adding an example to illustrate why
Hasn’t this been best practices since Grace “Light has a speed limit” Hopper? May she rest in power.
Grace “Light has a speed limit” Hopper
I’ll have you know that googling this phrase results in a link to this post, which makes the origin of this phrase no more clear.
Can you explain please?
I believe they were referring to this: https://youtu.be/9eyFDBPk4Yw?si=sb_v_EPhTM9C6bZZ
The very same thought yes. Also this interview
https://m.youtube.com/watch?v=oE2uls6iIEU&pp=ygUbZ3JhY2UgaG9wcGVyIGRhdmUgbGV0dGVybWFu
Remove the quotation marks and the first result is https://kottke.org/19/05/grace-hopper-explains-a-nanosecond
More accurate is “electricity has a speed limit”
I wonder when Firefox is going to add a configuration menu for keybinds.
I want one even more badly for thunderbird. It feels like such an obvious thing that’s just … missing.
It might be just me, but I think key bindings should definitely not be easily configurable or even changed across release. They should.be standard, pervasive, and set in stone.
For those who really want configurable key bindings in Firefox I think there are already a couple of extensions that do this for you.
All my software can be configured using dedicated configuration files (.c)
Run cc to complete configuration.
https://suckless.org/ has left the chat.
This is a really important principle of making APIs that people don’t really talk about. There’s a fine balance between hardcoded literals and full-gui options menu.
Every piece of data in your program has a different level of configurability, and you need to make that trade-off to decide how hard or easy it should be to change. You could hardcode the data as a literal, or you could hoist it to the top of your source file as a const. You could have a separate static const configuration class, or you could have a runtime configuration file. You could even go for an interactive configuration editor/ options menu. It’s all a tradeoff based on offering your users choice but not overburdening them with it, as well as balancing development cost.
I know it’s not always that straight forward. But that’s why it’s so important to pick sane defaults, and be very transparent in the documentation.
This is a really important principle of making APIs that people don’t really talk about. There’s a fine balance between hardcoded literals and full-gui options menu.
I think this principle might fly under some people’s radar because it has been a solved problem for decades.
Even Makefiles don’t require changes to the file to be configured. They take environment variables as input parameters, an approach that directly and indirectly permeated into high-level build systems. One example is the pervasive use of the
VERBOSEflag.After all these years I only had to tweak build config files by hand when I wanted them to do something that they were not designed to do. All build tools I know don’t require it. The ones linked with IDEs already provide GUIs designed with this in mind.
For edge cases where you need the power of a programming language in your config system, use something like PKL.
Okay, that’s pretty cool not going to lie. Granted, I’m not entirely sold on the idea of having a config format that’s aimed at generating other config formats.
That feels like (in most cases) a recipe for things getting out of sync between the latest version of the PKL and e.g. the JSON
I’ve often thought that something like git’s auto-merge would make like much easier when I get asked if I want to keep my config, use upstream or decide per-line. What I should be able to do is have the system pick whichever changed recently, and give me the results to review and/or fix conflicts.
I agree with this, but there are ways to make your “source code” not a file that you will modify.
For instance you can have a file that’s imported/included for configuration purposes that you yourself don’t author… And I think that’s okay.
One of my favorite configuration languages for Python projects is actually just Python. It’s remarkably nice. It’s like having a YAML file you can script.
The line between configuration is very messy anyways. So many projects abuse YAML as a domain specific language. Looking at you, HomeAssistant and ESPHome!
I assume less custom configs are better, but I’ve seen Ansible yaml files that are just convoluted bash scripts written in yaml, which makes them even more convoluted.
Yes. This is why conda and nix are complicated.
Not sure I buy this. If you have a config header file and make backwards incompatible changes to it how is that different to having backwards incompatible changes to any other config system?
I think what the author meant to say is “don’t make breaking changes to your config system”. Maybe it’s common to ignore that when using source code as config; I don’t know.
It’s a bad idea anyway because compile-time options should generally only be for configuring the presence of optional third party dependencies, which you can do automatically. Anything else should be a runtime option.
I think the author’s primary point is, “Merging changes sucks, don’t make your users do that,” with a corollary: if your program loads configuration from a directory that is only populated by the user, there’s nothing to merge and thus never any merge conflicts. Case in point:
/etc/polkit-1/rules.d. I can add whatever rules files I want in there and they’re never going to conflict when I update. If PolKit makes breaking changes to the format, it will log errors somewhere and I can look at those errors, look at my rules, and figure out how to fix them. That’s a hell of a lot easier than merging conflicting changes to code/configuration.That’s totally orthogonal to whether your config is source code or not though.
-
Options. We’ve got lots of them. So many in fact, that you need two strong people to carry the documentation around. So many that it will be a cold day in hell before half of them are used. So many that you are probably not going to do your work right anyway. However, the number of options isn’t all that important, because we picked some interesting values for the options and called them …
-
Defaults. We put a lot of thought into our defaults. We like them. If we didn’t, we would have made something else be the default. So keep your cotton-pickin’ hands off our defaults. Don’t touch. Consider them mandatory. “Mandatory defaults” has a nice ring to it. If you change them and your system crashes, tough. See Figure 1.
-
