Rooting for Google

My first job out of college was as an Oracle database programmer. I love me a good multidimensional database design, where you can slice values off the cube to get what you want.

That has nothing to do with the Oracle vs. Google lawsuit, but I felt like mentioning it.

Larry Page testified yesterday. I loved this back-and-forth:

[Oracle’s lawyer] Bicks asked Page if Google paid Oracle for the use of Java, which was developed by Sun Micro systems in the early 1990s and acquired by Oracle in 2010.

“I think when Sun established Java it was established as an open source thing,” Page said.

Bicks repeated the question.

“No we didn’t pay for the free and open things,” Page said.

Fix Elixir

Elixir is too complicated.

Elixir needs to be fixed.

I think we can all agree with these notions. Have you seen the Elixir-lang mailing list lately?

Having used it for a couple or three weeks, you realize it requires far too much typing — that is, pounding away on the keyboard with your fingers. What it truly lacks is typing — the kind that pre-defines a variable’s content type. We’re going to talk about fixing that shortly.

In this article, I hope to make a few suggestions to fix Elixir to make it better for future generations.

Steel Workers on a construction site to fix Elixir
If you need a change in your infrastructure, try a steel worker. Or three. They can fix Elixir for you.

Elixir Needs Types

For starters, we need to differentiate between data types. But we need to keep this simple so people will use it. I propose three types: Strings, Associative Arrays, and Lists. For simplicity’s sake, we’ll define numbers as strings, also. This doesn’t make sense, but it’s convenient and quick. Also, these types are more about the structure of the data than the contents of them. A string, thus, is a single unit of data without any sort of structure around it.

Current maps are far too complicated with far too many ways to do the same thing. Aren’t we all tired of looking for a value for a particular key by typing in this mess:

iex> example_value = Map.fetch(example_map, example_key)

::yawn::

Why not just have:

iex> example_value = example_map{example_key}

It’s so much more direct.

Fixing Strings

Strings are too complicated. I think we’re all tired of typing in “Hello” and getting back a result like:

iex> "Hello"
[67, 63, 70, 70, 72]

(No, it doesn’t actually do that in iex. This is a dramatization, like that time Dateline NBC blew up pick-up trucks, OK?)

Why not just learn Assembler at this point?

Let’s Unicode all the things and make them all just plain strings, composed of lists of characters.

Separating the Data Types

We need something short and pithy that gives us an easy visual reference to a variable’s data type. Because, right now, in Elixir, map_example could just as easily be a valid map, string, integer, or process id. MADNESS! We all know you can’t trust programmers to name things.

The solution is simple. Use a sigil. Elixir has a few leftover, but I say we just need to go all the way and use whatever we can. Let’s stick with an “S” for a string, an “A” for a list since it’s so similar to an array, and, er, we’ll use an “H” for an Associate Array, which is the same thing as a Hash.

Now, it might be confusing to use letters, so let’s use special characters. The “S” looks a lot like a “$”. The “A” can be an “@”. The “H” can be “%”, which is a bit of a stretch, but I’m running out of options here already. Prefixing with “|-|” wouldn’t work as it looks a bit like a pipe, and we might need that for all the multitudes of changes the pipeline operator needs. (That’ll be a future post.)

This also makes string interpolations simpler. We don’t need that ridiculous #{} muddying up our beautiful list of Unicode characters anymore. "Hello #{variable_for_world}" is now the much simpler "Hello $variable_for_world". Plus, your left pinky finger hits shift two less times now.

More Minor Changes

Using “<>” to concatenate strings is the most baffling design decision in the history of computer programming. They don’t do that in C, so why would any language do anything different? Everything should be based on C, just like every command line should look like it comes out of a Unix box. Even Microsoft is using Gnu BASH now…

We’re not going to use “+” for that, because we’re better than Javascript and we’re working on clearing up the differences between strings and integers here. I don’t want to overload the operators. Just the variables.

We’ll pick something sane here. In fact, I’ll give you a couple of options: “.” and “,”. Those make sense.

Tuples are dead. They are replaced with arrays/lists. If you like {:ok, “All is good”}, you’re going to love a two element array with those values. If you want to know if the function was successful, just ask for the first element of your list:

iex> @results = ("ok", "All is good")
iex> List.first(@results)
"ok"

Or, just plain old:

iex> @results[0]
"ok"

Everything in life should be zero based. You can’t spell foist without an 0, amIrite?

Summing It Up (So Far)

In these three short steps, we’ve already fixed strings, typing, and visual identification of types. We’ve cleaned up Elixir for the programmer, not touching on OTP at all.

I’ll be submitting pull requests on all of these items momentarily.

M. Night Shyamalan, The Programmer

Congratulations, you’ve just fixed Elixir by turning it into Perl.

Kinda almost like Perl6, actually. Perl has a couple of web frameworks, too, you know. Perl Dancer and Mojolicious can help.

You’re welcome.

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
  end

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. !

(17)

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