Kotlin [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/02/27(土) 01:46:01.68

JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org

**デフォルトの名無しさん** · 2017/05/31(水) 22:55:29.26

kotlinでjsってどんな感じ？
typescriptの型情報取り込めると知って
ちょっと気になってきた。
type scriptより関数型が強めだから幸せになれそう

**デフォルトの名無しさん** · 2017/06/01(木) 10:14:24.94

hasteやGHCjsじゃ駄目なん？

**デフォルトの名無しさん** · 2017/06/01(木) 10:55:02.44

SwiftとKotlinでちょっと遅延評価リストを比較した

■Kotlin
オンラインコンパイラ：　https://try.kotlinlang.org/

val a = generateSequence(0){it+1}

//A 問題なし
println("A: "+ a.take(10).toList() )

//B 問題なし
println("B: "+ a.take(10).map{it*10}.toList() )

//C 問題なし
println("C: "+ a.filter{3<it}.take(10).toList() )

//D 問題なし
println("D: "+ a.map{it*10}.take(10).toList() )

//E 問題なし
println("E: "+ a.map{it*10}.filter{50<it}.take(5).toList() )

**デフォルトの名無しさん** · 2017/06/01(木) 22:36:13.65

ファイルの整形処理で少しカジッてみたけど、ファイルIOはJavaのAPIと古い？関数と新しい？関数が混在してて、Googleの海をさ迷ったよw
kotlinのsequenceを返すreadLinesが欲しかったんだけど、見つけきれなかったので自作した。
既存であるのかな？

**デフォルトの名無しさん** · 2017/06/01(木) 23:40:24.53

lineSequence()とかuseLines()とか？

**デフォルトの名無しさん** · 2017/06/02(金) 22:36:46.10

androidアプリってscriptの方で作れますか？
kotlinc -script

**デフォルトの名無しさん** · 2017/06/04(日) 01:46:21.69

ヘイ親方質問
ファイルをShift_JISで保存してもUTF-8で保存しても
fun main(args: Array<String>){
println("日本語です")
}
が特段のオプションなしのkotlincでコンパイル可能で
特段のオプションなしkotlinでWindowsコマンドプロンプトに無事表示可能なんだけども
これはいったいどのへんが気を遣ってくれてるんですかね

**デフォルトの名無しさん** · 2017/06/07(水) 14:34:22.11

>>144-150
自己レス。データクラスを使った

data class Person(val age: Int, val name: String)

val mlist: MutableList<Person> = mutableListOf( );

mlist.add(Person(25, "Tom"));
mlist.add(Person(25, "Dave"));
mlist.add(Person(20, "Kate"));
mlist.add(Person(20, "Alice"));

val sortedList = mlist.sortedWith(compareBy({ it.age }, { it.name }))

sortedList.forEach {
println( it )
}

出力
Person(age=20, name=Alice)
Person(age=20, name=Kate)
Person(age=25, name=Dave)
Person(age=25, name=Tom)

**デフォルトの名無しさん** · 2017/06/16(金) 14:28:27.40

C#やってる人にとって凄く扱いやすかったりする？
ちなみに母ちゃんのあだ名がコトリン

**デフォルトの名無しさん** · 2017/06/16(金) 14:48:16.06

母ちゃんモダンな名前なんやね

**デフォルトの名無しさん** · 2017/06/16(金) 14:58:47.38

古都りん

**デフォルトの名無しさん** · 2017/06/16(金) 14:59:56.64

秋の奈良レンタサイクル“古都りん” - 奈良県自転車利用総合案内サイト
nara-cycling.com/rent-a-cycle/

**デフォルトの名無しさん** · 2017/06/16(金) 15:20:11.64

>>247
kotlinじゃなくてJavaの仕様でしょ。

**デフォルトの名無しさん** · 2017/06/19(月) 11:01:48.86

なんでgoogleはkotlinをアンドロイドアプリの公式言語にしたの？
なんでgolangじゃないの？
オラクルとの訴訟もあるのにjavaを切ったほうがいいんじゃないの？

**デフォルトの名無しさん** · 2017/06/19(月) 12:12:39.67

java切ってどうなるか考えればわかるだろう

**デフォルトの名無しさん** · 2017/06/19(月) 21:05:24.63

>>254
オラクルとの訴訟での争点は言語じゃなくてAPI
言語を何にしようが無関係

**デフォルトの名無しさん** · 2017/06/21(水) 02:18:15.32

>>254
使ってみればわかるけどgolangってメタプログラミングな部分が弱いから
既存のシステムの置き換えに向いてる言語ではないと思う。
新たに1から構築するなら可能性はあるけど。

**デフォルトの名無しさん** · 2017/06/21(水) 02:21:47.43

>>256
これ。でも段階的にjavaに頼らないようにしていくのかもね。
コレクション系がandroid用に別実装になるとかあれは面白い。

あとオラクルにjavaから離れるアピールして圧力をかける政治的意図もあると思う

**デフォルトの名無しさん** · 2017/06/21(水) 02:29:38.77

JetBrainsうまうまってこと？

**デフォルトの名無しさん** · 2017/06/21(水) 02:33:39.09

Jetbrains買収あるか？

**デフォルトの名無しさん** · 2017/06/21(水) 02:59:48.56

むしろ、なんで買収しないんだろな。
つーかjetbrainが謎すぎて。
なんで一社であんなに幅広くide作れるのかが謎

**デフォルトの名無しさん** · 2017/06/21(水) 05:02:56.13

なんか怪しい力働いてるよなjetbrainsって

**デフォルトの名無しさん** · 2017/06/21(水) 07:39:22.48

理解できないことを怪しいって言うのは悪い癖だぞ

**デフォルトの名無しさん** · 2017/06/21(水) 07:48:18.50

共通のベースに言語乗せてるだけだし、開発なんかほとんどオフショアだろ

あ · 2017/06/21(水) 08:05:49.79

Kotlin nativeも頑張ってるしな。
結構そっちにも期待。

**デフォルトの名無しさん** · 2017/06/21(水) 10:55:07.74

>>265
同意

**デフォルトの名無しさん** · 2017/06/22(木) 01:10:45.12

>>265
これが本格的に動き始めたらswiftの存在意義が、、、、、無くなるよね

**デフォルトの名無しさん** · 2017/06/22(木) 07:18:08.18

ラットナーがjetbrainsに転職するってマジ？

**デフォルトの名無しさん** · 2017/06/22(木) 09:16:59.96

>>267
swiftのが言語仕様は優れてる

**デフォルトの名無しさん** · 2017/06/22(木) 09:32:44.22

Swift on Androidが地味に進んでるからそっちも期待
一定量の完成度が見込めたらKotlinから移行するのも良いかも

**デフォルトの名無しさん** · 2017/06/22(木) 11:33:55.45

>>270
地味に進んでるって、Xamarin Androidのように、SwiftからJavaのAndroid APIを呼び出す仕組みが用意されつつあるの？
それが出来なきゃKotlinの代わりにはならんよ

**デフォルトの名無しさん** · 2017/06/22(木) 12:05:57.96

kotlin/nativeでndkを使いたい
sdk側とndk側で同じ言語使えたら開発楽だと思う

**デフォルトの名無しさん** · 2017/06/22(木) 12:16:58.77

>>272
それ何のためにNdk使うの？

**デフォルトの名無しさん** · 2017/06/22(木) 13:02:54.50

Kotlin.NativeからObjCが叩けるようになるのが先か
SwiftからJavaが叩けるようになるのが先か
どっちも現実的にはないわな

まぁそれでも言語/フレームワークの開発が絶賛進行中のSwiftの方に夢があるかな

**デフォルトの名無しさん** · 2017/06/22(木) 13:14:48.12

>>273
画像加工とかはndkで処理したい

**デフォルトの名無しさん** · 2017/06/22(木) 14:17:05.90

>>275
その用途だとKotlin nativeじゃ多分意味無い
Nativeコードに変換すればc++で書いたのと同じ性能が出るというわけじゃないからね

**デフォルトの名無しさん** · 2017/06/22(木) 19:32:17.15

>>276
llvmのコード吐くんじゃないの？

**デフォルトの名無しさん** · 2017/06/22(木) 19:42:12.44

いやJVMは十分速いよ?
C++でもJavaと同じように書いたらパフォーマンスは大差ない
C++が速くなるのは低レベルな汚いハックができるからで、それができないならあまり意味がないということだろ

**デフォルトの名無しさん** · 2017/06/22(木) 19:55:38.89

>>277
kotlinから変換されたllvmコードは、kotlinの言語仕様を満たすために、
例えばメモリ管理はガベージコレクションが前提となるから
その為の少し大きめなランタイム付いてくるはず
境界チェックのようなc++なら省略できるコードも漏れなく付いてくるはず

**デフォルトの名無しさん** · 2017/06/22(木) 22:21:35.91

>>276
c++ほどの速度は出ないのね
結構早くなると思って期待したんだけど

>>278
以前画像にブラー処理掛けたときは結構違った

**デフォルトの名無しさん** · 2017/06/23(金) 09:47:11.55

それは言語の違いではなくアルゴリズムの違いではなかろうか
もしくはJavaヒープ/Nativeヒープの性能差分ならByteBufferを使う手もある
そこまで考慮するくらいなら素直にC/C++使った方が幸せだけど

ByteBufferはGC走りづらいから性能良いんだけど普通は使わないよねぇ

**デフォルトの名無しさん** · 2017/06/23(金) 10:01:06.35

ByteBuffer(もしくはそれと同様の使い方をするプリミティブ配列)がGCの性能に大きな影響を与えるって一体どんな状況?
バッファは長時間使い回すんだからGCなんかほとんど関係ないだろ
GCの負担になるほど頻繁に生成しまくるとかアホなことしてるとしても、その場合はネイティブヒープの方が割当時のオーバーヘッドの分かえって遅くなりそうだし

**デフォルトの名無しさん** · 2017/06/24(土) 03:52:32.49

メモリ管理とかよりさ
JVMやDEXの中間コードからJITされたコードの場合、SIMDとかの特殊なCPU命令はまず使ってくれない
つまり十分に最適化されたネイティブコードに勝てる見込みはまずない

最適化されたライブラリの一つであるlibjpeg-turboみたいなのをアプリから使うときに
libjpeg-turboのAPIを一つ一つJNIでラップするのと
libjpeg-turboのAPIをNDKで利用してからアプリ固有のAPIだけJNIでラップするのと
どっちがリソース管理が楽かは言うまでもない

この「NDKで利用して」をKotlin Native でより安全に書けるのなら、価値はありそうだな

**デフォルトの名無しさん** · 2017/06/24(土) 04:16:45.08

んなこたない。
JITでSIMDぐらい普通に使われるし、
むしろ事前に最低限サポートするCPUを決めてそれに足を引っ張られる事前コンパイルより、実行しているCPUの拡張命令を最大限使えるJITの方が効率的なコードになる事もある。

**デフォルトの名無しさん** · 2017/06/24(土) 06:57:58.73

どっちなのさ！

**デフォルトの名無しさん** · 2017/06/24(土) 09:27:02.16

JITコンパイラの性能次第

**デフォルトの名無しさん** · 2017/06/24(土) 09:54:27.72

Dalvik, ARTどころかOracle JVMですらSIMDは扱うよ

>>282
俺が使った時は、Androidでnew byte[1024]がOutOfMemoryでByteBuffer.allocate(1024)は通るような状況(実際は1KじゃなくM単位
画像加工を試みたんだけどbyte配列のままで処理しようとしたら分割操作が必要になってクッソ重たいのwww

**デフォルトの名無しさん** · 2017/06/24(土) 10:51:37.84

ByteBufferのAPI嫌いだな
Javaの過剰設計の伝統ここに極まれりって感じ

**デフォルトの名無しさん** · 2017/06/24(土) 15:08:57.88

NIOが出た当初も評判良くはなかったよねー, ないと困ることは確かにあるんだけど必要とする人は少ないし
それでも当時は仮想マシンを謳うくせにこんな基本機能もないのかよって風聞で過剰どころか不足と言われ
1.4は標準ライブラリを大量に追加しようってリリースだったから仕方ない

**デフォルトの名無しさん** · 2017/06/26(月) 14:38:34.02

ByteBufferはdirectがあるからまぁ必要。

**デフォルトの名無しさん** · 2017/06/27(火) 08:01:46.32

間接的にお世話になってることも知らずに文句言ってるアホばっか。

**デフォルトの名無しさん** · 2017/06/27(火) 08:19:48.98

エンジン構造も知らずに車に文句付けてるってくらい論点が異なるよ
使う側であれば別に中身を意識しなくていいんだよ

**デフォルトの名無しさん** · 2017/06/27(火) 08:45:00.53

>>288とかはエンジンなんて車にいらねーって言ってるんだけどなｗ

**デフォルトの名無しさん** · 2017/06/27(火) 12:59:12.87

APIに文句言ってるだけじゃね
Javaが使いにくいからとKotlin使ってるお前らにそれを批判する資格はない

**デフォルトの名無しさん** · 2017/06/27(火) 14:24:44.78

実際問題java apiからkotlinを切り離すのはわりと簡単だったりするの？
google内で独自apiを作ってたりして

**デフォルトの名無しさん** · 2017/06/27(火) 16:52:29.37

余裕やろうな
やる価値があるかは別として

**デフォルトの名無しさん** · 2017/06/27(火) 17:26:00.35

技術云々でなく普及のための絡みで難しそうだな

**デフォルトの名無しさん** · 2017/06/27(火) 19:50:52.50

Java APIじゃなくJava Libraryだとするなら、そこを切り離して実用に耐えるにはJava1.4くらいには過剰設計しないと無理じゃね

**デフォルトの名無しさん** · 2017/06/28(水) 03:27:10.10

>>296
googleってそういうの不得意な気がする。
なんかいろいろ作りっぱなし感がすごい

**デフォルトの名無しさん** · 2017/06/28(水) 03:57:50.54

GoogleとOracleってまだちょっと揉めてるん？

**デフォルトの名無しさん** · 2017/06/28(水) 09:52:23.47

>>299
またOracleから技術をパクれは余裕綽々よ

しかし、あれは酷かったよなw
JVMのスポンサー/共同開発に名を連ねたと思ったら
その数年後にAndroid発表してSun JVMじゃなく自前のDalvik VM使うからwwwってSunを切り捨てる暴挙
そりゃ技術をパクられたSun(Oracle)はブチキレるわ

Googleはもうパクらないだろうから、Jetbrainsがパクることを期待しようか

**デフォルトの名無しさん** · 2017/06/28(水) 11:09:49.25

>>301
Androidは何もパクってないが
捨てられたApache Harmonyを引き継いだだけやし現時点ではOpenJDKになるってし
元を正せばOSS化を進めてたウンコOracleが突然APIのライセンスだなんだ

**デフォルトの名無しさん** · 2017/06/28(水) 11:10:28.02

と喚き散らしたことのほうがどう考えても筋違いや
Oracleはキチガイ集団

**デフォルトの名無しさん** · 2017/06/28(水) 12:55:43.96

当時、Sun JVMはクローズドソースでVMの中の人どころか、Java層のAPIも非公開だったろ...
ノウハウパクっておいてApache JVMから引き継いだだけだからってのは盗人猛々しいわw

**デフォルトの名無しさん** · 2017/06/28(水) 13:02:32.04

>>304
JavaのAPIが非公開だったってそれまでJavaプログラマは何を見て書いてたんだよ。

**デフォルトの名無しさん** · 2017/06/28(水) 13:09:21.41

面倒な奴だなぁ
APIとLibraryを区別する気はないのかと思ったら、そこは区別するのかよ

**デフォルトの名無しさん** · 2017/06/28(水) 13:45:27.56

>>304
sun javaはsunのものだがjavaはsunのものではない
何をぱくったって？

**デフォルトの名無しさん** · 2017/06/28(水) 16:04:17.62

だーかーらー、>>301で言っているだろ
クローズドソースのSun JVMに首突っ込んで、自前のJVM実装のリリースに走ったのを悪行と言っている
当時もJVM自体はGNU, Apache, MSと多様に存在してたし、独自のJVMを作る自体は気にしないけど
仲良くしようぜーって近づいて技術を盗み見るのをパクったと表現しているんだ

自前のJVM作ろうが、JVM上で動く別言語作ろうが一向に構わんが、あの時のGoogleの行為は大笑いだったんだぜ

**デフォルトの名無しさん** · 2017/06/28(水) 17:10:45.64

結局フェアユースという落ちが付いたろ。判決はどこまで確定したっけ？

**デフォルトの名無しさん** · 2017/06/28(水) 17:18:12.30

Googleはライセンス料を回避するためDalvikを作った
Oracleが訴訟起こしたのはGoogleから和解金や継続的なロイヤルティーを得るため
金vs金

GoogleがOracle JVMでなくApache Harmonyをベースに開発したため
OracleはソースコードでなくAPIの著作権という方向からDalvikの権利を押さえに掛かった

今のところ訴訟バトルはGoogle有利に進んでいる模様

**デフォルトの名無しさん** · 2017/06/28(水) 17:24:37.74

訂正

特許とAPIの著作権

**デフォルトの名無しさん** · 2017/06/28(水) 19:19:21.21

しかし何れにせよ、Androidが無かったらJava（及びそのエコシステム）はもっと廃れてたはずだよね

**デフォルトの名無しさん** · 2017/06/28(水) 20:01:24.52

JDKのライブラリ群は30年ぐらい前の発想で作られた頭が痛くなりそうな
APIも多いのでKotlinでJDKと別にモダンなコアライブラリ
作ってくれるならとても嬉しい

**デフォルトの名無しさん** · 2017/06/28(水) 20:13:20.22

>>312
androidが何に寄与したって？w

**デフォルトの名無しさん** · 2017/06/28(水) 20:17:07.79

>>312
Javaの市場はほぼ100%エンタープライズとWebが占めててAndroidなんかカスみたいなもんだぞ

**デフォルトの名無しさん** · 2017/06/28(水) 20:20:40.71

javaはヌルポ排除できない時点でだめだよな。

**デフォルトの名無しさん** · 2017/06/29(木) 00:16:43.10

>>316
だからKotlinが生まれたんだっけな

**デフォルトの名無しさん** · 2017/06/29(木) 11:02:50.69

Kotlinでヌルポ起きないってギャグにしては古すぎる・・・

**デフォルトの名無しさん** · 2017/06/29(木) 11:39:09.06

オプショナルを正しく使ってればヌルポなんて起きようがないんだがw

**デフォルトの名無しさん** · 2017/06/29(木) 11:40:38.32

ニュアンスとか前提の差で話が噛み合ってない気が

**デフォルトの名無しさん** · 2017/06/29(木) 11:47:39.86

ぬるぽは既存のライブラリやフレームワークから飛んでくるからKotlinを使ったところで解決にならないんだよなあ
自分で書いた範囲ならJavaでもぬるぽなんて滅多に出さないわ

**デフォルトの名無しさん** · 2017/06/29(木) 12:00:09.83

テストあるからJava1.4でもClassCastExceptionは滅多に出さない的な

**デフォルトの名無しさん** · 2017/06/29(木) 12:22:12.95

プリベリファイ要求してたMobileのJava1.3は偉大だったんだなって

**デフォルトの名無しさん** · 2017/06/29(木) 12:28:25.79

>>322
そういう問題じゃない
Javaのライブラリにおいて引数にnullが渡されそれが不正値であるときに発生する例外は何か? →たいていぬるぽ
Javaのライブラリにおいて属性の値がnullでそれが不正値であるときに発生するエラーは何か? →だいたいぬるぽ
明示的なチェックを怠りランタイムエラーに頼るこの糞習慣がある限りぬるぽは決して無くならない

**デフォルトの名無しさん** · 2017/06/29(木) 13:21:35.51

>>321
んなことは言わなくても全員わかっとる

**デフォルトの名無しさん** · 2017/06/29(木) 14:39:25.51

そもそもテストを書けばぬるぽの9割は生まれる前から死ぬ
しかしそれでもテストをしないできないすり抜けるからこそ静的言語コード本体に「テスト機能」をつけたのだよ
人間とは間違うものなのだ

**デフォルトの名無しさん** · 2017/06/29(木) 15:15:09.10

Javaのライブラリにおいて引数に配列上限値が渡されそれが不正値であるときに発生する例外は何か? →たいていあれいいんでっくすあうとばうんど
Javaのライブラリにおいて配列の要素値がマイナス値でそれが不正値であるときに発生するエラーは何か? →たいていあれいいんでっくすあうとばうんど
配列操作を安全に操作できないKotlinはJavaと同じレベルで糞だな

ヌルポだけがバグの原因だと思ってるアホは置いといて、やっぱテストフレームワークを充実させたJUnitは偉大だわ

**デフォルトの名無しさん** · 2017/06/29(木) 15:20:20.01

なんだこいつw

**デフォルトの名無しさん** · 2017/06/29(木) 19:47:56.73

>>327
問題の発生頻度が段違いだろ。

型システムを採用しているにもかかわらず、型無しのヌルポを排除できないjavaはとても古臭い。

**デフォルトの名無しさん** · 2017/06/29(木) 20:58:35.28

Sunが死んだ
太陽が死んだ

**デフォルトの名無しさん** · 2017/06/29(木) 21:19:35.80

日本語で書かれた Kotlin に関するいい感じのチュートリアルってない？

**デフォルトの名無しさん** · 2017/06/29(木) 21:34:38.83

書いて覚えろ

**デフォルトの名無しさん** · 2017/06/30(金) 00:28:01.26

>>331
情熱、自己顕示、小遣い稼ぎ、まあ理由はなんでもいいんだけど自分でちょろっと記事でも書いてみようとするとよくわかる
・Java入門
・Kotlin詳説
・よくわかるIntelliJ
・10日で学ぶAndroidプログラミング
あたりをごっちゃまぜにしたものが必要になる
ぶっちゃけとてもめんどくさい

**デフォルトの名無しさん** · 2017/06/30(金) 01:58:55.10

チュートリアルならKotlin Koansやるのが一番じゃない？
Webでも手軽に出来るしIDEAにも専用のプラグインがある

**デフォルトの名無しさん** · 2017/06/30(金) 10:50:35.57

あれいいんでっくすあうとばうんどは、0除算並みの恥ずかしいミス。
nullpoとは次元が違うわｗ

**デフォルトの名無しさん** · 2017/06/30(金) 11:53:55.60

>>334
webのやつってなんか重くないですか？

**デフォルトの名無しさん** · 2017/06/30(金) 13:36:42.47

そんなんローカルに持ってきてやればよろしいがな
IntelliJ入れてあるならプラグインがある
コマンドラインしかないなら…、まあ、IDEなしは初心者であるからこそ積極的には勧めないんだけども、
コマンドラインしかないならgitで持ってきてテストが通るようにスクリプト本体編集すればいい
えっコマンドラインからテストするやり方がわからない？

**331** · 2017/06/30(金) 13:58:27.40

>>334
本家 (またはそれに近いコミュニティ) にある資料ならここで聞くまでもなく有るのはわかりますがな。
そうじゃなくて「日本語で」あったらうれしいなぁという話で。

**デフォルトの名無しさん** · 2017/06/30(金) 14:35:57.92

自分用でなく他の人用という話だったら
Chromeなどでのページ翻訳＋原文で頑張る方法を勧める

**デフォルトの名無しさん** · 2017/06/30(金) 14:52:56.61

>>331
あるかどうかで言えば「まだないです」
Kotlinは基本的にはただのJavaなので、上にもあるけどJavaの基本知識（を教えるだけの余裕）が必要なのでちゃんとした入門制作はハードルが高い
巷の日本語ページがスタートブックすら超えられてないのはそのへんが理由
そしてスタートブックですら初心者全く掬えてない
助走読本はとても頑張ってるけれど、助走ゴールな気がちょっとしなくもない。これはやっぱりJavaが悪いので仕方がない
ttps://drive.google.com/file/d/0Bylpznm149-gTGRjOFRkWm9PODg/view

**デフォルトの名無しさん** · 2017/06/30(金) 15:08:07.12

>>340
なるほど。
Java の資産を使えるメリットと引き換えに Java の知識が必要ってことね。
というか、 Java をマシに使える言語って感覚なのかな。

私は Scheme (LISP 系言語) を普段使いしてるので同じく LISP 系言語である Clojure を検討してたんだが、
やっぱり Java の知識が必要で、しかし Java について全然知らないので他の系統はどうなんかなと思って
このスレに来た次第。

やっぱりそう簡単にはいかんか……