4 ms·

This in some ways evokes for me the worst of Google engineering and culture. It’s documented in a nice way and with a gentle tone, but it’s fundamentally a meth

by leoh 3y ago

This in some ways evokes for me the worst of Google engineering and culture. It’s documented in a nice way and with a gentle tone, but it’s fundamentally a method on top of broken behavior and a ton of tech debt. Yes, it’s not uncommon for folks engage like this in software; but once you’ve worked with individuals that think deeply about these kinds of issues and regularly, you start to see there’s another way.

klodolph 3y ago
What? Can you explain what broken behavior you’re talking about? Some things in concurrent programming can result in deadlocks. That doesn’t mean that you round off all the corners and take away all the dangerous tools until you’re left with a kiddie playground as a programming environment. No, instead it means that the more experienced programmers on your team keep a sharp eye on how concurrency / multithreading is used in your program.
- empiricus 3y ago
  When I needed to use this function, it was because the Android API to run things asynchronously using Handler.post()/remove() seems to be incomplete. You want to remove() a runnable, but maybe that runnable is executing in parallel exactly when you want to remove it. Depending on what you application does, this will cause various issues. The simplest way to fix issues in this case is to synchronize the threads using RunWithScissors. In short: the API is simple and easy to use, but it allows for strange cornercases, and you need a hack like RunWithScissors. That function is a hack because for various other reasons related to the rest of the API and the way it is implemented, it may block forever in some other cornercase. So maybe we can say this is broken behavior and an bad/incomplete API.
  - klodolph 3y ago
    That makes sense. Not making excuses for the API—but this does seem like a difficult design space to work in.
natnat 3y ago
As an xoogler, I don't agree at all. Google has a ton of problems, but a reluctance to think deeply about and fix tech debt isn't one of them. In fact, I think the eagerness to fix fundamentally broken abstractions is a big reason Google has so much code churn and is so eager to irresponsibly deprecate things that work!
freedomben 3y ago
I've never been a googler, but looking through this file, I would be really pleased if my company wrote that. I left Java altogether because "Java" became synonymous with "nightmare code" but I could live in the world of this source file.

by leoh 3y ago

klodolph 3y ago

What? Can you explain what broken behavior you’re talking about? Some things in concurrent programming can result in deadlocks. That doesn’t mean that you round off all the corners and take away all the dangerous tools until you’re left with a kiddie playground as a programming environment. No, instead it means that the more experienced programmers on your team keep a sharp eye on how concurrency / multithreading is used in your program.

empiricus 3y ago
When I needed to use this function, it was because the Android API to run things asynchronously using Handler.post()/remove() seems to be incomplete. You want to remove() a runnable, but maybe that runnable is executing in parallel exactly when you want to remove it. Depending on what you application does, this will cause various issues. The simplest way to fix issues in this case is to synchronize the threads using RunWithScissors. In short: the API is simple and easy to use, but it allows for strange cornercases, and you need a hack like RunWithScissors. That function is a hack because for various other reasons related to the rest of the API and the way it is implemented, it may block forever in some other cornercase. So maybe we can say this is broken behavior and an bad/incomplete API.
- klodolph 3y ago
  That makes sense. Not making excuses for the API—but this does seem like a difficult design space to work in.

natnat 3y ago

As an xoogler, I don't agree at all. Google has a ton of problems, but a reluctance to think deeply about and fix tech debt isn't one of them. In fact, I think the eagerness to fix fundamentally broken abstractions is a big reason Google has so much code churn and is so eager to irresponsibly deprecate things that work!

freedomben 3y ago

I've never been a googler, but looking through this file, I would be really pleased if my company wrote that. I left Java altogether because "Java" became synonymous with "nightmare code" but I could live in the world of this source file.