Yeah I find LLMs most useful to basically read the docs for me and provide it’s own sample/pseudocode. If it goes off the rails, I have to guide it back myself using natural language. Even then though it’s still just a tool that gets me going in the right direction, or helps me consider alternative solutions buried in the docs that I might have skimmed over. Rarely does it produce code that I can actually use in my project.

If they have the ability to accurately detect/enforce any of that, I’d be way more impressed with their fingerprinting techniques than any of the hardware they’re selling

Or some kinky cubist’s wet dream

And cut into their Lemmy time? Inconceivable!

C’mon man, this is just a textbook fallacious slippery slope argument. Rust isn’t some brand new language whose stable release was less than a year ago, it’s over a decade old now. Scheme and Lisp are interpreted languages for God’s sake, it’s borderline* impossible to use them for kernel programming.

Also I’m pretty sure the whole point of the Rust project that all this drama is centered around is to keep Rust code separate from the kernel. From what I understand the whole point is to maintain Rust bindings to the kernel API as a separate project, so that if developers want to write a driver in Rust, they can without having to rewrite those bindings themselves. But the kernel code itself will still be all C code. Now I’m not a kernel developer, and the last time I wrote a driver was for my operating systems class in university over a decade ago, so take that with a grain of salt.

* I say borderline because anything is possible with code if you’re creative enough, but anyone trying to submit Scheme or Lisp code to the Linux kernel is gonna get laughed off the Internet

Plenty of UI applications* are this bad

Right? Like my dude, bare minimum at least write down those steps in a text document so you can reference it the next time you have to add something. Bonus points for putting it on some shared internal wiki or whatever Microsoft uses.

I know it’s a one-of-a-kind game, but it still amazes me that Roller Coaster Tycoon released in 1999, a game where you could have hundreds of NPCs on screen at a time, unique events and sound effects for each of those NPCs, physics simulations of roller coasters and rides, terrain manipulation, and it was all runnable on pretty basic hardware at that time. Today’s AAA games could never. I’m glad some indie games are still carrying the torch for small, efficient games that people can play on any hardware though.

This has way more to do with that specific project being poorly written/not documenting things well than any shortcomings in Python

It cant do enterprise, performance heavy, commercial stuff.

It can, I’ve been doing it for almost a decade. I’ve never noticed a lack of dev tools, and I’m not sure why .NET style project management is a prerequisite for creating enterprise applications. Obviously you can write more performant code in other languages, but I’ve found that 90% of the time, python’s performance is good enough.

Agree on picking the right tool for the job though. Most of the time though, unless you’re dealing with an extreme edge case (like writing embedded firmware for the space shuttle), that just means picking the language your team is most comfortable with.

People need to reply to those comments with “out of scope” and a link to a new issue that will get buried in the backlog more often

https://www.allrecipes.com/article/should-you-peel-carrots/

Carrots are not like other vegetables

Carrots often have dirt caked on the outside that’s hard to get off with just water, so peeling is a good way to help with that.

The peel has the healthy bits

Sort of, but not really. The nutrients of a carrot may be slightly more concentrated in the skin, but all layers of a carrot contain those nutrients. You’re not depriving yourself of an appreciable amount of nutrients by peeling a carrot.

Those of pure enough heart to weild a Keyblade will know how to login - all you need to do is trust your heart, and follow the light!

You think it’s unreasonable for a software developer to take one to two days to learn a tool that’s basically ubiquitous in their field?

What I do locally on my branch is my own business.

Lol ok, but don’t expect git to read your mind. Like I said earlier, if people take a day or two to understand the tool, they can adjust their personal workflows to work better within the confines of git.

I don’t think rerere applies here. Once you do a rebase, the rewritten commits should contain the conflict resolutions. The only way conflicts could reoccur on subsequent rebases is if changes reoccur in those same files/lines.

Only if there are changes in the same files and on the same lines in both branches. And if you’re a commit freak, you should probably be squashing/amending, especially if you’re making multiple commits of changes on the same lines in the same files. The --amend flag exists for a reason. No one needs to see your “fixed things”, “changed things again”, “fixed it for real” type commits.

That could happen if the base branch has changed a lot since the last time you rebased against it. Git may make you resolve new conflicts that look similar to the last time you resolved them, but they are in fact new conflicts, as far as git can tell.

Neither rebasing nor merging should cause trauma if everyone on the team takes a day or two to understand git