• 0 Posts
  • 37 Comments
Joined 1 month ago
cake
Cake day: September 7th, 2025

help-circle









  • MotoAsh@piefed.socialto196@lemmy.blahaj.zonetrolly rule
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    1 day ago

    But what if it’s just a copy of that relation R? Is it the same mind in a new body? Or a new body that’s so utterly similar that it will merely continue on believing it’s the same person?

    I don’t like that philosophy, because it pretends the mind exists outside of the brain.

    Does the difference of the literally unobservable matter? Yes absolutely to the person stepping in to the machine! Sure, everyone else doesn’t have to care, but the teleported person sure probably should care, so that philosophy does less than nothing for answering the question.

    He’s basically saying, 'I don’t care if you die if I cannot tell if the new guy is different.". Saying, “I don’t care” is not an answer.


  • MotoAsh@piefed.socialto196@lemmy.blahaj.zonetrolly rule
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    1 day ago

    IMO, even the digitally sent person could be the original, depending on the philosophical concepts being applied (same ship of theseus style questions). If it’s just the process of reading your atoms to that level of detail that makes you disappear, and the only information that is literally ‘you’ is being transferred over and reconstituted in a similarly one-way-by-function process, it’s almost more of a phase shift to digital and back than a copy. Pretty much just side-stepping matter’s inability to travel without acceleration.

    If the machine is basically ‘digesting’ the person only to send over the results for reproduction, though… that’s definitely a copy. Pretty sure Trek describes their transporters as the latter? They’re definitely killing a bunch of people in that show. ha Though to answer it with any kind of conclusive result, I’d think we’d need a technical description for how it works, and it cannot exist, so… lol



  • MotoAsh@piefed.socialto196@lemmy.blahaj.zonetrolly rule
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    1 day ago

    Y’know, the more I think about free will as a religous concept, the more I’m convinced it’s supposed to be an allegory for how to treat others, like a more convoluted Golden Rule. The source was shifted to “God” simply to make the garbage people that don’t normally care about others hesitate before they just ignore others’ advice on how to treat people.

    The reasoning is pretty simple: Nobody can actually do anything they want because others will interfere. Individuals restrict others’ freedom all the time. If you’re restricting others freedoms, you’re doing an even worse version of judging others. The Bible pretty clearly says to leave such critical stuff that idiots can screw up in God’s hands, because idiots can and will screw it up.

    Same with free will. Peoples’ freedom is, according to religous teachings, a gift from God. They describe such things as “from God” solely because idiots respect their flavor of Sky Daddy over other human beings.

    If it’s actually a gift from God, then it makes little sense that humans can simply remove a gift an all-powerful diety bestows. So… either historic humans are insanely stupid and bad at logic … or it’s actually an allegory for not trying to control others so much.




  • MotoAsh@piefed.socialtoAsk Lemmy@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    37
    arrow-down
    1
    ·
    edit-2
    4 days ago

    Never the one who pushed, always ambivalent, but now the problem is potential number 6 is hesitant? Yea, that doesn’t add up.

    Sounds like the obvious answer is do not marry, yet you want us to justify it for you?

    That’s massive red flag #2: You cannot take accountability for your own actions and desires. If this is how you describe your decisions for a life-long bonding ritual, I hate to imagine how you handle less important decisions.



  • Unit tests have never been fun to me beyond the satisfaction of having good coverage. I mean good coverage that exercizes and asserts behavior, not just line/branch coverage!

    Maaaybe the closest I’ve come to TDD was in JavaScript, not even TypeScript. Something about strict languages needing to be described a bit more explicitly seems to make code more tightly coupled in the general sense. Somehow, even beyond the literal code changes necessary. On one hand, that’s great because it’s harder to dig your own pits to fall in (see every reason TypeScript is even popular or ‘necessary’), but on the other, code definitely ends up less… portable? On a version to version change level within the same product, even.

    In order to “properly” do TDD, I feel like I should only have to minimally tweak the tests once they’re defined, or else it’s not really “driving” the development. It kinda’ always ended up that I’d write the tests in tandem, which just doubled or worse the amount of work when an edge case or implementation detail popped up that wasn’t already factored in. Then I’d have to address the functional issue and then go fix/add a test(s) for it. The process just ended up being slower than finishing the impl first, and THEN writing the actual tests, because the little tweaks along the way simply have less code to cascade in to.

    It’s really task-dependent on whether it pays off, IMO. If it’s new code/functionality, it really takes well broken down issues so you’re not writing multiple classes/features/concerns at once in order for TDD to feel remotely worth it. Which then has tradeoffs with extra task grooming time anyways. If it’s existing code you have to enhance or fix a bug of? TDD can pay off in droves when the tests keep you from breaking other things or missing side effects, and makes it very clear when you’re done with the task at hand to reduce the desire to refactor ugly code and whatnot. lol

    IMO, how much trouble it is, is more about how testable the code is in general and whether you already have good test coverage, more than having tests defined first.

    Not sure where writing tests fits on the problem solving spectrum. At least it helps as described for updates and bug fixes: you don’t have to focus on or check on nearly as much stuff to get a task done well. Writing new stuff, it’s always been more about how well structured and testable the design is than having the tests implemented first.

    I suspect it ultimately comes down to the application’s complexity over all. When tasks and code can stay simple, like with proper microservices arch or similar simplifying practices, I suspect it could be easy enough to TDD “properly” in any language and maybe even enjoy it. Sadly, I haven’t had the pleasure of working on a clean project like that outside of pet projects where I’m too inconsistent on my work ethic to judge it. lol


  • Ohh executing examples and whatnot in the comments/docs is a good idea. I know a few frameworks/doc tools try that at least on a component level, but of course when you involve whole extra tools, it’s sometimes a big learning curve cost even if the boilerplate/setup is trivial. That would be neat to have functional comment examples and formal unit tests at a language level.

    I think I tend to agree on bad comments. There has definitely been a few memorable occasions where I’ve axed multiple paragraphs of comments simply because they were old and a touch nonsensical after years of updates.

    Yea I cheated a bit by bringing in API documentation, but then in my defense a lot of that I also write, or at least write the formal comments that end up compiled in to those docs. lol It’s also still a bit true when digging in to libraries to contribute, though. If the inline comments suck, most will probably not contribute unless it really legible code. lol

    To me, there is almost always something worth documenting about a function, unless it’s boilerplate or just obvious data handling, of course. Though even then, if it’s at an app or library boundary, there is almost certainly some ‘why’ and limitations/etc to describe. After all, even basic CRUD at an API/app boundary will have multiple known modes of failure that have to be described somewhere.