Twisol

55 ms·

511.
by Twisol 5y ago
> With `%` to search across open tabs ... No way. That's my TIL for the day. Am I the only one who didn't know about this!?
512.
by Twisol 5y ago
> The former is with respect to the inertial frame of the faller(s), the latter seemingly with respect to the inertial frame of some shared gravitational field. Fair, and I'm not sure I follow that, either. I'm not sure how an
513.
by Twisol 5y ago
Programming is neither design nor implementation; it's a skill and a tool that isn't owned by a particular process. I am quite happy to sketch in code; I won't work with my hands tied behind my back. Concretely, what "in
514.
by Twisol 5y ago
It depends on what you mean by "design", but sometimes the best way to figure out what your options are is to throw something together and see how it feels. Could be UI, could be API design, could be a form of test-driven design.
515.
by Twisol 5y ago
Layperson here. As I understand it, if there were no bonds or repulsive forces between the atoms that made up Earth, they would all be in free fall, and they would all fall toward the center of the Earth's mass. Since these are inertia
516.
by Twisol 5y ago
> To do this, the researchers first had to characterize the scattering medium precisely. At Utrecht University, they shone light through a layer of zinc oxide nanopowder deposited on a glass slide. They then used a detector on the other
517.
by Twisol 5y ago
The body (at least, the fleshy parts) isn't terribly opaque to X-ray wavelength light -- the point being that opacity depends on wavelength. If you've got a (white) flashlight handy, you can stick your fingertip in front of the fr
518.
by Twisol 5y ago
> The result is a type focusing on callback transformation : > type BIO inp out = (Maybe out -> IO ()) -> Maybe inp -> IO () Huh, neat! Looks like profunctor optics to me. ("Callback transformation" is a really goo
519.
by Twisol 5y ago
> Gish gallop Thanks for that; I learned a new phrase ^_^ Yes, admittedly your post throws a bit of a wide net, but I think I see what you're angling for. > it raises the question of what the minimum necessary set of instructions
520.
by Twisol 5y ago
> Classical inheritance is not just a performance hack, it is semantically compelling I think often it's compelling for misleading reasons. For example, is a square a rectangle? Mathematically, yes. But in mathematics, we don't
521.
by Twisol 5y ago
Trait objects (via `dyn`) are virtual dispatching, but traits themselves are basically agnostic to static vs. virtual dispatch. If you use a trait method through a statically known type, the method is invoked statically -- no runtime lookup
522.
by Twisol 5y ago
No, because a proof (especially a human-constructed proof) is a finite object built out of basic pieces. The only question as to the validity of a proof is whether the basic pieces have been fit together according to the established rules
523.
by Twisol 5y ago
> I've never studied categories, but my reading of the parent comment was that a category was the combination of a graph and a seperate identification of paths within the graph in addition to the bare graph. Pretty much, yes. In gro
524.
by Twisol 5y ago
No, but it would be equivalent to verifying that a given computer program halts on a specified N steps. This is the same distinction between (among other things) P and NP problems. For any problem in P, given an instance of the problem I ca
525.
by Twisol 5y ago
I'm nervous that there might be a confusion between levels of abstraction here. Let me try to ground the terminology a bit, and see if that helps first. As a recognized term, "graph isomorphism" would lift to category theory
526.
by Twisol 5y ago
> I think the truth is that most math is pretty simple to describe and doesn't require a grand framework to formalize. I agree -- most fields of math are happy to establish their own axioms, and leave the reducibility of those axiom
527.
by Twisol 5y ago
> The main thing categories add to graphs is identifications of paths. There's another, very different way to describe "identification of paths", although I agree that both are fundamental to categories. What you've d
528.
by Twisol 5y ago
Hilbert's program was about whether every statement could be proved ab nihilo either true or false. The question remains: given a proof, can we verify it? Arguably, any proof conceived by a human mind should be verifiable in prin
529.
by Twisol 6y ago
It's definitely hard to argue against something so easy, right? At the same time, it's often really hard for people to grasp that a solution now might have repercussions later -- and even if they do, maybe they won't be aroun
530.
by Twisol 6y ago
Yes, sorry to pick on you specifically for that ;) In my admittedly limited experience, GraphQL is easier to get right than true REST, but obviously somewhat harder than a slapped-togther RPC API. I also like GraphQL better because if your
531.
by Twisol 6y ago
"RESTful" tends to be used as though it means "good" these days, as though the only good APIs are RESTful. I actually don't think RPC is a bad approach if it suits your problem domain, but designing an RPC API when
532.
by Twisol 6y ago
FWIW, my team has adopted GraphQL because it fits our domain needs better in a few ways. Our product is org-internal, so that might play into the choice a little bit.
533.
by Twisol 6y ago
> while REST is trivial. I'm not convinced of this -- or at least, we might use different definitions of "REST". The guy who created the concept of REST regularly (or used to regularly) call out common problems with "
534.
by Twisol 6y ago
And there's something to be said for batching -- if instead of requesting each resource individually, you ask for all of them simultaneously, the backend can see that context and fetch that data more efficiently. In something truly R
535.
by Twisol 6y ago
The best part is that he starts off with the "usual" one-based indexing, and then decides to change the indices because it suits his situation better. Us programmers mostly have to stick to the indexing scheme baked into our progr
536.
by Twisol 6y ago
I don't think so. Per the abstract: > All organizational functions carried out by classes can be accomplished in a simple and natural way by object inheritance in classless languages, with no need for special mechanisms. The paper r
537.
by Twisol 6y ago
I think their point is that if you have a convergent sequence of fractions, you can drop some finite number of them from the start and still converge to the same real number. In some sense, the rest of the sequence already contains all of t
538.
by Twisol 6y ago
Even those kinds of specifications don't compose well. For instance, if you have a solved problem, and you add a requirement, you don't really have a solved problem anymore, and the new solution may look extremely different from t
539.
by Twisol 6y ago
Sure, that makes sense. In some of the cases in this discussion, isn't the problem the compiler has to solve a little bit simpler? From (a) the indeterminate type of the result and (b) the invocation of a method on that value within th
540.
by Twisol 6y ago
> It's not like Java is any simpler. Can attest. It's easier to learn the rules of Java the language, but way harder to learn how to write good Java software . To some extent, Rust forces you to begin learning both at the same

More ›