◎正当な理由による書き込みの削除について: 生島英之 とみられる方へ:Kotlin 4 ->画像>1枚
動画、画像抽出 ||
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク: http://5chb.net/r/tech/1531818027/ ヒント: 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう
https://kotlinlang.org ※前スレ
http://2chb.net/r/tech/1521401186/ class A{ var a=A //ここでStackOverFlowになる fun foo(a:A){this.a=a} } 無限ループしてる感じになっているのかな? どう実現すればいいですか?
>>6 何がしたいのか全く分からない。
var a = Aの部分は何をしたいの?
>>6 もしnull許容型にしたくないって意図なら
lateinit var a: A
にするとか
探索のnodeを作っていまして aのところに親ノード入れようとしているんですが、それがうまく行かなくて
それなら普通に var a: A? = null で初期化しとけよ どうしてもインスタンスを入れたいなら var a = A() でもいいけどさ aにはAのインスタンスを入れなくちゃいけないのに、なんでクラスそのものを入れようとしてるんだ
それと質問するときは差し支え無い範囲で実際のコードそのまんまの方がいいよ class Node { var parent: Node? = null } とか書いてあると何がしたいのか読み取れるけど、 Aとかaじゃ何が何やらわからない
>>6 それ var a = A って書いてる?
コンパイルエラーにならない?
あー、var a = A()になってそうだな それなら無限ループになるわ 対策方法は上に書いてあるやつでいいけど
よくわからんが class A(val a: A) じゃいかんのか?
あ、だめか。class A(val a: A?) じゃないと永遠に初期化不能かw
これおもしろいな、aをnull許容型にしないとインスタンスできないだろ Javaだとそんなこと考えることもなかった
試してないけど、nullobject用の派生クラスを用意して、nullobjectのaにはthis代入すりゃいいんじゃない?
>>12 で出来ました
ご迷惑おかけしました。ありがとうございます
他の言語だと、自動でnullが代入されているから、詰まってしまった
これはと思い階乗計算してみたが、微妙…orz class A(n : Int, f : Int = 0) { . val a = if (n > 0) ? A(n - 1, f * n) : else { println(f); null } }
>>20 おっと、いろいろ混ざった。
?と:は消して
>>19 そこ(Nullableと非Nullable)がことりんの最大の特徴だから、ぜひちゃんと理解して使いこなしてあげてね。
intellij入れたんだけど runしようとするとmain classを入力してって言われるんだけど 関数だけでrunできないですか?
>>25 fun main(args: Array<String>) {
// 実行したいコード
}
これが書いてある実行用のファイル作ってrunすれば動く
>>26 テスト書かなきゃだめなんですね
>>27 そうしてるんですがNo main class specified 言われるんですよ
main classってなんや
static void main …のあのおまじないですか?
>>28 main関数の書いてあるエディタのタブ部分を右クリックでメニューからのRunはどう?
fun main(args: Array<String>) { } をクラスの外に作った瞬間にその行の左に緑の三角が表示されて、そこから実行できるね クラスの定義は無くてもいいけど、クラスの中じゃダメだ
>>27 のやり方で普通に動いたよ。
左側のProjectペインから、その実行したいktファイルを右クリックして、そこからRunしてもだめ?
もしくは上の方にあるRun configurationを一回削除してから同じことをしてみるとか。
>>27 一応確認だけど、関数名はmainになってるよね?
他の名前だとだめだよ
>>25 状況がよくわからないからそのエラーが出た時のスクリーンショット取って見せて。ソースが表示されてる状態のな。
みなさん回答ありがとうございました 新しいプロジェクトでやったらできました。 おそらく原因はNewでファイルを作るときにkotlin scriptを選んでしまったためだと思われます srcディレクトリ直下にkotlin file/class でファイルを作ったら実行できました。
あ、そこまで頭回らんかった kotlin 作ったやつが一番辛い案件だな
今更、LinuxベースじゃないOS作ったから使えよ!って言われて流行ると思う?
Kotlin は今はとにかく JavaVM で動くコードを出すコンパイラで Android 開発で使って貰って 世界中に広めてある程度定着させれば良い。その隙にネイティブとか新OSの実行環境用コードを 出すコンパイラを作ってくれれば問題なし。そして Java は死亡して Kotlin は生き残る。
JavaVMなどの他の環境の寄生をやめるなら基本的なクラスライブラリはどうするんだ? コンパイラだけじゃダメじゃね。javaみたいなコレクションフレームワークやらHttpやソケットライブラリあたりも標準で用意してくれないとね。というか寄生やめるならUIフレームワークも必要じゃねぇ?無理だな。 サーバーサイドならいらんが。
ごめん。寄生やめるって話じゃなくて今はとりあえずandroidに寄生してその間に広めてその後は他の寄生先見つけりゃいいって話しかな?
寄生しても良いし、根底から全部作っても良いが、とにかく生き延びる率は非常に高いと思う。 まあでもネイティブでライブラリ全部作るとしてもそんなに時間掛からないんじゃないかな。 問題はどういうやつを作るかだと思う。
Kotlin良い言語だからもったいないよな というか新OSに入れ替わるとしても、既存のAndroidアプリ資産を無視するわけがないから何かしらの互換は保たれると思うけど
JavaFXをKotlinで拾ってくれないかな? OpenJDK+OpenJFX+Kotlinでまとまってくれれば みんな幸せ
>>40 対応言語にKotlinじゃなくてSwiftが入っているというのが、危機感を刺激される。
>>48 ぜひそうなって欲しい。
なにこれ、最近kotlin始めたばかりなのに終了かよwwww
Fuchsiaが普及するとしてもその頃にはKotlin/Nativeも出来上がってるでしょ ただ、Googleの進め方を見るにKotlin/Dartの実装も検討した方がいい気はする
まぁ、でもnull safetyを存分に味わうにはkotlinが標準クラスライブラリを用意してくれるのがいいんだけどね。
>>53 これあくしろよ
ファイル周りぐらいでもやってくれ~
>>51 現状でも、言語仕様を一つ修正するのにJVM, JS, Nativeの3通りの変更が必要になる。
この上、Dartのサポートとか、なんという無茶振り。
>>53 せめてnull safety対応generics欲しいよね。
できるそうだがやったことがない・・・やればいいんだなw
遊びで触ったことあるけど、メリットを何も感じなかった。 特に他のJSライブラリを使うのがえらく面倒くさい。
サーバーサイドでKotlin使ってたら有用な面もある 計算やチェック処理なんかをクライアント側と共用出来るから
JSいらんから、その分の労力をNativeに注力してくれ
>>40 >C言語、C++、Dart、Go、Python、Rust、シェルスクリプト、Swift、TypeScript
この中で生産性の良く主流になりそうな言語ってどれだろう?
PythonかSwiftくらい?
>>65 あとTypescriptかなあ。
Goはキモいからそこまで広がらないと思う。
それ最後に書いてあるよ。 暑さには要注意だ。脳が暖まり過ぎると段々おかしくなる。
入れたときの型そのままで取り出せる汎用的なmap的なもんって実装できないかな
>>69 Anyとスマートキャスト利用するしかないだろうなあ
>>66 TypescriptってC#scriptみたいな物か
何気に一番Javaに近そうねw
>>72 確かにJavaに似てるけど、あれは普通のJSの拡張みたいなもんだから使いやすい、というか既にめっちゃ使われてる
>>73 KotlinよりTypescriptの方が流行る?
TSからJS呼ぶときに戻り値の型意識しなきゃいけないことにイラつく感覚がKotlinからJava呼ぶときにnull意識しなきゃいけないときにイラつく感覚と似ている
てか、CとTypescriptとその他を比較する意味あんのか? 分野が違いすぎんだろ
null安全特有のバグが入ったり null安全のためにコードが長くなったりで あんまメリットない気がしてきた
Javaが有償化するけど、Kotlinにも影響ある?
いやひょっとしたら、JetBrainsがいい感じでやってくれるかと...
>>69 だけどkotlinだと無理っぽいな
arrow-ktでlistっぽいのならあったけど
scalaだとshapelessってライブラリで実現してるらしい
>>80 Oracle版JDKの有償化な
そのためにOracle自身もOpenJDKに力入れてきたんだから特に問題ない(KotlinもJavaも)
>>83 最近ちょこちょこ聞くようになった依存型がこれに使えるのね
>>79 null安全が好きでないなら、動的型付言語を使ったほうが幸せになれるんじゃない?
>>69 >>83 どういうの使用イメージを望んでるのかよく分からないので
コンパイル不可で構わないから使う側の疑似コードを書いてみてほしい
JetBrainsJDKは理想だけど、さすがにそんなことやるほど体力のある会社じゃないだろ
>>79 煽るわけじゃなく、純粋に知りたいのだけど、null安全特有のバグって、どんなのがあるの?
null安全のために記述が長くなるってのもよく分からんな kotlinはそうならないようにかなり配慮されてると思うのだけど、もしかしていちいち全部ifでnullチェックでもしてるんじゃないの
>>88 そうするとGoogleのAndroidのような面倒な問題を抱える可能性があるのでは?
素直に OpenJDK 使っといた方が良いと思うのだが。
RedHatがOpenJDK11を独自にLTSするらしいから、RedHat系のディストリビューション使ってるなら大丈夫だろ ubuntuは知らん
null安全のせいでコードが長くなるのは ・nullを返しうるメソッドだけど今回に限っては絶対にnullじゃない ってケースで !! の2文字が増えるぐらいでは
>>95 これを機にWndowsServerなんてカスは滅ぼそう
>>97 GitHub見てこいよ
アレをプロダクトで安定して使えるようになるまでまだまだ先は長そうだぞ
>>87 val map = HashMap<String, 抽象的な何か>()
map["hoge"] = "文字列"
map["fuga"] = 100
val str = map["hoge"] // :String
val num = map["fuga"] // :Int
みたいな感じで
とにかく型チェックやらキャストやらが面倒くさい
実際には自作クラスとかも突っ込みたい
試してないんで適当言うけど Class.forName(className).kotlin.cast(value) とかでなんとかならんの
>>99 型チェックなしだと取り出した変数が何型になっているかわからなくて結局扱えないのでは?
すまん伝わりやすいかと思って抽象的な何かって書いたけど語弊があるわ まず抽象クラスやらスーパークラスやらこの時点で指定してたらダメだしな ちなみにarrow-ktのHListはタプルみたいな感じになってた
マップに値を突っ込む人は中身の詳細を知らなくて、値を取り出す人はどのキーに何が格納されているか知っているようなシチュエーション、例えば設定ファイルのローダーみたいな奴への適用ならわからんでもない。
何に使う気かっていうとJSFでFlushっていう画面間で値渡すためのMapがあるんだけど、型チェック面倒くさいしチェックしないのも嫌だしでいっそ別に用意できないかと思った 入れるときも取り出すときも型は分かってる状況だな
XMLなりで文字列化しといて使うときにデシリアライズすれば?
keyごとに型が決まってるならjson文字列にしておいてGson使って取り出すとか
>>106-107 のやり方が使うときにはスッキリできそうだなぁ
>>108 二つ目のやつって色々出来そうに見えて汎用的にならないのが惜しい
よく調べないで書くけどMapでしか渡せないならMapの値にクラス突っ込めないの
普通に data class 書くかイヤなら動的型使え案件だな
動的型付言語でもMapから取り出したインスタンスに何かするにはそのインスタンスの型のチェックは必要なんだから、 KotlinでもAnyの変数に取り出した後、何かするとき型チェックすればいいのでは?
一回シリアライズするとか正気かよ。 inline fun <reified T: Any> cast(any: Any): T = T::class.javaObjectType.cast(any) val i = cast<Int>(map["hoge"])
Mapのキーの文字列に対して格納されてる型が決まってるのか エラーチェック無しで間違ったのが入ってたら例外で良いなら、そんな感じにキャストでいいかもね
>>113 動的型付言語は人間が頭の中で実際の型を把握してればコード上では型チェック不要だよ
Ruby
map = {}
map["hoge] = "今は文字列"
map["hoge"] = 100 #今は整数
map["hoge"] = [1,2,3] #今は整数の配列
map["hoge"].each{|i| puts i.to_s} # 今入ってるのは整数の配列だと人間が把握してるので適正なコード
>>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]
Kotlinスレが珍しくKotlinの話してるのか
元の
>>99 についての話なら「キャストなし」が前提なのでは
とはいえシリアライズやGSONなら型定義が必須だろうから
キャストより手間増える気がする
使うたびにキャストするのが面倒くさいって話なら一度定義しとけばあとはそのまま使えるgsonはアリじゃね
てか別にGsonなんて使わなくてもHashを渡して初期化したら中でいい感じにkeyごとにキャストしておいてくれるラッパークラス作れば良いのでは
結局取り出すときに型がわかってるようにするには事前定義が必須と
Mapから特定のキーで取り出した値の型をプログラマが知っている場合だけでしか使えなくて、型がわからないなら型チェックが必要になり、そうするとスマートキャストが使えるので現状のままで問題ない事になる。 型チェックなしで使えるようにできたとしてもやはりバグの温床になりそうだというのもある。(しかも見つけにくいバグにならないか?)
特にKotlinの場合はJavaのウンコ仕様のせいでジェネリクスの型引数を安全にダウンキャストできないからな
そもそもVM利用してるのってJavaの遺産利用する為だしな
>>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
ただのキャストよりコード量が増えて危険な操作であることがわかりにくくなっただけやんけ
全然関係ない話 これが出来る事を知らなかった。 val s = "abc" println("${s + "xyz"}") ダブルクォーテーションで括った中にダブルクォーテーションで括った文字列がある状態なのに問題なくコンパイルも実行もできる。 ${ ... } はコンパイル時に特別扱いしてたんだな。
>>137 マジか、知らなかった。
まあやることはあまりないだろうがw
{}の中はプラグラムのコードやからな。 それだけやで
一番内側のデリミタが来るまでは外側のデリミタはマスクされて見えないという話
むしろコンパイル時じゃなかったらビビる evalがある言語じゃないんだから
unit testしたいんですが junit って標準モジュールじゃないんですか?
operator で何も返さない Unit のやつを作るとどうなるかを実験していて気づいたこと。
例えば plus() って + 記号が出てきただけで呼ばれるわけで、そうなると + 記号だけで中身を書き換える事も可能になるんだな。
https://paiza.io/projects/wtY0TgCLyLhRsls2-6wcuQ >>149 これができるのなら Unit ではない演算子の結果を捨てるような式はエラーにして欲しかった。
JetBrains のサイトに StringBuilder.set メソッドのドキュメントがない事に気づいた。 いやググると見つかるので正確にはあるのだが、どこからリンクされているかがわからない。 普通に考えるとこれは StringBuilder のページからなんだろうが、それはない。getならある。
JavaFX+Kotlinでクロスプラットフォームのアプリ作ろうと思ったけど、 やっぱ今からだとElectronの方がいいのかな SDKからも切り離されたし
竜巻外為良さそうだけど、そもそもJavaFXが流行ってない気が
現時点で流行ってないし、java自体がこの状況で今から人気が出てくるとも思えないよなあ electronかみんな大好きXamarinでも使った方がいいだろう
TornadoFX良かった。JavaFXが切り離されさえしなければ...
トーナードは良いものだよ。 JavaFX自体が消滅しそうだけど
tornado の発音はトーネイドに聞こえるが・・・
なんでJavaFXって人気ないの? Electronが人気すぎるだけ? Electronコード隠蔽できないから嫌なんだけどな
>>160 なんでって、Javaだからだよ
有史以来、FXに限らずクライアントJavaに人気があったことなど無い
javafxscript用の設計だったからね script潰れてjava向けに再設計とか時間かけすぎなんだよ
アンドロイドせいでjava/kotlinを書かざるを得ない迷惑なはなし
>>164 C++やJavaScriptでも書けるだろ
加速度センサーに木星や土星の重力加速度があるのですが、何に使うんでしょうか?
俺も前職で何度か土星行ったから、そういう時は役に立った
10年前にJavascriptとDA PUMPが再ブレークすることを予想してた奴が居たら凄いと思う
Electron + Kotlin/JS というのはアリ? というかしている人いる?
ElectronならTypeScriptでいいだろ
>>175 ReactNativeをKotlin/JSで書こうとして死亡してた人なら知ってる。
出来ないことはない、ってレベルらしい
Javascriptが流行ってるのって言語の作りが良いからとかじゃなくて、結局はブラウザで動くからなんだよな だから、誰かがことりんが動くブラウザを作ればことりん流行ると思う
コトリンが動くブラウザをお前らが作っても流行らんよ
あ、そうか。JavaScriptの代わりにKotlinスクリプトが動けばいいんじゃないか。そうすればわざわざJavaScriptに変換しなくて済む。
GoogleがDartで、それやろうとして、結局、あきらめたじゃん。 Dart自体は、Fuchsiaで復活するみたいだけど。
dartもいい言語じゃねぇけど、JSよりかはましだからな。flutter人気でてdart使われるようになったら、dartのchromeブラウザ搭載計画を復活させて欲しい
wasmにDOM/GCが搭載されれば色んな言語からの需要があるだろうしそれほど夢物語でもない kotlinがその中で天下取れるかはまた別の話だけど
Chromeだけ動くようになったとしても他のブラウザが追随して、かつそれ以前のバージョンが駆逐されるまで待たないと実用できないからな。 それにDart自体がクソみたいな言語であることは変わらないから、多大なコストかけてまで乗り換えたくはないな
TypeScriptという手軽でまあまあなソリューションが広まって、なんかもういいんじゃねという空気だよね
プログラミング言語は素晴らしいから広まるんじゃないのだということを我々はこの30年でイヤというほど味わったのでるふぁい
WebもアプリもKotlinよりTypescriptだろうか
まあそうだね オラクルの件のせいで今後は(Kotlinが使えるような会社においては)Javaプラットフォームが積極的に選ばれることももう無くなるだろう どうしてもJavaプラットフォームを使わざるを得ない事情があるときのマシな選択肢としての限定的なポジションに落ち着いていくんだろうね
Kotlinは贔屓目でもなんでもなく、Java環境で動く素晴らしいJava代替物なのだが その肝心の「Java環境でなければならなかったこと」が唐突に外部要因で縮小し始めており回復の理屈もないのだ… 現時点でJavaに業務で縁のない人はちょっと立ち止まったほうがいいかもしれん Androidでプログラミングしたい? Unity使えUnity
一年前のだけど興味深いディスカッション
なぜKotlin Native?
https://discuss.kotlinlang.org/t/2275/ JetBrainsチームのコメントに気になる文言もある
Rock54のせいで引用出来ないけど18と22
今後の状況次第ではJava環境からの脱出口になるから
もっとKotlin/Nativeにパワーを
Kotlin/Native v0.8 released
https://blog.jetbrains.com/kotlin/2018/07/kotlinnative-v0-8-released/ 言っちゃ悪いけど、開発言語を前提にして物事を考えるのってエンジニアとしてはだいぶ低レベルな段階だよ そのレベルの連中が多数派を占めるほどにはまだKotlinの裾野は広がってないと思う 梯子外されるのがもうちょっと遅かったらもしかしたらとは思うけど、残念だね
仕事と趣味は別という発想が出てこない君はエンジニア以前に社会人としてとても低レベルだね
営利利用されない技術は進歩しないから、たとえ趣味でやってる人も離れていくもんだよ
>>196 そうかな、個人でやる分にはC++でもObjCでも構わないけどそうじゃない環境では
記述性などの他に学習コスト/人材調達的にも
Kotlinはバランスの良い言語だと思うんだけどな
仕事でサーバサイドkotlin使ってるけど今後はOpenJDKにするかもだって
え、むしろ今までOracle使ってたん? うちは8にする時にOpenJDKに切り替えたわ
なんだかんだJDKの混乱も今だけだとは思うけどな。 かっちりしたエンプラのシステムはOracle使うだろうし、そうじゃなくて現時点でKotlin使ってるようなフットワークの会社なら普通にOpenJDKのアップデートに追随していくだろうしな。
>>202 JavaFXしたかったんだ.....
公式にJavaFX使うならOracleJDK使えって.....
OpenJDK9には統合されると思っていたら、ご覧の有様だよ.....dayo.....
>>204 >公式にJavaFX使うならOracleJDK使えって
初耳だ…
そもそもRedHatクローン使ってればOpenJDKでなんの差し支えもないからな、数ヶ月前みたいな絶望感はない FX勢は、なんというか、がんばれw
>>205 今見ると書いてないな...
記憶違いかもしれないが、今となってはどっちでもいい....orz
情報が錯綜して勘違いやデマ流されたりするのが今のJavaは良くないな
>>> println("ちん${"ピョロ${"す${"ぽー"}"}"}ん") ちんピョロすぽーん >>>
まさかJavaよりJavaScriptが主流になる日がくるなんて・・・ 会社入りたての頃にJavaScriptでHP作る担当だった奴を見下してた自分を叱ってやりたい
>>210 そもそも担当言語で同僚を見下すこと自体人として終わってるから悔い改めるためにXamarinのライセンス買ってこい
>>210 その当時の JavaScript と今の JavaScript は同じか?
>>214 同じだよ。
JavaScriptの有用性に気付いたグーグル先生がGoogle Mapを作ってから流れが変わった。
JavaScriptはブラウザで動くからあの立ち位置にいるだけで基本的にはうんち言語 CoffeeScriptだのDartだのTypeScriptだのKotlin/JSだのが出てくるのもJavaScriptがうんち過ぎてなるべく書きたくないからだし
>>217 Javascriptがブラウザで動かなければ、多分Node.jsは生まれなかった。
あれ? ここJavascriptスレだっけ?
ES2018まで至った今としては至極平凡な言語 とりたてて語ることも無い
それがブラウザでそのままネイティブに動けばいいのにな トランスパイラ必須だし
コンパイル型言語は対象が何であれコンパイル要るし JavaScriptとか動的なのも狭義にはコンパイルされてる 単にソースをそのままで動かしたいだけなら babel-standalone とかで ブラウザ上でトランスパイルすれば似た感じにはなる でも開発に関してならインクリメンタルビルドやライブリロードの方が重要かと
フロントエンド周りは一時期進化のスピードが狂ってたからな デファクトだった技術が1年で時代遅れになるとか、頭おかしかった 当時のフロントエンド周りの人らは何故かそれを誇りにしてる感があったけど、 普通に考えたらそんなのに追随するための無駄コストがかさむわけで、結果的にユーザーにとってはなんのメリットもない狂騒だったな
おまえら数日前にやってたJetBrains様の半額セールにお布施した? All Productsパック買っちゃったからもう何が流行ろうとも IntellJIDEA と一蓮托生 Flutter が google スマホ公式言語になっても開発環境はほぼ IntellJIDEA ベース決定だから いまのうちに Android Studio で Kotlin やって慣れておけよ
>>215 ああ。Ajax とか。そういう言葉が作られたぐらいか。
そういや XMLHttpRequest 自体は1999年からあったんだよな。
そもそもブラウザソフトは時代遅れ 既にブラウザからよりもアプリからの方がネットワークアクセスが多くなってる HTML + CSS + JSはもう時代遅れ
初めてアンドロイドのアプリ作る人がいきなりことりん使うのは無謀? まずはjavaからですかね?
プログラミング自体が初めてならJavaからの方が良いと思う
プログラミングはc、java、pythonに少し触れたことがある程度です 肝心のjavaに関してはあまり覚えてないです
Kotlinでいいと思うよ。そのレベルならJavaの余計な煩わしさに振り回されない方がいいと思う。
IT業界に入らないならJavaなんて一生触らなくていいぞ
あるプログラミング言語がドイツ製でドイツ語でしか解説が書いてなかったとするじゃん その場合まあまずは簡単にでもドイツ語から学ぶよね んで、Kotlinは実はJavaプログラムで解説が書いてあるんよ メソッドのちょっと詳しい内部動作とかあれこれ便利ライブラリの使い方とか全部Javaベースで説明されるのよ どうすればいちばん能率的だと思う?というお話なのだ なのだ
Javaは書けなくてもいいけど読めないと辛い 特にメソッドの呼び方と読み方とクラスの関係あたり
初心者に言わなくてもいい余計な情報を山ほど叩きつけて混乱させる悪習がここでも、、
まずこの本を3回読んで、オブジェクト指向を学ぶ スッキリわかる Java入門 第2版、2014 その後、太郎本を読む。 Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016 これが最短!
Kotlin使ってる人はJava10年選手とかで初心者のこと全然思い出せない人ばかりだからな KotlinとJavaの区別がつかなくなってると言っていい Javaの知識ゼロでKotlinやった身から言うとJavaの知識は必須 「それはKotlin本体の話ではない」で毎時間のように詰まったぞ
結局、開発を始めると、言語の部分は関係ない ほとんどが、Android のフレームワーク・やり方がわからないという部分
少し触れたことがあるっていうのがどの程度かわからないけど、自力で小さなツールスクリプトを2,3作ったことがある程度なら 別にJavaわざわざやらなくてもJava読む分には苦労しなかったよ
Android界隈ではまずはJavaからおじさんが闊歩し始めてるのか とりあえずC言語からおじさんの亜種だな
ジェネリクスあたりでわからなくなるとは思う あれはピュアKotlinでの説明見たことないしJavaでの動作読んだほうがいい
初心者がとりあえず何か書いてみるって段階ならジェネリクスなんて存在自体知る必要もないのでは
さすがにそのレベルだとオブジェクト指向で詰まるでしょ Javaを知らなくても他のオブジェクト指向言語の経験は最低でも必要
C#なんかも初学者お断り言語として誕生してそのまま普及して今に至ってるわけだし、 初学者を取り込めるかどうかって実はそれほど重要ではないと思う Java, C, Python, VBAに並んでプログラミング教育に採用されるくらいにならない限り、初学者の流入が言語の普及を大きく後押しすることはない
誰か初心者向けのJava抜きでも大丈夫な入門書書けば良いのでは? 書けるやつここにも居るだろ?居ない? 売る方法はAmazonでいきなり電子書籍で出せばいい。
>>247 書く能力のある人はいるかもしれないが、それだけの時間をつぎ込める人はまずいないと思われる。
232です みなさんレスありがとうございます 人によって結構意見が分かれるみたいですね とりあえずjavaの復習しつつAndroid Studioにも触れていこうと思います
>>250 ご覧の通りここだとみんな好き勝手なこと言って申し訳ない。
ぶっちゃけどちらで書いても大差ないから、両方軽く見てみて自分がやりやすそうだと直感した方でいいよ。
>>249 いやもう夏休みの長い学生とかでも良いんだけどな。内容がまともなら誰が書いても構わないわけだし。
まあ学生はおすすめだな。後で就職する時に自慢げに言えるぞ。
変に期待され過ぎて後々おかしくなるかも知れんがw
>>254 数年後だろうからそれはわからない。
まあでもどんなものでも技術系の本書きましたってのは例えAmazonで電子書籍出しただけでも思い切り自慢して良いと思うけどね。特に学生なら。
本までは出さなくてもいいけど、そこらの勉強会に行ってLTしてるだけでも評価上がるわ 学生に限った話ではないけど
>>247 それは中身としては「Javaの小難しいとこを初心者向けに解説した良書」という存在の難しい書物なのでは…
Java習得している人の説明は、 Javaだとこう書くけどkotlinだとこう書く。で説明できている気になるからなあ 書籍もそういう書き方のものばかり C♯も出始めの頃はC++を例えに説明されてたなあ これではプログラミング初学者には理解できないわけで
読んだことないけどkotlinで書いてるAndroid入門本出てたろ? あれはさすがにJavaの知識前提では書いてないんじゃないの
まあでも新OSの噂を考えたら、Flutterもキャッチアップしておいた方が良さそうだよな。 Dartは糞だと思うが、結局言語自体の糞さなんて無関係に必要ならば使わざるを得なくなるのはObjectiveCが証明してる。
自分もjavaとばしてkotlinやってるんだけどgradle使おうとしたら結局java必須なんですかね
次のアプリは既にflutterで開発中だわ。dartは確かにクソだけどflutterの出来がいいから俺はdart+flutterに移行するわ
kotlinで作ったアプリは結局一つだけになりそう
ネイティブの実装を意識しなくちゃいけない時のためにネイティブで一つは作っておいた方がいいけど、 それ以降はflutterでいいかもな、もう
まあ後発だけあってxamarinよりは使い勝手いいよflutter
同じクラスに val hoge: Int と fun getHoge(): String が書けたりするんで java 知ってても混乱するかも
>>262 KotlinでもGradleスクリプト書けるらしいけど、本格的に使っている人がいるという話は聞いたことがない。
Gradle自体で色々やろうとするのはあまり感心しないやり方ではある
>>270 いや、普通に使ってるけど。
誰かが使ってるかどうかじゃなくてやりたいことが出来るかどうかで判断しなよ。
当然だけどjetbrainsのプラグインサンプルとか見るとgradle kotlinだよ
それどころか Kotlin 本体のビルド環境が gradle kotlin
Xamarinのビルド環境もきっとgradle kotlin
>>272 昔やってみようかと思って調べたら、IntelliJですらコード補完がきかない上に、
エラー扱いでスクリプトが真っ赤になると聞いたんだけど、今はそういった状況って改善した?
build.gradleをbuild.gradle.ktsにするだけでOK?
IntelliJ使っているなら、体験談は聞きたい。
>>280 過去の事例を見ていると泥沼になってるっぽいし、.ktsするだけならいいけど、
他に工夫がいるなら可能性のパターンが多すぎるし。
そんなことよりElectron for Kotlin作ろうぜ
それならflutter for kotlin作りたい
Xamarin for Kotlinがあればこのスレ的には最高だよな
Xamarinほどの◯はない ◯に一字を当てはめて文章を完成させよ。
>>294 借りられてました(T_T)
おそらく夏休み期間中は返却されないでしょう…
>>293 太郎本よりインアクション1冊持ってればいいよ
太郎本は入門時ぐらいしか役に立たないけど、インアクションは後々役に立つ
高いけど
progate に、Kotlin は無いのか? もしあれば、それをやれば?
>>295 polcaとかで募集してくれればカンパするけど、2ちゃんで晒すのは辛いかw
2933です。 冗談半分のつもりで書いたのですが、レスくださった方ありがとうございます。 他の図書館にもprogateにもなさそうなので素直に買います。
この言語があればJava使う機会なんてなくなるの?
>>302 Yes. ただし、Javaしか使っていない会社などからJavaでやるように指定があった場合や、
過去にJavaで書かれたライブラリのソースコードを参照したり修正したりする必要があるような場合などは
はその限りではない。
Oracle JDKのライセンス問題で、Kotlin関係なしにJVMごとJavaを使う機会がなくなるのでは
というのが目下の懸案だけど、JDK 11のリリースされる9月までにはなんらかの発表があって
目処がつくと信じたい。
>>302 今の所 Java VM 上で動かす方式が優勢なので使うと言えば使うなあ。
ただその内 Kotlin native が出来るので、そうなると Java VM 不要なので使わなくなると言える。
Kotlin nativeはJavaのライブラリ使えないんだろ? 全部Kotlinで再実装しなきゃならんのなら辛くないか
>>305 今色々とライブラリ用意してる所なんじゃないか?
それとC言語用のライブラリとか、他の言語のライブラリも使えるようだぞ。
http://blog.64p.org/entry/2017/05/19/005703 まあ、nativeなら使えないわけがないとは思うが。
google的にはkotlinも捨ててdartに行くつもりなのか
>>302 将来的にはYes
現状はNo
JDKがないと使えない
>>307 本命はwasmでしょ
flutterはgoogleによくある戦略外のお遊びプロジェクトで、すぐ消えるよ
flutter程度のお遊びプロジェクトは様々な団体であちこちで生まれては消えてを繰り返している Googleのそれに限って光り輝いて見えるのはSEOのせいであり、だからといってほとんどが失敗して消えていることに違いはない いいかげん気付け
そう思う根拠を教えて なんとなくの決めつけじゃ説得力ないよ
だいぶ色の違うプロジェクトではあるけど、最近だと軍事AIドローン開発の大プロジェクトが中止されたね Google社員が猛反発し、集団退職まで起こった 結構な大ニュースのはずだけど知ってた?そういうもんよ
いや、だからgoogleのプロジェクトのうち長く続くものとそうでないものにどういう違いがあって、 flutterが後者である理由を教えてよ
FlutterはAndroidから噂の新OSへ移行するとしたら絶対必要になるけどな。 そのOS自体をやめない限りは絶対続くし、Java周りのアレのせいでgoogleがAndroidを大転換したがってるのは間違いない。
新OSはまぁ、あんまり期待できないな。マイクロカーネルっていうアーキテクチャは面白いとは思うけど
この間Javaの入門書買ったばかりなのにこんな良さげな言語があるとは… 下調べ不足だわ
Javaの入門書やるレベルならまずはそれを終わらせたほうがいい OOP何それレベルはさすがにKotlinでは門前払い
これからJava離れ、あるいはJVM離れが加速するかもしれないのにJavaデビューとは もしIT業界で戦うための勉強だとしたらKotlinなんて知らない方がマシだぞ
>>317 未読のまま売ろうかなって思ってたけど読んだほうがいいかな
C言語をしばらくやってたからOOP何それ?とはならないけども
>>318 今大学三年なんだけどIT企業への就職を考えてる
もしIT業界で戦うための勉強だとしたらKotlinなんて知らないほうがマシ、っていうのはどういう意味?
>>320 Kotlin使える現場なんて少ないからな
ただでさえJava書いてるだけでストレス溜まるのにKotlin知ってたら「このコードKotlinなら・・・」って余計ストレス溜まるぞ
そもそもIT業界への就職はやめとけw ITやりたいだけなら普通の業界でもできる
まぁ、肌に合わなかったら辞めりゃいいやって甘い考えは捨てた方がいいかもな
ある程度自力裁量のあるプログラミングを業務としてやりたいというのなら、プログラミングの勉強ではなくIT業界研究に時間を割くべきだね プログラミングやらせてもらえない名ばかりプログラマや〇〇エンジニアやコーダが転職もできない底辺過重労働を死ぬか壊れるまでする業界だぞ どうしても判断できなきゃ「プログラミングに興味のある就活中の学生です」という体でツイッターと技術勉強ブログを公開して寄ってきた企業から選べ、確率的にはマシだ
>>324 その言葉を学生の頃の俺に聞かせてやりたいよw
windowsで仕事してるIT企業はブラック macで仕事してるIT企業はホワイト わかりやすいよ
本当はLinuxにしたいけど、GUIツールが貧弱すぎるのとiOSもやらないかんからやむを得ずMac使ってる。 最近はWSLがだいぶ使い勝手が良くなったと聞くがどうなんだろうね。
Linuxを選べるIT企業はホワイト Linux強制のIT企業はブラック
>>333 めっちゃ分かる。
何使っててもいいけど、自分で選べるかどうかが1番大事。
>>328 おまえがキモマカーだということはわかった
強制というか、作ってる製品のサーバ側が Linux だからサーバ側に配属されたら Linux になるってだけのことだな。
有料でもいいからリッチなLinuxのGUIが出てこないもんかね 主流のやつは大体試してきたけど、普段使いのメインにするにはちょっと厳しい
>>338 Linuxはそういうとこが弱い印象
MSにしろAppleにしろ素人集めて
UI使わせてどこで迷ったとかこういう動きした
とか実験して参考にしてるみたいだけど
Linuxは個人の趣味だけで作ってそう
よくLinuxは普段使えるGUIソフトが全然足りないと言われるけど、そもそもGUI自体が貧弱だから当然っちゃ当然だわな。 それがなんとかなりゃMacなんて使わないのに。
LinuxにGUI求める奴はLinux向いてないからMac使った方がいいよ Linuxはシェル駆使してターミナルで使う物
そうだねえ。 できればメインをLinuxにしたいんだけど、現状じゃ無理だ。
>>344 はまさにその通りなんだけど、
みんながみんなそれを言ってるからの現状なんだろうねw
Macはパッケージマネージャがクソすぎるからなあ WSLの出来が意外と良くて、好き嫌いを別にすれば既に開発環境としての使い勝手はWinに抜かれてる
>>344 なこと言ってるからいつまでもメジャーになれないんだよ
>>349 なる必要などないしその労力は無駄であるというのがfvwm95の昔からの結論
>>352 HomebrewってGUIだっけ?
>>350 XamarinスレだからKotlin 1.3の話をする人がいないのは仕方ないね。
ん?Windowsにまともなパッケージマネージャあったっけ?
>>354 apt
ほぼ普通のUbuntuがVMなしで使える
>>353 今のMacではHomebrewはmacOSのセキュリティと干渉してしょっちゅう不具合起こすよ
>>357 毎日のように使うけど、しょっちゅうってほど不具合は起きないぞ
OSのメジャーアップデートの時はやばいが
同じく、しょっちゅう使ってるが、特にHomebrewで不具合起きてないぞ
El Capitanになった時だけは死んだけど、それ以来はそんなことないな
MacはOSバージョン毎年変わるくせにアプリの互換問題な耐えないから大嫌い
$brew install Xamarin ... ... $ Error: Xamarin is shit. Uninstall it ? (Y/Y)
Windowsが好きなら黙って使っとけよ わざわざ自分が使わないものを貶めなくてもいいだろ
MacはBSDに綺麗な服着せて見た目かっこよくしただけだからな ちょっと凝ったことしようとするとシェル駆使する必要があって、Javaとか使ってるだけの純プログラマーに使いこなすのは難しいんだろ
>>368 いや、Macのそういうところは好きだ。あのGUIは邪魔。
MacとWindowsなんて、どこの板のどこのスレでも大荒れ必死な話題なのにこの程度しか燃えないのか ほんとこのスレ過疎ってるな
盛り上がるのは知識がなくても誰でも一言言える話題だからだろうな。 スレチだから他でやれば
ほんそれ。ここはXamarinスレだから、OS論争は他所でやれ、
これからはっていうか、JavaScriptは公用語みたいなもんだし……
Nodeが出来て、JavaScript はなんでも作れるようになったしな
>>382 Android: 成功しているが、まだJavaの方が優勢。しかもモバイルOSはFuchsiaに移行していく。
JVM: OpenJDKの半年ごとリリースのサイクルについていけなくなる。
Javascript: 圧倒的にTypescript
Native: 完成の目処がたたない。
どうしよう未来(さき)が見えない…
と、スレチながら極論してみる。
>>383 FuchsiaのSDK(Flutter)ってDartだってw
Nativeをもっと重視すべきだったんだよな 完全に後手
JBのリソースがそこまで足りてないんだろ flutterが出る前にGoogle様に会社ごと買収して貰えばよかった
>>385 ほんとそれだけが地獄だよな。
flutterは良く出来てるけど、Dartが辛すぎるww
リソースないならJS切り捨ててNativeに注力しろよって思う もしくは逆か 両方やろうとするからどっちも中途半端になってSwiftにもTSにも勝てないんだよ
JBって未だに正式なJavaの認証のないグレーなOpenJDKを配布してるよね Nativeなんか成功するわけないんだから、遊んでる余裕があるなら JBがOracleの正式なライセンスを受けたOpenJDKのディストリビュータになって、顧客にOpenJDKの安定的な提供を確約すべき このままだとVSCodeに食われて潰れるのも時間の問題
そのうちなんとかなるだろう。 Fuchsiaになったらなったでそれ用にコンパイルできるやつができればいいんじゃないか?
Javaは仮想マシン使ってクロスプラットフォーム対応ってのが新しいと言われて普及したけど、それも今は昔 今後の主流はPWAだからJavaとかオワコンになりつつおる
PWAねえ 少なくとも当面の間は主流になることはないと思うよ ビジネス的な理由で
でもflutterって現状sdkってより只のUIツールキットだからな。だからfuchsiaのOS提供機能のAPIが別に用意されてそれは他の言語から自由にアクセスできるんだろうし。 下手するとdart/flutterを全く介さないアプリもfuchsiaで動かせるとか? そこでmicrosoftさんで出番ですよ
>>395 そんなこと言ってると時代に取り残されるぞ
そういう本質的でない技術は主流になってからやりゃいいよ
>>403 関数型言語では、束縛といってletは再入不可だが、
JavaScriptとTypeScriptはなぜか再入可能になる
>>401 技術者としてはキャッチアップしておかなくちゃいけないけど、既存のプラットホームとの兼ね合いで主流になるまでのハードルは高いよ
具体的に言えばAppleとグーグルの稼ぎが減ってしまうから
>>409 確かに
>>399 varとvalが紛らわしいと思う一方で、letと束縛のイメージが結びつかなくて気持ち悪いと思う自分がいる。
>>411 確かにlet自体には束縛の意味はない。関数型言語ではletを使って束縛をする(デフォルトで再入不可)というだけの話。JavaScriptではデフォルトが再入可能なので、letも再入可能になったってことかな?
>>412 (キリッ が付きそうなレスする前に再入可能の意味をググってみよう
リアルで恥かかなくて済んでよかったね
>>414 mutable immutableの和訳なんてどうでも良い
>>404 let を最初に使ったのは Lisp だろ
Lisp の let は新しいスコープを作り、そのスコープに変数を束縛する
スコープに束縛された変数は、再代入可能だし、初期値も必須では無い
最近の関数言語でも概念的には一緒だと思うんだけどね?
関数言語 let a = 1 とかした場合、これは a に 1 を束縛しているのではなくて、スコープに変数 a を束縛してその値を 1 にしている
そして
>>411 が言ってるように、関数言語の場合は変数が再代入不可能だから a の値が 1 固定になる
binding自体は難しいものではないからな 特定の言語仕様がくっついたまんまの状態で別の言語で考えると「??」ってなるだけ それは方言だってやつね
>>417 let a be 1 で値を1にするというのはまだわかるのだけど、
英語nativeじゃないからかもしれないが、
letという単語にそういうスコープ束縛の意味はない気がするのでイメージしづらい。
>>414 再入可能と再代入可能は違うとだけ指摘すればいいものを。
リアルでそんな指摘のしかたでは敵も多かろうに。
俺からしたらreentrantを再入可能なんていう訳がしっくりこないが 再呼出可能だろうと
もう一つ違和感の原因に思い当たったのだけど、 value a is 1, variable a is 1は英語の第三文型だけど、 let a be 1だと、第五文型になるので、統一感がなくなるというのもあるかもしれない。
違和感といえばC言語の『=』ですでに違和感感じてたw 左辺と右辺違うやんって
>>423 第三文型じゃなくて第二文型(SVC)だったorz 第三文型はSVOだ
>>424 そのときにHaskellを知っていれば・・・みたいな話?
>>430 その後に知ったのがMLなのでHaskellは無用だった
>>432 今日やるのはKotlin confじゃなくてKotlin Fest 2018だよね。
なんか進展ありました?
2018年 人気&嫌われプログラミング言語トップ25- Stack Overflow
https://news.mynavi.jp/article/20180604-639227/ Kotlin は結構愛されて求められてるね。
今まで色々な言語使ってきたけど、ことりんは凄く気に入ってる ただ、それが依存してるJavaがなぁー
>>437 ほんそれ。Kotlinにガッツリ打ち込みたいけど、JVM自体がリスク因子になっちゃってて
Kotlinは良い言語だよ、本当に良い言語だ(Dartを書きながら)
KotlinはnativeかJSのどっちかに注力しないとJVMに引きずられて消えてく気がする
そもそもKotlinは、なぜJVMで動くのが前提で作られたのか Javaとの互換性を重視したんだろうけども
そりゃJetBrainsの客層を考慮したら当然でしょ JBの売上ってIntelliJとReSharperがほとんどだろ 後者はC#があるからKotlinは必要とされない したがって選択肢はJavaしかない
kotlinってGoogleと協議とかなしで作り出したん?
Googleと協議してたらクソ言語が出来上がってただろうね
Scala挫折組が低機能Scalaとして開発始めたんだから当然JVM言語
>>445 ネット見てるとPycharm使ってる人多いように見えるけどこれは無料版かな
いま結構大手メーカーに出稼ぎに来てるけど、JS書くのにWebstormつかつてたわ
WebStormはVSCodeの台頭で完全に死んだな
VSCode使いやすすぎてヤバい 未だにたまにEmacsとかVimの特集やってる雑誌もあるけど、vimはともかく、なぜEmacsみたいな旧式のエディタ未だに使ってる人がいるのかわからん
VSCode良いけど、IntelliJが完全に上位互換といって差し支えないからなあ VimとかAtomとかを使ってるなら乗り換えない理由がないけど
TypeScriptならWebStormのリファクタリングがJavaとかKotlinと同じぐらい奇麗に処理してくれそうなんだよね AndroidStudioのリファクタリング使いまくりな俺としてはどっちか選べるのならWebStorm使ってみたい 実際にWebStormのTypeScriptリファクタリング精度がどの程度なのか未確認なんだけど
>>453 無料で30日は使えるんだから試してみればいいじゃない。
おっしゃる通り、Typescriptで開発するならかなり良い。
>>454 暇になったら昔趣味で作ったサイトをTypeScriptとか流行りものてんこ盛りで作り直そうと思っててね
WebStormが期待通りに動いてくれるなら楽しみだ
ありがとう
>>451 emacsは大昔からあって30年以上使ってるような人は既に体がemacsにカスタマイズされてしまっているので他のに移行するなんて出来ないのだろう。
>>457 同意
ElectronってAtomのために作ったはずのに、そのAtomが重くて使いにくいくせに、MSが作ったら軽くて使いやすい物が出来る辺りは、やっぱMSってすげーなと思った
で、結局買収されたしw
>>458 そりゃ母体の大きさが違いすぎて勝負にならんわw
>>456 VScodeが起動できる環境でVScodeで用が済む範囲ならVScodeを使ってるだろう
VScodeはターミナルじゃ使えないしEmacsとは別な方向性で重いし
今時ターミナルでemacs使おうって環境がどうかと思うけどな 設定ファイルぐらいならviでいいし
そもそもデフォルトでemacs入ってるディストリビューションってまだあるの?
>>462 おう、昔はPC-UNIXのディストリビューションにデフォで入ってたみたいな言い方はやめろや
今も昔もEmacsは選択インストール対象だ
>>460 emacsを体で覚えてしまった人は似たようなものでemacsが動く環境ならそれで全てができてしまう状態なんだよ。
だからそう簡単には離れられない。
かれこれ20年以上Emacsを使っている ターミナルではctrl+x 2, ctrl+x d が便利
まじでemacsはおっさんしか使わないわな viはまあサーバーに入って何かするのに必須だから基本操作くらいはできるやつ多いだろうけど
オペレーションマニュアル作る時にesc-x shell は便利 viでも同じ事出来るのけ?
Kotlin使ってるくせに 静的言語+IDE じゃない組み合わせでコード書くとかありえないっしょ なのでそれ以外の用途につかうエディタなんてEmacsで十分 それとも Kotlin 使ってもないのにこのスレ監視してる人?
>>467 最近はVimでもVSCodeでも出来るらしいですよ
emacsは30年前から出来てたけど
うわあ、めんどくさいemacsおじさんがこのスレにもいる 前職で散々聞かされてうんざりしてるからやめてくれよ この手の人たち、ジョークじゃなくて本気でエディタ論争仕掛けて来るからほんとめんどくさい
エディタなんて使う必要ない Kotlin スレで延々とエディタの話するとかありえないですよね
Kotlinは良い言語だけど、JDKに起因する虚無感が漂っててネタがないので、エディターとか他の話で盛り上がってしまう
Kotlin書くなら現状IntelliJ IDEA以外の選択肢はないと思う
めんどくせえから vim で Kotlin 書いてる
めっちゃ効率悪そう こんなにIDEの恩恵の大きい言語なのに
>>482 いや今のところ仕事でバンバン使う招待じゃないからいいの。vimだと思い付いた瞬間に起動してすぐ打てるし。
きょうび開発環境でメモリ足りなくなったりしないからIntelliJは起動しっぱなしだし、思い付いて即試したいものはREPL使うからなー
昔からのやり方を変えられない人ってのはいるんだよ そっとしておこう
>>487 いや、足りなくなる。なぜならそんなにメモリ乗せてないからだ。w
ことりんは名前がいいよな 外国人だとなんとも思わないんだろうけど
外国人だといたずらする小さい悪魔みたいなのを連想するかも知れんね
>>492 えくりぷすならともかくいんてりじぇーでメモリが足りなくなるようなマシンならKotlin使う方が間違い
じゃあ久しぶりに IntelliJ 起動してみるか。
Tip of the day が出るまで約4分10秒。
IntelliJもVSCodeもスタートアップに入れて常時起動してるわ
他のソフトをあまり起動しないならそれでも耐えられるが・・・
>>503 さすがにそれはヤバいw
開発機なら今すぐ買い換えた方が良いレベル
久しぶりに起動してそれならindexingに時間かかってるんだろうから、CPUかなあ、当てずっぽうだけど
ここはKotlinスレであってうんこマシンスレじゃないからそろそろスレ違い
>>507 そうかも知れん。アップデート後に起動したら1分ぐらいだった。
まあしかし開発マシンと言えるほどのものではない。
個人で持ってるPCでそこでは趣味で小さいプログラム作るぐらいなので。
そう言えば IntelliJ がサクサク動くレベルのPCのスペックってどのぐらいのものなんだ?
pentiumとかで十分 ただし中身がatomのは除く
だよな。pentiumマシンで十分だろ。ストレージはssdで。 ただし実機でデバッグ
実機デバッグという言葉を見るにやっぱことりんスレだとAndroid前提の人が多いんかな サーバーサイド勢としては寂しい
spring boot + mybatis + kotlin というテンプレでやってるよ
>>518 Spring bootってもうことりんで問題ない?
今のところフルことりんだとSparkでライトなサイトしか作ってない。
katorはちょっと前に試したけどまだまだ未完成で辛かった
>>516 「Android StudioでつくるAndroidアプリ入門(半端にカラーで分厚い)」みたいな本では軒並みKotlin対応になってるので
最近親切げな本一冊でAndroid始めた人はみんなKotlinやってると思う
ていうかJavaで作るAndroidアプリ本がもう売ってねえ
>>521 会話が成立しているように見えて実は噛み合ってない好例
>>519 まだboot 2.0に上げれてないけど致命的な問題に遭遇したことはない
beanとinterface default methodの組合せで起動時エラーになってたが、@JvmDefaultで回避できるようになったし
@JvmDefault以前も拡張関数でどうにかなってた
今からJava学ぼうと思ってたんだけど、様子見たほうがいい? この言語がJavaに代わってすごい伸びそうだって聞いた でもそれって何年後なんだろう
>>524 様子見できるなら、9月末のOpenJDK 11のリリースか2019年3月のOpenJDK 12のリリースまで
様子見すれば、OpenJDKのLTSが出るのかどうかはっきりすると思う。
2017年はAndroid公認になって伸びるといわれて、実際そこそこ伸びた。
でも、2018年に入ってからはOracleのJDKリリースサイクル変更の問題や
7月のGoogleがAndroidごとJava, Kotlinを捨ててFuchsiaに行くような話も出ているし、
伸びそうというのがいつの時点での情報を元にした認識かにもよると思う。
>>524 KotlinはJavaの方言のようなもの
Javaに代わって主役になるなんて現実にはあり得ないし、Javaが消えたら自動的に消滅する
>>526 言語としては残るんじゃないの。
JVMで動くかどうかは別にして。
Flash亡き後のActionScriptみたいな立ち位置になるんじゃね
Javaの文法はもう古い 時代の流れ的にKotlin風の文法が主流になるのは間違いない
android無視すると逆にそこまでkotlinである必要もねぇんだよな。 javaにラムダもきたしjava10でローカル変数の型推論もきたし。
どちらかというと純Javaでなければならない理由を考えたほうがいい どーしてもJavaじゃないと困るのでないならもはやKotlinでいい んで次は「それを実現する」のにJVM+Kotlinでなければ困る理由をなんとかこう捻り出すのだ
>>529 TypeScriptの流行なんかも含めると時代はKotlin風というよりC#風かな
ベースとしてC#にインスパイアされたちょっとLightweight&FunctionalなC系の流れの本流に近く、
その中では比較的Ruby系に似せた仕上げのなされた言語と位置付けるのが妥当
まあどんなに少なく見積もってもあと5年以上は生きてるだろうから別に今から勉強しても損にはならない
今後は、Nativeなアプリ開発はSwiftに、JSのアプリ開発はTypescriptに、JVMのアプリ開発はKotlinが主流になるよ 問題は、そのJVMの必要性が薄れつつあるのがなぁ・・・(^_^;)
時代に全くついていけてないオッサンか、最近そこらへんのことを知ったばかりのど初心者かどちらかだろ
JVMなアプリ開発はネイティブなアプリ開発じゃないんか
>>540 定義にもよるかもしれないが、間にJVMが挟まる以上ネイティブではないと考えるのが妥当では?
どっからどう見てもツッコミどころしかないんだからそんなにマジレスしても禿げるだけだぞ
Swiftが注目されている頃に、Apple系以外のプラットホームのアプリも開発できるようにしようとかいう動きがあった気がしたけど、その後全く聞かないな
>>543 Googleが次期OSの開発にSwift使おうとしてるやん
そのためにSwiftの開発者引き抜いた
Kotlinはあくまで繋ぎだよ
swiftは言語的には良さそうなのに閉鎖的すぎてkotlinより可哀想
スレチだがtypescriptに完全に置き換わるなんてことあるのか?
>>544 Fuchsiaはswiftだけじゃなくて go rust dart あたりもサポート進めてる
このまえレポジトリ見たときには rust の文章が多めの感じだった
ラトナーがこれに関わってるのなら swift というより llvm 絡みなんだろうなという感じ
>>546 置き換わるっていうか、tsはバニラjsとシームレスに混在できるから、かなり浸透はするだろうね。
Kotlin native もそこに突っ込めればナイス
少なくともRailsブームの時にCoffeeで作っちゃったものは早いとこTSに置き換えておかないと誰もメンテできない巨大な負債になりそう
>>546 置き換わると思うよ
JVMを使うことの必要性が薄れてきてるからね
Nodeが出来たりGAFAのJava離れが進んで、ネイティブ以外はWEB良いじゃんって方向性になりつつある
>>551 あ、JSがTSに置き換わるかって話なんでJVMとか関係ないです
>>552 それだと完全にスレチだからよそでやってくれ
Triple()のTripleを省略したいんだけど
JVMは廃れるのは間違いないのだがさて何年かかるかって話だな Javaはまもなく終わるスマホと心中するってAndroid4前には口さがなく言われてたんだよ 4.4で成功しちゃって誰もそんなことは言わなくなったけども いやもう未来はわからんねえ
>>555 ICS前?確かにショボかったけどそんな風潮だったの?
良くも悪くも一寸先は闇だ。 未来予測は現在までに得た情報からしか出来ない。 しかし明日何かが新たに現れるかも知れず、それによりそこから先の未来は予想と大きく違ってしまうかも知れない。
Javaオワコンだなんてこれまで何度言われ続けてきたことか
>>551 自分でWebって言ってるのにクライアントサイドのことしか頭にないのはなぜ
>>561 なんとか揚げ足を取りたい気持ちはわかるが561はどう見てもサーバーの話してるだろ
Javaっぽいなにかを使ってるSalesforceは廃れてほしい
仕事でSalesforce使ってるけどうんこオブうんこ
俺は触ったことないけど、トラウマレベルのゴミだと聞くな、salesforce
>>562 Node知らんのだろ
そっとしておいてやれ
まあJVM使わなくなったとしてなぜ置きかわり先をNodeに限定してるのかは謎だけどな どっちにしろスレ違い
ここはXamarinスレなんだから脱JVMなんて言わずにサーバーサイドkotlinを粛々と語るべき
Javaで書いてコンパイルしてclassをJVMで実行 TypeScriptで書いてコンパイルしてjsをNodeで実行 まー、似たようなもんだしな
Nodeは一時期ソシャゲのサーバーサイドなんかで広まりまくったけど、 最近そういう大量の軽いリクエストを同時に捌く系の用途はGoが主流になりつつある
>>568 みたいに、ここはXamalinスレとか言ってるやつって、それが面白いと思ってやってるのかな。
認知症のジジイが、同じこと繰り返してるような痛々しさしか感じないんだが。
>>572 みんなそう思いつつもスルーしてやってる
それがエンジニアの優しさってもんだw
>>577 前々から疑問なんだけど
Xamarinは糞とか言うけどC#が糞とは言わないよね
ここはKotlinて言語のスレなんだから合わせたら?
まあスレチだから書き込まないでくれると助かるんだけどさ
じゃあKotlinの話題振れや 何も有益な情報提供せずに何様だ
>>578-579 なんでそんな攻撃的なんだお前らは
黙ってスルーしてりゃいいのに
>>583 FlutterでDart使うと、セミコロンのうざさがわかると思うよ。
FlutterはKotlinの言語仕様と相性がいいのにDartなんだよなー。
まあKotlin名指しの需要はないよね 言語選択の裁量のある現場において使いたいから使うもの
いやいやAndroidアプリの求人はKotlinだらけだろ メルカリもKotlinや
KotlinだからってKotlin経験者に限定して求人する必要は全くないだろ Javaできれば何の問題もない
むしろKotlinに限定してJava触ったこと無い奴来たら困る
>>594 「覚える」がどの程度のことを指すのかが不明確で釣りっぽいが、短く答えるなら、
覚えられるが、実用段階でJavaを知ることになるだろう
と言ったところか。
アプリからライセンス情報確認してみたが、 メルカリもabemaTVもクックパッドもKotlin使ってるな フルKotlinかどうかは分からんが
>>597 前々から疑問に思っていたけど、JVMやJSのKotlinのランタイムライブラリは
Apache 2 licenseだから、製品に含めるときにNOTICE.txtの表示は必要?
ScalaはBSDライセンスだから不要だと思っているんですが。
bsdなら表示しないと駄目だろ。binary も対象って明示されてる
俺は他のライセンスとまとめて書いてるよ なんならMITのライブラリもリストする 作者への敬意というより、依存してる外部ライブラリをリストしておきたいという理由で
>>599 スマン。三条項BSDライセンスに宣伝条項がないという記述の意味を勘違いしていた。
でもランタイム同梱はライセンス条項の適応を受けるという解釈は
>>598 であってます?
もしそうなら、Javaで作ったものには特に著作権表示がいらないけど、
Koltlinで開発した場合は(実行環境にランタイムがインストールされていない限り)
ライセンス表示が必要ということになると思うのですが。
そんなことよりKotlinがApacheライセンスであることの最大の問題は、GPLv2と互換性がないことだぞ つまり、Kotlinで作られたものにはGPLv2を適用できない これは、クラスパス例外を外して配布されたOpenJDKとリンクしたり、 OpenJDKと同じGPLv2クラスパス例外ライセンスを適用して配布したりすることもできないことを意味する GPLv2に固執し意図的に特許周りをグレーなままにしているオラクルに対するアンチテーゼかな
>>603 Apache License 2.0がGPL2.0と互換性ないのは普通に事実だぞ
https://www.apache.org/licenses/GPL-compatibility.html Kotlin製のソースをGPL2.0で配布しようとしたら、ランタイムライブラリをGPL2.0で提供できない限りGPL違反
ライセンス周りのことになるとこういう頭のおかしい拡大解釈する奴が必ず出てくるよな
拡大じゃない解釈を教えてくれよ ApacheライセンスがGPL2と互換性ないのはわりと常識だよ OpenJDKはリンク例外が付いているバイナリを使う限りは問題ないはずだしそう言ったつもりだけど、もしかして勘違いしてる?
俺が予想した通りの返答をありがとうw そういうことを言ってるんじゃないんだけど、 まあ君がそう思うならそう思ってればいいと思うよ。 それで俺は困らないし。
>>602 > クラスパス例外を外して配布されたOpenJDK
この前提がおかしいのでは? 仮にあったとしてもクラスパス例外を外さずに配布されたOpenJDKを使うべき?
> OpenJDKと同じGPLv2クラスパス例外ライセンスを適用して配布したりすることもできない
Apacheライセンス、GPLv2クラスパス例外ライセンス、BSDライセンスを
各部分に別々のライセンスを適用しつつ配布するのってだめでしたっけ
>>604 KotlinがGPL2.0になればNOTICE.txtの表示は不要になる?
ライセンス周りはそこまで詳しくないので、おかしなことを書いていたらそっとご教授下さい。
非互換なのは正しいけども >これは、クラスパス例外を外して配布されたOpenJDKとリンクしたり、 >OpenJDKと同じGPLv2クラスパス例外ライセンスを適用して配布したりすることもできないことを意味する こんな妙ちくりんな例を出して話を無意味に広げようとしなくてもなあ
>>606 ソースを配布するのかバイナリを配布するのかで全然話が変わると思うが、
お前の一連のレスの中でそれが混在してるから話がめちゃくちゃになってる。
非互換なのは確かに正しいし常識なのも正しい。 でも正しいのはそこだけ。まず前提がおかしい。
>>608 GPL2.0クラスパス例外とApache2.0とBSDを混ぜて配布することは可能
ただしその場合、再配布時には決してクラスパス例外を外してはいけない
Kotlinのランタイムライブラリをシステムライブラリだと主張するのはさすがに無理筋
少なくともKotlinでGPLv2なプロダクト(GPLv2のライブラリをリンクしただけのものも含む)を開発するのは不可能なわけで、 特定のベンダーによるプロプラな処理系だけが存在する言語を除けば割と珍しい気がする FSFから攻撃されないのが不思議だな
GPLv2のkotlin向けライブラリは存在しないし 自分で配布するならGPLv2からkotlinを例外にした独自ライセンスにしておけば問題ない
>>614 だよな、上のやりとりを見ててそう思った。
自分で勝手に例外条項つければそれで終わる話。
>>615 Oracleが保身のためにクソみたいなライセンス形態にしてるのが悪い
最初からWTFPLライセンスにしておけば何も問題ないのに
OpenJDKのライセンス決めたのはSunだけどな… てかクラスパス例外あるんだから困るケースは限られるし オラクルに難癖つけたいだけだろ
オラクルなんて大抵の開発者には嫌われてるからしょうがない
>>619 現在は企業が(「ソースのリリース」ではなくOSSベースで開発する目的で)OSSを公開するときはMITライセンスを採用するケースが多くなったけど、
当時はそこまで緩いライセンスを採用することはあまり一般的ではなかったからなあ
Javaのみで開発したJar: Javaのランタイムはシステム側にあるので、ライセンス表記不要.。 Javaのみで開発してJVMを同梱した実行ファイル: GPLv2クラスパス例外またはGPLv2のライセンス表記が必要。 Kotlinで開発したJar: Apache2.0ライセンスとKotlinのNOTICE.txtのライセンス表記が必要。 ということであってますでしょうか。Kotlinを使用したことを隠すことはできない...
お前らの作る糞アプリがライセンス違反で訴えられるようなことはねえよ その前にアプリの質を上げることを考えろよ
>>623 今日の昼飯、ラーメンとマクドどっちが良いと思う?
意味不明で草 KotlinがGPLv2と共存できないのはApacheライセンスを選んだJetBrainが主犯だろw Oracle関係ないww
ライセンス表記なんかで、なんで揉めてるの? オープンソースのフリーソフトなんか感謝の意味をこめて全部記載しとけばいいだけじゃね?
そもそもいつまでもGPLv2なんてクソのままにしてるのが悪いってことだろ
GPLv2とApache2.0に互換がないのはバクみたいなもので 対策したGPLv3とApache2.0との互換性には問題無いとFSFとApache財団で合意とれてるから、v3普及させたいFSFは文句言ったりしないのだろう
>>629 v3は明示的な特許訴訟回避の規定があるからオラクル的にはNG
ライセンス変更するならソース提供者全員の合意が要る
OpenJDKのコントリビュータ全員にはオラクルにソースを寄贈しますっていう契約書にサインさせてるから要らないよ
>>626 それは概ねその通りですが、Kotlinを使用したことを記載したくない場合でもそれが認められない
というのは、マイナスポイントかと。
>>635 そういう人がいればそうだね確かに。
もっと別に表記して問題が起きるわけじゃ無いし、それをマイナスポイントと捉える人はあまりいないと思うけど。。
何にせよライセンスは変わらんから、気に入らないなら Apache License 2.0 を採用しているものを使うのを諦めることだな 俺もライブラリとか見つけても GPLv2 だったら使うの諦めるしさ それだけの話
せやな。そもそも他人の著作物をただで使わせてもらうんだしな。
商用でも非商用でも、使用したものを隠さなくちゃいけないことはそうそう無いだろ 気持ちの上でなんとなく隠したいってくらいじゃね てか今どき何を作るにもライセンス表記の必要なライブラリの1つくらいは大抵使うんじゃないの
ライセンス表記いやなら全て自分でつくればいいだろ無能
Kotlinレベルのものを自分で全部作れたら無能どころかGoogleあたりからとてつもない年収でスカウト来るなw
googleが提供してるライセンス表示するライブラリがあって、これ使うと楽だぞ
>>641 仕様が決まってて実装するだけなら手間だけの問題で難しくはないぞ
難しいのは仕様の設計
ライセンス表示をしたくないからapacheライセンスがマイナスポイントになるとは、世の中には色々な価値観の人がいるもんだな 初めて聞いたよ
受託開発でKotlin使ったことが客にバレたら困るからとか? まあその場合は客にライセンス許諾させなきゃいけないからどんなライセンスだろうが隠せないけど
>>645 考えられるとしたらなんらかの理由でkotlinを使っちゃいけない要件なのにこっそり使っちゃった、とか?
その場合ライセンス表記をすっぽかすよりはるかにヤバいことになりそうだがw
>>644 コードが数画面分に収まるくらいのシンプルなユーティリティを公開するとして、
KotlinだとライセンスとNOTICE表示の実装をしないといけないので、
KotlinじゃなくてJava使おうかなと感じる人がいるかもというのが想定ケースの一つ。
>>639 あまりないとは思うけれど、Kotlinを
http://practical-scheme.net/trans/beating-the-averages-j.html のLispみたいな位置づけにしている人とかが、もう一つの想定ケースw
>>642 ありがとうございます。でも挙動を確認するくらいなら、自分で実装する、かな。
>>647 作る内容にもよるけど、ライセンス表記を乗せる手間とkotlinで上がる開発効率を考慮したら後者の方が大きそうではあるw
>>647 そのケースなら大抵の人は迷わずライセンスを載せる方を選ぶと思うけど、
その2択で悩むほどライセンス表示を嫌がる理由がやっぱりわからん。
肝心の「ライセンス表示をしなくちゃいけないからコトリンを使わない」部分の理由は謎のままだったな
OSSのライブラリほぼ何も使えなくなるよな Kotlin以外は全部自作コードなんだろうか
別にkotlinを避けてjavaで作ろうとしてもapache commonsとか使いたくなることもあるだろうに、それら全部回避してわざわざ自作するのだろうか あほやん
Androidなら何れにしてもほとんどはappcompat-v7を使うことになるのでは?
個人的には、
>>598 以降書き込んだ人全員がKotlinで開発したものに
Apache 2 licenseとNOTICE.txtの表示をつけていることが確認できればそれでいいです。
もとは
>>597 でKotlinを使っているアプリには必ずライセンス表示がある(はず)ということを確認したかっただけですし。
>個人的には、
>>598 以降書き込んだ人全員がKotlinで開発したものに
>Apache 2 licenseとNOTICE.txtの表示をつけていることが確認できればそれでいいです。
???
何様のつもりなんだこいつは
一方的に話を打ち切る前に、なんでkotlinの使用を断念するほどライセンス表示が嫌なのかの理由を教えてくれよ 昨日からそれが気になって気になって今日も10時間しか寝られなかった
>>657 >>647 で回答済み。
>>648 を読んですぐ眠りにつかれたようで何よりです。
>>656 Apache 2 licenseとNOTICE.txtの表示をつけないとライセンス違反になるのなら、
皆が違反していないと確認することはむしろ善行であると思いますが。
>>658 お前がどこの誰だからお前に確認されることに意味があるって言うんだよw
>>658 違うって。kotlinだとライセンス表記をしなくちゃいけないことがなんでjavaを選択することにつながるのか、
なんでそこまでライセンス表記を嫌がるのか、その理由だよ。
単にめんどくさいってだけ?
>>655 コンパイラ同梱またはコンパイラの一部ソースを含む場合はNOTICE.txt要るけど
標準ライブラリ同梱だけならNOTICE.txtの方は要らんよ
Apacheライセンスの表示またはテキスト同梱は必要
>>658 様にご確認いただき大変光栄でございます。
弊社で作らせている糞アプリ、また私共個人で作成しておりますゴミアプリに関しては、
いずれもライセンスの種類を問わず使用している外部ライブラリは全て謝意とともに表示させていただいております。
ライセンスをコピペすることがKotlin使用を断念する理由になるほどの手間なのか、、
なんの反論もないところを見るにマジでただめんどくさいだけだったのかな そのためにJavaを使う方がもっとめんどくさいと思うんだけど
変化が嫌いな人間っているからな 何だかんだ言い訳して変えようとせず不便を享受する
新しくてよくわからないことをやって苦労するのが嫌なんだろうな。 かといってそのままだと激しい競争に負けて稼げなくなるかも知れない。
まあ一応、ライセンスの表記はめんどくさい部類には入るとは思う あとここで発明されたものではないことがはっきり露見するのでイヤとかそういうの
>>665 ああそっか、javaを使い続けたいって感情が先にあってそこに理由を後付けしてるのかもな
ところで今日はコトリンが誕生した日です。 コトリンでコーディング中の同僚に教えてあげてください。
>>667 確かにめんどくさいけど開発言語の選定に影響を及ぼすほどの工数じゃないと思うw
今日はハイジャックされたエアベトナム機の搭乗者75人が全員死亡した日です
9月15日は 老人の日 ひじきの日 大阪寿司の日 スカウトの日 シルバーシート記念日 シャウプ勧告の日 国際民主主義デー 独立記念日 [エルサルバドル・グアテマラ・コスタリカ・ホンジュラス・ニカラグア]
29歳か エンジニアとしては脂が乗ってて転職もしやすいいい年齢だな
Kotlinを使うことのデメリットはビルドが遅くなる
Kotlinに慣れてしまうとたまにJavaのコードを読み書きしなくちゃいけなくなった時に辛いのもデメリット
そして頭が Java モードに移行した後で String s = "hpge"; がなぜコンパイルエラーなのかと数秒悩む。
Javaとの切り替えは楽だわ、全然違うから。 Swiftとの切り替えの方がはるかにしんどい。似すぎなんだよ。
Goの変数宣言は大嫌い err変数の使い回しを推奨してるからerrが最初に出てくる箇所だけ := で後は = という一貫性に欠け紛らわしいコードになる そのうえ := は左辺に新規変数が一つでもあればよく、その他は普通の再代入になるという変数宣言の意義を無にする支離滅裂な仕様 あれなら := だけに統一して最初に出てきた箇所を変数宣言と見做す仕様でよかっただろ
>>687 微妙に違ってるのが残念
errは使いまわさない
if判定式に書いてとブロック内での利用がGoのスタイルらしいです
普通はGoのイライラポイントは行末にセミコロンが置ける判定だと 勝手にセミコロンが入ってる前提でコンパイルしようとするところだと思う
>>687 言いたいことは分かるけどそれ実際そんな問題になるか?
つーかコロンがあるとソースが気持ち悪い 関数参照とか特に
書いた本人もsがどこから来たのかわからない。 でも真実は太陽のようなもの。何時までも隠し通せないものさ。
editTextで複数行入力可能で最大3行まで 入力できるようにするのはどうしたらいいですか maxLinesだと無視されるようです
>>700 それは Android の話? だったら Android スレで聞いた方が良いのでは?
まあ気長に待てばその内わかる人が来て何か書いてくれるかも知れんけどね。
分かるけどググれば4秒くらいで解決しそうだから教えない
コーヒーを入れた後の出し殻はトイレの消臭剤として有能だ どうだ、役に立つだろ
【審議中】 ∧,,∧ ∧,,∧ ∧ (´・ω・) (・ω・`) ∧∧ ( ´・ω) U) ( つと ノ(ω・` ) | U ( ´・) (・` ) と ノ u-u (l ) ( ノu-u `u-u'. `u-u'
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10196453085?fr=and_tw 「Kotlinしかありえません。」
「今後Javaでの開発は急激に衰退していきます。」
「Open JDKなぞ企業が利用するはずもありません。」
有償も無償もJDKを否定しながらKotlinを薦めるって意味分かんない
>>710 企業は有償のJDKを使うが開発はKotlinでやる事が多くなるって言いたいのではないかな。
ま、なんか勘違いしてそうではあるが。
君がしてくれ。俺は全然わからないので君の書いたのをひたすら読むから。
Kotlin 1.3 むかしむかしあるところにおじいさんとおばあさんがいました
おじいさんはキャバクラへ、おばあさんはホストクラブへ行きましたとさ。 めでたしめでたし。 ┼ヽ -|r‐、. レ | d⌒) ./| _ノ __ノ _______ 企画・製作 5ch
Windows 10 でコマンドラインのコンパイラの新しい kotlin 1.2.71 をインストールして kotlinc 実行したら「アクセスが拒否されました。」が出る。 Linux 用のやつを WSL の Ubuntu にもインストールしたがそちらは正常に動く。 なんだろ?
わかった。kotlin-compiler.exe がウイルスバスターの監視に引っ掛かってブロックされたからだった。 なんか変えて失敗ってことか。
強いて言うならウイルスバスターとかいうゴミをわざわざインストールしてるのが失敗
>>726 かといってウイルスバスターにブロックさせなくても java.lang.refrect.InvoctionTargetException が出て動かない。
そちらではちゃんと動く?
コピペしてもあまり意味ないかも知れないが、Windows にインストールしたコマンドラインコンパイラはこんな感じだ。 C:\>kotlinc -version info: kotlinc-jvm 1.2.71 (JRE 1.8.0_144-_2017_08_24_19_19-b00) WARN: Failed to load filesystem access layer: Windows 10, 1.8.0_144, nio2=true java.lang.reflect.InvocationTargetException at com.intellij.openapi.util.io.FileSystemUtil$Nio2MediatorImpl.getAttributes(Unknown Source) at com.intellij.openapi.util.io.FileSystemUtil.check(Unknown Source) (長いので省略) Caused by: java.lang.ExceptionInInitializerError at sun.nio.fs.Util.split(Unknown Source) (長いので省略) at java.nio.file.Paths.get(Unknown Source) ... 41 more Caused by: java.nio.charset.UnsupportedCharsetException: MS932 at java.nio.charset.Charset.forName(Unknown Source) at sun.nio.fs.Util.<clinit>(Unknown Source) ... 59 more C:\>kotlin -version Kotlin version 1.2.71-release-64 (JRE 10.0.2+13) C:\> kotlinc は何故か Java VM が JRE 1.8.0_144-_2017_08_24_19_19-b00 で動いている 事になっているようだが、Java 10 (jdk-10.0.2) しかインストールされていない PC なので これはおかしい。Linux の方にインストールした kotlinc コマンドはエラーは出ないが JRE 1.8.0_144-jdk_2017_08_24_20_46-b00 で動いている事になっていた。 ほんのちょっとバージョンが違う。 kotlin コマンドの方は普通に Java 10 で動こうとしていてエラーは出ない。
今日Windowsで動かしたけど別に問題なかったぞ
そう?同じ1.2.71?Javaの方は10? とすると何が原因かわからんな。
情報少なすぎてそれだけじゃ何もわからんけど、 コマンドラインのkotlincは渡すオプションが足りなかったり間違えたりすると動かないからそこらへんじゃね。 そういうのがめんどいから素直にgradle使うことを俺は勧める。
いやしかし Linux にインストールした方はちゃんと動くんだよね。
kotlin.bat setlocal set _KOTLIN_RUNNER=1 call %~dps0kotlinc.bat %* こんなんだぞ。特別なことしない限り違いが出るはずもない。
違いが出るはずもないって言っても実際に出てるんだろ。 俺の環境では問題ないし、公式にもそんなissueは上がってないし、お前が何かミスをしてるとしか思えんよ。 何日もこのスレで文句言う前に自分で原因究明した方が有意義だと思うけど。
意味のわからない、bat なんか使うな PowerShell を使え
>>736 俺じゃねぇw
PowerShellは、起動毎に毎回0.5秒くらい待たされるの我慢ならん。
kotlin-compiler-1.2.71-windows-x64.zipを展開したものを使うと確かになるようだ
>>739 ならない人はそれじゃないやつ使ってんのかね?
>>736 何日もって木曜と金曜にしか書いてないが?
なんでこんなことで苛立つ?おまえ疲れてんのか?
っていうか、-windows-x64なんてのがあるのか。 何もついてない方なら、問題ないな。 D:\home>kotlin -version Kotlin version 1.2.71-release-64 (JRE 11+28) D:\home>kotlinc -version info: kotlinc-jvm 1.2.71 (JRE 11+28)
この子、悪気はないのに周りから嫌われるタイプっぽい。。
>>743 俺も今試してみたけど問題なかったわ。なんなんだろうな。
>>743 よく見たらwindows-x64が付いてないzipファイルもダウンロードページにあるね。
OSごとに分けたから共通のがなくなったのかと思って見てなかったよ。
どうもありがとう。そっちでやってみる。
kotlin-compiler-1.2.71.zip と kotlin-compiler-1.2.71-windows-x64.zip の違い。 * kotlin-compiler-1.2.71-windows-x64.zip bin\kotlin-compiler.exe があり、それでコンパイルをするようになっている。 これは WSL の Ubuntu の file コマンドに読ませると下記出力がある。 kotlin-compiler.exe: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows * kotlin-compiler-1.2.71.zip lib/kotlin-compiler.jar があり、それをそのPCにインストールされた java コマンドで動かしてコンパイルをするようになっている。
さあ。 自分は、プロジェクト開いていないときでもREPLを使えるようにstandalone版も入れているけど。 GradleだけでREPLを「簡単に」使える方法あるのかな(イメージ的には、npm install -g)?
>>750 使わないんじゃなくて、スキルがなくて使えないんだろ
確かにないよw でも、たかがREPL動かすためにGradleで苦労する必要もない。 システムにインストール(ダウンロードしてPATH通すだけ)すれば済む話だし。 Gradleはwrapperオンリーで、プロジェクト専用でしか使わない、と自分は決めてる。
だから、Ruby をやっておけって言ってる Ruby == Groovy Rails == Grails Ruby, Groovy に型推論を付けたら、Kotlin, Haxe になる。 基本は、クロージャ
Gradle, Ruby のBundler, npm は、ほぼ同じ
なんかめんどくさい奴だなほんと トラブル起きた時にこのスレでクレクレするだけで自分で何もせず回答待ち、おまけにスキルがないのを開き直りかい ついでに関係ないRuby基地外までやって来てカオスw
>>757 複数の人を十把一絡げにして一人だと考えてないか?
なお、最初にWindowsのx64版がおかしいと書いたのは俺だ。
rubyはム版に生息してるいつものrubyガイジだろ
あいつ他のスレでも見かけるけど、板中のスレ全部巡回してるのかな
Kotlinではあまりやらないけど、LLだとたまに使う 巨大XMLの一部構造を解析する必要があるときなんかに、 「この要素でこの子要素持ってないやついる?」 「この要素の子要素でこの属性持ってないヤツいる?」 「この要素のこの属性が取りうる値一覧くれ」 みたいなのを逐一繰り返し聞く必要がある場合なんかにはREPLの方が楽
俺もIDEAのEvaluate Expression使う。完全にREPLの上位互換だと思う。
android studio3.2で、カーソルがある行のみ整形するショートカットを教えてください
>>770 Shift+下 の後 Ctrl+Alt+l (エル)
>>771 ありがとうございます。
けっこう手順を踏まないとダメなんですね
次に書く行がある場合Ctrl+Shift+Enterで整形できたのですが、
}前など最終行の場合にイライラしてました・・
>>772 Settings の Keymap の Editor Actions の中に、Emacs Tab というのがある
押すと、カーソルがある行だけを、前の行に合わせてインデントしてくれる
たぶんデフォルトだとキーに割り当てられてないので、何か適当なキーに割り当てて使う
じぶんはこれを Ctrl + I と Tab に割り当てて使っている
Tabを直接入力できなくなるけど、特に困ったことは無い
私たち日本人の、日本国憲法を改正しましょう。 総ム省の、『憲法改正國民投票法』、でググって みてください。拡散も含め、お願い致します。
ずっとkotlinばっか書いてると久しぶりにjavaを書いた時に==で文字列比較とかしそうになって危険
そういやnative試しにやってみたらちゃんとコンパイルできて感動した
あれってKotlinだけでiOSのGUIまで全部いけるの?
自分で調べたけど行けそうだね、今週末にでもなんか作ってみるか
どうせ日本語文字処理とか日本語表示とか日本語フォントとか日本語入力とかで(どう)しようもないバグとかあるんだろ お前ら使ってわかりやすく報告しろ
サーバー側もiOSもAndroidもKotlinのみでできてJVMからも独立して最強じゃん
Flutterとkotlin native どっちが将来性あるんだろうか
いまモノがあるという時点で後者 まあ仮に3年後に乗り換えだとしても3年は便利に使えるわけだし充分だろう
俺はFlutterの方が将来性あるし、シェアも大きくなると思うけどな。 特にグーグルがまじでAndroidを捨て去るならそうなると思う。 が、Dartとかいう古き悪しきJavascriptみたいなゴミは書きたくないからNativeを書くぞ俺は
>>784 当方はプログラミングの勉強を始めたいと考えている初心者です
ド素人の質問ですみませんが、
Kotlin nativeだとJVM(Oracle JDKやOpen JDKを含む)の制約から解放されるのですか?
ライブラリとかまだKotlin独自のものが少ないので、色々難しい課題があるとは思いますが、
とりあえずOracleからの著作権侵害訴訟のリスクに怯えなくてもKotlinで開発出来るように
なるなら、安心して開発に取り組めるようになるのではないかと思いまして
もし見当違いの質問でしたら、申し訳ありません
>>783 emojiのおかげでそのへん心配する必要はほぼ無くなったな
>>788 代わりに極めて高い確率でKotlin nativeそのものが頓挫しコード資産や経験がパーになるリスクを背負うことになるけど、それでもよければ
>>783 あるかなあ?元から国際化考えて作られたものだからnativeになったからといって新たにそれのバグが追加されるとは思えんが。
>>790 私がKotlin native習得に挫折するなら話は分かりますが、Kotlin nativeそのものが頓挫することは
ないんじゃないでしょうか?
>>793 普通にあるよ
何を勘違いしてるのか知らないが、たかが小さな会社の俺プラットフォームでプロダクションには現状誰も使ってないんだぞ?
そんなもん毎日のように腐るほど生み出されては消えていっている
逆に成功したら超ラッキー、くらいのレベルだ
Kotlinユーザーってほぼ例外なく他の言語も使えるから、Javaがゴタゴタしてるからって無理にKotlinに固執する理由もない
言っちゃ悪いけど、他に選択肢を持っている人がオモチャとして観察するフェーズであり、キャリアを賭けるようなもんじゃない
これから新規でクロスプラットフォームでアプリ作るとしたらflutterとkotlin nativeどっちがいいんすか
>>794 なるほど、社内でのKotlin nativeプロジェクトにおける開発という意味で頓挫と仰っておられたのですね
了解しました
Kotlin自体の開発元のJetBrains社によるKotlin native開発の頓挫のことを指してるのかと思ってしまったので。。
確かに現場視点から見ると、著作権云々より色々考慮しなくてはいけないことがあるんでしょうね
私の元々の質問の意図は、Kotlin nativeで作成したネイティブバイナリのコードであれば、Oracleの著作権
侵害とは一切関わりのないコードが生成できるのかと確認することでした
実際の現場での開発運用までいくと、会社による顧客へのサポート対応とか諸々の課題を当然考慮しないと
いけないでしょうが、今回の質問はそこまで踏み込んでおらず、あくまでOracleの著作権の影響範囲とその
回避について、Kotlin nativeの開発は有用か尋ねたつもりでした
多分私を学生だと思われて、現場の泥臭いことを教えていただいたのですね
勘違いさせてすみません
50近いオッサンが、趣味と好奇心の延長で質問したことですので
>>797 そうじゃなくてJetBrainsによるKotlin native開発が頓挫する話だ
JetBrainsはMSやOracle、Googleといった力押しで言語を普及させることのできるような企業と比較すれば遥かに「小さな会社」だよ
趣味なら好きにすればいいし、頓挫しても経験は決してゼロにはならないけど、
Javaロックインよりも遥かに大きなリスクを抱えることになるというのは理解しておきなさい
>>794 に禿げ上がるほど同意しすぎて禿げたわ
まだまだおもちゃとしか言えないレベルだよな。
とは言え一年前に比べたらだいぶ進化してるから、一年後にどうなってるかはわからない。
>>798 なるほど、まだKotlin nativeは使い物になるレベルに達していない代物なのですね
色々ご教授いただき、ありがとうございました。
正直、従来のKotlinとKotlin nativeとの言語としての完成度の差を知らなかったので、
大変勉強になりました
今は、(Kotlin nativeではなく)ノーマル(従来)のKotlinを触って勉強したいと思います
現状大差ない どちらもプロダクトに投入してる例はあるけどまだまだこれから
React Native + Kotlin/JS + Objective-C でアプリ書いてるけど React Native + Kotlin/Common + Kotlin/Native (RCT_EXPORT_MODULEだけObjC) を考えてる
>>804 Kotlin使ってるならObjCじゃなくSwift使えよ
構文とか似てるし
>>804 なんでそんな目に見える苦行の道を選んだのかw
>>806 以前別アプリで使ってたけど型推論あるとビルドクッソ遅いの直ったの?
ちょっとでも欠点を見つけるとそれを理由にして新しいものを拒否するやつってどこの世界にも必ずいるよな
それ以上に、古いものの欠点を過剰に騒ぎ立てて新しいものをゴリ押ししようとする奴のほうが多い気がする
あと個人的な経験でいうと、新しいものの欠点はむしろ検討段階で見落とされて後で問題になることが非常に多い 新規導入におけるビジネス判断って、フィーチャーだけに目が行って非機能仕様や細かい制約はあまり考慮されないもんだ
今ある問題に目を瞑って現状維持に固執するやつは多い 新しいものを見ると特に検証もせず推し進めるやつもいる
新しいものを受け入れられなくなった時が老化の始まりだと思っている
人は歩みを止めた時に、そして挑戦を諦めた時に年老いてゆくのだと思います。 このソフトを使えばどうなるものか。 危ぶむなかれ、危ぶめば道はなし。 踏み出せばその一足が道となり、その一足が道となる。 迷わず使えよ、使えばわかるさ ありがとう!
都合よく自分の使いたいものを想定して一般論を語るのはいけない こんな糞パッケージや糞製品導入した奴は子ねって思ったこと、ITエンジニアならあるだろ?
自社が製品として販売しているオリジナルフレームワークを自社サービスで使っているせいで仕事を辞めたことはある。 本当に、本当にゴミフレームワークだった。
>>814 その新しいものとやらが実際には価値のないものだったら動かない方が勝りますね
重要なのは新しいか古いかではなく、自分の望みを叶える事に使える道具かどうかだ。
>>819 叶えるのに最適かどうか、と言わないとC言語でなんでもできるおじさんがやって来るぞ。
>>820 そういやそうだな。
C、そしてアセンブラ最強になってしまう。
Kotlin の Char には isAlphabetic() がないのな。 しょうがないからプログラムの上の方にこんなの作って使っている。 fun Char.isAlphabetic() = Character.isAlphabetic(toInt()) こういうのってこうやって簡単に作れちゃうから最初から標準のライブラリに入れてないんだろうか? しかし最初からあってくれた方が楽と言えば楽だなあ。
直接JavaのAPIを呼ぶべきだからだよ そんな基準でKotlin版作ってたらキリがない そもそもCharacterのメソッドってプログラマの使いやすさよりもUnicodeの仕様を正しく反映することを意図して作られていて、 そんなに頻繁に使うようなものではないだろ 知ってると思うけどisAlphabeticって平仮名とか含むんだぞ?
おっUnicodeのクソさならおじさん語っちゃうぞ
クロスプラットフォーム狙うなら用意しなきゃ駄目だな
>>825 じゃJstarの開発マニュアルから初めてくれ
全て聞き流してあげよう
>>824 Charでやっといてくれればnativeでコンパイルする時にもそのままにできるという利点がある。
なんでByte型に符号が必要なんだろ。 扱いづらすぎ c#のbyte型にしてたもんせ
そして符号付きbitシフトとかどこで使うのか、今でも意味不明 Javaの負の遺産を引きずってるなー
Kotlinがそれなりに流行ったのはJavaの呪いを受け入れたからに他ならない その代償がその程度であれば小さいもんだろう
javaつうか元々cの右シフトの挙動が定義されてなかったから、それを引きずってるだけ
まあそこらへんは存在したとしてもどうせ使うことはないだろうから別にいいよ
>>830 シフトに関しては符号付き、符号無しの区別は重要だと思いますよ
ビットシフトはビットシフトで考えたほうが早いオールドタイプを宥めるために存在する 彼らの言う「ビットシフトでやったほうが速い処理」が必要な、いつか来る未来というのは結局来ずに終わる可能性のほうが高い 残りの折り返し見えた人生、来るほうにかけて生きてもいいけどさ
>>837 冪剰余のバイナリ法をみても、ビットシフトは重要だと思いますよ…
符号無しシフトは非常に稀には使うけど 符号付きシフトは使った記憶がない とはいえKotlinでは記号じゃないから負の遺産とは思わないな C++みたいに右シフトがtemplate構文の邪魔するとかなったら呪縛もいいとこだけど
ビットシフトを使うほどカリッカリにパフォーマンスに拘る時にkotlin、というかjvm言語を使うかって話よね。 必要な場面があるのは分かるけど、今時のサーバーで普通のシステムを動かす前提なら普通はまず求められないし、可読性を犠牲にしてまで使うべきだとは思わない。
主に移植性や相互運用性のために残ってるだけで批判の対象になるようなケースはほとんど実在しないと思うけどな
>>839 >右シフトがtemplate構文の邪魔するとか
C++11 lator でこの制限はなくなりました
使うシチュエーションは確かにあるけどものすごく稀だな あれば2年に1回くらいは使うかもしれないけどなかったらなかったで別に困らない
ビットシフトな。実務で使うことはまあないな。 何かの解析とか組み込み系なら多用するだろうけど、そんなところではそもそもこちょりん使わないだろう。
ビットシフトは画像処理やBluetoothで使いまくるぞ
だからそういうのを自前で実装するケースってそうそうないやろ、って話でしょ
元々ビット単位で詰め込んであるようなデータの解析には使った方が見易くなるかも知れない。ネットワークのパケットとか、その他色々あるよね。 もちろん割り算や余り計算すれば特定のビット抜き出す事はできるし、恐らく最適化されると最終的なコードは同じになるだろうけどね。 なのでどう書くと見易くなるかの問題だな。16で割って8の余り出すように書くか 4 ビット右シフトして 7 を and するように書くか。 だいたいは後者の方が見易く分かりやすいかも知れないが、場合によっては前者の方が良いかも知れない。
ビット操作するなら素直にビット操作演算子つかえばいいんじゃね ことりんはわり算した時のビット内容に規定があるのかわからんし
なんだ、低レベルな処理をkotlinで書きたい人って結構いるもんなのか。 そういうのはCか最近ならGoあたりを使うと思ってた。
最初は普通にkotlinで書いて、ボトルネックになるようならネイティブに逃がすでしょ。画像処理とか明らかにヘビーなことやるなら最初からネイティブで書くけど。 ところでkotlinネイティブで、本体の部分はJVMとかでkotlinで書いて、ヘビーな部分はkotlinネイティブで書いて利用するとか芸当簡単にできるようになるのか?
例えばandroid画像処理アプリ本体はdalvikのkotlinで動かして、画像処理本体はkotlinで書くけどネイティブでとか。
論理的にはできるはずだから、パフォーマンス比較してみたいなそれは
透過的にできるようになるといいな。例えばメソッドに native 付けておけばそのメソッドは自動でネイティブにコンパイルされるとか。
Androidならともかく、PCの方の非海賊版JVMのパフォーマンスをnativeが超えるのは相当難しそう
>>855 LLVMのコードってほとんどただの抽象化された機械語だから、
Kotlinを動かすならこれまでJVMに依存してたランタイムの機能を独自に相当作り込まなきゃいけないよ
10月初めのと基本同じ情報だけど日本語で来てるから貼っとく
Kotlin 1.3リリース ? コルーチン、Kotlin/Nativeベータ
https://blog.jetbrains.com/jp/2018/10/30/1511 これだけの大幅機能追加なら、そろそろJavaみたいにKotlin3とかに名前変更してもいいと思うけどな
Goとかrustみたいに、システムプログラミング向けとしてもkotlin /native は使われる将来性はある?
>>861 プリミティブのintと参照のIntを明示的に区別する仕様ではないから向いていないのではと思う。
>>861 低いレイヤーを直接触るようなことはやりにくいから、あえて使う理由もないと思う
出来ないことはないだろうけど
参照型にnullを許さないってのも、微妙だな 書いてて疲れる。 hoge?.fuga とか hoge!! とか返って可読性が落ちてる希ガス
>>864 そうだよ
面倒だから使いたくないでしょ
使わないようにしたいんだよ
だからそうなっている
arcだとすると既存プログラムはコードを書き換えないといけない場合があると思うけど、それを承知で採用してるの?
やってみたかっただけでしょ 所詮オモチャなんだから
ARC with cyclic collector というのをちらほら見る 弱参照を使わなくても既存コードのままで問題無いようだ ただこれがGCのような停止時間を発生させるかなどはよく分からなかった
諸々の問題の解決を試みているうちに、気がついたら出来上がったものはGCそのものだったというオチになりそう 既存の枯れた技術を舐めてかかって自分で実装してみてはじめてそれが十分に優れていたことに気付く 技術の過度な抽象化による間違った万能感に陥りがちなITエンジニアにはよくあること
オリジナル言語を頑張って作ったが結局動作的にLispになったみたいな話だな
そのまんまでしょ。弱参照ないARCで管理するが、循環参照用に定期的にGCは走らせる。
だから循環参照するクラス大量だとフルGC走らせるのと同じことになるが、大抵のプログラムでは循環参照するクラスはそんな大量じゃないので大抵のケースではARC with cyclic collectorの方が速くなるとか
ところでkotlinにweak reference見たいのあったっけ?
>>875 nativeでは kotlin.native.ref.WeakReference
jvmでは java.lang.ref.WeakReference が有る
jsには無いからcommonにも無い
javaや.netにあるのは知ってるから質問けど そっか、所詮、最大公約数になるから他の言語に引きずられまくりでjsとかにねぇからkotlinで標準で用意されてねぇのか。
いやKotlinに無い理由はJavaにあるからだよ 建前はともかく、実態はAltJavaとしてしか使われてないしJBもそれを前提に開発してるのが実情
現状だとメモリ管理は対応プラットフォームの機能に寄生するみたいな感じになってるのは気になるね iOS向けだとiOSのARCを利用するし、Cなら手動で開放してる Kotlin/Native として統一的なメモリ管理機構を作らないと、プラットフォームを超えたコードの共有化とかはかなり限定的なものになりそう しかし統一的なメモリ管理機構を言語で用意すると、プラットフォーム側で用意してるメモリ管理機構と重複部分ができて無駄だなとも思う Xamarinとかはそんな感じだし
ARCはOS関係無くね、Swiftと同じく普通にコンパイラとランタイムによる実装でしょ 現時点でcommon書くときメモリに関して支障は感じないけど メモリ管理機構ってJVM上やJS上でどういうのを想定してる?
JS はランタイム側でGCやってくれるし、JVMもGCやってくれるので、
アプリケーション側の kotlin コードでメモリ開放する必要ないし、循環参照とかも意識する必要ないでしょう
Kotlin iOS では、Swift や Obj-C と同じランタイム側にあるARCを使っているのではないのかな?
この場合アプリケーション側の kotlin コードでは、循環参照とかを意識しなくてはいけないのでは?
Cライブラリを使ってLinux上で直接動くような Kotlin Native コードの場合には、
malloc や free に相当するもので手動でメモリ確保開放とかやる必要があったりしますよね?
https://kotlinlang.org/docs/reference/native/c_interop.html んなわけあるかい LLVMで普通に直接動く実行コードを生成してるだけで、iOSのオブジェクトモデルとは別物だ iOSに循環参照を自動的に見つけて解放してくれるって事実上の独自GCやぞ そんなもん勝手に組み込めるんならみんなとっくにやっとる
var x = Foo() Bar(x) x = Boo() 以上のような Kotlin コードをコンパイルしたときに、Boo()の結果を x に代入するまえに x に入っていた Foo() への参照をどう処理するかってこと Bar(x)の結果、だれかが x に入っていた Foo オブジェクトへの参照を保持している可能性がある JVMやJSだと単に x を上書きするコードにコンパイルすればいいよね iOS向けにコンパイルするときには release(x) みたいなのを含んだ LLVM コードに変換される? もしくは、Kotlin が独自の ARC みたいなの持っていて、それに応じた処置がおこなわれるの? Linux 向けの Kotlin / Native でコンパイルはこのままできるのかな?
>>882 >>884 ObjCランタイムは普通にCのABIのライブラリ群だから
純粋なC言語から呼べるしKotlin/Nativeからも呼べる
iOSでもLinuxでもプラットフォームのAPIを使うには
それに沿ったメモリ構造や解放関数の呼び出しなどのリソース管理が必要だけど
外部呼び出しを除いたKotlin/Nativeの部分にmalloc/free/releaseなどは必要無いよ
>>885 そうすると、 Kotlin / Native で普通に確保したオブジェクトの解放はどういう方式で行われているのかな?
リファレンスカウンタ? GCでは無いよね?
リファレンスカウンタだとすれば、Kotlin/JVMでは問題無いオブジェクト同士が参照しあう構造は、避けないとダメだよね
ここで不毛な言い争いするくらいなら実際にコード書いて試せばいいのでは。。
>>886 >>873-874 と
https://github.com/JetBrains/kotlin-native/blob/master/FAQ.md > Q: What is Kotlin/Native memory management model?
> A: Kotlin/Native provides an automated memory management scheme, similar to what Java or Swift provides. The current implementation includes an automated reference counter with a cycle collector to collect cyclical garbage.
Kotlin 1.3 には Kotlin Native がバンドルされているみたいに書いてあるWebページがあるが、されてないよね? bin ディレクトリ以下はいつも通りのスクリプトやバッチファイルがあるだけで kotlin-native はないんだけど。 何かオプションで変わるのか?
>>890 ということはNativeがバンドルされているみたいに書いてある可能性があるな
古いIntelliJ(1.3) + Kotlin1.3プラグイン: 表示されず 最新IntelliJ(2.5) 素の状態(1.2.51) : 表示されず 最新IntelliJ(2.5) + Kotlin1.3プラグイン: 新規プロジェクトでKotlin/Nativeが表示された IntelliJ側も一定以上のバージョンが必要みたい Gradleプラグインは混ぜる意味無いし、 GitHubのリポジトリ直リリースの方も別のリポジトリと混ぜたりしないだろうから バンドル云々は関係無いと思う
Native使ってみたいけどNativeの恩恵にあずかれそうなアプリねーな
開発環境をインストール出来ない会社のPCで威力を発揮
>>895 そらならKotlinだろうがnativeだろうがインストールできないのでは?
タイプミスった スマホのタイプミスは変になるなあ とほほ
>>897 フリック入力には早く慣れたい、今30文字/分レベル
どうやったらKotlinを使えなくできると思うのか、逆に聞きたい
>>897 そんな些細なミスでいちいち訂正と言い訳しなくていいよ
>>900 Kotlinで書いたコードが動くまでの仕組みの基礎中の基礎を調べた方が良いよ
つまりkotlinは一回javaに変換してからコンパイルしてるってこと?
JVMはバイトコードを読むもの Kotlinソースコードはバイトコードを吐く Javaソースコードもバイトコードを吐く 他のJVM言語(Groovy、Scala、JRuby、Jython等)もバイトコードを吐く ドゥユゥアンダースタン?
>>905 概念的にはそうなんだけど実際にはそういう人間にとってわかりやすい中間的な状態はすっ飛ばして内部でいきなりバイトコード作っている。
>>905 Javaで書かれたコードはClassファイルに変換される
Kotlinで書かれたコードもClassファイルに変換される
つまり、OpenJDK (JVM)から見たら、実行する時点でそのコードがもともとJavaで書かれていたのかKotlinで書かれていたのかの区別はできない。
なるほど ありがとうございます JDKっていうのはコンパイラだけじゃなくてインタプリタも含まれてるのか
そもそもAWSのJDKっても普通のOpenJDKに対して長期的にバグフィックスとセキュリティ修正をするってだけだからな。
Kotlin使っといてJavaのLTS期間がどうとかアホかよ Kotlinって常に最新バージョンしかサポートされてなくて、 新しいバージョンリリースされた瞬間にサポート切れなんだけど、そこ理解してる?
>>910 JDKってか、JVMにバイトコードのインタープリタとJITコンパイラ(実行時によく使用されるメソッドとかをバイトコードから機械語にコンパイルする)が含まれてる
>>913 あ、すまん、文脈としては「だからAWSのJDKでだけ動かないなんてことはない」と言いたかった。
>>914 それとJDKのサポート期間と、なんの関係もないじゃん。いったい何と戦ってるのか。
>>917 どのみち放置運用するようなものには全く使えないんだから、半年毎にJDKを更新するくらい大した問題じゃないでしょ
>>918 最高に頭の悪い見解をありがとう。
そうだね、うんうん、君の言う通りだよ。
>>918 それが大した問題だからここ何ヶ月も世界中で大騒ぎしてたわけで。。
まあアプリ本体とJDKをDockerかなんかでまとめてコンテナ化とかしてりゃ何の苦労もないけどな、
現実に本番環境でそこまで出来てるところはまだ少数派だろう。
うわー。Pleiades インストールしたら IntelliJ IDEA が日本語に! 慣れてないと違和感あるなこれw
eclipseで開発してるやつおる? 最近 eclipse の Kotolin のプラグイン更新されてるみたいだけど、やっぱり IntelliJ の方が断然快適なんだろうか eclipse ずっと使ってきたから、今から開発環境変えるのも苦労しそう
むしろそういったIME使わずに作ってる人いない? どうも自分で制御出来ない感じが慣れなくって
>>923-924 おぢさん達、気持ちはわかるけどその程度のことくらい頑張らないと仕事なくなるよ
>>923 IntelliJの良いところは開発環境周りの苦労がほぼないことだよ
eclipseから移るとマジで別世界で漏らしそうになる
eclipse使っててよくストレス溜めずにいられるよな
>>924 IMEワロス
変数名を日本語にしちゃう人ですかぁ?
>>929 日本語で命名するの、騙されたと思ってやってみたらみやすくてワロタわ。
個人プロジェクトでしかやってないけど、テストケースを日本語にしておくとめっちゃ見やすい。
自分も趣味のプロジェクトはテストだけ日本語で書いてる
>>923 一回使ってみてから決めたら?
そもそもkotlinやるならintellijのほうがいいと思うが
Kotlin使うなら開発元のJetBrainsを支援する意味でもIntelliJの有償版を使うべき 最近はJavaがゴタゴタしてるし、JBが強いスマホ分野ではIDE離れの動きが出てきてるし、開発環境市場はVSCodeが席巻してる このままだと会社無くなってKotlinも終わっちゃうよ
SWT使うから、eclipseのWindowBuilderないとちょっときついのよね IntelliJ は魅力的だしとりあえずインストールしてみたけど、IDE2つ起動しないといけなくなりそう
>>923 プラグインが0.7.2くらいの時に使ったことがあったが、Javaのプログラミングの時にまでエラーが出るようになって、
たまらずアンインストールした。
その後どうなったか知らないが、まだアルファ版のままみたし、もともとのContributorはほとんど関与していなくて、
現在のContributorは実質ほぼ一人だけみたいだから、IntelliJのサポートレベルには
遠く及ばないんじゃなかろうか。
https://github.com/JetBrains/kotlin-eclipse/graphs/contributors >>934 支援させてやるから、俺にも買ってくれよ
>>936 やる気なさすぎてワロタ
まあJBがeclipseを手厚くサポートするメリットが何もないもんな
kotlin勉強してみたけど、なんていうんだろこれまでだと泥臭い書き方になるものが すっきりかけるようになっていいな JavaよりC#のほうがいいと思ってたがC#もdelegateを導入したあたりから複雑化して いまとなってはkotlinのほうがなんか直感的にわかる
本当に使ってるの? C#のdelegateは最初のバージョンからあるし、KotlinってC#をリスペクトしてて 盲目的にC#にあるものは全部取り入れてるからC#より複雑だぞ
C#よりいい点はレシーバ付きラムダ式と拡張関数の書き方かな ジェネリクスは… reifiedはがんばってる気がするけど
あんま使ってないんだと思うしスレチだが 最近のC#はdelegate負の遺産として使わないぞ
この流れはチャンスだ 使った事ないけどデリゲートって何ですか? デリケートなら知ってます
easy scalaとしてkotlin開発始めたんだからC#関係ないぞw てかC#もscalaの記法パクってるの多いからな
エヴァしか知らないとアニメ表現が全部エヴァのパクリに見える現象がここにも
作ろうとしていたのは静的型付けのgroovyで、静的型付け言語の先輩のC#やScalaの記法を参考にしただけなんですけどね
他の言語やった後に C# やると event や delegate キーワードはなんじゃこれって思うよね
>>945 Cのパクリ言語の多さには驚かされます。
>>943 最後の一文から知りたいのでなくて、ネタをやりたかったのだろうとは思うが、一応説明すると、
基底クラスを継承する代わりに、継承したい基底クラスのインスタンスを指定すると、
あたかも継承したかのように振る舞う機能。
基底クラスのメソッド呼び出しは、上記で指定したインスタンスに委譲(delegate)され、
そのインスタンスのメソッドが呼ばれる。
Effective Javaによると継承は一般的に間違いを起こしやすとしてdelegateするよう勧めている。
overrideするメソッドがたくさんあるけど具象クラスがないインターフェースを実装する時に
ヘルパークラスから生成したインスタンスに委譲すると便利。
KotlinでWindowsとかのデスクトップアプリ作ろうと思ったら、やっぱTornadoFXとかになるの? ネイティブで作れたら嬉しいんだけど
そもそもWindowsのデスクトップアプリを作るなら、C#かC++だろ なんでわざわざKotlinで作るんだ
Kotlinが好きなのかKotlinしか知らないからやろ
windows「とかの」 まぁクロスプラット狙ってるならそれでもいいんじやねぇの
Javaでクロスプラットフォームなクライアントアプリを作ろうとしたが、クリップボードひとつまともに機能しかった悲しい思い出が甦る
TornadeFXとかあかんやろ(見もせずに言ってます) ティアが嵩むほどシステムの信頼性は下がる(見もせずに言ってます) Java JavaFX Kotlin あかんやろ、Java標準からも外されるくらいクソなJavaFX、あかんやろ(見もせずに言ってます)
とりあえずAndroid用アプリでも作っときなさい。 今はその方が使ってくれる人は多そうだしな。 GUIも問題なし。 そうでなければGUIなしの主にサーバ用プログラム作るかかな。 GUIはクライアント側に任せる。クライアント側は何でも良い。
一つのことにこだわって新しいことの習得がおっくうになるのは老化してる証拠
そうだな。ボケ防止にもなるから新しいことやった方が良い。 ただしボケ防止の場合は完璧な状態になる必要はない。 学習を続けるという脳を使い続ける行為が重要なのであって、完璧になってゴールしてしまったらそこで学習が終わってしまうからだ。
>>959 尊師のお言葉にもあるけど、経験値が増えるにつれて、わざわざ自分で使い込んでみなくてもある程度わかるようになってしまうんだよな
Kotlinなんてまさにそうで、Javaに十分精通してる人なら「ああ、記述をライトにしたAltJavaね。機会があれば使おう。」で終わり
Javaで出来ることをKotlinで書くだけだから普通に出来るでしょ まあそもそもデスクトップアプリをJavaで作ること自体あんまりおすすめしないけど
まあそのうちnativeできるし、何かできるんじゃなかろうか。
>>962 確かに老い先短くなると、学習する期間で縮む余命の方が、残りの余命の間に得られる利益を上回るよね。
>>965 余命の問題だけじゃないけどな
・この程度なら必要になったときにググれば十分だ
・類似技術を習得済みだから最悪でも今持ってるスキルの範囲でカバー可能
経験を積めば大抵こうなるから、わざわざ使い込んで試す利益は限りなく低くなる
少なくとも触らないで理解した気になってる奴は成長しない
Kotlinに慣れてくるとJavaに戻る気は失せてくる。 型推論とか色々とコンパイラが面倒見てくれるから楽だ。
C#も型推論とかあるし、Kotlinが出来るなら、 学習コストは少ないだろ
最新のJava使えるなら型推論あるし、javaでもそこまでいらいらしなくったな。
Kotlinは言語としてとてもよくできている、しかし現実的な用途がピーキーだ おすすめできる人 ・現在Javaでプログラミングしている人 おすすめできない人 ・まだJavaでプログラミングしていない人 「いまからJava勉強してアプリとかサービスとか作ろうと思うんです」という初心者の人がいたらアホかやめとけと言うと思う それはKotlinにも当てはまる 「いまさらJavaで作らなくてもいいぞ」という進言はJavaの文法の小難しさというより周辺の環境を考慮しての物言いなはずである KotlinはJavaの環境のJava文法部分を変更するもので、たとえばJavaでのゲームGUIのつくりにくさや外部ライブラリの面妖さを変更してはくれない 「いやあちょうどJavaでプログラミングしようかと思ってたとこなんですよ」という人がたまたまいたならもう全力でおすすめできるのだが
Scalaとかいう意識高い系の先輩を倒したと思ったらまさか大地主様に後ろから殴られるとはな
確かに今現在Java使ってるやつには折伏したくなるがプログラミング初心者ですって奴にJVM言語は勧められないな
もともと、既存Javaユーザーを救おうというのがコンセプトっぽいしなKotlin
>>979 本当にまったく何もわからなければC#(とUnity)
なにか新しくてそれなりに作れる言語やってみたいとか骨のあること口走ったらGo
みんなと同じがいいのならPython
Androidはkotlinかdartになりつつある
Androidアプリ作りたいって初心者は多いから、普通にコトリン勧めるよ。 そこで慣れていく頃にはサーバーサイドKotlinももうちょっとはメジャーになってるだろうし
慣れていくが潰れていくに見えて 厳しい世界を海馬見た
Androidはデザパタ強制的に叩き込まれるから初心者にもいいと思う
理論上最速って理由でC++に挑んで潰れてく初心者は大勢見た
理論上はVM言語が最速でしょ 実行時の統計に基づいた最適化が可能だから
どんな最適化してくれるかに掛かっていると言える。 その辺の自由度はあまりない。
Javaだと1週間かかっていた機能追加が、Kotlin移行後は2~3日でできるようになりました。
――工数が半分以下に減ってるんですね……! Android版Yahoo!ニュースではまだJavaを使っている部分もあるかと思いますが、今後Kotlinへ完全移行する予定はあるのでしょうか?
https://employment.en-japan.com/engineerhub/entry/2018/12/07/110000 今プログラミング始めるなら最初はWeb公用語のJS(TS)からでいいよ
>>989 プログラミングすることだけが目的の勧め方じゃないですかァー!
>>990 何作りたいのかまったくヒアリングできないのならJSでもいいような気がする
実はiPhoneアプリ作りたいんでしたーでもなんとか…なんとか…いやどうだろう、なんとか
1000への道はKotlinで敷き詰められている。
このスレッドは1000を超えました。 新しいスレッドを立ててください。 life time: 147日 17時間 2分 20秒
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
read.cgi ver 07.7.23 2024/12/25 Walang Kapalit ★ | Donguri System Team 5ちゃんねる
lud20250323085517caこのスレへの固定リンク: http://5chb.net/r/tech/1531818027/ ヒント: 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「Kotlin 4 ->画像>1枚 」 を見た人も見ています:・次世代言語15 Go Rust Swift Kotlin TypeScript ・次世代言語議論スレ[Rust Kotlin Haskell]第6世代 ・次世代言語17 Go Rust Kotlin TypeScript Julia ・次世代言語14 Go Rust Swift Kotlin TypeScript ・次世代言語13 Go Rust Swift Kotlin TypeScript ・次世代言語15 Go Rust Bosque Kotlin TypeScript ・次世代言語9[Haskell Rust Kotlin TypeScript Dart] ・【IT】Kotlinで開発された初のAndroid向け不正アプリが発見 ・Kotlin 7 ・Kona Linux 4杯 ・【Kotlin】Compose Multiplatform 1 ・【乞食コイン】KOJIKI COIN 4【KIZUNAスワップ】 ・次世代言語25 TypeScript Swift Go Kotlin Rust Nim ・次世代言語22 Go Nim Rust Swift Kotlin TypeScript ・次世代言語29 TypeScript Swift Go Kotlin Rust Nim ・Seattle Mariners Vo.1150 ・Seattle Mariners Vo1152 ・Seattle Mariners Vo1159 ・ゲイが語るEvery Little Thing ・【◆BREITLING ブライトリング 総合78◆】 ・Every Little Thing総合雑談スレッド-225- ・進撃2Final Battleのアマゾンランキングwwwwwwwww ・BREITLING ブライトリング エアロスペース 総合2 ・【FREEDOM LAND】JACKS'N'JOKER【INSIDE OUTLAW】 ・【BATTLE AGAINST】LOVEBITES Vol.①【DAMNATION】 ・【秋の両国】新日総合スレッド1966【KING OF PRO-WRESTLING】 ・Outlast 2のNintendoSwitch版が海外で発売!!!XboxOne版との比較動画が完全に間違い探しな件w ・【ゲーム】『ポケモン』新作、Switchに登場 2018年以降に発売 他Switch向けゲーム情報あり「Nintendo Spotlight:E3 2017」 ・【●】KINOKOCAKE【●】 ・【KOK】KING OF KINGS 17 ・真夏の夜の淫夢.seinoyorokobi ・真夏の夜の淫夢.Princess Mako ・【 カミコベ 】Comin' Kobe ・【NEC-HE】PCエンジンmini ★14【KONAMI】 ・【KOF】THE KING OF FIGHTERS ALLSTAR part9 ・【KOF14】THE KING OF FIGHTERS XIV Part163 ・【KOF14】THE KING OF FIGHTERS XIV Part151 ・【KOF14】THE KING OF FIGHTERS XIV Part141 ・【KOF】THE KING OF FIGHTERS ALLSTAR part1 ・【KOF】THE KING OF FIGHTERS ALLSTAR part41 ・THE KING OF FIGHTERS ALLSTAR part60【KOF】 ・【KOF】THE KING OF FIGHTERS ALLSTAR part15 ・【KOF】THE KING OF FIGHTERS ALLSTAR part45 ・【KOF】THE KING OF FIGHTERS ALLSTAR part32 ・【Yokocho coin】横丁コイン 3軒目【バル横丁】 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part237 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part135 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part226 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part136 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part127 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part170 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part231 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part185 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part245 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part162 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part210 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part112 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part222 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part180 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part146 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part132 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part154 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part142 ・【KOFAS】THE KING OF FIGHTERS ALLSTAR part151
08:20:47 up 55 days, 9:19, 0 users, load average: 7.41, 8.00, 8.29
in 1.5189650058746 sec
@1.5189650058746@0b7 on 061121