次世代言語Part7[Go R ..
[2ch|▼Menu]
192:デフォルトの名無しさん
17/10/26 22:34:09.13 P+s05bng.net
>>182
「俺偉い」はさすがにないわ。笑かすな。
Rustに移植してみての感想だけど、確かにコンパイルを通すのには苦労したけど、
通ってしまえばメモリーリークはないって安心感がある。これが重要。
特に今回はunsafe一度も使ってないからなおさら安心できる。
Cのほうのコード一通り眺めてメモリーリーク無いって確信できる?
それができる超人君なら確かにRustは全く必要ないが。
Rustは君の嫌う面倒さと引き換えに安心を得ることができる言語。
むしろCで書いたコードにメモリーリークがあるのかないのか
自分の書いたコードに自信が持てないやつのためにこそRustがあると思ってる。
面倒だけが理由で思考停止しているのはどっちだ。
>>185
確かにこのコードは汚いよな。そこは自覚してる。



193:マジで誰かRust風に書き換えてくれない? 動いたところまで確認したところで集中が切れてしまってもうやる気が出ない。 Rustはオブジェクト指向も関数型のパラダイムを両方とも持っているし、 きちんと書けばかなり綺麗で整ったコードに書き直せるはずなんだよ。 あと、Rustアンチに1つ聞きたいことがある。 Rustが嫌いってことはわかったけど、じゃあアンチ君の好きな(愛用してる)言語は何なの? その言語のメリット・デメリット含めて詳しく解説してくんない?



194:デフォルトの名無しさん
17/10/26 23:26:00.76 LcYnzbeR.net
はっきり言わせてもらうけれど、
この規模のコードで書くのにそれだけ苦労する価値があると思えんが。
メモリリークについてもこの規模なら一通り見て、あるかないかくらい判断できるよ。
まあ主観といえば主観だけれど
本当に本心からこの程度のコードについてメモリリークを心配しちゃってるの?
言語を持ち上げるために無理に納得しようとしてない?

195:デフォルトの名無しさん
17/10/26 23:35:06.69 9syp6YaG.net
そりゃこの程度の規模じゃRust使うメリット皆無だよ
で、実際のプロジェクトがこの程度の規模なの?

196:デフォルトの名無しさん
17/10/26 23:35:07.35 51LPFkSD.net
なんでこの規模に限定した話をされているの?

197:デフォルトの名無しさん
17/10/26 23:37:41.83 9syp6YaG.net
Rustアンチスレ
スレリンク(tech板)

198:デフォルトの名無しさん
17/10/26 23:40:05.21 JSzFTz38.net
ブラウザの性能が圧倒的にchromeより上になったらrustの優位性が証明されるけど。
それをまとうかな。

199:デフォルトの名無しさん
17/10/27 00:07:16.82 xwp9Pca0.net
性能の差で優位性を証明したことなんて今まであったっけ
オブジェクト指向も関数型もiPhoneもみんな性能と関係ない価値観だったような

200:デフォルトの名無しさん
17/10/27 00:42:45.70 5+s2yfDd.net
>>185
さすがにコード一行も書いてない奴が言っていいセリフじゃねえわ……
>>189
さすがに後出し条件がひどい。そもそも発端は「Rustでは(unsafe使わずに)木構造すら書けねえだろ」って煽りが発端で
「さすがに木構造くらい(unsafeなし)Rustででも書けるわ」ってのの話がこれだろ
そりゃコンセプトが「安全性」なんだからCで書くより面倒なのは確かだし、この程度ならCの方がいいってのも当然だが、
そこを比較するために書いたもんじゃねえだろ

201:デフォルトの名無しさん
17/10/27 00:47:50.32 /3yfU/y8.net
見苦しくなってきたな

202:デフォルトの名無しさん
17/10/27 03:40:11.56 LQlgBzJd.net
流石に自演かすぎる…

203:デフォルトの名無しさん
17/10/27 06:31:17.46 2A0a9mBA.net
>>183
そんなことはないと思うが
何か具体例ある?

204:デフォルトの名無しさん
17/10/27 06:34:38.22 2A0a9mBA.net
>>195
言いたいことはわかるが
その「この程度」のも全部快適に書けるのが理想なわけだよね
この程度のをいっぱい書かなきゃいけなくなったときにこの調子じゃ萎える人も出てくるだろう

205:デフォルトの名無しさん
17/10/27 09:50:28.38 T+eCoUsJ.net
>>195
安全性のためとか言って結局まともにかけないアルゴリズムがあることを見て見ぬふりの信者
健康のためなら死んでもいいを地で行ってるな
これが宗教ってやつか

206:デフォルトの名無しさん
17/10/27 10:02:50.33 LQlgBzJd.net
Rustが面倒そうなのは伝わったが
C側の奴がコピペ野郎のくせに暴れてるクズすぎてなんとも

207:デフォルトの名無しさん
17/10/27 10:35:02.10 aniL1VIL.net
>>200
まともに書けるけど無料で教えてくれる人が少ないだけだってそろそろ気付けよ
普通は健康のためではなくカネのためにやってるから

208:デフォルトの名無しさん
17/10/27 11:13:40.46 T+eCoUsJ.net
というかさ、Rustのコードバグってるんだけどwwwww
バwグwっwてwるwんwだwけwどwwwww
remove_treeで要素Removeできてないwwwww
Rustはコンパイル通れば安心できる(ドヤァ)とかいってバwグwっwてwるwwwww

209:デフォルトの名無しさん
17/10/27 11:26:28.21 T+eCoUsJ.net
ここにRustは、安全性を高めると言いつつまともにアルゴリズムを書こうとすると制約回避のためにとてつもなく汚いコードになり、
バグもCより出やすくなることが公になりましたとさ
ちゃんちゃん

210:デフォルトの名無しさん
17/10/27 11:40:28.33 AXKOuk3Y.net
>>198
言語に気を遣わないとすぐ自分の足元を撃ち抜く言語であるということに同意しないということ?
具体例っていざ言われると困るなあ。ふと思い出した阿呆な失敗談を一つ挙げると、クラスの値型配列を作れちゃうところとか、クラスは絶対ポインタで持たないといけないDとは対照的に感じたな
常識的に考えたらクラスの値型配列なんてやったらダメなのはわかるんだけど、なぜかやってしまって、コンパイル通ってんのに思ってたのと違う挙動して困ったわ。こういう常識的に考えたらわかるけど、考えないといけない部分があるから言語に気を遣わないとやっていけん。
これは全然大したことない例だけど、なんか他にもあったような気もするし思い出したら書き込むわ

211:デフォルトの名無しさん
17/10/27 12:04:57.19 aniL1VIL.net
代入がなければ値型でもポインタでも同じ挙動だ
だから、代入しようとしたらコンパイルが通らない言語が現れた

212:デフォルトの名無しさん
17/10/27 12:27:06.09 Luz9kSs/.net
haskell追い出したら次はrustですか?

213:デフォルトの名無しさん
17/10/27 12:49:17.54 aniL1VIL.net
追い出す権利はないね
あると思ってるやつは権利に甘えすぎ

214:デフォルトの名無しさん
17/10/27 12:53:49.35 BmYygdVN.net
URLリンク(cpplover.blogspot.jp)
まあこう言う馬鹿がいなくなるまでは
実際のコードについて議論したほうがいいとは思うよ。
別にrustとかhaskellが悪いとは思わんけれど、コードなんて実際に現場で機能するかどうかが
一番重要なわけだから。原理に走ると都合の悪いことを無視し始めるのは気に入らん。

215:デフォルトの名無しさん
17/10/27 13:27:23.45 OeXtCDV4.net
>>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); }
...

216:デフォルトの名無しさん
17/10/27 14:02:45.56 OeXtCDV4.net
>>204
何度も言ってるがこのコードが汚いのは制約回避のためじゃなくて、Cのコードを愚直に移植してるからだぞ。
CのNULLを表現するためにOption型を使用してるから、コンビネータとかを
きちんと使わない限りはunwrapだらけになってコードが汚くなる。
Rustのコードが汚いんじゃなくてRustyに書いてないから汚いだけ。
同じことを何度も言わせないでくれ。
確かに、Rustはコンパイル通すために苦労するから、
執行錯誤してるうちにうっかりミスしやすくなるという考えはあるのかもな。
まあ、この程度のミスを犯す俺が単純にバカすぐるのか、これもRustの課題のひとつだと考えるかは
人によって意見が分かれてくるところじゃないか?みんなどう思う?

217:デフォルトの名無しさん
17/10/27 15:02:03.76 aniL1VIL.net
カネもないし時間のゆとりもないからコードが汚くなった
言語よりもカネと時間の使い方が間違っている

218:デフォルトの名無しさん
17/10/27 17:07:21.98 2A0a9mBA.net
>>205
クラスの値型配列はごく基本的で有用なデータ構造なんだけど…

219:デフォルトの名無しさん
17/10/27 17:26:21.22 2A0a9mBA.net
いや俺もちゃんと具体例出すか。例えば
class Point { public: double x; double y; }; だの Point3D だのが定義できて、
vector<Point> や Point v[..] が扱えなかったらシステムプログラミングなんかできやしない
…かどうかは別として別に値型の配列は必要なデータ構造だし、
immutable であれば直感に反した動作もないのでは。
実際に用途の多くは inmutable なオブジェクトの配列で、
C++17 では vector<const T> が許容されるようになりそうな流れ。

220:デフォルトの名無しさん
17/10/27 17:40:16.82 AXKOuk3Y.net
>>214
ああ、すまん。Dでは構造体は継承出来ない代わりに値型可能、クラスは継承出来る代わりに値型不能なんよ。そのイメージが残ってたわ。
継承したものを値型で混ぜ混ぜしてしまったというのが俺のミスなのです

221:デフォルトの名無しさん
17/10/27 18:04:05.75 697iydar.net
何でスレタイからHaskell外したんだよ
それならGo外せよ

222:デフォルトの名無しさん
17/10/27 18:39:17.91 BmYygdVN.net
なんか元々の C のコードを Rust に下から生じた問題みたいに言ってるけれど
tree のアルゴリズムを実直に書けばそういうふうになるだろ。
それってつまり実直にアルゴリズムを記述するのに向いてないって言ってるようなもんだろ。

223:あ
17/10/27 18:41:31.58 872yUCAe.net
また無様なHaskellのコード見るの嫌だし、むしろスレタイには言語一切入れんでもいいだろ。
好きなら、なぜ好きかを推すだけで充分議論になるのに、
他の言語を貶めて、○○はゴミだから△△が良い、って論調にするのはちょっとおかしいんじゃないの?
ホームレスが椅子で寝るの見て、俺はブラック企業戦士だけど屋根のある部屋で椅子で寝てるだけマシ、って言ってるように聞こえるよ。
好きで椅子で寝てるなら椅子寝のこだわりぐらい書けよ。パイプ椅子なら圧倒的に互い違い派だ、とか。

224:デフォルトの名無しさん
17/10/27 19:47:08.69 aniL1VIL.net
貶めるのが許せないという気持ちがよくわからない
例えば残業代未払いは許せるが貶めるのは許せないとか
なんでそういう優先順位になったのか理解できない

225:デフォルトの名無しさん
17/10/27 20:10:28.34 AXKOuk3Y.net
エアプガイジの言ってることわかる訳ないんだから絡むな��

226:デフォルトの名無しさん
17/10/27 20:13:53.36 AXKOuk3Y.net
Rust派の意見としては、
@TreeはCより汚いけど他のメリットが大きいから許せ
Aもっとうまく書けるから俺が書いてやるぜ
B副作用のある木は糞
どれ?

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

228:デフォルトの名無しさん
17/10/27 22:13:38.27 2kHVS/Sf.net
>>184
型がないと引数なり戻り値なりで与えられた情報をどう扱っていいかわからないでしょう

229:デフォルトの名無しさん
17/10/27 22:23:07.44 W2Xgzzyi.net
返り値が返るのも
それも副作用って事にならないのはなんで?

230:デフォルトの名無しさん
17/10/27 23:02:40.27 4WxMDiO8.net
式に値があるのは副作用と言わないから

231:デフォルトの名無しさん
17/10/27 23:04:58.68 2kHVS/Sf.net
>>224
主の作用だからだろ

232:デフォルトの名無しさん
17/10/27 23:23:42.05 LQlgBzJd.net
>>218
無様なHaskellコードって?

233:デフォルトの名無しさん
17/10/27 23:45:39.75 BmYygdVN.net
>>211
ちゃんと具体的にコードを書いてくれて議論しやすくしてくれたのはありがたい。
tree を rust で実装しろって言われたら 10 人中 9 人は Box と Option を
使ったそういう構造体作ると思う。

234:デフォルトの名無しさん
17/10/27 23:47:59.22 O21aknvD.net
>>214
Pointの例に限って言えば同意できないな
大量の小さなベクトルを扱うような場合、構造体を使うより各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
C++系の言語で行


235:持ちの方が好まれるのは、一番の理由は言語の性質上そのほうが扱いやすいからに過ぎない 最近は列指向DBなんかも普通に使われるようになって、データの列持ちが見直されつつある今、 列持ちのデータ構造をスマートに扱える言語があってもいいと思うわ



236:デフォルトの名無しさん
17/10/28 00:01:16.09 rPyPw2Q2.net
>>229
Fortran, Juliaのことか?

237:デフォルトの名無しさん
17/10/28 00:03:34.74 1i6fvk7+.net
>>227
>無様なHaskellのコード
908 :あ:2017/05/31(水) 09:15:21.09 ID:dc+IbjjD
>>905
具体的に上げろと言われてもなぁ。
<T>を持ったenumがOptionかcar(T)とcdr(<T,T>)である時くらいかな。
これのことじゃないの?(適当)

238:デフォルトの名無しさん
17/10/28 00:24:09.93 rPyPw2Q2.net
てか
>>229
> 各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
これってどういう演算の時にそうなるんです?

239:デフォルトの名無しさん
17/10/28 00:46:39.85 pDpr3v8b.net
Rustアンチくんはペチパー
はっきりわかんだね

240:あ
17/10/28 00:51:22.50 Nq0Bzlbk.net
>>219
許せないんじゃなくて、健全ではないよね、と。
なんせ改善せずとも、自分があたかもまともであるかのように思える一番楽な方法だし、進歩もない。
>>222
ホントに。好きなら好きで良いんだよ。
バカで比べる事ができないなら素直に信者してりゃ良いの。
狂信者が戦争起こすような真似をネットでまでやらんでもよろしい。
>>227
>>231
しかも、結局すごくひねり倒してグダグダ言った割に、最後まで動くコードが出てこなかったんだけっけ。

241:デフォルトの名無しさん
17/10/28 00:58:11.14 Ng05dLeH.net
>>232
分かりやすいのはパディングが入るケース
ループのベクトル化もスカラー配列の方が効きやすいらしい

242:デフォルトの名無しさん
17/10/28 01:07:07.63 rPyPw2Q2.net
>>235
うーむ……
もしかしてPoint3Dのベクトルに一括して行列を掛けたりする状況を想定しているのか?

243:デフォルトの名無しさん
17/10/28 01:09:54.95 Ng05dLeH.net
そういう状況でもない限りそもそもボトルネックにならないからな

244:デフォルトの名無しさん
17/10/28 01:16:42.42 FXSZ1oP/.net
>>211
試行錯誤の過程でアルゴリズムぶっこわれるってのはよくあるが、そうならないためにテストコードがあるっちゃそうだから、
明確な欠点とは言えないかもな
まさかスレに貼るサンプルコードにまでテストコードつけろなんて言えねえし。

245:デフォルトの名無しさん
17/10/28 04:09:54.80 62CU1Qsk.net
>>234
ドアの奴なかな?
あれならHaskellのコード出てただろ
いつまで言ってるんだ

246:デフォルトの名無しさん
17/10/28 09:04:44.68 C9milqrp.net
コード出すという行動ではなく
コードが正義っていう知見への承認とか共感が欲しかったんじゃないか
だから行動だけでは駄目

247:あ
17/10/28 09:19:59.46 Nq0Bzlbk.net
>>239
じゃ、いつまで、スレタイにはHaskellが、って言ってんだよ(笑)

248:デフォルトの名無しさん
17/10/28 10:25:15.53 CAnYo5YI.net
なぜ私達は Python から Go に移行したのか
URLリンク(frasco.io)

249:デフォルトの名無しさん
17/10/28 10:45:03.08 rPyPw2Q2.net
よくあんな無様な知ったかぶりしといて人のこと無様とか言えるな

250:デフォルトの名無しさん
17/10/28 11:06:53.69 pDpr3v8b.net
これだからペチプァは

251:あ
17/10/28 11:20:03.53 McmdGm+1.net
>>243
自分が無様だと思ってる奴に無様だと言われるのはさぞ辛かろうが、
俺が無様なのとHaskell書いたやつが無様なのは別の事象で、
同時に無様でありえるんだから、その指摘はナンセンスだろ。
その理解力でHaskell最高!と思ってるのも面白いな。Maybeの真髄だろ。事象を整理するのは。

252:デフォルトの名無しさん
17/10/28 11:28:14.87 rPyPw2Q2.net
なんだこいつなんで俺がHaskell 信者みたいな前提で煽って来てんだ

253:デフォルトの名無しさん
17/10/28 11:36:54.21 c+qfWZBO.net
もう最新規格のFortranで良いよ

254:デフォルトの名無しさん
17/10/28 12:01:24.16 1i6fvk7+.net
Fortranに第一級関数がついてimplicit noneがデフォルトになってinterface文をもうちょっと短く書けるようになって引数の型指定をCみたいに書けるようになって
配列の大きさ指定の関数に組み込みでない関数を使えるようになってgfortranのbind(C)周りのバグを解消してくれたらFortranでいいよ

255:デフォルトの名無しさん
17/10/28 12:13:39.86 pDpr3v8b.net
西京言語PHPを使えばいいじゃん(いいじゃん)

256:デフォルトの名無しさん
17/10/28 12:20:24.44 aTcnbQEE.net
PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい

257:デフォルトの名無しさん
17/10/28 12:31:15.99 MXV4el39.net
mod_perlとだったら大して変わらん気がする

258:デフォルトの名無しさん
17/10/28 12:33:46.88 pDpr3v8b.net
>PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい
キリッ
www

259:デフォルトの名無しさん
17/10/28 17:09:33.99 GkEAGE6K.net
皆がCGIという共通ルールを守る中
汎用性のない独自実装をしたphp

260:デフォルトの名無しさん
17/10/28 17:24:26.31 6pjbn+cV.net
まあ今更Perlとかって選択肢はないからね

261:デフォルトの名無しさん
17/10/28 17:31:59.24 Hah9JG+z.net
FacebookはなんでPHP推しなの?

262:デフォルトの名無しさん
17/10/28 18:04:40.73 D4ynCBSM.net
PHPをC++に変換するんだっけ
むしろJavaをC++に変換するのを誰もやらない理由を知りたい

263:デフォルトの名無しさん
17/10/28 18:12:54.21 z3Njt94H.net
>>256
Javaは事実上サーバーでしか使われていないので、
全くメリットがないから

264:デフォルトの名無しさん
17/10/28 18:27:47.92 GkEAGE6K.net
phpのがサーバでしか使われてない印象
どっかで使ってる?

265:デフォルトの名無しさん
17/10/28 18:32:36.63 GkEAGE6K.net
>>254
別にCGIはperlでなくてもいいだろ
プロセスを起動するインタフェースのお約束だよな
perlは文字列処理が得意だっただけで

266:デフォルトの名無しさん
17/10/28 19:01:45.06 0vLNpJP2.net
PHPの特徴ってインスタンスの生存時間が極端に短い。ってこと。
request受けてからresponse返すまで。
だからGCが貧弱でも何の問題もないし。糞汚いコードでもメモリリークが問題にならない。

267:デフォルトの名無しさん
17/10/28 19:13:14.28 PFwR8W+K.net
>>256
GCC
URLリンク(news.mynavi.jp)
あと、AndroidはJavaじゃないからノーカンなのかもしれないが、
以前はネイティブに全部変換していたのをやめた

268:デフォルトの名無しさん
17/10/28 19:51:46.92 SOIebb5r.net
>>255
むしろPHPを積極的に潰そうとしてる印象なんだが
クソ挙動しかしないウンコ製造機PHPを潰すためにHHVMは作られたんだぞ

269:デフォルトの名無しさん
17/10/28 20:44:53.33 VLfN62TL.net
>>255
最初は何も考えずにお手軽に作れたからPHPだった
大きくなりすぎてから管理コストを考えてノロノロと移行を企てている
そんなとこだろ

270:デフォルトの名無しさん
17/10/28 21:07:01.93 ruX3/fgh.net
それ以上ペチパーの心のより所を叩くのはやめてやれw
彼ら、憤死してしまうでwww

271:デフォルトの名無しさん
17/10/28 21:37:38.45 GkEAGE6K.net
>>260
言ってること滅茶苦茶だな

272:デフォルトの名無しさん
17/10/28 21:57:38.28 D4ynCBSM.net
伝えようとすれば滅茶苦茶
隠そうとすればバレバレ
だから型情報とか一生懸命伝えようとする言語が報われない

273:デフォルトの名無しさん
17/10/29 03:03:23.28 7slaGsXS.net
>>242
go 好きな人ってまともすぎてつまらんな。

274:デフォルトの名無しさん
17/10/29 05:05:09.88 ZPHcoPj2.net
>>261
ARTは全部変換なんてしてない
元からJITとAOTの複合

275:デフォルトの名無しさん
17/10/29 05:05:25.10 ZPHcoPj2.net
>>267
きんも

276:デフォルトの名無しさん
17/10/29 17:16:13.61 sv965ldD.net
>>268
URLリンク(gihyo.jp)
>しかし,AOT方式をいざ導入してみると,サイズの大きなアプリのインストールや,
>一度に複数のアプリをアップデートするような場合にコンパイルに時間がかかり,
>場合によっては20分程度かかるケースが存在していたようです。
>このインストール時間を問題と捉えて,Android NのARTでは,JIT方式をもう一度使うことになりました。

277:デフォルトの名無しさん
17/10/30 08:01:20.39 BetGXhC9.net
>>242
GOいいな

278:デフォルトの名無しさん
17/10/30 10:22:57.04 sonZMQS5.net
>>271
Goは色々足りないところも多いが、生産性にステガン振りしてるって点で評価できる
Rubyみたいに前借りではない

279:デフォルトの名無しさん
17/10/30 11:06:54.77 ywxMmK0+.net
Rubyの教訓は、「Perlよりマシ」に全振りしたけどPythonと比べると大したことなかった

280:デフォルトの名無しさん
17/10/30 17:27:48.73 ExtYgMew.net
Goのどこに生産性があるんだよ

281:あ
17/10/30 18:12:26.17 53AKimFl.net
>>274
そりゃ、ひたすら書ける部分だろ。
迷わんぞ。書く量が多いだけで。
生産性と言うと表現力ばっかり取り上げられるが、単位時間あたりのアウトプットも見ないといかん。
その点、信じられないレベルで楽。

282:デフォルトの名無しさん
17/10/30 19:01:45.29 ExtYgMew.net
>>275
行数多くなるから生産性が高いように見えるだけだろ

283:デフォルトの名無しさん
17/10/30 19:15:05.61 LhEsAIcv.net
そいつは関数型しったか野郎なので話すだけ無駄
無知が無知なりの常識で頑張って答えてくれるかも知れないけど参考にはならないだろう

284:デフォルトの名無しさん
17/10/30 20:23:14.16 1YWjfXwW.net
迷わずひたすらに書かれたF77のコード読みづらすぎ

285:デフォルトの名無しさん
17/10/30 20:45:20.95 uihdCXQ7.net
Goは構造体へのタグ埋め込みや、codegenまわりのツールが充実してるお陰で
ボイラープレートコードを書かんでいいのがでかい
それだけならLLでもできるが、テスト作ってから設置して実行するまでの作法が簡潔に固まってるのが更に強い
少なくとも時間当たりのテスト含めた成果物は他の言語と比べ物にならん

286:デフォルトの名無しさん
17/10/30 21:31:16.17 d6rNWUAL.net
逆に、汎用ライブラリ書こうとするととたんにinterface地獄になってボイラープレート増えるんだがな
だから、目の前の仕事の案件片付けるのに特化した言語だと思ってる

287:デフォルトの名無しさん
17/10/30 22:18:12.05 1mVUn5ql.net
>>221
ちょっといまさらだがRust版平衡木(AA木)をリファクタリングしたぞ。
まあ、だれも書いてくれそうになかったし、数日


288:たったらまたやる気も出たから自分でやり直したわけだが。 基本的にはAだが、すべて当てはまるな。 RustはNull安全なのでOption型のチェックが必須、コンパイラに所有権を伝えるためas_ref等が必要、 デフォルトはイミュターブルのためミュータブルを扱うためにmutキーワードが必要などが主な理由。 そこら辺の安全性と引き換えに多少は目をつぶってくれという感じはある。 Bに関しては副作用もあるが、それよりもどちらかというと木構造の回転操作みたいな 変数の所有者が次々に代わるようなコードはRustでは所有権システムがあるため書きづらい。 とはいえ、前のコードに比べれば大分マシにはなったかと。 まあコードが綺麗か汚いかなんて個人の主観によるところが大きいから、まだ文句を言うやつもいると思うけど。。。 特に>>217なんかには「どんなアルゴリズムだろうが言語によって最適な書き方は違う」 ということをきちんと理解してもらいたい。 あと、コードのリンクを貼るという手段があることを知った。 比較できるように全て載せておく。 C版 https://wandbox.org/permlink/fc1xI7dDCdOMgysC Rust版 before https://wandbox.org/permlink/cbzzpLw97K2Tydk1 Rust版 after https://wandbox.org/permlink/ppQOQREnDlpccpJV



289:デフォルトの名無しさん
17/10/30 22:28:38.00 LhEsAIcv.net
ほう

290:あ
17/10/31 00:08:53.17 VssU1hfB.net
>>276
そーでもないぞ。
>>277
関数型以外シッタカの意識だけ高い系に言われてもな。
人をディスるんじゃなくて、自分を高めれば?
無理なんだろうけど(笑)

291:デフォルトの名無しさん
17/10/31 00:13:46.41 AszsXbkO.net
関数型以外シッタカ←根拠なしのただのディス
からの
人をディスるんじゃなくて自分を高めれば?
自戒かな?

292:デフォルトの名無しさん
17/10/31 00:16:52.10 xO8W0Vv5.net
そいつの相手しても得るもん無いってことくらいはそろそろ分かって欲しい

293:あ
17/10/31 00:17:14.17 VssU1hfB.net
言い返されてそれはみっともないリアクションだな。
よほど、関数型言語が好きなんだね(笑)
専スレ立ててやれよ。次世代言語でもないわ。

294:あ
17/10/31 00:19:38.37 VssU1hfB.net
好きなら好きで良いのに、なぜ固執するかわからん。
ナイフで整備できるようにネジを全部マイナスネジにしたロシア(?)の戦車みたいな間抜けな話と同じように、目的に対して使う道具なんか考えりゃ良いのに。

295:デフォルトの名無しさん
17/10/31 00:26:46.01 AszsXbkO.net
よほど関数型言語が好きなんだね←誰もそんなことは言っていない
なぜ固執するかわからん←固執していない
誰と闘っているんだコイツは。少なくとも俺じゃねえな

296:デフォルトの名無しさん
17/10/31 00:39:43.26 H/nTnETZ.net
おまえら旧世代猿人類どもはウンコブラシのプェチピィのゲリクソピィでもプリプリしてろ

297:デフォルトの名無しさん
17/10/31 01:21:58.60 nWIRKYZE.net
>>281
コンパイル通らんのを試行錯誤してる間に答えが出てしまった悲しみ
まとめてもらって感謝。勉強してみるわ

298:デフォルトの名無しさん
17/10/31 07:32:43.21 nUaOreAB.net
>>281
比較を載せてくれてありがたい。
やっぱり
C -> rust before -> rust after
となっていくごとに読みづらくなってるんだけれど。。

299:デフォルトの名無しさん
17/10/31 07:35:28.96 u9ib2mEN.net
>>270
それの何が反論になってると?
元から速度云々関係なしにネイティブ変換できない部分があったんだよ

300:デフォルトの名無しさん
17/10/31 09:37:19.94 EcpjGxny.net
>>291
root.as_ref().unwrap().level

root->level
と書いて良いというシンタックスシュガーを導入すれば良い気がする

301:デフォルトの名無しさん
17/10/31 09:56:03.51 nWIRKYZE.net
unwrapはNoneだった場合にランタイムクラッシュする関数だから本来使ったらアカン関数
この辺はnil安全うたってる言語はおおむねそう

302:デフォルトの名無しさん
17/10/31 10:23:24.56 2R0mp116.net
Goは最初期Javaかっていう後退レベルだし、Rustは木構造すら数日かかりで必要な難解言語だしでどっちもクソ言語
はいこれで仲直り

303:デフォルトの名無しさん
17/10/31 10:43:17.86 gJSMspm+.net
パラダイムシフトを強いる言語は地雷が多いな。
俺はリアクティブプログラミングで懲りた。

304:デフォルトの名無しさん
17/10/31 10:44:19.94 Bl0tBU4z.net
数日がかりというが兎と亀みたいにRust以外の言語は寝てたから
Rustが一番早い

305:デフォルトの名無しさん
17/10/31 11:07:20.83 AszsXbkO.net
その理屈だとCが一番じゃん?

306:デフォルトの名無しさん
17/10/31 11:21:14.97 f3HKFkZK.net
結局当面はC#系(TypeScript/Kotlin)の天下ということでよろしいか

307:デフォルトの名無しさん
17/10/31 11:40:23.38 YHJiaIXY.net
>>294
そういうこと。だからRust版 afterではunwrapはほとんど使用していない。
通常、Optionの中身を取り出すときはunwrap_or, unwrap_or_else, unwrap_or_default
のどれかを使用してNoneだったときはどうするのか指定する。
unwrapを使用するときはアルゴリズム的に中身が存在しないこと自体がありえなくて、
Noneならバグと判断してむしろそのタイミングで落ちてバグを知らせてほしい時のみ使用する。
この仕組みによってNullが存在しない(いわゆるNull安全な)言語を実現している。
多少書くのは面倒だが「10億ドルの損失」に比べればこのくらいカワイイもんだろってこと。
ちなみにC#なんかでも導入が検討されているらしいが、既存コードとの互換性が保てないので難儀しているようだ。
Type scriptみたいにコンパイルオプション付ければいいのにとか俺は思うんだが、なんか理由があるのかな?

308:デフォルトの名無しさん
17/10/31 11:47:33.10 f3HKFkZK.net
コンパイルオプションだと既存コードを一緒にビルドできなくなるだろ
互換性を絶対神とするC#に導入するなら、#pragmaでソースファイルごとにオプトインするか、
asyncみたいに修飾子で特定のスコープだけ解釈を変えるか、
デフォルトをnull非許容にするのは諦めてstring!にするかのいずれかだよ

309:デフォルトの名無しさん
17/10/31 12:45:40.51 JU1cd7E4.net
Goが優れてる点はcode生成に最適化されてる点だと思う。
Goはメソッド定義が同じディレクトリ内なら何処でもできる。
つまりコード生成によってメソッドを追加できる。
ファイルでコード生成の箇所と自作の箇所をわけれる。

310:デフォルトの名無しさん
17/10/31 12:48:35.27 JU1cd7E4.net
>>296
Rxはもっとシンプルな定義にできないのかなーって思う。
「全てはストリーム」という考え方はシンプルなのにいざ使おうとすると
ライブラリは複雑すぎる。
もしかしたら言語まるごとRxの考え方で作ったら簡単になるんかな。
Rubyの作者がStreamって言語をつくってるけど、、、、完成しそうもないし

311:デフォルトの名無しさん
17/10/31 15:40:47.27 ivXWtcCM.net
rust で
if root.is_none() {
return 0;
}
root.as_ref().unwrap().level

match root {
Some(node) => node.level,
None => 0
}
と書かないのは何故?所有権とかの問題?

312:デフォルトの名無しさん
17/10/31 16:19:26.73 YHJiaIXY.net
>>304
え?どっちでもいいよ?
リファクタリング後のコードでは使用してないはずだけど。。。
それでもいいし
root.as_ref()
.map(|node| node.level)
.unwrap_or_default()
でもいいし
if let Some(ref node) = *root {
node.level
} else {
0
}
でもいい。どれを使うかは好みの問題。
ただし、>>304のmatch文は正確にはこうなると思う。
match *root {
Some(ref node) => node.level,
None => 0,
}
rootはたぶん型が &T (借用) だから*で参照外しないといけないし、
ref は所有権を「移動」じゃなくて「借用」するために必要。

313:デフォルトの名無しさん
17/10/31 17:24:30.09 YHJiaIXY.net
>>304
>> リファクタリング後のコードでは使用してないはずだけど。。。
誤解を招くかもだな。すまぬ。
if root.is_none() {
return 0;
}
root.as_ref().unwrap().level
のほうはリファクタリング後のコードでは使用してないはずだけど。。。だな

314:デフォルトの名無しさん
17/11/01 08:38:18.68 R9aAc8x6.net
なるほど。ありがとう。

315:デフォルトの名無しさん
17/11/02 00:38:25.36 0kOiRsC5.net
いいってことよ

316:デフォルトの名無しさん
17/11/02 08:54:18.64 N8nuZaLN.net
if not is_none 判定時に実行される、
コンパイラさんにも非noneと分かるコードパスでは
unwrap省略できれば読み書きする際にもPanic起こさないと分かりやすいしシンプルになるな。
実際にも最適化でチェックのコードも吐かれてないだろうし。

317:デフォルトの名無しさん
17/11/02 12:08:13.82 jpQjT5m9.net
>>308
んん?ちょっと待て。良くないぞ
誰だぁ?俺の手柄を取ったヤツは?

318:デフォルトの名無しさん
17/11/02 12:58:12.12 jpQjT5m9.net
>>309
そのやり方は所有権システムの関係で難しいかもしれないな。
非noneが分かっていたとしても中身を取り出す時に所有権を移動する借用するのか決める必要がある。
そして、移動するにせよ借用するにせよ、取り出した時点から所有権システムの制約により
その親にあたるOption型の変数がスコープを抜けるまでは参照不可になる。
移動する場合は、スコープが抜ければOption変数ごと一緒に消費されるはずなので問題ないと思うが、
借用の場合は、スコープを抜けるまでOption変数が参照不可のままじゃ困る場合も多いだろう。
結局は、if let や match 等のスコープを使って借用が終わるタイミングを
コンパイラに知らせるための表現が必要になるんじゃないかと思う。
自分も所有権システムを完全に把握してるわけではないので、間違ってたら指摘してくれ。

319:デフォルトの名無しさん
17/11/02 16:01:49.17 24MXnSEE.net
panic の代わりに未定義動作を行うことで、最適化時にNone時の経路が取り除かれる unchecked_unwrap() とかある。
外部クレートだけど。

320:デフォルトの名無しさん
17/11/02 18:20:00.53 hBgfRlI6.net
FFIと静的型は相性悪いなあ

321:デフォルトの名無しさん
17/11/02 21:04:39.70 aCC/XP/X.net
嫌われているプログラミング言語ランキング - Stack Overflow
URLリンク(news.mynavi.jp)

322:デフォルトの名無しさん
17/11/02 21:06:15.09 aCC/XP/X.net
最も嫌われているプログラミング言語は?--Stack Overflowが調査結果を発表
URLリンク(japan.zdnet.com)

323:デフォルトの名無しさん
17/11/03 01:51:06.45 8/ecCbDm.net
だから何度も言ってるだろ
型なし能なし未来なしの糞言語が
使ってる連中は今すぐ首吊ってなるべく苦しんで無様に血糞尿にまみれて死ねよ

324:デフォルトの名無しさん
17/11/03 01:55:11.36 KPeHygtG.net
>>316
死ぬだけじゃダメだな
来世でも来来世でも苦しみ抜いてもらわないと

325:デフォルトの名無しさん
17/11/03 09:09:40.17 8/ecCbDm.net
>>317
せやな
一族郎党末代まで呪われて地獄の業火で焼かれるべきだ

326:デフォルトの名無しさん
17/11/03 09:10:55.64 FED00RZ3.net
その政策の予算をいくらまでなら払えるか考えよう
予算なしは能なし未来なし

327:デフォルトの名無しさん
17/11/03 10:56:17.26 Z9aKc5RB.net
すまんが型なし言語って何ンゴ?

328:デフォルトの名無しさん
17/11/03 11:18:42.35 4GoOMjot.net
機械語のことかな?

329:デフォルトの名無しさん
17/11/03 11:44:21.79 TD8MDvzA.net
変数に型の無い言語か

330:デフォルトの名無しさん
17/11/03 14:34:55.34 5BCFVkq4.net
Go言語で
var 変数名 = 値



331:フ表記の時は型を省略できるそうですが 値が数値で、値から型が確定できない場合はどうなるのでしょうか? 値から型を確定できるのは文字列型と真偽値くらいだと思いますが



332:デフォルトの名無しさん
17/11/03 14:43:12.88 tw8puOLs.net
>>323
値に応じたデフォルトの型か決まっている

333:デフォルトの名無しさん
17/11/03 14:58:26.87 5BCFVkq4.net
>>324
なるほど
たしかにだいたい推測できますね
ありがとうございました

334:デフォルトの名無しさん
17/11/03 15:00:00.55 fYVptX6H.net
>>319
予算がないからクソゴミクズ汚物言語を使い続ける?
地獄に落ちろビチグソ野郎

335:デフォルトの名無しさん
17/11/03 15:50:26.42 Tuvr4QS2.net
VBA は explicit 付ければ堅く書くこともできるんやで〜。
そんな書き方するやつあんまいないけど。。

336:デフォルトの名無しさん
17/11/03 16:36:07.91 FED00RZ3.net
>>326
誘導尋問するなよ
というかどうせ誘導するなら天国に誘導しろよ

337:デフォルトの名無しさん
17/11/03 17:02:16.49 Ro85MhDs.net
>>320
PHPは型がないから
とかおっしゃってるいつもの人だろ

338:デフォルトの名無しさん
17/11/03 23:58:20.96 HHSOzVXl.net
>>328
なーにが誘導尋問じゃ
どんな理由があろうと下痢未満言語未満のぷぃーえっちぷぃーを使うことを肯定する時点でお前は地獄行きじゃ!
地獄でビチグソにまみれて二度と転生してくるな!!

339:デフォルトの名無しさん
17/11/04 00:00:53.97 I+CIRt80.net
次スレはワッチョイつけないとな。
330みたいな異常者をNGするために。

340:デフォルトの名無しさん
17/11/04 00:03:54.76 gh0lmyH1.net
HHVMを使うという手もあるんじゃ

341:あ
17/11/04 00:24:15.28 CAYPLKQ7.net
と言うか、では実務ではウェブの案件には何をお使いで?と聞きたいな。
ホントに何なんだろ。

342:デフォルトの名無しさん
17/11/04 00:42:18.37 OREBcHC8.net
>>333
330じゃねーけど、フツーにRailsって答えそうではある
フロントいらないAPIサーバならFlaskかGoかってところか

343:デフォルトの名無しさん
17/11/04 00:42:59.68 xCfQAlvJ.net
node + ts
未だにphpでlampとかもう(笑)も付かないレベル

344:デフォルトの名無しさん
17/11/04 00:46:07.02 sWNabS3I.net
叩きは理想の言語とやらでRails越を越える
フレームワークを作ってからしてくれ。

345:デフォルトの名無しさん
17/11/04 02:10:05.95 gh0lmyH1.net
俺の中ではgoでgoaかな。swagger.jsonを介して通信周りもコード生成できる。
API設計するとclientライブラリまで一括して作れるからSPA開発が捗る。
TypeScriptのクライアントライブラリ生成してapiの返すjsonのinterfaceまで作ってくれるから至れり尽くせり。

346:あ
17/11/04 02:22:57.88 CAYPLKQ7.net
Railsか。なるほどありがち。
APIサーバはGoとかnode確かに便利。
tsは置いといて。
あれやるくらいならc#とnancyで書いたほうが余程安定する。寿命の面でも。
そして.net coreすごいわ。
TSは最近イケイケドンドン過ぎる気がする。
イシューは閉じれてないけど、次以降のリリースに頑張るわ、ところでこれ!新機能盛りました!
みたいなノリ。

347:デフォルトの名無しさん
17/11/04 08:30:20.53 xYAYvDdv.net
nodeはnodeで闇深いがな……あいつ結構非自明なメモリリーク起こしやがる
ts on nodeってその辺解決できてるのか?

348:デフォルトの名無しさん
17/11/04 08:35:04.21 xCfQAlvJ.net
で。おまえは実務ではウェブの案件には何をお使いで?
PHPとか言って笑いを取る必要はないぞ

349:デフォルトの名無しさん
17/11/04 09:38:29.95 ZfOcIIq3.net
Django
何だかんだ言われてるけど強いよこいつは

350:あ
17/11/04 13:55:52.44 CAYPLKQ7.net
>>340
何でも使う。書捨てでビューがあればphp
ビューがあって書捨てじゃなけりゃasp.net
Tomcatとservletは嫌い。
安定したAPIサーバはGoかc#とNancy。
nodeは個人用。
イントラ多いから、デプロイ先がWindowsサーバで、セットアップが必要な処理系は入れづらいのよね。
phpは過去の案件ですでに入ってたり、だいたいIISは動いてる。

351:デフォルトの名無しさん
17/11/04 15:34:33.21 F1n0Y3Pu.net
ウチはseaside.st

352:デフォルトの名無しさん
17/11/04 18:58:28.17 xCfQAlvJ.net
>>342
浅く広くの器用貧乏なんだね
どうりで、知識はあるけど深い話になるとボロがでるわけで

353:あ
17/11/04 22:22:28.71 F/oA6Mmk.net
>>344
器用貧乏だろうなぁ。メインの言語以外は特に。
そもそもしばらくシステム屋じゃないし。
道具としては色々使うけど。用を果たせば良い部分と、趣味として使う分は別けてる。
流石に20代でもあるまいし、わきまえてるよ。仕事は。
ボロが出るというより、単純に知らんので参考になってる事も多いよ。

354:デフォルトの名無しさん
17/11/04 22:23:05.19 M2bfsYrO.net
しったかするから、自分の知らない領域ついても知識があるように見えるだけだぞ

355:あ
17/11/04 22:28:21.22 F/oA6Mmk.net
>>346
勝手にそう見てるだけで、俺自身が知ってるよ言ったことはあんま無いんじゃないかな。
俺はこう捉えてる、は話すけど。

356:デフォルトの名無しさん
17/11/04 23:34:55.56 M2bfsYrO.net
>>347
854 :デフォルトの名無しさん:2017/05/30(火) 13:17:09.64 ID:ynDKwlR5
851
>当たり前だがHaskellみたいに実行時に多相性を解決してる
おいおい、Haskellの実装知ってんのか?
Haskellで実行時に型情報が必要な多相性はほんの一部だ。
ほとんどの場合、コンパイル時に解決される。
863 :あ:2017/05/30(火) 16:00:40.31 ID:CncaY8jR
854
知ってるよ。実行時に多相性を「しない」のならその主張もわかるが、「ほとんどの場合しない」は「してる」だよ。
「施錠確認した?」「ほとんどしました」って、要は全く施錠の確認できてないのと変わらんよね。

357:あ
17/11/05 00:07:40.19 NGm20Afw.net
>>348
おお、それは知ってたから。
あんまりと書いてるからわかるだろうけど。

358:デフォルトの名無しさん
17/11/05 01:40:33.90 LYbC1fh+.net
>>341
scaffoldがないのが非常に残念
俺は言語としてはPythonが好きなのに、webとなると無意識にRailsを選ぶようになってしまった

359:デフォルトの名無しさん
17/11/05 11:59:20.40 3qpI8vVt.net
器用貧乏の対義語に名前をつけたい
サンクコスト貧乏かな

360:デフォルトの名無しさん
17/11/05 12:02:14.14 KWRWj+y1.net
Railsって未だに生産性高いんか。
PHPがパクっていろんなフレームワーク作ってるけど

361:デフォルトの名無しさん
17/11/05 12:11:59.33 /wBATO2P.net
ペチパーって何であんなにフレームワーク作りたがるんだろうな
自己主張が強いのか、ママの愛が足りなくて承認欲求に飢えてるのか

362:デフォルトの名無しさん
17/11/05 12:16:38.92 KWRWj+y1.net
>>353
たかがテンプレートエンジンがでしゃばりやがって感ある。
でもインスタンスの生存時間が短いから開発者に優しい言語ではある。
まぁwebScoketとか繋ぎっぱなしにするような仕組みには弱くなるけど

363:デフォルトの名無しさん
17/11/05 12:26:54.29 LYbC1fh+.net
>>352
なんだかんだであれは死なないよ
資産が豊富で、webのラピッドプロトタイピングにおいては群を抜いておる
Railsライクな他言語のフレームワークがRailsを羨ましがる場面はあっても、恐らくその逆はない

364:デフォルトの名無しさん
17/11/05 12:


365:51:00.18 ID:CS19J9AT.net



366:デフォルトの名無しさん
17/11/05 13:29:53.61 KWRWj+y1.net
時代はSPAの方向を向いている中あえて今Rails使うメリットってあるんかな。
最初からWebAPI提供できたほうがいいし。
React覚えるとモバイルももれなく作れるのがいい

367:デフォルトの名無しさん
17/11/05 14:06:42.08 k+vH6ph9.net
Node.jsとTypeScript使っとけば幸せになれるということ?

368:デフォルトの名無しさん
17/11/05 14:17:26.71 o4zLpSg/.net
>>358
webassemblyの時代が来るまではね

369:デフォルトの名無しさん
17/11/05 14:50:39.74 PoYQIzOm.net
wasm時代の覇権がどうなるか想像出来ん
とりあえずC++は安定だろうけど

370:デフォルトの名無しさん
17/11/05 15:02:45.09 /wBATO2P.net
PHP使ってれば食いっぱぐれることはないやろ
ガイジどもが作った負の遺産を保守し続ける楽なお仕事が半永久的にあるで

371:あ
17/11/05 15:14:12.83 kqNrnSiP.net
>>351
器用貧乏の反対は、ホントにその役職に居なければ「大先生」とか「教授」だろ。

372:デフォルトの名無しさん
17/11/05 15:32:04.98 3qpI8vVt.net
フレームワークやIDEを
ドラえもんの道具にたとえると四次元ポケット

373:デフォルトの名無しさん
17/11/05 20:51:56.70 vWNY+clC.net
>>361
真っ先に自動化されるか、見捨てられるシステムだな。

374:デフォルトの名無しさん
17/11/05 20:55:20.91 Fa7z1jl7.net
COBOLやJavaならわかるけどPHPではなあ
ある日突然消えてなくなったところで大した問題のないゴミばかりだろ

375:デフォルトの名無しさん
17/11/05 21:28:49.35 wTe1xxd0.net
おい、アスペチプァさんを馬鹿にするなよ
彼らが本気出したらお前ら血便漏らして死ぬようなコード書くぞ

376:デフォルトの名無しさん
17/11/05 21:40:31.01 RFcD7Uma.net
日本の技術力ガーとか言ってたくせに
結局全部嘘ばかり
バカチョン以下やでホンマ
そりゃペチパーが闊歩しますわ
Rustアンチくんはペチパー
はっきりわかんだね
これだからペチプァは
それ以上ペチパーの心のより所を叩くのはやめてやれw
彼ら、憤死してしまうでwww
ペチパーって何であんなにフレームワーク作りたがるんだろうな
自己主張が強いのか、ママの愛が足りなくて承認欲求に飢えてるのか
おい、アスペチプァさんを馬鹿にするなよ
マジキチ

377:デフォルトの名無しさん
17/11/05 23:19:35.12 wTe1xxd0.net
>>367
巣へお帰り
自称次世代言語議論スレ[PHP PHP PHP] [無断転載禁止]©2ch.net
スレリンク(tech板)

378:デフォルトの名無しさん
17/11/05 23:22:51.31 2EuxY2gH.net
ペチアンチの面白語録非難してる奴って胸に突き刺さって抜けないペチパーか?

379:あ
17/11/06 00:12:29.28 /hMSyilp.net
好きの反対は無関心になるはずだしな。
嫌いな事と言うのは、実は興味があったり、かつて好きだった事があったり、強制され抵抗できなかった惨めさがあったりするもんだ。
あまり人の憎しみを面白半分で扱ってはいかんな。

380:デフォルトの名無しさん
17/11/06 01:15:12.61 TNQjb5Zj.net
>>357
SPAは一番最初のローディングがアホみたいに遅いじゃん
これ解決するためだけにSSRもやるの辛い
じゃあ最初からSPAいらないやってなる

381:デフォルトの名無しさん
17/11/06 01:24:21.52 HP5doPtx.net
【泥沼】 京都市のシステム開発失敗、IT企業に7億5千万円の損害賠償請求 企業側は支払い拒否
スレリンク(news板)

382:デフォルトの名無しさん
17/11/06 07:18:27.19 9YhppvEm.net
>>371
dynamic importが実装されている現状から言って最初のローディングが遅いって問題は解決する。というかminifyすれば十分小さい。
せいぜい500kbとかでしょ開発中は10MBとかだったりしてビビるけど。

383:デフォルトの名無しさん
17/11/06 07:21:45.70 9YhppvEm.net
>>371
後、最初のローディングが遅い問題がSSRで解決するって初耳なんだけど。
どっちかというとSEO的な問題の解決かと

384:デフォルトの名無しさん
17/11/06 09:16:46.62 MQujfIpu.net
>>374
意味不明
順序的な動作いらないし負荷や遅延も減るんだから速いだろ

385:デフォルトの名無しさん
17/11/06 09:17:47.31 TNQjb5Zj.net
>>373
最初のローディングを早くするのとSEOできるっていう二つがSSRのメリットだと言われてないか?
それからSPAの初回表示が5000msとかかかるのは、DOMを構築する処理のせいだろ?
500kbというのはjsのサイズか?ファイルがいくら小さくてもな…
dynamic importは調べてもよくわからなかったが、解決するというなら良いことだ


次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

1873日前に更新/264 KB
担当:undef