Remix.run Logo
yacthing 3 days ago

> We're both programmers so we're both know we're talking about a one line regex...

As a big tech programmer, it's almost never that simple...

Small edges cases not covered by a one line regex can mean big issues at scale, especially when we're talking about removing things from a calendar.

godelski 3 days ago | parent [-]

  > As a big tech programmer, it's almost never that simple...
I'll be fair and agree that I'm being a bit facetious here. But let's also admit that if you are unable to dedupe entries in a calendar with identical names then something is fundamentally broken.

I did purposefully limit to holiday calendars as an example because this very narrow scope vastly simplifies the problem, yet is a real world example you yourself can verify.

You're right that edge cases can add immense complexities but can you really think of a reason it should be difficult to dedupe an event with identical naming and identical time entries, especially with the strong hint that these are holidays? Let's even just limit ourselves to holidays that exclusively fall over full day periods (such as Labor Day).

Do you really think we cannot write a quick solution that will cover these cases? The cases that dominate the problem? A solution whose failure mode results in the existing issue (having dupes)? Am I really missing edge cases which require significantly more complex solutions that would interfere with the handling of these exceptionally common cases? Because honestly, this appears like a standard table union problem. With the current result my choices are having triplicate entries, which has major consequences to usability, or the disabling of several calendars, which fails to generalize the problem and also results in missing some minor holidays. Honestly, the problem is so bad I'd be grateful even if I had to manually approve all such dedupes...

If not, I'd really like to hear. Because it really means I've greatly mischaracterized the problem and I should not be using this example. Nor the example of a failure to FIND contacts with identical names, nicknames, phone numbers, birthdays, and differ only on an email address and note entry. Because I have really been under the strong impression that the latter is a simple database query where we should return any entry containing matches (failure mode being presenting the user with too many matches rather than a lack of matches. We can sort by number of duplicate fields and display matches in batches if necessary. A cumbersome solution is better than the current state of things...).

I'm serious in my request but if I have made a gross mischaracterization then I think you'd understand how silly this all looks. I really do want to know because this is just baffling to me.

If I truly am being an idiot, please, I encourage you to treat me like one. But don't make me take it on your word.

yacthing 3 days ago | parent [-]

That's a lot of words, but I think it boils down to: you're making an assumption that two calendar events with identical naming and identical time entries will always have a desired behavior of being deduped.

- Maybe you want to separately invite people to the same thing and have different descriptions, now you're increasing the number of things to equate.

- Maybe a user creates one event that is simply a title and a time, and they then want to create a second one for another purpose. However, it keeps getting deduped and they don't know why. Now you have a user education problem that you have to solve.

- Now you might think: well just make it a toggle in the settings! Okay well now you have to add a new setting and that expands the scope of the project. Do you make it opt-in or opt-out? If it's opt-in, what if no one uses it? Do you maintain the feature if there's a migration? If it's opt-out, you still have the above problems.

I could go on. And this is mostly an exercise of not underestimating a "simple" change. Calendars (and anything involving time) in particular can get very complicated.

godelski 2 days ago | parent [-]

  > will always have a desired behavior of being deduped.
Okay, let's say people like repetition. Optional flag. Great, solved.

  > Maybe you want to separately invite people to the same thing
To a... holiday? Sorry, I already cannot invite people to a holiday in my existing calendar. I have no ability to edit the event. This capacity does not exist in my Apple Calendar nor Google Calendar and I'm not going to check that Outlook Calendar because the answer doesn't matter.

  > Maybe a user creates one event that is simply a title and a time,
Again, no need to auto-dedupe. But having collisions and requiring unique name entries is not that uncommon of a thing.

  > And this is mostly an exercise of not underestimating a "simple" change
Except to introduce your complexity you also had to increase the scope of the problem. Yeah, I'm all for recognizing complexity but come on man, we're talking about fucking Apple who makes you do it their way, by visiting 12 different menus, or the highway. We're talking about the same company who does not have the capacity to merge two contacts and only has the option "find duplicate contacts" but is unable to find duplicates despite multiple matching fields.

So what's your answer? Keep the bullshit and do not provide an option to allow merges or dedupes? Literally all the problems you've brought up can be resolved by prompting the user with a request to merge OR just giving them the ability to do so. You really think triplicate entries is a better result than allowing a user to select three entries, right click, "merge entries"? Come on...

yacthing 2 days ago | parent [-]

> So what's your answer?

My answer is simply: It's not a 5 minute regex change.

I'm not even saying it shouldn't be prioritized or isn't worth the effort. Just that you should give the problem a bit more respect.

godelski 2 days ago | parent [-]

  > you should give the problem a bit more respect.
The more generalized problem? Absolutely!

The very idealized trivial cases we're discussing and I've stressed we're discussing? I'm unconvinced.