sirclueless

Yes there are, and many of them will block all of your email if you run your own server...

Or did you mean "good for independent email operators"?

I suspect, though I have no way of knowing, that she has been thoroughly disabused of any Google-exceptionalism she may have harbored at one point. Remember this was from 2010. Google Reader was 3 years from being discontinued, Google's motto was still "Don't be evil," Buzz was an experiment that people still took seriously. The rose-colored glasses were firmly affixed to many intelligent faces, and it's hard to fault her for hoping something was intrinsically different about the company and its culture.

I'm very curious whether she still thinks and hopes the same things about Google that she did then.

Yes, she is a truly excellent writer.

I went digging into a Buzz post about the Boston startup scene that Piaw referenced, and could only find a crufty unstyled version in the Internet Archive. If you can forgive the formatting, it's still excellent reading: https://web.archive.org/web/20100613173203/http://www.google...

Who is "Rebecca"? I agree with 90% of her statements, and she appears in this conversation to have further ambitions of continuing with the ideas and convincing some powerful people, especially Paul Krugman, of their validity.

Did she ever succeed? Did she write her thoughts in a more digestible format and make those writings public? Does she have further commentary on her thesis on the capitalist or non-capitalist tendencies of modern software companies, or on other topics?

Mostly I'd just love to read more of her writing, if it exists.

Edit: I believe she is Rebecca Frankel, according to http://danluu.com/programming-blogs/#rebecca-frankel. Still interested in any pointers to more of her writing if it exists.

It probably seems like a bad thing to the customer paying for internet, and since they're the one paying for service they do get some say in the matter.

Which do you think costs Comcast more? Temporarily disabling 20,000 customers' internet connections, or forcing Akamai to drop Brian Krebs as a customer?

Right, the question is which direction you are going when you hit 1080p. Are you going down from 4k? Or up from 720p.

In context, it's likely they mean "1080p [or higher]", but it's arguably ambiguous.

Security is not "magical," no. In fact it's barely even a "property of software." Instead it's a property of a system. Some of the elements of this system are software. We can perhaps make some guarantees about the properties of this software, but these alone do not make the system secure (systems that are provably secure end-to-end are vanishingly rare, if they exist at all). Part of the system is configuration and data. What cryptographic keys and other systems do you trust, and how do you guarantee that trust? Part of the system is human process -- when a customer calls support, does someone give up private information or allow passwords to be reset? If the government knocks on the door of your cloud hosting provider, will they cooperate freely? When your linux distro announces a security issue to a trusted list ahead of a public announcement, do you have someone on that list ready to respond to the issue before your server is hit by a 0-day?

There's a lot that goes into making a secure system. And there is considerable economy of scale -- a large company can afford to have 24/7 monitoring and issue escalation processes. You cannot.

    for the most part it feels like TV shows don't have
    that pressure to fit into a very tight box.

Don't they? I feel like TV is a lot more constrained than movies. The forced "last time on XYZ" cadence means that it's very difficult to have natural story-lines when things need to be wrapped up in a suitable emotional resolution and/or cliffhanger every 22 or 45 minutes. Especially when the writers are working with 25% of the screen time being commercials (thankfully much less of a problem with Digital-first TV from Netflix, HBO etc.).

I think it's a lot easier to write and produce a quality movie about just about anything. Yes the mass-produced sequel machines look pretty cookie cutter, but you also get some extremely well-told stories like In Bruges or Wes Anderson's stuff. There's anything-goes stuff like Swiss Army Man. I feel like this kind of thing couldn't realistically be produced for TV. The acting, writing, and production value falls off a cliff very quickly as soon as you leave the mainstream. Even a single season of a TV show means 6-10x as much content as a movie, and consistently conforming to the structure of a serial TV show means the content feels inevitably more repetitious.

If by "trying too hard," you mean "researched something over the course of several months instead of paraphrasing an AP or Reuters blurb," then yes I agree. And the world needs more of it.

There's actually a lot of overlap. See Nauru (2, 10), Sierra Leone (1, 14), Uruguay (9, 13) etc.

It's interesting, I think both of these metrics reward largely the same thing, independent of actual approximate shape, which is a lack of irregularity in their borders and many degrees of symmetry.

Yes, but you are only looking at regular N-gons, while the person you are responding to is considering all polygons.

Square countries are relatively close to being circular compared to the many highly irregular countries out there, not compared to other regular N-gons.

Adjusting to the inability to focus is different from learning to focus. Like the jellyfish who can't orient themselves properly if they were born in zero gravity [1].

http://www.businessinsider.com/space-born-animals-adjust-to-...

I write a lot of these tests in my code as well. They are not exactly unit tests, because they test code at multiple levels of abstraction at once, but they are written in exactly the same way as a unit test and are intended for the same purpose: to make sure that some unit of your code functions as it should and does not stop functioning.

To me, mocks are useful for one thing only: there is some expensive or flaky dependency of your code that you may have poor visibility into, and you want to write a test that does not rely on its availability. Mocks for databases, file systems, REST APIs, externally maintained libraries, etc. all make sense to me. But if some library is developed locally (or in the extreme case, by you) and you can easily depend on its existence and stability, then I see no reason not to write code that depends on that library and test against that library. This is a testing strategy for a pragmatist, not a purist.

Go in particular makes it easy to separate a single codebase into separate logical packages, and if you do so, it often makes sense to test them together. That's why this is a pretty Go-specific issue.

> Expecting to be able to look at a code sample in isolation and know what it does is unrealistic for any large-scale system.

My number one favorite thing about Go: you can look at a code sample in isolation in a large-scale system and know what it does.

Why? Every identifier is either lexically scoped or lives in a module. There are about 6 control structures and they all do what they look like they do. Operators are all defined over a small set of well-defined primitives, they can't be overridden. Closures, callbacks, and non-linear control flow are rare and obvious. There is no way for code to be skipped by exceptional control flow apart from the single escape hatch called panic().

It's really like no other language I've ever coded in. You can work in large codebases that are as clear as your average Go code, if you have strong guidance about what kinds of code complexity are acceptable and you are ever-vigilant about avoiding language pitfalls, but nothing is quite as freeing as knowing for a fact you will be able to parse someone else's code because there wasn't any way for them to write something you can't understand.

The really hairy stuff is usually not the first-party proprietary stuff (e.g. "This stuff is so important to our business we need to keep an exclusive license.") It's usually possible to make an argument to the right business-person that the cost is not so high when compared with the extra brand goodwill and free maintenance.

Rather it's the third-party proprietary stuff. Someone else owns proprietary code you deeply rely on but doesn't share any of your business goals and needs. And when dealing with hardware, there is a whole raft of firmware and drivers that could be licensed this way.

Ahh, but this time around we have porn: http://www.theverge.com/2016/3/23/11290610/pornhub-vr-free-p...

The problem is that "governance by ordinary people" is not really on the table as an option. Governance by popular vote might be, but given how short-sighted and easily swayed the average loosely aware citizen is, the result is more likely to be "governance by demagogues and whoever has the most advertising dollars".

> ... if Google were "perfect", advertising wouldn't work, because it would always find exactly what you were looking for exactly when you needed it.

Advertising will always work so long as there is producer surplus[1] in the economy. If firm A and firm B both earn $10 of economic surplus on the purchase of some product, then either supplier will be willing to spend up to $10 to convince a customer to switch from their competitor to their product. If a customer considers the two firms' products to be substitute goods[2], then both products may be "perfect" search results, because the customer doesn't have a preference between them and considers them both to be equivalently useful, which is why Google can extract money from advertisers to show their product first without significantly harming their user experience.

[1]: https://en.wikipedia.org/wiki/Economic_surplus [2]: https://en.wikipedia.org/wiki/Substitute_good

This wasn't a public statement. It was an email to colleagues.

"Let's not comment" is, I think, the default position of PR departments everywhere on everything unless there is a crisis or a marketing campaign going on. Throwing fuel on a fire isn't wise unless you want there to be a fire.

> I found this to be disappointing. More concerned about their brand image than trying to push robotics research forward.

This is a director of communications we are talking about. Literally the beginning, middle, and end of her job description is "Consider our brand image." If she sounds overly concerned about Google X's brand image, that's because it's her job. Google pays her so that the rest of their employees don't have to be so concerned.

Basically every company on the planet with more than 20 people in it has someone making strategic decisions like this. The only difference here is we have a whistleblower reporting what she says internally. There's just about zero to learn about Google's priorities from her priorities, except that none of her immediate superiors is banging the drum for a PR battle over DoD robots.

Any of the VM languages could probably do this heuristically as well: the "if size == 1" base case depends only on one of the parameters, you could hoist that out of the concurrent thread/coroutine and into the caller. Then the code path that hits only ever assigns to a future/promise/array/whatever and immediately returns so it won't block and has no other side effects so it can run synchronously for less than the cost of a context switch.

In general programmers are pretty good about not kicking off expensive computations they don't need to, so the easy pickings here are probably pretty small. And as soon as there are any side effects at all (which includes any writes to shared memory) it becomes very hard to reason about moving computation from one thread to another. So it's easy to see why compiler writers are not super excited to start optimizing across concurrent threads.

Yes, goroutines are a concurrency mechanism. Actors are also a concurrency mechanism, so I fail to see why the comparison is unfair. As you say, Actors are safer in that uncaught exceptions in an actor will not bring down a program. They have a few more dials and knobs, you can store references to them, and they are more heavyweight. They have more overhead as can be expected from these facts and this is exhibited in benchmarks like this one.

Futures are not a concurrency mechanism precisely. They are a monadic data structure around possibly-concurrent execution. You can wrap a Future around concurrent execution by an Actor, or you can do what you have done and wrap a Future around a sequential recursive computation. As with the synchronous .NET core implementation of the benchmark, the performance is better due to not having the overhead of Actors or other concurrency. Like the synchronous .NET core implementation writing the computation this way is not a fair comparison to the other languages in the benchmark and the high performance does not indicate anything about the efficiency of the concurrency mechanisms available in Scala.

No it will not, and can not.

"c <- num" is a blocking statement. Since c is an unbuffered channel, execution cannot proceed past the statement until a reader consumes a value. The reader in this case creates 10 goroutines executing "c <- num" and only then starts consuming values. If the statements you wrote were inlined execution would immediately halt in a deadlock.

This is a silly argument. If I read you right, you are saying that a goroutine is closer to a promise/future than a Scala actor in terms of resources used, and therefore it's OK to use futures instead of actors in the Scala code and compare them that way.

That betrays the whole benchmark. The basic point of the benchmark is to answer the question, "How expensive is it to create and run 1,111,111 actors in various languages?" You can't make a manual optimization that causes only 111,111 actors to be created and then say that it's a better comparison.

The goroutine is actually in a separate concurrently executing computation. The "go skynet()" call from the Go example is a real concurrent call that will block on the "c <- xyz" lines and resume execution when a reader consumes the value. Calling Future.successful is not the same thing.

I particularly like the reasoning they use to determine that N > 1/54 for involuntarily committing people in California.

http://www2.law.ucla.edu/volokh/guilty.htm#T187 http://www2.law.ucla.edu/volokh/guilty.htm#187

This is addressed somewhat in the essay. For example, it mentions that God and Roman emperor Trajan limit the maxim to capital punishment, but Blackstone considers his version to apply to all forms of punishment.

http://www2.law.ucla.edu/volokh/guilty.htm#T37

Ahh, but does git-svn-cvs-rcs do this? It's worth remembering that there were still 15 years to go from when this code was commented out to when SVN was invented.

And for that matter, does burguggle-git-svn keep SVN revisions traceable? Or are we assuming git is the pinnacle of software revision control and emacs would never ever change again.

> Yea sure, those terms were used by Westerners in 1761. I bet the Africans would have seen it differently.

Why do you suppose the Africans would see it differently? They were in fact confined to belowdecks in anticipation of being sold into slavery by white men. Do you think they weren't cognizant of this? Do you think they would have rejected the institution of slavery on the basis that they were getting the short end of the stick? Slavery exists to this day and is generally recognized where it is seen. Attitudes towards it vary, but it's not a matter of belief or conjecture.

> Nevertheless, it is our duty to correct the terms they used to better reflect the reality. And this is common practice. If it weren't, Socrates would be remembered as a corrupter of the youth and Galileo as a heretic.

Socrates is remembered as an instigator of rebellion, and Galileo as a heretic in the eyes of the church. As it so happens, predominant Western culture cares much more about Socrates' other contributions to culture than his relationship with Athenian politics, and regards heresy as something of an unreasonable charge.

I really fail to see what the big deal is. Certainly attitudes towards slavery have changed dramatically over the years. Much as attitudes towards many historical facts of life have changed. That doesn't make them cease to be facts. Are you objecting to the article's use of "free men" and "slaves" as primary identifiers? The point of the article appears to be primarily about race and the institution of slavery, when in isolation shipwrecked on an island. The labels are not false, neither are they inappropriate in a historical context.

Go has an interesting take on whitespace-around-operators -- it starts removing whitespace around binary operators if there are higher precedence operators in the same expression. So, for example, you get:

    x = 2 * y
    x = 2*y + 5

This is pretty readable. In fact I think it is more readable than the usual convention of "spaces around every binary operator," but it would be untenable without the existence of gofmt. The most common argument against a convention like this is, "subtle bugs will be introduced if the actual precedence is different than the one implied by whitespace," which is why it's great to have a benevolent formatting overlord telling you when or not your formatting is consistent.