とはいえ、Apple / Google の中の人にしてみれば、iOS / Android が提供する API をがっつり使ってもらう予定だったんでしょうが、実際に動いてるアプリケーションはじつのところ、そうでもない。機能的にHTML5と大差なかったり、一貫性のある UI がモバイルアプリのあるべき姿と想像していたら、悪いデザインのアプリでも、それはそれで、機能するものなら人は案外、適応して、嫌々ながら使い続けてしまう。なんだか真面目にデザインして地道に Apple / Google の意図通りのアプリを書く人がバカを見てるような、ぎこちない状況です。
2014 (スコア:2)
Webサービス: Google App Engine に最適な Python、何か理由があれば Go や Java もオーケー(Google App Engine は絶対的に強力。使わない選択肢なし)
モバイルクライアント: Android や iOS の提供する API にアクセスしたければ、Java / Obj-c しかない
HTML5 クライアント: JavaScriptで書くことが多いでしょうが、Dart もいいでしょう
データ分析: RでもHaskellでもなんでもいい。既存のライブラリがあるときは、その言語でそのまま書くべき
リアルタイムゲームサーバ: なんでもいいけど、C++ よりは何か高級言語のほうが楽
ゲームクライアント: cocos2d-x /C++ や Unity/C# を使ってクロスプラットフォームにする。なぜならゲームのようなOSが提供する API にアクセスしなくていいし UI ガイドラインとかブランディングのために無視できるから。
Re: (スコア:0)
ゲームほどOSのAPIにアクセスするアプリケーションもそうないのでは、ファイルIOもグラフィックのネットワークアクセスもOSのAPIを使わずに出来ない。
OSのAPIの殆どは、OS非依存な形でラップできるし、既にライブラリもあるから、モバイルクライアントもJava / Obj-c以外の言語で開発できる。
Re:2014 (スコア:2)
ゲームで使うAPIっていうのは、OS非依存なAPIだらけだから、クロスプラットフォームでいいんです。むしろ、iOS と Android と違う動きをしてもらっては困る。同じように動いてほしいから、同じコードベースで組むしかない。しかし、それ以外のアプリは、iOS / Androidが元から提供している API を使うのが最適なんだろうと思います。主に UI、ナビゲーションの部分で、OS ごとに違うのだから、違う実装にするのが自然であると、それが Android / iOS のデザインした人の意図でしょう。
とはいえ、Apple / Google の中の人にしてみれば、iOS / Android が提供する API をがっつり使ってもらう予定だったんでしょうが、実際に動いてるアプリケーションはじつのところ、そうでもない。機能的にHTML5と大差なかったり、一貫性のある UI がモバイルアプリのあるべき姿と想像していたら、悪いデザインのアプリでも、それはそれで、機能するものなら人は案外、適応して、嫌々ながら使い続けてしまう。なんだか真面目にデザインして地道に Apple / Google の意図通りのアプリを書く人がバカを見てるような、ぎこちない状況です。