Having read your article, I contend it should be:
P(arentheses)
E(xponents)
M(ultiplication)D(ivision)
A(ddition)S(ubtraction)
and strong juxtaposition should be thrown out the window.
Why? Well, to be clear, I would prefer one of them die so we can get past this argument that pops up every few years so weak or strong doesn’t matter much to me, and I think weak juxtaposition is more easily taught and more easily supported by PEMDAS. I’m not saying it receives direct support, but rather the lack of instruction has us fall back on what we know as an overarching rule (multiplication and division are equal). Strong juxtaposition has an additional ruling to PEMDAS that specifies this specific case, whereas weak juxtaposition doesn’t need an additional ruling (and I would argue anyone who says otherwise isn’t logically extrapolating from the PEMDAS ruleset). I don’t think the sides are as equal as people pose.
To note, yes, PEMDAS is a teaching tool and yes there are obviously other ways of thinking of math. But do those matter? The mathematical system we currently use will work for any usecase it does currently regardless of the juxtaposition we pick, brackets/parentheses (as well as better ordering of operations when writing them down) can pick up any slack. Weak juxtaposition provides better benefits because it has less rules (and is thusly simpler).
But again, I really don’t care. Just let one die. Kill it, if you have to.
It’s like using literally to add emphasis to something that you are saying figuratively. It’s not objectively “wrong” to do it, but the practice is adding uncertainty where there didn’t need to be any, and thus slightly diminishes our ability to communicate clearly.
I think anything after (whichever grade your country introduces fractions in) should exclusively use fractions or multiplication with fractions to express division in order to disambiguate. A division symbol should never be used after fractions are introduced.
This way, it doesn’t really matter which juxtaposition you prefer, because it will never be ambiguous.
Anything before (whichever grade introduces fractions) should simply overuse brackets.
This comment was written in a couple of seconds, so if I missed something obvious, feel free to obliterate me.
On the command line, space is what separates each argument. If a path contains a space, you either have to quote the entire path, or use an escape character (e.g. the `` character in most shells, the backtick in Powershell because Microsoft is weird, or the character’s hexadecimal value), otherwise the path will be passed to the command as separate arguments. For example, cat hello world.txt would try to print the files hello and world.txt.
It is a good practice to minimize the character set used by filenames, and best to only use English alphanumeric characters and certain symbols like -, _, and .. Non-printable characters (like the lower half of ASCII), weird diacritics (like ő or ű), ligatures, or any characters that could be misinterpreted by a program should be avoided.
This is why byte-safe encodings, like base64 or percent-encoding, are important. Transmitting data directly as text runs the risk of mangling the characters because some program misinterpreted them.
but what does the command line matter for dates? sure every once in a while you’ll have to pass a date as an argument on the command line but I think usually that kind of data is handled by APIs without human intervention, so once these are set up properly, I don’t see the problem
<span style="color:#323232;">rsync -a "somedir" "somedir_backup_$(date)"
</span>
If the date command returns an RFC-3339-formatted string, the filename will contain a space. If, for example, you want to iterate over the files using for d in $(find…) and forget to set $IFS properly, it can cause issues.
But $(date) does return a string with spaces, at least on every system I’ve ever used. And what’s so bad about the possibility of spaces in filenames? They’re slightly inconvenient in a command line, but I haven’t used a commuter this century that didn’t support spaces in filenames.
Ok, I just reread it. I don’t see what you think I’m missing. You mean an improperly written find command misbehaving? The fact that a different date format could prevent a bug from manifesting doesn’t seem like much of an argument.
Spaces can exist in filenames. The only problem is that they have to be escaped. As the comment that you reread explained, cat hello world.txt would print the files hello and world.txt. If you wanted to print the file “hello world.txt” you’d either need to quote it (cat “hello world.txt”) or escape the space (cat hello world.txt)
Yeah? I once spent an entire week debugging a plaintext database because the software expected the record identifiers to be tokenized a certain way, but the original data source had spaces in those strings.
The software was the ISC DHCP server, the industry standard for decades and only EOL’d a year ago.
Sounds like a weekend that you could have saved if the software was just implemented properly and accepted spaces.
Something being an industry standard does not necessarily mean it’s good. Sometimes it just means it was the cheapest, or sometimes even just because it was used for so long. How long did it take for Torx to somewhat replace philips head screws despite being better in most cases?
I think date strings are made for human and machine readability. Similar to XML or JSON. So, why not improve systems so that we can have more human readable date strings? If you don’t care about human readability and want to make sure there is no confusion with spaces, you can just use epoch timestamps.
I’m not exactly fond of the space either, but man, the T is noisy. They could’ve gone with an underscore or something, so it actually looks like two different sections.
memes
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.