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.
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.
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.
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.
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.