JetBrainsが開発した期待の新言語、Androidの公式開発言語にしてサーバーサイドもなんでもいけるKotlinについて語りましょう
※前スレ
Kotlin 5
https://mevius.5ch.net/test/read.cgi/tech/1544268581/
探検
Kotlin 6
レス数が950を超えています。1000を超えると書き込みができなくなります。
1デフォルトの名無しさん
2019/06/22(土) 15:59:57.23ID:zj+KJbMh858デフォルトの名無しさん
2020/03/22(日) 09:32:27.12ID:nwybfWiz >>854
たまたま同じ型ばかりを引数にとる関数で順番を間違えるヒューマンエラーには配慮できるのに、nullを多用したときに誰かがミスして実行時エラーが多発するリスクに目を向けないのは何故?
たまたま同じ型ばかりを引数にとる関数で順番を間違えるヒューマンエラーには配慮できるのに、nullを多用したときに誰かがミスして実行時エラーが多発するリスクに目を向けないのは何故?
859デフォルトの名無しさん
2020/03/22(日) 09:58:58.91ID:CQOUf5Rv860デフォルトの名無しさん
2020/03/22(日) 11:22:24.81ID:nwybfWiz >>859
すまんアドホック多相だね
すまんアドホック多相だね
861デフォルトの名無しさん
2020/03/22(日) 11:43:59.28ID:F4lre3ad862デフォルトの名無しさん
2020/03/22(日) 12:55:36.51ID:q5xwUBc3 >>853
混同するのが危険なほど挙動が違うのなら、そもそも同じ関数名を使うべきじゃない。
関数・クラス設計における命名規則の問題だろ。言語設計(javaのヌルポ)の問題と関係ない。
この主張が、なんで型なしnullのマジックナンバー利用の肯定に繋がると考えているの?
混同するのが危険なほど挙動が違うのなら、そもそも同じ関数名を使うべきじゃない。
関数・クラス設計における命名規則の問題だろ。言語設計(javaのヌルポ)の問題と関係ない。
この主張が、なんで型なしnullのマジックナンバー利用の肯定に繋がると考えているの?
863デフォルトの名無しさん
2020/03/22(日) 15:36:31.56ID:HvrypJyW >>857
「ポリモーフィズムは次のようないくつかの種類に分けられる:
・アドホック多相(Ad hoc polymorphism):ある関数が、異なる型の引数に対してそれぞれ異なる実装を持つ場合。多くのプログラミング言語で関数の多重定義としてサポートされる。
・XXXX
・XXXX
・・・
」
「ポリモーフィズムは次のようないくつかの種類に分けられる:
・アドホック多相(Ad hoc polymorphism):ある関数が、異なる型の引数に対してそれぞれ異なる実装を持つ場合。多くのプログラミング言語で関数の多重定義としてサポートされる。
・XXXX
・XXXX
・・・
」
864デフォルトの名無しさん
2020/03/22(日) 15:39:40.53ID:HvrypJyW >>858
親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
「親がない」こと以外に意味を取りようがないから。
同様に、メニューオブジェクトへのポインタをNULLとした場合も、
「メニューがない」こと以外に意味を取りようがないので分かり易い。
それに比べて、関数を多重定義した場合には、ミスによってとんでもない動作をしてしまうことが有り得る。
親Windowのポインタを受け取る引数にNULLとした場合、意味は分かり易い。
「親がない」こと以外に意味を取りようがないから。
同様に、メニューオブジェクトへのポインタをNULLとした場合も、
「メニューがない」こと以外に意味を取りようがないので分かり易い。
それに比べて、関数を多重定義した場合には、ミスによってとんでもない動作をしてしまうことが有り得る。
865デフォルトの名無しさん
2020/03/22(日) 20:16:05.50ID:nwybfWiz >>864
結局、関数の実装者がミスってnull参照エラーを起こすリスクは見えてないのか
結局、関数の実装者がミスってnull参照エラーを起こすリスクは見えてないのか
866デフォルトの名無しさん
2020/03/23(月) 01:38:55.49ID:bf1cRh+B >>865
この例の場合、NULLにすると、それぞれ親Windowがない場合、Menuがない場合で、どちらも重要なので、さすがにテストしてあるはずなのだ。
この例に限らず、引数にNULLを指定する場合は、そのような「重要な変化」をもたらす事が多いので、必ずテスト済みの場合が多い故に安全なことが圧倒的多い。
この例の場合、NULLにすると、それぞれ親Windowがない場合、Menuがない場合で、どちらも重要なので、さすがにテストしてあるはずなのだ。
この例に限らず、引数にNULLを指定する場合は、そのような「重要な変化」をもたらす事が多いので、必ずテスト済みの場合が多い故に安全なことが圧倒的多い。
867デフォルトの名無しさん
2020/03/23(月) 02:26:57.24ID:dalJ4OEg868デフォルトの名無しさん
2020/03/23(月) 02:48:11.59ID:bf1cRh+B869デフォルトの名無しさん
2020/03/23(月) 03:14:15.98ID:6F6bSuZt >>866
それは言い換えると、nullを安全に使えるのはテストのパターン漏れがあり得ないような重要な変化があるところに限られ、それ以外で使うと安全とは言えないってことだよな
「安全なことが多い」ってのは危険は残っていると認めてるね
「さすがに〜はず」ってのは希望的観測だし、最後の文だけ「圧倒的」を付け足したのも論拠不足だよな
人は多重定義で引数順を間違えるような凡ミスをすると理解できているんだ
では人が重要ではない甘いところでnullを不用意に使ってしまうミスは当然あるよな
それは言い換えると、nullを安全に使えるのはテストのパターン漏れがあり得ないような重要な変化があるところに限られ、それ以外で使うと安全とは言えないってことだよな
「安全なことが多い」ってのは危険は残っていると認めてるね
「さすがに〜はず」ってのは希望的観測だし、最後の文だけ「圧倒的」を付け足したのも論拠不足だよな
人は多重定義で引数順を間違えるような凡ミスをすると理解できているんだ
では人が重要ではない甘いところでnullを不用意に使ってしまうミスは当然あるよな
870デフォルトの名無しさん
2020/03/23(月) 08:20:48.10ID:E0UAbPRX >>868
前半の準備できてから議論続けてね。
>「必要を感じない。」
それは個人の感想なので、主張としては弱くて役に立たないですね。
・メソッドを使う時に「NoWindow」であることをより明確化できる。
・間違えて「NoWindow」を指定してもnullより目立つので間違いに気づきやすい。
・名称がより明確なので、第三者がソースコードを読む時に読みやすい。
・それ専用に定義された変数に入っているので、IDEの支援を受けやすい。
・このケースだと必要性は薄いが、nullの意味が複数あるような場合でも(null,undefineなど)別々に定義できる。
くらいの利点はあるけど?
前半の準備できてから議論続けてね。
>「必要を感じない。」
それは個人の感想なので、主張としては弱くて役に立たないですね。
・メソッドを使う時に「NoWindow」であることをより明確化できる。
・間違えて「NoWindow」を指定してもnullより目立つので間違いに気づきやすい。
・名称がより明確なので、第三者がソースコードを読む時に読みやすい。
・それ専用に定義された変数に入っているので、IDEの支援を受けやすい。
・このケースだと必要性は薄いが、nullの意味が複数あるような場合でも(null,undefineなど)別々に定義できる。
くらいの利点はあるけど?
871デフォルトの名無しさん
2020/03/23(月) 08:53:23.76ID:7Cqb7CJ8 NullObjectパターン使ったライブラリーとかほとんどみかけないから...
もうここまで言えば後はワカルナ?
もうここまで言えば後はワカルナ?
872デフォルトの名無しさん
2020/03/23(月) 09:58:46.34ID:iyDg9ARV GetParentやGetMenuでnullチェックを忘れたらヌルポ
それを万が一忘れてもコンパイルエラーにしてくれるのがNullable
それを万が一忘れてもコンパイルエラーにしてくれるのがNullable
873デフォルトの名無しさん
2020/03/23(月) 12:12:09.69ID:E0UAbPRX874デフォルトの名無しさん
2020/03/23(月) 13:08:13.26ID:C8qDvQHU ここの住人って全員Androidアプリの開発者?
875デフォルトの名無しさん
2020/03/23(月) 14:27:37.30ID:kwvRFU7H Springもいるんじゃない?
小規模だけど去年bootで案件やったよ
小規模だけど去年bootで案件やったよ
876デフォルトの名無しさん
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にはならないし。
Keep It Simple.
NULLで現実に全く問題ないのに、NullObjectを導入することで新たな問題をむしろ入り込む余地が生まれる。
Polymorphism というが、「親Windowが無い」「Menuが無い」のような劇的な変化
は、Polymorphismでやるより、その場で if 文で場合分けするほうがプログラミングし易い。
例えば、Polymorphismに向いているのは、動物の種類を分けるようなときで、
「動物そのものが存在しない」時には向いていない。
後者は、if文無しで対処するより、本文の方でif文をちゃんと書いて場合分けした方が間違いが
生じにくくなるし、コード量も少なくなる。
だからNullObjectを使って、NullObject自身に処理を行わせて本文にはif分を使わないより、
ちゃんと本文にif文を書く方が適切なのだ。
仮にNullObjectを使っても結局、本文に if ( pMenu == &NullObject ) などという if 文を
書いてしまっては、Polymorphismにはならないし。
877デフォルトの名無しさん
2020/03/23(月) 23:59:37.49ID:Kfc9ZaIq KotlinはNullObjectよりnull推奨で
そのための前提として構文レベルで区別するための仕組みがある
x,yなのかrow,colなのか順番分からんから名前付き引数使うとか
どのオーバーロードが呼ばれるかとか
そういうのも区別出来るかどうかという似たような話になる
そのための前提として構文レベルで区別するための仕組みがある
x,yなのかrow,colなのか順番分からんから名前付き引数使うとか
どのオーバーロードが呼ばれるかとか
そういうのも区別出来るかどうかという似たような話になる
878デフォルトの名無しさん
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にはない。
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にはない。
879デフォルトの名無しさん
2020/03/24(火) 00:35:30.02ID:0F/GzGem Kotlinってnullableを使っても安全だし
NullObjectも書きやすいんだよなあ
sealed classならNullObjectがこの上なく簡単に定義できて
whenで受けたときプログラマーが分岐を漏らさないようにコンパイラが教えてくれる
スマートキャストも安全で便利だ
NullObjectも書きやすいんだよなあ
sealed classならNullObjectがこの上なく簡単に定義できて
whenで受けたときプログラマーが分岐を漏らさないようにコンパイラが教えてくれる
スマートキャストも安全で便利だ
880デフォルトの名無しさん
2020/03/24(火) 00:44:02.15ID:0F/GzGem 古いものが大好きなnull爺にこの話を教えてやろう
Kotlin公式ドキュメントからリンクされてる学習者には有名なエピソードだ
nullポインタを発明したのは、クイックソート等の数々のアルゴリズムを発明し、C言語の源流にもなったALGOLを実装した天才トニー・ホーア氏
彼は近年こう回顧し謝罪している
>それは10億ドルにも相当する私の誤りだ。null参照を発明したのは1965年のことだった。
(中略)
>私は単にそれが容易だというだけで、無効な参照を含める誘惑に抵抗できなかった。これは、後に数え切れない過ち、脆弱性、システムクラッシュを引き起こし、過去40年間で10億ドル相当の苦痛と損害を引き起こしたとみられる。
Kotlin公式ドキュメントからリンクされてる学習者には有名なエピソードだ
nullポインタを発明したのは、クイックソート等の数々のアルゴリズムを発明し、C言語の源流にもなったALGOLを実装した天才トニー・ホーア氏
彼は近年こう回顧し謝罪している
>それは10億ドルにも相当する私の誤りだ。null参照を発明したのは1965年のことだった。
(中略)
>私は単にそれが容易だというだけで、無効な参照を含める誘惑に抵抗できなかった。これは、後に数え切れない過ち、脆弱性、システムクラッシュを引き起こし、過去40年間で10億ドル相当の苦痛と損害を引き起こしたとみられる。
881デフォルトの名無しさん
2020/03/24(火) 01:42:20.76ID:T0vrM+QL >>880
偉いとされる人が言った、または、有名な団体が作ったようなものを無条件で信じるあなたのような権威主義者が多いだけ。
有名な所が出してきたものは初期の衣の凄くもてはやされる。
使ったこともちゃんと学んだことも無いのに多くの人が褒めちぎる。
それはなぜかというと、そうすることで自分が新しいものに追いついていると
人に錯覚させることが出来ると思い込んでいるからだ。
実際には何も知らないくせに適当に新しいものを褒めているだけ。
偉いとされる人が言った、または、有名な団体が作ったようなものを無条件で信じるあなたのような権威主義者が多いだけ。
有名な所が出してきたものは初期の衣の凄くもてはやされる。
使ったこともちゃんと学んだことも無いのに多くの人が褒めちぎる。
それはなぜかというと、そうすることで自分が新しいものに追いついていると
人に錯覚させることが出来ると思い込んでいるからだ。
実際には何も知らないくせに適当に新しいものを褒めているだけ。
882デフォルトの名無しさん
2020/03/24(火) 01:45:43.46ID:PY48eDSf Rustスレも荒らしてるので無視しとけ
883デフォルトの名無しさん
2020/03/24(火) 03:32:39.53ID:kBVBs/yt null自体が問題なんじゃなくて、既存の言語の型システムでnon nullableな参照型がないのが問題なだけ。ごっちゃにしすぎ。
884デフォルトの名無しさん
2020/03/24(火) 03:41:54.20ID:kBVBs/yt だから、null自体はあった方が便利、ただ、型システムの方で値型だろうが参照型だろうがnullable、non-nullableの両方定義できるようにしとけってだけ
885デフォルトの名無しさん
2020/03/24(火) 07:51:18.66ID:O58srhK5 もういい加減別スレ作ってそっちでやってくれ
886デフォルトの名無しさん
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>()
その失敗の本質は、いつでも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>()
887デフォルトの名無しさん
2020/03/24(火) 08:34:24.48ID:nrIfxQG3888デフォルトの名無しさん
2020/03/24(火) 09:26:10.10ID:/F68+jPW お前らの人生はnullみたいなもんだわ
889デフォルトの名無しさん
2020/03/24(火) 12:12:39.00ID:608mB07n ぬぬるぬるやで
890デフォルトの名無しさん
2020/03/24(火) 12:12:56.90ID:608mB07n ぬ多い
891デフォルトの名無しさん
2020/03/24(火) 12:22:26.33ID:cFvopTvT >>888
お前の人生は違うの?
お前の人生は違うの?
892デフォルトの名無しさん
2020/03/24(火) 12:48:34.07ID:Evm5n4ah けんかはおやめABC
893デフォルトの名無しさん
2020/03/24(火) 14:08:56.84ID:bSQ4VduX いい加減レス違いですよ
894デフォルトの名無しさん
2020/03/24(火) 21:20:41.36ID:PfG4KY3E Kotlin 1.4-M1 Released
https://blog.jetbrains.com/kotlin/2020/03/kotlin-1-4-m1-released/
https://blog.jetbrains.com/kotlin/2020/03/kotlin-1-4-m1-released/
895デフォルトの名無しさん
2020/03/25(水) 19:58:41.50ID:R+JOhqjs 初めてAndroidアプリ作成の案件に携わってるけどクソOSクソ端末に対応するコスト無駄すぎるな
イライラするわ
イライラするわ
896デフォルトの名無しさん
2020/03/25(水) 20:11:20.32ID:i/r3a70w テスト用に全ての実機用意するとかマジで有り得ん
897デフォルトの名無しさん
2020/03/25(水) 22:13:46.30ID:kFDvoIpy 全ての実機ってどんだけ集めたんだ?
898デフォルトの名無しさん
2020/03/25(水) 23:23:26.21ID:3tnofAZc ガラケー時代は中古もかき集めてやってたな
899デフォルトの名無しさん
2020/03/25(水) 23:47:54.47ID:TgMiAYI3900デフォルトの名無しさん
2020/03/25(水) 23:51:58.92ID:s5BcMGLd 社長て
901デフォルトの名無しさん
2020/03/26(木) 07:47:41.98ID:3JCRH1uw >>899
働いたことなさそう
働いたことなさそう
902デフォルトの名無しさん
2020/03/26(木) 07:52:36.00ID:PXNa4DUz まぁあれな感じのあれだけど、変に煽るのやめろ、誰も得しない
903デフォルトの名無しさん
2020/03/26(木) 09:15:47.51ID:RQaGoEl4 まあ先に煽ってるのは向こうだししょうがない
904デフォルトの名無しさん
2020/03/26(木) 11:30:29.60ID:cp63zjH+ >>901
社長したことなさそう
社長したことなさそう
905デフォルトの名無しさん
2020/03/26(木) 12:45:41.29ID:V49tRipQ 社長(自営業
906デフォルトの名無しさん
2020/03/30(月) 12:29:37.34ID:XS9n9xNo サーバーサイドkotlinを導入したいんだが、なんて言って上司を説得するのがいいと思う?
上司は昔java1.6やってたくらい。
上司は昔java1.6やってたくらい。
907デフォルトの名無しさん
2020/03/30(月) 12:36:40.55ID:Q7TXlLL8 言語云々を論点にしてはいけない
「技術選定も含めて俺に任せてくれ」だ
お前の全責任においてお前が成果を出せば誰も文句は言わない
それができないんなら黙って前例踏襲してなさい
「技術選定も含めて俺に任せてくれ」だ
お前の全責任においてお前が成果を出せば誰も文句は言わない
それができないんなら黙って前例踏襲してなさい
908デフォルトの名無しさん
2020/03/30(月) 15:01:23.30ID:XS9n9xNo すまん。ちょっと聞き方悪かったわ。
単純にメリデメ教えてくれって言われたらなんて答える?
単純にメリデメ教えてくれって言われたらなんて答える?
909デフォルトの名無しさん
2020/03/30(月) 16:14:25.46ID:S7P/1C/L ライブラリが同じなのでフツーのJava経験者なら3日もあれば習得できます
開発環境にJavaのソースをコピペすると自動変換もできます
null参照はコンパイラーが検出してくれる言語仕様なのでnullに関するバグを排除できます
ちなみにA案件でのnull参照バグは全体のxx%でした
Java14で計画されている言語仕様の改善も全て先取りしているので開発効率が上がります
中でもrecord型の先取りにより開発規模がA案件試算でxx%削減できます
ほかに口説き文句あれば俺も知りたい
開発環境にJavaのソースをコピペすると自動変換もできます
null参照はコンパイラーが検出してくれる言語仕様なのでnullに関するバグを排除できます
ちなみにA案件でのnull参照バグは全体のxx%でした
Java14で計画されている言語仕様の改善も全て先取りしているので開発効率が上がります
中でもrecord型の先取りにより開発規模がA案件試算でxx%削減できます
ほかに口説き文句あれば俺も知りたい
910デフォルトの名無しさん
2020/03/30(月) 18:20:58.26ID:LtUNGbMV911デフォルトの名無しさん
2020/03/30(月) 18:30:16.30ID:VgShyY/Q Kotlin採用していただけないのなら辞めますといえば一発や。
912デフォルトの名無しさん
2020/03/30(月) 18:40:18.84ID:/1SwYHDd 自分にとってどういうメリットがあるのかと
そのメリットが既存のものを捨てて乗り換えるコストを上回りそうかどうかという
2点をクリアしないと普通の人は新しいものを導入しようって気持ちにはならない
2つとも個々の状況によるものだから
現状の問題点や比較対象無しに聞いてもフワッとしたものしか返ってこないと思う
そのメリットが既存のものを捨てて乗り換えるコストを上回りそうかどうかという
2点をクリアしないと普通の人は新しいものを導入しようって気持ちにはならない
2つとも個々の状況によるものだから
現状の問題点や比較対象無しに聞いてもフワッとしたものしか返ってこないと思う
913デフォルトの名無しさん
2020/03/30(月) 19:38:12.89ID:4bRrJB51 上司「小鳥飼いたいのか?」
914デフォルトの名無しさん
2020/03/30(月) 19:57:32.43ID:2xrywwd7 ウザっ
915デフォルトの名無しさん
2020/03/30(月) 20:58:19.14ID:XS9n9xNo javaの仕様に追従してる層にならメリットは説明できるけど、そうじゃない層に説明するのは難しい。。
実際、アドバイスくれてる人の説明もjavaの辛みが分かってこその主張だと思う
なんかjava1.6で止まってる人にも分かりやすいメリットないかな。。
ちなみに上司は、人の集めづらさを懸念をしてるだけで、本格的に反対してる訳では無い。純粋にメリット何?って感じ
実際、アドバイスくれてる人の説明もjavaの辛みが分かってこその主張だと思う
なんかjava1.6で止まってる人にも分かりやすいメリットないかな。。
ちなみに上司は、人の集めづらさを懸念をしてるだけで、本格的に反対してる訳では無い。純粋にメリット何?って感じ
916デフォルトの名無しさん
2020/03/30(月) 21:25:01.20ID:Y9H00XEN >>906
ここは一つネガキャンで。「KotlinがあるのにJavaをやるのは、JavaがあるのにCをやるようなもの。」
ただ、上司がJava至上主義者なら、「Cなんかと一緒にするな!!」と激怒するおそれあり。
ここは一つネガキャンで。「KotlinがあるのにJavaをやるのは、JavaがあるのにCをやるようなもの。」
ただ、上司がJava至上主義者なら、「Cなんかと一緒にするな!!」と激怒するおそれあり。
917デフォルトの名無しさん
2020/03/30(月) 22:39:22.47ID:cikRGyRQ そろそろ転職しようと思ってたんだがコロナの影響でエンジニアの求人は減ってるの?まだ待った方が良い?
918デフォルトの名無しさん
2020/03/30(月) 23:14:36.65ID:9vU1dCrA プログラマとエンジニアは別物なので、まずその辺の違いをハッキリさせたほうがいい
919デフォルトの名無しさん
2020/03/31(火) 01:21:29.69ID:09jFIsyL でも、もしJavaならバージョンいくつ使うつもり?
そこどこ新しめJavaならそこまで苦痛にならんぞ
1.6ぐらいと比較して俺のペインポイントだったローカル変数の型推論もあるし、ラムダもあるし、コレクションのストリーム操作もあるし。
大きめの機能でasync/awaitないけど
そこどこ新しめJavaならそこまで苦痛にならんぞ
1.6ぐらいと比較して俺のペインポイントだったローカル変数の型推論もあるし、ラムダもあるし、コレクションのストリーム操作もあるし。
大きめの機能でasync/awaitないけど
920デフォルトの名無しさん
2020/03/31(火) 01:22:07.78ID:09jFIsyL そこそこ新しめ*
921デフォルトの名無しさん
2020/03/31(火) 01:23:36.87ID:09jFIsyL あぁもちろんnull safetyもあるが
922デフォルトの名無しさん
2020/03/31(火) 12:30:43.25ID:mNevEI+p >>911
一発で辞めることができたりして
一発で辞めることができたりして
923デフォルトの名無しさん
2020/04/02(木) 00:15:49.69ID:MNI6t01H Kotlinのdata classがJava14でrecordとして採用されると聞いて感動したのも束の間、まだPreviewなので正式採用はJava16辺りと知り気が遠くなった
誰もが普通に使えるようになるのは2026年頃じゃろか
誰もが普通に使えるようになるのは2026年頃じゃろか
924デフォルトの名無しさん
2020/04/02(木) 01:51:56.87ID:UJkjbKIq 半年毎にアップデートだからJava16は1年後
925デフォルトの名無しさん
2020/04/02(木) 02:07:24.43ID:MNI6t01H 誰もが普通にと書いたのはJava11の延長サポートが2026までだから遅い現場だとそこまで待つかなと
でもそれを言うなら8は2030まで延長できるんだった
でもそれを言うなら8は2030まで延長できるんだった
926デフォルトの名無しさん
2020/04/03(金) 06:46:06.71ID:/ReAKvRh >>919
ラムダ式とOptionalで行けるのではと思っていた時代が、私にもありました。
ただ参照透過なプログラミングをしようとした途端、Listと配列がMutableなことが越えられない壁になる。
Java9から不変リストを作るList.of()があるけど、必要なのは実行時エラーでなくコンパイルエラーで教えてくれる不変リスト。
ラムダ式とOptionalで行けるのではと思っていた時代が、私にもありました。
ただ参照透過なプログラミングをしようとした途端、Listと配列がMutableなことが越えられない壁になる。
Java9から不変リストを作るList.of()があるけど、必要なのは実行時エラーでなくコンパイルエラーで教えてくれる不変リスト。
927デフォルトの名無しさん
2020/04/03(金) 09:39:44.79ID:yWt1Tau8 それを言ったらKotlinのListも不変リストではなく読み取り専用のビューなので同じなのでは
928デフォルトの名無しさん
2020/04/03(金) 09:41:24.03ID:yWt1Tau8 いや追加や更新機能のないリストインターフェースが欲しいということか
929デフォルトの名無しさん
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 に
しておいた。これはちゃんと動く。
ウインドウは出るがその中が灰色のまま。右下に赤いやつが点滅していてマウスカーソルを
持って行ってクリックすると IDE Internal Error Occurred See Details and Submit Report と
出てくるが、Detail も何も出てこない。ウィンドウの右上の×を押しても終わらず、しょうがない
のでタスクマネージャで終了させた。
Community edition だが、試しに Ultimate の同バージョン方をインストールしたら動いた。
ま、しかし、ライセンスあるわけではないのでとりあえず Community edition の 2019.3.4 に
しておいた。これはちゃんと動く。
930デフォルトの名無しさん
2020/04/14(火) 10:52:23.60ID:TtcAIhBY javaすらやったことない人におすすめのKotlinの参考書ありますでしょうか?
931デフォルトの名無しさん
2020/04/14(火) 11:07:51.69ID:VpWClbHP Javaやれ
932デフォルトの名無しさん
2020/04/14(火) 11:14:48.92ID:TtcAIhBY 今更古いものを勉強するのは嫌です
933デフォルトの名無しさん
2020/04/14(火) 11:22:31.52ID:yYd/ONZz ネットで調べりゃすぐでてくんだろ
934デフォルトの名無しさん
2020/04/14(火) 11:31:09.72ID:ARe9d0+J Kotlinは腐りきったJavaをなんとか少しでも便利に使うための車椅子のようなもの
古いのを勉強したくないならKotlin含めJava系の世界に飛び込むこと自体を考え直してもいいんじゃないかな
古いのを勉強したくないならKotlin含めJava系の世界に飛び込むこと自体を考え直してもいいんじゃないかな
935デフォルトの名無しさん
2020/04/14(火) 11:35:17.73ID:TtcAIhBY 屁理屈は良いので参考書を教えて下さい。
936デフォルトの名無しさん
2020/04/14(火) 11:35:46.91ID:yYd/ONZz ダメだこいつ
937デフォルトの名無しさん
2020/04/14(火) 20:35:17.70ID:W7vR7yPX だめかなあ
938デフォルトの名無しさん
2020/04/14(火) 21:14:44.96ID:CfDohWIc 当然、日本ユーザー会会長の太郎本!
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
スッキリわかる Java入門 第2版、2014
超有名なスッキリを読んでないと、オブジェクト指向が分からないのでは?
Ruby をやってれば、オブジェクト指向・メソッドチェーンによる関数型と、両方とも理解できるけど
Kotlinスタートブック -新しいAndroidプログラミング、長澤 太郎、2016
スッキリわかる Java入門 第2版、2014
超有名なスッキリを読んでないと、オブジェクト指向が分からないのでは?
Ruby をやってれば、オブジェクト指向・メソッドチェーンによる関数型と、両方とも理解できるけど
939デフォルトの名無しさん
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自身は難しく無い。
C++, C#, Java, Swift, Rubyみたいなモダン言語の経験が無いと、Kotlinは難しいかも。
1. Clousure
2. Generics
3. Type Annotation Estimation
4. Collection
5. protocol
こう言うのが意味不明となる。
OOP自身は難しく無い。
940デフォルトの名無しさん
2020/05/01(金) 09:25:47.40ID:MJ8FtJpe 全然関係ないんだけどさ
前々から思ってたんだが
「モダン」って言い方になんか古臭さを感じるんだよな
大正時代的な
他に良い呼び方ってないもんだろうか
前々から思ってたんだが
「モダン」って言い方になんか古臭さを感じるんだよな
大正時代的な
他に良い呼び方ってないもんだろうか
941デフォルトの名無しさん
2020/05/01(金) 09:32:44.13ID:k2YlXFh6 ダイナミックレンジですねわかります
942デフォルトの名無しさん
2020/05/01(金) 09:41:54.27ID:xXuuls7c943デフォルトの名無しさん
2020/05/01(金) 10:56:25.01ID:q8mD6cDI >>942
Type inference
Type inference
944デフォルトの名無しさん
2020/05/01(金) 10:58:18.55ID:q8mD6cDI >>940
最新新言語、State of Arts computer language、Advanced Language、Recent Language、Up-to-date Language
御好きにすれば!
最新新言語、State of Arts computer language、Advanced Language、Recent Language、Up-to-date Language
御好きにすれば!
945デフォルトの名無しさん
2020/05/01(金) 11:12:14.62ID:zXgs9Rh4 プロトコルってどういうの?
946デフォルトの名無しさん
2020/05/01(金) 11:51:29.93ID:+e/fjpUy >>945
俺もそれ聞きたいな
俺もそれ聞きたいな
947デフォルトの名無しさん
2020/05/01(金) 12:19:40.77ID:zJYyytsu >> 440
意識高い系言語でいいんじゃね
意識高い系言語でいいんじゃね
948デフォルトの名無しさん
2020/05/01(金) 12:20:45.98ID:q8mD6cDI >>946
such like Interface in Java or Abstruct Class in C++
such like Interface in Java or Abstruct Class in C++
949デフォルトの名無しさん
2020/05/01(金) 13:01:44.47ID:zXgs9Rh4 >>948
機能的に違いないのに、名前だけ別のものつけたん?
機能的に違いないのに、名前だけ別のものつけたん?
950デフォルトの名無しさん
2020/05/01(金) 13:06:28.96ID:+e/fjpUy >>948
理解しました
理解しました
951デフォルトの名無しさん
2020/05/01(金) 13:13:27.88ID:578ddPng952デフォルトの名無しさん
2020/05/01(金) 13:16:50.04ID:+e/fjpUy モダンExcelなんていう言葉を最近聞いたよ
953デフォルトの名無しさん
2020/05/01(金) 15:33:32.05ID:q8mD6cDI954デフォルトの名無しさん
2020/05/01(金) 16:45:14.68ID:zXgs9Rh4955デフォルトの名無しさん
2020/05/01(金) 16:54:21.95ID:DyZSnah+ >>948
この業界ではよくあること
この業界ではよくあること
956デフォルトの名無しさん
2020/05/01(金) 18:17:15.79ID:m4mY1Cpc >>940
ナウいヤングな君は和製英語の事は忘れて英語の modern を思い浮かべなさい。
ナウいヤングな君は和製英語の事は忘れて英語の modern を思い浮かべなさい。
957デフォルトの名無しさん
2020/05/02(土) 04:45:48.24ID:HrddHHvE アマゾンで検索したら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/
基礎からわかる Kotlin
富田 健二 (著)
単行本: 224ページ
出版社: シーアンドアール研究所 (2020/7/17)
言語: 日本語
ISBN-10: 4863542917
ISBN-13: 978-4863542914
発売日: 2020/7/17
アマゾンのURL書くとここに書き込みできないのでヨドバシのURL書いておく。
https://www.yodobashi.com/product/100000009003256396/
レス数が950を超えています。1000を超えると書き込みができなくなります。
ニュース
- 【コメ】卸売業者「簡単に安売りできない」「大暴落起きれば大赤字に」 JA「新米の販売進度が近年になく遅い。コメの回転が悪い」 ★3 [Hitzeschleier★]
- 【将棋】福間香奈 女流六冠が会見 妊娠・出産でタイトル戦の事実上不戦敗 「妊娠したら、どちらか一方を諦めないといけない状況」★2 [冬月記者★]
- かつや、明日からカツ丼(竹)790円→590円、ロースカツ定食830円→630円、カツカレー(竹)990円→790円 画像あり [お断り★]
- タイがカンボジアを空爆、トランプ氏仲介の和平合意は“事実上崩壊”軍事衝突へ タイ首相「もはや対話の余地ない」 [お断り★]
- 空自機レーダー照射、音声データ公開 中国 ★5 [蚤の市★]
- 【速報】 米国政府、中国が日本の自衛隊にレーダー照射を批判、同事案で中国を批判するのは初めて ★2 [お断り★]
- 防衛省「了解は言っていない」 [966095474]
- 防衛省「日本は正当な対応をした。危険行為をしたのは中国。中国は再発防止を徹底せよ」 [834922174]
- 中国、日本人tiktokの収益剥奪開始wmwmwmwmwmwm [834922174]
- 【悲報】高市「円安進むから無駄な予備費積むな?逆に円高リスクに備えるためにも予備費必要なの!😡」😨 [359965264]
- 【画像】「無料男フェラ」にハマるノンケ男性が増加「金かからない」「女より気持ちいい」 [732289945]
- 元空自「日本側は火気管制レーダーともロックオンとも言っていない。中国の探索用レーダーの主張と矛盾しない」高市 [931948549]
