Kotlin 3

**デフォルトの名無しさん** · 2018/03/19(月) 04:26:26.03

JetBrainsが開発した期待の新言語Kotlinについて語りましょう
https://kotlinlang.org

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

**デフォルトの名無しさん** · 2018/06/24(日) 20:59:37.06

>>634
1人で全て開発するならそれでいいと思うよ。

**デフォルトの名無しさん** · 2018/06/24(日) 21:03:58.17

つまり、null不許容型は人的ミスのためであって他意はないと？

**デフォルトの名無しさん** · 2018/06/24(日) 21:05:43.17

>>634
初めたばっかで良く分かって無いが、null使わないなら許容する意味が無くね-か
寧ろnullを使う意味が分からない

**デフォルトの名無しさん** · 2018/06/24(日) 21:22:24.66

例えばSwiftは言語仕様でnullを抹殺しているが、わざわざOptionalというnullでないものでnullを表現してる。nullがない世界など何処にもないのだ。

**デフォルトの名無しさん** · 2018/06/24(日) 21:25:55.36

例えばファイルが読み込めなかった場合、どうなると思いますか？

答えられますか？

答えられるようになったら質問してください。
今はそういうレベルの話ではないです。

**デフォルトの名無しさん** · 2018/06/24(日) 21:38:37.19

>>630
> なぜnull不許容が必要なのか教えてください
あなたの言う意味では不要。null許容にすることによってプログラミングが不可能になることはない。
nullによって発生する凡ミスが減るというメリットを必要とする人がいる。それだけ。

>>640
> 今はそういうレベルの話ではないです。
わからないで聞いているというより、わかってて煽ってるわけだ。

> 例えばファイルが読み込めなかった場合、どうなると思いますか？
ここでnullを許容する必要があるのではないかと言いたいんだと思うけど、
Kotlinがそうしているかどうはかは別にして、「ファイルが読み込めなかった」という
nullでない値を返すという考え方もある。
null許容のJavaだと例外を投げるところかな。

**デフォルトの名無しさん** · 2018/06/24(日) 21:40:24.82

>>639
おっしゃる通りで、結局不正なデータのチェックは必要なわけで、null不許容だから安心して使えるわけでもなく、寧ろ何気にうまく動いている状態が一番怖いです

**デフォルトの名無しさん** · 2018/06/24(日) 21:52:05.84

null不許容のクラスを作るとして
そこではあらゆるケースに対処を強いられるわけで、チェック項目は膨大になります
しかしそれを利用する側は単純にファイルが読めるか否かだけ知れればいいとします。
null不許容を取り入れるということは、開発コストが上がることを示唆しているのではないかと

どうですか？

**デフォルトの名無しさん** · 2018/06/24(日) 21:54:49.09

Optionalは中身取り出すのにアンラップが要る。Kotlinはnullにならないようにコンパイラがチェックしてるだけ。よってアンラップ不要。副作用としてnullを許容してないのに場合によってはnullが入ってしまうこともある。。

**デフォルトの名無しさん** · 2018/06/24(日) 22:02:12.48

>>644
それは実行時の動的なnullですよね。
私が質問しているのは、null不許容型(言い換えれば静的なnullに関して)の必要性についてです。

**デフォルトの名無しさん** · 2018/06/24(日) 22:02:30.58

>>643
>>641が答え書いてるじゃん

**デフォルトの名無しさん** · 2018/06/24(日) 22:07:56.87

ていうか日本語の文章おかしいし、確実に酔っ払いかただのキチガイじゃん

**デフォルトの名無しさん** · 2018/06/24(日) 22:10:34.25

おおかた大学のレポートなり試験なりでその質問をされて回答を探しにきたんだろ
ネットで煽りっぽく聞けばムキになった人が答えてくれるからね、君は賢いね、偉い偉い

**デフォルトの名無しさん** · 2018/06/24(日) 22:30:46.16

>>627
たとえが下手すぎて

**デフォルトの名無しさん** · 2018/06/24(日) 22:36:12.55

だってこの子見るからに頭悪そうじゃない

**デフォルトの名無しさん** · 2018/06/24(日) 22:37:28.39

高圧的に質問すれば、逆に皆反応してくれる良い例だね

**デフォルトの名無しさん** · 2018/06/24(日) 23:18:47.64

>>624
コンパイルする言語なのかインタープリタなのかという問題ではなくて、そういう仕様の言語というだけのこと。
というのはコンパイルしようがしまいが同じような言語は作れるから。

**デフォルトの名無しさん** · 2018/06/24(日) 23:20:17.58

>>625
それによるバグをコンパイル時にエラーを出すことによって防げる。

**デフォルトの名無しさん** · 2018/06/24(日) 23:25:25.08

今ちょっと前にAmazon見たらこれのKindole版の方だけ1361円だった。55%offかな。だいたい半額ぐらい。
短期間のセール価格なのかも知れない。

Androidアプリ開発のためのKotlin実践プログラミング現場で求められる設計・実装のノウハウ
http://amzn.asia/iM5AGQY

紙の本はもう持ってるのにうっかり押しちゃうところだったw

**デフォルトの名無しさん** · 2018/06/24(日) 23:40:28.01

遠回しな宣伝だなぁ

**デフォルトの名無しさん** · 2018/06/25(月) 00:03:59.42

>>655
宣伝にはなっちゃうが他に知らせる方法ないよな。

**デフォルトの名無しさん** · 2018/06/25(月) 01:08:25.26

>>648
だろうな
煽り質問は無視しとけば良い

世の中nullっとしてないと入るものも入らないんだよ

**デフォルトの名無しさん** · 2018/06/25(月) 02:22:50.92

>>654
見る価値がないわぁ

**デフォルトの名無しさん** · 2018/06/25(月) 08:15:38.14

null安全に文句つけるひとほどnull安全を大袈裟に捉えてる現象

**デフォルトの名無しさん** · 2018/06/25(月) 08:19:39.17

本人あっさり逃げたな
マジで>>648が図星だったのかw

**デフォルトの名無しさん** · 2018/06/25(月) 08:59:14.92

とするともう大学で教えてる所があるということになるな

**デフォルトの名無しさん** · 2018/06/25(月) 09:02:09.61

null安全な言語はもうずっと前からあるから、それに触れる授業くらいはいくらでもあるでしょ

**デフォルトの名無しさん** · 2018/06/25(月) 09:08:55.77

>>657
【審議中】
．　　 ∧,,∧　 ∧,,∧
　∧ (´・ω・) (・ω・｀) ∧∧
(　´・ω)　Ｕ) ( つとﾉ(ω・｀ )
｜　Ｕ (　　・) (・｀　　)　とﾉ
　ｕ-ｕ（l 　　 ) (　　　ﾉu-ｕ
　　　　 `ｕ-ｕ’.　`ｕ-u’

**デフォルトの名無しさん** · 2018/06/25(月) 09:10:40.50

kotlin流行らんなあ

**デフォルトの名無しさん** · 2018/06/25(月) 12:17:54.99

BASICはnul安全

**デフォルトの名無しさん** · 2018/06/26(火) 06:08:18.39

KotlinのターゲットJVMは、Java8の次はOracleJDK 11になるんだろうか、OpenJDK 11になるんだろうか。

**デフォルトの名無しさん** · 2018/06/26(火) 08:30:26.76

Jetbrainオリジナルのkdkになるよ

**デフォルトの名無しさん** · 2018/06/26(火) 09:17:28.24

そんなん作ってくれるならそれはそれで助かる

**デフォルトの名無しさん** · 2018/06/26(火) 09:36:33.84

絶対に必要なのはJVMでJDKは要らなくする方向になるんだろな

**デフォルトの名無しさん** · 2018/06/26(火) 15:19:07.75

nativeはやく整備しよ？
jetbrainとgoogle様ならわけないっしょ？

**デフォルトの名無しさん** · 2018/06/26(火) 15:46:55.60

nativeっておもちゃとしては楽しいだろうけど、現実的にそこまでニーズあるかね

**デフォルトの名無しさん** · 2018/06/26(火) 18:39:53.31

明日JBの中の人が来日してkotlinイベントあるね
何か面白い話聞けるかな

**デフォルトの名無しさん** · 2018/06/26(火) 19:48:16.67

>>671
まずはおもちゃとして使って楽しんで、それから何かに使えないか考えれば良いのではないかな。
その内なにか丁度良い用途が見つかると思うよ。

**デフォルトの名無しさん** · 2018/06/26(火) 21:43:33.91

趣味で何か作るなら是非使いたいね。
ビジネスプロダクトを作るならまたちょっと話が変わるけど。

**デフォルトの名無しさん** · 2018/06/27(水) 07:38:02.49

クロスプラットフォームって、出始めの頃のhtmlベースのそび糞達のせいで普及が5年は遅れてると思う。
いまだにあの頃のイメージは抜けきれてない

**デフォルトの名無しさん** · 2018/06/27(水) 08:32:56.41

Kotlinを選ぶ時点で、既に自分の得意な特定の言語に固執する低レベルな段階を卒業してる人が多いだろうから
無理にKotlin使うよりプラットフォームに合わせた適切な言語を使うべきと考える人が多数派だろうね

**デフォルトの名無しさん** · 2018/06/27(水) 08:41:17.54

うちもいくつかアプリ作ってるけど、結局それぞれのネイティブで並行開発が1番間違いないって感じになってるな。
Xamarin使ってるのもあるけど、やっぱり色々辛い。RNはもっとアレだったからプロダクトに使う前にやめた。

**デフォルトの名無しさん** · 2018/06/27(水) 08:44:02.48

そうそう
クロスPFなんてもうunityくらいしか使われていない

**デフォルトの名無しさん** · 2018/06/27(水) 09:01:55.92

Xamarin程の糞はない

**デフォルトの名無しさん** · 2018/06/27(水) 10:28:55.92

>>678
Unityって触ったことないけど、ゲーム以外にも使えんの？

**デフォルトの名無しさん** · 2018/06/27(水) 10:31:24.77

使えない

**デフォルトの名無しさん** · 2018/06/27(水) 12:18:58.79

単純にプラットフォームのバージョンアップに加えて、Xamarinの更新や仕様変更にもついていかなくちゃいけないのが割と大きいんだよね。
レイヤーが1枚増えるぶんこちらの意思とは無関係にメンテしなくちゃいけないものが増える。

**デフォルトの名無しさん** · 2018/06/27(水) 18:40:46.48

ネイティブでクロスコンパイルだとgoがいい感じなんだがいかんせん言語仕様がアレじゃん?
rustもつらみが深いし。
kotlinがそこ狙ってくれないかなー

**デフォルトの名無しさん** · 2018/06/27(水) 19:00:28.69

Googleがgo諦めてKotlin推しになったんだと思ってるんだが

**デフォルトの名無しさん** · 2018/06/27(水) 19:40:54.39

Google的にはTypeScriptとPWAでしょ

**デフォルトの名無しさん** · 2018/06/27(水) 20:31:33.36

GoはGoogleAppEngineとセットで推されてる感じ
Dartはモバイルアプリに使えるようになったけど、PWAにも対応されるのかな

**デフォルトの名無しさん** · 2018/06/27(水) 21:31:14.11

Google A 「KotlinはAndroid開発の第一級言語」
Google B 「Dartならクロスプラットフォーム開発出来るよ」
Google C 「社内ではTypeScriptが標準開発言語ですけどね」
Google D 「Goはさらに進化する」

**デフォルトの名無しさん** · 2018/06/27(水) 21:47:53.30

Googleも一枚岩ではないからな

**デフォルトの名無しさん** · 2018/06/27(水) 21:54:44.06

そういうカオスなのがGoogleっぽくて嫌いじゃない
Googleはインド系
Appleは中国系

**デフォルトの名無しさん** · 2018/06/27(水) 22:06:52.35

Google的にはWebAssemblyはどの言語なんだろ
Kotlin/Nativeを推してくれたりしないものか

**デフォルトの名無しさん** · 2018/06/27(水) 22:36:51.97

GoogleはSEO最強だからどんなものでもそれなりに凄いもののように見えるけど、
実際にはGoogle自身も全く本気でやってないお遊びレベルのゴミが多いでしょ
Googleって社内的には非常に一貫性の高い独自のプラットフォームがあって、世間のOSSベースな開発とはかけ離れた世界になってるらしいし

**デフォルトの名無しさん** · 2018/06/28(木) 05:21:24.48

ソースは？

**デフォルトの名無しさん** · 2018/06/28(木) 08:16:52.30

googleのソースリポジトリへのコミット要件が割と厳し目なのは有名かな。
その割にgithubにあげてるのはそもそもまともに動かないものもたまにある。

**デフォルトの名無しさん** · 2018/06/28(木) 11:23:25.80

>>692
オリバーかイカリ使ってる

**デフォルトの名無しさん** · 2018/06/30(土) 20:53:17.24

この前のHadi Haririのイベント行った奴いないの？

**デフォルトの名無しさん** · 2018/07/01(日) 08:01:17.25

すみません、どちらに質問させて頂けるのか分からなくてこちらで教えていただければと考えてます。よろしくお願いします。

**696** · 2018/07/01(日) 08:15:08.30

1 fun func(x:int,y:(Int)->Int)=L(x)
2 func(1,{it*5})

1行目のL(x)は何を意味しているのでしょうか？
また、var y:(Int)->Int={x:Int->x*2}をfunc関数に代入するために
1行目にy:(Int)->Intを引数にして
2行目で、{x:Int->x*2}を実行しているという理解でいいのでしょうか？

**デフォルトの名無しさん** · 2018/07/01(日) 08:18:15.23

>>681
Unityの「だってお前らこれではゲームしか作らんだろ」という割り切りっぷりは清々しい
ゲーム的文法で作る以外のルートがねえｗ

**デフォルトの名無しさん** · 2018/07/01(日) 10:29:25.00

>>697
1行目はLという名前の関数にxを渡してるだけ
　fun func(x:int, y:(Int)->Int) {
　　　return L(x)
　}
の省略表記
ただ、引数のyが無視されているので
L(x) じゃなくて y(x) の間違いなんじゃねって気がする

2行目は代入云々はその理解で合ってるけど
「実行している」のではなく「定義して渡している」
実際そのコードではyが呼ばれてないのでその掛け算は実行されない

**デフォルトの名無しさん** · 2018/07/01(日) 16:20:40.37

なんで、宣言のとき型と変数名逆にしたんだろうなあ、苛つくわあ

**デフォルトの名無しさん** · 2018/07/01(日) 16:23:38.80

>>700
省略したいときウルトラ面倒になるのでやりたくなかったのだろう

**デフォルトの名無しさん** · 2018/07/01(日) 16:58:23.83

val 人間:文字列=山田

気持ち悪いわあ

**デフォルトの名無しさん** · 2018/07/01(日) 18:15:00.04

>>700
型が省略されてるものとされないものが混在したら可読性ウンコになるだろ

**デフォルトの名無しさん** · 2018/07/01(日) 19:41:23.70

以前はPASCAL, ML, Haskell、最近なら Scala, Go もこういう形で、
「型変数」っていう順序のCスタイルの方が本来異色なんだけど。

**デフォルトの名無しさん** · 2018/07/01(日) 20:18:17.04

>>703

val a=0
int b=1
みたいな感じじゃだめだったのか気になる

**デフォルトの名無しさん** · 2018/07/01(日) 20:49:55.44

val name : String = " 名前"
" String "に代入してる感覚があるから、わかりにくのは事実だわなw

**デフォルトの名無しさん** · 2018/07/01(日) 20:53:31.14

>>706
これよこれ
Aをhogeという型で代入
hogeという型のAに代入
好みかな…

**デフォルトの名無しさん** · 2018/07/01(日) 21:01:29.33

>>705
それだと
val int a = 0
val b = 1
になるやん

**デフォルトの名無しさん** · 2018/07/01(日) 21:31:28.10

文芸的プログラミングというやつで、
val name: String
はname of Stringと見えるから英語の順序的にはこのほうが自然

**デフォルトの名無しさん** · 2018/07/01(日) 21:38:16.02

てゆーか>>702の例の時点でさくっと英語理屈を出してあげたほうが混乱がなかったと思う
じゃあなんでC族がそうなってないかって？
Cだからそんな面倒なことしねーんだよお前側が機械に合わせろｗ

**デフォルトの名無しさん** · 2018/07/01(日) 22:01:00.11

日本語話者の一般的な認知様式は
鳥の模型＞模型の鳥
名前を表す文字列＞文字列で表された名前
だし、日本語でも変数名:型の方が言語的には自然では

**デフォルトの名無しさん** · 2018/07/01(日) 22:20:03.34

数字の n は 42
文字列の s は "42"

**デフォルトの名無しさん** · 2018/07/01(日) 22:26:56.25

言葉的にはそうかもしれないが
抽象度の順じゃないつうのがねー
これがモヤっとする原因

哺乳類>人間>山田

**デフォルトの名無しさん** · 2018/07/01(日) 22:31:27.77

>>713
うるせーそれが仕様だ
慣れろバカ

**デフォルトの名無しさん** · 2018/07/01(日) 22:50:43.53

>>712
それも大抵の日本人は
nは数字の42
sは文字列の"42"
と表現すると思うよ

**デフォルトの名無しさん** · 2018/07/01(日) 22:55:24.40

単純に慣れだと思うんだけどなぁ
コード読むときに
>>712
>>714
みたいな考えいちいち経由しないでしょ

**デフォルトの名無しさん** · 2018/07/01(日) 23:01:37.60

kotlinの基本に慣れる為に

val name : String = " 名前"

"定数"の"name"には"String型"の"値"を入れる

と言う解釈がすんなり行けるかな

**デフォルトの名無しさん** · 2018/07/01(日) 23:08:56.02

val name: String = "..."

"name" is a string: "John Smith"
「名前」は文字列、"山田花子"

打ってる時はだいたいこういう感じの思考の流れがある

**デフォルトの名無しさん** · 2018/07/01(日) 23:19:27.43

>>717
define a variable "name" as a string and assign a value "名前" to it って読むんだよそれ

**デフォルトの名無しさん** · 2018/07/01(日) 23:20:47.61

valなのにvariable ｗｗｗｗｗ

**デフォルトの名無しさん** · 2018/07/01(日) 23:27:05.41

昔々PascalというかDelphiをよく使っていたので変数名、形の順でも違和感なし。
Oracle の PL/SQL も確かそうだったな。

Cも昔からよく使ってるけどね。Javaは趣味で使う程度かな。

**デフォルトの名無しさん** · 2018/07/01(日) 23:30:37.32

そういやKotlinは val a, b, c : Int みたいに書いてまとめて宣言できないんだっけ？できた？

**デフォルトの名無しさん** · 2018/07/02(月) 00:28:48.57

>>708
javaとかこんなんじゃなかったっけ

**デフォルトの名無しさん** · 2018/07/02(月) 00:29:30.51

>>708
>>705のことね

**デフォルトの名無しさん** · 2018/07/02(月) 02:31:32.49

変数名とコロンの間にスペース入れるのは規約違反？

**デフォルトの名無しさん** · 2018/07/02(月) 04:08:17.17

>>725
エラー出ないから言語としては良いのでは？

関係ないが>>722で書いたやつは試したらダメだった。

**デフォルトの名無しさん** · 2018/07/02(月) 10:54:34.73

>>725
IntelliJのCode Style設定ではどちらも選べるようになってるから、どちらでもいいんでない

**デフォルトの名無しさん** · 2018/07/02(月) 12:07:35.37

>>726,727
そーなのか
なんとなく型はスペース無しで継承はスペース有りかと
ありがとりん

**デフォルトの名無しさん** · 2018/07/02(月) 15:54:18.89

そうそう型と継承が同じ記法だからごちゃごちゃするよな
どうせならすべて動的型付けにすればよかったのに

**デフォルトの名無しさん** · 2018/07/02(月) 16:24:41.26

動的型付けだと、存在意義全否定だろ。
Groovyでも使っとけ。

**デフォルトの名無しさん** · 2018/07/02(月) 20:41:56.60

型推論と動的型付けを混同すんなよ

**デフォルトの名無しさん** · 2018/07/02(月) 21:15:16.60

>>699
お礼が遅れてすみません。
仰る通り、記載ミスで、y(x)です。

ご解説ありがとうございます。
すっきりしました。ありがとうございます。

**デフォルトの名無しさん** · 2018/07/02(月) 21:24:23.77

>>732
うむ。精進なされよ。

**デフォルトの名無しさん** · 2018/07/02(月) 23:00:47.89

慣れたら型が後の方が可読性高く感じる
それと構文解析しやすくなるのもあるんじゃね

Kotlinでの
　(T1,T2)->R
はJavaでは
　BiFunction<T1,T2,R>

型が先だと関数型(function type)が他の構文と衝突しないよう識別子やジェネリクス型を置くことになる

**デフォルトの名無しさん** · 2018/07/03(火) 00:00:46.54

(TT^TT)

**デフォルトの名無しさん** · 2018/07/03(火) 00:39:55.52

関数の返値の変数の型も指定できるから、そっちのほうはわかりやすいんじゃないかな

fun hoge(): String = "ぬるぽ"

関数型プログラミングだと、そういう形式のほうがわかりやすいんじゃないかと思う

val hoge: () -> String = fun(): String = "ぬるぽ"