Quekid5

That's a nice quip, but aren't degrees meant to offer breadth of knowledge? (I'm sure she has lots, but perhaps is weak in other areas.)

*. sends its regards

:)

That seems like a low bar :)

> I want a way to state that my intent is to not rely on the TCO.

How would that work? You want a nontail keyword to indicate that intent explicitly?

I guess I could imagine a scenario where you want to de-optimize a TCO into a non-TC... but I mean... that's got to be rare enough to just not bother with?

EDIT: Also, this is the exact opposite of your comment which I replied to. Make up your mind on what you want and we can maybe find a way to achieve it

Sure, but if you're relying on the TCO, you kind of have to actually state that, regardless? (At least if you want to avoid accidental regressions.)

I don't see any way around having to state your intent (as a programmer) for this. It's just a semantic difference in behavior unless your Abstract Machine allows for just ignoring the possibility of stack overflow entirely.

Just add the @tailrec annotation -- then the compiler will complain loudly if you break tail calls.

> How do we know if random internet service sells our email / password pair? They probably store the hashed password because it's easier (libraries) than writing their own code, but they get it as cleartext every time we type it in.

For that, we can just use a unique password per service. That's not really a thing for code.

I believe the default compression setting for the zstd command is biased towards speed -- maybe try -9, -13 or even -22 (max, which should probably be fine for such a small file).

Not that it matters when the file is so small in the first place... I'm just saying you should be sure what you're 'benchmarking'

So... metadata checksums? I mean if enough data/metadata gets corrupted you're SOL either way.

For example, in ZFS the metadata is checksummed such that pointers to the data carry the checksum for that data.

It's worth noting that some (many?) languages[0] only support TCO as long as you're calling the function itself in tail position. The usual cases were you'll notice this when implementing state machines in "direct style" or when doing continuation-passing style for control flow.

TCO is more general than that in some languages where any function call in tail position can be turned into a direct jump. This obviously requires either 1) runtime support in some form or 2) a non-trivial amount of program transformation during compilation.

[0] Scala's @tailrec is one I'm 100% certain of.

I'd say it makes checksums even more important so that you know whether something got corrupted immediately and not after a year (or whatever) has gone by and you actually need it.

> However, it’s getting frustrating to see all of the reductionist claims that “chronic pain is psychological”.

It's incredibly frustrating and disheartening... For obvious reasons, I'm not going to go into too much detail, but chronic (non-visible) pain is the worst of the worst. People will either think you're "faking"[0] or it's "just psychosomatic"[1]. I actually relish being able to work for a good long day because I'm lucky enough to actually enjoy making computers do stuff.

[0] Yes, I love to miss lots of family occasions, just because.

[1] I'll just will myself better. Nevermind the MRI scans and all that.

EDIT: I should add... the cognitive biases at work are understandable because they've probably been around since proto-humanity, but that doesn't change the outcomes.

Undefined Behavior has a very specific meaning in the C and (respectively) C++ standards. And it is this.

I think you may be misunderstand how optimization works. It's not "AHA! Undefined Behavior, I'll poke at that!".

It's more that compilers are allowed to assume that some things just "don't happen"... and can optimize based on that. And it does make sense... if you were told to optimize a thing given certain rules, how would you do it?

"To shreds, you say?"

"Oracle" and goodwill is not a thing.

> Tbh the collections being mutable isnt really an issue since it gets the job done and reasoning about these things isnt that hard.

Have you worked in language with immutable collections by default? It's night and day -- no more defensive copies, no more weird ImmutableList wrappers (Guava) which will (interface-wise) say they're mutable but will throw at runtime, no worrying about multithreading, cheap subsequences, etc. etc.

The difference is so stark that I would literally choose a worse[0] language(!) over a better one if it had immutable collections by default.

EDIT: Since you mentioned Java in a sibling comment -- give Scala a try and try working with the collections there.

[0] Within reason, of course :)

Considering that it's Undefined Behavior, quite possibly.

EDIT: That said, I'm on the maintainer's side here.

Not if that language doesn't actually check the totality of your proof and ensures that the base case holds.

If a set-of-strings was trivially available in the source language (at time of implementation) the original programmer would probably have done this (relatively) trivial optimization... This is a symptom of anemic languages like C.

> It's not great, but you can always catch and retry if your belief is that the GC will free enough memory to allow the attempt to continue after the memory pressure subsides.

No, you cannot. Catching, for example, StackOverflowError (which inherits from Error) can lead to very strange deadlocks and such (if locking is relying on try-finally discipline, as it should), even if you do "almost nothing" before re-throwing.

It's a huge hornet's nest of weirdness to even attempt to catch anything which derives directly from Error. (Rather than RuntimeException/Exception.)

EDIT: There are some really strange subclasses of Error now that I think about it. E.g. VirtualMachineError ... I don't think I've ever seen that in any logs, thankfully, but what exactly is the program (running on the failing VM) supposed to do if that is thrown? It'd be like trying to carry on or log an error if suddenly 1==2 turned out to be true.

Sooooo much boilerplate and pointless generated tests is my prediction.

EDIT: Oh, and as a sibling poster mentioned: A huge number of security vulnerabilities -- except now they can be purposefully injected by just posting random subtly-wrong code on the interweb. Not that you couldn't do that before, but reach would be much more limited unless you got your 'seemingly correct' code posted on SO.

If your (backup-via-redundancy) keys are mutable, you do not have a backup. What happens in the case of a ransomware attack, for example?

You've also added (possibly substantial) latency to every single operation that operates on user data.

You still have to backup those keys somewhere... and if you don't do it the same way as for the data then your backups are effectively worthless.

Yes, negative indexing as in e.g. Python (so basically "from the end") can be incredibly convenient and works seamlessly when indexes are 0-based.

I think the Quantum Leap expression can also be understood as a "step" with no intermediate stages, i.e. very abrupt or transformative.

> Code ligature thing has something to do with just seeing the characters that are actually there rather than a smokescreen, which IMO impedes editability because I can't place the cursor half-way through a ligature and so on

Why wouldn't that be possible? (The cursor thing)

It's still two characters as far as your editor is concerned.

That's effectively "make clean" just slightly more automated. Btw, what happens if you change CFLAGS? Does anything get compiled if no files have changed?

Funnily enough, I tend to think the arrows should be in the other direction. Philosophy birthed Math, which was necessary for Physics, ... etc.

That's not to say Philosophy has outlived its usefulness, but... it was probably more consequential 2000, 400 or 200 years ago, in practice.

(EDIT: I should add... there is also a lot of absolute dogwank in Philosophy too... but I think that's universal for any field, tbf.)

"A implies B" does not mean "B implies A".

They are simple but very often wrong. It's surprisingly hard to write Makefiles that will actually do the right thing under anything other than "build from scratch" scenarios. (No, I'm not joking. The very existence of the idea of "make clean" is the smoking gun.)