Hi, author here. Thanks for the feedback! I'll take a look at the article tonight and go through the comments and update the post based on the comments.

Thanks for sharing! Appreciate the OSS work. Is it ok if I reference that repo in my article?

100%! I would be thrilled! Thank you very much.

It’s much more difficult to tell if someone bypassed the lock if they picked it (and relocked it), as opposed to cutting it off completely

Which is relevant when you're defending against Ocean's 11 or the Mossad, but for the other 99.999% of us, the lock is there to keep a bored teenager or a meth junkie out.

Or, more realistically, to convince an insurer that we've made a token effort to keep them out.

This is exactly the point.

The lock is there to keep the honest people out AND leave a trace that someone came in forcibly when they want to do so.

Which is why stuff like bump keying those stupid flat-keyed American locks is so scary because it requires almost zero skill and leaves very little traces.

Unless an expert takes apart the lock investigating for traces, there's no way to tell it was opened without a key.

What exactly is going on that:

1. You (or someone else) gives enough of a crap to be doing forensics about how a lock was circumvented.

2. You clearly care so much about security to do those forensics, but not enough to, I don't know, install a camera?

Will an insurer, or a cop that you're making a police report to actually physically check if the lock was shimmed?

Thanks for the feedback! I'll likely be editing part 1 to include the feedback so far from the commenters as well. If there's a specific statement or analogy that felt especially confusing, please point it out and I'll clarify it in the post.

Sorry for moaning - it's just the usual despair that I feel every time I read a new explanation and fail to understand it. This isn't your fault.

Thanks for the feedback, I totally agree that monads are not containers. From an OOP perspective, they have some properties that make them, in some sense, sorta like containers, e.g., they contain a value like the Maybe monad. I still agree that they are not simply containers. I can clarify this in a revision to part 1 soon.

> From an OOP perspective, they have some properties that make them, in some sense, sorta like containers, e.g., they contain a value like the Maybe monad.

Not always! I find this is a big source of confusion; not all monads contain values, sometimes beginners think they can or should "get the value out" of a monad and that tends to lead to writing the wrong kind of code.

Thanks for the feedback! I didn't expect my post to garner a lot of attention. I am totally ok with rewriting part 1, potentially to make it more concise to prevent confusion (wow, this post is super long, monads must be complex!) is what I'd like to avoid.

I can reproduce the double line issue in part 2, this was my mistake and I missed it as part of my editing process. I'll delete part 2 while I make the corrections.

Thanks for the feedback! I can definitely rename the post soon as a first step, although this may require rewriting a chunk of the article to more accurately reflect the fact that List is a monad, and not "a" list.

I could make this distinction in part 3 (not written yet) although I want to balance not misleading readers, but not overcomplicating it too early on.

Hi, I completely agree. "A" list isn't inherently a monad, and that is where my metaphor starts to fall apart a bit (my post title furthers this issue.)

I can clarify this earlier in part 1 or 2 instead of in to-be-written part 3.

Its a harmful metaphor and clickbait title.

This seems harsh to the point of being untrue...