スキップしてメイン コンテンツに移動

KotlinはどれほどC#を意識しているか?

今週のC#記事はKotlinがどれほどC#を意識しているかにします。(Bloggerを開く前まではReactivePropertySlimがどれだけ軽くなったのか調べて書こうかなと思ってたのですが新鮮なネタのほうから書くことにします)

新鮮なネタと言ってますが、あくまで自分の中でです。
なぜ新鮮かというとこちらのKotlin公式サイト(https://kotlinlang.org/)と言うんでしょうか?オフィシャルなサイトの右上のサイト内検索で"C#"を検索するとちゃんとC#の単語出現場所を検索してくれることに気づいてしまったからです。

C#erならわかるかと思いますが、C#って検索システムによってはちゃんと検索してくれないんですよね…"C"で検索した扱いになったりとか。Google大先生はもちろんちゃんとC#で検索できるんですが、内部で特殊扱いしているのか、Q#やP#だと"Q"や"P"の検索結果が目立ちます。

はい、本題に戻りまして、kotlinlang.orgでのC#検索結果がこちらになります。

出現個所をまとめると

  • Extensions
  • Android Frameworks Using Annotation Processing
  • FAQ
  • Generics
  • Control Flow: if, when, for, while
  • Coroutines
  • Functions
ですね。

詳細

  • Extensions

Kotlin, similar to C# and Gosu, provides the ability to extend a class with new functionality without having to inherit from the class or use any type of design pattern such as Decorator. This is done via special declarations called extensions. Kotlin supports extension functions and extension properties.
ざっくり言うとC#のように関数(メソッド)を拡張する機能を提供しているとうこと。KotlinはC#と違い拡張プロパティなどにも対応していますが、言語デザインとしてはC#の拡張メソッドを参考にしているのでしょうか。拡張できる機能としてはSwiftのExtensionsに似ている気もしますがね。
(それにしてもGosuとはなんでしょうか。Go langのことですかね…?検索しても出てこなかった…)

  • Android Frameworks Using Annotation Processing

SQLiteライブラリであるDBFlowについて
That gives you a way to express queries via C#-like LINQ syntax, use lambdas to write much simpler code for asynchronous computations, and more. Read all the details here.
はい、お恥ずかしいながらDBFlow初めて知りました。内容としてましてはLINQ to SQLを移植したようなもの。hereのリンク先はこちら(https://agrosner.gitbooks.io/dbflow/content/KotlinSupport.html)

  • FAQ

Is Kotin hard?についての解答
Kotlin is inspired by existing languages such as Java, C#, JavaScript, Scala and Groovy. We've tried to ensure that Kotlin is easy to learn, so that people can easily jump on board, reading and writing Kotlin in a matter of days. Learning idiomatic Kotlin and using some more of its advanced features can take a little longer, but overall it is not a complicated language.
 言ってることは、Java・C#・JavaScript・Scala・Groovyなどの既存言語に影響を受けてるから少し勉強したらできると思うよ、ということ。

はい、ここではっきりとC#は意識の中に入っていることが明言されています。
JVM言語を除けばC#とJavaScriptのみであり、JavaScriptはトランスコンパイル対象であることからわざわざC#が明言されているということは明示的に意識したと解釈していいのでしょうかね。

  • Generics

Declaration-site varianceについて
We believe that the words in and out are self-explaining (as they were successfully used in C# for quite some time already), thus the mnemonic mentioned above is not really needed, and one can rephrase it for a higher purpose:
The Existential Transformation: Consumer in, Producer out! :-)
 共変性と反変性についてC#のアプローチがうまくいっていると書いてあるので、これについてはC#のアプローチのまま取り入れたということでしょう。

  • Control Flow: if, when, for, while

(これについては引用は割愛)
どこで取り上げられているかと言いますと、for(C#で言うところのforeachに該当する機能)での順番に列挙するにはiteratorが必要になるが、それらはC#と同じようにダックタイピングできるよ、ということ。
C#と違う点はoperator修飾子が必要ということでしょうか。

  • Coroutines

ここでは2箇所(3単語)で取り上げられています。

概要:
Many asynchronous mechanisms available in other languages can be implemented as libraries using Kotlin coroutines. This includes async/await from C# and ECMAScript, channels and select from Go, and generators/yield from C# and Python. See the description below for libraries providing such constructs.
The inner workings of coroutines:
More details on how coroutines work may be found in this design document. Similar descriptions of async/await in other languages (such as C# or ECMAScript 2016) are relevant here, although the language features they implement may not be as general as Kotlin coroutines.
1箇所目は、C#とECMAScriptのasync/awaitや、Go langのチャンネルとセレクトや、C#とPythonのgeneratorsとyieldはKotlinのコルーチンを使えば実装できるよ、ということ。 
2箇所目は、他の言語のasync/await(つまりC#とECMAScript)は重要だが、Kotlinのコルーチンと同じように一般的ではないかもしれない、ということ(おい)

コルーチンに関してはC#の影響を色濃く残していますが、async/awaitはそんなに一般的じゃないんですかね?まぁ少なくともJVM界隈では一般的ではないですね。最近はSwiftで実装するかもという話にもなっていますし、async/awaitはどんどん輸出されるものと思います。

  • Functions

Function Scopeについて
In Kotlin functions can be declared at top level in a file, meaning you do not need to create a class to hold a function, like languages such as Java, C# or Scala. In addition to top level functions, Kotlin functions can also be declared local, as member functions and extension functions.
 Kotlinではトップレベルで関数を宣言できるからJavaやC#やScalaのようにクラスである必要はないよ、ということ。
C#の影響は完全に受けていない文章ですが、なぜここでC#に触れるのか。まぁC#を意識しているんでしょうねぇ…

まとめ

公式的に見てもC#の影響を受けていたり、意識をしていてりはすると判断できると思います。

また、コミュニティ的にもPartial Class support in the future?でC#のpartial classみたいなのはないのか~?のようにC#の影響は結構あったりします(笑)
自分も昔LINQをKotlinに移植してみたりしましたが(負の遺産)
まぁ、それもそのはずC#を知っている人間がAndroid開発をJavaですることに耐えれるわけもなく…C#のような機能のあるKotlinに逃げるのは必然と言いますか自然の摂理と言いますか…

まぁAndroidではXamarin.Androidがあるので皆さんはKotlin使わずにC#を使ってどうぞ(ダイレクトマーケティング)

コメント

このブログの人気の投稿

Stellaris 2.0.1 植民スパムプレイ

さっそくですが、友達との3日がかりのマルチプレイ終わりました。

銀河設定は中サイズ(600)、リング2、中盤の危機75年早く、終盤の危機100年早く、技術・伝統コスト0.5倍、難易度普通って感じでした。

そして、自分のプレイングは機械帝国植民スパム、友達は内向き牧歌でした。
最終的な国力としては機械帝国植民スパムのほうが強く、序盤から中盤は内向き牧歌のほうが強かったです。

機械帝国植民スパム はい、前回も言いましたが2.0から植民スパムゲーです。2.0.2からは前哨地維持費がかかるようになり更なる植民スパムゲーにもなりそうです。
植民スパムするからには、まぁロボットか機械帝国って感じなんですが、今回はゲーム進行が速い設定なので機械製造速度アップにガン振り帝国にしました。生産はエネルギー重視で、直轄地に鉱物惑星・研究惑星があるような感じにしました。
それでも、機械帝国は序盤の成長が遅く、鉱物を大量に消費するので、周りの帝国との不可侵条約はかかせません。直轄地6惑星(母星・エネルギー、エネルギー、研究*3、鉱物)の発展が終われば、今度はセクターの開発です。 まぁ、セクターの開発なんか物資さえ送り込めば勝手にやってくれるのでいいですが、エネルギー重視の生産なので鉱物の面倒は見てやらないとダメです。
帝国所有惑星が20ぐらいになれば、まぁ中銀河(サイズ600)なら敵なしですかね。あとは軍拡するだけです。
中盤の危機と終盤の危機 前述の通り危機はかなり早く発生するようにしたのですが、なんと中盤の危機がいっこうに発生しませんでした。発生したのは終盤の危機に立ち向かってるとき…おい()
終盤の危機は機械帝国プレイだったのでもちろんのようにコンティンジェンシー、中盤の危機は機械の反乱でした。
中盤の危機に関しては機械帝国プレイなので自分はどうでもよかったのですが、終盤の危機はがんばらないとまずかったです。コンティンジェンシーなので機械の生産-40%補正がつくので、スペシャルプロジェクトで解除(自分の研究力500ぐらいでは50か月ぐらいでした)しない限り国力が持ちません。
コンティンジェンシーは艦隊戦力が300k+100k*2の集団が4つほど湧いて100k艦隊は時間とともに増え続けるので急がないといけませんが、解除さえすればあまり余る国力で殴り続けるだけでしたね。終盤の危機の間に…

Stellaris ver2.0 Apocalypse プレイ感想

タイトルの通り大型アプデ後での友人とのマルチプレイでのプレイ感想です。

変更内容に関してはこちらのサイトで日本語訳された内容が公開されています(本当に助かりました)
Simulationian.com - 「Stellaris」開発日記#105――2.0「チェリイ」パッチノート

使用した帝国について 細かい設定は覚えていませんが(確認するのもめんどくさい)、有機生命体で狂信権威・平和主義で国是にアップデート内容の生まれた生命(Life-Seeded)を選択しています。 狂信権威について アップデートにより帝国の領域を増やすには星系ごとに影響力(1回限りに支払い)を使い前哨地を建てていく必要がありました。そこで狂信権威を選択したのですが、プレイスタイルが悪いのか、よく奴隷が不満を抱えストライキ?を起こしてしまいました。これに関しては防衛設備を地上に建て防衛軍を増やすことで対処できますが、タイルを無駄に消費している感じがすごいあります。 影響力が毎月4増えるのは領域を増やすのに好都合でしたが、Life-Seededとの相性が微妙でした(後述)。 Life-Seededについて 自分の種族がガイア型惑星にしか住めなくなるが、母星がガイア型25でスタートします。使用感想としては初期ブーストはいいかな?って感じです。ただ、アップデート後の環境ではプレイスタイルを頑張らなければ弱いかなと。その理由としては、まずアップデート後は研究コスト補正にPOP数が関係なくなり領域星系数が関係あるようになりました。つまり領域が大きければ大きいほどコストが高くなるということ。星系の資源はプレイヤーではどうしようもならない固定資源のようなものですから、それに頼って領域を大きくし過ぎると研究コストがすごいことになってしまいます。植民地を確保して賄おうにもガイア型にしか住めないのでかなり増やしにくいです。 ガイア型にしか住めないというのは、有機生命体であってロボットなら他のタイプの惑星に植民できるというのであれば、Life-Seededはロボットプレイをするしかないのかもしれないですが、これに関しては未検証です。
プレイスタイルについて 今回自分がとったプレイスタイルは要塞でガン守りキメるガチ芋戦略です。アップデートで要塞関連が変わり結構使えるものになったらしいので。 防衛プラットフォームを上限まで…

if(flag == true)はありなのか?なしなのか?

最近バズってるようなので便乗
ちなみに元ネタはこちらだとおもいます→qiita - Javaではif (flag == true)というコードを書いてはいけない

※真偽値としてのネーミングとしてflagはナシだろ~~wという話はナシでお願いします
※以下flag変数は真偽値とします

結論から言うと純粋な真偽値の場合はif(flag == true)、if(flag == false)はナシです

まず、最初に前提を整理します
if文は真偽値(true or false)で判定しなければならないJavaではbooleanKotlinではBooleanC#ではbool 話の簡素化のために整えておかないといけないこともあります JavaではBooleanのことは考えない(理由は省略)(ボクシング次第では考えていいかも)KotlinではBoolean?のことは考えないnullableな場合はtrue or false or nullなのでC#ではbool?のことは考えないnullableな場合はtrue or false or nullなので
前提を整理し終わったので、if(flag == true)はアリなのかナシなのか考えていきましょう。 おそらくif(flag == true)論争では2つのパターン(==演算子で比較するかどうか)に派閥分けされていますが、ここでは3つのパターンに分けます
1つ目のパターン:==演算子で比較する// true比較の場合 if(flag == true) // false比較の場合 if(flag == false) はい、もっともナシなパターンです(理由は後述)。

ナシと言われる理由は前提を振り返ればわかりますがif文の中では最終的に真偽値であればよいのですがflagはそもそも真偽値です。わざわざtrueと==比較して真偽値にする必要はありません。わざわざ==比較することは理論上はパフォーマンスが落ちます。

このパターンがなくならない理由は可読性がまぁまぁいいことです。
冗長であろうがパフォーマンスが理論上悪かろうが可読性があれば正義です(そういう考えもできる)。

自分も昔はこのパターンな書き方を多用していましたが後述の理由によって今はしません(少なくとも意識してはしてないはず)。

2つ目のパターン:否定演算子!を使う// true比較の…