システムトレードのヒカキンになりたい人生だった

2014年にFXのシステムトレードをPythonでやっていた

2015年夏, 今から7年前にわたしがFXのシステムトレードをPythonでやろうとしたとき, Pythonでシステムトレードをしている人がとても少なかった.

夏休みの自由研究 は OANDA APIを利用して FX システムトレード | Futurismo

日本語で情報を探すとほとんど情報がないかもしくはtickを取得してみた系の入門記事のみ. Pythonでシステムトレードを組む情報は英語しかなかった. わたしは3万円くらいの怪しい英語の情報商材を購入してそのサンプルコードで勉強した.

システムトレードが日本で全くなかったわけではなく, MT4が主流だった. そして大事なことは, 2015年はPythonはまだ人気ではなかった. Rubyのほうが圧倒的な人気で, さらにいえば統計処理をするならばRだった. 記憶だと, この翌年に機械学習ブームがきてPythonの人気がでて, さらにそのあとビットコインが人気になる.

わたしが2015年にPythonでFXシステムトレードをやろうとした理由は, Rubyではじめるシステムトレードという本を2014/10に購入し, さらに2014/11にcourseraでシステムトレードの授業を受け, そこで使われていたのがPythonだったから. わたしのPythonデビューはcourseraの講義だった.

未来はわからないのでワクワク感を基軸にしてClojureを選択する

2014年から8年の月日がながれた. まさかPythonが人気言語になることも, AIブームが来ることもビットコインが人気になることも, 全く2014年の時点では見えなかった. そして, 気づけばPythonで仮想通貨のアルゴリズム取引をする人たちがたくさんいた. 2015年にわたしがやっていたときはネットで検索するかぎりPythonで日本人ではみつからなかった. MT4の人はいた, 外人はいた. この状況は驚きである. 飽きっぽい私が仮に継続していたならば先行者利益でヒカキンになっていたかもしれない.

しかしよくわからない状況のなか, マイナーにものが好きなわたしはPythonをやっていた. Pythonがメジャーになってしまった今, なんかメジャーな言語をつかうのが嫌なのだ.

そして2014年に未来が見えなかったということはこの先数年でClojureの人気が来るかもしれないがそれはわからないのだ. こういうときは, ワクワクすることを判断の基軸にする. Pythonは残念ながらワクワクしないのだ.

ClojureでBotを書くときの壁と乗り越え方

ccxtがないのは自作する

Clojureでbotを書こうとしたときにまず現れる壁は取引所のAPIを叩くライブラリがないので自作しないといけない.

具体的にはPythonでいうccxtがない. Javaのライブラリを呼び出すという選択肢もあるものの, Clojureの強さはデータを言語組み込みのMapとして扱うことでオブジェクト指向の世界のようななんでもかんでもクラスを定義しまくる世界観から脱却することなので, Clojureで自分で書いたほうがいいと思った. さらにいえば, Clojureの世界においてAPIコールは関数呼び出しにすぎない(Remote procedure callのようなものだ). つまりライブラリやORマッパーがなくても素でマッチョなClojureは関数を書いてMapに格納すればいい.

そうはいっても, さっそくBitflyerのAPIを叩いたところ, 認証部分が少しむずかしかった. しかしそこを半日かけて突破したらClojureでAPIを扱えのようになり, 少なくともccxtがない課題は克服した.

Clojureのセールスポイントがデータ分析だった

bot開発においてロジックを組むのは簡単で問題は戦略を考えることだ. それはPythonでFXをやっていたときにとても感じた. だからこそデータ分析につよいPythonが唯一の選択肢なのかもしれない.

しかしClojureのデータ分析に興味があるので, bot開発のモチベとしてClojureによるデータ分析をハックするのはとてもおもしろそうだ. なぜならば, Python前夜のClojureの誕生初期のセールスポイントはなんとデータ分析だったのだ！Clojureにとってのデータ分析はお笑い芸人の若手のときに売れた一発ギャグなのである. オリエンタルラジオの武勇伝なのである.

この事実をきいたことだけあるものの, 実際のところどうだったのか, そして今の現状はどうなのかということにとても興味がある.

最終的にはPythonを書いてなんとかする

それでもいろいろと壁にぶち当たったら最終的にはPythonを書いてなんとかする. Pythonは あきたから嫌いなのであって, それなりには書ける. たとえば執行部分はClojureでデータ分析はPythonでというパターン.

これはけっこうありとはおもっている. そしてその方向性も見据えてGCPサービスはそこそこ積極的に使おうとは思っている.

Clojureの力への意志

Clojureの可能性について述べておく. まだ実際にやりかけのため, これは単なる仮説にすぎないのだが.

誰だって玄関開けて５秒でREPLと合体したい

Clojureをよく書くようになり他の言語が書くのが嫌になった最大の理由はREPL開発ができるかどうかにある. これのためにClojureをやりいたし他の言語を今は触りたくない. そのくらいこの方法はプログラミングを書くことのパラダイムシフトだった.

APIをちょろっと叩くのだってそのデータを変数に格納して中身をゴニョゴニョするのだって, 簡単にできる. Clojureを書く時, 自由を感じる. 同じことはPythonでもJupyter Notebookでできる. しかしJupyter Notebookが好きならばREPL駆動開発はその10倍好きになる.

誰だって玄関開けて５秒で合体したいように, Clojureを書いて5秒で実行したいのだ.

稼働中のBotに乗り込む

REPLからbotを起動することで稼働中のbotの中に乗り込める. このやり方が正しいのかは現在検証中. パフォーマンス的にはどうなんだろう. ただ, 便利だなと思うのは状態がREPLから覗けたりそれを出力できたりする. なんならREPLから使えるようなツールをあらかじめ組み込んでおけばその環境でAPIも叩ける.

まだハックしきれてないんだが, integrant.replをうまくつかってnamespacesを再読込するだけで修正したコードの動的コンパイルによってホットリロード的なこともできるのでは? まあ稼働中で一旦止めればいいのかもしれないけど.

[AAAI16実況報告] MIT/CSAIL はCommon Lispを水中探査ロボットAIに実運用している - Qiita

Common Lisp のリアルタイムコンパイル機能のおかげで、運用中に発覚したバグを(たしか木星を過ぎたあたりで) REPLにログインし動的にhotfix することができ、無事ミッションを達成することが出来ました。

このエモいエピソードに似ている. このリアルタイムコンパイル機能という用語がググってもででこないのでClojureとは違うのかもしれないが(Common Lispはよくしらない), 仮にこれが宇宙で実行中のREPLに乗り込んでREPLの中でゴニョゴニョすることを指すのならば感動のポイントが似ている. bot稼働はもはや私と宇宙の希望をかけた命がけのムーンショットだな.

強力な並行プログラミングと遅延シーケンスの力

Clojureの強さのひとつはcore.asyncによる並行プログラミングを書くことかなと期待している. 実際のところ, わたしはClojureでcore.asyncをあまり書いたことがないので, この実際のところはわからない.

しかしPytyonのような共有メモリ方式の並行プログラミングよりは書きやすそうという印象はある. そもそもPythonの並行プログラミングは並行なのか？

とりあえずPythonよりは速い

ClojureはJVMで動くので一応Java程度の速度があり, Pythonよりは速い. Clojureが遅いのは起動の部分だがbotならば関係ない. 開発中ならばREPL起動しっぱなしなので問題ない.

ガチるならばC++やRustがいいのかもしれない. そのときはまたそのときである. わたしはC言語しか書いてこない人生だったのでRustは書けないが勉強してみたい.