◎正当な理由による書き込みの削除について： 生島英之とみられる方へ:
次世代言語10[Rust Swift TypeScript Dart] ->画像>3枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1524607347/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
スレタイ以外の言語もok
前スレ
次世代言語9[Haskell Rust Kotlin TypeScript Dart]
http://2chb.net/r/tech/1520298555/ お疲れ様。
立たないから、不安になってた。
ラスト駆け足にして申し訳ない。
乙。だがDartを次世代言語としちゃうのはどうも。内部文字コード今どきUTF16だし。
たてなかった俺が言う権利はないのは承知の上で
いい加減Rust外そうぜ。まだ言語としての体をなしてない
そもそもスレタイに言語が入ってるから変な事になるんだと俺も思ってる。
取り払ったら？と何度か言ってきたけど、残したい派はどういう主張で残したいの？
>>5 FirefoxやDropboxじゃ既に実用言語として使われてる。
OSでさえも(あくまで実験用だが)Redoxが作られてる。
"impl trait"もそろそろstableになるし、もう必要な機能はほとんど揃ってるだろ？
何が「言語としての体をなしていない」だよ。いい加減しつこいぞ。
rustのメモリオーナーシップモデルを誰かわかりやすく説明頼む。
>>4 当然のようにutf8じゃ無いの。goはそうだし。
他の言語はどうなん？rustとか
>>3 他の内部文字コード決まってる言語ではどんなの使ってるの？
>>9 goのutf8ってのはソースコードじゃなくて内部もそうなの？
内部コードはJava,Swiftみたいに適宜切り替えしてくれたり
Rubyみたいに任意指定できる方が次世代感ある
jsがutf16だとは聞いた。dartがutf16なのはjsに引きづられた形なんかな。
>>12 javaって切り替えるの？utf16だと思ってた
>>7 全然揃ってねえよ
NLLとかnever typeとかないからクソみたいな回避テク使わないとコンパイル通らないだろ
Java9からStringはLatin1/UTF16を切り替えて使うようになってるね
String<UTF8>
String<UTF16>
これでいい
ゼロコスト抽象化以外の解決策を誰も答えられない
>>16 まあ、NLLを有効にしないと面倒な回避が必要になるケースは確かに存在するけど、
「面倒」というだけで「解決できない問題」というのは存在しないし、NLLが欲しくなるケース
自体も「時々」程度で「いつも」ではないので、「それがないと絶対に困る」って程ではない。
それに「クソみたいな回避テク」とか大袈裟に言ってるが、
せいぜい1~3行程度の少しばかり直感的ではないコードが増える程度。
never typeに関してもunreachable!マクロは使えるんだからそれほど問題にはならない。
「言語としての体をなしていない」ってのはあまりにも大袈裟すぎる。
どっちもnightlyでは既に使えるんだから多分そのうちstable化されるだろうし。
>>8 一つのインスタンスを指す変数を二つ以上にしないようにする。
スコープの外にある変数のメンバなどにスコープの内側の変数を代入させない。
（スコープが外れたらインスタンスは解放するルールで統一するため。）
基本はこんなとこ。
これでメモリ開放のタイミングについて困ることが減る。
>>20 結構コードに制約が大きそう。
これって幸せになりそうな制約になる？
いまいちピンとこなくて、、、
>>21 メモリ管理にGCが要らない、かな。
直接の生産性へのメリットよりも、コンパイル結果が正しくて速くて省メモリな事のメリットの方が大きいかと。
実際には大して速くもなければ省メモリでもないけどねRust
もっとコンパイラ頑張れよ
>>23 C++と張り合えるレベルでGoよりは全然速いし省メモリ。
コンパイラもまだ改善の余地がある。ポテンシャルとしては十分だろ。
RustでもDでもなんでもいいからさっさとC++を駆逐してくれ
Rustの人
コードは面倒になるがオーバーヘッド無しでオーナーシップがどうのこうの
c++の人
遅くてもいいところは楽して shared_ptr で済ませとくか
>>24 もしかして小さいメモリしか乗っていないような組み込み系でrustが活躍する可能性がある？
メモリオーナーシップモデルはswift5 or 6で乗ると聞いてるし、それでiOSアプリの省メモリ化が進んだらかなりすげーってなりそう。
でも、ロジックの書き方に制約が強そうで、
それがコードの見通しに寄与するなら良いんだけど、そもそも学習コストがヤバそう。
>>27 Goよりは省メモリなんだけどCと比べるとやっぱりメモリ食うんだよね。(C++と比べても少し多め)
組み込み系だとそこらへんどの程度までなら許容範囲内なのかな？とかが個人的な疑問点。
仮にメモリ的に許容範囲内だったとしても現状では全く流行る気配がない…
Swiftは確か参照カウンタだったよね？だったら元から比較的省メモリなんじゃないの？
あまり詳しくないからよく分からないけど、効果は薄そうな気がする…
学習コストに関しては「GCがない」且つ「高度な抽象化機能を持つ」言語の宿命として受け入れるしか…
Mozillaが「C++で大規模マルチスレッドプログラミングとかムリゲーじゃね？」ってなったから
Rustを作ったわけで…C++と比べて「落とし穴」が少ないって意味ではRustの方が学習コストは低いはず…
C++とRustにとってGCはオプション
オプションを色々変えるだけで、プロペラ機にもヘリコプターにもなるみたいな感覚
これが次世代だと思うか欠陥品と思うかは人それぞれ
単純にrustの文法とかコンセプトがクッソ気持ち良いと思うんだが
こーいうのはバカと初心者には分からんのやろなあ（笑）
いくら良いものでも他を煽って貶めてるユーザーが居ると印象悪くなるから止めて他の言い回しにしてくれ
てかGCのあるなしが混じった環境とか一番危険だけどな。
rustの問題点は31みたいなバカが多いとこだな。
まあ、明確な根拠のない言語叩きとか、言語使い叩きは辞めよう。
根拠のない殉教者じみた信者もいかんけど。
まあ掌を返すのが気持ち悪いなら根拠が必要だが
むしろ常識がひっくり返るのを見てみたいなら常識に根拠がなくても全く問題ない
ぜひrustの気持ちよさを文章化して欲しい。難しいとは思うが。
Rustは「書きたいコードが直感的に書けない」っていうくっそ気持ち悪い点をなんとかしないと
いかに机の上でのお勉強だけできるバカが絶賛しても寒いだけ
HaskellとかLISPもそういうとこあるけど
Rustは知らんがHaskellもLispも割と直観的に書けるが
おれの偏見も含めた個人的意見だが、
Goが気持ちいいって思うタイプは多分Rustは気持ち悪いって思うヤツが多いはず
Rustが気持ちいいって思うタイプは逆にGoが気持ち悪いって思うヤツが多いはず
結局書くことと読むことのどちらに重きを置いているかの違いだと思ってる
>>40 いちいちモナドとか継続とかこねくりまわすののどこが直感的なんだよ
研究室に帰って二度と現場に口出すな
>>41 抽象化フリークにとっては関数型とかRustとか好きな言語だろうなとは思う
現実に現場で物作ってる人にとっちゃそんなもんはクソの役にも立たん
>>45 すまん、勉強した上で物も作っててすまんw本当にすまんｗ
>>45 オブジェクト指向が出てきた時のコボラーみたいだな
>>46 おお！ついにhaskellでの実際のプロダクト例が聞けるんだな！
是非語ってくれ。是非haskellでないといけない根拠が聞きたい。
使いたいから使ってるんじゃなくて、他の言語が満足に使えないんでもなくて、
haskellでないと問題を解決できないからhaskellなんだという実例が聞きたいわ。
>>48 すまん、俺がHaskell をプロダクトに使ってるとは一言も書いてなくてすまん……
実際Haskell なんか使うくらいならLispとかOcamlとか使うよなあ！？
>>47 実際今世の中はオブジェクト指向捨てる方向だろ？Goしかり、Rustしかり
オブジェクト指向は間違いだったじゃないか
Rustもあんだけごてごてしてるが、オブジェクト指向捨てたのは評価してるぞ
>>48 めんどくさいヤツだな。
Haskellに限らず特定の言語じゃないと解決できない問題なんてほとんど無いだろ。
極論で言えば、C/C++さえあればWebクライアント以外は全て出来るんだ。
ホントに極論だがAndroidでさえNDK(C/C++用API)を公開してるから
Java系の言語である必要性なんてどこにもない。
結局は適材適所でその判断基準は十人十色。
>>50 Rustはオブジェクト指向捨ててないよ…捨ててたらimplが存在するのはおかしい…
Rustはオブジェクト指向も関数型もどっちも取り入れたマルチパラダイム。
個人的にはC#をもう少し関数型に寄せた感じかな。
「綺麗を謳っているわりに関数名が汚いからHaskell 嫌い」←わかる
「モナドがわからんからHaskell はゴミ！」←不勉強のカス
>>53 モナドがわからんとは一言も言ってないぞ
「直感的に書けない」っていってるだけだ
すまんな
rustの良さはやはりコンパイラがある程度チェックしてくれるところだと思う。
Rust、コンパイラの機嫌取らないと、文法合っててもプログラム書けないってのがわからんのだよな
Cでいう未定義動作避けたいのはわかるが、書き手のフラストレーションためる方向なのが良くない
>>57 ほんじゃあどうでもいいわHaskell について書いてた本人以外が俺の文の中の第三者のレスの表現にケチをつけるな
失せな
【マイトＬーヤとＰＳ４】 ＦＦとＤＱの最新作、ＶＲ開発は危険、プレーヤーの日常感覚を損なうおそれ
http://2chb.net/r/liveplus/1524621704/l50 関数型言語入門を読んだけど、宣言的に書けるというのはそれなりに感動したけどな。
でも実用的かというとまだわかんないなぁ。
RxをiOSアプリに導入したときも、正直読みづらくしかならなかったんだよね。
宣言的にかけるって、順序性にあんまり意味が無くなってくるんだけど、
そうするとコードへの宣言の書き順をどうすべきか？というセンスが問われるようになる。結構変数名を考えるくらいのコストになる。
しんどい。
その関数型グループに入れられてしまったらもう古いメンバーと同じ古い言語になる
同じグループのメンバーなら同じに決まってるだろ
>>49 うん、lispというかgaucheは俺も使ってるな。
>>51 それは極論でしょ。
アセンブラさえあれば何でもできるって言ってるわけじゃないんだよ。
例えば軽量スレッドとか、例えば軽量プロセスとか、プロセス間通信とか。
>>66 それ、この前podcastで作者の人が話してるの聞いたな。
結構すごい言語なん？
haskell、バグ少なくかけるとか謳い文句にしてる割にパッケージ管理ソフトが
盛大にバグってるとかバカジャネーノってなるわ。
c++11, rust, haskell あたりはシンタックスお勉強ごっこが
好きな輩にほんと大人気なんだよな。
別にそれはそれで個人で楽しんでる分には構わんが、人に押し付けてくるバカはほんと迷惑だわ。
明らかに難度高い押し付けは拒否しやすい
これくらい簡単だろ？って押し付けられるパターンの方が迷惑だよ
おお！ついにgaucheでの実際のプロダクト例が聞けるんだな！
是非語ってくれ。是非common lispではいけない根拠が聞きたい。
使いたいから使ってるんじゃなくて、他の言語が満足に使えないんでもなくて、
gaucheでないと問題を解決できないからgaucheなんだという実例が聞きたいわ。
>>67 いやその「軽量スレッド」がないと実現できない問題ってなんだよ？
軽量プロセスはネイティブスレッドとの違いが勉強不足でよくわかってないんだ。すまん。
プロセス間通信に関してはどういう意図でその言葉を使ったのが知らないが、
出来ない言語の方が少ないと思うんだが…
そもそもHaskellの並行処理は確か軽量スレッドだったはずだし、
プロセス間通信も普通に出来るぞ。
やっぱり、特定の言語じゃないと解決できない問題なんてかなり限られてくるはずだが…
何が言いたいんだ？
>>68 凄いかすごくないかは別として、素直かな。
>>72 何を煽ってるかわからんが、プロダクトとしては内製社内システムだよ。
CAD関連ののデータを触るシステム。
データ構造としてはS式で表すのが一番素直なシステム。
他の言語でデータをごちゃごちゃしてステートマシンの塊で処理するより、データ構造自体が手続きと言うかパラメトリックな式表現になってるほうが素直って感じ。
で、そっちは煽るだけじゃなくて、何作ってるの？
>>74 ネイティブスレッドであると都合が悪いってのは、極論はハードのスペックが上がれば無視できるとは思うし、微妙だったかな。
プロセス間通信も語弊があって、軽量スレッド同士のプロセス間通信がどう成されるかかもしれん。
erlangみたいな、疑わしきはプロセスごと殺して再投入みたいな思想や、プロセスの起動/再起動の単位や、プロセスへのメッセージみたいに、処理系の思想や備えられてる足回りか特徴的ならば、それはその言語であるから解決できる問題だと思う。
逆説的だけど。他の言語でそれを担保するにはコストがかかりすぎる、って。
>>69 この言い分も「めんどくせぇヤツだな」っていつも思ってたんだよ。
バグが減るって言ってるだけで無くなるとは一言も言ってないのに
なんでバグが見つかっただけで「話が違うじゃねぇか」みたいに騒ぎ出すわけ？
別にHaskellもRustも押し付けるつもりは全く無いし、
気に入らんなら文句を言っても構わんが、もう少しマトモなこと言ってほしい。
バグを減らすことに完璧に無関心にならない限り、取り付く島があると思って騒ぎ出す
>>77 erlangを使ったことがないから、なんとなく程度にしか分からんが、
そういう意味なら「副作用を記述しないコードの実現」がHaskellでしか解決できない問題じゃないか？
副作用は減らせるならそれに越したことはないんだし(その時点から否定するヤツは論外です)。
まぁ、Haskellみたいな純粋関数型は少々やり過ぎ感はあるし、最近はRustやSwiftみたいに
「副作用は記述できるけど極力避けましょう」みたいな思想を持った言語も増えてきたけど。
軽量プロセスは良く知らんけどコルーチンは排他も待ち合わせも手軽で軽くて良いが
どうせコア数だけスケールさせようとスレッド使うから今日ではあまり意味がない
シングルコア時代の優れた概念
>>76 同じ文を書いただけなのに煽ってる扱いってことは君はHaskellユーザーか誰かを煽ってるんだね？
俺が言いたいのは、自分が使ってる言語に関して説明できないようなことを他人に求めるなということだよ
>>78 cabal みたいな一番重要なパッケージ管理ソフトが無限ループしたり、
ここまでぶっ壊れてるって話にならんだろ。。
しかもデバッグが他よりも圧倒的にめんどくセー言語だっつーのにさ。
いろんなトレードオフ見たときに宣伝文句と比較して全く割にあってないっつー話だよ。
>>76 あと、common lispじゃだめな理由を説明出来てないぞ
出来ないよなあ？だって別にcommon lispでもいいもんな
それと同じで、どうしてもHaskell じゃないといけない理由なんて普通はねえよ。OCamlとかあるんだから
あと、聞かれたから答えるけど、俺は普段はFortran とPythonで量子化学プログラム作ってるよ
>>82 当たらずとも遠からず。
俺が根拠のあるプロダクトの話がなければただの煽りだろうし、haskell推しに根拠のあるプロダクトの話があれば煽りではなくなると思っての書き込みだよ。
なので、煽りかどうかはhaskell推しがプロダクトを出せれば煽りではないという返事になる。
>>85 聞いてないよ、普段どんな言語使ってるかなんてw
common lisp以外では妥当ではない、が根拠かねえ。
何かそんなにhaskellのプロダクトを言う事に抵抗あるの？
>>87 ほーんじゃあ言い直すわ
「普段は量子化学プログラム作ってるよ」
二行目は「Common lispでは妥当ではない」か「gauche以外では妥当でない」の間違いか？
そして大事なことだが俺はHaskell ユーザーじゃねえしHaskellの擁護もしていねえ。当然Haskellのプロダクトなんて知ったこっちゃねえ。
おまえがめちゃくちゃ言ってるから指摘してるだけだ
>>83 モナドに関してはおれは「便利に使えればそれでいいや」ってタイプなので
理論的なことはよく分かっちゃいないんだ。すまんな。
それに色々言ったけど、おれはHaskellよりRust推しなんだ。
Rustには「モナドもどき」しかない。
そしてその「モナドもどき」でおれは十分だと思ってる。
だいたい「～以外は妥当じゃない」みたいな理由が通るなら「Haskell 以外は妥当じゃない」も通るじゃねえか
>>48の後半は何なんだよいったい
何かうるせえ奴らが何人かいるな。
オナニーでもして寝てろや。
>>92 は？俺のことか？
そんな指図するならオカズでも貼れやｗ
>>84 だったらそこまで書いた上で批判してくれ。
そうじゃないとバカが喚いてるようにしか見えないんだ。
「話にならん」とか「割りに合わない」とかは人によって意見が違うんで、
それ以上はどうこう言うつもりはないよ。残念ながら君には合わないってだけの話だ。
>>94 ご丁寧に主食まで貼ってんじゃねえよ。吹いたわwww
>>94 うーん……��
これでオナニーして寝るのか……
ちょっと気合入れるか…… おやすみ……����
>>95 まあ大した問題じゃないと言い張るならそれも良いよ。
>>76 lisp系って結構いいもんなの？
熱狂的なファンいることは知っていたが（）だらけの式を見てるとゲンナリする
>>81 どうせ台数でスケールさせようとマルチプロセス使うから
スレッド使わずコルーチン使って1コアだけ使い切るプロセスにして
コア数だけプロセスを実行する、ってパターンは現在でも通用すると思うんだけどなあ
>>99 S式はWebAssemblyに採用されたな
>>102 電池が入ってないpython
並行処理とパターンマッチがないerlang
かつては言語に新機能入れてもLispの後追いって事が多かったけど
もうそんな状況じゃないからね
でも継続はあまり採用されないな
LispはPythonと違って一応最適化されたコンパイル済みバイナリ配布できるだろ
軽量スレッドはシューティングゲーム作るときは弾1発1発に使えるから重宝するんだけどな
ハードが進化すればどうでもいいとは言っても
流石にゲームがネイティブスレッドを1000も使ってたらスイッチコストも馬鹿にならんし
何よりタスクマネージャで見たユーザーがびっくりするw
>>88 そうか、じゃあずっとhaskellでそれ作っててくれ。
>>99 良いもんだよ。
CADの分野ではシステムに組み込まれた言語としても割と使われてる。
図研のとか、Autodeskのとか。
>>88 あ、読み違えたわ。
haskellユーザでないなら、別に黙ってりゃ良いじゃん。
haskellは良いものだ！って言うだけで何も具体例を出さない奴が居て、結局何が良いの？に答えが出なかったりしたから、
スレタイからhaskellが抜けたりしたわけ。
そのへんの過去スレは読んでのそういう発言？
滅茶苦茶でも何でもないよ。
お前の喧嘩の売り方がメチャクチャだよ。
>>88 よく考えたら言い直しにもなってないな。
haskellでのプロダクト例を聞いてるのに、普段使ってないよ、なんて、何を言い直してるかわからん。
反論するならきっちり反論して。
>>112 そうそう。それはデータであり、かつ評価できる式でもある。
jsとかgoとかだといちいちparserカマして抽象構文木を作った上じゃないとプログラムからコード解析できないけど、
lispだとそのままコード解析できるわけね。
なんか面白そう。
>>114 逆に、データもS式になってれば、それもパーサ要らないしね。
jsに対するjsonのように。
jsonのようにサブセットな訳でも無いので、そうしておくと、
そもそもデータに値の代わりに式を入れとくことも出来るから、融通がきく。
lispすごそうやんけ。
の割に、あんまり聞かないのは単に分野が違うだけ？web系で聞いたことないなー。
>>112 古典的な lisp では lisp で lisp のマクロも書くし
メタプログラミングは日常茶飯事というか「メタ」である特別さもなかった
古典的には lisp は LISP と書くのだけど
LISP 系の言語ではリストを万能データ構造として凡そ
配列以外の全て(プログラム自体を含む)をリストで表すので、
データ構造の宣言的な記述は省略される。
これはコードを書くときは楽だけど読むのには面倒か。
例
((foo 1) (bar 2)) というリストで辞書を表現するとして、
foo や bar がキーであるとか値はキーの直後の要素だとかを
宣言的に記述しておく箇所はコメント以外ない
>>110,
>>111 おれはID:uFcuTWSAじゃないがどう考えてもお前の方がメチャクチャだよ。
結局「common lispじゃなくてgaucheじゃないといけない」理由の説明できてないし。
お前のその返し(
>>72に対しての
>>76)じゃS式扱える言語ならなんだって構わないじゃないか。
gaucheユーザーのお前に
>>72の論破できないのと同じように、Haskellユーザーも
>>48を論破できない。
「自分でさえ論破できないことを他人に向かって言ってんじゃねえよ」ってことだろ？
まあc++でコンパイラ毎に全くコンパイルされる内容が違う状況とか
味わってみれば lisp みたいに構文化されてるコードを最初から書いた方が良くね？
って気にはなる。
確かにプログラムを全く書いたことないやつに薦めるのはどうかと思うが、
ある程度プログラムやったことある奴ならそこまで敷居は高くないんじゃないかな。
>>118 そもそも「あるわけがない」と煽ってるわけではない。
あるなら是非語れ、は真実。何回言っても「そういう煽り返しできる程度すら」挙がってこなかったから。
論破する必要なんかないんだよ。
「あるんだよ、こんなのなんだよ、haskellすげえっしょ」って言えればそれでいいだけなのに、
煽られたと思って、全く同じ文章で返事してくるほうが頭おかしいの。
その返事がgaucheであれなんであれ、煽られたと俺が受け取ったのは「全く同じ文章で返されたこと」であって、内容ではない。
>>118 あ、言葉足らずだったな。
S式で表せる言語なら何でも構わない、それは真だよ。
common lispではいけない理由、は俺は触れてないだろ。
よく読んでよ。
(h (g (f x)))をx.f().g().h()に変えても括弧の数は変わらん
foldrがfoldlに変わるだけだ
畳み込みという概念を知るだけのために凡人は何年も修行しないといけないのが現実
Haskellのプロダクトならpandocがあるやん
Parsecあるからなあ。
それは確かに「なるほど」と思ったわ。
>>120はねえ
『論破する必要なんかないんだよ。「あるんだよ、こんなのなんだよ、haskellすげえっしょ」って言えればそれでいいだけなのに、』
って言ってるけどね
>>108のレスでは『そうか、じゃあずっとhaskellでそれ作っててくれ。』
って言ってるね
こいつは例の「あ」で、Haskell について知らないことを晒されたことを未だに根に持っているだけで、本当はHaskell になんて微塵も興味がないんだよ
以前もHaskell のプロダクトを教えてもらってたのに未だに聞いて回っているしね
相手にするだけ無駄無駄
別に凄くない普通の言語のために何年も修行しないといけない現実と戦ってるんだろう
今すぐ教えろ
一瞬で理解させろって
>>116 Lispはまあぶっちゃけ滅んじゃったからねえ……
マクロとかいい感じに使えて良い言語だけど、ライブラリも割と貧弱で自分で構成していかないといけないから、他の言語でライブラリが充実してる今のご時世にわざわざweb屋が使うメリットはないんじゃないかな？
標準ライブラリが充実してる数少ないLispとしてRacketをオススメしておくから気になるなら触ってみるといいよ
>>125 テンション上げて説明してくれてありがとうね。
でも
>>123のほうがはるかに価値のある書き込みだったよ。
知らないことを晒されて根に持ってる訳でなはいんだけどなぁ。
そのことを説明できる能力もなく、ただただ「凄いんだ」「アセンブリレベルの話なんか高級言語では考える必要もない」という低レベルな主張を繰り返されたから、
何故なの？じゃあ考える必要がない程度のもの作ってるんでは？
に答えが貰えなかったから、さあ語れって言ってるのにね。
信者って悲しいわ。
>>126 違うよ。
する価値がないと思ってるから、次世代だ、する価値がある、と言うのならば、する価値を見せてみろって言ってる。
根に持ってるとかそういうバイアスがかかるから、「名乗れ」と言われて名乗ってやった「あ」を外してる(そしてhaskell以外の話題ではフツーにやりとりしてる)のに、
またバイアスかけてどーすんのかなー、自分の好きな話だけしたいお花畑なのかな？
haskellが蓮華なのかな？って思うわ。
毎回haskellが話題に出るたびに虚しいな、このやりとり。
コテを外されたからNG出来なくて困っちゃうよねえ
どうせバイアスがかかることが今回証明されたんだからもう一回コテ付けちゃいなよ
時間に価値がないと思えば何年でも続けられる
或いは時間に価値があるのは直感的に明らかと思うならば根拠のない直感にも価値はある
>>132 どうせバイアスを「かける」ことが証明されたんだろw
議論の上の「よく読んで」という指摘に「こいつの人格が悪い」という人格攻撃に走った時点で議論としては終わってるよ。
悲しいね。自覚がないって。
今回は「あ」がめちゃくちゃ言ってるからHaskell ユーザー以外から「それの論法はおかしいだろ」って突っ込まれてる構図であって、Haskell ユーザーは全然登場していない。
まさかその構図が見えてないのか……？
ああ、いつの間にか「議論スレ」でも無くなってるのなw
>>135 登場していないのか、登場していないことになってるのかは、胸のうちだからわからんよ。
俺も信者は悲しいなって言ってるだけで、誰が信者だとは言ってなかろう。
>>134 宣言しておくね
俺は君と議論する意味はないと思ってるから、君と気付き次第バイアスをかけるよ
>>139 バイアスをかけるという宣言のある議論の場っておかしいねw
素敵な花畑がほしいという自己紹介どうもありがとうね。
>>137 いや分かってるよ。
>>48に突っ込んでるID:uFcuTWSAもID:CtLujT77もどっちもHaskellユーザーじゃないって言ってる。
まぁ、それさえも嘘かもしれないじゃないかと言われればそれまでだが…
>>141 後者は使ってるけど推しではないと俺も思ってるけど、思ってるだけだよ。
嘘でもホントでもなく、知り得ないことだから仕方ない。
単純にわかるのは、煽って反応するやつが一定数居るって現実だけだけど、それで充分かと。
>>140 少なくともHaskell に関しては、君はHaskell を知らないんだからHaskell について語る土俵に立ってないよね
にもかかわらず君は最初、まるでHaskell について知っているようかのようなふりをしながら議論に参加していたんだ
そんなのバイアスをかけられて当然だよ
>>143 しつこいよ。
ここを花畑にして蓮華で蓮華座が組みたいなら人格否定せずに淡々と事実を述べれば良いだけでしょ。
人格否定した時点で議論は終わったの。
そりゃあめちゃくちゃな煽りを見たら煽られた奴以外も反応するだろ
>>144 ん？
俺は君と議論したくないからNGさせろっているんだが
最初から君と議論する気はないよ？
そんなに話したいなら、今立ってるPHPスレみたいに、次世代言語haskellスレでも立てれば良いじゃんw
>>142 いや煽られたから反応してるんじゃなくて、
煽りに使われてる文章の論法がメチャクチャだったから反応してるんだろ？
その違いは重要だよ。
理論がしっかり通ってる煽りだったらわざわざHaskellユーザー以外の人間が反応するわけがない。
少なくともID:CtLujT77に関してはHaskell推しじゃないとお前も思ってるんなら
Haskell推しの人間以外がわざわざ反応しているのおかしな状況に気付けよ。
>>150 間違えた。
前>>Haskell推しの人間以外がわざわざ反応しているのおかしな状況に気付けよ。
後>>Haskell推しじゃない人間以外がわざわざ反応しているのおかしな状況に気付けよ。
>>151 ん？やっぱり間違えていなかった(´・ω・｀)
アホか？俺は…
まさに
>>150よ。本当にその通りなんだけど、「あ」だし通用しないんだろうな……
次世代言語よりも日本語に付け加えるべき機能でも考えた方がいいじゃねーの？
まーたADHDが匿名で場を荒らしてんのか
ほんま困ったやっちゃな
騒いでる方も騒いでる方だが風評被害やめてくれって感じだ
Haskelがこういう場での無意味な話題に必要以上に上がるせいで実際以上にHaskell好きがHaskeller扱いされてる気がする
Haskellにはドカタの劣等感を刺激する何かがある
いかにもGWに予定のなさそうなキャラの子達が騒いでてウケる
Haskellって難しい理論がベースになってるせいか
ちょっとかじった程度で偉くなった気になる人多い
rustに難しい理論はねーよｗ
所有権みたいなことはあるレベルになると自分で考えるようになること
>>150はだいたい同意だけど、ちょっとだけ同意できない部分があるな
今回のあDHDほどめちゃくちゃな論法でなくても場合によっては指摘するかもしれん
例えば俺はLisp使わんし好きでもないけど、「Lispは遅いから糞」っていうレスを見たら多分指摘する
>>167 速さが求められるかどうかは何を作るか次第で変わってくるので、
取り敢えず「遅いからクソ」ってのは理論が通ってないし、突っ込まれて当然。
>>168 Common lispはまあまあ速いってことを念頭において書いたんだけど、それもそうだな。言う通りだ
>>166 ん～そうかな？
それはあくまでC or C++をメインでやっていた人に限られると思うが…
GCありの言語がメインの人達はほとんど考えてないと思う(根拠は2年程前までの俺)。
【プリッツァー賞も公認】 トルーマン 議定書 ＣＪＡ イルミナティ フリーメーソン マルタ騎士団
http://2chb.net/r/liveplus/1524877080/l50 デザインパターンが流行った頃なんかもそうだが、
新しいものを「せっかく覚えたんだから」みたいな貧乏性に陥る奴は昔からいて、
そういう奴がレガシーコードを残してったという歴史がある。
ふつうに真っ当な突っ込みを入れられるだけでうじゃうじゃ言って一日でここまで伸ばせるって、相変わらずあDHDはやべえな
>>172 どういうこと？レガシーコードってCOBOLとかFortranのあれのことではなくて、テストのないコードのこと？
流行とどういう関係があるの？
>>174 たぶんだが、新しいプログラミング手法(概念)がバズった時に「せっかく覚えたんで使ってみよう」
と適材適所もよく考えず(というよりかは覚えたばかりなんで適材適所がまだ分からないまま)
使う奴がいて、そういうコードは後から見ればレガシーコード(負の遺産)にしか見えないことじゃないの？
>>175 なるほどな。俺にも思い当たる節はあるなあ
俺はすぐに同等品を別の言語で作れるレベルを超える前に飽きちゃったから、ちょっと時間を無駄にした代わりにちょっとコーディングスキルが上がって次に繋がったって感じで終わったけど、
そんな理由で適当に作った負の遺産が問題になるほど作り込むってそれはそれで凄いなあ
その当時本当に新しかったなら負の遺産ではないだろう
デザインパターンがもう一回流行ったとき
新しいと勘違いしてもう一回何か作り込んだらそれこそが負の遺産だ
負の遺産はSmalltalkではなくSmalltalkをぱくった奴らだな
流行のスタイルって、それ自体は流行るだけの理由があって十分に優れてるんだよ
統一されてるうちはいいけど、後に別の流行と混ざった途端に糞になる
COBOLも伝統的なIPOスタイルのコードは美しいけど、SQLまみれになってから無茶苦茶になった
今はデザインパターン流行っとらんの？
あれって恒久的に使われるもんじゃないので？
>>181 GoFのことなら、大半は未熟なオブジェクト指向言語の機能を使ったハックに過ぎないから
便利な「C#系」が主流になりつつある今となっては明示的に使われることは少なくなったね
>>178 ゴミ過ぎて負の遺産も残らなかったからね、Smalltalk
型を明示したときにジェネリクスが一個も出てこないのは不自然だろ
恒久的ではない型システムを混ぜてしまった奴が戦犯
Haskellがクソなのはまぁ同意するけど
Lispは割と直感的に書けるやろ
>>185 副作用警察だ！貴様を逮捕する！（Land of Lisp風）
Lispを守りHaskellを叩く理由は
Lispが直感的に書けるからであって、Lispをせっかく覚えたんだからではないらしい
叩いてる張本人がそう言うならそうなんだろう
Haskellが直感的に書けないっていうのはよくわからん
普通の関数の記述は他の言語よりむしろ直感的だし、モナドだってdo構文使えば他の言語とそんなに変わらんやろ
>>182 よくわからんな。今どきの言語に合わせたデザインパターンを出してくれればよいのに
>>189 その今どきの言語というのがまだ定着していないんでないか？
何年かしてノウハウが蓄積されたらまたそれらをまとめたものが出てくるでしょ。
>>188 遊びでしか使ったことないからあんま深くは言えないが
本気で使おうとすると、haskell のシンタックスからコンパイラが吐き出す実際のマシン語での動作を
予測できるくらいhaskellの癖をわかってないと使えん印象なんだが。
>>192 もしかして速度が気になってチューニングとかしてるのか？
ってか俺もHaskellにわかだし、多分俺より
>>192のほうがしっかり使おうとして難しい所に当たったんだろうな
第一級関数使えると結構な数のデザインパターンが不要になるからな
継承は使わない方が良いっていう風潮だし、継承前提のパターンも微妙になってる
そもそも新しい言語からは継承消えていってるし
直感でエリクサーを消費できない人にはレガシーコードを捨てるのは難しい
[[[ []]]]*[[ [][] ][] } } {} [[[
アドホック多相とパラメータ多相のある言語が流行りますように……
javaが滅びたのにpythonだけ生きてるパターン
>>200 いい翻訳本が出たってんで買ってみたけど
さっぱりわからんかった(>_<)
過去スレ読み返してみたが「あ」は冗談抜きで本当にADHDだったのか…
それじゃ、これほどまでに意思疎通が難しいのはしょうがないわな。
一般人が通常の会話で無意識に補完してる部分を「あ」には明示的に言わなきゃ伝わらないということだな。
「あ」自身のためにももう一度コテハン付けるようにしてくれ。頼む。
ASDとADHDの違いがわかってない奴がまた一人出てきた
「あ」じゃないけどADHDの俺氏切れそう
>>210 「あ」は明らかに意思疎通が難しいけど、それはADHDではなくてASDってこと？
その辺の病気関連難しくてわかんないや
>>211 例えばこれ↓はASDの症状だ
＞一般人が通常の会話で無意識に補完してる部分を「あ」には明示的に言わなきゃ伝わらない
「あ」やADHDの場合は多動（落ち着きのなさ）が常時発生してるから、
相手の話をちゃんと理解する前に衝動的に返事するので意思疎通が難しいと思われる
決して無意識の補完ができないわけじゃない。常に慌てているのと、自分でそれを直せないんだ
>>212 彼も本当は無意識下の補完は出来るはずということか
でも現状、非常に丁寧に説明することで、いっぱいレスを使ってなんとか意思疎通出来てるような気がするけど、実はもっと良いADHD向けの方法があったりするの？
彼の文章の読み難さについては医学的にはどう説明されるの？
>>210 気を悪くさせたならすまなかった。
俺は友人の妹にADHDの子がいて時々会話することがあるってだけで、
そういう知識に詳しいわけじゃなく、俺の経験則での対応策なんだ。
あと過去スレ↓の800~1000あたりの部分を読み返してみて分かったが「あ」はきちんとHaskellのこと分かってるよ。
http://2chb.net/r/tech/1492631007/ 一連の流れを少し整理してみた。
「Rustアンチ」：Rustは再帰的データ構造が書けないからクソ。注釈：これはウソ。実際には面倒なだけで書ける。
「あ」________：書けるでしょ。お前ができないだけで。ただしHaskellみたいにジェネリクスの多相再帰はできないけど。
________________Haskellは実行時に多相再帰を解決するけど、Rustはコンパイル時に解決しなきゃならないから。
ここで、何故かHaskellerがHaskellをバカにされたと勘違いしたのか反応する。
「Haskeller」_：Haskellはジェネリクスをきちんとコンパイル時に解決してる。
「あ」：________ほとんどね。でも全てではない。
________________注釈：Haskellはジェネリクスの多相再帰だけは実行時に解決してるからこれは事実
「Haskeller」_：そんなはずない。コード例を見せてみろ
ここで、何故か「あ」が、Haskellのコード例ではなく、
Rustでジェネリクスの多相再帰コード(つまりコンパイルエラーする)例を示す。
「Haskeller」_：Haskellのコードじゃない。こいつHaskellのこと何もわかっちゃいない
って流れ。
つまり、絶望的に意思疎通が出来ていないだけでHaskellのことはきちんと分かってる。
ちなみにRustとHaskellのジェネリクスの多相再帰の問題は↓を見ると分かりやすいかな。
http://qnighy.hatenablog.com/entry/2017/03/16/114133 長文失礼した。
>>213 奴の調子次第だが、丁寧さはそのままで、一問一答みたいな感じで一度に処理する情報を少なくしてみてくれ
要はすごいスピードで飛ばし飛ばし文章を読んでる奴にどう理解させるかという問題になる
>>215 何かこっちこそすまん
しかし明示的に言うっていう対応策が有効そうなのがまた悩ましい
>>216 うーん。その解釈は結構腑に落ちない部分があるなあ。908,929,930のやりとりなんだけど
なぜかcar cdrが登場する点とか、（Rustのこと全然知らないんだけど、car,cdrは出ないよね？）
HaskellとScala間違えてるの？って聞かれた後でRustと訂正を入れずにoptionとかnilとか言ってるところとか
これ全部慌ててるからだっていうのなら、それこそ絶望的に感じる
>>217 現状、一つ議論しようと思ったらその倍以上のレスを使って理解させることになるのが悩みだったんだけど、解決は無理か。ありがとう
>>216 いや、ごめん。car,cdrは彼がlispユーザーだからなんとなく型名に使っただけか。
>>219 「あ」本人が「その辺は記憶だより」とか「違うかも」的なこと言ってるから、多分混乱してるね。
なにより、そう考えると辻褄が会うんだよ。
逆に、Haskellのことを何も知らないと仮定したほうが、
「何故ジェネリクスの多相再帰はできるけど実行時に解決してるということを知ってるのか？」
ということの説明ができなくなる。
この問題はHaskellについて詳しくないと答えられないはず。
しかも、聞かれたわけでも無いのに自ら答えてる。
ということは、「Haskellについて知っている」と仮定するほうが妥当。というのが俺の考え。
>>216 いや、よく読んだらたしかにおっしゃる通りだ。そのほうが綺麗な解釈だわ。3回もレスをつけてすまん。
よく読まず慌てて見当違いなレスをする症例
>>219 >>224 つまり一般人でも時々やってしまうことだからそう珍しいことじゃない。
ただし、「あ」の場合は「時々」じゃなくて「いつも」にということになるけど。
あと、そういうの煽ってるように見えるからよくないと思うよ。
そうですね。
不快な書き込みをしました。謝ります。
情報処理が遅いのは病気ではないぞ
自称健康な人でも前スレで出た情報を今頃処理してるんだから
人類はそんなに優秀な生物ではなかったというだけの話
最近Macを買ったからSwiftでも始めようかと思うんだけど
Objective-cもSwiftもどちらも全く触ったことがないならSwift始めるでOK?
次世代言語スレとしてはQ#から始めるべきと答えざるを得ない
「あ」の場合は慌ててるだけじゃあないよね
慌ててるだけだったらID:VNBrLSx6みたいに自己訂正して話はおしまい。
あんなに長々と場を荒らしたりはしない
解釈の原因は解釈者自身の固定観念。解釈の自由には責任が伴う
言葉風紀世相の乱れはそう感じる人の心の乱れの自己投影。人は鏡
憤怒は一時の狂気、無知無能の自己証明。中途半端な知識主ほど激昂
「真実は一つ」は錯誤。執着する者ほど矛盾を体験（争い煩悩）
他人に不自由（制約）を与えれば己も不自由（不快）を得る
問題解決力の乏しい者ほど自己防衛の為に礼儀作法マナーを要求
情報分析力の低い者ほどデマ宗教フェイク疑似科学に感化洗脳
自己肯定感の欠けた者ほど「己の知見こそ全で真」に自己陶酔
人生経験の少ない者ほど嫌いキモイ怖いウザイ憎い想定外を体験
キリスト教は世界最大のカルト。聖書は史上最も売れているト本
全ては必然。偶然 奇跡 理不尽 不条理は思考停止 視野狭窄の産物
人生存在現象に元々意味価値理由目的義務使命はない
宗教民族領土貧困は争いの「原因」ではなく「口実動機言訳」
虐め差別犯罪テロ紛争は根絶可能。必要なのは適切十分な高度教育
体罰は指導力問題解決力の乏しい教育素人の独善甘え怠慢責任転嫁
死刑は民度の低い排他的集団リンチ殺人。「死ねば償える」は偽善
核武装論は人間不信と劣等感に苛まれた臆病な外交素人の精神安定剤
投票率低下は社会成熟の徴候。奇人変人の当選は議員数過多の証左
感情自己責任論 ～学校では教えない合理主義哲学～ m9｀･ω･)
[[[ [ "[]" ]]] [] [][[[ [] ]][]
>>219 >>222 「あ」だから間違ってるに違いない、と言うバイアス無しで検証してくれてありがとうね。
でも、俺がhaskellの知識があろうがなかろうが(事実自慢できるほどは無いし)、そんなことはどうでもいい人たちが
「俺の方が賢い」「知識ないよね？対等じゃないから無視するね」とやりたいって事はもうどうにもならんと思ってるから、
半コテすらやめたし、鬱陶しくなりそうだったら一旦煽って瞬間的に燃やして、
建設的な話ができるようになるように鎮火するの待ってる。
>>236 別に「ありがとう」だとか「鎮火するのを待ってる」とかはそれで良いんだけど、
「あ」が「建設的な議論」がしたいのなら、その前に「あ」自身がきちんと「意思疎通」できるように心がけてね。
でないと、「あ」に対して人格否定を始める人間はいなくならないからね。
こういうのは相互に努力するから解決するんであって、どちらか一方だけが頑張ってもダメなんだよ。
今回の件で、君にバイアス無しで検証する努力をしている人もいるということは分かったでしょ。
だったら、君も他人に対してしっかりと意思疎通しようとする努力をしようね。
(「具体的にどう努力すればいいのか？」とかまではさすがにここじゃ面倒を見切れないからリアルの友人とかに相談してね)
少なくとも、ここにいる君以外の大多数の人間は「「あ」がきちんと意思疎通するための努力をしていない」と思ってるはずだよ。
もし、「あ」が「そうじゃない」と思うのなら、今この場で「自分は意思疎通の努力をしていないように見えますか？」と周りに聞いてみなよ。
多分ほとんどの人間が「「あ」は意思相通の努力をしていないように見える」と答えるはずだから。
でもって、「「あ」が意思疎通の努力をしている」と周りが感じられるようになったら、人格否定してくる奴らは次第に減るはずだから。
そもそも、バイアスをかけられてしまった原因は自分にあるということを自覚してね。
プログラマって自分の正当性に異常に執着するやつ多いよね
スレ違いなのは明白なのに延々とどうでもいい話を続けるやつはその典型
一種の知的障害なんだろうな
>>237 うん、それはおっしゃるとおりだな。
ちゃんと読んでくれてる人が居るならば、言葉足らずではいかん。
伝わるだろう、と最低限で伝えるのは改めるわ。
書いてねえこと読むなとか、書いてあること先に読めとか言うのは、まあ嫌味にならん程度に補足しながら話す。
嫌味言う方だから、「本人もわかってるだろうし、ここまで言うとやっぱこれも嫌味になるかな」って自重してた。
すまんかった。
バイアスバイアスっていう割に本人も他人の意見にバイアスかかってそうなのが気にかかる
>>238 スレチなのは承知の上で、それでも敢えて指摘してるよ。
でないと、今回の場合はそもそもマトモなコミュニケーションにならん。
スレチかそうでないか以前に2chは(議論、雑談を含む)コミュニケーションの場だろう？
でもスレチなのは事実だ。すまないな。
あと、俺もプログラマだが「正当性を主張したい」わけじゃなくて「問題を解決したい」んだよ。
つまり、デバッグがしたいわけ。
デバッグがしたいってのは実にプログラマらしくて、少なくとも悪いことじゃないと俺は思うけど。
俺はこの辺で一旦ROMるんで後はご自由に。
>>241 えー。このスレのコミュニケーションの正常化のためには君は必要不可欠な存在だ。そう言わずに是非書き込んで欲しい
そらそら、正当性を主張せずにはいられないんだよ、ビョーキなんだよ
デバッグは結構、でも自分のバグは自分で潰してくれ
>>243 やめたまえ。またこのスレを一つ議論するたびに倍以上を解釈の伝達に使う地獄に戻す気か
デバッグがしたいならまずコードとコメントを区別しようぜ
コードは良い内容も悪い内容も実行される
コメントはある意味フィクションであり利益は一円も出ないがその代わり損もしないのだ
>>239のレスからは自分が悪いから治そうというよりも、あくまでも相手が悪いから合わせてやるという感じの上から目線な強い心意気が伝わってくる（もちろん実際の心内は知らんがね）
これだけ親切なID:nkNJAN4mにあれだけ懇切丁寧に説明されてもこんな反応しか返せないなんて、これは多分治らんな。
>>246 そんなこといいんだよ
本人が仮に「相手に合わせてあげよう」とか思っていたとしても、コミュニケーションが通るのなら、それならそれで結果 all right だろう？
>>248 こういうのは心の持ちようだよ。それでも治るんなら良いけれど、
現にこれまでも彼は何回か同じように諭されて、今回みたいな感じのちょっと反省した風になって、それでも治りはしていないじゃないか
お前らの頭が旧世代なのは分かったから
次世代言語の話しろよ
>>246 大人げない言い方をすると、心内を知らないならそういう事言わないほうがいいと思うが。
あー、たしかに悪かったな、と思って「すまん」と言ったつもりだよ、少なくとも。
仕方ないと思ってりゃ、仕方ねえからやってやると言ってるわ。
どんだけ突っかかれば気が済むのかな？
>>249 そもそも勝手にキレてくる事のほうが多いけどね。haskellerさんは。
お前などに語られたくない、と。
まあ、じゃあ先に語れよって思っても仕方ないじゃん…。
>>250 現状のこのスレの状況で次世代言語の話をしようとしてもすぐに脱線しちゃって、
>>48のレスから
>>150の簡単な合意を得るまでに102レスもかかっている。こんな状況では次世代言語の話をしてもすぐに脱線することになると思う
今行われている会話はこの状況を脱するためには必要なことだと思う。
次世代言語を使ってあDHDのレスを識別するAIを作ればいいだろ
>>251 少なくとも
>>239はそういう風に取られかねない文書だよ。
>>237のいう「他人に対してしっかりと意思疎通しようとする努力」を本当にしている？していてその返答？
「もしかしたらまた自分の文章が悪かったかもしれない」という自省の念はない？俺に反論することが全てになっていない？意思疎通に限らず、成長に重要なのは自省だよ。
しかし「どんだけ突っかかれば気が済むのかな？」か……
俺はID:oQ8WGmv4と違ってADHDの人とコミュニケーションを取るのは上手くないし、
>>253が言ってるような簡単な合意に至るまで102レスもかかる人とは話したくない。
でも君が変わりもしないしコテもつけないしでこのスレに居座っているなら、匿名の君に触れてしまい、しょうもない合意にレスと時間を費やすことになる。それは嫌だし、君はコテをつけないという。だから君が変われないのは困るんだ。そう思っての
>>246のレスだよ。
それでも突っかかって欲しくないっていうならまたコテをつけなよ。そうしたら俺はもう君には二度と話しかけないよ。
>>252 このスレでもそうだった？今もそう？
君は随分とバイアスを気にしているけど、自分の認識にバイアスはかかっていない？
ふと思ったんだけど、そもそもADHDの煽りカスって時点でコミュニケーションは無理だよね
ADHDはやめられないし、煽りカスも辞めないという。これは厳しい
ある意味言語の話だな
これほど真面目に自然言語について議論してるスレはなかなか無いぞ
>>259 まあ、板違いだけどね。
｢あ｣とやらがコテつけてくれるのが最も現実的で皆が幸せになる解決策だと思うよ。
>>255 意思疎通しようとする努力はしてるつもりだよ。
匿名の俺に触れてしまい、と言うか、結構匿名の俺と普通に議論してることもあるんだよ。
ただ、単に一部の人間が、haskellについてマイナスにも取れる事を言うと燃え上がるだけであって。
いずれにせよ、余計なことは言わないようにするよ。
特にhaskellに関してはその存在すら触れないようにする。
では。
ある人物がいるところには必ず悪い結果が生じる
ある言語に触れたら必ず悪い結果が生じる
こういう因果関係に縛られて身動きが取れない世界観をなんとかできないのか
逆張りが必要だ
旧世代のジンクスが破れる方に賭けないと次世代は出てこない
ひでぇな…ちょっと見てない間にこの有り様かよ。
俺も煽り耐性ないほうだから「ROMって様子見るつもり」が耐えきれず出て来ちゃったよ。
このスレにはADHDと知ってなお煽るカスがいるのかよ。
特にID:c3w1WFHIだよ。
おまえ「コテ付けたら話しかけない」とか言ってるが
>>240,
>>246,
>>249,
>>255,
>>256の中で「コテ付けてほしい」って言ってるのが
>>255のたったの1つだけ。他は全て「あ」に対しての「煽りや批判」。
おまえの本心は「コテ付けて欲しい」でも「「あ」と話したくない」でもなく、
ただ単に「煽ったり批判したりしたい」だけだよ。
「「相互」に努力しろ」って言ってるだろうが。
解決するつもりが欠片でもあるなら、いちいち煽ってんじゃねぇよ。
解決するつもりが全くないなら、それ以上は俺もどうしようもできねぇよ。
自分からこの話振っといて言えた立場じゃないのは重々承知なんだけど、
そろそろ次世代言語の話に戻ろう。ご迷惑お掛けしました。
Haskellやってから$で後ろの文を優先度低いコードにするやつが欲しいけどそういうの流行ってないのけ？
オブジェクト指向捨てて関数型の鬱陶しいところ解決したら次世代言語でいいよ
HaskellはCommon Lisp の力強さとSchemeの美しさを併せ持ち、インデントに意味を持たせることで極限まで括弧を減らした言語だってLand of Lispかなんかに書いてあった希ガス
みんなxcodeでカード書いてるんでしょ？
どうやってxcodeの使い方覚えた？
visualstudioしか今まで使ってこなかったからIDEの操作で右往左往してるわ
iOSアプリ入門で覚えた。
xcode自体は割と素直な環境だと思うけどな。ただし俺の知識はswift2で止まってるが。
ここでhaskell押しをよく見るけど、正直取っ付きやすさは最悪だと思うんだけど、、
関数プログラミング実践入門
ってやつを読み進めてみたけど、半分過ぎても helloWorldまで行かなくて、なんてヘビィな言語だと思ったわ。
一方go言語は一時間で動かせました。
学習日一日目でphpで書いたバッチ処理をgoに移植できたよ。
なんだかんだでgoは学習コストとできるコードのバランスは良いと思うよ。
あんまり無作法なことするとコンパイラがコンパイルしてくれないくらいか。
gofmtあるし、vscodeでもプラグイン入れたらわかりやすいし。
後、結構組み込みに向いてないかなgoは？
例えばラズパイでsdに録画したデータを外部サーバにpostしようとしたときに、
一度メモリ上に、全部配置してからじゃないと動かない挙動だったんだけど、
検証したらpost処理時にsdからreadしながら転送できるように修正できた。
純粋オブジェクト指向言語が定着しなかったのと同じで
純粋関数型言語もメインストリームにはなれないと思う
goの良さって標準ライブラリが全部goで書き直されていて、それを読めば解決策が思いつくことがあるってことだな
>>275 リッチな組み込みには向いてると思ってる。
linuxのarm用にコンパイルしたら、androidでも動くし(普通のSDKアプリからプロセス起こして遊んでみた)
GCの動作と、そもそもリアルタイムが出せないを許容できるなら便利かと。
たしかqiitaでも、組み込みに押してる人居たよ。
goって組み込みでも使えるしwebでも行けるしスマホアプリも作れなくもないし
wasmにも対応間近だからwebクライアントにも進出しそうだし、いい感じ。
>>280 Rustはどうしても手軽じゃないんだよね
とはいえ、Rustも慣れると案外サクサク書けるから悪くはないと思う
慣れるまでメチャクチャ時間がかかることがそもそも問題なんだけどね…
メチャクチャっていうけど一週間もあればそれなりに書けるようになるでしょ
慌てるなよ
自分が数学を何年勉強したか思い出せ
1週間で何ができる？何もできないでしょ
>>282 Rustが一週間とか羨ましい頭してるな
毎日まじめにやってたわけじゃないのもあるけど、半年かかったわ
一週間とかおれには無理
>>283 一つのプログラミング言語を現場に持ち込むのに数年かけているのか？
>>284 phpで書いたバッチの移植くらいならできるでしょ
>>285 それくらいならまあギリギリ
でもちょっとでも複雑になっただけですぐアウト
とっつきやすさとかいうほど重要か？Javaとかそんなにとっつきやすかったイメージないけど
金のことばっかり考えると勉強ができなくなるようだな
子供は金持ってないのが当たり前だから何年も勉強できる
>>273 > 関数プログラミング実践入門
それは関数型言語の入門書だからHaskellのHello, Worldがなかなか出てこないのは当然
Haskellが「ヘビィな言語」なんじゃなくてあなたが「関数型言語」に馴染みが無いだけだと思うよ
まあたしかにHaskellのHello worldなんて大した長さじゃないし、本の最初のほうに配置するべきよな
そして最初に配置している本は見たことがない。あるのか？
>>289 馴染みのある人間が 入門 を果たして読むのか。
Haskellの難易度はC++とほぼ同じと気付くまでにあと何年かかるかな
phpで並列処理が書きづらくて、goに触り始めて感動して。
ちょっと触ってみて使えるのを確認して、
goを本格的に触るようになった。
ちょっとしたモチベーションで気軽に始められる。
ローリスクハイリターンな感じ？
haskellとかrustに触るモチベーションって言語マニア以外は何があるかな？
>>290 関数型とはなんぞやをすっとばしても入出力を扱うには副作用・モナドあたりを先に
やる必要があるから仕方ないね
>>291 つまり馴染みのないあなたにはHaskellが「ヘビィ」かどうかなんて判断できないってことだよ
>>294 そんなんHello wordするためにはincludeを理解する必要があるって言ってるようなもんじゃん
IOアクションなんて最初は「おまじない」で良くね？
>>293 Haskellの方は知らん
RustはC++の代替え
C++はもう嫌だ
>>294 そうかな。elixirも関数型言語だけど、だいぶ遊びやすかったけど。
俺みたいなショボいプログラマーはhaskellに近づかないほうが良いのかな。
素直にelm辺りを触ってみますわ。
C++にはbetter Cとかいうチート技があるから1秒で即戦力
1時間で自慢してるやつは恥を知れ
>>293 Haskell 勉強中なんだけど、ちょっとパーサーをいっぱい書く必要があって、パーサーを量産することがモチベーションになってる。Real world Haskell でチュートリアル的にJsonパーサー作れるくらいにはパーサー書きやすいんだと思う
でも環境周りとか正直鬱陶しいから、もしもっと書きやすい言語があったらそっちにしたい
>>293 rustやhaskellを選択しない自分に劣等感を抱いてるのかね
他の言語をオタク専用であるかのように揶揄して自尊心を満たそうとするのはやめんしゃい
わしはGCとおさらばしたいしresult/optionの扱いが気に入ってrustを使ってる
>>301 特定の書籍ではないね。本屋に山ほどあるどの本でも良いのでわ？
もしくは最近だとmixiとかが社内研修用のコンテンツを無料で公開してるからそれを利用しても良いと思う。
GCフリーは確かに魅力だけど、充分に賢ければGC言語でもそこまで問題になる事は無いと思うが。
そういや、rustだと、自身も誰かから特定のイベントを受け取るか、誰もイベントを送り得なくなったら死ぬような感じの、
タイマーみたいな自発的にイベントを起こすイベントソースは誰か所有すべきなのかな。
タイマー起こしたやつってのも変だし。
Rustの Rc<T> 型の問題
Haskellの IO a 型の問題
難易度下げたいなら型を書くのをやめればいいんだよ
>>307 とりあえずRustの話だが、Box<T>にせよRc<T>にせよ書かねえと
ボローチェッカを満足させられない or コストを可視化できねえんだよ
>>309 そうだね
チェックしたいなら学習コストを犠牲にすればいい
コスト下げたいならチェック機能を犠牲にすればいい
>>310 なんか勘違いされた気がするから補足
コストってのは学習コストのことじゃなくて実行時のコストのことね
Boxを明示することでヒープであるコストを可視化する
Rcを明示することで参照カウンタであるコストを可視化する
コードの短さこそ正義。ただし、可読性を損なわない範囲で
つまり、書かないとボローチェッカを満たせないというのももちろん理由の一つだけど
実行時のコストを可視化するという意味でも書いておいたほうがいいというわけ
Rustは実行速度が速くないといけない言語なんでね
2種類のコストの概念を学習するのが面倒臭い
だから色々なコストを無視して作ったフリーソフトが無双してるんだと思う
リスト内包表記が読みにくいって人たまに見かけるけど、このスレにもおる？
Haskellのリスト内包表記がモナドと知った時の衝撃
まあ3項演算子と同じで慣れよね
doといい、内包表記といい、全部ちゃんと何かのシンタックスシュガーになっているのには恐れ入るわ
ユーザーからしてみればそこまでしてもらわなくてもいいっちゃいいもん。
開発側の強い拘りを感じて好きだわ
Fortranのあれは内包表記と扱って良いものか悩む
RustはDみたいに.mapとか.filterとか繋げるのが主流かいな？
拘りっつーか関数型言語なんでそりゃそう作るでしょうよ
適当に文法導入してそれが関数に還元できないものだったら理論破綻するじゃん
そういえば純粋関数型だったな。Haskellは
純粋の意味を忘れておった
>>319 Dはやったことないから知らんけど多分同じ
C#のLINQみたいな感じでメソッドチェーンする
>>322 Rustは速くなくっちゃいけないとの事だけど、それって速いの？
>>326 え、rustのループとCのループって速度違うの！？
じ、じゃあCのループで
rustのmap,filterとcで同等のことをするのは、真ん中とって同じくらい速いと考えてよろしいですよ
大変非本質的なことを書いて申し訳ないんだが、<>と::に拒否反応が出る。俺だけかな
無茶苦茶な事敢えて言うがやっぱプログラミングするに至って世界に記号が足りない。だから2個記号を並べるというダメな記法になる
ついでにアルファベットも50個くらいにしてくれ
Vimでなんかのプラグイン入れてhaskell書いてたらラムダ式のバックスラッシュをλに変えられて草生えた
>>333 Juliaみたいにユニコード完全対応するとギリシャ文字を変数に使えたりするが
いまいち流行りそうな感じがしない
変数とかじゃなくて記号としてだろ
λとか { (x,y) | x ∈ R, y ∈ R } とかアリではあるのだろうけど入力面倒そうでもある。
Int や Real を意味する派手な(縦線が二本線)大文字の I や R も欲しい
Agdaとかその辺徹底してる。
作者自身が教えてる動画で、その記号どうやって打つのて何度も聞かれてて、
最後は何でユニコードにするの？て聞かれて、だってそっちの方が美しいじゃん？て答えて失笑されてた。
めんどくせ、こりゃ流行らんわと思ったけど、慣れると\より\lambdaて打ちたくなる不思議。
中置の二項演算ができたら記号は何でもいい
他には分数のように縦に並べたい
欧米の人たちは∈∧∋とかどうやって入力してるんだろう？
Unicode打ち込むエディタとして、Junoは良く出来てる
RAIIとGCってどっちがパフォーマンス優れているの？直感としてはGCの方が効率良さそうに感じるんだけど
感じるならしょうがないけど
GCは解放していいオブジェクトがどうか判定しなきゃいけないけど
RAIIだと不要だよね
究極的には圧倒的にGC
GCはメモリの再配置が可能という極めて大きな最適化の自由度があるからね
>>346 RAIIで面倒見きれるような単寿命のオブジェクトはほとんどGCのコスト無いんだぜ
再配置できるのはメモリアドレスを抽象化してる場合でしょ
GCとは直接関係ない
>>347 メモリの再配置なんて、C++ に慣れた身からみると、いかにもにコストが高そうだが…
>>349 その「メモリアドレス抽象化」はアプリケーションに益をもたらす性質があるのでしょうか？
>>348 RAIIが短寿命？
関数スコープのスタックにオブジェクトを置くだけがRAIIじゃないよ
どっちにせよ同じ条件でRAIIより速くはならんでしょ
解放のコストもさることながら、確保のコストが気になります
>>350 やっぱり第一にメモリコンパクションじゃない？
アクセス透過性みたいなのも原理的にはできるだろうけどプログラミング言語レベルで
そういうの実現してるのはなさそう
>>352 気になるんならしかたないけど
確保はほぼ違いがないよね
補足すると
GC言語はヒープを多用する傾向はあるけど
そういう場合スレッドローカルなヒープだったりするからね
>>355 スレッドローカルなヒープってどういうこと？
普通のヒープ(Cのmallocとか)とどう違うん？
>>356 あるスレッド専用のヒープってこと
そのスレッドしか使わないから排他処理がいらないので速い
スタック確保とそれほど差がつかない
cでもglibcとかだとスレッドローカルをミックスして使ってたと思う確か
RAIIを徹底したらスタックでメモリ管理出来るようになったりするんだろうか？
>>357 すまん。また質問なんだが、
ミックスして使ってるってどう言うこと？
それとRustのjemallocとかだとまたglibcと違う動きをするの？
取り敢えずjemallocの方が速いらしいぐらいしか知らないんだけど…
ごめん。意味が伝わりにくい書き方をした。
ミックスして使ってるって言ってもglibcは一体どうやって
スレッドローカルなヒープとそうでないヒープの区別をしてるの？
>>359 うろ覚えなんで間違えてたらすまんだけど、
最初は普通にグローバルヒープひとつではじまる
普通に各スレッドがロックをとってメモリをとってくるんだけど
もしロックがとれない状況になるとスレッドローカルなヒープを
作成するとかだったと思う
どっかに詳しく説明してるスライドショーがあるはず
>>361 ありがとう。
出来ればそのスライドとやらのリンクを貼ってくると助かる。
もう覚えてないってんならしょうがないけど…
dockerがgoで実装して十分パフォーマンス発揮してる時点で
組み込みレベルでないならそこまでGCいらんことは示されただろう。
GCはあっても無くてもいいけど
スタックかヒープかくらいは選ばせて欲しい
正直なところ、カスがGCなし言語で書いたものより、適当にGCあり言語で書いたもののが
ランタイム速度も速いでしょ。
バカがクソみたいな議論してる間にgoのGCの性能上げてたgoogleは正解だよ。
仮にDockerがPythonで実装されていたらやはりパフォーマンス足りなかったんだろうか？
>>351 スタックベースじゃないRAIIはメモリの断片化の原因になるぞ
1. 性能が足りないとクレーム
2. 厳しいノルマ
3. データ改竄
4. 1のクレームがぴたりと止む
こういう事案なら1から4まで全員怪しいよね
firacodeにカスタマイズ機能つければいいのか
dockerで示されるパフォーマンスなんかないだろ
パフォーマンスにちょっと興味を持つだけで怪しい奴らが集まってくる
Pythonのようにパフォーマンスに完璧に無関心にならないとすぐ腐敗する
ボトルネックだけCythonとかでなんとかするスタイルはやはり正しかったということか
そもそもRAIIはパフォーマンスのためのものじゃないだろ
dockerって正気か？動作中は何もしてないぞ？
# go のGCが優秀になったのは認める
なぜgoのGCだけを改善するの？
全てのGCを平等に改善しないとダブスタだと叩かれるかもしれないよ
>>378の他のレスも含めて何言ってるのか分からないものばかりだから、考えても無駄かと思うよ
goのGCと同じものをC++で実装できないのかな
C++のGCが優秀にならないかな
そういう意味
>>382 C++のGCって一体なにを指しているのだろう。
>>383 次世代の誰かだろ
正確な予知はできない
C++でGCとか言うとバットマンのコスプレしたハーブ・サッターにビンタされるらしいぞ
きっとスマートポインタなんかじゃやだもんって意味かと思いました。
>>392 メモリアドレスが抽象化されてれば、実行時の状況や統計情報に基づいたメモリレイアウトの最適化ができるね
理論的には、一緒に使われるものをメモリ上で近くに置いたりしてキャッシュヒット率を上げたりできる
>>393 それは抽象データ型を定義できる言語ならどれでも可能か
それともC++やRustでは不可能か
これが問題だ
>>393 ってもそれ空理空論であって、
x[i,j,k] みたいな配列のメモリレイアウトをアクセスパターンから
決めるという単純な処理ですらどの処理系にも実装の予定すらないだろう
「c/c++では有能なプログラマがちゃんと判断して書くから最適な結果が得られる可能性が高い」
という言説の方がまだ現実的
>>396 単純に隙間を詰めるだけなら普通にやってるし、それだけでもメモリのアクセス効率や利用効率は改善するよ
>>397 それアクセスパターンと関係ないでしょ
話通じてないな
アクセスパターンからの最適化というのは、
巨大な配列だけどアクセスされるのはごく一部
→スパース配列を用いる
2次元で同じyについて近しいxで連続してアクセスされることが多い
→ cでいう v[y][x] というように同じy座標のものを連続して並べる
こういうこと
実装が隠蔽されていればそういう最適化の自動化が可能だという
>>393に対して、
それはそうだが絵に描いた餅過ぎると否定的なことを言ったのが
>>396 以上
ヒープの話から来てるからあくまでメモリアロケートした単位での最適化と考えるべきでしょ
話を拡大解釈して通じてないのはお前だと思う
>>401 393をそう読むのなら話通じないな
別にお前が無違ってると主張する気は無いよ
思想と言論の自由は認めるから黙れとも言わないし
あ、いや俺が間違ってる気がしてきた
コンパクションで並べるとかいう話か
それでもやっぱり
>>396 ＞「c/c++では有能なプログラマがちゃんと判断して書くから最適な結果が得られる可能性が高い」
＞という言説の方がまだ現実的
だと思う
で、有能なC++プログラマはヒープの断片化をどうやって回避するの？
一般的な回避策としてはまとめて静的に確保するわけだけど、それだとRAII的な方法論を否定してることになるよね
生ポインタをprivateメンバーにすれば再配置できるんだろ
そもそもRAIIを肯定するのも否定するのもC++プログラマの自由だ
この自由を尊重すれば、極めて大きな最適化の自由度はC++にもあるんじゃないか
自由を奪ったら最適化の自由度もなくなるのは当たり前だ
C++は何も縛らないからなんでも出来る理論本当に嫌い
縛ったほうが最適化の自由度は上がる
C/C++はポインタのせいで配列アクセスの並列化がやりづらいのは有名な話だ
>>407 じゃあ逆の理論はなんなの
一長一短理論
どっちもどっち理論かね
GCは、あるプログラマにとっては仕事を単純にしてくれるが、別のプログラマにとっては仕事を複雑にする要因になるという特性があるんだよね
>>411 プログラマに、というよりは作ろうとする対象によってではないかな。
「設定より規約」で複雑な設定を不要にするために規約で縛って単純にすることはある
最適化とは関係ない
>>414 全然違うレイヤでしか評価されない概念だからね
型宣言を省略して単純にした言語はあまり評価されない
だからC++のように複雑な言語がずっと勝ち続ける
言語レベルでは縛りを減らして、ツールもしくはプロジェクト毎の規約で矯正する方が成功してる印象。
Ruby使いはなんでもRails基準で話するから困惑させられるわ。
規約で縛るのと、設定させるのはまた別の次元の話な気がする。
規約で縛った上でさらに明示的に設定させるなんて思想もあるし、
明示的に設定すること、と言う一文すら大きく捉えたら「規約」だと思うんだが。
misra然り、規約で担保される部分も否定はしないけど、
そんなこと考えなくても言語レベルで無茶は出来ないってのは、結構有益だと思うよ。
goが他の言語だと警告で済ますものをコンパイルエラーにしてたりとか。
それはわかる。
ただ「言語レベルで無茶させない」機能を実装するために「言語実装が無茶してる」
っていう本末転倒レベルのコンパイラが増えてる。
何かを実装しやすくする為の機能、とバグを減らすための安全装置としての機能、と分類した時に後者が気に入らんて訳だな。
古いタイプのハカー思想的にはそうだろうね。
まあでも人間にコード書かせてる内は後者を充実させて行くしか無いでしょう。
バグを減らすための機能はコードを書きやすくするための機能でもあって欲しい。Fortranはその辺のバランス感覚が地味に良い
[][][] [[[ ] X_[[[ [] ][ [] ][][[[]
>>420 半分だけはその通り。
ただセキュリティーについても結局は効率や速度を要求されるからって話なんだよ。
安全のためにって効率を落とすようなルールを作っておいて
ノルマは下げないみたいな現場ではセキュリティーホールつくようなハックが流行るってこと。
ルールを厳しくして逆に流出なんてパターンは結局これ。
悪事の限りを尽くしてきたサイコパスが
効率悪化だけは許さない真面目キャラになるのなんでだろう
安全性重視と言えば聞こえはいいが
やってることはWarningをErrorにしてるだけだからな
>>427 明確にエラーなら、それを前提にした最適化ができる
>>425 unsafeなりなんなりあるかと。
効率や速度というのは、安定動作している事が確実に出来てからやっとテーブルに上げることができる話題であって、
それで落ちる効率なんてのは最初からサボってた証拠とみなす方が多いかと思うよ。
ルールを厳しくして結局流出ってのは、また別の尺度かと。
流出したとしても、それは理由もはっきりさせられるし、なによりソフトウエアの瑕疵ではなくて運用の問題の話になってくる。
セキュリティーについての効率化云々とか、半可通だなあとしか言えんわ…
いくらコンパイラが怒らないからと言え、セキュリティーホールを突くようなハックとやらをしてたら流石にコードレビューではねるんじゃね？
どういうコードかイマイチ想像がついてないけど。
インラインアセンブラが禁止されてるからハンドアセンブルしたコードか入ってるconst char[]を無理矢理呼び出すとかかな。
単純にそのプロジェクトで使ってる静的解析が誤認するようにコードを書く事を、静的解析のセキュリティーホールと勘違いしてるのか、
それとも、バッファオーバーランしないようにするにあたって、根本的に長さを指定できる関数を使わずに付け焼き刃でバッファにクソ長い配列使うみたいなコードなのか(でもこれは静的解析で怒られそう)
一体何が、コーディングの上でセキュリティーホールを突くようなハックなんだろう？
ピアレビューがあれば瞬殺されて終わりな気もするし。
>>421 Fortranって現役なんか？聞いたことないが
スパコンでは現役。計算物理屋とかFORTRANしか書けないおっさんも居るしね。
まあ数値計算系のコード書いてる連中なんてgitも知らなかったりするレベルで
超絶的に遅れてるから意見なんて無視していいよ
>>434 現役かと言われたら、現状数値解析以外では老害しか使っとらん感じで口ごもっちゃうけど、そんな状況に反して最新の言語仕様は結構いい。そして老害はFortranの良い仕様は使っとらん
ある意味逆に次世代言語感あると思う
ベンダーがきっちり面倒見てるのも大きいわな。Fortranは。
老害と呼ばれるコードが生き残れるのも、新しいものがサポートされていくのも。
まあ運用の問題と言えばそうだけどね。
実際どこぞのrustコードなんて結局unsafe丸がこみコードになってるって話だよ。
レビュアーがまともならってのもその通りだが
P○zyさんとことか有名どこでもそんなもんですよ。
}]] [[《_["[[]]" 〈[]》》 [][][]0,1》》〈〉 [] } } "B,V,0%%%,*1BVLO,SASA1`}}//%\\0,1\"VL"\
>>440 そのP○zyさんのコードはどこで見れるの？
Fortran現役ってすげーな。
なんか便利な構文あるの？
スペースがなくても構文が認識するって凄いね。何というか分野によって現役だったりするし、web系とか組み込み系とか分野毎に次世代を考えたほうが良いのかも
数値計算の新しいアルゴリズムってあるの？
動画の圧縮とかだったらどんどん新しくなってるけど
アルゴリズムというよりは非プログラマが数学物理をプログラムに落とし込みやすいって所じゃないか？
統計メインの生物系なんかはもうRやPythonに移ってるけど
>>443 まあ、分野についての言及は必要だろうね。
よし、じゃあワシがwebの代表として次世代言語はrustであることをここに宣言しよう
今phpのlaravelしててミドルウェアとかバリデーションとかルーターとかマイグレーションとか
それ自体はフレームワークの機能なんだけど言語仕様としても使えそうなのがチラホラあるけど
こういうの言語に使われることないんかな？
一元論が無理なら八百万って極端すぎる
二刀流くらいがちょうどいい
C++の置き換え言語としてRustには期待している。ただ構文がなんかうっとうしいなあ。
ruby風のラムダは気に入ってるが。
>>445 Numpy相当のベクトル記述が出来るたった一つのコンパイル言語。それがFortran
>>452 確かにあれは書きやすいし速い
GPGPUでの(それをラップしたライブラリでの)行列演算に対するアドバンテージって何かあるのか？
分岐がモリモリ入ってくる場合くらいしか思いつかないが
>>452 現実のFortranプログラミングは大量に宣言したスカラー配列を添字でゴリゴリ回すだけだけどな
行列やベクトルの演算のセマンティクスなんか一切残らん
>>457 すばらしいね。
Cのコードに
__attribute__((optimize("unroll-loops")))
付けると100倍早いけどw
あと、手元の環境で gcc は何故か -O だけunroll付けたのと同様に早くて -O2 以上は遅かった。
バグと言うべきなのかな。
>>453 コンパイラのやる気さえあれば、ライブラリでは不可能な最適化なんていくらでもでできるだろ
実際にやってるかはしらん
乱数生成が遅いってどこかで見たような、Haskell
>>461 それって言語の問題ではなくコンパイラの実装の問題？
それとも言語仕様として計算量の大きい生成アルゴリズムが規定されてたりするんだっけ？
あ、ごめん。ライブラリの乱数生成の関数を呼んだらということかと思ったけど、自分で乱数生成の処理を書いたらということかな。
>>463 ごめん、そこまで詳しくないので、誰か補足を。記憶だと前者だったかな。
>>458 せっかくコンパイラ作ったんだからみたいな貧乏性だな
一方、富豪的プログラマはインタプリタを使う
なんか知らんが定期的にCより速いって話が出てくるな。
高級かつランタイム速度が落ちないってなんかおかしいとか思わないもんなのかな。
高級品だと遅くなるならC++がCより速くなることはないんだろうなあ
フムフム
実際、もしもコードを書く人がコンパイラを書いた人よりも賢いならばCの方が早 速いｗｗ
コンパイラの最適化能力的には今でもFortranが頭ひとつ抜けてるんだっけ
async awaitの存在のお陰でTypeScriptが使いやすさで一歩先言ってる感あるな。
VasualStudioでもサポートしてるんだよね。mac版試してみたい
>>472 どうせバックエンド同じなので、C言語でもpragmaとattribute駆使すればFortranと同じになるはず
rebuildfmで聞いたがswiftは機械学習との親和性を高める方向でラトナーは頑張ってるみたいね。
フォートランはスタックフレームを使わないから早いらしい
>>467 昔々 Java の方が C++ より速いなんて話もあった。
JIT で速くなるとか。
しかしC++だったとしてもややこしい機能を使わずC言語風に作って最適化掛かったらお終いのような気がしてならない。
Javaの場合はいくら局所的に速くなっても、JITそのものにかかる時間だったり
あるいは膨大なロード時間を計測に含めてしまうと台無しだからなあ
もちろん速いとアピールしたいベンチマークではその辺が含まれないようにするし
遅いとアピールしたい場合は
どっちかというとマルチコアを活かした最適化って人間が頑張るしかないんじゃないかな。
だからgoでgoroutineとか、
関数型言語推しになるんでわ
>>481 javaに限らずインタプリタ系も起動時間含めて time で測ってドヤってる Qiita の記事とか消滅して欲しい
>>480 ポインタをintやchar*に変換する自由を利用してFFIのようなものを作れるよ
自由にCを呼び出すことで他言語が速くなる
>>484 なぜその内容で
>>480に安価つけるし
>>485 内容に問題はないので、わからないなら自分で考えるか質問を変えてみてはどうかな
>>484の意図(自由過ぎるポインタにはメリットもあるよ)もわかるし
>>485の反応(最適化の話題から逸れてるだろ)もわかるんだけど
正直
>>486はぞっとするほど怖い。なんだろうこの不気味な感じは
なんやこいつ。
まあええわこのスレには会話通じんやつがおるみたいやし時間の無駄やわ。深く考えんとこ
>>487 >>484からその意図を読み取れるのはすげー行間把握力だと思うわ
>>486が怖いのは同意
「不気味罪という罪はない」とか言われたらゾッとするかもしれないが
そういうことを平気で言う奴は今の世の中にはいっぱいいるな
この感じどうせまた例のADHDやろ。つついてもうたことを後悔してるわ
>>480 はコンパイラの最適化を受けての発言でいわゆるaliasの問題の
ことを言っていると思われる
で
>>484 はコンパイラ関係ないFFIを持ち出してしったかをかます
で
>>485 がもっともなツッコミ
で
>>486 で上から目線で地面見てドやる
→キモイ
まとめてみました
C / C++ はとりあえず OpenMP 相当のものを標準化して実装して欲しいわ
他の言語よりクライアント側で使うこと多いから１つ１つの処理もスケールさせたい
アルゴリズム変える以外に速くする方法なんてのは
結局倉庫番を上手く解くって話にしかならんわ。
なんかgoogle ioでwasmからdom操作できるようになるって話があったらしい。
みんなアルゴリズムよりむしろデータ構造を変えたがる
CのポインタもJSのdomもデータ構造だろう
でもデータ構造を変えるのは速くするのが目的とは言ってないかも
>>457 >On Xeon Thinkpad P50 with Ubuntu, compiled with gcc -O3 this runs about 15.3 ms ― more than 20% slower than haskell!
あんまり関係ないが
3年前のレッツノートRZ4の最下位モデル、
Core M-5Y10 ベースクロック0.8GHz で
Visual Srudio 2017 でコンパイルしたバイナリも
ちょうど 15.3ms だわ
2コア4スレッドのcpuなので openmp で 4並列にしたら5.7ms
>>496 いやメモリやレジスタにデータやコードを載せるタイミングの話なんだが。
「アルゴリズム」はもう少しソフトなレイヤーを指したつもり。
>>501 最適化上手く行けば0.2ｍｓぐらいになると思うで
i5-3550 で 0.08ms
>>498 reactが早くなるってか。
ようやく90年代のクラサバに追いつくなw
GoogleはSUNと同じ愚を犯してるように見える。
wasmのDOM実装は最初からロードマップに入ってる
jsの出番が減るのか最近の仕様は好きなんだけどな。typescriptが直接wasm吐くようになってほしい
>>505 sunはコンテナーをいち早く実現してたり
zfs出したり、先進的な企業だったよな。金が稼げなかったけど。
googleは金があるから問題ない
JavaScriptからwasmへのコンパイルができるようになったら普及は速いんだろうけど、いつになるかなぁ。
そのころにはwasmのエコシステムも十分整備されてそう。
>>507 各種apiのリファレンス実装として続いてくんじゃないかとは思ってる
正直TS→wasmは期待しちゃうよね
rustでwasm吐くとdom操作もメモリ効率が良い感じになるのだろうか。
個人的にはgoで全部できるようになりそうで嬉しい。
meteor.jsというのがあってね。コンセプト的にすごく良かったんだけどエコシステムがいろいろ終わってた。wasmでもう一度復活するかも
Rustでブラウザ本体を書き直す動きがJSの部分にまで広がる
ブラウザを作れない言語には速い遅いという以前の問題がある
>>508 思い出は美化されるね。
不便なコマンド、SysV系転向、長いことジャーナリング無し、ftpのlsがユーザのロケールでパース困難、NFSの進歩の遅さ、etc
罪を数えたらキリが無いよ
>>508 SUNは我田引水に失敗して凋落したのだ。
自社の高価な機器を売るためにメモリーイーターな言語を広めたり、自社の機器以外では性能が発揮できないように互換環境を禁止したり。
Googleは現在我田引水のため色々やってるが、消費者にとっては良いことは何もない。
吉と出るか凶と出るか。
一方、MSは戦場から早々に離脱したので、不戦敗となるのか、勝ちもしないが負けもしないのか。
>>503 dot関数自体の最適化はほぼ完璧に行われています
gcc だと 100 回繰り返してるところを1度で済ます
最適化が起きてるだけでは？
速度もちょうど100倍だし。
そうじゃないと
>i5-3550 で 0.08ms
1G回の積和を0.08msで完了ということは毎秒125Gの積和を実行したことになりますから、
演算性能は125GFlopsメモリ帯域は1000GB/sになる (←あり得ない)
最後の計算間違ってるか
結果はあってるけど10M個の積和を0.08ms、という計算か。
>>519 ああ、確かに。引数変わらないから１００回ループが１回に省略されてるな…
GCのベンチマークって無いのかな
一番速いのはGo言語？
Rustってcと比べて機能てんこ盛りなのに同等の速度で実行できるって何でなの？
別に機能が多いかどうかは関係ない。
速度を出すための設定を細かくできるかどうか。
細かく設定するってことはそれだけ手間がかかるってこと。
整数とポインタの見分けがつかない機械語に比べたらCも機能てんこ盛り
だがCのポインタは参照とスライスとBoxとOptionの見分けがつかない
>>457 のCのコードみたけどぎょれつ演算にブロック化してないからキャッシュミスが
多くなって遅くなってるだけだな。
ハスケルは自動でメモリーの最適化してるからはやいだけだな。
dot product計算するだけのマイクロベンチなんか言語比較として無意味
デタラメ言ってるだけだぞw
このスレの連中はホント騙されやすいな
1次元のリニアなメモリをシーケンシャルに読むだけなのにブロック化とか
ここは物事の真偽もわからない初学者の集まりなんだからデタラメで混乱させるなよ
検証できることはちゃんと検証してから発言しよう
でも検証にはコストがあるからな
お前は嘘つきだと宣戦布告して戦争か裁判をやって勝つまでが検証です
xとy別々の配列じゃなくて
x0y0x1y1x2....のように並べるってことだよ。
そうするとメモリーアクセスが早くなる。
検証もせずに適当に推測するが
>>457のHaskellの方がCより速いというのはループを1回で済ます最適化がされた結果であって、
1ループあたりの実際の速度はCの1/80の速度なのかもね
Haskellが早いと言うかHaskellだと早く出来ることがあるって感じだろ
そりゃそうだろ
言語によって得意な処理は違うし、プログラマの実力によっても変わる
数値計算に限定すればjuliaは手軽に書けて尚且つ実行速度も速かったりする
バカが書いたCのコードより天才が書いたHaskellのコードのほうが(多分)速い
言語の速度だけ比較してあーだこーだ言う前に
各言語に関する詳細な知識とコーディングの実力を身に着けるべし
ドット積のような簡単な計算ならCPUの処理速度が速すぎて
メモリー転送速度がボトルネックになることは明らかだしな。
ハスケルの場合、ランダムな数値をメモリーに記録することなく
オンザフライで計算したのかもしれないな。
バイナリサイズも気になるけど。
と言うか、速い遅いはあんまり簡単に割り切るわけにいかんし、
推測より実測は確かだけど、その前に何を実測してるのか、
大体どれぐらいになるかをもう少し予測したほうがいいと思うんだけどな。
こういう小さい関数単位のベンチは特に。
最新の処理系は両方持ってないから俺出来ないけど、ネイティブコード比べたほうが良いのでは？
gccは(いろんな意味で)信じられない最適化かかってる事あるし。
>>542 HPCならなくはないけど、その場合は手計算で展開して前後の計算も含めたもっと大きなドメインで最適化するわな
単独でdotだけの最適化なんて、自分の息子を気持ちよくする以上の意味はない
>>539 そういう話でしかないからそういう話だという指摘をしたんだろ
ハード的なことは自分はよう知らんが、純粋関数のみで書いたところは、筋の良い関数への置き換えが利いてくれる、てことなのだろう。
知る限りだと、map、fold、filter、zipみたいな基礎的な高階関数と、配列更新はupdate関数を使っとけばその辺が勝手にかかるみたい。
>>457の例は、sumはfoldで、zipWithはzipとmap。
速度ガチ勢は満足しないだろうが、宣言的にやってる割に速度を出したければ、この辺りを気をつけてれば良い印象。
逆に気をつけないと、相当遅い。LazyとStrictも気をつける必要がある。
これはhaskellじゃなくて理系がバカなんだ
文系がhaskellを勉強しても速度のことなんて考えないだろう
>>550 次世代言語と言えば関数型、関数型と言えばHaskell、ホルホルホル。
>>549 理系が馬鹿ってことは文系が頭いいってこと？そんなバカな
先入観は可能を不可能にするって二刀流の人が言ってた
このご時世理系文系なんて言ってるのもどうかと思うがね
>>553 くっさ。流石にそういう返答は求めとらん。性格悪すぎか
理系文系で語る奴にはろくなものがイないはず
ソースは川上
そのろくでなしを討ち取るか逃げ切られるか確定してないソースにはあまり意味がない
>>548 加えて
>>457 には left fold にしとかないと遅いよとある
理由はあまりに明白だからか触れられていないけど
ここはあまり実践に拘る人いないからわりとどうでもいいか
コンパイル時と実行時で語る奴は速いよ
OOPと関数型で語る奴にはろくなものがいない
LazyかStrictかってな。評価戦略も考えてかなならん。
まあ、Haskellも使いこなすには、それなりの背景知識がないとあかんという事だね。
lazyは無限の計算を打ち切る
遅い計算をちょっと速くするだけの最適化とは次元が違う
>>562 これは同意かな。
結局抽象論でドヤるの好きなだけなやつってのは
実測を嫌う傾向にあるから問題を引き起こす。
>>564 初めから無限の計算をしないように書いた方が多くの場合(ずっと)速いのでないかみたいな話だろ
そういう話題だったら初めからそう言えばいいのに
現実的には後出しが便利だから後出ししてる
現実を実測しよう
いや後出しも何も
>>457のブログにlazy遅いよねとか書いてあってそれについて話してるわけだし…
もう少し真剣に考えてもいいんじゃないか？
誰も最適化が完璧に行われてる、の追試しないの？
ghcの最適化結果のバイナリをgdbで眺めるだけでも全然違うと思うが。
俺がやるとおま環でオラつくなとか言われるの目に見えてるから静観してるけどさ。
これ正味のところコンパイラのバックエンドの性能比較にしかなってないし、
その差も最適化オプションの違いと想像できる範囲だもの
うーん、だったら異なる言語の速度比較に説得力を持たせるためには、どんなルールを定めればいいの？
これは反対意見が多いと思うんだけど任意の問題について各々の言語で素直な(読み書きしやすい/一般的な)書き方で解いた際の速度比較が一番だと思ってる
コンパイルオプションレベルでの最適化はアリだと思うけどソースでの最適化なんてほんとにそれするの？っていうのあるし
問題の難度が低すぎるから早押しクイズになってしまう
正解者が1名いるかいないかの難問なら速度はどうでもいいだろ
>>579 いや、そもそもソースを1つに限定しようとするのがダメだと思う
読みやすい(一般的な)コードと最適化を前提としたコードの両方を用意する
そうすれば両方のケースで比較できるようになる
あと、その任意の問題とやらも複数ケース用意する必要があるだろうな…
面倒臭いけどそれがベストだと思う
>バカが書いたCのコードより天才が書いたHaskellのコードのほうが(多分)速い
一方ロシアは天才が書いたCのコードを用意した
>>580 ある種の難問を解きやすいのが関数型言語のウリのはずだし、それはそれで一つの結果じゃない？
それはそれとして
個人的に
>>457の確認をしてみたいのだけど、
どんな main 書けばいいのか誰か教えてくれないか？
ghc -O2 で下記のようなコードをコンパイルすると
一切メモリ使わずレジスタだけで0.1ずつ増加させた数を積和していくからテストにならないし、
10M個の積和を100回実行するところも1回に省略される気しかしない…
https://ideone.com/gjFBNp module Main (main) where
import Prelude hiding (sum, length, zipWith, map)
import System.Environment (getArgs)
import Data.Vector.Unboxed
test :: Data.Vector.Unboxed.Vector Double -> Double
test v = sum $ zipWith (*) v v
main :: IO ()
main = do
(n':_) <- getArgs
let n = read n' :: Int
let v1 = enumFromStepN 0.0 0.1 n
print n
print $ test v1
せっかくだから一応貼っておくと ghc -O2 は上記の sum zipWith をここまで最適化した
_c8Gb:
testq %r14,%r14 // 全て終わったら
jle _c8Gh // ループ終了
_c8Gi:
movsd %xmm1,%xmm0 // m0 <= m1
mulsd %xmm1,%xmm0 // m0 <= m1*m0
addsd %xmm0,%xmm2 // m2 <= m2+m0
addsd _n8GK(%rip),%xmm1 // m1 <= m1+0.1
decq %r14 // 回数カウンタ減らす
jmp _c8Gb // ループ
遅延評価と fusion すごいw
これO(1)じゃなくてO(n)だけど速いのか？
聞くは一時の恥、聞かぬは一生の恥
O(1)になるまで最適化って、それ1/6公式使わないと無理じゃね？
つまり、鳥人間コンテストのような謎のルールで縛られてまともな飛行機作れない状態か
1/6公式使うまで最適化してくれるようなコンパイラあんの？ あったら見て見たいんだけど
visualc の出したコードではループ回数が10の倍数だということを織り込んで
10回分ずつ loop unrolling して端数回を処理するコードは略されてた。
そこまでわかってるならもう全部計算しといて略せよという気がした。
1/6公式使うのは違う計算をして微妙に違う値になるから最適化というより簡略化だな
先に除算を分岐処理しないとオーバーフロー条件変わっちゃうからなぁ
まあ最適化してるってことでコンパイル時に全て計算してしまえば
ランタイム速度はいつだってO(1)だよ。
悪質な反則と正しいハックの違いを
理系の学問では説明できない
コンパイル時に計算可能なのは
>>457で
>>584は実行時の引数使ってるから計算しとくのは無理だな
いつだってO(1)に最適化できる、未来を予測する神のコンパイラがあれば別だけど。
積和しないで公式使うのがよろしくないってのは、
数学や算数の計算と違って丸め誤差のあるコンピュータ言語での
浮動小数点数演算は誤差に関する統一的な挙動、
通常 IEEE 754 に準拠した挙動が期待されるわけで、
式を変形したり変えたりすると丸め誤差の出方が違って結果の値が変わっちゃうから。
もちろん規格を守らなくて良いというオプションはあっても良いわけどけど。
…誰か何か他の話題を
何がどういう理屈で「つまり」なんだってばよ(；￣Д￣）？
Rustは最近impl traitが実装されて使いやすくなった
impl trait は確かに嬉しかった
これでやっとトレイトオブジェクト使わずにイテレータが返せるようになった
rust わかりやすいくらいダメな方向に行ってるな。。
何が理由で「ダメの方向」って言ってるのか分からない
C++の後継としてはRustは限りなく理想に近い言語だと思うが…
JuliaはPythonを殺せない気がする。ボトルネック以外速くてもあんまり意味ないし
py 3.6で標準で型付けできるようになったし
av女優の名前借りたゲス言語なんてオワコンでしょ
型システムだけはJuliaの方が好き。っていうかクラス嫌い
Juliaいらね
数値計算に使う分には記述性はFortranと大差ない
Julia使ってるとコンパイル不要のスクリプト系の強みをjitのプリコンパイルの時間で失ってる気がするんだけど分かる人いない？
>>614 パ……パイプとより柔軟な内包表記があるから……
グラフも出せるし……
>>614 第一級関数がFortranにはないじゃん？
Rustはクラス嫌いなだけでなく第一級関数も嫌う方向に行った
内包表記とかいうそびえ立つ糞
あのガイジ文法が読みやすいってpython作った低学歴はメクラのガイジなのか？
ピリオド.でpropertyをつないでいく何たら記法ってやつ
Rubyのゴルフ好きがよく使うが
あれこそ読みにくい
>>615 Juliaは数時間～数日単位の時間のかかる処理に使うもの
全く問題にならないオーバーヘッド
>>618 なに言ってるんだ？
Rustは普通に第一級関数使えるんだが…
いろんなクレートがクロージャ使いまくってるんだが…
あとクラスを嫌ったのはむしろ正解だろ？
データと操作を一緒にするのは失敗で関連付けるのが正解
つまり、クラスは失敗でRustのimplかGoのレシーバが正解
Haskellの移植だっけか？あっちは分かりやすい。
Pythonic wwなリスト内包表記
もう少しうまくパクればいいのに。
確かに for がネストしてたり if else がネストしてんのに内包表記するのは馬鹿だなと思うわ。
素直に for 文書いて append しろやと。
>>607 後継っつーか、ほぼc++と同じ方向に行ってるだけになってるだろ。
それに意味があるか？
Python の内包表記はややこしいって、Guido 自身が言ってるw
たぶん、a.b.c.d など、Ruby, jQuery みたいに、
Python では、関数型のメソッドチェーンができないからだろ
>>629 GCがないこと以外はほぼ全て真逆の方向に進んでると思うんだが…
Rustほど信頼性に極振りしてる言語なかなかないぞ
アレのどこが同じ方向なんだってばよ？
メソッドチェーン推しのくせにオプショナルチェーンに考えが至らず、多言語の後追いでパクリ導入したが?を識別子にできることとクソ命名習慣が相まり?.が使えず&.となった、もはやまともにパクることすら出来なくなってきた糞ジャップ言語があるらしい。
pythonはもう機械学習の覇権言語として確固たる地位を確立してしまったので、
ITドカタどもが書きやすいと感じるかなんて、最早どうでも良い領域に到達してしまった
機械学習を自分で書ける腕があるなら、既に人が作ってくれたものを捨ててわざわざ一からやるなら別にPython使わなくても良いのよ？
自分のオリジナルのモデルを実装したら、比較検証用に他のモデルも動かす必要あるわけじゃん？
既存のモデルまで全部自前で実装するのはダルいんだわ。
で、既存のモデルはPythonで動かすってなったら、そのまま自分のモデルもPythonで動かせた方がデータの加工やグラフ化なんかを使い回せて便利ってなっちゃう。
でも例えばtensorflow.jsはpythonのtensorflowやkerasのモデルインポート出来るぞ。
こんな風に移行手段提供されるんだったら言語は何でもいいんじゃない？
rustに信頼性？
あの言語で信頼できる書き方できるならc++でもできるほどのプログラマだわ。
機能追加しまくって聳え立つクソになりつつあるって意味で全く同一方向だと思うがね。
>>631 お前がそう思うならそうなんだろう
お前ん中ではな
>>637 まあライブラリ提供側の気分次第やね
提供してくれたら喜んで移行できる
Rustでまともなプログラム書けるならC++でまともにプログラミングできるって点が一番のRustの致命的にゴミな部分な
Rustを使う意味はただのひとつもない
>>641 大きな違いがあるぞ。
C++はまともでないプログラムでもエラーや警告を吐かずにコンパイルできてしまうが、Rustは、少なくともメモリ周りがまともでないかどうかはチェックしてくれる。デバッグや保守を考えたらRustの方がありがたい。
>>643 Sync, Sendのマーカートレイトのおかげでマルチスレッド下のデータ競合もチェックしてくれるぞ
もちろんNull安全も保証してくれる
むしろRustを使わずC++を使う理由の方が「既存資産」以外にはひとつもない
前から気になってたんだけどWindowsのDLLみたいな動的リンク方式のライブラリを作ったり使ったりするのに適した言語って最近のである？
言い方を変えるとバイナリ形式のプラグインやアドオンを作ったり使ったりする言語を探してるんだけど
最近のプラグインやアドオンってスクリプトが主流なんだよね
>>637 それ、Pythonで書いておけば何処でも動くから
Pythonで書こうってのが加速するだけじゃん
js では学習済みのモデルが動くだけなんだから
>>646 ちがうよ。学習も出来るフルセットだよtensorflow.jsは。
たしかに学習済みモデルを動かすだけのライブラリもあったけどね。
そうではないから盛り上がってるんじゃん。
数値計算の次世代言語雑魚すぎィ！
Fortress 復活させろよぉ！
>>645 ネイティブならC++
ネイティブでなくてよければC#がベスト
>>650 やっぱそうなるか
次世代言語への移行はまだまだ先になりそうだ
ありがとう
>>643 そもそもRustでコンパイル通せるならC++で十分ってことへの答えになってないな
そもそもチェック自体も胡散臭い。当てにならん
https://github.com/rust-lang/rust/pull/50966 >>644 Rustみたいな鬼のように複雑な言語使ってコンパイル通せるなら、
C++でバグ出さずに書けるっつってんだろ
コンパイル通せる前提で話すんなや
あんな数年の歴史しかないのにC++に匹敵する
サクラダファミリアに成長できた複雑怪奇な言語コンパイル通すのと
C++でバグなくプログラミングする難易度ほぼ同じなんだから
既存資産の分でC++に軍配あがるだろって単純な話よ
>>653 桜田じゃない。サ「グ」ラダだ、タコ助。
>>653 ああもう煩いな
おれの経験にのみ基づく話なので「それはおまえだけだろ？」
と言われた場合はぐうの音も出ないのであまり書きたくなかったが…
俺はRustを趣味で使い始めて１年半くらいで自分でもRust使いだと名乗れる
くらいには詳しくなったが、それでも未だにコンパイラには時々怒られてる
ただし、コンパイラのエラー情報を見れば何がダメなのか
すぐ理解できるようになったので少し考えれば修正できるようにもなったし
未だに怒られること自体はさほど大きな問題にはなっていない
ただ、始めた頃と比べれば、だいぶ怒られる回数は減ったが完全に無くなりはしなかったし、
今後もずっと俺はRustのコンパイラには時々怒られるような状態のままだと思う
そしてその状態の俺がC++で同じようにコードを書いた場合、
Rustだと時々コンパイラが怒ってくれてた部分をC++は全て無視してバグになってしまう
俺にはRustのコンパイルを(時々怒られつつ)通すことは出来るが
C++でバグを出さないことはできない。だから俺はRustを使う
他のRust使いはどうなんなんだろうな？俺と同じヤツはいないのか？
サクラダファミリアwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
チェリーブロッサムボーイかよwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
だいたいそんなもんじゃない？
今まで静的解析かけてたようなものが、コンパイラに標準実装されたようなもんかと。
無自覚にガバガバのCpp書くよりはよっぽど良いかと。
どっちに対しても言えるけど
そいつ本人の説得力ってのは
そいつのコードを見るまでわかんねえ
口では色々言ってるやつのコードが結局「えｗ」みたいなこともあるし
「えｗ」みたいなコード書いてるやつがそれを恥じて黙るどころか
むしろ誇ってるみたいな態度でどんどん発言をさらにするケースまであり
>>655 どっちかってーとコンパイラやボローチェッカが怒ってくれることは重視してない
言語の仕様とか、クロージャがすっきりかけたりするとことかすこ
C++のクロージャとか哀れで涙出てくるわ
自分のコードを見せなければ正体がバレないというのは楽観的すぎる
他人が書いたものをを正しく読めなかったらすぐバレる
お題ならPythonで十分
Pythonのコードを見せても、型がないとかなんとかケチつけられた場合の保険がRustだろ
お題なしで雑談というか口(くち)プロレスでいいよ
で実際速いの？どんなコード出てるの？とか実践始めるとみんな黙りこんじゃうからw
授業中先生に当てられたくない子供みたいに
>>655 結局、「Rust書けるんならC++も書けるだろ？」って言い分は
俺には全く適用されてないってことが言いたかったんだ
>>658 確かにC++のクロージャは酷いな
そこら辺もRustだと比較的すっきり書けて良いよね
>>664 みんな黙り込むのは質問が意味不明だったり、場にそぐわない質問だったり、質問者に触れたくないというパターンもあるのでそのパターンだけではない
無料で教えてもいいと思える範囲でみんなやってるだろ
課金しないともったいないレベルになったら大抵は黙り込む
ネイティブDLLでプラグインっつったら旧BorlandのBPLはすごく便利だったんだが
DelphiとC++Builderでしか作れないし、今となってはとてもおすすめできない
>>667 それな。少しばかりの優越感に浸るためにノウハウの公開はしないわな。
>>665 Rustのクロージャもどっこいレベルでひどいだろ
FnOnceとFnMutとFnの区別つかねえし、、moveのつくつかないで挙動まったく変わるし
Rustの代表的クソ仕様じゃねえか
少なくとも「C++のクロージャより出来が良い」なんて言えない
そのクソ仕様の後追いみたいなことばっかやってる印象なんだよ。
だいたい静的言語が無理やりクロージャーなんて入れる必要ないのに、
「俺もそれくらいできるから！」みたいなノリで無理くり入れるのが間違ってんだよ。
大人しく継承でオーバーライドしときゃいいんだよ。
カスのワガママに従うからクソが聳え立つ。
>>670 そーなん？
偉そうなこと言っといて実は俺C++あんま知らんのよごめんね
FnOnceとFnMutとFnの使い分けはまぁ毎回俺もぐぐってる
fn main() {
let seq = |mut a| {move || {a += 1; a}};
let mut f = seq(0);
let mut g = seq(100);
println!("{} {} {} {}", f(), f(), g(), g());
}
↑スッキリじゃん？
|| {a += 1; a}
↑この部分は↓こう書けたらなぁと思ったりするけど
|| ++a
一般にAがBよりマシとは、AがBより僅かなりとも優良であることを意味する。
後か先かは関係ない。
先であること自体に莫大なメリットがあることを考慮に入れた上でのなおかつ「マシ」ならその通りだがな
>>674 Goもだけど「継承自体がクソだからやめようぜ」って流れなんだよな
無理矢理クロージャ入れる必要がないには同意
無名関数が使えりゃ足りる
>>670 自分でC++の重大な欠点を言ってる気がするんですが…
自ら「区別がつかない」って言っちゃってるじゃん…
Rustならその3つをコンパイラがきちんと区別を付けて
間違ってたらコンパイルエラーとして教えてくれる
C++だと自分の脳内で区別しないとバグになる
他にもC++はキャプチャリストは自由度が高い分書くのがめんどくさいし
キャプチャしない場合でも[]は省略できない
戻り値の型は推論するくせに引数の型は推論してくれない
一行だろうと{}必須。よって戻り値ある場合はreturnも必須
mutableキーワードも必要に応じて推論してくれない
C++だとあまり使うことはないかもしれないが
例外がスローされる場合はそれも書かないといけない
RustならFnOnceとFnMutとFnの違いは推論されるから書き分ける必要はない
キャプチャする環境の所有権を移動したい場合にのみmoveをつけるだけ
move以外は他言語のクロージャと書き方は全く変わらない
確かに他言語のクロージャより仕様は複雑だが
推論がしっかりと効くから書く側はすっきりと書ける
まあクロージャを書く側ではなくて受けとる側(定義側)は
上記の3つをしっかり区別する必要があるので難しいのは認める
これはGCがない言語である限りは仕方のないこと…
とはいえ、ライブラリ作ろうとしない限りは定義側を書くことはないでしょ
敬称が糞って
ヒューマンクラスを継承したちんさんクラスとまんさんクラスは糞なのか？
>>682 その例えを借りるなら
ちんさんクラスとまんさんクラスを両方継承したふたなりさんクラスを作るときに
戦争が起こる
ちんもまんもクラス外に公開しなければならないインターフェイスだからhas-aだと実装を晒しすぎる
rustがいかに注目されているかよく分かるやりとりだな
is-aは寿命が同じ
has-aは寿命とメモリが断片化する
でもこれは全ての実装において正しいとは言えない
実装非依存のおまじないの方が正しいからis-aとかhas-aとかいうおまじないを使う
なにこれHaskellってコンパイラを入れるためのツール必要なのか
開発環境を管理するツールってことでええんか
>>690 最強の次世代言語C++について話すためだろうが。
>>692 C++が最強なのって、先行であることの諸々のメリットを含めての話？含めずの話？
>>691 Cとかと一緒で複数種類コンパイラがあるからな
>>692 C++2aから次世代？
それともC++2aまで今世代でその次から次世代？
開発環境を管理するツールを管理するツールが無いだけマシ。
>>695 visual studioも c++17完全対応したらしいから17までは現世代でいいかなと。
>>696 nodeやpythonやrubyの悪口はやめるんだ。
CPythonはC言語の環境さえあればなんでもできるしライブラリだけはC言語並みに速い
JavaもHaskellもただコンパイラを作るだけでなく
C言語のライブラリの使用を禁止する大義名分を作れるかどうかが重要になる
制御の反転とか
ドメインモデル貧血症とか
>>697 どうせuniversal initializer周りはバクだらけだろうよ。
>>698 nodeはもはやnpmのが価値がある。
>>700 ハサミで怪我した人はハサミを根絶すれば怪我しなくなると信じてるんだよ。
>>700 インタプリタ＋Cのライブラリ
を使っていい現状でPythonが勝ってるから
使っちゃいけないことにすればコンパイラ言語が勝てる確率が上がる
C+スクリプトが最強ってことね
Haskellもコンパイル出来るスクリプトみたいなもんだし
そういえばc言語にはパッケージ管理ツールってあるの？
>>704 C++ならMSのVcpkgとか？
使ったことないけどマルチプラットフォームらしい
>>704 結構OSと結びついてること多いし、普通はOS全体のパッケージ管理ソフトの
aptとかyumで入れる。
結構OSと結びついてる？？
多い？
普通は？
？？？
>>705 こっちの発言は普通に
>>704へのレスとして正常
>>707 はいはい、じゃあお前はMSのVcpkgってのを使ってろよ。
/usr/libとか.local/libとかにでもほりこんどきゃいいっていう単純なルールだからむしろパッケージマネージャ使うより分かりやすい
ファイルシステムと結びついてる
そのファイルシステムよりも優れたパッケージのデータベースを作れないだろうかと
口先だけの理論を極めたら実験台は最小限で済むのに、口先だけの人をなぜ笑うんだい
自分の成果として世に出すものならともかく、しょうもないことは人に投げれたから投げたほうがいいでしょ
そもそも実験の量を減らせないのかなと思うんだが
必要な実験の量は決まっていてそれ以上減らすのは不可能
という根拠がどこにあるのかなと
あの、どうしようもない仕様のC++が最強なわけがない…
そう言うアンチが使ってるウェブブラウザも99%C++製という
Menlo Park Projectで挫折したビル・ジョイはゴスリンにJavaを作らせたわけですが、結局これも挫折してしまいます。
>>719 C++が向いてる非常に限られた応用分野がアプリケーション・ソフトウェアだという話もある。
（俺の中で）
>>720 Java は復活するよ、OpenJDK 化したのが巧手になるという
Javaはもう無理じゃないのかな。
当初の野心的な設計が何の意味も持たないほど汚されてしまっている。
VPSで計算主体のちょっとしたサービスを作ろうと思うと、Javaじゃ重すぎるので、C++で書き直そうかと思ってる。
Boost.Beastが出たことだしね。
Javaで書くと月3万くらいかかるけど、C++で書き直すだけで1000円で済む。
AWS Lambdaとかうまく使えばJavaのままでもほぼタダで運用できる可能性もあるぞ
アプリケーション・ソフトウェアという言葉に
GUI処理担当という含みがあるなら、
その部分は Android なら Java だし iPhone なら Objective-C という風に
主要なモバイルプラットフォームで C++ は使われていないことを指摘しておく。
もちろんどちらもコア部分は c++ だけど。
アプリケーションを離れてみると
ffmepg などの動画関連のコーデックやフォーマットのライブラリはほぼ全てが c++
ソフトウェアの分野ごとの各種言語のシェアってどんなんなんだろうね
人工知能だと Python なのか
>>728 向いていない言語を使ってるからモバイルはもっさりなのでは。
>>715 つまり面倒なことは自分はやらんと。
「怠惰はエンジニアの美徳」を間違った解釈しとる典型例やな。
モラルハザードは美徳の欠如ではなく合理的行動、の典型例じゃん
スポーツの試合中に起きたことを美徳云々で説明するのはバカ
ただし試合やってないのに24時間戦ってる奴は本物のサイコパス
じゃあ、試合中に無防備の背中にタックルを決め込むのは何？
言語界の生ける神であるHejlsbergは人の扱いが上手いから出世したんやで
どれだけセンスや技術があっても人を使えない奴はくだらないタスクに追われて腐るだけ
>>730 エンジニア関係なくしょうもないことは他人にやらせるのが生存戦略なんだよなあ……
一生しょうもないことやってろ
>>732 どこからどこまでが試合中なのか空気読めない人には難しい
試合を止めたり再開したりするから
>>735 ってなことを言ってると
お前が他人に投げたいしょうもないことを
受け取ってくれる人がいなくなるんだよな
それとももう既にいないからこんなところで愚痴りに来てるのかな？
>>737 ？？？ いるが？
後半もなんか妄想で叩いてきてるし、きしょい奴やな君
パッケージ管理ソフトの使い心地の調査をしょうもないことといって切り捨て、
他人にやらせるとかクソ中のクソだな。
こんな奴が出世するようになってるから日本の技術者は腐るんだろう。
>>739 それ誰の話？ まさか妄想で俺に攻撃してる？
日本の技術者がどうのとか大きな話するのは
自分が恥かくだけだからおやめ
おうちに帰ってカーチャンに聞いてもらってくれ
当スレッドが本になりました。
読みやすい印刷されたペーパーとしてご購入できます。
是非この機会にご検討ください。
>>729 そうやって妄想で現実を否定して何が嬉しいんだよ…
JAVAが遅いなんてずっと言われてるし少なくともその部分は現実だろ
速いから使われてるわけじゃない
Javaは速いだろ
エンプラのサーバーに最適化されすぎてて、一般ピープルが触ると遅く感じるだけだ
最近はコンテナやFaaSの流行によってサーバーサイドにおいても重厚(遅いわけでわない)なスタックが嫌われるようになったから、
これまでのJavaのパフォーマンス特性も時代に合わなくなっているのは確かだけど
JavaはC++より二十倍速いで有名なページが、言及されまくった挙句、Hashはstd::vectorの二十倍速い場合もあるに変わったのを思い出した。
最近はRustもtokioのおかげで上位に食い込むようになってきたぞ
>>750 最近はC#も頑張ってるな
https://www.techempower.com/benchmarks/#section=test&;runid=f62c00e2-070f-4636-90a3-1ba2687271a4&hw=ph&test=plaintext
エラー吐きまくってる恥ずかしいフレームワークが3つともC++だなｗ
ウェブフレームワークだとC++は遅いのか。
不思議なもんだ。
>>750 c++は早くネットワーク関係のライブラリを標準で持てと。
ファイシステムよりプラットフォーム依存少ないだろうから標準になるの早いと思ったんだけどなぁ。
Networking TSはあるけどな。
当面はBoostで凌ぐしかないんじゃないのかな。
VPSだとJavaは使えないからな。
C++だとずいぶん安上がりなので、主流になると助かる。
勘弁してくれ
C++は限られた脳力しか持てない人類には複雑すぎる
Boost.Geometryでグラフィクスを作ればクロスプラットフォームのアプリができるんじゃないのか。
GDIにあったような計算がGeometryに揃っているのを発見したのだが。
>>758 Boost.BeastのFAQにライブラリの部品として使われることを意図してると書いてあった。
したがって、利用者側がテンプレートを駆使するスタイルではなく、用途に合ったインターフェースが用意されればいいんじゃないだろか。
C++は、複雑な利用法もできるけど、他の言語のような簡単な利用法もできるので。
ネットワーク関係はsignalに依存する気がする
javaはどうやってsignal依存を誤魔化してるの
>>750 プレインテキストのランキングの方がピュアじゃない
Boostって何をブーストするの？コンパイル時間？
c#最近実運用してるけど割と良いと思えてきた。
バランスがだんだん良くなってきたと思う。
半分腐ってるクラスをcoreで捨ててったからかな。
>>764 プログラミングを加速させるんじゃないかな。
次世代のステージへ。
>>767 いや、C++は深みにはまるとRustの方がはるかに簡単だったなと思いだす
分かりやすいと主張する側に分かりやすさを説明する義務がある
>>771 では、お願い致します
767デフォルトの名無しさん2018/05/28(月) 20:34:02.65ID:PHGZrKV/
>>768 >>758 Rustよりは分かりやすい
それは、わかりやすくない、わかりにくいと主張する側に説明責任があるとも言えるのでは？
わかりにくさの説明義務を放棄して「いや、わかりにくい。わかりやすいと言うならわかりやすい要素を挙げろ」というのは、ちょっと無責任だと思うが。
それじゃやってる事同じだよね。
プログラミング言語Rust 第四版が無いからわかりにくい。
c++はオーバーロードの優先順位、値を返す時のコンストラクタの省略ルール、
テンプレートのマッチング、エラーなどこの辺がわかりにくい、てか覚える気にならん。
C++はキャストの種類が多すぎてどれ使うべきなのかよく分からんくなるとか
マクロの各要素に括弧つけるの忘れて演算子の優先順位が狂って
そのことに気付くのに半日くらいかかったとか
インクルードガードなるものを知らなくて2重インクルードしてて困ったとか
他にも、C++は数え上げていくときりがないくらい落とし穴がいっぱいある
使い慣れてるヤツはそんなところで間違えないから問題ないのかもしれないけど
慣れてないヤツからすると上みたいな比較的簡単な部分でさえ落とし穴が多くて
そこにテンプレートとかが加わってくると「こんなもん使えるかよ」ってなる
Rustなら変なコード書けば大抵コンパイルエラーになるんで安心
逆にC++のほうが簡単って言ってるやつらは
Rustの何が難しくてC++の何がRustより簡単だと思ってるわけ？
>>777 ＞C++はキャストの種類が多すぎてどれ使うべきなのかよく分からんくなるとか
あれは、たしかに意味がよくわからないところがありますね…
＞マクロの各要素に括弧つけるの忘れて演算子の優先順位が狂って
C の時代からのバッドノウハウ…というか、もうマクロは書かないほうがいい…
＞インクルードガードなるものを知らなくて2重インクルードしてて困ったとか
別に二重インクルードしても「ほとんど」問題ないとは思うのですが…
あんなにC++マニアだったのにC++のちょっと良くない部分も見えて来始めた感じ？
二重インクルードしても問題ないとか言ってるくらいだから使ったことないだろ。
>>782 C/C++にて二重インクルードするとどんな問題が発生するのでしょうか？
C++は低級言語なんだよ
何でもありの世界で適切に振る舞うには野蛮であらねばならない
しかしそれは知的であることと矛盾しない
>>786 Rustも低級言語なんだよ
低級言語であるために常に野蛮である必要性はない
時に野蛮になれればいいだけだ
C++は言語オタクの遊び道具に成り果ててるイメージ
しかも言語理論もへったくれもない増改築を繰り返した温泉旅館のごとき醜悪さ
template特にSFINAEとかconstexprとかいきあたりばったりじゃん
しかもそういう複雑なメタプログラミングの仕様を規定してるくせに、
そのデバッグ手法はアウトオブスコープっていうのが超無責任だと感じる
最近になってようやくD言語のbetterCモードが使い物になるようになった、らしい
gc無し例外無しクラス無し、ランタイムはC言語のものだけを使うモード
D言語のC言語から微妙に改善された構文とメタプログラミング機能はそのまま使えるということで
顧客が本当に必要だったもの感ある
>>788 そんなとこだな。あいつらはデバッグなんてしないし考えもしない。
ただrustもそんなc++の暗黒面を後追いしつつある。
今後Rustがどうなるかを知っているのがC++だというなら
C++は遊び道具などではなく未来予知の道具だ
その考えが遊び道具だってんの
仕事でC++使っていわゆるプロダクトレベルのソフトウェアを作ってる身になってほしい
>>788 増改築を繰り返した温泉旅館のようって例え至るところで聞くな。
温泉旅館だけど風評被害で訴えるぞ！
>>792 人にものを頼むときには金を払え
プロダクトレベルってそういうことだろ
c++やめてrustでfirefox作ってるんなら
rustはbetter c++なんだろ？
それはいい
>>794 標準化やってる連中が言いそうなセリフだ
で、先週くらいからずっとRust勢はC++より優れてる点を挙げているのに
Rustアンチの奴等はそれに反論する訳じゃなくてほとんど無視して
RustはC++と変わらないって言ってるだけじゃなんの説得力もないんだけど…
>>655とか,
>>675,
>>681,
>>776,
>>777に対するマトモな反論はないの？
RustとC++は同じではないが対立しないだろう
どちらかが嘘をついているとか偏差値の差が10以上とか原因がなければ対立は起きない
>>797 だってまったく「優れてる」って根拠になってねーもん
個人の感想だったり、なんだかんだ言いつつC++側が決して手放しで優位でないって認めてたり
仕様の複雑さはC++が分かりにくいのは前提の上で、Rustの方が分かりやすいとは誰も言ってないよね
Rust使ってて客観的に生産性上がったってデータ、当のブラウザをRustで書いたmozillaからすら出てねえのに
>>798 当のRust信者が「RustはC++の後継！」とか言わなきゃ住み分けできると思うぞ
>>799 個人の感想しかないに決まってるだろ
分かりやすいだの生産性だのをどうやってデータで出すんだよ
分かりやすさなんて数値化できないし
生産性も行数ぐらいでしか数値化できない
そしたら次は行数なんかで生産性が測れるかよってなる
それとも君は誰もが納得できる計測方法を知っているとでも？
確かにRustの方が分かりやすいとは言ってないが
C++の方が分かりにくいとは言ってるよね
それって相対的にRustの方が分かりやすいってことだよね
>>800 RustがC++の後継になれるかどうかはともかく目指してるのは事実だからな
ていうかどうやって住み分けるの？
個人的にはC++の資産を今さら捨てるわけにはいかないって理由ぐらいしか
使い分ける理由が存在しないと思ってるんだが…
それって現実的な妥協案ではあっても住み分けではないよね
JavaやRustが優れているというのに、JavaやRustで書かれたアプリがユーザーに全く受け入れられないのは、呪いがかかっているからだろう。
rustは良いと思う
web開発では使いたくないけど
結局、書く手間の割に対して安全でもないってことだろ。
そこまでクリティカルなプログラムの場合、他の部分で十分テストするし、
言語レベルでなくてそちらの要素のが安全面に関しては影響がでかいっいう当たり前のことに
まともな奴らは気付き始めてる。
>>805 それJavaScriptとTypeScriptを比較しても同じこと言えるの？
小中規模ならtsいらないよflow使って最後外すくらいで十分。
えー俺はjsの入門者こそtsやるべきだと思う。つーかjsがtsになれ
tsはソースの見た目が美しい
C系シンタックスの最高到達点だと思う
あーでもflowはjsなんだっけ？
コメントで型情報追加するとか？
コメント使うのは最初の一行だけ。シバンみたいに。
あとは後置で普通に型書けるよ。
導入・取り外しが簡単。あくまでjs。
tsはよくも悪くも別言語だねありゃ。
>>813 取り外すってでも型情報ついてるんだよね。どうやってjsコードとして維持してるの？
tsはジェネリクスができることが増えて変態化してるのがいや。
エラーがわかる気がしない。flowはどうなん？
TSはそっち行っちゃったかー感半端無い。
JSはもっと関数的な記法に進化出来たのにAlgol系じゃなあ…
DartがショボすぎたのとCoffeeの失速が致命的だった。
>>814 flow-remove-typesってコマンドで外すんだよ
バベラせるだけだから、flow-remove-typesせんでええやろ
生でJSとやるのはもうリスク高すぎ
ここまで真の次世代言語Ponyの話題なし
最近バージョン上がったのに
>>819 ちらっとチュートリアル読んでるけど良さそうじゃん！シンタックスも奇形じゃないし。何で話題にならんの？
>>821 バックに企業がついてないのが1つ
日本語の情報がほぼないのが1つ
まだ1.0になってないのが1つ
安全性ならRustが先行、カジュアルな並列ならGoが先行してるのが1つ
キラープロダクトがないのが1つ
……多いな
安全性の理論自体は論文ベースだし
文法はまともだし
分かりやすいアクターモデルだしGC系言語だしで
次世代感は高いはずなんだがなあ
これ気に入ったわ。流行らんくても趣味で遊んでみるわｗ
goって並列用言語なの？
それ以外の用途では微妙っぽいけど
ググラビリティ低い名前つけんなっていつも思うわ
何がポニーだワイの馬並みぶち込むぞカス
ponyいい感じに見えるわ
違うそうじゃない的改良しないで頑張ってほしい
まあ最近の言語は～～langってぐぐればだいたい出てくるからそこまで困りはしないが
>>818 これだったら別にtsと変わらんの違います？
Haskellが影響を与えた言語の連なりに "cat" てのあるってのを見知って
"cat language" でググったら
「お家の猫ちゃんと楽しく会話する方法」ばっかりヒットして血圧急上昇でした
nimには次世代感感じないのにponyには感じるのはなぜだろう
正直
>>835はぞっとするほど怖い。なんだろうこの不気味な感じは
>>835 存在しないものをかぎ分ける嗅覚の持ち主のようだ
nimはこうなんというか「ここが今までと違う！」ってセールスポイントが見えない気がするんだよな
D言語っぽい感じ
開発者シェアという意味ならJavaがとっくに超えてる
>>825 並列っつーかサーバ用だな。
待ち受けてスレッド回すっつー書き方に特化してる。
>>842 意外とバッチ処理にも向いてる
特にある程度量のデータを右から左にデータ加工しながら投げたいみたいな用途
nimはまあ、ぼくのつくりなおしたさいきょうのDelphiみたいなもんだから……
構文木を扱うタイプのマクロは新しいかは別にして珍しくはある
>>843 結局何でも向いてるよな。カジュアルに使える
ライブラリ書くのには圧倒的に向かないけどな
貶す意味でなく、よくも悪くも土方のための言語
しかし世の中でプログラムが必要な分野の多くは土方だからこそ流行ってる
日本生まれのクソ言語Ruby『最も嫌われているプログラミング言語』堂々ランクイン！！
https://japan.zdnet.com/article/35109803/ おめでとうクソ言語！🎊
おめでとう日本の恥！！ｗｗｗ
![次世代言語10[Rust Swift TypeScript Dart] ->画像>3枚](https://japan.zdnet.com/storage/2017/11/02/e28392adae17a191547db083133339eb/171106-zdnet-1-01-languages-1-900x675.png)
>>848 こんどRubyistボコすときこれ使うわサンキュー
>>848 Rubyも含め、一時的に流行して廃れた負債言語が上位にランクインしてるな
言語そのものが糞というのももちろんあるけど、それ以上に、
終わってる言語で自分のキャリア上無価値と知りながらも負債をメンテするために触らざるを得ないのは辛いものがあるよね
他のグラフ見ると、RubyとRoRは同様に嫌われてるけど、
c#とLinqやUnity比べるとLinqやらUnityは嫌われてないとか、そこそこ面白いな。
多分ホントに負の遺産を負のままにしてきたツケだろ。
Rubyだって記法と実行速度と互換性がクソなくらいで他はそんなに悪くないだろ
あと信者がうざったいくらいで
記法も互換性も実行速度もクソってもはやライブラリしか残ってないやん
>>852 C#はWindows開発という最低最悪のイメージとセットなのにこの程度なのは相当な高評価だね
>>855 まあRoRだけで生き延びてきたような言語だからな
RubyがオワコンってよりはRoRがオワコンってことだな
Rubyは元から始まってすらいなかった
RoRが流行ったのは事実だしそれでRubyがひろがったのも確か
でもいまはDjangoなりなんなりもっと書きやすくて読みやすい言語があるわけだ
単純に疑問なんだが
昼間っから5chにカキコんでるような連中が
どんな根拠をもってある言語を叩いてるのか不思議だわ
誰かが作ってくれた言語をただ使うだけのユーザが
記法がどうの言えたもんだよな
オカンのタダ飯を批判するがごとく
勝手に作り上げた人物像を非難して
批判を潰そうとする方がよっぽど害悪じゃね
妄想癖の権威主義って感じ
Rubyは確かにオワコンっぽいけど、なんでダメだったんだろう？
Pythonが良くてRubyがダメな理由が分からん
numpy対抗のライブラリが弱くて研究者の歓心を引けなかった
いろんなソース見るとRubyは記法が人によってバラバラという印象はある
Pythonも無いわけではないけど
完全にイメージなのだが, RubyにはPerlと同じ臭いを感じる
Pythonは割と遠い感じ
悪い意味で自由な文法だからな。
書きやすいが読みにくい。
だからこそ設定より規約みたいな概念を「わざわざもう一回言ってまで」徹底しないと、
保守性最悪の動かさないとよくわからない、担当が辞めたら誰も保守できない逸品に仕上がる。
さらにグダグダして、Objectの親クラス足した時点で言語として終わったと思ってる。
なんでmethod_missingの解決にそういう事したのか全くわからん。常識的に考えて破壊的変更を甘んじて受け入れて対応するだろ。
破壊的変更されると規約で決めた決めごとでしかないから破綻するとかどんな戯言なんだと思ってたらその主張が通るとか意味不明じゃん。
それで純オブジェクト指向とか抜かしてたのにスーパークラス作るとか頭湧いてる。
うざったくて無能な信者とか煮ても焼いても役に立たん。
確かBasicObject継承したクラスで定数宣言しても理屈としてはわかるがビミョーに納得のいかん結果になったと思う。
まだc#の拡張メソッドでコンパイル出来なくて悩む方がマシ。
業務とかである程度使われちゃうと
好きじゃないのに使わなきゃいけない人が
増えてヘイトが溜まるのでは
>>856 じゃあ他に何を使ってアプリ開発を？と考えると c# いいよね！となる
矛盾してなくないか？
選んだ結果c#なのと、嫌々c#を使うのは別かと。
.net上だし、どのプロジェクトも
VB.net使って協力会社増やそう→爆死
中身はcppのdllでガワだけc#→爆死
と、みんな何度か死んできただけだと思う。
delphiがすごく嫌われる程度に選択肢自体はあるんだし。
なるほど
でアプリ開発分野での嫌々使わされてる系が Delphi と Obj-C、と。
2ちゃんブラウザの Jane も Delphi だっけ
delphiと言うかpascalが好きな人は未だに一定数居るからな。
そういうプロジェクトにつっこまれて、二度とこんな他の役に立たん言語はやりたくないと思ってプロジェクト抜けた人が積み重なったんだと思うよ。
vbaのマクロを一度でも「業務として」保守させられた人みたいな感じで。
windows版とlinux版のどっちかを手抜きするやつは危ない
実装できないくせに仕様だけ意識高い系
pythonも言語自体はクソだし、速度もおっそいし
ただただライブラリによって流行ってる
将来的にrubyと同じ命運をたどるのは間違いない
altjsのように言語仕様を変えるのは素人でもできる
jsが流行ってるのは実装によって流行ってる
pythonも同じ
>>880 Pythonもいずれそうなるというが、言語として出てきたのはRubyの方が後な訳で
それならPythonの方が先に死んでるよね？って話
まあ生き残ってる言語のが少ないんだから死ぬ言っとけばだいたい当たる。
>>881 原因が同じだからって時間も同じとは限らないだろ？
アホなのか？
まあ、本当に原因が同じかどうかも分からないが…
>>881 先に生まれた言語から死ぬルールってなに？
よくわからん
rubyがオワコンであること自体には異論が出ないって
大分雰囲気が変わって来た感じがするな
ドカタと関係ない世界で使われるようになった言語は長生きするから
残念ながらpythonは当分死なないよ
webドカタ専用言語だったrubyと違ってね
一方のんきなRubyistは今日もRubyKaigiとかいう身内オナニーで
他言語をdisっていた
matzが他言語disるから取り巻きも同じ事やるんだよな……
もうお前らがdisられる側だってのに
rubyは関数の取り回しがキチガイ仕様過ぎる
あとシンタックスな、行き当たりばったりで実装できたものから突っ込んでくなよ。計画性と言うものはないのか。
python は numpy が無ければ perl,ruby と同様非互換バージョン(2 -> 3)の断絶を超えられ無かったと思うよ。
numpyのおかげでアカデミックで生き残った所からの挽回かと
Rubyは2008年のComplex/ComplexFloatの議論のときも
「スクリプト言語で数値計算なんてやるわけない」って頭ごなしに
数値計算で便利な改善を蹴ったりするような文化だったし、
Rubyにnumpy相当が育たなかったのは偶然じゃないよ
わざわざ開発者がアンチスレに降臨して意思表明してたくらいだし
http://2chb.net/r/tech/1207233348/134 まあそう思ったのは普通な気もするけどね。
逆に python みたいにめちゃくちゃ遅くても c の呼び出し滑らかにしとけば
数値計算もいけるって感覚がどれくらい正当なのかは未知数だったと思う。
Ruby開発者がイメージする数値計算と実際のニーズとの間にズレがあったんだよ
Rubyコミュニティに代表されるように、目的よりもプログラミング技術そのものに拘る連中の間には、
処理の粒度を粗くするのをダサいと考える文化が根強く存在してて、
巨大バッチ処理において処理の粒度をとにかく粗くすればスクリプトの遅さは問題にならない、っていうnumpy的な方向性は関心を持たれにくかった
Rubyを数値計算に使えるようにたいとか吹いてた時期もあったけど、その頃もJITとか明後日の方向を向いててどうしようもないほどにズレてた
私たちみたいに賢い人たちはrubyなんか採用してないんだからどうでもよくない？
RubyはクラスベースではないOOPをdisって戦利品を得ていた気がする
戦利品が枯渇したら終わり
TypeScriptとSwiftは静的型ではないOOPをdisってる
typescriptというかaltjsに関しては、最初から
jsが進化するor WASM等の別物が流行るまでの期間限定なのは
開発者自身も織り込み済みでやってる気がするんだ
C++の演算子オーバーロードがdisられた時期もあった
disってたのはRubyだけではないし、数値計算に使えないイメージもRubyだけではない
>>898 それはiostreamの<<,>>とかstringの+のような流用の話で演算子オーバーロード全般じゃないだろ
まあ最近でもpathの/みたいにやらかしてるけどさ
他と比較して配列が扱いづらい云々ならともかく、C++単独で数値計算が苦手なイメージなんて最初から無い
wasmでjs以外の言語って流行るのかね
バイナリサイズ大きくなってappletやFLASHみたいに読み込みに時間がかかるサイト量産されそう
wasmかわいいよwasm
一応JSよりサイズが小さくなることを売りにしてるから多分大丈夫
と思ったけどコンパイル時間がどんくらいになるんかな
wasmといえば、Goももうちょいで対応しそうだし、c#だとblazorみたいな面白い荒業が出てきてたり、結構面白いよな。
最初から(たいてい他言語で書かれてる)共有ライブラリ使わない静的リンクでのクロスコンパイルが得意とか、
他言語呼び出さなくてもフレームワークにだいたい道具が揃ってて、かつ生きてるOSSのVMがあるとか、色々好条件が揃ってたんだろうけど。
blazorはwasmで書かれたVMだけだから、フレームワークやライブラリのデッドコードエリミネーションをどれだけ積極的にやるか次第だし、
Goもgithubのcommit見てる感じ今までのコンパイルとさほど速度変わらなさそうで、
emscriptenよりは少し気軽な気持ちでgo buildとかmsbuild叩けるんじゃないかな。
ruby亡き後、rubyがここまで嫌われる原因となった人格破綻者ruby信者たちに新たに担がれる可哀想な言語は何？
Delphi信者だって全部C#に行ったわけでもなく結構バラバラになったしコアな連中は未だにしがみついてるしで
rubyだってこれといった移行先なんてないでしょ
Scalaに行った連中は路頭に迷っちゃった
Elixirも期待されたけど結局泣かず飛ばず
Ruby難民達の未来は厳しい
とりあえず、まつもとゆきひろがキモいのをどうにかしてくれ。話はそれからだ。
俺、Ruby作れる気がしないからまつもとひろゆき凄いと思うんだけど、おまえらそうでもないの？
終わった過去の言語の話をするのでなく、これからのことを話すべきなのではないか？
Ruby嫌いじゃないよ
なんらかのニッチを埋めて衰退するのは寧ろ立派であるとすら思う
C++の14～の機能を未だに覚えられない。
というか使わない
覚えられたら便利なんだろうけど
autoを使うだけでEigenがよく分からないことになって辛い
>>916 ジェネリックラムダだけでも11より14以降使いたい理由になたよ。
>>848 型無し糞言語は全て死ねということだな
歴史がきちんと証明した
妥当だし、すばらしいことだな
プログラミング言語って大半が機能過多になって廃れるよね
言語自体がプログラミングのアンチパターンを踏襲している
rubyってクソ言語かな。
swiftの言語仕様毎年変更に比べれば全然良い
>>919 javascript や bash の順位
未だに型推論すら入らない糞オブザ糞、いわゆるSHIT
あの糞ウンコゴミ屑死ね死ねナンバーワン永世ドベのピチ糞PHPoorですら
ようやく型が書けるようになったというのに
（だからといってあの糞には2度と近付かないが）
>>922 JSにはFlow/TSがある
bashは小規模ではしょうがない
サバサイド言語で型を書かない意味がわからない
バカなのか？
すまん、自明だったな
型無し糞言語はバカ、型無し池沼イット土方はバカ
いますぐ死んでほしいよな、ほんと
これが総意
>>923 まだイマイチ。コンテナ内の型決めれないし
>>924 typescript は typescript で項目があるけど
>>919 ＞型無し糞言語は全て死ねということだな
適当に反論して「全て」と言ったの無しにしようとしてるだろw
そう言うことせずに間違いを指摘されたら撤回して訂正しようよ面倒な奴だな
あとtsはコンパイルが終わると型情報捨てられるの辛い。動的な型検査で外部から流入してくるjsonとか処理したいなぁ
>>925 自省して「全て」を消したようなので許してやろう
型推論は型あり言語だぞ？
型無し糞言語は死ねは撤回しない
やや例外かもしれんがPHPも死ね
あ、ちゃんとbashも死んだ方がいいと思ってるぞ
目の前にいたら包丁で微塵切りにしてやりたいわ
>>920 C#はC++に迫ろうかというくらいに複雑化したけど破綻も廃れもしてないよ
一方Kotlinは多言語をパクり終えて独自の機能を入れだしてからヤバい臭いがしてきた
期待したけど第二のScalaだわこれ
>>928 実行時型情報が捨てられるのはしょうがないとしても、型定義からTypeGuard Functionを生成
できるような機能があったらいいのにねぇ。
inteface定義したらいっしょにTypeGuard Function書くのがルーチンになってしまった。
動的型チェックはPHPみたいになるからマジで止めとけ
静的チェックが安全性とコストのバランスが最良
>>934 自動で書いてほしいって話だから別にphpになるわけではない。考えられるのはtsのコードパースしてtsのコードから自動生成かね。
とょっと面白そうな題材に感じた。試してみる！
jsonschemaを吐き出してくれるnpmモジュールはあったりするんだよね。
それを使ってvalidateすればいちいちコード本体を書く必要はなくなるんだろうけど、
今のところはまだ自分で書いた方がお手軽なんでそうしてる。
未だにPHPがどうのこうの言ってる連中がいて驚く
とっくの昔にクソ言語確定しただろ
次世代言語スレで口にするのも汚らわしい
動的型には厳しいことを言うくせに
Rustを教えてやったら難しすぎると弱音を吐く奴がいる
他人に厳しく自分に甘いクズだ
>>911 俺も書けないしクソゴミレベルを自覚してるが
ここの人らは違うんだろうな
書けるし書いてきたんだろうな
日本を代表するようなプログラミング言語を
うわっ…ruby信者が気持ち悪いイジケかたしてきた。
簡単な機能を難しく書くことに意味はないっていう当たり前のことを
まず言わなきゃならんかな。
もとからこのPHPに拘るやつおかしいと思ってたけど、bash切り捨てるとか頭おかしすぎるだろ。
問題領域違いすぎるとは思わんのかな？
カッターナイフ持って「これじゃ戦争できない」と言ってるレベルだろ。
>>932 一旦破綻しかけたから色々捨てた、が正しいかな。c#は。
C#って何か捨てたん？
増築増築ってイメージだけど
>>945 .net coreと.net standardとかで、このレベルが(新しい)標準のAPIな！って仕切り直して、
その標準を満たす形で各実装を進めてる感じ。
割と細かい範囲まで、mscorelibから抜けてる。
>>920 これ
ある程度いったらバグ取りだけでいいよ
>>943 bashは必要悪
PHPはただの悪
bashの代わりはないが
PHPを選ぶヤツはセンスがない、技術力がない
こんな簡単なこともわからんのかね？ん？
bashがどーしても必要な状況はわかる
PHPがどーしても必要な状況って何さ（失笑）
PHPがどーしても必要な状況ってさ
みずほも泣いて逃げ出すレベルの、ホイ卒日雇いゲェジが残業200時間で運用するクッッッソレガシーのゴミみたいな環境のことだろ？
ま、好きにするといいんじゃないかな
俺、そんな底辺と関わり合うこと二度とないしｗ
>>949 bashの代わりもあるぞ。
「PHPを選ぶやつはセンスがない、技術力がない」と言うやつも充分センス無いんじゃねえの？
PHPを讃えてるわけではなくて、言語として酷いのは分かってて言ってるけど。
必要悪になる前に、何でも「善」→「当たり前」→「ただの悪」と推移するもんなんだから、
他のなにかに対して必要悪と言う存在を認めてしまってる状態で、ただの悪を断ずることは出来んよ。
もし順番なら次スレ誰かよろしく。
>>950 ではそのPHPではない言語がどーしても必要で、PHPではいけないときって何さ？というと、ただの感情論でしかないと気づくよ。
ガイジとやらを集めることは簡単なんだから。
発注側としては、正直、動いてて保守されればどんな言語で書かれてようが知ったこっちゃない。
>>947 .NET Standardのリリース方針が決まってないから、今またfast Spanのせいでバタバタしてるよね
やっぱどの言語も増築の誘惑は大きいのかね。
バカユーザーの声なんて無視すりゃいいのにって気がするんだが。
パターンマッチを後から入れようとしてる言語は大体残念な出来だな
初期設計重要
Juliaのパターンマッチも残念な感じだけど
あれもうちょっとなんとかなるんだろうか
マクロの限界を感じる出来やね。Jeff次第なんかなあ？あれ
>>951 bashの代わりって何？
ちょっとしたサーバ内での作業を自動化するのに
いっつもbashの引数を受け取るときは・・・for文は・・・リストは・・・
と調べててめっちゃ作業効率悪いんだわ
あるんならマジで教えてたもれ
アプリ内でのチャット機能ってunityとかじゃできないよね？
どの言語できる人呼べば良いのか教えてください。
>>962 AWSでインフラ作れてコードも書ける人
言語はどうでもいい
>>960 実装方法に選択権あるならどの言語でもいい要件やん
自分が一番書きやすいの使いなはれ
# VB？あ、ごめんなさい…
普段からシェルで生活している人間だと自動化の見通しがすぐできるからいいのよ
シェル触ったことない人がシェルスクリプト書こうとするのが間違いだと思うよ
アプリゲームの課金システムもゲームシステムとは別分野だと思うけどそれもAWSでできるの？
次世代シェルスクリプト
fish
ユーザーフレンドリーを謳うシェル。サブシェルを使わないなどの他には見られない特徴がある。
xonsh
Python とシェルスクリプトのアクロバティックな融合。$(...)でシェルスクリプトを実行、@(...)でPythonを実行。
Xiki
ウィキの能力を取り入れた。斬新だったが開発は頓挫してしまったか。
他には、実験的な試作だったようだが qsh なるシェルが面白かった。hoo/bar のようにスラッシュが含まれていてもPATHから探してこれる。
>>968 UIとしての(本来の意味での)シェルとシェルスクリプトは区別した方が良いのでは。
fish は前者特化でしょう。
bash は微妙な所でDebianはUIシェルと独立させるためにdashを採用した訳だし。
シェル素人童貞ワイ
シェルにも方言があると知って身が震える
頭のシェバンがbashなやつだけがLinux標準で使えるシェルだと思ってタンゴ
あんな糞みたいな言語仕様に、糞方言を糞上塗りした糞連中がいるとか草々の糞が生い茂りますよ
これもう半分犯罪行為だろ・・・
別にシェルスクリプトで大規模なもの書かないしどうでもいい
bash依存せんと、shとPOSIX標準コマンドでなんとかするほうが良いんじゃねえの？
main関数の引数がどう見てもシェルだよね
他の関数を呼ぶにはheaderを読んだり設定ファイルを書いたり効率悪い
headerが不要なのはUIとしても優秀だよ
pythonでsh発行できるやつってないん？
rmとかmkdirとかOSに指示出すやつはしょうがないにしても
forとかifとか、あのおぞましいほどに汚いsyntaxで書きたくない
sh発行って意味がわからん。普通に子プロセス起動するだけやん
PythonがきれいなSyntax持ってるって、よくわからんな。
どんなスクリプティング言語にも system とかバッククォートとかある事を知らなそうだな…
部品の大きな関数型言語の一種だと思うとさほど難しくはない、と思うよ
データを変数に詰めてそれをいじくり回すんじゃなくて、関数を繋いでやりたいことを実現するようなイメージ
慣れるとバイナリファイルもRDBも邪悪に見えてくる
極まった人間が↓みたいなシステムを作っちゃう
http://www.atmarkit.co.jp/news/200909/07/lltv03.html >>978 機械にとってきれいなSyntaxやで
Pythonは自由文脈のLL(1)で、
某C++のように識別子が型か変数かで構文木自体が違ってきたり
後ろの内容が前に影響を与えたり、何トークンも先読みして巻き戻ってしないといけない
みたいなのが無くてすっきりなんやで
Pythonのsubprocessの使いにくさは異常
subprocess.runがギリギリ及第点くらいで、あとの関数は使いにくすぎるわ
>>969 最近作られたOilシェルの作者が同じことを言ってた。
テキストUIとしてのシェルと言語としてのシェルで分けて考えることができる。
良きインタラクティブシェルを作るためには、ベースの言語がよいものであるべきだと。
x=1 と x = 1 が同じで無いのとか難しい。
http://www.oilshell.org/blog/2018/01/28.html rubyここではボロクソだけど、
railsはあまりにも偉大すぎて、正直代替品は存在しない。
エコシステムがやばい。具体的にはrailsチュートリアルな。
これは一度やってみてほしい。ド素人をエンジニアに育て上げる気概がある。
x.f(y) と (x.f)(y) が同じになる言語だけが石を投げなさい
python だったら
os.system(" cat aho.txt | grep baka" )
とかやれば良い。
pyのリスト糞内包表記が読みやすいとは1nmも思わないが
shの糞糞糞表記よりはマシ
俺はPythonの内包表記が糞とか頭どうかしてると思うけど、個人差あるし、糞と思うなら使わなければ良い
python sample.py >log.txt
やるもよし、
os.system(" cat aho.txt | grep baka >log.txt" )
でもよし。
複数プロセス制御とか考えないならこんなんで十分だろ。
>>986 まだその話してんのかよ。
結論出ただろ。railsしかできない奴が生まれるだけだと。
result = [i * 2 for i in range(10) if i%2==0]
print(result)
val result = (0 to 10).filter(_ % 2 == 0).map(_ * 2)
println(result)
どっちが読みやすい？
>>994 正直俺としては同等やけど、それ言語何？Rust？「 _ 」の使い方めっちゃええやん。JuliaやDでは考えられない記述性。それ出来るんなら内包より良いという意見もわかるわ
変な改行入っちまった
リスト糞包表記は、どう考えても左から右に読めないのが糞
リスト糞糞表記：「何かを2倍する、何かは0から10、と見せかけて偶数」
一方、メソッドチェーンとまともなFPを備えた言語なら
0から10、の内の偶数、を2倍する
どっちが読みやすいですか？？？
>>995 Kotlinに殺されたScalaちゃん
いい言語だったよ、コンパイルが糞ひり出して戻ってきても終わらないくらい糞長い糞だったが
俺のリスト糞糞表糞の読み方が間違ってるだけ？
英語圏の人間なら読みやすいのか？
>>998 先に変数、後で条件という集合論の書き方に似てるやん？
「まずxというのがあって、そのxの条件は……」
って読んでる
つぎ
次世代言語11[Rust Swift TypeScript Dart]
http://2chb.net/r/tech/1528037607/ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 39日 16時間 51分 26秒
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
lud20250407112053caこのスレへの固定リンク： http://5chb.net/r/tech/1524607347/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「次世代言語10[Rust Swift TypeScript Dart] ->画像>3枚 」を見た人も見ています：
・次世代言語9[Haskell Rust Kotlin TypeScript Dart]
・次世代言語22 Go Nim Rust Swift Kotlin TypeScript
・次世代言語25 TypeScript Swift Go Kotlin Rust Nim
・次世代言語議論スレ[Go Rust Scala Haskell]第5世代
・【AI】DeepL、「次世代言語モデル」を実装--翻訳品質で「GPT-4」上回る [すらいむ★]
・次世代言語18 V Julia 他
・【AI】OpenAIの次世代大規模言語モデル「GPT-5」が2024年夏に公開されるとの報道 [すらいむ★]
・【速報】次世代Xbox「Scarlett」はZen2、Navi、GDDR7、カスタムSSDで最高品質の次世代ゲーム機に★3
・Sony Mobile 次世代Xperia 総合167
・Sony Mobile 次世代Xperia 総合176
・Sony Mobile 次世代Xperia 総合172
・Sony Mobile 次世代Xperia 総合201
・Sony Mobile 次世代Xperia 総合193
・Sony Mobile 次世代Xperia 総合223
・Sony Mobile 次世代Xperia 総合205
・【車】ホンダ、AIを持つ次世代スポーツEV「Sports EV Concept」東京モーターショー2017で世界初公開
・Sony Mobile 次世代Xperia 総合209
・Sony Mobile 次世代Xperia 総合230
・Sony Mobile 次世代Xperia 総合186
・Sony Mobile 次世代Xperia 総合148
・Sony Mobile 次世代Xperia 総合218
・Sony Mobile 次世代Xperia 総合165
・Sony Mobile 次世代Xperia 総合228
・【ゴキ悲報】次世代機どっち買う？ Xbox Scarlett「43％」 Playstation 5「39％」
・Sony Mobile 次世代Xperia 総合274
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★11
・Sony Mobile 次世代Xperia 総合255
・Sony Mobile 次世代Xperia 総合246
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★13
・Sony Mobile 次世代Xperia 総合251
・次世代Xperiaはなんと1Gbps通信が可能 0simとの組合せで最強モバイル体験へ
・SONY 次世代Xperia 総合本スレ 287
・Sony Mobile 次世代Xperia 総合251
・Sony Mobile 次世代Xperia 総合156
・Dorico 次世代楽譜作成ソフト Part2
・【Nexusから】次世代Google端末を語るスレ Part15【Pixelへ】
・次世代機専用The Medium開発者「XboxSeriesSのグラが凄すぎて吹っ飛んだよ。」
・Sony Mobile 次世代Xperia 総合126
・Sony Mobile 次世代Xperia 総合254
・Sony Mobile 次世代Xperia 総合270
・【速報】任天堂新型Switch用のVR/AR特許が公開。有名リーカー「次世代SwitchはVRハイブリッドになる」
・Switchの次世代機が出るなら当然名前は「Switch U」だよな…？
・任天堂「Switchはまだサイクルの中盤。次世代機はまだまだ出す予定なし」
・次世代の哲学を育むスレ Part 9
・次世代の哲学を育むスレ Part 15
・【Scorpio】次世代ゲーム機テクノロジースレ 【TegraX2版Switch 】
・【朗報】次世代エース松永里愛、本家本元Buono！を完全に過去にする史上最高の「Independent Girl」を披露してしまうwwwwwwwwwwwwwwwwwww
・次世代ゲーム機テクノロジースレ【Pro/Switch/Scorpio】
・今年、遂に任天堂次世代機「Switch2」が発売ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
・【Pro】【Switch】 次世代ゲーム機テクノロジースレ No.5【Scorpio】
・次世代iPhone Part258
・Xboxの開発者、Project Scorpioは「本格的な次世代機」になると発言
・次世代iPhone Part270
・【ガラホ】次世代フィーチャーフォン総合 Part23
・【燕の次世代エース】原樹理 part8【目指せハーラートップ】
・次世代iPhone Part265
・次世代プレ酒 新規銘柄開拓スレ Part13
・次世代iPhone Part260
・次世代iPhone Part270
・次世代プレ酒 新規銘柄開拓スレ Part7
・次世代iPhone Part250
・次世代iPhone Part271
・次世代セレクトショップ STUDIOUS ステュディオス10
・【軍事】＜エアーウルフ＞ 時速３５０km超 二重反転式ローターの次世代ヘリコプター「S-９７ RAIDER」
・次世代プレ酒 新規銘柄開拓スレ Part10
・次世代iPhone Part265
19:25:11 up 63 days, 20:23, 0 users, load average: 9.97, 9.57, 9.83
in 0.098915100097656 sec
@0.098915100097656@0b7 on 062008
|
ブックマークへ![次世代言語10[Rust Swift TypeScript Dart] ->画像>3枚](http://livedoor.blogimg.jp/theaaee/imgs/1/6/16a32fe2.jpg)