Kotlin [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
JetBrainsが開発した期待の新言語Kotlinについて語りましょう https://kotlinlang.org Swiftの開発者だけど、Kotlin/Nativeで使うLLVMの開発者でもあるんだよなぁ Googleへの転職も短期らしいしApple(Swift)からJetBrains(Kotlin)にすぐに転職したら 倫理的にAppleからクレームが来るのは当然だしお茶濁しかもね KotlinにLLVMのノウハウ投入してくれることを期待しようじゃないの googleって20%ルールってまだあるんでしょ? その20%の中でkotlinに手を出すのは自由なんじゃないの。 ただ、swiftの言語仕様の変遷を見るにkotlinの言語仕様に口出したら とんでもないことになりそう C#から来たけど、C#ではヌル安全もコンストラクタとメンバ定義が一体になってるやつも一向に入らないからKotlinの方がいいと思うようになったね IDEが少しモッサリしてるのとコンパイルが遅いのが難点だけどね SwiftはGCがないから論外じゃない? >>547 GCないから論外ってそれRustに向かって言えるの? Kotlin/Native PreviewはGCじゃなくARCなんだけど? そして、GCがベストというわけじゃないし今後はどうするかは知らんとも言ってる >>548 Rustはスゴイよな 使いこなせればあれが理想なんだろうな rustはどうなんだろうね。 いずれ学習したい言語ではあるけど、今のところ活躍場所がないからなぁ。 Kotlin勉強してるけどベターJavaとしてのScalaは相当辛いなあ。 Scalaは何目指せばいいんだろ Scalaって当時のサーバサイドJava(J2EE)の代替として出たものでしょ サーバ上で動かすJavaVMに既存資産(ソフト&人員)の再利用以外の価値を見出せるなら使えるんじゃないの Java EE が、大げさすぎるから、 2001年、Struts 2004年、Ruby の、Rails 2006年、Groovy の、Grails 2006年、Scala の、Play 今は、Kotlin が出たけど、型を書くのが面倒くさいから、 型を書かない、Ruby, Groovy は残るだろう >>555 javaばっか触ってる人は型がない方が素敵って思ってるのかね。 俺はTypescriptでかなり幸せだけど。確かにjsよりタイプ量が増えるけど それ以上に安心感がパない 型があろうがなかろうがどうせバグはテストで潰すからな js界隈にはテスト文化がないのか 直受けの50万 客:いつまでもうちにいていいよ 3次受けの50万(客は70万払ってる) 客:短期延長していい? 5次受けの50万(客は110万払ってる) 客:作り終わったらとっと出てけ できなかったら即退場だ 長時間労働 高稼働 高スキル要求が多い 零細フリーランスサイトは5次受けから誰もできない難易度の高い仕事 余り物の仕事を紹介してくる。40万円代でやってくれと これならJIETから3次でいったほうがいいな 446非決定性名無しさん2017/08/02(水) 22:12:48.95 JIETに毎月5千円払えば3次から入場できるだろ? 高額をうたうフリーランスのサイトはだいたい5次から45万円 JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした 高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした 473非決定性名無しさん2017/08/03(木) 15:21:30.71 JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる 自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の 間でやらしている。 372仕様書無しさん2017/08/11(金) 10:31:43.41 フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。 高額に見せているけど実際は50万前後 JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円 平凡な稼働時間の80万円の案件もある。 ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト 自称エージェントはJIETから流れてくる案件を転売してるだけだった。 JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む >>555 Railsより長く使われてるTomcat(Servlet)とPHPを忘れてんよ どっちもRailsに淘汰されるかと思ったらなんだかんだで未だに生き残ってやがるから困る テスト云々より動的型付け(TypeScript含む)は実行時速度がなぁ 動的型付け+型チェックは苦肉の策で、静的型付け+型推論が今の流行りよな よってKotlinは素晴らしい ひところJIETがネガキャンされてて最近は逆に急にこのありさま どこに首根っこつかまれたんだ Android Studio 2.3.3で新規プロジェクト作るとKotlin変換後syncするとなんか赤字のIDEエラーが出るわ AssertionError: Resolver for 'completion/highlighting in org.jetbrains.kotlin.idea.caches.resolve.NotUnderContentRootModuleInfo@1f51170a for files MainActivity.kt for platform JVM' does not know how to resolve ModuleProductionSourceInfo(module=Module: 'app') なんか設定間違ってるのだろうか… ぬーん原因らしきものわかった 「Javaをktファイルに変換する(Ctrl+Shift+Alt+k)」は/app/src/main/javaを選択した状態でやったほうがいいらしい 下手に/appとかプロジェクトルート選択した状態で変換すると余計なのまでkt化されてIDEサポート動作に支障が出るようだ こんなミスする人そんなにいないと思うけど数文字打つたびIDEエラー出まくるという人は気をつけてみてくれ そうでもなかった IlligalStateExcptionは別枠らしい Failed to create expression from text: '<ERROR FUNCTION>' ターミナルから起動すると標準エラー出力にスタックトレースが出ることがわかったのだが追跡めんどいな 前のと違ってこのエラー出ても補完とかは動くからもう無視したいした ちょっと関係ない話だがKotlinの入門書の最初に説明用のサンプルとして出てきた最大公約数を求める関数のアルゴリズムに驚いた ユークリッドの互除法なんてものがあることを今まで知らなかった 証明見てもまだよくわからん よくこんなことに気付いたな 紀元前300年の数学者すげー ユークリッドの互除法って有名で プログラミングの題材としてもよく出てくるけど 紀元前に生まれてたら自力で思いつかないとは思う 有名だったのか。確かに再帰処理の題材としては丁度いいねこれ。 Kotlinなんて最新言語じゃなくて 何十年も前のBASICやCの頃から 互除法の例題はあったよ 正直あれは脚注でもなんでもいいから一言解説がついててもいいと思う どこかで一度でもやったことさえあれば一発で見当がつくが そうでなきゃ何がなんだかさっぱりわからんはずだ 別にユークリッドの互除法を教えるのが目的じゃないからなあ Nクイーンとかもそうだけど 使い回されてるアルゴリズムを載せるのって 他言語でもう読み書きしたことがある人が 「この言語だとどう書くの?」ってのを 確認するためにあるようなものだからね 「※ユークリッドの互除法」と一言書いてあるだけで100人単位で手間が救われたはずではある もともとページ数ギリギリな書籍だから難しいのかもしれんが ま、しかし、少なくとも計算に関しては数学知ってるか否かでかなりプログラムが変わって物凄く効率化できる可能性あるな。 ユークリッドの互除法は、中学生レベルだろ。 知らなかったら、最大公約数を求められない プログラムの本で、素数を求めるのに、√N まで、求めれば良いのに、 それを知らない著者もいる N = 1,000 なら、32 まで試せば良いのに、1,000 まで試してる著者もいるw >>575 ユークリッドの互除法は4年前から高校の数学Aに記載されるようになった それ以前では教育課程では学ばない >>574 使うこともあるよ。使った方が簡単になる場合。 こないだやったのは(Kotlinではないが)XMLの階層構造をRDBの表に入れるとかそこから戻すとかの処理。 XMLって入れ子になってるから再帰で書いた方が楽だ。というか再帰使わないと複雑怪奇なプログラムになるんじゃないか? 互除法は繰り返しでもわりと自然にコーディングできるが、XMLとかの木構造の処理は再帰が自然だよね。 operator キーワードの意味が良く分からないんですがこれって何のために必要なんでしょうか >>579 operatorが書かれてない場合はそういう名前の普通のメソッド定義だとみなされる operatorが書かれてる場合はそれに対応する記号の演算子のメソッド定義だとみなされる ギアパワーの組み合わせで性能が見れるアプリを作ってみようかと思うんだが、 どういう機能があったら嬉しいかね 単に57表記が見れるだけじゃ意味ないよねえ それはプログラミング言語の手法の話ではないと思うよ そのアプリを使うであろう人たちに直接聞いてみてはいかがかな ミスった 引数がIntのメソッドにByteとかShortとかつっこみたいときの賢い方法ってない? いちいち.toInt()付けるのアホらしくて …いっそのこと全部Intにしてしまうか 「引数をとりあえずIntにして当該メソッドを呼ぶ」というメソッドを作ってそっちを使うようにする 具体的にどういうことをしたいときなのか言うと案外別アプローチあるやもしれず 拡張プロパティで短縮 val Byte.i:Int get() = toInt() fun f(b:Int) { println(b) } fun test() { val b:Byte = 100 f(b.i) } >>586 は何気にbytecodeにコンパイルすると最速処理に最適化されるのではと悩む val b:Byteはクラス型じゃなくプリミティブ型intに置換されて、+0は無意味な処理として削除される的なね toIntoをメソッドとしてコールするようなオーバーヘッドは無いに越したことはないよねー class MainActivity : AppCompatActivity() { fun func(value: Int) : String { } } : の前って空白をいれるべきなんでしょうか 入れないでおくべきなんでしょうか クラスの継承の時だけ入れるべきなんでしょうか >>590 https://kotlinlang.org/docs/reference/coding-conventions.html#colon interface Foo<out T : Any> : Bar { fun foo(a: Int): T } これ以外の書き方は公式規約に則らないスタイルとなる むろんそれを押し通してもよいが >>589 それはオーバーヘッドが出ないように最適化されるのかどうかに掛かっている。 >>593 後から思い直したけど、メソッドfがByteクラスというクラス型を受け取る以上 val b:Byte = 100 b+0 までをプリミティブ型に最適化する超絶賢いコンパイル処理がなされても f(100) でintからByteへのインスタンス生成が必要だからJVM上の最小限コストにはならぬ 小賢しく汚いコードの割に最大効果が得られるわけでもないから微妙だわ >>594 f(100)と書いたならコンパイル時にインスタンス作ってコンスタントプールに入れられるから実行時の無駄はないのでは? # メソッドfが受け取るのはByteじゃなくIntだったorz >>595 プリミティブ型byte/int 100はコンスタントプールに乗っかるけど クラス型Byte/Int 100はコンスタントプールには乗っからないから メソッドf呼び出し時のint to Intのインスタンス化コストは回避できてなくね? メソッドfが受ける型をJITやクラスローダーが書き換えないと無理ぽ どうやったってJava相当まで最適化できないんだから 全部Intにするなり拡張プロパティ使うなり、好きなように実装して良いと思った 乗らないか。じゃあダメだな。 まあでもそこまで最適化するようなコンパイラができればできるということでもあるので何とも言えんな。 それとプログラマが最適化を考慮してコード書くってのは、まるで昔のC言語のようで、かなり変な状態だとも思える。 現実問題としては効率を上げるためにはそうせざるを得ないが、本来であればそれはコンパイラがやるべき仕事であり 人間がそういうことから解放されないのはまだ技術力が足りないからだ。 100は例なだけでtoInt云々の文脈では定数でなく変数でしょ KotlinのByte/Intはオブジェクト型が必要なとき以外はプリミティブ型になる さらにJVMのスタック上でbyteはintサイズで置かれてる ※例えば引数の2つのbyte型の加算は「iloadでint変数として読み込み x2」「int加算」「i2bでbyte表現に切り捨て」「istoreでintとして保管」になる なのでtoIntはバイトコードレベルではメソッドコールどころか変換命令すら無く消滅する +0や拡張プロパティはバイトコードに残るけど多分Dalvik JITやARTが消すんじゃないかな 0〜127 なら、最初から、EXE の静的データ領域に入っているから、 インスタンスも作られないから、何も考えなくてよい やっぱそれなりに最適化されるのでほとんど考えなくて良いということかな Javaほどではないが、それなりには最適化されるから考えなくて良いよ ○次受けが多いほど退場率が早くなる。高くなる 直受けの50万 客:いつまでもうちにいていいよ 3次受けの50万(客は90万払ってる) 客:短期延長していい? 5次受けの50万(客は150万払ってる) 客:作り終わったらとっと出てけ できなかったら即退場だ 長時間労働 高稼働 高スキル要求が多い フリーランスサイトを運営している零細ITの自称エージェントは労働市場から流れてくる案件を転売してるだけだった。 労働市場に加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×3 = 言い値50万以下 エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×1 悪質な言い値で50万以下 エンド - ユー子 - エージェント-JIET 公表価格 90~60 - JIETに加入して公表価格で応募できる eJobgo JIET JISA で検索 優良エージェント・優良サイト 首都圏IT(PE-BANK) プログラマーズ Kotlinを使えば使うほど、Kotolinってええ言語やなと思う サーバーサイドでも使われているようだし、この言語はやる価値があるね Kotolinのデメリットって何かある? 全然見当たらないんだけど >>604 動的ではない どちらも適材適所、釘にはトンカチレベルの話だが、デメリットとして挙げるなら >>606 ランタイム(kotlin.jar)が実行に必要 >>604 言語自体のデメリットではないかもしれないが、 IDEの選択肢がない・開発補助ツールなどが未発達。 >>610 コレはでかい。正直この知識を簡単に獲得する方法あるの? kotlinからjavaの世界に入る方法を知りたい。 そういやJavaの知識なしの人向けの入門書はまだないのかな? なくても流行ればその内出そうだが。 Javaって一番メジャー言語だから 情報が溢れてると思うんだが…… マイナー言語の苦しさに比べたらはるかに楽 Javaを既に知っている者ならそうだろうな Javaを知らずにKotlinやると、KotlinとJavaを並行して学習することになるから面倒だって話だ kotlinはJavaのスクリプト言語みたいな立ち位置だからな(コンパイル要るけど) Java入門が巷に溢れているがゆえにKotlin+Javaの書籍は出しにくいかもしれん それにしたとしても時間が解決していくではあろう Kotlinで開発してたとして、具体的にどういうときにJavaの知識が必要になるんだろう? JVMに関してなら「言語+実行環境」だから他の言語と変わりないし Javadocのシグネチャくらいで困ることは無さそうだし 多分、解説書く側も「何が分からないのか分からない」状態になってるんじゃないかな >>607 JSもJVMもランタイムがいると思うけど、このランタイムってApache2.0ライセンスなのかな? だとしたら、同梱した場合、表示が必要になるんだっけ? >>618 こういうことをJVM上でやりたいなぁって思った時に、Javaでの実装手法を調べてKotlinで読み換えるわけだろ? その時にまずJavaの全般的な知識(文法, ライブラリ)を浅く広く手に入れる所から始まる 次に、JavaからKotlinに読み換えるために文法/ライブラリの在り様を深く理解してから適切なKotlinコードに書き下す JavaとKotlinの生半可な知識だけでJavaコードを参考にKotlinコード書くと、汚いKotlinコードになるよね なので、絶賛Javaを再勉強中・・・Java1.5の頃の知識で止まってるからイマドキのJavaが分からない java.langとかNIO2とかを使ったコードをKotlinでいきなり書こうとしたら何か違う感が酷くてやめちまったよ 他の言語を知ってれば要はリファレンスとjava特有の注意事項があればいいと思うの。 文字列組み立てにはStringBuilder使えみたいなの。 そういうの無い? android studioってkotlinのプロジェクトにjavaのコードを貼り付けたらkotlinに変換してくれる神機能があるから 泥開発する時にネットで拾ったjavaのコードをペタペタコピペプログラミングするだけでも勉強になる javaもkotlinも知識皆無の状態でkotlinで泥アプリ開発に取り組んだら見様見真似で簡単なアプリ作れた ある程度コピペしてたらjavaのこの書き方はkotlinではこう書きそうっていうのがなんとなく察せてくるからandroid studioの補完を頼りに写経したりする javaも知らないけど新しく言語の知識学ぶなんて面倒くさいからヤダ!知識皆無だけどすぐ何か作りたい!hello wordとか練習問題みたいなの書いても面白くないからモチベーションわかない!すぐ作りたい物作りたい!って場合は ネットのサンプルと強力なIDEの支援を頼りにコピペ写経するのが効率よさそう (外国語ができなくても海外でしばらく生活したら知識的に習わなくてもだんだん喋れるようになる理論) >>620 Kotlinで書かれたサンプルコードが少ないってこと? それについては自動変換で対応するか、Kotlinが広まってサンプルが増えるのを待つしか無いか それと思ったのはKotlin・・というよりプログラム初学者は 言語仕様、ライブラリ、プラットフォームの知識がごちゃ混ぜになってるのかも 「Java言語仕様の知識前提」の場合はデメリットだけど、後者2つはそうではないんだよね ちゃんと切り分けて教える必要があるのかもしれない >>620 一々Javaで考えてからKotlinに読み替えるのではなく最初からKotlinで考えればいいのでは?それは出来ないの? 前途洋々たる人にJavaを教えたいかというとそうでもない、しかし現状kotlinにはjavaの知識がいくらか必要というジレンマ kotlin変換はスニペット単位で変換挿入できれば初学者サポートとして文句ないんだけど まあ高望みしても仕方ないなw Kotlinを使い始めるのにJavaから始めないといけないのも高望みだから仕方ない JVMとJava LibraryありきなんだからJavaを知らないで何が始まろうかと理解している >>628 騙されたと思ってandroid studioでkotlinを開いてそこにjavaのスニペットをそのまま普通に貼り付けてみ kotlinというかIntelliJはなにかにつけてUnresolved Referenceで発狂して真っ赤になるのを潰していかんといかん 全部自前のkotlinファイルとパッケージだけで構成すれば絶対に起こらん事象だが、そんなのは稀だ >>632 あれはライブラリ作者とプラグイン作者が7割くらい悪い 提供されるテンプレートでjavaパッケージのimportの不足(しかもbuild.gradleに依存関係未記述)とか勘弁して欲しい ていうかこれ作者のとこではどうやって動いてたんだ… >>633 TornadoFXでえらい苦労した記憶がある 無論使うのやめた Androidのほうがまだきちんと動くw 昔のEclipse環境下開発みたいなトラブル起こしてんなw libs/*.jar と .classpath をコミットしてなくて、ライブラリ実装者とライブラリ利用者で環境が合致しないとかよくあった build.gradleで依存管理してないなら、libs/*.jar と .idea/ で管理してるんじゃないのかね ビルドできねーよってIssue発行して、build.gradleで依存管理するように直してもらおうぜ(Kotlinと全く関係ない話題 TornadoFXは面白そうだなと思って手を付けた瞬間 ・TornadoFXのDSL記法では思った通りに動作しないがJavaFXでは動く ・JavaFXではうまく動かないがswt直呼びでは動く ・JavaのGUIアプリケーションではあまり得意ではない の3者が混然一体となってGUI初心者に襲いかかってきた荒野の印象しかない GUIやるのさぼってきたツケもあるしkotlin関係ないけどな HTTPプロトコル受けるようにして、GUIはHTMLとjavascriptでブラウザ任せでやる方がいいんでね? とるねーどFXのDSL記法は初心者の「こうかな?これなら動くかな?」という学習の試行錯誤を念入りに潰してバグに変えるプロ 設定記述手法以外のDSLなんてまあたいていそんなもんだが どうしてもPCでGUI欲しくてなにもわからない最初ならJavaFXにするのがよいよ >>630 IntelliJではできんことのほうが多いね 完動するJavaのクラスのファイルとかそういうでっかいのか意味のあるわかりやすい小さいやつとかじゃないとまず無理 それでも便利だろうという指摘はもっともだが tornadoFXで丸1日悩んでいたことがJavaFXでは1時間でできたなんていう笑い話が… 別にこれに限った話じゃないけど、今から何か始めたいって人は「kotlin対応新鋭フレームワーク!」みたいな宣伝には騙されずにJava製のでいいからメジャーなやつを選ぼうね たいていkotlinでの書き方みたいなのが公開されてるからそれで充分さ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる