X
次世代言語Part8[Haskell Rust Kotlin TypeScript]
■ このスレッドは過去ログ倉庫に格納されています
0773デフォルトの名無しさん
垢版 |
2018/02/19(月) 09:53:32.16ID:isUwiiOH
>>767
便利さを教えてほしいな。
純粋なnilと型があるけど中味はnilって正直わかりづらくないかな。
reflectionのお勉強をしないと理解できない。

Goのインターフェースは後出しジャンケンってのは面白いな。パクらせてもらおう
0775デフォルトの名無しさん
垢版 |
2018/02/19(月) 12:10:56.39ID:BdVjRyEG
>>773
それがnilでも、メソッドチェーンできる。
だから、errを伝搬するのに便利。
末尾のDoなんかで、本当の結果,errorとして取り出せば良いよ。
いちいち失敗構造体なんぞ書かんでも良い。
Nullable的に使える。

どっちかというと下回り書いてるときに便利かも。
0776デフォルトの名無しさん
垢版 |
2018/02/19(月) 12:44:49.19ID:g9K5jJLr
>>774
C++はテンプレートを使ってダックタイピングができる
Haskellはアドホック多相を使って>>772でいうcomparator引数に相当する要求をTの型制約に含められる
0777デフォルトの名無しさん
垢版 |
2018/02/19(月) 14:19:03.08ID:x9oxab6h
>>775
なんかサンプルある？とょっとイメージがつかめない。nilでメソッドチェーンができるのはわかるけど、それがメリットになるかな？
結局nilを、返してるメソッドがエラー状態な訳で、そいつが暫定的な値を返せばメソッドチェーンはできるよね。
0779デフォルトの名無しさん
垢版 |
2018/02/19(月) 16:10:57.83ID:BdVjRyEG
>>777
暫定的なオブジェクトに、レシーバ書いてくの？
Hoge().Get().ReadAll().AsString()
で、毎度nilチェックとか暫定レスポンスのオブジェクト置いてたら非効率じゃん。
ToXXX以外の関数が、Hoge()の返す型やinterfaceを返せば楽じゃない？
Getに失敗したかReadAllに失敗したかが必要ならまた別だろうけど、だいたいひとからげにして問題ない事の方が多い。
0780デフォルトの名無しさん
垢版 |
2018/02/19(月) 18:59:46.08ID:esiJbF27
>>779
error情報を最初から諦めるってことね。
とにかく最終結果がnilだからメソッドチェーンのどっかで失敗してんだろーなー。くらいの感じなのか。

標準ライブラリでそういう実装してるのあるかな？reflect.Valueとかかな。
あれメソッドチェーンできる代わりに不正なメソッド操作するとpanicしててなかなかしんどい。
0782デフォルトの名無しさん
垢版 |
2018/02/19(月) 19:14:13.94ID:esiJbF27
流れをぶった切って悪いけどTypeScriptはさすがMS。開発リソースたっぷり。という余裕を感じる。vscodeと一緒に毎週くらいの勢いでアップデート繰り返してる。

ジェネリクスの気持ち悪さもエラーメッセージがわかりやすく進化する感じで直してくれれば全然良いので頑張ってもらいたい。
0783デフォルトの名無しさん
垢版 |
2018/02/19(月) 19:17:59.63ID:u7QgBPEb
goのことは全然知らないんだが、型付きnilとやらは実行時ディスパッチしてくれて
その型のメソッドにnil引数付けてやってくるという理解でOK？
0784デフォルトの名無しさん
垢版 |
2018/02/19(月) 20:22:12.51ID:BwjO59+V
まずメソッドではなくて、ちょっと変わった構文のの関数ぐらいに受け取ったほうが良いかも。
Foo.Bar()は
Bar(Foo)と、
Foo.Bar(a,b)
は
Bar(Foo,a,b)と同じぐらいの意味。
だからFooがnilでも(ポインタに対してのレシーバであれば)呼べる。
0785デフォルトの名無しさん
垢版 |
2018/02/19(月) 23:02:26.53ID:cDVYUoQ2
やはりメソッドチェーンは何回も値 (nil) を返すのが気になる

Haskellでは
((Nothing >>= f) >>= g) >>= h
こうするとNothingのパターンマッチを3回するのに対し
Nothing >>= (\ y -> f y >>= (\ z -> g z >>= h))
これなら1回だけ
0790デフォルトの名無しさん
垢版 |
2018/02/20(火) 05:20:12.69ID:o3fs2Zzy
goの場合nilの場合分けを関数の中でしなくちゃいけないわけだろ。
それが嫌だからモナドができたわけだからな。
メソッドチェーンも嫌だからasyn/awaitとかdo構文が出来たわけで
全部が劣っているな。
0791デフォルトの名無しさん
垢版 |
2018/02/20(火) 17:49:07.93ID:uyRcVPMC
秀でるのと、こねくりまわすのは違うからな。
原理上、変態構文と純でも何でもないモナドで出来るとか抜かすぐらいなら、nilチェックするほうがマシ。
0792デフォルトの名無しさん
垢版 |
2018/02/20(火) 18:26:18.82ID:SK024iMW
コンパイラはモナドをコンパイルエラーにしない
一部の人間は忖度してモナドを自主規制する
コンパイラと人間はどっちが正しいかというだけの話
0793デフォルトの名無しさん
垢版 |
2018/02/21(水) 18:12:35.61ID:WKR1veUF
機械と人間の両方に指図されるのは不自由過ぎる
両方採用するのは過激派
どっちか一つだけにした方が中道という可能性がある
0795デフォルトの名無しさん
垢版 |
2018/02/21(水) 20:32:34.11ID:qR5uNCei
そもそもnil安全にする必要もない。
その変数に型的にnilが入ることが無かろうがあろうが、
他の言語のnullとはちと違うレベルでnilを取り扱える。
タプルで返す前提だと大した問題には無いと言うか。
他の言語は、nullに本来のその型が持つ意味以上の意味を与えてしまうからわざわざnull安全にしないといかんのでは？
0796デフォルトの名無しさん
垢版 |
2018/02/22(木) 02:26:39.63ID:zGB/N5H/
タプルで値が返せるから必要ないってただの理屈の上の話で、エラーチェック漏れをおこしたり、エラーチェックしててもnilの入った変数を次の処理に引き継ぐミスは起こり得るだろ。それを防ぐのがnil安全なわけで。
0797デフォルトの名無しさん
垢版 |
2018/02/22(木) 04:32:43.91ID:+RpZ2cWG
俺も>>797と同意
>>796の言ってることはいまいちよく分からん
nilに余計な意味を与えるからダメとか言ってるがnil自体がそもそも余計だと思う
nilは便利すぎるがゆえにチェック忘れ系の地雷がある
ポインタ演算みたいに強力な機能は同時に危険も引っ付いてまわる
そういった機能は出来うる限りは排除・制限していくべきだと思う
0799デフォルトの名無しさん
垢版 |
2018/02/22(木) 08:14:10.74ID:p8NiYEqx
同僚のコトリンのコードがビックリマークだらけで、こりゃだめだと思った
0800デフォルトの名無しさん
垢版 |
2018/02/22(木) 08:54:55.92ID:MB1I4+Gh
だから、便利に使わなければ良いと思うんだが。
参照にしない限りnilにはなれないし。
0801デフォルトの名無しさん
垢版 |
2018/02/22(木) 12:53:25.00ID:+RpZ2cWG
>>797
すまん。番号ズレてるな。以下訂正
> 俺も>>796と同意
> >>795の言ってることはいまいちよく分からん

スマホアプリ使ってると時々ズレるんだよな クソが
そのせいで自分で自分に同意するというアホな文章になってやがる
0803デフォルトの名無しさん
垢版 |
2018/02/22(木) 14:54:41.89ID:ei88pKkZ
>>798
基準がどうこうってnil安全な言語ってのがわかっていないのかな?
設計思想とかの話じゃなく言語仕様の話をしてんだけど。
つまり変数に明示しない限りnilを代入不可能な変数が作れるってのか
nil安全な言語ってこと。
TypeScriptなら

let some?:number = null; // OK
let some:number = null; // NG
ってこと someにnullが入っている可能性をコンパイル時点で排除できる。

Goだって

func hoge(s *Some) {
// sが絶対nullじゃないことが保証されるスコープ
}
func (s? *Some) SomeFunc() {
if (s != null) {
hoge(s)
}
hoge(s) // NG コンパイルエラー sがnullである可能性が残っている
}
みたいな感じで書ける。?が使えると仮定
0804デフォルトの名無しさん
垢版 |
2018/02/22(木) 16:43:44.83ID:ePT/3hrM
>>803
しょぼ！
その例はnull安全の中でも一番弱いやつ。
書き方を気をつければnullを避けられるってだけ。
本物のnull安全はスコープ単位ではなく、型検査が通ればプログラムにnullによる誤りを完全に排除されるんだよ。Haskellのように。
0805デフォルトの名無しさん
垢版 |
2018/02/22(木) 17:06:16.89ID:zGB/N5H/
>>804
elmも実行時エラーを完全排除できるというのを売りにしてたね。
しょぼくても学習コスト最小でメリットは十分享受できる。
とりあえずelm触ってみようかな
0807デフォルトの名無しさん
垢版 |
2018/02/23(金) 01:19:34.60ID:i8nFKqus
動的型で解決できる問題はすべて静的型で解決できるし
もしこれが嘘八百だと証明されたとしてもそれはそれで大きな成果だし
いずれにせよHaskellは静的型の歴史に貢献している
0810デフォルトの名無しさん
垢版 |
2018/02/23(金) 10:35:29.52ID:fGTUWBf8
実在するだけでは不満か
実在すら怪しいものがあったらもっと不満だろ
実用よりも実在の方がモチベーションが強い
0811デフォルトの名無しさん
垢版 |
2018/02/23(金) 10:45:07.36ID:HJaUFAvs
>>809
ラテン語は良い喩えだね。印欧語ヒエラルキーの上の方にいるし。
俗ラテン語を見て、どこが欠落してるかの見通しが良くなる。

Haskellも足りてないけどさ、型理論的に。そういう点でもラテン語あたりなのは妥当。
0812デフォルトの名無しさん
垢版 |
2018/02/23(金) 11:35:44.21ID:2M6dxKUJ
コンパイル時に解決できるならそれに越したことは無いが
そのための学習コストは増大する傾向にあるよね。
Elmはブラウザのviewに特化したDSLとして学習コストを抑えてる。
Rustもメモリリークを静的に解決しようとするけどそのためのコストはかなり高め。
何事もバランスだよね。
0813デフォルトの名無しさん
垢版 |
2018/02/23(金) 21:27:40.00ID:LZyM23a9
>>811
そう。
そんなに格いるか？確かにあれば便利だけど前置詞のほうが実質簡潔じゃねえの？とか、
今更ラテン語使う必要無いだろ。足りない語彙を現代語から借用するの？とか、
ヒエラルキーの上位と言うより、広がる枝の根本にほうっておかれた存在だろ。
全く次世代で無い。
0814デフォルトの名無しさん
垢版 |
2018/02/23(金) 22:03:17.49ID:GuloKGfV
Haskellの熱心なアンチが全くのエアプだった事件があるので、そういう意見はHaskellに精通していることを示さないとなかなか受け入れられないと思うよ
0815デフォルトの名無しさん
垢版 |
2018/02/23(金) 23:44:14.84ID:NePmI3sA
まあカス仕様を必死に守るのにコストかけるくらいなら
goみたいにコンパイラの性能上げてもらった方がよっぽど有益だったりはする。
0817デフォルトの名無しさん
垢版 |
2018/02/24(土) 01:03:27.04ID:67+llEBF
>>814
エアプって言葉好きだなぁ。
正直触ってダメ出ししたぐらいだけど、精通せんでも文句は言える。
ラーメン食いに行って「まずいわこれ」って言って、店主に「じゃあお前はこれ以上のラーメン作れんのかよ」「それだけラーメン食って言ってるのか？」ってキレられても困るだろ。
客観的にまずいもんはまずい。まずいと誤解されるものもその次にまずい。
0818デフォルトの名無しさん
垢版 |
2018/02/24(土) 01:06:09.79ID:67+llEBF
意識高い系のおもちゃとして使うんじゃなくて、なんか使えるプロダクト出してから言ってくれよな。
古代言語を次世代言語スレで出すんなら。
0820デフォルトの名無しさん
垢版 |
2018/02/24(土) 02:01:52.41ID:9192Hwvs
goにはクラス階層も無いんでしょ？ジェネリクス以外の多態が無いならまだ綺麗に導入できる可能性がある
swiftはバージョンアップで型推論を入れるようなスジの悪い進化を進めてるから好きになれんよ
0821デフォルトの名無しさん
垢版 |
2018/02/24(土) 06:02:14.88ID:VvbK4X3N
コンパイル速度優先の上で云々ということであれば
goがDelphi/FreePascalを超えてるかというのは正直疑問
0823デフォルトの名無しさん
垢版 |
2018/02/24(土) 07:57:18.04ID:ZueQv0Xl
>>821
現在も絶賛コンパイル速度更新中だからいいんじゃないの。
そもそもdelphiって古すぎて早く見えるってだけでは、、、？

>>822
interfaceを進化させるイメージでジェネリクスぽいものを作るんだろうね
現状複数のinterfaceを受け入れる可能性のある変数は空インターフェース(interface{})
(javaでいうところの何でもありのObject型みたいなの)
にするしかないのがツラミになってる。
ここを改善する方向に進化させるでしょう。
直積型をつくるのはできてるから直和型(union)をサポートして
someFunc(o interface{}) error {}
みたいなのを
someFunc(o A & B) error {}
someFunc(o A | B) error {}
みたいにできればいい。TypeScript好きだからこうなったら感動する
0825デフォルトの名無しさん
垢版 |
2018/02/24(土) 11:20:37.36ID:pBIylWjV
古すぎて速いってのは正しい
あとはジェネリクスがない言語は古いと認識できたらもっと正しい
0828デフォルトの名無しさん
垢版 |
2018/02/24(土) 14:17:22.06ID:WPlCcRak
>>825
TypeScriptの最近のジェネリクス変態進化ぶりを見ていると
ジェネリクスが正しいという意見も
なんとも言えないかも。
0829デフォルトの名無しさん
垢版 |
2018/02/24(土) 14:39:08.92ID:ozvKRveg
言うほど変態か？
JSによるOOPの実装方法や、即値を型として扱うTypeScriptの特性を十分に理解してないと
new () => Tとかkeyofなんかは分かりにくいかもしれないけど、それはGenerics以前の問題だろ
基本的には必要以上の驚きのない自然な仕様だと思うよ
0831デフォルトの名無しさん
垢版 |
2018/02/24(土) 15:44:01.13ID:ozvKRveg
>>830
これくらい何とも思わないな
所詮は型アノテーションを正しく引き継ぐためだけの仕組みだぞ？
生成されたコードをデバッグしなきゃいけないテンプレートとは訳が違う
0833デフォルトの名無しさん
垢版 |
2018/02/24(土) 17:03:15.17ID:ZueQv0Xl
>>832
こういうエラーメッセージと戦うのが辛いのって結局途中経過を追えないってことなんだよね。
goはコードジェネレート前提だったりする。
そっちだと分かりやすいコードを吐いてくれれば追いやすい。
0834デフォルトの名無しさん
垢版 |
2018/02/24(土) 17:08:20.40ID:yL1hQTQw
>>833
つまり言語仕様の問題じゃなくてコンパイラが途中結果を出力しないのか問題なんだろ？
MSが改善すれば済む話
完全に論理が破綻してるね
0836 ◆QZaw55cn4c
垢版 |
2018/02/24(土) 17:14:56.38ID:yWQ45jBy
>>832
C++ とて似たようなものだ、ジェネリクスのエラーメッセージは総じて汚らしい
0837デフォルトの名無しさん
垢版 |
2018/02/24(土) 17:15:40.58ID:NYPMK72i
>>834はコンパイルがクソ遅い言語に対しても
問題は言語仕様じゃなくてコンパイラの所為だと思ってそう
0838デフォルトの名無しさん
垢版 |
2018/02/24(土) 17:26:03.56ID:WPlCcRak
>>834
論理がはたんしてるか？
というかコンパイラの挙動と言語仕様を分けて考える意味がわからない。

言語としての素晴らしさはそれを囲むエコシステム全体を含めて語っていいと思うが。
0839デフォルトの名無しさん
垢版 |
2018/02/24(土) 17:29:02.21ID:WPlCcRak
>>836
これ。ジェネリクスは人間に牙を向くのが辛い。ライブラリ開発者でうまくエラーをラップできたりすれば良いんだけどね。　
0840デフォルトの名無しさん
垢版 |
2018/02/24(土) 17:43:47.02ID:yL1hQTQw
>>832が分かりにくいのって、structual-subtypingで特定のメンバの型に互換性がないのを
「型同士の互換性」の単位で出力してしまってるからじゃないか？
TypeScriptならVSCodeに代入元と代入先の型を展開した状態で比較するビューが付けば解決だと思う
0841デフォルトの名無しさん
垢版 |
2018/02/24(土) 17:51:04.11ID:ZueQv0Xl
>>840
あと、もしかしてこう書きたかったんじゃなりませんか？ みたいにannotationをコンパイラが出してくれるとかね。
rustってそういう感じだっけ？
0842デフォルトの名無しさん
垢版 |
2018/02/24(土) 17:54:41.90ID:ZueQv0Xl
ちなみに >>832 のエラーはTypeScript2.5.3では出ない。2.6以降にすると出るようになる。
コードとしては何の問題もなく動くんだよね。
バージョン上げるたびに修正するのしんどくて放置してる。
0845デフォルトの名無しさん
垢版 |
2018/02/24(土) 20:27:10.88ID:67+llEBF
する必要の無いものをチューリング完全にしてしまったが故にえらいことになったプロジェクト見てきたし、
そもそもコンパイルの時点で無限ループしかねないとかどんな闇言語だよって話になってくるじゃん。
Scalaも型システムだけでコンパイラ止めれたっけ。
0846デフォルトの名無しさん
垢版 |
2018/02/24(土) 21:39:56.69ID:Wx4opHQO
c/c++ のヘッダ処理なんかもデバッグしやすくするのとコンパイル効率は
かなりトレードオフがあるってのが一般的。
だから visual studio が内部で変なことガツガツやってるわけで。
そんなもん２、3年本気で仕事すりゃわかることだろうと思うんだが
なぜか理論よりの人間は事実を認めない傾向にある。
0847デフォルトの名無しさん
垢版 |
2018/02/24(土) 22:16:50.94ID:8UiUrtqZ
チュリ完であることそれ自体が問題なのではなく、デバッグ回りが弱すぎるのが問題なのだ
0848デフォルトの名無しさん
垢版 |
2018/02/24(土) 22:36:20.17ID:CuRF79s8
>する必要の無いものをチューリング完全にしてしまったが故にえらいことになったプロジェクト見てきたし、

それ、「えらいことになった」原因が本当にチューリング完全のせいだったのかね。
0849デフォルトの名無しさん
垢版 |
2018/02/24(土) 22:55:49.93ID:WPlCcRak
少なくともc,c++の依存関係解決の遅さの解決のためにgoが生まれたってのがgoogleの言い分なわけだし、遅いは遅いんじゃないの。
goにプリプロセッサが無いのも意味があるわけで。
0851デフォルトの名無しさん
垢版 |
2018/02/25(日) 00:02:11.41ID:/LdYt4iz
ちなみにredoxというrustで書かれたosはコンパイルは早いんだろうか。lunuxと単純比較はできないだろうけども
0853デフォルトの名無しさん
垢版 |
2018/02/25(日) 07:45:46.39ID:Pn1I1KPs
そりゃチューリング完全であることが問題なんじゃなくてそのチームに問題があったんだろ。
世の中にチューリング完全なシステム(言語)は腐るほどあるわけだし。
0855デフォルトの名無しさん
垢版 |
2018/02/25(日) 09:34:28.35ID:5I/H3HR9
できちゃうことが問題なんじゃないの
c++の型システムがチューリング完全だと自分たちだけがコンパイル速度に気をつけても
依存しているサードパーティライブラリまでは保証できないでしょ。
だったら言語側で制限がかかっておいてほしいって話。

Cの依存性解決も#ifdefを駆使してプリプロセッサの自由度を持って後付で解決していた。
プリプロセッサ自体便利なものだけど、それが原因でコンパイル速度の低下を招いた。
というのが >>819 に書いてる。

汎用性がある機能はなんでもできるからこそ、コンパイル速度を落としたり迷惑を書けることも可能。
swiftもGoも後発言語だけどプリプロセッサのってないもの
rustのマクロの自由度は知らんけども。
0856デフォルトの名無しさん
垢版 |
2018/02/25(日) 10:45:11.82ID:AkGT52Is
テンプレートやマクロで無茶をする奴が
コードジェネレータで無茶するようになるだけ
0858デフォルトの名無しさん
垢版 |
2018/02/25(日) 11:41:56.21ID:oFPVlXbE
あるC++のファイルを変更したら
そのファイルがincludeした全てのコードを再コンパイルする
型情報のみをincludeすればいいのに型ではない値とコードが大量に入ってる
この値とコードが原因だよね
チューリング完全はそこから生じた結果の一つ
0864デフォルトの名無しさん
垢版 |
2018/02/25(日) 15:13:14.53ID:iLEoqX9J
>>853
まあバカな奴をチームに入れないためにc++を採用しないって主張をするリーナスは
ある意味正しいな。
0865デフォルトの名無しさん
垢版 |
2018/02/25(日) 16:03:19.53ID:jkdNIq8n
>>858
それはちょっと違う
そもそも今時フルコンパイルなんてそんなに重いものではない
C++がまずいのは、includeしたヘッダのコンパイル結果をコンパイル単位(.cpp)を跨って共有できないことだ
プリプロセッサのせいで毎回変わる可能性があるからな
0866デフォルトの名無しさん
垢版 |
2018/02/25(日) 16:17:08.31ID:UX7CM2uT
>>864
リーナスはc++がクソだって言ったんだよ。
その次に使う人間もクソが多いって言ったの。、間違えんな
0868デフォルトの名無しさん
垢版 |
2018/02/25(日) 17:25:46.72ID:eL53m5ic
リーナスはもともとアセンブラーやからのうｗｗｗ
Cは複数のCPUのアーキテクチャーに適応するためにどうにゅうしたわけやしのうｗｗ
0870デフォルトの名無しさん
垢版 |
2018/02/25(日) 18:22:22.98ID:iLEoqX9J
linux もだいぶヘッダマクロでテンプレみたいなことはやってる。
もちろん型安全ではないがそれでもc++のテンプレート使うよりマシという判断をしてるわけだよ。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況