pixelscript @ pixelscript @lemm.ee

Posts

0

Comments

188

Joined

11 mo. ago

I have never been in or adjacent to a situation where I had to measure chocolate packaged and sold to be eaten as-is in a recipe by squares broken off of a bar, at the demarcations pre-scored into the bar. If I needed that much control I'd grate it or use a chocolate that came pre-granulated, like baking kisses.

For chocolate bars meant to be eaten, the score lines are very much for sharability first. Any use of them for culinary measurement is at best a peripheral feature.

This probably doesn't hold true for baking chocolate. But Tony's isn't baking chocolate.

Everything works the same, times of website incompatibility are long gone.

Not completely true. It's mostly true. I've daily driven Firefox for years, and the number of websites I've crossed that wouldn't function in it correctly but would work just fine in Chrome was very slim... but not zero. Definitely not comparable to the complete shitshow of the 90's and 00's. That's true. But it's not a completely solved problem.

And with Mozilla's leadership practically looking for footguns to play with combined with the threat of Google's sugar daddy checks drying up soon due to the antitrust suit (how utterly ironic that busting up the monopoly would actually harm the only competition...), that gap can get much worse in very little time if resources to keep full time devs paid disappear.

I recently had a rather baffling experience trying to preemptively avoid this by downloading the stupid app right away, only to discover I needed the website version anyway.

I was attempting to add my Known Traveler Number to an already booked trip with Southwest Airlines, booked by someone else. I was able to link the trip to my account right away in the app, no issue. And I could see the KTN field for my ticket sitting there, empty, greyed-out, and not interactible. I opened up the moble version of their website, completely unsurprised to find it was identical to the app, except for the detail that the KTN field there was functional. Put in the information, changes reflected in the app instantly, and I was in the TAS-pre line that afternoon.

Why did the two versions obviously built from the same codebase have two different sets of capabilities? Why was the website the more capable of the two this time? I have no clue. All I know is I never want to be a developer at a corporation where I'd have to be responsible for this flavor of trash.

The more egalitarian principle would be to not assume. I won't deny that. People from more minority locales have every right to be upset at being marginalized.

But at the same time, whenever I read passive aggressive comments on socials from residents of crown countries or from EAASL people around the world bitching about US defaultism as if people are doing it just to be ignorant dicks, I can only think to myself, "Uhh, hello? What do you think the demographics of this space were? What did you expect?"

Americans are hardly the majority of the world's English speakers, but for all the reasons you listed, they tend to remain a massive plurality, if not an outright overwhelming majority, of any mainstream online English language platform. No, that's not a license to perpetuate US defaultism. But like... read the room, people. Your good fight is far more uphill than you seem to think it is.

I've seen at least one company press kit in rules on how to display their logo refer to it as "respect distance".

For anyone who was using K-9 wondering why Thunderbird looks no different, it's because they aren't different.

They build both apps from the exact same codebase. Only difference between the two are the default color scheme, the branding icons, and the text strings of the application's name. It's literally just a choice of which brand skin you prefer.

Which, honestly, kinda cool. A virtually zero-cost way to keep a few K-9 stans happy.

It's also part of what makes FOSS niche.

I recognize three kinds of comments that have different purposes.

The first kind are doc block comments. These are the ones that appear above functions, classes, class properties, methods. They usually have a distinct syntax with tags, like:

    
/*
 * A one-line description of this function's job.
 *
 * Extra details that get more specific about how to use this function correctly, if needed.
 *
 * @param {Type} param1
 * @param {Type} param2
 * returns {Type}
 */
function aFunctionThatDoesAThing(param1, param2) {
    // ...
}

  

The primary thing this is used for is automatic documentation generators. You run a program that scans your codebase, looks for these special comments, and automatically builds a set of documentation that you could, say, publish directly to a website. IDEs can also use them for tooltip popups. Generally, you want to write these like the reader won't have the actual code to read. Because they might not!

The second kind is standalone comments. They take up one or more lines all to themselves. I look at these like warning signs. When there's something about the upcoming chunk of code that doesn't tell the whole story obviously by itself. Perhaps something like:

    
/* The following code is written in a weird way on purpose.
I tried doing <obvious way>, but it causes a weird bug.
Please do not refactor it, it will break. */

  

Sometimes it's tempting to use a standalone comment to explain what dense, hard-to-read code is doing. But ideally, you'd want to shunt it off to a function named what it does instead, with a descriptive doc comment if you can't cram it all into a short name. Alternatively, rewrite the code to be less confusing. If you literally need the chunk of code to be in its confusing form, because a less confusing way doesn't exist or doesn't work, then this kind of comment explaining why is warranted.

The last kind are inline comments. More or less the same use case as above, the only difference being they appear on the same line as code, usually at the very end of the line:

    
dozen = 12 + 1; // one extra for the baker!

  

In my opinion, these comments have the least reason to exist. Needing one tends to be a signal of a code smell, where the real answer is just rewriting the code to be clearer. They're also a bit harder to spot, being shoved at the ends of lines. Especially true if you don't enforce maximum line length rules in your codebase. But that's mostly personal preference.

There's technically a fourth kind of comment: commented-out code. Where you select a chunk of code and convert it to a comment to "soft-delete" it, just in case you may want it later. I highly recommend against this. This is what version control software like Git is for. If you need it again, just roll back to it. Don't leave it to rot in your codebase taking up space in your editor and being an eyesore.

Easily my vote for the most unweildy named concept in software development.

It always reads like a typo of memorization. Not exactly an accident, of course. Memorize is memory + -ize, while memoize is memo + -ize, and memo is short for memorandum, which comes from memory. Both terms refer to some kind of storage and retreival of information. The similarities are deliberate.

My gripe with it is that memo in my head exclusively refers to a one-paragraph email sent to my company to notify me about something. Not remembering something. Definitely not the very specific case of linking input parameters to results of pure functions.

So we have this made-up word that looks suspiciously like an existing word that is related and means something related but is not the same thing, and the words it is actually adapted from don't mean the thing it's supposed to mean. Thanks, I hate it.

Really ought to call memoization what it what it really is. Lazy-loaded lookup tables.

That's the thing, though. I computed from the claimed figure above of 13 billion net income. The costs are already accounted for.

I've been told we have state senators who openly claim to only be there to keep speeding tickets low.

If you make $50k/yr after taxes, the equivalent fine would be on the order of about $120.

Where I'm from, that's a speeding ticket.

why is there no replacement for x11 forwarding over ssh??

There kind of is. The project you're looking for is waypipe.

Knowing how these things tend to go, I predict you'll try to use it for your use case and it just won't work for whatever stupid reason. But I successfully used it to tunnel an app from my Debian machine at home to a Windows machine under WSL.

I still won't forgive Shopko for consuming Pamida and ultimately taking the remnants of Pamida down with it.

I'm surprised to see on Wikipedia that Shopko actually owned Pamida basically the entire time I was growing up, they just ran it independently. They even broke up breifly before re-merging later. The second merger sent it all to shit, though. "Shopko Hometown" my ass.

Fellow tattooless here. Uh, neither?

I simply don't see the appeal of putting on something I can't easily take off if I wanted to, for its own sake. Yeah, tattoos aren't permanent, a removal process exists. But they cost money and require an appointment to be rid of, on top of the investment of time, money, and pain to buy in. The barrier to entry and the barrier to exit are both too high for my liking.

Ideally you get a tattoo and enjoy it for life. I can't commit to that kind of decision. Not for a funny body picture. If I need a memento to cherish memory of a thing or event I'll get a tchotchke or something.

I have no complaints about others' tattoos. They're more often than not incredible works of art.

There are exactly three kinds of manpages:

1. Way too detailed
2. Not nearly detailed enough
3. There is no manpage

I will take 1 any day over 2 or 3. Sometimes I even need 1, so I'm grateful for them.

But holy goddamn is it awful when I just want to use a command for aguably its most common use case and the flag or option for that is lost in a crowd of 30 other switches or buried under some modal subcommand. grep helps if you already know the switch, which isn't always.

You could argue commands like this don't have "arguably most common usecases", so manpages should be completely neutral on singling out examples. But I think the existence of tl;dr is the counterargument.

Tangent complaint: I thought the Unix philosophy was "do one thing, and do it well"? Why then do so many of these shell commands have a billion options? Mostly /s but sometimes it's flustering.

Acid rain is real. So is quicksand. Either of them being common and severe hazards experienced across the entire US (and maybe elsewhere, I don't know what the rest of you were taught in gradeschool), not really.

Real acid rain causes mass ecological damage through relatively subtle increases in acidity over several exposures. The way we learned about it in school, whether they meant to or not, came across like concentrated hydrochloric acid was going to rain from the skies and melt human flesh on contact.

Don't forget how to put yourself out if you spontaneously combust, and acid rain.

I drive Linux for a similar reason to why some people prefer driving manual transmission cars to automatics.

Automatic transmission cars are ideal for a certain kind of driver that has no interest in how the machine actually works, they just want the machine to do its job as smoothly as possible without them having to think about it. Not bothering with the details is the whole point.

For those of us who do have an interest in knowing how the vehicle works, automatics become kind of suffocating. They're designed to only ever behave in certain specific ways. If there's a weird niche thing that we know is possible for the machine to do with manual control, but the automatic system doesn't support, you're just SOL. You can't. This starts coming up in all sorts of annoying little ways, increasing in frequency as your knowledge increases. Death of a thousand cuts. You start feeling like you're not really driving this car, you're being taken for a ride.

Windows is like the automatic. It is a black box designed to allow people who don't care how the computer works to use the computer. To prevent morons from breaking the internal components, they put up barriers around everything and tell you to keep out.

Linux is like the manual. Yes, it does demand more finesse and active knowledge about how the computer works to drive properly. But you're in maximum control of it. If you want to pop the hood and tinker with every facet of its innards for whatever reason, it does not attempt to stop you. It's all open, laid bare for you to do whatever you want with it.

Linux has a lot of options available to make it more automatic like Windows, if you want it. The difference is that the automatic-ness is completely optional in Linux. Imagine a car that can be automatic most of the time when you don't care, but can become manual at the drop of a hat when you need it. Linux can be that if you want it to be. Windows can't.