Deadly stupidity during Aeroflot flight 1492 emergency evacuation - <AUTHOR> http://www.askthepilot.com/deadly-stupidity-in-moscow/ <comment><USER2> This person did not bother to read anything about the incident but is quick to blame "people's stupidity". There were plenty of details available before this was posted on May 9th, including the Wikipedia article.

> If indeed lightning touched off a fire aboard Aeroflot 1492, this would be > highly unusual

No, the lightning did not set off a fire. There was no fire until it landed. See Wikipedia Aeroflot 1492.

> there's evidence that the death toll was higher than it should have been, > thanks to the selfish actions of a number of passengers

Fails to reference any of this evidence. All eyewitness accounts I've read (see below) say the passengers with bags were business class and they did not interfere with the evacuation. The state news said 4 days ago the evacuation was completed in 55 seconds (last link at the bottom). Sure, they are lying and this guy has better sources but he failed to mention where he got his "evidence" from.

Eyewitnesses (a passenger and a flight attendant) say the back of the plane filled with thick smoke and started melting even before it stopped. The only people who survived in the rows 12+ were the two who rushed to the front while the plane was still moving. By the time the plane stopped people in rows 12+ were most likely already unconscious. Yet, TFA's author is smearing people as "stupid" and is 100% certain it was the stupid luggage people.

[https://ria.ru/20190507/1553334256.html](https://ria.ru/20190507/1553334256.html) [https://lenta.ru/news/2019/05/06/saved/](https://lenta.ru/news/2019/05/06/saved/) [https://tass.ru/proisshestviya/6403085](https://tass.ru/proisshestviya/6403085)

<comment><USER3> Please, before I rush to judgement, in what way does taking a suitcase even by a single individual not create a few seconds lost for those further down the line?

I saw the footage and my first thought was exactly that of the OP. Tens of suitcases means tens of seconds delay. In an incident that gives you at most a few minutes for evacuation at least some of the dead are attributable to the actions of those carrying suitcases. That is criminal negligence in my book.

I now see another response quoting a Russian reponse indicating there was no congestion. Technically only the last survivor coming out could answer that question. For me, it seems strange that all the fatalities were instantaneous, while the survivors were unhindered. I'd imagine that with a broken up fuselage but not with a unbroken fuselage on fire. Perhaps the OP is overly emotional, but it's emotion pointing to something that is clearly wrong: people value belongings wrongly in case of serious accidents and the training should help people cope with that. I once saw a video of people trying to get their backpacks in case of a flash flood. They did not survive. Your property is basicly worthless compared to you being alive. We should learn to extend that to other people in case of emergency.

<comment><USER2> > few minutes for evacuation

The evacuation was completed in 55 seconds. People in the back were stranded/unconscious/buckled-up before the plane even stopped. The eyewitness reported (see links in my post) he had to _crawl on all fours_ out of the plane through thick smoke through a completely clear aisle. People with bags were the ones sitting immediately in the first few rows, they did not cause a congestion.

I would be pissed off as anyone if luggage grabbers killed someone, but it seems they weren't the "deadly stupidity" here? I mean, the dude just wrote the whole pompous blog post with a flashy title off an unlikely rumor?

<comment><USER4> > People with bags [...]

SHOULD NOT HAVE HAD THEIR BAGS. END OF STORY.

You say yourself the last survivor existed after 55 seconds. Did bag carriers cause even a two second delay? Could one extra person have crawled out from the smoke before succumbing? Perhaps that 12 year old girl?

You (and I mean anyone but if you fly I literally mean you) should not be making these sort of calculations when deciding to carry or not carry. Do not carry. Exit.

<comment> crooked-v A quote from the last survivor off the plane says that the aisle in front of them was completely clear as they left. In other words, any delays that might have happened weren't actually enough to harm or kill anyone in and of themselves.

<comment><USER5> Or someone ahead of there spent several seconds pushing bags out of the aisle, and not everyone realized the speed of evacuation was being determined by obstructions. Or, not every piece of luggage causes the same slowdown, and the first piece of luggage with significant delay caused the choke point for all of those who didn't make it out. Or a dozen other scenarios. We just don't know.

90% of highway traffic jams I drive through end up having no visible cause. That doesn't mean that there was never anything in the road causing a slowdown.

</comment></comment></comment></comment></comment></comment><comment><USER6> The article talks about stupidity, and these people are often marked as idiots. It is important to note that people follow patterns. Dazzled, scared, and panicking people even more so. I don't know what is the solution to this problem, but I bet the first step is to drop the labels, accept that this is how many reacts currently and design around that behaviour.

Take for example fire exits. We know masses have died meters from safety because they couldn't figure out to pull instead of push, or had the calm to handle a door knob. Did we blame their 'stupidity'? No, we mandated outward opening doors and push-to-open emergency latches.

<comment><USER7> _or had the calm to handle a door knob [...] we mandated [...] push-to-open emergency latches_

Tangent, is that about focus & presence of mind or the knob getting hot? Much easier to push open a hot latch with your clothed shoulder than to turn a red- hot knob.

<comment><USER8> There were a few incidents where people were crushed to death by a panicked crowd trying to flee burning buildings. With that much force behind you, there's no way to open an inward door. It'll also generate a lot of friction between the bolt and strike plate, making a traditional doorknob hard to open.

The new-style emergency exit door is designed to act like a pressure release valve— if a person is pressed up against the inside with life threatening force, the door opens automatically and lets the fleeing crowd out.

</comment></comment></comment><comment> orbital-decay The article raises a valid concern, but the last person who left the plane alive said in a recent interview that there was no congestion in this particular accident. [0]

 _> Я ничего не могу сказать насчет сумок, про которые все говорят. Мне они точно не помешали: я шел последним, за мной никого не было. Я уже не могу сказать, сколько мы ждали, пока проход освободится, — время относительно, не могу точно оценить. Но я не могу сказать, что что-то тормозило эвакуацию. Был только один момент — одна женщина побежала вперед и упала, но ее вынесли. Никакой давки в самолете не было._

[0] [https://meduza.io/feature/2019/05/07/ya-shel-poslednim-za- mn...](https://meduza.io/feature/2019/05/07/ya-shel-poslednim-za-mnoy-uzhe- nikogo-ne-bylo)

<comment><USER9> > I can't say anything regarding bags, about which everyone is talking. They > definitely didn't get in my way: I went last, there was nobody behind me. I > can't say how long we waited until the way was clear -- time is relative, > and I cannot judge precisely. But I cannot say that there was anything > interfering with the evacuation. There was one moment -- one woman ran > ahead, and she fell, but she was carried out. There was no stampede/crush on > the plane.

</comment></comment><comment><USER10> At least one aggrevating factor seems to me to be the fault of the airlines.

They were so busy adding fees to checked-in luggage that everybody now tries to stuff everything into their carry-on.

If the majority of people's luggage was checked in, it would not make the problem go away, but some selfish idiot running out with his laptop under his arm is a lot different than the same idiot trying to get his laptop AND his oversized wheelie bag off the plane.

<comment><USER11> Even if checked-in fees went away, I would still try to go cabin luggage only for short trips away (anything under a week) because it is significantly quicker than waiting for luggage to be unloaded etc.

And for what it's worth, I use a backpack, so it's often stored at my feet due to locker space pseudo reserved for hard cases.

<comment><USER12> On many budget carriers, a personal item that fits under the seat is actually all you get for free. You have to pay extra for a carry on bag.

<comment><USER13> Not in Europe.

<comment><USER14> Meanwhile, in real life Europe, check out the practices of low-cost carriers like Wizzair and Ryanair.

<comment><USER15> Wizzair was so expensive with carry-on luggage that I ended up putting most of my clothes in a cardboard box and shipping it to the hotel using DHL. My small backpack was free and I used it for toiletries and two days of clothes.

</comment></comment></comment></comment></comment></comment><comment><USER16> Those passengers aren't to blame, regulators and aircraft designers are to blame.

People are idiots in the aggregate, and reliably exhibit herd behavior counterproductive to their survival. Aircraft design must account for this.

There's something to the famous Feynman quote if we apply it in this context:

        "For a successful technology, reality
        must take precedence over public relations,
        for Nature cannot be fooled. -- Richard P. Feynman

In order to be certified aircraft must be completely evacuated during a test in 90 seconds. Here's such a test of the A380, Boeing etc. conduct tests in the same manner: [https://www.youtube.com/watch?v=XIaovi1JWyY](https://www.youtube.com/watch?v=XIaovi1JWyY)

These tests have been widely critiqued as completely unrealistic, e.g. here: [https://www.aerosociety.com/news/emergency-evacuation- time-f...](https://www.aerosociety.com/news/emergency-evacuation-time-for-a- rethink/)

Numerous real-world examples of emergency evacuations "in the wild" have shown that evacuations proceed _nothing_ like what's shown in these tests.

If aircraft manufacturers and regulators faced up to this we wouldn't have this problem. You'd get actual safety instead. E.g. design changes to aircraft mitigating the aisle blockages that _do_ happen in these evacuations, but aren't accounted for in tests, more emergency exits etc.

This is a recurring topic, e.g. in 2015 a BA flight in Las Vegas took 5 minutes to evacuate: [http://www.flight.org/the-numbnut-passenger-evacuation- of-ba...](http://www.flight.org/the-numbnut-passenger-evacuation-of-ba- flight-2276)

</comment><comment><USER17> FWIW the first reaction across all russian language sources was exactly the same as on this thread. From what I understand (based on later reporting and comments by two survivors) there were no delays due to people grabbing bags or anything else. The maim issue seem to have been the rear escape door not working. It might be a good idea to wait for official results of the investigation before calling for all sort of action.

</comment><comment><USER18> I've seen many posts like this in Russian media too. While the death toll is huge and the air carrier's stock has plunged 3% down, there is a natural motivation for existence of social media fakes blaming passengers. Someone shared similar post on Facebook recently from an account that was created a few months ago and has posted only 3 meaningless picture shares ever since. Initially many media outlets did not even mention air carrier's name in their stories covering the accident.

From multiple video sources it's clear that the plane caught fire only after violent progressive bouncing on runway. The preceding events (lightning strike, partial radio loss, overweight landing) set up a stage for a disaster but hardly were direct causes of the fire.

Having been a private pilot for a while, we, pilots, are trained for emergencies. For example, my instructor routinely idles engine power without saying a word during flight reviews. On FAA practical test you are supposed to glide and land an airplane that lost power completely. Though I hope to never encounter engine loss in real life, I did dozens of practice approaches with zero power.

However passengers are never trained. This accident's survivor witnessed that screams started after first bounce. When gear failed and fire ignited on second or third kick screams got louder. One couldn't hear crew instructions in this mess. You can't be sure you'd behave rationally until you're there.

If we want extra safety we should train for rare situations like this. How many ditching incidents you can recall beyond Hudson miracle of 2009? Then why explain how to inflate a life vest every time on board. Shouldn't we better teach passengers to leave their belongings, to crawl under smoke, to push other people out if they are unconscious? I would create a financial incentive for those travelers who undergone such a training and passed certain test.

Statistically, however, commercial flying today is much safer than traveling by car. In the US alone about 100 people are killed on the road every single day. So if we are optimizing for the number of souls lost during transportation, it is unclear what needs to be fixed with a top priority.

<comment><USER19> _"Shouldn't we better teach passengers to leave their belongings, to crawl under smoke, to push other people out if they are unconscious?"_

 _Teaching_ will help only a little, at best. You would have to _train_ passengers.

The more they're under stress, the harder it is for untrained passengers to deviate from their standard "leave a plane" program. That includes taking one's luggage and waiting for other passengers.

And yes, that applies to the life vests instructions, too. Advantage there is, that if you need those, chances are you'll have minutes to prepare (but often, passengers still will make the mistake of opening them while inside the plane)

<comment><USER18> Agree. You can't rely on everyone's behaving rationally. You should rather expect panic.

Though _knowing_ there _could_ be smoke or you _might_ need to crawl will trigger thoughts at least in a subset of people and will increase an overall survival rate.

As for life vests - even in Hudson accident they were left unused. Maybe in the 1960s they were helpful but for now they look obsolete. Chances are you'll get fire rather than ditching. I feel their value is more psychological.

</comment></comment></comment><comment><USER20> To this day, I still don't take more than a very small backpack on board any aircraft with me. I don't understand people taking huge roll ons with them in the passenger compartment?

Is it really too much to check the bags in and wait at the baggage carousel at the other end to retrieve them? Airlines need to can the exorbitant baggage fees to encourage people to check bags into the hold rather than try and take their entire 2 weeks vacation worth of stuff with them in the cabin.

It is particularly annoying that on almost every flight I am on, I have to remove my very small and light backpack (usually just containing a book and my phone, headphones etc.) from the overhead bins and am forced to stow it under my feet in front of me (I am quite tall, and prefer nothing on the floor in front of me to prevent me stretching my legs in the limited room available) in order to make room for hundreds of others who can't bear to wait a few more minutes at the destination airport. I try to travel light and take up as little room as possible on the plane, and I get penalised because too many people try to do the opposite. It is a lose-lose endgame.

Increase the incentives to check bags in the hold, restrict carry on even further - that should make it a much more pleasant cabin experience, even in a non emergency.

<comment><USER21> I think most people don't check bags because airlines lose luggage all the time.

<comment><USER22> Do they though? Or is that just people's perception? It's a common case in life that people operate on extremely inflated perceptions of risk, often related to how news invert risk perceptions (the more you hear about something on the news, the less likely it is to happen; journalists and article writers don't report on stuff that happens regularly).

<comment><USER23> The last 2 times I checked my luggage, at least one piece didn't arrive.

In one of those cases, it was our camping gear that we needed a few days later (luckily we got it the morning we left the hotel for that campground, which was a 4 hour drive from the hotel). The other case, it was literally all my cloths for a 5 day stay. It arrived 2 days later. (The airline paid for essentials.)

I know that the official statistics of lost luggage are very low. I'm sure that these number don't come close to reality, probably due to some technicality (e.g. 'lost' only counts when it never showed up, instead of showing up after a few days.)

When you plan vacations that go from one place to the other, with hotels, cars, and activities booked everywhere, the last thing you want to happen is throw it all into disarray because your luggage didn't arrive. (And, yes, we usually plan for a day or 2 close to the airport in case flights get cancelled etc.)

</comment></comment></comment></comment><comment><USER24> Oddly enough, this article is almost word for word the same as one about the Vegas crash it mentions (and links to): [http://www.askthepilot.com/emergency- etiquette/](http://www.askthepilot.com/emergency-etiquette/)

<comment><USER25> At the bottom of which is this interesting paragraph:

 _And for a slightly different perspective, here are some comments from Christine Negroni, aviation safety journalist and author of the Flying Lessons blog:

Like you, I found myself shaking my head when I saw the videos or read reports of people taking their carry on luggage off the plane. Then I interviewed a passenger on Asiana 214 [the 2013 crash-landing of a 777 in San Francisco] who had done so and was surprised by his explanation. He told me that when the plane came to a stop and the evacuation began, he acted by habit in gathering his things and only afterward did he realize what he was doing. So I think we cannot discount the effect of altered state of consciousness as playing a role in this behavior. You may have read about this as a form of "negative panic."_

Which may lead to a revision of Hanlon's razor:

 _"Never attribute to stupidity that which can be adequately explained by indifference."_

<comment><USER26> Even with flight attendants desperately screaming "leave your bags!" and a fire raging? More likely that person was just trying to hide his embarrassment.

<comment><USER27> I've never been in a flight accident (thankfully), but from my experience in amateur kickboxing fights when you're in a stressful environment (in a ring) and everyone is screaming, I don't think I ever heard a thing my corner was yelling at me, even if they were only a few metres away, my brain just went into auto-pilot. So I wouldn't discount his story.

</comment></comment></comment></comment><comment><USER28> It's a total trash article, just sensationally-hysterical crying.

"It's not clear at this point if the plane was on fire before it landed"

It is totally clear, just read more official sources. Plane was not on fire before landing. You can see it even on videos.

"While a deadly fire raged around them, witnesses say people were nonetheless stopping to collect their carry-ons, clogging the aisles and slowing the evacuation"

It's a lie. One of the survivors, who left the plane last (not first), witnessed there was no such issue, path was clear and evacuation was quick.

Engines didn't stop - they were working as blust furs, accelerating fire, so people behind the wings died in about 20 seconds. 2 people survived after row 12, just because they started running before the fire started.

Such an awful example of "sensational" journalism.

<comment><USER29> What are your a source(s)? As the official accident report hasn't even been completed (let alone released) anything else is just speculation.

<comment><USER28> There are links in other comments here. There are official statements already about accident, main version is "mistakes of pilots".

Before asking "sources" from just comment, try to find at least one "source" link in that click-biting trash we are discussing.

</comment></comment></comment><comment><USER30> > They are [evacuation slides] designed for no other purpose than to empty a > plane of its occupants as rapidly as possible.

They are also designed to be flotation devices.

</comment><comment><USER31> Maybe the luggage compartments should be automatically locked shut for any landing/takeoff thus preventing people accesssing them during an evacuation

<comment><USER32> How about mandatory jail time for anyone removing personal items during an emergency evacuation.

<comment><USER33> That wouldn't help much. That's after the fact, no one is going to be thinking about it during an evacuation.

Anyone who _would_ be thinking about it, already knows not to.

<comment><USER34> Well, it might help raise awareness if the proceedings get significant news coverage.

</comment></comment></comment></comment><comment><USER35> The most surprising thing to me was that while watching the plane driving along, turning, coming to a stop, there was not a single fire engine there. Why is nobody talking about that? Every time I saw some kind messed up landing, I saw fire engines rushing towards and/or behind the plane even before it lands.

<comment><USER36> Because the pilots never indicated there was an emergency warranting a fire crew.

<comment><USER35> Alright I can accept that.

However, the moment this plane hit the ground and started burning somebody at the tower should have seen it. I mean...probably many people saw it. What about them?

<comment><USER37> Airports are large. As in "huge". This is not obvious from airplane traffic, as airplanes are also fast, so they cover the distances at a proportionate speed. Check out any emergency landing videos where firefighters are visible: the trucks seem tiny and slow, even at top speed (which could be ~200 kph). Speculation from reports: firefighters were a) expecting them at a different rwy, b) chasing the plane as it touched down, but no video long enough to actually see them arrive.

<comment><USER35> Alright, let's not overdo this. I live in Frankfurt and I know what a big airport is. I also know that fire trucks are not THAT small...This was an emergency landing. The trucks should have been all over this plane the moment it touched down. Just as you can see it on many videos of even less dangerous situations. However there is not a single fire truck to see here: [https://www.youtube.com/watch?v=WmvcoAPLeuA](https://www.youtube.com/watch?v=WmvcoAPLeuA) nowhere. Even when people were already away from it. Also here: [https://www.youtube.com/watch?v=GX_tMKmUjbg](https://www.youtube.com/watch?v=GX_tMKmUjbg) you see people starting to get out of the plane. Nothing. There is some kind of vehicle coming over at the end but it's not a fire truck.

In this video (around 2Mins) [https://www.liveleak.com/view?t=k5Lw7_1557086404](https://www.liveleak.com/view?t=k5Lw7_1557086404) you see finally water from obviously a single fire truck being sprayed on the plane but there must have passed a very long time since the vehicle from the other video is standing on the right site and people are gathered around it.

So please. Don't tell me there isn't a massive fuckup here.

<comment><USER38> The fire trucks do not know where the plane will stop on the runway. A plane coming in to land will be going well over 100 mph. The fire trucks cannot be on the runway ahead of the plane (lest they be taken out by the plane and make the crash worse with the side benefit of now having more victims and less first responders).

It is physically impossible for the firetrucks to be at the plane the moment it stops.

</comment></comment></comment></comment></comment></comment><comment><USER39> This sounds like a great reason to:

a) strongly enforce minimal luggage overhead

b) require free luggage transport (up to certain limit)

c) provide much stronger penalties if airlines lose luggage

d) provide strong penalties if an airline allows too much luggage in the passenger compartment

In Japan, having lots of luggage in overhead bins is rare. However, I've never been inconvenienced by lost luggage, or had to wait very long (if at all) for luggage at the carousel.

If the airplane was a commercial building, it seems likely that the overhead bins would be banned by fire code.

</comment><comment><USER40> This is a sobering reminder that keeping something like [https://cooltravelstuff.com/product/pocket-smoke- mask/](https://cooltravelstuff.com/product/pocket-smoke-mask/) in your carryon may save your life if you have the misfortune to end up in a situation like this.

There have been several accidents where passengers perished in an otherwise survivable situation due to smoke inhalation. The most well-known example is [https://en.wikipedia.org/wiki/British_Airtours_Flight_28M](https://en.wikipedia.org/wiki/British_Airtours_Flight_28M) which had to abort a takeoff due to an engine fire where leaked fuel ended up quickly burning through the fuselage in a similar manner to what appears to have happened here.

Whether you think the risk is worth the hassle is up to you to decide.

</comment><comment><USER41> Would being able to lock overhead compartments remotely solve some of these issues? Have a hardware switch somewhere for staff for emergencies to literally make it impossible for people to get their stuff.

I kind of thought something like this was already possible but never gave it more thought

<comment> crooked-v That sounds like it would lead to people blindly smacking at the overhead compartments in a panic when their brain gets stuck in a loop at "step 2, get bag". Sudden operational mode changes in emergencies have a long history of causing that sort of brain shutdown.

</comment></comment><comment><USER42> Basic Laws Of Human Stupidity

[http://harmful.cat-v.org/people/basic-laws-of-human- stupidit...](http://harmful.cat-v.org/people/basic-laws-of-human-stupidity/)

<comment> crooked-v That needs a sixth law: "in emergencies, most people turn into stupid people".

</comment></comment><comment><USER18> Official sources deny it, from Wikipedia Aeroflot 1492:

The information that evacuation was delayed because some passengers grabbed their baggage have not been confirmed. According to TASS's law enforcement source the majority of passengers in the tail end of the aircraft had practically no chance of rescue. "This is evidenced by the position of the bodies of many passengers who were found in the tail of the aircraft. They did not even have time to unfasten their seat belts, they died of poisoning in their seats. Someone might have lost consciousness when the plane hit the runway. The causes of death of all the victims are now established" \- said the source. He added that the passengers from the tail section of the aircraft, who managed to escape, moved to the front of the aircraft even before it stopped.[10] According to witnesses some baggage fell from overhead compartments during the hard landing and passengers removed them in order to free the passage.[11]

</comment><comment><USER43> Companies are also at fault for keep cramping the seats and putting heavy fees in checked luggage so that everyone ends up only taking hand luggage.

Regulations are needed.

</comment><comment><USER44> > The briefings need to be shorter and more concise, and this needs to be a > part of them

This.

Instead we get airlines making [un]funny short films stuffed with celebrities (yes, I'm looking at you, BA) because their marketing department knows it's sure-fire PR and they'll get tens of millions of clicks/views/shares on social media out of it.

<sigh>

<comment><USER45> I normally never pay attention to the briefings because I just heard too many of them. But the BA is funny. Works for me.

More general about the briefings: The explanation of the life vest seems to take most of the time. I often wonder how many airplane accidents involved landing on water, making that instruction worth having every single time. Maybe someone knows ?

<comment><USER46> Also, how to open and close a seat belt. Do we need that?

<comment><USER47> _sigh_ yes

I had to help a passenger once. I didn't think it was important before that.

</comment></comment></comment></comment><comment><USER48> Here is an interview with one of the survivors: [https://meduza.io/en/feature/2019/05/07/i-was-the-last- one-w...](https://meduza.io/en/feature/2019/05/07/i-was-the-last-one-walking- out-there-was-no-one-behind-me)

TLDR: news about passengers taking luggage and blocking the evacuation are probably fake, most of the people who died couldn't evacuate because they died from CO-poisoning in seconds.

</comment><comment><USER49> Maybe the overheads compartment should lock and remain locked in the event of an accident so that people are forced to leave some of their carry-ons on the plane.

</comment><comment><USER50> I hope these cases could be added to flight safety manuals, when and where this accident happened, how many people died and most importantly, why.

This could be so much better than a simple "Don't bring your luggage during an emergency exit" sentence.

</comment><comment><USER51> It may be time to start prosecuting people that carry anything out during an emergency evacuation. A heavy fine (at least) seems a reasonable price to avoid loss of life in future.

<comment><USER52> People carry their luggage because they know it will take years before they get reimbursed, and often they remain stranded in the foreign city with no passport. You need to ensure there is no incentive to keep your luggage, otherwise people will do it no matter the fine.

<comment><USER51> So jail time then. People can learn to keep their passports on their persons to avoid jail time for putting it in the carry-on and taking the carry-on.

<comment><USER52> Sounds fair to me. Save time by carrying your luggage at risk of others, spend it in jail, for risking/causing the death of others.

<comment><USER38> A passport in your pocket is not "carrying your luggage".

The comment even says to not put the passport in the carry-on.

There is no need to be disengenious.

</comment></comment></comment></comment></comment><comment><USER53> It might help if the pilots could lock and unlock the luggage stores. This would prevent anybody to get at them in emergency evacuation situation.

</comment><comment><USER33> I know not to, and yet, knowing that, I probably would anyway. Sigh.

Mostly because I don't feel like it would slow me down. Even though I know intellectually it would.

\</comment><comment>-

Airplanes need wider aisles. That's all. It's as simple as that. The ones they have now are just too narrow.

Does it really cost that much to increase space? Isn't the main operating cost of a plane weight, not volume?

<comment><USER54> The surface area increases with the square of linear dimensions. So increasing aisle space meaningfully would make planes significantly heavier—unless you're suggesting making seats narrower to compensate.

<comment><USER33> > The surface area increases with the square of linear dimensions

That's for a ball. A cylinder does not increase that way.

Plus you only need to increase the width, not the height. So the surface areas goes up as twice the linear dimension, which I don't think would be significantly heavier, just a bit incrementally heavier.

<comment><USER54> Fair enough. I would say another likely issue is that of the highway problem: you make wider aisles—and now people think they can _definitely_ take their stuff.

</comment></comment></comment></comment><comment><USER55> Solution: during the safety briefing, there should be a statement about bringing bags during an evacuation, and they should mention a fine on the order of tens of thousands of dollars for not complying.

</comment><comment><USER13> Simple solution, digital locks that are able to be activated either by the cabin crew manually, or by the pilot automatically as a result of some controls that indicate there is a problem.

<comment><USER37> Anytime a programmer sees a non-technological issue, they think "I know, I'll use computers!" Now they have two problems. (With apologies to JZ et al.)

</comment></comment><comment><USER56> I was watching the evacuation video and as soon as I saw an idiot going down the slides with 3 bags I realised the death toll would be unnecessarily high. It's safe to say those 3 bags cost 3 lives or more. What utter selfishness and stupidity.

<comment><USER57> Don't be so quick to judge and call them idiots. In a panic situation you can act irrationaly.

<comment><USER58> People who go into some kind of dumbshit mode where they violate a rather basic social contract, by clearly indicating higher value for their crap than human lives? Yes, I'm getting a sense of acting irrationally right now: how about assaulting and trampling them? Hmm, small problem, while they deserve that and I think it would be completely ethical, their body will be yet another obstruction that will potentially cost others their lives.

<comment> crooked-v You seem to be under the assumption that people in a true emergency situation have the mental coherency to even actively consider their own safety. The reason airline safety rules are so often repeated is that it gets people acting on 'automatic' without thinking about it, and even then there are various documented cases where airplane emergency survivors just sat in their seats without doing anything until someone told them to get up and off the plane.

</comment></comment></comment></comment><comment><USER57> Was the pilot also deadly stupid by trying to land the plane without releasing the fuel first? As I understand very few pilots have the experience to do that.

<comment><USER59> Not all airplanes can dump their fuel. Only the bigger ones can. I once had to fly circles around an airport for 5 hours to burn up the fuel, because the airplane couldn't dump it.

<comment><USER34> They generally only dump fuel over the ocean. Not great from an environmental perspective, but at least it isn't landing on people's houses or farm land.

<comment><USER38> They generally dump over the ocean because there is less air traffic there, nothing to do with the fuel itself.

Jet fuel disapates in a few thousand feet. You won't notice it if a jet dumps fuel over you.

</comment></comment></comment></comment><comment><USER60> Since training and education does not have any effect, isn't it time to make it a criminal offense to take your belongings when you are evacuated in an emergency situation?

<comment><USER46> If the plane was on fire, filled with smoke, I don't think the risk of "criminal offense" is going to change anyone's behavior.

It's a run for your life at that point.

</comment></comment><comment><USER61> Simple rule, in case of evacuation all luggage carried by evacuated people will be confiscated and destroyed (or returned after paying 5 years average salary to leave a loophole for rare cases of really valuable luggage).

All luggage recovered from the plane after evacuation will be given back to owners.

<comment><USER15> Better solution: After the evacuation, make them put the luggage back into the overhead bins.</comment></comment>


Ask HN: Ethics and the "hacking system" Q from YC application - <AUTHOR>

Hey guys, had a general question for you. For those who have applied or seen YC's app, theres a question that asks: Please tell us about the time you most successfully hacked some (non-computer) system to your advantage.
PG writes: If this wasn't already clear, we're not looking for the sort of obedient, middle-of-the-road people that big companies tend to hire. We're looking for people who like to beat the system.
Naturally, beating the system requires some form of deception (some degrees of lieing, cheating, dishonesty). The "system" was setup in a way to obviously prevent that, which is why it exists in the first place. I know it doesn't necessarily make you an unethical or a bad person if you beat a system. But someone reviewing my previous application made a good point that PG puts a lot of value in the "Don't be evil" mantra, and said that our hack the system examples were shady. So I thought about trying to balance the amount of shadiness with the amount of beating the system-ness. (To be clear, one answer was getting around a library system to fake returning a lost library book in the 6th grade. Another was bait and switch trade technique to get items in Diablo 2. Not super evil stuff, we were kids and had to be creative.)
Now I don't want this to be a discussion about what I wrote, I just wanted to provide context for my question. On one hand, PG wants people who beat the system. On the other hand, someone told me PG is high on ethics. These seem to contradict one another. Which side is more powerful and more important in making an impression? Thanks <comment><USER2> Beating the system doesn't require dishonesty -- it just requires approaching the problem in a way the system did not anticipate.

For example, we all know what "the system" looks like for getting hired, right? Send in your resume, which looks like every other resume. We'll have an HR drone read it. You may be called back for an interview. Don't call us, we'll call you.

One way to hack this system is to create a website designed to interact with, specifically, the decisionmaker in charge of hiring you. Maybe you pull in Google Analytics, an A/B test, sixteen different web services/Twitter integrations/whatever, and then after a few minutes hit him with a AJAX popup asking for what time is best for you to call him about hiring you. On the call, you demonstrate uncanny attention to what he needs by the simple expedient of talking about the topics he evidenced the most interest in by interacting with on your resume. (He read seven blog posts and didn't touch your educational achievements once? That tells you something.)

That isn't dishonest in the slightest: you're using your professional skills to effectively demonstrate that you and the company would be a mutually beneficial pairing. You're just presenting yourself in a more engaging, effective, forceful way than the overdone resume format would present you in.

<comment><AUTHOR> I gotcha, good example. Did you try this at some point, or did you make it up?

<comment><USER2> The last time I was applying for a job I had insufficient web development skills to pull this off and I rather doubt I will ever have need to apply for a job again, so no, I have never actually delivered a resume in this format. (Though if I were hypothetically doing an application to YC or otherwise trying to influence a decisionmaker to give me money, I'd have a website purpose-built for it.)

Let's see, previous job application hacks I have actually done: when I was 16 I applied for a summer job at a large American company which sells office supplies, as a seasonal order entry operator. They sort of value obsessive- compulsive attention to detail in that position (difference between 10 reams of paper and 10 cartons of paper: rather substantial!). I am not normally a very detail-oriented person but I have a fairly decent memory, so I called them up, asked them to mail me a catalog, and then memorized a few bits of trivia about prominent product lines and all their policies about shipping.

During the interview, the person speaking to me mentioned "drop shipment", and then proceeded to explain what drop shipment actually is. I cut her off and said that "Drop shipment is when you order from $COMPANY but the order actually ships directly from the vendor." She asked if I had previous experience in the industry. I said "No, but it is written in your catalog. You see, customers should know whether they are ordering drop shipped products or not, because while drop shipped products are covered by the same 'free shipping for orders above $THRESHHOLD' policy as products shipping from the warehouse, they are not actually carried by the same shipping lines, and appropriately the customer needs to make arrangements to move the item from the door. However, for an extra charge of $35, the truck driver will take it to anywhere accessible via an elevator."

She looked at me dumbfounded for a moment.

"I made it my business to know your business."

That line was pure luck, incidentally -- I had to come up with it on the spot because I did not have a half-dozen prepared, tested, memorable quotes ready to slot in at any opportune time in the interview. I have learned the value of those in the last decade, though.

<comment><AUTHOR> Great story, one thing though. You were impressive in your interview/performance, but I'm kind of failing to see how you "hacked" the system.

You were smart by being prepared and researched the company's product offering. This is kind of standard practice, to know what the company you're applying to sells/builds. So in this particular example, can you show you hacked the system? Is being more prepared than the average applicant good enough to show this?

</comment></comment></comment></comment><comment><USER3> _On one hand, PG wants people who beat the system. On the other hand, someone told me PG is high on ethics. These seem to contradict one another._

They don't when the system is evil.

<comment><USER4> One of my examples: I was working on a political campaign for federal office. The party had promised our candidate significant financial backing, it didn't come through they just wanted a candidate in the race. We realized that we were never going to be able to compete financially against an incumbent candidate with a war chest of special interest money.

The hack I came up with was that we would announce that we weren't going to accept and money from lobbyists, PACs, or anyone outside the state. Not that we were going to get much anyways ;)

We still got stomped. But it was great ammunition in our message toolbox and we used it all of the time.

Thats what I call message hacking.

</comment></comment><comment><USER5> One way to "hack the system" is to do what you said - employ some type of deception or misdirection in order to gain something you shouldn't.

Another way is to re-purpose something to do what it wasn't designed to do. For example, any contraption that would be called a "Rube Goldberg Machine" would qualify as (non-computer) hacking. MAKE Magazine is full of hacks of this nature as well. The Burning Man Festival is a great place to see things hacked together.

Another way might be to fix a perceived flaw through unorthodox means. For example, I put new pickups in my guitar, and they were too hot (too loud, bad distortion). Instead of replacing them (they sounded awesome at lower volumes), I routed the pickup holes to be slightly deeper, then wired in a bypass switch, letting me choose to have a normal tone or naturally overdriven (good distortion) tone. Drummers who put tape over part of a drum skin are hacking their system. Guitarists with old Stratocasters often file their nuts and lower the bridge for better tone.

So I respectfully disagree - one can definitely be a (non-computer) hacker and be ethical at the same time.

<comment><AUTHOR> Great points, I understand your idea about hacking a system.

But PG alludes to "obedience" in his comment and "middle of the road" people, leading me to believe he wants to see some sort of gain over the system. A rube goldberg machine doesn't really fit that profile. Fixing your guitar up doesn't really beat the system. Sure you hacked it up and saved money, but did it really show how clever you are? (Not that I'm saying you aren't)

<comment><USER5> I consider what I did to my guitar beating the system ;) But then, I'm a guitarist so that's in my domain. It would have been cheaper to just get middle-of-the-road pickups instead - less money, less gain (in a signal- strength sense).

Having said that, I understand your point. My examples were not necessarily about beating a system, but changing how that system relates to myself (or whomever). And I did get to type the phrase "file their nuts" with a straight face.

Inconveniently, I am having trouble coming up with relevant examples of ethical, non-computer hacking resulting in some sort of net gain unrelated to a select niche of people (like guitarists). I'll have to get back to you on that one...

</comment></comment></comment><comment><USER6> _On one hand, PG wants people who beat the system. On the other hand, someone told me PG is high on ethics._

I think this question serves two purposes: First, to see how creative people have been in hacking systems; and second, to see how people interpret the question.

</comment><comment><USER7> _"Naturally, beating the system requires some form of deception (some degrees of lieing, cheating, dishonesty)"_

I think that's a flawed premise. Remove the assumption (as others have done) that "beating the system" means any of those things, and the argument fails.

</comment><comment><USER8> I think your examples are pretty 'light', and not in any way detrimental, but I could be wrong.

To me it is as simple as 'whitehat/blackhat' hacking.

And what you did when you were a kid should be taken with a grain of salt, there is a reason we keep childrens criminal records sealed.</comment>


Doccano: Open-source text annotation tool for machine learning - <AUTHOR> https://github.com/doccano/doccano <comment><USER2> One of the most important and underserved aspects of actually doing machine learning is data collection and error analysis (and in software they are essentially the same thing).

Prodigy by Explosion AI (creators of spacy) is very good, great UX focused on making you extremely efficient. It's a paid product but I'm happy to help fund such a talented and impactful team.

That said we don't use any tool out there nearly as much as we could. One fundamental reason is that they don't cover all of our use cases. My team works with legal contracts, and oftentimes the flow has to be: scan through the entire document to find the region you're looking for and drag your cursor over it to highlight. I haven't seen any annotation tool that works for that, so we built our own.

In a similar vein, doing error analysis for those predicted highlights on large documents is also painful. Scrolling here is a chore. If anyone has seen LiquidText in action then you know the solution here.

There's so much left to do in this world. The exciting part is that the better the models start to work, the more interesting UX challenges you have to push efficiency even further. All ML projects largely have to look at the costs of building and analyzing their datasets, and making that cheaper with models in the loop and exceptional UX is super critical and super fun to think about.</comment>


Haskell for Web Developers - <AUTHOR> http://www.stephendiehl.com/posts/haskell_web.html <comment><USER3> You might not need a deep understanding of category theory to write useful programs in Haskell, but the downsides of relying on those explicit monads to control state and interactions still show through in practical code.

Here's an early example from the article:

        import Control.Monad.State

        type Interact a = StateT Int IO a

        repl :: Interact ()
        repl = forever $ do
          val   <- liftIO readLn
          state <- get
          liftIO $ putStr "Total: "
          liftIO $ print (val + state)
          put val

        main = runStateT repl 0

Here's something with similar behaviour written in Python, an imperative language with a reputation for being easy to read:

        total = 0
        while True:
            total += input()
            print "Total:", total

The difference is striking. The latter is obviously much more concise. Ironically, it also seems clearer about how the state is used, having the initialization, reading and writing of that state all kept together. It's worth considering that the stateful logic is relatively kind here, too, because there's only a single value that needs to be maintained via StateT in the Haskell version.

The Python code has the added advantage of actually being correct, assuming that the intended behaviour really is to add up the total of all entered numbers over time as the output suggests.

I think this example is instructive in terms of advancing industrial practice rather than the theoretical state of the art. Haskell demonstrates a lot of nice features that mainstream industrial languages lack today, but as soon as any sort of state or effects enter the picture, it becomes absurdly complicated to describe even simple systems. I would love to have future languages incorporate some of the safety that Haskell offers, but I think to catch on with working programmers they will have to hide away a lot of the state/effect details where they aren't needed, just as tools like type inference have hidden away their own form of boilerplate. It's not just about not needing to be an expert on category theory, it's about not having to be aware of it at all.

<comment><USER4> >The Python code has the added advantage of actually being correct, assuming that the intended behaviour really is to add up the total of all entered numbers over time as the output suggests.

Only in a single threaded environment. However, concurrently, the Haskell code _stays_ correct in a concurrent environment while your python code has bugs.

Extrapolate a bit, and think about how many python functions may be slightly less trivial than yours and yet still have the same concurrency issues...

<comment><USER3> Contrary to the hype, I think plenty of useful code _does_ still run in a single-threaded environment, so I find your argument unconvincing.

That said, even in an environment with concurrency, I'm not advocating uncontrolled state changes as typified by current imperative programming languages. I'm arguing that we could benefit from the robust theory underlying languages like Haskell, but used more transparently so the developer only has to worry about it when it matters.

For example, you could be running a second thread in parallel with the one we're looking at here, but if its effects are constrained to replying to a network-supplied request for the current time and reading the system's clock, it doesn't matter at all that our interactive adder is running at the same time. These effects affect different, independent resources and will never interact, so there is no benefit to cluttering either code path with extra details.

What I'd really like to see is a language that could understand those resources and how they are affected by each thread in terms of reads and updates. I want it to stop me from modifying the code later so that it accidentally becomes vulnerable to interactions that I'm not fully controlling. I want it to provide me with tools to specify how potential interactions should be handled, in a way that is systematic and robust but otherwise as simple as possible, and that can be applied at whatever level of my design makes the most sense.

Research into type and effect systems is addressing challenges like these, but I'm hoping that when the dust settles, the final version will look a lot more like Python with a few strategically placed annotations than Haskell where these implementation details are in your face all the time (even if most of the time you don't actually need to worry about them).

<comment><USER4> >I want it to stop me from modifying the code later so that it accidentally becomes vulnerable to interactions that I'm not fully controlling. I want it to provide me with tools to specify how potential interactions should be handled, in a way that is systematic and robust but otherwise as simple as possible, and that can be applied at whatever level of my design makes the most sense.

That's...the state monad. The compiler tells you when you try to access it in a way that is not allowed.

You have to be explicit with sharing.

<comment><USER3> _That 's...the state monad. The compiler tells you when you try to access it in a way that is not allowed._

But the price for that is that I _always_ have to access it in a cumbersome way, even when being so explicit makes no useful difference to the correctness of my code.

 _You have to be explicit with sharing._

I don't _want_ to be explicit with sharing.

I want to be explicit with sharing _when it matters_ , and otherwise not to worry about it, safe in the knowledge that the language will warn me if I try to do something later that invalidates any assumptions I'm making now.

</comment></comment></comment></comment></comment><comment><USER5> I don't think you're going to convince existing web developers to adopt Haskell.

The second example from the article uses 8-lines of Haskell, a hand-waving explanation of a state transformer monad, composition, and a state transition diagram to demonstrate how easy it is to write trivial Haskell programs. The program in question takes a number from stdin, adds it to a counter, and prints the result.

"Web developers," being those who have experience building applications using web-based technologies, have a plethora of tools and languages at their disposal that don't require the up-front investment of learning Haskell.

Haskell has a lot to offer but I suspect the only people interested in using Haskell in their web application projects are Haskell developers or people who've been convinced that they will be smarter if they learn Haskell.

<comment><USER6> I've had the opposite experience. Everyone I know who does web development is frustrated by the poor quality of work they produce, and how hard it is to maintain the projects they've done. Re-writing a project from scratch every ~5 years is essentially normal development practice. I learned haskell just for web development. I am not smarter as a result, I just have a better tool now that helps me produce better results. My wife then decided to learn haskell for web development too. Neither of us have a background in computer science, or even a degree at all. We learned haskell for purely practical reasons, and we keep using it for those purely practical reasons.

<comment><USER5> ymmv; I hate web development but maintainability is the least of my concerns. I have frameworks for that.

<comment><USER6> What framework, and what is it doing to help with maintenance? My experience has been that typical RoRish frameworks are so heavily concerned with trying to make the initial writing of the app easier that they actually hinder long term maintenance.

<comment><USER5> Pick a framework, I've probably worked on an application that used it.

 _what is it doing to help with maintenance?_

What frameworks do: impose structure and convention on the design of programs.

In the case of web frameworks you provide some data, map URLs to functions, and hook into some helpers for managing sessions, caching, and the like.

Haskell has them too.

 _...they actually hinder long term maintenance._

I've found the opposite to be true in the general case.

Disqus is probably the largest Django application out there that I know of (and note I have never worked there). From their technical talks and contributions to Django over the years it seems to me that Django has been a net-win for them, maintenance wise, over the years. I can't say what it's like maintaining a Django application like Disqus but it doesn't sound to me from what I know that Django is any hindrance to them.

<comment><USER6> >What frameworks do: impose structure and convention on the design of programs.

So, nothing? Convention doesn't prevent things from breaking when you make changes.

>Haskell has them too

I know, I use two of them. And I haven't found any benefits to maintenance from them. I've found huge benefits to maintenance from haskell though.

>it seems to me that Django has been a net-win for them

Compared to what though? I didn't say frameworks are useless, I said they don't appear to do anything to aid in maintenance.

<comment><USER5> _So, nothing? Convention doesn 't prevent things from breaking when you make changes._

No, not nothing. Exactly what it says on the tin.

Without a web framework what do you get? A few buffers to read/write some bytes to. Have fun writing your parsers, dispatchers, database connection pool handling, object relational mapper, etc, etc, etc... and especially have fun _maintaining_ all of that.

If you used a framework though, _you wouldn 't have to_. It's already there and there's a community of people who work on that stuff for you. Awesome.

First rule of maintenance: _the code you don 't write is the code you don't have to maintain_.

I don't see what Haskell is winning here in terms of maintenance. Without Yesod or any other framework you're in the same boat as someone starting with plain Java or Tcl or something.

Unless of course you're referring to its masochistic type system that magically protects you from ever writing a bug ever. _Good luck with that_.

My point was, originally, that a web developer that doesn't already know Haskell and hasn't convinced themselves to learn Haskell isn't going to look at some Haskell code and be converted. They're going to see StateT and monad combinators and the awful pain of IO in Haskell and go write their app in X.

<comment><USER6> >Without a web framework what do you get? A few buffers to read/write some bytes to. Have fun writing your parsers, dispatchers, database connection pool handling, object relational mapper, etc, etc, etc... and especially have fun maintaining all of that.

Why would I write all of that myself rather than use libraries? You do realize that writing an application is not a binary choice between "use framework" and "write everything from scratch" right?

>If you used a framework though, you wouldn't have to

I don't have to anyways, a framework has nothing to do with it.

>I don't see what Haskell is winning here in terms of maintenance

Type safety. I can change my code, and every single thing I just broke is now specified for me, file and line, by the compiler. This is an absolutely massive difference compared to trying to rely exclusively on unit tests. You should really try it sometime.

>Unless of course you're referring to its masochistic type system that magically protects you from ever writing a bug ever.

Really, you should try it sometime. Or at least take the ignorant nonsense to reddit where it belongs.

>My point was, originally, that a web developer that doesn't already know Haskell and hasn't convinced themselves to learn Haskell isn't going to look at some Haskell code and be converted

And my point was that is exactly what happened with both me and my wife.

<comment><USER5> _Really, you should try it sometime. Or at least take the ignorant nonsense to reddit where it belongs._

I've read the papers and I've tried a bit of Haskell. I write lots of C++ too. I've tried different flavours of typing. I still prefer dynamic, strong-typing any day. Common Lisp or Python generally do the trick.

And I've been programming for > 10 years. I'd appreciate it if you wouldn't assume I'm an ignorant dumbass because I don't agree with you.

 _And my point was that is exactly what happened with both me and my wife._

Does not imply it's true for everyone. Maybe I should quantify that my original point with _most_ web developers using existing technologies aren't going to hop over to Haskell because of state transformation and combinator monads and strong typing.

<comment><USER6> >I write lots of C++ too

I know, that's why you say completely backwards things like "masochistic type system". You are ignorant of haskell, and instead apply your experience with statically typed languages with inexpressive and awkward type systems to haskell.

>And I've been programming for > 10 years. I'd appreciate it if you wouldn't assume I'm an ignorant dumbass because I don't agree with you.

Ignorance has nothing to do with being a dumbass. You are ignorant. So am I. So is everyone else. The fact that modern type systems is one of the areas where you are ignorant does not make you stupid or a bad person. My suggestion that gaining knowledge and experience in that area could be beneficial to you is not an attack, it is a genuine suggestion. I used to be a programmer with 10 years experience who thought static typing was bad too.

>Does not imply it's true for everyone

I didn't claim it was. I pointed out that your broad claim is unsupported by evidence, and that my personal experience was directly contradictory.

<comment><USER5> _I know, that 's why you say completely backwards things like "masochistic type system"._

I don't think disagreeing with you makes me ignorant or gives you any special insight into my knowledge of type systems.

And my statement is only backwards from the perspective of developers who find pleasure in working with such a compiler.

If you want to know the extent of my ignorance I've only used Haskell in so far as to complete various programming exercises and inspecting the source code to xMonad. I was interested enough at one point to find out what all the hype was about. I've watched most of the seminal talks from Peyton-Jones and I've read numerous papers on Hindley-Milner type inference, category theory, monads... and perhaps countless more articles than I care to remember that extoll the virtues of the pain of getting your types right (in fact I think I've read it from numerous sources describing the experience as "pain," but that, "it's worth it").

Weird.

In the end my conclusion, different and ignorant though it is, is that purity is over-rated and not worth the trade-offs. I prefer languages that let me be the judge of what is useful and avoid languages that make broad generalizations about purity, mutability, and types.

 _I pointed out that your broad claim is unsupported by evidence, and that my personal experience was directly contradictory._

And my experience is directly contradictory to yours. So what?

If we needed hard numbers to settle this I think we will find that the majority of web applications in existence are not written in Haskell. And if we take a survey of developers who build and maintain web applications about whether they would consider switching to Haskell I imagine very few would answer, "Yes." I think they will continue to maintain and develop new features and applications without Haskell and the world will continue to turn.

Yes, as you've pointed out, there are other people out there like you. Sorry, you're in the minority. The vast, vast minority.

There are a plethora of considerations to make when writing web application software. I don't think I've ever stopped and said, "You know, I should wrap all of this in a state transformation monad and combine it the an IO monad and ensure that my entire program passes through my compiler's type-checker." And I write large, eventually consistent data-stores without type checking... and most of the time they work!

I just don't see why type checking up-front is such a huge deal. And believe me or not, I've tried to convince myself.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> One thing I haven't seen mentioned here is that web development is often not a one-man endeavor. At its most basic, you commonly have separation between front- and back-end. So unless you plan on doing it all yourself, you will need to find a front-end developer who is either familiar with Clay, JMacro and Fay; or who is willing to learn; and frankly, I don't think that's a very likely scenario, given the scant usage of Haskell as a web development language.

Also, the example of the compiled JavaScript from Fay is horribly obfuscated:

      return Fay$$_(Fay$$_(
                Fay$$cons)(i))(Fay$$_(
                Prelude$enumFrom)(
                Fay$$_(Fay$$_(
                    Fay$$add)(i))(1)
            ));

Oh, God, my eyes. Any idea at all what that does? I can tell you one thing: I would not want to debug that on a Friday night. Or a Tuesday afternoon. Or ever, really.

Kind of have to agree with a few of the other commenters here who are saying things along the lines of "You can do anything with a hammer, if a hammer is what you have."

Also: this reminds me of a "LISP for Web Development" talk I went to a few years ago. The speaker was talking to a bunch of web devs about how LISP has an undeserved reputation for being domain specific (academia, astronomy, whatever). He then went on to explain how you could use it for calculating the results of some kind of physics experiment and output it as an HTML table. Uh- huh. My buddy and I walked out after about 25 minutes.

Am I being unfair?

>> As an example of we'll use JMacro to implement a simple translator for the untyped typed lambda calculus.

Nope.

<comment><USER8> > Oh, God, my eyes. Any idea at all what that does? I can tell you one thing: > I would not want to debug that on a Friday night. Or a Tuesday afternoon. Or > ever, really.

Do you often debug the assembler output of your compiler? Same thing; fix the Fay code, not the Javascript that the compiler generates.

<comment><USER9> I have source-level debuggers in other languages.

I'm not sure Fay now generates sourcemaps, and either way not all browsers support them.

So it's pretty much guaranteed you'll have to debug generated javascript at some point.

</comment></comment></comment><comment><USER10> I'm just getting started with Haskell and there will soon come a time where I need to jump in the deep end. When I'm ready to learn Category theory, what background will I need? Is elementary calculus and a little linear algebra enough? Or am I going to need some more advanced math concepts? Once I've got the right background, where should I go to learn Category theory?

<comment><USER11> We had a discussion on this when Stephen's last post showed up here: [https://news.ycombinator.com/item?id=6041726](https://news.ycombinator.com/item?id=6041726)

I've been looking into this myself and I have a similar background as you (elementary calculus and linear algebra; I also took number theory as part of a math minor). So far it looks like I should pick up a bit of abstract algebra/topology (rings, fields, groups, etc) then I should be able to start off on the shallow end of category theory and work from there. At the same time I need to improve my understanding of how monads, monad transformers, monoids, functors, etc work in Haskell from an operational standpoint; I have a basic understanding now but I'd like to dig deeper.

The thread I linked above has a lot of links to books and stuff like Reddit's r/haskell and other places, that you can sort through to see what works for you. I have yet to make that determination for myself, but there's plenty to choose from. I actually picked up a copy of Benjamin Pierce's "Basic Category Theory for Computer Scientists" a few years ago based on someone's recommendation, way before I got into Haskell, and didn't make the connection until I picked up his book on type theory recently (while researching a paper on FP) and thought his name looked familiar.

Ultimately I'm hoping to be able to get deep into type theory and go through that Homotopy Type Theory book that came out recently.

<comment><USER12> Thanks for the response. I was interested in the answer to this question as well. I read through the thread [1] that you linked to, and seems like the consensus is the same thing you said: it's best to learn abstract algebra and topology first. Does anyone know of some good sources for those topics? The other threads are understandably focused on category theory.

As for category theory, after reading through that thread [1] and the Reddit thread [2] that it links to, I think _Conceptual Mathematics: A First Introduction to Categories_ [3] will be my first read on category theory (but probably followed by the Rosetta Stone paper). That book receives some strong recommendations as a first book in the Reddit thread [2].

[1] [https://news.ycombinator.com/item?id=6041726](https://news.ycombinator.com/item?id=6041726)

[2] [http://www.reddit.com/r/haskell/comments/1ht4mf/books_on_cat...](http://www.reddit.com/r/haskell/comments/1ht4mf/books_on_category_theory_for_beginners/)

[3] [http://www.amazon.com/Conceptual-Mathematics-First- Introduct...](http://www.amazon.com/Conceptual-Mathematics-First-Introduction- Categories/dp/052171916X)

<comment><USER11> Not a problem. I'm interested in the abstract algebra question too, as I haven't actually done any research yet. Perhaps someone should start an r/categorytheory. :)

<comment><USER12> Digging deeper into the HN thread that you linked to, I came across this discussion [1] on Reddit which is focused more on the abstract algebra question. They recommend _Algebra: Chapter 0_ by Aluffi (Amazon [2] or PDF [3]).

[1] [http://www.reddit.com/r/math/comments/1eiyid/category_theory...](http://www.reddit.com/r/math/comments/1eiyid/category_theory_prereqs_does_alg_geometry_come/)

[2] [http://www.amazon.com/Algebra-Chapter-Graduate-Studies- Mathe...](http://www.amazon.com/Algebra-Chapter-Graduate-Studies- Mathematics/dp/0821847813?tag=duckduckgo-d-20)

[3] [http://www.mimuw.edu.pl/~jarekw/pdf/Algebra0TextboookAluffi....](http://www.mimuw.edu.pl/~jarekw/pdf/Algebra0TextboookAluffi.pdf)

<comment><USER10> Thanks for the Algebra Chapter 0 link! I think that's my next math book :)

</comment></comment></comment></comment></comment></comment><comment><USER13> My long term bet is Haskell, but boy do the examples look ugly. And most of Haskell really is ugly. My mind just can't get around type names like "M a p f b c => (a -> p) -> b -> c -> a" just yet. I know it's not hard to understand, but it is hard to parse and build up context.

Looking forward to having 5+ years of experience in this brilliant language.

<comment><USER14> Why do you think a language that "really is ugly" and " is hard to parse" _must_ be a "brilliant language"? Maybe the emperor has no clothes? Maybe Haskell is just what you see: suitable for academic discourse, unusable for real-wold programming.

<comment><USER15> Presumably he thinks that it is brilliant for reasons he already knows, probably involving the type system, but also observes that it is aesthetically ugly and difficult to read.

<comment><USER16> Aesthetics are purely subjective and rather useless. Hell even our own opinion of them can change drastically over time. The other reasons are what matter. I initially found Haskell quite ugly. But now that I understand the semantics behind it the syntax is quite beautiful in my eyes.

</comment></comment></comment></comment><comment><USER17> I really like Stephen's writing style: no frills, concise, but he still spends time explaining the hard things. Plus he usually writes about things I don't understand so I come away having learned something.

</comment><comment><USER18> In this blog post about how easy and non-academic Haskell is I'm going to implement the lambda calculus as an example

</comment><comment><USER19> One of the most challenging things about Haskell tutorials is the difficulty in determining the etymology of very terse function names.

For example, what does the M in _forM__ stand for? Monad? Something else? What about _liftM_? Why is it called lifting? Is the M here the same as the M in _forM__?

These are just a few examples from this tutorial, but I find that this is pretty much common everywhere in the Haskell world, making it hard to parse semantic meaning from function names if you aren't already immersed in the language and community and well versed in the lingo.

One of the best things I've learned to break out of this is to search for JavaScript implementations of many Haskell concepts when such a concept is doable in JavaScript. It usually leads me to enough understanding of what some function is trying to accomplish to proceed with whatever Haskell tutorial I happen to be reading.

<comment><USER20> The positive news is that while it might take a while to learn the conventions, usually the conventions are enforced all around. In your case, the conventions are documented in the docs for Control.Monad, the library those functions are from:

The functions in this library use the following naming conventions:

> A postfix 'M' always stands for a function in the Kleisli category: The > monad type constructor m is added to function results (modulo currying) and > nowhere else. So, for example,

       filter  ::              (a ->   Bool) -> [a] ->   [a]
       filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a]

> A postfix '_' changes the result type from (m a) to (m ()). Thus, for > example:

        sequence  :: Monad m => [m a] -> m [a]
        sequence_ :: Monad m => [m a] -> m ()

> A prefix 'm' generalizes an existing function to a monadic form. Thus, for > example:

        sum  :: Num a       => [a]   -> a
        msum :: MonadPlus m => [m a] -> m a

[http://www.haskell.org/ghc/docs/latest/html/libraries/base/C...](http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control- Monad.html)

Personally, the things that I found hard were idioms (like learning that $ is just avoiding parenthesis, "go" is for loops, etc) and how theres a lot of libraries that make the code shorter at the expense of forcing you to be aware of them (for example, applicatives <$> <*> look alien until you learn what they are and monad transformers add a lot of "magic" to the code as well as force you to use annoying lifts all over the place)

</comment></comment><comment><USER21> these "how to read _" posts are helpful mini- style guide/naming convention roadmaps

[http://blog.ezyang.com/2011/11/how-to-read- haskell/](http://blog.ezyang.com/2011/11/how-to-read-haskell/)

[http://www.haskell.org/haskellwiki/How_to_read_Haskell#What_...](http://www.haskell.org/haskellwiki/How_to_read_Haskell#What_does_this_function_do.3F)

</comment><comment><USER22> If you like hammers you can make them do anything. Or is the analogy nails? I forget.

The real question is why use Haskell instead of something else that most people generally consider targeted at the web?

<comment><USER23> > The real question is why use Haskell instead of something else that most > people generally consider targeted at the web?

An equally "real" question is why people think "the web" is special in such a way that it requires a different programming language for back-end applications than other server applications use.

<comment><USER24> I would say that the difference is that the Web is almost entirely about I/O, which Haskell treats as an unfortunate aspect of programming that is to be made as unpleasant as possible so it will be avoided except where unavoidable.

There are many programs that run on servers, grinding away on deep questions for extended periods with no more than the bare minimum of communication with the rest of the universe---maybe just a terse "42" at the end of a long run.

But the Web is about talking to users thousands of times per second, sending it all in a hurricane of streams to a database, fetching data for each of them from various databases, streaming it out to a third-party credit card processor, sending the results back to the users....

Haskell's ideal of minimal I/O isolated in a ghetto so the "real" work of the program can remain unpolluted doesn't seem an ideal match for the case where the real work is almost entirely about routing I/O streams.

<comment><USER23> > I would say that the difference is that the Web is almost entirely about I/O

That's true in the trivial sense, in the same way that "the desktop" is about i/o, or "the command line" is, in that all of those specify an i/o channel.

But web apps or services aren't all about i/o any more than any other applications/services, they just differ in that the main user-facing i/o channel is HTTP.

> Haskell's ideal of minimal I/O isolated in a ghetto so the "real" work of > the program can remain unpolluted doesn't seem an ideal match for the case > where the real work is almost entirely about routing I/O streams.

Monads aren't ghettos isolated from the real work of the program. Monads are tools for _doing_ the real work of the program -- whether its i/o, or dealing with mutable state in a transactional, concurrency-safe manner, or, well, lots of other things.

<comment><USER6> >That's true in the trivial sense

I think it is true in the actual real world practical sense too. Consider how many web applications are just plumbing between a database and a browser. 95% of my app is in a MonadIO.

</comment></comment></comment></comment></comment><comment><USER25> >Do I still need a graduate degree in category theory to write to a file?

No.

> Will I need a graduate degree in category theory to parse the next paragraph > in this article?

Oh. Um wait, define web developer for me again?

</comment><comment><USER8> In the second example, shouldn't it be `mapM_` instead of `forM_` with this ordering of the arguments?

</comment><comment><USER26> I've been meaning to ask this for a while now: what's the appeal of Haskell? It doesn't come off as a pleasure to program in. Could someone who knows the language share their thoughts?

<comment><USER17> I _love_ programming in Haskell! Seriously, the reason it's on HN so much is that Haskellers love the language. Here are some reasons:

* Types, types, types. You're probably sick of hearing about Haskell's type system, but it's amazing. Gives you almost all the flexibility of a language like Ruby, PLUS you can encode a lot of your assumptions in types...so if there's a bug you'll catch it at compile time. I like how I can just write a LOT of Haskell code without testing it, and then just compile my project and find all the issues I need to fix. It makes prototyping really easy and fast.

* Awesome abstractions. Functors, monads, first class functions: you know how java is verbose and you end up writing the same boilerplate over and over? Haskell is the opposite.

* Awesome syntax. I really love Haskell's syntax: super clean, and you can modify it however you like. I like writing very readable code (you read code way more often than you write it) and Haskell lets me write very readable code.

* Neat libraries! All that stuff other languages are trying to work around? Like concurrency, or sandboxing? Part of the standard library already. I had written this post a while back ([http://adit.io/posts/2012-03-10-building_a_concurrent_web_sc...](http://adit.io/posts/2012-03-10-building_a_concurrent_web_scraper_with_haskell.html)) that shows exactly how easy it is.

Seriously, if you're curious about languages at all, give Haskell a try.

<comment><USER27> I think something that's hard to appreciate before you learn Haskell is that while a lot of the abstractions used in the language are more complex and abstract than you're used to using, it's because the language/types/compiler help to lift an enormous mental burden you usually carry while reasoning about code in most languages.

Purity is great not because you make fewer errors but because when writing pure code you can focus on what needs to happen instead of worrying about state/effects/control flow. While having to sprinkle `liftIO`s around your imperative code sounds dreadful, it's quickly appreciated as a statically checked marker for "code that you need to think harder about".

So what you end up with is a fantastic playground to use mental tools unavailable in other languages due to the complexity overhead. You also have a suite of abstractions that "almost never break" due to their invariants being encoded into the type system and thus checked every single time you reload the file.

People often compare this effect to having a large suite of automatically generated test specs run on every compile. It's like that, yeah, but humans can write tests this bulletproof and no suite runs this quickly.

I get jitters writing Ruby sometimes now because I know I'm fallible and I have to store so much more in my mind in order to reason about it.

<comment><USER17> Agreed. Ruby used to be my go-to scripting language but I've switched over to Haskell because it's much easier to reason about.

<comment><USER19> Can you give examples of the scripting tasks you've used Haskell for? Are they on your github?

<comment><USER17> All sorts of command line utilities. For example, here's a timer:

[https://gist.github.com/egonSchiele/6005209](https://gist.github.com/egonSchiele/6005209)

Here's a script that emails me when someone follows/unfollows me on Github:

[https://gist.github.com/egonSchiele/6091917](https://gist.github.com/egonSchiele/6091917)

</comment></comment></comment></comment></comment></comment><comment><USER28> Set aside the small examples and theory about what's best, no argument beats a real world example.

Are there any large opensource haskell web apps that one could read to see how it really done ?

<comment><USER21> [http://www.joachim-breitner.de/blog/archives/606-Real- World-...](http://www.joachim-breitner.de/blog/archives/606-Real-World- Haskell-Applications.html)

[https://www.fpcomplete.com/page/case- studies](https://www.fpcomplete.com/page/case-studies)

<comment><USER29> So, the short answer is no.

And there are many reasons to that. One of them: Haskell developers tend to love the technology and forget about the product.

<comment><USER6> How do you come to that conclusion? I am all about the product, which is why it isn't open source.

<comment><USER30> Well, I think there's clearly such a contingent, and I think it's more visible because of Haskell's academic heritage; it may also be larger, but I am much less confident in that - there are people who love pushing the tech in most languages.

<comment><USER6> I think it isn't more visible, it is just more talked about. There is a perception, not a reality.

<comment><USER30> I don't think there's a difference between what you mean by "talked about" and what I mean by "visible". I am convinced that the perception is there - <USER2> perceive it. I am not convinced that the reality is present - though I am not entirely convinced it's absent, either.

<comment><USER6> There is a big difference. Visible means you can see that "contingent" existing. Talked about means they don't actually exist, but people always refer to them as though they do exist.

<comment><USER30> So you think there is _not_ a subset of Haskell developers who are more interested in tweaky tech than in practical problems? If that's the case, then it's true that I disagree with you - as well I should, having observed and interacted with such people myself.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> Reminds me of "Step 2: Draw the rest of the fucking owl." It does not follow that because Hello, World is easy, therefore IO in general is easy.

<comment><USER8> Can you explain what you feel is hard about IO in Haskell that isn't hard in other languages? Sure, you need to get used to the different way of working with IO (remembering to use <\- instead let, calling return to wrap the result back into the IO type, etc.), but after some time, it's pretty much automatic.

</comment></comment><comment><USER32> I really need to learn Haskell. Thanks for this.

</comment><comment><USER33> All of the examples of aeson I've seen have been for very simple, flat, json objects. What happens when you have json with nested objects. Do you have to create types for each intermediate json object or can you pull the values out into the top level type? If so how?

<comment><USER34> When I code in Haskell, the first and most important step I make is to create rich types for the domain I'm working in. If you disambiguate your types, your code becomes more readable and the compiler is a lot better able to help you out when you make a mistake.

For example, rather than having an Invoice with a status field of Text or String, I have a type InvoiceStatus = Paid | Unpaid | Void. From there, you can write a very precise parser that takes exactly what you want and nothing else. When I apply this approach to each component of the thing I need to parse (or do it generically even), I don't really find myself having to munge javascript types into my data structures.

<comment><USER35> To expand on that, these "custom" types are really the only time you have to do any extra work for support with aeson. If you leave your status field as Text or String it's implicitly supported.

That said, aeson support for nullary types (i.e. types that hold no "extra" values, like InvoiceStatus above) is trivial and the types make a _huge_ difference in the rest of your code.</comment></comment></comment>