Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Small programming tricks

will-keleher.com

Post reply on HN
Print view View original

171–180 of 186 posts

Re: Small programming tricks

#171

Post by wild_egg »

lelandbatey wrote: post #150
phforms wrote: post #77

The 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…

It's quite true. Years ago, after `git switch` was released, I wanted to try to switch from `git checkout` to `git switch`. Ultimately I had to set up some bash nastiness to error and "scold" me when I typed `git checkout` from memory, while still allowing shell scripts to call `git checkout` just fine. It was a fun exercise, and at least now I know how I could do it again: https://github.com/lelandbatey/dotfiles/blo…

What's the point of switching to switch? I've only ever used checkout and not sure what I am missing out on.

Re: Small programming tricks

#172

Post by zem »

dec0dedab0de wrote: post #124
phforms wrote: post #77

The 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…

I was my most effective when I had a bunch of cheat sheets taped up in my workspace.

reminds me of the time when you got strips of fn key binding cheat sheets for various popular software packages like lotus 123 and wordperfect, and keyboards came with a space to hold them.

Re: Small programming tricks

#173

Post by zem »

ChickeNES wrote: post #109
quirino wrote: post #93

Earlier quoted context omitted.

atuin kind of fixes this habit, when you click up you get a list of the latest commands, and you can just start typing to search. It's extremely natural.

I found atuin way too hard/slow to use, I think I went two days before I nuked it and went back to pure omzsh. Has it gotten any better in the past 2ish years?

I've been using it happily for longer than that! I do remember having to tweak the default search behaviours when I first installed it but it's been largely problem free ever since.

Re: Small programming tricks

#174

Post by zem »

throwaway219450 wrote: post #99
kccqzy wrote: post #38

A lot more tricks can be learned from just watching AI work. Instead of allowing AI to work autonomously, go back to the old days where you manually approve every command the AI runs. Just recently while doing performance optimization work, I found Opus using the `perf` command in ways I didn’t know possible. Just give AI a real task and carefully read what commands are used by the AI to solve the problem; most likel…

There are several keyboard shortcuts that you would never find out from watching an agent, but are mindblowing to new Linux users. I suck at remembering vim keybindings, but I have ingrained ctrl+a ctrl+e for jumping to the start/end of a string (which also works all over OS X). I had been a developer for an embarassing amount of time before I discovered those. There are other terminal specific shortcuts for removing…

ctrl+u and ctrl+k (to delete the line forward/backward from the cursor) are super useful too

Re: Small programming tricks

#175

Post by zem »

TeMPOraL wrote: post #126
gosub100 wrote: post #116

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.

there was an old riddle I saw on usenet, "there is a key I use for one of its intended purposes several times a day, but when it stopped working I never missed it. what key was that?". the answer was the caps lock key, one of whose intended purposes was reverting back to normal after accidentally pressing it to go into caps mode.

Re: Small programming tricks

#176

Post by RhysU »

GNOMES wrote: post #125

Simple trick I use almost daily for navigating backwards to an exact directory: https://gist.github.com/GNOMES/6bf65926648e260d8023aebb9ede9... I use this often instead of chaining together multiple '../..'. Also nice for when I use Zoxide to CD into a deep nested directory. I quickly found out unless you manually CD each hop, the different parent directories aren't added to your Zoxide DB. (I have come across snippi…

Abbreviate moving up in the directory hierarchy:

  alias ..="cd .."
  alias ...="cd ../.."
  alias ....="cd ../../.."
Just keep typing period and hitting enter until you get where you want according to your prompt. I haven't found much use for more than four periods. One period would be well-defined but useless.

Re: Small programming tricks

#177

Post by GuB-42 »

winternewt wrote: post #100
robby_w_g wrote: post #55

Earlier quoted context omitted.

Yeah, I don't buy the premise that branchless code is intrinsically easier to understand. Maybe OP's point is that adding unnecessary branches makes code harder to read? But that's generally the case for any unnecessary code.

I see stuff along the lines of: if (x == 0) { return y; } y += 25*x; return y; and skipping the if just makes the function shorter and simpler, while also not involving the CPU branch prediction. Another one that doesn't necessarily skip all branching but at least drops one - and more importantly makes the code simpler and easy to verify, is removing the if statement in code like if (count == 0) { return; } for (int…

Both of your examples are optimized by the compiler (gcc 16.1 -O3).

In the first case, the compiler removes the first if/return

In the second case, if you don't have the first if/return the compiler will add it. That's because it will actually convert your loop into a do/while, with the test in the end, because it is more efficient. But it has to handle the count == 0 special case first, so it will do that early return even if it is not explicitly there.

That's the kind of optimization modern compilers are good at.

Re: Small programming tricks

#178

Post by nulltrace »

forty wrote: post #138

> In NodeJS, you can keep a connection open to an external resource by creating an https.Agent and then providing it to your http requests: fetch(url, {method, agent}). This can have a dramatic impact on latency. Is it true that you can pass a nodejs agent to fetch ? I don't think so

No. Node's built-in fetch uses Undici. The custom hook is dispatcher, with an Undici-compatible dispatcher: fetch(url, { dispatcher })

Re: Small programming tricks

#179

Post by RSHEPP »

jamiejquinn wrote: post #147
FlyingSnake wrote: post #40

Earlier quoted context omitted.

I’m lazy so With fish, I just type a part of the command and press up few times to get to where I want. There’s also fish-fzf.

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

#180

Post by computermadeofc »

It’s sad, I used to love little tricks like this: optimizing my workflow, learning the keyboard shortcuts, reading the manual. But now I just prompt codex or cc. The appeal of “sharpening the axe” is greatly diminished. I fear much of this type of knowledge will soon be lost to time.
Post reply on HN