Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
7
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

@kikuyuta

はじめてなElixir(7) なぜElixirにしたのかを振り返る

ようやくそもそもやりたかったIoTに突入します。
先週末の無限リスト遊び はじめてなElixir(6) は脱線しすぎました。

注:
2019.02.16
この記事をベースに Elixir を使うようになった経緯 〜電力システム制御の現場から〜 という記事を書きました。こちらもご参照ください。

背景

次に行く前に自分のやりたいことを整理しておきます。

なぜElixirか

仕事で制御モノを作ったのですが、まあ今どきですから、マシンの観測データをクラウドに打ち上げたり、ネット側で操作したらマシンに伝わってよろしく動いたり止まったりするようにしたかったです。

そういうのを作ろうとしましたけど、普通機械ものを制御するのはPLC (programmable logic control)なコンピュータを使います。ただこれリレー制御の延長上にあって、PLCやらリレーやらのその向こうにクラウドはないなと。クラウドと相性の良い設計思想が必要です。そこで、まずは Python を使ってみたのです。私が書いたんじゃなくてパートナー会社さんに書いてもらいました。が、Python だと Native な平行プログラミングの概念がありません。ちょっと微妙な制御システムになりました。

次のステップとして、Python じゃなくて Node.js を検討していました。ところが、現場でデバッグしているのを見ると、スクリプトで作ると走ってからバグが見つかるケースが多々あることに気づきます。こりゃインタプリタ前提の言語じゃなくてコンパイラ、それも型チェックとかで走らせる前に一定のチェックができる環境が良いだろうなと。

次の言語を検討しました。
- Go lang
- Haskell
- Rust
- Erlang
話すとかなり長いので、詳細は別途にしますが、結論としては Elixir になりました。Erlang は「記述が記号的すぎてちょっとなぁ…」というところでした。Elixirは、Erlangにチョイと皮をかぶせたぐらいなもんかなと思ってスルーしてたんですが、ガッツリ言語として組まれているのが好感触です。

あとは #fukuoka.ex に行ってみて、今どきのICTのエコシステムというか、エンジニアの置かれてる環境ってのがもう自分の知ってる過去のものとは全く違っているのに感銘を受けたのが大きいです。ああ、今は社会がこうやって成長していくのかと。その一部になれれば楽しいだろうなと思いました。

無限リストと遅延評価

なぜ無限リストで遊んだかと言うと、遅延評価を組み合わせて楽しく遊べるのが一つ。もう一つは、入出力の概念と相性が良いかなと思ってるからです。入出力は関数名に!をつけたりして副作用があり得ることの注意喚起をします。単発のI/Oと思うと副作用になりますが、これが無限の入力/出力があるけど今はたまたまその途中の時刻にいるだと思えば、無限リストをLazyにエバってるのと同じ状態と言っても良いだろうなと。

関数型言語の世界を「そもそも時間の概念がない世界で、空間の一部が評価されて行って、最後に欲しかった値が得られる」ようなものだとします。すると評価という概念が時間軸を関数型言語に導入できる手法とも思えます。するってえと、入出力のような時間軸にそって値が変わるものも関数型言語できちんと扱える… かもしれません。

そんなことができて何が嬉しいかというと、例えば型の概念にハマれば入出力も含めて型検査でバグを見つけてもらえる… とかにつながるかなとか思ってます。

マイルストーン

遊んで楽しいだけじゃなくて、仕事にしていくという文脈がありますので、こういう風に進めようかなと思ってます。
1. Elixir で入出力モジュールを書いてみる
- 1台の PC(わたしの Macbook air)で入出力をするモジュールを書いてみる
2. いくつかの入出力モジュールから/へのやりとりをする本体モジュールを書いてみる
- 入出力のモジュールは並行して動くプロセスとする
- 簡単なもので構わない。
- これも1台のPCの中で済ます。
3. 入出力モジュールの一部を別PCで動かす
- センサモジュールがIP的に別であるような状況を仮定して
4. 本体モジュールの計算も一部を別PCに飛ばす
- CPU の能力が足りなくなった時を想定
5. 作ろうとしているシステム全体の入出力を模倣するような構成で作ってみる
6. ラズパイとかで動くものか試してみる

状態マシン(state machine)をどう扱うか

かなり気になってるのが、現在運用中のシステムの設計が状態遷移図で記載されいてることです。これは思いっきり関数型言語パラダイムと相容れません。そこをどう解決できるのかわかってません。

関数型リアクティブプログラミングって概念があるようなので書籍を調達してみました。
関数型リアクティブプログラミング
これ先頭の方で「状態遷移はいかん!」って書いてはあるのですが、本文中にダイレクトにそれを解決するような文章が見当たらないです。全部読むには大変分厚く、これ読んで解法を見つけるよりは、Elixir触りながらあれこれ考える方が早いかなと思ってます。

でも、適当な解法が見つからなかったら "Help!" を叫びますので、そのときはみなさん、どうぞ助けてください。よろしくおねがいします。

参考文献

関数型リアクティブプログラミング

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
7
Help us understand the problem. What are the problem?