> Given that the phrase “adjust the imports”—again, in a statutory
provision that did not use specific words such as “tariff ” or
“duty”—was unanimously held by this Court in 1976 to
include tariffs, and given that President Nixon had
similarly relied on his statutory authority to “regulate . . .
importation” to impose 10 percent tariffs on virtually all
imports from all countries, could a rational citizen or
Member of Congress in 1977 have understood “regulate . . .
importation” in IEEPA not to encompass tariffs? I think
not. Any citizens or Members of Congress in 1977 who
somehow thought that the “regulate . . . importation”
language in IEEPA excluded tariffs would have had their
heads in the sand.
The roll-call vote for HB7738 (IEEPA) was not recorded [2], so we seemly can't confirm today how any sitting members voted at the time. But there are two members of Congress remaining today who were present for the original vote: Chuck Grassley (R-Iowa) and Ed Markey (D-Mass). They clearly both agree with the Court, while having different opinions on the tariffs themselves.
Statement by Grassley [3]:
> I’m one of the only sitting members of Congress who was in office during IEEPA’s passage. Since then, I’ve made clear Congress needs to reassert its constitutional role over commerce, which is why I introduced prospective legislation that would give Congress a say when tariffs are levied in the future. ... I appreciate the work [President Trump] and his administration are doing to restore fair, reciprocal trade agreements. I urge the Trump administration to keep negotiating, while also working with Congress to secure longer-term enforcement measures.
Statement by Markey after previous decision in August [4]:
> Today’s ruling in the U.S. Court of Appeals for the Federal Circuit makes it clear that President Trump’s chaotic tariff policy is illegal. ... Today’s ruling is an important step in ending the economic whiplash caused by Trump’s abusive tariff authority.
N=2 is scant evidence, but it seems like both sides of the aisle "had their head in the sand", or Justice Kavanaugh's historical interpretation is a bit off.
In my research I take notes exactly as described here. I use plain-text files, one per week, with dated sections using markdown-ish notation where convenient. Display is never a goal; approximately 80-char column plaintext is the target format.
I agree with other commenters here that typing gives me more flexibility, in particular when writing arguments. I’ll format each point as a bullet and rearrange the list until I’m satisfied with the flow.
The notebook is essential for recovering tidbits learned along the way, e.g. what tricky steps did I need to get that one dependency to build. Weekly notepads are coarse enough to search by memory and contain enough context to get oriented quickly when going back several months.
I recall a paper from many years ago (early 2010s) describing methods to estimate the camera motion and remove motion blur from blurry image contents only. I think they used a quality metric on the resulting “unblurred” image as a loss function for learning the effective motion estimate. This was before deep learning took off; certainly today’s image models could do much better at assessing the quality of the unblurred image than a hand-crafted metric.
This is... hard to follow. You seem to be implying that Cloudflare is covering for USG's failed military op-sec surrounding a malicious BGP leak, and judging that this is such a bad action (on the part of Cloudflare) to undermine your trust, not only in Cloudflare, but in all companies and the US government entirely. I don't think the situation is so dire.
Cloudflare's post boils down to Hanlon's razor: a plausible benign interpretation of the facts is available, so we should give some scrutiny to accusations of malice.
Are there specific relevant facts being omitted in the article, or other factors that diminish Cloudflare's credibility? They're clearly a qualified expert in this space.
Let's assume for the sake of argument that the BGP leaks (all of them from the month of December, in fact) were the result of secret US military intelligence operations. The fact that militaries generally use cyber vulnerabilities to achieve their objectives is not news, and the US military is no exception. Keeping specific exploits secret preserves a valuable advantage over competitor states.
One could argue that Cloudflare's post helps to preserve USG's secrecy. We can't know publicly whether USG solicited the article. But even if we assume so (again assuming malice): Is Cloudflare wrong to oblige? I don't think so, but reasonable people could disagree.
Merely pointing out Hanlon's razor doesn't fundamentally change the facts of the situation. In Cloudflare's expert opinion, the facts don't necessarily implicate USG in the BGP leaks without an assumption of malice. Assuming Cloudflare is malicious without justification is just deeper belief in the conspiracy that they're arguing against.
If Cloudflare is distorting the facts, we should believe (rightly) that they're malicious. But I don't see any evidence of it.
> a quick introduction to a few modern Fortran features: declaring variables, printing and reading to and from the terminal, if and select case, and stop
Pretty much sums up this one. Can't say that I agree if/select/stop are "modern" features.
I’ve never heard of this. Are you saying I could enter “MyLocal Bank” as the payer name instead of my own when transacting online with a credit card? This seems like the kind of fact that should be essential privacy knowledge if true!
To be clear, I'm not disagreeing with antirez at all. I feel his argument in my bones. I am a smart programmer. I want simple, powerful systems that leave the kid gloves in the drawer.
The unfortunate reality is that a large cadre of people cannot handle such tools, and those people still have extremely valuable contributions to make.
I say this as a full-time research engineer at a top-10 university. We are not short on talent, new problems, or funding. There is ample opportunity to make our systems as simple/"pure" as possible, and I make that case vigorously. The fact remains that intentionally limiting scope for the sake of the many is often better than cultivating an elite few.
I am often responsible for landing branches created by colleagues who are less disciplined about their diff cleanliness than me. Very often, attempting to regroup a spurious change from an early commit to a separate "cleanup" commit results in a long conflict hell.
> many programmers are smart, and if instead of creating a magic system they have no access to, you show them the data structure, the tradeoffs, they can build more things, and model their use cases in specific ways. And your system will be simpler, too.
Basically my entire full-time job is spent prosecuting this argument. It is indeed true that many programmers are smart, but it is equally true that many programmers _are not_ smart, and those programmers have to contribute too. More hands is usually better than simpler systems for reasons that have nothing to do with technical proficiency.
Thank you for the many tool links! You seems to know this space well. I have come to pick your brain for more.
I have been searching for a while for good tools to split/regroup diffs in a patch series. hunk.nvim looks interesting. Do you know of similar/competing tools?
I frequently hit a problem where removing a spurious hunk from an old commit causes cascading conflicts in all subsequent commits. Are there tools to propagate hunk removal into the future without the manual conflict-resolution pain?
An underrated reason to remove eligibility testing is to make programs accessible for people in poverty. Navigating a means-tested welfare program is byzantine in the worst way-- accessing and submitting countless forms with confusing, often ambiguous or incomplete instructions; standing in long lines at specific times/locations far from the city center to get help or make progress; complete lack of process transparency; and dependence on faceless bureaucrats to decide your fate.
My family once had to navigate Medicaid. I was well-resourced, understood the expected outcome thoroughly, was motivated to get it done, and committed the time to follow the required process. When our initial application was mishandled due to inaccurate guidance, it took over 2 years of persistent failed communications with the various county, state, and federal agencies, back-office middlemen, doctors, and legislators to get any response beyond "apply again and hope for the best", which we did several times to no avail. In the mean time, having a Medicaid application open changes the availability of medical care, as some doctors will not or cannot by law accept additional Medicaid patients. Eventually by some mild social engineering I procured direct access to a specific empowered bureaucrat who had knowledge of a separate set of applicable rules/processes and resolved our case immediately.
Most people in poverty do not have the time, attention, or stamina to persist through means testing on top of struggling against whatever landed them in poverty in the first place. Every time I visited the county office, I would hear someone complaining about how they had applied 8 times without success for a program everyone in the room agreed they should qualify for. Means-testing is designed, by popular demand, to make accessing benefits difficult for the sake of spending less. UBI, for all its faults, at least addresses that problem.
I used Tcl at my very first internship for test automation. Coming from a self-taught Javascript/Java/C#/C++ background, Tcl really stretched my concept of what a programming language is, especially how it plays with stack frames and munges string values.
Coincidentally Tcl also inspired my first deep dive into Vim. The test automation framework at that company required meaty Tcl expressions packed into CSV cells. Tcl was mind-boggling enough when properly formatted, so hand-editing squashed 1800 character long expressions on a single line was way too much. I'm fairly certain the assignment was part hazing and the framework part "job security".
Jokes on them, I spent 2 weeks on a side quest to make a Vim plugin that could add line breaks and indent a Tcl expression into a split temporary buffer for editing and squash it back to the right cell when I was done. Halfway through the summer I had completed the entire backlog. The manager got a reprimand for being a jerk and I spent the rest of the summer making the framework less painful.