Everyone has a cognitive limit on what they can keep track of/in working memory. Once your codebase exceeds that limit (in # of files, lines of codes, types, interfaces, etc.) you lose productivity. 10k lines of python is a lot harder to grasp than 10k lines of go.
And that's not even considering the ramp up time for someone new to the code to jump in, which is even worse in most dynamic language codebases.
Not taking surge pricing into account probably plays a large role in explaining this article's findings.
Another thing to note in his section with self driving cars: the pool of cars would be fixed in that case, but the amount of uber drivers fluctuates throughout the day. Now, uber doesn't really care if drivers are 70% utilized or 50% utilized, as their revenue doesn't depend on that, but they do have an interest in keeping the drivers marginally satisfied
Also I don't have the numbers but at least in SF, taking an uber to the airport is much cheaper than taking a cab ($25 vs 50 from my office, last I checked), so I could imagine that something like that skews the distribution of ride lengths.
Yes, the email system could be better. But for something that was designed decades ago it works surprisingly well.
Should somebody try to do some smart parsing of failure notifications to make them more readable? Sure, I don't see why not. But don't pitch the baby out with the bathwater here. The underlying system is not that bad.
(Disclosure: FB employee, but nowhere near the photos/locations teams, just personal experience)
In all likelihood, there's no magic. Its just comparing 'dumb' manual album labels with places pages and trying to match them up.
I've had similar experiences with the location-suggestion feature where I was totally bewildered by how it was getting the data to recognize the locations. As it turns out, all of the albums they've done this for were pre-location tagging and so I'd manually put in a location (like 'Bowery Ballroom'). So there wasn't any particular magic in how they seem to be doing it. This would also explain one of the other comments on here about the location suggestions being England, Arkansas (if she just labeled the album England and the location suggester goofed). I also had it goof when I had an album labeled "Rhode Island and Massachusetts" and it tried to suggest a real estate agency with that in its name.
One of the other annoyances we had (I think its addressed in the note?) is that until now the interpreter (on our dev machines) and the compiler (hphpc in production) occasionally differ in small, occasionally painful ways. Unifying our development and production environments will eliminate another potential source of bugs.
Also: Tight loops don't imply a lack of understanding. Often times when you're trying to get the CSS on a page just right (across all browsers) it requires quick iteration, even if you do understand CSS well.
While I agree with you, I think the article was talking about the nontechnical consumers, the ones who don't understand what mhz and gigabytes mean, they just want a computer that does what they want it to do (yes, I'm being intentionally vague here).
That said, I'd like to think that most people/kids under the age of 20 or so have much better grasps on a computers technical specs, at least comparable to how most people are familiar with the relevant specifications on a car (HP, torque, fuel efficiency, etc)
"This almost sounds like a spiritual leader declaring a jihad on Android as his dying wish"
What the hell? Beyond the fact that this is one small part of a book (not the same as him saying it on video or written by himself on a website), there's no way the average joe is going to have his purchasing decision swayed by the opinions of Steve Jobs. Everyone who would already has (or is planning on procuring) an iPhone.
Correct. I thought that was in my profile info (it wasn't has since been updated). That said, I was going out of my way to make my comment as general purpose as possible (I think evaluating the bias of anything you read on the internet is generally a Good Idea(tm) )
So, I'm going to make a statement that I think is important for anyone reading anything on the internet.
WHAT IS THE PROOF! (also known as 'consider the author', 'read the article', etc)
Now I can't say with certainty that any of these claims are false or true, but it occurs to me that a lot of these claims are based on what facebook MIGHT be doing with your data. I decided to take a look at the complaint and attachments for the shadow profiles case, I don't see any evidence that these shadow profiles exist, just that there is the possibility that they exist.
And for those that will inevitably say that proof isn't necessary, that means you don't trust facebook. If thats the case, there is nothing they can do to prove to you what they're doing is legitimate short of open sourcing their entire stack (and even then, you must trust that what they're running == the source they give you). So either trust that what they're saying is true, find evidence that they're doing something they aren't supposed to, or stop using the service entirely.
afaik, facebook does not use flash cookies. In the initial blog post that caused the cookie uproar, I thought he mentioned that? Otherwise maybe it was somewhere else I read it.
Source? That doesnt sound like an unreasonable number, but I'm dubious of articles like this (site I've never been to before, obvious bias, lack of source).
That may be true, but even if it is, it isn't sharing this activity with your friends, that would be facebook doing exactly what google does with their analytics platform/js.
I don't get the freakout people have over fb potentially tracking you through something you can see (the like button) vs google doing it everywhere with something you can't (the analytics js)
I had a friend mention this to me before I wrote this, and it does seem pretty neat.
That said, I think it's big shortcoming to me (havent spent much time with it, spent ~10 minutes going through some of the demos) is that its a functional language. Personally, I don't mind haskell/sml/their ilk, but since I was trying to conceive of a language that people would actually use/adopt, it needs to be imperative and probably resemble something along the lines of C/php/python.
Perhaps? It's unclear that a JIT with type inference will give you better performance than compiling (especially if you were to do profile guided optimization) (sidethought: not sure if llvm has support for PGO).
Also, if most of your types are static anyway (which in my middling amount of experience, they tend to be), I personally would rather get compile time errors rather than runtime errors. But maybe thats just me.
Right on. I'm not sure I'd go so far as wanting the language to be as strict/typesafe as those (also calling Haskell an ML derivative is kind of funny, but I know what you mean)
So, like I said in the post (but perhaps didn't make clear enough) is that there are plenty of options for when scaling isn't too much of an issue. But you take a look at Twitter (Ruby/rails and now scala, I think? which kinda goes towards my point) and facebook (hacked up php and made it compile). My thoughts were focused on a language that you could start something small in (aka easy enough to use), but that could scale up reasonably well.
Everyone has a cognitive limit on what they can keep track of/in working memory. Once your codebase exceeds that limit (in # of files, lines of codes, types, interfaces, etc.) you lose productivity. 10k lines of python is a lot harder to grasp than 10k lines of go.
And that's not even considering the ramp up time for someone new to the code to jump in, which is even worse in most dynamic language codebases.