dllthomas

So, with... frequency?

> And for `hash.toUpperCase()`, it's a valid program.

In a sense, but it's not the program we wanted to write, and types can be a useful way of moving that kind of information around within a program during development.

> TypeScript is not designed to stop you from using string prototype methods on... strings!

No, but it is designed to let me design my types to stop myself from accidentally using string prototype methods on data to which they don't actually apply, even when that data happens to be represented as... strings.

But if we updated our standards such that we no longer accept those things, they would no longer be passable, and something else would be "just barely passable".

My point - inasmuch as there was a serious one - wasn't that we shouldn't raise our standards but that the framing isn't particularly helpful in determining whether we should (while rhetorically sounding like it is).

Are you saying that velocity hurts?

> I'm so sick of the fact that everyone is ok accepting "just barely passable"

Isn't everyone ok with that by the definition of "passable"?

> That might be possible in some supermarkets.

Yeah, I was going to say, it's worth asking.

That is a plausible explanation for a present correlation, but I think less so for when the correlation was first noted.

> hardly any different from debugging your own first draft

I find this take surprising. Leaving AI aside entirely, debugging my first draft seems very different than debugging your first draft.

> exactly the kind of engineering leadership a good C-suite would want to keep around and promote

... or, failing that, a different good C-suite might want to hire away from a less good C-suite.

My impression is that, at a place like MS, bugs are often reported by a separate team accountable to different metrics.

Ah, I wasn't trying to say those were the only two options, or that either was what you were suggesting. I also typically prefer other things.

I just find that "always squash the entire branch" is a common reaction to "history is messy" and I wanted to surface that (per my understanding) it doesn't actually improve the situation (vis-a-vis bisect in particular, assuming you're passing the correct arguments for your situation) over merging (no-ff, I neglected to specify...) branches where some of the commits do not build.

> Keeping all commit (including broken ones and subsequent fixes) in topic branches and then merging them without some squashing and rebasing gets in the way of that.

It seems to me that, with respect to bisecting, a merge workflow with git bisect --first-parent is equivalent to a squash workflow with a bare git bisect. Am I missing some way in which that's not the case?

All commits that will be shared. There's nothing wrong with a local WIP commit when you want to plant a flag to compare your next changes against.

Buildable and testable, but notably sometimes not formatted or linted, when (atypically but not rarely) the semantic change is much easier to understand separated from the superficial changes it motivates in the context of the formatting/linting rules of the project.

An easy to understand history that is correct about the relevant details... but "David didn't happen to run the formatter before his WIP commit that time" isn't ever going to be a relevant detail.

It's saved while it's in the reflog, and then saved until gc. How long things stay in the reflog is configurable.

The bigger deal is that things are never shared simply for being in the reflog - which is probably correct for its intended use but doesn't really fit what's asked for up thread.

> Customer co-ops are nothing like employee co-ops.

And agricultural co-ops are neither.

Yes, but note that those are typically neither worker co-ops (like Cheese Board or the components of Mondragon) nor consumer co-ops (like REI or a grocery co-op), but a cooperative association of businesses that are themselves typically very much not co-ops.

Tangentially, I once saw a list that gave "wunch" as a collective noun for bankers.

You have a point, but on the other hand "this was negotiated by an independent party" is one part of what was in front of them, and may've influenced the decision.

> I forget the term, but those silly terms like "pride of lions" or "murder of crows"

Collective nouns.

> in my opinion at least, are a bit harder to screw up, so I will always prefer them

My experience is the opposite - a sizeable chain of ifs has more that can go wrong precisely because it is more flexible. If I'm looking at a switch, I immediately know, for instance, that none of the tests modifies anything.

Meanwhile, while a missing break can be a brutal error in a language that allows it, it's usually trivial to set up linting to require either an explicit break or a comment indicating fallthrough.

I think you're correct that experience will differ substantially by context. I think your particular generalizations might hold enough to show up in a regression but there's enough other stuff going on (and noise) that they won't be tremendously predictive in individual cases.

I was a STEM major, did well at a reasonable school, and the only time I felt like I had way the hell more homework than I could get through was at a community college when I signed up for a Literature course and a Political Science course the same summer.

I think fuzzing is doing testing, but often using other techniques (including sometimes formal methods) to improve the effectiveness of that testing.

> 32 bits is a bit over 4 billion states, so that is doable.

Whether 4B is doable depends on how much work you're doing for each of those states, but yes, "4B" alone certainly doesn't rule it out. There's also a question of whether it goes with your most frequently run tests or is something that's only run occasionally.

> However a lot of algorithms can have more than 32 bits of states and so quickly get beyond what is doable.

I'm pretty confident we're all in agreement there.

> in general we should assume it is always impossible to exhaustively test programs

The whole program? Yes.

For testing individual components, there's no need to assume. The answer is very likely either clearly yes (the input is a handful of booleans) or clearly no (the input is several integers or even unbounded) and for those cases where it's not immediately clear (one i16? Three u8s?) it's probably still not hard to think through for your particular case in your particular context.

Formal methods aren't "testing".

As you say, though, exhaustive testing is sometimes possible.

> And substituting multiple different interfaces doesn't compose well (this is essentially the mtl problem).

I think you're talking here about abstracting over the underlying monad, with a different implementation for testing than for production. That can work well[1], but it's not what I was talking about.

With my Writer (nb: io., not Control.Monad.) example, how does Haskell make it harder? I'm not talking about replacing the underlying monad, but to define an interface in terms of that underlying monad.

Fleshing it out, something like:

    main :: IO ()
    main = flip runReaderT () $ do
        -- with Handle
        writeStrings stdout
  
        -- with IOVar
        var <- liftIO $ newMVar ([] :: [ByteString])
    writeStrings var
    liftIO $ print =<< takeMVar var

    writeStrings :: Writer w => w -> ReaderT r IO ()
    writeStrings w = do
        write w $ pack "oh hi\n"
        write w $ pack "uh\n"
        write w $ pack "bye then\n"

    class Writer w where
        write :: w -> ByteString -> ReaderT r IO ()

    instance Writer Handle where
        write w bs = liftIO $ hPut w bs
    
    instance Writer (MVar [ByteString]) where
        write w bs = liftIO $ modifyMVar_ w $ \ bss -> pure (bs:bss)

[1] A digression: Taking that approach, I think it's generally most comfortable to use a unique base type for each test (or natural clusters of them) and implement just the interfaces you need with an eye to the particular tests. The biggest problem I've seen is a tendency to push too much into that environment and thereby make too much implicit, which can make it confusing to distinguish and lead to things like the confused deputy problem.

Yeah, I wasn't really endorsing the program, just pointing out that "history doesn't belong in news" is a weird critique (not yours) of a history program.

> A news publication is not a replacement for history class and is probably one of the worst places to get a complete view of history.

Okay, but is it an okay topic for a history podcast like the one sobellian was apparently listening to?

https://www.npr.org/podcasts/510333/throughline