Teenager's sickle cell reversed using a treatment to change his DNA - <AUTHOR> http://www.bbc.com/news/health-39142971 <comment><USER3> After adenoviruses proved to be dangerous [1] I wonder what sort of virus they're using now?

[1] [https://en.wikipedia.org/wiki/Jesse_Gelsinger](https://en.wikipedia.org/wiki/Jesse_Gelsinger)

Are doctors allowed to use gene therapy in life or death conditions now? In the trial for fixing OTC deficiency that Jesse Gelsinger died in they only administered the trial to people who were capable of living with the disease as opposed to the babies that were going to die in their first year without it. The idea was that a parent faced with the possibility of their child dying painfully couldn't possibly refuse the treatment and therefore couldn't give informed consent.

<comment><USER4> > The idea was that a parent faced with the possibility of their child dying > painfully couldn't possibly refuse the treatment and therefore couldn't give > informed consent.

Well ... I get the idea, but I am not sure this is rational. If I have the choice between pizza and no pizza, and of course everyone would choose the pizza, my choice is not uninformed, just because it is too good of a deal.

<comment><USER5> The idea is that they would agree to anything, including things which has low likelihood of success and could be traumatic to the child simply because the known downside was too great.

People aren't very good at comparing a terrible known condition A, to a merely potentially terrible known condition B.

</comment></comment></comment><comment><USER6> Will this change potentially be transmitted to his children?

<comment><USER7> Unfortunately, human germline modification is still taboo here: [https://motherboard.vice.com/en_us/article/scientists- argue-...](https://motherboard.vice.com/en_us/article/scientists-argue-the-us- ban-on-human-gene-editing-will-leave-it-behind)

It angers me that a misguided and stringent sense of ethics might slow the deployment of one of the most beneficial technologies ever conceived.

<comment><USER8> I agree with this, but not a popular opinion. Hence the down votes you are getting. Korea and China don't have the same memetic immune response to such ideas, injecting one's children with growth hormone in hope of increasing future job prospects, for example, is extremely common in Korea. I suspect embryo selection and generic engineering for increased IQ will take off in East Asia first. Then we will be forced to allow it to compete. 50+ more IQ points looks very possible: [https://arxiv.org/abs/1408.3421](https://arxiv.org/abs/1408.3421)

However, any significant lag could spell the end of American economic dominance. For this reason, I intend to start investing more in Korean firms in the next few decades.

<comment><USER9> A better way to increase iq would be to raise the socioeconomic level...

<comment><USER8> Nope. Genetic engineering works far, far better. We've already plucked the low hanging fruit of adequate nutrition, early education, salt iodization, and lead reduction. Anyway, those reduce mental retardation, they don't improve the baseline too much. And the Flynn effect looks to be slowing or reversing. 50 IQ points is huge. It's the difference between a burger flipper and a physics professor. The change to the world when the average 5th grader is mastering chromodynamics is hard to even contemplate.

<comment><USER10> People in Flint, Michigan still don't have clean water. Lots of other folks in the world also don't have clean water. Doesn't that seem like an easier thing to fix than trying out experimental therapies?

<comment><USER11> This might particularly interest you: [http://www.lettersofnote.com/2012/08/why-explore- space.html](http://www.lettersofnote.com/2012/08/why-explore-space.html)

The gist of it is, in 1970 someone asked a director of NASA why billions of dollars were being spent on exploring space when millions of children were still dying on Earth. The response in part explained that NASA's R&D was paving the way for satellites with better weather forecasting, better communications, and better equipment that was making its way into people's everyday lives. While a bit morbid to say, the advancements made by NASA have arguably saved many more lives in the long run.

It's hard to see the point in investing in experimental technology whose payoff is unknown, especially when we have definite problems with feasible solutions. That doesn't mean we shouldn't try. The possible payoffs - <USER2> cures, age prolongation, enhanced food production, disease and sickness prevention - that can come from investing in gene therapies are just too great to ignore.

As a side-thought, the technological singularity is thought of as the point at which we create an AI smarter than us, triggering a run-away effect of self- improvement. What if we end up doing it to our own race first through intelligence-improving gene modification? Can you imagine the implications of applying that intelligence to solving the rest of our problems?

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Is this using CRISPR or some other method of editing the DNA?

<comment><USER13> This treatment does not use CRISPR. It involves the hollowed out and repurposed lentivirus (similar in kind to HIV)[1]. The virus keeps it's own viral 'insert-into-DNA' machinery, but is stripped of its replication machinery as well as the code for its physical shell. The insert-into-DNA machinery is further hijacked so it can insert nothing but the DNA that encodes for the new mutated hemoglobin (HBB [T87Q][2]) that, when the patient's cell reads that new DNA will produce a new version of the protein. That insertion machinery with its new payload is loaded into a viral shell in a lab somewhere (again, its replication machinery and the code for new shells has been gutted).

When this new virus is given to the patients it does indeed infect the patients' cells. It uses its viral machinery to insert itself into the genome of the patient, more or less randomly - and that is not ideal. CRISPR systems are much newer and are being worked on right now, but the technologies you see in use in this article predate CRISPR. CRISPR will only speed up what was here a monumental (and slightly more risky) effort.

Regardless of how the code gets inserted into the genome (lentiviral in this case, CRISPR likely in future therapies), the instruction set to produce the new protein is not only capable of doing the job of the broken hemoglobin, but actually enables the broken hemoglobin to regain some of its function, likely coming very close to actually curing the patient.

In computer terms, someone with sickle-cell disease has a typo in the source code that leads to a buffer overflow error in the oxygen transport module. We found stuxnet can inject live code into a running OS, so we stripped it of its payload, it's ability to replicate but kept its injection capabilities and gave it our hot-fix as its payload. Our patch will be injected into billions of running nodes, inserting a ~500 line patch randomly into the each node's memory stack (yes, that's scary - but if a few of the nodes (cells) go down, it's not a horrible problem, and the current price of doing the patch at all... CRISPR can help here in future versions). That new code provides not only an alternative oxygen transport package, but this new package, so long as its running on >20% of the nodes, actually forces the original code's memory to periodically flush, thus de facto correcting the original typo's overflow bug - allowing both the new package and the old (kinda bug-fixed) package to both now be useful oxygen transport code. No more bug = cure.

The patients had a code regression, and we're applying not just a 1.0 fix, but a very real 1.1 patch on the human hemoglobin instruction set (randomly, into live code, on millions if not billions of cells, using modified HIV technology).

Diagram of the patch's entire injected instruction set (8.5kb): [https://www.ncbi.nlm.nih.gov/core/lw/2.0/html/tileshop_pmc/t...](https://www.ncbi.nlm.nih.gov/core/lw/2.0/html/tileshop_pmc/tileshop_pmc_inline.html?title=Click%20on%20image%20to%20zoom&p=PMC3&id=4779296_fig-3.jpg)

[1] Lentivirus: [https://en.wikipedia.org/wiki/Lentivirus](https://en.wikipedia.org/wiki/Lentivirus)

[2] The 'updated' hemoglobin: [https://serotiny.bio/notes/proteins/hbb/](https://serotiny.bio/notes/proteins/hbb/)

<comment><USER14> CRISPR is typically delivered via a lentivirus.

<comment><USER13> The lentivirus has a number of capabilities - insert into cell, insert into DNA, replicate payload, build capsid, encapsidate payload, escape cell. In this particular case the lentivirus was used both for it's 'insert into cell' as well as its 'insert into dna' capabilities - with all others being stripped.

CRISPR (more specifically, Cas9) is another protein machine that locates particular DNA sequences [1]. It can help take over from the lentivirus with respect to the 'insert into dna' capability. But you're right, we still have no better way to get it into the cell than to use a (lenti)-virus's own 'insert-into-cell' machinery. So a lentivirus might be used along with CRIPSR in order to just get CRISPR machinery into the cell.

This is further muddled by the fact that _sometimes_ you actually want the dna that encodes for your CRISPR system to itself be inserted into the genome, and in that case you might keep both the lentivirus's 'insert-into-dna' machinery AND the CRISPR's own 'insert-into-dna' capability.

At the end of the day, lentivirus's capability to insert into DNA is not predictable, and therefore a bit dangerous (if it inserts its payload in the middle of an oncogene in a predisposed cell you could get cancer). CRISPR is a device which promises to bring specificity to the command, making it 'insert- into-dna-AT'. And in that way it could replace the job of lentivirus in the above gene editing technique.

[1] Cas9: [https://serotiny.bio/notes/proteins/cas9/](https://serotiny.bio/notes/proteins/cas9/)

</comment></comment></comment></comment><comment><USER15> here is the nejm paper in the article: [http://www.nejm.org/doi/10.1056/NEJMoa1609677](http://www.nejm.org/doi/10.1056/NEJMoa1609677)

<comment><USER13> Ultimately, they are delivering a payload with a slightly modified version of wild-type hemoglobin (a single point mutation from wild-type). Patients with sickle-cell disease have a (different) mutation in their hemoglobin that causes the hemoglobin protein to aggregate, and not carry oxygen. The modified version being delivered to patients is _not_ just a 'corrected, wild-type' version of the protein capable of carrying oxygen more efficiently, but actually carries a synthetic mutation that actually prevents the patient's version from aggregating. So if even 20% of the hemoglobin in the treated patient's blood is of this modified type, then none of their hemoglobin will aggregate, and they should get much of their oxygen-carrying capacity back. This modification to the introduced version of the protein also allows it to be easily identified and tracked to monitor things like its concentration.

The actual sequence and mutation HBB [T87Q] protein: [https://serotiny.bio/pinecone/part/10803](https://serotiny.bio/pinecone/part/10803)

A short little writeup I did about the mutation: [https://serotiny.bio/notes/proteins/hbb/](https://serotiny.bio/notes/proteins/hbb/)

A very detailed presentation about Bluebird Bio's therapy (called LentiGlobin BB305) provided to the government: (PDF warning) [http://osp.od.nih.gov/sites/default/files/1164_bluebirdbio.p...](http://osp.od.nih.gov/sites/default/files/1164_bluebirdbio.pdf)

</comment></comment><comment><USER16> "He no longer requires a transfusion so we are quite pleased with that"

I like that language so much more than, than the increasing THIS IS AMAZING, SO AWESOME, WHAT WE GREAT GUYS ACCOMPLISHED!!! even though it would fit here much more, than in the usual context people use it fore ...

<comment><USER17> I don't think I have ever seen medical professionals speak in the manner you described.

<comment><USER16> I did not say that, I was talking about other tech branches, startup hype speak etc.

<comment><USER17> Aha my mistake.

</comment></comment></comment></comment><comment><USER18> Would this apply to thalassemia too?

</comment><comment><USER19> Total noob here, is this type of treatment going in the direction of something like in the movie gattaca? Would gene editing also help fully grown adults?

<comment><USER20> Real life gattaca would be quite boring. Protagonist would have failed practical aptitude tests or some such.

<comment><USER5> He cheated. He had a heart condition but faked his heart rate for the testing so he would be allowed to go into space.

Yes, he could run at the same pace as someone with a better heart, but he was predisposed to arrhythmias even at a normal level of effort.

</comment></comment></comment><comment><USER21> What an amazing achievement. Finally, the promise of genetic therapy is starting to actually emerge from the lab.</comment>


The case of the 500-mile email - <AUTHOR> http://www.ibiblio.org/harris/500milemail.html <comment><USER2> Reminds me of the bug: "Open Office won't print on Tuesdays". That was posted here on HN a while back - see the comments for some other interesting bugs. [https://news.ycombinator.com/item?id=8171956](https://news.ycombinator.com/item?id=8171956)</comment>


Why collision avoidance is harder for an AI-based system - <AUTHOR> https://medium.com/@rebane/could-ai-have-saved-the-cyclist-had-i-programmed-the-uber-car-6e899067fefe <comment><USER3> Hang on. That argument makes no sense. We've had subsumption architecture for a long time now( [https://en.wikipedia.org/wiki/Subsumption_architecture](https://en.wikipedia.org/wiki/Subsumption_architecture) ). Subsumption architecture puts some of the intelligence in the lower level systems. While the higher level controls can tell the lower level systems what it wants, it can't do things that the lower system determines is dangerous.

So if a normal Mercedez has a collision avoidance system that automatically brakes, there is no reason why an AI based system can't be built on top of that and the collision avoidance system automatically braking without intervention from the higher AI systems. A subsumption system prevents higher level controls from doing something catastrophic like hitting a pedestrian or, in biology, a person holding their breath until they die.

<comment><USER4> Very true. Which is why I'm still waiting for what happened to all the lower level safety systems, presumably driven by lighting invariant LIDAR or RADAR systems, in the Uber situation.

The article kind of mentions: "cyclist detection from 3D point cloud is much harder task than cyclist detection from an image"

The system didn't need to know that it was a "cyclist". There was something there, in its path. Stop.

<comment><USER5> In fact, the XC90 is already equipped with a radar-based emergency stop system from factory - that alone would have been 100% sufficient to prevent or vastly reduce the impact. But of course it looks like the system was disabled/overriden by the Uber's autonomous solution.

</comment></comment></comment><comment><USER6> This is looking at it all wrong. Watch Chris Urmson's video from SXSW on how Waymo does it. I've mentioned that before. You build a map of what's around the vehicle. Then you try to tag some obstacles to help predict their behavior. But the obstacle detection is geometric, and does not depend on the tagging, which uses machine learning. If there's an obstacle, the system doesn't hit it, even if it has no clue how to identify it.

Tesla/Mobileye managed to get that backwards. Their original system was "recognize vehicle visually, compute distance and closing rate to vehicle". If it didn't recognize an obstacle as a vehicle, it ignored it. We know this for sure, because you can buy a Mobileye unit as a dashcam-like warning device and many people have seen how they work. That led to three collisions with vehicles partly blocking the left side of a lane. One death ramming a street sweeper, one collision with a stopped fire truck, one sideswipe. The NTSB is investigating the fire truck collision.

The NTSB is now investigating the Uber collision.[1] As they usually do, the first thing they did was to get control of the wreckage.[2] Uber does not have control of the investigation. The NTSB investigators are working this like an air crash. They are "beginning collection of any and all electronic data stored on the test vehicle or transmitted to Uber". As usual, they haven't announced much, but they have mentioned that the video seen publicly is from a third-party dashcam, not the vehicle sensors.

[1] [https://www.ntsb.gov/news/press- releases/Pages/NR20180320.as...](https://www.ntsb.gov/news/press- releases/Pages/NR20180320.aspx)

[2] [http://wsau.com/news/articles/2018/mar/21/arizona-police- rel...](http://wsau.com/news/articles/2018/mar/21/arizona-police-release- video-of-fatal-collision-with-uber-self-driving-suv/)

<comment><USER7> Devils advocate here, but what if a supposed "obstacle" is a plastic bag or a jet of steam coming out of a sewer grate?

<comment><USER8> Then you stop. Type 2 errors for cars are much less dangerous than Type 1 errors.

<comment><USER7> Unless it's icy out, you have to swerve, or you're being tailgated...but yes, stopping (or at least attempting to stop) is the best decision from a liability perspective.

<comment><USER9> Well that's when you're grateful that along with your forward collision prevention, your car's ABS and electronic stability control systems are also still enabled.

As for tailgating, this seems to be a problem with U.S. attitudes, not vehicle mechanics. Stop making it acceptable to tailgate! If you're close enough to the vehicle in front of you that any significant braking on its part will cause you to hit it _you are too close_ and it's _your fault if you hit it_.

<comment><USER10> Isn't that the case in the US? In the EU, you can be fined for driving too close to the car in front of you.

I think that driving close to the car in front of you is the number 1 cause of accidents. Much more dangerous than driving fast.

<comment><USER11> Legally, in most (if not all) of the US you /can/ be cited for tailgating (the laws require a minimum following distance).

Reality is that the traffic cops seldom ever cite for tailgating in general. If one were to see a citation for such, it is likely after an accident where the officer can deduce that the cause was "following too closely" and so they then issue the citation.

<comment><USER9> In Australia, if you are the rear vehicle in a rear-end accident you are automatically at fault in almost all circumstances. The only exceptions I know of are if the front car pulled out immediately in front of the rear car, or if the front car was reversing.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> > Also, lets back up our AI's with old school collision avoidance! > Intelligence is not the same as perfection, at least for now.

The car was travelling at 38mph and never braked. Even if the collision- avoidance only saw it at the last moment it would still have braked and potentially slowed the car enough so that the woman was injured instead of being killed.

I'm all for self-driving and fully believe it can improve on humans, but I don't see how it's possible for self-driving cars to be on the road if they can't properly detect the most vulnerable users in all conditions.

<comment><USER13> This is absolutely a case where an autonomous system should have out-performed a manned system. Lasers see through darkness very well. A camera-only system is insufficient.

<comment><USER14> Not to mention it wasn't even very dark on the road. If you look at other video and images, that stretch is very well lit. The dash cam video was poorly calibrated / selected (but probably not used in the decision process of the AI).

</comment></comment></comment><comment><USER15> If the technology were as undeterministic as this post makes it seem to be, there should not be any self driving car allowed even under the best conditions.

I fully agree that an AI can be fooled, but that is high level logic (path planing), the system should be designed to have a fallback that does emergency braking if all else fails.

There simply is a point where the high-level AI does not matter any more. And that is if I (the car) am moving at 45 mph towards an obstacle that is in the middle of the road less than 2 meters from my projected path. This does not mean that a full brake is required but the speed definitely needs to be reduced to account for the uncertainty, and once it is determined that it is physically impossible to miss the obstacle the system must do a full stop to reduce the impact velocity as much as possible.

It's fine, if the LIDAR data is plugged into a machine learning algorithm, and you will probably get less than the 10-20 Hz the scanner can produce, but at the same time it is probably also used by a much simpler obstacle tracking algorithm that can run at near real-time speeds.

<comment><USER16> Right; if we want to compare it to ourselves, maybe the various minds that control our impulses. We can hold a knife over our finger with our high level cognitive mind, but (hopefully) our low level brain will prevent us from bringing it down and chopping our finger off, even if we _really really_ wanted to do it.

I know that's sort of a weird example, but I think it's really illustrative of a dual/multiple mind scenario playing out in our own understanding.

<comment><USER15> Or reflex.

We act on an input on a lower cognitive level first before a higher level function even has the chance to intervene.

If someone is throwing a ball at my face, my body hopefully reacts before my higher level functions had the chance to evaluate if the ball will really hit the face and if I may look silly if I wave my hands in the air while no actual danger exists. Because it actually IS on a trajectory to my face the benefit far outweigh the risk of looking silly

</comment></comment></comment><comment><USER17> > AI is not preprogrammed to monitor a known input from a sensor to take a > predefined action.

I guess one of my outstanding questions, which reading this only confirmed, is _why_ this is the case? I mean, humans are pretty good examples of intelligence. And yet we still have and use these anti-collision systems. Because, in the end, when wrong decisions are made these systems save lives.

Why would AI-driven vehicles _not_ have dedicated, single-purpose subsystems such as anti-collision? I mean, are we going to also remove ABS, because the AI could learn to modulate the brakes itself? How much are we going to push into AI, when the purpose-built systems are both functional and effective?

<comment><USER18> >I mean, are we going to also remove ABS, because the AI could learn to modulate the brakes itself?

This is the topic that I feel SDC enthusiasts forget. Not everything HAS TO BE AI. And we could maybe make steps towards SDC, not fantastic leaps that get people killed and really just get government involved where it doesn't need to be yet.

We could replace the ABS/ESP/traction control systems in current vehicles with a machine learning / deep learning system absolutely - that's not sexy though!

No one wants increments, they want whole self-driving cars right now - <USER2> while I have opinions about that, there is no doubt it's driving (pun intended) the industry.

Ideally, at first, we'd see components in consumer vehicles, and completely automated long haul trucks from A to B determined routes - but like I said, not sexy.

<comment><USER19> > Ideally, at first, we'd see components in consumer vehicles

We do, though. Look at the cruise control or auto-park on a vehicle produced in the last few years. The totally autonomous car may make headlines, but these sorts of features will be what really make the technology ubiquitous.

<comment><USER18> I work on ECUs like this. High end stuff is doing computer vision, but 99% of what is on the road is pre-calibrated motor/solenoid control and that's all.

Even adaptive cruise, steel camera object "detection" are just pretty simple systems. Almost nothing is doing even pieces of what the whole-package SDCs are.

</comment></comment></comment></comment><comment><USER8> I am freaking sick of this notion that AI==ML. AI is a much bigger field than neural nets. AI can be _programmed_ with rules, with logic, with symbols, with subsumption, and with a thousand other things that are both deterministic and don't require huge training sets.

If you're making a living doing AI, you damn well should know this.

<comment><USER20> If you define AI like that, then basically every decision making program, i.e. with branches, is AI.

<comment><USER21> how else are you going to include pacman's ghosts as using AI?

<comment><USER20> You shouldn't because those ghosts are stupid.

If intelligence just means "can make decisions based on inputs" then everything is intelligent. That's a useless definition.

</comment></comment></comment></comment><comment><USER22> I'd like to see a law that says: to obtain certification to operate a self- driving car on a roadway, an organization must agree to:

1) Conform to a standard set of protocols for how sensors provide data to a self-driving software system.

2) Log data in a form that could be submitted to any conforming self-driving software system, to obtain results from that system reporting what the system would do given these inputs.

With this in place, it would be easy to do after-the-fact comparisons of data leading up to incidents, and learn from the differences in results between systems.

It could be taken a step further if the car makers would also share data on near misses, which could uncover cases where other car makers' systems did not handle the situation as well.

Even if the sensors are different, I suspect some good mileage could be gotten out of this. The fact that learning opportunities are not perfect, is not always a good reason to pass them up.

<comment><USER23> Perhaps some sort of logging standard that is enforced across all systems? A black box of some sort?

<comment><USER22> Yes, exactly, but with the additional factors I mentioned.

</comment></comment></comment><comment><USER24> My educated guess: The somewhat unusual shape of the combination of the woman and the bicycle, combined with the uneven lighting caused the vehicle to misclassify her as lightweight road debris.

To a real degree, this is a downfall of machine learning. Every distribution has tails. If we learn purely from data, rather than from principle, we will necessarily make mistakes on the tails. For problems that can be effectively solved with 99% accuracy, this is fine, and we just deal with a few mistakes. With more data, our accuracy will improve anyhow.

If a datapoint costs a human life though, we can't afford to collect enough data. We must have a more sophisticated model of the world in order to operate on the tails without killing people.

I think that this might actually be a watershed moment for ML. Supervised learning is not adequate to this type of task. Either the computer does low level perception, and a human writes a high level algorithm to manage the risk, or datapoints have to contain a lot more information than just safe/unsafe. When you made a mistake as a child, your parents didn't just punish you, they explained what you did wrong and why, and a rule to follow to do better next time.

<comment><USER25> > misclassify her as lightweight road debris.

Surely the classification has a confidence level, and a low confidence score should cause the vehicle to slow down if it's not confident in knowing what it's looking at? Also, the size of the "lightweight road debris" should have made the vehicle slow down slightly at least, because hitting a 6ft pile of paper wouldn't be great at even a low speed

</comment></comment><comment><USER26> I don't know what would have happened if "this guy programmed it", but the answer should be _yes_ , the car should have seen the cyclist and it should have pressed the brakes.

This was an interesting post, too, by Brad Templeton who worked on Google's self-driving car project for a while:

[http://ideas.4brad.com/almost-every-thing-went-wrong-uber- fa...](http://ideas.4brad.com/almost-every-thing-went-wrong-uber-fatality- both-terrible-and-expected)

<comment><USER27> in response to that piece by Brad, I sincerely hope that the "safety" driver in the uber accident was fired.

<comment><USER28> Why? If it is not proven the driver was negligent why fire this individual? Presumably this individual has a lot of experience and domain knowledge in testing self driving cars so replacing them with someone else may not be an improvement.

If they did make a mistake that got someone killed that could change things but I would hope we wait to find out if the driver was actually at fault.

<comment><USER29> I don't think Uber's safety drivers have any domain knowledge. The law says you need bodies in seats so Uber is paying as little as possible to put bodies in seats. They aren't engineers or professional (as in stunt/trick/etc) drivers.

<comment><USER28> I'm not sure stunt or trick drivers are the best choice anyway but you make a good point. Do we know this individual's qualifications or are we just guessing at Uber's standards?

</comment></comment></comment></comment></comment><comment><USER18> Has anyone been able to even remotely explain why the LIDAR system wasn't going nuts? I saw the "it was dark" nonsense, but I assume this vehicle had laser and IR right?

The camera footage was released, I'd like to see the lidar representation.

<comment><USER30> Author here :) LIDAR itself is just a sensor, it does not process the data nor does it output a directly usable image like a camera more or less does.

LIDAR in this case is a rotating laser and while it scans, the vehicle moves (imagine moving a paper when a copier scans it). All processing is done later, first to construct an image and then to understand and use it. Part of why I wrote the piece was to explain how things can go wrong even if your LIDAR works fine.

<comment><USER31> You don't have to "construct an image" to use LIDAR returns. Minimal processing on the point cloud will tell you that there's an obstacle, and you don't need more than that to start trying to avoid hitting it. A simple occupancy grid map, for instance, would suffice.

[https://en.wikipedia.org/wiki/Occupancy_grid_mapping](https://en.wikipedia.org/wiki/Occupancy_grid_mapping)

<comment><USER32> The problem with naive occupancy grid mapping from sparse LIDAR data is that things like birds, falling leaves, pieces of paper of plastic bags flying in the wind can mark the grid occupied.

Emergency breaking for all these cases would be very dangerous. The same object must be scanned multiple times to get the idea if the object is something to be avoided.

<comment><USER31> Quite true -- but LIDAR has a very high refresh rate, and it's not hard to do better than naive grid mapping. This was a full height pedestrian plus bicycle, which would have multiple nice returns from a Velodyne HDL 64 at these distances.

</comment></comment></comment></comment></comment><comment><USER13> Either the author works on toy systems, or is being disingenuous.

These are not problems with AI, they are problems with using _only_ AI, and no viable-for-development system that I'm aware of in industry does that.

</comment><comment><USER33> They should release all of their sensor data and logs from the incident, and then some of us could actually _answer the question_ in the headline.

This should be standard procedure for any future incidents.

<comment><USER34> The NTSB has control of the investigation and the data for now. _That_ should be standard procedure IMO.

</comment></comment><comment><USER35> Why isn't car driving AI put to the same rigour of testing and approval as that of airplanes? There are far more people on the road than in the sky, and yet, there's formal verification for airplane autopilot code but an accident like this is supposed to be "you couldn't have prevented it either?"

If no one could prevent such a thing, this AI should never drive a car!

<comment><USER36> More rigor is definitely required, but it may not be possible to formally verify AI driven code to the same extent. Aviation software is driven from formal requirements, has a strict set of coding rules, and the generated assembly code is compared to the original source code. Within the coding rules, the software isn't even allowed to dynamically allocate memory.

I have no idea how you'd build an AI system with those constraints, given that the computer essentially programmed the model itself by learning.

</comment></comment><comment><USER37> This guy seems specificially talking about a certain style of ai approach.

</comment><comment><USER38> I admit I stopped reading halfway through, but managed to scroll to the last paragraph.

This article is a dance through many important topics in a AV. Yet, it fails to actually answer the "Why collision avoidance is harder fo an AI-based system" question, really. Some arguments argue that systems with a smaller scope are easier, systems with a larger scope are more difficult, it brings on arguments about determinism in decision making. It brings on sensor sets, neither is really about AI or hand-crafted rules, but about problems inherent to robotics as a whole. Again, it is a fine example why the therm AI is useless and harmful for discussions, as it blurs what is talked about considerably.

</comment><comment><USER39> Unpopular question but here goes:

What if some crashes are unavoidable? e.g. somebody darts out in front of a mobile vehicle. We accept that trains are not at fault for striking "trespassers" on their railways.

Also, when we all drive cars with collision avoidance systems, who gets sued by whom? If my car e-brakes for no reason and I get rear-ended, is the guy who hits me still at fault like usual?

I believe computer control will be super helpful and is here to stay, but it's interesting to see it implemented in cars as emergency help versus in modern commercial airliners (where autopilot and landing control systems are ubiquitous) when it is only relied on for the most routine and straight-shot ability.

<comment><USER40> > If my car e-brakes for no reason and I get rear-ended, is the guy who hits > me still at fault like usual?

What's different about your SDC slamming on its brakes vs you doing the same thing? That's why the law says how much spacing is to be between cars!

> What if some crashes are unavoidable?

From all evidence which is publicly available at this time, it appears this accident was anything but unavoidable, so the question is a red herring.

</comment></comment><comment><USER41> All I'm going to say is that I could tell this was a Medium post by the title...

<comment><USER42> I couldn't, but I could immediately tell once I clicked and the page was half- covered by persistent sharing dickbars. -.-

</comment></comment><comment><USER43> The author writes a long text about how this is "not as easy for an autonomous system to solve" just to make the obvious point at the end of the article.

It should be obvious to anyone that you need to compose systems of different criticality to build a safe autonomous vehicle.

Of course the "AI" system needs to be complemented with a safety critical auto brake and other fail safes.

</comment><comment><USER44> I've been really interested in exactly this question - the technical drive to revisit moments when contingency (and tragedy) emerges. I've been working on an artwork around this, "Iterated Accident", which I just put online this morning, [http://darkmttr.xyz/16/](http://darkmttr.xyz/16/)

</comment><comment><USER45> This is shoddily written bunk. I would downvote if I could. Object detection from LIDAR/Radar data plus path planning is 'AI-based', and I guarantee you Waymo's systems (which are 'AI-based', though more old school and less ML based) would have done collision avoidance better than Uber.

</comment><comment><USER46> This is an extremely unconvincing argument

</comment><comment><USER13> I smell a straw man argument.</comment>


Designing a Programming Language for the Desert - <AUTHOR> https://futhark-lang.org/blog/2018-06-18-designing-a-programming-language-for-the-desert.html <comment><USER2> How close is Futhark to being considered production-ready? How close is the generated code to hand-optimized OpenCL for real problems (I did look at the benchmarks, but only the Rodinia suite had comparison numbers, and those are trivial to beat)?

OpenCL is easy to write for anyone who knows C (far more people than fans of functional programming) and moderately difficult to write decently well. What's the value proposition of Futhark? Is it just that some people prefer writing in a functional DSL rather than C, or does it purport to enable some optimizations that are hard to write well manually?

<comment><AUTHOR> > How close is Futhark to being considered production-ready?

It's not 1.0 yet, and there are ways to trip up the compiler by accidentally writing irregular code (and the workarounds are nonobvious), but several people have used it productively (albeit non-production by most standards). Addressing this is part of the research we're doing, and we are quite sure we know how to get there.

> OpenCL is easy to write for anyone who knows C (far more people than fans of > functional programming) and moderately difficult to write decently well. > What's the value proposition of Futhark? Is it just that some people prefer > writing in a functional DSL rather than C, or does it purport to enable some > optimizations that are hard to write well manually?

In principle, a skilled GPU programmer can always outperform Futhark. The value proposition of Futhark is partly that you can obtain decent code without having low-level knowledge (usually within x2 of hand-written performance), and partly that even a skilled GPU programmer can get there much faster. Most low-level GPU languages (like OpenCL and CUDA) make it very hard to write code that is both fast _and_ modular. For example, you might write some really nice CUDA kernel that operates on vectors, but there is no obvious way to apply it to every row of a matrix - probably you will have to write a new kernel from scratch; one that is very similar to the old one, but without direct code reuse. In Futhark, you would just 'map' the old function over the matrix, and let the compiler figure out how to turn it into one or more segmented operations.

Essentially, the Futhark compiler is not bound by the restriction that the optimised code should be maintainable by humans, so it is able to use inlining, duplication, fusion and a host of other transformations that are helpful for performance, but no sane programmer would write if they cared about the maintainability of their code.

In practice, Futhark usually gets beat on single primitive operations (matrix multiplication, FFT, etc), but at an application level, it tends to do well.

<comment><USER2> Thank you for the detailed response. I'll try to allocate a weekend to port some of my usual scientific GPGPU test cases to Futhark and see how it goes.

> Most low-level GPU languages (like OpenCL and CUDA) make it very hard to > write code that is both fast and modular.

That's absolutely true, which is why a frequent solution is to achieve modularity by using simple metaprogramming to generate kernel code from higher level constraints. I understand Futhark aims to obviate at least a subset of these issues, so there's value there.

> Essentially, the Futhark compiler is not bound by the restriction that the > optimised code should be maintainable by humans, so it is able to use > inlining, duplication, fusion and a host of other transformations that are > helpful for performance, but no sane programmer would write if they cared > about the maintainability of their code.

Am I correct in assuming that you can still (easily) obtain, inspect and profile the Futhark-generated OpenCL code using the usual tools? I suppose a sensible workflow could be using Futhark to get as far as you can and then hand optimize the bottleneck kernels further.

> In practice, Futhark usually gets beat on single primitive operations > (matrix multiplication, FFT, etc), but at an application level, it tends to > do well.

Do you happen to know of any scientific/engineering applications (lattice Boltzmann methods, molecular dynamics, etc.) using Futhark in the wild? From a quick glance at the website it seemed like all of the applications are focused on image/video processing, any reason for that?

<comment><AUTHOR> > Am I correct in assuming that you can still (easily) obtain, inspect and > profile the Futhark-generated OpenCL code using the usual tools? I suppose a > sensible workflow could be using Futhark to get as far as you can and then > hand optimize the bottleneck kernels further.

Sort of. Futhark generates pretty simple OpenCL host code, but there is not yet an obvious way to tie the generated kernels back to the original Futhark source code. As a result, it's easy enough to detect that some specific kernel is the bottleneck, and often also why, but it can be a bit of a puzzle to connect it to a part of the original program. While you _can_ in principle edit the generated kernels yourself, it's not code that is at all nice to read or modify.

> Do you happen to know of any scientific/engineering applications (lattice > Boltzmann methods, molecular dynamics, etc.) using Futhark in the wild?

No. Closest are simple things like nbody[0] simulations.

[0]: [https://github.com/diku-dk/futhark- benchmarks/tree/master/ac...](https://github.com/diku-dk/futhark- benchmarks/tree/master/accelerate/nbody)

> From a quick glance at the website it seemed like all of the applications > are focused on image/video processing, any reason for that?

Not sure. Most of these are stencils, and while Futhark does alright with stencils, it doesn't do anything particularly clever (no hexagonal tiling, for example). Maybe it's just that they are easy and satisfying to write, because you trivially get something visual at the end.

Futhark's design was originally inspired by nasty financial algorithms (the ones from the FinPar suite[1]), which tend to be a combination of Monte Carlo methods and differential equations. I'd say that is Futhark's main strength.

[1]: [https://dl.acm.org/citation.cfm?id=2898354](https://dl.acm.org/citation.cfm?id=2898354)

</comment></comment></comment></comment><comment><USER3> These DSLs for high performance parallel computing based on purely functional algorithm descriptions are very exciting- halide and accelerate are similar projects. I can see as the demand for writing parallel, portable code increases technology like these becoming essential tools.

<comment><USER4> What applications?

<comment><USER5> Most algorithms related to computer vision and image processing come to mind. Of course there are efficient libraries written in general-purpose languages, but DSLs could lead to smaller, easily maintainable codebases.

</comment></comment></comment><comment><USER6> tl;dr futhark is a DSL for transpiling non-graphics parallel submodules for other programs. Which is to say, if one were to write a N-queens futhark program, it could create C, C#, or Python modules for use in a larger program that would leverage OpenCL for parallelizing the chess moves.

This blog post declares some culture boundaries. Namely, the team intends to keep the dsl targeted at this domain, rather than expanding to general computation in some far future. This enables them to focus on common target language constructs and keep their documentation efforts toward similar experts. They acknowledge that this demands more of their users, for <example all> external imports must be in the same folder when compiled, but allows for simplicity and clarity all around.

Hence, the author uses the analogy of a desert creature that survives in an environment of constrained resources.

</comment><comment><USER7> Honestly, if it's _not_ intended for general use, I don't think it's worth it to complicate the build process, and complicate the process of setting up a dev environment by installing a whole new compiler toolchain just for a couple of small functions.

<comment><USER8> > Thus, even were Futhark to become the indisputably best language in its area > - which is certainly the goal! - the user base would still be small, and so > would the development resources.

Exactly. If I'm selecting a language for any critical components, it's going to be one with a strong community, not something obscure that might be a little less verbose or a little more performant.

<comment><AUTHOR> What if it's a _lot more performant_? It's of course always a risk to incorporate another language, but sometimes performance is a critical feature, yet you have no time or inclination to write (say) low-level GPU code by hand. Futhark is more of an alternative to CUDA or OpenCL than to high-level languages.

Also, there is the important property that Futhark programs tend to be fairly small, and are semantically close to ordinary functional programming. Thus, even in a worst case situation where the Futhark compiler is abandoned, it is a reasonable task to simply rewrite all the code in another high-level language.

<comment><USER7> > sometimes performance is a critical feature, yet you have no time or > inclination to write (say) low-level GPU code by hand

I also have no time or inclination to integrate an entirely new tool into my build chain, complicate and lengthen the build process, and increase the cognitive load required to begin working on the project.

<comment><USER9> That's probably why they focussed on making the compiler as simple and straightforward to use as possible, so it does not significantly increase the complexity of your build process.

<comment><USER10> You would still need to wrap it in some form for it to be useable from most other build systems except make. For build systems such as bazel this is quite some work for little immediate benefit.

</comment></comment></comment></comment></comment></comment><comment><USER11> > Fairly sure you don't have to watch out for sandworms in a real desert.

Doesn't that map rather well to being acquired by $bigcorp?

</comment><comment><USER12> Transcendant read. Bang on.

</comment><comment><USER13> So futhark is designed to be small and specific to a single class of problems. Has the author considered implementing it in another language as a DSL?

<comment><AUTHOR> Yes, we considered that. There were two reasons we wrote a standalone language instead:

* It gives more flexibility and simplicity, regarding both syntax and type system. The compiler can also more easily analyse the AST, because there are no artifacts of an embedding.

* An embedded DSL is practically available only to users of the host language. In contrast, Futhark is equally accessible to many languages, either via direct code generation (such as for Python), or using a fairly simple C FFI.

The best example of an embedded high performance DSL is, I believe, Accelerate[0] for Haskell. It is really good, but is ultimately only accessible to Haskell programmers, and the implementation has to solve non- trivial problems related to the embedding.

[0]: [http://hackage.haskell.org/package/accelerate](http://hackage.haskell.org/package/accelerate)</comment></comment>


How similar is hacking to 21st Century pharma discovery? - <AUTHOR>

Reading this thread on the latest advancement in antibiotics, (https://news.ycombinator.com/item?id=8852487) I noticed several commenters touching on various strategies that seemed eerily similar to hacking...penetration testing, brute force fuzz testing, vulnerability analysis. The language and the medium is different, but at an abstract level, the strategies appear to be similar.<p>For someone versed in both worlds, how similar is it in reality, and are there advancements in say, white hat hacking that have counterparts in medicine/biology/genomics? <comment><USER2> There are superficial similarities, as well as some deep fundamental relationships. Studying biological systems from the viewpoint of information theory has been very productive. Systems theory, too. IMHO, these approaches don't really get to the deep core of biology (my guess is there are aspects of information processing in biology which have no equivalent in CS, but they provide valuable tools to study it).

Those things aren't unique to hacking, btw- they are common in warfare and intelligence, predating computers (well, maybe not fuzz testing).

That said, it can be misleading and people often stretch the analogy too far (DNA splicing is kind of like the C preprocessor but the ribosome is no compiler)

<comment><AUTHOR> I can understand information theory and systems theory, so maybe the question is whether there is anything in "hacking" that is separate from those two theories that is being explored?</comment></comment>


Show HN: A keyboard shortcut library for React - <AUTHOR> https://github.com/reasonink/clack-react <comment><USER2> From creating a few complicated web editors, the things I would find really useful in a (non-react specific) keyboard shortcut support library:

\- help identifying "web-safe" keyboard short-cuts which are not taken by the OS or the browser

\- handling of different short-cut schemes for OS/browser combination

\- easy handling of common system conventions e.g. f2 on windows/ubuntu is often rename but probably not on macos

\- handling reduced keyboards e.g. not sure what the state of on-screen or iPad keyboards is these days but they certainly used to lack a lot of keys making any short-cut heavy app almost unusable

<comment><USER3> You can override "web safe" keyboard shortcuts (for example, "CTRL+S") in a pretty standard way, with or without a library. The biggest issue I think is the _expected behavior_ for the user. If I press CTRL+S, do I expect the same HTML dialog or something custom in the app. Depends on the experience.

For different OS/browsers, the library I wrote for react shortcuts (see comment history for this post) handles this behind-the-scenes. CTRL/CMD are interchangeable depending on MacOS vs anything else.

Handling educed shortcuts is an interesting point I don't believe a lot of people are exploring. With increasingly complex apps being built that often rely on memorizing shortcuts, what alternatives exist beyond good design? I don't know the answer myself but am open to thoughts on how that might be achieved.

<comment><USER4> > With increasingly complex apps being built that often rely on memorizing > shortcuts, what alternatives exist beyond good design?

I think it's key to make the shortcuts discoverable inline. Maybe by default, maybe with a modifier pressed, every button and menu item should show the shortcut for it.

Also take a look at the experience in Spacemacs, where you compose multiple keys for a shortcut and if you pause you get a pop-up showing possibilities (eg press , to get major mode specific, then pause to see options, press x for text, then pause to see all the options for the next letter. Then when you know it you just quickly hit ,xi) (I vaguely remember someone else wrote this and Spacemacs popularized it, but I can't find the name)

<comment><USER5> Interesting to me is that a lot of native apps have similar functionality with the Alt key to navigate menus. Certain menu options would have an underlined character and you'd hit that character to select it like in Spacemacs.

I never use those in apps outside of Spacemacs. I think the bottom bar succinctly showing you all the options when you hit space/comma really makes discoverability a lot easier than in traditional apps.

</comment></comment></comment></comment><comment><USER3> I built a keyboard shortcut library for React not too long ago. There are a couple of issues you might run into.

There is a real chance that you don't define your keyboard shortcuts all in one place. There could be many components that have their own shortcuts. Some might override each other (Press "E" to toggle flashlight on/off or while riding a boat, "E" disengages). Since that's the case, you need a way to turn off or unregister the shortcut.

There is also the chance the shortcut is not being activated all the time. Having experimented with a method like in this library, I can tell you that unless you are focused on a root or parent element to the component, it's not going to fire.

Third, I'm not seeing any tests. Are you instructing people to install this library and it's not tested?

I opted to write my own that defines a single global event listener and can register/unregister shortcuts on the fly. No dependencies and tested[0]

[0] [https://github.com/UnicornHeartClub/react- keybind](https://github.com/UnicornHeartClub/react-keybind)

</comment><comment><USER6> This is neat, but the way blueprintjs handles Hotkeys is my absolute favorite of anything I've used.

[https://blueprintjs.com/docs/#core/components/hotkeys](https://blueprintjs.com/docs/#core/components/hotkeys)

It's essentially a JS decorator `@HotkeysTarget` and then your component gets a `renderHotkeys()` method on it.

</comment><comment><USER7> [https://github.com/JohannesKlauss/react-hotkeys- hook](https://github.com/JohannesKlauss/react-hotkeys-hook) looks more interesting to me (react-hooks)

</comment><comment><USER8> Thanks for sharing! Curious why you made it. Are there no good alternatives?</comment>


Show HN: Free app to get text main ideas instead of reading long articles - <AUTHOR> http://www.conceptmeister.net/demo.html <comment><USER2> Reminds me of the TLDR; app on the chrome store.

Have you considered making it a chrome extension?

<comment><AUTHOR> Yes, we are working on the Android version now. Chrome extension will be the next step of this project.</comment></comment>


How Programming Languages Differ Between Wealthy and Developing Countries - <AUTHOR> https://stackoverflow.blog/2017/08/29/tale-two-industries-programming-languages-differ-wealthy-developing-countries/ <comment><USER2> I think there may be some hysteresis effect going on here. If wealthy countries developed their tech industry sooner, you'd expect them to have a larger installed base of projects written using older technologies.

This effect explains why Java, C and C++ rank higher in high-income countries. It also explains why Android ranks higher in the rest of the world -- I suspect in many places, people are leapfrogging PC's altogether, and a lot of people have a tablet or phone as their sole device.

</comment><comment><USER3> The author concludes that wealthy countries have a lot more _data science_ than the rest of the world (eg., R and the scientific Python stack). Further, platforms common in _outsourcing_ are more common in developing nations (eg., PHP and Android).

<comment><USER4> I don't see how this blog article contains any scientific rigor by not doing any on-the-ground surveys in all these countries, but instead relies upon analytics from their own platform.

<comment><USER5> The conclusion summarized the findings as a topical analysis, more to find the "fun facts" as they look to dive deeper into the data internally.

But I definitely believe there are too many factors within the data for a full understanding. Most likely a case of _Correlation != Causation_</comment></comment></comment>


The Truth About Tech Company Perks - <AUTHOR> http://blogs.wsj.com/atwork/2014/07/15/the-truth-about-tech-company-perks/

<comment><USER2> I have always sort of disagreed with perks as a hiring lure. If your business is not interesting, you are not solving interesting problems, etc., then no amount of perks are going to attract me. The only perk I'd ever be interested in is for all health care costs to be paid in full by the employer until we realize the sanity of universal health care.

I work for non-profits as a rule now, having seen the futility in chasing the money. I'm happier making less, solving interesting problems for people who cannot afford to pay huge amounts of money. I'm not the most talented guy in the world, but I have solid skills most IT employers desire, and I get things done with little to no budget save new HW every now and then. Gotta love libre/free/OSS. Never, ever should a business pay for a software license again IMHO. I have not paid for software in since 1998, and will never do so again.

Perks should be real and tangible. Let's start with paying 100% of every employee's health insurance first. The donuts, dry cleaning , and other crap are worthless.</comment>