expr @ expr @programming.dev

Posts

0

Comments

453

Joined

2 yr. ago

This is something often repeated by OOP people but that doesn't actually hold up in practice. Maintainability comes from true separation of concerns, which OOP is really bad at because it encourages implicit, invisible, stateful manipulation across disparate parts of a codebase.

I work on a Haskell codebase in production of half a million lines of Haskell supported by 11 developers including myself, and the codebase is rapidly expanding with new features. This would be incredibly difficult in an OOP language. It's very challenging to read unfamiliar code in an OOP language and quickly understand what it's doing; there's so much implicit behavior that you have to track down before any of it makes sense. It is far, far easier to reason about a program when the bulk of it is comprised of pure functions taking in some input and producing some output. There's a reason that pure functions are the textbook example of testable code, and that reason is because they are much easier to understand. Code that's easier to understand is code that's easier to maintain.

In Nebraska, I get my ballot by mail way in advance. I fill it out at my leisure, doing research on candidates as needed. I can then either mail the ballot back or drop it off at one of several locations around town (including any of the public libraries). I haven't voted in person in years. This method is so much better.

Yeah our corporate machines won't run any external media. I assumed that was standard practice.

Obligatory "JSON APIs are not REST because JSON is not hypermedia".

GraphQL is a mess too as you throw out any ability to reason about query performance and it still requires thick clients with complicated/duplicated business logic.

If you're doing RoR anyway, then go for https://htmx.org/. It's much, much simpler and closer to how the web was originally designed. Highly recommend this book the author wrote on the subject (also provides tutorials walking through building an app): https://hypermedia.systems/book/contents/.

The typical "30% on income" advice is based on gross, not net. Which is about 93,000 a year for the median mortgage payment right now.

Just to point out, with the median mortgage at $2349 a month, it's more like you need a household income of $93,000 a year (probably closer to $100k with utilities and other expenses) for your housing costs to equal 30% of your income. That is steep for a lot of people, but still much more attainable than 7 figures. A quick Google says that makes up around 37% of US households as of 2022. Still doesn't quite add up to their figures, admittedly, unless "nearly half" is doing a lot of work in that sentence.

I can't even find showings in my state.

Spoken like someone who knows absolutely nothing about vim/unix.

It's not necessary. Unlike on Windows, Linux users rarely download random packages off the internet. We just use package managers.

The software itself may or may not be more secure, but acquiring software is absolutely more secure. There's so much Windows malware people unwittingly download from the internet. Downloading from a distro's software repository simply doesn't have that problem.

Let's give it a shot. I live in the suburbs of Lincoln, Nebraska, which is an average-sized college town in the US (about 300k residents):

• Nearest convenience store: 1.1 miles/1.7km (we often do walk there, takes about 20 minutes)
• Nearest chain supermarket/big supermarket (they are often one in the same here): Target @ 1.5 miles/2.4km
• Bus stop: 1.3 miles/2.1km
• Nearest park: 0.6 miles/965m
• Nearest public library: 3.5 miles/5.6km
• Nearest train station: 9.1 miles/14.6km (we don't really use trains much at all in the US, though)

This is just taking a very antagonistic view towards kids. Manipulation is learned behavior and says much more about the parent than the child.

But honestly, it's besides the point. This point is that it's wrong to force kids to eat food barring medical situations.

I do have a kid. We give our son a variety of foods and let him decide what he wants to eat. He eats a lot of different kinds of foods (big fan of Indian food atm), and the foods he wants to eat change from one day to the next. Treats are reserved for special occasions, mostly because those in particular can have a pretty significant impact on brain chemistry.

Forcing kids to eat is very well known to be a very bad idea.

A synopsis for a great fucking movie.

That's what the diff tool is for.

Interactive rebase? There's no GUI that actually does that well, if at all. And it's a massive part of my daily workflow.

The CLI is far, far more powerful and has many features that GUIs do not.

It's also scriptable. For example, I often like to see just the commits I've made that diverge from master, along with the files changed in each. This can be accomplished with git log --oneline --stat --name-status origin/master..HEAD. What's more, since this is just a CLI command, I can very easily make a keybind in vim to execute the command and stick it's output into a split window. This lets me use git as a navigation tool as I can then very quickly jump to files that I've changed in some recent commit.

This is all using a standard, uniform interface without mucking around with IDE plugin settings (if they even can do such a thing). I have many, many other examples of scripting with it, such as loading side-by-side diffs for all files in the worktree against some particular commit (defaulting to master) in vim in a tabpage-per-file, which I often use to review all of my changes before making a commit.

It can be nice when you successfully do a rebase (after resolving conflicts), but change your mind about the resolution and want to redo it.

Doesn't come up that much, but it's been handy once or twice, for me. It's also just nice security: no matter how I edit commits, I can always go back if I need to.

I'd say the odds of kids doing that are pretty slim, they usually aren't that strategic when it comes to food. But even if it were the case, it's still no reason to control kids' food intake during mealtime. That's just abusive and is going to give them issues with food.

Kids are generally actually quite good at regulating their food intake naturally in ways that parents often don't understand. Adults tend to think in terms of roughly balanced meals for every meal, but kids often tend to favor one particular food at a time, achieving balance of nutrition over the course of the week. Especially when they're younger, it's often very chaotic what kids want to eat at a given time. They might love something one day and hate it the next. Their taste and palate are still developing, and it's a parent's job to be flexible rather than a child's job to follow arbitrary food rules.

I'm sure it's fine for small-scale usage, but overall it's extremely inflexible and doesn't really scale well at all. There's also a lot of very basic functionality that's straight up missing. For example, there's no way to have a global epic priority. You can rearrange epics in an epic board, but the ordering of the epics there is not persisted elsewhere. There were many, many other shortcomings we kept running into.

Oh, and after a lot of our tickets had been imported (which itself was a huge undertaking since the auto import tools are complete trash), it started to be very slow. It feels like a very unfinished, unpolished product.

We use Gitlab's CI/CD features extensively at my current job and it's very, very nice. That's what they are actually good at, not project management.

I also wonder if people complaining about Jira are still on Jira Server. Jira Cloud is a much nicer experience. Certainly not perfect, but I've yet to see an actual viable alternative (once worked someplace that tried to move all project management to Gitlab... 🤮).