Kotlin 7

**デフォルトの名無しさん** · 2020/05/06(水) 16:00:38.76

JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう

※前スレ
Kotlin 6
https://mevius.5ch.net/test/read.cgi/tech/1561186797/

**デフォルトの名無しさん** · 2020/12/01(火) 07:41:02.13

!!や?って説明できるなら使ってもいいんだよね
いま宣言したけど中身がない、下の行で関数かなんか呼び出して空の変数に入れる、その変数を使う
コードの中に書いたらダメならそもそも書けないし
見る人が嫌ってだけだよね

**デフォルトの名無しさん** · 2020/12/01(火) 08:37:49.02

javaでいいよ
無理矢理感有り過ぎの上
文法がひどい

**デフォルトの名無しさん** · 2020/12/01(火) 12:39:29.78

>>462
明快な話だよ
どちらの演算子も、if文を使ったそれと等価のロジックに置き換えて考えて、そのロジックを使うべきだと思えば使えばいい
特定の頻出イディオムの短縮記法に過ぎないと捉えれば、長ったらしく書くよりも演算子ですっきり書いた方がいいとわかるはず
追加メッセージのないNPEを送出するなんて絶対にムリという状況下なら !! は使わないことになるだろうし、低リスクな部分なんて元々エラーメッセージ考えないし万一落ちたらスタックトレース見りゃいいやという状況なら !! を使うのは理に適ってる

状況を問わず絶対に使うなというのは原理主義者かアホだと思う
Javaを使ってるのにクラスや例外を避けようとする老人と似たようなもの

**デフォルトの名無しさん** · 2020/12/01(火) 14:06:45.61

!!を使わなくても書けるのに敢えてクラッシュのリスクのある!!を使う必要ない

**デフォルトの名無しさん** · 2020/12/01(火) 14:51:50.13

コントラクト書いてもスマートキャストできないならアリ

**デフォルトの名無しさん** · 2020/12/01(火) 17:28:10.09

assert文もクラッシュのリスクがあるから使わないって言うんだろうか
フェイルセーフで進めるべきシーンとフェイルファストで落とすべき部分を判断して使い分けてほしい

**デフォルトの名無しさん** · 2020/12/01(火) 17:44:21.87

そんなのは設計が糞
センスないからしね

**デフォルトの名無しさん** · 2020/12/01(火) 18:45:05.23

いろんな宗教食タブーに配慮した結果、鶏肉料理しか選択肢がなくなる感じ。それがクロスプラットフォーム。

**デフォルトの名無しさん** · 2020/12/01(火) 19:28:13.47

そうそう、そんな感じ

**デフォルトの名無しさん** · 2020/12/01(火) 21:58:25.69

>>459
あー。Stringとかと同じか。書き換えられないように作ってあるだけで言語レベルでリードオンリーというわけではないという。

**デフォルトの名無しさん** · 2020/12/02(水) 07:55:24.49

そういうこと。ただ変更のためのAPIを提供してないだけ。

**デフォルトの名無しさん** · 2020/12/02(水) 10:41:02.88

Stringはクラスがfinalで閉じてる分、変更可能性という意味では層が少し違うかな

**デフォルトの名無しさん** · 2020/12/02(水) 10:42:20.86

CharSequenceが等価だと思う

**デフォルトの名無しさん** · 2020/12/04(金) 16:14:35.33

>>461
何つながりでいっているのか知らないけれど、まあ、それでも基本部分だけでも
動作すればだいぶ楽にはなる。
同じように書いてHelloWorldが出て、直線や矩形描画、文字描画、キー入力が
共通化されていて、同じ言語で書けるならかなり楽になるから。
クロスプラットフォームキットを何も使わなければ、言語自体も違ったりして、
ロジック部分すら共通化できず、大変なことになる。
WindowsではC++(またはC#), AndroidはJava, AppleはSwiftみたいに。
そしてprintf()文すら共通しては使えない。

**デフォルトの名無しさん** · 2020/12/05(土) 12:38:19.27

実務経験1年で月収80万稼げるエンジニアになった理由
https://www.youtube.com/watch?v=DrbbyGsHQic
意識が低いエンジニアこそフリーランスになれ
https://www.youtube.com/watch?v=nSEaAJlgjbQ
フリーランスエンジニアの週3労働ってどんな感じ？
https://www.youtube.com/watch?v=8yjoDCdbzMc
ぼくがスキルのない社畜ならこうやって脱する
https://www.youtube.com/watch?v=aae8xxbUlMM
初めて人を雇ったらもう二度とサラリーマンをやりたくないと思った話
https://www.youtube.com/watch?v=U0OCGRVLFsM
プログラミングは文系でも余裕で出来ます！理由を現役プログラマーが解説
https://www.youtube.com/watch?v=iBOeiSKBIW8
貧乏人こそ社会不適合者
https://www.youtube.com/watch?v=O3BT72BIBJI
元ド貧乏が教える】貧乏を抜け出すための2つの考え方
https://www.youtube.com/watch?v=IRrCgTy3ckc
より良いオファー貰ってるのに転職しないとか何考えてるの？
https://www.youtube.com/watch?v=i0J6uRhlj7o

**デフォルトの名無しさん** · 2020/12/12(土) 16:10:56.29

Kotlinは人気順位をどんどん下げてんね。

**デフォルトの名無しさん** · 2020/12/12(土) 17:12:12.40

型違いやぬるぽのエラーが動かす前にわかるというが
逆に言うと動かせばすぐわかることだ
今時そのパスとおってませんとかテストでありえんから

型なんかいらんかったんや

**デフォルトの名無しさん** · 2020/12/12(土) 17:37:35.65

そんなしっかりテスト書くなら型あった方が楽じゃん

**デフォルトの名無しさん** · 2020/12/12(土) 19:11:57.44

変数は全部public staticで MutableList<Object>じゃい！
goto文も好きに使え！
だって全部テストでパス通せばいいじんじゃい！

うん、暴論だと思う
null安全も型安全もカプセル化も、言ってしまえばほんのちょっとの便利ツールでしかないんだけど、そのほんのちょっとがバグを減らし、思考の負荷を落としてくれる

**デフォルトの名無しさん** · 2020/12/12(土) 19:17:54.50

万全のテストが組み上がった後では言語ごとの安全設計の違いはプロダクトの品質に影響をほとんど及ぼさない、それはそうかもしれない
ただ、その万全のテストが手にはいるまでにどれだけのコストを要するかが違う
流れるように書くことができて、書き間違えや考慮漏れが起こりにくく、テスト作成中にfailが出てもすぐに特定して直せる、その結果生産性が高い、それがいい言語だと思う

**デフォルトの名無しさん** · 2020/12/12(土) 19:17:56.76

誤りは防ぐが思考の負荷は増えるぞ

**デフォルトの名無しさん** · 2020/12/12(土) 19:31:00.69

とても小さいスクリプトを書く場合と、バグをいくらでも作ってよく誰かが直してくれるならそうだな
VBの変数宣言不要のVariant天国は何でも格納できて極楽
一方である程度大きいものをバグなく作る必要があるなら脳内に展開する必要のあるデータ量が増えてスケールしなくなる

**デフォルトの名無しさん** · 2020/12/13(日) 08:02:21.21

単純に型のあるなしだと設計を疎結合にしやすいとかリファクタの安全性が高いとか色々変わってきますがな

**デフォルトの名無しさん** · 2020/12/13(日) 11:22:13.31

それでもやっぱり型が好き

**デフォルトの名無しさん** · 2020/12/13(日) 13:22:32.62

シェルスクリプトやマクロみたいな簡単な治具には形を意識せずにすむ言語がお手軽だし、バックエンドのシステムを組み上げるにはnull安全のある厳しい静的型付き言語がフィットするので使い分けましょうねという結論でいいと思う
使い分けのミスマッチを解消したいい例がTypeScript

**デフォルトの名無しさん** · 2020/12/13(日) 17:03:49.88

Rubyも型のような何かを入れたし、時代の流れだわね

**デフォルトの名無しさん** · 2020/12/14(月) 00:35:19.60

数値や String が保持出来て計算出来れば良いんだったらそういうクラス作って
operator で色々作って計算出来るようにしちゃえば良いんじゃないか?
効率悪いかも知れないが。

**デフォルトの名無しさん** · 2020/12/14(月) 08:23:45.23

>>478
> 今時そのパスとおってませんとかテストでありえんから

そのテストを自動で実現するテストフレームワークが無いんじゃない？
せめてnull安全ぐらい関数１つで実現してほしいわ。

**デフォルトの名無しさん** · 2020/12/14(月) 10:17:36.45

君らみたいにkotlinやってる人ってアプリ開発者が多いのか？

**デフォルトの名無しさん** · 2020/12/14(月) 10:24:57.92

Android以外でKotlin使ってんだなぁて思う
JavaだったとこをKotlinに置き換えてんの？

**デフォルトの名無しさん** · 2020/12/14(月) 10:39:03.40

元々Javaのサーバアプリ書いてる

**デフォルトの名無しさん** · 2020/12/14(月) 18:48:58.24

サーバーサイドだね
完全にbetter Javaとして使ってる
既存コードの置き換えもするし、新規実装するものに関しては完全にことりん

**デフォルトの名無しさん** · 2020/12/14(月) 18:50:01.54

Androidやってるだけだからサーバーとか行っても戦力にならないんだろうな
同じ言語なのにここに出てくるサーバーサイドの会話がなんとなくわかったつもりの異次元

**デフォルトの名無しさん** · 2020/12/14(月) 18:50:06.38

サーバーサイドkotlinは採用も意外に楽よ
それ自体の経験者はほぼいないけど、Kotlin書きたいJava経験者はかなりいるから

**デフォルトの名無しさん** · 2020/12/14(月) 18:50:39.52

>>494
それはお互いにそうでしょ。
言語そのものの知識なんて大して重要じゃないし。

**デフォルトの名無しさん** · 2020/12/14(月) 22:34:42.15

nullsafeでぬるぽが減った人いますか？

**デフォルトの名無しさん** · 2020/12/22(火) 19:15:05.74

減るっていうか0になったけど何が言いたいんだろ

**デフォルトの名無しさん** · 2020/12/22(火) 21:19:38.41

ぬるぽを無くすためのnullsafeだからな

**デフォルトの名無しさん** · 2020/12/22(火) 22:42:34.84

ＤＢカラムに入ってるはずのデータがなかったときどんなエラーがでるんすか

**デフォルトの名無しさん** · 2020/12/22(火) 23:40:20.45

ヌルポよりも大切なものを失います

**デフォルトの名無しさん** · 2020/12/23(水) 00:04:41.19

APIのレスポンスがnullじゃないはずなのにnullが返ってきたときどうしたらいいんですか

**デフォルトの名無しさん** · 2020/12/23(水) 19:38:57.98

nullsafe って言うのは Null チェックしなくていいという意味じゃないよ？
チェック必要なものと不要なものを区別して、必要なものはチェックしてからアクセスしないとコンパイルエラーになるんだよ？

**デフォルトの名無しさん** · 2020/12/24(木) 07:36:37.88

>>502
普通にnullチェック入れればいいんじゃないの？

**デフォルトの名無しさん** · 2020/12/24(木) 08:10:29.60

>>502
nullチェックしながら
APIの作者にバグレポート上げろよ。

**デフォルトの名無しさん** · 2020/12/24(木) 08:57:55.57

まずレスポンスのデータクラスのフィールドををnullableにしないといけない
nonnullでもコンパイルエラーならないのにだ

**デフォルトの名無しさん** · 2020/12/25(金) 09:41:57.24

何で companion object って一番下なんすか
一番上じゃ駄目なんすか

**デフォルトの名無しさん** · 2020/12/25(金) 11:57:59.25

kotlin世界との境界部分はもろもろを自分で気を付けるしかない

**デフォルトの名無しさん** · 2020/12/27(日) 23:41:45.31

>>507
文法的にはどっちでもいいよ

**デフォルトの名無しさん** · 2021/01/01(金) 17:03:56.74

kotlin/nativeでサーバーサイド作る話はどうなった？

**デフォルトの名無しさん** · 2021/01/02(土) 07:50:34.05

SuperJobだと、子の失敗は親に影響与えないとのことですが、子をキャンセルすると親もキャンセルされてしまうとのことです

子が失敗しようが、子をキャンセルしようが親に全く影響を与えたくないのですがどうすればいいでしょうか？

**デフォルトの名無しさん** · 2021/01/02(土) 08:31:31.17

SupervisorJobだった
つか、なんかややこしくなってきた
間違ってた、SupervisorJobは子のキャンセルは親に影響しないからスーパーなのか？

**デフォルトの名無しさん** · 2021/01/02(土) 12:00:19.22

間違ってた
子Jobのcacelメソッドによるキャンセルは親が普通のJobだろうがSupervisorJobだろうが親をキャンセルさせない

子JobがCacellationException以外の例外で失敗したとき、違いがでてくるのか

**デフォルトの名無しさん** · 2021/01/02(土) 13:51:40.78

おちつけ

**デフォルトの名無しさん** · 2021/01/07(木) 12:30:36.60

明けましておめでとうございます。
ことりんもよろしくお願いします。

**デフォルトの名無しさん** · 2021/01/07(木) 13:06:35.86

酉年にやれよ

**デフォルトの名無しさん** · 2021/01/08(金) 00:22:29.53

2029年までネタとして取っておこう…

**デフォルトの名無しさん** · 2021/01/08(金) 00:30:46.51

その時まで生きてるのかな、ことりん

**デフォルトの名無しさん** · 2021/01/08(金) 07:52:19.70

こぅのとぉりん生きてますよ

**デフォルトの名無しさん** · 2021/01/08(金) 08:38:56.45

ことりんじゅうさまです

なんてことならないように使っていこう

**デフォルトの名無しさん** · 2021/01/09(土) 09:13:47.78

例えばUserクラスがあって、userIdプロパティとネストしたUser型のuserプロパティがあります

このときList<User> users
から、users.map?とかcollection apiを使ってネストしたUserも含めたすべてのuserIdのリストを求める方法があれば教えて下さい

再帰関数を用意しないと無理?

**デフォルトの名無しさん** · 2021/01/09(土) 09:19:13.14

flatmap

**デフォルトの名無しさん** · 2021/01/09(土) 09:28:30.58

userプロパティは多段ネストする可能性があるんですがflatMapでいけましたっけ?

**デフォルトの名無しさん** · 2021/01/09(土) 15:43:34.22

プロパティをどう辿るかはcollection apiだけじゃどうにもならないから自分で実装するしかないでしょ
扱うデータによっては重複や循環なんかも考慮が必要かも

https://paiza.io/projects/JkGNST_vjmARbX8XFfMLnA

**デフォルトの名無しさん** · 2021/01/10(日) 00:59:41.08

>>521
そのロジックに意味のあるものならUserにallChildrenUser : List<User>メソッドを作って子のallChildrenUserを呼び出す、つまり再帰構造、allChildrenUser() -> users.flatmap{ it.allChildrenUser() }
かな

ネスト構造の時点で循環参照の可能性があるわけで言語機能でどうにかなる話とは違うと思う
または、データ構造として最適なツリーを採用したほうが良いかもしれん

**デフォルトの名無しさん** · 2021/01/10(日) 01:38:59.42

自分が出来ると心から信じることができれば必ずやれる

**デフォルトの名無しさん** · 2021/01/10(日) 20:09:18.30

言語機能でどうにかなるか否かはまた別の話でしょう
データが循環していたらスタックオーバーフローなりその他の例外なりが出るように標準ライブラリが設計されていればいいだけなので

**デフォルトの名無しさん** · 2021/01/10(日) 20:13:22.96

余談だけどグラフの探索は再帰を使わなくてもループに書き換えることができる
スタックオーバーフローしなくなるのが利点
ループではなく再帰でしか解決できないアルゴリズム問題が存在し得るかどうかは不勉強なので知らない

**デフォルトの名無しさん** · 2021/01/10(日) 20:31:18.39

再帰は必ずループに出来る

**デフォルトの名無しさん** · 2021/01/10(日) 21:54:19.01

クイックソートどうすんじゃ

**デフォルトの名無しさん** · 2021/01/10(日) 21:56:12.30

木の探索は横探索すればいいか
スタックのかわりにヒープがあふれる

**デフォルトの名無しさん** · 2021/01/10(日) 22:08:14.99

whileループでbreakすればいい

**デフォルトの名無しさん** · 2021/01/10(日) 22:25:02.75

flatmapで何でも解決できる

**デフォルトの名無しさん** · 2021/01/22(金) 13:56:01.26

じゃあflatmapで俺の資産を増やしてくれ

**デフォルトの名無しさん** · 2021/01/22(金) 14:36:13.50

flatmapと元気があれば何でもできる！

**デフォルトの名無しさん** · 2021/01/22(金) 20:45:59.10

Kotlin Roadmap
https://kotlinlang.org/roadmap.html

**デフォルトの名無しさん** · 2021/01/25(月) 06:26:23.02

>>534
理論上はflatmapで何でも解決できるとしても、実装するには十分な数学的能力が必要なのだ。

**デフォルトの名無しさん** · 2021/01/25(月) 18:04:21.90

>>537
そうか。じゃあお前なら出来るんだな。任せたぞ。

**デフォルトの名無しさん** · 2021/01/25(月) 22:47:14.88

プログラミングは
気合いだ

たとえば１万件のソートをするのに
処理のオーダーがどうとか
クイックソートのライブラリがないとか
代替するものをつくるかどうかとか
悩むときに

Ｅｘｃｅｌにはっつけたり
２重ループで平気で馬鹿ソートする
周囲の嘲笑をものともしない決断力

そういうやつができるやつなんだ

**デフォルトの名無しさん** · 2021/01/26(火) 08:07:03.00

>>539
そういう能力の人は便利屋として安い単価で使い捨てられるだけです

**デフォルトの名無しさん** · 2021/01/26(火) 11:42:19.41

いうほどflatmap使うか？
そりゃたまには使うけどさ

**デフォルトの名無しさん** · 2021/01/26(火) 12:25:48.83

1万件程度なら普通にExcelも使うし
バカソートも使う

もちろん製品コードではそんな事はないけど

**デフォルトの名無しさん** · 2021/01/26(火) 20:08:03.52

flatmapが世界を救う

**デフォルトの名無しさん** · 2021/01/26(火) 20:21:56.10

flatmapはステータスだ！

**デフォルトの名無しさん** · 2021/01/27(水) 16:58:07.84

!!って基本的に使うべきでないんですかね

**デフォルトの名無しさん** · 2021/01/27(水) 23:12:27.62

>>538
STモナドの中に入れたら増やせそうな気がするが、取り出せなくなるけどいい?

**デフォルトの名無しさん** · 2021/01/27(水) 23:15:32.07

>>545
簡易的なアサーションとして理解した上でNPEが出てほしい場合は使っていいよ
知らない間に大事な処理が実行されずスルーされたりするよりも、バグなのでとっとと例外を出して知らせてほしい場合とかね

https://kotlinlang.org/docs/reference/null-safety.html
> Thus, if you want an NPE, you can have it, but you have to ask for it explicitly, and it does not appear out of the blue.

**デフォルトの名無しさん** · 2021/01/28(木) 09:16:46.22

kotlinではnullチェックの代わりに?.を使うべきですか

**デフォルトの名無しさん** · 2021/01/28(木) 09:54:30.26

nullチェックと一口に言ってもバリエーションを考えないとだめ
nullなら何もしない
nullなら空白で表示する
nullならハイフンで表示する
nullなら代替手段で値を取りに行く
nullならログを吐いてフォールバックする
nullならフェイルファストで例外を出す

?.は上記のうちの一部に最適ではあるものの、一部には役に立たない
実現したいことや状況に沿った措置が先にあり、それをコードで表現するために適した言語機能を選ぶという順序で考えるべき

**デフォルトの名無しさん** · 2021/01/28(木) 12:36:53.48

nullなら割り込み禁止してその場で無限ループ

**デフォルトの名無しさん** · 2021/01/29(金) 15:21:19.10

Kotlinって、SwiftやRuby以上にWindows切り捨て感があるのな

**デフォルトの名無しさん** · 2021/01/29(金) 16:40:33.72

そう？

**デフォルトの名無しさん** · 2021/01/29(金) 22:17:24.41

やっぱSwiftやRubyの方がひどいか・・・・

**デフォルトの名無しさん** · 2021/01/30(土) 13:36:04.18

>>551
なんでそう思うの？
普通にJVMだからむしろWindowsに優しい方の言語だと思うけど。
Rubyなんて酷いものだろう。。

**デフォルトの名無しさん** · 2021/02/16(火) 22:13:20.25

ねこ

**デフォルトの名無しさん** · 2021/02/20(土) 08:00:32.70

過疎なんか？

**デフォルトの名無しさん** · 2021/02/21(日) 22:47:03.15

TornadoFXが終わってしまったっぽい。

**デフォルトの名無しさん** · 2021/02/22(月) 03:31:15.20

>>553
そもそもその2つもそれぞれMacとUNIX系のことしか考えてないってだけで切り捨て云々以前の話

**デフォルトの名無しさん** · 2021/02/22(月) 07:50:49.54

>>557
最初だけ話題になったけどすぐ話聞かなくなったもんな

**デフォルトの名無しさん** · 2021/02/24(水) 06:00:45.34

>>559
TornadoFXで作ったソフトウェアがあるんだが、Java8の終了と共に沈めるしかないか…

**デフォルトの名無しさん** · 2021/02/24(水) 15:55:29.28

これから覚えようと思ったのに・・・