[-] firelizzard@programming.dev 3 points 7 months ago

I won't say copilot is completely useless for code. I will say that it's near useless for me. The kind of code that it's good at writing is the kind of code that I can write in my sleep. When I write a for-loop to iterate over an array and print it out (for example), it takes near zero brain power. I'm on autopilot, like driving to work. On the other hand, when I was trialing copilot I'd have to check each suggestion it made to verify that it wasn't giving me garbage. Verifying copilot's suggestions takes a lot more brain power than just writing it myself. And the difference in time is minimal. It doesn't take me much longer to write it myself than it does to validate copilot's work.

[-] firelizzard@programming.dev 3 points 9 months ago

Copilot frequently produces results that need to be fixed. Compilers don’t do that. Anyone who uses copilot to generate code without understanding how that code works is a shit developer. The same is true of anyone who copies from stack overflow/etc without understanding what they’re copying.

[-] firelizzard@programming.dev 3 points 11 months ago

The obvious answer is packages that aren’t essential for basic functions of the OS/desktop environment.

[-] firelizzard@programming.dev 4 points 11 months ago

I'm interpreting that as clickbait - just something they added to the title to drive traffic.

[-] firelizzard@programming.dev 3 points 11 months ago

I was trying to make a point without starting a flamewar that was beside the point. Personally I’d never choose a dynamically typed language for a production system. That being said, Python and Ruby complain if you try to add an array, dict/hashmap, string, or number to another (of a different type) so they’re certainly more sane than JavaScript.

[-] firelizzard@programming.dev 3 points 1 year ago

so you have to catch all exceptions then do extra work to tell what the specific situation is

That’s horrifying. That’s a solid reason to avoid Python like the plague.

[-] firelizzard@programming.dev 3 points 1 year ago

I think the author's primary point is, "Merging changes sucks, don't make your users do that," with a corollary: if your program loads configuration from a directory that is only populated by the user, there's nothing to merge and thus never any merge conflicts. Case in point: /etc/polkit-1/rules.d. I can add whatever rules files I want in there and they're never going to conflict when I update. If PolKit makes breaking changes to the format, it will log errors somewhere and I can look at those errors, look at my rules, and figure out how to fix them. That's a hell of a lot easier than merging conflicting changes to code/configuration.

[-] firelizzard@programming.dev 3 points 1 year ago

Additionally, switch performs extra sanity checks that checkout doesn't, for example switch would abort operation if it would lead to loss of local changes.

What checks? Under what situation does checkout lead to loss of changes? If I make changes and attempt to checkout a ref that would overwrite them, I get the following error:

error: Your local changes to the following files would be overwritten by checkout:
        some/file
Please commit your changes or stash them before you switch branches.
Aborting

To my knowledge it's not possible to overwrite changes when switching branches/refs (git checkout <ref> without any other arguments or flags) so I guess what the author really means is, "If you use checkout incorrectly you can overwrite local changes." As far as I can recall I've never accidentally git checkout <ref> <some/file> so I don't see a reason to retrain my muscle memory. I do use git restore since it's behavior is a lot more obvious than checkout/reset though sometimes I still use git checkout <ref> -- <some/file> because muscle memory.

[-] firelizzard@programming.dev 3 points 1 year ago

Objective-C does not enforce method access (e.g. private methods) at the runtime level. If you are sufficiently determined, there are no restrictions on what methods you can call, unlike Java or C# (AFAIK).

[-] firelizzard@programming.dev 3 points 1 year ago* (last edited 1 year ago)

I totally agree that it’s really annoying when debugging, but go run literally builds then executes. I think what they should do is add a build flag. So debug builds can pass that flag to get the builder to shut up, and leave ~~it~~ those errors enabled for production builds.

[-] firelizzard@programming.dev 3 points 2 years ago

Do you have other regular meetings? I'm at a fully remote company and if we didn't have stand ups I probably barely ever talk to my coworkers via anything more than email and chat.

[-] firelizzard@programming.dev 3 points 2 years ago

He also talks to investors and clients, but about business focused subjects vs tech focused subjects. Beyond that I'm fairly vague on what he does but I'm happy with that because it means I can keep my focus (mostly) on what I find interesting.

view more: ‹ prev next ›

firelizzard

joined 2 years ago