You make a very good point, and maybe a problem here is that “human factors studies” are set up like market research rather than anthropology.
People who’ve spent a long time programming have spent a long time optimizing everything about their work, and they’re willing to talk about it (most of them won’t shut up about it, even).
For some reason you're willing to drop the context.
He's talking about people coming through the border without being vetted, who are dangerous to the country.
Do you think that people should be able to come into the country freely without any vetting at all?
He was pointing out a specific problem, maybe your imagination turned that into the much more general "all immigrants are bad" when he's never actually said or suggested anything of the kind?
> If you say "they're eating the dogs, they're eating the cats, we have to clean up our country" then... yeah you're getting pulled into HR.
Trump was just repeating the same thing that many other people heard, a resident at a town council meeting in Springfield, Ohio claimed that some group of migrants there had eaten someone's pets.
Was it true? Who knows? People tend to repeat a lot of things they hear but haven't verified themselves. For example in that same debate, David Muir falsely repeated the lie that crime was down nationally. Do we take David Muir to HR?
That kind of obvious logical inconsistency, coupled with the assumption of moral authority (which for whatever reason seems to be the subtext for so many of these conversations), rubs a lot of people the wrong way.
> And sure, it’s weird Hunter was involved but it’s also weird the guy who brags about being rich still won’t show us his tax returns […]
You’re so quick to drop the question of the Biden family’s involvement in Ukraine and you pivot to Trump’s tax return, but the billions of our tax dollars and lives lost in Ukraine now make that a MUCH more important issue than Trump’s tax returns.
Congressional investigations blah blah blah, obviously they can’t get anywhere. Trump was impeached for trying to get information right from the source, and it was very stupid. We should get that information, hopefully he takes another shot at it. We’ll see what happens.
Eh, maybe he shouldn't have been impeached for that call. President Biden's son had a strangely lucrative position, which he appeared not to be qualified for. And Biden was very involved in pressuring the Ukraine government to fire a prosecutor who was investigating that same energy company. There's a lot of public corruption in Ukraine, which was one of the factors leading to the election of their current president (according to what I've heard anyway).
This doesn't mean that Biden is definitely corrupt, but it does look very suspicious, and seems worthwhile to investigate. Our country is sending a lot of money to Ukraine. We deserve to know everything here.
I made something like this for Morgan Stanley some years ago, a structurally typed eager variant of Haskell with static elimination of type class constraints (so no runtime penalty for overloading) and uses LLVM for the back-end:
http://github.com/morgan-stanley/hobbes/
We used it for processing and analyzing billions of events per day. Using structural algebraic types let us encode market data (obviously) but also complex data structures inside trading systems that we could correlate with market data.
As you say, Haskell-ish expressions are much more compact and capable than SQL, which was one of the reasons I wanted to build it.
It also had a somewhat novel compression method (“types as probabilities” if you like the old Curry-Howard view), which was very important to manage billions of daily events.
> if you want to claim "forall x in X, P(x) is true" then you need to exhibit a particular element of x for which P holds
I don’t mean to be pedantic (although it’s in keeping with constructivism) but in the case you describe, you don’t have to provide a particular x but rather you have to provide a function mapping all x in X to P(x). It may very well be that X is uninhabited but this is still a valid constructive proof (anything follows from nothing, after all).
If instead of “for all” you’d said “there exists”, then yes constructivism requires that you deliver the goods you’ve promised.
I’ve always wondered why SQL doesn’t support variant types, and in this case especially.
If you’re going to store a sequence of values whose type can change over time, a variant is the obvious encoding choice. As new schemas are introduced, you add constructors to the variant.
On top of that, you can apply some basic structural reasoning to say eg a field can be indexed (possibly by different paths in each case) iff it exists in each constructor, or optionally with the awkward SQL nulls in case a field is not in each constructor (as they describe in the paper).
But then you could also use general variant deconstruction to decide on a case-by-case basis how to handle each version or subset of versions of a schema, and having that capability to represent variants in user data, independent of “evolving schemas” could have significant general use as well.
If you feel like having tuples and variants is too complicated, use dependent sigma types, so they’re all tuples, and then your schema language is much more expressive still.
It’s weird how much database systems have stagnated on this front.
I hear different opinions about whether type checking is "an" instance of abstract interpretation (AI) or "the" instance (which IMHO is a useful question since we might consolidate our efforts on one method if possible).
This article does a very good job of laying out typical examples motivating AI as a concept.
But the process of attributing points in the AI lattice to expressions does look a lot like type inference (and the AI lattice itself does look a lot like a type hierarchy).
Does this point to a slightly different approach we should take to type systems? For example, suppose the type of '1' was not 'int' but rather '1' (a type runtime equivalent to unit, but carrying its information at compile-time), and that 'add' is overloaded on input types so that it can either directly compute its result (also then statically knowable) or emit instructions to dynamically compute its result if its arguments are only dynamically known.
Is that the meta lesson here? Should we be using more detailed/nuanced type systems?
Yeah, some maintenance projects have been much easier than others. Implicit knowledge that you have to “just” hunt down is generally the cause of difficulty and delay. It has little to do with “purity” and more to do with not wasting my time.
Have you ever inherited a 1MLoC codebase that you yourself didn't write from scratch, or worked on a large project with at least one other person? How do you know what the side-effects are and where they happen when you aren't intimately familiar with the code you're interacting with? That's the whole point of making effects explicit and available for analysis in the type system.
> Lists and trees can be fully captured by sum and product types, but extending this representation style to DAGs and graphs doesn't work--you either get inefficiency (for DAGs) and then infinite regress (for cyclic graphs) attempting to continue the "syntactic" style of representation
You also need "inductive" recursive types to represent lists and trees, in addition to sums and products.
One way of representing the type of a list of T is like:
mu X.1+T*X
(Hence sum and product types, but also inductive or "least fixed point" recursion.)
But you can also use "coinductive" recursive types to represent "processes" (or "greatest fixed point" recursion) with almost the same notation:
nu X.1+T*X
This represents a FSM which at any point yields either a termination (the "1" on the left side of the recursive sum) or a value and a continuation (the "T" in "T*X" is the value and the "X" in "T*X" is the continuation).
This doesn't answer every question about graph representation, obviously, but it's a useful tool for attacking some graph problems you'd like to represent "syntactically" as you say (though you have to think in terms of "coinduction" instead of "induction" e.g. bisimilarity instead of equality).