I don't necessarily disagree with you, but I did want to point out that a big part of what made it possible for Word to displace WordPerfect in the legal world was, literally, the fact that Word implemented full support for WordPerfect's file format including all sorts of weird quirky edge cases.
So, an analogous "Word-killer" today would presumably have to implement all of the docx format's weird quirks etc. On the one hand, the file format is standardized and open, so in principle that should be possible; on the other hand, it's a pretty gnarly file format, with a lot of nooks and crannies. Ironically, I remember hearing once that some of the weirder nooks and crannies of the docx format have their roots in... Word's WordPerfect interoperability features.
And as somebody who recently spent far more time than he expected to trying to reliably get data _out_ of a set of mildly-complicated docx files, I can report that the various fiddly details that the OP notes as being particularly important in the legal domain --- very specific details of paragraph formatting, complex table structures, etc. --- are a huge PITA to deal with when working with the docx format.
Yes, exactly. A successor could theoretically replace Word, but first it needs to replicate all of its existing functionality.
For a competitor to supplant Word, it would need to:
- Be fully backwards compatible with .docx. Lawyers will inevitably receive .docx files from counterparties that they need to review, redline, and mark up. The new processor has to handle everything Word does flawlessly. (As an engineer who has spent considerable time building a high-quality docx comparison engine, I can tell you this is tremendously difficult.)
- If it introduces a new file format, support seamless comparison and conversion between that format and .docx. Not technically impossible, but also tremendously difficult with marginal upside.
- Defeat the Microsoft Office bundle in the market — meaning it either offers enough advantage that organizations pay for both, or it replaces Excel, PowerPoint, and Outlook too.
Given the enormous challenge of building a viable Word competitor and the marginal room for improvement that Microsoft has left on the table, I think it's very unlikely that a competitor will threaten its market position.
For certain legal use cases SaaS is still a non-starter due to security concerns so this hypothetical MS Word competitor would also need a native local application option. I don't think Google is interested in that market.
It seems to me as though you're reading a lot in to that second paragraph. Are you disputing the basic facts outlined, about "masked agents roaming the streets kidnapping people in broad daylight"? Because that is, in fact, a thing that is happening in cities all over the country right now, and simply pointing out that it is happening is not a partisan act.
This is good, in means we have checks and balances. I don't have the details of this particular case, but does it mean every action ICE takes is illegal?
If someone breaks the law ICE or otherwise, there should be enforcement and justice.
It really depends on the specifics of the clinical situation; for a lot of outpatient radiology scenarios the patient and radiologist don't directly interact, but things can be different in an inpatient setting and then of course there are surgical and interventional radiology scenarios.
Umberto Eco gave a pretty well-reasoned definition of Facism, and I think it's pretty straightforward to apply this definition to the situation in London (and DHH's commentary thereon): https://en.wikipedia.org/wiki/Ur-Fascism
Two points. First, the danger is very real, as the specific administrative mechanism for those final determinations involves political appointees outside of the regular scientific or program review processes, so who knows what they will or won’t understand or what sort of priorities they’ll be working off of.
Second, the programs you’re referring to (“diversity” meaning only people with the right skin color etc.) used a very clear and well-defined model of “under-represented minority” that (in addition to members of this or that minority racial or ethnic group) included women, people from rural zip codes, people who were the first in their families to go to college, people who grew up on free/reduced lunch, and a bunch of other categories that have long been known to be under-represented in science. This definition has been around for decades and there’s been a ton of research about the importance and efficacy of these kinds of programs, some of which are training programs to try and diversify the incoming pipeline of scientists, and some of which were additional funding pools to try and address the very, very, very well-documented gap in early career funding awarded to URM scientists. Characterizing it as just being about skin color is simply inaccurate.
Some of the other “DEI” research that has been terminated consists of projects looking at health issues that are specific to certain populations; the NIH has officially said that health disparities research is still allowed but we are all scratching our heads trying to figure out how to write grants for it that don’t run afoul of the current “rules” which are frankly nonsensical and very “vibe” based so it’s hard to know what will and what won’t be allowed. Almost like they don’t want us to bother trying…
Totally agreed, but I will just add, to your first point, it’s fine for priorities to change, but we do also have well-established statutes that define how changes in administrative rules are supposed to be implemented (eg the Administrative Procedures Act), and at least some of the lawsuits about grant termination have argued that those rules have been being ignored or outright turned inside-out. The district court judge’s written decision in the APHA v NIH case was quite detailed in his explanation of the many, many, many ways that the APA was grossly violated. So yes, priorities are allowed to change, but we have a system in place to manage that; otherwise we are, as Justice Jackson put it this week, playing Calvinball which IMHO is no way to run a country. At a micro level, it’s really painful to spend months writing a grant, more months waiting for it to come up for review, and then at the last second have it get administratively bounced because of new “rules” that didn’t exist when the grant was written or submitted (as happened to me earlier this year).
You are of course correct that it’s utterly bananas that in 225 we are wasting our time trying to guess which words shouldn’t be used in grant applications, and that our colleagues at the CDC and NIH are having to do the same for their papers.
To do those things, I do the same thing I've been doing for the thirty years that I've been programming professionally: I spend the (typically modest) time it takes to learn to understand the code that I am integrating into my project well enough to know how to use it, and I use my brain to convert my ideas into code. Sometimes this requires me to learn new things (a new tool, a new library, etc.). There is usually typing involved, and sometimes a whiteboard or notebook.
Usually it's not all that much effort to glance over some other project's documentation to figure out how to integrate it, and as to creating working code from an idea or plan... isn't that a big part of what "programming" is all about? I'm confused by the idea that suddenly we need machines to do that for us: at a practical level, that is literally what we do. And at a conceptual level, the process of trying to reify an idea into an actual working program is usually very valuable for iterating on one's plans, and identifying problems with one's mental model of whatever you're trying to write a program about (c.f. Naur's notions about theory building).
As to why one should do this manually (as opposed to letting the magic surprise box take a stab at it for you), a few answers come to mind:
1. I'm professionally and personally accountable for the code I write and what it does, and so I want to make sure I actually understand what it's doing. I would hate to have to tell a colleague or customer "no, I don't know why it did $HORRIBLE_THING, and it's because I didn't actually write the program that I gave you, the AI did!"
2. At a practical level, #1 means that I need to be able to be confident that I know what's going on in my code and that I can fix it when it breaks. Fiddling with cmakes and npms is part of how I become confident that I understand what I'm building well enough to deal with the inevitable problems that will occur down the road.
3. Along similar lines, I need to be able to say that what I'm producing isn't violating somebody's IP, and to know where everything came from.
4. I'd rather spend my time making things work right the first time, than endlessly mess around trying to find the right incantation to explain to the magic box what I want it to do in sufficient detail. That seems like more work than just writing it myself.
Now, I will certainly agree that there is a role for LLMs in coding: fancier auto-complete and refactoring tools are great, and I have also found Zed's inline LLM assistant mode helpful for very limited things (basically as a souped-up find and replace feature, though I should note that I've also seen it introduce spectacular and complicated-to-fix errors). But those are all about making me more efficient at interacting with code I've already written, not doing the main body of the work for me.
> State law does not require a woman to notify authorities when she miscarries, but Truman said that women who miscarry in West Virginia can protect themselves against potential criminal charges by reporting the miscarriage to local law enforcement.
>
> “Call your doctor. Call law enforcement, or 911, and just say, ‘I miscarried. I want you to know,'” advised Truman.
Now, in fairness, the state's association of prosecutors has clarified that this is not official policy and that the association as a whole does not support it. But it's definitely not out of the realm of possibility.
In the case of this specific post, it is unfortunately very appropriate to bring him up: his administration is enthusiastically setting back the US’s ability to study, treat, and cure cancer by years and possibly decades; his cuts at the FDA are setting back the availability of new therapies and his cuts to AHRQ and are undermining our ability to study whether the ones we have work; and his proposed budget would strip access to healthcare (including cancer screening and relevant preventative care) from tens of millions of Americans. Oh and his administration’s attack on higher education, and his immigration policies relating thereto, are gutting our scientific and biomedical workforces.
So while I am as sick as anybody about hearing about him, on a thread about advances in cancer treatments, it would be awfully weird to ignore the elephant in the room. Just sayin’.
Excellent point; the administration has a serious and well-publicized antipathy to mRNA vaccine technologies in particular, and has begun to suppress research in that direction. Given that mRNA vaccines are one of the biggest advances in vaccine technology in decades, and that mRNA-related techniques are key to many of the most promising methods for treating a whole host of rare diseases etc., it seems absurd that we would intentionally be seeking out agnotology in this space, but here we are.
So, an analogous "Word-killer" today would presumably have to implement all of the docx format's weird quirks etc. On the one hand, the file format is standardized and open, so in principle that should be possible; on the other hand, it's a pretty gnarly file format, with a lot of nooks and crannies. Ironically, I remember hearing once that some of the weirder nooks and crannies of the docx format have their roots in... Word's WordPerfect interoperability features.
And as somebody who recently spent far more time than he expected to trying to reliably get data _out_ of a set of mildly-complicated docx files, I can report that the various fiddly details that the OP notes as being particularly important in the legal domain --- very specific details of paragraph formatting, complex table structures, etc. --- are a huge PITA to deal with when working with the docx format.