Kotlin [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org むしろ、なんで買収しないんだろな。
つーかjetbrainが謎すぎて。
なんで一社であんなに幅広くide作れるのかが謎 共通のベースに言語乗せてるだけだし、開発なんかほとんどオフショアだろ Kotlin nativeも頑張ってるしな。
結構そっちにも期待。 >>265
これが本格的に動き始めたらswiftの存在意義が、、、、、無くなるよね ラットナーがjetbrainsに転職するってマジ? Swift on Androidが地味に進んでるからそっちも期待
一定量の完成度が見込めたらKotlinから移行するのも良いかも >>270
地味に進んでるって、Xamarin Androidのように、SwiftからJavaのAndroid APIを呼び出す仕組みが用意されつつあるの?
それが出来なきゃKotlinの代わりにはならんよ kotlin/nativeでndkを使いたい
sdk側とndk側で同じ言語使えたら開発楽だと思う Kotlin.NativeからObjCが叩けるようになるのが先か
SwiftからJavaが叩けるようになるのが先か
どっちも現実的にはないわな
まぁそれでも言語/フレームワークの開発が絶賛進行中のSwiftの方に夢があるかな >>275
その用途だとKotlin nativeじゃ多分意味無い
Nativeコードに変換すればc++で書いたのと同じ性能が出るというわけじゃないからね いやJVMは十分速いよ?
C++でもJavaと同じように書いたらパフォーマンスは大差ない
C++が速くなるのは低レベルな汚いハックができるからで、それができないならあまり意味がないということだろ >>277
kotlinから変換されたllvmコードは、kotlinの言語仕様を満たすために、
例えばメモリ管理はガベージコレクションが前提となるから
その為の少し大きめなランタイム付いてくるはず
境界チェックのようなc++なら省略できるコードも漏れなく付いてくるはず >>276
c++ほどの速度は出ないのね
結構早くなると思って期待したんだけど
>>278
以前画像にブラー処理掛けたときは結構違った それは言語の違いではなくアルゴリズムの違いではなかろうか
もしくはJavaヒープ/Nativeヒープの性能差分ならByteBufferを使う手もある
そこまで考慮するくらいなら素直にC/C++使った方が幸せだけど
ByteBufferはGC走りづらいから性能良いんだけど普通は使わないよねぇ ByteBuffer(もしくはそれと同様の使い方をするプリミティブ配列)がGCの性能に大きな影響を与えるって一体どんな状況?
バッファは長時間使い回すんだからGCなんかほとんど関係ないだろ
GCの負担になるほど頻繁に生成しまくるとかアホなことしてるとしても、その場合はネイティブヒープの方が割当時のオーバーヘッドの分かえって遅くなりそうだし メモリ管理とかよりさ
JVMやDEXの中間コードからJITされたコードの場合、SIMDとかの特殊なCPU命令はまず使ってくれない
つまり十分に最適化されたネイティブコードに勝てる見込みはまずない
最適化されたライブラリの一つであるlibjpeg-turboみたいなのをアプリから使うときに
libjpeg-turboのAPIを一つ一つJNIでラップするのと
libjpeg-turboのAPIをNDKで利用してからアプリ固有のAPIだけJNIでラップするのと
どっちがリソース管理が楽かは言うまでもない
この「NDKで利用して」をKotlin Native でより安全に書けるのなら、価値はありそうだな んなこたない。
JITでSIMDぐらい普通に使われるし、
むしろ事前に最低限サポートするCPUを決めてそれに足を引っ張られる事前コンパイルより、実行しているCPUの拡張命令を最大限使えるJITの方が効率的なコードになる事もある。 Dalvik, ARTどころかOracle JVMですらSIMDは扱うよ
>>282
俺が使った時は、Androidでnew byte[1024]がOutOfMemoryでByteBuffer.allocate(1024)は通るような状況(実際は1KじゃなくM単位
画像加工を試みたんだけどbyte配列のままで処理しようとしたら分割操作が必要になってクッソ重たいのwww ByteBufferのAPI嫌いだな
Javaの過剰設計の伝統ここに極まれりって感じ NIOが出た当初も評判良くはなかったよねー, ないと困ることは確かにあるんだけど必要とする人は少ないし
それでも当時は仮想マシンを謳うくせにこんな基本機能もないのかよって風聞で過剰どころか不足と言われ
1.4は標準ライブラリを大量に追加しようってリリースだったから仕方ない ByteBufferはdirectがあるからまぁ必要。 間接的にお世話になってることも知らずに文句言ってるアホばっか。 エンジン構造も知らずに車に文句付けてるってくらい論点が異なるよ
使う側であれば別に中身を意識しなくていいんだよ >>288とかはエンジンなんて車にいらねーって言ってるんだけどなw APIに文句言ってるだけじゃね
Javaが使いにくいからとKotlin使ってるお前らにそれを批判する資格はない 実際問題java apiからkotlinを切り離すのはわりと簡単だったりするの?
google内で独自apiを作ってたりして Java APIじゃなくJava Libraryだとするなら、そこを切り離して実用に耐えるにはJava1.4くらいには過剰設計しないと無理じゃね >>296
googleってそういうの不得意な気がする。
なんかいろいろ作りっぱなし感がすごい GoogleとOracleってまだちょっと揉めてるん? >>299
またOracleから技術をパクれは余裕綽々よ
しかし、あれは酷かったよなw
JVMのスポンサー/共同開発に名を連ねたと思ったら
その数年後にAndroid発表してSun JVMじゃなく自前のDalvik VM使うからwwwってSunを切り捨てる暴挙
そりゃ技術をパクられたSun(Oracle)はブチキレるわ
Googleはもうパクらないだろうから、Jetbrainsがパクることを期待しようか >>301
Androidは何もパクってないが
捨てられたApache Harmonyを引き継いだだけやし現時点ではOpenJDKになるってし
元を正せばOSS化を進めてたウンコOracleが突然APIのライセンスだなんだ と喚き散らしたことのほうがどう考えても筋違いや
Oracleはキチガイ集団 当時、Sun JVMはクローズドソースでVMの中の人どころか、Java層のAPIも非公開だったろ...
ノウハウパクっておいてApache JVMから引き継いだだけだからってのは盗人猛々しいわw >>304
JavaのAPIが非公開だったってそれまでJavaプログラマは何を見て書いてたんだよ。 面倒な奴だなぁ
APIとLibraryを区別する気はないのかと思ったら、そこは区別するのかよ >>304
sun javaはsunのものだがjavaはsunのものではない
何をぱくったって? だーかーらー、>>301で言っているだろ
クローズドソースのSun JVMに首突っ込んで、自前のJVM実装のリリースに走ったのを悪行と言っている
当時もJVM自体はGNU, Apache, MSと多様に存在してたし、独自のJVMを作る自体は気にしないけど
仲良くしようぜーって近づいて技術を盗み見るのをパクったと表現しているんだ
自前のJVM作ろうが、JVM上で動く別言語作ろうが一向に構わんが、あの時のGoogleの行為は大笑いだったんだぜ 結局フェアユースという落ちが付いたろ。判決はどこまで確定したっけ? Googleはライセンス料を回避するためDalvikを作った
Oracleが訴訟起こしたのはGoogleから和解金や継続的なロイヤルティーを得るため
金vs金
GoogleがOracle JVMでなくApache Harmonyをベースに開発したため
OracleはソースコードでなくAPIの著作権という方向からDalvikの権利を押さえに掛かった
今のところ訴訟バトルはGoogle有利に進んでいる模様 しかし何れにせよ、Androidが無かったらJava(及びそのエコシステム)はもっと廃れてたはずだよね JDKのライブラリ群は30年ぐらい前の発想で作られた頭が痛くなりそうな
APIも多いのでKotlinでJDKと別にモダンなコアライブラリ
作ってくれるならとても嬉しい >>312
Javaの市場はほぼ100%エンタープライズとWebが占めててAndroidなんかカスみたいなもんだぞ >>316
だからKotlinが生まれたんだっけな Kotlinでヌルポ起きないってギャグにしては古すぎる・・・ オプショナルを正しく使ってればヌルポなんて起きようがないんだがw ぬるぽは既存のライブラリやフレームワークから飛んでくるからKotlinを使ったところで解決にならないんだよなあ
自分で書いた範囲ならJavaでもぬるぽなんて滅多に出さないわ テストあるからJava1.4でもClassCastExceptionは滅多に出さない的な プリベリファイ要求してたMobileのJava1.3は偉大だったんだなって >>322
そういう問題じゃない
Javaのライブラリにおいて引数にnullが渡されそれが不正値であるときに発生する例外は何か? →たいていぬるぽ
Javaのライブラリにおいて属性の値がnullでそれが不正値であるときに発生するエラーは何か? →だいたいぬるぽ
明示的なチェックを怠りランタイムエラーに頼るこの糞習慣がある限りぬるぽは決して無くならない そもそもテストを書けばぬるぽの9割は生まれる前から死ぬ
しかしそれでもテストをしないできないすり抜けるからこそ静的言語コード本体に「テスト機能」をつけたのだよ
人間とは間違うものなのだ Javaのライブラリにおいて引数に配列上限値が渡されそれが不正値であるときに発生する例外は何か? →たいていあれいいんでっくすあうとばうんど
Javaのライブラリにおいて配列の要素値がマイナス値でそれが不正値であるときに発生するエラーは何か? →たいていあれいいんでっくすあうとばうんど
配列操作を安全に操作できないKotlinはJavaと同じレベルで糞だな
ヌルポだけがバグの原因だと思ってるアホは置いといて、やっぱテストフレームワークを充実させたJUnitは偉大だわ >>327
問題の発生頻度が段違いだろ。
型システムを採用しているにもかかわらず、型無しのヌルポを排除できないjavaはとても古臭い。 日本語で書かれた Kotlin に関するいい感じのチュートリアルってない? >>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 のサイトで、ブラウザからプログラミングできる ■ このスレッドは過去ログ倉庫に格納されています