A theory behind busting trusts is that monopolies stifle innovation, and thus growth, in the long term. When it comes to "competing with China" (which, to be naive, I'm not sure the meaning of), many nationally competing firms will have a better result for future consumers than if there were a single "national champion."
That's how the theory goes but I would argue the observable evidence says otherwise. TSMC is Taiwan's national champion and effectively a global monopoly, Samsung is the same for Korea and is highly effective on the world stage, same again with ASML.
When a country does what it can to support its key industries those companies often out compete their global rivals and this is exactly the strategy China is using against the west with their support of domestic electric car manufacturing, solar panels, battery tech.
Alternatively the west is often anti big business and we've repeatedly seen national championions go under.
I will watch this. Generally I think you raise a fair concern, and I appreciate the shade of nuance.
By "compete with China" I mean at least have parity of competition with China in the essential technologies of the future, rather than falling behind into some sort of obsolence or inability to shape the global economy we all on the whole benefit from. If China becomes the dominant economic hegemon without a viable American competitive check, I think the world (and certainly Americans) will be worse off.
Meanwhile, a balanced competition between the US and China I think will benefit almost everyone on the planet, for reasons likely not that unlike what I expect Lina Khan will say in that video. There is no perfect solution, so I will look forward to hearing more of her perspective on this issue, thanks.
From Moby-Dick, about spending three years at sea (Chapter 35):
"""There you stand, lost in the infinite series of the sea, with nothing ruffled but the waves. The tranced ship indolently rolls; the drowsy trade winds blow; everything resolves you into languor. For the most part, in this tropic whaling life, a sublime uneventfulness invests you; you hear no news; read no gazettes; extras with startling accounts of commonplaces never delude you into unnecessary excitements; you hear of no domestic afflictions; bankrupt securities; fall of stocks; are never troubled with the thought of what you shall have for dinner- for all your meals for three years and more are snugly stowed in casks, and your bill of fare is immutable."""
Thanks John. Neat to see you on the HN front page.
One LLM feature I've been trying to teach Alltrna is scraping out data from supplemental tables (or the figures themselves) and regraphing them to see if we come to the same conclusions as the authors.
LLMs can be overly credulous with the authors' claims, but finding the real data and analysis methods is too time consuming. Perhaps Claude with the right connectors can shorten that.
Thanks. I can guess who this is but not 100% sure.
Totally agree with what you're saying. This tool ignores supplemental materials right now. There are a few reasons - some demographic, some technical. Anything that smells like data science would need more rigor.
Have you looked into DocETl (https://www.docetl.org/)? I could imagine a paper pipeline that was tuned to extract conclusions, methods, and supplemental data into separate streams that tried to recapitulate results. Then an LLM would act as the judge.
You know who viewed the writing of history as political entertainment? Ancient Romans!
In SPQR, Mary Beard elaborates that much of what we "know" about ancient Rome was recorded by men with political projects. Sometimes it was to glorify the empire or republic; sometimes it was to grind an axe against their personal enemies (looking at you, Cicero). Then their records were often interpreted once again by scholars in the early-modern-to-pre-contemporary era where they became accepted history. (1)
So yes, Beard never conquered Asia minor and thinks women should be full citizens (unlike the Romans), but her scholarship is both informative and IMO entertaining. Perhaps moreso than ancient writers.
(1) Drawing the line at WWII when using Roman history as an example is a peculiar choice because the study and glorification of Rome was _very_ popular in certain European countries in the preceding century.
I'm in the same boat. Since they decided to bundle in their AI features with their core product (at only a 30% price increase!), I've been looking for an exist route. But finding a single collaborative text editor + database designer replacement has been difficult.
At a previous Biotech, we used Cromwell/WDL because the DSL was the most intuitive to our bioinformatics scientists. But seeing as that doesn't work as nicely on AWS (and is also supported by an organization that is imploding), we opted for Argo on our K8s cluster to process RNAseq data en masse. Getting the scientists to use YAMl has been an uphill struggle, but the same issues would apply to learning groovy I guess. We've found that the Argo engine is easier to maintain, and also we only have to support one orchestrator across our Bioinformatics and ML teams.
For industrial purposes, I've started to approach these pipelines as a special case of feature extraction and so I'm reusing our ML infrastructure as much as possible.
For both workflow languages, they are both better for building a singular reproducible workflow that can be published with an academic paper. For us, I'm looking for a workflow language that can treat the pipeline as a testable, deployable piece of software. I find that with Nextflow, scientists fall into bad patterns of mixing in the pipeline logic (eg if this sample type, then process it this way) interspersed with the bioinformatics model (eg use these bowtie2 parameters) throughout the pipeline which makes it more difficult to maintain as our platform evolves. Their K8s integration is lacking for both of them and they work much better an academic-style clusters.
YAML does leave a lot to be desired, but it also forces a degree of simplicity in architecting the pipeline because to do otherwise is too cumbersome. I really liked WDL as a language when I used to use that--seemed to have a nice balance of readability and simplicity. I believe Dyno created a python SDK for the Argo YAML syntax, and I need to look into that more.
I run a small software team at a small biotech working on diseases with small patient populations, and the answer is yes x 1000. The issue is that in drug companies, software isn't the product, so SWEs will never make as much money nor be as much of a priority as in tech-proper.
There are two categories of software we need help with:
1. Salesforce for science. We don't have big data in terms of volume; we have big data in terms of heterogeneity. Tons of small data sets that need context to be interpreted, including measuring uncertainty. This software, often called an eLN or LIMS, is offered by expensive vendors who each have their custom, locked-in implementations. Every organization needs customization on top of this that can be developed and change with the changing direction of the bench scientists.
2. Informatics tools. Much of the heavier computational tools (bioinformatics, molecular dynamics, stats) were developed by academic labs, who don't have the training or incentives to create sustainable software. Alternatively, they are made by vendors who write software on short-term contracts, so they don't have expertise in house. Our mass spec vendor told us to put their analysis servers on our Citrix so employees could access it. Citrix! If you can convince those vendor to hire you and rewrite their software, please do.
Despite cool tools like alphafold making headlines, the software needs in drug development are more mundane. We need people who are excited to sit down with bench scientists and help them figure out how very normal tools can be applied to their work.
Fortunately we have troves of her handwritten documents; all of her poems were first printed posthumously. To me, she's using the punctuation as pacing or tonal markers as opposed to ligatures ("I'll clutch— and clutch— " vs "I'll clutch-and clutch-"). Many publishers style these marks as longer than normal m-dashes for that reason, which makes sense seeing as they are rarely used as asides.
Em-dashes have been the norm in every Dickinson poem I read, and I think it might have derived from the preferences of Victorian publishers, who I understand loved those long dashes.
Here is an hour long video where Lina Khan makes this point to the Council on Foreign Relations much more cogently than I can: https://www.youtube.com/live/L_QaZk5iJOA?is=rk192CuSIBHLemsi
reply