awk is cool (again)

Awk is lately appearing in HN more often.  I quite like awk, but having gone through Perl, bash, awk, I see people praise awk for being a POSIX compliant enhanced scripting language.  And while being true, I don't think this matters much to the commenters. They see it as an improved bash. And I think we're repeating the history.

Shortcomings that people see in bash, or awk, are solved in Perl. But people dismiss Perl for some reason, and they (we) are going to rediscover it in different forms. Perl is so optimized for scripting that it's really hard to beat. And it has a awk-like mode, so you can easily do the "/pattern/ {action}" thing.

 

Still, here are some threads on awk, with mentions to Perl.  I specially liked K (from K&R) awk.help file. That guy knows how to write!

https://news.ycombinator.com/item?id=28707463

https://earthly.dev/blog/awk-examples/

https://www.cs.princeton.edu/courses/archive/spring19/cos333/awk.help

 https://ferd.ca/awk-in-20-minutes.html

https://www.gnu.org/software/gawk/manual/gawk.pdf

http://www.cs.unibo.it/~sacerdot/doc/awk/nawkA4.pdf

https://ia803404.us.archive.org/0/items/pdfy-MgN0H1joIoDVoIC7/The_AWK_Programming_Language.pdf

Shell Tricks: ripgrep -U and $(!!)

Because learning the tools is an ongoing task, just two simple helpers for your daily terminal usage:

Finding matches in two consecutive lines. I used to do that in Perl, using multiline matches, but it involves remembering the Perl one-liner incantations....

 Well, I found that rg -U enables multiline matches, so you can do stuff like:

rg -U 'doseq.*\n.*deftest' test

To find tests wrapped in doseq.

Another cool shell trick I discovered by myself was $(!!).  

I have this helper function that greps my $HISTFILE, to find old usages of commands. I use it like ctrl-r, sort of:

rg --no-filename "$@" ~/.zhistory

I use it sometimes with fzf, and many times, when I select the commad, I realize I want to run it.  Well, there are more optimal ways to do it (fzf can run the command), but I liked discovering $(!!), that reruns your last command (the rg ..|fzf), and will run its output.

The “Two-And-Done” Rule

This one is something that depending on the moment your think about this you might agree or disagree, and it's like those optical illusions that when you think "right" the images rotates to the right, and when you think "left", it does to the left.

The principle of "two and done" is a guiding tenet to keep yourself sane, on your toes, and put things on perspective to not give an unwarranted amount of importance to things that do not have them. 

Even is "someone is wrong on the internet", knowing when to stop arguing can feel like "not driven enough" on my side, but it can feel also like a liberating proactive empathic way to problem solving.

So the Two-And-Done rule was born, wherein I will state my case the first time, and if whoever is arguing to the contrary does not agree after hearing my position, I’ll let it go. But the next time the opportunity comes up, I will argue my point again. Maybe allowing for a gap of time for people to consider my original point, or maybe allowing me time to refine and rephrase my ideas to be more convincing.

If I fail to get my way after the second time though, I am done. I will even say as much to whomever I am debating if they are the final decision-maker. I will say something like, “OK, let’s go your way then. I still don’t completely agree with everything proposed here, but I think I’ve made my case, and we need to move on.”

Yielding in an argument like this has some weird, powerful effects. One is, it kind of releases you from responsibility if things should go wrong. And if a truly bad decision has been made, it is actually pretty likely that things will start going wrong. (Important Note: If you fail to convince people after two tries, you really do have to get behind the decision, and not try to sabotage or undermine it)

 

The pretty important part is that you have to get behind the decision.

 

Good Job Aaron

Today I read this HN thread about YJit and Tenderjit that is a great lesson, and there's a comment there, someone describing some traits of his. I'm quoting it here just to read it from time to time when I review my posts:

I've had the pleasure of meeting Aaron at a number of ruby confs. He's supportive from the largest all the way to the smallest.

My personal favorite thing he'll do is ask conference speakers questions that make the speaker look good/best-light-possible. Something slightly technical/challenging, not fully covered in the talk but definitely something the speaker can handle.

To be able to do this consistently means he knows the topic better than the speaker themselves (at least this has been true when I've been there).

This is in contrast to people who ask "gotcha" questions. Spend 3-4 minutes showing off their knowledge and then finally getting to the question which is to stump the speaker. I hate these kinds of people at conferences the most.

 

Shouldn't be hard, right? supporting people and trying to make them feel engaged and well about what they do, let people shine without having to point out that "actually,....", or "as I said in an earlier thread....", or ... you know.... 

Caught by a regex

I'm a big fan of regexes. 

I've not found yet a DSL that has proved so useful in so many situations (text handling, really).

But today, I got caught by something I didn't know, and that totally escaped me. It's not even in the sense of "now you have 2 problems". Because the problem at hand was perfectly suited for regular expressions. no capturing, no grouping, no back references, no (negative)?look(ahead|behind). A typo gone wild.

It's about `]`, and the fact that if it's paired with an earlier `[`, the regexp matches any character inbetween them. That's known, and what's also known is that escaping characters inside works a bit different, and also that `-` means "range", UNLESS it's in the first or last position.

But, What caught me today is that `]` (without escaping) works as a literal if there's no pairing `[`. 

• /(/ -> invalid regexp
  
• /)/ -> invalid regexp
• /[/ -> invalid regexp
• /]/ -> fine. O_O
  

This is so foreign and arbitrary I couldn't really believe it. I don't know if there's a deeper reason for this being this way, but I can't find a reason why it couldn't behave the same way as grouping parenthesis.

This was cascading from a regex like /[`~! @#$%\^&*()_+={\[}]|:;\"'<,>.?\/-]/ .

It is intended to check that there's at least 1 symbol in a string.

If you look closely, there no escaping for the ] in the middle, the regexp is still valid, but the bracketed part is smaller than what you'd think.  And it doesn't fail to compile the regex.

But to make things worse, just after the ']', there's a pipe symbol (because they are close in the keyboard). and now, this symbol is not treated literally anymore, but it counts as an alternative choice.

With this, what do we have here? 

The regexp matches either one of [`~! @#$%\^&*()_+={\[}] bracket, or the string ':;\"'<,>.?\/-'. This made it even more difficult to find, because some validations passed, while some didn't. If it wouldn't be for the '|' being just after ']', all validations would have failed.

Well... 2 level fuckup from a single regexp due to an missing backslash and the US keyboard layout.

How many problems do I have now?

7GUIs examples

I discovered 7GUIs from a guy in HN that posted his plain vanilla html/js/css implementations https://news.ycombinator.com/item?id=28600804 . 

The HN comments have some good insights on when DIY is no longer sustainable. And in the case of web development, it falls appart pretty early.

On my personal front end adventures, I'm trying material-ui, which I think combining react with that might actually alleviate a lot of the pains when developing a frontend as an "I-dont-care-much-how-it-looks-like-as-long-as-it-looks-okish".

I also liked tailwind a lot, but it's lower level, and really, I-dont-care-much-how-it-looks-like-as-long-as-it-looks-okish.

 

 Also, Look at the Red implementations of the GUIs. Amazing

Small little grep+edit trick

This is so small, but so huge....

It's like many other finders you find in your editor of choice, but because it's such a generic and minimalistic tool, I keep up using it tenths of times a week.

Idk, this is more composable and functional and succinct than many things I find in the wild that claim to be so. 

And it is damn useful!

Also, even it's 4 lines of code, there's probably a thing or two you can probably learn from those. Here are some things I like and why I think it's High Quality Shit:

- It's short, you can inspect the words  it contains, and if you get more or less the programs it calls, it can only do one thing.

- It solves a real problem

- It has high density. All words there mean something, there's 0 boilerplate

- It is composed of smaller parts. It feels Forth-y

- The way it's composed is subtly nice (the existence of "e" function is needed to compose it that way)

- It's as configurable as the program it uses to grep. It inherits its flags

- It inherits its auto-completions

- You can learn a bunch of things from it

- It fits in your head

- It has that Iversonian "suggestivity"

- I wrote it, so it has that IKEA effect on me

Many more things like that in https://raimonster.com/scripting-field-guide/

Oh! I found https://github.com/junegunn/fzf/blob/master/ADVANCED.md#ripgrep-integration which is an even more advanced version of it. Not as cute though