SwiftとGolang並行してやるとわけわかんなくなりがち。

どっちもそれほどクセが強い言語ではないので、いわゆる常識的な範囲では混乱する事はあまりない。もともと用意されたライブラリを使ったり、ありもののソースを改造したりするので、そこまで文法で引っかかる事はないのだが、細かいところはやっぱり引っかかる。

最近の言語はお互いに参考にしているところが多いので、プログラマのコモンセンスが割と役に立つ。とはいえ、やはり別々の独立した言語なので、そもそもの演算子がなかったりあったりで、こっちはそういうのなかったんだったっけという場面も少なくない。

Swiftは再三の要求を受けてAppleがOSS化したんだけれど、僕がOSS版を使った時はまだまだだった。そもそもAPTなどでパッケージ化されていなかったり、コマンドラインで必要な部分のライブラリがスタブ状態で実装されていなかったり、コマンドラインのツールを作る程度の状態にはなっていなかった。

今の状態はわからないけど、たぶんSwiftは基本的にMacやiOSのアプリケーションを作る言語であるという前提条件を出ない域であろうと思う。言語の素養は悪くないので、コンパイル言語としてもっと活躍してくれていないのは残念である。


同じコンパイル言語として、ガベージコレクションを使っているGolangだが、SwiftのARCにしてもメモリの解放を考えなくていいのは楽だ。というか、本来の処理を考えるとメモリの確保と解放は本来的な部分ではないことが多いので、言語側で処理してくれるのは正しい進化ではある。旧Objective-CとかC++がダメなのはそういうところだったから、LLのようなスクリプト言語のようなメモリの処理は期待されるところである。

それとGolangがいいのは他の人が作ったパッケージをサクッと使える仕組みである。gitリポジトリから取ってくるのかHTTPでアクセスして取ってくるのかは知らないけど、パスを指定してあげるだけで取り入れられるのは作る点においてしんどさが少なくていい。ソフトウェアは手元に自己管理で持っているというのがかなりしんどいことで、どこかで一元管理してくれていればそれに乗っかってしまった方がいい場合も多い。一度固めてしまったソースを弄られたくないとかなら、参照先が新しくなってしまうのはきついが、まぁセキュリティーも上がるのであればそれに追随すべきなのかもしれない。

SwiftがまともにApple以外の用途で使えないのであれば、Golangでやるのが筋なのかもしれない。というか、まともなオブジェクト指向のコンパイル言語が出てきたと思ったら、やっぱりAppleで使うのがせいぜいなんかいというのが、やっぱりAppleという企業の懐の浅さを示したところだろう。そもそもOSSにするのさえ渋っていたのだから、そのままOSSになったという時点でまだ歓迎するべきなのかもしれないが、その後があまり良くない。そもそもAppleとOSSというのはあまり相性が良くないのだ。それは多分最近のMSを下回るレベルだと思われる。


というか、Golangが出来てから、別に無理にオブジェクト指向にしなくていいんじゃね？という流れができた気がする。オブジェクト指向ではないのに加え、ライブラリパッケージが薄めにできているのも、Golangの性格が出ているようだ。あまり階層を深くして作ったところで、使うときに調べたりするのに面倒なのは余計な労力だろう。MSの.Net FrameworkやMacのCocoaはオブジェクト指向でシステムのAPIを組んでいるが、Linuxとかでオブジェクト指向のライブラリは少数派なんじゃなかろうか。結局、べったり平らな単純な関数が並んでいるAPIの方が使いやすいとされているような気がする。

一度はオブジェクト指向万歳な時もあったが、そのライブラリを作っている方としては組み直しがきついということを念頭に置いて設計しているとは思えなかった。Cocoaはやたらdeprecatedなメソッドがたくさんあった気がしたし、何年かしたら使えなくなるライブラリなんて使いたくない。


今、Swiftを全体をさらっておこうかなと思っていたんだけど、どうせAppleでしか使えない知識は覚えるに値しないんじゃないかと思い出した。その場で本などを見つつ書ければいいレベルの頻度しか使わないんだから、もっと別のことをすべきかもなぁと。でも文法の本ってさらっと流して読むってことがしにくいんだよね。どうしようか。

タグ：Golang SWIFT