I think they have already realized this, which is why they are moving towards tool use instead of text generation. Also explains why there are no more free APIs nowadays (even for search)
I use it to build some side-projects, mostly apps for mobile devices. It is really good with Swift for some reason.
I also use it to start off MVP projects that involve both frontend and API development but you have to be super verbose, unlike when using Claude. The context window is also small, so you need to know how to break it up in parts that you can put together on your own
Cline + RooCode and VSCode already works really well with local models like qwen3-coder or even the latest gpt-oss. It is not as plug-and-play as Claude but it gets you to a point where you only have to do the last 5% of the work
This has been an issue with university rankings for a while. A lot of top US universities engage in this practice too - anecdotal, but I've heard a lot of professors force students to add/remove some citations, or even add their names to the list of people who worked on a paper to help the numbers for their university.
It would be good to see what the criteria is for deciding if a journal is "to be taken seriously". I imagine for example that Chinese or Arabic language journals wouls be published and citsd in journals of those languages. That doesn't necessarily mean that they arent to be raken seriously in the field, it's just that they aren't Western publications.
Agreed. Any bug report from a user is valuable - the fact that he was frustrated enough to report it means that there is a problem that needs to be addressed.
^ Ditto. I thought pointers were being shown in a negative light at first, but now I see the point. In my opinion too, manual memory management is a very important part of developing highly scalable applications, but should only be done if absolutely needed - which is fortunately rarely the case nowadays as most people just develop for the Web, and can afford to throw money at the problem. But for embedded systems where resources are limited and inputs are very limited, it is still very useful. In the early years, it was C + inline assembly for further optimization - where you try your best to avoid assembly. I guess now, it's a dynamic/interpreted language, plus C/C++ for further optimization, and avoid C/C++ like the plague as much as possible.
I agree with you for the most part. C/C++ lets you do what you want, presumably because you know what you're doing. But I don't agree that pointers are evil, and should be avoided. If you want to do any practical programming with C/C++ at all, you have to learn how to dynamically allocate memory and use pointers. Generally, pointers work as advertised. It's the cases where they work when they shouldn't that is the problem. In these cases a compiler usually warns you, so you are still covered. So in C/C++, just because it works, doesn't mean your code is right.
I think it isn't about the engineers' skill, but more on how they work together as a team. 5 superstar pricks will get you nowhere. 1 superstar plus 4 average engineers that work and take directions well, and you have a team. Even with just 5 average engineers, as long as they get the job done and take to instructions well, you're better off. The problem with superstars is that they usually have huge heads, and would rather prove a point than make things work. A superstar with a great work ethic and is a team player, now that is worth the money.