Kogasa

But something has to be written on the birth certificate and social security card, and that’s what everything else will expect you to use. I think just due to technical limitations (e.g. of the printer/template for those things) it wouldn’t be allowed, but I dunno about legally

Paru was at one point a rewrite of yay in Rust, and has since continued development as a pseudo parallel fork. It’s good. Dunno if it’s worth switching, you’d have to see if there’s any specific features you might happen to want, but they’re both fine

Yeah. Normal whoppers are crunchy. 1 in 4 whoppers is soggy and chewy and hard to eat

Whoppers are good but the risk of getting a bad one is not worth it. Ech

Status 200 for errors is common for non-REST HTTP APIs. An application error isn’t an HTTP error, the request and response were both handled successfully.

There may be a need for additional information, there just isn’t any in these responses. Using a basic JSON schema like the Problem Details RFC provides a standard way to add that information if necessary. Error codes are also often too general to have an application specific meaning. For example, is a “400 bad request” response caused by a malformed payload, a syntactically valid but semantically invalid payload, or what? Hence you put some data in the response body.

I’m speaking my truth. XR Adderall, crack em open and pour em on me tongue. The caviar of stimulants

My only time-release capsule is filled with little beads, I just pop it open and eat the beads like pop rocks

I’ve been taking 6+ pills a day for years and still can’t get myself to swallow them. I just chew everything. Tasty painkillers and caffeine.

This should be done with font ligatures, not replacing character combinations with other characters that can’t be typed normally

No, it isn’t

You’re making assumptions about the control flow in a hypothetical piece of code…

What you’re saying is “descriptive method names aren’t a substitute for knowing how the code works.” That’s once again just a basic fact. It’s not “hiding,” it’s “organization.” Organization makes it easier to take a high level view of the code, it doesn’t preclude you from digging in at a lower level.

You can’t disagree with the fact that Nullable<T> works a lot like an Option<T>. Returning an error is not idiomatic C# code (which would be to throw an exception usually) but if you wanted that, you’d use a Result<T, TError> type or similar.

Null pointers are one thing, C# nulls (with nullable reference types enabled) are another. They behave a lot like an Option monad with the caveat that the static analysis can technically be tricked by incorrect hints.

No, your argument is equally applicable to all methods. The idea that a method hides implementation details is not a real criticism, it’s just a basic fact.

No, not “almost every modern developer thinks inheritance is just bad.” They recognize that “prefer composition over inheritance” has merit. That doesn’t mean inheritance is itself a bad thing, just a situational one. The .NET and Java ecosystems are built out of largely object-oriented designs.

You realize this is just an argument against methods?

Java is a fine choice. Much prefer it over pseudocode.

Sure, but hosting the wiki itself has a cost.