armedgorilla

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.

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.

I interpret her marks—

as breathless pauses—

that— having no unicode—

should be given to m—

and space—

https://www.edickinson.org/editions/2/image_sets/12170035