I’m on the Elixir Fountain Podcast!

Elixir Drop records a podcast with Elixir Fountain

Recorded on Wednesday, today sees the release of my conversation with the ever-amiable Johnny Winn on the topic of Elixir. And Phoenix. And Perl. And Ruby. I may have even mentioned Haskell at some point in there. We cover a lot of stuff. (And then we talked comics, naturally.)

It was only afterwards that I realized I’m a complete blabbermouth and didn’t go too deep on any one topic and likely will need to explain myself at length on a couple of things after the fact.

In other words: More blogging material! =)

But if you have any questions, leave a comment or send me a tweet, and I might just make a post here out of it. Thanks!

The Joy of C

I don’t like C. I know why it’s good and why it’s important to know. I took the class in college. I’m just saying it’s not fun.

my college copy of The Joy of C

Here’s my college C textbook. Note the sad face in the middle. And I think that’s the word “skipping” scrawled in the appropriate place in Sharpie.

Like anyone new to programming at that level, pointers drove me nuts for a semester. I get them now, but I also haven’t had to use a pointer to a pointer since college. This makes me happy.

Core Elixir: List Module Misc.

Core Elixir looks into the List module and finds Erlang wrappers, test-driven development, and the joy of tuples.

We’ll be dipping a toe into the List module waters today…1

Elixir Drop dips his toe into the water

In researching modules and functions for Core Elixir, I often come across dead ends. These are the functions that don’t go very deep and that aren’t very interesting for a Core Elixir article.

The #1 cause of this is Erlang functions that are called directly by Elixir just to switch the parameters around so the list or collection comes first. Thanks, Pipeline Operator.

For example:

List.duplicate/2 takes a list and a non negative integer that describes how many times the caller wants to repeat that list. So, to steal the example straight out of the documentation:

iex> List.duplicate([1,2], 2)
[[1,2], [1,2]]

You know how that works? List.duplicate(list, multiplier) calls Erlang’s :lists.duplicate(multiplier, list).

For Core Elixir purposes, that’s a dead end.

That seems simple, but Elixir goes one step simpler:

List.flatten/1 directly calls :lists.flatten/1. It doesn’t even need to swap the order of the parameters around, since there’s only one.

But, wait, you say, there’s another version of List.flatten that has an arity of 2! The second parameter is a value that gets slapped on at the end of the newly flattened list! Does that extra parameter make any difference?

No. List.flatten(list, tail) calls :lists.flatten(list, tail).

The list still comes first. Erlang is inconsistent compared to Elixir in this way.

Purely Functional Looks Test Driven

I like this bit of code, to define List.last, the biggest tongue twister in Elixir’s code base:

  def last([]),    do: nil
  def last([h]),   do: h
  def last([_|t]), do: last(t)

It feels like the way you’d write something when you’re test driving it, doesn’t it? Let’s work through it:

Make it work for the simplest possible case — an empty list. In that case, there’s no making heads or tails of it (ha!), so you return a nil.

OK, so what happens when there’s only one item in the list? The answer isn’t nil anymore. You need to write that case next. The single value is the head AND the last item in the list.

And when you have two or more items? You look for the last value in the list by going through the whole list until you get to the end, recursively. Keep stripping off the head from the list and look for the last of the rest.

As a bonus, the second case now makes more sense. Why is the single value the last value? Because if you started with two or more values, this is the base case. A list with one value would effectively be the most tail item in the list. Pretty nifty.

It’s logic like that that makes me like functional programming. It just feels smart, somehow.

Of Tuples and Keyfinds

List.keyfind/3 strikes me as funny, mostly because it isn’t what I thought it was at first. And then I felt stupid for missing it. Let me assume for the moment that we’re all being honest with ourselves and that all of our minds blank at something ridiculously basic every once in a while. Thanks.

`List.keyfind/3′ calls on the similarly named :lists.keyfind/3, like so:

  def keyfind(list, key, position, default \\ nil) do
    :lists.keyfind(key, position + 1, list) || default

The function takes a list of tuples ( [a: 1, b: 2, c: 3] ), a value that it’s looking for, and which position in each tuple it’s looking for that value.

Here’s the trick to remember: A tuple can have not just two values, but also more or less than 2 values. A tuple is just an ordered list of things. Curly braces surround the list, and the values inside are separated by commas.

Valid tuples:
* {1}
* {1,2}
* {1,2,3}
* {1,2,3,4}

Et cetera. Well, you probably want to use a map after that, instead, but it’s your program. Do what you want.

When you have a two element tuple, it’s not a key and a value. It’s just two values.

I had forgotten that in a list with keywords, the curly braces can be dropped.

iex> t1 = [a: 1, b: 2]
[a: 1, b: 2]

iex> List.first(t1)
{:a, 1}

See? That’s a list with two tuples. Each is kinda sorta key and value, but not really. It’s position 0 and position 1 in a two element tuple. [a: 1, b: 2] is the same thing as [{:a, 1}, {:b, 1}]. It just looks a lot cleaner, so long as you remember that little trick. I’m a little out of practice using it, I guess.

In List.keyfind, the position parameter refers to which value you’re looking at in each tuple, the zeroth or the first, in these cases. For what I think of as the key, I’d always use 0. For what is traditionally the value, it’s a 1.

If I wanted to make a ridiculous pull request to the Elixir core language, I’d offer up positions of :key and :value that are equal to 0 and 1 in two element tuples. (Pro tip: Don’t do it. It’s a silly idea.)

Finally, the last parameter sent to List.keyfind is the default value to return if nothing is found. “Nil” is the default default.

There’s one other gotcha to point out here in this code. Erlang likes to be a 1-based language, while Elixir likes the 0-based values. List.keyfind calls :lists.keyfind, moving the list to the front and adding 1 to the position value to make up for that off-by-one position.

You may all quibble amongst yourself over whether everything should start with 0 or 1. I’ll be over here indenting my code with the tab key just to annoy you.

I’m just kidding. I would never do that. I program in a non fixed width font, so indentations never looks right no matter which keys I use.

Sorry, I’m kidding again. I don’t use a non fixed width font. That’s madness! But this switch to a Dvorak keyboards means d;jdsfo dsmowm ojf of s;ljfy. !


  1. This might just be the best Elixir Drop drawing I’ve done yet. Just sayin’

TIL: List Directories

Unix 101: To make a list of just the subdirectories inside the current directory:

$ ls -ld */

Or, to include “hidden” directories and ALL subdirectories recursively:

$ find . -maxdepth 1 -type d

Of course, you can change the maxdepth depending on how far you want to go into the inner recesses of your file system.

There’s so much cool stuff you can do with the ls command that it’s worth looking up its man page every few months as a reminder…

iPhone Security as a Feature

I thought about this also, but have one rather large, big “but” to add after it:

I don’t think Apple would succumb to that and stop improving their device security, but it shows what an untenable position the government is trying to put Apple in. The only easy way out for Apple, if they lose, is to stop making iPhones truly secure.

But: Apple Pay. That’s the big selling point of a big feature that Apple can’t afford to just walk away from right now. Well, I guess they could, but I’m sure they don’t want to. They just rolled out in China.

China. You know, that place President Obama wants to stop hacking American technology companies, while now asking those companies to make their products less secure and easier for foreign countries to hack…

Welcome Back, WordPress

I plan on making this blog much more active, now that I’ve switched to WordPress.  Writing gigantic pieces like the Core Elixir pieces is informative and fun for me, but there’s a lot more I want to bring up.  I have ideas for other essays as well as shorter posts, sort of in the vain of the currently trendy microblogs.  This new blog engine will make doing that both possible and easy.

This blog began life as an Octopress static blog.  As much as I love the idea of a website that’s just flat static pages, the restrictions that places on creating for it just proved too much.  It slowed me down and often stopped me.  I want to be able to post from my phone, or a computer other than the one at home that hosts all the files and blog engine.

I want better themes.  I want more plug-ins to make the back-end stuff easier.  I want a desktop app to put things together.  I want to do less of the mechanical and technical stuff, and more of the writing.  I don’t want to open a terminal window anymore and change directories and tell rvm what version of Ruby I need to use to get the blog engine rolling. I want to write in a WYSIWYG word processor or text editor.

Now that WordPress has all of that fun stuff on the back-end — including statistics and analytics and social media posting — I’m excited to get back to blogging again.  The old, slow installation of WordPress is ancient memory now.  The modern WordPress is a big leap forward.

This does mean the end of the Github mirroring of posts.  I’ll keep what’s up there available.  As always, if you find an error in one of those older posts, send a pull request.  But, now, you can also just leave a comment. (…until the spammers drive me away…)

I’m excited to write more and have some fun drafts already lined up and ready to edit.  So let’s get going….