zygo_histo_morpheus

This article uses the term "parsing" in a non-standard way - it's not just about transforming text into structured data, it's about transforming more general data in to more specific data. For example, you could have a function that "parses" valid dates into valid shipping dates, which returns an error if the input date is in the past for instance and returns a valid_shipping_date type. This type would likely be identical to a normal date, but it would carry extra semantic meaning and would help you to leverage the type checker to make sure that this check actually gets performed.

Doing this would arguably be a bit overzealous, maybe it makes more sense to just parse strings into valid dates and merely validate that they also make sense as shipping dates. Still, any validation can be transformed into a "parse" by simply adding extra type-level information to the validation.

Why do you think it's a bad idea? Both you and OP are in agreement that you should validate early, which seemed to be what your first comment was about. Is it encoding that the data has been validated in the typesystem that you disagree with?

If you want to test windows programs on linux, you're probably going to want to do that in a virtual machine, or even a spare computer just for testing on windows. Depending on how much you need to use excel, a virtual machine could be a good option for that as well, but if using Microsoft Excel™ is a big part of your job, maybe it makes more sense to just stay on Windows for work at least

fd is a lot faster than find. This might not matter if you're searching through small directories but if you're working in a very large project it does make things a lot nicer.

RFK is a C-nile

The US government recommending memory safe languages has really given people worms in their heads

Always squashing is a bit much for my taste, sometimes the individual commits have interesting information! Text from the MR in the merge commit is great though, maybe I should see if we can set that up with gitlab and propose that we start doing that at work.

Putting the message in git puts the information closer to the code, since the pr isn't in git itself but instead the git forge. You can for example search the text of git messages from the git cli, or come across the explanation when doing git blame. I sometimes write verbose commit messages and then use them as the basis for the text in the pr, that way the reviewer can see it easily, but it's also available to anyone who might come across it when doing git archeology

Who the fuck types out "snigger" haha

Teleports behind you

I mean if you think that it's bad for linux culture because you're teaching newbies the wrong lessons, fair enough.

My point is that most people can parse that they're essentially asking you to run some commands at a url, and if you have even a fairly basic grasp of linux it's easy to do that in whatever way you want. I don't know if I personally would be any happier if people took the time to lecture me on safety habits, because I can interpret the command for myself. curl https://some-url/ | sh is terse and to the point, and I know not to take it completely literally.

You should start getting it from CD-roms, that shit you can trust

You have the option of piping it into a file instead, inspecting that file for yourself and then running it, or running it in some sandboxed environment. Ultimately though, if you are downloading software over the internet you have to place a certain amount of trust in the person your downloading the software from. Even if you're absolutely sure that the download script doesn't wipe your home directory, you're going to have to run the program at some point and it could just as easily wipe your home directory at that point instead.