勉強し続ける - 技術をかじる猫

前のエントリでも書いたが、勉強はスキルを上げる唯一の手段だ。
加えて言えば、勉強する気もなく古い技術ですべて解決しようとする人、とはコードを改善したいとも思わない人とは、僕は仲良くできないだろう(きっと一緒に仕事をしたら喧嘩になるか、そいつにコードを書かせない)。

勉強は大事だ

これは古い技術を馬鹿にしている訳ではない。
パラダイム・シフトは多くの場合、古い技術をより洗練させた形で実現することでおこるからだ。

正に温故知新。

オブジェクト指向だって、C++/Java で一気に有名になったが、元を正せば Simula 言語のクラスを C 言語の struct の発展形として実装したのが広まっただけだ。
もっと言えばオブジェクト指向という言葉も smalltalk 由来だ（C++ファミリとは違ったオブジェクト指向の流派だ）。

http://d.hatena.ne.jp/sumim/20080415/p1

C# には 2008 年ごろから、Java は 8 で対応したラムダ式なんて、自分の知る限り LISP/ML/haskell にまで遡る。
マルチスレッドのより良い制御だって Java/Scala に Akka があるが、この Akka のアクターモデルなんて一体いつの発明だよって話だ。

だがこれは、新しいものを学びもせず、学習コストは嫌いだと拒絶するのは意味が違う。

何故新しいライブラリ、フレームワーク、言語が出るのかを考えた事はあるだろうか？

それは主に2つの理由があると考えている。

ビジネスが時代と共に変化し、そのビジネス要件を容易に実現するため
要するにやりたいことをより単純な手段で解決するためだ。
クラウドが出て、分散処理が流行ると、Hadoop あたりからどんどん分散処理が増えた。
現在 DeepLerning が大流行だが、早速ライブラリまで出ている。
ビジネスの進化に追従した結果だ。
今は落ち着いたが HTML5 当初は AltJS 言語がやたら出たのも記憶に新しい。
No silver bullet - essence and accidents of software engineering:銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項
フレデリック・ブルックス.1986年著
「本質的（ビジネス要件）な複雑性と、偶有的（要件のために行う手続き）な複雑性で考えると、本質的な複雑性に対する特効薬はない」という論文。
逆を言えば、偶有的複雑性は簡略化し得る事を意味してる。
今更フレームワークなしで Web システムを作るか？正気の沙汰ではない。

全く勉強しなければ取り残されるのは上記が理由だ。

学習は価値観を変える

この業界の個人生産性はアホのような差がある。
それをもたらすのが学習だ。

そして、学習は価値観も変える。

Java で三項演算子を使ってるだろうか？

    final String displayName =
　　　　　　　　user.getDisplayName() == null ? user.getAccountId() : user.getDisplayName();

言っておいて何だが、多くの職場がそうであるように、三項演算子は禁止としているところが多い。
それのどこが悪いのかなんてそうそう気にすることではないだろう。

だが、 scala とかの関数型言語にどっぷり浸かると意見が変わる。

    val displayName =
　　　　　　if (user.displayName.isEmpty) user.accountId else user.displatName.get

scala は関数型言語で、関数型言語は定例的に「if は文ではなくて式」なのだ。だから、if や下手すれば for にも返値がある。
言語仕様上それは「処理ブロックの最後の一行」なわけだが、この処理どこかで見なかったか？

そう、さっき見た 三項演算子 だ。

「条件分岐」なのではなく、「条件で式の結果が変わる」という考え方に変わる。
（余談だが、こうした言語に慣れると、「if で値が返せないとかダサい」と考えるようになる）

当たり前だが、こんなコードの中で複雑な条件を載せるとか、返値が複雑化するとかなら scala ユーザでも if で長々とは書かない。
簡潔に書ける事こそ是としているからだ。

だが、逆に簡潔に書くことができるなら、Java でも三項演算子の使用に何のためらいがある？

それはきっとこんなださいコードを書くより良いはずだ。

   String tmpName = null;
   if (user.getDisplayName() == null) {
     tmpName = user.getAccountId();
   } else {
     tmpName = user.getDisplayName();
   }

   final String displayName = tmpName;

こうしたコードの価値観だって、更に勉強すればより良い書き方が出てくるかも知れないのだ。
その時、僕の価値観はまた少し変わるかも知れない。

例えば JavaScript ならこんな書き方もある。

    const displayName = user.displayName || user.accountId;

null = false の扱いだから、null なら右の値が返る。
boolean 同士だったらまた意味論が変わってしまうこともあるし、名前が重要になってくる書き方だ。

まぁ書き方の是非は置いといても、学べばシンプルに物事が書ける事が多い。

だからこそ学ぶのだ。