次世代言語24 Go Nim Rust Swift Kotlin TypeScript

**デフォルトの名無しさん** · 2022/03/22(火) 03:23:41.60

スレタイ以外の言語もok

前スレ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/

**デフォルトの名無しさん** · 2022/03/26(土) 07:54:07.76

>>251
> 多分Rustをやってる期間は多分お前よりはるかに長いよｗ

はるかに長い期間やっててそれでは知能が低いです

**デフォルトの名無しさん** · 2022/03/26(土) 08:12:28.41

>>256
それはそういう話じゃないと思うぜ
C++とRustの両方使いこなせると分かるが
低レベルであるポインタアクセスがRustでは無くなり抽象化された参照アクセスとなり
安全でないアクセスがコンパイル時点で排除されるためその種の実行時デバッグが無くなる
その件だと思われる

**デフォルトの名無しさん** · 2022/03/26(土) 08:24:24.55

>>257
ただの記憶違いに知能は関係ないｗ実際それで困ったことがないからなｗ

**デフォルトの名無しさん** · 2022/03/26(土) 08:47:16.92

>>259
その件は君が嘘をついていると明確になっている
その件の書き込みを見ると君はarrayとsliceを勘違いしただけでなく関数からarrayで返すと明言している
一方でその関数は返り型宣言で必ず[T; N]が現れる
このNは定数であるからさらに宣言することになりarrayでNの存在を忘れる人はいない
しかし君はarrayを[T]だと間違えて覚えていたわけだから矛盾する
君はRustのコードを書いたことがないという結論となる

**デフォルトの名無しさん** · 2022/03/26(土) 09:14:29.48

何を勘違いしちゃったのか知らないけど、こう書いてあるんだけどｗ
「arrayは定義はあるんだけど、今まで初期化にしか使わなかったから、使わなすぎて間違って覚えてたｗ」

**デフォルトの名無しさん** · 2022/03/26(土) 09:23:18.54

>>260
正確にはガイガー君はsliceで受けてArrayで返すと言っている
この発言の時点でガイガー君はRustを知らないと証拠

動的サイズのスライスで受けて固定サイズの配列を返すのは不可能だからだ
Nが判明しないと配列で返せないが実行時になるまでスライスの長さは不明
この点からもガイガー君はRustを知らない

**デフォルトの名無しさん** · 2022/03/26(土) 09:51:30.12

ニュアンスが違うんだよｗ
「それは俺のポリシーとして、可能ならVecを返すならVecを受けたいだけｗ
今回のケースではメリットとかないよｗ
同様にsliceで受けたらArrayで返したいし、iteratorを受けたらiteratorを返したいｗ」
slice->&[T]
array->[T]

**デフォルトの名無しさん** · 2022/03/26(土) 09:55:08.60

はるかに長い期間やってるのにこの有様
子供の遊びかな？

**デフォルトの名無しさん** · 2022/03/26(土) 09:56:51.30

実際のロジック書くのに使ってたのVecだもんｗ

**デフォルトの名無しさん** · 2022/03/26(土) 10:02:36.56

結局TypeScriptがどの場においても最強って言いたいの？

**デフォルトの名無しさん** · 2022/03/26(土) 10:18:06.61

間違ってても普通に説明すりゃいいのにお互いに煽りながら主張しあってるから、くだらない議論が余計に長引く

**デフォルトの名無しさん** · 2022/03/26(土) 10:39:18.75

TypeScriptさいきょー

**デフォルトの名無しさん** · 2022/03/26(土) 10:44:45.97

>>263
Vecを返す関数は原則引数の型はVecにしたいということ？
敢えてそうする理由ってなにかあるの？

**デフォルトの名無しさん** · 2022/03/26(土) 11:44:23.82

goとtypescriptどっちかを捨てればいいのに

tcshやrubyを捨てるみたいに

**デフォルトの名無しさん** · 2022/03/26(土) 12:29:34.61

新しい言語はどれも配列の宣言があまりきれいじゃない気がする

Cなどの型名変数名[要素数]だと何か都合が悪いのだろうか
それともやってる感を出すために変えてるの？

**デフォルトの名無しさん** · 2022/03/26(土) 12:37:22.57

>>271
固定長で問題ないならそれが一番いいが、
大体において固定長である事自体がものすごく不便だから。

**デフォルトの名無しさん** · 2022/03/26(土) 12:41:53.15

>>271自身がモダンな言語における配列を正しく理解できてないから変なように感じるんじゃないかな
最近の言語ではCスタイルの配列、いわゆる配列変数(複数個の変数が連続して並んでいるもの)はあまり積極的に使用されないんだよ
最近の言語では配列は配列型のオブジェクトであって、変数が並んでるわけじゃないの

**デフォルトの名無しさん** · 2022/03/26(土) 12:49:13.92

>>263
Vecを返すならVecを受けたい、って
例えばこういうこと？
fn foo(input: Vec<i32>) -> Vec<i32> {…}

**デフォルトの名無しさん** · 2022/03/26(土) 17:16:05.98

>>271
Cの形だとパーサーをLRにしないといかんのでは？
GoとかPascalの形だとLLでパースしきってしまえるから早い。

**デフォルトの名無しさん** · 2022/03/26(土) 18:34:45.11

別スレの引用なので、興味があればそれを見てこいｗ
LL/LRとか懐かしいなｗ
S式とかに回帰するかｗ

**デフォルトの名無しさん** · 2022/03/26(土) 18:46:07.16

ちんちんシュッ！シュッ！シュッ！

**デフォルトの名無しさん** · 2022/03/26(土) 20:52:37.86

>>263
Vecを受けてVecを返すインタフェースに通常することはない
普通は以下のようにする

(1) 同じVecを返す場合 (=書き換えたい場合)
まずこの場合はVec<T>自体を渡さなくても参照を渡せば済む
書き換えるから&mut Vec<T>を渡せばいいように思うが
普通はスライス&mut [T]を渡すインタフェースにする
なぜならVecの書き換え参照を渡すとVecの書き換えしかできないが
スライスの書き換え参照を渡せばVecの途中一部の書き換えもできるし
配列や配列の途中一部の書き換えもできるからである

(2) 別のVecを返す場合 (=引数側のVecのデータから作り出したい場合)
この場合も同様となる
引数としてVec<T>を渡すのではなくスライス共有参照&[T]を引数にする
これで入力データがVecだけでなく配列やそれらの一部でも受け付けることが可能

(2)' (2)のケースで入力を順次アクセスのみする場合
この場合は入力としてイテレータを受け付けられると良い場合がある
なぜならイテレータはVecのようなメモリ領域を必要としないため有利
イテレータを入力とする場合のインタフェースは更に2通りに分かれる
　[a] イテレータのメソッドとしてしまう
　　イテレータチェーンに組み込むことができて便利
　　ただしVecや配列やスライスに適用する時はinput.iter().method()の形になる
　[b] 引数として IntoIterator<Item=T> を受け付ける
　　これだと引数に直接スライス、配列、Vec、イテレータのどれも渡せて便利
　　ただしイテレータチェーンに組み込むことはできない
　　イテレータメソッドの2つ目の入力インタフェースとしても使われる
どちらの場合でも順次出力でない場合ならばVecを返すのもありだが
順次出力ならばイテレータを返したほうがイテレータチェーンに組み込めて有利
なぜなら中間生成Vecを無駄に返さずに済むからである
この場合にVecが欲しければcollect()すればよい

**デフォルトの名無しさん** · 2022/03/26(土) 21:26:11.73

>>278
間違ってるよｗそれは俺のポリシーだからｗ普通こうするという話じゃないｗ

**デフォルトの名無しさん** · 2022/03/26(土) 22:23:14.39

ガイガー君はRustに関しても素人だから
そういう常識を知らなくても仕方ない

**デフォルトの名無しさん** · 2022/03/26(土) 22:42:20.46

>>279
なんでそういうポリシーなの？

**デフォルトの名無しさん** · 2022/03/26(土) 23:07:56.60

>>279
&strじゃなくてString使ったり、&TじゃなくてBox<T>やRc<T>使ったりするのかな
初めて聞くポリシーだからどういう考え方なのかが気になる

**デフォルトの名無しさん** · 2022/03/26(土) 23:13:02.38

>>279
あっ、もしかしてborrow checker通すために借用使わないようにしてる？

**デフォルトの名無しさん** · 2022/03/26(土) 23:29:11.35

鋭い指摘だな
確かにガイガー君は参照を使いこなせなくて借用を批判してた

**デフォルトの名無しさん** · 2022/03/26(土) 23:34:15.32

なんか哀れだよね彼は

**デフォルトの名無しさん** · 2022/03/26(土) 23:41:42.26

同じ型の方が設計意図が明白になるし、繋げやすいからｗそれだけだよｗ他のにする理由がないよねｗ
まあもとのスレにも理由は書いたけどｗ

**デフォルトの名無しさん** · 2022/03/26(土) 23:58:50.18

>>286
繋げやすい？？
全く意味不明だ
繋げるならばメソッドチェーンにすべき
そしてVecが中間生成物となるのは無駄となるバッドパターン
イテレータメソッドチェーンにすべき
イテレータを使わないならばスライスを引数で渡すべき

**デフォルトの名無しさん** · 2022/03/27(日) 00:23:39.64

>>287
君にとって意味不明なら意味不明でいいよｗそう思っていればいいｗ
ポリシーとはそういうものｗ菜食主義者に肉を食わないとはケシカランって言ってるようなものだからｗ

**デフォルトの名無しさん** · 2022/03/27(日) 00:25:07.45

>>286
借用で済ませて良い場所で所有権要求するのは普通じゃないからドキュメントコメントにちゃんと書いた方が良いよ

**デフォルトの名無しさん** · 2022/03/27(日) 00:30:12.96

>>288
技術分野でのポリシーとはまず意味のある目的がありそのために設定される
それを説明せずにポリシーとだけ唱えて普通ではない非合理なインタフェースにしているから叩かれる

**デフォルトの名無しさん** · 2022/03/27(日) 01:18:29.05

ｗｗｗｗｗ
知ってて書いてるんだと思うが、もとを読めば分かるけど、参照で受けてるよｗ

**デフォルトの名無しさん** · 2022/03/27(日) 01:35:46.26

>>291
見てみた
確かに引数の型をVecの参照にしてることがわかった
そして元のお題では一貫してずっとlet input = ["a", "b", "c"];となっているのに
引数の型をVecの参照にしてしまったためそこだけlet input = vec!["a", "b", "c"];としている
つまりに引数の型をVecの参照したのは明白な失敗となっている
もちろん正解は引数の型をスライスにすること
これで配列もVecも受け取れる

**デフォルトの名無しさん** · 2022/03/27(日) 03:52:33.29

>>292
だから失敗したからではなくて、何度も言ってるようにポリシーとして合わせたんだよｗ
正解は動くことｗ 2つの方法からsliceとしない方を選択したのｗ

**デフォルトの名無しさん** · 2022/03/27(日) 04:12:54.52

>>293
それまでに他の人たちが書いたコードは入力元データが全てlet input = ["a", "b", "c"];と配列になっているね
そして関数の引数の型は全てスライス&[T]となっているね

ところが唐突にその引数の型を&Vec<T>へと変更したコードが登場
それまでの入力元の配列をスライスで渡すことが出来なくなる破綻
破綻の辻褄を合わせるため入力元データを配列から無駄で無意味なlet input = vec!["a", "b", "c"];へと変更
それまで入力元が配列でもスライスでもVecでも大丈夫だったのに入力元がVecしか受け付けなくなっているね

**デフォルトの名無しさん** · 2022/03/27(日) 07:57:46.18

> 2つの方法からsliceとしない方を選択したのｗ

キミはスライスが何なのかも知らなかったでしょ
自分の知能が低いのを弁えないと恥かくよ

**デフォルトの名無しさん** · 2022/03/27(日) 08:56:07.10

>>294-295
何を言いたいのか知らんが、I/F部分は自由にいじってるので、渡す型が変わるのなんて何の問題もないよｗ

**デフォルトの名無しさん** · 2022/03/27(日) 09:20:19.51

>>296
元々は利便性の良いスライスや効率で優る配列も受け付けていたのに
貴方の変更では効率の劣るVecのみを受け付けとなってコードが退化している

**デフォルトの名無しさん** · 2022/03/27(日) 10:51:24.60

>>297
何度も言ってるようにポリシーｗ

**デフォルトの名無しさん** · 2022/03/27(日) 10:56:32.38

>>298
劣ったコードにするポリシーかよ…

**デフォルトの名無しさん** · 2022/03/27(日) 11:10:30.04

さすがに可哀想やからもうやめたれ

**デフォルトの名無しさん** · 2022/03/27(日) 11:41:31.93

>>299-300
別に劣っても可哀想でもないよｗ意図が明白なコードになってるｗ

**デフォルトの名無しさん** · 2022/03/27(日) 12:11:24.82

面白い課題なんだね
input = ['a', 'b', 'c']; と集合が与えられた時に
そのべき集合（＝全ての部分集合）を返す関数subsets()を作成せよ、ってことか
[]とか['a']とか['a', 'b']とか['a', 'b', 'c']とか全てを漏れなく返せと

**デフォルトの名無しさん** · 2022/03/27(日) 12:27:49.24

初学の人でもすぐ書ける簡単なロジックだよｗ

**デフォルトの名無しさん** · 2022/03/27(日) 12:39:06.02

>>303
じゃあプログラム書いてみて

**デフォルトの名無しさん** · 2022/03/27(日) 14:06:20.96

>>301
Vec<T>を引数で受けることは配列全体の所有権を関数に委譲するという意図を表明してるんだけど
そういう意図ということで認識合ってる？

**デフォルトの名無しさん** · 2022/03/27(日) 15:46:34.95

このスレでも参照って何度も書いてんだけどｗアホなのｗ？

**デフォルトの名無しさん** · 2022/03/27(日) 20:05:48.71

たかだか数年で身につけたスキル、しかも数年後には使ってないかもしれないスキルでイキってんじゃねーよ

**デフォルトの名無しさん** · 2022/03/27(日) 21:23:46.37

Rustは数年後にはなくなってるかもねｗ

**デフォルトの名無しさん** · 2022/03/27(日) 23:33:02.98

人間よりは長生きしてもらわないと
AIが人間に勝てそうな所がどんどん減っていく

**デフォルトの名無しさん** · 2022/03/27(日) 23:40:27.92

Rustなんて人間に負けっぱなしな印象しかないけど・・・ｗ

**デフォルトの名無しさん** · 2022/03/28(月) 05:38:25.18

恥ずかしながら質問なんだがNimって何？

**デフォルトの名無しさん** · 2022/03/28(月) 06:43:08.84

中間生成となるVecを使わずにイテレータを返すイテレータにするという点と
2進数でべき集合を表現するという点が面白いね

fn subsets<T>(input: &[T]) -> impl Iterator<Item=impl Iterator<Item=&T>> {
let len = input.len();
(0..(1 << len))
.map(move |bits| (0..len)
.filter(move |index| bits & (1 << index) != 0)
.map(|index| &input[index]))
}

fn main() {
let input = ["a", "b", "c"];
use itertools::Itertools;
for (i, iter) in subsets(&input).enumerate() {
println!("{}: {:03b}: [{:?}]", i, i, iter.format(", "));
}
}

出力
0: 000: []
1: 001: ["a"]
2: 010: ["b"]
3: 011: ["a", "b"]
4: 100: ["c"]
5: 101: ["a", "c"]
6: 110: ["b", "c"]
7: 111: ["a", "b", "c"]

**デフォルトの名無しさん** · 2022/03/28(月) 08:08:20.92

>>311
目の前にある箱で検索しろ

https://ja.wikipedia.org/wiki/Nim

**デフォルトの名無しさん** · 2022/03/28(月) 11:24:54.13

>>297
横からみてた感想だけど、コードの目的（全てのサブセットを列挙する）達成できているのに退化とは？
その論説は本来の設問からすると別のゴールが生えてる

**デフォルトの名無しさん** · 2022/03/28(月) 12:05:00.42

ツッコミついでにスライスの参照ではなくVecでインターフェース書くメリットについて考えてみたが
これ考え方がモロにPythonのそれだわ
こういう設計はRustだとあんまりやらないが、これをVecから派生した型へのimplとして書くとそこまで違和感ない

「Rustっぽくない」のは指摘されてる通りだが、思想としてはたぶんそこから来てる

**デフォルトの名無しさん** · 2022/03/28(月) 12:12:56.02

Pythonはそのまま例えばこんな感じで書かれた関数をオブジェクトに代入してメソッドに使えるからPythonって言ったけど
とにかくオブジェクト指向にどっぷり頭まで漬かった設計だな

元の「どちらのやり方もある」発言も、「関数型の書き方に寄せるかオブジェクト指向的な書き方に寄せるか」という意味なら納得
（まあオブジェクト指向に寄せるならimplで書けよなんだが）

**デフォルトの名無しさん** · 2022/03/28(月) 14:02:45.07

>>314
元々に挙げられていた例は入力が配列
そして彼のコードは配列を入力として受け付けなくなっているから退化であっている

**デフォルトの名無しさん** · 2022/03/28(月) 14:31:13.30

>>316
そのimplを使ったオブジェクト指向的な書き方でもその理由はおかしい
例えばRustには以下のようなrepeatというメソッドが標準ライブラリにある
assert_eq!(vec![1, 2].repeat(3), vec![1, 2, 1, 2, 1, 2]);
もちろんご指摘のようにimplで書かれているのでメソッドとして使えている

しかしソースコードを見てみると次のようになっている
　impl<T> [T] {
　　fn repeat(&self, n: usize) -> Vec<T>
　　(以下略)
つまりVec<T>に対してではなくスライス[T]に対してimplされている

したがって配列に対しても適用できる
assert_eq!([1, 2].repeat(3), vec![1, 2, 1, 2, 1, 2]);
もちろんスライスに対しても適用できる
let v = [0, 1, 2, 3, 4];
assert_eq!(v[1..=2].repeat(3), vec![1, 2, 1, 2, 1, 2]);

>>315
上述の状況なのでその指摘では皆が納得できる理由や説明になっていない
メリットについて考えてみたとのことだがVecにimplするメリットもない

**デフォルトの名無しさん** · 2022/03/28(月) 22:32:51.22

ガイガー君完敗か

**デフォルトの名無しさん** · 2022/03/28(月) 23:11:23.81

1+1=の結果とか誰も興味ない上、俺がindex版、iterator版、vector版3つ正解を書いてやった後も、誰も興味のないその話題をひたすら続けて無視された挙げ句、このスレにまで持ってきて見当違いな自画自賛と自作自演の嵐ｗ
どれだけバカなんだよｗ

**デフォルトの名無しさん** · 2022/03/28(月) 23:19:40.94

>>318
ガイガー君とやらは配列とスライスの違いすら知らなかった超初心者だから仕方ないんじゃないか
もちろんスライスに対して実装すればVecにも配列にも適用できるからそれがベストチョイス

**デフォルトの名無しさん** · 2022/03/29(火) 01:19:51.25

>>312
Rustってスクリプト言語みたいに簡単に書けるんやな

**デフォルトの名無しさん** · 2022/03/29(火) 17:06:45.34

このスレなんでJuliaは扱わないの？

**デフォルトの名無しさん** · 2022/03/29(火) 18:10:38.94

Juliaって数値計算に特化してるイメージなんだけどそれ以外の用途でも良い感じに使えるの？

**デフォルトの名無しさん** · 2022/03/29(火) 19:43:35.70

数値計算というのはひたすら配列に対してループをぶん回すもんで、FortranやJuliaはそういう処理の記述に特化している
そういう意味だと、数値計算以外だと昔のCOBOLみたいに愚直に一行ずつレコードを処理していくような古典的なバッチ処理には向いてるんじゃないかな

**デフォルトの名無しさん** · 2022/03/29(火) 22:44:22.64

>>321
本人乙ｗ配列とスライスの違いは分かってたけど、配列の定義を誤って覚えてただけだよｗ
Juliaは入れていいと思うｗ

**デフォルトの名無しさん** · 2022/03/29(火) 22:53:46.10

>>326
あんたは [T] を配列だと思っていた
もちろん [T] はスライスが正解
これはあんたが配列とスライスの違いをわかっていなかったことを意味する

**デフォルトの名無しさん** · 2022/03/30(水) 08:18:40.34

型無し糞言語勧めてくる屑どもを全員●したい

**デフォルトの名無しさん** · 2022/03/30(水) 08:41:28.55

今時型無し言語を使うやつはそんなにいないだろ
動的型付け言語は使うが

**デフォルトの名無しさん** · 2022/03/30(水) 09:47:02.31

代表的な型なし言語：Smalltalk、BCPL、B言語、アセンブリ言語

**デフォルトの名無しさん** · 2022/03/30(水) 16:32:49.22

動的型付け言語は型無し糞言語じゃないんだ
僕はまだ大丈夫なんだ

こういうやつよな
●したくなるのは
注連縄を首に巻いて通勤快速に連結してやりたくなるよな

**デフォルトの名無しさん** · 2022/03/30(水) 21:28:09.18

型無しと動的型付けを間違えていたことを糊塗しようと必死

**デフォルトの名無しさん** · 2022/03/30(水) 21:47:02.85

>>331
動的型付け言語には型はちゃんとあるぞ

型を忘れる静的言語、型を覚えてる動的言語
https://dankogai.livedoor.blog/archives/51856318.html

**デフォルトの名無しさん** · 2022/03/30(水) 21:52:53.10

もちろん強い静的型付け言語の方が圧倒的に優れている
ほとんどのバグはコンパイル時点で検出できる
言語によっては実行時のエラーや善きせぬ例外を無くすこともできる
そのため強い静的型付け言語が最もプログラミング生産性も高い

**デフォルトの名無しさん** · 2022/03/30(水) 21:58:42.01

>>333
バカなことばかり書いてあるダメなページだな

> 動的言語の値は、実行時においても自分の型を覚えている。
> このことは何を意味するか?
> 実行時に値の型を調べ、それに対応したコードを実行するプログラムが書けるということだ。

これはまともな静的型付け言語でも出来る
しかもコンパイル時に安全に型をチェックして実行時にエラーをなくすことさえ可能
動的型付け言語ではそのような安全性は無く実行時エラーの山

**デフォルトの名無しさん** · 2022/03/30(水) 22:01:00.78

正直動的型付けのメリットをあまり感じない

**デフォルトの名無しさん** · 2022/03/30(水) 22:02:22.01

いまさら型の動的静的言い出してもウンザリだから
それは君たちが各自自分で勉強して自分で満足してくれ
どっちが優れてるだのどうだの素人の見解1ミリもいらんから

**デフォルトの名無しさん** · 2022/03/30(水) 22:06:41.15

このスレ雰囲気からして学生が多い気がするが、一般的には

型あり：ソースコードに型を明記する＝静的型
型無し：そうじゃない＝動的型

だぞ。ただし「型無し」と全くの初心者に言うと「本当に型がない」と勘違いしてしまう為、
「動的型付け言語」と『教育上』言われる事があってもおかしくないが、それは学校での話。
プログラミング界での用語は上記の通り。
330内はアセンブラしか知らんが、アセンブラにも型（サイズ）はあって、
floatとdoubleは命令が違うし、byte/word/doublewordも命令が違う。
(だから本当の意味で型がない言語なんて実装しようがない)

ただまあ、この辺のごくごく初歩的なところをまずは抑えるべきだよ。
生産性なんてその後の話、一通り書けるようになってからでいい。
心配しなくても初心者の時に書いたコードなんて後から見たらゴミ同然でしかない物ばかりだよ。

**デフォルトの名無しさん** · 2022/03/30(水) 22:09:14.11

>型あり：ソースコードに型を明記する＝静的型
>型無し：そうじゃない＝動的型

どこの一般だよ

**デフォルトの名無しさん** · 2022/03/30(水) 22:10:48.06

いずれにしても動的型付け言語はバグがあっても実行時になるまで検出できないクソ言語
強き静的型付け言語がベストと結論が出ている

**デフォルトの名無しさん** · 2022/03/30(水) 22:15:34.40

よかったですね
ハイ終了

**デフォルトの名無しさん** · 2022/03/30(水) 22:33:44.92

ちょっとした短いスクリプトを書く程度ならば動的型付け言語でも大丈夫
そうでなくプログラミングをするならば静的型付けのメリットが非常に大きいね

**デフォルトの名無しさん** · 2022/03/30(水) 22:47:29.54

個人的にどちらが好みかと言われると静的型付け言語なんだけど、自分全然Pythonとか使うので、そういう言語を唾棄してる人的に雑な書き捨てをするときは何の言語使うのか正直気になる

**デフォルトの名無しさん** · 2022/03/30(水) 22:52:27.20

>>343
ものに依る
例えば簡単なものならシェルスクリプト
よくいる何でもかんでもPython屋さんたちはシェルスクリプトも静的型付け言語も使えないがために陥ってる

**デフォルトの名無しさん** · 2022/03/30(水) 23:01:10.09

PHP
Ruby
Perl

この辺は人として見下してるな
死んでもいいゴミだと思ってる

**デフォルトの名無しさん** · 2022/03/30(水) 23:09:42.25

PHPないと個人サイト作成不便だよ。
pythonで書いてた時期もあったがやはりPHPのが楽だしCPU負荷も少ない。

**デフォルトの名無しさん** · 2022/03/30(水) 23:13:37.76

個人サイトなら静的サイトジェネレータで十分な場合も多い

**デフォルトの名無しさん** · 2022/03/30(水) 23:23:35.91

>>346
おもちゃ程度ならPHPで十分だね
しかしアクセスされるたびに動的サーバーサイドレンダリングをしているわけで無駄すぎ
例えばアクセス数のある企業がそれをしたら負荷のせいで複数のサーバーが必要になりやすい
>>347の言うように出来る限り静的サイトジェネレーションがベスト

**デフォルトの名無しさん** · 2022/03/30(水) 23:26:27.50

PHPerは性根が腐ってる
人間のくず

**デフォルトの名無しさん** · 2022/03/30(水) 23:30:47.36

サーバーサイドレンダリング…？

**デフォルトの名無しさん** · 2022/03/30(水) 23:35:38.07

静的サイト生成系は結局すぐやめたなぁ。
JSで無理くりなことやりはじめたりして個人サイトレベルだと逆に作りが歪む傾向がある。

**デフォルトの名無しさん** · 2022/03/30(水) 23:46:31.10

歪んでるのはPHPerの脳みそだろ
ビルから飛び降りて矯正しろ

**デフォルトの名無しさん** · 2022/03/30(水) 23:49:24.01

自分は普段はc++とc#ばかりだけど...
だけどphpの方が楽、blazorとか逆にしんどかったし。

**デフォルトの名無しさん** · 2022/03/30(水) 23:58:31.85

>>353
選び方が極端すぎ
BlazorはJavaScriptの代わりにC#で書いてブラウザ上をWebAssemblyで動かす究極のアホ
C#はランタイムがデカい上にGCランタイムも必要なわけでそれらを全てブラウザ上のWebAssemblyで動かす
巨大で重くて遅い

**デフォルトの名無しさん** · 2022/03/31(木) 00:17:05.37

負荷が高いからCGIは使わない、PHPは使わない、
共用格安24時間稼働サーバーでnodeやjavaは基本動いてないからそれらは使わない、
VPSで個人サイト運営とか手間なだけだからやらない。

そうなると何でサーバー側で判定必要な処理書いてるのさ。
3大クラウド使って普通の個人サイトにGoでサーバー処理でも書いてんの？

**デフォルトの名無しさん** · 2022/03/31(木) 00:28:30.60

>>354
WebAssembly使うならGCの無いRust一択だな
C++でもよいがRustに対してC++使うメリットがないため
この新たな分野ではC++よりもRustの方がシェア高い