Kotlin [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org >>331
情熱、自己顕示、小遣い稼ぎ、まあ理由はなんでもいいんだけど自分でちょろっと記事でも書いてみようとするとよくわかる
・Java入門
・Kotlin詳説
・よくわかるIntelliJ
・10日で学ぶAndroidプログラミング
あたりをごっちゃまぜにしたものが必要になる
ぶっちゃけとてもめんどくさい チュートリアルならKotlin Koansやるのが一番じゃない?
Webでも手軽に出来るしIDEAにも専用のプラグインがある あれいいんでっくすあうとばうんどは、0除算並みの恥ずかしいミス。
nullpoとは次元が違うわw >>334
webのやつってなんか重くないですか? そんなんローカルに持ってきてやればよろしいがな
IntelliJ入れてあるならプラグインがある
コマンドラインしかないなら…、まあ、IDEなしは初心者であるからこそ積極的には勧めないんだけども、
コマンドラインしかないならgitで持ってきてテストが通るようにスクリプト本体編集すればいい
えっコマンドラインからテストするやり方がわからない? >>334
本家 (またはそれに近いコミュニティ) にある資料ならここで聞くまでもなく有るのはわかりますがな。
そうじゃなくて「日本語で」あったらうれしいなぁという話で。 自分用でなく他の人用という話だったら
Chromeなどでのページ翻訳+原文で頑張る方法を勧める >>331
あるかどうかで言えば「まだないです」
Kotlinは基本的にはただのJavaなので、上にもあるけどJavaの基本知識(を教えるだけの余裕)が必要なのでちゃんとした入門制作はハードルが高い
巷の日本語ページがスタートブックすら超えられてないのはそのへんが理由
そしてスタートブックですら初心者全く掬えてない
助走読本はとても頑張ってるけれど、助走ゴールな気がちょっとしなくもない。これはやっぱりJavaが悪いので仕方がない
ttps://drive.google.com/file/d/0Bylpznm149-gTGRjOFRkWm9PODg/view >>340
なるほど。
Java の資産を使えるメリットと引き換えに Java の知識が必要ってことね。
というか、 Java をマシに使える言語って感覚なのかな。
私は Scheme (LISP 系言語) を普段使いしてるので同じく LISP 系言語である Clojure を検討してたんだが、
やっぱり Java の知識が必要で、しかし Java について全然知らないので他の系統はどうなんかなと思って
このスレに来た次第。
やっぱりそう簡単にはいかんか…… 何に困ってるのか分からない
その辺の経験あるなら手動かせば身に付くまで大して掛からないだろう googleのやるべきことはFWを全てkotlinに書き換えることやな 英語読めない奴がLISPとかすげえな
やってて死にたくならない? >>344
Scheme は日本語訳あるからそんなにつらくない。
Common Lisp とかみたいに仕様の日本語訳がなくてクソ巨大なのを使いこなすのは大変だと思うけど、
最初からリッチなライブラリがそろっているので実用しやすいという人もいる。
>>342
興味本位なので面倒くさかったらやらないだけ。
ハードルの低い入門があれば見るかもっていう感じ。 >>335
RuntimeExceptionの子クラスの例外は総じて同レベルで恥ずかしいんだが
原則、どれもパラメータチェックしてないから発生する例外だからな
むしろ、ヌルポが一番恥ずかしくて、それが起きないようにオプショナルがあるんだと思ってる Javaがクソなのと、クソの処理をしないプログラマがマヌケなのは別の話。一緒にすんな。
Optionalはその変数がnullでないことをコンパイル時に保証できたっけ?
実行時コストをかけて解決するのは鈍臭い。 そのクソの処理をしないプログラマでも安全にコーディングさせるためにオプショナルがあるんだよ...
オプショナルがあるからヌルポが起きないわけでもないから完全に安全とは言えんがまぁ言及すまい >>349
まともな言語なら(c++でさえ)コンパイル時に済ませられるのを、わざわざ実行時にチェックしなきゃいけないのは鈍臭い、つうこと。 全く噛み合ってなくてワロタ
どんだけ崇拝してるんだかwww Rustだとガチでヌルポが起こせないゾ
オプショナルとかいう中途半端なモノを誇ってるKotlinとは格が違う
まぁ他の面倒が多くて全く勧められるものじゃないけど
オプショナル()だけで素晴らしいとか絶賛してる子は他にメリットを見出してどうぞ ヌル安全つうのはモダンな言語じゃ標準装備なんじゃろ? >>338
Koansとか英語読めなくても(読まなくても)分かるんだが…
メインはKotlinのソースコードで説明読めないなら問題と答えを比べて見るだけで基本的な構文は勉強出来るし
そもそもプログラミング自体の理解が浅いならJavaとかから始めないと例え日本語の解説あっても分からんと思うよ Java + Groovy = Kotlin
つまり、Javaに関数型を付けた言語だから、
最初に、オブジェクト指向を学ぶ必要があるから、かなり大変
まずこの本で、オブジェクト指向を学ぶ
スッキリわかる Java入門 第2版、2014
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
WEB+DB vol.94 の特集が、Kotlin, Electron
Try Kotlin のサイトで、ブラウザからプログラミングできる Kotlin.NativeよりSwiftのが使えるって本当?
Kotlin.Nativexはキーワードばかり散見されて実質何がどこまで完成してるのか分からんのだが
SwiftはWin, *nix, Androidで普通に動くようになってるけど、Kotlinはそこまで至ってないんだよね? Kotlin/NativeのCとの連携ってJNIを踏襲するんじゃなくて、現在進行形で独自I/F仕様を作ってるっぽいな
一応、Linux, Mac, Winで動くようだけど完成度はSwiftのがまだマシだ いまさらJNIはないだろ。
JVMの方も10か11でJNIに代わるNative対応が予定されているし。 なおさら踏襲しとけよと思わなくもないな
Kotlin/NativeのNative I/F
Java9以前, KotlinのJNI
Java10以降のFFI
と仕様が乱立するのか・・・
Kotlinって仕様安定してないのな JNI踏襲とか無いわ
そうしたいなら普通にJava使っとけば良いと思う KotlinがJNIを踏襲していることは知らないのか、知ってて度外視なのか
Kotlin/NativeアゲのためにKotlinを蔑んでちゃどうしようもないな Kotlin/Javaが使うのは何でもないこと。
もしKotlin/NativeがJNI使うとしたら、それどこのXamarinだよってことだろw JNIのI/F踏襲して
external fun fgetc(file: CPointer) char;
とかでいいじゃんっつーね
externalの先はわざわざVM/Runtimeかます必要はなくてCに繋げればいい
Kotlin/NativeのNative I/FはC++に対応してないようだし
後発で新規に仕様を作り始めてる割にしょっぱいなぁと思う
C++に対応するならまぁアリかと思うけどないんだろうしね >Cに繋げればいい
ならJNI要らないじゃん
JNI踏襲ならJNIEnvの実装必須でしょ
C++対応とか正気かよ
C++同士でさえコンパイラやバージョン違いで
マングリングが異なってリンク不可能だからCリンケージ使うのに I/Fとランタイムの区別が出来てない
まぁ>>368とかもJavaとKotlinとKotlin/Nativeと区別してないからその程度なんだろうけど
> C++対応とか正気かよ
Rustのアホはbindgenって補完ツールで実現したぞ
他言語では見たことないから当然Kotlinもナイと思ってる, 後発なんだから検討はして欲しいけどねー javaに触らずにkotlinだけでandroid開発できるようになんないかな >>373
>>365からの一連の流れはKotlin/NativeでのI/Fの話だぞ
区別云々は君が話の前提から混乱しているだけ
>bindgen
見たけどClang 3.9(〜4.0)のマングリングを前提としてるから
ヘッダだけじゃなく実装本体もClangでビルドする必要があるようだが
完全なC++コードがある場合は使えるが、ABIの代わりにはならないだろう >>374
5年後にバージョン3とかになればなんとか… スマホアプリの言語ぐらい統一して欲しい
googleとappleで話し合えないのかねぇ
mac以外でもios用のアプリ製作からリリースまで最後まで出来るようにしてほしいよねぇ Appleの昔から自分たちのプラットフォームにユーザーを囲いこんで、他のプラットフォームからの鎖国という考え方
Googleは自分たちのサービスを他のプラットフォームでも利用してもらってユーザーを増やし、収益を伸ばしたい考え方
統一でという方向で動く時、どちらがそれを拒んだり我を通した条件を突きつけてくるかは明白 >>378
お互い何のメリットが?
開発者としても何のメリットも感じないが 開発者として開発環境を統一できるメリットがあるだろうが >>382
開発側からすればwebフロントエンド系のように開発者余りまくりで単価デフレになるデメリットしかない >>378
ブラウザですら自分の思い通りに開発できないからってwebkitからblinkフォークさせたのに >>382
androidとiPhoneでフレームワークが違うから無理。 >>378
react native とtypescriptに期待してる。
typescriptならサーバサイドにも耐えそう。言語仕様もパターンマッチング提案中だったり、
結構格好いい言語になってきた >>385
JVM言語で「iOSとAndroidを統一環境で開発できる」と言うのもなんかがっかりではある
君は一体歴史のどこを見てきたのかと >>388
別次元?なにが?
ある側面だけみてメリットデメリットの話してもなんの意味もないやろ >>378
GoogleはAndroid開発環境を複数OS向けに出している
iOSアプリの公式開発環境がMac用しかないのはAppleが狭量なだけだし、Googleは無関係
話し合いで進展する問題ではない 仮にAppleがiOSの開発環境をWindows向けに出すとして、iOSエミュレータはついてくんのか?っていう
Androidのような大真面目なエミュレータではなく、iOSはMac上でも「シミュレータ」しか動かん
それがWindows上で動かせるようになるとはあまり思わない >>376
JNIEnvが必須とか言い出すからIFじゃなくRuntimeの話を交え始めたと理解したが?
RustがclangでC/C++本体のコンパイルが必要だからNGなら
Kotlin/Nativeがclang等々でC本体のコンパイルを必要とするのもNGになっちまうだろw
他言語を他コンパイラでコンパイルするのは当然で、C++に限ってはその上でKotlin/Nativeが頑張るんだよ どうでもいいけど擬人化ことりんちゃんまだかよ
無能ども >>394
>IFじゃなくRuntimeの話
Javaからnativeを使う方のJNIは以下から成り、JNIEnvはJNI仕様の中核
・CのABI
・シンボル名と引数のルール
※ Java_パッケージ_クラス_メソッド(JNIEnv*, thisインスタンス, java側引数)
・プリミティブ型の定義
・JNIEnv(JNI関数群)のインターフェイス仕様
>clang等々
特定のコンパイラ/バージョン依存なのと, CのABI依存なのはまったく異なる
Kotlin/Nativeのinterop, JavaのJNI, C#のP/Invoke, RustのFFIなどはABIで連携するけど
bindgenはI/FでなくC++コード全体を取り込む外部ツール
Clangの実装に強く依存するからRustの仕様の一部として取り込まれることも無いだろう
誰かがKotlin版bindgenを作ろうとすることに特に反対は無いけどすべきとも思わない
Kotlin/NativeでJNIのI/Fを使う話も労力に見合うものは得られない >>394
追記
そもそも根本的な話としてCのABIと呼んでいるもの(↓と同義)が何か分かってる?
https://github.com/JetBrains/kotlin-native/blob/v0.1.0/INTEROP.md
>target is a C library
https://doc.rust-lang.org/book/first-edition/ffi.html
>C ABI
バイナリ内のシンボル名や呼出規約であって別にコード自体がC言語である必要は無い
C++(extern "C"), Rust, Haskellなどネイティブにビルド出来るものは
C ABIでのライブラリを作成する機能を持つものは多い
Cに無い機能(C++例外など)をそのまま透過出来ないというだけで、
C++やRustで作った共有ライブラリをKotlin/Nativeから呼べる なんでandroidのために新しい言語覚えなきゃいけないねん 汎用言語が Android では使えないというのは制約だろう。 呼出規約には、2種類ある
呼び出した方で、引数のスタック領域の確保・解放をするものと、
呼び出された方で、するもの さらには引数を後ろからスタックに積むもの、前から積むものもってのもある。 >>396
なんか長々書いてるけど、結局新規のIF, 文法切っても現仕様はSwift同程度なんだよね
中身がどうあろうがいいけどショボい機能しか載せられないなら、Kotlinの上っ面IFだけはKotlinとKotlin/Nativeで共通化して欲しかったって話だよ
まぁ絶賛開発中の言語仕様だし期待しないで気長に待つわ しょっぱいだのショボいだのディスるのは簡単だが
浅い知識と考えでそれを言うのは恥ずかしいことだと少しは自覚しろよ・・・ >>398
Kotlinは簡単な言語だからいいでしょ 構文糖衣が多くてperlみたいな雰囲気を感じないでもない >>408
>構文糖衣が多くてperlみたいな雰囲気を感じないでもない
カッコとかなしでむき出しで書かれる A keyword B みたいな構文はどうにも慣れないね
A.method(B)やfunction(A,B)と同じはずなんだが、空白という文字で区切られていると脳が一瞬括りを拒否する >>406
最初(>>367の時点)からKotlin層の文法だけを注視してて、C層は気にしてないからなぁ
Kotlin層の共通化が大変な訳でも無し、わざわざ大変な新規IF切ってしょぼい機能になってるのは恥ずかしいよ >>412
何何どういうこと?
まだkotlinは遠くから眺めているだけだから気になる? >>412
C層を気にしてないんじゃなく知らないだけだろ
だから「わざわざ大変な新規IF」なんて的外れなレスをすることになる
JNIライブラリを書いたことすら無さそうだし
良案と思っているものがあれば↓で提案してみたらどうだ?
https://discuss.kotlinlang.org/
鼻であしらわれるのがオチだが 言語なんて色々あるんだから自分の好きなの選んだらええんやで
Androidに正式採用されてから一気に書き込み増えたな >>414
別にKotlinがそこまで好きなわけじゃないし、ここでKotlin/Nativeの喜劇を鼻で笑ってた方が楽だし・・・
業務でJNIを書いてたのは15年くらい前の1.3の頃だねぇ、あの頃はJNIはC++が使えなくてラッパー層の実装も面倒だった
いつからか知らんけど、JNIEnvにC++ APIが追加されててC層の実装が楽になってて数年前にビビったわ
・・・と老害なレスしとけば、論点ズラして技術論から離れた場外乱闘になって俺が飽きれるだろ >>413
Kotlin
--
external fun sayHello();
System.loadLibrary("hello")
sayHello() // C API呼び出し
Kotlin/Native
--
import kotlinx.cinterop.*
sayHello() // C API呼び出し
// 別途、defファイル, gradleファイルを用意
Kotlin/Nativeはexternal funを宣言しないでシームレスにC APIを利用させるために、KotlinからIF構成を変えてる
external funの宣言がなくなった分だけKotlin層の記述は楽になったけど
代わりにdef, gradleが必要で、Kotlinと互換性なくて、C++ APIは呼べないという制限がある
そこまで変えるなら、頑張ってC++ API呼べるようにして欲しいなーって冗談半分で言ったら噛み付かれた プログラマの勉強しようとおもってますが、これはジャバとなにがちがいますか?
大差ないようであればこれを勉強しようおおもいます >>418
Javaとの大きな違いは、Javaを完全に理解してる人向けで初心者向けの情報がほぼゼロという点 ObjCというマイナーで黴の生えた言語がiOS開発入門の障害になっていたところに現れたSwiftとは違い、
Javaは開発者ならはっきり言ってできて当然なので今後も初心者向けの情報の充実は望めない Android入門は今後kotlinベースになるだろ。 それ頼む。javaのライブラリに依存すると言ってもandroid似関係するのはごく一部でしょう?
フルセットのjavaを学ぶ必要ないよね >>418
Kotlinは話題になってはいるが「Java言語を使いこなしている人がその知識を使うと楽に書ける」ので好評を得ている
Java言語を全く知らないのであればKotlinはむしろ二重三重の習得障壁があるので勧められない
なにするかもぜんぜんわからないし現実世界で聞ける師匠もいないというのならJavaでいいんじゃないかな
JavaなしでのKotlin学習術というのは数年したら出てくるとは思うがそれはKotlin本体の充実も待たねばならんのでしんどい >>417
随分トーンダウンしたなw
>Kotlin/NativeのNative I/FはC++に対応してないようだし
>後発で新規に仕様を作り始めてる割にしょっぱいなぁと思う
↓
>頑張ってC++ API呼べるようにして欲しいなーって冗談半分で言った
そもそもKotlin(JNI)との互換性の話にC++は関係無いだろう
JNIでもエクスポートする部分はextern "C"なんだから おう、そうだなw
それでKotlin/NativeのIFの話はどうした?論点ズレてんよ >>425
日本語が不自由なのか?
「Kotlin(JNI)との」と書いているんだが 僕Javaはちょっとしか使ったことないLisperだけど、Kotlinサクッと学んでAndroid開発してるよ? 難しくないよ? >>423
javaのエコシステムが学習障害なのかな。歴史がある分根深そう
gladleとかいうタスクランナー用に専用言語あるんだっけか swift、typescriptと触ってoptionalが無い言語は正直触りたくなくなっとる。 >>418
Kotlin = Java + Groovy
Javaのオブジェクト指向に、Groovyの関数型を付けたもの。
クロージャを多用する
まずこの本で、Javaとオブジェクト指向を学ぶ
スッキリわかる Java入門 第2版、2014
その後、
プログラミング GROOVY、2011
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016 ■ このスレッドは過去ログ倉庫に格納されています