This is a huge misconception about functional programming, one that I used to have myself.

With a functional programming language, you can have side effects, you are just forced to be explicit about those side effects with specific language features in specific places.

Basically functional programming requires you to "opt-in" to side effects only where necessary.

Traditional imperative programming requires you to "opt-out" by taking huge steps to enforce immutability, generating mountains of code to accomplish any task because the compiler doesn't help you.

Apple handles the billing, customer service, credit card merchant fees, runs gift card programs, provides a CDN to deliver both the app and downloadable content, and provides access to a captive market.

Paypal or merchant account require you to handle the charging, refunds, paperwork, etc. You also need to find your own addressable market. And run your own gift cards if you want bank-less people or kids to be able to purchase. And setup your own CDN. Depending on the situation you may need to pay commissions to sales people too. You'll be on the hook for currency conversions and setting up with the various banks, government entities, filing the paperwork, etc to make sure you comply with all local business laws in over 100 countries.

Apple is providing a service and 30% is a steal compared to most publishing agreements in the history of the world. They also don't cut side deals with large developers for a lower cut, meaning you and I are on the same level as Amazon and Microsoft. If you think large retailers pay the same merchant fees as the small guys you are badly mistaken. The big guys also have lawyers on staff to deal with filing paperwork and tax forms.

They cover that in the paper and videos. At 40,000 ft equivalent atmospheric pressure, water begins to cavitate or boil inside the siphon, but the momentum of the water pulls the bubbles past the apex before they can stop the flow, resulting in a "waterfall" inside the tube. Slightly lower pressure decreases this effect, slightly higher increases it.

At some point around 41,000 ft equivalent pressure the bubbles form too quickly and touch all sides of the tube at or slightly before the apex, resulting in the flow stopping. However if you then increase the pressure again at a certain point (around 30,000 ft IIRC) the flow resumes. They discuss attempting the experiment in the future with an ionic liquid that won't vaporize.

If you think about it, this is the same phenomenon as the ball chain flowing out of a container (https://www.youtube.com/watch?v=_dQJBBklpQQ). Gravity pulls on the first ball, which pulls on the next, which pulls on the next. As soon as that pull is strong enough to lift the chain from the surface to the apex, a siphon effect begins that will empty the entire container.

IANAP, but it appears that water siphons work the same way. Once enough water flows over the apex sufficient that the force of gravity on that water exceeds the weight of the water prior to the apex the siphon will flow. The big tell-tale sign that any explanation involving the air pushing down on the surface of the liquid is wrong is the flow rate - it is almost completely independent of atmospheric pressure.

The one question I still have is why the flow stops at 41,000 ft. I would have expected a kind of spring effect, followed by the lower portion of the siphon slowly descending as water vaporizes off the pre-apex portion, allowing the water in the lower part to descend while maintaining the same vapor pressure. I'm sure it is my failure to understand, so if anyone can offer a better explanation please do so!

Translation of GitHub's weasel words: "Our lawyers told us not to admit to anything or we could be liable in a lawsuit. The company we hired to tell us we aren't liable in a lawsuit told us we aren't liable in a lawsuit."

Maybe Horvath isn't entirely in the right here but it is clear that the co-founder must have intimidated her as she claimed and/or let his wife (a non-employee) run amok. GitHub even admitted as much when the original story broke and re-banned his wife from the building. GitHub's legaleze non-statement doesn't address this at all.

The anonymous medium post is being given far more credence than it deserves because it fits the narrative people want to have about the story. Just be honest... You want the truth to be that Horvath somehow did wrong and brought this on herself because the alternative is that a fun cool company that has good technology also did a bad thing.

Let us not forget that Horvath did not bring any of this up in the first place - she simply quit. It was an anonymous person (that was suspected of being the founder's wife at the time) who posted about it, thus eliciting a reply from Horvath.

Again, according to Horvath, the supposed "investigators" never bothered to contact her until a day or two before wrapping up the "investigation". It seems very clear GitHub hired them to obtain a foregone conclusion.

I don't see how any of this is shocking. It is 100% believable (and by Occam's razor probably true) that the founder's wife was allowed to run around like she owned the place, got into a conflict with Horvath, then when it blew up Preston-Werner jumped to his wife's defense (understandable) without thinking about the implications of allowing your non-employee relative to even put you in that kind of situation to begin with; he certainly didn't consider what it would be like for an employee to be cornered by a co-founder over it. Then when it became public, they called the lawyers, circled the wagons, etc. I also would be shocked if some of the anonymous stories are by GitHubbers who are just repeating internal rumors and rising to defend the company they like, without any actual direct knowledge of what happened.

While you are technically correct, the reality is that the most serious security vulnerabilities are almost all directly related to buffer overruns (on read or write), allowing an attacker to read or write arbitrary memory. Everything else is a second-class citizen by comparison; denying service by causing Apache to repeatedly crash is far lower priority than compromising all traffic and stealing credentials.

So when we look at that class of serious problems, we find that managed memory languages completely eliminate them.

Relying on people to "just drive better" is an automatic failure. We design everything from signs/road markings to cars themselves around the idea that relying on humans to be perfect is pure idiocy, so we need to create affordances that lower cognitive load, along with automatic systems that attempt to avoid collisions and mitigate their consequences when they occur.

Similarly, just relying on programmers to never make mistakes is guaranteed to lead to more exploits like Heartbleed. It's pure stupidity.

If OpenSSL were written in Rust or C#, it wouldn't be quite as fast, but we wouldn't be looking at years of government spies completely negating SSL, forcing all webservers on the *entire* internet to replace their SSL keys, instantly obsoleting hardware that can't be upgraded, exposing user's data (including login credentials) to attackers thus requiring EVERY FUCKING USER ON THE INTERNET TO CHANGE THEIR PASSWORDS.

Was the tiny performance benefit worth what we have now paid for it?

Of course we're going to continue using C and getting burned over and over and over. Who needs air bags? Just drive better.

Yet again, C's non-existent bounds checking and completely unprotected memory access lets an attacker compromise the system with data.

But hey, it's faster.

Despite car companies complaining loudly that if people just drove better there would be no accidents, laws were eventually changed to require seatbelts and airbags because humans are humans and accidents are inevitable.

Because C makes it trivially easy to stomp all over memory we are guaranteed that even the best programmers using the best practices and tools will still churn out the occasional buffer overflow, information disclosure, stack smash, or etc.

Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory. Singularity proved that was perfectly workable. I don't care if the language is C#, Rust, or whatever else. How many more times do we have to get burned before we make the move?

As long as all our personal information relies on really smart people who never make mistakes, we're doomed.

Eich was not fired. He chose to resign. Maybe he did so because he cares about the foundation and didn't want to be a distraction. Maybe he was told he'd better resign or they would lose their funding and have to lay everyone off. We don't know, but the insinuations of the original story are out of line for implying so. The truth is we just don't know.

This isn't some free speech issue or some form of inquisition trying to purge the unbelievers.

Eich chose to wade into a controversial issue by making political donations (after all, a conservative majority of SCOTUS claims money == speech). Those "free speech" statements offended a bunch of people and he chose to resign rather than drag the non-profit Mozilla foundation through an ordeal over it.

Anyone in a leadership position is certainly free to make any statements or support any political cause they want. Employees, customers/donors, etc are also free to loudly complain or refuse to associate with the organization if they disagree. That comes with the territory. We wouldn't give Eich a pass if he were sending checks to neo-Nazi organizations. A leader always takes a risk that they'll piss people off by taking a stance. He was CTO of Mozilla at the time, he knew what the consequences could be and made the donation anyway.

A few decades ago it was accepted that blacks and whites shouldn't intermarry. Even some people who campaigned for civil rights still held such a view. If Eich were donating to a group promoting a constitutional amendment to outlaw interracial marriages almost none of you would be wringing your hands over free speech. Everyone would laugh at him for being a dumbass and move on with their lives.

Freedom of speech is not freedom from consequences. Even if someone faces no offical sanctions for speaking out, they can certainly be excluded socially, even to the point of being driven out of the organization. That's how human group dynamics have always worked since we were grunting at each other and throwing pointy sticks.

Furthermore, technology has always been intertwined with personalities, politics, and the like. Only very rarely is it always 100% about the pure technology. You can write the best code in the world but if you can't play nice with others you run the risk of your code languishing in obscurity.

Social norms are changing; you can change with them, you can keep your mouth shut about it, or you can fight for the status quo. Each of those courses of action has risk associated with them. Eich chose to fight for the status quo, then chose to stick by his guns when it pissed a lot of people off, including a lot of the very people his organization depends on to contribute money and code from their own good will! That has consequences and it always has.

Linus is generally fair from what I can tell, and does not except himself from criticism. In that very thread:

Someone proposed a better idea and Linus immediately admits his idea was worse and moves on. That was also one of Steve Jobs' greatest talents, even though it's in a completely different sphere. He originally said "no" to iPods for Windows and the iOS app store. People presented their case and he changed his mind.

We should all be so willing to admit when someone else has a better idea or we were wrong.

They also open-sourced their new C# compiler:

http://roslyn.codeplex.com/

Ah, the arguments of the willfully ignorant. I wish I were still a conservative. No nuances, no questions. Everything had a trite simple answer.

Reality does not so neatly fit into a box.

House fires happen rapidly. They are also largely preventable. And even though one person's house fire may be a tragedy, pouring water on it puts out the fire. (Remember kids: the fire department exists to prevent your house fire from burning down the rest of the city, not to save your house)

Mudslides, like earthquakes, are triggered by complex conditions that are not knowable by humans in advance (with any degree of certainty). They also cannot be prevented or controlled. There is no "Mudslide Department" because there is no response. By the time you find out about it, the mudslide is over and the damage is done.

This case is very simple to explain: no one wants to be the person who "wastes" taxpayer dollars buying out homeowners and tearing down houses when the potential disaster can strike anywhere between tomorrow and 50 years from now. So county officials, housing developers, and maybe to some degree homeowners all chose to ignore the report and get on with their lives. That works great, right up until the moment when everyone died.

Correct. The huge, gaping security flaw with Android is the same one that afflicted ActiveX in Internet Explorer: Assuming that the majority of users
a) have a clue what any of the permissions actually mean
b) can trust the app not to abuse the permissions it has (or contain flaws that allow it to be hijacked)

The reality is that 100% (rounding up from normal people to geeks) of people simply tap accept, click OK, etc and move on with their lives. Those annoying dialogs are just how you use phones/computers. They've learned if they choose Cancel they don't get the game/app they wanted, so the correct course of action is to always accept.

Any security decision that relies on users to take the correct course of action is an automatic failure. If making the wrong choice results in being pwned, having a $10/mo premium SMS subscription added to your bill, etc then the system is badly designed and broken.

The article didn't make this terribly clear, but people seem to be missing the point.

If you teach the concepts through hands-on interactive play, kids as young as five can understand the concepts underlying Calculus without too much difficulty. This also happens to be one of the best times in your life for learning, when the brain is rapidly forming new connections.

Her point is teach the concepts, teach the patterns, teach kids how to find patterns, and how to internalize mathematical knowledge.

The mechanical drudgery of formal language, writing out and solving equations, etc comes later on but builds on the fundamental understanding developed much earlier in life.

There have always been holes in the App Store and sometimes you can sneak things through.

The difference is if you try such things and you app becomes even remotely popular, Apple can pull your app and even your developer account so the actual window where your fraud or evil tricks can result in some kind of gain is very small.

I'm not sure why people constantly fail to recognize this.

Similarly with the SSL flaw... Apple pushes iOS updates in a way Android users can only dream of; within a month more than 90% of all iOS devices still in use will have the patch applied. Compare that with the web view remotely exploitable hole just revealed for Android... at least half of all Android devices will still have that hole a year from now!

So in theory yes, Apple is just the same as everyone else. In reality, the actual user experience will be quite different.

In order to regulate credit card companies and banks, the CFPB needs to know what is happening with these financial products.

It would appear that the banks' astroturf campaign is in full swing trying to get people riled up.

I may be misunderstanding, but it appears that the existing contractors are using old-school waterfall. Gee, government contractors using a heavily-specs-oriented approach, when has that gone wrong?

The new idea seems to be having a team of smaller players use an agile approach to deliver the real system.

Any time you can get a group of smaller developers doing rapid iterations with the government it's a miracle... It is also vastly more likely to deliver something decent and on-budget.

Anytime I see HP, IBM, Agilent, et al winning a contract for some government system I automatically assume it will be an epic fail.