Haskell勉強会

関数型プログラミングの学習日記

プログラミングElixir 目次

「プログラミングElixir」という本を買いました。

Elixirを勉強して、Webアプリを作ってみたいです。

プログラミングElixirは、以下のような構成になっていました。

 

プログラミングElixir

プログラミングElixir

 

 

目次

(参考)プログラミングElixir | Ohmsha

 

Elixir 作者による前書き

 

はじめに(正当化のむなしい試み)

 

第1章 赤いカプセルをとれ

 1.1 プログラミングはデータの変換をするものだ
 1.2 Elixir のインストール
 1.3 Elixir の実行
 1.4 この本を読むにあたって
 1.5 練習問題
 1.6 Think Different(ly)

 

第I部 伝統的なプログラミング

 

第2章 パターンマッチ

 2.1 代入:あなたの考える代入は、私の考える代入ではない
 2.2 もっと複雑なマッチ
 2.3 _(アンダースコア)で値を無視する
 2.4 変数の束縛は(マッチ中で)一度だけ
 2.5 等号記号の別の見方

 

第3章 不変性

 3.1 あなたはすでに(いくつかの)不変データを知っている
 3.2 不変データは既知のデータ
 3.3 不変性の性能への影響
 3.4 不変データでコーディングする

 

第4章 Elixir の基礎

 4.1 組み込みの型
 4.2 値型
 4.3 システム型
 4.4 コレクション型
 4.5 マップ
 4.6 名前、ソースファイル、慣習、演算子など
 4.7 変数スコープ
 4.8 基礎の終わり

 

第5章 無名関数

 5.1 関数とパターンマッチ
 5.2 一つの関数、複数のボディ
 5.3 関数は関数を返すことができる
 5.4 関数を引数として渡す
 5.5 関数はコアだ

 

第6章 モジュールと名前付き関数

 6.1 モジュールのコンパイル
 6.2 関数のボディはブロックだ
 6.3 関数呼び出しとパターンマッチ
 6.4 ガード節
 6.5 デフォルトパラメータ
 6.6 プライベート関数
 6.7 素晴らしきパイプ演算子|>
 6.8 モジュール
 6.9 モジュールの属性
 6.10 モジュールの名前:Elixir、Erlang、そしてアトム
 6.11 Erlang のライブラリにある関数の呼び出し
 6.12 ライブラリを見つける

 

第7章 リストと再帰

 7.1 ヘッドとテイル
 7.2 ヘッドとテイルによるリストの処理
 7.3 ヘッドとテイルを使ったリストの構築
 7.4 map 関数の作成
 7.5 再帰中の値の保持
 7.6 より複雑なリストのパターン
 7.7 実践List モジュール
 7.8 リストと仲良くなろう

 

第8章 マップ、キーワードリスト、セット、構造体

 8.1 マップとキーワードリスト、どちらを使うべきか
 8.2 キーワードリスト
 8.3 マップ
 8.4 マップのパターンマッチ
 8.5 マップの更新
 8.6 構造体
 8.7 入れ子になった辞書構造体
 8.8 セット
 8.9 大いなる力には大いなる誘惑が伴う

 

第9章 寄り道:型とは何か?

 

第10章 コレクションの処理―――Enum とStream

 10.1 Enum―――コレクションの処理
 10.2 ストリーム―――遅延列挙
 10.3 Collectable プロトコル
 10.4 内包表記
 10.5 神業との訣別

 

第11章 文字列とバイナリ

 11.1 文字列リテラル
 11.2 「文字列」という名前
 11.3 シングルクオートで囲まれた文字列―――文字コードのリスト
 11.4 バイナリ
 11.5 ダブルクオート文字列はバイナリ
 11.6 バイナリとパターンマッチ
 11.7 見慣れた、けれど奇妙な

 

第12章 制御フロー

 12.1 if とunless
 12.2 cond
 12.3 case
 12.4 例外の発生
 12.5 例外を使ったデザイン
 12.6 少ない努力で、大きな成果

 

第13章 プロジェクトを構成する

 13.1 プロジェクト: GitHub からIssues を取得
 13.2 タスク: mix を使って新しいプロジェクトを作る
 13.3 変換:コマンドライン解析
 13.4 ステップ: 基本的なテストを書く
 13.5 変換:GitHub からの取得
 13.6 タスク: ライブラリを使う
 13.7 変換:レスポンスを加工する
 13.8 変換:データを並び替える
 13.9 変換:最初のn 個を取り出す
 13.10 変換:テーブルに整形
 13.11 タスク:実行可能なコマンドを作成
 13.12 タスク:ロギングの追加
 13.13 タスク:コメントのテスト
 13.14 タスク:プロジェクトドキュメントの生成
 13.15 データの変換によるコーディング

 

第II部 並行プログラミング

 

第14章 複数のプロセスを使う

 14.1 シンプルなプロセス
 14.2 プロセスのオーバヘッド
 14.3 プロセスが死ぬとき
 14.4 Parallel Map―――Erlang の“Hello, World”
 14.5 フィボナッチサーバ
 14.6 Agents―――難問
 14.7 プロセスで考える

 

第15章 ノード―――分散システムの要

 15.1 ノードの名前付け
 15.2 プロセスの名前付け
 15.3 I/O、PID、ノード
 15.4 ノードは分散の基本

 

第16章 OTP:サーバ

 16.1 OTP でのいくつかの定義
 16.2 OTP サーバ
 16.3 GenServer コールバック
 16.4 プロセスの名前を付ける
 16.5 インターフェースの整理

 

第17章 OTP:スーパーバイザ

 17.1 スーパーバイザとワーカー
 17.2 スーパーバイザは信頼のかなめ

 

第18章 OTP:アプリケーション

 18.1 これは伝統的なアプリケーションではない
 18.2 アプリケーション仕様ファイル
 18.3 Sequence プログラムをOTP アプリケーションにする
 18.4 スーパーバイザが信頼性の基盤
 18.5 コードのリリース
 18.6 EXRM―――Elixir のリリースマネージャ
 18.7 OTP は大きい、信じられないくらい大きい

 

第19章 タスクとエージェント

 19.1 タスク
 19.2 エージェント
 19.3 大きめの例
 19.4 エージェントかタスクか、それともGenServer か?

 

第III部 より高度なElixir

 

第20章 マクロとコードの評価

 20.1 if 文の実装
 20.2 マクロはコードを注入する
 20.3 コードとして表現を利用する
 20.4 値の注入のためのバインディングの利用
 20.5 マクロは健全
 20.6 コード片を走らせる他の方法
 20.7 マクロと演算子
 20.8 さらに深掘り
 20.9 とんでもなく深掘り

 

第21章 モジュールのリンク: ビヘイビアとuse

 21.1 ビヘイビア
 21.2 use と__using__
 21.3 総まとめ―――関数呼び出しのトレース
 21.4 use を使う

 

第22章 プロトコル―――ポリモーフィック関数

 22.1 プロトコルの定義
 22.2 プロトコルの実装
 22.3 利用可能な型
 22.4 プロトコルと構造体
 22.5 組み込みプロトコル
 22.6 プロトコルポリモーフィック

 

第23章 かっこいい機能いろいろ

 23.1 自前のシジルを書く
 23.2 複数アプリケーションのアンブレラプロジェクト
 23.3 お楽しみはこれからだ!

 

付録A 例外:raise、try、catch、throw

 A.1 例外を起こす
 A.2 catch、exit、throw
 A.3 独自の例外の定義
 A.4 今はこの付録を無視してほしい

 

付録B 型仕様と型チェック

 B.1 いつ型仕様が使われるか
 B.2 型の指定
 B.3 新しい型の定義
 B.4 関数とコールバックの型仕様
 B.5 Dialyzer の利用

 

付録C 参考文献

 

付録D 日本語版に寄せて

 D.1 Elixir 作者より
 D.2 原著者より
 D.3 訳者より

 

索引

 

著者紹介

(p.325)

著者

Dave Thomas(デイヴ トーマス)

 クールなものを伝道するのが好きなプログラマ

The Pragmatic Programmer(『達人プログラマー』)の共著者で、アジャイルソフトウェア開発宣言の著者の一人でもある。

彼の著書 Programming Ruby(『プログラミングRuby』)は、プログラミング言語Rubyを世界に紹介し、Agile Web Development with Rails(『RailsによるアジャイルWebアプリケーション開発』)はRailsが一世を風靡する最初の一押しとなった。

 

訳者

笹田耕一(ささだ こういち)

 プログラミング言語Rubyを開発するプログラマ

Heroku, Inc. SMTS、一般財団法人Rubyアソシエーション理事。

楽天テクノロジーアワード2008 Ruby賞、The Ruby Hero Awards 2016等受賞。

他の監訳に『アンダースタンディング コンピューテーション』(オライリー・ジャパン、2014)。

好きなElixirの機能はマクロ。

 

鳥井雪(とりい ゆき)

 プログラミング言語Rubyを使用するプログラマ

株式会社万葉所属。

楽天テクノロジーアワード2013ルビー賞受賞。

他の訳書に『ルビィのぼうけん』(翔泳社、2016)。

好きなElixirの機能はパイプ演算子

 

twitter.com

 

twitter.com

 

twitter.com

 

出版社情報

www.ohmsha.co.jp

 

shop.ohmsha.co.jp

 

書評

RubyRailsの大御所が書いた本なので、内容は確かなものになっているはずだと思います。

まずは、第1部の基礎文法解説を理解できればいいかな?

 

本書を買うきっかけは、立ち読みで冒頭部分(第1章)にいいことが書いてあったから。

 

第1章 赤いカプセルをとれ

→これは、映画「マトリックス」有名なシーンからの引用ですね?

  • 青いカプセル:このまま仮想現実で生きる
  • 赤いカプセル:現実の世界で目覚める

 

youtu.be

 

なかなか粋なタイトルの付け方だと思いました。(それはさておき…)

 

(p.1)

1.1 プログラミングはデータを変換するものだ

 オブジェクトを使ってコードを書くとき、考えているのは状態のことだ。

たくさんの時間が、オブジェクトのメソッドを呼び出し、またそれを別のオブジェクトに渡すことに費やされる。

この呼び出しに基づいて、オブジェクトは自分自身の状態と、ひょっとしたら他のオブジェクトの状態を更新する。

この世界では、クラスが王様だ。

クラスは各インスタンスができることを定義し、そのインスタンスが抱えるデータの状態を暗黙的にコントロールする。

目的は、データの隠蔽だ。

 

 でも、これは現実ではない。

現実の世界では、抽象的な階層構造をモデル化したいわけではない(なぜなら、実際には、真の階層構造なんてそう多くはないからだ)。

私たちは仕事を済ませてしまいたいのであって、状態を維持したいわけではない。

 

 例えば今から、コンピュータの殻のファイルを、文章の入った形に変換する。

そのあとすぐに、私はこれらのファイルを読める形に変換する。

どこかのウェブサーバは、その本をダウンロードしたいというリクエストを、中身にその内容が入ったHTTPレスポンスに変換するだろう。

 

 データを隠蔽したいのではない。変換したいんだ。

 

「入力 → 変換 → 出力」という流れが処理の基本形。変換について考えたいと。

 

(p.2)

パイプラインで変換を組み合わせる

 Unixユーザは、小さく、焦点を合わせた、どのようにでも組み合わせられるコマンドラインツール、という哲学に慣れ親しんでいる。

それぞれのツールは入力をとり、それを変換し、次のツール(もしくは人間)が利用できる形式で結果を出力する。

 

 この哲学は信じられないくらい柔軟で、そのため素晴らしい再利用性がある。

Unixユーティリティは、その作者が思いもよらなかった方法で組み合わせられる。

そうして一つひとつが、他のツールの可能性を何倍にもする。

 

 また、そういったコマンドラインツールは、高い信頼性を持つ。

それぞれの小さなプログラムは、一つのことをきちんとするので、テストも簡単になる。

 

 他にも利点がある。

コマンドパイプラインは並列に実行できる。

 

UNIX哲学 - Wikipedia

UNIX哲学とは、ソフトウェア開発に関する文化的な規範と哲学的アプローチのまとまりであり、UNIX OSの先駆的な開発者たちの経験に基づいている。

 

パイプの発明者でありUNIX創始者の一人でもあるマキルロイは、この哲学を以下のように要約した。

これがUNIXの哲学である。
一つのことを行い、またそれをうまくやるプログラムを書け。
協調して動くプログラムを書け。
標準入出力(テキスト・ストリーム)を扱うプログラムを書け。標準入出力は普遍的インターフェースなのだ。

— ダグラス・マキルロイ、UNIXの四半世紀 

 この哲学はしばしば、「一つのことを、うまくやれ」とさらに厳格に要約される。

 

パイプ(パイプライン)の発明者であるダグラス・マルキロイ氏は、

  • 1つの機能を作る
  • 機能を組み合わせる

という考え方をUNIXに適用したんですね。

これは、関数型プログラミングにも当てはまる考え方だと思います。

 

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

 

 

(p.3)

関数はデータ変換器

 Elixirでの問題の解き方は、Unixシェルと同様だ。

コマンドラインユーティリティの代わりに、関数がある。

驚くほど簡単に、関数同士をつなげることができる。

関数をより小さく、より焦点を合わせた形にすればするほど、つなげる際の柔軟性は高まる。 

 

ここまで読んで、閃いちゃいましたね!

関数型プログラミングって、難しく考える必要はなかったんだ!

Unixのシェルと原理は同じじゃん!

うひょ~、やったろやったろ、関数型!」と。(笑)

 

わずか3ページ立ち読みしただけで、「これは買い!」と決定w

 

Pleromaのコードリーディング

まあ本当は、Elixirの本を手にした理由は、Pleromaに興味を持ったからです。

 

www.itmedia.co.jp

 

https://pleroma.social/

 

最近話題になってたSNSマストドン」を高速化したPleromaは、「Elixir」というプログラミング言語で作られている、と知りました。

Pleromaのコードを読むには、Elixirの知識が必要になるので、ちょっと勉強してみようと。

関数型プログラミングにも興味を持っていたので、Elixirはもってこいでした!

 

  1. Pleromaのコードを読みたい
  2. 関数型プログラミングにも興味がある
  3. Elixirの解説本でいいことが書いてあった

 

こんな方には「プログラミングElixir」はお勧めです!

 

Elixirを勉強した後は、Erlangもかじってみたいと思います。