Hacker News Reader

The fundamental challenge of most engineering disciplines is attempting to create a model that represents a useful subset of reality but can be easily reasoned about and is, in some sense, reliable or reproducible. Perhaps what makes computer science unique is how unusually successful it has been in wrangling physics into a machine that appears to execute the laws of mathematics. Physics does rear its head from time to time (e.g. rowhammer and "single-event upsets"), but it is truly impressive how little we have to consider the physical nature of the machine nowadays.

However, other engineering disciplines do also try to build similar abstractions with varying levels of success. We've managed to build simple books of electrical standards that can be used by electricians around the world to build and reason about power systems without having to understand the weird quantum mind of an electron. I suspect we'll get there with biology too, we're just a century too early.

Computer engineering is literally designed to allow the most simple reliable substrate for the most complex possible abstractions to be built upon. It's bizarre (but common?) for computer science practitioners to be strangely unaware of how artificial the tools they use are. Then expecting the rest of the world to be as "simple" as their environment.

   logic: analog>digital
   gates: multi-level>binary
   timing: ripple>global clock
   architecture: logic>ISA/CPU/GPU
   memory: register/cache/disk>monolithic VM
   language: binary ASM>Compile/Interpreted
   memory/device: management interrupt loop>Kernel/OS
   Libraries, Frameworks, Virtualization

It goes on and on.

Semiconductor processing on the other hand is physics. Success is discovered rather than primarily designed. There are development tools, but things like the "pixie dust" used to avoid the superparamagnetic limit in spinning media were not understood for years after they were commercially shipped in hard drives. Biology/Pharma is much more complex/hit-miss and the biotech industry treats most employees quite badly.

This is exactly why I switched to computer science after finishing my biology BSc.

I don't get nightmares about analytic chemistry anymore, but the level of self-loathing you get from doing labs that never work out for reasons that defy understanding make the annoyance of debugging code seem quaint almost.

(I should really say "it used to", but now that I can run an LLM call locally and get a completely different response than the deployed version of a piece of software, with all other factors seemingly being equal...)

I too switched from biochem to CS: it was such a relief to work in a field where I felt that, as in math, you can get by remembering axioms and rules and derive the rest, without all the arcana of biology. (My mentor in biology bought me a copy of Barrow & Tipler as a parting gift, as if to say, CS and biology are not so different.) Today I’m not sure I still feel that way. Programming is more an empirical than logical discipline that ever before, as programs are too complex to be objects of pure reason; and the layers of stuff one needs to know keep growing in both directions, from SIMD to OAuth.

I’m so glad to come across this writer though. I was going to send them a note to tell them they have a real talent, until I noticed the long list of New Yorker and Atlantic publications, and thought: they already know. :)

Minor nit: the observer effect is distinct from the uncertainty principle, which says that two quantities like position and momentum (“conjugate variables”) cannot simultaneously be known to arbitrary certainty, which is to say, their wavefunctions cannot be simultaneously localized to arbitrarily small regions (of their respective spaces). This applies to any two functions that are Fourier transforms of each other, which position and momentum are (my terminology is sloppy here, but close enough to be useful), and has nothing to do with the change to a wavefunction that occurs by measuring it.

>the trouble comes from the fact that cells are too small, too numerous, too complex to analyze the way a programmer would, say in a step-by-step debugger.

It's like analyzing a Swiss watch if the back was welded on. You could send it though a shredder and analyze the fragments and work backwards to determine the size of the gears. But it's impossible to shred just one watch-- you have to shred a hundred thousand at a time, which are inevitably a complex mix of different watch models each with different minute lengths and hour durations.

Something I have felt is undertaught in introductory biology is how unknown human cells still are! No textbooks wants to list off a thousand proteins with "function unknown" next to them, after all. But to surprisingly large extent it's an undiscovered country. Just in the last few years we're discovering entire new species of RNA! https://www.science.org/content/blog-post/enter-glycornas

How big a factor is the fact that bio systems weren't designed?

It strikes me as the mother of all spaghetti code. Is it even possible to meaningfully look at parts of the human body in isolation?

Good point. It reminds me of an observation made by Paul Sutter in his podcast [0]. Paraphrasing, there so many layers of emergent phenomena, most of whom we will probably never figure out:

- From quantum fields to atoms

- From atoms to chemistry

- From chemistry to biochemistry

- From biochemistry to cellular life

- From cellular life to multicellular life

- From multicellular life to consciousness

- From individual consciousness to social phenomena

[0] https://podcasts.apple.com/en/podcast/ask-a-spaceman/id95882...

> For a computer scientist, a biologist’s methods can seem insane;

I actually use biological methods all the time, now that I'm a dev. For instance in Biology, gene knock-out experiments are common, where you damage or delete a gene, and see what breaks. You then know that this gene is important for a given thing.

This is the equivalent to the debugging approach of "if I comment out this code, what happens?"

Not to mention, you can also do things like fuzzing.

Mutation testing literally has a biological term in its name.

> Imagine replicates being a thing you have to think about when debugging a program. Like in software, running your code again with no changes after it just failed is insanity.

This is a common requirement in software QA. "Can we reproduce the issue? Does it happen every time? Is it sensitive to timing of user actions, or anything else? What part of the initial state of the system could affect this outcome? What other external or environmental changes will alter the result?"

Sometimes, the initial failure seems to have an obvious answer, and sometimes an immediate code change is the best first move. But replicating a behaviour does is insanity.