Armchair air crash investigator - <AUTHOR> http://momav.me/armchair-air-crash-investigator/ <comment><USER3> The accuracy of something like flighradar24 at low altitudes (where the difference between a landing and a crash is a matter of feet) is not high enough, and the data reporting interval is not small enough, to be used to do more than guess what happened. The article gives 3-4 data points _per minute_. You can't look at that data and draw any conclusions about the motion of an aircraft.

It's fun speculating, but please remember that the data from ADS-B is not designed to reflect the aircraft's motion over the time periods that matter in a crash. We have no idea what delays are present in the system, what delays flightradar's system adds in, and what the accuracy of the system is. It's very important to understand the limitations of any sensor data you analyse. It would be good to mention that in the article.

Edit: I notice that there's a little disclaimer at the bottom of the article saying that Flightradar24/flightaware data is "not 100% accurate", which is sort of covering the issue. However, when dealing with data like this it's important to remember that there's all sorts of ways data can be "accurate" or not. The uncertainty of the data itself, the frequency of data captured, the accuracy of the timestamps attached to the data and all sorts of other variables need to be considered when you're trying to understand the picture that sensor data is painting.

<comment><USER4> I would hope the difference between a landing and a crash is a little more than 'feet' otherwise we'd have a lot more crashes. Maybe the difference between a BAD landing and a crash is only feet :)

<comment><USER5> A typical airliner approach is a 3 degree angle touching down at 1000ft past the end of the runway. That means that they pass over the threshold at about 150ft. Let's say there's another 1000ft past that before things get problematic (at SFO it's considerably less, I believe), that means that the airliner passes over the dangerous bit at about 300ft when operating normally, and 300ft lower would cause a crash.

This isn't normally a problem, because detecting and ensuring that 300ft difference is not really hard.

<comment><AUTHOR> Just a note about approaches and landings – most, if not all airline ops usually say that you should be ~50ft when passing above the threshold.

<comment><USER5> My simplistic analysis ignored the flare, thus why the real-world height would be lower. Thanks for pointing that out.

</comment></comment></comment></comment></comment><comment><USER6> It goes without saying that my qualifications in aviation matters are only as an aviation enthusiast and for the full cause of the accident, we'll have to wait for the NTSB report (which has access to vital black box data and cockpit recordings).

However, I did give this accident some thought as well given the circumstances of the accident and came the pretty much the same final conclusion as the OP.

An airline pilot I once spoke to told me once that all the big jetliners use automated ILS with autopilot to automate the landings. The system is pretty accurate and reliable and can deliver landings as good as a well-trained and experienced pilot can.

When I saw the rather steep final approach the aircraft was making, I had suspected that the pilots were doing a manual landing. Now that we have information that the ILS was temporarily inoperational this appears to be what transpired and the pilots manually flew the final approach.

The precise reasons for why the manual approach ended up in this accident are still to be determined. One thing that I will point out though is that pilots for modern jetliners do relatively little actual manual flying of the plane. Modern airplanes have advanced FMS (Flight Management System) that allow for automatic flying from lift-off until landing with pilots overseeing the system. Given this lack of manual flying, there is a greater potential for human error when a pilot is required to actually do manual flying.

<comment><USER7> Pilots will actually very rarely use the autoland functionality (apart from when weather, e.g. low visibility, requires it, and also to ensure that they're current with the procedure). They'll use the autopilot for the initial part of the approach, but then when visual with the runway will often disconnect it in order to fly the actual landing manually (still following the indications on the flight director, which are provided by the localiser/glidescope signals).

<comment><USER8> Why is this? Can they do a better (in terms of passenger comfort) job landing manually?

<comment><USER9> No, autoland is pretty good. But there are two factors that cause pilots to land manually most of the time: 1) pilots think they are better at handling last-minute unexpected contingencies like wind sheer or bird strikes (and they may well be right about that) and 2) pilots don't want to give the Powers that Be any additional data to suggest that they aren't actually needed to fly a plane at all. The fact of the matter is that there are no technological barriers to making aircraft completely autonomous, but pilots want the world to remain in denial about this for as long as possible for the sake of their job security. (FWIW, I'm an instrument-rated private pilot.)

<comment><USER10> > The fact of the matter is that there are no technological barriers to making > aircraft completely autonomous, but pilots want the world to remain in > denial about this for as long as possible for the sake of their job > security.

Two words: anomalous conditions.

As we both know, pilots aren't needed in the vast majority of commercial flights. The plane is perfectly capable of taking off, navigating, avoiding collisions, and landing with minimal, mostly unskilled supervision.

We don't need pilots on planes... until something unexpected goes wrong, and we do.

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

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

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

<comment><USER11> Devil's-advocate: fine, OK, we still need pilots, for the time being. But do they actually need to be _on_ the planes?

In the case of two recent crashes (AF447 and this one, assuming pilot error turns out to be the cause as seems likely), it's safe to say that a computer would've easily done a better job than the pilots.

Would be interesting to hear Capt. Sullenberger's take on the question.

<comment><USER12> Assuming we could make such a system secure and unhackable as well as unjammable, why would we want to? To save some money? I would rather pay a little more to have the pilot sit in the same airplane and have his life on the line as well.

I just find it fascinating how obsessed people seem with getting rid of pilots. You don't often hear the same discussion about train or bus drivers, or doctors for that matter, even though we are just as close to having automated robotic surgery and expert systems have been around for a long time.

<comment><USER13> _You don 't often hear the same discussion about train or bus drivers_

Plenty of cities are getting rid of their subway drivers at least. And if many airport shuttle trains around the world are automated as well.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Here is graphical comparison of safe landing and Asiana crash: [https://pbs.twimg.com/media/BOhIDCWCUAApHFV.jpg:large](https://pbs.twimg.com/media/BOhIDCWCUAApHFV.jpg:large) .

Also it appears that runway was modified: [http://metabunk.org/sk/HL7742_777_Crash%2C_Korean_Asiana_Air...](http://metabunk.org/sk/HL7742_777_Crash%2C_Korean_Asiana_Airlines%2C_San_Francisco_%7C_Metabunk-20130706-142510.jpg)

<comment><USER15> Interesting. I wonder what the Asiana's descent profile looks like compared to the average and some outliers of other safe 777 landings at SFO. Did you generate that image? If not, what was the source?

<comment><USER16> I saw another image online, which compared the descent profiles of the past week of landings for the same flight. It showed that the July 6th landing was very close to the normal descent profile, and the July 5th landing was actually the outlier -- it had an unusually shallow glide slope.

Unfortunately I can't find the image right now, but perhaps someone else knows where it is and can provide it?

<comment><USER17> There are some at [http://flyingprofessors.net/what-happened-to-asiana- airlines...](http://flyingprofessors.net/what-happened-to-asiana-airlines- flight-214-2/)

<comment><USER18> like this link better than the OP which is fairly uninformed speculation ...

<comment><USER18> some video of the crash - kind of looks like it was skimming the waves in ground effect trying to go around

[http://www.cnn.com/video/?/video/us/2013/07/07/vo-plane- sf-p...](http://www.cnn.com/video/?/video/us/2013/07/07/vo-plane-sf-plane- crash-on-cam.courtesy-fred-hayes)

I stand by the parent having some useful data and analysis, and the OP being totally speculation, and in many respects uninformed.

\- number 1, if you say 'loss of power', makes sense as a possible cause. if you say 'icing in the FOHE', it's like saying the murder was done with a yellow pistol. nothing points to that, no icing conditions (humidity/temperature), and of course not same engine as the previous plane crash attributed to that

\- number 2, you can't be unaware of an ILS out of op, you wouldn't be cleared for the ILS approach, you wouldn't be using the ILS on visual approach, you would be cued there's no signal, you wouldn't hear the outer marker, etc. etc.

\- number 3, auto-throttle, well again, if you say malfunction in power setting, OK could make sense, if you get as specific as 'confliction with autopilot/auto throttle' that's a purple pistol. Clearly not on cat3 autoland, you're basically saying pilot forgot to set throttle in the right configuration for visual approach and landing.

\- number 4, pilot error/bad approach, can't argue with that. the story is what's interesting, eg undiagnosed walleye vision, ate the bad fish etc.

<comment><USER19> "\- number 4, pilot error/bad approach, can't argue with that. the story is what's interesting"

Pilot induced oscillation on a really big scale. Coming in way too hot, slam down, whoops way over corrected, now coming in too low, whoops ran outta air and time to correct. Coming in way too hot, now are you better off trying to salvage or go around and get fired? Different nations airlines have differing policies on this...

<comment><USER20> Do you really risk getting fired for a go around? I mean, I can see that happening if you do it way more than other pilots, but just doing it once?

(For the record, I have no idea how these things works, it's just very surprising)

<comment><USER18> I think you might get a call from a chief pilot for an anomalous approach, whether you salvage it at last minute or go around. If there's a pattern of things not going by the book, would guess you get sent for 'retraining' before you get fired... airline version of big data FTW I guess...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> NY Daily News is reporting that VASI was down as well ([http://www.nydailynews.com/news/national/expert-runway- guida...](http://www.nydailynews.com/news/national/expert-runway-guidance- systems-sfo-disabled-article-1.1392294)) Which appears to be due to someone incorrectly reading a post-crash NOTAM which is about the aids being gone due to the crash, so there's no particular reason to think VASI was down before the crash.

I really don't think I'd trust SF city government to run an airport, even under FAA regulations. Look at every other city service SF has, and imagine that quality applied to preventing hundred ton soda cans full of people and jet fuel from exploding.

<comment><USER19> The short version is there are multiple things on a runway that emit light and I think they're being confused.

"Which appears to be due to someone incorrectly reading a post-crash NOTAM which is about the aids being gone due to the crash"

OK first of all VASI has been obsolete since I was a kid in the 90s, its all PAPI now. (edited to add, in the USA) Much like people still call the AWOS an ATIS because it does about the same thing. I'm not just picking nits, if you try researching this, you'll find the VASI has been outta service probably since the 90s, you want the PAPI. Its all the same anyway, white you're light, red you're dead. VASI is before my time but I'm told it was the same arrangement?

If you want NOTAMs you can just go to FAA's pilotweb, this link might work or you can search. Holy cow SFO has a lot of NOTAMS to read about.

[https://pilotweb.nas.faa.gov/PilotWeb/notamRetrievalByICAOAc...](https://pilotweb.nas.faa.gov/PilotWeb/notamRetrievalByICAOAction.do?method=displayByICAOs&reportType=RAW&formatType=DOMESTIC&retrieveLocId=SFO&actionType=notamRetrievalByICAOs)

!SFO 07/047 SFO RWY 10R/28L CLSD WEF 1307062309

!SFO 07/046 SFO RWY 28L PAPI OTS WEF 1307062219

The PAPI (precision approach whatever indicator or something) was marked out on the 6th at 2219 and the runways (not all listed above) formally closed at 2309. I think that is after the crash UTC time?

Now according to this NOTAM

!SFO 06/003 SFO RWY 28R ALS OTS WEF 1306011400-1308222359

They've been screwing around with the ALS lights for like 5 weeks now as per the daily news story. The ALS is mostly to light the place up at night, make sure you can line up on the correct runway (L or R) and most importantly in the USA this has the decision bar, if the weather is so poor that you can't see the decision bar, its too poor to continue the approach. I'm told the weather was beautiful during the crash, so I don't think the decision bar being rebuilt or whatever had much if anything to do with the crash.

Something I don't understand about ALS on an airport by an ocean (not exactly a problem where I live) is how they mount the decision bar and its little friends. Its going to be quite a distance from the end of the runway and some runways seem to go right up to the sea, so piers out in the ocean or something? If they hit the SFO ALS that would imply the plane would be well offshore under water.

The ALS, aside maybe from some wiring, is probably not any more or less messed up by the crash than anything else's power wiring. I could imagine a plane running off the runway into the PAPI and that would be about the end of that PAPI, or at least it'll have to be aligned.

<comment><USER21> It looks like they mount stuff on CA-92/San Mateo Bridge ([http://www.flysfo.com/web/export/sites/default/download/abou...](http://www.flysfo.com/web/export/sites/default/download/about/news/pressres/fact- sheet/pdf/PRM_SOIA_version_1.pdf)) and then from there along the approach. The main issue seems to be the two parallel runways. From when I took photos of the airfield, there were a lot of lights and other things sticking out of the bay on the approach path. Decision Bar is supposed to be 1000' off the threshold so that was probably it.

I'm not a pilot; once I have spare money and time (and enough to fly monthly to keep current), probably.

It's interesting reading about stuff like the "No Transgression Zone", though.

<comment><USER19> "once I have spare money and time"

I've been telling myself that for decades and never quite had both at the same time. Often a great excess of one or the other. By the time I finally have both, I'll probably fail my medical with my luck. I did do ground school + a bit more on my own, and I've got a couple hours in the air with an instructor. I do some semi-serious sim flying for fun, mostly the X-Plane. If I ever get serious I'll already be pretty good at navigation, flight planning, reading approach plates, E6B use, METAR decoding, NOTAM decoding, etc.

There's a remarkable number of free electronic E6B apps for most phones. And some paid ones that are marginally better. I find my tablet to be quite helpful when "flying" although I also use old fashioned mechanical E6B... Figure $10 for a paper one that'll last "awhile" and $30 for a lifetime metal one.

The frontier of flight sims right now is no one does NOTAM simulation. Why not shut down some ground stuff occasionally, just like you can shut down aircraft systems and screw around with weather? It may be there's a sim out there that does this that I don't know about.

<comment><USER21> I'm think in the Bay Area it's mostly a question of $10-15k and maybe 100 hours (flight + study time) to get the first license, and there are a decent number of rental choices.

My dream (well, the realistic one) is to get a CH-801 STOL kit plane with a diesel engine so I can live in Central Washington and get to I-5 in a reasonable amount of time, although weather probably prevents that often. That's only $150k or so, which would be saved in taxes and property cost differential several times over.

</comment></comment></comment></comment></comment><comment><USER22> Sorry to go offtopic here, but the images seem to be used without any credits. The first one was taken by David Eun ([https://path.com/p/1lwrZb](https://path.com/p/1lwrZb))

<comment><USER23> Well, the whole blog design is very gray-area 'theft' of Medium's design.

<comment><USER24> I don't know what Medium is, but ... a white page with a title on the top? This is just as much a 'theft' of the default Apache "It works!" page.

<comment><USER25> Design is about choices. In this case you can point out:

        1. top-left square logo, dark gray, slab serif, fixed on scroll
        3. bold, large sans-serif title in "off-black"
        4. large serif body text with extended line-height
        5. 100% width image on top

Despite the visual simplicity, there are a lot of variables in effect. It's definitely "inspired" by Medium.

(medium has a few different post layouts, but they share the same spirit: [https://medium.com/lift-and-drag/5f803f1482e3](https://medium.com/lift-and- drag/5f803f1482e3) vs [https://medium.com/lift-and- drag/51691e99279f](https://medium.com/lift-and-drag/51691e99279f))

</comment></comment></comment></comment><comment><USER26> There is an excellent posting with graphs comparing the Asiana flight to a United 777 that landed 10 minutes before. The graphs compare height, speed and importantly energy. [http://flyingprofessors.net/what-happened-to-asiana- airlines...](http://flyingprofessors.net/what-happened-to-asiana-airlines- flight-214-2/)

As most have hypothesized, it was an unstabilized approach and they should have done a go around (barring unknown technical/mechanical factors).

<comment><USER19> Looking at the graphs the plane was ahead of them by about 5-10 seconds. That usually doesn't turn out too well. Gotta be ahead of the plane, not the plane ahead of you. Usually a noob mistake (on the ground system failure, hard to fix) OR hopefully extensive extenuating circumstances (on the plane system failure, easy to fix).

</comment></comment><comment><USER27> I heard a reporter on TV reporting that the airplane was doing cartwheels on the runway, and I pictured the semi-truck being flipped over in Batman. And then I thought what the hell could have done that? Fishtailed makes more sense, thanks for the clarification.

<comment><USER28> There were a lot of reports like these that were complete assumption based on the fact that one witness said the airplane had flipped over. It actually hadn't.

<comment><USER29> O RLY? [http://www.cnn.com/2013/07/07/us/plane-crash- main/index.html...](http://www.cnn.com/2013/07/07/us/plane-crash- main/index.html?hpt=hp_t1)

<comment><USER30> That is not a cartwheel

<comment><USER29> Why, because the plane was not 100% vertical on the Z-axis?

<comment><USER30> Yes

</comment></comment></comment></comment></comment></comment><comment><USER31> It looks like this was an unstabilized approach right down to the ground. It would be interesting to see what the company SOP is. Any safe airline has a no-fault go-around policy for unstabilized approaches, and you'll actually get in trouble if you continue with an unstabilized approach and you don't go around. From what pilots are saying on the message boards it seems that a lot of Asian airlines have pretty much the opposite policy - you get in trouble if you go around for any reason, and they would prefer you to salvage an unstabilized approach to save money.

<comment><USER32> pretty much looks the same to me - the guy stalled and when he finally, at the last second (actually - well past the last second), decided to go around, he did jerk up the nose and that increased the stall, so they fell. Reminds me about the AirFrance fall in the Atlantic some years ago - that guy was trying to gain altitude by jerking the nose up (i.e. increasing the "angle of attack") instead of "pressing the accelerator pedal".

<comment><USER33> If this is what really happened, I'll say the same thing I said then - <USER2> shocks me that airline pilots with thousands of flight hours can make the most elementary piloting mistake possible.

But I've read accident reports before, and it's rarely a good idea to speculate. I won't have an opinion about this until the official report is published.

<comment><USER32> well, until report is out, we're here to speculate (or to read a good speculation if we're lucky :). From the Flightaware data the plane had 109kts at 100feet altitude before the seawall. The stall speed of 777 is about 110kts (its Vat is ~140, and it is 1.3 of the stall). And the speed was falling as the next recording is 85kts. While we can only guess about the original cause - pilot error or hardware, etc... - the stall seems to be there.

<comment><USER33> Are you sure that the Flightaware data is accurate enough? When flying a glider, I have attempted to make similar judegments from GPS log data when doing an outlanding, and I'd be similarly careful when using radar data from a website.

I don't want to be very negative here, but my point is I've made wrong calls about this when speculating in the past. So currently I'm opposed to doing it for reasons other than entertainment.

<comment><USER32> > for reasons other than entertainment.

well, i'd be surprised if there are people here for any other reasons :)

the flightaware data correlates very well with what is on video. Personally i spent a bunch of time on Coyote Pt. so i can mentally correlate the video with how it looks for other planes/landings at SFO. As we aren't ordained NTSB officers, we're free to make wrong calls :)

</comment></comment></comment></comment></comment></comment><comment><USER34> This is an excellent article. Like Air France 447, seems very plausible that pilot error did play some role. This reinforces my respect for the pilot of US Airways Flight 1549, Captain Sullenberger.

</comment><comment><USER35> Curious as to why autopilot isn't being used to land planes yet. My understanding is that pilots can choose to use it to land, but only do so when visibility is very low. (ex: [http://www.youtube.com/watch?v=DOFs-oa- bbc](http://www.youtube.com/watch?v=DOFs-oa-bbc))

<comment><USER31> The autopilot requires the ILS to land the plane. If the ILS is inoperative, it can't autoland. However pilots do still land planes to keep their skills honed.

<comment><USER36> Presumably GPS and/or visual recognition system can be used to achieve the same, after all airstrip location is know in advance.

<comment><USER37> Presumably, the visual recognition system in this case was a human.

</comment></comment></comment></comment><comment><USER38> Here is my one minute as an _armchair air crash investigator_.

In recent times I've read some very strange incidents reports with regard to airline pilots.

One plane crashed on landing while coming in to final approach at twice the recommended speed.

Another was coming in for final approach some 500 feet below the allowable height and off the designated flight path.

These are examples of some very basic flying errors.

In years previous pilots had to do many hours in light aircraft, then move on to bigger aircraft and only after decades of flying experience did they make it onto the big jets.

But in todays _cut price flying_ environment I suspect most pilots don't do that much flying and as such they don't know as much about flying as they should.

This one is going to be pilot error.

</comment><comment><USER39> I don't really like when people post these sort of "arm-chair" hypotheses. As much as it's fun to try to figure things out, there is always the danger of people jumping to conclusions based on bad or incomplete data. It reminds me a lot of the reddit people immediately following the Boston Marathon bombings. It's definitely an interesting read, but I don't want to take it for much more than just idle speculation.

<comment><AUTHOR> Idle speculation and having a bit of fun trying to play air crash investigator, is exactly what this article is. I hope that I was able to convey that this is about "what I think" happened and not "what happened".

</comment></comment><comment><USER40> Cellphone video shot by a guy, Fred Hayes, watching aircraft land yesterday at SFO shows the tail dragging in the water for quite a distance before striking the seawall.

[http://statter911.com/2013/07/07/must-see-crash-of-asiana- fl...](http://statter911.com/2013/07/07/must-see-crash-of-asiana- flight-214-captured-on-video/)

I'm guessing that the pilot was praying for those engines to spool-up faster.

</comment><comment><USER41> Some more relevant news just breaking now ... [http://www.nydailynews.com/news/national/asiana- flight-214-p...](http://www.nydailynews.com/news/national/asiana- flight-214-pilots-realized-seconds-crash-approach-slow-article-1.1392535)

</comment><comment><USER42> Does anyone know if they've released the information about where the people who died/were severely injured were sitting in the plane? I'd love to see a seating chart that shows the safest and least safe seats on a 777.

<comment><USER43> It really depends on the type of accident (skim Wikipedia on ones with survivors) ... and after looking at the CNN supplied video [https://news.ycombinator.com/item?id=6003232](https://news.ycombinator.com/item?id=6003232) right now I'm thinking "Major miracle" and "If it's ain't Boeing, I ain't going", although I'm sure it's a lot more of the former than the latter.

</comment></comment><comment><USER44> "The final bit of information is interesting. It shows a positive rate of climb – 120 feet per minute to be exact, which for a jet airliner, is very slow. For reference, at takeoff the vertical speed is most often +1500 feet per minute. Another interesting bit of information is the aircraft's airspeed; 85 kts – for a Boeing 777 that is (and I'm guessing here) probably way below stall speed."

That is actually expected. It is called the flare just before touchdown:

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

<comment><USER45> I've never flown a B777 or any heavy aircraft so I can't comment on their typical flares, but in a Cessna 172 the flare doesn't induce a positive rate of climb, it simply slows the vertical descent speed to something manageable for touch down, a positive vertical speed seems counterintuitive to me as a good flare. What I want to know is what his IAS (indicated air-speed) at the decision altitude.

Again the only thing I've flown are parachutes and some hours in a C172 and a C182.

<comment><USER19> It gives a pretty good estimate of the error involved in the descent rate reporting. Probably accurate +/\- 200 FPM or so.

The airspeed encoder is probably from the same system that displays the pilot instruments, indicated airspeed IAS. I thought it odd that the analysis of conditions didn't think 125 and 98 were ridiculously low airspeeds, but claimed that an approach around 130 knots was a "fast approach". However what little I know about the 777 from the flightsim and real pilot community is that a typical approach is around 150-something slowing to a bit above 130 at flare. I've read some claims from actual heavy pilots that under really light conditions a Vref below 120 is theoretically possible.

None of us know the weight and balance calcs so its impossible to determine if the pilots were doing the correct thing, although it is possible to determine they were flying a flight path implying they thought they were very light indeed. Now why? Who knows. Maybe because they were right, they were light. Maybe because they were low-ish on fuel. Maybe they didn't trust their IAS instrument. Maybe their IAS was actually broken and comparing their visual approach with instruments, well, its just a really strong headwind today. Maybe they made a math error. Somebody overcontrolled?

He could have found this info by violating the copyright of numerous google- able flight sim forums, and forums with real genuine 777 pilots talking about their experience with the 777. Instead he violates the copyright of a picture which we've all already seen, oh well.

<comment><AUTHOR> About the speed, you're correct – 130 kts for a 777 is not fast, I was mistaken. In fact the NTSB just said the target approach given by the pilots was to be 137 kts. I should have chose one of the higher airspeeds given but I did not want to give a high estimate. I am not familiar with 777 speeds and should of done some more research in that regard. I did however, write that I found the sub-100 speeds to be extremely slow, even suggesting that it's most likely below stall speed – which seems to be correct as the NTSB says the stick shaker went off some 4 seconds before impact.

<comment><USER19> I read sometimes you can get a Vref under 120, great density altitude, sea level, winter, no pax cargo and low on fuel, but yeah when the IAS is reporting 98 you're pretty much screwed under any conditions. Maybe it was already on the ground at that point, if it wasn't.. it going to be on the ground real soon...

I would imagine some of the flightsim people I know are flying the approach under identical conditions right now. Would be interesting to hear at what point they found it unrecoverable. 98 kts is unrecoverable, but I wonder when it went unrecoverable. One problem with sims is if you know how its supposed to turn out, that screws up your actual reaction if you sim it 20 times trying different things. All you need is a cockpit distraction to totally screw up an approach. Maybe a false alarm of some type at just the wrong moment.

</comment></comment></comment></comment></comment><comment><USER46> To the OP just curious -- are you a licensed pilot? Not to question you since you did say this was just speculation but just wondering. It's pretty well informed.

</comment><comment><USER47> Is anyone else puking mad at those people carrying their luggage in the photo? I feel like getting off a burning plane should take priority over duty free purchases.

</comment><comment><USER48> Thank you for your armchair analysis, but I will wait for the NTSB's report.

<comment><USER49> That seems needlessly snarky in response to some thoughts that are very clearly labeled as speculation.

<comment><USER48> It was snarky, and I expected the down votes. But, I think it needs to be said. Neither I, nor the OP, have enough information to make any conclusions. It is just a lot of observations, rumors, and opinions.

I love speculating about everything from government policy to interpersonal relationships. (It helps me validate my mental model of the world.) But, in this case, I know the NTSB currently has a better picture of the situation than anyone on the internet.

<comment><USER12> Why say it when it's already mentioned several times in the post? I'll wait for the report, in the meantime I'm interested in qualified speculation based on the available data.</comment></comment></comment></comment>


Cross domain requests to every resource on the web - <AUTHOR> http://corsproxy.io/

<comment><USER2> Consider supporting HTTPS, since a lot of the un-cors'ed javascript this service enables involve credentials.</comment>


Fedora Loves Python - <AUTHOR> https://fedoralovespython.org/ <comment><USER2> > Python 3 by default

Two lines below:

> However, /usr/bin/python remains Python 2, [...]

Not sure what they call "default". They seem to quote some PEP that only specified that this was okay during a transition period. I think we're WAY past that. If not, then the first statement is plainly wrong.

<comment><USER3> I read PEP 394 ([https://www.python.org/dev/peps/pep-0394](https://www.python.org/dev/peps/pep-0394)) differently. It states

> The more general python command should be installed whenever any version of > Python 2 is installed and should invoke the same version of Python as the > python2 command

Rather than permitting python to refer to python2 during a transition period, that is the recommendation. They later state

> It is anticipated that there will eventually come a time where the third > party ecosystem surrounding Python 3 is sufficiently mature for this > recommendation to be updated to suggest that the python symlink refer to > python3 rather than python2.

</comment></comment><comment><USER4> Most of this seems pretty standard for Linux distros; python2 and python3 installed by default, ability to install venv through `python -m`, other versions of Python and various packages available in the repositories. Is there something I'm missing here?

<comment><USER5> Installing different Python versions is not possible with many distros (you'd have to compile it from source/use something like pyenv):

[https://developer.fedoraproject.org/tech/languages/python/mu...](https://developer.fedoraproject.org/tech/languages/python/multiple- pythons.html)

<comment><USER6> As far as I remember Debian has always been able to support multiple versions of python simultaneously although I think they've dropped packages for <~2.7 now

<comment><USER7> But:

\- iirc they can only go down one version (i.e. 3.4/3.5, no 3.4.1/3.4.2)

\- it's always been a real b@llache to install newer versions on Debian releases where it has not been officially packaged (e.g. 3.6 on jessie). With most packages, you can grab the source from Sid and rebuild it on Stable; with Python it's become basically impossible, the pile of dependencies below and above the package is unwieldy. And this _despite_ tons of policies around packaging python apps, which was supposed to make it easier to run multiple versions.

If Fedora really made things easier in this area, it's most welcome. However, when a marketing page starts with "you can now do this standard thing that actually most people have been doing for years already" (-m venv), I'm somewhat skeptical.

</comment></comment></comment></comment><comment> chroem- Another fine example of heartwashing. It just doesn't feel genuine when all these companies start plastering hearts all over everything.

</comment><comment><USER8> _tips fedora furiously_

<comment><USER9> Colorless green pythons tip fedoras furiously.

</comment></comment><comment><USER10> Why should I use fedora on my laptop over Ubuntu? Even on servers?

Does fedora increases my productivity?

<comment><USER11> In my experience most Fedora users are from corporations that want a support contract from RedHat. That's really the only reason. I've yet to meet anyone who uses Fedora willingly otherwise.

<comment><USER12> If you want support contracts you don't use Fedora, you use RHEL

<comment><USER13> Well you buy one RHEL and use centos everywhere then pretend whatever broke was on your RHEL licensed box. That's usually how corporates seem to run it.

I haven't seen a single Fedora install in all my years on a desktop or server.

</comment></comment></comment></comment><comment><AUTHOR> Relevant to their "Fedora Python initiative":

[https://labs.fedoraproject.org/en/python- classroom/](https://labs.fedoraproject.org/en/python-classroom/)

</comment><comment><USER14> Fedora can not be python3 only, if you want to have offline documents, e.g.: there is a `python2-matplotlib-doc`, which depends on `python2-matplotlib`, however no `python3-matplotlib-doc` or a generic `python-matplotlib-doc` exists.

On the other hand, ubuntu /debian packages are well organized at this point.

</comment><comment><USER15> /rant If fedora really loves python, they should first start showing their love by publishing all their distribution related libraries to pypi. blivet, selinux, none of these are available in pypi. Why do they expect everyone to use rpms?

<comment><USER16> Personally I can't stand when I have to get language specific packages from one of their many package managers, that's the point of having a distribution - so it can be distributed.

<comment><USER4> Right, but the issue GP has with this is that the Python libraries that Fedora develops aren't available on other distros, and that submitting them to a Python repository would be an easy way to achieve that availablility

<comment><USER17> These libraries are in fact available for other distributions. The SELinux Python things, for example, are hosted on Github.

</comment></comment></comment></comment><comment><USER18> Off topic, but it seems to me that the "Python 3 by default" logo has cobras, not pythons.

<comment><USER19> Maybe it's a python pretending to be a cobra?</comment></comment>


Legislation would restrict H-1B visas - <AUTHOR> http://www.latimes.com/business/la-fi-h1b-visa-20160830-snap-story.html <comment><USER2> Right now H1B is a lottery with country specific quotas? Could we think of a worse way to choose people to bring in?

Let's make it an auction. Let the bids tell us which skills are in highest demand and use the proceeds for scholarships and training of citizens in those jobs. Think H1B fees funding computer science scholarships. And at least with an auction we'll bring in higher quality workers that will contribute more to our economy (relative to a random selection).

Second, the catch-22 on why brown people hating politicians can't solve the problem: To make companies prefer foreign workers less we have to protect those workers better. Make it easier for them to change jobs and harder to force them into long hours without pay.

<comment><USER3> I'm not too familiar with the H1B system, but one of the issues I have with the idea of an auction is that it hurts startups who are willing to give up a lot of equity but not much cash to an employee.

<comment><USER4> Today a huge portion of H1Bs are get assigned to body shops who then provide labor to large companies. I'm more concerned with worker exploitation than I am with a few startups who as missing out today, potentially missing out tomorrow.

</comment></comment></comment><comment><USER5> Good. The top 10 recipients are all outsourcing bodyshops. It's undeniable the program is being abused and no longer functions the way it was intended.

<comment><USER6> Here's my question: wouldn't it fix a lot of the issues with the program if preference were given to awarding visas to largest number of sponsors, rather than a true lottery? So in essence you couldn't get a second visa in the lottery as a sponsor until every sponsor had gotten at least one.

<comment><USER5> No, it should just be an auction. Bring in the top earners and the specialized skills will follow. Most of the companies are bringing in H-1B workers who lack experience and specialized knowledge/skills. In addition, somewhere between 47 and 85% of H-1Bs are being significantly underpaid compared to their peers:

>Wages for H-1B workers in computer programming occupations are overwhelmingly concentrated at the bottom of the U.S. pay scale. Wages on LCAs for 85 percent of H-1B workers were for less than the median U.S. wage in the same occupations and state.

[http://cis.org/PayScale-H1BWages](http://cis.org/PayScale-H1BWages)

The top H-1B recipients: [http://www.myvisajobs.com/Reports/2015-H1B-Visa- Sponsor.aspx](http://www.myvisajobs.com/Reports/2015-H1B-Visa-Sponsor.aspx)

Make the H-1B 'lottery' into an auction. Instead of accepting 65,000 H-1Bs at random--accept the 65,000 H-1Bs with the highest wages. That way we are getting the immigrants with the highest valued skills and stopping companies like Infosys, TCS, Wipro, HCL, and Cognizant that game the immigration system by applying for the cheapest H-1Bs possible.

<comment><USER7> Except that the industry will lobby for that 65,000 number to be increased to say 195,000 [0] or higher until they can get their $55k per year programmers in SF. And it will work, because it has in the past. And that is a bill that has A LOT of bipartisan support.

[0] [https://www.govtrack.us/congress/bills/114/s153/summary](https://www.govtrack.us/congress/bills/114/s153/summary)

</comment></comment></comment></comment><comment><USER8> > employers can be exempted from that paperwork if the potential employee > holds a master's degree or is paid at least $60,000 annually.

Wow, I wasn't aware the bar was so low. Given the recent brazen misuse of the program I hope this goes through

<comment><USER9> The salaries listed for a senior programmer that gauge how much H1Bs are paid are obnoxiously low. Last time I looked, I was shocked. When the average salaries listed are lower than anyone other than junior programmers, they get H1Bs for cheaper. Also, the companies can hire a person as a front line support and pay them accordingly, but actually have them doing system development or design.

Big businesses in the macro sense, seem willing to do anything to cheat the system to drive down costs and subsequently wages.

I do think raising the cap will help.

</comment></comment><comment><USER10> The purpose of H1B Visas is to supply talent that CANNOT be found domestically. They are not designed to suppress the wages of locals at the benefit to the owners of capital. This is no different than a company whining about a tax-loop hole being closed and throwing around rhetoric like: "it'll come at the cost jobs and innovation!" The IT workers cited from the article in question are not uniquely skilled over their american counter-parts, they are simply being used by corporations to lower wages.

<comment><USER11> It should bring talent and diversity. Bringing ideas from multiple cultures and occupations, to establish connections and interchange with those. Right now many H1B are used by Indian IT companies.

Also, they are the most abused on the green card process since they have to wait years because of the huge backlog.

Edit: Seems like my argument is being misunderstood. The HB1 program should bring talent from many different countries not only India. It should bring different talent for different occupations not only IT.

<comment><USER12> The diversity argument falls flat when you replace _your entire IT workforce_ with H1Bs from the same country (India). This holds true when companies replace entire divisions or departments with outsourced H1B labor as well.

<comment><USER11> This is the argument. Currently H1B are not bringing diversity. They should.

</comment></comment></comment></comment><comment><USER13> H1B is a classic case of how legislators are far away from reality.

Increasing minimum wage does not help it creates a bigger problem. A lot of smaller companies will happily show $100,000 salary to their employee while paying only $30,000. This is technically a fraud but the companies do it all the time. Google or Facebook wont be able to do it but those consulting companies could.

Here are my suggestions:

1\. Do not allow consulting companies to file H1B at all. If the person is specialized then let some company hire him/her full time. Create a separate visa category for consulting work for foreign companies trying to send their staff to USA.

2\. Scrap H4 and give EAD to the H1B spouse. Most of the illegal things about H1B is because of the desperate attempts by H1Bs to get the well educated spouse be productive. Also given that most H1B are male this is also a very anti-women thing to do by putting women out of work. My wife enrolled for F1 in a small university just to get an OPT EAD. Wasting $20K and 2 years for a completely useless masters degree.

3\. Have a clear and simple path to green-card for H1Bs.

<comment><USER14> Also, stop connecting H1B to the hiring company!

If the H1B company isn't offering a good salary, the person should be able to change jobs to another in the US without paperwork. This would remove most incentives for a person to take a below-market wage, removing the downward pressure (that I think is theoretical but...)

Plus it stops treating people like indentured servants. +1 for humanity.

For companies whining about people leaving fast: don't offer shitty jobs! Signing bonuses exist for americans, figure out how to keep people without the threat of deportation.

<comment><USER13> Yes. H1B = EAD.

My wife had h4 and she could not work. I was sponsored a green card and she got her EAD while I am still waiting for my PR.

</comment></comment></comment><comment><USER15> Nowadays remote is as good as local.

There is really no big difference from what physical location one is accessing project's resources (repos, tracking, etc). Big and sophisticated projects like GHC (leave alone Linux kernel) are being successfully developed by remote teams.

The only downside is that pointy-haired managers cannot easily bully and abuse (with unpaid hours) migrant employees and there is no easy and accessible personal payment solution (Paypal sucks for non-us citizens) due to "anti- terrorism" money-control cretinism.

Actually, there is no technical problems at all, only organizational.

<comment><USER16> > (...) there is no easy and accessible personal payment solution (Paypal > sucks for non-us citizens) due to "anti-terrorism" money-control cretinism.

What's wrong with bank transfers?

</comment></comment><comment><USER17> Misuse must definitely stop. But wouldn't this force businesses to outsource to offshore offices... Losing talent, losing jobs to other country and losing out on taxes. And the jobs that cannot be offshored would require higher/complex skillset

<comment><USER18> The H1-B program allows employers to hire foreign employees, at below-market rates, by limiting those employees' options to compete freely on the US domestic labour markets. Employment is an area in which employers already have a natural advantage, a point noted (and explained in detail) 240 years ago by Adam Smith.

Offshoring introduces additional challenges to management -- it's simply easier to manage a workforce who rolls into the office and is locally present, though yes, remote (or occasional from-home) management is possible.

If a company wants to pay offshore-wages, then it can employ offshore talent, offshore, and incur the offshore management and logistics hassles. If it wants to hire domestic labour, it should do so at local labour rates.

If foreign workers are brought to domestic markets, allow them full mobility between employers.

Otherwise, the only effect of the H1-B program is to use one class of restricted-rights workers (the visa holders) to depress domestic wages through threat of a cheaper, effectively indentured workforce.

This has been clearly evident for years, and eloquently argued by Norman Matloff of UC Davis:

[http://heather.cs.ucdavis.edu/h1b.html](http://heather.cs.ucdavis.edu/h1b.html)

<comment><USER19> > The H1-B program allows employers to hire foreign employees, at below-market > rates

However, it's also by far the most attractive visa type for people from many countries. If I'm an e.g. German dev, what other options do I have if I wanted to work in the US long term? L-1?

> Otherwise, the only effect of the H1-B program

Obviously misuse isn't okay, but I'm sure they'd be chilling effects worth thinking about. I've always wondered why there aren't visa swap programs, i.e. if a Dutch and an American citizen wanted to live in the US/Netherlands respectively, why not swap (as long as some basic criteria are met)?

<comment><USER20> If you're a German dev, I doubt you'll come to US to work at Tata. Wouldn't be worthwhile. You might come to work at Google and such, but they wouldn't be affected by raising the bar as this law does, since they already comply with it in practice.

<comment><USER19> sure, but it's still the same visa class, right?

<comment><USER20> Yep. But not all legislation that pertains to it affects all companies that use it equally.

</comment></comment></comment></comment></comment></comment><comment><USER21> In many ways, I like the idea of setting a high minimum salary. It's a simple approach, but complex regulations often just produce elaborate ways to exploit loopholes. And honestly, the higher the salary, the less I worry that the visa is being misused.

100k still seems a bit low. I think Ted Cruz suggested 110k. That's still below the average salary for an applications developer in SF or San Jose. I'd go higher, though I do think that 110k would do some good - it would have no effect whatsoever on the use of the H1b to bring in the truly talented, and it would probably deter some of Disney/Edison style abuses.

</comment><comment><USER22> I think in our industry we have a huge wrench. It's very hard to hire experienced Americans in Silicon Valley right now because the cost of living is so high. There's no way that an experienced engineer, making a Silicon Valley salary, can afford the same kind of home that he/she expects everywhere else in the country.

In contrast, an H1-B from a country where homes are typically smaller, might think the kind of home that he/she can afford in Silicon Valley is perfectly fine!

</comment><comment><USER23> People need to first understand that the minimum wage in america allows you to save more money as a single male then working as an engineer in a large part of India and many other poor countries.

The salary in my own country for a mid level software engineer is 600 dollars a month !

Think about that for a moment . . . .

Now imagine if you are a company, you can hire a developer with 10-20 years of experience at the cost below your junior developer.

Why won't you do it ?

The other part of the equation is the fact that if you do not do it you are a strong competitive disadvantage compared to companies.

Now many people on HN might want to crack down on this Donald Trump Style.

But actually cracking down on it will make matters worse.

Software, IP is really global these days.

So as soon as wages are pushed up in america, the flow of FDI ( which is growing at 5x every year in India ! ) will shoot even higher.

Someone made this argument that I find the best explanation for what is going on.

Countries like India have more untapped computational power compared to the US, just due to having 4x the population and not even 1:1 the wealth.

There is nothing immoral about what is going on.

Its capitalism working as intended - I also do not think americans are losers in this game, it just means they will not see any investment or improve in their standard of living while private money is busy improving the lives of everyone else.

<comment><USER24> Arbitrage in labor markets results in a regression to the global mean. Every year that wages do not grow in the US, the buying power of those wages decreases due to inflation (increasing the cost of living). This will result in the standard of livings of the US moving towards that of India. And as a US citizen, I do not want this. If capitalism worked as intended, we'd be a world full of slaves fighting for pennies and shitting in open pits while our masters live like kings.

<comment><USER23> I think that is not what is happening.

Standard of living in the US is growing - but very slowly.

While standard of living is increasing rapidly in developing countries.

You can see the same issue in China, where standard of living has actually grown rapidly.

I am not arguing to make American standard of living regress at the expense of improving the standard of living for other developing nations.

Standard of Living would have risen regardless of FDI money moving into India and China - the only difference is that western capital is allowed to make money off that development.

The issue is that the amount of money that is required to bring any massive improvement in living standard in western countries is really large. Things like self driving cars are much harder to create - then just copying current technology and distributing it.

This is why it should have been upto western govt to channel a lot of public money and tax multinationals aggressively so that western countries can have accelerated rate of growth.

</comment></comment></comment><comment><USER25> Keep in mind that Hillary and her running mate are pro H1B. A lot of people don't like Trump for good reason, but it makes it difficult to vote for her given that she is likely to work against my interests as an engineer.

<comment><USER26> 1\. More engineers = more valuable products built.

2\. Move valuable products in the market = more money to reinvest into building valuable products.

3\. More money invested into building products = more demand for engineers.

4\. Goto 1.

Being pro-H1B is in your interest because it increases demands for your skill set.

</comment></comment><comment><USER27> Is it me or I suspect the 100K lower limit is kind of ineffective?

Every time I ran the numbers about moving to the US, the minimum acceptable offer was well above that number.

<comment><USER8> I imagine it depends on your country of origin and current standard of living. There's two salary averages of current H1B holders quoted in the article at less than 80K

</comment></comment><comment><USER7> Make college free and give tax subsidies to organizations that have training programs and be done with it.

This program has been around for decades and was created in an effort to bring in skills not found in the country. If in all of that time we haven't trained up enough people to meet "demand" then we are obviously doing something wrong and non immigration intent visas aren't going to fix it.

</comment><comment><USER28> A while ago I searched on the data, the majority H1Bs are from India and China. China took about 12%, most of them are graduated in USA, India had about 47% of all the H1B visas, most of them are from India and were put under India's consulting companies. The current lottery system for H1B might have changed that situation a bit, as it might be able to prevent possible abuse.

</comment><comment><USER13> USA does not have any visa that would help companies bring in outside talent at cheaper rate. Create that sort of visa first else H1B would always be a mess.

<comment><USER10> Politicians in democratic countries overtly suppressing wages for the benefit for the super few (0.001%) is not politically feasible and anecdotally, is probably bad in a consumer driven economy (which the US is).

<comment><USER13> I am not sure what that means. Politicians can suppress wages ? When have they done it in past ? Isn't the overwhelming support for illegal immigrants in USA from democratic party similar to what you are talking ? Why is that there is such a massive support for illegal mexicans but not for legally immigrating highly educated Indian and Chinese ?

</comment></comment></comment><comment><USER29> I was talking to my friend yesterday, she works for AT&T. She described being overworked, and, while she was paid well compared to other PMs, she considered the idea of taking a pay cut in exchange for a better managed workload.

The problem was that her reports were all leaving her project or leaving the company. The company was responding to the staffing difficulty with outsourcing, moving her entire project to Israel. Directors were squabbling over the most capable employees and twice she was approached about switching departments.

She has a friend who nominally is an architect, but is instead doing the work of a frontline dev. He's about to jump. Recruiters have made the job market liquid enough that businesses can't meet their objectives with the coders they hired.

In some sectors, coders right out of school can command six-figure salaries, and they're only going higher. In the larger job markets, firms are moving en- masse to consulting companies to meet business needs. The developers are following suit. 5 months ago, I worked at a marketing company as an in-house dev. I now work for a consulting company, my old company hired a consulting company to do my old job. I am somebody whose natural tendency is towards loyalty. I want to find a nice position at a nice company and just stay there for years. The current job market makes that impossible. The siren's song of getting a 30% pay bump every year, sometimes twice in the same year, is impossible to resist.

Make no mistake about it, the US needs more developers. Immigration is an excellent solution to the problem. Protectionism is only going to make it worse. If businesses can't meet their objectives, then end result is going to be a recession. No one comes out better in one of those.

<comment><USER30> I read sentiments like yours frequently. It does not match my experience.

Many of the companies I have talked to have fairly large lists of requirements for positions and are serious about requiring them. They get really picky about specific languages, frameworks, and experiences. As I mentioned in another discussion here recently, there are tens of thousands of programming jobs controlled by companies who do not see a programmer shortage from their perspective.

When discussions on hiring methods come up, multiple people inevitably chime in that the companies in question are dealing with situations where they have more qualified applicants than slots. That is in direct conflict with what you said above.

I would love to be able to jump jobs for 30% pay raises. I can't. I started my career at $55,770. I'm up to $92,500 14 years later, which is only a 66% bump for my entire career. Even if we consider me underpaid for my area (Hi! I'm looking in Dallas!) I would likely only be looking at a 100% total career bump if I got that situation addressed. There _are_ companies out there who refuse to give you more than X% above your current salary, regardless of how underpaid you are.

It's funny that you should mention AT&T, what with them being headquartered here and all. I see them as one of the companies I was referring to in my second paragraph. I have personally applied to them for multiple positions and heard bupkis.

It may well be that certain sectors in certain markets have these issues. I do not see it as widespread. What I do see as widespread are broken recruiting and sourcing practices, HR departments that work at cross purposes to the other departments they support, and a general desire to hit all the points on a wish list, no matter how long it takes.

<comment><USER31> Not to offend you or anything, but have you considered that the problem of your potential (better) employment is you. I see a lot of people claiming that the H1B program is bad and that there are tons of developers available in the US etc. But my experience is the polar opposite.

And to make things clear - I am actually a H1B holder, working as a CTO for a US based company, been here for 3 years now. When looking for people for our engineering team, we get lots of resumes but very few actually promising ones. Out of the promising ones, almost none are actual people with tangible experience that could be hired as a senior person. If there is someone who could be senior, they ask for like 200k and up a year - and this is just to be a senior engineer, not even in a managerial position or anything (P.S and this is the NOVA area, not the bay area).

So yeah, I would say good people are always in high demand, and the lack of good engineers right now is troubling. Then again most of the H1B visas get abused by companies who hire second rate talent from abroad so...

<comment><USER30> > Not to offend you or anything, but have you considered that the problem of > your potential (better) employment is you.

I have considered that, but I would think I would be getting and failing more interviews if that was the case. I have a hard time _getting_ interviews.

> When looking for people for our engineering team, we get lots of resumes but > very few actually promising ones. Out of the promising ones, almost none are > actual people with tangible experience that could be hired as a senior > person.

What do you consider "promising" and "tangible experience"? I have been refused interviews because of _who_ I have worked for, without anyone delving into whether I might still have the experience desired.

> If there is someone who could be senior, they ask for like 200k and up a > year - and this is just to be a senior engineer, not even in a managerial > position or anything (P.S and this is the NOVA area, not the bay area).

You realize that NoVa is not much cheaper than the Bay Area, right? I mean, $200k for no management responsibility in NoVa is ridiculous to ask for, but I would expect $150k - $160k.

> So yeah, I would say good people are always in high demand, and the lack of > good engineers right now is troubling.

So what is "good"? I have been told before that maybe the problem is me. Nobody has ever told me I'm not "good", though. I have consistently been one of the best engineers (software and systems at least; I was a bit dicier at electrical) wherever I have worked. I am an order of magnitude more competent than the anecdotes that come up during these discussions. Yet I get refused interviews because my background is "too government" and similar bullshit. I would love for someone to tell me there is something objectively wrong that I can fix. Nobody has done that. Except for my resume; fecack did a good job with that. Doesn't help with the aforementioned bullshit rejections, though.

<comment><USER29> > I have been refused interviews because of who I have worked for, without > anyone delving into whether I might still have the experience desired.

Consider taking those companies off your resume. I'd prefer a gap in the resume to a negative item. A gap can be explained any way you want in an interview, but a negative item will cause you to get rejected before you even begin.

<comment><USER30> The problem is the company is Raytheon, and I spent the first 9.5 years of my career there. It isn't something I can just drop.

<comment><USER32> I've dropped the first 10 years of my career so I could fit my resume onto a single page. Nobody even asks or cares. No employer even reads your resume past the first half of the first page.

<comment><USER29> Now that I think about it, it's good practice for anybody to just put the last few years on a resume. Unless you are actually selling yourself as someone with 14 years in X, with an expectation of commensurate salary and responsibilities, it's noise and should just be left off. Noise on a resume is unforgivable.</comment></comment></comment></comment></comment></comment></comment></comment>


Ask HN: List of books published by Google employees? - <AUTHOR>

A Google search didn't return much. These are the ones which I know of:
"I'm Feeling Lucky: The Confessions of Google Employee Number 59" by Douglas Edwards
"How Google Tests Software" by James A. Whittaker
Any others?
Edit: Clarification: I meant those who were Google employees at some point as well as those who are working at Google now. <comment><USER2> Giigle: How I Got Lucky Massaging Google

[http://www.giiglebook.com/](http://www.giiglebook.com/)

This is a real thing.

</comment><comment><USER3> "The Silicon Jungle" by Shumeet Baluja.

</comment><comment><USER4> Authored while an employee or authored by someone who at some point in their life had google on the resume? There will be some overlap, and one will be longer than the other.

<comment><AUTHOR> >authored by someone who at some point in their life had google on the resume

This is what I meant - edited the text just now.</comment></comment>


Deep learning may need a new programming language - <AUTHOR> https://venturebeat.com/2019/02/18/facebooks-chief-ai-scientist-deep-learning-may-need-a-new-programming-language/ <comment><USER2> What about Julia[1]? Seems like a perfect fit[2].

[1] [https://julialang.org/](https://julialang.org/)

[2] [https://juliacomputing.com/domains/ml-and- ai.html](https://juliacomputing.com/domains/ml-and-ai.html)

<comment><USER3> It is not typesave and doesn't really support programming in the large. I think the best bet is something like Swift or Microsoft could come out with a C#/F# compatible thing.

<comment><USER4> I was curious about Julia, mostly to experiment with the Flux machine learning library. I tried some 'general purpose' Julia programming: network IO, consuming RDF data, some natural language processing/text processing, etc.

I was specifically interested in the question 'could Julia be my general purpose language?'. In reality, I am too much into Lisp languages, Haskell, etc. to seriously want a new language, so this was just a two evening experiment.

<comment><USER5> > In reality, I am too much into Lisp languages, Haskell, etc. to seriously > want a new language, so this was just a two evening experiment.

But what did you think of Julia?

<comment><USER4> Julia is a very nice language. Still, I would not use it for a large project with many developers: similar situation as Python.

</comment></comment></comment></comment></comment><comment><USER6> >Python ... the language forms the basis for Facebook's PyTorch and Google's TensorFlow frameworks

The state of journalism today ... their Github repo web pages show that there's more C++ than Python in both repos.

<comment><USER7> To be fair, while that's true I think what's meant here is that Python is the language of choice for _using_ Tensorflow and PyTorch. Probably no other language is used to interface with deep learning libraries and primitives as much as Python.

<comment><USER6> >I think what's meant here is that Python is the language of choice for using Tensorflow and PyTorch

So it's a good editor that's lacking too, besides the fact-checkers.

</comment></comment></comment><comment><USER8> This is the reason why swift for tensorflow initiative was started by Google - [https://github.com/tensorflow/swift/blob/master/README.md](https://github.com/tensorflow/swift/blob/master/README.md)

Facebook will obviously go its our own way. Given their investments in the JS ecosystem, im hoping they end up choosing Typescript for this.

<comment><USER9> Is Facebook adopting Typescript or are they still full-in on Flow, their own competing typed Javscript alternative?

<comment><USER8> [https://news.ycombinator.com/item?id=18918038](https://news.ycombinator.com/item?id=18918038)

Jest is a Facebook project for testing React. They moved from Flow to Typescript.

[https://github.com/facebook/jest/pull/7554](https://github.com/facebook/jest/pull/7554)

Dont want this thread to go OT. But I do think Typescript will be an awesome counterpart to Swift-for-Tensorflow on the ML side.

</comment></comment></comment><comment><USER10> Im sorry, but this very much feels like a fluff piece. Yes we _may_ need a new programming language, or we may not.

Half of this article is about hardware, while only a small part of it is about programming languages.

> There are several projects at Google, Facebook, and other places to kind of > design such a compiled language that can be efficient for deep learning, but > it's not clear at all that the community will follow, because people just > want to use Python

Are the libraries not implemented in native code? The brief mention that python gets does not really detail what is wrong with it, aside from not beeing compiled I guess. But that is no issue if the libraries are native, so I dont see a reason to move away from python, let alone create a new programming language for it

<comment><USER11> You don't have to check baby's diaper to know they went number 2.

Python ML code is a bit of a joke. If you're any kind of semi professional developer who sees deep learning code for the first time and doesn't say "what the fuck would you do it like that for", I simply don't know what to tell you.

Im not saying a new language will fix this problem but some new primitives and idiomatic options protecting people from themselves probably wouldn't hurt the industry.

Likewise, something more ergonomic might actually improve onboarding new developers into the space.

<comment><USER12> poo-poo, people will insult your sensibilities using whatever language you choose, the "problem" is not them, or the language or its idioms, its you.

If you write ML code for money, you are a pro, the end. Python is not perfect, but everything else is worse, far worse. What is the product that falls out of a ML pipeline ? ML pro-tip: its not hand-crafted artisanal code.

<comment><USER11> My complaints about ML prettiness were unclear but to clarify it's usually criticism aimed at library authors who often come from very academic backgrounds with very poor sense (lack of exp?) of just how lazy professional developers are. Case in point, you don't care if it comes out as poop because you're getting shit done. Hell it seems like you don't even care if you have to wade in it for another 5 years.

Kudos, but what if i told you if the tooling authors could have ensured you never wrote poop but still got shit done?

</comment></comment></comment></comment><comment><USER13> The main problem, imho, is that (for best performance) most libraries require the programmer to create a data flowgraph, and to think in terms of this graph. However, this is the perfect job for a compiler. In mainstrain compilers, dataflow analysis has traditionally been the task of the compiler, so it seems silly to break with this tradition. A new (compiled) language could bring us back on track.

<comment><USER14> I'd probably argue the opposite. Dataflow is a natural way to think about ML activities. The problem is that no mainstream languages offer dataflow as a first class construct; at best it's a set of libraries. That creates some impedance mismatch between intent and implementation. That compilers already do dataflow under the covers would hopefully mean that implementing a first- class dataflow language wouldn't be too hard.

<comment><USER15> What would a language primitive for "dataflow" look like, and what would it offer over an implementation as a library?

<comment><USER14> There are a few things, nicely covered in "Concepts, Techniques and Models of Computer Programming" by Van Roy and Heridi [0]. Briefly:

1\. First-class dataflow variables 2\. Syntax for creating flows (c/f pipe in *nix shell) 3\. Transparent parallelisation

All of these things exist in libraries of various sorts, but can feel cumbersome compared to native syntax.

[0] [https://mitpress.mit.edu/books/concepts-techniques-and- model...](https://mitpress.mit.edu/books/concepts-techniques-and-models- computer-programming)

</comment></comment></comment></comment><comment><USER16> I know Nim has some interesting working going on here, [https://github.com/mratsim/Arraymancer](https://github.com/mratsim/Arraymancer)

As well as that esolang that appeared a few months ago on the front page. [https://github.com/mrakgr/The-Spiral-Language](https://github.com/mrakgr/The- Spiral-Language)

</comment><comment><USER17> It would be hilarious if everybody suddenly shifted to a Prolog implementation with ML functionality ¯\\(°_o)/¯

<comment><USER18> I like the idea.

There are two types of ml jobs. One for modeling and another for computation. The former deals with the communication with human. The latter deals with the communication with machines. I would prefer that a statistical logic programing language (maybe extended from prolog) for the modeling part. A strong compiler tool or service that compiles it into any machines, on cloud or edge. Most of the time, what human likes to achieve is small and declarative. But for any small modifications of the program, we have to think about the computational flow, deal with the type errors and tune the low level efficiency of CPU and GPU. It's a waste.

I like the settings of SQL where modelers use SQL to mine data while engineers maintain the performance of the computational engines.

</comment></comment><comment><USER19> There's already Nim ([https://nim-lang.org/](https://nim-lang.org/)), which is Python like syntax and statically typed, with easy parallelisations etc already. What's lacking is the adoption as it wasn't hyped up. There's rarely a need to create yet another language and wait till it becomes mature and fixed all the issues with the eco system etc. If at all what's required is a way of translating all the Python libs to Nim or some similar effort.

<comment><USER5> In my opinion, I'd rather see F# or Julia succeed.

</comment></comment><comment><USER20> Why did everyone dump C++? Oh wait, they didn't.

<comment><USER21> Depends on the context.

On GPGPU programming certainly not, in fact latest NVidia's hardware is designed explicitly for C++ workloads.

On GUI frameworks, C++ no longer has the spotlight on OS SDKs that it once had.

<comment><USER20> My point is all AI worth its salt (robots) is C++ based in production.

<comment><USER21> There I fully agree with you, specially with NVidia doing C++ in hardware.

<comment><USER22> NVidia is adopting ADA/Spark for autonomous vehicles work [1]. It's service- proven, compiles to C/C++ speeds, and is safe. I learned Turbo Pascal in college in the 80s after Basic, C and assembler in the late 70s, early 80s, and I am attracted to languages like Haskell, Julia, Lisp, and J/APL, yet after toying with Spark, I think it is probably a good fit to do safe, ML at C/C++ speeds. It would be easy to hook it into all the C++ of TensorFlow too.

[1] [https://blogs.nvidia.com/blog/2019/02/05/adacore-secure- auto...](https://blogs.nvidia.com/blog/2019/02/05/adacore-secure-autonomous- driving/)

<comment><USER21> Yeah that as well.

I belong to the same fanboy club, which is kind of why I do like C++ and not so much about C.

I just don't see many adopting it without legislation enforcement, which is why the focus is on autonomous vehicles, where Ada already has a good story.

<comment><USER22> If I am not trying to write verbose, safe code with things like Rust or Spark, I still have a thing for low-level C vs. C++ bloat for fun stuff. I am going to commit this year to Spark, and probably Rust if Spark doesn't work for me, and then C++ after Rust. I have not used C++ in years, so I need to look at the latest and greatest before passing judgement.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> I wonder what he thinks about Julia. There are lots of projects to turn it into an "ML language".

<comment><USER5> I think it was explicitly designed as an "ML Language" from the ground up already. Do you mean packages like Flux and KNet?

</comment></comment><comment><USER24> I'd much rather a deep learning system that could handle simplified natural language and file operations, and then grow a network for specific tasks. Surely the point of AI is to liberate humans from having to write everything in code, and especially from needing to learn another language (which he fairly observes few people want to do).

I do everything flow-based these days. It's not the fastest way (and I also have the luxury of not having to please anyone but myself), but it allows me to only think about my domain problem instead of programming language issues.

<comment><USER4> Maybe not quite what you have in mind, but I have tried saving trained Keras models, loading them with Racket (a modern Scheme language), and implemented the required runtime. My idea was to encapsulate trained networks like 'functions' for use in other languages.

<comment><USER5> And?

<comment><USER4> and... I think this is a neat idea and I thought other people might enjoy trying it. code (2 repos) is on github

</comment></comment></comment></comment><comment><USER25> Sounds like FB is also working on its own AI chips:

[https://www.bloomberg.com/news/articles/2019-02-18/facebook-...](https://www.bloomberg.com/news/articles/2019-02-18/facebook- s-ai-chief-researching-new-breed-of-semiconductor?srnd=technology-vp)

[https://www.ft.com/content/1c2aab18-3337-11e9-bd3a-8b2a211d9...](https://www.ft.com/content/1c2aab18-3337-11e9-bd3a-8b2a211d90d5)

</comment><comment><USER26> Fortran is going to make a big comeback. I can feel it.

<comment><USER27> > Fortran is going to make a big comeback. I can feel it.

It is indeed one of the few existing languages appropriate for generic experimentation in numeric programming.

For example, computing the product of two matrices in C or Fortran is exactly as fast by writing three nested loops or by calling a library function. In python, julia, octave, etc, the difference is abysmal. This is a very sad state of affairs, that forces a mindset where you are allowed a limited toolset of fast operations and the rest are either slow or cumbersome. If you want to compute a variant of the matrix product using a slightly different formula, in Fortran it is trivial change, you just write the new formula inside the loop. But in python or julia you are stuck with either an unusably slow code or you have to write it in another language entirely.

"Vectorized" operations are cool, elegant, and beautiful. But they should not be the only tool available. As differential geometers often resort to coordinates to express their tensor operations, so should programmers be able to.

<comment><USER28> Have you used Julia recently? Vectorised operations are just as fast relative to hand written loops as c and FORTRAN, you just need to appropriately annotate @inbounds and @simd. Sure that's more work, but removing safety checks should be explicit.

<comment><USER27> Not recently, thanks. I will surely try!

My main gripe with the julia interpreter was that it was ridiculously slow to startup (I was using it as a "calculator" from within a shell loop: each iteration spawned a julia to perform a simple matrix computation). Does this performance has improved recently?

By the way, what do you mean by "removing safety checks should be explicit" ? This sounds like a problem that the language should be able to deal with itself without bothering the programer (e.g. if the bounds of the loop are variables of known value, it can be checked beforehand, so the bounds checks can be safely omitted).

<comment><USER5> AFAIK it was designed for long running processes, not for quick start up time. On the other hand, I don't find it that slow for experimentation on the REPL.

</comment></comment></comment></comment></comment><comment><USER29> We may need a programming language for DL, but I doubt it'll happen soon, if it even happens. Lindy effect working in favor of Python here, as many data scientists have prior "big data" experience in it, and typical software engineers from the "scripting/tooling" world.

People have been calling for the phaseout of C/C++, but even today's most popular DL frameworks have backends written in C++ in lieu of Rust.

</comment><comment><USER30> > Deep learning may need a new programming language that's more flexible and > easier to work with than Python

Whoever has imagination more rich than mine, how can a programming language can be easier than Python? What's difficult in it?

The only thing I find inconvenient in Python is you can't simply put every function (including every member functions of a class - that's what I would love to do) in a separate file without having to import every one of them manually.

<comment><USER31> Read it again. He/She did not imply that Python is hard.

I do believe that he/she meant that they need way higher levels of abstraction than Python.

Let's say Python is current C, they want something X that's like Ruby in compare to current C.

<comment><USER30> It's just hard for me to imagine a higher level of abstraction. That's why I invite whoever has imagination more rich than mine to suggest ideas.

<comment><USER32> Have a look at Prolog, that might expand your mind a little.

</comment></comment></comment></comment><comment><USER33> Yes. Deep Learning definitely needs a new programming language. Uber's Pyro is worth checking out. ([https://eng.uber.com/pyro/](https://eng.uber.com/pyro/))

<comment><USER34> Umm that's not a programming language as such, it's a probabilistic programming DSL built on top of Python/Pytorch. It's one level of abstraction up.

</comment></comment><comment><USER35> I'm not the biggest Python fan, but I can definitely tolerate it, as long as I have a decent way to use the models from another language.

</comment><comment> pi-victor i always thought Haskell would be amazing for this task.

but python is really popular and easy to grasp. you'll end up writing a new programming language and people would still use python in the end.

</comment><comment><USER36> I thought that language was Julia.

</comment><comment><USER37> More likely a markup language

</comment><comment><USER38> sql

</comment><comment><USER39> 1\. Features 2. Performance 3. Usability

You can pick only two options;

<comment><USER40> Or use Rust to get all 3!

<comment> semi-extrinsic I'm sorry, but Rust certainly doesn't score high on usability. Compare e.g. the "Guessing Game" intro from the official docs, just look at how much more complicated both the code and the tutorial is as compared to how you would do the same in Python, heck even in Fortran:

[https://doc.rust-lang.org/book/ch02-00-guessing-game- tutoria...](https://doc.rust-lang.org/book/ch02-00-guessing-game- tutorial.html)

<comment><USER41> I don't think comparing 100 line programs is a good benchmark for usability. Most software is much larger and the design choices you have to make for a programming language should favor programs with at least a few thousand lines of code.

<comment><USER21> Then try to do a few thousand lines of code in Gtk-rs, including custom widgets, the issues with borrow checker and internal mutable struct data accessible to callbacks is what lead to the creation of Relm.

<comment><USER41> The GUI story in Rust is currently terrible, I agree. But writing GUIs in Python with wrappers to C(++) libraries is not exactly nice either ;)

<comment><USER21> To me it looks pretty nice.

[https://www.qt.io/qt-for-python](https://www.qt.io/qt-for-python)

</comment></comment></comment></comment></comment></comment></comment><comment><USER42> This guy - or the article's author - hasn't heard of DSLs?</comment>