次世代言語18 Go Rust Elixir Kotlin TypeScript
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok 前スレ 次世代言語17 Go Rust Kotlin TypeScript Julia https://mevius.5ch.net/test/read.cgi/tech/1567602619/ コンパイラがメチャ賢くなってあらゆるプログラムが最適化で削除されるようになったら消滅する議論 そんな10年前に終わったitaniumみたいな話されてもな。。 コロナで糞バカ中世ジャップランド土人どもが消滅するよ やったね でも死亡率低いようだよ。 感染後に何人治癒したかも発表してほしいね。死ななかった人が治癒した人だからいずれはわかることではあるが。 JavaScriptはPHPとかいう汚物を一刻も早く滅ぼしてくれ。 言語仕様自体がゴミの癖にコーディング規約1番うるさい のほんと腹立つ。 言語じゃないがjsonが最後の要素にカンマあるだけで壊れるの何とかして >>380 型無し糞言語からJavaの悪いところだけを輸入して、ただの糞言語になった 便器ブラシことゴミ屑PHP(障害者手帳持ち)の悪口を言うな phpでクソコード書く奴はjsで同じ様にクソコード書くけどな。 そう。一度ペチパーの畜生道に堕ちると、ほとんどの人間がダメになってしまう。 ペチパーは、クソコードを書かれる前に、打ち首の上さらし首にするしかない。 JSONを策定した連中(IETF)は馬鹿 propertyでのidentifier(ダブルクォート無し)、末尾カンマ、コメント、 undefined(void 0) を削って設定ファイルとしても優秀に出来た仕様をぶち壊した 言語間ネタ繋がりで FFIのモダンな標準っていつまで経っても出てこないな C言語ヘッダファイルが悪いとは言わないけど Ruby を書く人は、JS でも、きれいに書く React でも、Ruby のinclude(mix-in)を入れた mix-in で、親子の継承チェーンの間に入るから、 同名のメソッドが、親の前に、mix-in で見つかる Ruby の、require/include の違いを学びましょうと、matz も言ってたw class やら継承やら、久しくやってない(もっぱら関数・合成と委譲)ので、mix-in の記憶が曖昧なんだが、 React で mix-in なんてやることある? 少なくとも、独自コンポーネントの継承は随分昔からアンチパターンとわかってるから、やめた方がいいと思う というか、最近の React ならほぼ全部 function でいけるぞ ヘルパーメソッドなど、汎用的なモジュールを作って、子クラスでinclude(mix-in)すると、 メソッドの探索チェーンが「子 → mix-in → 親」となるので、 同名のメソッドが、親よりも先に、mix-inで見つかる 便利なインターフェースみたいなもの そういうのはロギングとか、本筋の処理と関係ない部分でやるならいいんだけどね。 継承より委譲と言われるようになって久しいが、まだこんな老害が生きていたのか >>386 どうせc呼ぶくらいしか需要ないんだしそれでいいだろ。 他の言語呼ぶくらいならプロセス切り離してシステム関数つかったらええわ。 高級言語がC言語を呼び出すのは古い C言語が高級言語を呼び出すのがモダン Cの書きにくさと高級言語の遅さを兼ね備える のか…(困惑) Goの良くない点 入門者への分かりやすさを重視して設計したはずなのに、配列のスライスが上端を 含まない半開区間であること。閉区間にすべきだった。 配列のインデックスが0ベースならスライスは普通半開だけど 含んでる言語はスライス用途以外に同じ記法を用いる特殊な事情があるやつ >>390 標準化あるいはデファクト化が重要なんすよ 自社ソフト内で使う分にはいいけど 公開APIでJSON5を返す選択は厳しい 半開区間で表すのが常識になれば入門者が迷うこともなくなるよ。実際そうなりつつある。 >>399 >入門者への分かりやすさを重視して設計したはず 言語入門者はともかく、プログラミング入門者を対象とはしてないよ 楽しさや設計の美しさより実務を最優先にした言語 公式にも以下のようにある > Go was designed to address the problems faced in software development at Google >>400 添字が0始まりだから半開区間にしなければならない理由なんてないだろ。 添字が0始まりでも閉区間のF#やPowerShellの方が入門者にとっても それ以外の人にとっても直感的で分かりやすい。 >>404 だからそれらの言語のは配列のスライス専用の記法じゃないから let list = [ 1 .. 10 ] みたいな場面でも使われる こういう時にはたしかに直感的で便利だけどスライス用途ではむしろ使い難い RubyやPerlも同じ >>405 スライスでも閉区間の方がはるかに使いやすい。Pythonみたいな奇形言語の真似を するのはやめてもらいたい。 おまえの個人的な決めつけで閉区間のがいいとか言われても困るわ。 開閉と区間とか知らない言葉出てきた モナドばりの失笑もんだ https://tour.golang.org/moretypes/7 The following expression creates a slice which includes elements 1 through 3 of a: a[1:4] `1 through 3 of a` == a[1:4] さすがGoogle謹製わかりやすい!!! Rust for x in 1..4 { println!("{}", x); } > 1 2 3 Java for(int i : Arrays.asList(0,1,2,3,4).subList(1,4)){ System.out.println(i); } > 1 2 3 IntStream.range(1,4).forEach(System.out::println); > 1 2 3 C# foreach(var i in new int[]{0,1,2,3,4}[1..4]){Console.WriteLine(i);} > 1 2 3 Rust, Ruby, Swiftあたりは選べるよ 閉区間だったり1始まりが好きな奴はjulia使ってればいいんじゃね?そこから出なくていいよ。 閉区間だと[i:i-1]で空集合にするのはどうなんだ @ & $ ^ * ` -> => などを 使ってる言語は俺の中でゴミ確定 うんこをOSS公開しなくていいから 配列クラス自体は言語ではなくライブラリだから いくら言語を統一してもライブラリを何通りも作るのは合法 >>415 ぴーーーーーーーーえいーーーーーーちーーーーーーーーーーーーピューーーーーーーーーーーーーーーーーーー Ruby のrange では、 p ( 1 .. 3 ).to_a #=> [1, 2, 3] p ( 1 ... 3 ).to_a #=> [1, 2] オプションで切り替えられるのも良いかも ( 1 .. 3, true ) >>408 たかが高校数学にすら出てくる用語だぞ 開区間,閉区間の意味と関連する話題 https://mathtrain.jp/kukan オプションよりキーワードを使おう first=1, overrun=3 zeroth=1, last=3 Swiftの半開区間/閉区間の表現を使うとして (10 ..< 20) → (10 <= x < 20) 要素数: 20-10 = 10 (10 ... 19) → (10 <= x <= 19) 要素数: 19-10+1 = 10 2分割を考える 整数区間の表現や分割は互いに代用可能 (10 ..< 20) → (10 ..< 15) (15 ..< 20) 要素数: 5, 5 (10 ... 19) → (10 ... 14) (15 ... 19) 要素数: 5, 5 実数区間は代用不可能 ※精度の仮定無しに <= 1.9999.. は表現不可 (1.0 ..< 2.0) → (1.0 ..< 1.5) (1.5 ..< 2.0) (1.0 ... 2.0) → (1.0 ... 1.5) (1.5 ... 2.0) ※境界点のhitTestは両方に該当 閉区間では整数区間と実数区間で考え方が異なる また、固有の値の数が多くなりがち (10...14) (15...19) → 10,14,15,19 両方あるべきとは思うけど、半開区間の方がロジックが簡潔になることが多い スカラーと行列では交換法則がー ↓ 交換法則を使ったら不正解とする方がロジックが簡潔みたいな風潮 >>409 a[1:4]はa[1], a[2], a[3], a[4]にしか見えない。見た目が左右対称だから機能的にも 左右対称な閉区間を表すのが自然。半開区間を表したければ、見た目にも左右非対称な a[1:<4]にすべきで、1文字増えるだから不満はないだろ。 a[1], a[2], a[3]を指定したいときに、3に1を足して4なんて煩わしいことをするのは 馬鹿げているから、たいていの場合は閉区間が適していて、開区間が適しているのは >>423 のような特殊な場合だけ。 半開区間は「赤上げて、白下げないで青下げて」みたいなひねくれた書き方だから、 閉区間の方が分かりやすい場合にも半開区間を強要するのは、書き間違えやすくバグの 元。お前らも半開区間の言語で、a[1], a[2], a[3]のつもりでa[1:3]と書き間違えた ことが一度はあるだろ。いや、二度、三度どころかもっとあるはず。白状しろw >>419 *と言えば、Goの巨大数パッケージmath/bigは異様に使いにくいな。 階乗関数の整数版factと巨大整数版Factを書いてみると、C#ではfactのintを BigIntegerに置換するだけでFactになる。アルゴリズムが本質的に同じときに 同じ書き方をできるのは、分かりやすくて良い。 https://www.ideone.com/T8WbLX ところが、Goではfactと比べFactには余分なものがたくさん増えている。 *big.Intなんてポインタが現れるし、整数からの変換にbig.NewInt関数が必要だし、 四則演算子を使えず、掛け算は*ではなくMul関数を呼ばないといけない。 こんな実装の裏方を晒して低レベルな書き方をさせるのは、煩雑でバグの元。 C#では許されるp *= n--をGoが許さないのは、評価順序の勘違いによるバグを 防ぐためだろうが、他方で半開区間や巨大数パッケージでバグの温床を与えているのは 設計方針がちぐはぐすぎる https://www.ideone.com/9ndenp >>425 > 3に1を足して4なんて煩わしいこと off位置からlen個取りたい → off..<(off+len) "key=value"からkeyを切り出したい → 0..<(=の位置) 閉区間では1を引くなんて煩わしいことが必要とも言える 使い易さの例がマジックナンバーなのはナンセンスでは? 非対称な構文にすべきという点には異論無いけど それ以外の部分は、君がそう思っているという以外に根拠が無いように見える >>429 範囲をマジックナンバーで指定したい場面は多い。 閉区間にするため1を引く計算は日常的に染みついているから、煩わしいと思わない。 例えば、2月22日から5日間は、22 + 5 - 1 = 26だから26日までと理解する。 変数で書く場合も、off..<(off + len)よりoff..(off + len - 1)の方が最小値と 最大値が両方明示されていて分かりやすいと思うが、人によって違うだろうし、 半開区間の方が4文字短いので、好みに応じて選べるようにするのが良い。 offを二度書かずに済む構文off+..(len - 1)とoff+..<lenがあるともっと良い。 >閉区間にするため1を引く計算は日常的に染みついているから、煩わしいと思わない。 他の人は半開区間もすぐに染みつくから問題ないのよ。 >>399 無いなら作れば良い。 そう。Haskellならね。 組込のindexえんざんし(!!)だとこう [1..3]!!0 >1 んで、1で始まるindex演算子が欲しければ作る。 (x:_) !!! 1 = x (_:xs) !!! n = xs !!! (n - 1) [1..3]!!!1 >1 そんなとこでつまづく様じゃどのみちまともにプログラムできる様にはならんだろ >>430 ではその期間にログインした人をログイン日時から絞り込むとする 2月22日 <= ログイン日時 <= 2月26日 仕様の具体例として上記を書くのは不具合のリスクがある 2月22日 <= 日単位切り捨て(ログイン日時) <= 2月26日 のように精度を揃える切り捨てを明示するか 2月22日0時0分 <= ログイン日時 < (2月26日0時0分 + 1日間) のように半開区間にすべき このような操作が必要なのは、2月22日から2月26日という表現は 実際には「2月22日から2月26日終日」という暗黙の非対称性があるため >>432 Haskellでは範囲を指定してリストを作るときの範囲は閉区間だな。 だから、スライス風演算子!..!を定義すれば、 Prelude> xs !..! ys = map (xs !!) ys Prelude> [1..10] !..! [1..4] [2, 3, 4, 5] となる。 Haskellは言語仕様は難解で有名だが、標準インストールでREPLが提供され、 ソースファイルをいちいち作らずにいろいろ試せて便利だな。C#とF#も コンパイラ言語だがREPLがある。GoにもREPLが欲しい。Goreという REPLもどきを作った人はいるが、もどきなので遅くて使い物にならない。 純正で本物のREPLを提供してもらいたい。 >>430 一方で時間は「昼休みは12:00〜13:00の1時間」のような半開区間の表現と 12:00〜12:59のような閉区間の表現がある (秒以下もあるので中途半端だが) ググった限りでは前者の方が一般的に見える 行程表などでの分割では 12:00〜12:30, 12:30〜13:00 のようになる これは君が「特殊な場合」と言ったものの実例 整数区間の日付と実数区間の時刻 配列が1から始まるウンコさに比べたら こんなもん誤差ですよ >>439 配列が1から始まったら何か不都合がありますか? numpyとか 数値計算専用ライブラが 充実してて使いやすればいいだけの話。 言語ネイティブのシンタックスで そこまでサポートしなくてもいいし、 どうでもいい。 しかしよく考えたら if(0 < x < 10) くらいの比較演算は確かにあったら便利だよな なんでこれができる言語はないのか。 もしくはbetweenとか 誤解を招くような記法を使うのではなく、 普通の不等号で挟めるのが一番わかりやすいな。 一発目でboolが出てこない特別ルールを構文解析器に埋め込まなきゃなんないからな >>441 配列が2から始まったら何か不都合がありますか? if (0 < x && x < 10) と書くのと比べてもそこまで便利だとも思えん こんなしょーもないことでグダグダ文句言うくらいなら本人だけがjuliaでも使ってりゃいいんだよ。 こういう馬鹿に限って人に自分の感覚を強制しようとする。 >>415 _*:;を多用する言語が目に悪くてイラッとする これ自分の「正しさ」を人に押しつけるパターンではないな 狼少年は自分の言葉が正しくないと知りながら人に教える 動機は、例えば何かの記憶を消すためにでたらめなデータで上書きするとか そういうことじゃなくて、0<x<10 の 0<x の部分と単体の 0<x では異なる評価をしないとならないということ。 モナドみたいな形で解決できるかもしれないが。 >>438 「○〜○」や「○から○まで」という表現は閉区間だよ。13時ちょうどは次の閉区間と 重複し、昼休みであると同時に昼休みではないことになり、厳密に言えばおかしいが、 13時とそれより0.01秒前または後との違いなんて日常感覚では知覚できないから、 このような表現でも問題なく通用している。 秒を小数で表示すれば実数になるが、(連想配列でない)配列の添字は整数しか ないから、実数を持ち出すのはそれこそナンセンス。実数は数直線上の点だが、 整数は番号が付けられた桝目として捉えられる。配列は下図のようなメモリ格納 イメージだから、 012345 □■■■□□ 黒く塗られた部分をスライスとして指定したければ、その部分の最初と最後の番号を 使ってa[1:3]と書くのが分かりやすく間違えにくい。Excelのセル番地の範囲を 指定するのに閉区間でA1:B3と書き、半開区間でA1:<C4とは書かないのと同じ。 >>441 PowerShell, Python, Rubyのように配列の添字が負の整数-iのとき最後からi番目の 要素を指す仕様の言語では、正の整数iのとき最初からi番目の要素を指す仕様(つまり 添字が1始まり)にする方が整合性が取れて分かりやすいな(実際には0始まり)。 >>455 > 配列の添字は整数しかないから、実数を持ち出すのはそれこそナンセンス 区間という概念が配列にしか使われないとでも? > 13時ちょうどは次の閉区間と重複し、昼休みであると同時に昼休みではない 時間帯毎の集計程度の処理で容易に不具合出しそう グラフィック処理でのピクセル座標系とグリッド座標系の違いの方が似てるかな。 昔は直感的なピクセル座標系も使われていたけど、グリッド座標系の方が合理的だということが理解されて 今じゃそっちが主流だな。 馬鹿が馬鹿なことを言ってるだけだわ。 電流が本当は負の方向にながれててもそのまま正負は変えてないってことの意味を少しは理解しろ。 >>460 閉区間に合わせろやと言ってるバカは無視していいってこと。 添字が実数の場合は左辺値という概念がなくなるだろうから []演算子は意味のない仕様だよ ()演算子だけでいい これが面白いと思ってるんだろうな。。かわいそうに。 長編すぎて売れすぎた作品で笑った記憶ある? お笑いは意味のない芸だよ あまりに社会に都合がわるい真実なので隠蔽されているが 笑いは基本的には嘲笑であり相手との社会的距離による 自分の地位向上が見込めそうなとき笑いが出る 自分と近しい人だとちょっとした失敗のとき笑う、ケガとかは後で自分に面倒がくるから笑えない 自分と距離がすごくある、究極的にはフィクションだと指でつつかれて頭が吹っ飛ぶのに大笑いできるわけだ 愚かさをアピールして反射的な笑いを取る方法だと 長期になるとそいつが愚かなのはわかりきってるので笑えなくなる 状況が思いもしない方向に転換するようなときは長編でも笑える >>461 範囲指定(スライスに限らない)が閉区間だけの言語 Fortran, F#, Haskell, Julia, MATLAB, Octave, Pascal, PowerShell, R, S, Scilab どう見ても使用者の平均的な知能は半開区間だけの言語より高そうだなw 蛇に唆され禁断の果実を食べ「知恵」を得たが、「知恵」と呼べるほどのものでは なかった。代償として産みの苦しみが増し、苦労して食物を収穫し、死んで塵に 帰らなければならなくなった―― Pythonに後続し半開区間だけにしたGoは、非合理で書きにくい記法を甘受しなければ いけない、>>2 の表現を借りるなら「イケてない労働者言語」か… その地位を 否定したいなら、改悛して閉区間も取り入れ、Pythonを駆逐してもらいたい。 >>472 だからその使用者の平均的な知能が高そうな言語をおまえは使ってたらええやん。 そんなことも通じない人の知能が高いとはとても思えないけれど。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる