◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ: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{
>>6 何がしたいのか全く分からない。
var a = Aの部分は何をしたいの？
>>6 もしnull許容型にしたくないって意図なら
lateinit var a: A
にするとか
探索のnodeを作っていまして
それなら普通に
それと質問するときは差し支え無い範囲で実際のコードそのまんまの方がいいよ
>>6 それ var a = A って書いてる？
コンパイルエラーにならない？
あー、var a = A()になってそうだな
よくわからんが class A(val a: A) じゃいかんのか？
あ、だめか。class A(val a: A?) じゃないと永遠に初期化不能かw
これおもしろいな、aをnull許容型にしないとインスタンスできないだろ
試してないけど、nullobject用の派生クラスを用意して、nullobjectのaにはthis代入すりゃいいんじゃない？
>>12 で出来ました
ご迷惑おかけしました。ありがとうございます
他の言語だと、自動でnullが代入されているから、詰まってしまった
これはと思い階乗計算してみたが、微妙…orz
>>20 おっと、いろいろ混ざった。
?と:は消して
>>19 そこ(Nullableと非Nullable)がことりんの最大の特徴だから、ぜひちゃんと理解して使いこなしてあげてね。
intellij入れたんだけど
>>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 状況がよくわからないからそのエラーが出た時のスクリーンショット取って見せて。ソースが表示されてる状態のな。
みなさん回答ありがとうございました
あ、そこまで頭回らんかった
今更、LinuxベースじゃないOS作ったから使えよ！って言われて流行ると思う？
Kotlin は今はとにかく JavaVM で動くコードを出すコンパイラで Android 開発で使って貰って
JavaVMなどの他の環境の寄生をやめるなら基本的なクラスライブラリはどうするんだ?
ごめん。寄生やめるって話じゃなくて今はとりあえずandroidに寄生してその間に広めてその後は他の寄生先見つけりゃいいって話しかな?
寄生しても良いし、根底から全部作っても良いが、とにかく生き延びる率は非常に高いと思う。
Kotlin良い言語だからもったいないよな
JavaFXをKotlinで拾ってくれないかな？
>>40 対応言語にKotlinじゃなくてSwiftが入っているというのが、危機感を刺激される。
>>48 ぜひそうなって欲しい。
なにこれ、最近kotlin始めたばかりなのに終了かよwwww
Fuchsiaが普及するとしてもその頃にはKotlin/Nativeも出来上がってるでしょ
まぁ、でもnull safetyを存分に味わうにはkotlinが標準クラスライブラリを用意してくれるのがいいんだけどね。
>>53 これあくしろよ
ファイル周りぐらいでもやってくれ～
>>51 現状でも、言語仕様を一つ修正するのにJVM, JS, Nativeの3通りの変更が必要になる。
この上、Dartのサポートとか、なんという無茶振り。
>>53 せめてnull safety対応generics欲しいよね。
できるそうだがやったことがない・・・やればいいんだなw
遊びで触ったことあるけど、メリットを何も感じなかった。
サーバーサイドで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に近そうねｗ
>>72 確かにJavaに似てるけど、あれは普通のJSの拡張みたいなもんだから使いやすい、というか既にめっちゃ使われてる
>>73 KotlinよりTypescriptの方が流行る?
TSからJS呼ぶときに戻り値の型意識しなきゃいけないことにイラつく感覚がKotlinからJava呼ぶときにnull意識しなきゃいけないときにイラつく感覚と似ている
てか、CとTypescriptとその他を比較する意味あんのか？
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安全のために記述が長くなるってのもよく分からんな
>>88 そうするとGoogleのAndroidのような面倒な問題を抱える可能性があるのでは？
素直に OpenJDK 使っといた方が良いと思うのだが。
RedHatがOpenJDK11を独自にLTSするらしいから、RedHat系のディストリビューション使ってるなら大丈夫だろ
null安全のせいでコードが長くなるのは
>>95 これを機にWndowsServerなんてカスは滅ぼそう
>>97 GitHub見てこいよ
アレをプロダクトで安定して使えるようになるまでまだまだ先は長そうだぞ
>>87 val map = HashMap<String, 抽象的な何か>()
map["hoge"] = "文字列"
map["fuga"] = 100
val str = map["hoge"] // :String
val num = map["fuga"] // :Int
みたいな感じで
とにかく型チェックやらキャストやらが面倒くさい
実際には自作クラスとかも突っ込みたい
試してないんで適当言うけど
>>99 型チェックなしだと取り出した変数が何型になっているかわからなくて結局扱えないのでは？
すまん伝わりやすいかと思って抽象的な何かって書いたけど語弊があるわ
マップに値を突っ込む人は中身の詳細を知らなくて、値を取り出す人はどのキーに何が格納されているか知っているようなシチュエーション、例えば設定ファイルのローダーみたいな奴への適用ならわからんでもない。
何に使う気かっていうとJSFでFlushっていう画面間で値渡すためのMapがあるんだけど、型チェック面倒くさいしチェックしないのも嫌だしでいっそ別に用意できないかと思った
XMLなりで文字列化しといて使うときにデシリアライズすれば？
keyごとに型が決まってるならjson文字列にしておいてGson使って取り出すとか
>>106-107 のやり方が使うときにはスッキリできそうだなぁ
>>108 二つ目のやつって色々出来そうに見えて汎用的にならないのが惜しい
よく調べないで書くけどMapでしか渡せないならMapの値にクラス突っ込めないの
普通に data class 書くかイヤなら動的型使え案件だな
動的型付言語でもMapから取り出したインスタンスに何かするにはそのインスタンスの型のチェックは必要なんだから、
一回シリアライズするとか正気かよ。
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
ただのキャストよりコード量が増えて危険な操作であることがわかりにくくなっただけやんけ
全然関係ない話
>>137 マジか、知らなかった。
まあやることはあまりないだろうがw
{}の中はプラグラムのコードやからな。
一番内側のデリミタが来るまでは外側のデリミタはマスクされて見えないという話
むしろコンパイル時じゃなかったらビビる
unit testしたいんですが
operator で何も返さない Unit のやつを作るとどうなるかを実験していて気づいたこと。
例えば plus() って + 記号が出てきただけで呼ばれるわけで、そうなると + 記号だけで中身を書き換える事も可能になるんだな。
https://paiza.io/projects/wtY0TgCLyLhRsls2-6wcuQ >>149 これができるのなら Unit ではない演算子の結果を捨てるような式はエラーにして欲しかった。
JetBrains のサイトに StringBuilder.set メソッドのドキュメントがない事に気づいた。
JavaFX+Kotlinでクロスプラットフォームのアプリ作ろうと思ったけど、
竜巻外為良さそうだけど、そもそもJavaFXが流行ってない気が
現時点で流行ってないし、java自体がこの状況で今から人気が出てくるとも思えないよなあ
TornadoFX良かった。JavaFXが切り離されさえしなければ...
トーナードは良いものだよ。
tornado の発音はトーネイドに聞こえるが・・・
なんでJavaFXって人気ないの？
>>160 なんでって、Javaだからだよ
有史以来、FXに限らずクライアントJavaに人気があったことなど無い
javafxscript用の設計だったからね
アンドロイドせいで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もいい言語じゃねぇけど、JSよりかはましだからな。flutter人気でてdart使われるようになったら、dartのchromeブラウザ搭載計画を復活させて欲しい
wasmにDOM/GCが搭載されれば色んな言語からの需要があるだろうしそれほど夢物語でもない
Chromeだけ動くようになったとしても他のブラウザが追随して、かつそれ以前のバージョンが駆逐されるまで待たないと実用できないからな。
TypeScriptという手軽でまあまあなソリューションが広まって、なんかもういいんじゃねという空気だよね
プログラミング言語は素晴らしいから広まるんじゃないのだということを我々はこの30年でイヤというほど味わったのでるふぁい
WebもアプリもKotlinよりTypescriptだろうか
まあそうだね
Kotlinは贔屓目でもなんでもなく、Java環境で動く素晴らしいJava代替物なのだが
一年前のだけど興味深いディスカッション
なぜ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/ 言っちゃ悪いけど、開発言語を前提にして物事を考えるのってエンジニアとしてはだいぶ低レベルな段階だよ
仕事と趣味は別という発想が出てこない君はエンジニア以前に社会人としてとても低レベルだね
営利利用されない技術は進歩しないから、たとえ趣味でやってる人も離れていくもんだよ
>>196 そうかな、個人でやる分にはC++でもObjCでも構わないけどそうじゃない環境では
記述性などの他に学習コスト/人材調達的にも
Kotlinはバランスの良い言語だと思うんだけどな
仕事でサーバサイドkotlin使ってるけど今後はOpenJDKにするかもだって
え、むしろ今までOracle使ってたん？
なんだかんだJDKの混乱も今だけだとは思うけどな。
>>202 JavaFXしたかったんだ.....
公式にJavaFX使うならOracleJDK使えって.....
OpenJDK9には統合されると思っていたら、ご覧の有様だよ.....dayo.....
>>204 >公式にJavaFX使うならOracleJDK使えって
初耳だ…
そもそもRedHatクローン使ってればOpenJDKでなんの差し支えもないからな、数ヶ月前みたいな絶望感はない
>>205 今見ると書いてないな...
記憶違いかもしれないが、今となってはどっちでもいい....orz
情報が錯綜して勘違いやデマ流されたりするのが今のJavaは良くないな
>>> println("ちん${"ピョロ${"す${"ぽー"}"}"}ん")
まさかJavaよりJavaScriptが主流になる日がくるなんて・・・
>>210 そもそも担当言語で同僚を見下すこと自体人として終わってるから悔い改めるためにXamarinのライセンス買ってこい
>>210 その当時の JavaScript と今の JavaScript は同じか?
>>214 同じだよ。
JavaScriptの有用性に気付いたグーグル先生がGoogle Mapを作ってから流れが変わった。
JavaScriptはブラウザで動くからあの立ち位置にいるだけで基本的にはうんち言語
>>217 Javascriptがブラウザで動かなければ、多分Node.jsは生まれなかった。
あれ? ここJavascriptスレだっけ?
ES2018まで至った今としては至極平凡な言語
それがブラウザでそのままネイティブに動けばいいのにな
コンパイル型言語は対象が何であれコンパイル要るし
フロントエンド周りは一時期進化のスピードが狂ってたからな
おまえら数日前にやってたJetBrains様の半額セールにお布施した？
>>215 ああ。Ajax とか。そういう言葉が作られたぐらいか。
そういや XMLHttpRequest 自体は1999年からあったんだよな。
そもそもブラウザソフトは時代遅れ
初めてアンドロイドのアプリ作る人がいきなりことりん使うのは無謀？
プログラミング自体が初めてならJavaからの方が良いと思う
プログラミングはc、java、pythonに少し触れたことがある程度です
Kotlinでいいと思うよ。そのレベルならJavaの余計な煩わしさに振り回されない方がいいと思う。
IT業界に入らないならJavaなんて一生触らなくていいぞ
あるプログラミング言語がドイツ製でドイツ語でしか解説が書いてなかったとするじゃん
Javaは書けなくてもいいけど読めないと辛い
初心者に言わなくてもいい余計な情報を山ほど叩きつけて混乱させる悪習がここでも、、
まずこの本を3回読んで、オブジェクト指向を学ぶ
Kotlin使ってる人はJava10年選手とかで初心者のこと全然思い出せない人ばかりだからな
結局、開発を始めると、言語の部分は関係ない
少し触れたことがあるっていうのがどの程度かわからないけど、自力で小さなツールスクリプトを2,3作ったことがある程度なら
Android界隈ではまずはJavaからおじさんが闊歩し始めてるのか
ジェネリクスあたりでわからなくなるとは思う
初心者がとりあえず何か書いてみるって段階ならジェネリクスなんて存在自体知る必要もないのでは
さすがにそのレベルだとオブジェクト指向で詰まるでしょ
C#なんかも初学者お断り言語として誕生してそのまま普及して今に至ってるわけだし、
誰か初心者向けのJava抜きでも大丈夫な入門書書けば良いのでは？
>>247 書く能力のある人はいるかもしれないが、それだけの時間をつぎ込める人はまずいないと思われる。
232です
>>250 ご覧の通りここだとみんな好き勝手なこと言って申し訳ない。
ぶっちゃけどちらで書いても大差ないから、両方軽く見てみて自分がやりやすそうだと直感した方でいいよ。
>>249 いやもう夏休みの長い学生とかでも良いんだけどな。内容がまともなら誰が書いても構わないわけだし。
まあ学生はおすすめだな。後で就職する時に自慢げに言えるぞ。
変に期待され過ぎて後々おかしくなるかも知れんがw
>>254 数年後だろうからそれはわからない。
まあでもどんなものでも技術系の本書きましたってのは例えAmazonで電子書籍出しただけでも思い切り自慢して良いと思うけどね。特に学生なら。
本までは出さなくてもいいけど、そこらの勉強会に行ってLTしてるだけでも評価上がるわ
>>247 それは中身としては「Javaの小難しいとこを初心者向けに解説した良書」という存在の難しい書物なのでは…
Java習得している人の説明は、
読んだことないけどkotlinで書いてるAndroid入門本出てたろ？
まあでも新OSの噂を考えたら、Flutterもキャッチアップしておいた方が良さそうだよな。
自分もjavaとばしてkotlinやってるんだけどgradle使おうとしたら結局java必須なんですかね
次のアプリは既にflutterで開発中だわ。dartは確かにクソだけどflutterの出来がいいから俺はdart+flutterに移行するわ
kotlinで作ったアプリは結局一つだけになりそう
ネイティブの実装を意識しなくちゃいけない時のためにネイティブで一つは作っておいた方がいいけど、
まあ後発だけあって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 太郎本よりインアクション１冊持ってればいいよ
太郎本は入門時ぐらいしか役に立たないけど、インアクションは後々役に立つ
高いけど
progate に、Kotlin は無いのか？
>>295 polcaとかで募集してくれればカンパするけど、2ちゃんで晒すのは辛いかw
2933です。
この言語があればJava使う機会なんてなくなるの？
>>302 Yes. ただし、Javaしか使っていない会社などからJavaでやるように指定があった場合や、
過去にJavaで書かれたライブラリのソースコードを参照したり修正したりする必要があるような場合などは
はその限りではない。
Oracle JDKのライセンス問題で、Kotlin関係なしにJVMごとJavaを使う機会がなくなるのでは
というのが目下の懸案だけど、JDK 11のリリースされる9月までにはなんらかの発表があって
目処がつくと信じたい。
>>302 今の所 Java VM 上で動かす方式が優勢なので使うと言えば使うなあ。
ただその内 Kotlin native が出来るので、そうなると Java VM 不要なので使わなくなると言える。
Kotlin nativeはJavaのライブラリ使えないんだろ？
>>305 今色々とライブラリ用意してる所なんじゃないか?
それとC言語用のライブラリとか、他の言語のライブラリも使えるようだぞ。
http://blog.64p.org/entry/2017/05/19/005703 まあ、nativeなら使えないわけがないとは思うが。
google的にはkotlinも捨ててdartに行くつもりなのか
>>302 将来的にはYes
現状はNo
JDKがないと使えない
>>307 本命はwasmでしょ
flutterはgoogleによくある戦略外のお遊びプロジェクトで、すぐ消えるよ
flutter程度のお遊びプロジェクトは様々な団体であちこちで生まれては消えてを繰り返している
そう思う根拠を教えて
だいぶ色の違うプロジェクトではあるけど、最近だと軍事AIドローン開発の大プロジェクトが中止されたね
いや、だからgoogleのプロジェクトのうち長く続くものとそうでないものにどういう違いがあって、
FlutterはAndroidから噂の新OSへ移行するとしたら絶対必要になるけどな。
新OSはまぁ、あんまり期待できないな。マイクロカーネルっていうアーキテクチャは面白いとは思うけど
この間Javaの入門書買ったばかりなのにこんな良さげな言語があるとは…
Javaの入門書やるレベルならまずはそれを終わらせたほうがいい
これからJava離れ、あるいはJVM離れが加速するかもしれないのにJavaデビューとは
>>317 未読のまま売ろうかなって思ってたけど読んだほうがいいかな
C言語をしばらくやってたからOOP何それ？とはならないけども
>>318 今大学三年なんだけどIT企業への就職を考えてる
もしIT業界で戦うための勉強だとしたらKotlinなんて知らないほうがマシ、っていうのはどういう意味？
>>320 Kotlin使える現場なんて少ないからな
ただでさえJava書いてるだけでストレス溜まるのにKotlin知ってたら「このコードKotlinなら・・・」って余計ストレス溜まるぞ
そもそもIT業界への就職はやめとけw
まぁ、肌に合わなかったら辞めりゃいいやって甘い考えは捨てた方がいいかもな
ある程度自力裁量のあるプログラミングを業務としてやりたいというのなら、プログラミングの勉強ではなくIT業界研究に時間を割くべきだね
>>324 その言葉を学生の頃の俺に聞かせてやりたいよw
windowsで仕事してるIT企業はブラック
本当はLinuxにしたいけど、GUIツールが貧弱すぎるのとiOSもやらないかんからやむを得ずMac使ってる。
Linuxを選べるIT企業はホワイト
>>333 めっちゃ分かる。
何使っててもいいけど、自分で選べるかどうかが1番大事。
>>328 おまえがキモマカーだということはわかった
強制というか、作ってる製品のサーバ側が Linux だからサーバ側に配属されたら Linux になるってだけのことだな。
有料でもいいからリッチなLinuxのGUIが出てこないもんかね
>>338 Linuxはそういうとこが弱い印象
MSにしろAppleにしろ素人集めて
UI使わせてどこで迷ったとかこういう動きした
とか実験して参考にしてるみたいだけど
Linuxは個人の趣味だけで作ってそう
よくLinuxは普段使えるGUIソフトが全然足りないと言われるけど、そもそもGUI自体が貧弱だから当然っちゃ当然だわな。
LinuxにGUI求める奴はLinux向いてないからMac使った方がいいよ
そうだねえ。
>>344 はまさにその通りなんだけど、
みんながみんなそれを言ってるからの現状なんだろうねw
Macはパッケージマネージャがクソすぎるからなあ
>>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
Windowsが好きなら黙って使っとけよ
MacはBSDに綺麗な服着せて見た目かっこよくしただけだからな
>>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のリソースがそこまで足りてないんだろ
>>385 ほんとそれだけが地獄だよな。
flutterは良く出来てるけど、Dartが辛すぎるww
リソースないならJS切り捨ててNativeに注力しろよって思う
JBって未だに正式なJavaの認証のないグレーなOpenJDKを配布してるよね
そのうちなんとかなるだろう。
Javaは仮想マシン使ってクロスプラットフォーム対応ってのが新しいと言われて普及したけど、それも今は昔
PWAねえ
でもflutterって現状sdkってより只のUIツールキットだからな。だからfuchsiaのOS提供機能のAPIが別に用意されてそれは他の言語から自由にアクセスできるんだろうし。
>>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を再入可能なんていう訳がしっくりこないが
もう一つ違和感の原因に思い当たったのだけど、
違和感といえば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 は結構愛されて求められてるね。
今まで色々な言語使ってきたけど、ことりんは凄く気に入ってる
>>437 ほんそれ。Kotlinにガッツリ打ち込みたいけど、JVM自体がリスク因子になっちゃってて
Kotlinは良い言語だよ、本当に良い言語だ(Dartを書きながら)
KotlinはnativeかJSのどっちかに注力しないとJVMに引きずられて消えてく気がする
そもそもKotlinは、なぜJVMで動くのが前提で作られたのか
そりゃJetBrainsの客層を考慮したら当然でしょ
kotlinってGoogleと協議とかなしで作り出したん？
Googleと協議してたらクソ言語が出来上がってただろうね
Scala挫折組が低機能Scalaとして開発始めたんだから当然JVM言語
>>445 ネット見てるとPycharm使ってる人多いように見えるけどこれは無料版かな
いま結構大手メーカーに出稼ぎに来てるけど、JS書くのにWebstormつかつてたわ
WebStormはVSCodeの台頭で完全に死んだな
VSCode使いやすすぎてヤバい
VSCode良いけど、IntelliJが完全に上位互換といって差し支えないからなあ
TypeScriptならWebStormのリファクタリングがJavaとかKotlinと同じぐらい奇麗に処理してくれそうなんだよね
>>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使おうって環境がどうかと思うけどな
そもそもデフォルトでemacs入ってるディストリビューションってまだあるの？
>>462 おう、昔はPC-UNIXのディストリビューションにデフォで入ってたみたいな言い方はやめろや
今も昔もEmacsは選択インストール対象だ
>>460 emacsを体で覚えてしまった人は似たようなものでemacsが動く環境ならそれで全てができてしまう状態なんだよ。
だからそう簡単には離れられない。
かれこれ20年以上Emacsを使っている
まじでemacsはおっさんしか使わないわな
オペレーションマニュアル作る時にesc-x shell は便利
Kotlin使ってるくせに 静的言語+IDE じゃない組み合わせでコード書くとかありえないっしょ
>>467 最近はVimでもVSCodeでも出来るらしいですよ
emacsは30年前から出来てたけど
うわあ、めんどくさいemacsおじさんがこのスレにもいる
エディタなんて使う必要ない Kotlin スレで延々とエディタの話するとかありえないですよね
Kotlinは良い言語だけど、JDKに起因する虚無感が漂っててネタがないので、エディターとか他の話で盛り上がってしまう
Kotlin書くなら現状IntelliJ IDEA以外の選択肢はないと思う
めんどくせえから vim で Kotlin 書いてる
めっちゃ効率悪そう
>>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とかで十分
だよな。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学ぼうと思ってたんだけど、様子見たほうがいい？
>>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の文法はもう古い
android無視すると逆にそこまでkotlinである必要もねぇんだよな。
どちらかというと純Javaでなければならない理由を考えたほうがいい
>>529 TypeScriptの流行なんかも含めると時代はKotlin風というよりC#風かな
ベースとしてC#にインスパイアされたちょっとLightweight&FunctionalなC系の流れの本流に近く、
その中では比較的Ruby系に似せた仕上げのなされた言語と位置付けるのが妥当
まあどんなに少なく見積もってもあと5年以上は生きてるだろうから別に今から勉強しても損にはならない
今後は、Nativeなアプリ開発はSwiftに、JSのアプリ開発はTypescriptに、JVMのアプリ開発はKotlinが主流になるよ
時代に全くついていけてないオッサンか、最近そこらへんのことを知ったばかりのど初心者かどちらかだろ
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は廃れるのは間違いないのだがさて何年かかるかって話だな
>>555 ICS前？確かにショボかったけどそんな風潮だったの？
良くも悪くも一寸先は闇だ。
Javaオワコンだなんてこれまで何度言われ続けてきたことか
>>551 自分でWebって言ってるのにクライアントサイドのことしか頭にないのはなぜ
>>561 なんとか揚げ足を取りたい気持ちはわかるが561はどう見てもサーバーの話してるだろ
Javaっぽいなにかを使ってるSalesforceは廃れてほしい
仕事でSalesforce使ってるけどうんこオブうんこ
俺は触ったことないけど、トラウマレベルのゴミだと聞くな、salesforce
>>562 Node知らんのだろ
そっとしておいてやれ
まあJVM使わなくなったとしてなぜ置きかわり先をNodeに限定してるのかは謎だけどな
ここはXamarinスレなんだから脱JVMなんて言わずにサーバーサイドkotlinを粛々と語るべき
Javaで書いてコンパイルしてclassをJVMで実行
Nodeは一時期ソシャゲのサーバーサイドなんかで広まりまくったけど、
>>568 みたいに、ここはXamalinスレとか言ってるやつって、それが面白いと思ってやってるのかな。
認知症のジジイが、同じこと繰り返してるような痛々しさしか感じないんだが。
>>572 みんなそう思いつつもスルーしてやってる
それがエンジニアの優しさってもんだw
>>577 前々から疑問なんだけど
Xamarinは糞とか言うけどC#が糞とは言わないよね
ここはKotlinて言語のスレなんだから合わせたら？
まあスレチだから書き込まないでくれると助かるんだけどさ
じゃあKotlinの話題振れや
>>578-579 なんでそんな攻撃的なんだお前らは
黙ってスルーしてりゃいいのに
>>583 FlutterでDart使うと、セミコロンのうざさがわかると思うよ。
FlutterはKotlinの言語仕様と相性がいいのにDartなんだよなー。
まあKotlin名指しの需要はないよね
いやいやAndroidアプリの求人はKotlinだらけだろ
KotlinだからってKotlin経験者に限定して求人する必要は全くないだろ
むしろKotlinに限定してJava触ったこと無い奴来たら困る
>>594 「覚える」がどの程度のことを指すのかが不明確で釣りっぽいが、短く答えるなら、
覚えられるが、実用段階でJavaを知ることになるだろう
と言ったところか。
アプリからライセンス情報確認してみたが、
>>597 前々から疑問に思っていたけど、JVMやJSのKotlinのランタイムライブラリは
Apache 2 licenseだから、製品に含めるときにNOTICE.txtの表示は必要?
ScalaはBSDライセンスだから不要だと思っているんですが。
bsdなら表示しないと駄目だろ。binary も対象って明示されてる
俺は他のライセンスとまとめて書いてるよ
>>599 スマン。三条項BSDライセンスに宣伝条項がないという記述の意味を勘違いしていた。
でもランタイム同梱はライセンス条項の適応を受けるという解釈は
>>598 であってます?
もしそうなら、Javaで作ったものには特に著作権表示がいらないけど、
Koltlinで開発した場合は(実行環境にランタイムがインストールされていない限り)
ライセンス表示が必要ということになると思うのですが。
そんなことよりKotlinがApacheライセンスであることの最大の問題は、GPLv2と互換性がないことだぞ
>>603 Apache License 2.0がGPL2.0と互換性ないのは普通に事実だぞ
https://www.apache.org/licenses/GPL-compatibility.html Kotlin製のソースをGPL2.0で配布しようとしたら、ランタイムライブラリをGPL2.0で提供できない限りGPL違反
ライセンス周りのことになるとこういう頭のおかしい拡大解釈する奴が必ず出てくるよな
拡大じゃない解釈を教えてくれよ
俺が予想した通りの返答をありがとうw
>>602 > クラスパス例外を外して配布されたOpenJDK
この前提がおかしいのでは? 仮にあったとしてもクラスパス例外を外さずに配布されたOpenJDKを使うべき?
> OpenJDKと同じGPLv2クラスパス例外ライセンスを適用して配布したりすることもできない
Apacheライセンス、GPLv2クラスパス例外ライセンス、BSDライセンスを
各部分に別々のライセンスを適用しつつ配布するのってだめでしたっけ
>>604 KotlinがGPL2.0になればNOTICE.txtの表示は不要になる?
ライセンス周りはそこまで詳しくないので、おかしなことを書いていたらそっとご教授下さい。
非互換なのは正しいけども
>>606 ソースを配布するのかバイナリを配布するのかで全然話が変わると思うが、
お前の一連のレスの中でそれが混在してるから話がめちゃくちゃになってる。
非互換なのは確かに正しいし常識なのも正しい。
>>608 GPL2.0クラスパス例外とApache2.0とBSDを混ぜて配布することは可能
ただしその場合、再配布時には決してクラスパス例外を外してはいけない
Kotlinのランタイムライブラリをシステムライブラリだと主張するのはさすがに無理筋
少なくともKotlinでGPLv2なプロダクト(GPLv2のライブラリをリンクしただけのものも含む)を開発するのは不可能なわけで、
GPLv2のkotlin向けライブラリは存在しないし
>>614 だよな、上のやりとりを見ててそう思った。
自分で勝手に例外条項つければそれで終わる話。
>>615 Oracleが保身のためにクソみたいなライセンス形態にしてるのが悪い
最初からWTFPLライセンスにしておけば何も問題ないのに
OpenJDKのライセンス決めたのはSunだけどな…
オラクルなんて大抵の開発者には嫌われてるからしょうがない
>>619 現在は企業が(「ソースのリリース」ではなくOSSベースで開発する目的で)OSSを公開するときはMITライセンスを採用するケースが多くなったけど、
当時はそこまで緩いライセンスを採用することはあまり一般的ではなかったからなあ
Javaのみで開発したJar: Javaのランタイムはシステム側にあるので、ライセンス表記不要.。
お前らの作る糞アプリがライセンス違反で訴えられるようなことはねえよ
>>623 今日の昼飯、ラーメンとマクドどっちが良いと思う？
意味不明で草
ライセンス表記なんかで、なんで揉めてるの？
そもそもいつまでもGPLv2なんてクソのままにしてるのが悪いってことだろ
GPLv2とApache2.0に互換がないのはバクみたいなもので
>>629 v3は明示的な特許訴訟回避の規定があるからオラクル的にはNG
ライセンス変更するならソース提供者全員の合意が要る
OpenJDKのコントリビュータ全員にはオラクルにソースを寄贈しますっていう契約書にサインさせてるから要らないよ
>>626 それは概ねその通りですが、Kotlinを使用したことを記載したくない場合でもそれが認められない
というのは、マイナスポイントかと。
>>635 そういう人がいればそうだね確かに。
もっと別に表記して問題が起きるわけじゃ無いし、それをマイナスポイントと捉える人はあまりいないと思うけど。。
何にせよライセンスは変わらんから、気に入らないなら
せやな。そもそも他人の著作物をただで使わせてもらうんだしな。
商用でも非商用でも、使用したものを隠さなくちゃいけないことはそうそう無いだろ
ライセンス表記いやなら全て自分でつくればいいだろ無能
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を避けてjavaで作ろうとしてもapache commonsとか使いたくなることもあるだろうに、それら全部回避してわざわざ自作するのだろうか
Androidなら何れにしてもほとんどはappcompat-v7を使うことになるのでは？
個人的には、
>>598 以降書き込んだ人全員がKotlinで開発したものに
Apache 2 licenseとNOTICE.txtの表示をつけていることが確認できればそれでいいです。
もとは
>>597 でKotlinを使っているアプリには必ずライセンス表示がある(はず)ということを確認したかっただけですし。
＞個人的には、
>>598 以降書き込んだ人全員がKotlinで開発したものに
＞Apache 2 licenseとNOTICE.txtの表示をつけていることが確認できればそれでいいです。
？？？
何様のつもりなんだこいつは
一方的に話を打ち切る前に、なんでkotlinの使用を断念するほどライセンス表示が嫌なのかの理由を教えてくれよ
>>657 >>647 で回答済み。
>>648 を読んですぐ眠りにつかれたようで何よりです。
>>656 Apache 2 licenseとNOTICE.txtの表示をつけないとライセンス違反になるのなら、
皆が違反していないと確認することはむしろ善行であると思いますが。
>>658 お前がどこの誰だからお前に確認されることに意味があるって言うんだよｗ
>>658 違うって。kotlinだとライセンス表記をしなくちゃいけないことがなんでjavaを選択することにつながるのか、
なんでそこまでライセンス表記を嫌がるのか、その理由だよ。
単にめんどくさいってだけ？
>>655 コンパイラ同梱またはコンパイラの一部ソースを含む場合はNOTICE.txt要るけど
標準ライブラリ同梱だけならNOTICE.txtの方は要らんよ
Apacheライセンスの表示またはテキスト同梱は必要
>>658 様にご確認いただき大変光栄でございます。
弊社で作らせている糞アプリ、また私共個人で作成しておりますゴミアプリに関しては、
いずれもライセンスの種類を問わず使用している外部ライブラリは全て謝意とともに表示させていただいております。
ライセンスをコピペすることがKotlin使用を断念する理由になるほどの手間なのか、、
なんの反論もないところを見るにマジでただめんどくさいだけだったのかな
変化が嫌いな人間っているからな
新しくてよくわからないことをやって苦労するのが嫌なんだろうな。
まあ一応、ライセンスの表記はめんどくさい部類には入るとは思う
>>665 ああそっか、javaを使い続けたいって感情が先にあってそこに理由を後付けしてるのかもな
ところで今日はコトリンが誕生した日です。
>>667 確かにめんどくさいけど開発言語の選定に影響を及ぼすほどの工数じゃないと思うw
今日はハイジャックされたエアベトナム機の搭乗者75人が全員死亡した日です
9月15日は
29歳か
Kotlinを使うことのデメリットはビルドが遅くなる
Kotlinに慣れてしまうとたまにJavaのコードを読み書きしなくちゃいけなくなった時に辛いのもデメリット
そして頭が Java モードに移行した後で String s = "hpge"; がなぜコンパイルエラーなのかと数秒悩む。
Javaとの切り替えは楽だわ、全然違うから。
Goの変数宣言は大嫌い
>>687 微妙に違ってるのが残念
errは使いまわさない
if判定式に書いてとブロック内での利用がGoのスタイルらしいです
普通はGoのイライラポイントは行末にセミコロンが置ける判定だと
>>687 言いたいことは分かるけどそれ実際そんな問題になるか？
つーかコロンがあるとソースが気持ち悪い
書いた本人もsがどこから来たのかわからない。
editTextで複数行入力可能で最大3行まで
>>700 それは Android の話? だったら Android スレで聞いた方が良いのでは?
まあ気長に待てばその内わかる人が来て何か書いてくれるかも知れんけどね。
分かるけどググれば4秒くらいで解決しそうだから教えない
コーヒーを入れた後の出し殻はトイレの消臭剤として有能だ
【審議中】
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
おじいさんはキャバクラへ、おばあさんはホストクラブへ行きましたとさ。
Windows 10 でコマンドラインのコンパイラの新しい kotlin 1.2.71 をインストールして kotlinc 実行したら「アクセスが拒否されました。」が出る。
わかった。kotlin-compiler.exe がウイルスバスターの監視に引っ掛かってブロックされたからだった。
強いて言うならウイルスバスターとかいうゴミをわざわざインストールしてるのが失敗
>>726 かといってウイルスバスターにブロックさせなくても java.lang.refrect.InvoctionTargetException が出て動かない。
そちらではちゃんと動く？
コピペしてもあまり意味ないかも知れないが、Windows にインストールしたコマンドラインコンパイラはこんな感じだ。
今日Windowsで動かしたけど別に問題なかったぞ
そう？同じ1.2.71？Javaの方は10？
情報少なすぎてそれだけじゃ何もわからんけど、
いやしかし Linux にインストールした方はちゃんと動くんだよね。
kotlin.bat
違いが出るはずもないって言っても実際に出てるんだろ。
意味のわからない、bat なんか使うな
>>736 俺じゃねぇw
PowerShellは、起動毎に毎回0.5秒くらい待たされるの我慢ならん。
kotlin-compiler-1.2.71-windows-x64.zipを展開したものを使うと確かになるようだ
>>739 ならない人はそれじゃないやつ使ってんのかね？
>>736 何日もって木曜と金曜にしか書いてないが？
なんでこんなことで苛立つ？おまえ疲れてんのか？
っていうか、-windows-x64なんてのがあるのか。
この子、悪気はないのに周りから嫌われるタイプっぽい。。
>>743 俺も今試してみたけど問題なかったわ。なんなんだろうな。
>>743 よく見たらwindows-x64が付いてないzipファイルもダウンロードページにあるね。
OSごとに分けたから共通のがなくなったのかと思って見てなかったよ。
どうもありがとう。そっちでやってみる。
kotlin-compiler-1.2.71.zip と kotlin-compiler-1.2.71-windows-x64.zip の違い。
さあ。
>>750 使わないんじゃなくて、スキルがなくて使えないんだろ
確かにないよｗ
だから、Ruby をやっておけって言ってる
Gradle, Ruby のBundler, npm は、ほぼ同じ
なんかめんどくさい奴だなほんと
>>757 複数の人を十把一絡げにして一人だと考えてないか？
なお、最初にWindowsのx64版がおかしいと書いたのは俺だ。
rubyはム版に生息してるいつものrubyガイジだろ
あいつ他のスレでも見かけるけど、板中のスレ全部巡回してるのかな
Kotlinではあまりやらないけど、LLだとたまに使う
俺も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 どっちが将来性あるんだろうか
いまモノがあるという時点で後者
俺はFlutterの方が将来性あるし、シェアも大きくなると思うけどな。
>>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 でアプリ書いてるけど
>>804 Kotlin使ってるならObjCじゃなくSwift使えよ
構文とか似てるし
>>804 なんでそんな目に見える苦行の道を選んだのかw
>>806 以前別アプリで使ってたけど型推論あるとビルドクッソ遅いの直ったの？
ちょっとでも欠点を見つけるとそれを理由にして新しいものを拒否するやつってどこの世界にも必ずいるよな
それ以上に、古いものの欠点を過剰に騒ぎ立てて新しいものをゴリ押ししようとする奴のほうが多い気がする
あと個人的な経験でいうと、新しいものの欠点はむしろ検討段階で見落とされて後で問題になることが非常に多い
今ある問題に目を瞑って現状維持に固執するやつは多い
新しいものを受け入れられなくなった時が老化の始まりだと思っている
人は歩みを止めた時に、そして挑戦を諦めた時に年老いてゆくのだと思います。
都合よく自分の使いたいものを想定して一般論を語るのはいけない
自社が製品として販売しているオリジナルフレームワークを自社サービスで使っているせいで仕事を辞めたことはある。
>>814 その新しいものとやらが実際には価値のないものだったら動かない方が勝りますね
重要なのは新しいか古いかではなく、自分の望みを叶える事に使える道具かどうかだ。
>>819 叶えるのに最適かどうか、と言わないとC言語でなんでもできるおじさんがやって来るぞ。
>>820 そういやそうだな。
C、そしてアセンブラ最強になってしまう。
Kotlin の Char には isAlphabetic() がないのな。
直接JavaのAPIを呼ぶべきだからだよ
おっUnicodeのクソさならおじさん語っちゃうぞ
クロスプラットフォーム狙うなら用意しなきゃ駄目だな
>>825 じゃJstarの開発マニュアルから初めてくれ
全て聞き流してあげよう
>>824 Charでやっといてくれればnativeでコンパイルする時にもそのままにできるという利点がある。
なんでByte型に符号が必要なんだろ。
そして符号付きbitシフトとかどこで使うのか、今でも意味不明
Kotlinがそれなりに流行ったのはJavaの呪いを受け入れたからに他ならない
javaつうか元々cの右シフトの挙動が定義されてなかったから、それを引きずってるだけ
まあそこらへんは存在したとしてもどうせ使うことはないだろうから別にいいよ
>>830 シフトに関しては符号付き、符号無しの区別は重要だと思いますよ
ビットシフトはビットシフトで考えたほうが早いオールドタイプを宥めるために存在する
>>837 冪剰余のバイナリ法をみても、ビットシフトは重要だと思いますよ…
符号無しシフトは非常に稀には使うけど 符号付きシフトは使った記憶がない
ビットシフトを使うほどカリッカリにパフォーマンスに拘る時にkotlin、というかjvm言語を使うかって話よね。
主に移植性や相互運用性のために残ってるだけで批判の対象になるようなケースはほとんど実在しないと思うけどな
>>839 ＞右シフトがtemplate構文の邪魔するとか
C++11 lator でこの制限はなくなりました
使うシチュエーションは確かにあるけどものすごく稀だな
ビットシフトな。実務で使うことはまあないな。
ビットシフトは画像処理やBluetoothで使いまくるぞ
だからそういうのを自前で実装するケースってそうそうないやろ、って話でしょ
元々ビット単位で詰め込んであるようなデータの解析には使った方が見易くなるかも知れない。ネットワークのパケットとか、その他色々あるよね。
ビット操作するなら素直にビット操作演算子つかえばいいんじゃね
なんだ、低レベルな処理を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を許さないってのも、微妙だな
>>864 そうだよ
面倒だから使いたくないでしょ
使わないようにしたいんだよ
だからそうなっている
arcだとすると既存プログラムはコードを書き換えないといけない場合があると思うけど、それを承知で採用してるの？
やってみたかっただけでしょ
ARC with cyclic collector というのをちらほら見る
諸々の問題の解決を試みているうちに、気がついたら出来上がったものはGCそのものだったというオチになりそう
オリジナル言語を頑張って作ったが結局動作的に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にあるのは知ってるから質問けど
いやKotlinに無い理由はJavaにあるからだよ
現状だとメモリ管理は対応プラットフォームの機能に寄生するみたいな感じになってるのは気になるね
ARCはOS関係無くね、Swiftと同じく普通にコンパイラとランタイムによる実装でしょ
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 んなわけあるかい
var x = Foo()
>>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ページがあるが、されてないよね？
>>890 ということはNativeがバンドルされているみたいに書いてある可能性があるな
古いIntelliJ(1.3) + Kotlin1.3プラグイン： 表示されず
Native使ってみたいけどNativeの恩恵にあずかれそうなアプリねーな
開発環境をインストール出来ない会社のPCで威力を発揮
>>895 そらならKotlinだろうがnativeだろうがインストールできないのでは？
タイプミスった
>>897 フリック入力には早く慣れたい、今30文字／分レベル
どうやったらKotlinを使えなくできると思うのか、逆に聞きたい
>>897 そんな些細なミスでいちいち訂正と言い訳しなくていいよ
>>900 Kotlinで書いたコードが動くまでの仕組みの基礎中の基礎を調べた方が良いよ
つまりkotlinは一回javaに変換してからコンパイルしてるってこと？
JVMはバイトコードを読むもの
>>905 概念的にはそうなんだけど実際にはそういう人間にとってわかりやすい中間的な状態はすっ飛ばして内部でいきなりバイトコード作っている。
>>905 Javaで書かれたコードはClassファイルに変換される
Kotlinで書かれたコードもClassファイルに変換される
つまり、OpenJDK (JVM)から見たら、実行する時点でそのコードがもともとJavaで書かれていたのかKotlinで書かれていたのかの区別はできない。
なるほど ありがとうございます
そもそもAWSのJDKっても普通のOpenJDKに対して長期的にバグフィックスとセキュリティ修正をするってだけだからな。
Kotlin使っといてJavaのLTS期間がどうとかアホかよ
>>910 JDKってか、JVMにバイトコードのインタープリタとJITコンパイラ（実行時によく使用されるメソッドとかをバイトコードから機械語にコンパイルする）が含まれてる
>>913 あ、すまん、文脈としては「だからAWSのJDKでだけ動かないなんてことはない」と言いたかった。
>>914 それとJDKのサポート期間と、なんの関係もないじゃん。いったい何と戦ってるのか。
>>917 どのみち放置運用するようなものには全く使えないんだから、半年毎にJDKを更新するくらい大した問題じゃないでしょ
>>918 最高に頭の悪い見解をありがとう。
そうだね、うんうん、君の言う通りだよ。
>>918 それが大した問題だからここ何ヶ月も世界中で大騒ぎしてたわけで。。
まあアプリ本体とJDKをDockerかなんかでまとめてコンテナ化とかしてりゃ何の苦労もないけどな、
現実に本番環境でそこまで出来てるところはまだ少数派だろう。
うわー。Pleiades インストールしたら IntelliJ IDEA が日本語に！
eclipseで開発してるやつおる？
むしろそういったIME使わずに作ってる人いない？
>>923-924 おぢさん達、気持ちはわかるけどその程度のことくらい頑張らないと仕事なくなるよ
>>923 IntelliJの良いところは開発環境周りの苦労がほぼないことだよ
eclipseから移るとマジで別世界で漏らしそうになる
eclipse使っててよくストレス溜めずにいられるよな
>>924 IMEワロス
変数名を日本語にしちゃう人ですかぁ？
>>929 日本語で命名するの、騙されたと思ってやってみたらみやすくてワロタわ。
個人プロジェクトでしかやってないけど、テストケースを日本語にしておくとめっちゃ見やすい。
自分も趣味のプロジェクトはテストだけ日本語で書いてる
>>923 一回使ってみてから決めたら？
そもそもkotlinやるならintellijのほうがいいと思うが
Kotlin使うなら開発元のJetBrainsを支援する意味でもIntelliJの有償版を使うべき
SWT使うから、eclipseのWindowBuilderないとちょっときついのよね
>>923 プラグインが0.7.2くらいの時に使ったことがあったが、Javaのプログラミングの時にまでエラーが出るようになって、
たまらずアンインストールした。
その後どうなったか知らないが、まだアルファ版のままみたし、もともとのContributorはほとんど関与していなくて、
現在のContributorは実質ほぼ一人だけみたいだから、IntelliJのサポートレベルには
遠く及ばないんじゃなかろうか。
https://github.com/JetBrains/kotlin-eclipse/graphs/contributors >>934 支援させてやるから、俺にも買ってくれよ
>>936 やる気なさすぎてワロタ
まあJBがeclipseを手厚くサポートするメリットが何もないもんな
kotlin勉強してみたけど、なんていうんだろこれまでだと泥臭い書き方になるものが
本当に使ってるの？
C#よりいい点はレシーバ付きラムダ式と拡張関数の書き方かな
あんま使ってないんだと思うしスレチだが
この流れはチャンスだ
easy scalaとしてkotlin開発始めたんだからC#関係ないぞw
エヴァしか知らないとアニメ表現が全部エヴァのパクリに見える現象がここにも
作ろうとしていたのは静的型付けのgroovyで、静的型付け言語の先輩のC#やScalaの記法を参考にしただけなんですけどね
他の言語やった後に C# やると
>>945 Cのパクリ言語の多さには驚かされます。
>>943 最後の一文から知りたいのでなくて、ネタをやりたかったのだろうとは思うが、一応説明すると、
基底クラスを継承する代わりに、継承したい基底クラスのインスタンスを指定すると、
あたかも継承したかのように振る舞う機能。
基底クラスのメソッド呼び出しは、上記で指定したインスタンスに委譲(delegate)され、
そのインスタンスのメソッドが呼ばれる。
Effective Javaによると継承は一般的に間違いを起こしやすとしてdelegateするよう勧めている。
overrideするメソッドがたくさんあるけど具象クラスがないインターフェースを実装する時に
ヘルパークラスから生成したインスタンスに委譲すると便利。
KotlinでWindowsとかのデスクトップアプリ作ろうと思ったら、やっぱTornadoFXとかになるの？
そもそもWindowsのデスクトップアプリを作るなら、C#かC++だろ
Kotlinが好きなのかKotlinしか知らないからやろ
windows「とかの」
Javaでクロスプラットフォームなクライアントアプリを作ろうとしたが、クリップボードひとつまともに機能しかった悲しい思い出が甦る
TornadeFXとかあかんやろ（見もせずに言ってます）
とりあえずAndroid用アプリでも作っときなさい。
一つのことにこだわって新しいことの習得がおっくうになるのは老化してる証拠
そうだな。ボケ防止にもなるから新しいことやった方が良い。
>>959 尊師のお言葉にもあるけど、経験値が増えるにつれて、わざわざ自分で使い込んでみなくてもある程度わかるようになってしまうんだよな
Kotlinなんてまさにそうで、Javaに十分精通してる人なら「ああ、記述をライトにしたAltJavaね。機会があれば使おう。」で終わり
Javaで出来ることをKotlinで書くだけだから普通に出来るでしょ
まあそのうちnativeできるし、何かできるんじゃなかろうか。
>>962 確かに老い先短くなると、学習する期間で縮む余命の方が、残りの余命の間に得られる利益を上回るよね。
>>965 余命の問題だけじゃないけどな
・この程度なら必要になったときにググれば十分だ
・類似技術を習得済みだから最悪でも今持ってるスキルの範囲でカバー可能
経験を積めば大抵こうなるから、わざわざ使い込んで試す利益は限りなく低くなる
少なくとも触らないで理解した気になってる奴は成長しない
Kotlinに慣れてくるとJavaに戻る気は失せてくる。
C#も型推論とかあるし、Kotlinが出来るなら、
最新のJava使えるなら型推論あるし、javaでもそこまでいらいらしなくったな。
Kotlinは言語としてとてもよくできている、しかし現実的な用途がピーキーだ
Scalaとかいう意識高い系の先輩を倒したと思ったらまさか大地主様に後ろから殴られるとはな
確かに今現在Java使ってるやつには折伏したくなるがプログラミング初心者ですって奴にJVM言語は勧められないな
もともと、既存Javaユーザーを救おうというのがコンセプトっぽいしなKotlin
>>979 本当にまったく何もわからなければC#（とUnity）
なにか新しくてそれなりに作れる言語やってみたいとか骨のあること口走ったらGo
みんなと同じがいいのならPython
Androidはkotlinかdartになりつつある
Androidアプリ作りたいって初心者は多いから、普通にコトリン勧めるよ。
慣れていくが潰れていくに見えて
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で敷き詰められている。
このスレッドは１０００を超えました。
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
このスレへの固定リンク： 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
ブックマークへ