X
Kotlin 6
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん
垢版 |
2019/06/22(土) 15:59:57.23ID:zj+KJbMh
JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう

※前スレ
Kotlin 5
https://mevius.5ch.net/test/read.cgi/tech/1544268581/
0851デフォルトの名無しさん
垢版 |
2020/03/21(土) 14:00:49.01ID:txJMIm7g
なんでも古い古いと言っていれば、どんなに駄目でも新しい言語や若い人が有利になってしまう法則。
0852デフォルトの名無しさん
垢版 |
2020/03/22(日) 04:45:41.69ID:HvrypJyW
引数の個数や型だけが異なる「関数の多態性」を行うと、プログラムが間違い易くなる。
なぜなら型や引数の個数の書き間違いをコンパイラが報告してくれなくなることがあるから。
C/C++で型が導入されたのもそういう間違いをコンパイラに発見してもらうためも有ったが、それが働きにくくなってしまう。
0853デフォルトの名無しさん
垢版 |
2020/03/22(日) 04:50:38.77ID:HvrypJyW
>>852
一つの関数名に引数の型や個数が異なる関数が10種類くらい多重定義されていたとする。
これを使ったプログラムする際には、マニュアルを見、関数名だけでなく引数も非常に正確に書かなくてはならなくなる。
型や引数の順序や個数などが僅かでも間違っていると、自分が思っていたのとは違う定義のものが呼び出されてしまうことになるが、それでも「合法」になってしまうのでコンパイラがエラーを出してくれない。
また、後から動作を調べようと思ってマニュアルを見たときにも、見間違いで間違った定義の部分の説明を読んでしまう現象が生じ易くなる。
0854デフォルトの名無しさん
垢版 |
2020/03/22(日) 04:56:18.54ID:HvrypJyW
>>853
func(1,2);
と書いたつもりで、タイプミスなどで
func(1,2,0);
と書いたとしよう。
func()が多重定義されていない場合なら、コンパイラがエラーを出してくれる。
ところが、func()が多重定義されてしまっている場合、たまたま、3つの整数引数の定義があった場合、自分の思ったのとはかなり違う動作の関数なのに、コンパイラが何もエラーを出してくれなくなってしまうことが有り得る。

それから、知らず知らずに「引数の自動型変換」機能が働いてしまうことが有り得る。
それと関数の多重定義の両方が組み合わされると、自分が思っていたのとはかなり
違う動作の関数が間違って呼び出されることになっていても、気づくことができない。
本当はどの関数が呼び出されているのかが分からず、どんなにチェックしても原因が分からない難しいバグが入ってしまうことになるかもしれない。
0856デフォルトの名無しさん
垢版 |
2020/03/22(日) 08:47:08.62ID:sfJQKmPV
技術的な話でスレが進むのは、過疎ってるよりは良いことだよ
ほぼ読んでないから内容は知らんけど
0857デフォルトの名無しさん
垢版 |
2020/03/22(日) 09:31:29.37ID:nwybfWiz
>>854
その話は、引数爆発は嫌だ、じゃあデフォルト引数使え、で解決してるだろ
さらに付け加えるなら名前付き引数も使え
そのあたりのCやJava時代の弱点をKotlinやC#は克服済みだ
あと多重定義は多態とは呼ばない
0858デフォルトの名無しさん
垢版 |
2020/03/22(日) 09:32:27.12ID:nwybfWiz
>>854
たまたま同じ型ばかりを引数にとる関数で順番を間違えるヒューマンエラーには配慮できるのに、nullを多用したときに誰かがミスして実行時エラーが多発するリスクに目を向けないのは何故？
0861デフォルトの名無しさん
垢版 |
2020/03/22(日) 11:43:59.28ID:F4lre3ad
>>853
ほんそれ
同じように思ってた人が居て良かった
0862デフォルトの名無しさん
垢版 |
2020/03/22(日) 12:55:36.51ID:q5xwUBc3
>>853
混同するのが危険なほど挙動が違うのなら、そもそも同じ関数名を使うべきじゃない。
関数・クラス設計における命名規則の問題だろ。言語設計(javaのヌルポ)の問題と関係ない。

この主張が、なんで型なしnullのマジックナンバー利用の肯定に繋がると考えているの？
0863デフォルトの名無しさん
垢版 |
2020/03/22(日) 15:36:31.56ID:HvrypJyW
>>857
「ポリモーフィズムは次のようないくつかの種類に分けられる：

・アドホック多相（Ad hoc polymorphism）：ある関数が、異なる型の引数に対してそれぞれ異なる実装を持つ場合。多くのプログラミング言語で関数の多重定義としてサポートされる。
・XXXX
・XXXX
・・・
」
0864デフォルトの名無しさん
垢版 |
2020/03/22(日) 15:39:40.53ID:HvrypJyW
>>858
親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
「親がない」こと以外に意味を取りようがないから。
同様に、メニューオブジェクトへのポインタをNULLとした場合も、
「メニューがない」こと以外に意味を取りようがないので分かり易い。

それに比べて、関数を多重定義した場合には、ミスによってとんでもない動作をしてしまうことが有り得る。
0866デフォルトの名無しさん
垢版 |
2020/03/23(月) 01:38:55.49ID:bf1cRh+B
>>865
この例の場合、NULLにすると、それぞれ親Windowがない場合、Menuがない場合で、どちらも重要なので、さすがにテストしてあるはずなのだ。
この例に限らず、引数にNULLを指定する場合は、そのような「重要な変化」をもたらす事が多いので、必ずテスト済みの場合が多い故に安全なことが圧倒的多い。
0867デフォルトの名無しさん
垢版 |
2020/03/23(月) 02:26:57.24ID:dalJ4OEg
>>864
何を言いたいのか全然わからん。

NULLの利点は親Windowの指定方法だと言っているのに、
>>854だと全く関係のない関数funcでoverloadに問題があると言っている。
自分の主張に沿うようにいいとこ取りしすぎ。

同じケースでNULL利用の利点とoverloadの欠点を比較しろよ。

>親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
nullよりも"NoWindow"というNullObjectを定義して使ったほうが意味はわかりやすい。
なんでnullを使わなきゃいけないのかね？
0868デフォルトの名無しさん
垢版 |
2020/03/23(月) 02:48:11.59ID:bf1cRh+B
>>867
後半、NULLで十分なのに敢えて、NoWindow なんてオブジェクトを定義する必要
を感じない。それでバグが減るわけでもないし。
0869デフォルトの名無しさん
垢版 |
2020/03/23(月) 03:14:15.98ID:6F6bSuZt
>>866
それは言い換えると、nullを安全に使えるのはテストのパターン漏れがあり得ないような重要な変化があるところに限られ、それ以外で使うと安全とは言えないってことだよな
「安全なことが多い」ってのは危険は残っていると認めてるね
「さすがに〜はず」ってのは希望的観測だし、最後の文だけ「圧倒的」を付け足したのも論拠不足だよな
人は多重定義で引数順を間違えるような凡ミスをすると理解できているんだ
では人が重要ではない甘いところでnullを不用意に使ってしまうミスは当然あるよな
0870デフォルトの名無しさん
垢版 |
2020/03/23(月) 08:20:48.10ID:E0UAbPRX
>>868
前半の準備できてから議論続けてね。


>「必要を感じない。」

それは個人の感想なので、主張としては弱くて役に立たないですね。

・メソッドを使う時に「NoWindow」であることをより明確化できる。
・間違えて「NoWindow」を指定してもnullより目立つので間違いに気づきやすい。
・名称がより明確なので、第三者がソースコードを読む時に読みやすい。
・それ専用に定義された変数に入っているので、IDEの支援を受けやすい。
・このケースだと必要性は薄いが、nullの意味が複数あるような場合でも(null,undefineなど)別々に定義できる。

くらいの利点はあるけど？
0871デフォルトの名無しさん
垢版 |
2020/03/23(月) 08:53:23.76ID:7Cqb7CJ8
NullObjectパターン使ったライブラリーとかほとんどみかけないから...
もうここまで言えば後はワカルナ?
0872デフォルトの名無しさん
垢版 |
2020/03/23(月) 09:58:46.34ID:iyDg9ARV
GetParentやGetMenuでnullチェックを忘れたらヌルポ
それを万が一忘れてもコンパイルエラーにしてくれるのがNullable
0873デフォルトの名無しさん
垢版 |
2020/03/23(月) 12:12:09.69ID:E0UAbPRX
>>871
c言語の悪癖に冒されているだけだろ。

「マジックナンバーは悪」というのは常識だろうにマジックナンバー的にnullを使う設計者の気が知れんわ。
0876デフォルトの名無しさん
垢版 |
2020/03/23(月) 23:43:05.45ID:bf1cRh+B
>>873
Keep It Simple.

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

例えば、Polymorphismに向いているのは、動物の種類を分けるようなときで、
「動物そのものが存在しない」時には向いていない。
後者は、if文無しで対処するより、本文の方でif文をちゃんと書いて場合分けした方が間違いが
生じにくくなるし、コード量も少なくなる。
だからNullObjectを使って、NullObject自身に処理を行わせて本文にはif分を使わないより、
ちゃんと本文にif文を書く方が適切なのだ。
仮にNullObjectを使っても結局、本文に if ( pMenu == &NullObject ) などという if 文を
書いてしまっては、Polymorphismにはならないし。
0877デフォルトの名無しさん
垢版 |
2020/03/23(月) 23:59:37.49ID:Kfc9ZaIq
KotlinはNullObjectよりnull推奨で
そのための前提として構文レベルで区別するための仕組みがある

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

そういうのも区別出来るかどうかという似たような話になる
0878デフォルトの名無しさん
垢版 |
2020/03/24(火) 00:18:55.74ID:T0vrM+QL
>>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にはない。
0879デフォルトの名無しさん
垢版 |
2020/03/24(火) 00:35:30.02ID:0F/GzGem
Kotlinってnullableを使っても安全だし
NullObjectも書きやすいんだよなあ
sealed classならNullObjectがこの上なく簡単に定義できて
whenで受けたときプログラマーが分岐を漏らさないようにコンパイラが教えてくれる
スマートキャストも安全で便利だ
0880デフォルトの名無しさん
垢版 |
2020/03/24(火) 00:44:02.15ID:0F/GzGem
古いものが大好きなnull爺にこの話を教えてやろう
Kotlin公式ドキュメントからリンクされてる学習者には有名なエピソードだ
nullポインタを発明したのは、クイックソート等の数々のアルゴリズムを発明し、C言語の源流にもなったALGOLを実装した天才トニー・ホーア氏
彼は近年こう回顧し謝罪している

>それは10億ドルにも相当する私の誤りだ。null参照を発明したのは1965年のことだった。
(中略)
>私は単にそれが容易だというだけで、無効な参照を含める誘惑に抵抗できなかった。これは、後に数え切れない過ち、脆弱性、システムクラッシュを引き起こし、過去40年間で10億ドル相当の苦痛と損害を引き起こしたとみられる。
0881デフォルトの名無しさん
垢版 |
2020/03/24(火) 01:42:20.76ID:T0vrM+QL
>>880
偉いとされる人が言った、または、有名な団体が作ったようなものを無条件で信じるあなたのような権威主義者が多いだけ。
有名な所が出してきたものは初期の衣の凄くもてはやされる。
使ったこともちゃんと学んだことも無いのに多くの人が褒めちぎる。
それはなぜかというと、そうすることで自分が新しいものに追いついていると
人に錯覚させることが出来ると思い込んでいるからだ。
実際には何も知らないくせに適当に新しいものを褒めているだけ。
0883デフォルトの名無しさん
垢版 |
2020/03/24(火) 03:32:39.53ID:kBVBs/yt
null自体が問題なんじゃなくて、既存の言語の型システムでnon nullableな参照型がないのが問題なだけ。ごっちゃにしすぎ。
0884デフォルトの名無しさん
垢版 |
2020/03/24(火) 03:41:54.20ID:kBVBs/yt
だから、null自体はあった方が便利、ただ、型システムの方で値型だろうが参照型だろうがnullable、non-nullableの両方定義できるようにしとけってだけ
0886デフォルトの名無しさん
垢版 |
2020/03/24(火) 08:13:59.70ID:PfG4KY3E
>>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>()
0887デフォルトの名無しさん
垢版 |
2020/03/24(火) 08:34:24.48ID:nrIfxQG3
>>876
自分勝手な論理展開が多くて議論にならんね。

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

そういや、>>870にヌルポの観点が抜けてるな。追加すると、
・変数の初期化ミスで変数にデフォルト値(null)が入っていても、意図しない(親無しウインドウでの)呼び出しにならない。
0895デフォルトの名無しさん
垢版 |
2020/03/25(水) 19:58:41.50ID:R+JOhqjs
初めてAndroidアプリ作成の案件に携わってるけどクソOSクソ端末に対応するコスト無駄すぎるな
イライラするわ
0896デフォルトの名無しさん
垢版 |
2020/03/25(水) 20:11:20.32ID:i/r3a70w
テスト用に全ての実機用意するとかマジで有り得ん
0906デフォルトの名無しさん
垢版 |
2020/03/30(月) 12:29:37.34ID:XS9n9xNo
サーバーサイドkotlinを導入したいんだが、なんて言って上司を説得するのがいいと思う？
上司は昔java1.6やってたくらい。
0907デフォルトの名無しさん
垢版 |
2020/03/30(月) 12:36:40.55ID:Q7TXlLL8
言語云々を論点にしてはいけない
「技術選定も含めて俺に任せてくれ」だ
お前の全責任においてお前が成果を出せば誰も文句は言わない
それができないんなら黙って前例踏襲してなさい
0908デフォルトの名無しさん
垢版 |
2020/03/30(月) 15:01:23.30ID:XS9n9xNo
すまん。ちょっと聞き方悪かったわ。
単純にメリデメ教えてくれって言われたらなんて答える？
0909デフォルトの名無しさん
垢版 |
2020/03/30(月) 16:14:25.46ID:S7P/1C/L
ライブラリが同じなのでフツーのJava経験者なら3日もあれば習得できます
開発環境にJavaのソースをコピペすると自動変換もできます
null参照はコンパイラーが検出してくれる言語仕様なのでnullに関するバグを排除できます
ちなみにA案件でのnull参照バグは全体のxx%でした
Java14で計画されている言語仕様の改善も全て先取りしているので開発効率が上がります
中でもrecord型の先取りにより開発規模がA案件試算でxx%削減できます

ほかに口説き文句あれば俺も知りたい
0910デフォルトの名無しさん
垢版 |
2020/03/30(月) 18:20:58.26ID:LtUNGbMV
>>907
クッソ頭悪いだろお前
説得する材料くれって言う要件に対してその回答はあまりにも的外れだわ
0912デフォルトの名無しさん
垢版 |
2020/03/30(月) 18:40:18.84ID:/1SwYHDd
自分にとってどういうメリットがあるのかと
そのメリットが既存のものを捨てて乗り換えるコストを上回りそうかどうかという
2点をクリアしないと普通の人は新しいものを導入しようって気持ちにはならない

2つとも個々の状況によるものだから
現状の問題点や比較対象無しに聞いてもフワッとしたものしか返ってこないと思う
0915デフォルトの名無しさん
垢版 |
2020/03/30(月) 20:58:19.14ID:XS9n9xNo
javaの仕様に追従してる層にならメリットは説明できるけど、そうじゃない層に説明するのは難しい。。
実際、アドバイスくれてる人の説明もjavaの辛みが分かってこその主張だと思う
なんかjava1.6で止まってる人にも分かりやすいメリットないかな。。

ちなみに上司は、人の集めづらさを懸念をしてるだけで、本格的に反対してる訳では無い。純粋にメリット何？って感じ
0916デフォルトの名無しさん
垢版 |
2020/03/30(月) 21:25:01.20ID:Y9H00XEN
>>906
ここは一つネガキャンで。「KotlinがあるのにJavaをやるのは、JavaがあるのにCをやるようなもの。」
ただ、上司がJava至上主義者なら、「Cなんかと一緒にするな!!」と激怒するおそれあり。
0917デフォルトの名無しさん
垢版 |
2020/03/30(月) 22:39:22.47ID:cikRGyRQ
そろそろ転職しようと思ってたんだがコロナの影響でエンジニアの求人は減ってるの？まだ待った方が良い？
0918デフォルトの名無しさん
垢版 |
2020/03/30(月) 23:14:36.65ID:9vU1dCrA
プログラマとエンジニアは別物なので、まずその辺の違いをハッキリさせたほうがいい
0919デフォルトの名無しさん
垢版 |
2020/03/31(火) 01:21:29.69ID:09jFIsyL
でも、もしJavaならバージョンいくつ使うつもり?
そこどこ新しめJavaならそこまで苦痛にならんぞ
1.6ぐらいと比較して俺のペインポイントだったローカル変数の型推論もあるし、ラムダもあるし、コレクションのストリーム操作もあるし。

大きめの機能でasync/awaitないけど
0922デフォルトの名無しさん
垢版 |
2020/03/31(火) 12:30:43.25ID:mNevEI+p
>>911
一発で辞めることができたりして
0923デフォルトの名無しさん
垢版 |
2020/04/02(木) 00:15:49.69ID:MNI6t01H
Kotlinのdata classがJava14でrecordとして採用されると聞いて感動したのも束の間、まだPreviewなので正式採用はJava16辺りと知り気が遠くなった
誰もが普通に使えるようになるのは2026年頃じゃろか
0925デフォルトの名無しさん
垢版 |
2020/04/02(木) 02:07:24.43ID:MNI6t01H
誰もが普通にと書いたのはJava11の延長サポートが2026までだから遅い現場だとそこまで待つかなと
でもそれを言うなら8は2030まで延長できるんだった
0926デフォルトの名無しさん
垢版 |
2020/04/03(金) 06:46:06.71ID:/ReAKvRh
>>919
ラムダ式とOptionalで行けるのではと思っていた時代が、私にもありました。
ただ参照透過なプログラミングをしようとした途端、Listと配列がMutableなことが越えられない壁になる。
Java9から不変リストを作るList.of()があるけど、必要なのは実行時エラーでなくコンパイルエラーで教えてくれる不変リスト。
0927デフォルトの名無しさん
垢版 |
2020/04/03(金) 09:39:44.79ID:yWt1Tau8
それを言ったらKotlinのListも不変リストではなく読み取り専用のビューなので同じなのでは
0929デフォルトの名無しさん
垢版 |
2020/04/12(日) 01:08:01.34ID:NWUkpCEz
Windows 10 で IntelliJ IDEA を 2020.1 にアップデートしたら起動後にちゃんと動かなかった。
ウインドウは出るがその中が灰色のまま。右下に赤いやつが点滅していてマウスカーソルを
持って行ってクリックすると IDE Internal Error Occurred See Details and Submit Report と
出てくるが、Detail も何も出てこない。ウィンドウの右上の×を押しても終わらず、しょうがない
のでタスクマネージャで終了させた。

Community edition だが、試しに Ultimate の同バージョン方をインストールしたら動いた。
ま、しかし、ライセンスあるわけではないのでとりあえず Community edition の 2019.3.4 に
しておいた。これはちゃんと動く。
0931デフォルトの名無しさん
垢版 |
2020/04/14(火) 11:07:51.69ID:VpWClbHP
Javaやれ
0934デフォルトの名無しさん
垢版 |
2020/04/14(火) 11:31:09.72ID:ARe9d0+J
Kotlinは腐りきったJavaをなんとか少しでも便利に使うための車椅子のようなもの
古いのを勉強したくないならKotlin含めJava系の世界に飛び込むこと自体を考え直してもいいんじゃないかな
0938デフォルトの名無しさん
垢版 |
2020/04/14(火) 21:14:44.96ID:CfDohWIc
当然、日本ユーザー会会長の太郎本！
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016

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

超有名なスッキリを読んでないと、オブジェクト指向が分からないのでは？
Ruby をやってれば、オブジェクト指向・メソッドチェーンによる関数型と、両方とも理解できるけど
0939デフォルトの名無しさん
垢版 |
2020/05/01(金) 08:16:22.65ID:q8mD6cDI
>>930
C++, C#, Java, Swift, Rubyみたいなモダン言語の経験が無いと、Kotlinは難しいかも。

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

こう言うのが意味不明となる。
OOP自身は難しく無い。
0940デフォルトの名無しさん
垢版 |
2020/05/01(金) 09:25:47.40ID:MJ8FtJpe
全然関係ないんだけどさ

前々から思ってたんだが
「モダン」って言い方になんか古臭さを感じるんだよな
大正時代的な
他に良い呼び方ってないもんだろうか
0941デフォルトの名無しさん
垢版 |
2020/05/01(金) 09:32:44.13ID:k2YlXFh6
ダイナミックレンジですねわかります
0943デフォルトの名無しさん
垢版 |
2020/05/01(金) 10:56:25.01ID:q8mD6cDI
>>942
Type inference
0944デフォルトの名無しさん
垢版 |
2020/05/01(金) 10:58:18.55ID:q8mD6cDI
>>940
最新新言語、State of Arts computer language、Advanced Language、Recent Language、Up-to-date Language

御好きにすれば！
0948デフォルトの名無しさん
垢版 |
2020/05/01(金) 12:20:45.98ID:q8mD6cDI
>>946
such like Interface in Java or Abstruct Class in C++
0951デフォルトの名無しさん
垢版 |
2020/05/01(金) 13:13:27.88ID:578ddPng
>>940
日本人的には大正モダンでハイカラなイメージが強いけど、英単語のmodernにそんなニュアンスはないんだから直訳でモダンでもイイでしょ
アートやインテリアではモダンって普通に使うし
レス数が950を超えています。1000を超えると書き込みができなくなります。
ニューススポーツなんでも実況