You make a good point that knowing the content is not worthy of removal does have implications. However, I think the non-removal implies that the content is not a threat with regards to making the user a victim of a crime. This is an important distinction from "fact checking", which is evaluating the accuracy of the content.
This is the problem with "fact checking". It positions the platform as an authority. Now, any claim that isn't "debunked" by this "fact checking" gains a certain amount of credibility by comparison. The moral hazards are enormous, multiplied by the opaque behavior of Facebook's algorithm and again multiplied by its unprecedented reach in society.
I used this strategy when developing a client library for a web socket API. It was hugely helpful. I could just include the string of the response in my tests, instead of needing a live server or even a mock server for testing. Tests were much simpler to write and faster to execute.
I agree that they would help in the regression testing process, especially in diagnosing the cause. However, I think those are usually just called "unit" tests, not "regression" tests. For instance, the internal implementation of a feature might change, requiring a new, internal unit test. The regression test would be used to compare the output of the new implementation of the feature versus the old implementation of the feature.
"External" functionality will be behavior visible to other code units or to users. If you have a sorting function, the sorted list is external. The sorting algorithm is internal. Regression tests are often used in the context of enhancements and refactorings. You want to test that the rest of the program still behaves correctly. Knowing what behavior to test is specific to the domain and to the technologies used. You can ask yourself, "how do I know that this thing actually works?"
One arguing that sn established0 pattern of behavior will continue into the future is not a slippery-slope fallacy. There is nothing fallacious about arguing that Apple will continue to make the OS more restrictive in the future, based on a profit motive.
"The core of the slippery slope argument is that a specific decision under debate is likely to result in unintended consequences." [1]
I don't see any claim of unintended consequences here.
It's important to understand causation. Engaged parents will still want to spend quality time with their children either way, but they will still want to know the impact. Even engaged parents let young children play with toys on their own from time to time. How are physical toys different than touchscreen "toys"?
'Dr Ana Maria Portugal, main researcher on the project points out “We are currently unable to conclude that the touchscreen use caused the differences in attention as it may also be that children who are generally more attracted to bright, colourful features seek out touchscreen devices more than those who are not.”'
This is an important confounding factor. My opinion is that toddlers often spend time with media that are brighter and more colorful than the surrounding environment, e.g. animated videos for children or educational apps for young children. A better study would take that into account.
I see that, but the best candidate of the current generation is not necessarily the best candidate ever seen. Reproduction and mutation can lead to the best solution of a given generation being worse than the generation before it.
I'm not the author, but DNA can be used to encode data. Interpreting your question another way, the parameters of each solution are data, and they metaphorically evolve like genes.
I like the cleanliness of the library. I learned about and used GAs in college. It is important for this library to have the ability to hold out the fittest candidate so far. This avoids the situation where a good solution is lost because the population evolves away from it. Optionally, the best candidate can be retained for breeding. Deleting unfit solutions should be a parameter. Breeding partner selection should also be weighted by fitness.
I think this is an unfair comparison. Constructing SQL query strings is risky, because it is essentially dynamically constructing and evaluating code from user input. However, there is no reason why one can't use parameters (like you mention) or even call stored procedures.
I've found with distributed postgreSQL databases that the optimizer needs more help than you might initially expect. After looking at how the optimizer inefficiently implemented a query, I found a different, but equivalent, way to rewrite the query that could then be efficiently optimized. It's more complicated in the distributed case, because the shard distribution rules have a strong impact on performance. The time needed to re-balance data across shards for a query can be significant.
SQL is designed around databases. Python is designed around objects. Clojure is designed around expressions. A table is analogous to a list of objects. None of these languages is more domain-specific than any other.
It's just a weird thing that some online brokers seem to do. I once had exercised contracts for 200 shares put me "in debt" for $4mm. Then the shares settled, and everything in my account went back to normal.
This is why the business is usually not asked to make engineering decisions. Things like backups, disaster recovery, and redundancy could all be described as "something in the future maybe will be useful".
When the companies are the same type of business, it is called horizontal consolidation, not vertical integration. Vertical integration is a company buying its supplier or its customer.