Microbe computers
stanmed.stanford.edu
stanmed.stanford.edu
http://openwetware.org/wiki/ChIP-Chip_E._coli
edit:
found this: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2989930/
BioCoder, a C++ library that enables biologists to express the exact steps needed to execute a protocol. In addition to being suitable for automation, BioCoder converts the code into a readable, English-language description for use by biologists
Its built on the cloud with NodeJS & MongoDB. Runs right in the browser.
Check it out. Its free.
:-)
I don't mean to insult the people who work on the tools currently- they're great! But we need more software people writing tools for the industry.
Fortunately, people are starting to do just that. TeselaGen and Genome Compiler are both good examples. (Disclaimer- I'm a TeselaGen engineer)
To give an example, I once witnessed an algorithmic redesign effort completely miss two extragenic components in an essential gene that would likely not have been missed by an attentive human (or better yet two or three attentive humans). Luckily, the cells evolved their way around it, the researchers tracked down the problem and how the bugs solved it and the situation is interesting enough to possibly result in a publication.
Clean, well-documented source code won't get you grants. It won't yield citations. It won't get you tenure. Beyond making sure you can run the same code again, and it works if the postdoc who wrote it leaves, everything else is under the "For the good of humanity" incentive structure. And with grant paylines in the middling single digits, its really hard not to triage good code in favor of making sure the lights stay on.
But it took years for your (now typical) OS, server, and Internet open source projects to reach maturity and figure out how they can be monetized.
People in the sciences should start blogging more. People like me find all of these subjects very interesting but very foreign. And I think many of us have grown a bit bored with where most programming efforts are directed (backoffice, ecommerce, and social apps).
1. Keep in mind for most projects and papers, not very many people are ever going to use the source code. For most projects, there's almost no chance that you're going to get a lively, multiple contributor project going. Odds are it's just going to be on your shoulders.
2. If you're going to stay in academia, there's no level of bragging rights to an awesome project, and it won't particularly help your job prospects - indeed from an opportunity cost perspective, most of the time it will hurt them. Once the code is good enough for a paper to be written, the incentive to do more work on the code vanishes.
3. Science blogging is actually a pretty active field. But talking about the software aspects of code don't get talked about as much because its just a tool. There are some blogs on software for science drifting around out there though.
Yes, There have been demonstrators of biological computing and circuits, but from a functional perspective they are extremely limited, especially compared to in vivo systems. Put a different way, even if we can do complex "computation" in a cell, our understanding of the "I/O" is too superficial to design systems to treat diseases or act as devices. The failure of rational drug design over the last 20 years has taught the pharmaceutical community this lesson quite harshly.
Understanding the interfaces and mechanisms that our "biological computers" will work with will require more research in fields like structural and molecular biology, and this work will take time.
With that said, there are some useful systems we can engineer in the meantime; for example, biosynthesis pathway work is well underway. Just realize that these systems don't require substantial engineered computation.
This is spot-on correct. In the lab I worked in, we are working on a gene cluster of 11 genes, that result in the assembly of an enzyme that creates hydrogen. The PI's project was to play around with "promoters" that tell the bacterium to produce the genes. Think of this as 'script kiddie' work. I came in and immediately told him that this was the wrong approach; we had to alter the structure and chemistry of the enzymes themselves (think of this as 'assembler-level hacking'). Thankfully he was sympathetic to my argument and let me play around; I achieved a 3x improvement in enzyme activity. This summer,we tested the original idea, and all of the variants we tested were worse than what we started out.
Also, and this is my highly opinionated position informed by my experience as the sole chemist in a synthetic biology lab, but part of the problem is that a lot of biologists tracked themselves into biology because they didn't do so hot at chemistry. Many synthetic biology problems are chemistry problems, and even problems that are not on first blush like those that Drew Endy are trying to solve really become easy to grok if you're used to thinking qualitatively in terms of statistical thermodynamics and can mentally estimate collisions per nanosecond, from concentrations and kinetic parameters. These are quintessentially chemistry skills.
reference: https://www.ncbi.nlm.nih.gov/pubmed/23819621
Thinking like this is awesome when it happens: a lab I worked in would combine structures of motor proteins with single molecule studies, targeted mutation work, and even in-vivo studies. The result? You could take specific loops and helices within the motor and not only understand where and how they interact with a microtubule, but also how that affected the motor's mechanical action and cellular behavior.
Another real problem is we don't teach students anything anymore on the premise that there's too much to know, and as long as you can look it up, it will be fine. Or if you are working interdisciplinarily, your colleague will be able to tell you (of course they're relying on you too so there's a bootstrapping problem). This is terrible. Sometimes you need to call someone on their bullshit, say during a lecture, or even more importantly during a meeting where actionable decisions are being made and critical insight can avoid wasting time and effort. If you don't have a significant depth of knowledge, which multidisciplinarity typically doesn't encourage - because it's hard - you are just a body making warmth in that room. You need to have instant recall of as much related information as possible at all times when doing science.
Doubling transistor density on silicon will end about 2020/22, when 7 or 5nm etching occurs - beyond that and chip designers are past the wavelength of red (?) light and into quantum tunnelling effects
But ...
maybe the amount of CPU cycles available to use for a given bi-annual price will keep doubling. More efficient systems on a chip, cooling in huge data centers means Siri can keep doubling its ability to run voice analysis on my behalf?
is that true?
3. is there genuinely any chance things like bio-computing?
Memristors
Graphene
3D Chips
Optical Computing
Spintronics
Quantum Computing
and I'm pretty sure I'm forgetting a couple of other promising paths to extending Moore's Law.
Microbe computers strike me more as a path to nanorobotics.
Let's also not forget Paul Jaschke! http://www.researchgate.net/profile/Paul_Jaschke/ He was able to design and produce a working refactored version of the PhiX174 bacteriophage.
Refactoring in bio has the typical CS connotation of cleaning up messy code -- The natural PhiX174 has some overlapping genes that cannot be edited in isolation -- The refactored version has no gene overlaps, so the genes can be editted individually in a more rational manner.
Adventures in Synthetic Biology
That is the comic I read a Synthetic Biology REU at Princeton. At that point, Drew Endy was at MIT and our leader Ron Weiss was at Princeton.
People have shuffled around a bit in 7 years http://openwetware.org/wiki/Endy:Lab http://groups.csail.mit.edu/synbio/