Ask HN: What do you wish someone would build? It's time for another go at this question; we had interesting ideas the last time. What do you wish someone would build, either for your personal use or for your business? |
Ask HN: What do you wish someone would build? It's time for another go at this question; we had interesting ideas the last time. What do you wish someone would build, either for your personal use or for your business? |
- Offline DNA and epigentic methylation (this is almost already a thing with MinION, just not real time) [1]
- proteins, nutrients, enzymes, known and unknown chemicals found in blood, urine and stool samples
- Full spectrum breakdown of lipoprotein into particle sizes and types. (sdLDL-P, ldLDL-P, full lipid panel, A1C)
- Hormone levels in blood (All hormone types)
- Antibody tests, WBC/CD4 count, cytokines, etc..
- Preferences to set different unit measurement standards.
- Ability to export to a USB memory card in json and text output on exFAT or ext4 formatted drives.
All of this without requiring any connections to the internet. This would be for me, not a business. I suspect there are businesses that could use this too. They could submit the json output into a cloud site assuming legal compliance, etc...
Devices would be for rough preliminary screenings, to avoid repeated outsourced labs until red flags appear and to adjust dietary intake and exercise for optimal levels. Primary audience for this would likely be professional athletes, body builders, health enthusiasts, biohackers. I would pay good money for something like this. Less than 90% accuracy is fine for some tests provided it displays the estimated accuracy or range.
[1] - https://phys.org/news/2021-01-method-pocket-sized-dna-sequen...
Sept 2016 - https://news.ycombinator.com/item?id=12567645
Dec 2017 - https://news.ycombinator.com/item?id=16023507
Oct 2011 - https://news.ycombinator.com/item?id=3163554
April 2016 - https://news.ycombinator.com/item?id=11592228
Photos would be a good starting place for this, since they are easy to fingerprint.
I guess making sure the quality is high would be tricky. I imagine somehow pledging a certain amount, say $5 or $10 (or the whole amount if you want) towards the job, then the money is paid to the person who does the job, when they complete it.
It could even be a community effort. I helped translate some things on viki.com years ago, there was a huge community effort, it was great..but it seems all that work disappeared.
This is a fairly big undertaking, including at least:
- A standard for representing and installing grammar information. Perhaps a file in /usr/share/grammar/ for each programming language, packaged in each language's own tools. Since not all languages are context free, the format must support more advanced grammars as well, at least indexed grammars, maybe more. Perhaps grammars should be able to depend on and extend each other (e.g. HTML can have a JavaScript node), perhaps they definitely should not.
- A new text-based diff/patch format that is less line based so that the difference can be communicated on a more semantic level, while still retaining exact reproduction i.e. B = patch(A,diff(A,B)). Add and delete should probably still be the only supported operations, but maybe not.
- A standard for representing semantic weight. The patch operation is deterministic but diff is not, i.e. given A and B, there are many possible patches that, applied to A, would correctly produce B. The job for the diff tool is to find a patch that both is guaranteed to correctly produce B, and as closely as possible describes the difference the same way a human would. Example: In Python, removal of an If condition and promotion of the contained 100 line code block should not be represented as delete 101 lines and as 100 lines. Rather, it should be represented as delete 1 line and delete 100 indents, on the correct level. The semantic weight information that allows diff to choose the best representation in most cases, might be produced using ML. Imagine a collaborative effort to produce training data using commits from open projects, where in most cases a human would simply select the patch candidate that is most easily understood. The semantic weight representation would probably have concepts for other operations than add and delete.
- The actual patch and diff tools. Patch implements only the patch format and has no dependency on grammar or semantic weight data. Diff is where the effort lies. Perhaps some languages are not best served by the generic approach with grammar and semantic weight. In these cases, diff should be pluggable. Perhaps /usr/share/diff can contain configuration for each language e.g. whether it uses a certain grammar and semantic weight file or a custom binary. It also needs some way of detecting which language to use for a certain file.
The vast majority of version control information (including git) is snapshot-based, meaning that among the many possible patches from A to B, none is preferred by the version control data. We are completely free to improve the way our tools select these patches, and it will be completely backward compatible with the existing wealth of version control history. We'd just be able to look at it with more clarity.