Kotlin 2
■ このスレッドは過去ログ倉庫に格納されています
それは君には中々理解できない理由による。 例えば以前Appleが傾いた時にジョブズが復帰してiMacを作ってAppleは救われたが、iMacはハードウェアとしてそんなに素晴らしかっただろうか? たいして素晴らしくはないのだ。ブラウン管ディスプレイに本体入れて一体化しただけだ。しかし売れた。なぜか? デザインがよかったからだ。コンピュータとしてはどうでもいい見た目が売れ行きに多大に影響した。 技術者から見ればどうでもよさそうなものでも甘く見てはいけないということだ。 >>77 技術的な話をスレでされても理解できなくて不愉快だから「とにかくほかの話」をさせたがっている 知らない言語のスレなんて見なきゃいいのにね goが人気になった要因もgopher君が半分くらいあるからな。ことりんはいいな ほんとおまえらはばかだなあ 日本の電子IT系なんてオタクの巣窟なんだから萌えキャラことりんで流行言語間違いなしやで インアクションとなんとか太郎本どっち買おう 後者は本屋で見たんだけど 目指すとこがちゃうからな 現在どのくらい習熟してるかにもよるかと 「たのしいRuby 第5版、2016」高橋 征義 「みんなのPython 第4版、2017」柴田 淳 「Kotlinスタートブック、2016」長澤 太郎 この辺は、日本では、避けては通れない人達 >>91 公式のチュートリアルをパクって チョコっと変えて解説してるだけ 掌田津耶乃は、ほとんどの言語・フレームワーク・開発環境の、本を書いてる 売れ筋では、必ず顔を出す。 売れる分野に、掌田あり! 公式見て自習しろや、が通じるならセミナーとか講演会とか必要ないわけでな(いや、これに関しては別に必要ないとは思ってるが) 世の中の需要はあんまりロジカルではないのだ >>85 太郎しか読んでないでActionは買ったばかりだけど、 Javaは一通りで来てKotlinをとりあえずやってみたいなら太郎、 Kotlinにどっぷり漬かることが確定しているならAction?かな いずれにしてもJavaの理解はないとかなり不利。 >>95 器用貧乏というやつですね、わかります。 やってみるとわかるのだが(やらなくてもいいが)、中上級者向けの本というのは全然儲からないのだ 書くの時間かかるし分厚くなって値段高くなるし売れなくなるしチェック内容増えるし時代遅れが混じるし下手すると共書だし 出来によっては「あのすごい便利な本を書いた人」という称号はいくらかの称賛になり、ひょっとしたら生活豊かルートをも開拓するかもしれないが、分は悪い 初心者向けの本をひとりで年に2冊くらい書いてたほうが、志低いと揶揄されながらもきちんと生活できるのさ 掌田津耶乃って何者? (Late 2012) http://egg.2ch.net/test/read.cgi/mac/1349360916/ 1 :Mac Fan Letterより転載 [sage] :2012/10/04(木) 23:28:36.22 ID:ZGQCgQTH0 ● ネットサーフの溺死者たち 「友がみな我より偉く見ゆる日よ」 「2チャンネル」という最低最悪のサイトがある。 >>94 器用貧乏とは言ったものの、翻訳書が原書+1000円くらいの値段になることがざらなことを考えると 英語の公式チュートリアルを訳しただけでも、値段相応なのかもしれん。 しかし、著者のことをよく知らずにタイトルだけでうっかり買ってしまったものの身にもなって欲しい(自己責任) 深く理解した上で書かれた本かどうかは、(本を必要とするレベルの人には)立ち読み程度ではわからない。 Kotlinに限らずあれもこれも全く初心者に寄り添っていないことを鑑みると、初心者向けの本を書くというだけで価値があるのやもしれぬ あなたがライブラリマニュアル作るときに開発環境のダウンロードやプログラミング言語の文法から説明しないのと同じだ 「単純に意味や役割が似通ってるメソッドを集めただけのメソッド集」を表すものってないですかね Rubyでいうmoduleみたいなやつ 特にどのオブジェクトに属してるってわけでもない、誰も初期化しなくてよくてすぐメソッドが使えるやつ いまobjectでシングルトンクラスにしてるけど、なんか漂う特別感に違和感が 適当なネームスペースで、メソッドじゃなくて関数だけ複数定義したファイルを作ればいいんじゃないかな? ああなるほど、packageで分ければいいのか… シングルトンクラスの中に書くよりはしっくりくる…ような…気が…す…うん、そういうものだと思うことにします Kotlinで以下の処理をスマートに書き直したらどうなりますか int idx = -1; for (int i=0; i<list.size(); i++) { if (list[i].data == data) { idx = i; break; } } (idxを使った処理) val idx = list.indexOfFirst{ it.data == data } >>110 サンクス!まさか1行でできてしまうとは。。 Android Studioに貼り付けてもこうはならないよね >>111 とりあえずここで質問すれば答えが書かれるので、後でまとめページを作れば良い。 お前ら「よーし新しく覚えたKotlinのあんな技こんな技使ってコーディングするぞー」 〜 数日後コードレビュー 〜 リーダー「あー、これ全部Javaと同じ感じで作り直しといてネ、ヨロシク」 >>119 コーディングルールでピュアJava使えってなってるならただのアホだろw >>121 トップがKotlinへの移行を目指して次はKotlinとJavaの混在プロジェクトにするとか言って、 でも所属するチームのトップがJavaしか使わないとかいうシナリオなら、 >>119 のような事が起きたとしても>>121 の言うような矛盾はない...と思う。 そして逆コンパイルしたJavaを提出して盛大に怒られる...みたいな。 こんなことで連投してスマン そういや print って印刷って意味だよな。もはや時代も変わり誰も印刷してないのにプログラミング言語では print で出力が定番になっちゃったな。 厳密には印字なのでギリギリ合ってる 原初のBASICのPRINT対象はテレタイプだったから印刷するという意図とはそもそもちょっとだけ違う ブラウン管に文字を焼き付けるから print 無理があるな。 kotlinの文法ってちょっと省略しすぎだし、やりすぎじゃねぇの・・・ C#の方がバランス取れてるわ。 >>139 具体的にはどういう文法のこと言ってるの? 抽象化と少ないコードが正義な昨今の風潮ではこういう文法が受ける 本当にこれで良かったのかは後10年ぐらいしたらわかるだろう >>140 どれがとは言いにくいけど>>139 の言いたいこともわかる気がする。 個人的にはコンストラクタをクラス宣言に書けば、フィールドやコンストラクタの宣言を省略できる仕様とか。 2つ以上のコンストラクタを定義したり複雑なコンストラクタを定義しようとするときの表現に一貫性がなくなったと思う。 フィールド(Kotlinではプロパティだっけ)の記述場所もクラス宣言と本体にバラバラの配置になるし。 Javaにしとけばいいのかもしれないけど、null安全に書いてみたいと思って使っている。 あとwhenがお気に入り。 これはこれで同じこと書いてる感がん〜って感じではある class MyData(name: String, age: Int){ val name = name val age = age } 引数にval書けちゃうことでの「見かけ一貫性の破れ」と「引数もチェックしなければならなくなったという手間」は肯定する というかあれはdataクラスを便利に書くためだけのギミックな気がするぞ しかし言われてみれば視線的にめっちゃ遠いのはその通りだな、家のやつは今度使わずに書いてみるか KotlinがNull安全といっても結局、Javaなどの使用するクラスライブラリがNull安全じゃないからな。 Kotlinだけで閉じてればいいけど、Kotlin最小限のライブラリしか用意してねぇし。どうすりゃいいんでしょうか?? 「!!」演算子積極的に使えばいいの? うん。自分のメソッドはNot Nullにしてるけど、その実装で結局、Javaのクラスが絡む事多いから、 その実装部分で「!!」連発してるんだけど、なんだかなぁ・・・・・ ぬるぽが出そうならトラップするという記法がKotlinにはいくつもあるだろそれ使え chackNotNull(nullable){ "ぬるぽだけは阻止しましたが例外で落ちますさようなら" } nullable?.aaa?.bbb ?: throw RuntimeException("エラーとぬるぽって死ぬ点で大差なくね?") when(){ nullable == null -> println("おかあさんに言いつける") isSomeState -> nullable.xxx.yyy // 文脈上nullが来得ないので ?. で書かなくていい } ああまた空whenに()つけてる 毎回間違って毎回IDEに文句言われるんだよなこれ >ぬるぽが出そうならトラップ ぬるぽが出そうというより、Javaのクラスから返される型は「型名!」ってAndroid Studioを 表示されてて、この型ってNullableの「型名?」と同じでNullチェックしないといけないと思ってて 「!!」連発してたんだが、これ違うな・・・ 「型名!」ってNullチェックしなくてもいいのか・・・ つか、言語仕様上どんな扱いになってんだこれ・・ >>60 で質問したときに、>>61 で答えてもらって ただのIDEの表示上の事なんだと思ってたが違うのか?? T? と T or T? は違うよ Nullableかどうかすらわからない後者の場合はnullチェックしなくてもコンパイルは通るよ 「だってそれはNullableではないから」 まあ、そしてぬるぽが出るんだけども Kotlin的にはnullチェックは不要だけどIDE的にはnullが入りうることがわかってるので気を付けてね! の ! だ >>155 ありがとうございます。 Platform Typesについてしっかり読んでませんでした。そこに色々書いてありましたね。 >T? と T or T? は違うよ T or T?がプラットフォーム型というやつですかね。で、プラットフォーム型ではNullチェックが緩和される って書いてありましたね。 T? と T or T? は同じと勘違いしてました。要はT or T?か分からないから、よりたくさん表現できるT?として扱えばいいし、 そうなってるのかと勘違いしてました。 つか、デバッグしてて思ったけど、C#のusing (resource)やlock文に相当する言語組み込みの 文がkotlinにないのがちょっとめんどくさいよね。ステップオバーで順にどんどん進めねぇじゃねぇか・・ inputStream.use { // いちいちここにブレークポイント設定しないと・・・ }とかだと、実態は関数呼び出しだから、ステップオーバーだと、内部のブロック飛び越えちゃう・・ ああ、ステップインで行けたね。ステップインすると、最初useなどの拡張関数の方にぶっとぶかと思ったけど、 自分のブロックの方に直接飛べるのか。 まぁ、オーバー・インを切り替えるのひと手間だけど、まぁそれぐらいなら。 正直、AndroidのJavaの代替としてKotlinを使うなら、Android Studio 3.0でJavaで全APIレベルでラムダ式が 使えるようになったらしいし、後、Javaにvarなどのローカル変数の型推論あたりがくれば、Javaでも いいかなと思うが(async/awaitもほしいけど)、Kotlin for JavaScriptの存在を知って、 ちょうど、JavaScriptとかスクリプト言語を本格的に使った事なく動的型付け言語使いたくない自分にぴったしだと 思ってKotlin覚えてみようかなと思ってきた。 Kotlin,JavaScriptでググってもあんま引っかからんけど、TypeScriptとかにとって代わったりしそうじゃねぇか?? >>161 > Javaにvarなどのローカル変数の型推論あたりがくれば それ実現されるまでまってられっかよ Haxe(ヘックス)はOSSで、JSに型チェックを付けたような言語で(altJS)、 JS(ES5), Flash, PHP, C++, Java, C#, Python, Lua に書き出せる。 Windows8.1対応。IDEは、FlashDevelop このサイトで、ブラウザでプログラミングして、実行できる Try Haxe ! try.haxe.org/ Kotlin = Java + Groovy Haxe, Kotlin, Ruby をやると、他の言語がクソに見える >>163 言語がどうのこうの言ってるうちは、まだまだだよ。 kotlinから始めたら挫折して、 結局Javaの勉強再開しました。 何個かアプリ作れるようになったけどまだまだ。 Java覚えたらkotlinまで追いつきたい。 Javaで動くアプリ作れてKotlin書けないってのもわりとレアケースだと思うのだが(完全に全くJava以外の経験がないとか?) まあ個人の進度に文句もないしKotlinはしばらく逃げないので焦らずお好きにやっていただきたい >>167 Javaの勉強途中でちょうどkotlinが盛り上がってて、 両方覚えられる!と欲張った結果、 なんか情報も少なく、混乱して挫折。 とりあえずJavaで慣れたらkotlinもやってみます。 Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016 プログラミング言語初学に向かないのは多分間違いない C#のusingもJavaのtry-with-resourcesもkotlin.io.useも気に入らない GCだからC++やSwiftのようなデストラクタまでは無くてもいいけど せめて use val xx = ... のようにキーワード付き変数の場合に スコープアウトでcloseする構文を用意して欲しい 後処理の指定ごときでいちいちブロックスコープ増やすなと >>172 中括弧省略すればブロックスコープ増えないし、ほぼそれと同じ構文で書けるやん そーゆークラスを作ればいい 内部的にはそうしてても使う側が意識しなきゃそれでいい StackOverFlowで「○○するにはどうすればいいですか」に対して 自作の20行くらいの関数返して「こうすれば1行で書ける」とか言う回答者みたいだなw 例えばこれを openCamera(id).use { dev -> dev.video().use { vidIn -> File(dstPath).outputStream().use { output -> val vidOut = videoWriter(output) vidIn.eachFrame { frame -> filter.write(frame, vidOut) return checkContinue() } } } } このように use val dev = cameraOpen(id) use val vidIn = dev.video() use val output = File(dstPath).outputStream() val vidOut = videoWriter(output) vidIn.eachFrame { frame -> filter.write(frame, vidOut) return checkContinue() } 次点で、golangのdeferのように val dev = cameraOpen(id) defer{dev.close()} val vidIn = dev.video() defer{vidIn.close()} val output = File(dstPath).outputStream() defer{output.close()} val vidOut = videoWriter(output) vidIn.eachFrame { frame -> filter.write(frame, vidOut) return checkContinue() } としたい usingやuse関数での書き方が駄目とまでは言わないが俺は気に入らない ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる