TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
集合論に基づいた言語を作りたい
【マウスだけで】Scratch【プログラミング】その1
ほぼ初心者プログラマでするべき事がわからない
【会津】パソコン甲子園2004【若松】
HSPだって
テストしにくいコードをテストする方法 その2
JavaScript 4
C言語相談室(上級者専用）
クライアント「神々たる仕変！後悔など遅い！」
PureBasic

Kotlin 4


1 ：2018/07/17 〜 最終レス ：2018/09/12
JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう
https://kotlinlang.org


※前スレ
http://mevius.2ch.sc/test/read.cgi/tech/1521401186/

2 ：
乙

3 ：
Xamarin程の糞はない

4 ：
公式サイト
https://kotlinlang.org/
公式ブログ
https://blog.jetbrains.com/kotlin
コードを貼れる所
http://rextester.com/l/kotlin_online_compiler

Google、KotlinをAndroidアプリ開発言語に選定
http://jp.techcrunch.com/2017/05/18/20170517google-makes-kotlin-a-first-class-language-for-writing-android-apps/

5 ：
オンラインコンパイラ
https://ideone.com/

コードの実行と保存にアカウントなどは不要
https://ideone.com/Jef7Hv

6 ：
class A{
var a=A //ここでStackOverFlowになる
fun foo(a:A){this.a=a}
}
無限ループしてる感じになっているのかな？
どう実現すればいいですか？

7 ：
>>6
何がしたいのか全く分からない。

var a = Aの部分は何をしたいの？

8 ：
>>6
もしnull許容型にしたくないって意図なら

lateinit var a: A

にするとか

9 ：
探索のnodeを作っていまして
aのところに親ノード入れようとしているんですが、それがうまく行かなくて

10 ：
var a=Aは初期化しているだけです

11 ：
それなら普通に
var a: A? = null
で初期化しとけよ

どうしてもインスタンスを入れたいなら
var a = A()
でもいいけどさ

aにはAのインスタンスを入れなくちゃいけないのに、なんでクラスそのものを入れようとしてるんだ

12 ：
それと質問するときは差し支え無い範囲で実際のコードそのまんまの方がいいよ

class Node {
var parent: Node? = null
}

とか書いてあると何がしたいのか読み取れるけど、
Aとかaじゃ何が何やらわからない

13 ：
>>6
それ var a = A って書いてる？
コンパイルエラーにならない？

14 ：
あー、var a = A()になってそうだな
それなら無限ループになるわ
対策方法は上に書いてあるやつでいいけど

15 ：
よくわからんが class A(val a: A) じゃいかんのか？

16 ：
あ、だめか。class A(val a: A?) じゃないと永遠に初期化不能かw

17 ：
これおもしろいな、aをnull許容型にしないとインスタンスできないだろ
Javaだとそんなこと考えることもなかった

18 ：
試してないけど、nullobject用の派生クラスを用意して、nullobjectのaにはthis代入すりゃいいんじゃない？

19 ：
>>12で出来ました
ご迷惑おかけしました。ありがとうございます
他の言語だと、自動でnullが代入されているから、詰まってしまった

20 ：
これはと思い階乗計算してみたが、微妙…orz

class A(n : Int, f : Int = 0) {
. val a = if (n > 0) ? A(n - 1, f * n) : else { println(f); null }
}

21 ：
>>20
おっと、いろいろ混ざった。
?と:は消して

22 ：
kotlinスレの優しさは異常

23 ：
地獄への道は善意で舗装されている
みたいな

24 ：
>>19
そこ(Nullableと非Nullable)がことりんの最大の特徴だから、ぜひちゃんと理解して使いこなしてあげてね。

25 ：
intellij入れたんだけど
runしようとするとmain classを入力してって言われるんだけど
関数だけでrunできないですか？

26 ：
>>25
ユニットテストからなら

27 ：
>>25
fun main(args: Array<String>) {
// 実行したいコード
}

これが書いてある実行用のファイル作ってrunすれば動く

28 ：
>>26
テスト書かなきゃだめなんですね

>>27
そうしてるんですがNo main class specified 言われるんですよ

main classってなんや
static void main …のあのおまじないですか？

29 ：
>>28
main関数の書いてあるエディタのタブ部分を右クリックでメニューからのRunはどう？

30 ：
fun main(args: Array<String>) { } をクラスの外に作った瞬間にその行の左に緑の三角が表示されて、そこから実行できるね
クラスの定義は無くてもいいけど、クラスの中じゃダメだ

31 ：
>>27のやり方で普通に動いたよ。
左側のProjectペインから、その実行したいktファイルを右クリックして、そこからRunしてもだめ？
もしくは上の方にあるRun configurationを一回削除してから同じことをしてみるとか。

32 ：
>>27
一応確認だけど、関数名はmainになってるよね？
他の名前だとだめだよ

33 ：
>>25
状況がよくわからないからそのエラーが出た時のスクリーンショット取って見せて。ソースが表示されてる状態のな。

34 ：
Kotlinスレの半分は優しさで出来ています

35 ：
残りの半分はXamarinで出来ています

36 ：
それだけはお許しください

37 ：
Delphiがアップを始めました

38 ：
みなさん回答ありがとうございました

新しいプロジェクトでやったらできました。
おそらく原因はNewでファイルを作るときにkotlin scriptを選んでしまったためだと思われます

srcディレクトリ直下にkotlin file/class
でファイルを作ったら実行できました。

39 ：
Xamarinみたいな糞でやるからそうなる

40 ：
https://gigazine.net/news/20180720-android-to-fuchsia-in-5-year/
kotlin短い命だったな

41 ：
あ、そこまで頭回らんかった
kotlin 作ったやつが一番辛い案件だな

42 ：
今更、LinuxベースじゃないOS作ったから使えよ！って言われて流行ると思う？

43 ：
Kotlin は今はとにかく JavaVM で動くコードを出すコンパイラで Android 開発で使って貰って
世界中に広めてある程度定着させれば良い。その隙にネイティブとか新OSの実行環境用コードを
出すコンパイラを作ってくれれば問題なし。そして Java は死亡して Kotlin は生き残る。

44 ：
JavaVMなどの他の環境の寄生をやめるなら基本的なクラスライブラリはどうするんだ?
コンパイラだけじゃダメじゃね。javaみたいなコレクションフレームワークやらHttpやソケットライブラリあたりも標準で用意してくれないとね。というか寄生やめるならUIフレームワークも必要じゃねぇ?無理だな。
サーバーサイドならいらんが。

45 ：
ごめん。寄生やめるって話じゃなくて今はとりあえずandroidに寄生してその間に広めてその後は他の寄生先見つけりゃいいって話しかな?

46 ：
寄生しても良いし、根底から全部作っても良いが、とにかく生き延びる率は非常に高いと思う。

まあでもネイティブでライブラリ全部作るとしてもそんなに時間掛からないんじゃないかな。
問題はどういうやつを作るかだと思う。

47 ：
Kotlin良い言語だからもったいないよな
というか新OSに入れ替わるとしても、既存のAndroidアプリ資産を無視するわけがないから何かしらの互換は保たれると思うけど

48 ：
JavaFXをKotlinで拾ってくれないかな？
OpenJDK+OpenJFX+Kotlinでまとまってくれれば
みんな幸せ

49 ：
>>40
対応言語にKotlinじゃなくてSwiftが入っているというのが、危機感を刺激される。
>>48
ぜひそうなって欲しい。

50 ：
なにこれ、最近kotlin始めたばかりなのに終了かよwwww

51 ：
Fuchsiaが普及するとしてもその頃にはKotlin/Nativeも出来上がってるでしょ
ただ、Googleの進め方を見るにKotlin/Dartの実装も検討した方がいい気はする

52 ：
Dart程の糞はない

53 ：
まぁ、でもnull safetyを存分に味わうにはkotlinが標準クラスライブラリを用意してくれるのがいいんだけどね。

54 ：
結局javaのライブラリに依存しちゃうもんねえ

55 ：
その点、オラクルってメシウマだよな

56 ：
>>53
これあくしろよ
ファイル周りぐらいでもやってくれ〜

57 ：
>>51
現状でも、言語仕様を一つ修正するのにJVM, JS, Nativeの3通りの変更が必要になる。
この上、Dartのサポートとか、なんという無茶振り。

58 ：
>>53
せめてnull safety対応generics欲しいよね。

59 ：
JSはいっそ無くしても良いと思うけどねえ

60 ：
ことりんjsにトランスできたんか…

61 ：
できるそうだがやったことがない・・・やればいいんだなw

62 ：
遊びで触ったことあるけど、メリットを何も感じなかった。
特に他のJSライブラリを使うのがえらく面倒くさい。

63 ：
サーバーサイドでKotlin使ってたら有用な面もある
計算やチェック処理なんかをクライアント側と共用出来るから

64 ：
JSいらんから、その分の労力をNativeに注力してくれ

65 ：
>>40
＞C言語、C++、Dart、Go、Python、Rust、シェルスクリプト、Swift、TypeScript

この中で生産性の良く主流になりそうな言語ってどれだろう？
PythonかSwiftくらい？

66 ：
>>65
あとTypescriptかなあ。
Goはキモいからそこまで広がらないと思う。

67 ：
それ最後に書いてあるよ。

暑さには要注意だ。脳が暖まり過ぎると段々おかしくなる。

68 ：
>>66
キモナイ

69 ：
入れたときの型そのままで取り出せる汎用的なmap的なもんって実装できないかな

70 ：
Keyの型にValueの型を持たせればできそう

71 ：
>>69
Anyとスマートキャスト利用するしかないだろうなあ

72 ：
>>66
TypescriptってC#scriptみたいな物か
何気に一番Javaに近そうねｗ

73 ：
>>72
確かにJavaに似てるけど、あれは普通のJSの拡張みたいなもんだから使いやすい、というか既にめっちゃ使われてる

74 ：
>>73
KotlinよりTypescriptの方が流行る?

75 ：
用途が違いすぎるから比較できない。

76 ：
TSからJS呼ぶときに戻り値の型意識しなきゃいけないことにイラつく感覚がKotlinからJava呼ぶときにnull意識しなきゃいけないときにイラつく感覚と似ている

77 ：
めっちゃ分かる

78 ：
てか、CとTypescriptとその他を比較する意味あんのか？
分野が違いすぎんだろ

79 ：
null安全特有のバグが入ったり
null安全のためにコードが長くなったりで
あんまメリットない気がしてきた

80 ：
Javaが有償化するけど、Kotlinにも影響ある？

81 ：
なんで影響がないと思ったのか

82 ：
いやひょっとしたら、JetBrainsがいい感じでやってくれるかと．．．

83 ：
>>69だけどkotlinだと無理っぽいな
arrow-ktでlistっぽいのならあったけど
scalaだとshapelessってライブラリで実現してるらしい

84 ：
>>80
Oracle版JDKの有償化な
そのためにOracle自身もOpenJDKに力入れてきたんだから特に問題ない(KotlinもJavaも)

85 ：
>>83
最近ちょこちょこ聞くようになった依存型がこれに使えるのね

86 ：
>>79
null安全が好きでないなら、動的型付言語を使ったほうが幸せになれるんじゃない？

87 ：
>>69 >>83
どういうの使用イメージを望んでるのかよく分からないので
コンパイル不可で構わないから使う側の疑似コードを書いてみてほしい

88 ：
JetBrainsJDKは理想だけど、さすがにそんなことやるほど体力のある会社じゃないだろ

89 ：
>>79
煽るわけじゃなく、純粋に知りたいのだけど、null安全特有のバグって、どんなのがあるの？

90 ：
null安全のために記述が長くなるってのもよく分からんな
kotlinはそうならないようにかなり配慮されてると思うのだけど、もしかしていちいち全部ifでnullチェックでもしてるんじゃないの

91 ：
>>88
そうするとGoogleのAndroidのような面倒な問題を抱える可能性があるのでは？
素直に OpenJDK 使っといた方が良いと思うのだが。

92 ：
LTSしてくれるならね

93 ：
RedHatがOpenJDK11を独自にLTSするらしいから、RedHat系のディストリビューション使ってるなら大丈夫だろ
ubuntuは知らん

94 ：
null安全のせいでコードが長くなるのは

・nullを返しうるメソッドだけど今回に限っては絶対にnullじゃない

ってケースで !! の2文字が増えるぐらいでは

95 ：
>>93
つまりWindowsは死亡と。

96 ：
>>95
これを機にWndowsServerなんてカスは滅ぼそう

97 ：
AdoptOpenJDKが無償のLTS提供するよ

98 ：
>>97
GitHub見てこいよ
アレをプロダクトで安定して使えるようになるまでまだまだ先は長そうだぞ

99 ：
>>87
val map = HashMap<String, 抽象的な何か>()
map["hoge"] = "文字列"
map["fuga"] = 100

val str = map["hoge"] // :String
val num = map["fuga"] // :Int

みたいな感じで
とにかく型チェックやらキャストやらが面倒くさい
実際には自作クラスとかも突っ込みたい

100 ：
試してないんで適当言うけど
Class.forName(className).kotlin.cast(value)
とかでなんとかならんの

101 ：
>>99
型チェックなしだと取り出した変数が何型になっているかわからなくて結局扱えないのでは？

102 ：
その後処理分ける時点で型は見ることになりそう

103 ：
すまん伝わりやすいかと思って抽象的な何かって書いたけど語弊があるわ
まず抽象クラスやらスーパークラスやらこの時点で指定してたらダメだしな
ちなみにarrow-ktのHListはタプルみたいな感じになってた

104 ：
マップに値を突っ込む人は中身の詳細を知らなくて、値を取り出す人はどのキーに何が格納されているか知っているようなシチュエーション、例えば設定ファイルのローダーみたいな奴への適用ならわからんでもない。

105 ：
何に使う気かっていうとJSFでFlushっていう画面間で値渡すためのMapがあるんだけど、型チェック面倒くさいしチェックしないのも嫌だしでいっそ別に用意できないかと思った
入れるときも取り出すときも型は分かってる状況だな

106 ：
XMLなりで文字列化しといて使うときにデシリアライズすれば？

107 ：
keyごとに型が決まってるならjson文字列にしておいてGson使って取り出すとか

108 ：
>>99
Mapに代入のみで型認識するのは難しいな

タプル的な感じでやるか
https://ideone.com/Aekjqn

事前定義でMapに関連付けるか
https://ideone.com/rCFcai

むしろ変数に型が無い言語使うか
https://ideone.com/BUHFe3

109 ：
>>106-107のやり方が使うときにはスッキリできそうだなぁ
>>108
二つ目のやつって色々出来そうに見えて汎用的にならないのが惜しい

110 ：
動的型言語「呼んだ？」

111 ：
よく調べないで書くけどMapでしか渡せないならMapの値にクラス突っ込めないの

112 ：
普通に data class 書くかイヤなら動的型使え案件だな

113 ：
動的型付言語でもMapから取り出したインスタンスに何かするにはそのインスタンスの型のチェックは必要なんだから、
KotlinでもAnyの変数に取り出した後、何かするとき型チェックすればいいのでは？

114 ：
>>109
汎用的ってどういうこと？

115 ：
一回シリアライズするとか正気かよ。

inline fun <ｒｅｉｆｉｅｄ T: Any> ｃａｓｔ(any: Any): T = T::ｃｌａｓｓ.ｊａｖａＯｂｊｅｃｔＴｙｐｅ.ｃａｓｔ(any)

val i = ｃａｓｔ<Int>(ｍａｐ["hoge"])

116 ：
Mapのキーの文字列に対して格納されてる型が決まってるのか
エラーチェック無しで間違ったのが入ってたら例外で良いなら、そんな感じにキャストでいいかもね

117 ：
全角読みにくい

118 ：
>>113
動的型付言語は人間が頭の中で実際の型を把握してればコード上では型チェック不要だよ

Ruby
map = {}
map["hoge] = "今は文字列"
map["hoge"] = 100 #今は整数
map["hoge"] = [1,2,3] #今は整数の配列

map["hoge"].each{|i| puts i.to_s} # 今入ってるのは整数の配列だと人間が把握してるので適正なコード

119 ：
>>117
半角のまま貼り付けたら弾かれたんだ。

120 ：
>>115
明示的にキャスト、間違ってたら実行時例外でいいなら as でよくね

val map = HashMap<String, Any?>()
map["hoge"] = 10
map["hage"] = "zura,katsura"
map["hoge"] = map["hage"]

val list = (map["hage"] as String).split(',')
println(list) // [zura, katsura]

121 ：
Kotlinスレが珍しくKotlinの話してるのか

122 ：
元の>>99についての話なら「キャストなし」が前提なのでは

とはいえシリアライズやGSONなら型定義が必須だろうから
キャストより手間増える気がする

123 ：
使うたびにキャストするのが面倒くさいって話なら一度定義しとけばあとはそのまま使えるgsonはアリじゃね

124 ：
てか別にGsonなんて使わなくてもHashを渡して初期化したら中でいい感じにkeyごとにキャストしておいてくれるラッパークラス作れば良いのでは

125 ：
結局取り出すときに型がわかってるようにするには事前定義が必須と

126 ：
せやな

127 ：
当たり前の話
嫌なら静的型付けなんてやめちまえ

128 ：
性的片付けならお手伝いします。

129 ：
Mapから特定のキーで取り出した値の型をプログラマが知っている場合だけでしか使えなくて、型がわからないなら型チェックが必要になり、そうするとスマートキャストが使えるので現状のままで問題ない事になる。
型チェックなしで使えるようにできたとしてもやはりバグの温床になりそうだというのもある。(しかも見つけにくいバグにならないか？)

130 ：
特にKotlinの場合はJavaのウンコ仕様のせいでジェネリクスの型引数を安全にダウンキャストできないからな

131 ：
やっぱJetbrain VM作ってよ〜

132 ：
>>131
何のメリットが？

133 ：
そもそもVM利用してるのってJavaの遺産利用する為だしな

134 ：
資産ではなく遺産

135 ：
>>99
https://ideone.com/Bxe3Vj

136 ：
>>135
map["hoge"] as String → map.get<String>("hoge")
map["fuga"] as Int → map.get<Int>("fuga")
無 → inline fun <reified T> HashMap<String, Any?>.get(key: String) = get(key) as T

ただのキャストよりコード量が増えて危険な操作であることがわかりにくくなっただけやんけ

137 ：
全然関係ない話

これが出来る事を知らなかった。

val s = "abc"
println("${s + "xyz"}")

ダブルクォーテーションで括った中にダブルクォーテーションで括った文字列がある状態なのに問題なくコンパイルも実行もできる。
${ ... } はコンパイル時に特別扱いしてたんだな。

138 ：
>>137
マジか、知らなかった。
まあやることはあまりないだろうがw

139 ：
{}の中はプラグラムのコードやからな。
それだけやで

140 ：
一番内側のデリミタが来るまでは外側のデリミタはマスクされて見えないという話

141 ：
むしろコンパイル時じゃなかったらビビる
evalがある言語じゃないんだから

142 ：
もちろんネストも出来る

Kotlin　　　https://ideone.com/9oQrPl
Groovy　　https://ideone.com/PkZexd
Swift　　　https://ideone.com/vCuTyE
bash　　　https://ideone.com/9GW6lT

143 ：
>>141
そんな威張るなよ

144 ：
そんな僻むなよ

145 ：
unit testしたいんですが
junit って標準モジュールじゃないんですか？

146 ：
じゃないです。

147 ：
ようやくKotlin1.3の話が出てきた。
ttps://blog.jetbrains.com/kotlin/2018/07/see-whats-coming-in-kotlin-1-3-m1/

148 ：
operator で何も返さない Unit のやつを作るとどうなるかを実験していて気づいたこと。
例えば plus() って + 記号が出てきただけで呼ばれるわけで、そうなると + 記号だけで中身を書き換える事も可能になるんだな。

https://paiza.io/projects/wtY0TgCLyLhRsls2-6wcuQ

149 ：
そりゃまあただのメソッド呼び出しを糖衣構文だし

150 ：
>>149
これができるのなら Unit ではない演算子の結果を捨てるような式はエラーにして欲しかった。

151 ：
DSLに使うからそれは困る

152 ：
JetBrains のサイトに StringBuilder.set メソッドのドキュメントがない事に気づいた。
いやググると見つかるので正確にはあるのだが、どこからリンクされているかがわからない。
普通に考えるとこれは StringBuilder のページからなんだろうが、それはない。getならある。

153 ：
JavaFX+Kotlinでクロスプラットフォームのアプリ作ろうと思ったけど、
やっぱ今からだとElectronの方がいいのかな
SDKからも切り離されたし

154 ：
TornadoFX使ってみてよ

155 ：
竜巻外為良さそうだけど、そもそもJavaFXが流行ってない気が

156 ：
現時点で流行ってないし、java自体がこの状況で今から人気が出てくるとも思えないよなあ
electronかみんな大好きXamarinでも使った方がいいだろう

157 ：
TornadoFX良かった。JavaFXが切り離されさえしなければ...

158 ：
トーナードは良いものだよ。
JavaFX自体が消滅しそうだけど

159 ：
tornado の発音はトーネイドに聞こえるが・・・

160 ：
なんでJavaFXって人気ないの？
Electronが人気すぎるだけ？
Electronコード隠蔽できないから嫌なんだけどな

161 ：
>>160
なんでって、Javaだからだよ
有史以来、FXに限らずクライアントJavaに人気があったことなど無い

162 ：
Android で大人気だけどなw

163 ：
javafxscript用の設計だったからね
script潰れてjava向けに再設計とか時間かけすぎなんだよ

164 ：
アンドロイドせいでjava/kotlinを書かざるを得ない迷惑なはなし

165 ：
>>164
C++やJavaScriptでも書けるだろ

166 ：
C#で書けるだろ、忘れるな

167 ：
はいxamarinネタ禁止

168 ：
加速度センサーに木星や土星の重力加速度があるのですが、何に使うんでしょうか？

169 ：
なんかの実験用じゃない

170 ：
木星や土星へ行った時のため

171 ：
たまに使うよね

172 ：
俺も前職で何度か土星行ったから、そういう時は役に立った

173 ：
どしぇー

174 ：
10年前にJavascriptとDA PUMPが再ブレークすることを予想してた奴が居たら凄いと思う

175 ：
Electron + Kotlin/JS というのはアリ? というかしている人いる?

176 ：
ElectronならTypeScriptでいいだろ

177 ：
プロシュート兄貴を見習え

178 ：
>>175
ReactNativeをKotlin/JSで書こうとして死亡してた人なら知ってる。
出来ないことはない、ってレベルらしい

179 ：
Javascriptが流行ってるのって言語の作りが良いからとかじゃなくて、結局はブラウザで動くからなんだよな
だから、誰かがことりんが動くブラウザを作ればことりん流行ると思う

180 ：
>>179
君に任せた

181 ：
コトリンが動くブラウザをお前らが作っても流行らんよ

182 ：
あ、そうか。JavaScriptの代わりにKotlinスクリプトが動けばいいんじゃないか。そうすればわざわざJavaScriptに変換しなくて済む。

183 ：
GoogleがDartで、それやろうとして、結局、あきらめたじゃん。
Dart自体は、Fuchsiaで復活するみたいだけど。

184 ：
dartもいい言語じゃねぇけど、JSよりかはましだからな。flutter人気でてdart使われるようになったら、dartのchromeブラウザ搭載計画を復活させて欲しい

185 ：
wasmにDOM/GCが搭載されれば色んな言語からの需要があるだろうしそれほど夢物語でもない
kotlinがその中で天下取れるかはまた別の話だけど

186 ：
Chromeだけ動くようになったとしても他のブラウザが追随して、かつそれ以前のバージョンが駆逐されるまで待たないと実用できないからな。

それにDart自体がクソみたいな言語であることは変わらないから、多大なコストかけてまで乗り換えたくはないな

187 ：
TypeScriptという手軽でまあまあなソリューションが広まって、なんかもういいんじゃねという空気だよね

188 ：
プログラミング言語は素晴らしいから広まるんじゃないのだということを我々はこの30年でイヤというほど味わったのでるふぁい

189 ：
でるふぁい

190 ：
Algol

191 ：
WebもアプリもKotlinよりTypescriptだろうか

192 ：
まあそうだね
オラクルの件のせいで今後は(Kotlinが使えるような会社においては)Javaプラットフォームが積極的に選ばれることももう無くなるだろう
どうしてもJavaプラットフォームを使わざるを得ない事情があるときのマシな選択肢としての限定的なポジションに落ち着いていくんだろうね

193 ：
Kotlinは贔屓目でもなんでもなく、Java環境で動く素晴らしいJava代替物なのだが
その肝心の「Java環境でなければならなかったこと」が唐突に外部要因で縮小し始めており回復の理屈もないのだ…
現時点でJavaに業務で縁のない人はちょっと立ち止まったほうがいいかもしれん
Androidでプログラミングしたい？ Unity使えUnity

194 ：
一年前のだけど興味深いディスカッション

なぜKotlin Native？
https://discuss.kotlinlang.org/t/2275/

JetBrainsチームのコメントに気になる文言もある
Rock54のせいで引用出来ないけど18と22

195 ：
今後の状況次第ではJava環境からの脱出口になるから
もっとKotlin/Nativeにパワーを

Kotlin/Native v0.8 released
https://blog.jetbrains.com/kotlin/2018/07/kotlinnative-v0-8-released/

196 ：
言っちゃ悪いけど、開発言語を前提にして物事を考えるのってエンジニアとしてはだいぶ低レベルな段階だよ
そのレベルの連中が多数派を占めるほどにはまだKotlinの裾野は広がってないと思う
梯子外されるのがもうちょっと遅かったらもしかしたらとは思うけど、残念だね

197 ：
仕事と趣味は別という発想が出てこない君はエンジニア以前に社会人としてとても低レベルだね

198 ：
営利利用されない技術は進歩しないから、たとえ趣味でやってる人も離れていくもんだよ

199 ：
それはまた別の話

200 ：
>>196
そうかな、個人でやる分にはC++でもObjCでも構わないけどそうじゃない環境では
記述性などの他に学習コスト/人材調達的にも
Kotlinはバランスの良い言語だと思うんだけどな

201 ：
仕事でサーバサイドkotlin使ってるけど今後はOpenJDKにするかもだって

202 ：
え、むしろ今までOracle使ってたん？
うちは8にする時にOpenJDKに切り替えたわ

203 ：
なんだかんだJDKの混乱も今だけだとは思うけどな。
かっちりしたエンプラのシステムはOracle使うだろうし、そうじゃなくて現時点でKotlin使ってるようなフットワークの会社なら普通にOpenJDKのアップデートに追随していくだろうしな。

204 ：
>>202
JavaFXしたかったんだ.....
公式にJavaFX使うならOracleJDK使えって.....
OpenJDK9には統合されると思っていたら、ご覧の有様だよ.....dayo.....

205 ：
>>204
>公式にJavaFX使うならOracleJDK使えって
初耳だ…

206 ：
そもそもRedHatクローン使ってればOpenJDKでなんの差し支えもないからな、数ヶ月前みたいな絶望感はない
FX勢は、なんというか、がんばれw

207 ：
>>205
今見ると書いてないな...
記憶違いかもしれないが、今となってはどっちでもいい....orz

208 ：
情報が錯綜して勘違いやデマ流されたりするのが今のJavaは良くないな

209 ：
>>> println("ちん${"ピョロ${"す${"ぽー"}"}"}ん")
ちんピョロすぽーん
>>>

210 ：
まさかJavaよりJavaScriptが主流になる日がくるなんて・・・
会社入りたての頃にJavaScriptでHP作る担当だった奴を見下してた自分を叱ってやりたい

211 ：
>>210
そもそも担当言語で同僚を見下すこと自体人として終わってるから悔い改めるためにXamarinのライセンス買ってこい

212 ：
Xamarin程の糞はない

213 ：
ネックは処理が重いだけだから可能性はあったよな

214 ：
>>210
その当時の JavaScript と今の JavaScript は同じか?

215 ：
>>214
同じだよ。
JavaScriptの有用性に気付いたグーグル先生がGoogle Mapを作ってから流れが変わった。

216 ：
JavaScriptはブラウザで動くからあの立ち位置にいるだけで基本的にはうんち言語
CoffeeScriptだのDartだのTypeScriptだのKotlin/JSだのが出てくるのもJavaScriptがうんち過ぎてなるべく書きたくないからだし

217 ：
>>216
Node.js知らんの?

218 ：
>>217
Javascriptがブラウザで動かなければ、多分Node.jsは生まれなかった。
あれ? ここJavascriptスレだっけ?

219 ：
>>218
閑Kotlinのスレです。

220 ：
Xamarinスレだぞ、いい加減にしろ

221 ：
ES2018まで至った今としては至極平凡な言語
とりたてて語ることも無い

222 ：
それがブラウザでそのままネイティブに動けばいいのにな
トランスパイラ必須だし

223 ：
コンパイル型言語は対象が何であれコンパイル要るし
JavaScriptとか動的なのも狭義にはコンパイルされてる

単にソースをそのままで動かしたいだけなら babel-standalone とかで
ブラウザ上でトランスパイルすれば似た感じにはなる
でも開発に関してならインクリメンタルビルドやライブリロードの方が重要かと

224 ：
フロントエンド周りは一時期進化のスピードが狂ってたからな
デファクトだった技術が1年で時代遅れになるとか、頭おかしかった
当時のフロントエンド周りの人らは何故かそれを誇りにしてる感があったけど、
普通に考えたらそんなのに追随するための無駄コストがかさむわけで、結果的にユーザーにとってはなんのメリットもない狂騒だったな

225 ：
おまえら数日前にやってたJetBrains様の半額セールにお布施した？
All Productsパック買っちゃったからもう何が流行ろうとも IntellJIDEA と一蓮托生
Flutter が google スマホ公式言語になっても開発環境はほぼ IntellJIDEA ベース決定だから
いまのうちに Android Studio で Kotlin やって慣れておけよ

226 ：
>>215
ああ。Ajax とか。そういう言葉が作られたぐらいか。
そういや XMLHttpRequest 自体は1999年からあったんだよな。

227 ：
そもそもブラウザソフトは時代遅れ
既にブラウザからよりもアプリからの方がネットワークアクセスが多くなってる
HTML + CSS + JSはもう時代遅れ

228 ：
そうかなあ？

229 ：
webとappの境界は既に曖昧

230 ：
初めてアンドロイドのアプリ作る人がいきなりことりん使うのは無謀？

まずはjavaからですかね？

231 ：
プログラミング自体が初めてならJavaからの方が良いと思う

232 ：
プログラミングはc、java、pythonに少し触れたことがある程度です

肝心のjavaに関してはあまり覚えてないです

233 ：
Kotlinでいいと思うよ。そのレベルならJavaの余計な煩わしさに振り回されない方がいいと思う。

234 ：
IT業界に入らないならJavaなんて一生触らなくていいぞ

235 ：
あるプログラミング言語がドイツ製でドイツ語でしか解説が書いてなかったとするじゃん
その場合まあまずは簡単にでもドイツ語から学ぶよね

んで、Kotlinは実はJavaプログラムで解説が書いてあるんよ
メソッドのちょっと詳しい内部動作とかあれこれ便利ライブラリの使い方とか全部Javaベースで説明されるのよ
どうすればいちばん能率的だと思う？というお話なのだ
なのだ

236 ：
Javaは書けなくてもいいけど読めないと辛い
特にメソッドの呼び方と読み方とクラスの関係あたり

237 ：
初心者に言わなくてもいい余計な情報を山ほど叩きつけて混乱させる悪習がここでも、、

238 ：
まずこの本を3回読んで、オブジェクト指向を学ぶ
スッキリわかる Java入門 第2版、2014

その後、太郎本を読む。
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016

これが最短！

239 ：
Kotlin使ってる人はJava10年選手とかで初心者のこと全然思い出せない人ばかりだからな
KotlinとJavaの区別がつかなくなってると言っていい
Javaの知識ゼロでKotlinやった身から言うとJavaの知識は必須
「それはKotlin本体の話ではない」で毎時間のように詰まったぞ

240 ：
結局、開発を始めると、言語の部分は関係ない

ほとんどが、Android のフレームワーク・やり方がわからないという部分

241 ：
少し触れたことがあるっていうのがどの程度かわからないけど、自力で小さなツールスクリプトを2,3作ったことがある程度なら
別にJavaわざわざやらなくてもJava読む分には苦労しなかったよ

242 ：
Android界隈ではまずはJavaからおじさんが闊歩し始めてるのか
とりあえずC言語からおじさんの亜種だな

243 ：
ジェネリクスあたりでわからなくなるとは思う
あれはピュアKotlinでの説明見たことないしJavaでの動作読んだほうがいい

244 ：
初心者がとりあえず何か書いてみるって段階ならジェネリクスなんて存在自体知る必要もないのでは

245 ：
さすがにそのレベルだとオブジェクト指向で詰まるでしょ
Javaを知らなくても他のオブジェクト指向言語の経験は最低でも必要

246 ：
C#なんかも初学者お断り言語として誕生してそのまま普及して今に至ってるわけだし、
初学者を取り込めるかどうかって実はそれほど重要ではないと思う
Java, C, Python, VBAに並んでプログラミング教育に採用されるくらいにならない限り、初学者の流入が言語の普及を大きく後押しすることはない

247 ：
誰か初心者向けのJava抜きでも大丈夫な入門書書けば良いのでは？
書けるやつここにも居るだろ？居ない？
売る方法はAmazonでいきなり電子書籍で出せばいい。

248 ：
>>246
誰もそんな話してないぞ

249 ：
>>247
書く能力のある人はいるかもしれないが、それだけの時間をつぎ込める人はまずいないと思われる。

250 ：
232です
みなさんレスありがとうございます

人によって結構意見が分かれるみたいですね

とりあえずjavaの復習しつつAndroid Studioにも触れていこうと思います

251 ：
>>250
ご覧の通りここだとみんな好き勝手なこと言って申し訳ない。
ぶっちゃけどちらで書いても大差ないから、両方軽く見てみて自分がやりやすそうだと直感した方でいいよ。

252 ：
オブジェクト指向は初心者に無理

253 ：
>>249
いやもう夏休みの長い学生とかでも良いんだけどな。内容がまともなら誰が書いても構わないわけだし。

まあ学生はおすすめだな。後で就職する時に自慢げに言えるぞ。
変に期待され過ぎて後々おかしくなるかも知れんがw

254 ：
面接でkotlinの話しても通じないだろ

255 ：
>>254
数年後だろうからそれはわからない。

まあでもどんなものでも技術系の本書きましたってのは例えAmazonで電子書籍出しただけでも思い切り自慢して良いと思うけどね。特に学生なら。

256 ：
本までは出さなくてもいいけど、そこらの勉強会に行ってLTしてるだけでも評価上がるわ
学生に限った話ではないけど

257 ：
>>247
それは中身としては「Javaの小難しいとこを初心者向けに解説した良書」という存在の難しい書物なのでは…

258 ：
Java習得している人の説明は、
Javaだとこう書くけどkotlinだとこう書く。で説明できている気になるからなあ
書籍もそういう書き方のものばかり
C♯も出始めの頃はC++を例えに説明されてたなあ
これではプログラミング初学者には理解できないわけで

259 ：
読んだことないけどkotlinで書いてるAndroid入門本出てたろ？
あれはさすがにJavaの知識前提では書いてないんじゃないの

260 ：
Xamarinはやめとけ

261 ：
まあでも新OSの噂を考えたら、Flutterもキャッチアップしておいた方が良さそうだよな。
Dartは糞だと思うが、結局言語自体の糞さなんて無関係に必要ならば使わざるを得なくなるのはObjectiveCが証明してる。

262 ：
自分もjavaとばしてkotlinやってるんだけどgradle使おうとしたら結局java必須なんですかね

263 ：
いや、別にそんなことないけど

264 ：
次のアプリは既にflutterで開発中だわ。dartは確かにクソだけどflutterの出来がいいから俺はdart+flutterに移行するわ

265 ：
kotlinで作ったアプリは結局一つだけになりそう

266 ：
ネイティブの実装を意識しなくちゃいけない時のためにネイティブで一つは作っておいた方がいいけど、
それ以降はflutterでいいかもな、もう

267 ：
>>259
http://mevius.2ch.sc/test/read.cgi/tech/1521401186/381-385n
で出た話かな。

268 ：
まあ後発だけあってxamarinよりは使い勝手いいよflutter

269 ：
同じクラスに val hoge: Int と fun getHoge(): String が書けたりするんで java 知ってても混乱するかも

270 ：
>>262
KotlinでもGradleスクリプト書けるらしいけど、本格的に使っている人がいるという話は聞いたことがない。

271 ：
Gradle自体で色々やろうとするのはあまり感心しないやり方ではある

272 ：
>>270
いや、普通に使ってるけど。
誰かが使ってるかどうかじゃなくてやりたいことが出来るかどうかで判断しなよ。

273 ：
当然だけどjetbrainsのプラグインサンプルとか見るとgradle kotlinだよ

274 ：
それどころか Kotlin 本体のビルド環境が gradle kotlin

275 ：
Xamarinのビルド環境もきっとgradle kotlin

276 ：
コトリソ

277 ：
Xamarinの内部実装はkotlin

278 ：
地獄で十王に責められたら良いと思うの

279 ：
>>272
昔やってみようかと思って調べたら、IntelliJですらコード補完がきかない上に、
エラー扱いでスクリプトが真っ赤になると聞いたんだけど、今はそういった状況って改善した?
build.gradleをbuild.gradle.ktsにするだけでOK?
IntelliJ使っているなら、体験談は聞きたい。

280 ：
そんなこと聞くより自分で試してみた方が早いのに

281 ：
>>280
過去の事例を見ていると泥沼になってるっぽいし、.ktsするだけならいいけど、
他に工夫がいるなら可能性のパターンが多すぎるし。

282 ：
あ、だめだこいつ典型的な使えないやつだ

283 ：
そんなことよりElectron for Kotlin作ろうぜ

284 ：
それならflutter for kotlin作りたい

285 ：
Xamarin for Kotlinがあればこのスレ的には最高だよな

286 ：
そうなのか？

287 ：
新たな罰ゲームですかね

288 ：
Xamarinほどの◯はない

◯に一字を当てはめて文章を完成させよ。

289 ：
神

290 ：
金箔貼っても○は○

291 ：
鉄

292 ：
幼女

293 ：
苦学生なので太郎本誰か安く売ってください

294 ：
>>293
学校の図書館にはないのかね？

295 ：
>>294
借りられてました(T_T)
おそらく夏休み期間中は返却されないでしょう…

296 ：
>>293
太郎本よりインアクション１冊持ってればいいよ
太郎本は入門時ぐらいしか役に立たないけど、インアクションは後々役に立つ
高いけど

297 ：
>>295
市や区の図書館はどうかな？

298 ：
progate に、Kotlin は無いのか？

もしあれば、それをやれば？

299 ：
>>295
polcaとかで募集してくれればカンパするけど、2ちゃんで晒すのは辛いかw

300 ：
2933です。
冗談半分のつもりで書いたのですが、レスくださった方ありがとうございます。

他の図書館にもprogateにもなさそうなので素直に買います。

301 ：
明後日から来たの？ご苦労様

302 ：
この言語があればJava使う機会なんてなくなるの？

303 ：
>>302
Yes. ただし、Javaしか使っていない会社などからJavaでやるように指定があった場合や、
過去にJavaで書かれたライブラリのソースコードを参照したり修正したりする必要があるような場合などは
はその限りではない。
Oracle JDKのライセンス問題で、Kotlin関係なしにJVMごとJavaを使う機会がなくなるのでは
というのが目下の懸案だけど、JDK 11のリリースされる9月までにはなんらかの発表があって
目処がつくと信じたい。

304 ：
>>302
今の所 Java VM 上で動かす方式が優勢なので使うと言えば使うなあ。
ただその内 Kotlin native が出来るので、そうなると Java VM 不要なので使わなくなると言える。

305 ：
Kotlin nativeはJavaのライブラリ使えないんだろ？
全部Kotlinで再実装しなきゃならんのなら辛くないか

306 ：
>>305
今色々とライブラリ用意してる所なんじゃないか?
それとC言語用のライブラリとか、他の言語のライブラリも使えるようだぞ。
http://blog.64p.org/entry/2017/05/19/005703
まあ、nativeなら使えないわけがないとは思うが。

307 ：
google的にはkotlinも捨ててdartに行くつもりなのか

308 ：
>>302
将来的にはYes
現状はNo
JDKがないと使えない

309 ：
>>307
本命はwasmでしょ
flutterはgoogleによくある戦略外のお遊びプロジェクトで、すぐ消えるよ

310 ：
flutter程度のお遊びプロジェクトは様々な団体であちこちで生まれては消えてを繰り返している
Googleのそれに限って光り輝いて見えるのはSEOのせいであり、だからといってほとんどが失敗して消えていることに違いはない
いいかげん気付け

311 ：
そう思う根拠を教えて
なんとなくの決めつけじゃ説得力ないよ

312 ：
だいぶ色の違うプロジェクトではあるけど、最近だと軍事AIドローン開発の大プロジェクトが中止されたね
Google社員が猛反発し、集団退職まで起こった
結構な大ニュースのはずだけど知ってた？そういうもんよ

313 ：
いや、だからgoogleのプロジェクトのうち長く続くものとそうでないものにどういう違いがあって、
flutterが後者である理由を教えてよ

314 ：
FlutterはAndroidから噂の新OSへ移行するとしたら絶対必要になるけどな。
そのOS自体をやめない限りは絶対続くし、Java周りのアレのせいでgoogleがAndroidを大転換したがってるのは間違いない。

315 ：
新OSはまぁ、あんまり期待できないな。マイクロカーネルっていうアーキテクチャは面白いとは思うけど

316 ：
この間Javaの入門書買ったばかりなのにこんな良さげな言語があるとは…
下調べ不足だわ

317 ：
Javaの入門書やるレベルならまずはそれを終わらせたほうがいい
OOP何それレベルはさすがにKotlinでは門前払い

318 ：
これからJava離れ、あるいはJVM離れが加速するかもしれないのにJavaデビューとは
もしIT業界で戦うための勉強だとしたらKotlinなんて知らない方がマシだぞ

319 ：
>>317
未読のまま売ろうかなって思ってたけど読んだほうがいいかな
C言語をしばらくやってたからOOP何それ？とはならないけども

320 ：
>>318
今大学三年なんだけどIT企業への就職を考えてる
もしIT業界で戦うための勉強だとしたらKotlinなんて知らないほうがマシ、っていうのはどういう意味？

321 ：
>>320
Kotlin使える現場なんて少ないからな
ただでさえJava書いてるだけでストレス溜まるのにKotlin知ってたら「このコードKotlinなら・・・」って余計ストレス溜まるぞ

322 ：
そもそもIT業界への就職はやめとけw
ITやりたいだけなら普通の業界でもできる

323 ：
まぁ、肌に合わなかったら辞めりゃいいやって甘い考えは捨てた方がいいかもな

324 ：
ある程度自力裁量のあるプログラミングを業務としてやりたいというのなら、プログラミングの勉強ではなくIT業界研究に時間を割くべきだね
プログラミングやらせてもらえない名ばかりプログラマや〇〇エンジニアやコーダが転職もできない底辺過重労働を死ぬか壊れるまでする業界だぞ
どうしても判断できなきゃ「プログラミングに興味のある就活中の学生です」という体でツイッターと技術勉強ブログを公開して寄ってきた企業から選べ、確率的にはマシだ

325 ：
>>324
その言葉を学生の頃の俺に聞かせてやりたいよw

326 ：
>>325
SIerの方ですか？

327 ：
いつまでも学生気分じゃ困るんだよw

328 ：
windowsで仕事してるIT企業はブラック
macで仕事してるIT企業はホワイト
わかりやすいよ

329 ：
俺はLinux

330 ：
僕はNetBSD

331 ：
Linuxだなあ

332 ：
本当はLinuxにしたいけど、GUIツールが貧弱すぎるのとiOSもやらないかんからやむを得ずMac使ってる。
最近はWSLがだいぶ使い勝手が良くなったと聞くがどうなんだろうね。

333 ：
Linuxを選べるIT企業はホワイト
Linux強制のIT企業はブラック

334 ：
>>333
めっちゃ分かる。
何使っててもいいけど、自分で選べるかどうかが1番大事。

335 ：
>>328
おまえがキモマカーだということはわかった

336 ：
mac強制の企業とかwwwww

337 ：
強制というか、作ってる製品のサーバ側が Linux だからサーバ側に配属されたら Linux になるってだけのことだな。

338 ：
有料でもいいからリッチなLinuxのGUIが出てこないもんかね
主流のやつは大体試してきたけど、普段使いのメインにするにはちょっと厳しい

339 ：
>>338
Linuxはそういうとこが弱い印象
MSにしろAppleにしろ素人集めて
UI使わせてどこで迷ったとかこういう動きした
とか実験して参考にしてるみたいだけど
Linuxは個人の趣味だけで作ってそう

340 ：
よくLinuxは普段使えるGUIソフトが全然足りないと言われるけど、そもそもGUI自体が貧弱だから当然っちゃ当然だわな。
それがなんとかなりゃMacなんて使わないのに。

341 ：
Linuxのデスクトップ環境程の糞はない

342 ：
なんだ、やっぱりXamarinのせいだったのか

343 ：
Androidでも使っとけ

344 ：
LinuxにGUI求める奴はLinux向いてないからMac使った方がいいよ
Linuxはシェル駆使してターミナルで使う物

345 ：
そうだねえ。
できればメインをLinuxにしたいんだけど、現状じゃ無理だ。

346 ：
実際ほとんどの開発者はMacに流れたな

347 ：
>>344はまさにその通りなんだけど、
みんながみんなそれを言ってるからの現状なんだろうねw

348 ：
Macはパッケージマネージャがクソすぎるからなあ
WSLの出来が意外と良くて、好き嫌いを別にすれば既に開発環境としての使い勝手はWinに抜かれてる

349 ：
>>344
なこと言ってるからいつまでもメジャーになれないんだよ

350 ：
しかしkotlinの話題ねーな

351 ：
>>349
なる必要などないしその労力は無駄であるというのがfvwm95の昔からの結論

352 ：
>>348
Homebrew知らんの？

353 ：
>>352
HomebrewってGUIだっけ?
>>350
XamarinスレだからKotlin 1.3の話をする人がいないのは仕方ないね。

354 ：
ん？Windowsにまともなパッケージマネージャあったっけ？

355 ：
scoop

356 ：
>>354
apt
ほぼ普通のUbuntuがVMなしで使える

357 ：
>>353
今のMacではHomebrewはmacOSのセキュリティと干渉してしょっちゅう不具合起こすよ

358 ：
>>357
毎日のように使うけど、しょっちゅうってほど不具合は起きないぞ
OSのメジャーアップデートの時はやばいが

359 ：
同じく、しょっちゅう使ってるが、特にHomebrewで不具合起きてないぞ

360 ：
El Capitanになった時だけは死んだけど、それ以来はそんなことないな

361 ：
MacはOSバージョン毎年変わるくせにアプリの互換問題な耐えないから大嫌い

362 ：
Xamarinみたいな糞でやるから不具合を起こす

363 ：
$brew install Xamarin
...
...
$ Error: Xamarin is shit. Uninstall it ? (Y/Y)

364 ：
Windowsが好きなら黙って使っとけよ
わざわざ自分が使わないものを貶めなくてもいいだろ

365 ：
Windowsは特に好きではないな

366 ：
マカーはキモいから嫌い

367 ：
かといってMacが好きというわけでもない

368 ：
MacはBSDに綺麗な服着せて見た目かっこよくしただけだからな
ちょっと凝ったことしようとするとシェル駆使する必要があって、Javaとか使ってるだけの純プログラマーに使いこなすのは難しいんだろ

369 ：
Kotlinの話題はスレ違い

370 ：
>>368
いや、Macのそういうところは好きだ。あのGUIは邪魔。

371 ：
MacとWindowsなんて、どこの板のどこのスレでも大荒れ必死な話題なのにこの程度しか燃えないのか
ほんとこのスレ過疎ってるな

372 ：
盛り上がるのは知識がなくても誰でも一言言える話題だからだろうな。
スレチだから他でやれば

373 ：
ほんそれ。ここはXamarinスレだから、OS論争は他所でやれ、

374 ：
Kotlinもよろしく

375 ：
プログラミング言語のシェア競争は安定期に？ 人気ランキングから見えてきたこと
https://wired.jp/2018/08/18/apple-swift-android-kotlin-rankings/

376 ：
やっぱこれからはJavascriptなんだな

377 ：
これからはっていうか、JavaScriptは公用語みたいなもんだし……

378 ：
Nodeが出来て、JavaScript はなんでも作れるようになったしな

379 ：
CSSって言語なんかい

380 ：
>>374
スレ違い

381 ：
ことりん…寿命短かったな…

382 ：
これからは Kotlin の時代

383 ：
>>382
Android: 成功しているが、まだJavaの方が優勢。しかもモバイルOSはFuchsiaに移行していく。
JVM: OpenJDKの半年ごとリリースのサイクルについていけなくなる。
Javascript: 圧倒的にTypescript
Native: 完成の目処がたたない。
どうしよう未来(さき)が見えない…
と、スレチながら極論してみる。

384 ：
つまりDelphiの時代が来るということか

385 ：
>>383
FuchsiaのSDK(Flutter)ってDartだってw

386 ：
Nativeをもっと重視すべきだったんだよな
完全に後手

387 ：
JBのリソースがそこまで足りてないんだろ
flutterが出る前にGoogle様に会社ごと買収して貰えばよかった

388 ：
>>385
ほんとそれだけが地獄だよな。
flutterは良く出来てるけど、Dartが辛すぎるww

389 ：
リソースないならJS切り捨ててNativeに注力しろよって思う
もしくは逆か
両方やろうとするからどっちも中途半端になってSwiftにもTSにも勝てないんだよ

390 ：
JBって未だに正式なJavaの認証のないグレーなOpenJDKを配布してるよね
Nativeなんか成功するわけないんだから、遊んでる余裕があるなら
JBがOracleの正式なライセンスを受けたOpenJDKのディストリビュータになって、顧客にOpenJDKの安定的な提供を確約すべき
このままだとVSCodeに食われて潰れるのも時間の問題

391 ：
全然意味がわからない

392 ：
わかんないんです

393 ：
そのうちなんとかなるだろう。

Fuchsiaになったらなったでそれ用にコンパイルできるやつができればいいんじゃないか？

394 ：
Javaは仮想マシン使ってクロスプラットフォーム対応ってのが新しいと言われて普及したけど、それも今は昔
今後の主流はPWAだからJavaとかオワコンになりつつおる

395 ：
PWAねえ
少なくとも当面の間は主流になることはないと思うよ
ビジネス的な理由で

396 ：
あー、馬場が持ってたベルト？

397 ：
NWA

398 ：
でもflutterって現状sdkってより只のUIツールキットだからな。だからfuchsiaのOS提供機能のAPIが別に用意されてそれは他の言語から自由にアクセスできるんだろうし。
下手するとdart/flutterを全く介さないアプリもfuchsiaで動かせるとか?
そこでmicrosoftさんで出番ですよ

399 ：
valをletにしてくれ

400 ：
sed 's/val/let/g'

401 ：
>>395
そんなこと言ってると時代に取り残されるぞ

402 ：
そういう本質的でない技術は主流になってからやりゃいいよ

403 ：
let って再代入可な方じゃないの

404 ：
>>403
関数型言語では、束縛といってletは再入不可だが、
JavaScriptとTypeScriptはなぜか再入可能になる

405 ：
letよりvalの方が好きなんだけど

406 ：
>>401
技術者としてはキャッチアップしておかなくちゃいけないけど、既存のプラットホームとの兼ね合いで主流になるまでのハードルは高いよ
具体的に言えばAppleとグーグルの稼ぎが減ってしまうから

407 ：
完全にjavascript脳だったわ…

408 ：
>>407
それは君のせいじゃないから大丈夫

409 ：
jsは呪い

410 ：
本日は朝から晩までC言語漬けでした。

411 ：
>>409
確かに
>>399
varとvalが紛らわしいと思う一方で、letと束縛のイメージが結びつかなくて気持ち悪いと思う自分がいる。

412 ：
>>411
確かにlet自体には束縛の意味はない。関数型言語ではletを使って束縛をする(デフォルトで再入不可)というだけの話。JavaScriptではデフォルトが再入可能なので、letも再入可能になったってことかな？

413 ：
Ｃ言語程の糞はない

414 ：
>>412
(ｷﾘｯ が付きそうなレスする前に再入可能の意味をググってみよう
リアルで恥かかなくて済んでよかったね

415 ：
>>414
mutable immutableの和訳なんてどうでも良い

416 ：
reentrantのことかな？

417 ：
>>404
let を最初に使ったのは Lisp だろ
Lisp の let は新しいスコープを作り、そのスコープに変数を束縛する
スコープに束縛された変数は、再代入可能だし、初期値も必須では無い

最近の関数言語でも概念的には一緒だと思うんだけどね？
関数言語 let a = 1 とかした場合、これは a に 1 を束縛しているのではなくて、スコープに変数 a を束縛してその値を 1 にしている
そして >>411 が言ってるように、関数言語の場合は変数が再代入不可能だから a の値が 1 固定になる

418 ：
binding自体は難しいものではないからな
特定の言語仕様がくっついたまんまの状態で別の言語で考えると「？？」ってなるだけ
それは方言だってやつね

419 ：
>>417
関数型言語

420 ：
>>417
let a be 1 で値を1にするというのはまだわかるのだけど、
英語nativeじゃないからかもしれないが、
letという単語にそういうスコープ束縛の意味はない気がするのでイメージしづらい。

>>414
再入可能と再代入可能は違うとだけ指摘すればいいものを。
リアルでそんな指摘のしかたでは敵も多かろうに。

421 ：
let it be

422 ：
俺からしたらreentrantを再入可能なんていう訳がしっくりこないが
再呼出可能だろうと

423 ：
もう一つ違和感の原因に思い当たったのだけど、
value a is 1, variable a is 1は英語の第三文型だけど、
let a be 1だと、第五文型になるので、統一感がなくなるというのもあるかもしれない。

424 ：
違和感といえばC言語の『＝』ですでに違和感感じてたw
左辺と右辺違うやんって

425 ：
letと言えばBASICじゃろ

426 ：
let me see

427 ：
whisper words of wisdom

428 ：
Let it be.

429 ：
let me go.

430 ：
>>423 第三文型じゃなくて第二文型(SVC)だったorz 第三文型はSVOだ
>>424
そのときにHaskellを知っていれば・・・みたいな話?

431 ：
>>430
その後に知ったのがMLなのでHaskellは無用だった

432 ：
Kotlin conf

433 ：
>>432
今日やるのはKotlin confじゃなくてKotlin Fest 2018だよね。
なんか進展ありました?

434 ：
スライドと動画のリンクはよ

435 ：
2018年 人気＆嫌われプログラミング言語トップ25- Stack Overflow
https://news.mynavi.jp/article/20180604-639227/

Kotlin は結構愛されて求められてるね。

436 ：
スライド一覧
ttps://kotlin.connpass.com/event/91666/presentation/

437 ：
今まで色々な言語使ってきたけど、ことりんは凄く気に入ってる
ただ、それが依存してるJavaがなぁー

438 ：
おらくるりん

439 ：
>>437
ほんそれ。Kotlinにガッツリ打ち込みたいけど、JVM自体がリスク因子になっちゃってて

440 ：
Kotlinは良い言語だよ、本当に良い言語だ(Dartを書きながら)

441 ：
そのうちなんとかなるだろう

442 ：
なんくるないさぁ

443 ：
KotlinはnativeかJSのどっちかに注力しないとJVMに引きずられて消えてく気がする

444 ：
そもそもKotlinは、なぜJVMで動くのが前提で作られたのか
Javaとの互換性を重視したんだろうけども

445 ：
そりゃJetBrainsの客層を考慮したら当然でしょ
JBの売上ってIntelliJとReSharperがほとんどだろ
後者はC#があるからKotlinは必要とされない
したがって選択肢はJavaしかない

446 ：
kotlinってGoogleと協議とかなしで作り出したん？

447 ：
Googleと協議してたらクソ言語が出来上がってただろうね

448 ：
Scala挫折組が低機能Scalaとして開発始めたんだから当然JVM言語

449 ：
>>445
ネット見てるとPycharm使ってる人多いように見えるけどこれは無料版かな
いま結構大手メーカーに出稼ぎに来てるけど、JS書くのにWebstormつかつてたわ

450 ：
WebStormはVSCodeの台頭で完全に死んだな

451 ：
VSCode使いやすすぎてヤバい
未だにたまにEmacsとかVimの特集やってる雑誌もあるけど、vimはともかく、なぜEmacsみたいな旧式のエディタ未だに使ってる人がいるのかわからん

452 ：
VSCode良いけど、IntelliJが完全に上位互換といって差し支えないからなあ
VimとかAtomとかを使ってるなら乗り換えない理由がないけど

453 ：
TypeScriptならWebStormのリファクタリングがJavaとかKotlinと同じぐらい奇麗に処理してくれそうなんだよね
AndroidStudioのリファクタリング使いまくりな俺としてはどっちか選べるのならWebStorm使ってみたい
実際にWebStormのTypeScriptリファクタリング精度がどの程度なのか未確認なんだけど

454 ：
>>453
無料で30日は使えるんだから試してみればいいじゃない。
おっしゃる通り、Typescriptで開発するならかなり良い。

455 ：
>>454
暇になったら昔趣味で作ったサイトをTypeScriptとか流行りものてんこ盛りで作り直そうと思っててね
WebStormが期待通りに動いてくれるなら楽しみだ
ありがとう

456 ：
>>451
emacsは大昔からあって30年以上使ってるような人は既に体がemacsにカスタマイズされてしまっているので他のに移行するなんて出来ないのだろう。

457 ：
もう軽量言語は全部VSCodeでいいよ

458 ：
>>457
同意

ElectronってAtomのために作ったはずのに、そのAtomが重くて使いにくいくせに、MSが作ったら軽くて使いやすい物が出来る辺りは、やっぱMSってすげーなと思った

で、結局買収されたしw

459 ：
>>458
そりゃ母体の大きさが違いすぎて勝負にならんわw

460 ：
>>456
VScodeが起動できる環境でVScodeで用が済む範囲ならVScodeを使ってるだろう
VScodeはターミナルじゃ使えないしEmacsとは別な方向性で重いし

461 ：
今時ターミナルでemacs使おうって環境がどうかと思うけどな
設定ファイルぐらいならviでいいし

462 ：
そもそもデフォルトでemacs入ってるディストリビューションってまだあるの？

463 ：
>>462
おう、昔はPC-UNIXのディストリビューションにデフォで入ってたみたいな言い方はやめろや
今も昔もEmacsは選択インストール対象だ

464 ：
>>460
emacsを体で覚えてしまった人は似たようなものでemacsが動く環境ならそれで全てができてしまう状態なんだよ。
だからそう簡単には離れられない。

465 ：
かれこれ20年以上Emacsを使っている
ターミナルではctrl+x 2, ctrl+x d が便利

466 ：
まじでemacsはおっさんしか使わないわな
viはまあサーバーに入って何かするのに必須だから基本操作くらいはできるやつ多いだろうけど

467 ：
オペレーションマニュアル作る時にesc-x shell は便利
viでも同じ事出来るのけ？

468 ：
Kotlin使ってるくせに 静的言語+IDE じゃない組み合わせでコード書くとかありえないっしょ
なのでそれ以外の用途につかうエディタなんてEmacsで十分
それとも Kotlin 使ってもないのにこのスレ監視してる人？

469 ：
>>467
最近はVimでもVSCodeでも出来るらしいですよ
emacsは30年前から出来てたけど

470 ：
うわあ、めんどくさいemacsおじさんがこのスレにもいる
前職で散々聞かされてうんざりしてるからやめてくれよ
この手の人たち、ジョークじゃなくて本気でエディタ論争仕掛けて来るからほんとめんどくさい

471 ：
Emacs+RCSでレッツノスタルジー

472 ：
エディタなんて使う必要ない Kotlin スレで延々とエディタの話するとかありえないですよね

473 ：
ここはドザーに監視されています

474 ：
お前ら当然ideaVim入れてるよな

475 ：
Kotlinは良い言語だけど、JDKに起因する虚無感が漂っててネタがないので、エディターとか他の話で盛り上がってしまう

476 ：
Kotlin書くなら現状IntelliJ IDEA以外の選択肢はないと思う

477 ：
vi vs emacs
ﾌｧｲ!

478 ：
勝利の条件は？

479 ：
面白いと思ってやってるんだろうな

480 ：
>>478
そりゃXamarinが開発しやすい方

481 ：
めんどくせえから vim で Kotlin 書いてる

482 ：
めっちゃ効率悪そう
こんなにIDEの恩恵の大きい言語なのに

483 ：
セクシーvim

484 ：
エリーゼの憂鬱

485 ：
>>482
いや今のところ仕事でバンバン使う招待じゃないからいいの。vimだと思い付いた瞬間に起動してすぐ打てるし。

486 ：
招待じゃねえ。状態。
なんという変換ミス。

487 ：
きょうび開発環境でメモリ足りなくなったりしないからIntelliJは起動しっぱなしだし、思い付いて即試したいものはREPL使うからなー

488 ：
昔からのやり方を変えられない人ってのはいるんだよ
そっとしておこう

489 ：
ことりんの好きなとこ聞かせて……♡

490 ：
一気 一気 一気

491 ：
>>489
名前がかわいい

492 ：
>>487
いや、足りなくなる。なぜならそんなにメモリ乗せてないからだ。w

493 ：
ことりんは名前がいいよな
外国人だとなんとも思わないんだろうけど

494 ：
外国人だといたずらする小さい悪魔みたいなのを連想するかも知れんね

495 ：
コトリン≒グレムリン

496 ：
コトリンはとっても歌が好き

497 ：
ラブライブオタクの男性が使ってそう

498 ：
ちゃんと実装面でもいいとこ言えよ

499 ：
>>495
こっちこっち
https://ja.m.wikipedia.org/wiki/%E3%82%B4%E3%83%96%E3%83%AA%E3%83%B3

500 ：
>>492
えくりぷすならともかくいんてりじぇーでメモリが足りなくなるようなマシンならKotlin使う方が間違い

501 ：
さよか

502 ：
じゃあ久しぶりに IntelliJ 起動してみるか。

503 ：
Tip of the day が出るまで約4分10秒。

504 ：
あ、アップデートされてた。

505 ：
IntelliJもVSCodeもスタートアップに入れて常時起動してるわ

506 ：
他のソフトをあまり起動しないならそれでも耐えられるが・・・

507 ：
>>503
さすがにそれはヤバいw
開発機なら今すぐ買い換えた方が良いレベル

久しぶりに起動してそれならindexingに時間かかってるんだろうから、CPUかなあ、当てずっぽうだけど

508 ：
ここはKotlinスレであってうんこマシンスレじゃないからそろそろスレ違い

509 ：
使わなきゃいいよ

510 ：
コトリン＝やかん

511 ：
>>507
そうかも知れん。アップデート後に起動したら1分ぐらいだった。
まあしかし開発マシンと言えるほどのものではない。
個人で持ってるPCでそこでは趣味で小さいプログラム作るぐらいなので。

512 ：
そう言えば IntelliJ がサクサク動くレベルのPCのスペックってどのぐらいのものなんだ？

513 ：
pentiumとかで十分
ただし中身がatomのは除く

514 ：
2013年のMac miniでもサクサク動く

515 ：
だよな。pentiumマシンで十分だろ。ストレージはssdで。
ただし実機でデバッグ

516 ：
実機デバッグという言葉を見るにやっぱことりんスレだとAndroid前提の人が多いんかな
サーバーサイド勢としては寂しい

517 ：
動画まだー

518 ：
spring boot + mybatis + kotlin というテンプレでやってるよ

519 ：
>>518
Spring bootってもうことりんで問題ない？
今のところフルことりんだとSparkでライトなサイトしか作ってない。
katorはちょっと前に試したけどまだまだ未完成で辛かった

520 ：
うちはJSFだよ・・・

521 ：
>>516
「Android StudioでつくるAndroidアプリ入門（半端にカラーで分厚い）」みたいな本では軒並みKotlin対応になってるので
最近親切げな本一冊でAndroid始めた人はみんなKotlinやってると思う
ていうかJavaで作るAndroidアプリ本がもう売ってねえ

522 ：
>>521
会話が成立しているように見えて実は噛み合ってない好例

523 ：
>>519
まだboot 2.0に上げれてないけど致命的な問題に遭遇したことはない

beanとinterface default methodの組合せで起動時エラーになってたが、@JvmDefaultで回避できるようになったし
@JvmDefault以前も拡張関数でどうにかなってた

524 ：
今からJava学ぼうと思ってたんだけど、様子見たほうがいい？
この言語がJavaに代わってすごい伸びそうだって聞いた
でもそれって何年後なんだろう

525 ：
>>524
様子見できるなら、9月末のOpenJDK 11のリリースか2019年3月のOpenJDK 12のリリースまで
様子見すれば、OpenJDKのLTSが出るのかどうかはっきりすると思う。
2017年はAndroid公認になって伸びるといわれて、実際そこそこ伸びた。
でも、2018年に入ってからはOracleのJDKリリースサイクル変更の問題や
7月のGoogleがAndroidごとJava, Kotlinを捨ててFuchsiaに行くような話も出ているし、
伸びそうというのがいつの時点での情報を元にした認識かにもよると思う。

526 ：
>>524
KotlinはJavaの方言のようなもの
Javaに代わって主役になるなんて現実にはあり得ないし、Javaが消えたら自動的に消滅する

527 ：
>>526
言語としては残るんじゃないの。
JVMで動くかどうかは別にして。

528 ：
Flash亡き後のActionScriptみたいな立ち位置になるんじゃね

529 ：
Javaの文法はもう古い
時代の流れ的にKotlin風の文法が主流になるのは間違いない

530 ：
android無視すると逆にそこまでkotlinである必要もねぇんだよな。
javaにラムダもきたしjava10でローカル変数の型推論もきたし。

531 ：
どちらかというと純Javaでなければならない理由を考えたほうがいい
どーしてもJavaじゃないと困るのでないならもはやKotlinでいい

んで次は「それを実現する」のにJVM+Kotlinでなければ困る理由をなんとかこう捻り出すのだ

532 ：
>>529
TypeScriptの流行なんかも含めると時代はKotlin風というよりC#風かな
ベースとしてC#にインスパイアされたちょっとLightweight&FunctionalなC系の流れの本流に近く、
その中では比較的Ruby系に似せた仕上げのなされた言語と位置付けるのが妥当

533 ：
インスパイアっていうか作った本人やで

534 ：
時代は Kotlin

535 ：
まあどんなに少なく見積もってもあと5年以上は生きてるだろうから別に今から勉強しても損にはならない

536 ：
Java程の糞はない

537 ：
今後は、Nativeなアプリ開発はSwiftに、JSのアプリ開発はTypescriptに、JVMのアプリ開発はKotlinが主流になるよ

問題は、そのJVMの必要性が薄れつつあるのがなぁ・・・(^_^;)

538 ：
swiftて…

539 ：
時代に全くついていけてないオッサンか、最近そこらへんのことを知ったばかりのど初心者かどちらかだろ

540 ：
JVMなアプリ開発はネイティブなアプリ開発じゃないんか

541 ：
>>540
定義にもよるかもしれないが、間にJVMが挟まる以上ネイティブではないと考えるのが妥当では?

542 ：
どっからどう見てもツッコミどころしかないんだからそんなにマジレスしても禿げるだけだぞ

543 ：
Swiftが注目されている頃に、Apple系以外のプラットホームのアプリも開発できるようにしようとかいう動きがあった気がしたけど、その後全く聞かないな

544 ：
>>543
Googleが次期OSの開発にSwift使おうとしてるやん
そのためにSwiftの開発者引き抜いた
Kotlinはあくまで繋ぎだよ

545 ：
swiftは言語的には良さそうなのに閉鎖的すぎてkotlinより可哀想

546 ：
スレチだがtypescriptに完全に置き換わるなんてことあるのか？

547 ：
>>544
Fuchsiaはswiftだけじゃなくて go rust dart あたりもサポート進めてる
このまえレポジトリ見たときには rust の文章が多めの感じだった
ラトナーがこれに関わってるのなら swift というより llvm 絡みなんだろうなという感じ

548 ：
>>546
置き換わるっていうか、tsはバニラjsとシームレスに混在できるから、かなり浸透はするだろうね。

549 ：
Kotlin native もそこに突っ込めればナイス

550 ：
少なくともRailsブームの時にCoffeeで作っちゃったものは早いとこTSに置き換えておかないと誰もメンテできない巨大な負債になりそう

551 ：
>>546
置き換わると思うよ
JVMを使うことの必要性が薄れてきてるからね
Nodeが出来たりGAFAのJava離れが進んで、ネイティブ以外はWEB良いじゃんって方向性になりつつある

552 ：
>>551
あ、JSがTSに置き換わるかって話なんでJVMとか関係ないです

553 ：
>>552
それだと完全にスレチだからよそでやってくれ

554 ：
Triple()のTripleを省略したいんだけど

555 ：
JVMは廃れるのは間違いないのだがさて何年かかるかって話だな

Javaはまもなく終わるスマホと心中するってAndroid4前には口さがなく言われてたんだよ
4.4で成功しちゃって誰もそんなことは言わなくなったけども
いやもう未来はわからんねえ

556 ：
Fuchsiaの普及次第だろうな

557 ：
>>555
ICS前？確かにショボかったけどそんな風潮だったの？

558 ：
良くも悪くも一寸先は闇だ。
未来予測は現在までに得た情報からしか出来ない。
しかし明日何かが新たに現れるかも知れず、それによりそこから先の未来は予想と大きく違ってしまうかも知れない。

559 ：
明日太陽が爆発するかも知れない

560 ：
Javaオワコンだなんてこれまで何度言われ続けてきたことか

561 ：
>>551
自分でWebって言ってるのにクライアントサイドのことしか頭にないのはなぜ

562 ：
>>561
なんとか揚げ足を取りたい気持ちはわかるが561はどう見てもサーバーの話してるだろ

563 ：
Javaっぽいなにかを使ってるSalesforceは廃れてほしい

564 ：
仕事でSalesforce使ってるけどうんこオブうんこ

565 ：
俺は触ったことないけど、トラウマレベルのゴミだと聞くな、salesforce

566 ：
>>562
Node知らんのだろ
そっとしておいてやれ

567 ：
まあJVM使わなくなったとしてなぜ置きかわり先をNodeに限定してるのかは謎だけどな
どっちにしろスレ違い

568 ：
ここはXamarinスレなんだから脱JVMなんて言わずにサーバーサイドkotlinを粛々と語るべき

569 ：
Javaで書いてコンパイルしてclassをJVMで実行
TypeScriptで書いてコンパイルしてjsをNodeで実行

まー、似たようなもんだしな

570 ：
Nodeは一時期ソシャゲのサーバーサイドなんかで広まりまくったけど、
最近そういう大量の軽いリクエストを同時に捌く系の用途はGoが主流になりつつある

571 ：
これやね
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00138/082900134/

572 ：
>>568 みたいに、ここはXamalinスレとか言ってるやつって、それが面白いと思ってやってるのかな。
認知症のジジイが、同じこと繰り返してるような痛々しさしか感じないんだが。

573 ：
その痛々しいのが面白いんだからやらせとけ

574 ：
>>571
新しい物が出ないと儲からないんで。

575 ：
>>572
みんなそう思いつつもスルーしてやってる
それがエンジニアの優しさってもんだw

576 ：
やっぱみんなSalesforce嫌っててワロタ

577 ：
Xamarinが糞はガチ

578 ：
>>577
前々から疑問なんだけど
Xamarinは糞とか言うけどC#が糞とは言わないよね
ここはKotlinて言語のスレなんだから合わせたら？
まあスレチだから書き込まないでくれると助かるんだけどさ

579 ：
じゃあKotlinの話題振れや
何も有益な情報提供せずに何様だ

580 ：
>>578-579
なんでそんな攻撃的なんだお前らは
黙ってスルーしてりゃいいのに

581 ：
セミコロン不要の原理が分からん。

582 ：
セミコロンを使うところはある

583 ：
むしろセミコロンしない意味が分からない。

584 ：
>>583
FlutterでDart使うと、セミコロンのうざさがわかると思うよ。
FlutterはKotlinの言語仕様と相性がいいのにDartなんだよなー。

585 ：
korlinなんて求人がないやろ

586 ：
まあKotlin名指しの需要はないよね
言語選択の裁量のある現場において使いたいから使うもの

587 ：
Javaが金徴収し出したら本気出すんだろ？

588 ：
>>585
Kotlin名指し
https://www.wantedly.com/projects/205802#_=_

589 ：
募集終了してた。

590 ：
いやいやAndroidアプリの求人はKotlinだらけだろ
メルカリもKotlinや

591 ：
(　´_ゝ`)ﾌｰﾝ

592 ：
KotlinだからってKotlin経験者に限定して求人する必要は全くないだろ
Javaできれば何の問題もない

593 ：
むしろKotlinに限定してJava触ったこと無い奴来たら困る

594 ：
Javaを知らずにKotlinって覚えられるの？

595 ：
>>594
「覚える」がどの程度のことを指すのかが不明確で釣りっぽいが、短く答えるなら、
覚えられるが、実用段階でJavaを知ることになるだろう
と言ったところか。

596 ：
別に書けなくても読めれば十分だゾ

597 ：
アプリからライセンス情報確認してみたが、
メルカリもabemaTVもクックパッドもKotlin使ってるな
フルKotlinかどうかは分からんが

598 ：
>>597
前々から疑問に思っていたけど、JVMやJSのKotlinのランタイムライブラリは
Apache 2 licenseだから、製品に含めるときにNOTICE.txtの表示は必要?
ScalaはBSDライセンスだから不要だと思っているんですが。

599 ：
bsdなら表示しないと駄目だろ。binary も対象って明示されてる

600 ：
俺は他のライセンスとまとめて書いてるよ
なんならMITのライブラリもリストする

作者への敬意というより、依存してる外部ライブラリをリストしておきたいという理由で

601 ：
>>599
スマン。三条項BSDライセンスに宣伝条項がないという記述の意味を勘違いしていた。
でもランタイム同梱はライセンス条項の適応を受けるという解釈は>>598であってます?
もしそうなら、Javaで作ったものには特に著作権表示がいらないけど、
Koltlinで開発した場合は(実行環境にランタイムがインストールされていない限り)
ライセンス表示が必要ということになると思うのですが。

602 ：
そんなことよりKotlinがApacheライセンスであることの最大の問題は、GPLv2と互換性がないことだぞ
つまり、Kotlinで作られたものにはGPLv2を適用できない
これは、クラスパス例外を外して配布されたOpenJDKとリンクしたり、
OpenJDKと同じGPLv2クラスパス例外ライセンスを適用して配布したりすることもできないことを意味する
GPLv2に固執し意図的に特許周りをグレーなままにしているオラクルに対するアンチテーゼかな

603 ：
なんで平然と嘘を書くかな

604 ：
>>603
Apache License 2.0がGPL2.0と互換性ないのは普通に事実だぞ
https://www.apache.org/licenses/GPL-compatibility.html
Kotlin製のソースをGPL2.0で配布しようとしたら、ランタイムライブラリをGPL2.0で提供できない限りGPL違反

605 ：
ライセンス周りのことになるとこういう頭のおかしい拡大解釈する奴が必ず出てくるよな

606 ：
拡大じゃない解釈を教えてくれよ
ApacheライセンスがGPL2と互換性ないのはわりと常識だよ
OpenJDKはリンク例外が付いているバイナリを使う限りは問題ないはずだしそう言ったつもりだけど、もしかして勘違いしてる？

607 ：
俺が予想した通りの返答をありがとうw
そういうことを言ってるんじゃないんだけど、
まあ君がそう思うならそう思ってればいいと思うよ。 それで俺は困らないし。

608 ：
>>602
> クラスパス例外を外して配布されたOpenJDK
この前提がおかしいのでは? 仮にあったとしてもクラスパス例外を外さずに配布されたOpenJDKを使うべき?
> OpenJDKと同じGPLv2クラスパス例外ライセンスを適用して配布したりすることもできない
Apacheライセンス、GPLv2クラスパス例外ライセンス、BSDライセンスを
各部分に別々のライセンスを適用しつつ配布するのってだめでしたっけ
>>604
KotlinがGPL2.0になればNOTICE.txtの表示は不要になる?

ライセンス周りはそこまで詳しくないので、おかしなことを書いていたらそっとご教授下さい。

609 ：
非互換なのは正しいけども

>これは、クラスパス例外を外して配布されたOpenJDKとリンクしたり、
>OpenJDKと同じGPLv2クラスパス例外ライセンスを適用して配布したりすることもできないことを意味する

こんな妙ちくりんな例を出して話を無意味に広げようとしなくてもなあ

610 ：
>>606
ソースを配布するのかバイナリを配布するのかで全然話が変わると思うが、
お前の一連のレスの中でそれが混在してるから話がめちゃくちゃになってる。

611 ：
非互換なのは確かに正しいし常識なのも正しい。
でも正しいのはそこだけ。まず前提がおかしい。

612 ：
>>608
GPL2.0クラスパス例外とApache2.0とBSDを混ぜて配布することは可能
ただしその場合、再配布時には決してクラスパス例外を外してはいけない
Kotlinのランタイムライブラリをシステムライブラリだと主張するのはさすがに無理筋

613 ：
少なくともKotlinでGPLv2なプロダクト(GPLv2のライブラリをリンクしただけのものも含む)を開発するのは不可能なわけで、
特定のベンダーによるプロプラな処理系だけが存在する言語を除けば割と珍しい気がする
FSFから攻撃されないのが不思議だな

614 ：
GPLv2のkotlin向けライブラリは存在しないし
自分で配布するならGPLv2からkotlinを例外にした独自ライセンスにしておけば問題ない

615 ：
Javaのライセンスの話題って結構伸びるよな

616 ：
>>614
だよな、上のやりとりを見ててそう思った。
自分で勝手に例外条項つければそれで終わる話。

617 ：
>>615
Oracleが保身のためにクソみたいなライセンス形態にしてるのが悪い

618 ：
最初からWTFPLライセンスにしておけば何も問題ないのに

619 ：
OpenJDKのライセンス決めたのはSunだけどな…
てかクラスパス例外あるんだから困るケースは限られるし
オラクルに難癖つけたいだけだろ

620 ：
オラクルなんて大抵の開発者には嫌われてるからしょうがない

621 ：
>>619
現在は企業が(「ソースのリリース」ではなくOSSベースで開発する目的で)OSSを公開するときはMITライセンスを採用するケースが多くなったけど、
当時はそこまで緩いライセンスを採用することはあまり一般的ではなかったからなあ

622 ：
Javaのみで開発したJar: Javaのランタイムはシステム側にあるので、ライセンス表記不要.。
Javaのみで開発してJVMを同梱した実行ファイル: GPLv2クラスパス例外またはGPLv2のライセンス表記が必要。

Kotlinで開発したJar: Apache2.0ライセンスとKotlinのNOTICE.txtのライセンス表記が必要。

ということであってますでしょうか。Kotlinを使用したことを隠すことはできない...

623 ：
お前らの作る糞アプリがライセンス違反で訴えられるようなことはねえよ
その前にアプリの質を上げることを考えろよ

624 ：
>>623
今日の昼飯、ラーメンとマクドどっちが良いと思う？

625 ：
意味不明で草
KotlinがGPLv2と共存できないのはApacheライセンスを選んだJetBrainが主犯だろw
Oracle関係ないww

626 ：
ライセンス表記なんかで、なんで揉めてるの？
オープンソースのフリーソフトなんか感謝の意味をこめて全部記載しとけばいいだけじゃね？

627 ：
なぜライセンスの話になると荒れるのか

628 ：
排他的なのはGPLv2の方なので何も問題なし

629 ：
そもそもいつまでもGPLv2なんてクソのままにしてるのが悪いってことだろ

630 ：
GPLv2とApache2.0に互換がないのはバクみたいなもので
対策したGPLv3とApache2.0との互換性には問題無いとFSFとApache財団で合意とれてるから、v3普及させたいFSFは文句言ったりしないのだろう

631 ：
JVM捨てて.Netにしようずwwwww

632 ：
>>629
v3は明示的な特許訴訟回避の規定があるからオラクル的にはNG

633 ：
ライセンス変更するならソース提供者全員の合意が要る

634 ：
OpenJDKのコントリビュータ全員にはオラクルにソースを寄贈しますっていう契約書にサインさせてるから要らないよ

635 ：
>>626
それは概ねその通りですが、Kotlinを使用したことを記載したくない場合でもそれが認められない
というのは、マイナスポイントかと。

636 ：
>>635
そういう人がいればそうだね確かに。
もっと別に表記して問題が起きるわけじゃ無いし、それをマイナスポイントと捉える人はあまりいないと思うけど。。

637 ：
何にせよライセンスは変わらんから、気に入らないなら
Apache License 2.0 を採用しているものを使うのを諦めることだな
俺もライブラリとか見つけても GPLv2 だったら使うの諦めるしさ
それだけの話

638 ：
せやな。そもそも他人の著作物をただで使わせてもらうんだしな。

639 ：
商用でも非商用でも、使用したものを隠さなくちゃいけないことはそうそう無いだろ
気持ちの上でなんとなく隠したいってくらいじゃね
てか今どき何を作るにもライセンス表記の必要なライブラリの１つくらいは大抵使うんじゃないの

640 ：
ライセンス表記いやなら全て自分でつくればいいだろ無能

641 ：
Kotlinレベルのものを自分で全部作れたら無能どころかGoogleあたりからとてつもない年収でスカウト来るなw

642 ：
googleが提供してるライセンス表示するライブラリがあって、これ使うと楽だぞ

643 ：
>>641
仕様が決まってて実装するだけなら手間だけの問題で難しくはないぞ
難しいのは仕様の設計

644 ：
ライセンス表示をしたくないからapacheライセンスがマイナスポイントになるとは、世の中には色々な価値観の人がいるもんだな
初めて聞いたよ

645 ：
受託開発でKotlin使ったことが客にバレたら困るからとか？
まあその場合は客にライセンス許諾させなきゃいけないからどんなライセンスだろうが隠せないけど

646 ：
>>645
考えられるとしたらなんらかの理由でkotlinを使っちゃいけない要件なのにこっそり使っちゃった、とか？
その場合ライセンス表記をすっぽかすよりはるかにヤバいことになりそうだがw

647 ：
>>644
コードが数画面分に収まるくらいのシンプルなユーティリティを公開するとして、
KotlinだとライセンスとNOTICE表示の実装をしないといけないので、
KotlinじゃなくてJava使おうかなと感じる人がいるかもというのが想定ケースの一つ。

>>639
あまりないとは思うけれど、Kotlinを
ttp://practical-scheme.net/trans/beating-the-averages-j.html
のLispみたいな位置づけにしている人とかが、もう一つの想定ケースw

>>642
ありがとうございます。でも挙動を確認するくらいなら、自分で実装する、かな。

648 ：
>>647
作る内容にもよるけど、ライセンス表記を乗せる手間とkotlinで上がる開発効率を考慮したら後者の方が大きそうではあるw

649 ：
com.google.gms:oss-licenses を使ってオープンソースライセンスを表示する
https://qiita.com/sho5nn/items/f63ebd7ccc0c86d98e4b

650 ：
>>647
そのケースなら大抵の人は迷わずライセンスを載せる方を選ぶと思うけど、
その2択で悩むほどライセンス表示を嫌がる理由がやっぱりわからん。

651 ：
肝心の「ライセンス表示をしなくちゃいけないからコトリンを使わない」部分の理由は謎のままだったな

652 ：
OSSのライブラリほぼ何も使えなくなるよな
Kotlin以外は全部自作コードなんだろうか

653 ：
別にkotlinを避けてjavaで作ろうとしてもapache commonsとか使いたくなることもあるだろうに、それら全部回避してわざわざ自作するのだろうか
あほやん

654 ：
Androidなら何れにしてもほとんどはappcompat-v7を使うことになるのでは？

655 ：
個人的には、>>598以降書き込んだ人全員がKotlinで開発したものに
Apache 2 licenseとNOTICE.txtの表示をつけていることが確認できればそれでいいです。
もとは>>597でKotlinを使っているアプリには必ずライセンス表示がある(はず)ということを確認したかっただけですし。

656 ：
＞個人的には、>>598以降書き込んだ人全員がKotlinで開発したものに
＞Apache 2 licenseとNOTICE.txtの表示をつけていることが確認できればそれでいいです。
？？？
何様のつもりなんだこいつは

657 ：
一方的に話を打ち切る前に、なんでkotlinの使用を断念するほどライセンス表示が嫌なのかの理由を教えてくれよ
昨日からそれが気になって気になって今日も10時間しか寝られなかった

658 ：
>>657
>>647で回答済み。>>648を読んですぐ眠りにつかれたようで何よりです。

>>656
Apache 2 licenseとNOTICE.txtの表示をつけないとライセンス違反になるのなら、
皆が違反していないと確認することはむしろ善行であると思いますが。

659 ：
>>658
お前がどこの誰だからお前に確認されることに意味があるって言うんだよｗ

660 ：
>>658
違うって。kotlinだとライセンス表記をしなくちゃいけないことがなんでjavaを選択することにつながるのか、
なんでそこまでライセンス表記を嫌がるのか、その理由だよ。
単にめんどくさいってだけ？

661 ：
>>655
コンパイラ同梱またはコンパイラの一部ソースを含む場合はNOTICE.txt要るけど
標準ライブラリ同梱だけならNOTICE.txtの方は要らんよ

Apacheライセンスの表示またはテキスト同梱は必要

662 ：
>>658様にご確認いただき大変光栄でございます。
弊社で作らせている糞アプリ、また私共個人で作成しておりますゴミアプリに関しては、
いずれもライセンスの種類を問わず使用している外部ライブラリは全て謝意とともに表示させていただいております。

663 ：
ライセンスをコピペすることがKotlin使用を断念する理由になるほどの手間なのか、、

664 ：
なんの反論もないところを見るにマジでただめんどくさいだけだったのかな
そのためにJavaを使う方がもっとめんどくさいと思うんだけど

665 ：
変化が嫌いな人間っているからな
何だかんだ言い訳して変えようとせず不便を享受する

666 ：
新しくてよくわからないことをやって苦労するのが嫌なんだろうな。
かといってそのままだと激しい競争に負けて稼げなくなるかも知れない。

667 ：
まあ一応、ライセンスの表記はめんどくさい部類には入るとは思う
あとここで発明されたものではないことがはっきり露見するのでイヤとかそういうの

668 ：
>>665
ああそっか、javaを使い続けたいって感情が先にあってそこに理由を後付けしてるのかもな

669 ：2018/09/12
ところで今日はコトリンが誕生した日です。
コトリンでコーディング中の同僚に教えてあげてください。

CVS導入スレ〜 Rev.3
Perl初心者スレ（マジレス回答）
DarkBASIC
Kotlin 5
ふらっと C#,C♯,C＃（初心者用） Part137
【消しゴム】MONOを使ってみるスレ4【じゃない】
C++相談室 part144
次世代言語10[Rust Swift TypeScript Dart]
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part19
TopCoder
--------------------
【シャニライ】うたの☆プリンスさまっ♪ Shining Live【36曲目】
ぎんぎつね
ワグネリアン福永wwwwwww
寿司は過大評価されてるか？２貫目
髭（HiGE) part36
タワレコ長野って・・・
【函館】ﾗｳﾝﾄﾞﾜﾝへの嘆き【限定】
さあさみんなで(‘ω’ﾉﾉ゛ｼｬﾝｼｬﾝ
なんJSOA部★64
インターネットブラウザを晒せPart
【ミティキュア】ダニアレルギー性鼻炎の舌下免疫療法薬【アシテア】
群像文学賞74
肴27754
ソニー会長「iPodはいらない。ウォークマンでいい」
B型が「最も高ストレス」 血液型別イメージは間違いだった
法典の湯
【ネタバレ注意】プリパラ排出コーデ　2枚目
USBオーディオインターフェース Part54
【朗報】「レッツゴー！研究生公演」復活する
【再就職】オッパを見守るスレ【Satart】6
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼