I know you didn’t ask, but you don’t need a weird fork of emacs to run a Clojure REPL, that just works in regular emacs

Fuckin goteem

That thread is from like 4 years ago, types in Python have come a long way since then. Maybe they’d reconsider if the community brought it back up

The django-stubs package is decent though

This is me. Software developer by day, endless diyer and hobby starter by night (at least on nights when I’m not dissociating on the couch)

Right, the amount of times I’ve had to put breakpoints in Django/DRF code to figure out what’s causing that weird undocumented behavior is concerningly large

It does, but most style guides and autoformatters will use 4

I can’t believe we still have to justify writing unit tests to management in the year 2024

Nah, hackthebox and many other red team simulation type sites have strict rules of engagement. You’re there to solve a puzzle as defined by hackthebox, not get around the puzzle by hacking hackthebox.

The amount of people who say they do agile/kanban/scrum but have never talked to a customer/end user, let alone released something, is frightening

You don’t necessarily need types for that kind of thing though, a strict linter that flags that code works just as well

We used to do this with thumb drives. You can get a 128G usb3 thumb drive these days for like 20 bucks in the checkout line of most electronics stores. Cool things about a thumb* drive is I don’t need to pay a subscription fee for it, it doesn’t need an Internet connection, and it isn’t liable to be rifled through by Microsoft unless Bill Gates comes to your house and steals it from you.

we struggle getting wifi to work

No we don’t

Don’t put words in my mouth.

a more sensible default would be -A

No it wouldn’t. You’d have git beginners committing IDE configs and secrets left and right if -A was the default behavior.

vim, less a text editor and more a cruel joke of figuring out how to exit it.

Esc, :, q. Sure it’s a funny internet meme to say vim is impossible to quit out of, but any self-respecting software developer should know how, and if you don’t, you have google. If you think this is hard, no wonder you struggle with git.

it chose defaults that made sense to the person programming it, not to the developer using it and interacting with it.

Just because you don’t like the defaults doesn’t mean they don’t make sense. It just means you don’t understand the (very good) reasons those defaults were chosen.

Git has a steep learning curve not because it’s necessary but because it chose defaults that made sense to the person programming it, not to the developer using it and interacting with it.

Git’s authors were the first users. The team that started the linux kernel project created it and used it because no other version control tool in existence at that time suited their needs. The subtle implication that you, as a user of git, know better than the authors, who were the original users, is laughable.

git add with no arguments outputs a message telling you to specify a path.

git commit with no arguments drops you into a text editor with instructions on how to write a commit message.

git push with no arguments will literally print the git push --set-upstream command you need to run if your branch has no upstream.

Again, I recognize that git has a steep learning curve, but you chose just about the worst possible examples to try and prove that point lol.

I am not doing anything complex with it

So basic, well documented, easily understandable commands like git add, git commit, git push, git branch, and git checkout should have you covered.

the CLI surface area that’s exposed to me is by and large nonsense and does not meet me where I’m at

What an interesting way to say “git has steep learning curve”. Which is true, git takes time to learn and even more to master. You can get there solely by reading the man pages and online docs though, which isn’t something a lot of other complex tools can say (looking at you kubernetes).

Also I don’t know if a package manager really compares in complexity to git, which is not just a version control tool, it’s also a thin interface for manipulating a directed acyclic graph.

There are tons of wrappers for git, but they all kinda suck. They either don’t let you do something the cli does, so you have to resort to the arcane magicks every now and then anyways. Or they just obfuscate things to the point where you have no idea what it’s doing, making it impossible to know how to fix things if (when) it fucks things up.

The best part is they don’t understand the cost of that retraining. The non-engineer marketing types in my field suggest AI as a potential solution to any technical problem they possibly can. One of the product owners who’s more technically inclined finally had enough during a recent meeting and straight up to told those guys “AI is the least efficient way to solve any technical problem, and should only be considered if everything else has failed”. I wanted to shake his hand right then and there.

Seriously, ask yourself, how often did the need arise to look into old commits

Literally every single day. I have a git alias that prints out the commit graph for my repositories, and by looking at that I can instantly see what tasks my coworkers are working on, what their progress is, and what their work is based on. It’s way more useful than any stand-up meeting I’ve ever attended.

I’ve been in the industry for a few years now and I can literally count on one hand how often I had to actually look at commit history for more than maybe 10 commits back.

I’ve been in the industry for nearly 15 years, but I can say that the last 3 years have been my most productive, and I attribute a lot of that to the fact that I’m on a team that cares about git history, knows how to use it, and keeps it readable. Like other people have been saying, this is a self fulfilling prophecy - most people don’t care to keep their git history readable, so they’ve only ever seen unreadable git histories, and so they think git history is useless.

I honestly don’t see a use case that would justify the overhead.

What overhead? The learning curve on rebasing isn’t that much steeper than that of merging or just using git itself. Take an hour to read the git docs, watch a tutorial or two, and you’re good to go. Understand that people actually read your commit messages and take 15 extra seconds to make them actually useful. Take an extra minute before opening an MR to rebase your personal branches interactively and squash down the “fixed a typo” and “ran isort” commits into something that’s actually useful. In the long run this saves time by making your code more easily reviewable, and giving reviewers useful context around your changes.

It’s always just “but what if X, then you’d save hours!” But X never happens or X is caused by a fucked up process somewhere else and git is just the hammer to nail down every problem.

No, having a clean, readable git history literally saves my team hours. I haven’t had to manually write or edit a changelog in three years because we generate it automatically from our commit messages. I haven’t had to think about a version number in three years because they’re automatically calculated from our commit messages. Those are the types of things teams sink weeks into, time absolutely wasted spent arguing over whether this thing or that is a patch bump or a minor bump, and no one can say for sure without looking at diffs or spinning up multiple versions of the code and poking it manually, because the git log is a tangled mess of spaghetti with meatballs made of messages like “finally fixed the thing” and “please just work dammit”. My team can tell you those things instantly just by looking at the git log. Because we care about history, and we keep it clean and useable.