DEV Community: ᴙɘɘᴙgYmɘᴙɘj

Pattern Matching in Elixir

ᴙɘɘᴙgYmɘᴙɘj — Fri, 11 Jun 2021 12:22:07 +0000

reposted from https://reergymerej.github.io/blog/2021/06/11/pattern-matching.html

When discussing pattern matching in Elixir (and other languages), it seems like most of what people talk about isn't the actual matching part.

Pattern Matching

Pattern matching is the ability to check if the left and right match.

iex(1)> 1 = 1
1

iex(2)> 2 = 1
** (MatchError) no match of right hand side value: 1

It is sensitive to data types.

iex(1)> [] = []
[]

iex(2)> [] = {}
** (MatchError) no match of right hand side value: {}

It checks the shape of the data as well.

iex(1)> {1} = {1}
{1}

iex(2)> {} = {1}
** (MatchError) no match of right hand side value: {1}

It can be used to branch code.

case 1 do
  1 -> "one"
  2 -> "two"
end
"one"

That's really all there is to it. Everything else is using pattern matching.

Using Pattern Matching

When matching, you can bind values on the LHS.

iex(1)> foo = 1
1

iex(2)> foo
1

This works in cases too.

case 1 do
  foo -> foo
end
1

You can destructure values while binding.

iex(1)> [foo, 2] = [1, 2]
[1, 2]

iex(2)> foo
1

You can ignore parts of the data.

iex(1)> [foo] = [1, 2]
** (MatchError) no match of right hand side value: [1, 2]

iex(1)> [foo, _] = [1, 2]
[1, 2]

You can use underscore as a wildcard when branching.

case "bitch" do
  "cops" -> "yep"
  "critics" -> "yep"
  "paparazzi" -> "yep"
  _ -> "ain't one"
end
"ain't one"

And finally, the ever-popular splitting of head/tail of a list.

iex(1)> [head | tail] = [1, 2, 3]
[1, 2, 3]

iex(2)> head
1

iex(3)> tail
[2, 3]

Find and Replace a Bunch

ᴙɘɘᴙgYmɘᴙɘj — Thu, 03 Jun 2021 02:00:51 +0000

Reposted from original article

Say I'm writing a journal and want to make sure I'm not leaking names. I'd like to change it consistently so it's anonymous, but still makes sense.

Instead of this

John force-pushed to `master` for some reason.  Harold didn't pull before he
added his fix and Betty ended up cherry-picking into yet another branch.  To
avoid this, next time we could...

I'd like this

Farmboy force-pushed to `master` for some reason.  Jimmybob didn't pull before
he added his fix and Horsenator ended up cherry-picking into yet another
branch.  To avoid this, next time we could...

Find-and-replace is what I want to do, but consistently and repeatedly (and quickly!). sed is the tool for the job.

First, define the replacements in files named encode and decode.

Encode

s/Betty/Horsenator/g
s/Harold/Jimmybob/g
s/John/Farmboy/g

Decode

s/Horsenator/Betty/g
s/Jimmybob/Harold/g
s/Farmboy/John/g

Replace

Then to replace, we use one of

sed -i "" -f encode journal.md
sed -i "" -f decode journal.md

Obviously, we don't want to keep the encode/decode files with the output, but you get the idea. You can also send a whole bunch of files through sed with this set up. Maybe you could add a build step that cleans up content or something.

This article gives explains a few more basic sed options that may help you get started.

You can find an example here to play with.

One-Handed Vim

ᴙɘɘᴙgYmɘᴙɘj — Mon, 08 Jul 2019 19:41:02 +0000

Vim takes a lot of dexterity and practice. Speed comes with time and a lot of muscle memory. It's a big investment, but worth it.

And then you break your hand.

That's OK. You can still work at a decent pace. Here are some tips.

Macro Everything

Basic

First, add a macro to edit and to source your vimrc. You will need to edit it a lot.

" edit this file
:nnoremap <leader>ev :vsplit $MYVIMRC<cr>

" re-source this file
:nnoremap <leader>sv :source $MYVIMRC<cr>

Going forward, you can open, change, save, and source your runtime config in no time.

Add mappings for write and quit.

:nmap <leader>ww :w<cr>
:nmap <leader>qq :wq<cr>

Common Structures

As you're writing code, you will recognize structures you use a lot. Add insert mappings for them. For example, in insert mode, if I want to reduce an array, I can type ...

foo.rrr

and it will be swapped with

foo.reduce((acc, value) => {
  return {
  ...acc,
  }
}, {})

Take the time to write these. You'll have to goof around to find what you like, hence the quick source thing we did at the beginning. Here are some I'm using for JavaScript.

" insert if block
" if () {
"
" }
:imap iii if () {<cr>}<esc>kwa

" insert braces
" {
"
" }
:imap {{{ {<cr>}<esc>O

" insert brackets
" [
"
" ]
:imap [[[ [<cr>]<esc>O

" insert arrow fn
" () => {
"
" }
:imap ((( () => {{{return

" map loop
:imap .mmm .map((item) => {<cr>return item<cr>})<esc>kA

" reduce loop
:imap .rrr .reduce((acc, value) => {<cr>return {<cr>...acc,<cr>}<cr>}, {})<esc>kkA

" console
:imap ccc console.log()<esc>i

Efficient Moving

Take a moment to think about what you're navigating to. Lazy kkkkkjjjjkj crap doesn't work well in one-hand mode. Look at relative line numbers. Move to them properly.

Go up 17 lines with 17k.
Go to the next r with fr.
Go to the first blank line above you with {.
Go down 3 folds with 3zj.

Brush up on your movements a bit and take the time to do them correctly.

Use <C-o> and <C-i> a lot. As you hit the wrong keys, you'll bounce around a lot. These take you back or forward.

Don't be a purist. Sometimes the mouse is faster, especially when you're
confused.

Avoid Typing

Especially if you're typing really long entity names, use ctrlp.vim or something to auto complete for you. This avoids typos and can be much faster. This includes when opening files.

Slow is Smooth, Smooth is Fast

That's an Infantry motto that applies well here. I'm going to take these next many long weeks to practice deliberate movement and optimizations. Yeah, it will suck, but I'll come out the other end even faster.

Do Whatever You Want, So Will I

ᴙɘɘᴙgYmɘᴙɘj — Wed, 03 Jul 2019 04:36:40 +0000

tl;dr

Moving toward the creative side may result in more shit, but neat things can grow out of it.

While writing an article explaining why spreading props to React components is a bad idea - and it is - my hairline receded, white hairs appeared in my beard, the music around me became too loud, and no one's clothes made any damned sense.

Technically, all that stuff happened slowly over many years, but I suddenly saw it as I prepared another shit talking session about all the crap code I've run into in the wild. What the hell? When did I become so fucking cranky?

Yes, if everyone did things a certain way, everything would be fine. Fine-ish. It may be stable, but without crazy ass innovation. We would have a world of very resilient, performant spreadsheets.

But I certainly didn't start writing code because of a desire to take up the cause of the clean code brigade. I couldn't have given less of a shit. I had an idea that I wanted to present and the tool to do it was code. Over time, possibly because of pursuing a career in code and not the artifacts I once used them for, I've become obsessive over the freaking tools. Like some crusty, psycho carpenter sharpening and organizing blades, forgetting about the freaking cabinets he was supposed to make.

"Listen up! If you want to make cabinets, you need to stop and learn your tools. I mean really learn them. Learn care and maintenance, learn other tools you can use to make these tools better, and go around making sure others use their tools right. If you're interested, I've written a lot about how to use these tools. I've even made tools that can make other tools. If people would just use the right freaking tools, all the cabinets would be perfect."

Meanwhile, some asshole using a chisel as hammer whacked together 16 cabinets.

Who cares? Let people suck.

Wild analogy shift in 3...2...1

When trying resuscitate a weed-infested lawn, you may be tempted to run straight to the weed killer. That will kill the weeds, but has a negative overall effect on the lawn's health. This results in a weaker lawn, which is more likely to sprout weeds.

Adding poison is a negative action.

A better reaction is to focus on nurturing the lawn. Add phosphates and shit. That will make the grass healthy, which will flourish, and not give the weeds anywhere to hang out.

Adding fertilizer is positive.

This pattern comes up a lot in life. Pessimism and overall negativity are not creative. And writing software is - hold onto your planning meeting notes - a creative process. Meetings and story points and micro-managing dickbacks may have slowly sucked the life out of it, but I started doing this because it was another art form and pretty fun.

I've stashed my cranky article for now.