@omuomugin はい。「安全」って言葉の意味が強すぎるってのが私も違和感がある原因かと思います。TypeScriptについていうと、Gradual Typingという概念の導入が必要なので、全ての型にふつーに型がつく世界とは違う、ということなのかなと(TypeScriptが本当にGradual Typingの概念満たしてるのか未調査)
posted at 22:28:46
ツイートの記録を停止しています
このアカウントはTwitter APIの仕様変更の影響でツイートの記録を停止しています。
記録を再開するには、Twilogにログインしてください。
Stats | Twitter歴 6,199日(2007/04/10より) |
ツイート数 110,424(17.8件/日) |
表示するツイート :
@omuomugin はい。「安全」って言葉の意味が強すぎるってのが私も違和感がある原因かと思います。TypeScriptについていうと、Gradual Typingという概念の導入が必要なので、全ての型にふつーに型がつく世界とは違う、ということなのかなと(TypeScriptが本当にGradual Typingの概念満たしてるのか未調査)
posted at 22:28:46
@koher "Kotlin's type system is aimed to eliminate NullPointerException” この辺は、元ネタと思われる(?)Void-safety https://www.eiffel.org/doc/eiffel/Void-safety-_Background%2C_definition%2C_and_tools… も同じ感じですし。
posted at 22:14:03
@koher 返信遅くなってすいません。non-nullableこそ本質、という意見でしたら全く異論ないです。ただ、null-safe(null安全)という言葉はそれより広い範囲を(残念ながら)指してしまっているように思います。 https://dogwood008.github.io/kotlin-web-site-ja/docs/reference/null-safety.html…
posted at 22:10:42
なんか疲労がたまっていたらしく(?)、寝落ちしていた。
posted at 22:07:02
@gakuzzzz Javaの話、でしょうか?
posted at 22:06:40
@omochimetaru はい。それは同感です(non-nullnessといいますか、そこはとてもうれしいところかと)。ただ、それは「null安全」のサブセットであって、「null安全」でうたっているところのものとは、ずれがあるようだ、という話です。
posted at 19:10:10
現在、体重は 85.6 Kg です(IFTTTからの自動投稿です)。 #kmizu_diet
posted at 18:54:52
@_yyu_ そういうのもありますね。
posted at 17:22:24
@nobkz Noneとかの値でないことがわかっているので、パターンマッチを書いても無駄(case Noneとかで例外投げる羽目になる)、という場面がある、ということだと理解しています(し、実際そういうケースがしばしばあります)。
posted at 17:02:58
49件のコメント https://b.hatena.ne.jp/entry/s/www.jigowatt121.com/entry/2019/08/11/230036… “アベンジャーズの功績にフリーライドするドラマ『ザ・ボーイズ』が皮肉マシマシで最高に面白かった - ジゴワットレポート” (221 users) https://htn.to/cenjEXgsK5
posted at 17:00:58
しかし、連休だというのに、というか、連休だからこそ、というべきなのか、家でだらだらしている…。
posted at 15:47:25
その辺の共通点があるのが、真の(?)意味での「null安全」に対しても疑念が湧いてくる理由の一つだったりします。
posted at 15:27:51
なお、Scalaでv.get() ができたり、Kotlinで v!! ができたり、Rustでv.unwrap() ができたり、Swiftでv! ができたり、どれもこれも、短い名前で、Option/Optional/nullableを外せるのは、結局、それだけカジュアルにそういう操作やりたいという要求が強かったからなのだと思います。
posted at 15:26:34
@yy_yank その、「safety度合いが段々減ってる」というのは、近い感覚です。
posted at 15:17:37
@yy_yank 起源としては、EiffelのVoid-safety https://www.eiffel.org/doc/eiffel/Void-safety-_Background%2C_definition%2C_and_tools… から来たんじゃないかと思ってます。余談ですが、元ネタ(?)のVoid-safetyの話は、かなりまじめに、ソフトウェアの性質として論じていて、(b) 文脈では依然として疑問があるのですが、(a) の話としては問題ない感じです。
posted at 15:08:54
@_yyu_ かなり似た話として、たとえば、パターンマッチの網羅性チェックがされるというのはうれしいのですが、それを網羅安全性(もちろん今考えた造語です)とかいう用語にされたら強烈な違和感を覚える、みたいな。
posted at 14:31:12
@_yyu_ そうですね。他の〇〇安全と比べて、用語として浮いている、と感じています(他の〇〇安全にも微妙なものがあるかもしれませんが)。
posted at 14:26:37
なお、型レベルでのnullable/not-nullableの区別は明らかに嬉しい(少なくとも、たとえば、Javaがunsoundじゃない問題とかは、たぶんこれで解決しそうだし、実用上もメリットが多い)ので、それはそれとして。
posted at 14:00:21
この二つって感じになります。
posted at 13:58:21
私の「null安全」批判には2つの別の話があってややこしいので、整理すると
(a) 「null安全」をうたっているものの、それを危うくする操作がカジュアルにできてしまっていて、うたい文句と実質がずれている、という話
(b) そもそも「null安全」で達成される性質がどの程度嬉しいのか、ということの疑念
posted at 13:57:41
わけで、本気で「null安全」(先ほど自分が言ったような意味での)を追求しているのなら、カジュアルに!!使えたり、他の言語でもそれが簡単にできるっての、どうかと思うわけです。実用的にそうする意図はわかるものの。
posted at 13:49:24
もうちょっと細かくいうと、実のところ「null安全」な言語では、型検査を通ったプログラムでNullPointerException(相当)が発生しない、という性質だととらえるのは意味がある一方で、カジュアルに!! とかでnullableを「はずせる」っていうのは(実用的にはわかるものの)「null安全」を危うくしてる
posted at 13:46:08
nullable/not-nullabeの型レベルでの区別がKotlinをはじめとした色々な言語に取り入れられた事自体は望ましいし、素直に良かったと思うのですが、それが、「null安全」というキャッチーだけどビミョーな言葉に吸収されていくのは喜べないなあというのが正直な気持ちです。
posted at 13:39:12
Hidemoto Nakada@hidemotoNakada
ある言語が「null 安全」かどうか、ってどうやって判断するのだろうか。Juliaも 型Aの変数にnothing は代入できない。かつては Nullable{A} みたいな記法があったみたいなのだけど、今はなくてunion{A, Nothing} と書くことが推奨されているようだ。
Retweeted by kmizu
retweeted at 13:24:09
「韓国のサムスンや中国のメーカーはすごいぞ」という人に「やはりこれからは企業と政治が癒着する時代なのだ。財閥復活! 財閥復活!」っていうとなぜか怒られそうなのは腑に落ちないんだけど「豊かだった時代の日本を取り戻せ」論と合わせると、財閥と政治家が癒着するの理想だと思うんだけどなあ
Retweeted by kmizu
retweeted at 13:15:16
@gakuzzzz あ、そういう話ならわかります。理由っていうのが漠然とした書き方だったので、ちょっと誤解していました。そういうものをコメントで書けって話ならわかります。
posted at 12:50:18
@gakuzzzz 実際に私がget()したくなった話としては、 ASTからASTへの変換処理中に、ある構文木ノード中の要素が必ずSomeになることがあって、でも、そのために別のASTの階層を作るのは正当化できない、という話がありました。
posted at 12:43:57
@gakuzzzz なぜNoneにならないのにOptionを選択したか、に関しては、型としてはOptionであっても、一般に、利用側での特定の実行パスを経ることによって != Noneであることがわかる場合がある、というのが私の答えになろうかと思います。
posted at 12:42:38
@gakuzzzz そこはまさに「方便」としては、「原則使わない」はありだと思っているので、それでいいのかな、というのが一つの答えで、「方法論」としては、そもそも一つのワードで書けない(もう少し詳細な場合分けが必要)、ということになろうかと思います。
posted at 12:40:56
@gakuzzzz 証明できるなら型で縛れる、はScalaの型システムの下で、だと、正しくないと思います。フルスペックの依存型がある言語ならともかく。
posted at 12:31:41
@gakuzzzz その問題意識はわかります。一方で、コメントで書く、というの、審査するコストがかかるとも思います。軽々しく使ってしまえる、get()という名前が良くなくて、assertNotNoneAndGet() くらいにしてくれると、表明しているということがわかるのかなあ(私はget()するときは常に表明しているつもりです)
posted at 12:30:14
@gakuzzzz どう防ぐかという観点でいうと、業務を円滑に進めるための「方便」として「原則使わない」はわかるものの、方法論を提示する観点では、「原則使わない」は何も言っていないのかなという意見です。
posted at 12:26:24
@gakuzzzz あと、「なぜ」をコメントで書くというの、assert v != Noneの根拠を書くってことになるのでしょうか。それは有効だと思いますが、突き詰めると証明プログラミングみたいな話になりそうです。
posted at 11:55:47
@gakuzzzz これは、MeyerのOOSC 2nd editionでも類似の話があったのですが、不必要にget()使いたいわけもなく、必要な箇所だと思ったからこそ、get()したいのであって、それに対して、「原則使わない」は回答になっていないよなあと。もちろん、よくわからず使う人への戒めとしてはわかるんですが。
posted at 11:53:11
@gakuzzzz 私は、その「原則使わない」って言い方が結構曲者だと思っています。気持ちはわからなくもないのですが、どういう場合に原則に当てはまらないかという言及がないので、その原則って何ぞやってなるわけで。
posted at 11:51:03
Catsとかを使うことと、Scalaで関数型プログラミングをすることは全く別のことなんだけど(Scalaで不変コレクションを使ったプログラミングをするだけでも、関数型プログラミング(=副作用をなるべく用いない)をしてることになるはず)、そこらへんがしばしば誤解されてる気がします。
posted at 11:23:39
で、そういうときに、原則!!は使わないとか、原則get()を使わない、というルールだけだと(安易にそうしてしまう人への警鐘として意味があると思いますが)、問題は解決しないよなと。
posted at 11:19:33
null安全の話なんですけど、私の経験上、いったんnullable(あるいはOption)にしたものの、利用側の特定のコンテキストで assert v != null; あるいはassert v != Noneという表明をしたくなる(つまり、ある実行パスでnon-nullableであると確信している)ことがしばしばあります。
posted at 11:18:25
ご利益は色々あると思うのですが、たとえばDSLの構文や意味論を定義するときには役に立つと思いますし、既存のプログラミング言語の構文や意味論を相対化して考えられると、単に「与えられた言語から選ぶ」だけでなく、マクロなどによって新しい「構文」を定義して使うという考え方も得られるかなと。
posted at 11:07:41
その一つとして、プログラミング言語論はかなり重要だと考えていて、それが、プログラミング言語ハンズオンとか構文解析ハンズオンをやる動機につながっています。
posted at 10:58:53
この意見には自信を持てていないのですが、プログラミング教育と同時にコンピュータサイエンス教育もちゃんと行われるとよりよいと最近思います(この、コンピュータサイエンスといっても幅が広いのでどこまでを選択するかという問題がありそうですが)。
posted at 10:52:59
@kis 生存者バイアスに加えて、選択肢が2つだけではないのに2択の問いにするミス、良し悪しを2軸で測ろうとするミス、「誰も助けてくれない」環境がいいと言ってるツイートで「困った時に助けてくれるメンターがいた方がいい」という整合性のなさ、など問題だらけなので添削課題として有用そうですね。
Retweeted by kmizu
retweeted at 10:46:50
できる人だけついてくるやつを、できる人を育てる方法だといわないほうがいいと思うのよね。
Retweeted by kmizu
retweeted at 10:46:30
生存者バイアス。。。教育方法論が未熟なことを、プログラミングの特性にしないほうがいいと思う https://twitter.com/uuyr112/status/1158893016561508352…
Retweeted by kmizu
retweeted at 10:46:24
@kis こういうシゴキっぽい論が蔓延るのは、なんなんでしょうね…。
posted at 10:46:15
@koher もうちょっと詳しくいうと、要するにテキトーに型をnullableにしたところで、!= nullだと利用側が判断したら、Kotlinでいうところの!!が使われるだけ(単にNullPointerExceptionの発生場所が変わるだけ)なので、何をnullableにするかの基準まで示して本当の問題解決だろう、という意図です。
posted at 10:42:41
@koher どもです。その、null safetyというのは、型レベルでのnullable/non-nullableの区別のことをさしていますか?だとすると、私の言いたいこととしては、null safetyというキャッチーな言葉で、nullに関する問題が解決されたかのように言うのは危ういということです。
posted at 10:39:28
2件のコメント https://b.hatena.ne.jp/entry/s/mametter.hatenablog.com/entry/2019/03/27/211140… “新雑誌「n月刊ラムダノート」の『「コルーチン」とは何だったのか?』の草稿を公開します - まめめも” (51 users) https://htn.to/3RHuef5fcF
posted at 01:55:23
@kis @curelemonade2 個人的な経験では、JVM言語を効果的に使う上ではJVM知る方がより良い、という気がします(JVMを知る、はJava言語より知る、より難しいですが)。
posted at 01:46:37
Gmailが新UI(って1年以上前か)になってからか、色々変な挙動(メールを開こうとすると失敗するがリロードすると成功する、が度々起こるのが特に代表的)に悩まされることが増えた気がする。Chromeに拡張機能ほとんど入れてないので、それ以外の理由だと思うのだけど。
posted at 00:53:58