Kolanaki@yiffit.net
on 10 Apr 2024 22:13
nextcollapse
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.
FalseMyrmidon@kbin.run
on 11 Apr 2024 00:15
collapse
This wouldn't apply to that criticism. An ini is a configuration file, not really source code.
TrickDacy@lemmy.world
on 11 Apr 2024 02:31
collapse
…which is why they’re agreeing with op and simply adding an example to illustrate why
aodhsishaj@lemmy.world
on 10 Apr 2024 22:22
nextcollapse
Hasn’t this been best practices since Grace “Light has a speed limit” Hopper? May she rest in power.
TropicalDingdong@lemmy.world
on 10 Apr 2024 23:04
collapse
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?
nik9000@programming.dev
on 10 Apr 2024 23:26
nextcollapse
cgtjsiwy@programming.dev
on 10 Apr 2024 22:39
nextcollapse
I wonder when Firefox is going to add a configuration menu for keybinds.
Dark_Arc@social.packetloss.gg
on 11 Apr 2024 05:22
nextcollapse
I want one even more badly for thunderbird. It feels like such an obvious thing that’s just … missing.
lysdexic@programming.dev
on 11 Apr 2024 05:47
collapse
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.
YIj54yALOJxEsY20eU@lemm.ee
on 11 Apr 2024 16:31
nextcollapse
I disagree but you made it clear its your opinion so I am upvoting to cancel out the downvotes.
avonarret1@programming.dev
on 13 Apr 2024 14:07
collapse
Why would you want that? It seems a bit arbitrary for me to make sense.
TootSweet@lemmy.world
on 10 Apr 2024 23:10
nextcollapse
jlh@lemmy.jlh.name
on 10 Apr 2024 23:24
nextcollapse
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.
dustyData@lemmy.world
on 11 Apr 2024 00:55
nextcollapse
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.
lysdexic@programming.dev
on 11 Apr 2024 05:44
collapse
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.
abhibeckert@lemmy.world
on 11 Apr 2024 01:41
nextcollapse
For edge cases where you need the power of a programming language in your config system, use something like PKL.
Dark_Arc@social.packetloss.gg
on 11 Apr 2024 05:10
collapse
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
mvirts@lemmy.world
on 11 Apr 2024 04:09
nextcollapse
Yes. This is why conda and nix are complicated.
Dark_Arc@social.packetloss.gg
on 11 Apr 2024 05:07
nextcollapse
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.
maiskanzler@feddit.de
on 11 Apr 2024 11:00
collapse
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.
maiskanzler@feddit.de
on 13 Apr 2024 20:31
collapse
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…
Deebster@programming.dev
on 11 Apr 2024 05:23
nextcollapse
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.
FizzyOrange@programming.dev
on 11 Apr 2024 05:43
nextcollapse
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.
firelizzard@programming.dev
on 11 Apr 2024 17:14
collapse
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.
FizzyOrange@programming.dev
on 12 Apr 2024 21:17
collapse
That’s totally orthogonal to whether your config is source code or not though.
firelizzard@programming.dev
on 13 Apr 2024 23:01
collapse
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.”
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.
threaded - newest
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.
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: youtu.be/9eyFDBPk4Yw?si=sb_v_EPhTM9C6bZZ
The very same thought yes. Also this interview
m.youtube.com/watch?v=oE2uls6iIEU&pp=ygUbZ3JhY2Ug…
Remove the quotation marks and the first result is kottke.org/…/grace-hopper-explains-a-nanosecond
More accurate is “electricity has a speed limit”
All my software can be configured using dedicated configuration files (.c)
Run cc to complete configuration.
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.
I disagree but you made it clear its your opinion so I am upvoting to cancel out the downvotes.
Why would you want that? It seems a bit arbitrary for me to make sense.
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.
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
Yes. This is why conda and nix are complicated.
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.
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…
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.
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.
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.”