Yeah, that's an insane things for a program to do. The only correct thing for a software to do in case of conflict is to warn the user there is a conflict and provide them with the tools to fix the conflict. Assuming a solution is the last thing anyone wants.
I feel like the problem is simply... it should just be a file.
And if it were a file, you could sync it with dropbox or OneDrive.
And if you can do that, they can't make money selling their own cloud service for their local-first app.
More specifically, if you can edit different parts of a same document on different devices, then the document should be split across multiple files that can be synced independently, e.g. a photoshop document where each layer is a separate file and a "main" document simply loads them into a single layer stack.
In fact there are too many document types nowadays that are composites of sub-files and are even actually just a zipped folder under the hood. It feels like we should have just been using files all along, or some sort of file-folder hybrid with OS-level support instead of using zipped folders to contain all the files of a single document.
> More specifically, if you can edit different parts of a same document on different devices, then the document should be split across multiple files that can be synced independently
A more robust idea is to store a log of changes in files that are synced with Dropbox/OneDrive/etc. To prevent conflict warnings from Dropbox, you'll want each device to write to a separate file. Readers re-assemble the logs into (some) canonical total order, then reduce over that to get the document state.
The hard part is re-architecting your app to record all changes, instead of just writing out the current state to disk. However, once you do that, it can form the basis for other features like undo/redo, a view of the file's history, etc.
(The changes don't need to be CRDT/OT messages - anything deterministic works, though it's a good idea to make them "rebase-able", i.e., they will still do something reasonable when replayed on top of a collaborator's concurrent changes.)
Way back in like 2012-2013 I was putting together workflows in ESRI ArcGIS.
The options for scripting were either VBScript or Python. Python was the better choice (AFAIR the UI would show what you were doing in it as python, which made it easy to take a manual flow you developed and automate.)
However, the editor window for scripts in the UI, used the default windows dialog font configured for the user. [0] I wound up having to put together a workflow where I'd have to copy-paste back and forth from a text editor, which was fairly unproductive.
[0] - No, changing the dialog font to fixed width was not a great solution, because then other apps suddenly had terrible UX due to their design....
The main reason I don't want to use C/C++ are the header files. You have to write everything in a header file and then in an implementation file. Every time you want to change a function you need to do this at least twice. And you don't even get fast compilation speed compared to some languages because your headers will #include some library that is immense and then every header that includes that header will have transitive header dependencies, and to solve this you use precompiled headers which you might have to set up manually dependending on what IDE you are using.
> You have to write everything in a header file and then in an implementation file.
No you don't. You write your guaranteed to the public interface into the header file. When you start to put code in there it stops being a header file.
> because your headers will #include some library that is immense and then every header that includes that header will have transitive header dependencies
Your approach is what leads to this problem. Your header files should be tiny and only composed of, well, headers. Also almost all header files should have include guards, so including more then once should be a no-op.[1] Nothing stops you from including implementation files.
[1] When you say that your or compiler doesn't have that optimization: When it has the complexity to support precompiled header files, it can also implement this optimization.
It gets better with experience. You can have a minimal base layer of common but rarely changing functionality. You can reduce static inline functions in headers. You reduce data structure definitions, but put only forward declarations in header files. (Don't use C++ methods, at least don't put them in an API, because they force you to expose your implementation details needlessly). You can separate data structures from functions in different header files. Grouping functions together with types is often a bad idea since most useful functionality combines data from two or more "unrelated" types -- so you'd rather make function headers "by topic" than putting them alongside types.
I just created a subsystem for a performance intensive application -- a caching layer for millions or even billions of objects. The implementation encompasses over a 1000 LOC, but the header only includes <stdint.h>. There are about 5 forward struct declarations and maybe a dozen function calls in that API.
To a degree it might be stockholm syndrome, but I feel like having had to work around a lot of C's shortcomings I actually learned quite a lot that helps me in architecting bigger systems now. Turns out a lot of the flexibility and ease that you get from more modern languages mostly allows you to code more sloppily, but being sloppy only works for smaller systems.
I've been trying Java recently with IntelliJ and it's been funny watching Java's evolution from the IDE's suggestions.
In Java a lot of code looks like this
void foo(Bar bar);
where Bar is an interface, and in many cases it only has one single method, so it looks like a callback that must be wrapped inside a class. Fortunately, Java lets you create anonymous classes to use these methods.
I assume because this paradigm is so common somewhere along the way Java introduced "lambdas" that look like this (I learned this from an IDE hint)
foo((Fish fish) -> false);
But what if you have a class that has Bar.baz method signature but it's called something else like fries()? Turns out you can do this (another IntelliJ hint):
foo(this::fries);
This feels like a complicated way to declare a callback, but it means that if you do implement a method with the same name, you can just pass the instance, otherwise you can use the syntax sugar, e.g.
There is a lot in Java that just feels weird, though. From the top of my head:
1. No unsigned integers. "byte" is -127 to 128. I believe this means it's not straightforward to make a 32-bit RGBA structure since you options are either using a signed "red" or using a 16-bit integer to store the 8-bit values. by the way I tried to benchmark how slow Java was compared to C in a simple test (I had arr1[] with indexes of arr2[] which contained values and I created arr3[] by resolving them) and it seems to be only half the speed of C which is probably fast enough for some basic low-level 2D graphics.
2. String.split takes a regex argument and there is no standard way to split without a regex. This was really confusing to me, but fortunately it's very easy to write your own .split, so it's not that much of a big deal.
3. You can call a different constructor with this(), but it has to be the first statement in the constructor. This one is pretty crazy! It would make sense if you couldn't access member fields before calling the constructor, but having to be first statement means if you want to calculate the argument for one constructor based on an argument passed to another constructor you need to do it inside the parentheses.
So far there is only 2 things I wish Java had. First the ability to implement methods in interfaces so you could use them if you have an interface instead of using a static method. Second I wish @NotNull was the default. This is a problem that Kotlin fixes so I think if you like Typescript for tis type-safety learning Kotlin would be a good idea.
Absolutely not. This is trying to turn a desktop computer into a mobile phone.
I'm sure everyone already understands this, but just to be clear:
There is NEVER, just NEVER, ABSOLUTELY NEVER, going to be a SINGLE QUERY that you want to search BOTH your local files AND the web for. If you want to search the web, you open the web browser. If you want to search your local files, you want privacy which means you don't want the query going to the online search engine. It's a catastrophic privacy risk to put both things in the same box just for the convenience to not have to open the web browser, which is completely pointless either way because you're going to have the browser later anyway if you want a web result.
I'm convinced that Microsoft, Google and (once) Canonical do this fully knowing that some people don't take their own privacy seriously with computer devices or lack the understanding to do so, and when they start letting these things happen and accepting these intrusions, it becomes normalized and suddenly nobody has any privacy left. In the future all your local files will be posted to web servers automatically all the time without consent because that's just what will be the "normal" and accepted pattern by then. This already happens with OneDrive. People get their files sent to Microsoft all the time having no idea it is happening. Google Drive is the same for mobile. People use the "cloud" barely understanding that their data is in someone else's computer, and in many cases without even being aware that they are using the cloud in first place.
The worst of all is that even if you wanted this, in 5 years it's probably going to be "sunsetted" anyway since it's Google.
> This is trying to turn a desktop computer into a mobile phone.
Windows itself is trying to turn a desktop computer into a mobile phone. I try to avoid google and windows because of privacy issues already, but even without them I'm afraid it's only going to get harder to own a computer that does work for you without also being used against you by somebody else.
Many websites are free because they survive from ads. Ads make more money if you collect data. The EU law essentially cut the revenue of all these websites. Their choice is to not collect data (meaning less revenue) or show a popup (meaning more bounce rate, which means less revenue).
People who think this is a good thing are being short-sighted. That's because this law mainly affects websites that host information that visitors visit from clicking on links on the web. If a website is like Facebook or Youtube, where users must sign up first or probably already have an account, they will be able to collect data for ads with or without banners since they have their own ToS for creating an account, and they can infer a lot from how the user uses their services.
I'm not saying privacy regulation is a bad thing. It made countless businesses reconsider how they handle people's data. But it's clear to me that there are two problems.
First, this regulation hurts all the small websites that need to exist in order for we have to have a healthy "web." A lot of these are making only barely their hosting costs in ads, so there is no way they can afford the counsel to figure out how to comply with laws from another continent. If we had another way to support these websites, this wouldn't be a problem, but ads are really the lifeblood of half of the internet, and almost nobody wants to donate or pay a subscription.
Second, this regulation doesn't even really protect people's private data in the end, which may give users a false sense of security because they have the GDPR on their side. I forgot the name, but there was a recent gossiping app that required the user to upload a photo in order to sign up, which should be deleted afterwards, but they never deleted it and when the app was hacked the attacker had access to photos of all users. It's the same thing with GDPR. We can tell when a website is clearly not complying with the GDPR, but there is no way to tell if they actually complied with the GDPR until the server gets hacked.
Even the way they comply with GDPR isn't enough to protect users' privacy, e.g. if you have an account on Discord and you want your data deleted, they will simply turn every post your made into an "anonymous" post. This means if you sent a message that discloses your private information on Discord, that will never get deleted because its outside the scope of compliance. You could literally say "Hi, my name is XYZ, I live in ABC" and they won't delete that because you consented to provide that information, they will just change your username from "xyz" to "anonymous" or something like that.
I still wonder what are the actual benefits of GDPR with these cookie banners when 99% of the users just stay on Facebook and Youtube anyway.
> Many websites are free because they survive from ads. Ads make more money if you collect data.
My business is to get money out of other people's wallets and bank accounts. I could get make much money if you just logged into your bank account and approved transactions whenever I told you to, or screamed less whenever I took the wallet out of your pocket on my own.
That there's a way to earn more money does not justify it as legitimate thing to do, and if you can't figure out how to run a service in legitimate ways does not mean that illegitimate ways that attempt to violate its users in secret suddenly become okay.
Like I said, GDPR only stops the smallest websites from doing that, and in most cases they're barely a "business," they're just some website that gets paid only enough in ads to cover its hosting costs so that the webmaster doesn't have to pay money on top of time to publish information for free for everyone on the internet.
The largest websites will still "violate its users in secret." That's why I don't think GDPR is as useful as people purport it to be.
You're going to get force-fed ads optimized via collected data either way. The only question is whether small websites will exist that rely on third-party ad networks or only Facebook and Youtube will exist because they have first-party ad delivery systems. I don't think the latter is healthier than the former. Do you?
