Prologue

Hal Fulton and Johnny Winn are talking

Hal: So I was thinking of writing a book.

Johnny: Me, too. What kind?

H Oh... like a cookbook. Or a murder mystery. Or The Marcel Proust Coloring Book. Or a Chinese dictionary. Or maybe a book for Ruby programmers who want to learn Elixir.

J The Chinese dictionary sounds a little dry, but I like the last one. I had the same idea.

H We could work on it together. I know Ruby better than Elixir.

J Well, I've been working with Elixir for quite awhile, and I know Ruby. I mean, I didn't write the book on it or anything.

H There are lots of books on Ruby. I did write one of them. So let's talk about an Elixir book for Rubyists. Would you assume any deep knowledge of functional programming?

J Not really. I'd want to start at the beginning. It's all about the transformation.

H Like data transformation?

J Exactly

H But we would assume the reader was competent in OOP and in Ruby?

J Yes. Not necessarily expert, but competent.

H I'd rather not start at the hello-world level. Maybe a little higher. And I would do a breadth-first approach.

J Explain what you mean by that.

H I wouldn't really want a chapter on syntax, then a chapter on data structures, then a chapter on control structures, and so on. That's what I call "depth-first." I'd introduce just enough of each topic at one time to make that chapter meaningful and understandable. Then each chapter builds on the previous one, but you get into the actual code "early and often."

J That sounds good. That would let us present just what's needed at the time and build on it through each lesson.

J I'd also like to see problems that are a little more "real-world" than the usual programming book. I mean, they usually seem contrived.

H Definitely. Something very example-oriented. We might have to start out with some basic examples, but I'd like to see it get real in later chapters.

J I was thinking of creating characters to interact in a sort of dialogue that moves the book forward. There would be an opportunity to compare and debate examples. Almost like a chance to challenge the reader on how they think about code.

H I see. A dialogue... to motivate learning, to anticipate questions and confusion, that sort of thing. That's an interesting idea. It's a time-honored technique that goes back thousands of years.

J But I was thinking of three characters, not just two.

H Another nice idea. Galileo did that in the 17th century.

J Darn. I thought it was original.

H Who would your characters be?

J I was thinking one would be sort of a novice in Ruby, and one would be more of a Ruby expert. The third would be an Elixir mentor. Maybe the mentor would present the problem and the two Rubyists to work through the solutions. The mentor could keep the conversation focused but let the Rubyists come to their own conclusions.

H OK... for now, let's call the Elixir expert Ellie as a mnemonic. Let's call the Ruby expert Matt, which sounds like Matz. And let's randomly call the third person Alex.

J That seems fine. Two male names and a female.

H Actually, the other way around. Alex is short for Alexandra.

J Then we have our cast of characters: Ellie, the Elixir expert; Matt, the Ruby expert; and Alex, who is more of a beginner. I think they call that a dramatis personae in Latin.

H Latin is Greek to me. What if we sometimes want to dive in deeper?

J I think we could have personal asides where we comment on specific topics in more detail.

H That works for me. Let's do this.

An excerpt from Elixir for the Functional Rubyist

[Ellie is an Elixir expert, Matt is an advanced Ruby developer, and Alexandra is more of a novice. We join the story in progress.]

# File: examples/anagrams/anagrams.rb

class AnagramFinder
  def initialize(dictfile)
    words = get_words(dictfile)
    hash = process(words)
    print_words(hash)
  end

  def get_words(filename)
    myfile = File.open(filename)
    words = myfile.readlines
    words.map! {|word| word.chomp.downcase }
  end

  def process(words)
    hash = {}
    words.each do |word|
      key = word.split("").sort.join
      hash[key] ||= []
      hash[key] << word
    end
    hash.each_pair {|key, list| list.uniq! }
    hash
  end

  def print_words(hash)
    hash.each_pair do |sig, words|
      next if words.size < 2
      word = words.shift
      puts "#{word}: #{words.join(", ")}"
    end
  end
end

AnagramFinder.new("/usr/share/dict/words")

[She codes and debugs while they watch and comment.]

# File: examples/anagrams/anagrams.exs

defmodule AnagramFinder do
  def search_file(file) do
    get_words(file)
      |> process
      |> Enum.map(fn({key, list}) -> {key, Enum.uniq(list)} end)
      |> Enum.each &print_words/1
  end

  defp store(word, dict) do
    key = word
          |> String.downcase
          |> to_char_list
          |> Enum.sort
          |> List.to_atom
    word = String.downcase(word)
    HashDict.update(dict, key, [word], &[word|&1])
  end

  defp get_words(file) do
    File.read!(file)
      |> String.split(~r/\n/, trim: true)
  end

  defp process([], dict), do: dict

  defp process([word|tail], dict \\ HashDict.new) do
    dict = store(word, dict)
    process(tail, dict)
  end

  defp print_words({_key, []}), do: nil

  defp print_words({_key, [_word]}), do: nil

  defp print_words({_key, words}) do
    [first | rest] = words |> Enum.reverse
    IO.puts "#{first}: #{Enum.join(rest, ", ")}"
  end
end

AnagramFinder.search_file("/usr/share/dict/words")