• 0 Posts
  • 99 Comments
Joined 2 years ago
cake
Cake day: October 23rd, 2023

help-circle
  • End-to-end ML can be much better than hybrid (or fully rules-based) systems. But there’s no guarantee and you have to actually measure the difference to be sure.

    For safety-critical systems, I would also not want to commit fully to an e2e system because the worse explainability means it’s much harder to be confident that there is no strange failure mode that you haven’t spotted but may be, or may become, unacceptable common. In that case, you would want to be able to revert to a rules-based fallaback that may once have looked worse-performing but which has turned out to be better. That means that you can’t just delete and stop maintaining that rules-based code if you have any type of long-term thinking. Hmm.


  • Yeah, that’s a good point. I guess in light of that what I would say is that, if you are going to have a state-run payment processor, you need to build in a) pluralism (enable and encourage multiple processors) and b) legal protections (legally guarantee that the payment processor has a limited remit in terms of allowing all payments unless instructed to block them by a court order) which would help mitigate or slow down anti-democratic backsliding.





  • Loads of people gave a shit.

    Doesn’t mean loads of people bought into him being a paedo.

    It’s like the pee tape. There’s not actual evidence for it, but people will buy into something like that regardless. Some tongue-in-cheek (because unlike CSA, it’s funny) but some seriously, and the tongue-in-cheek repetition of it also keeps it in people’s minds until some of them forget that there was never anything substantive.

    There’s never anything wrong with repeating the scummy things Trump has said, but condensing it into “Trump is a paedo” is drivel.







  • If your encryption is not a layer on top of a messaging service, you have to trust that the service you’re using is actually end-to-end encrypted. I point this out because it means that encryption is not a protection against he service not doing what it says it does, but rather it is a protection against other things: passing data to governments, having a hacker break in and leak it, that kind of thing.

    By storing stuff securely, it mitigates that problem, I guess. A government would have to have a “live tap” to know what you write to the LLM, rather than being able to slurp out all your historical conversations.





  • I once repaired my dishwasher. It cost me about £50 for a new pump, and many hours working out how to take the dishwasher apart and put it back together again. If I treated this as work, I would have been better off buying a new dishwasher, because I would have been paid more for those hours than the cost of a new dishwasher minus a pump.

    Appliances are cheap relative to wages now, and repair still takes a lot of time. That’s the simple answer.

    We have to consider why we want to encourage repair: it’s not simply true that we should always prefer to repair for its own sake. We should true to minimise greenhouse gas emissions or the use of resources that can’t be reclaimed, but not to the exclusion of all else.

    If we had a carbon tax for example, it would somewhat increase the price of new goods and promote repair. But such a tax would not cause people to repair everything reparable - there would still be reparable items that are not economical to repair. This is a good thing though - if the carbon tax correctly embodies the externalities of producing emissions, then the choice to not repair it is a choice to do something else with people’s time. That time could be used on other productive things - maybe working to replace dirty fossil fuel infrastructure, or working to feed or entertain people, which are all things we want.


  • It’s more about industrialisation making new products really cheap. Think about a pair of trousers. They’re exactly as repairable as trousers ever were, and you can still get your trousers repaired economically. But the cost of a minor repair will total about half the price of a cheap pair of trousers. So there is little point repairing trousers unless they’re expensive - you may as well buy a new pair if they’re cheap.

    This isn’t because of planned obsolescence, this is because clothing used to be far, far more expensive - you can come up with various multipliers but somewhere between 10x and 100x as expensive in terms of how many days of work was needed to pay for them. This is because industrialisation means that cloth and clothes can be made with a fraction of the labour as it did centuries ago.

    Sewing machines have also made repairs much more efficient, but to a far lesser degree - someone doing clothing repairs has overheads beyond the limited bit of work that is sewing up a split seam or rip, which are almost non-existent for the business producing clothes in the first place.

    So, if this is the case for simple items like clothes where repair itself is more economical nowadays, how much more true is it for complex items where each repair job is completely custom?



  • Either way gets me to a passing test, but I prefer the latter because it enables me to write another failing test.

    But you could just write that failing test up front. TDD encourages you to pretend to know less than you do (you know that testing evenness requires more than one test, and you know the implementation requires more than some if-statements), but no-one has ever made a convincing argument to me that you get anything out of this pretence.

    Tests should make changing your system easier and safer, if they don’t it is typically a sign things are being tested at the wrong level

    TDD is about writing (a lot of) unit tests, which are at a low-level. Because they are a low-level design-tool, they test the low-level design. Any non-trivial change affects the low-level design of a component, because changes tend to affect code at a certain level and most of those below it to some degree.


  • When faced with a failing test, you make it pass as simply as possible, and then you summon all your computer science / programming experience to refactor the code into something more elegant and maintainable.

    Why bother making it pass “as simply as possible” instead of summoning all that experience to write something that don’t know is stupid?

    TDD doesn’t promise to drive the final implementation at the unit level

    What exactly does it drive, then? Apart from writing more test code than application code, with attendant burdens when refactoring or making other changes.