You can be as tolerant as you want, that's not how things go for iOS apps. It's certainly not how things go on macOS except when there are no available alternatives.
Windows, Android, and the web, constantly changing so that there's never really been any sense of stability, blind a lot of developers to the fact that good design is both functionality AND looks.
When people complain about designs of controls being out of date, they don't only refer to looks. They refer to how they feel, behave — or more succinctly, don't correspond to the expectations set up by the rest of the system.
To reduce the debate down to looks vs. functionality is reducing things down to the wrong level, missing the forest for the trees, and ignoring the user — a person who often isn't able to express what they need but knows what they want, not often realising that they're the same thing.
The objective is far less practicality or usefulness than of determining possible attacks on the anonymous contact tracing method. Also incidentally highlighting the power and threats of widely-distributed surveillance networks. Inference is powerful.
Well, they failed then, because it can definitely be used for stalking. Having covid and distributing your daily keys makes it much easier but not necessary.
Sure it is, you just need imagination. Say that you are a stalker, you (or someone delegated by you) passed near your target and got h(daykey, time), your target happens to go to the hospital for covid a while after, so you have the daykey of your target for multiple days and all of their h(day, time). You detect that it was your target that went into the hospital because one of their h(daykey, time) matches with the one that you have stored, in addition you know if your target passed nearby you/one of your friends/one of the locations where you have put some cheap bluetooth phones and the exact day and time that this happened. Intentionally infecting the target will covid will help this whole thing but it is not necessary.
That maybe "censorship resistance" isn't the universal good some people make it out as. Maybe the people who benefit the most from it, and who make up the majority of those who actually benefit, are criminals. Maybe it's not a great idea to make tools that make it easier for criminals to commit crimes.
> That maybe "censorship resistance" isn't the universal good some people make it out as
How is it not? Not having it means that certain organisations and governments will be able to remove your ability to see certain things.
> Maybe the people who benefit the most from it, and who make up the majority of those who actually benefit, are criminals
Again, debatable. See all kinds of videos that are removed from youtube because either youtube thinks that they violate their tos or because someone makes a copyright claim on them for example.
But even if the majority of these who did benefit from it were criminals, I will ask again, and?
> Maybe it's not a great idea to make tools that make it easier for criminals to commit crimes.
How so? I would assume that most of these who make such tools have some form of ideology similar to anarchism and who do not think that every action that the government designates as a crime is morally evil. In addition a lot of these people believe that certain elites and government officials are the ones committing the biggest crimes and use such tools to enforce transparency and benefit from censorship resistance and anonimity.
Because it helps criminals commit crimes. Not crimes as in "oh the government doesn't like you doing this", crimes as in theft, fraud, blackmail and child rape.
> You can't steal physical objects via TCP due to censorship resistance.
You can steal money, and passwords. And you can steal things in the physical world and sell them over the internet.
> If anything censorship resistance helps prevent fraud
The entire Bitcoin economy gives a massive counterexample of this.
> I do not see how censorship resistance has anything to do with blackmail.
Censorship-resistant digital currencies like Bitcoin are massively used for ransomware and other forms blackmail.
> I do not see how censorship resistance can help a criminal rape children via TCP.
You are not so stupid that you would think anyone was ever making that argument. Do not feign stupidity, that never makes you look clever or convince anyone of your argument. I am ignoring this one and giving you a second chance to give a good-faith answer.
Censorship resistance somehow helps you steal money and passwords via TCP? How?
(Regardless, I am not buying this whole "stealing numbers" thing)
> And you can steal things in the physical world and sell them over the internet.
Sure, how is censorship resistance relevant to this?
> The entire Bitcoin economy gives a massive counterexample of this.
Do you know of a lot of people who put advertisements of their companies on the blockchain?
Regardless (and I am going on an off-topic tangent here), anyone dealing in bitcoin should be aware of the fraud issue. You are not going around asking people to ban stoves because you decided that it would be a good idea to put your hand on one despite being aware of the potential complications.
> Censorship-resistant digital currencies like Bitcoin are massively used for ransomware and other forms blackmail.
Censorship resistance has again nothing to do with this. There is nothing stopping someone from including some form of "chargeback" command in a censorship-resistant cryptocurrency. I can't say for sure why this has not been done but I presume that most cryptocurrency users would not like to give the ability to a centralised institution to take their money away from them (I know for sure that the freelancers that use paypal are not too happy with this).
In addition there are a lot of real life services that do not offer the ability to chargeback yet they do not offer censorship resistance - western union for example.
> You are not so stupid that you would think anyone was ever making that argument
Rather than insulting people because you think that they misunderstood your post why not try to elaborate instead?
"Giving out money for free" isn't really something that make me think something is LESS of a scam. Giving out free money is literally what every every cryptocurrency scam does at first.
I'm not an expert on cryptocurrency scams, but if anything, I think they'd generally give away their magical internet tokens rather than US dollars. (Though I suppose magical internet tokens can be exchanged for US dollars so perhaps there isn't that much of a difference?)
Well, you see, that's one of the problems... monad implementations don't have to be "containers", or at least not the way most people mean. This was one of the critical errors in many of the aforementioned "tutorials". IO, the quintessential monad, is not a container, for instance.
(A nearly-exact parallel can be seen in the Iterator interface. You can describe it as "a thing that walks through a container presenting the items in order"... and yeah, that's the majority use case and where the idea came from... but it's also wrong. What it really is is just "a thing that presents items in some order". It doesn't have to be from "a container". You can have an iterator that produces integers in order, or strings in lexigraphic order, or yields bytes from a socket as they come in, or other things that have no "container" anywhere to be found. If you have "from a container" in your mental model then those things are confusing; if you understand it simply as "presenting items in order" then having an iterator that just yields integers makes perfect sense. A lot of the Monad confusion comes from adding extra clauses to what it is. Though by no means all of it.)
The problem is telling people it's a container is "over describing" it. We don't need to hypothesize about that. We have the space suits and burritos to prove it is not a good didactic approach. It is not removing from the definition to simplify, it is adding to the definition, exactly as I carefully showed in my description of "Iterator". An Iterator is "a thing that presents a series of items". It does not simplify the discussion of Iterator to say "It's a thing that presents a series of items out of a container, but also, it doesn't have to be a container". It's not the first definition that's "overdescribing", it's the second.
Part of why Haskell appears like such an implacable curmudgeon is the predilection of its community to believe that users must grasp type and logic theory to use it.
They don't.
Just like they don't need to have a mental model of their computer to write software for it.
This has inspired me to try to update my post on the idea in a side window, but it's been sitting on my hard drive for over a year now and probably still has a ways to go yet.
I've had good luck with explaining it as a characteristic of a programming language. In a language consisting of sequences of statements with bindings and function calls, we expect that
f(x)
is the same as
a = x;
f(a)
and the same as
g = f;
g(x);
That's the monad laws. Whatever craziness you want to put in the semantics, those are properties you probably would like to preserve in your language.
I'm no expert, although I think I remember that a Monad is basically just like allowing a sequence of statements to be executed. Like executing a code file ;)
Functional languages are really weird, for instance it's possible to switch line order of statements and the compiler will still figure out how to stitch that together. I think even JS in parts has or at least had that behaviour. (Actually that's useful when having mathematical formulas that are interdependent and you're too lazy to order them topologically by dependence)
On the other hand, just executing a sequence of commands in order to do I/O is only a normal thing to do since recently as far as I understand. The sweet spot for FP is IMHO something like React where state is strictly separated from the functions. (Imagine writing Hello World using Normal Maths)
(Please correct me if I'm wrong, which is probably quite likely ;))
Yes, but iOS requires you to use Objective-C (or Swift) just like Android requires you to use Java.
I know the comment put Objective-C right next to C and C++, but it doesn't belong there. All platforms should have (at least) C interfaces, not requiring C++ or even Objective-C.
That would mean either implementing your entire API twice, or adding layers of pointless indirection, for extremely little gain. It is just not reasonable.
You're assuming that people want to program applications in "platform languages" like Objective-C or Swift or Java or Kotlin. That's generally not true. They want to use their language of choice.
That's why C interfaces are the reasonable choice, you can interface with them conveniently from pretty much any language and if you want a more idiomatic "pointless layer of indirection", you can build it.
Making a performant list view is actually a very non-trivial task. All the weird complexity you see in the API is there to make it possible at all to have large list views that do not absolutely kill your phone.
That’s only necessary because a View in Android is ridiculously heavyweight and slow.
I ported a game from iOS to Android and just wrote simple C wrappers for all the views. I didn’t bother much with optimization, but lists with hundreds of complex items worked just fine, no lazy loading or recycling necessary.
