Catastrophic effects of working as a Facebook moderator - <AUTHOR> https://www.theguardian.com/technology/2019/sep/17/revealed-catastrophic-effects-working-facebook-moderator <comment><USER2> The situation might not be so much better on other services of that scale (Youtube, image hosters,...) but what really makes the difference with FB for me is that it reminded me of a tweet from a FB employee who claimed that the amount of good that Facebbok does (might have been 'can do'?) is _unlimited_. Unlimited, ffs? I can only wonder how it comes that self-perception and reality can diverge so enormously.

(My eternal gratitude to the one who can dig up the tweet. All my efforts were futile so far.)

<comment><USER3> You're doing the same thing by claiming your opinion is "reality".

<comment><USER4> I think this is a false equivalence. His claim is the stronger one in my opinion.

<comment><USER5> I think his opinion is far stronger. Facebook is a far better company than apple. At least they dont hate poor people.

How crazy I sound to you is how crazy you all sound to me.

<comment><USER6> A company considering its users its product can't get much lower IMO. Remember that time they experimented on users' emotional states without any consent or informing? [1] This is when they started to show their true cards. To me FB is on its own level far below even oil companies and big banks, probably around the same ranking as PMCs. You'd be far pushed to find me something worse.

Apple is no saint but FB's total disregard to its responsibility and position in the world is so much worse.

1: [https://www.forbes.com/sites/kashmirhill/2014/06/28/facebook...](https://www.forbes.com/sites/kashmirhill/2014/06/28/facebook- manipulated-689003-users-emotions-for-science/)

<comment><USER5> Not really when that service is offered free of charge. I am pretty sure most people in India, Africa don't give a shit that Facebook uses their data to serve them ads. They and the world, gets an invaluable service in return.

I certainty don't care.

<comment><USER4> Facebook uses their data _today_ to target ads.

What the data gets used for later by Facebook, the government or organized crime, when it inevitably gets stolen, is anybody's guess.

<comment><USER5> Apple uses their data _today_ to create various products.

What the data gets used for later by Apple, the government or organized crime, when it inevitably gets stolen, is anybody's guess.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> >They also said others were pushed towards the far right by the amount of hate speech and fake news they read every day.

There's something wrong with mainstream reporting if mere exposure to social media turns people far right. It really strikes me that people are trapped in some pretty strong filter bubbles to the point mere exposure is enough to change political belief.

Spend a week on a far right community and you'll be shown more stats that point to a far-right conclusion than you can critically evaluate. In any internet discussion of police racism for instance FBI crime stats will be mentioned in a heartbeat but I don't think I've seen a mainstream journo bring them up once. Social media and mainstream media fundamentally follows different schemas of information simply because even bringing up certain data can cause a mainstream journo reputational damage.

This is also causing an inverse filter bubble where hateful ideas which actually have refutations don't get refuted because people refuse to discuss the ideas on principle. Much of the data cited is crap and much of the interpretations are crap but they're not meaningfully contested.

<comment><USER8> > There's something wrong with mainstream reporting if mere exposure to social > media turns people far right. It really strikes me that people are trapped > in some pretty strong filter bubbles to the point mere exposure is enough to > change political belief.

A different conclusion to draw from this is that far-right interests are responsible for the majority of the objectionable content on social media. One might further suggest that said content is deliberate propaganda, designed to push people to the right, and that this is a central pillar of their strategy that isn't shared to the same degree or extreme by other political factions.

This isn't "mere exposure". I haven't read the article so please correct me if I'm wrong but this is a job, a place they go to sit every day to be bombarded with this crap. To some extent they _have_ to sit and let it wash over them—I don't imagine the people doing these jobs have much career mobility. IMO it's not realistic to suggest that if they were just better-informed, they wouldn't suffer these effects. The mind is not an inviolable fortress—no matter how strong you think your defenses are, they can be worn down.

<comment><USER7> >One might further suggest that said content is deliberate propaganda, designed to push people to the right, and that this is a central pillar of their strategy that isn't shared to the same degree or extreme by other political factions.

This is certainly part of it. I've literally watched Russian propaganda around the Syrian war featuring a "Canadian independant journalist". Yet overall this explanation strikes me as unsatisfying. From what I've heard from the researchers propaganda techniques have been less about promoting the right wing specifically and more about spreading social discord generally. The Russians had efforts to promote Jill Stein that were promoting left wing rather than right wing propaganda. I've never really bought that propaganda efforts weren't getting overwhelmed by the influence of regular users generally. It's possible but I haven't seen serious attempts to prove it.

>I don't imagine the people doing these jobs have much career mobility.

This is actually a more interesting criticism to me. Perhaps internet moderators are more drawn to far-right thought than others because of their life circumstances? This is a population that's lower income and tech savvy.

</comment></comment></comment><comment><USER9> I recently met a guy in Berlin who is employed by a company that is a FB sub- contractor for content screening. When I met him, he had been on sick leave for 2 weeks, because of the awful working conditions and the stuff he had to go through daily. He was obviously looking for a new position and, I can attest, he looked like "damaged".

</comment><comment><USER10> One idea: To cope with all this, reduce the flagged posts presented by the algorithm to maybe 2 - 3 hours a day. For the remaining 5 hours, the algorithm could show them chats, pictures and videos that are harmless and uplifting. This might create a counterbalance, showing that there is still something good in social media.

I think that's how RL works in most countries. You are not running through the streets, getting slapped with crime and therelike all the time.

Of course, this also means you need more people to deal with the same amount of content as you do today.

<comment><USER11> I think you might be on the right path, at the same time mandated "happy picture time" seems like it might be it's own weird world to live in.

Moderator1: "Hey man how is it going today?"

Moderator2: "Pretty good, it's kitten day."

<comment><USER10> That sounds pretty surreal, I agree.

</comment></comment></comment><comment><USER12> I spent most of last Friday keeping an eye on 4chan's /pol/ after finding out that morning that users were planning an attack on my job.

Even just looking for one day, it took a serious emotional toll on me. I've definitely seen some awful things on the Internet but the constant bombardment of hate speech, racism, anti-Semitism, and all sorts of disturbing images and text over the course of 6 hours made me feel physically sick a number of times, and I had to take extra care to rest the next day.

This is anecdotal of course, but I can't imagine what the Facebook moderators go through having to process at least one ticket a minute.

<comment><USER13> Or the 4chan janitors, for that matter.

<comment><USER14> Even worse than Facebook moderators, since they do it for free

<comment><USER15> OTOH: my understanding is that most (if not all?) 4chan janitors are recruited from 4chan itself, so they have a pretty good idea of what they're getting into.

</comment></comment></comment></comment><comment><USER16> There are many aspects to this, but it seems that the most lasting and strong effects are due to visual content (especially raw content, violence...) rather than text (even though text can be violent).

Which is why automated Image/Video moderation solutions (such as Vision, Rekog, Sightengine.com, Hive) will continue to grow. Not only because it is cheaper/faster, but because it becomes a necessity. Or at least as a first filter to weed out the "worst" content.

<comment><USER17> At a $previousJob I had some tangential contact with professionals who track child pornography, trying to identify and free the kids (people involved in catching [https://en.wikipedia.org/wiki/Christopher_Paul_Neil](https://en.wikipedia.org/wiki/Christopher_Paul_Neil)). They felt that automation was of little help for what they were doing, and that every image had to be looked at by at least one human (most of the images by more than 1). They had a few tricks (apparently looking at the image in B/W helped lessen the trauma) but they did not find value in the automated tools we tried to build to help them.

Now, they felt much more empowered than what Facebook was doing: they kept going because the goal was to stick cuffs on the wrists of the guys who were doing this, and get those kids away from him, and they could put up with all of the rest for that goal. They were treated as rockstars by the rest of the people they interacted with, because they were the ones who got kids away from the predators. They had frequent opportunities to take breaks and could set their own schedule, with only the guilt that came from the longer they delayed, the more time passed with the kids in the predators hands to drive them.

Ultimately, feeling empowered to make a difference in the world is key, and if Facebook treated screening as an important job and gave their moderators more power to set their own working conditions I suspect that it would improve their mental health by quite a bit.

<comment><USER18> Good point about empowerment.

I hope they are investing in an army of shrinks /psychologists/sociologists to study,improve and supervise these centers, cause this stuff is not going away by just deleting content.

</comment></comment></comment><comment><USER19> They could use some image processing to make the videos look cartoonish, at least for the first analysis.

That might soften the blow to the screeners.

</comment><comment><USER11> I wonder what the solution is here.

To expose people to this stuff continuously seems wrong.

Then again so does exposing everyone to it / would probabbly kill the service if it wasn't dealt with by someone.

Another concern is finding people who can handle these situations in a healthy way, might be few and far between, and generally the folks exposed to it folks hired into low pay / outsourced warm bodies in chairs kinda situations.

<comment><USER20> What if the answer is to kill social-media-as-we-know-it?

There are some sick and "extremist" people in this world. If their stage were relegated to email threads I imagine we would not be having this discussion.

But I think what bothers me the most, and this is eluded to in the article, is not that some extremist is posting crap, no surprise there. But that seemingly once-normal relatives of mine are consuming this crap and then reposting it — becoming the extremists themselves.

<comment><USER21> > What if the answer is to kill social-media-as-we-know-it?

This is the real answer. If running a service _requires_ paying people to look at awful, damaging material—stop running the service. It shouldn't exist. It doesn't need to. Absent things like Twitter and Facebook we'd find other ways to keep in touch with people who matter. Special Email clients that do most of the friends & family stuff that FB does but over email or whatever. Some new protocol. Progress on that kind of stuff only stalled because we've got the spyvertising- or VC-funded, moderator-harming services to compete with. Take those away and the void _will_ be filled, with hardly a hiccup.

"Well gee whiz we just can't run our service without doing this to our moderators, so I guess we have to"—no, you don't, period, at all. You can stop running your service, or live with hurting people and stop acting like you care.

<comment><USER20> I would suck as a CEO. The first time someone live-streamed an attack/rape/murder on my platform I would pull the live feature.

</comment></comment></comment></comment><comment><USER22> Yet another reason to stop trying to have a central authority, in this case Facebook moderators, police speech. It can't be done effectively or without major side effects. Let people filter on their own, we all do every day in the real world and it works just fine.

<comment><USER23> You are a lot less likely to run into violence, gore, exploited people, etc. in person. The answer to, "human moderators get hurt by the constant stream of truly awful stuff." is not, "let the stream of truly awful stuff just go straight to everyone".

</comment></comment><comment><USER24> What strikes me about this issue as a whole is what it says about the true state of "AI". This is a perfect job for such technologies. I mean how is it that we're already making 'deep fake' videos and audio but can't feed a video stream which is just a stream of images to an algorithm which can determine if it's inappropriate. I recognize that some such tech is being utilized on the front end in this case, and that the problem is non trivial, but I see this as FB saying 'good enough' and not pushing as hard as they could to improve the tech to where it can be trusted to make the decision. I sense that they may be telling themselves they're doing social good by 'creating jobs'. Why must humans be subjected to this torture? What happened to "move fast and break things"? Why not put the algorithms out front and let them have the final say, and let them learn and improve quickly? I suppose just because meat is cheaper than chips.

<comment><USER25> > I recognize that some such tech is being utilized on the front end in this > case, and that the problem is non trivial, but I see this as FB saying 'good > enough' and not pushing as hard as they could to improve the tech to where > it can be trusted to make the decision. I sense that they may be telling > themselves they're doing social good by 'creating jobs'.

This seems like a weird take to me. Why would this be your conclusion rather than that the technology isn't good enough yet?

<comment><USER24> Because the move to hire so many moderators so fast was a big expensive move that seemed like more of an implementation for PR purposes considering some of the troubles the company was experiencing. When your motto is 'move fast and break things', and you implement features like live video streaming without much thought to the full ramifications of doing so, it would seem even if only to me, that company might not be afraid to take a leap on tech that's 'not quite ready'. Again, I know such a hasty implementation could hurt quality, but given what's at stake (human health), they might get credit for doing the right thing. Obviously, though in our society, where they wouldn't get such credit, and would only get flamed for having a bad user experience for the wrong videos being taken down, the mental health if a few humans who willingly signed up is a small sacrifice for profitability.

</comment></comment></comment><comment><USER26> If you think about it, you have a large group in society who spend 8 hours a day watching content so controversial it won't even reach the rest of us. Just like any other company, people eventually quit, and new people join. Now if you were the bad guy wanting to nudge a % of society in a specific political direction, wouldn't this moderator group be a perfect target? Just bombard [insert social media platform] with propaganda content and you _will_ reach this group of people even if the content never appears on the platform. What a messed up situation.

<comment><USER27> Not really feasible; a group of a couple thousand converts are useless if they aren't targeted at a specific region; with Facebook's love of outsourcing you can't even be sure they are in the same country.

</comment></comment><comment><USER28> Maybe you need people who are just numb to it? It seems like the kind of gig that would attract the kinds of people who like seeing it. I know that's morbid to think about but look at subreddits like RIP /r/watchpeopledie, /r/enoughinternet, morbidreality is still around luckily. You get people who don't mind the gore and terrible things, pay them to sift through it, and see what the outcome is there?

<comment><USER29> Maybe for gore. For child abuse images, not so much.

I can only imagine the aghast looks one would get from the PR and HR people, just for _asking_ about forming a team of people who liked looking at child abuse images!

<comment><USER30> The conversation might go better if you framed it as paying the members of that team less than they'd get in comparable jobs with less child abuse.

</comment></comment></comment><comment><USER31> Back in 1999 when I had AOL 4.0 at the age of 16, I would frequent www.goregallery.com and other various gore-related websites that showcased real crime & accident scenes from around the world. Still to this day, I am fascinated by that kind of content. I don't really seek it out like I did as a teenager, but it excites me nonetheless.

</comment><comment><USER32> The solution here may be for all of us to flag posts that we know are benign, like puppies or birthday greetings. This would reduce the percentage of disturbing content moderators are forced to see, and costs us nothing at all.

<comment><USER33> That's not a solution, that's just increasing their workload. It doesn't remove the root cause, nor the fact that people still have to assess a lot of content - which apparently the super smart AIs can't identify themselves.

</comment></comment><comment><USER34> Just to be clear: There are no statistics in this article, just some anecdotes selected to push a particular narrative.

I don't claim to know whether working as a FB moderator is 'catastrophic' or not, but this article makes an emotional case for it rather than a rational case for it. It reminds me of reporting around the Foxconn suicides - sure, each is a tragedy, but it turns out the Foxconn suicide rate matches the national rate.

<comment><USER35> "There are no statistics in this article, just some anecdotes selected to push a particular narrative."

Please don't reduce people to data like this. Plese don't automatically assume bad faith on the part of the authors of the article. Consider there are actual people involved here, reporting their experiences. Don't make it into some kind of social-justice battleground or science experiment, just consider their perspective without instant judgment.

<comment><USER36> You could say exactly the same about anti-vaxxer nonsense. The lack of statistics makes it something where you can only wring your hands and say "oh, how awful" and not "yes, but..." and consider meaningful alternatives.

<comment><USER35> There is a stark difference in the anti-vaxxers are directly advocating for dangerous policy changes. I don't see anything of the sort here.

<comment><USER37> The problem is that to someone on the fence about vaccination, they take legitimacy from articles that appeal to emotions and don't back up facts with data. Anti-vaxxers write the same way.

<comment><USER38> This article cites clear examples of psychological harm and trauma being inflicted upon Facebook moderators. That itself is sufficient data.

</comment></comment></comment></comment></comment></comment><comment><USER39> The very fact that Facebook outsources its censorship to contractors underlines the precarity of a workforce that is considered both disposable in the short term and irrelevant in the long term.

Ultimately Facebook wishes to replace this workforce with AI automation where possible, and then heteromate the remaining human work by enticing users of the platform to inform on each other with posts that don't abide by the platforms implicit social norms or opaque moderation rules.

</comment><comment> J-dawg There seems to be a fundamental hypocrisy in a legal system that considers some material is so fundamentally _corrupting_ that it must be illegal for people to possess or see it.

If this were truly the case, it should also be illegal to compel someone to look at this same material as part of their employment.

<comment><USER40> I wonder how you look at vice-squad members?

And from what I've seen they are quite happy to receive tips about abusers from the public and businesses that care enough to review their content. For society to work some of us have to step forward and agree to do the dirty work.

That some people are doing this for a living without proper counseling and guidance is another matter, you can lay that at Facebook's door. The few times that I've been exposed to that crap was enough to make me shut down some services.

In fact, I think that _any_ business that deals in user generated content should assume the cost of business that goes with that and have a system of flagging and escalation in place.

<comment> J-dawg > I wonder how you look at vice-squad members?

It was a poorly formed argument, but you've hit on the absurdity that I was trying to point out. Obviously _somebody_ has to look at this stuff.

But having low paid, poorly trained people do it all day, every day? I don't think it's crazy to suggest that shouldn't be legal.

And if Facebook can't exist in its current form without these teams, then I'm totally fine with that.</comment></comment></comment>


The Future Programming Manifesto - <AUTHOR> http://alarmingdevelopment.org/?p=893 <comment><USER3> Nice to see another post addressing the biggest issue in Software Engineering head-on.

This of course is nothing new - it's something Alan Kay has been telling us for more than 3 decades [1], who also has an enlightening talk addressing the biggest problem facing software engineering [2].

Before vanishing from the Internet node's Ryan Dahl left a poetic piece on how "utterly fucked the whole thing is" [3].

Steve Yegge also has dedicated one of his epic blog posts to "Code's worst enemy" [4].

More recently Clojure's Rich Hickey has taken the helm on the issue producing his quintessential "Simple Made Easy" [5] presentation, explaining the key differences between something that is "Easy", to something that is truly "Simple".

[1] [http://mythz.servicestack.net/#engineering](http://mythz.servicestack.net/#engineering)

[2] [http://www.tele-task.de/player/embed/5819/0/?iframe](http://www.tele- task.de/player/embed/5819/0/?iframe)

[3] [https://gist.github.com/cookrn/4015437](https://gist.github.com/cookrn/4015437)

[4] [http://steve-yegge.blogspot.com/2007/12/codes-worst- enemy.ht...](http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html)

[5] [http://www.infoq.com/presentations/Simple-Made- Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

</comment><comment><USER4> Some demonstrations of how simplicity can be pursued:

The Viewpoint Research Institute is trying to build an entire computing stack in 20kloc - [http://www.vpri.org/pdf/tr2010004_steps10.pdf](http://www.vpri.org/pdf/tr2010004_steps10.pdf)

The Berkeley Order-Of-Magnitude group reimplemented Hadoop and HDFS in a few thousand loc whilst remaining api compatible and having similar performance - [http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf](http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf)

Both efforts required questioning the assumption that the complexity of modern systems reflects inherent complexity in the problem. That is the point of this manifesto - to get such drastic improvements we have to step back and rethink our entire approach to build software systems.

I suspect that a large part of the problem is the different response curves for features and complexity. Adding a new feature for a little complexity seems like a good trade. Thousands of people make that decision in their own individual areas and suddenly the cumulative complexity falls off a cliff and we can't handle it anymore. To get simplicity back we have to take a very high-level view of the tradeoffs and demand much more power in return for each unit of complexity we add.

EDIT "Programmers tend to overlook the fact that spring cleaning works best when you're willing to throw away stuff you don't need." \- [http://steve- yegge.blogspot.com/2007/12/codes-worst-enemy.ht...](http://steve- yegge.blogspot.com/2007/12/codes-worst-enemy.html)

<comment><USER5> The example from the BOOM group is interesting! However, it's not clear they are arguing for the same kind of "simplicity" than Jonathan Edwards.

The BOOM group seem to be using a Prolog variant, and their conclusions argue for declarative, high-level programming languages (I didn't read the paper in full; please correct me if I'm wrong!). But if you take a look at declarative programming languages such as Prolog, or functional languages like Haskell or OCaml (all languages which aim to make complex problems more tractable), this is precisely what many programmers reject as "too complex". It doesn't help that very often, "complex" is used as a synonym for "unfamiliar".

Here is another piece of the puzzle: in another post by John Edwards, he claims simplicity led him to reject higher-order functions for the "simple" language he is designing. But higher-order functions are a tool (not necesarily a _simple_ tool) useful to reduce the complexity of code! It just happens that a programmer unused to them must first learn about them before becoming proficient with them.

So the trade-off between complexity and simplicity isn't so easy to define.

<comment><USER6> > he claims simplicity led him to reject higher-order functions for the > "simple" language he is designing. But higher-order functions are a tool > useful to reduce the complexity of code! It just happens that a programmer > unused to them must first learn about them before becoming proficient with > them.

Higher-order functions, or higher-order anything (e.g. predicates) are not complicated because they are unfamiliar, but are complicated necessarily: HOFs, for example, indirect control and data flow, and now you have to think 2nd or 3rd order (hopefully not more) about what your code is doing!

Complexity is really just in the definition of "higher-order." It even shows up directly in our tools for automatically reasoning about program behavior (1st order is easier to deal with than 2nd or N-order). There is a reason 1st order logic is so popular, not because people don't get higher-order logic, but 1st order logic is easier to deal with. The problem is, of course, expressiveness (you can't do much with a functional language that doesn't admit HOFs).

<comment><USER5> I disagree that higher-order functions are "complicated necessarily". I believe this is actually a side effect of people usually learning to program using languages that don't support them. Weren't there success stories posted here on HN about novices learning to program with functional languages without difficulty?

It's not surprising you can do a lot with a programming language that doesn't support HOFs (though, of course, there wouldn't be much point in calling it functional) -- you can in fact do everything without them. The key issue here is whether HOFs are a useful tool that, once learned, will help make the complexity of the problem you're attempting to solve more manageable. I believe they are, by helping with modularity and composability.

Even if learning to use more powerful tools is more "complex" (that is, it's "easier" or "takes less time to get used to"), _once_ you master them, presumably you're equipped to deal with the tasks you want to accomplish.

Maybe some power tools can be made easier to handle. This is a valuable goal. But if your goal is to never make a tool that requires the user to be trained, you're severely limiting yourself.

<comment><USER4> I think he is arguing that higher-order functions are more difficult to learn/use than first-order functions because they require higher-order reasoning. That's not to say that they aren't useful or that beginners can't learn them, but just that they impose an overhead and it's worth exploring alternative methods of reducing complexity that may end up having a lower overhead.

> ...once you master them...

Arguments of this sort tend to assume that a) the learning time can always be written off and b) that once you master a tool there are no more overheads. a) is false in the case where the learning time is too long or simply not available eg Joe Accountant may benefit from learning to program but he doesn't have the time to spend years learning. b) is false in the case where the abstraction is harder to reason about or makes debugging harder.

There is certainly an economic decision to be made here but it must consider opportunity cost, cognitive overhead and maintenance overhead as well. That decision doesn't always favour the slow-to-master tool.

It's like extolling the virtues of investing in an industrial nailgun to someone who is just trying to hang a photo. Sure, the nailgun will make driving in nails faster but the investment won't pay off for them.

</comment></comment></comment></comment></comment><comment><USER7> I'm all for simplicity, but often, programmers follow the same cycle:

1\. X is bloated, let's reimplement it under the name Y with all the fat trimmed!

2\. Notice that the problem may be a little bit harder than originally envisioned, start to add more and more features

3\. Y is impossible to distinguish from X

Not to say that sometimes you shouldn't cast down existing systems, but it's often because the times have moved on (eg, Wayland vs X11).

I'll note that 1. is (involuntarily) in the same category as the discourse of populist politicians who promise simple solutions to complex problems. I am wary of both.

<comment><USER8> Case in point: Notice that the web technology stack is really complex. So are the native GUI toolkits on all mature platforms. And something like wxWidgets that wraps all those toolkits is its own kind of complexity. "I know, I'll implement my own beautifully simple UI toolkit and bind it to the core graphics and input APIs on each platform." Congratulations; your beautifully simple solution is going to be off limits to some users, because you haven't handled accessibility, internationalization, etc. So some of that complexity you wanted to avoid was necessary after all. But maybe we can still categorically reject the web stack for applications that don't actually run in a browser.

<comment><USER9> I think you are not stepping back far enough to look at the problem. Are you actually suggesting the entire complexity of the current web-stack (html, css, js and server side code) is essential to make web-apps?

<comment><USER8> I wasn't clear. I know there's a lot of incidental complexity in the web stack. But I'm afraid that some developers, in response to a stirring call to simplicity such as this manifesto, will go too far, blissfully unaware that some of the complexity of mature UI toolkits (not just the web stack, but also the native toolkits of mature platforms) is actually necessary.

</comment></comment></comment></comment><comment><USER10> A Manifesto for Mediocrity.

Every few years someone comes up with the idea of making programming so simple that anyone can do it. This is not new; the concept has been around at least since the '60s. Look at some COBOL history:

"They agreed unanimously that more people should be able to program and that the new language should not be restricted by the limitations of contemporary technology. A majority agreed that the language should make maximum use of English, be capable of change, be machine-independent and be easy to use, even at the expense of power." [1]

Many attempts have been made to achieve this Silver Bullet. The examples that get closest are things like GameMaker:Studio [2] or Unity 3d [3], which are extremely domain-specific (for certain classes of 2d and 3d games, respectively).

So you CAN create a _domain-specific_ language that anyone can use. But every attempt to create a completely general purpose language that anyone can use to do anything has failed -- or has ultimately (accidentally?) produced a domain- specific language that solves the specific problems that the authors are most familiar with.

[1] [http://en.wikipedia.org/wiki/COBOL](http://en.wikipedia.org/wiki/COBOL)

[2] [http://en.wikipedia.org/wiki/Game_Maker:_Studio](http://en.wikipedia.org/wiki/Game_Maker:_Studio)

[3] [http://en.wikipedia.org/wiki/Unity_%28game_engine%29](http://en.wikipedia.org/wiki/Unity_%28game_engine%29)

<comment><USER4> > But every attempt to create a completely general purpose language that > anyone can use to do anything has failed

Excel is used by millions of people and powers large swathes of the worlds economy. VB6 is still in use today and powers multi-million dollar companies ([http://msdn.microsoft.com/en- us/magazine/jj133828.aspx](http://msdn.microsoft.com/en- us/magazine/jj133828.aspx)). COBOL still lurks in the heart of many banks.

These systems have problems that cause untold economic damage. Instead of improving the tools to help people avoid these problems we sit around being smug about our uber-programming skills and declaring that programming is too complex for those people anyway. What many people here don't seem to realise is that the choice is not between the crappy VB6 app and a nicely architected system built by a 'real' programmer, the choice is between the crappy VB6 app and the same people doing the job manually.

Empirically speaking, given tools with an approachable learning curve many people are capable of producing simple programs that make them more effective at their jobs. Rather than lamenting that these people produce bad code we should be improving the tools to lead them down the correct path.

<comment><USER5> I agree with some of what you say about the damage these tools have done (but please note Excel is _not_ a general purpose language, which the parent post was talking about, though it can be used to make pretty cool and surprising things).

However, I don't think anyone is arguing that _nothing_ should be done about it. Some of us would argue that something _must_ be done, but that the answer is not necessarily simplification, especially simplification of the "make it easy" kind.

Especially since, for many programmers, "simple" & "easy to learn" are actually synonyms for "similar to something I'm already familiar with".

<comment><USER4> What most people seem to be arguing is either that the people currently using Excel and VB6 should suck it up and learn a real language or that they shouldn't be programming at all (I'm not saying you are, but this is the general sentiment I encounter in eg [http://developers.slashdot.org/story/14/07/09/131243/normal-...](http://developers.slashdot.org/story/14/07/09/131243/normal- humans-effectively-excluded-from-developing-software)). There are number of different spheres of programming with different requirements. For the sphere of end-user programming (which Jonathan Edwards explicitly calls out in this post) there are a huge number of people who have to choose between simple tools which don't work well or complex tools that they don't have the time to learn. This sphere has seen little change since the start of the millennium (Excel is still the best option by far, for all its limitations). The OP is arguing for efforts to close the gap and produce simple tools for their simple needs.

<comment><USER11> "What most people seem to be arguing is either that the people currently using Excel and VB6 should suck it up and learn a real language or that they shouldn't be programming at all"

And why is that such a problem? If you can handle excel and vba you can learn to program. A lot of existing languages are easier to learn than excel+vba.

Excel is not easy to use if you want to do anything moderately complex. Even after years of training all through school and in the workplace the average user can't do much programmatically with it.

Excel solved the input/output problem, the availability problem, and the business acceptability problem.

By that I mean business users were doing a massive amount of data entry and data manipulation mainly in order to do simple calculations and view data logically in tables. They did this without thought to automate but it made automation 10x easier.

As a business grunt I can't just install python and start cutting code. If I said "Hey boss I can automate this with python. It will only take me 2 weeks" I've got no hope. For starters corporate IT wouldn't even let me install python. But I can spend a month fiddling around in a spreadsheet to automate the same task and my manager will be happy.

<comment><USER5> @jamii

> It's not just programming that is hard, it's editing, debugging, compiling, > version control, packaging, deploying, upgrading etc. Existing tools give > you a huge amount of flexibility and power (that most end-user tasks don't > need) at the expense of a brutal learning curve.

Sure, I agree all of those steps are painful, and I think everyone here agrees that anything that can improve them is welcome! At the same time, some of them only exist in specific contexts. For example, is the guy writing an Excel macro not bothered about version control because Excel is an easy-to-learn tool that achieves simplicity, or because he isn't building something collaboratively with a team of 5 other people, all working on the same task?

By the way, I read your article. I fully agree with this:

 _" Finally, environments can't be black boxes. Beginners need a simple experience but if they are to become experts they need to be able to shed the training wheels and open the hood. Many attempts at end-user programming failed because they assumed the user was stupid and so wrapped everything in cotton wool. Whenever we provide a simplified experience, there should be an easy way to crack it open and see how it works."_

I'd add that they also need to be able to reach for the complex tools once they've mastered the simpler ones.

<comment><USER4> I think you misunderstood my point somewhat. I'm not saying that Excel solved the version control problem - far from it. Manual version control by emailing copies of spreadsheets was identified as a major cause of errors in various studies.

My point is that for end-user programming to work we need version control, deployment, packaging etc to scale down as well as up. The software industry has a tendency to fetishize scaling up and ignore scaling down.

Experienced professional programmers still struggle with git in their day-to- day workflow ([http://www.sussex.ac.uk/Users/bend/ppig2014/13Church- Soderbe...](http://www.sussex.ac.uk/Users/bend/ppig2014/13Church-Soderberg- Elango-PPIG2014.pdf)). The average end-user has no chance. Even if the underlying data model is something like git, the experience for the user needs to be more like undo-tree or etherpad.

Excel smooths the learning curve for calculation/simulation - you can get started by just putting in some numbers and learning a few basic functions. If that's all you need, that's all you have to learn. I want to see the same pay- as-you-go approach for all our tools.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> > Build compelling simplicity and performance will come.

Python and Ruby are notable counter-examples to this.

Both Python and Ruby were designed primarily for human-friendliness, as this essay advocates. Guido has described Python as "executable pseudo code". Matz has said that the primary purpose of Ruby is to make programmers productive and happy, and to design more for humans than for the machines.

People have tried to make the performance come. Python is well-loved which has led to numerous attempts to accelerate it (Psyco, Unladen Swallow, PyPy). Many of these efforts have made notable progress, but none have met the bar of compatibility and performance necessary to displace the relatively slow cPython. Ruby is getting faster, but it's still among the slowest compared with its peers.

There are other languages where the performance _did_ come (JavaScript, Lua). But this is in no way a given.

<comment><USER13> > Python and Ruby are notable counter-examples to this.

I beg to differ. You seem to imply that Python is a simple language. Quite the contrary. Attempts to accelerate Python failed exactly because it's an extremely complicated language. Same goes for Ruby and JavaScript.

<comment><USER13> > Python have a simple syntax

Python has a rather simple syntax indeed, but it has very complicated semantics. `foo.bar` - syntactically very simple expression of the attribute access has a mountain of semantics behind it.

> Given that Python and Ruby are both simple to learn and use (as users, not > implementors), they are both simple by the definition given in this article.

Good remark. I still tend to disagree though. It's easy to learn and use a very small _subset_ of the language. Not the whole language. Even then, it's practically impossible to limit yourself to a certain subset. Not if you want to use any python libraries.

</comment></comment></comment><comment><USER14> I feel like this is a kind of naive approach that might work for some end user programs, but isn't a good principle in general. Large/monolithic programs like databases, operating systems, compilers, etc. all can benefit from added overall complexity. (new data structures for storing data on disk, better memory management and program separation, better/more aggressive optimization+static analysis+etc.) You can argue that monolithic programs like those should be broken down into smaller parts (they already are, though), but in the end adding an R*-tree to a database allows you to do more types of lookups efficiently and makes your program /better/.

The thing that no developer really benefits from is added state complexity. But we've spent the last 30+ years coming up with ways to hide that kind of complexity from a programmer. That's /why/ we have our programs and processes divided into boxes (PL, OS, etc.) and /why/ we use things like higher level languages instead of assembly, object oriented programming, and general data hiding. On the other hand, it sounds much less sexy to say "People should do a better job of following best practices, and a lot of the problems in our industry are because people prefer to glue things onto existing code instead of being willing to do a higher level restructuring of a code base when a new need is established."

I'd agree that a lot of programming is not science. We shouldn't be treating it as such. The harder parts of programming are an application of theoretical mathematics (Dijkstra pointed this out years ago, and it's still true), but very little of CS is 'science' the way something like physics or chemistry is 'science'.

<comment><USER4> > That's /why/ we have our programs and processes divided into boxes

[http://db.cs.berkeley.edu/papers/cidr11-bloom.pdf](http://db.cs.berkeley.edu/papers/cidr11-bloom.pdf) \- by unboxing distributed systems we can statically predict whether a given program is eventually consistent ([http://arxiv.org/abs/1309.3324](http://arxiv.org/abs/1309.3324) \- and automatically add coordination protocols where necessary)

[http://db.cs.berkeley.edu/papers/dbtest12-bloom.pdf](http://db.cs.berkeley.edu/papers/dbtest12-bloom.pdf) \- by unboxing distributed systems we can use static analysis to more efficiently explore the space of message interleavings in unit tests

[https://infosys.uni-saarland.de/projects/octopusdb.php](https://infosys.uni- saarland.de/projects/octopusdb.php) \- by unboxing storage, databases and application-side queries we can treat the entire pipeline as a single optimisation problem

[http://www.openmirage.org/](http://www.openmirage.org/) \- by merging the OS box and the PL box we can improve performance and security for server applications

I don't disagree with you exactly, but I would point out that a) boxes are a mean of dealing with complexity - less complexity means we can have bigger boxes and more opportunities for cross-layer optimisation b) the places we have drawn those boxes are largely arbitrary and shift over time - <USER2> existence of the boxes does not imply that we can't benefit by moving the lines around or by merging some of them.

<comment><USER14> Interesting papers! I appreciate the links.

>a) boxes are a mean of dealing with complexity - less complexity means we can have bigger boxes and more opportunities for cross-layer optimisation b) the places we have drawn those boxes are largely arbitrary and shift over time - the existence of the boxes does not imply that we can't benefit by moving the lines around or by merging some of them.

I agree completely. However, the manifesto seems (to me) to advocate all-over unification as the end goal, which I think is naive. I read it as "if a program needs to be divided into separate boxes, perhaps you need to make it simpler", which to me seems like the wrong way to go about things.

<comment><USER4> Oh, I read it in context with:

> We should concentrate on their modest but ubiquitous needs rather than the > high-end specialized problems addressed by most R&D

A lot of the things we do in programming give us power and flexibility at the expense of increasing the learning curve: eg separate tools for version control, compiling, editing, debugging, deployment, data storage etc. IDEs can show all those tools in one panel but it can't change the fact that they were designed to be agnostic to each other and that limits how well they can interface.

My current day job is working on an end-user programming tool that aims to take the good parts of excel and fix the weaknesses. We unify data storage, reaction to change and computation (as a database with incrementally-updated views). The language editor is live so there is no save/compile step - data is shown flowing through your views as you build them. We plan to build version control into the editor so that every change to the code is stored safely and commits can be created ad-hoc after the fact (something like [http://www.emacswiki.org/emacs/UndoTree](http://www.emacswiki.org/emacs/UndoTree)). Debugging is just a matter of following data through the various views and can also be automated by yet more views (eg show me all the input events and all the changes to this table, ordered by time and grouped by user). We have some ideas about simplifying networking, packaging/versioning and deployment too but that's off in the future for now.

Merging all these things together reduces power and flexibility in some areas but allows us to make drastic improvements to the user experience and reduce cognitive load. It's really a matter of where you want to spend your complexity budget and how much value you get out of it. We think that the amount spent on the development environment is not paying for itself right now.

</comment></comment></comment></comment><comment><USER15> As an experiment, I took a few paragraphs and replaced the words "software", "software and programming", "programming" with the word "mathematics" and replaced the word "programmers" with "mathematicians":

Most of the problems of mathematics arise because it is too complicated for humans to handle. We believe that much of this complexity is unnecessary and indeed self-inflicted. We seek to radically simplify mathematics.

and

Much complexity arises from how we have partitioned mathematics into boxes: <put various branches of mathematics here>; and likewise how we have partitioned mathematics development: <put various phases here, from "Eureka" moment to copy-editing of proof>. We should go back to the beginning and rethink everything in order to unify and simplify. To do this we must unlearn how to do mathematics, a very hard thing to do. (I paraphrased by replacing the original "to" with "how to do".)

and

Revolutions start in the slums. Most new mathematics platforms were initially dismissed by the experts as toys. We should work for end-users disenfranchised by lack of mathematics expertise. We should concentrate on their modest but ubiquitous needs rather than the high-end specialized problems addressed by most R&D. We should take inspiration from end-user tools like <replace with your favorite tools, like pen-and-paper, whiteboard, abacus>. We should avoid the trap of designing for ourselves. We believe that in the long run expert mathematicians also stand to greatly benefit from radical simplification, but to get there we must start small.

</comment><comment><USER16> If you've seen some of Edwards' work and listen to what he is saying about aiming for non-programmers you may get an idea of how different his idea of programming is from what most programmers do (I admit I am a traditional programmer).

I think the problem is that the basic definition of programming relies on editing textual and mainly static source code that describes processes at a low level. As soon as you start to get away from that your tool by definition is not a programming tool and therefore programmers don't want to be associated with it.

Its a problem of a failure of imagination and worldview and a psychological issue of insecurity. Programmers are like traditional wood workers who look upon automated manufacturing with disdain.

Ultimately superior artificial general intelligence will arrive and put those mainstream programmers with their overly complex outdated manual tools out of work.

But programmers will hang on to their outdated paradigm until the end of the human age. Which by the way is coming within just a few decades.

<comment><USER17> I think you have a mistake in your analogy. We're more like mechanical engineers drawing complicated CAD diagrams. It's just that we don't need a whole factory to produce our product, because it's not physical. All we need is a compiler and copy the bytes of the output.

There are 100 decisions every minute that need very complicated thought processes to solve, this is as true in manufacturing as it is in software development. Do you make this button out of plastic or metal? What _kind_ of metal or plastic? How big should it be? Should it click or not? Does it have multiple functions based on the state of the vehicle? Does it have a label? Where does the label go? What does it say?

You could write this all into a spec, but the spec would end up being the same as the CAD drawing / program. So you end up relying on the experience of the engineer to make all the decisions without it all being 100% specced out. Maybe it's a button on a top end Mercedes that gets pushed a lot, so it should be metal to complete the feeling of luxury. Maybe it's a button on a mid-end Nissan that gets pushed a moderate amount - make it a decent plastic, etc.

<comment><USER16> But we arent using CAD programs to develop software are we. Look at the tools used to develop software and compare them to CAD programs.

</comment></comment></comment><comment><USER18> This "manifesto", for lack of a better word, neatly exhibits the main problem I have with so many efforts to "improve programming" of this style: they focus on ease of learning as the be-all and end-all of usability. Coupled with the unfortunate rhetoric¹, it left me with a negative impression even though I probably agree with _most_ of their principles!

Probably the largest disconnect is that while I heartily endorse simplicity and fighting complexity—even if it increases costs elsewhere in the system—I worry that we do not have the same _definition_ of "simplicity". Rich Hickey's "Simple Made Easy"² talk lays out a great framework for thinking about this. I fear that they really mean "easy" and not "simple" and, for all that I agree with their goals, that is not the way we should accomplish them.

How "easy" something is—and how easy it is to learn—is a relative measure. It depends on the person, their way of thinking, their background... Simplicity, on the other hand, is a property of the system itself. The two are not always the same: it's quite possible for something simple to still be difficult to learn.

The problem is that (greatly simplifying) you learn something _once_ , but you _use_ it continuously. It's important for a tool to be simple and expressive even if that makes it _harder_ to learn at first, since it will mostly be used by people who have already learned it! We should not cripple tools, or make them _more_ complex, in an effort to make them easier to learn, but that's exactly what many people seem to advocate! (Not in those words, of course.)

So yes, incidental complexity is a problem. It needs addressing. But it's all too easy to mistake "different" for "difficult" and "difficult" for "complex". In trying to eliminate incidental complexity, we have to be careful to maintain actual simplicity and not introduce complexity in other places just to make life easier for beginners.

At the same time, we have to remember that while incidental complexity is _a_ problem, it isn't "the" problem. (Is there every really _one_ problem?) Expressiveness, flexibility and power are all important... even if they make things harder to learn. Even performance still matters, although I agree it's over-prioritized 99% of the time.

Focusing solely on making things "easy" is _not_ the way forward.

¹ Perhaps it's supposed to be amusingly over the top, but for me it just sets off my internal salesman alarm. It feels like they're trying to _guilt_ me into something instead of presenting a logical case. Politics rather than reason.

² [http://www.infoq.com/presentations/Simple-Made- Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

<comment><USER19> I've observed a definite correlation that people who like Hicky's simple/easy framework don't agree with mine. Personally I don't find it useful because it tries to separate knowing from doing.

I also seem to disagree with people who emphasize "expressiveness, flexibility, and power". I think they are mostly a selection effect: talented programmers tend to be attracted to those features, especially when they are young and haven't yet been burned by them too often.

With such fundamental differences we can probably only agree to disagree.

<comment><USER20> I don't think this manifesto and the simple/easy framework are even really talking about the same things beyond the basic point around avoidance of incidental complexity. I think both viewpoints outline worthy goals with staggeringly different levels of scope. In the case of the manifesto there's hardly anything actionable beyond doing lots of mostly messy research. I think people find this frustrating, but so what? Lofty goals often arise out of the conviction theres far too much momentum in the wrong direction. In contrast I think the simple/easy framework is something a working programming can apply to everyday tasks and while unlikely to result in a radical shift it may perhaps bring some of us closer to seeing that even larger goals may be possible.

</comment></comment></comment><comment><USER21> <brain dump> Complexity really is the enemy. A couple of thoughts:

\- In programming, our job is to move over the "complexity hump." We hear a problem, we analyze it, we code it, then we simplify. Most really bad code comes from programmers never pushing past the hump. They just slash away at whatever problem is in front of them.

\- When we move past the hump, we push complexity off. Sometimes this is done by abstraction, sometimes by a reduction in terms. In either case, our job is to make the complexity go away. If we're still dealing with arcane issues a month from now? We're not past the hump.

\- Many times we believe we've simplified a problem, only to have the complexities jump out and bite us again later. That's why it's best to "exercise your code" to make sure that your abstractions or re-organizations will hold up in the real world. Use it in different contexts. When we don't exercise our code enough, we get complexity debt. The old "works on my machine" is now "works in these 12 cases I tried"

\- Every tool we pick up has some degree of complexity debt depending on how much it has been exercised in various contexts. Stuff like *nix command line programs? They rock. The reason they rock is because they have a billion different scenarios in which they've been proven.

\- Most modern programming environments involve programmers plugging into x number of tools, all of which have varying degrees of complexity debt. Many a time I've watched a programmer walk down the "happy path" of using a tool or suite. What a happy look! Then they realize they need something that's off the happy path. So they've got to pull the source code, inspect the deployed javascript, take a look at the IL, get a new patch, spend an hour on Google. It's at this point that the tool/framework stops being a help and becomes a liability.

\- For this reason, most tools and frameworks are actually liabilities instead of assets. I think there are a lot of programmers that would be amazed at what you can do in C, JSON, simple HTML, and Javascript.

</brain dump>

</comment><comment><USER22> This part seems really difficult to do well:

 _We should work for end-users disenfranchised by lack of programming expertise. We should concentrate on their modest but ubiquitous needs rather than the high-end specialized problems addressed by most R &D._

The single biggest win for end-users "disenfranchised by lack of programming expertise" in the past 20 years was probably PHP, because all you really needed to know was HTML plus a tiny smidgen of CSS, PHP and SQL. Anything else could be cobbled together with help from StackOverflow. The results were a mixed blessing: A lot of people built sites to suit their needs, but a lot of those sites degenerated into pretty ugly hairballs. Before that, the biggest win was probably Excel: The world runs on useful (but often buggy) spreadsheets. I have nothing against these tools. They're important and they fill a critical need.

Now compare a tool like Python: it's simple and it scales from novices to experts. But it's mostly limited to programmers and scientists, and unlike PHP, you actually need to learn some basic programming to use it in most cases.

I like using tools designed for professional programmers. It's great if they also work well for novices who are willing to learn a bit of programming. But the stuff I build is a lot bigger than the typical amateur PHP website, and I need tools for managing large amounts of complexity in my problem domain, and for managing requirements that will change significantly over the course of years.

</comment><comment><USER23> Highly recommended: Code Complete by Steve McConnell. A big part of the book talks about how to reduce complexity, in the literal sense and by using abstractions.

</comment><comment><USER24> A.k.a. the Suckless philosophy a.k.a. back in the day, the Unix/Plan 9 philosophy.

Unfortunately the market has shown that people vastly prefer ready-made, comprehensive, integrated solutions to a loose kitbag of nice, simple, composable parts out of which one might _build_ a solution. See: Outlook (mail, contacts, and calendaring in one!) vs. Unix mail programs, many of which didn't even have an editor built in but punted that to your $EDITOR. See also, Apple's domination of everything. So you are going to see less and less of the KISS priciple apply as the market demands more complexity for the sake of making their lives easier. And this applies to open source too. Systemd is evolving into a tightly-coupled mass that monitors and controls everything you might monitor or control on a Linux system; and soon it will be everywhere. There's also a whole generation of young programmers who do not understand Unix and so reimplement it poorly in JavaScript.

<comment><USER4> The key quote from the OP is "Complexity is cumulative cognitive load".

From the point of view of an end-user, using Outlook is vastly simpler than learning to program in order to cobble together their own solution out of command-line tools with harsh learning curves. Even for a professional programmer the tradeoff is pretty clear.

People only have so much cognitive capacity and so much time to live. Every hour spent messing with configuration or customising behaviour has to be weighed against the lifetime gain of that improvement (let alone the lifetime cost of maintaining the custom solution as the environment changes).

That's not to say that I don't want software to be configurable and composable, just that the cost of doing so with our current tools is too high for most users.

<comment><USER8> I think a crucial clarification here is the distinction between simplicity of interface and simplicity of implementation, as pointed out in "The Rise of Worse is Better". The components of a Unix system may individually have simple implementations, but it adds up to a complex interface for the user.

<comment><USER4> Well said. That's the distinction that causes so much tension between programmers and users - it's why we have this rift between unixy software which is wonderfully composable but infuriating to use and windows/mac software which is easy to use on the common path but refuses to talk to anything else.

</comment></comment></comment></comment><comment><USER25> The article seems to be cross with Computer Science in some way, while all the points it makes are about software engineering. The last paragraph in particular seems to be railing against something or other.

The manifesto declares boldly "we are not doing science". Right. This is completely and trivially correct. No one thinks you are.

</comment><comment><USER26> > "Perhaps we can learn from the methodologies of other fields like > Architecture and Industrial Design. This is a meta-problem we must address."

Something about history and being doomed to repeat it springs to mind.

<comment><USER10> The _entire concept_ of Design Patterns stems from a (largely failed) attempt to create design patterns in architecture. [1]

So, yes.

[1] [https://en.wikipedia.org/wiki/Pattern_%28architecture%29](https://en.wikipedia.org/wiki/Pattern_%28architecture%29)

</comment></comment><comment><USER27> It seems everybody is talking at a different level of abstraction. Reality is complex so the closest you're to it, the more complex your code will be (e.g. kernel supporting a zillion different hardware devices).

If the idea is to abstract even more in a simple and powerful way that more people can create more/better software, go for it. But don't dream that all that has been done until this day is complex because nobody cared about simplicity at all. I'm not saying the complexity is completely unavoidable but it takes a lot of work.

</comment><comment><USER28> I would not say that we are not doing science.

I would rather say we are doing science of the artificial---which looks a lot like design.

See the Sciences of the Artificial by Herb Simon (a true legend):

[http://www.amazon.com/The-Sciences-Artificial-3rd- Edition/dp...](http://www.amazon.com/The-Sciences-Artificial-3rd- Edition/dp/0262691914)

</comment><comment><USER29> What does the acronym 'PL' stand for in the sentence: "...partitioned software into boxes: OS, PL, DB, UI, networking..."?

OS = Operating Sytem, DB = DataBase, UI = User Interface, PL = I can't work it out but I'm sure it will be stupidly obvious once it's pointed out...

<comment><USER30> Programming language?

<comment><USER29> Haha! Stupidly obvious indeed. Thank you both.

</comment></comment></comment><comment><USER31> There's another thing that encourages complexity: vested interests. Once a complex paradigm is established you'll have vendors with an interest in maintaining or even increasing that complexity.

The corporate IT ecosystem is rife with this around areas like security and network administration.

</comment><comment><USER32> Is Hypercard always mentioned in 'make programming easier' manifestos because it was really easy or because we remember it nostalgically? I used it a few times in school but can't remember much about it. Never really got into programming in it much.

<comment><USER33> I used Hypercard for a solid year in high school. It was black-and-white and ran on Macs that were old even for 1994, but you could do stuff that was just awesome.

That was 1994--20 years ago--and my anatomy teachersomehow had a lab for Hypercard computers. He had the entire class design animated anatomy presentations that you still couldn't match today using 2014 mainstream presentation software.

There's a lot of nostalgia in programming, but Hypercard was the real deal.

<comment><USER34> I think part of what made Hypercard so useful was that it made it really easy to make one specific kind of application, which at the time was 90% of what any single person could be expected to do by themselves. Most of the "multimedia experiences" people were making and buying were basically interactive slideshows, roughly as complex as a DVD menu. Hypercard made this easy, and you knew before you started whether or not it would be a good fit for your project. Under the covers, it was a Turning-complete language, but I'd imagine trying to make anything more complicated than Myst would be really painful. I suspect the developers of Myst probably ran into its limitations before they were done.

I think the main obstacle nowadays is deployment. Back in the day, you'd have Hypercard export a native application, and then copy it onto a disk that you passed around. Nowadays, the expectation is that people can run it in a browser, or download it from an app store. Web-based deployment means you have to embed it in a website using Javascript, while app stores require setting up a developer account, and building with complicated toolchains.

This isn't to say it definitively can't be done, just an explanation of why it hasn't yet.

</comment></comment></comment><comment><USER35> "Inessential complexity is the root of all evil" this should be the wallpaper of every programmer.

</comment><comment><USER36> Of course, why hasn't anyone thought about that?!

/s

</comment><comment><USER37> Natural language programming.</comment>


Why are some people so much luckier than others? - <AUTHOR> http://ninjasandrobots.com/why-are-some-people-so-much-luckier-than-others <comment><USER2> Some people are so much luckier than others because nobody writes articles about Bob Jones, the failed actor, even though the Bob Joneses outnumber the James Garners by orders of magnitude.

I'm now convinced survivor bias needs to be taught in kindergarden and every year thereafter.

<comment><USER3> That's a really great point. However, I think there's still a lot of value studying a guy like James Garner and people who are the best.

I've actually studied acting for years. I've seen a lot of terrible actors and people who are good and struggle to get parts.

On observation. One of the biggest things to being a good actor or at least not a terrible actor is to learn that acting is much more about reacting. Learning to listen. Stop reciting lines, and instead LISTEN to the other people on stage and their needs and desires. Then react to those. A good actor could forget all their lines and still get through a scene because they can just react in character to what's going on around them.

James, as you can imagine from this article, was awesome at just listening. He didn't start out as a great actor but this quality definitely helped get him there.

On taking chances. I know some good actors who are baristas right now when not acting. When James needed money as a starting actor he was helping other actors recite lines, cleaning actors dressing rooms, even washing their cars. Which do you think will get you more possibilities for "luck", making coffee for random Joes, or helping Marlon Brando with lines?

But I agree with you that there are a lot of people trying and they'll never be as successful as James. But I also know a lot of people who won't ever as successful as they want because they do so little to find new opportunities. Also, the article wasn't titled, how to be as successful as James Garner, but was meant to point out some things Wiseman has found "lucky" people (not necessary James Garners) doing that "unlucky" people aren't.

<comment><USER4> This really is a very important point. The fact that James immersed himself in the world in all respects(day job and as an amateur) likely increased his chance of success.

If you were asked on the spot to name the names of a few acquaintances(not people you know, only people you know of), you'd probably name those who pepper your life most often. Now if those people made it known that they're fisherman or actors or really into painting or programming or etc. Then the next time someone asks "Hey you know of any good programmers? You know of anyone interested in painting? You know...etc"; _you 'll be able to say yeah I know a guy, he washes my car every other week._ It works out for you(because you recommended a person) and it works out for the other person because they get a shot at doing something they love.

James Garner allowed himself to seep into the consciousness of as many people as he could so they'd associated him with what he loved; smart move.

A corollary may be that the more people that know what you love, the more you become a person who loves that thing; both personally(mentally associating yourself as an actor/writer/programmer/etc) and professionally("Yeah, James he's an actor. Ben wants to be a painter. Sheila is trying to be a cartoonist").

</comment></comment></comment><comment><USER5> I rather like the Techzing guys' take on this, called "luck surface area," because it tracks with my experience and is actually weaponizable in a way that "be more observant" is not.

[http://www.codusoperandi.com/posts/increasing-your-luck- surf...](http://www.codusoperandi.com/posts/increasing-your-luck-surface-area)

If you for some reason want to get into a guild protected by a scouting system, then your priorities should be a) identifying what the scouts are looking for and getting good at it and b) getting in front of as many scouts as possible as often as possible.

There exist many opportunities which HNers want which resemble "a guild protected by a scouting system" if you squint at them, by the way.

</comment><comment><USER6> Perhaps instead of "fortune favors the bold," Virgil should have written "fortune favors the observant." I consider myself extremely lucky in life, but reading this article, I'm recognizing just how much of my luck has been a direct result of my being bold, highly observant, or both. Great piece.

<comment><USER7> I'm higly unobservant and my life I would say has been very "unlucky" :D Great article. Something for me to work on:)

</comment></comment><comment><USER8> People who believe life is not fair and nothing will go their way, will always find reasons not to act. People who believe good things are going to happen to them will always take action and have more luck.

In other words, the more chances you take the luckier you get. Life is a numbers game.

</comment><comment><USER9> Hero worship + survivor bias + "I did it all myself" autobiographies = "there's no such thing as luck, it's all hard work".

Hey, is there anyone here who was born in a first world country, grew up speaking the world's pre-eminent language, was born to parents in the richest 1% of the world population, grew up eating an ample supply of extremely nutritious food, and received a first-rate education while still a child? Anyone here like that?

<comment><USER10> Hey, is there anyone here who feels the need to self-flagellate in public over imagined sins, but not to read the article before trying to contribute to the discussion? Anyone here like that?

</comment></comment><comment><USER11> It turns out that about half of all people are luckier than the median. And ~2.5% are two sigma luckier than that.

It's a weighted random number generator. Some people make their own luck, and some have luck thrust upon them. Some people work hard and never get lucky.

Obligatory XKCD applies here too: [http://xkcd.com/904](http://xkcd.com/904)

</comment><comment><USER12> "The harder I work, the luckier I get" \--Henry Ford.

<comment><USER13> And this really is the answer... Luck is created. You'll never win the lottery if you don't buy a ticket, you'll never create Facebook if you don't create a business, and you'll never meet to girl of your dreams if you don't ask girls out...

<comment><USER14> On the flip side, nobody should expect to win the lottery just because they bought a ticket. Same goes for all of the other scenarios. Statistically you could expect that no matter how hard you work, you won't "make it."

<comment><USER13> The fact that you may not make it to the 99th percentile doesn't mean you won't see any success. Not everyone who starts a business will make billions, buy many make enough to live on. Especially more traditional businesses. Most people will get married. And most won't win the lottery, but that's not really putting in work anyway.

<comment><USER14> Right, the point is more to make sure your definition of "making it" is not essentially "win the lottery."

<comment><USER13> No, of course not. But those that put in enough work, are observant, etc... can make it to say, the 80th percentile. Then of those, the most talented might make it to the 95th. And those who have connections, or funding, or the right idea, might make it to the 99th. But either way, achieving success and being 'lucky' means putting yourself in the position to achieve success and be lucky...

Chasing girls is a great example. The guy I've known who has been with the most girls has also been turned down more than anyone I know...

<comment><USER14> Do you have numbers to prove it? Because... to many of us, it seems that _by far_ the largest indicator on whether you will make it to the 80th percentile, is if you started there.

<comment><USER13> Numbers to prove success is possible? There are numbers that show inherited wealth peaks and then declines, there are numbers show that most who have multiple billions of dollars earned their money (as opposed to inheriting it), but I don't think it necessarily matters.

Most individuals aren't entrepreneurs, most are content to work for someone else on a hamster wheel and blame their lot in life for their lack of success.

So I have no doubt people who grew up wealthy or at least well-off are more successful, since their parents taught and showed them that success is possible.

If you grew up in a household where your parents ran the rat race and told you that success is to get a degree and run the rat race, odds are that's what you've done...

<comment><USER14> I'm curious to know of the actual numbers you are referring to.

I am not convinced you are wrong. However, I am also far from convinced you are right. There is a lot of faith in "work hard and you can become rich." Especially if you are trying to imply this can get you "multiple billions of dollars."

Now, I personally think "rich" begins well before "multiple billions." I also don't think the world is split between entrepreneurs and people content to work for someone else on a hamster wheel. Truth is, as in many things, it is much more complicated.

So, yeah, do you have any good links to the numbers you are referring to?

<comment><USER13> I don't have any particularly large sampling with which to draw statistics from, but here's an article which uses Forbes lists to draw some stats: [http://www.chicagobooth.edu/capideas/magazine/summer-2013/bi...](http://www.chicagobooth.edu/capideas/magazine/summer-2013/billionaires- self-made)

[http://www.forbes.com/sites/erincarlyle/2013/09/18/how- self-...](http://www.forbes.com/sites/erincarlyle/2013/09/18/how-self-made- forbes-400-billionaires-earned-their-money/)

I'd guess it's harder to poll millionaires since most don't own enough of a public company for it to be reported.

Regardless, stats do a poor job of presenting possibility, and my guess would be most poor stay poor, if for no other reason than a defeatist attitude they inherited...

<comment><USER14> How would you propose to test this "defeatist" attitude hypothesis?

More interestingly, how would you reconcile it with the core hypothesis of this article. That is, that people can create their own luck.

Also, many of the numbers in those articles are... interesting. To call Bill Gates a "self made" individual is rather... cute. He is _far_ from a poor family. Pretty much everyone they have that is a "self made" rich person came from "upper middle class" families. (The articles words.)

This is concerning, as a large part of the problem that many fear in this nation is precisely how far the gap has grown between "merely middle class" and "upper middle." Consider, the vast majority of the "self made" rich people it lists are people that had early access to technology. Something that was decidedly situational related. Sheer numbers wise, it is on the level of winning the lottery.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Sometimes what people call luck may be observation, preparation, positioning or things of this nature....yes, that's true. These are things that can be controlled. I'm sure we have all met people who believe they have simply gotten unlucky while it's obvious to the outside observer that their actions resulted in the consequence they consider bad luck.

But, there is an element of random chance that exists outside our control and always will. This is what I call real luck and there isn't any use in trying to explain "why" because there is no "why" that we can understand. It's just a flip of the dice from our perspective. These kind of articles should really differentiate and stop lumping behavior in with luck. They aren't the same.

<comment><USER16> > But, there is an element of random chance that exists outside our control > and always will.

Certainly. But - statistically speaking - this would affect everyone the same way, positively or negatively. You're talking about chance, not luck as a property or attribute that someone can have more of than someone else. It might seem that way, depending on your sample size, but that's not really how it works.

<comment><USER15> Maybe what you are calling luck I call chance.

Just for fun I looked the word up. It turns out that either definition can apply.

I just take exception to the idea that everything is in our control. It isn't. Some events our out of control and often we don't even see what's coming.

</comment></comment></comment><comment><USER17> > James had a reason to be relaxed. He and his brothers grew up in a home of > mental, physical and sexual abuse. ... If that wasn't terrible enough, James > grew up during The Depression in Oklahoma, meaning he, his family, friends > and neighbors battled things like the Dust Bowl. ... James didn't worry > about much because nothing could be as bad as the life he had already lived.

Considering this is a crucial step in the thesis, I would like to see some evidence that this correlation (between a miserable childhood and lack of anxiety in adulthood) actually exists. It might _sound_ rational to look back over your life, realize that the worst parts are probably over, and thus not worry about the present or future, but I highly doubt this is how most people actually behave.

<comment><USER18> As my family includes many sufferers of anxiety of varying degrees, I've done quite a bit of research on the subject (in addition to personal bouts with mental health issues of that type, going through psychotherapy, etc.) and this James fellow is definitely the exception rather than the rule.

Typically childhood trauma like what the article mentions is much more likely to lead to mental issues (usually something like anxiety + depression) in adulthood.

So yeah, take that one with a grain of salt. It was a silver lining for this guy that he had such a horrible childhood but that is a dangerous part of the thesis to not mention as being very abnormal.

<comment><USER3> Thanks for reading my article! And thanks for the insight here. I really wasn't trying though to make it part of my thesis that you should have a terrible childhood in order to create a non-anxious state to make yourself more observant, or that you should give your own kids a terrible childhood to make them more successful.

But it was to show how relaxed James was, and it also seemed to stem from how he interpreted the terrible things that happened to him. I thought those stories could help some of us realize that if we could re-interpret some of the bad things that have happened to us the way James has, we could probably become more observant too, and hence spot more opportunities.

Also, Malcolm Gladwell has some interesting bits in his latest book, David and Goliath, about how childhood trouble like dyslexia can turn into opportunities. I'm going to butcher the research if I try and bring it up now, but there's some neat bits there if you haven't read them.

</comment></comment></comment><comment><USER19> This is a topic I have been thinking about quite a bit. here are my thoughts:

Good and bad things happen to all people. When a good thing happens, you can recognize the opportunity and seize it, or you can ignore it. The article mentions attributes this to attentiveness, and that is surely part of it. I also tend to attribute it to a mixture of intelligence and fortitude. If a person is a go-getter and is intelligent, he will make more out of fortunate situations than their counterparts. On the other hand, when bad things happen, "lucky" people tend not to fixate on them and work on forgetting them.

If you agree with me at this point, the next part is just a numbers game. If you are the type of person who always takes the same route to work, always eats at the same restaurant, goes to the same part, and vacations in the same spots, your chances of anything (good or bad) happening to you are limited. If you do diversify, take new roads, discover new places, and meet new people, you increase the number of things happening.

So in general, people who are positive, go-getters, and like to vary their routines and people they interact with will be considered luckier than the rest.

</comment><comment><USER20> Best post on luck, similar to this one, is by Paul Buchheit, "Serendipity finds you" \- [http://paulbuchheit.blogspot.com/2010/10/serendipity- finds-y...](http://paulbuchheit.blogspot.com/2010/10/serendipity-finds- you.html)

And the best book IMO is by Michael J. Mauboussin, "The Success Equation: Untangling Skill and Luck in Sports, Business, and Investing" \- [http://www.amazon.com/Success-Equation-Untangling- Business-I...](http://www.amazon.com/Success-Equation-Untangling-Business- Investing/dp/1422184234)

Way better than Nassim Nicholas Taleb's work, he's got his head up his ass way too much and makes too many hyperbolic remarks.

</comment><comment><USER21> Isn't there a basic math aspect to this?

Everything like looks, basic intelligence, rhythm, musical ability, sportsmanship are distributed among people according to a (mostly) uniform distribution.

I would believe you can say the samething about luck.

Now don't get the wrong idea that I advocate people to be bums waiting for the "luck" to happen to them. Not everybody who works their ass off(while being smart) is successful. We can quote a lot of examples from history to see this isn't the case.

And then there are people like Kardashians, who got to where they are, by what?

<comment><USER22> Actually, physical attributes are probably distributed closer to a Gaussian distribution - most people clustered around the average, with a small number of exceptionally lucky and exceptionally unlucky people in the tails of the distribution.

I would agree with you that in some vague sense, we might be able to think of a "luck distribution" with similar properties; however, it's not obvious what exactly that would mean in terms of what is actually being measured. Wealth? Happiness? Recognition in their field? All of these in the short run? The long run?

<comment><USER21> Yeah, you are right. It is Gaussian distribution.

We have to come up with an accurate definition of luck, and a way to quantify it. It is a function of work put in and the results obtained. And we have to define how to quantify work.

Another way is to think of world with no luck in it. How would it affect us? Would the world be the same?

</comment></comment></comment><comment><USER23> This coincidental connection made me smile: Queeg -> Red Dwarf -> Luck Virus

[http://en.wikipedia.org/wiki/Captain_Queeg](http://en.wikipedia.org/wiki/Captain_Queeg) [http://en.wikipedia.org/wiki/Queeg_(Red_Dwarf)](http://en.wikipedia.org/wiki/Queeg_\(Red_Dwarf\)) [http://en.wikipedia.org/wiki/Quarantine_(Red_Dwarf)](http://en.wikipedia.org/wiki/Quarantine_\(Red_Dwarf\))

</comment><comment><USER24> I remember reading somewhere that the question, 'Why are you lucky?' is used by companies during interviews. The question is supposed to say a lot about a person' attitude, self-confidence, self-worth, etc... The conclusion was why would anyone want to work with someone who perceives themselves as being unlucky. (Does anyone have a link to this article?)

Has anyone had to answer this question during an interview? Do you think it's a question worth asking?

</comment><comment><USER25> Tangential to this article, but chance events which effect an individual's life circumstances tend to be subject to feedback loops, where more of the same become more likely, in the sense that someone in bad circumstances (possibly partly attributable to bad "luck") has an increased range and likelihood of events that could make those circumstances worse. Same story with beneficial events, mutatis mutandis.

</comment><comment><USER26> I can relate to this somewhat. My grandmother always said I was lucky in life, and joked that if I walked up to a bus stop then three buses would turn up. I do consider myself to be observant to the point of distraction (I am also forgetful, lacking common-sense, and lazy).

Of course, I've not measured just how observant I am against anyone else, and it's just a hunch, so I could be talking shit. Enjoyed the article!

<comment><USER27> I'm similar to you. I notice potential problem situations amd opportunities way before friends and family do. I'm also lazy but also very particular.

With regards to coding it means that the lazy part of me wants to write as little code as possible, but the particular part of me is pedantic about making it both elegant and neat (I have a thing about consistent coding styles).

I am also very forgetful (terrible remembering birthdays for example) but more recently I've come to notice that I'm forgetful with regards to things that, in all honesty, I don't find important to me. Hence others are disappointed when I forget their birthdays bit it doesn't really bother me if I don't celebrate mine.

</comment></comment><comment><USER28> See also: last month's discussion of the _Commencement address by Bill and Melinda Gates_ [https://news.ycombinator.com/item?id=7954266](https://news.ycombinator.com/item?id=7954266)

</comment><comment><USER29> "Luck is what happens when preparation meets opportunity." -Seneca

<comment><USER30> After US Airways' 1549 "lucky" ditching Capt. Sullenberger said that "for 42 years, he's been making small, regular deposits in this bank of experience, education and training. And on January 15 the balance was sufficient so that he could make a very large withdrawal". So you might say that he got lucky, but you never see a student pilot with 4 hours flight time being this lucky.

<comment><USER31> He is also a glider pilot. I always hope when I am flying that the pilots fly gliders or Pitts Specials.

</comment></comment></comment><comment><USER32> I always recall Larry Niven's RingWorld and that amazing statement about probability (The Puppeteers breeding "lucky people").

</comment><comment><USER33> So he was lucky to be observant and positive. Heh.</comment>


Relicensing the GraphQL specification - <AUTHOR> https://medium.com/@leeb/relicensing-the-graphql-specification-e7d07a52301b <comment><USER2> So, wait, let me get this straight:

React has a revokable patent grant, people freak out about it, FB removes the patent grant, everyone rejoices.

GraphQL _doesn 't_ have a patent grant, people freak out about it, FB adds a revokable patent grant, everyone rejoices.

What am I missing?

<comment><USER3> > What am I missing?

That there is a patent actually associated with GraphQL, I believe.

<comment><USER4> the funny thing is, this means that the patent grant previously shipped with react had basically zero relevance to using react (even after a patent dispute).

<comment><USER5> Yes, as was pointed out by the many that continued to use React.

</comment></comment></comment></comment><comment><USER6> I'm not, by any means, a licensing expert but OWFa (the new spec license) has the following termination clause:

> All rights, grants, and promises made by me to you under this Agreement are > terminated if you file, maintain, or voluntarily participate in a lawsuit > against me or any person or entity asserting that its Permitted Uses > infringe any Granted Claims you would have had the right to enforce had you > signed this Agreement, unless that suit was in response to a corresponding > suit first brought against you

Wasn't this the problem with the previous BSD + patents license? Not criticizing by any means, I'm genuinely curious.

<comment><USER7> The "...Granted Claims you would have had the right to enforce..." seems to limit the claim to stuff related to GraphQL.

<comment><USER8> The license is certainly unclear from a layman's perspective.

The text specifically defines "Granted Claims" as "those patent claims that I own or control [...] that are infringed by Permitted Uses." And "I" refers only to the entity granting the patent rights.

So how does "Granted Claims you would have had the right to enforce" make any sense? Does it only apply to co-owners of the patent rights, or something like that?

<comment><USER9> > The license is certainly unclear from a layman's perspective.

If that's your standard then you'll either be using PD or leaving yourself up to your ears in very very risky code. Most laymen won't understand the full legal implications of something as simple as the BSD licence.

</comment></comment></comment></comment><comment><USER10> Great news! This follows on the heels of the relicensing of React, Jest, Flow, and Immutable.js. All MIT licensed now. Thank you, Facebook for taking the high road here and putting developers first.

</comment><comment><USER11> Awesome news, now we can reconsider using GraphQL at GitLab! :) [https://gitlab.com/gitlab-org/gitlab- ce/issues/34754#note_41...](https://gitlab.com/gitlab-org/gitlab- ce/issues/34754#note_41492393)

Out of curiosity, does anyone know of any other specs licensed under OWFa?

<comment> shaded-enmity Some parts of the OCI use the patent-only OWFa: [https://www.opencontainers.org/release- notices/v1-0-0](https://www.opencontainers.org/release-notices/v1-0-0)

</comment></comment><comment><USER12> For previous context and discussion that led to this decision, this is the GraphQL issue to look at: [https://github.com/facebook/graphql/issues/351](https://github.com/facebook/graphql/issues/351)

The original Medium post from an IP attorney is linked in the original issue comment, but I will link it here too as it was a catalyst: [https://email@example.com/using-graphql-why- facebook-n...](https://firstname.lastname@example.com/using-graphql-why-facebook-now- owns-you-3182751028c9)

</comment><comment><USER13> In my opinion this is a lot more important than relicensing React. There are a few libraries that do React's job even better than React. But GraphQL and Relay are a bigger game changer... a 10x improvement compare to the current use of REST for server/client communication.

</comment><comment><USER14> These are all huge wins for Open Source activism! Thanks for listening, Facebook.

</comment><comment><USER15> Are these licensing changes retroactive? If I'm already running Facebook's GraphQL reference implementation, do I have to upgrade to be free of the patent restrictions?

<comment><USER16> Great question. It applies to the variant of the spec as it exists today when the license was applied. Currently found at [http://facebook.github.io/graphql/draft/](http://facebook.github.io/graphql/draft/)

GraphQL's reference implementation (GraphQL.js) intends on not just being a great implementation, but also very closely following the spec, so you're in good shape.

Also, GraphQL.js has had a BSD3+PATENTS license until today, which meant you've always had that patent license. Later today I'll be releasing a version of GraphQL.js that is MIT license instead, understanding that the OWFa1.0 applies to all implementations including the reference implementation.

</comment></comment><comment><USER17> This is a far more important change than the React one, because GraphQL does actually have patents and didn't have a patent grant.

Glad to see it, and learning about the OWFa license :)

<comment><USER18> Won't be surprised if fibers get patented in some sense, but who knows

</comment></comment><comment><USER19> I couldn't be more excited for the recent license adjustments of Facebook's open-source projects. Great work!

</comment><comment><USER20> I was sure GraphQL issue would have a happy resolution, Relay becoming MIT was a nice surprise.

</comment><comment><USER21> I obviously don't know for certain, but I wouldn't be surprised if it was Matt Mullenweg who framed the issue in a way that resonated well enough with Facebook to make them change their approach to licensing so drastically and swiftly...

> I think Facebook's clause is actually clearer than many other approaches > companies could take, and Facebook has been one of the better open source > contributors out there. But we have a lot of problems to tackle, and > convincing the world that Facebook's patent clause is fine isn't ours to > take on. It's their fight.

[https://ma.tt/2017/09/on-react-and-wordpress/](https://ma.tt/2017/09/on- react-and-wordpress/)

That last part summed it up perfectly for me. Facebook may well have been right (and I personally believe they were), but it's their responsibility to prove they're right to the world, not ours.

<comment><USER4> > it's their responsibility to prove they're right to the world, not ours

i agree, to some extent. but it's also irresponsible to say they're wrong without sound reasoning.

</comment></comment><comment><USER22> So react, graphql and flow and some others have been re-licensed. Anyone here has info about changing licenses for reasonml?

</comment><comment><USER23> Does anyone know if GraphQL can be used for a social network competitor to facebook? Or is that still risky?

<comment><USER24> The current license doesn't prevent you from doing that in any way.

</comment></comment><comment><USER25> This will win hearts and minds for Facebook.

<comment><USER26> More like a sigh of relief.

</comment></comment><comment><USER27> excellent news!</comment>