this post was submitted on 10 Apr 2024
108 points (95.8% liked)

Programming

17457 readers
72 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
top 32 comments
sorted by: hot top controversial new old
[–] [email protected] 99 points 7 months ago (1 children)

All my software can be configured using dedicated configuration files (.c)

[–] [email protected] 29 points 7 months ago

Run cc to complete configuration.

[–] [email protected] 55 points 7 months ago
[–] [email protected] 30 points 7 months ago* (last edited 7 months ago) (2 children)

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.

[–] [email protected] 10 points 7 months ago

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.

[–] [email protected] 5 points 7 months ago

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 VERBOSE flag.

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.

[–] [email protected] 22 points 7 months ago (1 children)

Hasn't this been best practices since Grace "Light has a speed limit" Hopper? May she rest in power.

[–] [email protected] 11 points 7 months ago (2 children)

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?

[–] [email protected] 15 points 7 months ago

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"

[–] [email protected] 6 points 7 months ago (1 children)
[–] [email protected] 3 points 7 months ago* (last edited 7 months ago)
[–] [email protected] 18 points 7 months ago (1 children)

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.

[–] [email protected] 15 points 7 months ago (1 children)

This wouldn't apply to that criticism. An ini is a configuration file, not really source code.

[–] [email protected] 5 points 7 months ago

...which is why they're agreeing with op and simply adding an example to illustrate why

[–] [email protected] 10 points 7 months ago (2 children)

I wonder when Firefox is going to add a configuration menu for keybinds.

[–] [email protected] 3 points 7 months ago (2 children)

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.

[–] [email protected] 1 points 7 months ago

I disagree but you made it clear its your opinion so I am upvoting to cancel out the downvotes.

[–] [email protected] 1 points 7 months ago

Why would you want that? It seems a bit arbitrary for me to make sense.

[–] [email protected] 2 points 7 months ago

I want one even more badly for thunderbird. It feels like such an obvious thing that's just ... missing.

[–] [email protected] 10 points 7 months ago (1 children)

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.

[–] [email protected] 5 points 7 months ago (1 children)

The line between configuration is very messy anyways. So many projects abuse YAML as a domain specific language. Looking at you, HomeAssistant and ESPHome!

[–] [email protected] 1 points 7 months ago (1 children)

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.

[–] [email protected] 1 points 7 months ago

Yeah that occurred to me as well. Then I immediately think that maybe we need ☆one more language☆ to fix this. And then I remember that one xkcd comic...

[–] [email protected] 8 points 7 months ago
  1. 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 ...

  2. 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.

[–] [email protected] 7 points 7 months ago (1 children)

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.

[–] [email protected] 3 points 7 months ago (1 children)

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.

[–] [email protected] 1 points 7 months ago (1 children)

That's totally orthogonal to whether your config is source code or not though.

[–] [email protected] 1 points 7 months ago

True, but if you read the article the point is clearly not about source code vs non-source configuration. There's an implicit assumption that source code is something the developer will be modifying as time goes on, but the real point is, "Don't make users merge changes."

[–] [email protected] 4 points 7 months ago (1 children)

For edge cases where you need the power of a programming language in your config system, use something like PKL.

[–] [email protected] 2 points 7 months ago

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

[–] [email protected] 2 points 7 months ago

Yes. This is why conda and nix are complicated.

[–] [email protected] 1 points 7 months ago

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.