次世代言語Part7[Go Rust Swift Kotlin TypeScript]

**デフォルトの名無しさん** · 2017/10/19(木) 17:51:38.66

文字数制限きついので改題
スレタイ以外の言語もok

前スレ
次世代言語議論スレ[Rust Kotlin Haskell]第6世代
http://mevius.5ch.net/test/read.cgi/tech/1503924817/

**デフォルトの名無しさん** · 2017/10/26(木) 00:31:32.93

rustのコンパイルを通せない低級汚グラマーが
嫉妬で腐してるだけだろ

腐ってるのはテメーの言語センスだろってね

**デフォルトの名無しさん** · 2017/10/26(木) 00:32:53.75

Haskell言語って何だ
夜は誤字増えるから寝よう

**デフォルトの名無しさん** · 2017/10/26(木) 00:50:43.34

>>150
なるほど、でも面白そうだな

パフォーマンスは良いって聞くし
haskellも好きだし一通り触ってみるかな

**デフォルトの名無しさん** · 2017/10/26(木) 03:24:21.96

まあ御託はいいからデータコピーなしの平衡二分木をRustで書いてからにしてくれよ
Cのコードは出たぞ

**デフォルトの名無しさん** · 2017/10/26(木) 05:10:18.37

Haskellなら副作用だらけのコードは断固拒否するだけだが
Rustで副作用を拒否すると延々と粘着されそう

ついでにPythonは静的型を拒否するだけだが
Goはジェネリクスがない件で永久にいじめられるんだろう

**デフォルトの名無しさん** · 2017/10/26(木) 07:04:11.52

Haskellは速さは捨てて副作用を無くすことに全振りしてるけど、Rustはそうではないからな

**デフォルトの名無しさん** · 2017/10/26(木) 09:12:10.17

Rustはunsafeつかえば（ffiしたほうがはやいだろうが）できないことはないと思ってるんだが違うのかな？

**デフォルトの名無しさん** · 2017/10/26(木) 09:59:20.18

Goはいつものgoogleのフカしで持ち上げられてる感がプンプンするぜ。
単なる昔ながらのVM使ってない静的型付け言語を
システムプログラミングとかいうバズワードを作って
スクリプトしか描いたことない奴らにいかにも新しいものであるかのように錯覚させてる。

**デフォルトの名無しさん** · 2017/10/26(木) 10:42:13.95

>>157
初めからプログラム全体をunsafeで囲ってある状態を仕様にすればいいのにな

>>158
バズワードだろうがなんだろうが、速くて書きやすけりゃ正義よ

**デフォルトの名無しさん** · 2017/10/26(木) 10:47:47.28

最近は新しいOSSもGoで書かれてるの多くてうんざりする
再来年辺りには「Goは終わった」とか言われだしてScalaと同じ道を辿るのわかりきってるのにWeb系の馬鹿共は何度同じ間違いを繰り返すのか

**デフォルトの名無しさん** · 2017/10/26(木) 11:10:35.34

個人的にはDが一番純粋なc++ 後継って感じで頑張って欲しいんだけどなぁ
まったく流行る兆しがない……
別に新しい言語を求めてるんじゃないんだ。c++ からc互換を取り除いて標準ライブラリと文法見直してくれるだけでいいんだ

**デフォルトの名無しさん** · 2017/10/26(木) 11:45:28.73

>>160
「新しいOSSもGoで書かれてるのが多」いのに
「再来年辺りには『Goは終わった』とか言われだ」すのか。すげえな

まあGo2.0の漏れ聞く噂によると可能性なくもないんだが

**デフォルトの名無しさん** · 2017/10/26(木) 11:47:37.13

>>161
GC言語な時点でそりゃねえわ
全く同じ理由でGoもC++の完全な後継ではないと思ってるけど

**デフォルトの名無しさん** · 2017/10/26(木) 11:54:33.47

>>162
Scalaという前例があるからね
特にビッグデータ系はScalaのOSSが多くて悲惨だよ
壮大な糞の山が残されてしまった

**デフォルトの名無しさん** · 2017/10/26(木) 12:17:09.48

>>164
Scalaが廃れた理由は、言語のバージョンアップ戦略がクソofクソだったってのと
コンパイル回りの性能が悪いっていう言語自体の特徴、
それから置き換えを狙っていたはずのJavaの進化に取り残されたことっていう色々と複合的な原因がある

Goがその後追いをするかって言われると、
少なくとも書きやすさの面でC++がGoに勝てる目は向こう5年はないだろうし、
バージョン戦略は少なくとも1系の間は下位互換性崩さんだろうしな

**デフォルトの名無しさん** · 2017/10/26(木) 12:19:58.53

不安があるとするなら、なんか1系と完全に互換性なくすとか言われてるGo2.0なんだよな
この辺の方針次第では、おっしゃる通り再来年にはゴミの山になってる可能性が無視できない

Swiftがクソバージョンアップでもなんとか成功してるのはプラットフォーム囲い込んでるのがでかい

**デフォルトの名無しさん** · 2017/10/26(木) 12:27:59.75

AA木のRust版の移植を練習がてらやったぞ。
みんなunsafeが必要とか言ってるが、別に必要なくない？
ポインタ演算もサイズの違う型の変換もしてるわけじゃないから生ポインタ扱う必要ないと思うんだけど。
だた、マジで愚直に移植したから全くRustっぽくはないし、
俺がバカなだけで無駄なオーバーヘッドが気づかんうちにいっぱい発生してるかもだから指摘よろしく。
一応何回か適当にinsertとremoveして正しく動いてるとこまでは確認してる。
みんなunsafe使わないとダメ的なこと言ってるから正直これでいいのか全然自信がない。

**デフォルトの名無しさん** · 2017/10/26(木) 12:28:38.79

#[derive(Debug)]
struct Tree {
value: i32,
left: Option<Box<Tree>>,
right: Option<Box<Tree>>,
level: isize,
}

fn level(root: &Option<Box<Tree>>) -> isize {
if root.is_none() {
return 0;
}
root.as_ref().unwrap().level
}

fn left_end(root: &Option<Box<Tree>>) -> &Option<Box<Tree>> {
if root.is_none() {
root
} else if root.as_ref().unwrap().left.is_none() {
root
} else {
left_end(&root.as_ref().unwrap().left)
}
}
（続く）

**デフォルトの名無しさん** · 2017/10/26(木) 12:29:34.82

fn right_end(root: &Option<Box<Tree>>) -> &Option<Box<Tree>> {
if root.is_none() {
root
} else if root.as_ref().unwrap().right.is_none() {
root
} else {
right_end(&root.as_ref().unwrap().right)
}
}

fn skew(mut root: Option<Box<Tree>>) -> Option<Box<Tree>> {
if root.is_none() {
return root;
} else if root.as_ref().unwrap().left.is_none() {
return root;
} else if root.as_ref().unwrap().left.as_ref().unwrap().level != root.as_ref().unwrap().level {
return root;
}
let mut left = root.as_mut().unwrap().left.take();
root.as_mut().unwrap().left = left.as_mut().unwrap().right.take();
left.as_mut().unwrap().right = root;
left
}
(まだ続く)

**デフォルトの名無しさん** · 2017/10/26(木) 12:30:37.02

fn split(mut root: Option<Box<Tree>>) -> Option<Box<Tree>> {
if root.is_none() {
return root;
} else if root.as_ref().unwrap().right.is_none() {
return root;
} else if root.as_ref().unwrap().right.as_ref().unwrap().right.is_none() {
return root;
} else if root.as_ref().unwrap().right.as_ref().unwrap().right.as_ref().unwrap().level != root.as_ref().unwrap().level {
return root;
}
let mut right = root.as_mut().unwrap().right.take();
root.as_mut().unwrap().right = right.as_mut().unwrap().left.take();
right.as_mut().unwrap().left = root;
right.as_mut().unwrap().level += 1;
right
}

**デフォルトの名無しさん** · 2017/10/26(木) 12:31:04.94

fn decrease_level(mut root: Option<Box<Tree>>) -> Option<Box<Tree>> {
if root.is_none() {
return root;
}
let left_level = level(&root.as_ref().unwrap().left);
let right_level = level(&root.as_ref().unwrap().right);
let mut expected_level = 0;
if left_level < right_level {
expected_level = left_level + 1
} else {
expected_level = right_level + 1
}
if expected_level < root.as_ref().unwrap().level {
root.as_mut().unwrap().level = expected_level;
if root.as_ref().unwrap().right.is_some() {
if expected_level < root.as_ref().unwrap().right.as_ref().unwrap().level {
root.as_mut().unwrap().right.as_mut().unwrap().level = expected_level;
}
}
}
root
}

**デフォルトの名無しさん** · 2017/10/26(木) 12:31:51.05

fn insert_tree(mut root: Option<Box<Tree>>, value: i32) -> Option<Box<Tree>> {
if root.is_none() {
root = Some(Box::new(Tree {
value: value,
left: None,
right: None,
level: 1, }));
} else if value > root.as_ref().unwrap().value {
root.as_mut().unwrap().right = insert_tree(root.as_mut().unwrap().right.take(), value);
} else {
root.as_mut().unwrap().left = insert_tree(root.as_mut().unwrap().left.take(), value);
}
root = skew(root);
root = split(root);
root
}

**デフォルトの名無しさん** · 2017/10/26(木) 12:34:16.58

fn remove_tree(mut root: Option<Box<Tree>>, value: i32) -> Option<Box<Tree>> {
if root.is_none() { return root; }
else if value == root.as_ref().unwrap().value {
if root.as_ref().unwrap().left.is_none() && root.as_ref().unwrap().right.is_none() {
return None;
} else if root.as_ref().unwrap().left.is_none() {
let succ = {
let end = left_end(&root.as_ref().unwrap().right);
end.as_ref().unwrap().value
};
root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value);
root.as_mut().unwrap().value = succ;
} else {
let pred = {
let end = right_end(&root.as_ref().unwrap().left);
end.as_ref().unwrap().value
};
root.as_mut().unwrap().left = remove_tree(root.as_mut().unwrap().left.take(), value);
root.as_mut().unwrap().value = pred;
}
} else if value > root.as_ref().unwrap().value { root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value); }
else { root.as_mut().unwrap().left = remove_tree(root.as_mut().unwrap().left.take(), value); }

関数途中です（1レスに収まらんかった）

**デフォルトの名無しさん** · 2017/10/26(木) 12:37:30.92

root = decrease_level(root.take());
root = skew(root.take());
root.as_mut().unwrap().right = skew(root.as_mut().unwrap().right.take());
if root.as_ref().unwrap().right.is_some() {
root.as_mut().unwrap().right.as_mut().unwrap().right = skew(root.as_mut().unwrap().right.as_mut().unwrap().right.take());
}
root = split(root.take());
root.as_mut().unwrap().right = split(root.as_mut().unwrap().right.take());
root
}
終わり。
クソコードの上に長くてほんとすんません。

あと、おもてのコードでは一度もunsafeは使ってはないけど
Option型のtakeメソッドが所有権を誤魔化すために裏でunsafe使ってる。
あとは、裏でも使ってないと思う。

**デフォルトの名無しさん** · 2017/10/26(木) 12:39:25.88

Rustトーシロの初見だけどこんなにunwrap必要なの怖いって気分になるな……
CのポインタをOption<Box<>>で表現してるからしゃーないとはいえ

**デフォルトの名無しさん** · 2017/10/26(木) 12:39:26.85

ここまでやったらもう飽きた。
誰かメソッド構文とかコンビネータとかをきちんと使ったRustyなコードに書き換えて。

あ · 2017/10/26(木) 12:42:49.23

Rust嫌いな奴はCをすぐ引き合いに出すが、misraの案件やったら死ぬんじゃねえかなって思う。

GC言語も悪くはないぞ。ちゃんとGCの動き考えれば、正しく開放「されてない」理由もわかるだろ。
最初からデカイ配列を握って離さない、それを切り貼りして使う、みたいなJavaのプロジェクトあるしな。

**デフォルトの名無しさん** · 2017/10/26(木) 12:50:10.86

>>175
あくまでも愚直に書いてるからこんなにunwrapとas_refとas_mutだらけになる。
if letとかコンビネータとかをきちんと使えばこんなひどいコードにはならないよ。

**デフォルトの名無しさん** · 2017/10/26(木) 16:47:19.95

rustのコード<>だらけで読みにくい
これはlispの括弧みたいに慣れたら読みやすいものなのか？

**デフォルトの名無しさん** · 2017/10/26(木) 17:58:11.26

>>153
難しいとは言ってもOOP→関数型のパラダイムシフトに比べれば簡単だけどね

**デフォルトの名無しさん** · 2017/10/26(木) 20:01:45.08

>>154
おい、お前でてこいよ

**デフォルトの名無しさん** · 2017/10/26(木) 21:09:45.15

rust も haskell も理解できても面倒だし無駄に言語に気使ってるだけじゃねーかって
思うんだが、信者はききやしない。。
「お前らは理解できないものを理解できる俺偉い」で思考停止しちゃってんだよ。

**デフォルトの名無しさん** · 2017/10/26(木) 21:15:34.16

一番言語に気を遣わないといけないのはC++だがなｗ

**デフォルトの名無しさん** · 2017/10/26(木) 21:19:35.59

型っていうシステムが
そもそも良くないっていうのは無いの？

**デフォルトの名無しさん** · 2017/10/26(木) 21:46:13.96

>>181
出てきたが、お前まさかこんな汚いコード未満とCのコード比較させる気か？勝負にならん。解散

>>182
それならマシで、Rust信者の工作員はモジラブランドのためなら使えないものを世界中の企業に絶賛させるための工作をに熱心すぎてもうね

**デフォルトの名無しさん** · 2017/10/26(木) 21:54:28.12

>>185
おめー流石に一から書いてもいない奴が言うセリフじゃねえよ
Cライク信者からしても何様だてめえは

**デフォルトの名無しさん** · 2017/10/26(木) 21:55:02.68

>>185
てめえがしね

**デフォルトの名無しさん** · 2017/10/26(木) 22:34:09.13

>>182
「俺偉い」はさすがにないわ。笑かすな。

Rustに移植してみての感想だけど、確かにコンパイルを通すのには苦労したけど、
通ってしまえばメモリーリークはないって安心感がある。これが重要。
特に今回はunsafe一度も使ってないからなおさら安心できる。
Cのほうのコード一通り眺めてメモリーリーク無いって確信できる？
それができる超人君なら確かにRustは全く必要ないが。
Rustは君の嫌う面倒さと引き換えに安心を得ることができる言語。
むしろCで書いたコードにメモリーリークがあるのかないのか
自分の書いたコードに自信が持てないやつのためにこそRustがあると思ってる。
面倒だけが理由で思考停止しているのはどっちだ。

>>185
確かにこのコードは汚いよな。そこは自覚してる。
マジで誰かRust風に書き換えてくれない？
動いたところまで確認したところで集中が切れてしまってもうやる気が出ない。
Rustはオブジェクト指向も関数型のパラダイムを両方とも持っているし、
きちんと書けばかなり綺麗で整ったコードに書き直せるはずなんだよ。

あと、Rustアンチに１つ聞きたいことがある。
Rustが嫌いってことはわかったけど、じゃあアンチ君の好きな(愛用してる)言語は何なの？
その言語のメリット・デメリット含めて詳しく解説してくんない？

**デフォルトの名無しさん** · 2017/10/26(木) 23:26:00.76

はっきり言わせてもらうけれど、
この規模のコードで書くのにそれだけ苦労する価値があると思えんが。
メモリリークについてもこの規模なら一通り見て、あるかないかくらい判断できるよ。

まあ主観といえば主観だけれど
本当に本心からこの程度のコードについてメモリリークを心配しちゃってるの？
言語を持ち上げるために無理に納得しようとしてない？

**デフォルトの名無しさん** · 2017/10/26(木) 23:35:06.69

そりゃこの程度の規模じゃRust使うメリット皆無だよ
で、実際のプロジェクトがこの程度の規模なの？

**デフォルトの名無しさん** · 2017/10/26(木) 23:35:07.35

なんでこの規模に限定した話をされているの？

**デフォルトの名無しさん** · 2017/10/26(木) 23:37:41.83

Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/

**デフォルトの名無しさん** · 2017/10/26(木) 23:40:05.21

ブラウザの性能が圧倒的にchromeより上になったらrustの優位性が証明されるけど。
それをまとうかな。

**デフォルトの名無しさん** · 2017/10/27(金) 00:07:16.82

性能の差で優位性を証明したことなんて今まであったっけ
オブジェクト指向も関数型もiPhoneもみんな性能と関係ない価値観だったような

**デフォルトの名無しさん** · 2017/10/27(金) 00:42:45.70

>>185
さすがにコード一行も書いてない奴が言っていいセリフじゃねえわ……

>>189
さすがに後出し条件がひどい。そもそも発端は「Rustでは（unsafe使わずに）木構造すら書けねえだろ」って煽りが発端で
「さすがに木構造くらい（unsafeなし）Rustででも書けるわ」ってのの話がこれだろ

そりゃコンセプトが「安全性」なんだからCで書くより面倒なのは確かだし、この程度ならCの方がいいってのも当然だが、
そこを比較するために書いたもんじゃねえだろ

**デフォルトの名無しさん** · 2017/10/27(金) 00:47:50.32

見苦しくなってきたな

**デフォルトの名無しさん** · 2017/10/27(金) 03:40:11.56

流石に自演かすぎる…

**デフォルトの名無しさん** · 2017/10/27(金) 06:31:17.46

>>183
そんなことはないと思うが
何か具体例ある？

**デフォルトの名無しさん** · 2017/10/27(金) 06:34:38.22

>>195
言いたいことはわかるが
その「この程度」のも全部快適に書けるのが理想なわけだよね

この程度のをいっぱい書かなきゃいけなくなったときにこの調子じゃ萎える人も出てくるだろう

**デフォルトの名無しさん** · 2017/10/27(金) 09:50:28.38

>>195
安全性のためとか言って結局まともにかけないアルゴリズムがあることを見て見ぬふりの信者

健康のためなら死んでもいいを地で行ってるな
これが宗教ってやつか

**デフォルトの名無しさん** · 2017/10/27(金) 10:02:50.33

Rustが面倒そうなのは伝わったが
C側の奴がコピペ野郎のくせに暴れてるクズすぎてなんとも

**デフォルトの名無しさん** · 2017/10/27(金) 10:35:02.10

>>200
まともに書けるけど無料で教えてくれる人が少ないだけだってそろそろ気付けよ
普通は健康のためではなくカネのためにやってるから

**デフォルトの名無しさん** · 2017/10/27(金) 11:13:40.46

というかさ、Rustのコードバグってるんだけどwwwww
バwグwっwてwるwんwだwけwどwwwww
remove_treeで要素Removeできてないwwwww

Rustはコンパイル通れば安心できる（ドヤァ）とかいってバwグwっwてwるwwwww

**デフォルトの名無しさん** · 2017/10/27(金) 11:26:28.21

ここにRustは、安全性を高めると言いつつまともにアルゴリズムを書こうとすると制約回避のためにとてつもなく汚いコードになり、
バグもCより出やすくなることが公になりましたとさ

ちゃんちゃん

**デフォルトの名無しさん** · 2017/10/27(金) 11:40:28.33

>>198
言語に気を遣わないとすぐ自分の足元を撃ち抜く言語であるということに同意しないということ？

具体例っていざ言われると困るなあ。ふと思い出した阿呆な失敗談を一つ挙げると、クラスの値型配列を作れちゃうところとか、クラスは絶対ポインタで持たないといけないDとは対照的に感じたな

常識的に考えたらクラスの値型配列なんてやったらダメなのはわかるんだけど、なぜかやってしまって、コンパイル通ってんのに思ってたのと違う挙動して困ったわ。こういう常識的に考えたらわかるけど、考えないといけない部分があるから言語に気を遣わないとやっていけん。

これは全然大したことない例だけど、なんか他にもあったような気もするし思い出したら書き込むわ

**デフォルトの名無しさん** · 2017/10/27(金) 12:04:57.19

代入がなければ値型でもポインタでも同じ挙動だ
だから、代入しようとしたらコンパイルが通らない言語が現れた

**デフォルトの名無しさん** · 2017/10/27(金) 12:27:06.09

haskell追い出したら次はrustですか？

**デフォルトの名無しさん** · 2017/10/27(金) 12:49:17.54

追い出す権利はないね
あると思ってるやつは権利に甘えすぎ

**デフォルトの名無しさん** · 2017/10/27(金) 12:53:49.35

https://cpplover.blogspot.jp/2017/10/range-based-for.html

まあこう言う馬鹿がいなくなるまでは
実際のコードについて議論したほうがいいとは思うよ。

別にrustとかhaskellが悪いとは思わんけれど、コードなんて実際に現場で機能するかどうかが
一番重要なわけだから。原理に走ると都合の悪いことを無視し始めるのは気に入らん。

**デフォルトの名無しさん** · 2017/10/27(金) 13:27:23.45

>>203
すまぬ。すまぬ。完全なうっかりミスだったわ。
訂正した。

fn remove_tree(mut root: Option<Box<Tree>>, value: i32) -> Option<Box<Tree>> {
if root.is_none() { return root; }
else if value == root.as_ref().unwrap().value {
if root.as_ref().unwrap().left.is_none() && root.as_ref().unwrap().right.is_none() {
return None;
} else if root.as_ref().unwrap().left.is_none() {
let succ = {
let end = left_end(&root.as_ref().unwrap().right);
end.as_ref().unwrap().value
};
>> 訂正前 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value);
>> 訂正後 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), succ);
root.as_mut().unwrap().value = succ;
} else {
let pred = {
let end = right_end(&root.as_ref().unwrap().left);
end.as_ref().unwrap().value
};
>> 訂正前 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value);
>> 訂正後 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), pred);
root.as_mut().unwrap().value = pred;
}
} else if value > root.as_ref().unwrap().value { root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value); }
else { root.as_mut().unwrap().left = remove_tree(root.as_mut().unwrap().left.take(), value); }
...

**デフォルトの名無しさん** · 2017/10/27(金) 14:02:45.56

>>204
何度も言ってるがこのコードが汚いのは制約回避のためじゃなくて、Cのコードを愚直に移植してるからだぞ。
CのNULLを表現するためにOption型を使用してるから、コンビネータとかを
きちんと使わない限りはunwrapだらけになってコードが汚くなる。
Rustのコードが汚いんじゃなくてRustyに書いてないから汚いだけ。
同じことを何度も言わせないでくれ。

確かに、Rustはコンパイル通すために苦労するから、
執行錯誤してるうちにうっかりミスしやすくなるという考えはあるのかもな。
まあ、この程度のミスを犯す俺が単純にバカすぐるのか、これもRustの課題のひとつだと考えるかは
人によって意見が分かれてくるところじゃないか？みんなどう思う？

**デフォルトの名無しさん** · 2017/10/27(金) 15:02:03.76

カネもないし時間のゆとりもないからコードが汚くなった
言語よりもカネと時間の使い方が間違っている

**デフォルトの名無しさん** · 2017/10/27(金) 17:07:21.98

>>205
クラスの値型配列はごく基本的で有用なデータ構造なんだけど…

**デフォルトの名無しさん** · 2017/10/27(金) 17:26:21.22

いや俺もちゃんと具体例出すか。例えば
class Point { public: double x; double y; }; だの Point3D だのが定義できて、
vector<Point> や Point v[..] が扱えなかったらシステムプログラミングなんかできやしない
…かどうかは別として別に値型の配列は必要なデータ構造だし、
immutable であれば直感に反した動作もないのでは。

実際に用途の多くは inmutable なオブジェクトの配列で、
C++17 では vector<const T> が許容されるようになりそうな流れ。

**デフォルトの名無しさん** · 2017/10/27(金) 17:40:16.82

>>214
ああ、すまん。Dでは構造体は継承出来ない代わりに値型可能、クラスは継承出来る代わりに値型不能なんよ。そのイメージが残ってたわ。
継承したものを値型で混ぜ混ぜしてしまったというのが俺のミスなのです

**デフォルトの名無しさん** · 2017/10/27(金) 18:04:05.75

何でスレタイからHaskell外したんだよ
それならGo外せよ

**デフォルトの名無しさん** · 2017/10/27(金) 18:39:17.91

なんか元々の C のコードを Rust に下から生じた問題みたいに言ってるけれど
tree のアルゴリズムを実直に書けばそういうふうになるだろ。
それってつまり実直にアルゴリズムを記述するのに向いてないって言ってるようなもんだろ。

あ · 2017/10/27(金) 18:41:31.58

また無様なHaskellのコード見るの嫌だし、むしろスレタイには言語一切入れんでもいいだろ。

好きなら、なぜ好きかを推すだけで充分議論になるのに、
他の言語を貶めて、○○はゴミだから△△が良い、って論調にするのはちょっとおかしいんじゃないの？

ホームレスが椅子で寝るの見て、俺はブラック企業戦士だけど屋根のある部屋で椅子で寝てるだけマシ、って言ってるように聞こえるよ。
好きで椅子で寝てるなら椅子寝のこだわりぐらい書けよ。パイプ椅子なら圧倒的に互い違い派だ、とか。

**デフォルトの名無しさん** · 2017/10/27(金) 19:47:08.69

貶めるのが許せないという気持ちがよくわからない
例えば残業代未払いは許せるが貶めるのは許せないとか
なんでそういう優先順位になったのか理解できない

**デフォルトの名無しさん** · 2017/10/27(金) 20:10:28.34

エアプガイジの言ってることわかる訳ないんだから絡むな��

**デフォルトの名無しさん** · 2017/10/27(金) 20:13:53.36

Rust派の意見としては、

①TreeはCより汚いけど他のメリットが大きいから許せ

②もっとうまく書けるから俺が書いてやるぜ

③副作用のある木は糞

どれ？

**デフォルトの名無しさん** · 2017/10/27(金) 22:02:47.00

>>218
隔離スレだしな。
プログラマ自体、人口のほんの一部だし、複数の計算モデルが異なる言語を使いこなしてるのなんて更に希少種だから、もともと言語のマトモな比較が出来る奴が殆ど居ない。
だからここで言い合ってるのはおま環がデフォ。

**デフォルトの名無しさん** · 2017/10/27(金) 22:13:38.27

>>184
型がないと引数なり戻り値なりで与えられた情報をどう扱っていいかわからないでしょう

**デフォルトの名無しさん** · 2017/10/27(金) 22:23:07.44

返り値が返るのも
それも副作用って事にならないのはなんで？

**デフォルトの名無しさん** · 2017/10/27(金) 23:02:40.27

式に値があるのは副作用と言わないから

**デフォルトの名無しさん** · 2017/10/27(金) 23:04:58.68

>>224
主の作用だからだろ

**デフォルトの名無しさん** · 2017/10/27(金) 23:23:42.05

>>218
無様なHaskellコードって？

**デフォルトの名無しさん** · 2017/10/27(金) 23:45:39.75

>>211
ちゃんと具体的にコードを書いてくれて議論しやすくしてくれたのはありがたい。
tree を rust で実装しろって言われたら 10 人中 9 人は Box と Option を
使ったそういう構造体作ると思う。

**デフォルトの名無しさん** · 2017/10/27(金) 23:47:59.22

>>214
Pointの例に限って言えば同意できないな
大量の小さなベクトルを扱うような場合、構造体を使うより各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
C++系の言語で行持ちの方が好まれるのは、一番の理由は言語の性質上そのほうが扱いやすいからに過ぎない
最近は列指向DBなんかも普通に使われるようになって、データの列持ちが見直されつつある今、
列持ちのデータ構造をスマートに扱える言語があってもいいと思うわ

**デフォルトの名無しさん** · 2017/10/28(土) 00:01:16.09

>>229
Fortran, Juliaのことか？

**デフォルトの名無しさん** · 2017/10/28(土) 00:03:34.74

>>227
>無様なHaskellのコード

908 ：あ：2017/05/31(水) 09:15:21.09 ID:dc+IbjjD
>>905
具体的に上げろと言われてもなぁ。
<T>を持ったenumがOptionかcar(T)とcdr(<T,T>)である時くらいかな。

これのことじゃないの？（適当）

**デフォルトの名無しさん** · 2017/10/28(土) 00:24:09.93

てか
>>229
> 各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
これってどういう演算の時にそうなるんです？

**デフォルトの名無しさん** · 2017/10/28(土) 00:46:39.85

Rustアンチくんはペチパー

はっきりわかんだね

あ · 2017/10/28(土) 00:51:22.50

>>219
許せないんじゃなくて、健全ではないよね、と。
なんせ改善せずとも、自分があたかもまともであるかのように思える一番楽な方法だし、進歩もない。

>>222
ホントに。好きなら好きで良いんだよ。
バカで比べる事ができないなら素直に信者してりゃ良いの。
狂信者が戦争起こすような真似をネットでまでやらんでもよろしい。

>>227
>>231
しかも、結局すごくひねり倒してグダグダ言った割に、最後まで動くコードが出てこなかったんだけっけ。

**デフォルトの名無しさん** · 2017/10/28(土) 00:58:11.14

>>232
分かりやすいのはパディングが入るケース
ループのベクトル化もスカラー配列の方が効きやすいらしい

**デフォルトの名無しさん** · 2017/10/28(土) 01:07:07.63

>>235
うーむ……
もしかしてPoint3Dのベクトルに一括して行列を掛けたりする状況を想定しているのか？

**デフォルトの名無しさん** · 2017/10/28(土) 01:09:54.95

そういう状況でもない限りそもそもボトルネックにならないからな

**デフォルトの名無しさん** · 2017/10/28(土) 01:16:42.42

>>211
試行錯誤の過程でアルゴリズムぶっこわれるってのはよくあるが、そうならないためにテストコードがあるっちゃそうだから、
明確な欠点とは言えないかもな

まさかスレに貼るサンプルコードにまでテストコードつけろなんて言えねえし。

**デフォルトの名無しさん** · 2017/10/28(土) 04:09:54.80

>>234
ドアの奴なかな？
あれならHaskellのコード出てただろ
いつまで言ってるんだ

**デフォルトの名無しさん** · 2017/10/28(土) 09:04:44.68

コード出すという行動ではなく
コードが正義っていう知見への承認とか共感が欲しかったんじゃないか
だから行動だけでは駄目

あ · 2017/10/28(土) 09:19:59.46

>>239
じゃ、いつまで、スレタイにはHaskellが、って言ってんだよ(笑)

**デフォルトの名無しさん** · 2017/10/28(土) 10:25:15.53

なぜ私達は Python から Go に移行したのか
https://frasco.io/why-we-switched-from-python-to-go-19581e27de7c

**デフォルトの名無しさん** · 2017/10/28(土) 10:45:03.08

よくあんな無様な知ったかぶりしといて人のこと無様とか言えるな

**デフォルトの名無しさん** · 2017/10/28(土) 11:06:53.69

これだからペチプァは

あ · 2017/10/28(土) 11:20:03.53

>>243
自分が無様だと思ってる奴に無様だと言われるのはさぞ辛かろうが、
俺が無様なのとHaskell書いたやつが無様なのは別の事象で、

同時に無様でありえるんだから、その指摘はナンセンスだろ。
その理解力でHaskell最高！と思ってるのも面白いな。Maybeの真髄だろ。事象を整理するのは。

**デフォルトの名無しさん** · 2017/10/28(土) 11:28:14.87

なんだこいつなんで俺がHaskell 信者みたいな前提で煽って来てんだ

**デフォルトの名無しさん** · 2017/10/28(土) 11:36:54.21

もう最新規格のFortranで良いよ

**デフォルトの名無しさん** · 2017/10/28(土) 12:01:24.16

Fortranに第一級関数がついてimplicit noneがデフォルトになってinterface文をもうちょっと短く書けるようになって引数の型指定をCみたいに書けるようになって
配列の大きさ指定の関数に組み込みでない関数を使えるようになってgfortranのbind(C)周りのバグを解消してくれたらFortranでいいよ

**デフォルトの名無しさん** · 2017/10/28(土) 12:13:39.86

西京言語PHPを使えばいいじゃん（いいじゃん）

**デフォルトの名無しさん** · 2017/10/28(土) 12:20:24.44

PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい