Kotlin 6
レス数が900を超えています。1000を超えると表示できなくなるよ。
JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう
※前スレ
Kotlin 5
https://mevius.5ch.net/test/read.cgi/tech/1544268581/ nullが危険といっている人は、MMUを使ってない化石の様なOSでの経験に基づくものなのかな。 if で場合分けせずに、オブジェクトのclassの仮想関数で場合分けさせると言う考え方
は時々聞くが、それはすべてをオブジェクト指向に置き換えれば上手く行くと言う根拠
のない浅はかな考え方だ。
経験を積むとその思想は間違いであることが分かってくる。 ページ違反が起きて特定に悩まされたのが昭和
一般保護例外なりヌルポなりの発生元ステップをテストで洗い出すのが平成
モダン言語ではコンパイル時に検出するので品質もコストも優位
老人は自らの成功体験に頼るので新しく良いものが現れても知識体系に取り入れることが難しく適材適所の選択ができない >>823
むしろ、OOPでやればなんでも上手く行くと思い込んでいる頭の固い馬鹿にしか思えんが。 Javaカスイライラで草
プログラマのくせに新しいもの嫌いとか致命的にセンスないだろw
さっさとやめろよこの業界w 新しくても駄目なものは駄目。
新しければいいと思うな。
若ければ年上に勝てると思うな。 >>828
今時厳密にコーダープログラマーをわけてる現場なんかないだろwクソ老害か?w >>829
老害イライラで草
顔真っ赤にしてる暇あったらkotlinの勉強しようなwww >>833
Javaはブームとなるほど、当時としてはちょっと革新的な言語だった。
Kotlinは全然違う。 >>832
君が派遣されてるドカタ現場ではそうなんだね nullセーフもoopも嫌いならgoがオススメですよ >>835
君が派遣されてるクソ現場は下流しかやってないから律儀にフロントとバックでコーダープログラマー分けてるんだねw
普通上流の仕事してたらそんな底辺下流の扱いなんか厳密に分けてないよwwwww
勉強になったねえ w >>829
年寄りだったのか。
若い頃に苦労して身につけたテクニックが、言語仕様でカバーされて誰でも実践できるようになって、
脅かされている自分のアイデンティティを守るために必死になっている、ってところかな。 >>839
この板に居るようなパンチカード(?)を語るようなほどの年寄りではない。
NullObjectでNULLを代用することが、
「言語仕様で誰でも実践できるようになって、自分のアイデンティティーが脅かされる」
に該当するとはとても思えない。 >>840
> この板に居るようなパンチカード(?)を語るようなほどの年寄りではない。
この板にパンチカードなんて単語一度も出てきてないけど誰のこと?
パンチカード世代ではないにしても、NULLを駆使するのが美しいテクニックだった時代の年寄りなんでしょ?
相手の主張を反論しやすいように歪曲するのはやめた方がいいですよ。
>NullObjectでNULLを代用することが、
「NullObjectでNULLを代用すること」はKotlinの言語仕様でないから、
そのように受け取ったのなら、Kotlinのコンセプトを理解していないか、
相手の主張を反論しやすいように歪曲する癖があるかのどちらか。
>>840が対話の成立しない相手であることが証明されたので
>>840の回答には大変満足しております。ありがとうございました。 なんだ、親無しWindow を、null にしただけか。
確かに、そういうAPI があるけど、マネしない方がよい
それって、0 でも空文字列でも、何でもよいわけでしょ。
そうい所に、nullを使うのはおかしい
nullは、ヌルポだけに限定すべき!
異なる意味で使ってはならない!
使い方を文章に書いた時にも、
引数がnullなら、親無しWindowになりますというのも、ちょっとおかしい
そういう用途には、デフォルト引数! >>820
それどっちかというと Windows 独自の文化だと思う
たまに Windows 系の助っ人に行ってコンソールに例外出まくりなのみてビビるよ >>843
nullは存在しないことを意味すると考えれば、あながち間違いでもないと思うし、
デフォルト引数を使うにしてもデフォルト値はNullObjectになるだろうし。
というのは置くとして>>842で述べたように>>840にこれ以上構わないほうがいいと思うんだが。 俺が老人という言葉を使ったのは実年齢のことではなく振る舞いだよ
Kotlinのコンセプトを理解してないどころか学ぶ気すらない
C++でサンプルを提示する辺りJavaを知っているかすら怪しい
自分のアイデンティティーを脅かされるという自覚はなく、わざわざ下らないものの詳細を学ばなくても俺には経験上わかるんだという老人特有の驕りが見える
全貌が見えてないから議論が噛み合わない
このスレにはnullは一切使わずにNullObjectを使うべきと主張する層とnullableは安全とする層と適材適所で使うという層がいて、この老人にとっては全員敵であり区別できないのだろう
NullObjectはJavaでは効果的なプラクティスだったけどKotlinではStateパターンのような役割でないとさほど輝かないと俺は思う
KotlinでNullObjectが常にnull(able)の良き代替になるなんて誰も提示できないはず
この老人がその一点に拘り他を無視する限りやっぱり俺は正しいんだと信じ続けるだろうな >>845
あながち間違いでないことと良いAPIであることには隔たりがあると思うよ
参考としてはJavaが提供しているライブラリにおいてnullを指定してくださいというメソッドよりもオーバーロードを提供しているメソッドの方が多い
ウィンドウの例だけでなく一般化して考えると、引数のデフォルト値として空の関数を与えて綺麗に書けるケースも多い
メソッドごとにnullを渡すべきなのか空の関数を渡すべきなのかNullObjectがあるのかを考えず、引数を省略するというシグネチャーで判別可能な一貫した利用ができるのは優れたメソッド設計だと思う 爺さんが引数に null 渡す例出したのに釣られちゃってるけど
Javaでも戻り値に null かオブジェクト返す API は普通にあるからね
これは NullObject か nullable に修正したい プログラマーの気持ち悪い部分をいい感じに体現してくれてる
ここであれこれ書いてもぬかに釘
noteかブログにでも書いておけ なんでも古い古いと言っていれば、どんなに駄目でも新しい言語や若い人が有利になってしまう法則。 引数の個数や型だけが異なる「関数の多態性」を行うと、プログラムが間違い易くなる。
なぜなら型や引数の個数の書き間違いをコンパイラが報告してくれなくなることがあるから。
C/C++で型が導入されたのもそういう間違いをコンパイラに発見してもらうためも有ったが、それが働きにくくなってしまう。 >>852
一つの関数名に引数の型や個数が異なる関数が10種類くらい多重定義されていたとする。
これを使ったプログラムする際には、マニュアルを見、関数名だけでなく引数も非常に正確に書かなくてはならなくなる。
型や引数の順序や個数などが僅かでも間違っていると、自分が思っていたのとは違う定義のものが呼び出されてしまうことになるが、それでも「合法」になってしまうのでコンパイラがエラーを出してくれない。
また、後から動作を調べようと思ってマニュアルを見たときにも、見間違いで間違った定義の部分の説明を読んでしまう現象が生じ易くなる。 >>853
func(1,2);
と書いたつもりで、タイプミスなどで
func(1,2,0);
と書いたとしよう。
func()が多重定義されていない場合なら、コンパイラがエラーを出してくれる。
ところが、func()が多重定義されてしまっている場合、たまたま、3つの整数引数の定義があった場合、自分の思ったのとはかなり違う動作の関数なのに、コンパイラが何もエラーを出してくれなくなってしまうことが有り得る。
それから、知らず知らずに「引数の自動型変換」機能が働いてしまうことが有り得る。
それと関数の多重定義の両方が組み合わされると、自分が思っていたのとはかなり
違う動作の関数が間違って呼び出されることになっていても、気づくことができない。
本当はどの関数が呼び出されているのかが分からず、どんなにチェックしても原因が分からない難しいバグが入ってしまうことになるかもしれない。 技術的な話でスレが進むのは、過疎ってるよりは良いことだよ
ほぼ読んでないから内容は知らんけど >>854
その話は、引数爆発は嫌だ、じゃあデフォルト引数使え、で解決してるだろ
さらに付け加えるなら名前付き引数も使え
そのあたりのCやJava時代の弱点をKotlinやC#は克服済みだ
あと多重定義は多態とは呼ばない >>854
たまたま同じ型ばかりを引数にとる関数で順番を間違えるヒューマンエラーには配慮できるのに、nullを多用したときに誰かがミスして実行時エラーが多発するリスクに目を向けないのは何故? >>857
>あと多重定義は多態とは呼ばない
異なる型に対する多重定義は多態の一種だよ >>853
ほんそれ
同じように思ってた人が居て良かった >>853
混同するのが危険なほど挙動が違うのなら、そもそも同じ関数名を使うべきじゃない。
関数・クラス設計における命名規則の問題だろ。言語設計(javaのヌルポ)の問題と関係ない。
この主張が、なんで型なしnullのマジックナンバー利用の肯定に繋がると考えているの? >>857
「ポリモーフィズムは次のようないくつかの種類に分けられる:
・アドホック多相(Ad hoc polymorphism):ある関数が、異なる型の引数に対してそれぞれ異なる実装を持つ場合。多くのプログラミング言語で関数の多重定義としてサポートされる。
・XXXX
・XXXX
・・・
」 >>858
親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
「親がない」こと以外に意味を取りようがないから。
同様に、メニューオブジェクトへのポインタをNULLとした場合も、
「メニューがない」こと以外に意味を取りようがないので分かり易い。
それに比べて、関数を多重定義した場合には、ミスによってとんでもない動作をしてしまうことが有り得る。 >>864
結局、関数の実装者がミスってnull参照エラーを起こすリスクは見えてないのか >>865
この例の場合、NULLにすると、それぞれ親Windowがない場合、Menuがない場合で、どちらも重要なので、さすがにテストしてあるはずなのだ。
この例に限らず、引数にNULLを指定する場合は、そのような「重要な変化」をもたらす事が多いので、必ずテスト済みの場合が多い故に安全なことが圧倒的多い。 >>864
何を言いたいのか全然わからん。
NULLの利点は親Windowの指定方法だと言っているのに、
>>854だと全く関係のない関数funcでoverloadに問題があると言っている。
自分の主張に沿うようにいいとこ取りしすぎ。
同じケースでNULL利用の利点とoverloadの欠点を比較しろよ。
>親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
nullよりも"NoWindow"というNullObjectを定義して使ったほうが意味はわかりやすい。
なんでnullを使わなきゃいけないのかね? >>867
後半、NULLで十分なのに敢えて、NoWindow なんてオブジェクトを定義する必要
を感じない。それでバグが減るわけでもないし。 >>866
それは言い換えると、nullを安全に使えるのはテストのパターン漏れがあり得ないような重要な変化があるところに限られ、それ以外で使うと安全とは言えないってことだよな
「安全なことが多い」ってのは危険は残っていると認めてるね
「さすがに〜はず」ってのは希望的観測だし、最後の文だけ「圧倒的」を付け足したのも論拠不足だよな
人は多重定義で引数順を間違えるような凡ミスをすると理解できているんだ
では人が重要ではない甘いところでnullを不用意に使ってしまうミスは当然あるよな >>868
前半の準備できてから議論続けてね。
>「必要を感じない。」
それは個人の感想なので、主張としては弱くて役に立たないですね。
・メソッドを使う時に「NoWindow」であることをより明確化できる。
・間違えて「NoWindow」を指定してもnullより目立つので間違いに気づきやすい。
・名称がより明確なので、第三者がソースコードを読む時に読みやすい。
・それ専用に定義された変数に入っているので、IDEの支援を受けやすい。
・このケースだと必要性は薄いが、nullの意味が複数あるような場合でも(null,undefineなど)別々に定義できる。
くらいの利点はあるけど? NullObjectパターン使ったライブラリーとかほとんどみかけないから...
もうここまで言えば後はワカルナ? GetParentやGetMenuでnullチェックを忘れたらヌルポ
それを万が一忘れてもコンパイルエラーにしてくれるのがNullable >>871
c言語の悪癖に冒されているだけだろ。
「マジックナンバーは悪」というのは常識だろうにマジックナンバー的にnullを使う設計者の気が知れんわ。 Springもいるんじゃない?
小規模だけど去年bootで案件やったよ >>873
Keep It Simple.
NULLで現実に全く問題ないのに、NullObjectを導入することで新たな問題をむしろ入り込む余地が生まれる。
Polymorphism というが、「親Windowが無い」「Menuが無い」のような劇的な変化
は、Polymorphismでやるより、その場で if 文で場合分けするほうがプログラミングし易い。
例えば、Polymorphismに向いているのは、動物の種類を分けるようなときで、
「動物そのものが存在しない」時には向いていない。
後者は、if文無しで対処するより、本文の方でif文をちゃんと書いて場合分けした方が間違いが
生じにくくなるし、コード量も少なくなる。
だからNullObjectを使って、NullObject自身に処理を行わせて本文にはif分を使わないより、
ちゃんと本文にif文を書く方が適切なのだ。
仮にNullObjectを使っても結局、本文に if ( pMenu == &NullObject ) などという if 文を
書いてしまっては、Polymorphismにはならないし。 KotlinはNullObjectよりnull推奨で
そのための前提として構文レベルで区別するための仕組みがある
x,yなのかrow,colなのか順番分からんから名前付き引数使うとか
どのオーバーロードが呼ばれるかとか
そういうのも区別出来るかどうかという似たような話になる >>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にはない。 Kotlinってnullableを使っても安全だし
NullObjectも書きやすいんだよなあ
sealed classならNullObjectがこの上なく簡単に定義できて
whenで受けたときプログラマーが分岐を漏らさないようにコンパイラが教えてくれる
スマートキャストも安全で便利だ 古いものが大好きなnull爺にこの話を教えてやろう
Kotlin公式ドキュメントからリンクされてる学習者には有名なエピソードだ
nullポインタを発明したのは、クイックソート等の数々のアルゴリズムを発明し、C言語の源流にもなったALGOLを実装した天才トニー・ホーア氏
彼は近年こう回顧し謝罪している
>それは10億ドルにも相当する私の誤りだ。null参照を発明したのは1965年のことだった。
(中略)
>私は単にそれが容易だというだけで、無効な参照を含める誘惑に抵抗できなかった。これは、後に数え切れない過ち、脆弱性、システムクラッシュを引き起こし、過去40年間で10億ドル相当の苦痛と損害を引き起こしたとみられる。 >>880
偉いとされる人が言った、または、有名な団体が作ったようなものを無条件で信じるあなたのような権威主義者が多いだけ。
有名な所が出してきたものは初期の衣の凄くもてはやされる。
使ったこともちゃんと学んだことも無いのに多くの人が褒めちぎる。
それはなぜかというと、そうすることで自分が新しいものに追いついていると
人に錯覚させることが出来ると思い込んでいるからだ。
実際には何も知らないくせに適当に新しいものを褒めているだけ。 null自体が問題なんじゃなくて、既存の言語の型システムでnon nullableな参照型がないのが問題なだけ。ごっちゃにしすぎ。 だから、null自体はあった方が便利、ただ、型システムの方で値型だろうが参照型だろうがnullable、non-nullableの両方定義できるようにしとけってだけ >>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>() >>876
自分勝手な論理展開が多くて議論にならんね。
ここはkotlinスレだし、「javaではヌルポのトラブルが多い」という事実を無視した主張はクソの役にも立たない。
「ヌルポのトラブルを避けるためにはどうしたらいいか」くらい考えたら?じゃなきゃスレ違いだからNGにするわ。
そういや、>>870にヌルポの観点が抜けてるな。追加すると、
・変数の初期化ミスで変数にデフォルト値(null)が入っていても、意図しない(親無しウインドウでの)呼び出しにならない。 初めてAndroidアプリ作成の案件に携わってるけどクソOSクソ端末に対応するコスト無駄すぎるな
イライラするわ >>895
それを判断するのは社長
現場のお前じゃない まぁあれな感じのあれだけど、変に煽るのやめろ、誰も得しない サーバーサイドkotlinを導入したいんだが、なんて言って上司を説得するのがいいと思う?
上司は昔java1.6やってたくらい。 言語云々を論点にしてはいけない
「技術選定も含めて俺に任せてくれ」だ
お前の全責任においてお前が成果を出せば誰も文句は言わない
それができないんなら黙って前例踏襲してなさい すまん。ちょっと聞き方悪かったわ。
単純にメリデメ教えてくれって言われたらなんて答える? ライブラリが同じなのでフツーのJava経験者なら3日もあれば習得できます
開発環境にJavaのソースをコピペすると自動変換もできます
null参照はコンパイラーが検出してくれる言語仕様なのでnullに関するバグを排除できます
ちなみにA案件でのnull参照バグは全体のxx%でした
Java14で計画されている言語仕様の改善も全て先取りしているので開発効率が上がります
中でもrecord型の先取りにより開発規模がA案件試算でxx%削減できます
ほかに口説き文句あれば俺も知りたい >>907
クッソ頭悪いだろお前
説得する材料くれって言う要件に対してその回答はあまりにも的外れだわ Kotlin採用していただけないのなら辞めますといえば一発や。 自分にとってどういうメリットがあるのかと
そのメリットが既存のものを捨てて乗り換えるコストを上回りそうかどうかという
2点をクリアしないと普通の人は新しいものを導入しようって気持ちにはならない
2つとも個々の状況によるものだから
現状の問題点や比較対象無しに聞いてもフワッとしたものしか返ってこないと思う javaの仕様に追従してる層にならメリットは説明できるけど、そうじゃない層に説明するのは難しい。。
実際、アドバイスくれてる人の説明もjavaの辛みが分かってこその主張だと思う
なんかjava1.6で止まってる人にも分かりやすいメリットないかな。。
ちなみに上司は、人の集めづらさを懸念をしてるだけで、本格的に反対してる訳では無い。純粋にメリット何?って感じ >>906
ここは一つネガキャンで。「KotlinがあるのにJavaをやるのは、JavaがあるのにCをやるようなもの。」
ただ、上司がJava至上主義者なら、「Cなんかと一緒にするな!!」と激怒するおそれあり。 そろそろ転職しようと思ってたんだがコロナの影響でエンジニアの求人は減ってるの?まだ待った方が良い? プログラマとエンジニアは別物なので、まずその辺の違いをハッキリさせたほうがいい でも、もしJavaならバージョンいくつ使うつもり?
そこどこ新しめJavaならそこまで苦痛にならんぞ
1.6ぐらいと比較して俺のペインポイントだったローカル変数の型推論もあるし、ラムダもあるし、コレクションのストリーム操作もあるし。
大きめの機能でasync/awaitないけど レス数が900を超えています。1000を超えると表示できなくなるよ。