khalid_salad

my pants are an anti-embarrassment protocol

After reading some of the counterpoints here, I began thinking about how I considered Excel a hyperkludge if you qualify it enough. I realized the qualifications apply to every programming language (good ol' Turing Completeness). I think, in my case, the common scenario of

1. this tool^[1]^ is just a proof of concept/prototype
2. it costs less to maintain our tool than to write a more appropriate solution from scratch
3. our infrastructure is now the tool

had me erroneously criticizing the tool instead of its application^[2]^. In the case of Excel, I worked a few jobs where the spreadsheets used when the company was small led to an absolute nightmare after the company grew.

I appreciate the thoughtful responses from everyone. <3

1: Usually a spreadsheet, in my experience.

2: Noting that, while "it's not the tool, it's the application" is a common refrain from people using tools in shitty ways, there is a distinction between "this is the wrong tool for the job" and "this tool will hurt people".

I need an excuse to learn Rust and have wanted to do a "parse, don't validate / make invalid states unrepresentable" project for a while. I will definitely share it if I get anything done.

At the end of the day you shouldn't have to maintain anything in order to use a program, in my opinion (at least ideally). I think a "everything must be present in the file" type of config would require ~~less~~ no extra maintenance (assuming devs don't do anything too silly). Additionally, while noting that my primary programming language is TeX and also that I am a dipshit, this just strikes me as an API-design problem. Alternative solutions could be:

1. multiple config files (I think mpv already supports this)
2. semver style config (idk if this would be practical)
3. a config-editing tool (i.e., what the overwhelming majority of applications do, by hiding the implementation details from the user)

I have thought about doing #3 for Sway (a sort of Sway-config editor). This does give me an idea, though: define a meta-format for specifying the variables, default values, allowed values, etc., for an arbitrary^[0]^ program's config file, and create a program that reads a meta-format file and presents a GUI for editing the config.

tbh i just lost my config file, forgot what i changed, and now i have to read documentation (and figure out which file the mpv flatpak uses for config)

[0]: maybe not too arbitrary

I personally disagree. I think in the era of "a megabyte is big," this made sense, but in my opinion after parsing a config file with missing config data, we should print something indicating they are missing then error out. The existence of a reference config file with all options included would definitely help, but I think it's no coincidence that there is no such config for mpv

why bother creating and maintaining one if the program will use the default value anyway?

tl;dr explicit is better than implicit

What's great is even the very best "just use valgrind lol, lmao" folks make these errors all the time. It's basically impossible to write correct C code generally

the best we can do is verify subsets of code (c.f. Rust's unsafe keyword). The memory-safety CVEs in EXT3/4 are proof of this, IMO, as if there were anyone able to write correct C code today, it would be Ted Ts'o.

Surely it’s better to specify those defaults in the config file and have the system just fail if the necessary flags aren’t present.

Completely agree. I think this may just be an extension of the "you gotta know what you're doing to code correctly in C" old school bullshit.

this rules <3

Does anyone else get tired of "read documentation and edit this text file to configure your app" Unix shit? I have no problem with the underlying configuration being a text-file (makes for a straightforward API), but do I really need to navigate to https://mpv.io/manual/master/#configuration-files and go through the rigamarole of figuring out which options I need to edit/include^[0]^ because I misplaced (read: sudo rm -rf /) my config file?

[0]: And there is always so much implicit bullshit. "By default, we summon Cthulhu on Tuesdays and Thursdays if the variable summon_octopus_guy is unset." It's a fucking config file, my friends, can we just be explicit?

me frantically changing my downvote

It's actually super easy to increase the accuracy of LLMs.

import pytorch # or ollama or however you fucking dorks use this nonsense
from decimal import Decimal

I left out all the other details because it's pretty intuitive why it works if you understand why floats have precision issues.

I'd suggest learning more things before sharing your thoughts.