The eigenvector of “Why we moved from language X to language Y”

> but he doesn't count how many of them do not move at all. The whole diagonal of his (sample) transition matrix are actually missing values, but he treats them as zeroes

Great point. It's interesting to think about how exactly this could bias the results -- would it bias it in favor of languages that developers tend to initially not choose for their project?

I do see that as very consistent with C, C++, and Java being up there. For new projects, developers love to choose anything but those, but then they find themselves gravitating towards them when the project gets bigger and practical concerns intrude

Absolutely an error there. If you try to search the literal string "move from swift to Objective-c", Google rejects the precision given there are so few results, and searches only for the words independently. The bulk of results in that case are actually about moving from Objective-C to Swift.

If you search "move from Objective-c to Swift", there are actually enough results that it honors the literal string, yielding far fewer results.

Definitely a major methodology error for pairs with a large asymmetry.

Nonetheless I found the post humorous, and I don't think it was held with the conviction some of the top posts seem to think.

Author here. You are absolutely right. As I mentioned in the notes, I think this matters a bit less than it might seem like (the stationary distribution does not change if you add a diagonal matrix) but clearly some languages will have a higher propensity for people to stay.

I think this flaw is even smaller than the issue of using Google statistics to infer transition probabilities. It's just a shitty proxy, at best.

At the end of the day, there's a lot of assumptions going into this analysis. I hope I didn't make it seem more serious than I meant it to be – it's really just a fun project and kind of a joke not to meant taken seriously.

That being said, I think the conclusions are at least "directionally" correct. They might be off by a factor of 2x or 5x or even 10x, but the stationary distribution exhibits an even bigger spread (multiple orders of magnitude) so I suspect the final ranking is still "roughly" correct (with a very liberal definition of "rough")

I wish more people would read 'Hack and HHVM', written by Owen Yamauchi, formerly a member of Facebook’s core Hack and HHVM teams.

http://shop.oreilly.com/product/0636920037194.do

The hidden lesson for me was that rewriting the code in is not the only option. Another option is to slowly improve the language/runtime itself until you've essentially switched it out underneath the application, which is what happened at Facebook. Meanwhile keep refactoring the code to take advantage. (Granted, this is isn't an option for a small company.)

I work at Facebook and sometimes write www code. When I was interviewing and thought about writing PHP code, I didn't get a warm and cozy feeling, being reminded of terrible PHP code I've seen (and written myself) in the 2000s as a "webdev". Thanks in part to the advances described in the book, the codebase is definitely not like that; it's easily the best large scale codebase I've ever seen (I've seen 3-4).

My thoughts in blog form (written 3 months after I joined):

http://bytepawn.com/hack-hhvm-second-system-effect.html

Author here. Yes you are reading this incorrectly. Look at the contingency table.

objective c to swift: 5216 swift to objective c: 1639

(sorry about the small font size though. had to squint really hard)