Kotlin 6

**デフォルトの名無しさん** · 2019/06/22(土) 15:59:57.23

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

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

**デフォルトの名無しさん** · 2020/03/23(月) 08:53:23.76

NullObjectパターン使ったライブラリーとかほとんどみかけないから...
もうここまで言えば後はワカルナ?

**デフォルトの名無しさん** · 2020/03/23(月) 09:58:46.34

GetParentやGetMenuでnullチェックを忘れたらヌルポ
それを万が一忘れてもコンパイルエラーにしてくれるのがNullable

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

>>871
c言語の悪癖に冒されているだけだろ。

「マジックナンバーは悪」というのは常識だろうにマジックナンバー的にnullを使う設計者の気が知れんわ。

**デフォルトの名無しさん** · 2020/03/23(月) 13:08:13.26

ここの住人って全員Androidアプリの開発者？

**デフォルトの名無しさん** · 2020/03/23(月) 14:27:37.30

Springもいるんじゃない？
小規模だけど去年bootで案件やったよ

**デフォルトの名無しさん** · 2020/03/23(月) 23:43:05.45

>>873
Keep It Simple.

NULLで現実に全く問題ないのに、NullObjectを導入することで新たな問題をむしろ入り込む余地が生まれる。
Polymorphism というが、「親Windowが無い」「Menuが無い」のような劇的な変化
は、Polymorphismでやるより、その場で if 文で場合分けするほうがプログラミングし易い。

例えば、Polymorphismに向いているのは、動物の種類を分けるようなときで、
「動物そのものが存在しない」時には向いていない。
後者は、if文無しで対処するより、本文の方でif文をちゃんと書いて場合分けした方が間違いが
生じにくくなるし、コード量も少なくなる。
だからNullObjectを使って、NullObject自身に処理を行わせて本文にはif分を使わないより、
ちゃんと本文にif文を書く方が適切なのだ。
仮にNullObjectを使っても結局、本文に if ( pMenu == &NullObject ) などという if 文を
書いてしまっては、Polymorphismにはならないし。

**デフォルトの名無しさん** · 2020/03/23(月) 23:59:37.49

KotlinはNullObjectよりnull推奨で
そのための前提として構文レベルで区別するための仕組みがある

x,yなのかrow,colなのか順番分からんから名前付き引数使うとか
どのオーバーロードが呼ばれるかとか

そういうのも区別出来るかどうかという似たような話になる

**デフォルトの名無しさん** · 2020/03/24(火) 00:18:55.74

>>873
NULLは、「無い」という真空状態のようなものに対応している。
(古典物理学的にはだが原則的に)真空は唯一のものであるから、
親ウィンドウがないことと、Menuがないことで、別の真空が存在する
わけではなく、唯一無二の真空で十分だとも考えられる。
それとマジックナンバーでは全く異なる、
マジックナンバーが問題なのは、後で修正しようとした時に簡単に修正できないことや、
その意味での定数を使っている場所をgrep検索で発見できないことだ。
親ウィンドウやMenuが無い事をgrep検索する必要はないし、「無い」状態を
簡単に修正する必要もない。WindowNullやMenuNullと区別した所で何か便利になる
可能性は低い。
マジックナンバーとは、
int TOMATO_PRICE = xxx;
int NUMBER_OF_TOMATO = xxx;
・・・
int TOTAL_PRICE = TOMATO_PRICE * NUMBER_OF_TOMATO + CAROT_PRICE * NUMBER_OF_CAROT;
みたいにしてから、
func(TOTAL_PRICE);
とするのと、いきなり合計価格を計算してしまった結果だけを使って
func(4032);
などとするのでは大きく分かり易さも訂正し易さも変わってくると言うことだ。
この場合、TOMATOの一個当りの値段を変えたり、個数を変えたりすることが、4032という数値では
簡単に修正できなくなってしまうのだ。
そのような問題点は、NULLにはない。

**デフォルトの名無しさん** · 2020/03/24(火) 00:35:30.02

Kotlinってnullableを使っても安全だし
NullObjectも書きやすいんだよなあ
sealed classならNullObjectがこの上なく簡単に定義できて
whenで受けたときプログラマーが分岐を漏らさないようにコンパイラが教えてくれる
スマートキャストも安全で便利だ

**デフォルトの名無しさん** · 2020/03/24(火) 00:44:02.15

古いものが大好きなnull爺にこの話を教えてやろう
Kotlin公式ドキュメントからリンクされてる学習者には有名なエピソードだ
nullポインタを発明したのは、クイックソート等の数々のアルゴリズムを発明し、C言語の源流にもなったALGOLを実装した天才トニー・ホーア氏
彼は近年こう回顧し謝罪している

>それは10億ドルにも相当する私の誤りだ。null参照を発明したのは1965年のことだった。
(中略)
>私は単にそれが容易だというだけで、無効な参照を含める誘惑に抵抗できなかった。これは、後に数え切れない過ち、脆弱性、システムクラッシュを引き起こし、過去40年間で10億ドル相当の苦痛と損害を引き起こしたとみられる。

**デフォルトの名無しさん** · 2020/03/24(火) 01:42:20.76

>>880
偉いとされる人が言った、または、有名な団体が作ったようなものを無条件で信じるあなたのような権威主義者が多いだけ。
有名な所が出してきたものは初期の衣の凄くもてはやされる。
使ったこともちゃんと学んだことも無いのに多くの人が褒めちぎる。
それはなぜかというと、そうすることで自分が新しいものに追いついていると
人に錯覚させることが出来ると思い込んでいるからだ。
実際には何も知らないくせに適当に新しいものを褒めているだけ。

**デフォルトの名無しさん** · 2020/03/24(火) 01:45:43.46

Rustスレも荒らしてるので無視しとけ

**デフォルトの名無しさん** · 2020/03/24(火) 03:32:39.53

null自体が問題なんじゃなくて、既存の言語の型システムでnon nullableな参照型がないのが問題なだけ。ごっちゃにしすぎ。

**デフォルトの名無しさん** · 2020/03/24(火) 03:41:54.20

だから、null自体はあった方が便利、ただ、型システムの方で値型だろうが参照型だろうがnullable、non-nullableの両方定義できるようにしとけってだけ

**デフォルトの名無しさん** · 2020/03/24(火) 07:51:18.66

もういい加減別スレ作ってそっちでやってくれ

**デフォルトの名無しさん** · 2020/03/24(火) 08:13:59.70

>>880
その失敗の本質は、いつでもnullポインタを入れられてしまうことだよ

Nullableの元でもあるHaskellのMaybeモナドやScalaのOptionモナドは
無効を表現出来るが何ら脆弱と見られていない

KotlinのNullableは効率のため単なる参照型変数にコンパイルされるが
プログラム上は以下のようなコンテナと概念的には同じ

sealed class Nullable<T> {
open val isNull:Boolean get() = true
open val value:T get() = throw NullPointerException()
}
class Some<T>(override val value:T): Nullable<T>() {
override val isNull:Boolean get() = false
}
class None<T>: Nullable<T>()

**デフォルトの名無しさん** · 2020/03/24(火) 08:34:24.48

>>876
自分勝手な論理展開が多くて議論にならんね。

ここはkotlinスレだし、「javaではヌルポのトラブルが多い」という事実を無視した主張はクソの役にも立たない。
「ヌルポのトラブルを避けるためにはどうしたらいいか」くらい考えたら？じゃなきゃスレ違いだからNGにするわ。

そういや、>>870にヌルポの観点が抜けてるな。追加すると、
・変数の初期化ミスで変数にデフォルト値(null)が入っていても、意図しない(親無しウインドウでの)呼び出しにならない。

**デフォルトの名無しさん** · 2020/03/24(火) 09:26:10.10

お前らの人生はnullみたいなもんだわ

**デフォルトの名無しさん** · 2020/03/24(火) 12:12:39.00

ぬぬるぬるやで

**デフォルトの名無しさん** · 2020/03/24(火) 12:12:56.90

ぬ多い

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

>>888
お前の人生は違うの？

**デフォルトの名無しさん** · 2020/03/24(火) 12:48:34.07

けんかはおやめABC

**デフォルトの名無しさん** · 2020/03/24(火) 14:08:56.84

いい加減レス違いですよ

**デフォルトの名無しさん** · 2020/03/24(火) 21:20:41.36

Kotlin 1.4-M1 Released
https://blog.jetbrains.com/kotlin/2020/03/kotlin-1-4-m1-released/

**デフォルトの名無しさん** · 2020/03/25(水) 19:58:41.50

初めてAndroidアプリ作成の案件に携わってるけどクソOSクソ端末に対応するコスト無駄すぎるな
イライラするわ

**デフォルトの名無しさん** · 2020/03/25(水) 20:11:20.32

テスト用に全ての実機用意するとかマジで有り得ん

**デフォルトの名無しさん** · 2020/03/25(水) 22:13:46.30

全ての実機ってどんだけ集めたんだ？

**デフォルトの名無しさん** · 2020/03/25(水) 23:23:26.21

ガラケー時代は中古もかき集めてやってたな

**デフォルトの名無しさん** · 2020/03/25(水) 23:47:54.47

>>895
それを判断するのは社長
現場のお前じゃない

**デフォルトの名無しさん** · 2020/03/25(水) 23:51:58.92

社長て

**デフォルトの名無しさん** · 2020/03/26(木) 07:47:41.98

>>899
働いたことなさそう

**デフォルトの名無しさん** · 2020/03/26(木) 07:52:36.00

まぁあれな感じのあれだけど、変に煽るのやめろ、誰も得しない

**デフォルトの名無しさん** · 2020/03/26(木) 09:15:47.51

まあ先に煽ってるのは向こうだししょうがない

**デフォルトの名無しさん** · 2020/03/26(木) 11:30:29.60

>>901
社長したことなさそう

**デフォルトの名無しさん** · 2020/03/26(木) 12:45:41.29

社長（自営業

**デフォルトの名無しさん** · 2020/03/30(月) 12:29:37.34

サーバーサイドkotlinを導入したいんだが、なんて言って上司を説得するのがいいと思う？
上司は昔java1.6やってたくらい。

**デフォルトの名無しさん** · 2020/03/30(月) 12:36:40.55

言語云々を論点にしてはいけない
「技術選定も含めて俺に任せてくれ」だ
お前の全責任においてお前が成果を出せば誰も文句は言わない
それができないんなら黙って前例踏襲してなさい

**デフォルトの名無しさん** · 2020/03/30(月) 15:01:23.30

すまん。ちょっと聞き方悪かったわ。
単純にメリデメ教えてくれって言われたらなんて答える？

**デフォルトの名無しさん** · 2020/03/30(月) 16:14:25.46

ライブラリが同じなのでフツーのJava経験者なら3日もあれば習得できます
開発環境にJavaのソースをコピペすると自動変換もできます
null参照はコンパイラーが検出してくれる言語仕様なのでnullに関するバグを排除できます
ちなみにA案件でのnull参照バグは全体のxx%でした
Java14で計画されている言語仕様の改善も全て先取りしているので開発効率が上がります
中でもrecord型の先取りにより開発規模がA案件試算でxx%削減できます

ほかに口説き文句あれば俺も知りたい

**デフォルトの名無しさん** · 2020/03/30(月) 18:20:58.26

>>907
クッソ頭悪いだろお前
説得する材料くれって言う要件に対してその回答はあまりにも的外れだわ

**デフォルトの名無しさん** · 2020/03/30(月) 18:30:16.30

Kotlin採用していただけないのなら辞めますといえば一発や。

**デフォルトの名無しさん** · 2020/03/30(月) 18:40:18.84

自分にとってどういうメリットがあるのかと
そのメリットが既存のものを捨てて乗り換えるコストを上回りそうかどうかという
2点をクリアしないと普通の人は新しいものを導入しようって気持ちにはならない

2つとも個々の状況によるものだから
現状の問題点や比較対象無しに聞いてもフワッとしたものしか返ってこないと思う

**デフォルトの名無しさん** · 2020/03/30(月) 19:38:12.89

上司「小鳥飼いたいのか？」

**デフォルトの名無しさん** · 2020/03/30(月) 19:57:32.43

ウザっ

**デフォルトの名無しさん** · 2020/03/30(月) 20:58:19.14

javaの仕様に追従してる層にならメリットは説明できるけど、そうじゃない層に説明するのは難しい。。
実際、アドバイスくれてる人の説明もjavaの辛みが分かってこその主張だと思う
なんかjava1.6で止まってる人にも分かりやすいメリットないかな。。

ちなみに上司は、人の集めづらさを懸念をしてるだけで、本格的に反対してる訳では無い。純粋にメリット何？って感じ

**デフォルトの名無しさん** · 2020/03/30(月) 21:25:01.20

>>906
ここは一つネガキャンで。「KotlinがあるのにJavaをやるのは、JavaがあるのにCをやるようなもの。」
ただ、上司がJava至上主義者なら、「Cなんかと一緒にするな!!」と激怒するおそれあり。

**デフォルトの名無しさん** · 2020/03/30(月) 22:39:22.47

そろそろ転職しようと思ってたんだがコロナの影響でエンジニアの求人は減ってるの？まだ待った方が良い？

**デフォルトの名無しさん** · 2020/03/30(月) 23:14:36.65

プログラマとエンジニアは別物なので、まずその辺の違いをハッキリさせたほうがいい

**デフォルトの名無しさん** · 2020/03/31(火) 01:21:29.69

でも、もしJavaならバージョンいくつ使うつもり?
そこどこ新しめJavaならそこまで苦痛にならんぞ
1.6ぐらいと比較して俺のペインポイントだったローカル変数の型推論もあるし、ラムダもあるし、コレクションのストリーム操作もあるし。

大きめの機能でasync/awaitないけど

**デフォルトの名無しさん** · 2020/03/31(火) 01:22:07.78

そこそこ新しめ*

**デフォルトの名無しさん** · 2020/03/31(火) 01:23:36.87

あぁもちろんnull safetyもあるが

**デフォルトの名無しさん** · 2020/03/31(火) 12:30:43.25

>>911
一発で辞めることができたりして

**デフォルトの名無しさん** · 2020/04/02(木) 00:15:49.69

Kotlinのdata classがJava14でrecordとして採用されると聞いて感動したのも束の間、まだPreviewなので正式採用はJava16辺りと知り気が遠くなった
誰もが普通に使えるようになるのは2026年頃じゃろか

**デフォルトの名無しさん** · 2020/04/02(木) 01:51:56.87

半年毎にアップデートだからJava16は1年後

**デフォルトの名無しさん** · 2020/04/02(木) 02:07:24.43

誰もが普通にと書いたのはJava11の延長サポートが2026までだから遅い現場だとそこまで待つかなと
でもそれを言うなら8は2030まで延長できるんだった

**デフォルトの名無しさん** · 2020/04/03(金) 06:46:06.71

>>919
ラムダ式とOptionalで行けるのではと思っていた時代が、私にもありました。
ただ参照透過なプログラミングをしようとした途端、Listと配列がMutableなことが越えられない壁になる。
Java9から不変リストを作るList.of()があるけど、必要なのは実行時エラーでなくコンパイルエラーで教えてくれる不変リスト。

**デフォルトの名無しさん** · 2020/04/03(金) 09:39:44.79

それを言ったらKotlinのListも不変リストではなく読み取り専用のビューなので同じなのでは

**デフォルトの名無しさん** · 2020/04/03(金) 09:41:24.03

いや追加や更新機能のないリストインターフェースが欲しいということか

**デフォルトの名無しさん** · 2020/04/12(日) 01:08:01.34

Windows 10 で IntelliJ IDEA を 2020.1 にアップデートしたら起動後にちゃんと動かなかった。
ウインドウは出るがその中が灰色のまま。右下に赤いやつが点滅していてマウスカーソルを
持って行ってクリックすると IDE Internal Error Occurred See Details and Submit Report と
出てくるが、Detail も何も出てこない。ウィンドウの右上の×を押しても終わらず、しょうがない
のでタスクマネージャで終了させた。

Community edition だが、試しに Ultimate の同バージョン方をインストールしたら動いた。
ま、しかし、ライセンスあるわけではないのでとりあえず Community edition の 2019.3.4 に
しておいた。これはちゃんと動く。

**デフォルトの名無しさん** · 2020/04/14(火) 10:52:23.60

javaすらやったことない人におすすめのKotlinの参考書ありますでしょうか？

**デフォルトの名無しさん** · 2020/04/14(火) 11:07:51.69

Javaやれ

**デフォルトの名無しさん** · 2020/04/14(火) 11:14:48.92

今更古いものを勉強するのは嫌です

**デフォルトの名無しさん** · 2020/04/14(火) 11:22:31.52

ネットで調べりゃすぐでてくんだろ

**デフォルトの名無しさん** · 2020/04/14(火) 11:31:09.72

Kotlinは腐りきったJavaをなんとか少しでも便利に使うための車椅子のようなもの
古いのを勉強したくないならKotlin含めJava系の世界に飛び込むこと自体を考え直してもいいんじゃないかな

**デフォルトの名無しさん** · 2020/04/14(火) 11:35:17.73

屁理屈は良いので参考書を教えて下さい。

**デフォルトの名無しさん** · 2020/04/14(火) 11:35:46.91

ダメだこいつ

**デフォルトの名無しさん** · 2020/04/14(火) 20:35:17.70

だめかなあ

**デフォルトの名無しさん** · 2020/04/14(火) 21:14:44.96

当然、日本ユーザー会会長の太郎本！
Kotlinスタートブック -新しいAndroidプログラミング、長澤太郎、2016

スッキリわかる Java入門第2版、2014

超有名なスッキリを読んでないと、オブジェクト指向が分からないのでは？
Ruby をやってれば、オブジェクト指向・メソッドチェーンによる関数型と、両方とも理解できるけど

**デフォルトの名無しさん** · 2020/05/01(金) 08:16:22.65

>>930
C++, C#, Java, Swift, Rubyみたいなモダン言語の経験が無いと、Kotlinは難しいかも。

1. Clousure
2. Generics
3. Type Annotation Estimation
4. Collection
5. protocol

こう言うのが意味不明となる。
OOP自身は難しく無い。

**デフォルトの名無しさん** · 2020/05/01(金) 09:25:47.40

全然関係ないんだけどさ

前々から思ってたんだが
「モダン」って言い方になんか古臭さを感じるんだよな
大正時代的な
他に良い呼び方ってないもんだろうか

**デフォルトの名無しさん** · 2020/05/01(金) 09:32:44.13

ダイナミックレンジですねわかります

**デフォルトの名無しさん** · 2020/05/01(金) 09:41:54.27

>>939
>3. Type Annotation Estimation

なんのこっちゃ？

**デフォルトの名無しさん** · 2020/05/01(金) 10:56:25.01

>>942
Type inference

**デフォルトの名無しさん** · 2020/05/01(金) 10:58:18.55

>>940
最新新言語、State of Arts computer language、Advanced Language、Recent Language、Up-to-date Language

御好きにすれば！

**デフォルトの名無しさん** · 2020/05/01(金) 11:12:14.62

プロトコルってどういうの？

**デフォルトの名無しさん** · 2020/05/01(金) 11:51:29.93

>>945
俺もそれ聞きたいな

**デフォルトの名無しさん** · 2020/05/01(金) 12:19:40.77

>> 440
意識高い系言語でいいんじゃね

**デフォルトの名無しさん** · 2020/05/01(金) 12:20:45.98

>>946
such like Interface in Java or Abstruct Class in C++

**デフォルトの名無しさん** · 2020/05/01(金) 13:01:44.47

>>948
機能的に違いないのに、名前だけ別のものつけたん？

**デフォルトの名無しさん** · 2020/05/01(金) 13:06:28.96

>>948
理解しました

**デフォルトの名無しさん** · 2020/05/01(金) 13:13:27.88

>>940
日本人的には大正モダンでハイカラなイメージが強いけど、英単語のmodernにそんなニュアンスはないんだから直訳でモダンでもイイでしょ
アートやインテリアではモダンって普通に使うし

**デフォルトの名無しさん** · 2020/05/01(金) 13:16:50.04

モダンExcelなんていう言葉を最近聞いたよ

**デフォルトの名無しさん** · 2020/05/01(金) 15:33:32.05

>>949

1. 違いない
2. 似ている
3. 同じ

これらは、全く異なる意味を持っている。

**デフォルトの名無しさん** · 2020/05/01(金) 16:45:14.68

>>953
ありがとう
知らないなら普通にそう答えてくれればいいのに

**デフォルトの名無しさん** · 2020/05/01(金) 16:54:21.95

>>948
この業界ではよくあること

**デフォルトの名無しさん** · 2020/05/01(金) 18:17:15.79

>>940
ナウいヤングな君は和製英語の事は忘れて英語の modern を思い浮かべなさい。

**デフォルトの名無しさん** · 2020/05/02(土) 04:45:48.24

アマゾンで検索したら7/17発売予定の本が見つかった。表紙デザインもまだ出てこない。

基礎からわかる Kotlin
富田健二 (著)

単行本: 224ページ
出版社: シーアンドアール研究所 (2020/7/17)
言語: 日本語
ISBN-10: 4863542917
ISBN-13: 978-4863542914
発売日： 2020/7/17

アマゾンのURL書くとここに書き込みできないのでヨドバシのURL書いておく。
https://www.yodobashi.com/product/100000009003256396/

**デフォルトの名無しさん** · 2020/05/02(土) 10:00:39.97

モダンと言えばモダン焼きが思い浮かぶな

**デフォルトの名無しさん** · 2020/05/02(土) 15:59:26.40

>>958
大阪人臭い、俺はだんぜん考える人だな

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

ガチで間違えたのかネタで言ったのか分かりにくい

**デフォルトの名無しさん** · 2020/05/02(土) 20:00:00.13

10秒ぐらい考え込んでフリーズした。

**デフォルトの名無しさん** · 2020/05/03(日) 08:14:29.07

思考回路はショート寸前

**デフォルトの名無しさん** · 2020/05/03(日) 21:30:39.85

>>962
今すぐ会いたいよ

**デフォルトの名無しさん** · 2020/05/04(月) 05:41:02.53

>>957
その出版社の本、本のサイズの割に字が小さくて、読みにくいんだよね。

**デフォルトの名無しさん** · 2020/05/04(月) 20:57:12.28

プロトコルってなんなのかよくわからんからググったんだけどさ
Swiftだと主に構造体を使うことになっていて！？構造体にも適用できるインターフェイスがプロトコルってことなのか？
もしそうだとしたら、構造体が主流じゃないKotlinにプロトコルがあろうがなかろうがほとんど変わらん気がするが・・・・

**デフォルトの名無しさん** · 2020/05/04(月) 21:27:04.79

プロトコルとインターフェースは呼び名が違うだけ

JavaのインターフェースはObjective-Cのプロトコルを真似して違う名前を付けたもの
SwiftはObjective-Cからプロトコルという名前をそのまま受け継いでる

**デフォルトの名無しさん** · 2020/05/05(火) 04:39:20.00

>>966
まじで？>>948は冗談で言ってるんだと思ったぜ・・・・

**デフォルトの名無しさん** · 2020/05/05(火) 06:35:08.05

Interfaceって機能がなぜ必要？

1. Super1, Super2を多重継承したDerived ClassからSuper1, 2に共にあるfooメンバにアクセスすると、Super1.foo, Super2.fooのどちらが呼ばれる？

2. この問題を回避するには、多重継承を禁止すれば良い(菱形継承問題、Diamond Problem)

3. もう一つの解決方法は、宣言しか実装していないClass(Interface, Prototype, Abstruct Class, Module)を使えば良い。

この理解でOK?

**デフォルトの名無しさん** · 2020/05/05(火) 06:40:25.13

>>968
具体例

図形 -> 四角形 -> 平行四辺形 -> 長方形
平行四辺形 -> 菱形

こう言うClass Hierarchyがあった時に
長方形 -> 正方形
菱形 -> 正方形

なる正方形を作りたい。

こんな時に、Diamond Problemが発生。

**デフォルトの名無しさん** · 2020/05/05(火) 06:47:50.54

>>969
[菱形継承問題 - Wikipedia](https://ja.wikipedia.org/wiki/%E8%8F%B1%E5%BD%A2%E7%B6%99%E6%89%BF%E5%95%8F%E9%A1%8C)

俺も昔、C++のvirtual ってなんだ？って日々を過ごした。
e.g.
class B: virtual public A