I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people.
With physical messages, unsending has at least partial support. Before the mailman picks up from my porch, I can grab a sent message any time. If you FedEx the envelope, you can cancel before delivery. With a university's mail system, you can get the receiving department's admin to return something even later in the chain. And of course, you can always tell a recipient, "Hey, I sent you the wrong box, just send that back."
The reason email doesn't support unsending is not some essential property of messaging. It's just that at the time our email protocol was defined, both our hardware and software was pretty primitive, so we locked in a very primitive model of messaging. But note that more modern systems, like Slack and Facebook Messenger, happily let you unsend things. And consequently, they're effectively replacing email for most users.
I think you're twisting the problem statement a little here.
Asking "How do I unsend an email" is just as unreasonable as asking "Hey, give me that gift I gave you back".
The problem is that, regardless of your intent, you've given something to someone and they own it now.
You can't undo that without involving the 3rd party (Or breaking the law and stealing it, digitally for the email).
And I want to be clear upfront - THIS IS A GOOD THING.
I don't want Amazon to be able to "unsend" my receipts. I don't want Google to be able to "unsend" my support chat log. I don't want my boss to be able to "unsend" his approval for my time off.
This system is designed explicitly to put the USER first. But it treats each side of the exchange as user, and values them equally - If they disagree, it's not the system's job to resolve that, they have to talk it out.
Slack and Messenger (and a lot of other modern chat) have an arbiter - They don't require users to agree because they own the content, not the users. In a company slack, I haven't given you anything when I message you. I've just pinned something to the company message board. I can take it down, and so can anyone else who has the key. It's not mine and it's not yours - It is very clearly owned by the company.
That can work great in a well structured environment, but I have to laugh when you say its replacing email. It's not a replacement, it's a complement - They are not the same things.
Just like an oral promise with no witnesses is NOT the same as a signed receipt. Use each as needed.
I think you're missing the forest for the trees here. The point of version control systems is to make developing software easier. It's a tool that exists for the convenience of its users. It's reasonable for people developing software to ask for the ability undo a change or restore a repository to the way it was a second ago. Telling a team of people using Git "it doesn't work like that" is unhelpful because it's not impossible for a version control system to work like that and the point of any software is to help them do what they're trying to do.
This doesn't mean that Git has to accept any feature under the sun and it might be that Git isn't most appropriate tool for teams that want such a feature. But there's nothing holy or fundamental about an implementation detail of how Git does things that makes their use-case hard.
> But there's nothing holy or fundamental about an implementation detail of how Git does things that makes their use-case hard.
Yes, yes there is.
I've worked in systems like you're describing (CVS, SVN) - The problem is that they ALL require locking.
Locking freaking sucks. It sucks SO INCREDIBLY MUCH more than dealing with the complexity of a real distributed system that git won, even though its cli interface is a god-damned nightmare.
You clearly haven't had a co-worker lock a file you need to edit and then go on vacation.
VCS exist to make it possible to organize and track changes to project source code. Convenience of the user is a secondary goal to clear organization and code management.
A VCS shouldn't be unnecessarily difficult to use, but the fact that this conversation around Git's UX is endlessly rehashed is proof that version control is a hard problem.
If there was an easy and obvious 10x improvement over Git it would have replaced Git by now. Or to put it differently, when someone makes an easy 10x improvement over Git, it will see widespread adoption.
I don't think that last bit is necessarily true. Git has strong network effects, and people are generally very conservative about tools like source control. Git also has the benefit that there are a lot of people used to its quirks, and that skill investment makes them feel fond of it.
The same was true with the switch to WYSIWYG OSes and word processing tools; they were generally liked by people new to computing, but people who were steeped in the old ways, many switched only reluctantly.
> I have to laugh when you say its replacing email.
Laugh all you like, but kids and the interns I've chatted with see email as something akin to how I feel about fax machines: not something they'd use by choice, but necessary for historical reasons. When I've been at organizations during a Slack adoption, email volume drops hugely; 50-80%, I'd guess. I've closed most of the mailing lists I used to run because they shifted to mediums better suited. Just this morning I had to FB message a few friends to get their current email addresses, which tells me a lot about who's winning.
Yes, I agree there are times you don't want things unsent. And there are times you do. There are a variety of ways to balance these concerns. But exactly none of them involves saying, "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices."
Asking to unsend an email is a reasonable request. The answer could be yes or no given the circumstances, but it's only an absurd question to people who have taken a 1980s technological choice and treat it as some sort of unalterable gospel. It reminds me of this Douglas Adams quote:
"I've come up with a set of rules that describe our reactions to technologies: 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3. Anything invented after you're thirty-five is against the natural order of things."
Sure, I get that a lot of people were born after RFC 822, so it seems like the natural order. But the people who wrote the early RFCs weren't thinking that way, and neither should we.
I have no problem with using Slack or Hangouts or Discord or some other chat solution while at work. I also tend to use discord/steam for throw-away conversation with friends.
At no point did I appeal to authority or history in my argument above, so drop the shit around
> "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices."
---
If you think Chat apps are winning, let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.
You jumped into a discussion. The person I replied to was treating the email we happen to have as some sort of unchangeable given. That's what I am objecting to. If you are disavowing that side of his argument, feel free to say so, but it looks to me like you lean pretty heavily on it.
> let me know when you can buy an item online without an account linked to an Email. I'd love to see an example.
You mean aside from the billion or so users of WeChat Pay?
> [Chat apps] can work great in a well structured environment
> Use each as needed
> I also tend to use discord/steam for throw-away conversation with friends
Yes, clearly I'm only advocating for the use of email in its current form for all communication, see me lean so hard above?
---
Wechat might as well be the Chinese government, and it requires a Chinese/Hong Kong bank account to use Wechat Pay. If the government won't honor your transaction record, keeping a copy yourself isn't very useful...
Ok, this one is entirely fair, but also I'd argue the circumstances around it are a little different.
Given how tightly integrated wechat is with the chinese government, and the restriction of wechat pay to use with folks who have a Chinese/Hong Kong bank account, we're talking about different levels of utility around preserving the record.
If the government chooses not to honor your transaction record, it doesn't really matter if you have a copy yourself.
> The reason email doesn't support unsending is not some essential property of messaging. It's just that at the time our email protocol was defined,
email supports unsending in exactly the same ways you described for packages. It most definitely is a property of messaging.
Your fron porch is called "outbox". works the same - you can delete from outbox before sending.
If both you and your recipient are on a properly configured Microsoft Exchange server, you can unsend a message, which is similar to the university department.
And if you aren't, you can still send a message saying "hey, please don't open the last email", and it's up to the other side if they do or don't.
For better and worse, email has a lot of similarity to real mail, down to the distinction between content and envelope.
The main difference is the speed of delivery - you would not expect any of the ways you suggested to work 3 months after you've sent your package -- and yet, compared to the 500ms or so that it takes the email to reach the recipient, that's what attempting to unsend after one minute is.
You can’t unsend an email because you can’t force someone else to delete something. Emails end up as files on someone else’s server. Claiming this is a UX issue is intentionally missing the point. If this is legitimately a foreign concept to you, an afternoon setting up postfix and playing around with it might be worth your time. Email is a protocol, not a program. A “delete” request would be just that, a request.
You can “unsend” on those platforms because the GUI does not display files saved locally, it always fetches them from the server. If you could “unsend” on a version control platform, then it would cease to be distributed version control. The code would have to live inside the VCS app (the same way messages are in memory in slack), or you’d have to give a network daemon delete privileges on your file system.
Imagine if youtube-dl used the model you’re proposing. Letting the git equivalent of “unsend” propagate through the system takes you from a redundant system to, not a system with a single point of failure, but even worse, a system with many points of failure.
Git is for helping develop open source projects, where sometimes a random gal who will never show up again fixes a small thing and sends the maintainer the diff through email. If you want a tool for the high trust environment of your individual team, git will never be what you want. It literally wouldn’t work for its intended workflow if it did what you want.
> Emails end up as files on someone else’s server.
When I use my Gmail account to send an email to another Gmail user, this is obviously not the case. Many adults in their twenties have never used a desktop email application - at my company the younger new hires need some time to figure out how to use Outlook, and they're engineers. They've grown up with the cloud as a given, local storage as the exception, and centralized messaging apps as the default method of communication.
I'm not going to argue about whether way of thinking about computing is any better or worse, but undeniably convenient, and it's definitely the direction we're headed.
Thanks for the explanation, but I ran mail servers for ~25 years. I am familiar with the technology, and in the mid-90s even wrote a chapter of a book explaining email. And I've been using version control even longer. Maybe try rereading what I wrote without the assumption that it comes from ignorance.
I think your comments are coming from ignorance, though.
Without trying to be snarky - All your comments directly ignore that what you're proposing values one stakeholder more highly than another.
People keep pointing out that there are two users involved in this exchange, and they both weigh equally, and you dismiss them and talk about running mail servers 25 years ago (who cares?).
You keep saying "I should be able to unsend my email". Let me rephrase your question - Why should you be allowed to delete my email?
I have in fact never said "I should be able to unsend my email". Once. In my life. Please try to argue with my actual points; I don't have time for straw men.
>Asking to unsend an email is a reasonable request. The answer could be yes or no given the circumstances, but it's only an absurd question to people who have taken a 1980s technological choice and treat it as some sort of unalterable gospel.
---
We're here answering affirmatively that "No" is the right answer for a LOT more reasons than an appeal to authority and history, and you accuse me of a strawman?
Yes, I am indeed accusing you of a strawman. You seem very much in the discussion to win it, whatever that means to you. I can only hope that, having decided you are victorious, you'll now leave me alone, because none of your comments seem particularly productive to me.
>I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer.
You don't understand because you think you're fighting computers but you're actually at odds with other human's desires.
If I pull your code, even if it was a mistake I don't want you to later rip the rug out from me and force me to figure out what happened from the history you deleted.
You can easily change the history technologically. You just force push what you want. The issue is that is usually disabled because it causes a lot of problems for everyone else on the team.
That's a plausible reason, but it's definitely not what the person I was responding to said. "There are user reasons that won't work," is a very different answer than scoffing that the person asking the question just doesn't understand the underlying technology.
I also don't think what you said is necessarily true. If person A has pushed and nobody else has pulled, then for most situations there's no reason to prevent A from un-pushing. Even if person B has pulled, a propagating un-push might well be what they want. I generally would. There are certainly some cases where B might not want that, but given that undoability is a has become a strong user expectation, I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior.
>I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior.
Gitlab and Github (rightfully imo) came to this behavior. It was not random and is not the default git behavior which is to just allow the force push and all the chaos afterward. If you don't like it, mark your master branches as unprotected. However, there's clear reasons for the current defaults.
Technically, I think their problem is assuming that it's acceptable for there to be such a entity, not that one necessarily exists. And then misinterpreting/misrepresenting git's semi-intentional exclusion of such a entity as a bug when in fact it's a feature.
I'm not sure that that such an entity is truly necessary to get a lot of the functionality. However, in the case of git, I'd guess 95% or more of users in effect do have a such an entity. Github is $7.5 billion worth of proof that most people are cool with effectively centralized source code management.
> I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people.
If you try to do that too hard you run into the task automation problem:
That is also a reasonable request.
I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people.
With physical messages, unsending has at least partial support. Before the mailman picks up from my porch, I can grab a sent message any time. If you FedEx the envelope, you can cancel before delivery. With a university's mail system, you can get the receiving department's admin to return something even later in the chain. And of course, you can always tell a recipient, "Hey, I sent you the wrong box, just send that back."
The reason email doesn't support unsending is not some essential property of messaging. It's just that at the time our email protocol was defined, both our hardware and software was pretty primitive, so we locked in a very primitive model of messaging. But note that more modern systems, like Slack and Facebook Messenger, happily let you unsend things. And consequently, they're effectively replacing email for most users.