Kotlin 2
■ このスレッドは過去ログ倉庫に格納されています
Kotlin in actionのおかげでやっとflatmapの意味が分かった ifとか式にできるくせに、代入文は式にできねぇの??しょっぺぇ。
while ((bytesRead = stream.read(bytes)) != -1)
とかできねぇの?しょっぺぇ あれ、ひょっとして、kotlinてまだシリアライズできねぇの??
しょっぺぇ・・・
普通にデータの保存にJavaのバイナリフォーマットのシリアライズ使ってたんだけどな・・・
あぼぼぼぼぼ。 whileはみんなそこで詰まるNE!
Kotlinは条件部分で副次作用が起こることをよしとしないのだ
数少ない「単体部分で見ればJavaより記述量多い」部分なので、
我慢して明示的に変数定義に切り分けるか、素直に組み込みのBufferedReaderとか使ってくれ
よっぽどオリジナルでない限りwhileでなんかしてたやつは「whileの外ごとまとめて」3行くらいで書ける 昔、ポインタ演算できないからJavaはしょぼい、というような主張してる奴が
たまに居たのを思い出した Kotlinの仕事ができてないお前ら失業確定www無職ざまあwwwwww >>49
Java使ってれば違和感なく移行できますと言われつつ、実際はプチパラダイムシフトの受け入れが必要なのはちょっと不誠実かなとは思う
我々は「うっひょー○○言語や××言語のアレみたいだね!」とか喜ぶわけなんだが
Javaしかやらないような人から見たら「Javaとは全く違うだけの気持ち悪い何かがくっついてる」としか思えない可能性は高い >>51
アピールしてるのは「相互運用性が高いから移行できます」であって、「違和感なく移行できます」では無いよ
そういうのを書いてる第三者の記事はありそうだけど
公式的にはむしろ関数型に力入れてるのを売りにしてる >>51
> Javaしかやらないような人から見たら「Javaとは全く違うだけの気持ち悪い何かがくっついてる」としか思えない可能性は高い
そうやって全く関数型やらモダン言語らしいとこ使わない違和感あるKotlinコードが出来そう プロパティと型推論しか使わないのもあり?
それならできそう。 >>38
Kotlin in action買おうか迷っているけど、公式サイトの解説と比べてもっと深いことが書いてあったりする?
ちなみにKotlinスタートブック は読了済み。 >>54
javaとの対比だとプロパティとnull安全だな。最も有用
それ以外はコーディング的な進化だから追々覚えればよい 俺のお気に入りのF#はなんだかんだでnull残ってるから、その点はkotlin羨ましい 残念ながらjava互換だからnullは無くならないのだよ ガードしない場合、ぬるぽが起こる割合はJavaとほぼ同じ
言語の仕組み上安楽にガードしやすいってだけの話だからね
しない・できない・忘れてたという場合はぬるぽぬるぽぬるぽだ
コードはまさに意図した通りではなく書いた通りに動く
そこでは思想など無意味だ Android Studioでのコード補完のパラメータ表示にInputStream!とか末尾に「!」が
ついてるんですが、これは何なんでしょうか? IntelliJ の T! は「T か T? のどちらか」を示す
つまりNullableかどうかすらわかんねえという記号 >>60
ありがとうございます。Java絡みのは当たり前ですが、ほぼそうなってますね。
理解しました。 忘れてたって言ったって全部に?付けないとJavaと同じにならないわけで
?付けなけりゃコンパイル通らないしNULL安全意識せざるを得ない !! は、Nullable を、NotNull に強制変換する、危険な演算子だから、
requireNotNull 関数を使え
例えば、Java から、null が代入される場合、
String → IllegalStateException。ヌルポよりまし
String? → Nullable なのでOK
Platform Type
型を省略(String!) → デリファレンス時に、ヌルポ
Java からの戻り値がすべて、Nullable になるのは困るので、
その折衷案がPlatform Type Java からの戻り値をすべて、Nullable にするのは面倒なので、
そのまま使ったのが、Platform Type
デリファレンス時に、ヌルポとなるため危険! Javaのほうのコードに@NonNullアノテーションつけとけば、KotlinからT!じゃなくてTとして扱える 現代的な気遣いのされてるJavaライブラリはKotlinからでも便利に扱える
シガラミがあって旧来のままのライブラリはそりゃ利用者側が手間かけるしかない ラッパークラスもありだし、OSSなライブラリだったらアノテーション付与してPR送るのも有用だな Kotlinから使いやすくなりました! みたいに言えるのはひょっとしたら売りになるかもしれんね それは君には中々理解できない理由による。
例えば以前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年ぐらいしたらわかるだろう ■ このスレッドは過去ログ倉庫に格納されています