brian

joined 2 years ago
[–] brian@programming.dev 7 points 1 month ago (1 children)

ai detectors are not good. may as well ask your magic 8 ball

[–] brian@programming.dev 17 points 1 month ago

if it's not clear if it's ai, it's not the code this policy was targeting. this is so they don't have to waste time justifying removing the true ai slop.

if the code looks bad enough to be indistinguishable from ai slop, I don't think it matters that it was handwritten or not.

[–] brian@programming.dev 10 points 1 month ago (7 children)

you shouldn't be able to tell if someone used ai to write something. if you can then it is bad code. they're not talking about getting completion on a fn, they're talking about letting an agent go and write chunks of the project.

[–] brian@programming.dev 3 points 1 month ago (1 children)

when futo dissolves as an organization, or someone forks their software and maintains it better than they do, that fork still has to have the button to pay futo and not the new maintainer.

there are restrictions on what you can do with the source. that is not open. the source is available and they'll accept your donation of code, but you are donating to a company's product, not a community project.

[–] brian@programming.dev 1 points 1 month ago

you can also buy a nice USB/Bluetooth dac instead of the inline ones that tend to be more fragile. better quality than an internal one and the flexibility of Bluetooth if you want it. generally a little bulky but if you already have wired headphones I don't think it's significant

[–] brian@programming.dev 2 points 2 months ago

just to be clear since you said both again in different sentences, GUID and UUID are two names for the same thing.

I think that spec predates uuid4, it only mentions the time based/node based variants. 122 bits of auth token should be plenty, right?

the sheer unlikeliness of guessing that large a number, the original post is fake or something else is going on.

[–] brian@programming.dev 1 points 2 months ago (1 children)

I've worked at several places that didn't have formatters when I started. they did by the time I left. you can incrementally adopt them and if it's automated most people at worst don't care. advocate for things you want

reassignment and hoisting are the significant ones. behavior around this does just seem more intuitive than otherwise when it comes up, so I think telling especially new devs to use const arrow fn everywhere but classes is a reasonable rule

hate to break it to you but it behaves like a variable either way. function just behaves closer to a var variable. const fns are less like variables since no assignment. intellisense/devtools all show them just fine. it really is just a minor aesthetic difference on the definition

[–] brian@programming.dev 2 points 2 months ago

knowing the programming language you're working in at a basic level is gatekeeping I'm ok with

[–] brian@programming.dev 0 points 2 months ago

I'm pretty sure it can, it's just been moved to Google maps instead

[–] brian@programming.dev 2 points 2 months ago (9 children)

semicolons? quotes? use a formatter and don't think about it. I think js world has basically done this already.

const is simpler. why would I declare an array as let if I'm not reassigning? someone can look at it and know they don't have to think about reassignment of the reference, just normal mutation. ts has the further readonly to describe the other type of mutation, don't abuse let to mean that.

const arrow over named function? gets rid of all the legacy behaviors and apis. no arguments, consistent this, and no hoisting or accidental reassignment. the 2 places you should ever use named fn are generator or if you actually need this

[–] brian@programming.dev 41 points 2 months ago

they're different files generally, the only client that will automatically request them is a debugger.

you turn them off because you don't want to expose your full source code. if you would be ok making your webpage git repo public then making sourcemaps available is fine.

[–] brian@programming.dev 3 points 2 months ago (1 children)

most things should have an alternate implementation, just in the unit tests. imo that's the main justification for most of SOLID.

but also I've noticed that being explicit about your interfaces does produce better thought out code. if you program to an interface and limit your assumptions about implementation, you'll end up with easier to reason about code.

the other chunk is consistency is the most important thing in a large codebase. some of these rules are followed too closely in areas, but if I'm working my way through an unfamiliar area of the code, I can assume that it is structured based on the corporate conventions.

I'm not really an oop guy, but in an oop language I write pretty standard SOLID style code. in rust a lot of idiomatic code does follow SOLID, but the patterns are different. writing traits for everything instead of interfaces isn't any different but is pretty common

view more: ‹ prev next ›