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.
I think the distribution of ride lengths might partially have something to do with the nature of cab hails in NYC vs. other cities. I travel a lot, and in most cities, uber is my go-to cab service, because I don't know the local cab system, I might have to call multiple companies, I can't street hail in a lot of places, etc.
However, in NYC, it's often faster to street hail a yellow cab for short trips than it is to wait for an uber. So here, I mostly use uber for long trips (airports, midtown to the financial district, brooklyn, etc.) or for time-sensitive situations.
I see 6 month chargebacks on a regular basis (dealing with consumer fraud is fun), so these definitely happen, they're possible and if consumers can do it when they are the ones defrauding the merchants there will be a lot less trouble when it is the merchant doing the defrauding.
In many cases the cc company debiting your checking account is automated and there is no step for you to verify other than to periodically go through your statements to see if you have taken on any ghost charges.
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.
The underlying problem is that SMTP only has a few error codes, and so there is no way the MUA can understand (in a standard way) why the MTA rejected the message. HTTP ended up having richer errors, and so clients can provide nice messages if they feel like it. (IE does this for 404s and 500s, though it's not a nice message and it seems to upset most web developers.)
SMTP MTAs can also "provide more info if it wants", but that's what the article considers a problem. What the author of the article wants is a way to dumb down error messages (or, less cynically, automatically correct errors), which is not easy with free-form responses. Imagine a web page that returns a page that says "404 Not found" with a 200 status code. Brokenness ensues.
It is that bad. Email works and gets stuff done, yes, but at the expense of your time, server time, storage, network throughput. It is used for much more than it should, and is long past its expiration date. Sadly, we've all come to depend so much on email and how it works today that changing it would be like suddenly having to breathe underwater. It'll take a load of time to get used to whatever comes next.
Okay, email works at the expense of my time, server time, storage and network throughput. So what's your brilliant e-mail replacement? Heck, pg himself has talked about these very same issues and has noted that YCombinator would jump at funding any startup that came up with a credible replacement to e-mail.
E-mail is like democracy. It's the worst messaging system, except for all the others.
Actually, the underlying system is absolutely putrid, a sentiment that pg agrees with based on his latest talk at PyCon. Mail is, unequivocally, the worst part of my daily existence and you are kidding yourself if you're calling it "not that bad".
Using pg's words, mail is a to-do list that anybody can put shit on, and I don't have any control over who puts things on it. We live in an era of technology that can do e-mail so much better, and replacing it must happen in my lifetime. Everything, from the architecture to the messages themselves, need an overhaul. The extraneous shit we bolt on to e-mail (SPF, DKIM, PGP)...it's just making it a big, unwieldy mess.
> mail is a to-do list that anybody can put shit on, and I don't have any control over who puts things on it
That's a misuse of email on the receipient's side, not on the system's side. Email is about messages, not about tasks. Although there might be more comfortable (i.e., more automatic) ways, there's nothing wrong with maintaining a TODO list that is 100% separate from the INBOX.
For example, in my TODO list I describe shortly (and in my own words) what I consider to be important. Why should I waste my time scanning through the INBOX everytime I want to check what needs to be done?
In other words: It's me who decides what gets on my TODO list, nobody else! I'm in total control because I'm a free citizen living in a democracy, and as such it's my responsibility to organize my life. In particular, to decide what to do (to-do) in my life.
If you decide to give other people access to your TODO list (e.g. by defining your INBOX to be your TODO list), you're voluntarily giving up control of an important part of your life. Nobody forces you to do that. In fact, almost every organization guideline strongly advises against that kind of nonsense. (The most famous one being the "Inbox zero" series at http://www.43folders.com/izero)
Email isn’t the problem, the problem is the client. Here’s just a few of the things we use email for today:
Todo list
Social networking notifications
Text messaging
Planning meetings
Planning vacation
Discussing issues with colleagues (mailing list)
Bill notifications
Newsletters / grey mail
File sharing
We do all of those different things and shove them into a single client that was designed (with minor alterations) over 30 years ago. What were they using email for then? To send “holy shit, this is cool!” messages to other neckbeards.
We should be using a separate client for all of these uses. Email is nothing more than a messaging protocol. You could launch a group texting app and use email as the delivery protocol. Your user base would instantly be every person with an internet connection. It wouldn’t matter that person A has your app and person B doesn’t, you could make it transparent to the person that has the app and pitch to the person that doesn’t.
The biggest obstacle to this is that we all use regular old email clients today and increasing the already incredible noise would not be without backlash. I think you have to start out with apps that don’t require adding to your message count (a notification app that scrapes your inbox, for example).
Meanwhile startups are trying and failing to make every service its own silo that travels over port 80. This is what is most sickening about startup culture today, no one is creative about using the stuff that has been around forever and is used by everyone.
> mail is a to-do list that anybody can put shit on, and I don't have any control over who puts things on it.
If that's your complaint, then your beef isn't with email in particular, but with the mailbox paradigm in general. But I for one find that paradigm useful, and I respectfully disagree.
(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)
Most completely non technical people will ask the advise of a friend/family member in order to make a computer purchase even if they don't know anybody they will ask a shop attendant to advise, these people will then interpret the specs on their behalf.
The reason that specs don't seem to be so important in the tablet world so far is that there really aren't many to choose from and in many cases people simply want an ipad in which case there are really only 2 to choose from and they are basically the same anyway.
"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.
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.