lysdexic

I think you're trying too hard to confuse yourself.

With what in mind? Evading NULL?

Depends on your perspective. It's convenient to lean on type checking to avoid a whole class of bugs. You can see this either as avoiding NULL or use your type system to flag misuses.

Languages that make use of references rather than pointers don’t have this Dualism. C# has nullable references and nullability analysis, and null as a keyword.

C#'s null keyword matches the monadic approach I mentioned earlier. Nullable types work as a Maybe monad. It's the same concept shoehorned differently due to the different paths taken by these languages.

I’ve never heard of evading null with a Null object.

This is quite standard, and in fact it's even a safety feature. C++ introduced nullptr defined as an instance of std::nullptr_t explicitly with this in mind.

https://en.cppreference.com/w/cpp/language/nullptr

This approach is also quite basic in monadic types.

It really depends on what problem you experience the most. Automated tests do require an awful lot of maintenance, and minimizing the number of tests you need to track all the invariants you care about is something that helps everyone in the long run.

I often felt that current ML speeds up newbie devs by effectively teaching them the language and libraries — but slows down experts that already know the stack well from memory.

It depends. You don't need LLMs to write stuff for you that you already know. You use them to take.care of the drudge work or explore things you are not familiar with. Things like Copilot's /explain can speed up onboarding even for seasoned developers, and Copilot can also help you speed up iterations on proofs of concept. For example, I've been using Copilot to experiment with some changes to the software architecture of some projects I own, and it's fantastic at generating code following specific design patterns. It's also fantastic to get it to iterate designs in near-real.time by prompting it with directives such as "repeat the last example but implementing X with design pattern Y and moving the implementation to Z". You are presented with examples that you can browse through and get a taste of what you'd get, but with a fraction of the time. To top things off, you can prompt Copilot to present pros and cons and even propose optimizations.

Like any tool, it has its purposes. You just need to learn how to use it.

I don’t use chat, it’s usually useless.

I think Chat is the most useful feature of Copilot. Prompts like /docs work impeccably, but /explain and /optimize is also pretty good. /tests is hit-and-miss if you have zero tests and require too much context if you already have them. More often than not /fix is a waste of time.

Where I found Copilot to be quite useful is something unexpected: naming things. You can prompt it to give suggestions, you can ask it to refactor things for you. Quite nice.

I think that Claude is far better at generating code, and explore new stuff, but Claude is also down and broken extremely often,not to mention it's annoying limit of 10 questions per half a day.

I use chat the most. It's pretty good once you understand the importance of building context, set up personas, and feed it workable prompts. The biggest mistake I see people do is presume that you can expect it to output gold when inputting garbage.

Once you build up an understanding of what personas work for your personal tastes and what context you need to have, it can output impressive results. The most success I've been having is with somewhat complex refactorizations. Stuff like "refactor X so that Y and Y" can save you a lot of time.

The most disappointing experience has been with writing unit tests. copilot has this infuriating tendency to remove old tests when you're prompting it to add new ones. You need to explicitly request it to append tests to file X without overwriting existing tests for it not to mess up, and even then results are sketchy. For unit tests it's also important to setup good contexts otherwise whatever time you save by prompting copilot to write them will be wasted refactoring code to use specific frameworks and follow specific styles.

Like most have already said, the auto complete is top tier (...)

My experience is the exact opposite. Even though it has its moments, more often than not it just hallucinates and proposes a lot of stuff that neither matches definitions nor could possibly compile. I guess that this might reflect the impact of having classes with similar names in multiple namespaces but it's bad to the point I prefer to rely exclusively on plain old autocorrelation.

It doesn’t matter, why the present is garbage, it’s garbage and we should address that. Statements like this are the engineering equivalent of “it is what it is shrug emoji”.

I don't think your opinion is grounded on reality. The "it is what it is" actually reflects the facts that there is no way to fix the issue in backwards-compatible ways, and it's unrealistic to believe that vulnerable frameworks/websites/webservices can be updated in a moment's notice, or even at all. This fact is mentioned in the article. Those which can be updated already moved onto a proper authentication scheme. Those who didn't have to continue to work after users upgrade their browser.

He’s not being run out of the project… yet.

To be honest, to me this all sounds like sociopath behavior to throw politically-inconvenient people under the bus in desperate self-preservation, and hoping this would intimidate anyone falling out of line.

Everyone in that group should present their immediate resignation. Shameful.

Imagine running Guido out of his own fucking project

Imagine running Guido out of Python and still have the gall to argue they are acting on Python's best interests.

What a bunch of self-serving fools.

Boy, does that group sound like the ultimate bunch of social climbers trying to make a living out of someone else's work.