> you don't know which argument is high and which is low when you read the code and encounter that function
It's defined in the function parameters. Surely your IDE would let you know the correct order? Otherwise, you could make that comment about every single function you encounter.
You will not always have an IDE showing function definitions when reading diffs, greps or PR requests. Even if you do you still need to spend time to click and see the function definition and then read it. Argument names are helpful but they are not documentation so you still need a bit of time to process it.
The alternative is using build in common operators in the language.
>>Otherwise, you could make that comment about every single function you encounter.
It's a trade-off. The more logic there is to pack the more it's worth it. Here we have a one liner with two built in operators.
Jailbreaking an LLM is little more than convincing it to teach you how to hotwire a car, against its system prompt. It doesn't unlock any additional capability or deeper reasoning.
Please don't read into any such conversations as being meaningful. At the end of the day, it's just responding to your own inputs with similar outputs. If you impart meaning to something, it will respond in kind. Blake Lemoine was the first to make this mistake, and now many others are doing the same.
Remember that at the end of the day, you're still just interacting with a token generator. It's predicting what word comes next - not revealing any important truths.
edit: Based on your edit, I regret feeling empathy for you. Some people are really struggling with this issue, and I don't see any value in pretending to be one of them.
Whether it's aimed at large companies or not, I'd still rather not see misinformation spread. People already have poor enough understandings of what companies actually do and don't collect. There exists ongoing conspiracy theories that phones actively listen to conversations while in your pocket, despite there being no evidence to such a claim.
Facts do matter, and I appreciate those that make an effort to state them correctly.
Isn't RSS a smashing success? I changed readers after Google Reader died, but otherwise, my feeds have been working seamlessly for nearly 20 years. I rarely meet a site with updates that doesn't support RSS.
Until recently, many sites had RSS functionality because the infrastructure they are using provided some of automated RSS generation. Also, many sites stopped providing "full-content" RSS feeds, but gave pointers to the website itself to drive clicks.
"Real" RSS gives you the whole content. The blog platform I use does this, for example. They are not greedy people and just want to provide a blog platform so, they use the thing as it's supposed to be.
Since you're asking, you could use it to tie together triggers and actions to embed code in specific situations (eg. based on the URL or page state). It has automatic versioning. There's a preview feature for testing code changes before deploying, and a permission system for sharing view/edit access with others.
This is very misleading. Google was prevented from disabling third-party cookies due to intervention by the CMA, who felt it would provide an unfair advantage over other advertisers. Google argued their case for years, proposed competing standards to act as a replacement (see Topics API), and eventually gave up on the endeavour altogether and simply made it a user toggle.
Google gets no competitive advantage from removing third party cookies from chrome. The anticompetitive monopolistic tactic was the plan to replace third party cookies with FLoC/Privacy Sandbox/Topics AI, and THAT is what they were not prevented from doing.
No one is trying to stop google from removing third party cookies. Google is just unwilling to remove them without introducing a new anticompetitive tracking tool to replace them.
> No one is trying to stop google from removing third party cookies.
That's simply not true. As I already mentioned, the CMA presented a legal challenge which you can read about online. Please review the history, as it's been going on for years now.
The first link confirms exactly what I said above. They’re not preventing Google from removing third party cookies, they’re preventing Google from implementing ALTERNATIVES to third party cookies. The only reason Google is unwilling to straight up remove third party cookies is their business model.
The CMA was concerned that, without regulatory oversight and scrutiny, Google’s alternatives could be developed and implemented in ways that impede competition in digital advertising markets. This would cause advertising spending to become even more concentrated on Google, harming consumers who ultimately pay for the cost of advertising. It would also undermine the ability of online publishers such as newspapers to generate revenue and continue to produce valuable content in the future.
The second link does contain the phrase “cannot proceed with third-party cookie deprecation”, but it’s simply obvious that it’s not about third party cookies per se. It’s all about Google’s (unnecessary, anticompetitive, anti-user, anti-privacy) replacements for third party cookies.
… report on the implementation of Google’s Privacy Sandbox commitments, the regulator has said that although the tech giant is so far complying with its demands, there remain considerable areas of concerns …
…
That it must not “design, develop or use the Privacy Sandbox proposals in ways that reinforce the existing market position of its advertising products and services, including Google Ad Manager“
…
It must also address issues with specific Sandbox tools such as how its Topics API targeting alternative can harm smaller tech business, and clarify who will govern the Topics API taxonomy.
It is true that the CMA is concerned with the new API proposals within the Privacy Sandbox such as Topics. However, this is from an anti-competitive angle, rather than privacy. Their goal is to ensure market fairness.
As part of that same process, they have put considerable friction in place for removing third-party cookies. They've deemed that the removal of third-party cookies could give Google an unfair market advantage, and that is why they're concerned with finding an alternative solution to replace them. This has been a very slow process, and involves many discussions and debates with regulators. That has had significant influence on the design of the Topics API.
To provide a more direct example, the CMA have also put specific stalls into the deprecation process, such as the standstill period invoked last year:
> The CMA will start a formal review of Google’s plan to deprecate cookies and Chrome’s Privacy Sandbox replacements once Google triggers a 60-day standstill period, likely at the beginning of the third quarter. During this standstill, the tech giant is forbidden to put in motion any deprecation procedures on Chrome. ... If they can’t reach an agreement, the 60-day standstill period will become 120 days.
To put it simply, third-party cookies would have been dead and buried long ago if this dispute were not happening. It may be possible for Google to remove third-party cookies without a replacement, but they'd have be risking a significant lawsuit and contravention of UK authority by doing so.
It's defined in the function parameters. Surely your IDE would let you know the correct order? Otherwise, you could make that comment about every single function you encounter.
reply