It makes a far broader point (or, points) than that.
> If your browser is a privacy gamekeeper and those trackers are data poachers, then you probably don’t want them all sporting the same logos.
> Chrome is one of Google’s primary platforms for user data profiling
> “If you use Chrome, you give up your privacy,” my STC colleague Kate O’Flaherty warns this week.
> Chrome is an excellent browser—technically. But as with all platforms, apps and services, you always need to follow the money. Once you ask yourself is this a product I have paid for or am I the product, are others paying to access me, then you can start to make clearer choices.
> The FLoC origin trial enrolled millions of you without an opt-in or opt-out into a secretive trial that Google now admits added additional fingerprinting surfaces. That means you were more easily identified and profiled. That’s not okay. Similarly, having promised to ditch tracking cookies, Google changed its mind—again, not okay.
Yeah this is a non story. Delete Chrome because its not getting rid of this (admittedly anti-user prone) feature it's had since 1.0 is not very sudden.
Even as a Firefox user I don't see why that means you suddenly should get rid of Chrome.
I do hope Google keeps cracking at something to replace third party cookies with.
I used to own cheeseonthemoon.com, it was one of my first websites back in high school and I just goofed off trying to be funny. It's still on archive.org where you can read about my theory (misinformation?) that there is cheese on the moon. There was a forum where me and a few friends would discuss random topics.
I always like to look back at the "Show HN: Dropbox" thread (https://news.ycombinator.com/item?id=8863) and look at the comments like "For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account" :)
I think most engineers try to think more critically than the general population.
More likely that engineers are more likely to think that they are more critical than the general population and that basic human social facts somehow don’t apply to them.
Copilot is a fancy autocomplete tool for code. I think the controversy comes from it being trained on public repos without adhering to licensing. I used copilot and thought the best part was when it would autocomplete based on other code I was writing. Sometimes the Copilot would help me see places where I had repetitive code which could be turned into a function.
I have access and hints for entire functions have only appeared from code already in the same file. It uses the file you are in for context.
It also says on their website that the AI may generate api keys that look real but it’s actually just a “fake” key that the AI generated as placeholder.
I have had access for one day, spent my entire Saturday playing with while working on an addon for a game. I find it useful and most of the hints come from other code I have in the same files which saves me time or let’s me know when I’m too repetitive :)
"It also says on their website that the AI may generate api keys that look real but it’s actually just a “fake” key that the AI generated as placeholder."
So the article mentions an issue reported by dtjm annd the maintainer answers the issue explainig that the keys are fictional. I don't see any statement by the github CEO about this being an issue as the article says.
This is more of a US problem. In the EU much of higher education is very cheap or free. Some students even get paid a small amount of money and have access to loans with low interested and great terms so that it's easier to focus on school and everyone is on a more even playing field.
Yes, and in various countries universities have a solid theoretical and scholarly approach to STEM topics.
In US Engineering is framed as a very practical, "how-to" oriented, to the point that people can be surprised to learn that engineers do research and publish papers.
I spend a lot of time reviewing code, I currently review every line of code for 16 other developers.
Obvious comments are great for code reviews because it's a validation that what you intended to do is what your code actually does.
From the article, the comment about adding a vertical scroll bar allows me to review the code and to check that it does indeed add a vertical scroll bar and not something else.
Did the developer intend to require password lengths of at least 8 characters? A simple comment would tell me what the developer wanted to do and then I can verify that it was done correctly.
Great, but that's not the reason why obvious comments are bad. They are bad because it's not maintainable. For you this means that the next time a developer refactors the code, you need to check if the comment is still accurate with the refactored intentions. I repeat, this is not maintainable! I love how the book Clean Code described it: "A comment is a failure to express yourself in code." There are situation they are useful, but those are definitely not obvious comments.
Eg. I like paragraphed comments, because you know what the next 5 lines will do and you can quickly skip to the part you need.
It's not always possible to have a method with only 5 lines. There are use-cases where you want a big method doing a lot of things together, because it's complex.
Eg. For a government project i needed to connect to the internal network for executing certain requests and all that logic was in one HttpProxyClass, shared between the api + service/deamon
If those 5 lines do so much that you can't scan it quickly, why is it not in a function? I don't understand, why so many people here have a hard time of understanding this here on HN. You can't trust that comment, you don't know if its outdated or not.
Update: I noticed you updated your comment.
So my reaction to your addition is that a class can always be abstracted to higher level. It will probably do to much at this point.
I added the example of what i kept together, because that complex class was the junction class of 4 interfaces for server/client + receive/send.
The logic was much simpler to scan/change if you comprehend everything it does. Instead of only partially by abstraction. The use case that one thing was called for one-use case wasn't applicable.
I like clean code and apply it a lot. But it's not applicable for everything. I think you just didn't encounter the more advanced cases yet where it isn't, since they are not that frequent.
The spirit of clean code is to make readable code. Not the reality is that you have to adjust to the situation. They're is code were comments make sense. Comments can give context and intent ( look at code of sqlite for example).
These comments will rot and become confusing/misleading oh so quickly.
It's great that somebody is reviewing every single line of code and probably will catch it when folks modify the code but inevitably forget to update the comment, and it becomes out of sync - becomes misleading.
If the reviewing is not vigilant that's where you end up: you don't know what to trust, the comment or the code. And the code wins, so that _what_ and _how_ type of comment becomes a net negative.
I see the point. I guess our team just puts the barrier for "useful comment" a bit lower than most other teams. I work with software as a medical device products which has requirements for documentation. Some of this documentation is autogenerated from doc blocks and it is therefore part of the review to also review comments.
I understand that my situation will not reflect the average developer. But it is good to see both points of view.
