次世代言語11[Rust Swift TypeScript Dart]
■ このスレッドは過去ログ倉庫に格納されています
スレタイ以外の言語もok
前スレ
次世代言語10[Rust Swift TypeScript Dart]
https://mevius.5ch.net/test/read.cgi/tech/1524607347/ 内包表記だと
result = [i * 2 for i in range(10) if i%2==0]
で
かっちょええチェーンは
val result = (0 to 10).filter(_ % 2 == 0).map(_ * 2)
で
ちょっとかっちょよくないチェーンは
auto result = iota(0, 10).filter(a => a % 2 == 0).map(a => a * 2)
なんだなあ。最後のはちょっと長いし無駄が多い印象 >>3
最後のはスィープラ?いけるやん
これの良さがわからないリーナスとかいう禿げは何何やろなん? >>3
かっちょええやつで、引数が2つあるときや
同じ引数を2回使いたいときの書き分けはどうすんのん? >>5
(a => a % 2 == 0)
のスィンタックシュスュガーなだけだから
((a, b) => a % 2 == 0)
こうなるだけやぞ >>4
Dやで。C++は少なくとも17まではこんなん出来なかった気がする
>>5
Scala全く知らないけど、_1,_2としていくのがMathematicaとかの定番やね 前999
集合論の書き方という発想はなかった
初めに神はxを創造された。
さて、xは0から始まり、荒漠としていて、10まであった。
それから神は言われた、「偶数あれ」。
良く訓練されたパイスォニスタは、コードではなく聖書を書いていたというのか? >>7
さよか、autoとiotaテケトーにググっただけだから釣られたわ
やっぱスィープラは糞なんやな、リーナスは神 >>8
そう見ると割と理解しやすいと思うんやけどなあ…… >>8
自分で書いてあれやが、2倍が抜けてるやん
やっぱリスト内包表記は糞としか思えないんだが
俺の脳内パーサがコンパイルエラーを吐く pythonはもうドカタが使う言語じゃないからね
内包表記もアレで良いんだよ 内包記法は2重ループとか畳み込みでぐちゃぐちゃになるからイラネ Scalaの_は糞やで
外側の_をメソッド呼び出しの引数に渡せないから現実にはほとんど使い物にならない
使えば使うほど理不尽な制約の多さに辟易する
Kotlin関係なく、こんな行き当たりばったりなゴミが元々普及するわけがなかった >>13
それメソッドチェーンでも同じやん
それに場合によるけど二重くらいなら改行すればそんなにぐちゃぐちゃにはならないと思うよ >>14
あー。Juliaでも議論されて結局それのせいでいろいろ決まらなかったやつやね……
そうかあかんか…… 内糞は、必ずmap句、generate句、filter句の順である・・・と覚えりゃいいんだろうか
どう考えても糞ちゃう? SQLのSELECT文に近い順番だけど
あれもROM句から考えるほうがしっくりくるんだよなあ 英米人「Catch me if you can!」
ジャップ「捕まえられるものなら捕まえてみろ!」
長いし冗長。 ああ、SQLとも似てるのか、なるほどですね
1ライナーで書くことを強いられてるせいで余計読みづらいのかな
しかし前996に尽きる
前提が数字か文字列か何なのかわからんのに、
いきなり「2倍します」で始まるとかファッ!?てなるですよ まあデータを後ろへ流していくパイプラインの方がより書きやすいというのはわかる。書いてるとメソッドチェーンの方が書きやすいわ。
ただ、ラムダ式に毎回引数を書く必要があったり、外側の_の問題が鬱陶しい ポイントフリースタイルにすれば引数も書かなくてよくなるぞ
難読具合もUPするとは思うがw 普段C/C++使ってる身としてはいくら読みやすかろうと
実行効率犠牲にされると使う気が起きないな 横レスだがCPU時間次第では
I/O律速だから非効率でもいいかとガシガシCPU使ってると熱持ったり電池減ったりするからね そんなん気にし始めたらもうPythonに限らずスクリプト言語全般無理やん >>28
最適化作業が当たり前の世界にいるのだけど、最適化って進めるごとにどこがボトルネックは変わっていくんだ
また最近は可能な限りジョブ分割して並列実行させるから特定のcpuが遊んでるってこともあまりない
もし遊んでれば機能追加しようという話になる
そういう世界だと最適化前であっても原則富豪的なプログラミングは許されない
プログラミング言語にもとめるものとして可読性の順位はあまり高くない
どういうバイナリに落ちるか想像つくレベルでないとリバースエンジニアリンクに時間とられるはめになる >>31
よくC++でどういうバイナリに落ちるか想像つくな
どのくらい勉強したん? >>30
普段 C/C++ 使ってる>>27みたいな人はスクリプト言語でやるような仕事はあまりしてないんじゃないか >>33
それってつまり関係ない話題ぶっこんで来たってことか
反応する必要なかったか コンパイルと起動用のスクリプトにpython使おう
最適化の世界ではコンパイル時間と起動時間はノーカンだろ常識的に 起動時間をノーカンにしてたからクライアントサイドJavaは嫌われて滅びたというのに >>34
そもそもここ実行速度の遅い、C代替になり得ないようなスクリプト言語のスレなのか? >>38
両方ありのスレだろ。TypescriptがCの代替になるとは思えない。
そして俺達は今C代替になりえるかとかそういう話はしていなかった。てっきり続きの話題なのだと思ったけど、続きでなく新規の話題だったなら俺が反応する必要はなかった 実行速度は速いに越したこと無いけど、速いだけじゃCの代わりは無理だからね ダウンロードとコンパイルを最適化した結果がこれなのか ところでうちのサーバー、オフラインだからパッケージマネージャの類い全然有り難くないどころかむしろ鬱陶しいんだけど、お前らの所ってそうでもない? >>44
そんな環境で次世代言語?
ストレス溜まるだけだから諦めよう >>44
パッケージ配布のためのローカルなフィード作ればいいだけやない? そもそもパッケージマネージャーとか抜きにオフラインキツイわ。
大抵そういう現場ってバカの保身の為で全然本質でないことをやらされるイメージ。 linuxを起動する円盤にもパッケージが入ってるので
この仕組みを解明できたらネット接続は本質ではない >>46
ごめん分からなかった。良ければ解説リンクみたいなの頂けませんでしょうか? 気軽にリポジトリのURIをローカルに指定できるパッケージマネージャとそうでないやつがいるから何とも言えない
Rustのパッケージマネージャはcrates.io決め打ちでリポジトリの構造もオープンでないからネット環境無いと面倒くさい wasmの世界になったらめっちゃ楽しそう。
c++で書いたwasmが一番早いのですか? >>53
c++をバグなく書ける人がいないから
最も遅くなるよ >>39
発端は>>27だからC代替の話だね
一体なんの続きだと誤解していたんだ? >>56
>>27自体が内包表記とメソッドチェーンの話題に対するレスかと勘違いしてたよ 流れとしてはそうなんだろうけれども
C/C++ で実行効率がという話だからスクリプト言語は視野に入ってなかった 誤解なんて放っておけば自然治癒することもあるし
悪化したら何が問題か自然に明らかになる で、次世代最強言語は決まったのか?
おまえら人類は今まで何してたんだ?
シコって昼寝するだけのカスだったのか? Nimが面白そうなんだがイマイチ盛り上がってないな nimとかcrystalとかredの話が全然ないな 数値計算が得意でないかライブラリが足りない言語ばっかりで、いずれも「最強」と呼ぶには値しない みんなで使う言語が最強の言語だが決めるのに時間がかかりすぎる
自分だけ使う言語を今すぐ決めよう 銀の弾丸を求めても意味ないよ。
自分の戦場の自分の兵科で一番便利だったり一番強い武器使えば良いじゃん。
同じ戦場でも狙撃手と本隊とだとライフルとサブマシンガンに別れるように、
同じ業務系とくくられる開発でもそれぞれ最強言語が違って当たり前だと思うよ。
さらに領域すら異なるなら、最強とか言ってもホントに無駄でしょ。
「この言語はこう新しくて、ここが好き」とか、
「この言語も最近は良くなってきた、特にこの辺」とか
そういう話題からの
「じゃあ〇〇系の開発でも使い物になってきたな」みたいな話題ならわかるんだけど、
使いみちありきの言語ageは違うと思う。
そういう意味では、ちょっと前から出てるRailsファンは書き込む前に考えてから書き込んでほしい。 >>69
そんなんどっちでも良くないか?
ルールとしてRailsユーザは禁止ってならわかるけど
そもそもここの人間はなぜrubyを親の敵のように叩いているのかわからない。
特定の人物が騒いでるだけ? rubyは敵だと1秒で決める人物もいるし
20年考えても敵か味方かを決められない人物もいる rubyと言うより信者が糞。
別言語のスレで唐突にrubyでは〜とか言ってrubyコード貼り出したりその言語のライブラリ探してんのにrubyのライブラリとruby薦めだしたりやりたい放題。
スレ違いだと言っても無視してずーっと居座る。
目には目をだな。 信者がキモいからこのスレで叩くというのは筋が通らない。一時期沸いてたHaskellアンチと同レベル リアルでの信者のキモさでいえば明らかにHaskellは最底辺
Ruby使いはライトなレイラーも多いから平均的にはそこまで酷くない >>70
どっちでも良くない事はわかってるだろ。
叩かれてる原因ぐらい理解できるだろうし、理解できないならそれこそもっと考えるべき。
rubyが1.9からくさった事は何度も書いた。 一位を決められない奴が「とりあえず最下位を決めよう」って思いつくのなんでだろう 信者がキモくない言語って単に人口が多いだけのPython以外にあるか? 言語を叩くってのがだいたい噴飯ものなんだよ
センスも経験も力量も劣ってるクソゴミ野郎が
自分のサイズすら見えず
プログラミングの成果物のうちでも
偉大な
恐れ多いプログラミング言語というもんを気軽に叩きやがる
もっとひれ伏せよ蛆虫 そこまでは言わんが何が嫌いかより、何が好きで語ったほうが良い。 Rubyは信者というより作者がキモい。(主に見た目が) いや言語については嫌いな理由のが有意義な情報な場合が多い。
好きとかクソみたいな理由しかないし。 昔リリースマネジメントが滅茶苦茶だったころBTSぐらい導入しようと提案されて
自分は無くても困ってないので不要という趣旨のこと言ってて
だから滅茶苦茶なんだと呆れ果てた 次の戦場はwasmだから、そこでどの言語が勝つかな。何か開発力はMSが一番な気がするからTypeScriptな気がする。.Netがwasmに対応するほうが早いか? jstsはまだまともにコンパイルできる処理系がないという点で一歩出遅れているけどな。
pypy的なアプローチでいけたりするかな。 結局みんなCに戻るのか
こんな世界滅んでしまえばいいのに >>88
そう思った理由をぜひお聞かせください、とても期待しています >>87
そもそもpypyって別に速くないぞ
Python界では無駄にリソースを分散させているだけの嫌われ者 言語がバージョンアップしていってどんどん多機能になっていくの何か嫌い
むしろ機能を削っていくキレキレ言語が欲しい 互換性の問題をクリアした言語作ればいいのに
ソースファイルにコンパイラのバージョン書くとか 同じ言語間の新旧interop用の機能を用意するのと、互換性のために機能を残しておくのと
何が違うというのか Cとbash
wasmとJSとかいうマルチパラダイムinteropが解禁されたら結局みんなCに戻る >>94
jsで言うとstrictモードとかね。
jsは最新仕様のコードから古いjsコードを吐き出せるトランスパイラを、作ることで進化スピードが上がった。トランスパイラなら後方互換性が壊れても良いかもね。
デバックは死にますが c++はgccかVCで実装が終わってから標準にすりゃいいんだよ。
標準委員とか全く実装をわかってないバカがクソ仕様を決めてんのが大問題。 その点「標準にしたけど、実装難しかったから次のバージョンからやっぱなしw」ってやるFortranってすげえわ ■ このスレッドは過去ログ倉庫に格納されています