後半はマニアック過ぎて伝わらないかもしれません。
目次
今回は開発面での不満です。言語環境としての不満は以前の記事が参考になります。
Swift開発環境はまだ弱い〜Objective-C環境と比較して気づいた問題や不満〜
文字列処理が厄介で面倒
面倒です。NSRangeをベースとしている既存のUIフレームワークとの相性が悪いように思います。NSString時代のコードとも互換性が少なく、学習コストが高い印象でした。StringをNSStringに変換してその場をしのぐこともありました。Swift 4からは文字列APIの設計が見直されるそうなので、今後に期待です。
オプショナルのせいでコード量や学習コストが増える
強制アンラップをするべきかしないべきかで迷うことがあります。 これはSwiftと既存UIフレームワーク(UIKit/AppKit)との相性も関係してそうです。
// AppDelegate.swiftでよく見かけるコード
// 基本的に安全
let splitViewController = self.window!.rootViewController as! UISplitViewController
// 画面遷移やライフサイクルの影響を受けるため危険
let window = view.window!
このように、Swift開発では強制アンラップをしてよいケースとしてはいけないケースに遭遇することがあります。APIの仕組みをきちんと理解していれば、迷うこともないのですが、そこまで学習コストを掛けられるプログラマやプロジェクトはそう多くはないでしょう。かといって曖昧な理解で強制アンラップを行うわけにも行きません。
すると、プログラマは強制アンラップを極力避けるようになります。 結果として冗長的なコードを書かざるを得なくなるのです。
if let window = view.window { /* do something */ }
let frame = view.window?.frame ?? CGRect(0, 0, 0, 0)
最近は強制アンラップ自体をコーディング規約で禁止している現場もあるそうです。
フリーフォーマットの恩恵が受けられない
簡易的なデバッグテクニックやC言語時代のえげつないテクニックが使えなくなってます。
/* ブロック文のコメントアウトテクニック */
if(0) if (that) {
print("if(0)を消すと表示される");
}
/* ブロック文のトグルテクニック */
// if (false)
{
print("上のコメント外すと表示されなくなる");
}
/* プリプロセッサのいやらしいテクニック */
#ifdef THAT_FLAG
if (cond) {
it();
}
else
#endif
{
/* do something */
}
JavaやPHP, C/C++の世界では他にもフリーフォーマットを活用した様々なイディオムが存在するのですが、Swiftではそれがまったく通用しません。
最近はデバッガやテストツールが高機能になっているので、わざわざこんなことをしなくても、もっとスマートな方法は沢山あるのですが、しかしSwiftは痒いところに手が届かない感じがとてもモヤモヤします。代替手段を探すための学習コストが高いのも特徴です。全体的に手間のかかる言語だと感じます。
今まで使ってきた開発ツールや開発ノウハウがほとんど通用しないため、まるで知らない街で生活を始めた時のような不安を覚えます。
プリプロセッサが貧弱
以下のようなコードはエラーになります。
class CanvasView :
#if OS_macOS
NSView
#else
UIView
#endif
{
}
以下のように、少し頭をひねる必要があります。
#if OS_macOS
typealias View = NSView
#else
typealias View = UIView
#endif
class CanvasView : View {
}
従来の発想が通用しない所もSwiftの特徴です。本当はもっとスマートな方法があるかもしれません。スマートな方法を探し精査ためのコストが高いのもSwiftの特徴です。
今回はなんとかなりましたが、Swiftのプリプロセッサは全体的に融通がきかず貧弱です。
Swift言語の不満
Swiftは趣味で扱う分には楽しい言語なのですが、実際に業務で使うと面倒で厄介な言語になります。特に既存のフレームワーク(Cocoa/Cocoa Touch)や低レイヤーの処理が絡むと厄介な問題を多く抱えるようになります。
またSwiftのコンセプトや言語仕様は、設計やテストのフェーズに大きなインパクトを与えてしまうほどに強力な物が多いのですが、その半面、融通がきかない設計や規約をプログラマに強制させる効力も持ち合わせています。
とはいってもオプショナルの仕組み自体は非常によく出来たもので、うまく活用すれば安全性が高く頑強なAPIの設計を後押しすることにも繋がります。
しかし問題は、Swiftのコンセプトや思想をきちんと理解した上で使わなければならないことです。既存言語のスタイルやノリでSwift開発を始めてしまうと、思うように開発が進まないことになるかもしれません。
また既存のフレームワーク(UIKit/AppKit)ではSwiftの有効性があまり活かせていないという点も問題だと感じています。