I find I am frequently removing sections of inscrutable “vectorized” NumPy code that is inefficient, not because NumPy is inefficient but because conforming the data to a structure amenable to NumPy is too inefficient in the first place, and rewriting in straightforward, simple Cython functions.
Also the next maintainer will thank you for it.
To be clear, this is not meant as a critique on C, on the contrary. Put simply, it is just that making computers do stuff is hard. This is especially true if you want it to do it in a very particular way such as in high-performance code. If you cannot already leverage the work of other experts, you need to know about modern optimizing compilers, language runtimes, modern processor architectures, OS/system, ...)
To continue your Numpy example, that framework entombs the know-how and man-years of work of specialist in a certain area. If you need to do simple dense algebra, you will a hard time beating Numpy/Julia/Eigen/MKL etc. If your problem goes slightly off-track (e.g. sparse problems) where you cannot easily leverage the hard work and expertise of others, you better start rolling up your sleeves and open that main.c
With more experience you'll find that certain operations are easier with particular workflows.
Git vs other ... well, Subversion is the standard. I'm not getting paid to move repositories on a whim. I have to make a business case ... etc. Guess what, I've got better things to do (i.e. do things that make money) than chase the newest shiny thing.
Sometimes a multi-hundred line git dump works and sometimes it doesn't. In some workflows the GUI scans better. e.g. pick out the hot spots in functions.
- learn a basic workflow and ask/google for help for problems. A gui makes this slightly easier
- learn the underlying model for git. Then you probably still have to google for invocations occasionally but you would have to do the same with a sugary gui. And for complex actions in a gui the answer usually is 'use the cli'
Plus occasionally a gui does something incredibly weird like giving direct access to `git clean --force` like vs code did a while back.
I like git, but the cli is only usable after a dash and a spoonful of aliases.
Other commands like stash, checkout and branch are equally simple. It’s just a very simple user experience.
I think where people express confusion over git is that they don’t expect to be interact with revision history, rather just inflicting changes onto a head-only svn style repo.
People are mistakenly encouraged to bring that mentality to the table when it’s not useful. You need bring a mentality that you’re mutating and sculpting branches.
It’s like a beginner saying “snowboards are complicated” because they come in expecting it to be like a sled. You hear the same complaints about other systems like darcs and mercurial too, for the same reasons, even though each of those offers respectively super easy to use cli experiences as does git.
Once you grok rebasing branches, git add, push, pull, bisect, rebase, log, commit --amend are all I have needed to work with Git and the experience has been far better than working with any other version control like SVN or Mercurial.
Ok, so they are the simple because you say so? Stash in all but the simplest cases is a sure-fire way to shoot yourself in the foot. Checkout is a weird guy, he does too many different things, and what's up with the double dashes? Super-weird! Also beware that any of your branch names happen to match any of the file names in the repo :O.
> I think where people express confusion over git is that they don’t expect to be interact with revision history
This is one of the things that confuses beginners about git, but it's not a confusion about git cli. You are conflating the criticism of git cli with criticism of git. Git is good, git cli is (notoriously) bad. However, eventually you'll (hopefully) learn the proper incantations and then using git cli will seem simple to you.
> “You are conflating the criticism of git cli with criticism of git.”
Not at all. I’m saying most of the time when people say they are confused by git cli, that it behaves counter to their expectations, they are not actually expressing any design limitation of the cli commands themselves, but instead blaming cli commands for the conceptual confusion they have about git’s model in general.
To generalize, I have the impression that the general CS/programmer culture values initial easy of use much more than long term usefulness. And that's not directed at the younger generation, you will find plenty of old farts that only want to use or learn git when it's been thoroughly lathered the thick sugary syrup of a pretty GUI.