Earlier quoted context omitted.
Another one, not quite as handy but still awesome: ctrl s / ctrl-q. This freezes/unfreezes the terminal output so you can read it, without interrupting your program. Useful for very fast walls of text.
Oh so that is what this is for. I thought ctrl-q / ctrl-s are there as a nasty way to screw with users, who every now and then accidentally press one of these, and find their terminal frozen and no longer visibly reacting to input, for no apparent reason.
Small programming tricks
211–220 of 235 posts
Re: Small programming tricks
#212The thing with a lot of these tricks is that you have to get into the habit of using them. I knew `Ctrl+r` for history since I learned about the command line. I even have a nice shell integration with fzf. But I still used the up/down arrow keys for years or scrolled up when I was looking for a previous command, because I never remembered the shortcut and just took the path of least resistance to find something. Usua…
Bonus: if you write all your tricks in a document, people will love your document. Whenever I offer a new student my CHEATSHEET.md file, their eyes absolutely light up.
Re: Small programming tricks
#213Earlier quoted context omitted.
I’ve read that if you’re trying to overturn a habit with a new habit, it’s best to undo whatever it is you did the old way, then redo it the new way. So if you want to use ctrl-r, but you’re using the up key, use the down key to navigate back to a clear line, then use ctrl-r. Do it enough times and your brain will work overtime to find a shortcut (aka just doing it the new way).
Temporarily binding the up arrow in the shell to echo "Use Ctrl-R" is probably the quickest way to un-/re-learn
Re: Small programming tricks
#214Earlier quoted context omitted.
I'm struggling to comprehend how branches can be avoided (or why one would want to, as they are the cornerstone of programming). I can only think how to obfuscate them, which is rarely useful.
What people refer to when they say "branchless code" is something very particular, and it refers to not triggering the CPU's branch prediction. That is, don't make the CPU have to guess which fork in the code you're going to take. This is usually accomplished in one of two ways: either bit twiddling hacks or specialized instructions that do not affect the CPU's branch prediction, such as the 'cmov' family in x86. If…
vector conditionmask = ; // E.g., 11111111 00000000 00000000 11111111
vector truebranch = ;
vector falsebranch = ;
vector result = (truebranch & conditionmask) | (falsebranch & ~conditionmask);
where each lane of the conditionmask has either all bits set or all bits clear, depending on the outcome of the conditional test for that lane.The processor obviously does execute both branches here, so there's going to be wasted work. But since it's just a linear sequence of operations it can often schedule them independently and run them out-of-order and in parallel. And of course, if there's any shared computation between the two branches, the compiler can do common subexpression elimination.
That said, that sort of approach where you go ahead and do both and then blend them was definitely the kind of optimization where you'd want to profile rather than doing it blindly. But it was a pretty common thing to do when hand-vectorizing code. (Thankfully, auto-vectorizers are pretty good at doing this sort of optimization for you these days. It's been a very long time now since I've had to hand-write vector intrinsics.)
Re: Small programming tricks
#215I would love for someone to package up some kind of script or AI skill that evaluates your current terminal config/set-up and applies all of these tips and tricks. For instance, it might detect that you currently use ag, install ripgrep, and offer a short tutorial on how users accustomed to ag should use it. Or it might look at the history of git commands you've run and offer tips on efficiency improvements.
Re: Small programming tricks
#216I always wanted the same for Vim, zsh, etc.
Re: Small programming tricks
#217Good one. :(){ :|:& };:
https://en.wikipedia.org/wiki/Fork_bomb
(See in particular the "Implementation" section where there's an explanation of how it works)
Re: Small programming tricks
#218Earlier quoted context omitted.
I've relied on this so much that I copy my entire history between machines...
Self hosted Atuin would do this for you too. Unless you don't want the added tooling/complexity
Re: Small programming tricks
#219I remember when I was using JetBrains IDE they had this feature that would list all shortcuts and IDE features and how frequently I use them. This was excellent for feature discovery. I would regularly check it out and scroll to the list of features I never used and try them. I always wanted the same for Vim, zsh, etc.
Re: Small programming tricks
#220I remember when I was using JetBrains IDE they had this feature that would list all shortcuts and IDE features and how frequently I use them. This was excellent for feature discovery. I would regularly check it out and scroll to the list of features I never used and try them. I always wanted the same for Vim, zsh, etc.
Do they still do this? I'm using PyCharm daily but have never seen it. Would indeed be pretty cool!