Are you saying you don’t support FOSS projects that aren’t willing to engage in activism? A lot of us are morally aligned with you but aren’t willing to die on that hill. I think this age verification stuff is utter bullshit but if I were a maintainer of a project that was likely to be the target of one of these laws I would not be willing to put my livelihood on the line. Shaming people who are volunteering their time for being unwilling to endanger their livelihoods is pretty entitled IMO.
That doesn’t make it not suck. I’d much rather not hate my job.
Your coworkers are not your oppressors. The people who own the company are. And maybe management if they’re assholes, but most people in management are just doing their jobs so they can get paid.
Using YAML as an intermediate format between steps of a process is a mistake. I love YAML for configuration but I’d never use it for machine-to-machine anything. If the tool you’re feeding data to requires YAML as input, just give it JSON. All JSON is valid YAML.
Edit: I realize you weren’t the one who made that decision. I’m saying the problem isn’t YAML, the problem is someone using YAML inappropriately.
Depends on what you mean by “basically a class”. If you mean inheritance, overriding, and more generally class/inheritance based polymorphism, no, it does not. Those require dynamic dispatch, which Go does not have (for concrete types, which is what we’re talking about here).
They’re different signals. The default handling is the same - terminate - but they’re triggered by different things and (if the process handles them) handled by separate handlers.
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).
Fuck that, I don't trust executables unless they're signed, downloaded securely (e.g. HTTPS), and I trust the source I downloaded them from. Anything else might as well be a virus. If I can't find a signed binary from a trustworthy source, I'm either not using it or I'm going to build it myself (after skimming through the code).
As my first job out of college (when I didn't know what I didn't know) I was hired to build a bespoke inventory system for a manufacturing company. My prototype became a production system the second I showed it to one of the engineers. The next three months of my life were a living hell as I frantically fixed bugs on a live system. Lesson learned.
There are certainly situations where it would be valuable to be able to place limits on what can be imported, but I can't imagine trying to work with a language that was completely devoid of imports. Because that would mean 100% of your source would have to be in a single file, which sounds absolutely awful for anything but the most trivial applications.
But evidently git rev-parse - will not print out the previous branch 😔 that would have been useful for scripts
firelizzard
0 post score0 comment score
“How easy is it to onboard?” is functionally equivalent to “How easy is it to understand?”. The biggest factor in maintainability almost always boils down to how easy it is to understand. So, difficult to onboard almost certainly means difficult to maintain, and thus is tech debt.