Live data from Hacker News

Small programming tricks

will-keleher.com

241–250 of 250 posts

Re: Small programming tricks

#241
post #174

Earlier quoted context omitted.

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

ctrl+u generally works for lots of password prompts to reset/remove what was typed, wherever you come across a password prompt and a keyboard including those two keys.

Re: Small programming tricks

#242
post #151

Those were not programming tricks, but computing tricks or command line/sql tricks. Anyways I find it mind boggling how many useful actions are not known by „normal people”. Most people are really using computers in a very inefficient way. My idea is if we would spend time making people learn computers or software they use daily better - we wouldn’t need AI agents and we would triple GDP.

> if we would spend time making people learn computers or software they use daily better - we wouldn’t need AI agents There's no amount of skill/efficiency/productivity a human worker can reach that will make employers give up on the dream of one day replacing them with software. The AI companies looking to profit from renting out the collected works and creativity of humanity certainly wouldn't shut down if the GDP…

> There's no amount of skill/efficiency/productivity a human worker can reach that will make employers give up on the dream of one day replacing them with software.

I agree... but also this is so wrong it's painful. If you do have a good worker, they don't cost money, they MAKE money. Of course if you as the CEO think you are smart enough to cover everything and anybody but you is just wasting money, then that doesn't work and optimizing makes sense. Corporations have grown in size to be mindless heartless engine, literally, and that comes at the heavy price of ... not thinking, just an automaton with a single goal, growing profit, leading to an even more inhumane setup within which removing costly humans makes perfect sense.

Re: Small programming tricks

#243
My bash terminal starts with my own shortcuts and

     ^a         ^e       \
      } Moving
    alt-b    alt-f       /
            /
       ^b    ^f        /
         z 
$ cp monfi[c]hier dir/

     
     ^w     alt-d       \
     } Erasing
     ^u         ^k      /
precisely because combinatorial mindset and efficient navigation are so important to my workflow.

PS: visual adapted from https://gist.github.com/tuxfight3r/60051ac67c5f0445efee

Re: Small programming tricks

#244
post #57
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…

> “the old days” Is this just plain old rage baiting? I literally can’t tell any more.

I find it a valid statement.

IT was always fast, and I explained my students what IDE cable was and they don't even knew about SWAP because they never had memory issues.

Re: Small programming tricks

#245
I think it's wise to be a bit deliberate when turning on globstar in bash. The main cost is occasional slowness on big trees. It's OK to turn it on for general purpose things, but for scripts the bigger concerns are portability and the possibility of unexpectedly broad expansion.

Re: Small programming tricks

#246
In case you were confused about the logarithm trick, here's what I think it's trying to say.

This hypothetical system has a bunch of users, belonging to groups. A possibility is that most groups have a only handful of users, but a few famous group might have disproportionate amount of users say 500,000.

If you wanted to put these groups in buckets, you can create linear buckets of fixed size based on number of users like

    bucket 1: 0 to 100 users
    bucket 2: 101 to 200 users
    bucket 3: 201 to 300 users
    ...
    bucket 600000: 599001 to 600000 users
Now the problem is you have way too many buckets, and most of them are probably empty. In situations these "buckets" actually cost you money, you might want to optimise the number of buckets.

So the code converts the user distribution to logarithmic scale:

    const bucket = Math.floor(Math.log10(userInGroupCount))
This essentially creates buckets as number of digits:

   bucket 1: 0 to 9 users
   bucket 2: 10 to 99 users
   bucket 3: 100 to 999 users
   bucket 4: 1000 to 9999 users
   bucket 5: 10000 to 99999 users
   bucket 6: 100000 to 999999 users
With this, you have needed only 6 buckets. Moreover, this probably maps to the real life distribution, so your charts read cleanly.

Re: Small programming tricks

#247

In case you were confused about the logarithm trick, here's what I think it's trying to say. This hypothetical system has a bunch of users, belonging to groups. A possibility is that most groups have a only handful of users, but a few famous group might have disproportionate amount of users say 500,000. If you wanted to put these groups in buckets, you can create linear buckets of fixed size based on number of users…

(you'll have to handle the case where `userInGroupCount == 0` in the code given)

Re: Small programming tricks

#248
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…

Eh sometimes it overcomplicates things. I have seen Opus 5 do mad shell gymnastics for something that could have been a simple `jq`.

Re: Small programming tricks

#249

I am so proud of this (I'm sure others came up with it way before me, but I still came up with it all by myself!) //* normal path /*/ debug path //*/ take away the the first slash to toggle the debug zone ON !

I once took the time to figure these out for all the languages I use

here's python:

    #'''
      normal path
    '''
      debug path
    #'''
when I comment out python code I do it with ''' ... #''' so I can uncomment it with 1 keystroke

Re: Small programming tricks

#250
post #176
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.

I have a shell function called "up" that finds a project root and jumps back to it (e.g. a dir containing something like .git)

Now I have these to complement - thanks!

Post reply on HN