◎正当な理由による書き込みの削除について： 生島英之とみられる方へ:
次世代言語12 Go Rust Swift Kotlin TypeScript ->画像>2枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1530664695/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
スレタイ以外の言語もok
前スレ
次世代言語11[Rust Swift TypeScript Dart]
http://2chb.net/r/tech/1528037607/ スレタイ以外の言語は禁止にするべきじゃないだろか。
前スレではC++が次世代だと言い出すやつまで現れたし。
俺だけどな。
いちおつ
>>2 んなこと言い出したら次スレは俺が立ててFortran入れるぞ
[Fortran COBOL BASIC なでしこ ALGOL]
おまいらはこのスレを古代言語スレにでもするつもりか？
劣化が速い方が古い
ガンダムは古くないが君の名はは古い
Smalltalk|erがしゃしゃり出てくると決まってなにげに荒れるのが笑える
感情的になるバカが常駐しているからなあ
昔よっぽどこっぴどく無知を晒されたのだろうな
かわいそうに
感情の発露は喜んでいいのか恐怖の対象なのか判断が難しいよね。
とはいえ、世界で初めてAIが感情を爆発させたのが5chというのは興味深いよね。
>>12 この予想はどういう発想で生まれたの？理解出来ないんだけど
予測を当てる一番の方法は自分が実現することってやつだな。
rustは案件で採用されづらそうだけど仕事で使ってるやついる？
ツールとかじゃなく製品orサービスとして
TypeScriptを仕事で使ってるけどjs使いからは不評臭い。ライブラリの使い方+tsの使い方を調べるという二重苦が辛いらしい。
辛いのはただの自己責任という発想がある
自己の内部に全ての原因がある
例えば感情
外部に原因なんてないし外の人はみんな良い人だよ
rustやってるやつは
ずっとやっていれば役に立つんだと必死に自分に言い聞かせてる感じだなw
言語なんて開発効率あげるためのものなのにどうかしてる連中だよ。
>>21 それも決めつけだと思うんだけど、
firefoxが一つの指標になるよね。
実質c++ vs rustの代理戦争だよな。
chrome vs firefixは。
そしていまのところはrust負けてる？
役に立ちたいとか勝ちたいとかいう感情が前提なので
前提を崩さないためなら決めつけでも何でもやる感じ
>>19 前に言った通りの状況や、、
書きやすさの為に学習コストがかさんでは本末転倒なんや
これからの新言語はこの問題が常に付きまとう、
C++とHaskellを知ってたらRustの学習コストは低い
ゆえにHaskellが役に立っていると思うかどうかは個人の感情
c++は関係あるがhaskellとrustはそんな関係あるか？
rustの評価順序なんていたって普通だし、return書かないことくらいしか接点ないわ。
C++系でいうオーバーライドとオーバーロードのうち
オーバーライドを極力使わない流儀がRustとHaskell
スレタイから括弧外したのは構わないようだね
こっちのほうが見やすいだろうし文字数稼げるから
追加でNim入れる考えもあったけど、並べると格落ち感出すぎたので保留した
Rust以外は実案件に投入できるやつばかりでつまらない
>>2 >スレタイ以外の言語は禁止にするべきじゃないだろか。
まず次世代言語というのが何を指すか明確に決まってない以上、
実際にスレタイ以外の言語の話はされるだろう
それに多様な意見を交わす総合スレとしての場を阻害しないうえでも、
言語を限定せず、かつそれを明示しておくべきだと思う
スレタイに言語名を入れる意義があるとすれば、検索性というか客寄せでしょう
立てた人の推しが窺えるのも面白いし
ちなみに「スレタイ以外の言語もok」って一文を付け足したのは自分だけど、
本当のところは、自分の独断でスレタイの言語を選んだ負い目を感じたのが発端だよ
>>19 ほとんどがただ隣に型書くか推論任せにするだけだろ
こんな簡単なことがつらいとか
ガイジか池沼か知らんが、保守不能なクソコード撒き散らされる前に殴り殺して窓から投げ捨ててカラスの餌にしてしまえ
Sで始まる信者だけが読みやすいと思ってるクソ言語の話題が出なければ何でも良いよ
>>33 なんだろうな。環境面でなんか動かないって現象起きやすくない？
tsっていうよりバンドラーの問題なのかライブラリの相性問題なのか？
firebaseの最新ライブラリで動かなくなるとか、そういうのがあってひどく混乱する
なんでやSatherなんてこのスレで名前が出たことも無いだろ
PharoとかVisualWorksとかなら話題にしてもいいのかね？
こんな返答アスペでガイジでADHDやん……
気が狂って頭がパーになってるんちゃうか……
この場で解決できないのはこの場にいる人間の責任だな
ここにいない医師のせいにするな
c++はクソだがこれだったらc++使えやと思う内容ですな。。
>>39 Eiffelよりいいかもって思ったことあった。
bindgenってRust公式からはスルーされてるやつじゃなかったっけ
aiプログラミングってなんの言語？
swift学んだけどそっちの方向に行きたいから教えてほしい
愛のプログラミング
つまり、それはLOVE
人類は今、愛を再発明する
AIと言ってもルールベースもあれば最近流行りの機械学習もある
これからの時代はPrologかな(^^)
という感じで前回のAIブームは終わったのであった。
なんか大昔に大学で、急にAIはだめだって本がでてインパクトがあって研究費さがったって聞いた
よくきいたらXOR計算がでいないからだめとかって不条理な理由で
とにかく偉い人がだめって言ってるからだめなんだろうみたいな雰囲気
裏で一部の人間が研究を独占するための陰謀だったにちがいない
常温核融合だって実際は核分裂で核反応起こってたぽいし
世の中むちゃくちゃ
>>61 そういう混沌のなかから新しいものが生まれてくるんだと思います
私は混沌を歓迎します
pythonてかnumpyだよな
ai屋さんにとっては言語なんてどうでもいい
2位じゃダメなんですかおばさんの一声で潰れる程度の研究しかできない連中が悪い
糞バカ中世ジャップランド土人村の末路
ガチで有能なところは企業から金貰って研究してるからな
データ系なんか金稼がないと何の価値もない分野なのに
>>69 どこが古臭いんだ？
これもATS2とかIdrisとかと同じで依存型がある証明系の言語だろ？
ガチガチの最新言語じゃん
多分compassとかの勉強会で発表できるようなカッケーのしか認めない層がいるんだろ。
そういう連中は相手にしてもなんの意味もないよ。
F* でできる程度の依存型なんて70年代の話題じゃん
70年代にできてることが未だにできない糞言語があると聞いて
お願いだから全機で超高速で動く言語VMつくって
ちょっとくらい難しくてもいいからお願いします
>>72 70年代かどうかは知らんが依存型関連の理論自体は昔からあることは知ってる
F*はつい最近知ったので詳しくないから他の言語の依存型とどう違うかは知らないが、
これが最新じゃなかったら君にとっての最新の言語はなんなの？
具体的に「どこがどう違うから新しい」ってとこまで含めて教えて
>>76 言ってないよー
こんなとこに沸かないで！
こういう風に聞くと大抵は黙るのなんなの？
こっちは純粋な興味で聞いてるのに
75に悪意があるとは思わないけれども
煽りとも取られかねない質問文で、後から「純粋な興味で聞いてるのに」ってのは
下手な物の尋ね方のテンプレにしてもいいのではってぐらいよく見る気がする
煽ってから純粋な質問と言いなおす。記憶回路にバグがあるのだろう
内容が大事だと思っているなら煽らずに本当に純粋に聞けば良い。煽っておいて「大事なのは内容」などと言うのはダブルスタンダード
>>87 勘違いしてるようだけど俺は75じゃないぞ
おまいらなんでこんな事には食いつきがいいんだよ
こっちは純粋な好意で気を遣って書いたつもりなのに
こんなことにはっていうけど、逆に何に食いつきが悪いと思ってるわけ？
実際
>>69>>72にとって古くさくない言語って何だったんだろうな
純粋に言ってればなんでも答えてもらえると思うなよ。
純粋に考えて、未だに型無し糞言語を崇めてる連中って馬鹿だと思うんだけどどう思う？
>>97 バカにされているのはSmalltalkerだろ？
Smalktalkそれ自体には罪はないよ
動的静的問わず型が弱くて扱い切れる人間は殆ど居ないからなぁ
話題の依存型も個人的には好きなんだけど対極的だし汎用プログラミングだと扱い切れなそう
rubyにはなんであんなクズみたいなのばかり集まっちゃったんだろうな。ruby自信に詰みはないというのに
当時のRailsの流行は頭の悪い人達のコンプレックスに支えられていたからだよ
英語わからない難しい要件わからない複雑なコーディングできない、でも俺はペチパーとは違う、という層に夢を見せた
依存型がある言語はML族もしくはF#の軽量構文みたいなのが多いのはなんでなの？
C系のシンタックスだと何か不都合でもあるの？
>>103 後の引数のpredicateが前の引数を参照するためにはカリー化されてると都合がいい
>>104 C系の方が慣れてる人が多いでしょ？それだけである程度意味があると思うけど
>>105 正直何言ってるかよくわからないんだけど、依存型とカリー化って別に関係ないんじゃないの？
だって、依存型のあるATS2では関数宣言↓だけは何故かC(Golangっぽい？)シンタックスだよ
fn test(x: double, y: double): double
だから、ATS2はML族なのにカリー化しづらいよ
>>106 型について研究してる畑の人ではML系の方が多数派だからね
それは論理学数学から醸成されたのがML系だからってのもあるし、型についても扱いやすいシンタックスが既にあるML系とわざわざ型を扱うシンタックスを設計しなければいけないC系ベースどっちをまず採用するかってなったんじゃない？
知らんけど
>>103
> 依存型がある言語はML族もしくはF#の軽量構文みたいなのが多いのはなんでなの？
> C系のシンタックスだと何か不都合でもあるの？
依存型や本来の多相型(polymorphism)［†］などは型理論の体系つまり高階の型付λ計算に関する論理体系に基づくので
プログラミング言語の型システムとして組み込む場合には同じくλ計算に基づくと関数プログラミング言語の枠組みとは親和性が良いが
Cなどのように変数の値を書き換える代入文や代入演算を有する命令的プログラミング言語とは馴染まない。［‡］
だからそれらの型システムを導入した言語は既存の関数プログラミング言語の構文を流用するケースが多いのだろう。
なおStandard ML/CAML/OCaml/F#などeager evaluationを評価ルールとするいわゆるML系の関数プログラミング言語の一群は
ref型のように代入可能な変数を許すが、本格的な型理論に基づく型システムを組み込む場合はref型の類は除いたsublanguageに対して
行うのが普通。
［†］：本来の多相型とはGirardが竹内の基本予想に関する学位論文で最初に発見（あるいは発明）し
Reynoldsが独立に再発見した型の全称化・抽象化やMilnerが発見したlet-polymorphismなどを指す。
オブジェクト指向での継承に伴って使われるようになった“polymorphism”は
定義が不明確で勝手な拡大解釈が多いので「本来の」という修飾句の対象範囲からは除く。
［‡］：代入操作（代入文と代入演算の総称）を含む命令的プログラミング言語
（Ｃなどの手続き的プログラミング言語やオブジェクト指向プログラミング言語を纏めてこう呼ぶ）に
例えば多相型が馴染まない理由は代入操作可能な変数の型として多相型を許すことは
その変数について動的な型付けを許すことに他ならなくなる。
例で少し説明するが既知なら許してくれ。最も基本的な多相型 ∀t.t （どんな型でもＯＫ）と宣言された変数 x を考える、つまり
∀t.t x;
この変数はどんな型の変数としても使えるので、これにint型の値 1 は代入できる、
x = 1;
この後で式の中でこの変数の値を参照すると int型の値 1 が許される文脈以外ではエラーになる。
即ち、型理論における本来の多相型つまり静的な型付けでの多相型の概念は代入可能な変数では失われるということだ。 Cは関数()をカリー化しなかったが配列[]をカリー化した
2次元配列を1次元のように扱い、逆にスカラー (0次元) を1次元のように扱う
Cには共用体もあるからML系に似ている部分は多かった
オリジナルのC/C++はもう実質的に依存型と同じものを既に使いこなしてるな
依存型がまだないという自称C系ってのは本当はJava系と名乗るべきだな
>>106 こいつCのシンタックスじゃないって理由でPython嫌ってそうｗ
>>106 カリー化されてると全部1引数の fun a -> aを使う(かもしれない)型 の形で済むだろ
ATS2がどうしてるかは知らん
別にC以外のシンタックスを嫌ってる訳じゃないよ(てか、なんでそういう風に受けとる…？)
普及を考えれば新規ユーザーのハードルを下げるためにも少しくらい相性が悪かろうが
C系のシンタックスを採用した方が良いんじゃない？って思っただけ
どれだけ理論が優れていようが結局のところ広く普及した言語の大半
(C/C++, Java, C#, JavaScript, PHP...etc.)はC系のシンタックス
勿論C系以外で普及した言語もある(Python, Ruby...etc.)けど…数はそれほど多くない
Cのシンタックスを採用することに致命的な不都合があれば話は別だけど
そうでなければ1つくらい依存型ありの言語でC系の言語があったって良いんじゃない？
優れた理論が使われてる言語がそんなしようもない理由で普及しなかったら勿体ないじゃん
普及させるためにはそういう些細な部分は妥協したらどうだ？と思ったわけ
COBOL舐めてるわけ？
Fortran舐めてるわけ？
>>109 > Cは関数()をカリー化しなかったが配列[]をカリー化した
配列をカリー化の意味が分からんのだが
まともな推論を入れようとしたら
>>108みたいな理由で式ベースになるんだから
C系に似せようとしたところで不格好で無駄に記述量も多いキメラができるだけだろ
ところでBASIC舐めてるわけ？
>>114 > ALGOL舐めてるわけ?
AlgolとくにAlgol 60は実用性はともかく言語設計の観点からは非常に優れた言語だったが、命令的言語であるがゆえに型理論には馴染まない部分がある
今回の君のような内容ゼロの一言レスしてる暇があったら、ReynoldsやTennentの教科書・論文ぐらいは読んで勉強したらどうよ
>>117 そうか？式指向でC系のシンタックスっていったら真っ先にRustが頭に浮かんだが
別に不格好とも無駄に記述量が多いとも感じないが…
そもそもC系の時点で何指向だろうが関数型と比べると記述量は少し多くなるものだし…
C系を式指向にしたところでそんなに変になるところは無いと思うんだが
別に全部C系にしろって言ってる訳じゃないんだ
依存型ありの言語にも1, 2個くらいC系があっても良いのにっ思ってるだけで…
現実は正しい
格付けの方が間違ってるんじゃねえか
リーマンショックみたいに
あってもいいということはなくてもおかしくないという事だよ
言語設計者が依存型を普及させたいにしてもC系シンタックスを蛇蝎の如く嫌っている可能性だってある訳だ
そうでない君が依存型+C系シンタックスが普及に必要だと思うならそれは正しく良い意味で言い出しっぺの法則だね
>>120 rustは根っこのところは手続き型だからな
もっと式ベースを徹底していったらC系文法なんてどんどん余計なものになってくよ
式指向にしてブロックが値を返す
ブロックの中でreturnなどと書いたらブロックだけではなくメソッド全体が終了する
これSmalltalkとRubyでやったやつだ
>>124 ＞ブロックの中でreturnなどと書いたらブロックだけではなくメソッド全体が終了する
他のほぼ全ての言語もそうじゃね？
やっとラムダが当たり前になったところだぞ
型理論の成果がプロダクト利用に広まるには時間がかかるんだよ
なんでJavaだけバージョンアップしなきゃだのセキュリティアップデートがどうの、大騒ぎしてんの？
JavaScriptなんて毎日のように新しいsyntaxぶち込まれてるし、
Kotlinがここまでアプデに振り回されてるのはあまり聞いたことない気がする
他でここまでセキュホがギャースカ言われてるのって、ポンコツペチプァとWordPressくらいじゃね？
Javaってそんな糞脆いの？
>>108 詳しい人から見てF*ってどうなん？良さそう？
>>127 エンプラで使われまくってるからわずかな変更にも大騒ぎするというだけ
履歴書がフォーマット通りじゃないとか、書類に印鑑がないとか、工場作業員の歩く幅が守られてないとか、そういうので騒ぐと同じ
javaというのは汲み取り式の便所みたいなもので、それに下水と近代的な便座を取り付けたのがkotlinだが、結局大便か小便かあるいはその両方をひり出す装置だということに気づかず、エレガントなクソの仕方について議論しているのが奴らだからな
いきなり外に出ろと言われても、オラクルにオツムを履かせてもらわないと不安で仕方ないんだよ
omutu {
ブリッ()
} catch(unko) {
throw unko
}
>>133 人の頭をオムツ代わりにするとは、家畜人ヤプー的な変態だろう
そのRustを語るとコンパイル通せないアンチが沸くしな
メモリ制御しなきゃいけない世界が無くなることはよしんばあっても当分先なのでメモリ制御できる言語の更新はあった方が皆幸せになると思うんだけどな
車輪に怒られるだろ
せいぜい定年後の手作りログハウスだな
GCはメモリには効くけどリソースの速やかな解放には効かないから
using文とかtry-with-resources文とか必要になってくる
SwiftやRustとかはメモリはGCほどお手軽では無いけど
リソースがメモリ管理と同じ流れに乗るからカメラとかのAPI扱うときはむしろ楽になる
一長一短なところはある
実際問題ログハウスで十分なところを最近の言語はウインチェスターハウスにしちゃってる感じ。
ログハウスはお手軽という意味で例に出したんじゃないんですけど
ログハウスで充分な仕事しかしてないのにウィンチェスターハウス作れる言語に目が向いてこんなスレに迷い込んでしまったの間違いでは
ほんまに計算科学の次世代言語欲しいわ
Fortranさん仕様は悪く無いのにprint文書くだけで周りの計算結果変わったりしてコンパイラがガバガバすぎる
>>154 すぐバグるんだよな
gfortranで通ったし大丈夫だろって思ってたらifortでは通らなかったり、C++よりはるかにプログラマの責任が重いと思うわ
fortranは仕様より処理系依存の独自拡張が蔓延ってるイメージ
haskellも処理系拡張が基本みたいな所あるしそういうの好きになれない
処理系が実質ひとつしかない言語だと処理系拡張が基本でも困らないけどね
＿＿＿_
／⌒ ⌒＼
／（ ●） （●）＼
／::::::⌒（__人__）⌒::::: ＼ 次世代言語でやるお！
| |r┬-| |
＼ `ー'´ ／
rustはダメだな。
信者のウザさがhaskellと一緒だわ。
ああいう1機能を理解するのがめちゃくちゃ嬉しくなっちゃうような言語はダメだわ。
信者のウザさとか言う概念なんなん？ 何を見て判断してんの？
リアルの知り合いじゃね
Rust信者には会ったことないが、Haskell信者のウザさは割とガチだな
>>164 逆に言うとウザい知り合いが使ってる言語はダメってことか……
生き辛そうな人だな
> 信者のウザさ
自分では到底習得出来ない言語を
楽しげに使いこなしてる事に対する嫉妬でしょ？
なんで所有権の移動という一度しか起こらない元値を破壊するものが印なしで
参照の借用渡しが＆にしたんだろう
リアルうざい知り合いはモチベーションに影響するからなあ
いくら物が良くても距離を置くのはそれはそれで賢い処世術
またUXの話してる
親がUX 社会がUX 信者がUX
あぁ、わからんでもない
言語じゃなくライブラリの話だが
仕事で使ってるライブラリを大して覚えようともせずVue.jsを猛プッシュしてくる中国人が、同僚に居て大嫌いになったわｗ
日本で流行ってる！ていうのもペチパーのCakePHP臭がして近寄りたくない
楽しげに使ってるというよりかは
楽しいと思い込もうと必死になってるといった印象だから嫌なんだよ。。
それ絶対楽じゃないよね、もっと簡単なやり方あるよねって話が一切通じなくなるっていう。。
なんてこった。このスレは昔からリアルの友人報告スレだったのか……
rustの狂信者なんて5chですら見たことないけど
>>168 C/C++の&演算子と仕様を合わせただけだろ
仮に借用に&を使わない場合はどうするのが良いと思うわけ？
あと「元値を破壊」ってどう言うこと？
「移動」と「破壊」を同義として使ってるの？
>>172 Haskellに対してならある程度は同意する
でも、Rustに対しては同意できないな
メモリ管理を自力でするのではなくコンパイラに任せる
メモリリークは自力でデバッグして解決するのではなく
コンパイラに詳細なエラー情報を表示して解決を手伝ってもらう
コンパイルが通ればメモリリークが無いことが保証される
きちんと楽で簡単になってるじゃん
GCの無い言語であれより楽で簡単にメモリ管理を行う方法を俺は知らない
知ってたら教えてほしい
>>178 半ば本気で言うが c++ で生ポインタ使わなければ概ね実現できるんじゃないか
「〜すれば」は(しないこともできちゃうから)ダメとか、
その場合の効率はどうなんだとか議論の余地はあるだろうけど
GCが有っても、不要になったデータは破壊される
ただしその事実が隠蔽される
Haskellでもデータは破壊され、隠蔽される
もし隠蔽しなかったら、破壊的代入禁止という無理ゲーがもっと簡単になるよね
だからRustはGCをやめ、隠蔽するのをやめた
破壊的代入禁止が無理ゲーってどこのドカタ星の話だよ
Rust使ってると脳が破壊されるのかな？
そんな旧約聖書にだって書かれているようなことは議論の余地もない
rustは次世代言語の逆で、幼児退行言語。
rustの所有権は、赤ん坊のおしゃぶりと同じ。
おなかすいたらGCおかあさんのおっぱい吸えばいいのに
いつもおしゃぶりを握っていないと不安になるだけ。
不可抗力的にお母さんのおっぱいが出ない(パフォーマンス上制約のある)現場はどうするのか
幼児退行を悪い事として述べる為におしゃぶりという例を用いているのに、良いものとしておっぱいを挙げているので幼児退行と非幼児退行の良し悪し比較がおしゃぶりとおっぱいの比較になりレスの中で批判の比喩が統一されていない
何かに例えてもふわっとしか批判できないのにそれを通り越して例えに統一感がない無意味さの塊みたいなレス
おっぱい（GC）で十分なのに、実際は効果のない何かを手で握ってないと不安な幼児退行ってことだろ
おしゃぶりじゃなくてガラガラって方が例えとして正しいと思うが
Rustが幼児退行言語ってことには激しく同意する
もうちょい踏み込むとアダルトチルドレン言語か？
ママのおっぱい（GC）には頼りたくないけどガラガラ握ってないと不安なクソガキメンタル
スレッドセーフなARCと
シングルスレッド専用ARCと
mark&sweepのようなもの
を使い分けたい＝宣言したいという需要がとても強い
どう強いかっていうと、int型とdouble型とstring型を宣言したい需要と同じ種類の強さ
そういえば最近GCも
新しいアルゴリズムやらで改良されてるね
ガラガラ握り続けてないと不安で不安で仕方ないRustちゃん
巡回参照を持てない時点で使い物にならない言語なんだよなあ
どのcpuでもinterlockedなインクリメントやデクリメントがあるから、
よほどコア数大きくない限りそんなに違いでないのでは？
測ってないけど。
>>スレッドセーフなarcとシングルスレッド専用のarc
>>188 ラストスタンディングマン方式でレスバしてる板の定型文はNG
>>195 おっぱいおっぱい言ってるレスへの返答なんて適当でいいでしょ
rustみたいな言語が一般に広まっても
結局無理やりコンパイル通すためにRefCell,unsafe使いまくりのクソコードが
蔓延するだけなんだよね。
「コンパイル通れば安全」とかね、プログラムのバグの多くはそんなところにはない。
まあRustなんてやってる奴は、
悪いこと言わないからCやC++やってろってこった
どんな現場にいたら
>>198 みたいな歪んだ考えをもつんだ？
気の毒すぎるだろ
>>175 デフォルト借用
破壊というと御幣があるが、C＋＋の仕様をいうならなおさら
auto_ptrへの所有権移動で
=だけで移動するのがわかりにくいからって非推奨になった経緯がある
>>200 C,C++は習得した上で趣味でやるもんでしょ。
>>198 動的言語でできることはすべて静的言語でもできる
この性質により、お前らが気に食わないコードでもコンパイルが通る
RefCellはコンパイル時ではなく実行時にborrowチェックしているようだな
まるで動的言語のようだ
>>202 デフォルト借用なら移動の方はどんな演算子orキーワードを導入するの？
>auto_ptrへの所有権移動で
>=だけで移動するのがわかりにくいからって非推奨になった経緯がある
それはC/C++の=はもともとコピーのセマンティクスを持つから移動に変えたら分かりにくいって事情があったからでしょ？
RustはCとの互換を捨ててるからCのセマンティクスの影響は受けない
でも、Rustは互換は捨ててもCとの親和性は欲しいという都合(ワガママとも言える)があるから
Rustの参照(借用)はC/C++の参照と似たようなセマンティクスになる&で妥当だと思うけど？
C++とRustのコピー・移動・参照(借用)の方法を整理すると↓になる
C++
コピー : =
移動 : std::move()
参照 : &
Rust
コピー : Copyトレイト
移動 : =
参照(借用) : &
C++ユーザー取り込むために文法にせてるのに
肝心のところでC++ユーザーが混乱するじゃないか…
どうせ=で移動したって参照わたしてるんだから&の意味がズレてる
所有権の移動という重要なできごとにこそ別途印がつくべきだった
>>179 >半ば本気で言うが c++ で生ポインタ使わなければ概ね実現できるんじゃないか
出来ると思うよ
でも、C++はRustよりもさらに複雑怪奇な仕様で使いづらい
C++のスマートポインタは正しい使い方をすればRustに負けず劣らず優れてるけど
それは、同程度に優れているだけであってRustより優れているとは思わない
あと、少し話が変わるけど実はRustの最も優れているところは
所有権・借用・ライフタイムの概念よりもエラーハンドリングだと思ってる
あのResult型とErrorトレイト・Fromトレイトとtry!マクロ(?演算子)を使用した
エラーハンドリングの方法は個人的には感動するレベルの代物だった
今後の次世代言語のエラーハンドリングは全てあれをベースに発展させていくべきだと思うほど気に入っている
>>207 >どうせ=で移動したって参照わたしてるんだから
あれ？それって仕様として決まってるんだっけ？
コンパイラの最適化の結果としてそうなるってだけじゃなかったっけ？
>>所有権の移動という重要なできごとにこそ別途印がつくべきだった
いや、だからその移動に何の印を付けるのがいいと思ってるの？
俺は借用には&が妥当だと思うとは言ってるけどベストだとは言ってないじゃん
ベターな代替え案があるなら俺だって意見を変えるよ
x = f(x) とか
C++で有名な x = x とか
これらはmoveが最善
Rustも=でコピーのことがあるから余計ややこしい
let p = q ってかいてあってqがその後も使いまわせるかぱっと見わからんとか
ポインタっぽく普段の=は参照渡しで&が所有権移動にすりゃよかったとおもう
スレチなんでちょっとだけ、C++は別に複雑では無いよ
プリプロセッサは氏んだほうがいいけど
書いてて初めて気が付いた
実際に触ったことないから想像で書いてるんだが
>let p = q ってかいてあってqがその後も使いまわせるかぱっと見わからん
ほんとにこういう仕様なのか
使いづらすぎんかこれ？
使い回せるかどうかはCloneトレイト実装してるかどうかに依存する
つまり見た目ではわからない
まあそもそも古い変数を変なとこで使い回す設計って普通にバグの元だし
ぱっと見てコピーかムーブか分かるかどうかが重要かと言われると確かに怪しい
ぱっと見で区別が必要なコード書くなって話だな
使い回せるかどうかは、ぱっと見た時ではなく、コンパイル時にわかる
ぱっと見てわかるならコンパイラいらねえよ
スクリプト言語以外はとりあえずgoやっときゃええの？
今時文字列リテラルに変数とか式を埋め込めない言語って嫌がらせかよって思う
Goは他のまともな言語をいくつか使える人にとっては、低脳言語な割には意外とまともに使えるよく考えられてる言語だ、という感想になるけど、
PHPとGoしか知らないとかだと普通に低脳なだけの言語になっちゃいそう
頭悪くなるからやめとけ
>>219 まさにこれ
低脳言語の中では一番頭がいいのがGo
頭がいいと思って使うと肩透かしくらうが、低能と割りきるならすこぶる便利
そこにニーズがあると読みきったGoogle少しだけ見直したわ
Go言語らしさを生かしてどうこう言われると反発したくなるので関心を持たないことにした
エントロピー低いなら低能じゃないだろって思ったけど、驚き最大的な意味ではたしかにエントロピー高いのが一番いいのか？
圧縮専門の人頼む
ざっくり言うと
「これもっと短く書く記法や仕組みがあるだろ」
というようなものが低エントロピー
別に良いとも悪いとも言ってない
エントロピーの話
ライブラリや組み込み機能を使って短く書けました！
なんてのは圧縮で言うなら辞書式圧縮だな
よく勘違いしたアホがいうソースコードのエントロピーの増大ってのは、
MOVE A OF X TO A OF Y
MOVE B OF X TO B OF Y
MOVE C OF ...
の二行目だけが仕様変更で
COMPUTE B OF Y = B OF X + 1
に変わったら元より情報量が増えるという当たり前のことを言ってるに過ぎない
最初から
MOVE CORRESPONDING X TO Y
の一行だったら当然同じ行数あたりのエントロピーはずっと大きくなる
エントロピーが低いと無駄な繰り返しが多いけど、高すぎるとgzになっちゃう感じか
ギブズエネルギーに当たる概念はないのか？
なんでエントロピーって言葉を使うの？コンテキストじゃ駄目なの？
すまんがコンテキストって何ンゴ？ エントロピーとはちょっと違う概念なの？
最近のVSCodeが最強過ぎて恐ろしいわ
MS帝国の再来ですわ
確信をもって言える。確実にエントロピーを間違って理解している
まずエントロピーと自己エントロピーとをちゃんと区別しろ
単純に圧縮率をあげるなら予約語は一文字にすべきだ。
しかし一般に冗長性がないと多分人間はまともに読めん。
>>242 すまんが自己エントロピーって何ンゴ？自己情報量とは違うものなん？
てめえここでンゴるとはいい度胸してんな
まとめ民ならまとめに、J民なら標準語で喋るんやで
vscodeはemacsキーバインド使えるようになりました？
そうか……🤔
じゃあ今日からここはプロJ板だからよろしくやで〜
オッスお願いしまーす！
何がおかしいんだこのクズ
J言語はとっくの昔にある
ans =: -:@(1&o.@((o.2)&%)@#*+/@(*(}.@, {.))"1@((/:[)/:(/:+/@(*,~/"1)@(*\)@i.@#)))
>>256 はぁ？そんなもん知っとるわｗ 昔からあるからこそ面白いんやぞ��
ユーモアのセンスのないガイジが人をクズ呼ばわりする前にちょっとは相手の意図でも考えればｗ
J言語はちょうど話題になってる「圧縮率高い言語」と言えるのでは
perlも$@みたいな組み込み変数が多用されてるから圧縮率高い？
コンパイル言語のScalaですら、イカ演算子やらググラビリティの低さで敬遠されがちだったのに
型無し糞言語の糞みたいな演算子、迷惑以外の何物でもない
ペェルとか死ね今すぐ死ねなるべく苦しんで死ね
数学なんかよりも地理歴史政治経済のググラビリティが高いから
マスコミが報道しないネットの真実は地理歴史政治経済の話題ばっかりなんだな
>>259 慣れても読みやすいとはいえないけど
慣れると「他の言語はコード自体がコメントのように冗長だから読みやすくて当然、」とか思うようになる
あとまあ、Jでも普通の人に読みやすく長々書くこともできる
swift 触った経験なしなんだけど、自作アプリから他のアプリを操作って可能なの？アプリAの情報をアプリBに書き込んだりとか。
それが出来るならMacBook買おうかと思ってる。
教えてくらはい
ちなみに想定端末はiPhone,iPad
セキュリティ上やばいからiOSでは通常どうやっても無理だな
脱獄必須
>>271 与えられ数列を並べ替えてレーダーチャートにしたときの面積
並べ替える法則がよくわからない
面接が最大になるようにしているように見えるけどもしそうならバグってる
面接最大ならこうだな
ans =: -:@(1&o.@((o.2)&%)@#*+/@(*(}.@, {.))"1@((/:[)/:((i.@#)/:+/@(*,~/"1)@(*\)@i.@#)))
ちなみに
-:@(1&o.@((o.2)&%)@#
これが 1/2 sin (num of arg /(2π)) なので円をN分割したような三角形の面積の総和かなあ、と。
こういう書き方だとどんな言語でも読みにくいだろ
式１つで書くと変数名等の読むヒントがなくなって厳しい
普段使ってる数式と乖離しすぎてやべー外国語って印象
クラスと変数には必ず名前空間をつけろ
演算子とメソッドにはつけなくていい
つまり、短くしたいならクラスと変数を使うな
>>269,270
ありがと！
脱獄で調べてみるわ
まじサンキューな
史上もっともカネを動かした言語はAPLだと言われるこの世界線で
なぜJが仕事で使えないと思うのだろう…
>>280 そのエピソード読みたい。なんて検索すればいい？
成果は何かではなく原価はどのくらいかを重視する異世界
ガイジでも作れるウンポコペチプーと宣伝した結果
ほんとにガイジに作らせて、保守費用が天までそびえたつ糞と化したゲリクソピィさんも
なかなかのカネを動かしてると言えるんじゃないか？
> 「APLという言語そのものがボトルネックとなって巨額の損失を生み出す間接的な要因になってしまった」
ガーイｗ
単語の辞書化をした上でのソースコードの圧縮率って、糞コード性を推定するメトリクスとしては実際わりと有効そうに思えるけど
研究でやった人いないのかな
Goの勉強始めてみようかと情報探りながら勉強してたんだけど、
http://golang.jp が5年くらい更新されていないのを知って
Goは終った言語なのかと思えて勉強する気がちょっと萎えた。
じゃnimやろうぜ！in action出たよ！英語だけど。
>>289 それ、全然goと関係ない。少なくとも勝手にやって勝手に諦めてるだけで誰も参考にしてないから
プログラマは検索力も大事
jpドメインなわけがない、と気付ける知識も含め
非公式翻訳サイトってほんと害悪しかないよな
普通に公式の翻訳に参加しろよと思う
ああいうの作る奴は結果的に自分達が日本の情報的孤立化を増長してることを自覚すべき
翻訳は原文に絶対勝てないのになぜ翻訳するのか
逆に英語に翻訳したくなる日本語を話せよ
>>296 もちろん分かっちゃいるんだけど
思ってたよりオワコン化してるのかとかいう
イメージを持っちゃうんだよなあ。
勉強し始めでこういうの見ると。
python始めたばかりの頃もググると最初に出てくるpython.jpで
欲しい情報探すのに遠回りさせられた記憶あるしなあ。
あー、なるほど
エイチレス発音のやつですね
声を喉からつむじの方に吹き抜けさせるイメージで発音する
ハトゥムル、ゥムの部分が重要ですね、語学的な意味で
かれこれ20年ワイフとはエイチ・レスです。
ワイフとは。
>>305 レンタルサーバー屋のヘテムルって
そこからとったのか
>>311 んなに長い発音してるの、ジャップランド土人村のイエローモンキースくらいですわ
言語のマスコットってキモいの多くない？
D、Java、Go、Perl6
D言語くんはマシな方では。Gopher、Lispエイリアンが飛び抜けてキモい
Delphiのアテナでも眺めてよう
オライリーすら侵食したLispのマスコットは凄いと思った
ギアにRのやつは「ロゴ」で、「マスコット」はキモいカニだよね？
>>327 あのマスコットはたしか非公式だったはずだからセーフ
てか、言うほどキモくないと思うが…
ここでHTML5のロゴを御覧ください
>>329 わりと好き
スーパーマン的なダサ格好良さ
ロゴは割りとどれもクールでいいんだよ
マスコットは大概きもい
一番キモいのはTomcat
Hadoopのマスコットとロゴ好き
あのゾウ単独だとぶん殴りたくなるけどロゴ全体で見るとパロディっぽくポップにまとめてあるおかげで愛嬌のある顔に見える
>>303 GoはオワコンだからホットなC++使おうぜ
言語以外も含めると象多くない？
PHP、Hadoop、Postgre、Evernote
他にもありそう
スレ違だけど最近javaからの移行でc++使い始めたわ
わりといいかなーと思ってる
win32api使いにくくね？
んんんそのとおりだ…
ぶっちゃけいうとWin32apiが頭のなかでスパゲッティになってる
C#もやってみるわありがとす
C#とかM$サーバにでも骨を埋めるつもりか？
Javaにしとけよ
連日40度を超えるモ〜レツな熱量を電気エネルギーに変換するプログラムとかおまいら書けないの？
次世代だの世界を変えるだの言ってる割りに、おまいらって無力だよなｗ
熱はエネルギーのゴミと言われており、もっとも利用しにくいエネルギー形態の一つだ
＼ /
＼ 丶 i. | / ./ ／
＼ ヽ i. .| / / ／
＼ ヽ i | / / ／
＼
-‐
ー
_＿ わ た し で す --
二 ／￣＼ ＝ 二
￣. | ＾o＾ | ￣
-‐ ＼＿／ ‐-
／
/ ヽ ＼
／ 丶 ＼
／ / / | i, 丶 ＼
／ / / | i, 丶 ＼
「意識高い系の何が問題なの？」「世界を変えると言ってる割りに無力」
>>341 UI はWindowsならC#、AndroidならJava、iOSやMacならSwiftで書いて
これはどう考えてもマルチプラットフォームにしたいでしょ
3度も書きたくないしというところだけC++で書くと良いですよ
>>345 今はクロスプラットフォームでオープンソースな.NET Coreがある
オラクルがソースコードをGPLで「リリース」しているだけの○penJ○Kとは違い、
本当にコミュニティベースでMSが参加する形で開発してるしライセンスがMITだしMSからは形式上切り離された非営利団体が権利を持つ形になっている
おまいら無力世代wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
JVMの新言語はさすがにもう今後一切出てこない(出ても流行らない)だろうな
手っ取り早く新言語作って既成のエコシステムに乗せるなら.NET Coreはアリかも
コマンド一発でVMごとバンドルできるからそれほど.NET意識しなくていいし
>>358 ほー。なんか良さげに聞こえるけどvm上で動かすことにメリットあるの？
goで良いじゃんって思ってしまうんだが
簡単にプラットフォームごとにビルド出来るし。
>>359 goでいいならいいけど他の言語が使いたいならgoのライブラリ使えないでしょ
新しい言語を作ってオナニーしたくても、最低限の実用性を持たせるためにライブラリまで一から作り上げるのはハードルが高すぎる
.NETは元々クロスランゲージを標榜して開発されたから、特定の言語に依存した変な制約はJVMに比べても少なくて、オナニー言語の実装には最適
まーたM$信者が出張ってきたよ
翻訳の改善をコーディングスタイルでリジェクトして炎上してることへの火消しか？
この間はコミッタの名前をsquashして開き直りかましてたし
ほんとお前らがオープンソース活動とかOracle未満なんだよ反吐が出る
>>356 コミュニティベース（実態は都合の悪いことは燃えない聞こえない）
形式上切り離された非営利団体（ただの節税対策の天下り先）
ライセンスがMIT（今後特許を主張しないとは言ってない）
>>360 ライブラリを作り上げる程度なら無力レベルでもできるぞ
作ったものに課金して儲けるのがハードル高い
monoも無料になった時点で無力レベル
>>361 そういえば、Closeされたぜ-1してやろうって呼びかけてたキチガイがいたな
closeした方だけじゃなく
thumb downした方まで煽るのか…
MSの最近のOSSへの貢献度をみればありがてぇと思うけどな
>>359 goはゴミだもの
https://github.com/dotnet/docs.ja-jp/issues/118 炎上してるのこれか
フィードバックしても意味不明な返事しか返って来ないなら
オープンにした意味がないなw
>>371 てらだよしおがフォローしてて草
他のエバンジェリスト共もこんな時くらい動けよw
>>371 受付の姉ちゃんに絡むような真似してアホかよ
こんな連中が増えるなら日本語翻訳なんか全部やめるべきだな
>>370 私物化を貢献と言い張る社員様
Googleのsageも入れてぬかりなし
善いことをしたのに処刑された聖人もいるからな
処刑なんてただの被害妄想に決まってるという信念があるから聖人になれるんだな
最近のMSのOSSとの関係って、Darwinが出た頃のAppleとOSSの関係に似ている。
>>376 私物化って、だって実際MSの私物だし？
>>382 オプソフレンドリーなことを言っておいて
オプソのプロセスよりも社内のプロセスを優先させて
コントリビュータとの対話を一方的に切断するところ。
ドキュメントの翻訳などという機械的な単純作業プロセスを開発とごちゃまぜにして外に公開したのが間違いでしょ
いちいち個別に対応してたらキリがない
http://d.hatena.ne.jp/megascus/20180726/1532557216 ボタン設置してフィードバック求めてるくせに
まともに機能させる気がないだろこれ
終いには報告者を叩き始めるとか
流石のMSクオリティとしか言いようがない
プロセス自体もアレだが、
裏でエバンジェリストに叩かせるってやり方がもうMSを象徴してる
これよりMSが関わる言語は次世代言語の選択したり得ないことを提唱
当スレでは.NET系言語、Typescriptの話題を禁ず
Visual Studio Codeにプラグインがない次世代言語を探す遊び
MSが関わってない言語しか使わない君は一体どんな仕事をしているの？
なでしこでホームページでも作ってるのかな？
>>392 よくみんなから「キチガイめ、あっちいけ」って言われない？
やっぱりどの言語もライブラリがまだ全然足りてないな。もうちょっとましになってから勉強したい。
無ければ作るんだろ
そのためにプログラマになったんじゃないの
>>396 Kotlin から Java のライブラリ呼べばおｋ
能率は悪いが完全に無駄だというわけでもない
まぐれで前任者のものよりもっといいのができるかもしれない
チューリングマシンの再発明と言ってしまうとこのスレ自体の存在意義が
Webkit だの libavformat だのを各言語でまた作るなんてあり得ないから
ライブラリはどの言語からも使える c/c++ でいいよ
世の中には車輪よりも複雑で大規模なものもあるんですよ
>>396 どんな言語を勉強しても無駄にはならんよ
時間がかかるのは言語の習得じゃなくて、いろんなアルゴリズムを理解することだからね
>>409 別にJava書けとは言ってないんだよなあ
Kotlin側から気にするのはJava側が引数にnull受け入れるか、戻り値にnull吐くかどうかだけ
JVM自体が????が嫌いというならどうしようもないけど
んだ、jvmがウンチだ
恥ずかしくて使えないよな
kotlinも頑張ってkotlin nativeを完成させて欲しい
結局c90くらいしかドフリーな言語なんてないんじゃないかね。
もうDartはそっとしておいてあげてください
たまに気紛れで棺桶から引っ張り出してぶん殴るのはやてめください
GoogleとFacebookとMS、一番信用しちゃいけないのは誰
梯子外しの常習犯という意味では目糞鼻糞だけど、それに対して適正な批判を受けていない点で圧倒的にGoogleだろうな
批判を情報操作によって封殺してきたわけだから
わからないことは正直にわからないと言うやつが信用できる
どんな質問にも答えようとするやつと答えさせようとするやつは信用できない
py老害脱落か
さっさとconst/final/valを導入しろ時代遅れ言語
GAFMAはもはや国よりも力あるからな。。ヤベーわ。
最強言語じゃなくライブラリの時代になって悲しいのう
それな
pythonみたいな欠陥言語が天下取るとは
ないわな
学歴高い連中にはpythonがイケてる事が分かっちゃうんだよね
綺麗なところと汚いところのバランスが取れてるところとかさ
だからAIで流行っちゃう
pythonの良さが分からない底辺ドカタはシンタックスの重箱の隅をつつくのに夢中だけどね
継続最強伝説からモナド最強伝説に移行するところで大多数が挫折しただけだろ
C言語で書かれたpythonライブラリがイケてるのであって、言語としてのpythonは全然イケてないぞ
Python並みのライブラリがあるイケてる文法の言語が来たら乗り換えるわｗ
[JavaScript]
a.sort().reverse().map(x => x.toString()).join(“-“)
[Python]
'-'.join(map(lambda x: str(x), reversed(sorted(a))))
うーんこのウンＰｙ
結局言語のしょうもないシンタックスについてあーだこーだ言っても意味ねーわって話だな。
インストールの容易さとか実行環境だったりモジュール管理の容易さだったり
そういったところの影響のがでかいってのがpythonが流行ってる理由だろ。
でもPythonのシンタックスに満足してないのは事実なので、Pythonの良いところを全部持った上でシンタックスも良い言語が来たら嬉ぴい
__init__.py （笑い）
sys.path.append（木亥火暴）
実行環境だったりモジュール管理の容易さだったり藁藁藁藁藁藁藁藁
大草原か？
Pythonは好きだが、MercurialがGitに負けたのは正直Pythonのせいだと思う
Rubyもそうだけど広く使われるツールに使うもんじゃない
>>433 というか、(RoR以前に)rubyが受けた理由がそういう感じだったと思う。
pythonのシンタックス以上にrubyに気に入らない点があるなら仕方がないが。
>MercurialがGitに負けたのは正直Pythonのせいだと思う
Mercurialの設計がまずかったとしか言いようがないがな。
コンフリクト修正のためのresolveの不自然さとかコミットツリーの修正ができないところだったり
使っていると普通に問題になる。
gitの設計はよくできてると思うよ。
>sys.path.append
こんなものを容易にソースに入れる奴はディレクトリ管理自体ど下手くそなだけで
どんな言語でもクソなことやり出すと思うがな。
リスト内包表記とやらにしがみ付いてる悲しい連中ってイメージ
可読性ｗ
リスト内包がクソなコード生みやすいってのは賛同するが
多分そういうクソコードを書くやつがruby、perlで書くともっととんでもないキメラコードを作成する。
pythonが流行ってるというかnumpyが流行ってるだけでしょ
>>446 せやな。numpyは神
でもscipyも良いぞ
Python は、メソッドチェーンしにくい。
Ruby, JavaScript, jQuery では、a.b().c() みたいに書けるけど、
Python では、逆に書く
c( b(a) )
オブジェクト指向からすると、突っかかる。
自然に読めない。
思考が乱されるから、バグりやすい
a のインスタンスに、b を適用して、
その結果に、c を適用する
これが自然
>>448 pythonでもそういうメソッドを作ればメソッドチェーンにできるけど、一行にだらだら書くべきじゃないという思想的な問題のせいで、そういうメソッドが用意されてないだけだよね。
底辺のドカタにとってはメソッドチェーンが重要なんだね
> 一行にだらだら書くべきじゃない
a = unko()
b_result = b(a)
c_result = c(b_result)
あっ、ふーん・・・
>>448 オブジェクト指向というより、パイプラインじゃねえの？
Objective-Cにもそんなチェーンはなかったと思うが
言うほど読みやすいか？
こんなの書いてくるやついたら草生やしてしばき倒すでフツウ
>>451 読みやすい！
pythonic!
pythonic!
こうですね
見当違いの批判をされてもAI分野で圧倒的に支持されてるのは変わらないから
ドカタが嫉妬してるだけに見えるんだよね
関数型言語の関数チェーンはともかく、メソッドチェーンは似て非なるゴミ。
Pythonだと、
>>451の一行一行で扱うものがGBクラスのバッチだったりするからね
[JavaScript]
a
.sort()
.reverse()
.map(x => x.toString())
.join(“-“)
[Python]
'-'.join(map(lambda x: str(x), reversed(sorted(a))))
下は書く気にもならん
補完も効かないし
パイソニップさあ・・・このウンコードはなんだい？
パイソニップさあ・・・
JavaScript以下、ウンポコペチプー並とか
恥ずかしくないのかい？
これは数学が悪い
関数はあるのにメソッドがない
ラムダやmapは教えないくせに内包表記は教える
冗長なコードを美徳として可読性の高さを謳っているのは
Python だけじゃなく、同じ手続き型言語の Cobol がある
たとえば >>455 を改変してみると：
見当違いの批判をされても業務アプリ開発の分野で
(Cobol が)圧倒的に支持されてるのは変わらないから
ドカタが嫉妬してるだけに見えるんだよね
仮にこんな感じでコボラが主張したとしても、なんら違和感がない
つまり現在に復権したコボラの正統後継者がフェイトニスタってこと 【悲報】パイソニップはウンポコペチプー以下のコボラーだった
>>456 COBOL では、まさしくそのとおりですね
まぁ実際には、GBどころかTB単位の夜間バッチですけど
>>458 aに副作用生じさせといてなんとも思わんお前がカス。
>>466 はいガイジ
全てのメソッドチェーンは副作用ないよ
くそパイソニップと違ってね
悔しかったら糞糞糞内包糞記で糞してみろよゴミｗ
メソッドチェーンってそんないいもんかね？
可読性がいいとも思えないけど
糞糞糞糞包糞糞と糞関数ラップワンライナーおじさんのパイソニップ草ｗ
これはやばい。。
やっぱシンタックス厨ってのは害悪でしかないな。
var a = new Array(4, 11, 2, 10, 3, 1);
var b = a.sort();
//var b = a.sort().reverse();
これでaの結果が異なるってマジクソだろ。
お得意の糞糞糞糞包みで糞してみろカスwwwwwwwwwwwwww
内包表記は数学由来だから文系のコンプレックスを刺激してしまうんだねw
副作用が糞
メソッドチェーンはフツウに良い
パイソニップ≒コボラー
これが結論
>>476 あれ？
>>467の釈明まだ？w
無知晒したからって勝手に終わらせようとするなよw
メソッドチェーンがぱっとわかりやすいのも分かるが
リスト内包はリスト内包で数学やってりゃわかる可読性がある
リスト内包がわからんってわめき散らすの無知晒してるだけだからやめた方がいい
それはそれとしてPythonはもっと関数を横に繋げられるようにしてくれ
Elixirのパイプ演算子みたいな感じでさあ
というかリスト内包とメソッドチェーン比較してる時点でただの無知だよね
数学ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
すｗｗｗｗｗｗすううっがくｗｗｗｗｗｗ
あれｗｗｗｗすうがくやったんけｗｗｗｗｗ
A = {2x + 5 | x ∈ N}
とかな。見たことあるだろ？
リスト内包はこの延長
こんなんもわからんで批判してたんかい
低学歴パイソニップ、Pythonで数学マウントを取る
あーもう
どこの板にもこういうキチガイ湧くんだよな
煽りカスでどっちにも有益にならないから放置安定よ
物欲はなくて支配欲だけがあるのが問題なんだろう
買いたい物がない人間が一体何のために利益を出すのか
益が少ない者を見下したり支配したりするためでしょ
お前ら次世代言語の話をしなさいよ
俺はRockstarをお勧めするぞ
プログラムであり自己表現でもある
言語の内容は一切しらないが
名前が商品っぽくてギーク臭がしないから、その言語ははやらないだろう
だからPonylangが真の次世代だっつってんだろ
Haskellのエラーモナドかましたリスト内包表記は難解すぎる
多言語を批判するならお互いが同じ例題でソース書き比べたらええやん
ずっとごちゃごちゃ言ってるやつってソースもごちゃごちゃしてそうｗ
>>492 多言語を批判なんてしてないから言い出しっぺではない傍観者だ
>>491 書き比べはそれはそれでもめるんよ
言語ごとの推し抽象化手法（有り体に言えば得意分野）が違うから同じの書かせつつ公平にはしにくいし
オーバーラップする領域ではライブラリーのAPI叩くだけのHelloWorldレベルのコード比較に終始してしまう
>>495 なるほどね触れた俺がアホだったわすまんなｗ
NG入れて見ないようにすればいいだけだしなｗ
読解力のないIQ低すぎる奴とは会話が噛み合わないから仕方ないなｗ
というわけで多言語とか言ってる馬鹿 ID:GVyD60rv はNGっと
なんでpythonの話になっとるんだ
rustの話が尽きたからか
批判っていうか評論も一つの作品だよな
漫画や小説なら良いが評論は悪いという価値観を押し付けるから揉めてるんじゃないか
数学やってりゃ分かるってのは高級言語にとって正当性の担保にならんと思うんだけど
pythonはスクリプトを書くためにあってアプリケーションを書くには向いてないよ
pythonはスクリプトやアプリケーションとかじゃなくてapiとかライブラリとかじゃないか？
スクリプトは後で修正するためにある
正当性の担保ってのがなくても後で修正すればいいと思ってる
だからスクリプトはズル
本物のアプリケーションはズルをしない
androidアプリ開発でGUデザインに拘りたいとしたら
どんな言語がいいでしょうか？
ん？ユニクロをもっと安っぽくしたようなデザインにしたいってこと？
GUIライブラリに何を使うかによる
SDLってAndroidでもつかえたっけか？
In our survey of 16,000+ npm users in January 2018, 46% of them reported using TypeScript.
https://twitter.com/seldo/status/1024052940355526656 >>509 .NetのC#以外は死んでるようなものだし
C#も半端な位置で留まってるから話題にならんのだろ
他バッサリ切ってC#に注力すればいいのにな
>>504
たしかに、そのとおりです
たとえば数学でいう直積(direct product あるいは cartesian product)の
プログラミング言語上の表現を、一般的には「タプル」と呼んでいる
もちろん ML や Haskell に代表される厳格な型システムを前提に設計された
言語の代数的データ型を持ち出すまでもなく、直積と直和の概念は
計算における数学上の概念の中で基本中の基本です
それにもかかわらず Python では、単なる不変(immutable)な配列に対して
公式文書でこともあろうか「タプル」と命名し、驚くなかれ「1要素のタプル」
といふ数学の概念を超越したリテラル構文を定義しちゃいました
世界的に普及している/していた言語は数多くありますが、こんな命名や
リテラル定義が存在するのは、後にも先にも Python だけ、唯一無二の存在です
まさに Python の設計哲学とは；
スクリプト言語にとって数学なんてクソ
といふことなんでしょうね 直積集合がタプルじゃなくて直積集合の要素がタプルな
んでもってn個の集合の直積を考える場合普通n=1は除外しない
>>478 あのぅメソッドチェーンとは異なり、内包表記というのは
決して万能な道具ではないんですけど、ご存知ですか？
内包表記というのは、高階関数 map/filter とジェネレータという
三つの要素を簡潔に表現できる構文糖でしかありませんから、
内包表記では表現できない課題も数多く存在します
ですからたとえば Haskell では内包表記を提供する一方で、
ポイントフリーといふ関数を繋ぐ流れるようなスタイルでも書けます
つまり「メソッドチェーン vs. 内包表記」という対決の図式は成り立ちません
これでもまだ「リスト内包がわからんってわめき散らすの無知晒してるだけ」と
騒ぎたいなら、以下のお題(
>>430-431)を内包表記だけで書いてみてください
'-'.join(map(lambda x: str(x), reversed(sorted(a))))
>>478氏が無知でなければ、内包表記でサラッとエレガントなコードを書けますよね？
ちなみに以下のような三重にカッコが入れ子になった醜いコードは勘弁してくださいね
'-'.join(str(x) for x in reveresed(sorted(a)))
>>517
>n個の集合の直積を考える場合普通n=1は除外しない
ええ、それが Python 村の中では「普通」で常識なんですよね
でも Python 村から一歩外に出れば：
n個の集合の直積を考える、ここで n>=2
が「普通」なんですけど、ご存知でしたか？
たとえば手元の教科書(*1)だと、直積は以下のように定義されています
・２つの集合の直積 A × B = { <x, y> | x <- A, y <- B }
・３つの集合の直積 A × B × C = { <x, y, z> | x <- A, y <- B, z <- C }
・４つの集合の直積も同様に定義される
この本では n=1 は定義されていないし、個人としても定義のしようがないと考えます
で、ML/Haskell/Erlang/Prolog といったタプルというデータ構造が存在する言語でも、
「普通」n=1の直積を除外しており、これが世間の常識です
ちなみに「Python村の常識、世間の非常識」といふ格言、聞いたことありませぬか？
ところで、もちろん内包表記はご存知ですよね？
知らないと>>478氏に「無知晒してる」と嗤われちゃいますよ
*1：論理と計算のしくみ
https://www.amazon.co.jp/dp/4000061917/ n=1もあるしn=0もある
n=0は直積の単位元いわゆるunit
直和の単位元はbottom
>>520 >n=1もあるしn=0もある
>n=0は直積の単位元いわゆるunit
たしかに Python 村の中では、n=0 も除外しないのが「普通」ですね
で、静的型付け言語の ML/Haskell では単位型(unit)として定義され
タプル型とは明確に区別されていますし、動的型付け言語では
nil という特別なアトムで表現することが多く、これが世間の常識です
ちなみに「Python村の常識、世間の非常識」といふ格言、聞いたことありませぬか？
ところで、もちろん内包表記はご存知ですよね？
知らないと
>>478氏に「無知晒してる」と嗤われちゃいますよ
>>516 なんだか随分と力んでいるみたいだけれど
> それにもかかわらず Python では、単なる不変(immutable)な配列に対して
> 公式文書でこともあろうか「タプル」と命名し、驚くなかれ「1要素のタプル」
> といふ数学の概念を超越したリテラル構文を定義しちゃいました
> 世界的に普及している/していた言語は数多くありますが、こんな命名や
> リテラル定義が存在するのは、後にも先にも Python だけ、唯一無二の存在です
いや、そういうことを言い出せば同じ引数の値で呼び出しても返す値が同じになるとは限らないCなどの「関数」“function”は数学における関数の概念とは全く違う破廉恥極まりない命名だとなるよ
そもそも手続き型プログラミング言語やオブジェクト指向プログラミング言語での「変数」“variable”と呼ばれているものもも数学の変数とは全く異なる
（例えば、それらの言語で書かれたプログラムの検証を考えるとその問題があからさまになる）
つまりプログラミング言語での用語は数学の用語を借りて使ってはいるが数学でのその用語の表していた概念を尊重しているとは限らないということだ
そういう例、つまり数学用語を数学での概念を尊重しない形でプログラミング言語の世界で借用してしまっている例は探せばいくらでもあるだろう
そもそも = が代入って時点で数学と違うんだから
いちいち「厳密な定義がー」いう方がどうかしてる。
普通にWikipediaでタプルをしらべたら一要素のタプルの事をシングルというと
書いてあるのだがｗｗｗ
>>522 数学の定義や数式を計算機上で実行するには、
必然的に「解釈」という(あるいは「評価」とも呼ばれる)プロセスを伴いますから、
数学の概念とプログラミング言語との間に乖離(かいり)が存在するのは一般論ですし、
その為に計算機工学という分野で研究成果が積み重ねられてきました
もちろんこうした乖離は一般論ですから、例を探せばいくらでも挙げられるでしょう
たとえば「n個の直積を考える」場合に数学では n=1 や n=0 を除外しないモデルを
構築することは可能ですが(
>>517,521)、計算機工学の研究成果を元に設計された
言語だと「n個の集合の直積を考える、ここで n>=2」が暗黙のうちに認知されています
（なぜなら n=1 または n=2 の直積は、一般的には形式的に定義できない為）
ところが、こうした計算機工学の成果である n>=2 を無視し、
そんなのどうでもいいとばかりに「単なる不変な配列をタプルと命名する(
>>516)」といふ
深淵の淵へ自ら飛び込んだ稀有な例が Python といふ次世代言語なんですよ
もしも「他のあらゆる言語では計算機工学の常識に沿って設計しているのに、
ある特定の言語ではそれを無視している」という具体例があれば、ご教示願います
たとえば「Python におけるタプルの命名」は、他の言語には見られない唯一無二の例です
A = { x | x <- A}
A × B = { <x, y> | x <- A, y <- B }
普通に定義できるがｗｗｗ
>>478
>それはそれとしてPythonはもっと関数を横に繋げられるようにしてくれ
>Elixirのパイプ演算子みたいな感じでさあ
いや、新たにパイプ演算子みたいな構文を追加しなくても、
オブジェクト指向言語の Python であれば、メソッドチェーンで実現できるよ
だって、Python を除く今時のオブジェクト指向言語では実現できていますから
その具体例が >>430 のリンク先のブログ主様が書いた簡潔なライブラリです
問題は、「なぜこれをやろうとしないのか？」という点です
もちろんライブラリの後方互換性は失われますが、
python2 から python3 で致命的な「後方互換性の断絶」を断行したのが
Python ですから、一貫性のあるAPIを提供するライブラリへの刷新もできたはず
さらに根本原因にさかのぼれば、「なぜ最初から一貫性のあるAPIを設計しなかったのか」
といふ疑念に突き当たります
だって、Python を除く今時のオブジェクト指向言語では設計できていますから
最後に背景原因を考察すると、Python 作者のGuido氏が：
API の設計において一貫性などはクソ
と考えていたのか、それとも：
オブジェクト指向が流行っていたから行き当たりばったりに設計した、
今は後悔している
と考えているのか興味深い >>526 >A = { x | x <- A}
えぇとぉ、{ x | x <- A} というのは単に集合 A を内包的に定義してるだけですから、
それは「1個の集合Aから構成される直積」ではなく単に「単純集合A」を定義してるだけです
あぁそうか、フェイトニスタには内包表記うんぬん以前に、数学の教養が欠けているのですね
ついうっかりしておりまして、大変失礼をば致しますた
うっかりミスを訂正：
>>525
X：>（なぜなら n=1 または n=2 の直積は、一般的には形式的に定義できない為）
O：>（なぜなら n=1 または n=0 の直積は、一般的には形式的に定義できない為） 定義するのに集合と同じ定義では同じでは駄目というルールはないから間違っては無いｗｗｗ
ちなみにｎ=０の直積は１元集合として定義できるとWikipediaにかいてあるｗｗｗ
正式な定義だと、直積の要素はペアの中にペアがある構造じゃないと駄目ｗｗｗ
A × B × C = { <x, y, z> | x <- A, y <- B, z <- C }
↑の定義があってるのは日本のWikipediaだっけでしたｗｗｗｗ
これを使うにはn-fold Cartesian productという直積を拡張した奴じゃないとだめでした残念ｗｗｗ
とくにｎ＝１の時はそのままA＝Aとちゃんとした本に書いてあるｗｗｗｗ
今までの流れをまとめるとpythonはクソ。
TypeScriptが最強。という理解でよいでふか？
メソッドチェーンでもリスト内包でも異常なまでのテンポラリ変数嫌悪を感じるのだが、
無理にそんな書き方するくらいならテンポラリ変数使えや。
メソッドチェーンは無理なく書けるでしょ
変数はバグの餌だから忌諱するのは当然
変数があって嬉しいのはデバッガでステップイン実行するときだけだな
そろそろステップの概念を卒業した新発想のデバッガが必要な時期にきてると思う
一時的な内部処理でまでステートを毛嫌いする純粋病の関数型信者と似ている
お前らみたいなドカタなら兎も角、数学者がn=0やn=1に自然に拡張できる定義をn>=2に限定するわけないじゃん
ドカタここに極まれりだな
プログラマならバグの素を毛嫌いするのは当たり前じゃん
あくまでリーダビリティを損ねない範疇でだけども
>>540 途中でクラスが変わるようなメソッド呼び出しを10個も20個もチェインするヤツは知らんが
コレクションに対する操作を数個チェインするぐらいは別に普通じゃね
>>539 ちゃうやろおっさん
型理論的にはn>=2に拡張するために持ち出すのがpair
なのでn=0,1にpairを持ち出す必要がない
別の言い方をすると型理論的にはAと<A>は同じ
そこを区別するのがアドホックにpairを導入した言語ということ
組み込みの土方より
>>541 たとえばコレクションのフィルター関数を実装するようなときに
一時的にミュータブルなコレクション作ってループ回して最後にイミュータブルにして返せばいいようなものを
最初の要素が条件満たさなかったらそれを落とした新しい不変コレクション作って返す関数の再帰で書くようなゴミが純粋病
>>541 バグの元の一番大きなものは可読性のなさだぞ。
測りにくいものを一切無視するのがこの手の輩のダメなとこだな。
>>544 なにそれこわい
それってなんというテクニックなの？
>>545 だから可読性を損ねてはならないって書いてるじゃん
俺のレスは可読性低かったか？
>>542 コレクションの操作ってのが具体的にどういうのかしらんけど
(おもちゃのような例は勘弁)
初見のコードだと返り値が何なのか副作用のありなしもよくわかんないのが嫌い
組み込み屋なんでそういうのに神経質なんですわ
>>543 お前みたいなドカタには同じに見えるんだろうけど
違うものだよ
>>548 おもちゃのような例とやらがなんだか知らんが
「配列にフィルタかけてマップしてソート」みたいなのはメソッドチェインで書くのが普通だし
プロダクトコードで頻出するし
言語組み込みとか標準ライブラリの範囲なので仕様知らないのは知らないほうが悪いで終了
組み込み屋だからコードが読めないって言い分が通用するのか
b=a.filter(hoge).sort(piyo)はaが変化しないけど
b=a.sort(piyo).filter(hoge)はaが変化するJavaScriptとかもあるし
気持ちがわからんでもない
c=a
b=a.sort(piyo).filter(hoge)
a=c
jsのsortはソート結果を戻り値でも返すからよくないんだよね
rustは関数が破壊的な操作をするか一目で分かってよいんだよね
関数の副作用や純粋性が気になるなら
関数型の言語さわるのも良いぞ
F#は宗教論争に発展せず
現場でも実用十分的
>>552 マジかー。副作用あるかないかわかるようにしてほしいわ
>>550 > 言語組み込みとか標準ライブラリの範囲なので仕様知らないのは知らないほうが悪いで終了
なんでそこで特定の言語前提になってんの？w
標準の範囲なら百歩譲ってありだけど標準だけのデザインという保証はないやろ普通
あといちいちAPIリファレンスで確認しないと使えないってのは言語の可読性低いとも言えるわ
批評家が口だけで問題解決することを理想としているように
可読性は目だけで解決するのが理想的である
>>559 土方は古代言語をメモ帳で書いてるのか……
写像や部分集合、ソートなんぞはほとんどの言語で標準で用意されてるし
IDEなりプラグイン入れたエディタならリファレンスはマウスオーバーするかショートカット叩くだけだよ
>>523 > そもそも = が代入って時点で数学と違うんだから
それは単なる記法上の問題であって本質じゃない
C一族みたいないい加減な言語でなくAlgolやPascalのなどの正統派Algol系言語のように代入を表す記号を “:=” で書く言語であっても変数の概念が数学のそれと全く違うという問題はCなどでの変数と同じ
見掛け上の記号の使い方がいい加減という問題と、ある用語で表される概念がいい加減（間違っている）という問題とはレベルが全く違う
それが何レベルなのか知らんけどどうでもいいじゃん
数学とプログラミングは別物なんだし
>>565 タプルがどうとかも十分同じレベルだろ。
そんなところで誤解して問題起こす奴なんて代入以上にいねーわ。
自分の理解の都合でイチャモンつけてるだけってことにそろそろ気づけや。
>>554 c=aではオブジェクトは作られないので、そうやってもaは変化する
更に言うと
c=a
b=c.sort(piyo).filter(hoge)
でaが変化する
こういう話を見ると言語としてイミュータブルな変数しかない言語が良い気がしてくる。
「いふ」とか言っちゃうイタイ奴にろくなのはいないな
>>518 いつ誰が「メソッドチェーン vs 内包表記」なんて下らん比較したんだよ
内包表記は内包表記で便利だっつっただけで、
メソッドチェーンつーかポイントフリースタイルが内包表記があれば不要なんて言った記憶は少なくとも俺にはないな
つーか
>>478下段、まさにPythonにはポイントフリースタイル実現する記法が足りねえっつってんのが読み取れねえのか？
今時エセ歴史的仮名遣いで書き込むクルクルパーは国語の勉強しなおした方がいいぞ
ずっと数学言ってるやついい加減うぜえわ
別スレ立ててそっちでやれやボケが
JavaScriptのsortとreverseが破壊的なのがぱっと見わからないのも、
JavaScriptの命名規則がうんこなだけでメソッドチェーン自体の良し悪しとは関係ない
関数合成大好きな関数型バカがメソッドチェーン腐すの、マジ笑えるww
>>573 こればっかりはなぁ。後発の言語は、副作用有無が明示されるようになってほしい。命名規則とか人間が頑張るタイプはやめて
webサービス作るとき。というかrdbとの連携って静的言語より動的言語のほうが向いてる気がするんだけど、そんなことはない？
typescriptなしにjavascriptを書こうとは思わないからな
頑なに副作用嫌ってる人意味分からん
java.awt.Graphics2Dとかにあるような
コンテクストオブジェクトをイジイジするのってめちゃ便利やんけ
>>575 バカは引数のconst外してでも副作用入れてくるから言語で規制するって発想自体が無駄。
1行に書かなきゃどんどん一時変数を増やさなきゃならない関数パイプラインはそれなりに意義が
あると思うけど、そうじゃないメソッドチェインはわざわざ見にくい1行の式にしなくても、と思う。
とはいえtypescriptは型情報が嘘つくことあるのがしんどい。ないよりはマシなんだけど。
いまいち信用できない。
jsに、標準で型情報ついてくれないかなー。
嘘つき「何も宣言しないよりはマシ」
付け焼刃「何もしないよりはマシ」
ギャンブル依存症「何も賭けないよりはマシ」
TypeScriptはもうデファクトスタンダードなのよね
なぜ病気とか健康とかなんですか
悪とか正義とかではだめなんですか
病人は生産性がないなんて言ったらたぶん炎上するし
悪人は生産性がないと言う方が無難だと思うけどなあ
生産性がないならまだいいが生産性がマイナスな輩というのがいる。
こういう輩を見るとベイシックインカムはいいんじゃないかと本気で思うよ。
やっぱ副作のないメソチェが最高やろ
リス内記は読つら
初心者用の言語は上級者の要求を満たすことが出来ないということだな。
上級者が初心者用の言語使うのが間違ってるな。
haskellを使えば副作用を分離出来るし、メソッドチェーンも出来るし、
直積のタプルも0次元からN次元まで使えるし（1次元は普通の集合）
解決だな。
ハスルケはセパレイタとしての記号が少ないからリイダビリティが悪い
そして誰もいなくなっただろう
Haskellはタプルを使わなくてもコンストラクタのアリティを2以上にできる
多変数コンストラクタの具体例のひとつにすぎないのがHaskellのタプル
1変数コンストラクタも無数にある
だから a と (a,) が同じ型にならないPythonを見ても違和感はない
>>601 オレオレ略語とか変なカタカナ表記とか、お前さんのレスもreadability低いぞ
>>598 だからなんでリスト内包vsメソッドチェーンの対立になってんだよ
ハスケルはエコシステムが腐ってるという話を聞いたけど本当？
言語がいくらすごくても環境構築で、しんどい思いするなら用無しなんですが
理論ばかりの頭でっかちの奴等ばっかりだからな。
実用性なんかどうでもいいんだろ。
だから実用されないんだよｗ
>>607 パッケージ管理ツールのcabalもstackも依存把握がすぐぶっ壊れる。
あれは何が副作用がないからバグが少ないだって気分になるわ。
1. 関数プログラミング自体が実は大したことない
2. 副作用禁止の強制が邪魔
3. 使ってるプログラマーのレベルが低い(偏屈しか使わない・ユーザー層が薄い)
4. まだ成熟していないだけ
どうだろう。4だと思いたいが…
・Web系→モデルやロジックが単純なので関数型のメリットなし
・ゲーム系→常に時間変化を扱うので関数型のメリットなし
・業務系→PGの単価が上がって割に合わないので関数型のメリットなし
関数型の定義が未だに分からない
2だけならどの言語でも原則として受け入れられているんじゃないの
関数型はテストするまでもなく結果の明らかな極めて宣言性の高いコーディングができるというのが実用上最大の強みなわけだけど、
関数型マニアの関心は主に無限リストやら再帰やらモナドやら、自らその宣言性を捨てるテクニックにばかり向いていて、
結局関数型の何が嬉しいのかよくわからん状態になってしまってるのが現状
具体的にはどんなコードになるの？
そんな単純なコードの断片だけを組み合わせるだけで実用に耐えうる可読性や性能を発揮できるもんなの？
関数単位、メソッド単位でなるべく純粋にしておくのは重要
短い関数内部の実装まで純粋にしようとするのは宗教
平気で数百メガあるようなデータに対して副作用のないメソッドチェーンで加工するのって普通にやることなの？
>>617 そういうのはステップ毎に一時ファイルに書き出すのが普通でしょ
COBOL時代からの伝統的なスタイルであり、今でもHadoopなどに受け継がれている
副作用がなくむしろ関数型的だ
遅延評価だったりストリーム使えるんなら大体気にしなくていいんじゃないかね
関数型言語の本質は関数そのものを柔軟に扱うことだと思うんだけどな
例えばジェネリック関数のある言語ではジェネリック関数をジェネリックなまま引数や戻り値として扱えないと関数型言語っぽくない気がする
>>613 副作用はよろしくない、というのは確かに広く受け入れられている。
でもHaskellなどが要求する基準は、もっとずっと高い。
ちょっと前にstackツールのコードを見たことがある。今どうなってるかは知らんが当時は、
ある純粋な関数の中でデバッグ用ログをより詳細に出力するってフラグを、ソースコードに即値でベタ書きしていた。
これは他の言語では例えば環境変数を読み込む関数をその場で実行すれば良いだけなのだが、
Haskellでそれをやろうとすると、関数のシグニチャを非純粋なものに置き換えて、使用する全箇所も合わせて換えるか、
あるいはフラグを引き渡す配管を新設するか、などの工事が必要になる。
>>620 それは勘違い
遅延ストリームでステップ毎にコピーしてるんなら、コピーするオブジェクト数はバッチでステップ毎に全件コピーするのと変わらん
というかメモリアクセスが細切れになる分だけ遅くなる
遅延ストリームはレイテンシの低減には有効だけどスループットも下がるよ
...という工事が必要になる。だから仕方ないと言えなくもない。
このような事態は純粋な言語では良くあるのだが、このことだけで、すわHaskellあかんやん、は早計だと思う。
Implicit ParametersやGivenのようなアイデアも出てきてるし、これは解決する余地のある課題なのかもしれない。
あるいはこのような事態を引き起こす設計に問題があるのかも。
次世代言語たって、シングルスレッドのJSをこねくり回してドヤってる人と
Native言語でハードウェアの性能を最大限引きだそうとしてる人とで
必要とするもの違うからいっしょに議論してもかみ合わない
そもそもハスケルの仕様通りの評価順序で実装してたらまともな実行速度でないっしょ。
そういうごまかしを含んでる時点でしょーもねーわ。
副作用はよろしくない、といってるくせに再帰やら遅延ストリームやらモナドやら状態依存のコードを好んで書きたがるのが関数型マニア
そもそも状態に依存するコードなんか極力書くな、避けられるならモナドなんか使うな、という正論を言えない空気があり、
競って予測困難で難解なコードを書いて「俺すげえ」のマウント合戦を繰り広げている
こんな状態で流行るわけがない
状態依存は避けられないのに状態を禁止してしまったからやたらと状態関連が発達してしまっているけど、状態なしで書ける部分と状態が必要な部分を分けて書くという理念は守られているはず……
Haskellの定義を知ってる人ならいるけど関数型の定義は誰も知らないんだよ
だから「Haskellは関数型である」とか
「Haskellマニアと関数型マニアは同一人物である」とかいう根拠がそもそも存在しない
つまりおまいらはまたオブジェクティバラブルなコード時代に戻るというの？
関数型言語の定義ってラムダ計算を計算モデルにしてる言語でいいだろ
そのラムダ計算には型があるのかないのか
副作用があるのかないのか
なにも定義されていない
型なしラムダ計算だったとしてもlispだし型付ラムダ計算だったとしてもML/Haskell/etc…だし広義には問題なくない？
副作用の有無=純粋性は程度で片付けなきゃやってられない(どの汎用言語にもプログラムならどこかしら副作用が存在する)し
定期的に定義に固執しすぎなレス見掛けるけど自分でその問い掛けを考えたか？って感じなのが多い
計算機科学の研究課題としては興味深いが
プロダクション用途ではないだろう
だから何が悪いというわけではないが
>>614 がいいこと言った。
見通しが良いコードにするための宣言型言語のはずが
むしろ見通しを悪くしている。
Scalaという見通しの悪い言語が関数型として世に知られてしまったのも不幸だったよね
意識高い系のオモチャに選ばれたのがScalaではなくF#だったら状況はだいぶ違っていたのではないか
状態に依存する部分と純粋な部分を切り分けること自体は純粋関数型言語じゃなくてもできること
そもそもHaskell使える開発者が集まってるならHaskellじゃなくてもみんな極力そのように書くし、
強制されないと副作用ごちゃまぜコードを書くような土方はHaskellは使えない
純粋性を強制するメリットが禁止して柔軟性を失うデメリットに釣り合ってない
純粋性を強制するメリット、を考えてみた。
例えばエディタの設定ファイルをHaskell自身で書くことができる。
設定ファイルがSafeHaskellであることを要請して、かつ設定操作に限定された型のみを許すようにする。
これで設定ファイルに、勝手にビットコインを採掘するスクリプトを忍ばせるような悪さができなくなるし、
Haskellそのものの柔軟性を活かして好きなだけ設定を短く表現できる。
安全さと強力さが両立された。
Haskellは状態に依存するコードを書こうとすると途端に
可読性の低い冗長なコードになるのがダメなところだと思う
純粋な部分の構文に比べて手抜きすぎなんだよ
手抜きではないだろ、むしろ逆
worldを隠しつつ宣言的に書くという変態技のために
モナド用の構文糖衣が多数あるせいで関数型の簡潔さが失われている
シンタックスシュガーを幾ら用意しても簡潔に書けるようにする工夫がないから
どう書いても冗長って話なんだけど？分かってないなぁ
それは手抜きと表現すべきではない。わかってないなあ
>>642 じゃあ例えばどういう工夫なの？
お前のHaskellの理解力が試されてるから慎重に答えてね
無理なら別に逃げてもいいよ
工夫するたびに言語の差は大きくなって言葉が通じなくなる
逆に言語を一つにしたければチューリングマシンだとかラムダ計算だとか
人が手を加えないまるで手抜きのような方向に行けばいい
>>644 そうだなぁ。何でもいいんだけど、たとえば in-place quicksort をHaskellで可読性高く書けるかって話ですよ
いままでCにも劣る可読性のコードしか見たことないわ
だから、お前が可読性高い in-place quicksort を書いて見せたらこっちの意見は取り下げてもいいけどね
無理なら別に逃げてもいいよw
関数型は実行モデルに由来する制約が少なくて言語設計の自由度が高い分、アイランドモンキー族にとって馴染みにくいものになってると思うんだよな
「結論から言え」なカルチャーが色濃く出すぎてる
>>646 お前の可読性の基準なんかこっちはしらんがな
お前が言う工夫が例えば何かって聞いてんだよ
まさかノーアイデアで批判だけしてんの？
可読性が低く冗長なのが問題だ。簡潔に書ける工夫があればよい。
例えばどういう工夫が？
例えば in-place quicksort が問題だ。簡潔に書ける工夫はないだろ？
----
まあ問題意識は判った。確かに可読性と速度の両立は課題だと思う。
CとHaskellの両立ができないやつは二刀流を自粛している
これは自粛であって禁止ではない
あれっひょっとして
>>642 は
「もっと状態方面を簡潔に書けるよう工夫しろよ」って非難してるのか。
だとしたら誤読だったすまん。
インプレースに書かなくてもインプレースにしてくれるのが stream fusion
副作用を書かなくても書ける（副作用禁止とは言っていない）
>>633 > そのラムダ計算には型があるのかないのか
> 副作用があるのかないのか
副作用を入れたものは本来はλ計算ではないよ
そういう変てこなバリエーションをデッチ上げて「何ちゃらλ-calculus」とか呼んで発表してるのは幾らでもあるがゴミばかり
状態などというものを考えず単純に構文的な置き換えだけで扱えるλ計算の長所を破壊し放棄する拡張をしても何もメリットはない
単にほとんど誰にも論文のカウント数を１増やすだけ
まあ御当人の学位取得や助教職のアプリケーションには有効なのかも知れないが
>>654訂正
誤> 単にほとんど誰にも論文のカウント数を１増やすだけ
正> 単にほとんど誰にも読まれない論文のカウント数を１増やすだけ
モナドクラスは副作用を入れたinstanceと入れないinstanceの見た目を同じにする
副作用を禁止しても見た目が美しくなったりしない
Haskellには副作用を禁止するモチベーションがない
>>648 ここはHaskellスレじゃないんですよ？
ゴミ言語にはゴミである理由さえ説明すれば十分ですよ
Inplaceが必要な時はHaskellを使うべきではない
Inplaceが不要な時に力を発揮する言語だし、Inplaceなんて避けておけというメッセージのこもった言語だ
>>659 それって言い方を変えると
HaskellもPythonみたいにクリティカルな部分はCで書いてそれ呼び出せ
って解釈できる気がするんだが、そう解釈しておk？飛躍しすぎ？
たかがin-placeが必要なだけでCの助けが必要って？
そんなウンコは次世代言語に相応しくないな
>>662 なるべくin-placeは避けろという言語に対してin-placeがかけないなら云々とかもう思想が合ってないとしか言いようがないな
Haskellは富豪プログラム専用。in-placeがどうしても必要になるような貧乏人の道具ではない
副作とノー副作を合一合体して書けるScalaサイキョってことか？
関数型言語に学ぶ価値はあるけど使う価値はないっ昔から言われてるじゃん
Monad勉強してへーうまくできてんなー(実行効率悪そうだけど)
って思っときゃいいの
そして最近の言語はOptionalとかいいとこだけうまく取り込んでるわけだ
既存の手続き型言語で培われてきたアルゴリズムは
ミュータブルなデータ構造に対して最大限の効果を発揮するものなんだから
イミュータブルなデータ構造が基本の言語で同じことをやろうとするのが誤り
イミュータブルなデータ構造の方が速い、ってケースはあり得るのかしらん
速いってケースは思いつかないけど(ヒープを遠慮なく使う時点でたぶんアウト)
SSAとかは興味深い
なんか俺がいなくても結局誰かをガイジ呼ばわりして叩くスタンスには変わりないんだな
ビットコドンドコで大負けくらってる僕よりガイジーヌなやちゅなんておらんJARO草ァwwww
んでさでさ、Inplaceて何ンゴンゴ？＿？
宣言的に書くならC#のLinqよりF#で書いた方が速いね
もちろん速くするだけならC#の方が速いけど
>>670 金融、財務とかかね
stackoverflowのアンケでは給料の高い人が使ってる言語の１位になってるし
日本じゃほぼ使われてないのかもしれんけど
GoもKotlinもTSももう次世代じゃなくて現世代だな
関数型言語が高いんじゃなくて関数型言語使えるような人は土方と違って生産性も収入も高い人が多いってだけなんだよな。
なんでもそうだけど、役に立たない仕事ほど年収が高いんだよね。
役に立たない仕事で収入を得るのは特別な能力が必要だから当然
Google社内では本当にDart使用していると言い張っているようだな
>>684 それな
ここは次世代スレだからそろそろ退場して欲しい
最近の言語ってなんで文末のセミコロンを無くしたがるのかはホント理解できんね
正解が二個以上あっても正気を保てるのは言語オタクだけだ
だから改行を唯一の正解とする
改行の強制はインデントの強制でもある
>>691 じゃあ次世代言語上げてくださいますか？
次世代言語って、現世代では全く使われていない言語を指すの？
そうなると、ここでは書いたことの無い言語の話しか出来ないんじゃないかな。
もう少し冷静に、新しいか、成長の余地がある言語にすりゃ良いかと思うよ。
新しくもないし凝り固まってるしパラダイムも充分に理解されてるがメジャーではない言語、を入れるかに悩むならわかるけど。
Javaみたいなゲージ御用達スーパーゲージ変換じゃなけりゃなんでも良いだろ
>>699 業務でってのが一つの基準な気がするけど
スレタイの中だとrustかswiftくらいしか成長の余地なくない？
kotlinは生まれながらにしてjavaの業を背負ったどん詰まり言語じゃん
だって必要ないじゃん;
意味ある？;
これ;
(;_;);
てか何気にRustよりGoの方が古いってのは意外だったな
>>706 実行環境についての話でいいなら、Kotlin/Nativeが成長途中という状況だよ
>>709 kotlin nativeはjavaに足を引っ張られたkotlinに足を引っ張られるんじゃないかと勘ぐってるけどそんなことないのかな？
それは逆コンパイルしたら中身jvmだったりしないの?
>>681 これ見るとkotlinよりscalaの方が求人多くね？
kotlinも死んだ？
求人件数だけ見るなら ruby 一択だろう
しかしなんだかとても嫌な予感がしないか？w
そんな数字の話をするだけなら靴磨きの少年でもできるからな
>>718 クッソゴミみたいな保守やらされそう
今やRubyもPHPに匹敵するレベルの糞になりつつあるな
rubyは散々馬鹿にしてきたPHPと席を分け合うポジションに収まったのが笑える
rubyが笑えるのは散々バカにしてきたjavascriptの後塵を拝してるどころか3周差くらいつけられてなお離されてる最中なところ。
rubyやたらディスられてるけどphpみたいにapiに一貫性がない感じになってるの？
>>704 Rustは既に方向性失敗して、2018editionとやらで互換性壊してなんとかしようとしてるらしい
成長の余地どころかぱいてょん（爆）の後追いで死にに行ってる
Swiftも似た感じだが、圧倒的なプラットフォームパワーでなんとかなってる
elmはどうなん？別なチームが社内ツールで使おうとしてるけど
>>724 ぱいちょんと違って何も変えなければ動くんだから事情は違うでろ
コンパイラ言語なら互換性を無理に維持しなくていいと思うけどな
2にしがみついてる老ガイどもを皆殺しにするウイルスでも仕込めばいいのにな
>>723 Rails全盛期の頃に比べると開発端末としてWinが復権してきたのが大きいんじゃないかな
Python をはじめとして Node, Go, TypeScript, VSCode など、比較的Winと相性のいいツールが全体的に伸びてる
>>729 こういうカス発言してる奴がクソコード残して逃げてくんだよな。
>>731 おっ ２にしがみついてワイに殺される予定の老ガイか？
そういやRubyってRPGツクールの拡張スクリプト枠JavaScriptに取られたんだったっけ？
Kivyのクロスプラットホームで未だにPython2しか対応してないのがガッカリだな
>>733 明日から2が動かなくなってもnumpy, scipy, matplotlibを使ってる連中は全く困らないし、
その辺のユーザを掴んでる限りPythonは安泰だよ
perl5とpython2とpython3を全部インストールしても他の言語1個分より小さい気がする
お前ら、Dartが何か呼吸してるのを気にかけてやれよ
Dartの功績は、SEOによる情報操作だけでは言語をゴリ押しできないことを証明したこと
Dartを「ごり押ししても」メリット無いってきづけよ。Dartをごり押しして、何のメリットがあんだよ？答えてみろよ！？
googleが言語仕様をコントロールできるからね
新OSもLinuxから離れてるし内製への拘りが強くなってる
goが示したのは
クソ言語仕様を押し付ける暇があったら実装の性能をあげた方がよっぽど良いって事。
どうせ馬鹿に高度なものは扱えないんだから
馬鹿でも使えるものだけ与えた方が混乱がないってこと
馬鹿にも理解できる言語仕様だからといって
馬鹿でも素晴らしい成果物を得られるわけではない
かと言って頭のそれなりにある人間も頭抱えるような言語じゃ開発サイクルも早くは回せんけどな
>>752 Generics実装してmapとかreduceとか使えるようになれば申し分ないんだけどなぁ
Javaのぱくり言語とUnixのぱくりOSはいちいち説明しなくてもわかる
ぱくりじゃないところだけ説明しろよな
大体なんでAndroidの標準開発言語Goにしなかったんだろうな
>>741 Googleがなんで機械学習系のライブラリを2系でしか出してないか知らないのか
まともに安定してnumpyまわりが動かないからだぞ
>>742 Rustっていう、現在進行形で情報操作でごり押しして
ある程度バカがつられてる言語があるんだよなあ
そういう意味でDartに対するGoogleの姿勢はまだ技術には誠実だと言える
>>756 tensorflowも3で動くぞ
マジでしったかだなw
>>758 お前のそれ本当にtensorflowなのか？
いや普通に tensorflow1.8.0 は python3 で動いてるぞ。
google cloud 周りは確かに python2 系統だが。
互換性周りの話って、python3推しもpython2推しも普通に嘘つくから嫌なんだよ。
自分の都合のいい話しか信じないっていうのが露骨に出る。
>>756 numpyまわりで3系だけの不具合って何？
まともに動かないと言うくらいなら、いくつも例を出せるでしょ？
え？出せない？思いつきで言っただけ？
嘘ついても全ての人を騙せるわけではない
情弱が多数派でなおかつ多数決は正しいという前提がなければ騙せない
多数決やめればいいだけだ
>>760 いやTensorflowが3系で動くこと自体がはっきりいって眉唾
公式じゃ動くって言ってるが手元で動いたためしがない
>>761 そもそもインポートでエラー出るんだよなあ
>>762 多数決とろうが動かないものは動かないし、動いてるものは動いてるんだよ。
>>763 だから普通に手元で動いてるっつーの。
少なくともうちの会社の中で問題が生じた奴はいないし、
問題が生じるのは大抵cudaに対するバージョン依存くらい。
お前の環境がイかれてるだけだろうと思うが他の奴にも聞いてみたの？
python3でgoogleが問題になるとしたらプロトコルバファ周りくらいだろ。
あれはもろにstrの変更の影響を受けるのはなんとなくわかる。
>>763 ＞公式じゃ動くって言ってるが手元で動いたためしがない
それお前が馬鹿すぎるだけじゃんw
お前みたいな低脳にはDNNなんて無理だから諦めろwm
python3でcudaやtensorflowがセットアップ済みのdocker imageあるから、素直にそれ使えやw
typescriptのジェネリクスのヤバさを目撃すると、どうにもgo2でジェネリクスを導入するのは見送ったほうが良い気がする。
少なくとも、慌てて入れるんじゃなくてgoらしく独自な感じで頼みたい。
同じ家だか会社だか学校の回線使っての意見対立か何かか？
ここでいくら python3 へ移行しても無問題と叫んだところで、
未だに macOS ではデフォルトが python2 のままという事実からは
逃げられないんだな
おまけに次期バージョンの Mojave に至っても、プレビュー版では python2 だし
・Apple、macOS 10.14 MojaveにもPython v2.7.10を同梱？
https://applech2.com/archives/20180612-macos-10-14-mojave-beta-with-python-v2-7-10.html >>729 からすれば Apple は「2にしがみついてる老ガイ」らしいけど、
Apple を罵倒できる男の子ってカッコイイなぁ(棒
>>774 vertualenvどころかhomebrewも使わずにシステムのpythonにnumpyやtensorflowとか入れてんの？
完全にアホじゃんww
こういうアホの子も機械学習に手を出してるのを見ると俺もやらないとって思うけど、解決したい問題が無いという
珍しく弱気だな
いつもならノーベル物理学賞ですら、それ何の役に立つの？って強気で問い詰めるくせに
>>770 tsのジェネリクスのヤバさ詳しく
興味ある
型がない言語に型を持ち込んだからだって突っ込まれるかもしれんけど、
こんなことになる可能性はジェネリクスを持つ言語全般に言える。
ちなみにジェネリクス関連のエラーにぶつかるとさっきのリンクみたいな型情報をエラーメッセージに垂れ流して直せって要求してくる。
>>774 AppleじゃなくてもどのシステムでもWindows以外はデフォルトはPython2だよ
だからこそPython3にはシステムが依存せずに最新版選ぶ事ができるんだから
Go
Gnericsできることは中身なしのインターフェース型（interface{}）できるからいらないって言う人もいて
確かにできるんだけども
欲しいって言ってる人はできるできないじゃなくて実行前にエラー教えてほしい（せっかく静的型付けなんだから）って人たちだから
できるからいらないって言っても納得しないんじゃないの？
"で"できる
が
できる
になって意味不明の文章になってる
すまん
>> 779
これ、redux に型情報書こうとしてるからこんなことになってるだけで、
int,doubleで2回も同じの書かなくていいみたいのだったらこんなことにならんけど...
>>783 空インターフェイスが問題なんだから、それが絶対に使わないようにする方法があれば良いんだよね。
goにおいてはcode生成が一つの答えだったりする。
>>781 え、
>>774 のリンク先にも書かれている2015年に公開された
Python の公式文書 PEP 394 もご存知ないんですか？
Windows以外の「どのシステム」というのが曖昧ですけど、
すでに主要な Linux ディストリビューションだと
デフォルトのインストールは Python3 になって移行を完了してます
・LinuxディストリビューションにおけるPython 3デフォルト化の流れ
https://orangain.hatenablog.com/entry/python3-as-default だからこそ、それでも Python2 のデフォを維持しようとする
Apple は「老ガイ」なのか？と
>>774 で問題提起したわけです
もう少し Python を勉強したほうが良いのではないかと思われます
しがみついてるんじゃなくて放置してるって読めるけど
>>786 コード生成はひと手間かかるから敬遠してしまう。
コード書き換えたら再生成しないといけないし、
やっぱりC++やRustみたいな感じでジェネリクスくらいはできてほしいと思ってしまうなぁ。
前メジャーバージョンのサポートを十年以上続けてきた言語って何なんだろうね
>>790 ジェネリックってもの自体が実際それくらい手間かかるものって認識した方がいい。
だからエラー出た時に追いづらいわけで。
マクロにしろテンプレにしろ本質的には生成系だよ。
rustがあるのにgoの未来に期待する必要ないよね
>>793 goaとかコード生成を多用するフレームワークにさわると実感する。
生成されたコードは読みやすいし、
追いやすい。
ジェネリクスは書いてる最中はともかくエラーが出たときに、対応が難しい。
あとgoの言語仕様自体がコード生成に対して最適化されてると思う。
>>787 そうなん？CentOSは保守的だからさておき
RaspbianもPythonって打つと2が動いてたから
まだまだ2がデフォなんだと思ってた
あとAndroidのPython3もいつになったらKivyに対応するんだかね
つい最近QPython3をスマホに入れてkivyのサンプル動かそうとしたら2でやれってメッセージ出たんだけど
ジェネリクスのエラー対応が難しいってよくわからないなあ・・・
ジェネリクスでエラーでるって言っても複雑な型地獄にはまって出るものと、
結局実行時にエラーになるから教えてくれるものがあるし
後者なら別にエラー直すの難しくない
型地獄にはまるのって関数型言語や関数型インスパイアにフレームワークで厳密に型定義しようとした時しか思いつかない…
あと、ジェネリクスって言っても文法上は同じでも種類があって
C++…
超高機能なマクロみたいなもの
全部インライン展開される（実行効率はいい）
コンパイルに時間がかかるし、実行ファイルサイズが膨れ上がる
Java…
Java バイトコード上は generics に対応していない
Java コンパイラがキャストを自動的に挿入してくれる
いわゆる「型消去」
C#…
ILにgenerics 用の命令がある
ャストの分のコードが減って実行効率がいい
ボクシング不要
って種類がってGoはどれになるか...
> goの言語仕様自体がコード生成に対して最適化されてると思う。
ここまで書いといてあれだけど
確かにこれは同意だなあ
>>794 RustがGCで動けばRust使ってた。
所有権システムがややこしくて挫折した。
>>793 C++使ってたことあるから、エラー出たときの追いづらさについては、個人的に少々目が瞑れる。
Goで新しく実装されるなら、C++よりはマシにはなるだろう。
これ以上有象無象のプログラミング言語を増やすな
全言語LLVM対応してよ
所有権システムって、コンパイラに怒られる怒られない関係なく、C++使ってたことがあると言うなら考えていて当然だし、適応できて当然というか感謝するレベルだと思うんだけど、
何でrustアンチは「C++が書ける」みたいなハッタリかますの？
ややこしくて挫折したと言っているんだから、別にアンチではないでしょ
確かにアンチでは無いか。
言い方が悪かったな。すまん。
所有権意識しない奴がC++書けるって言っても、全然書ける気がしない違和感の事を言いたかった。
ただの入力補完はもう古い！
人工知能がコーディングを補助！
Visual Stuio IntelliCode
https://visualstudio.microsoft.com/ja/services/intellicode/ ・無料かつオープンソース
・Githubでスターの多いリポジトリで機械学習
・あなたのコードの文脈を理解した提案
・今のところC#のみ対応、別言語も提供予定
所有権システムの理解と所有権の意識は別の話だと思うけどな
C++と違って型パラメータでライフタイムの整合性取る必要あるし
今のC++はコピー上等の値型指向を右辺値参照でカバーする感じなところなど考え方がやや違う
rustがgoより劣っているのは学習コストの高さと開発支援ツール(racer/rls)がポンコツであることくらいだけども、誰でもコストが払えるわけじゃないし、ボローチェッカーにうんざりする気分は分かる
>>808 実際にrust書いてる人でも引数のライフタイムがそこまで全く違うようなコードは
普通書かないでしょ。
あれを複雑に設定しなきゃならんシチュエーションはそもそも設計ミスってる。
C++ならポインタにはdeleteの義務があるやつとないやつがある
参照カウントがあればカウントが1のとき義務があるのは誰でも理解できる
最適化などと称してカウントを省略するから分からなくなる
そもそもdeleteの義務のことを所有権というから意味が分からない
C++書ける人ならRustに感謝するってそんなこと言ってるのRustプログラマだけだろ
こんな仕様に感謝したこと一度もない
Rustの二次元配列の要素のswap
https://qiita.com/tanakh/items/d70561f038a0ef4f0ff1 MS嫌悪は病気と言ったというLinusが嫌悪したC++を書ける人だけが石を投げなさい
>>807 これに頼ったインチキプログラマが大量に湧いてきそうで怖い
ルーストにゴールデンカリバーン(GC)が実装されたら最強カードになるとオモｗ
>>812 何度もその仕様を憎むコードを書いたの？
unsafe事案なんだからunsafeで書けばいいじゃん
>>806 C++使ってたときは、所有権(どこでdeleteさせるか)に関して迷うほど複雑なことはしてなかったし、
C++書けるってほどじゃないです。ごめんね。
Rustは特にクロージャ絡んでくると所有権がややこしくて挫折した。
パフォーマンス気にしてRust使ったほうがいい場面もあるかもしれないけど、
GC使って楽できるならそうしたいっていう。
>>806 正論はときに人を傷つけるからやめとけｗ
kuso設計をスマポ（）で誤魔化してる連中には
所有権も借用もライフタイムもまだ早い
rustの1番の問題点はハスケルと一緒でこういう選民思想持ったバカが多いって事なんだがまあ気づかないで言語毎消え去るんだろうな。
それにしても選民思想って言葉が好きだな
そんなにお気に入りなのか？
よく選民思想だって言われてるけど単に一生懸命勉強したほうがいいよってことでしょ
プログラマにとってはそれが仕事じゃん
goとrustで実行に必要なコンピュータリソースに5%差があるならビジネス的には大きなアドバンテージになるのに、ややこしいからという理由で放棄するのはプログラマとしてどうかと思うよ
>>823 よく言われてるって…
今までこのスレで選民思想って言ってたの多分全部同一人物だと思うよ
俺の記憶にあるかぎりではどれも主張と口調がすごく似通ってるし…
まあいいけどね。。小難しく書くことに価値があると思ってるならそうしてればいいさ。
そのうち誰からも相手にされなくなるだけだから。
その位置からだと「小難しく書くことに価値があると思ってる」ように見えるんだなｗ
まあこれはインチキ人工知能が人間に勝つための作戦だと思う
人間が小難しいことを考えたら批判する
人工知能が小難しいことを考えたらほめてほめてほめまくる
なんの目的もなく「小難しい」事を書いてるわけ無いでしょw
そもそも理解すれば小難しくも何でもないし。
選民思想って言葉は、裏表あるが、選民の方の定義がよくわからん。
ついて行けた人間って事？
なら、ついていけなかった自分の心の平静を維持するために
「あいつらは理解できる人間で徒党を組んで理解できない人間をバカにしている」と思い込まないと仕方ないからのように見えるなぁ。
そうなると完璧に敗北を認めたような発言なんだし、選民思想云々と言って恥を晒さずにおとなしくしてりゃいいんじゃないかな？
自分たちのことを選ばれた民なんて自称する馬鹿は(滅多に)いないので
外から呼ばれる時の言葉に決まってる、という当たり前の話を長く書いてるだけ
>>816 板ごとの設定による。
言語学板とかは書ける。
rustで組み込みできないか調べ始めてるんだが
メモリまわり完全に使うがわで制御可能？
暗黙的にヒープ使われると見積りできなくなるからいやなんだが
c代替言語探しても全部そのへんでアウトなんだよね
妥協して適当なヒープ見積りで作るぐらいならcでいいやってなる
ヒープを使わないのは可能
ヒープを使うときはBoxに入れるので宣言的
平行処理向け、OOP、例外なし、漸進的型付け
https://inko-lang.org このスレ見たことも聞いたことも
無いような言語が出てきて勉強になるw
このスレで教えられた見たことも聞いたこともないような言語：
ponylang
plasmalang
redlang
nimlang
minlang
Wikipediaにあるプログラミング言語のリスト
1950年代 FORTRAN LISP ALGOL RPG COBOL
1960年代 CPL BASIC PL/I APL BCPL Simula LOGO B
1970年代 Forth Pascal C Prolog Smalltalk Scheme ML AWK SQL Ada
1980年代 C++ Objective-C Common Lisp Eiffel Erlang Perl Mathematica J
1990年代 Python Tcl Haskell Visual Basic Ruby Lua Delphi Java JavaScript PHP OCaml SuperCollider R ECMAScript
2000年代 C# Scala D F# Go Nim
2010年代 Dart Ceylon Elixir Hack Swift Rust Perl 6 Elm Julia Kotlin
90年代は豊作だったな。
>>839 なるほどそんな感じなのか
ヒープのライブラリをすげ替えるのは可能？
>>848 すげ替えとはどんな意味？
Boxは特別扱いされてるから挙動を変えたりはできないと思う
より具体的な話はrustスレがよいでしょう
chapelを誰かレビューしてください。気になってるけど試してないんだ
>>848 アロケータを変えたいという意味で聞いてるのなら一応可能だったはず。
「一応」っていうのは確かNightly(不安定版)だったはずってのと
使ったこと無いから正直俺もよく分かってないって意味。
因みにデフォルトのアロケータはjemallocだよ。
>>840 最初から漸進的型付とかバカちゃうか
型無し糞言語だからしょうがなく漸進的型付と型推論入れて糞をごまかしてるのに
最初から糞丸出しの糞とか糞以外の何糞なんだ？
UNKOLANGwwwwwwwwwwwwwwwwwwwwwwwwwwww
バカじゃねwwwwwwwwwwwwwwwwwwバーカバカwwwwwwwwwwwwwwww
型無しを見下すのも選民思想のようなものだな
HaskellやRustはこいつの手口に学んだのだろう
でも型のない言語で作られたプロジェクトの9割がゴミだったわ
PHP 5系とかほんと酷かった
サーバーがゴミ
スマホを見習うべき
修理するより10割捨てて買い換えろ
最初は型ありで、動的言語台頭してきて、
それがまた型ありのほうが良いってなった。
繰り返してるのかな？
また、将来動的言語の方が良いってならないか？
動的と静的が合体したのがあればいいんだがな(´・ω・｀)
型推論が進化するとむしろ人間が下手に型を書くと推論の邪魔になるから最小限しか書かなくなるようになる
>>860 動的型付け+型ヒンティングがそれだろう。TypeScriptが理想に近いと思う。
>>859 多分君が言ってる「型」ってのは、文字列、整数、浮動小数点とか構造体の事じゃね？
初期に普及したCPUアーキテクチャでは、そういった原始的型の実現が重要だった。
ソフトウェの組み方が、プロセス指向、データ指向、オブジェクト指向、メッセージ指向と拡張されるに連れて、必要な型も拡張されてきた。
で、現在「型」って一般的に言ってるのはオブジェクト指向用なんだが、その一方でC言語の入門編では古代の型を教えるから、大抵の人は混乱してしまう。
動的にも静的にも良いところはあるんだし、一概にどうとは言えんだろう。
動的型言語に慣れてるやつに言わせれば、コンパイラに指摘されるまでエラーに気づかないのは甘え、テスト不足、みたいな極論になるぞ。
オブジェクト指向もずいぶんアラン・ケイが考えたものと乖離してる気はするしな。
smalltalkは放置するとして、erlangみたいなメッセージ志向の言語はもう少しあっても良いと思う。
コンパイル通れば安全！IDEが全部教えてくれる！
これぞ最強モダン開発
我が社ではサーバ側をrustでリプレイスし始めた
今のところ楽しい
>>870 どの言語からRustにリプレースしてるの？
php, java(or kotlin), c(apache module), nginx(lua module), python, ruby
など一通り
負荷の高いところからちょっとずつだけど、phpのは一つ終わった
弊社ちっぽけな会社なもので、ランニングコストを抑えて価格で勝負しないとやってゆけないのです
rust案件として俺を雇ってくれない？
仕事なら勉強しそう。TypeScriptなら仕事で使っとります
最終的にどれくらい改善されたのか気になるから教えてほしい
自分達の稼働コストは無視か
典型的なダメベンチャーだな
オープンソースのようにコストを公開する習慣がないから
高いという証拠も安いという証拠もない
だから無視されるんだ
>>877 仕事じゃなくても勉強しないと！
>>878 元のコードの良し悪しについて無視するならば、phpのシステムはcpu時間が1/2、メモリ1/50、レイテンシ1/2、スループット3倍になった
>>879 無視してないよ
まあまさか月額百万以下とか言わないと信じてるけど、
動画配信のような本質的に高負荷な事業を除けば、クラウド費用が問題になるのはそもそもビジネスとして成立してないやろ
もしそんな状況なんだったらコスト削減なんかよりピボットして開発に金使うべきだわ
サーバを維持＆増強するコストが半分になると考えればアリじゃないの？
>>883 なんの金額？
>>884 なんの金額？
>>885 アリアリだよ
>>886 クラウド費用を元々いくらだったのをいくらに削減できたかに決まってるでしょ
金額ね
>>887 オンプレだからそういう計算はできないなあ
ちゃんとペイするからそう心配しないでよ
>>890 だったらクラウドに移行するか、データセンターに運用丸投げするのが先じゃね
手間も含めたらよっぽどコスト削減になると思うけど
>>892 ここでアピっとけば誰かがビジネスチャンスだと思ってもっととっつきやすい本執筆してくれるんじゃないかっていうなんかそういうのだよ
>>893 そんなことはないんだけど、残念ながら納得いただけるだけの材料を提供することはできないからなあ
単純に自分の金が欲しいという話ではないんだよな
自分だけでなくみんなが金を欲しがって欲しいという話だから面倒臭い
今出向してるベンチャーで工数が３倍になるのを覚悟してでも社内システムの開発用言語を関数型にしようとしてる。
最初はHaskell+elmだったけど、エコシステムが腐っているという理由によりScala+elmに変わった。rustは最初から除外されてた。学習コストが半端ないという理由により。
（まともに使えるのに２ヶ月かかる）
Scalaって最近微妙によくきくな
昔いろいろ入れすぎて一瞬でオワコン化したって聞いたが
Rustのコードを書くと借用チェッカにコテンパンにされて工数かかる、とでも思ってんのかねぇ。
実際は真面目に設計してりゃそこまで問題でもなかろうに。
Scalaで生き残ってるのはSparkだけだよ
Sparkがビジネスで受け入れられ始めた頃にKotlinやDottyで無茶苦茶になってアーリーアダプタが一斉に引き揚げ、負債として残っちゃった
コンパイルと言えばTypeScriptってめっちゃエラー出てるのにちゃんとjsファイル生成されるのには笑う
>>900 > 工数が３倍になるのを覚悟してでも社内システムの開発用言語を関数型にしようとしてる
これはなんで？
声の大きい関数型信者がいただけでしょ
社内システムだとビジネス観点の統制もないだろうし
俺も社内向けの仕事するときは毎回新しい言語使ってるぞ
まあ、社内システムっていつでもごちゃごちゃになるもんだし、本当にできるなら関数型にすればテストは楽だね。
俺が作ってたシステムは、言語は関数型ではないけど、何が何でもキュー処理システムが処理する結果が正で、それ以外の書き込み許してなかったから、ジャーナルを流し直すとデグレてないかテストができるよ。
業種の問題なんだろうけど。売ってるシステムも、キュー処理システムだけが書き込み出来るようになってる。
非同期対応とかも、もともと非同期を前提にしてたから何も困らんし、キュー処理システムは処理ロジックとして何でも呼び出せるからモックにしようが本番にしようがなんとでもなったな。
変な言語で出来てるけど、どんな言語に持ってっても移植できると思うわ。
意識高い系のエンジニアに対してビジネスサイドによる適切な方向付けができてないと、
こうやって誰も求めていない非機能要件を勝手に創造してオナニーを始めるんだよな
工数３倍というのは学習コストを加味してると思う。仕事で勉強していいとか羨ましい。
elixirも話題になったけど、結局erlangに精通する必要性が出るから除外された。
>>908 すべての変更処理はイベントとしてキューイングして処理するようにしたってことかね？
Elixirは関数型として見ると微妙なんだよなぁ。
F#から借りてきたパイプライン演算子はなんでああなっちゃったんだろうか。
あれじゃただのUFCSなんだからドットにしとけばよかったのに。
>>911 そうそう。
売り物の方が、監査証跡と全データの変更履歴が必須だから。
社内システムにも持ってきてるが、今まで事故ったのは入力ミスに赤伝切らずにDB書き換えた事由来ばっかり。
俺も初めて任されたwebアプリケーションスタートアップでJSF選んだの後悔してるから変えたいわ
>>900 Haskellのエコシステム、そんなにひどいのか。
具体的にはどういう所がダメなんだ？
確かにScalaはなんとなく良い感じなのは同意。
他言語なら他のインストール方法試すなりコード弄るなりで対処しようがある感じだがhaskellはあかんわ。。
>>907 自分のプロジェクトで使って最後までメンテするんなら別にいいと思うが
人のライブラリに無理やり突っ込んで人を実験台にしてくる輩は死ねと思う。
>>867 >動的型言語に慣れてるやつに言わせれば、コンパイラに指摘されるまでエラーに気づかないのは甘え、テスト不足、みたいな極論になるぞ。
そんな奴見た覚えはないが、新人君みたいなテスト＝単体のインターフェーステストって認識なのかもね。
>>918 「関数型」と言ってる奴にとってはHaskell自体が実験台でしょ
パラダイムの方に興味があるということは実装のメンテナンスは期待できない
でも今どきピュー(P)と吹けば(H)壊れる(P)ウンポコペチプー選ぶガイジよりはマシだろ
>>921 別に自分で実験する分にはいいと思うが
メンテナンス性も含めてそのパラダイムが有効か検証しないと意味ないだろ。
今時メンテナンス性を考慮しない言語なんてありえんわ。
HaskellはCのライブラリをいくらでも取り入れるのでCが分からないと地獄
「全部自動化すればCが分からなくても問題ない」という説を信じたら地獄
一方、JavaやJavaScriptは鎖国のようなことをやってCを使わないようにした
この問題についてはパラダイムは関係ない
Googleは当初Dartでやろうとしてた事にはTypeScript採用したんじゃなかったっけ？
>>928 haskellの評価順序とcの評価順序のバインディング考えるだけでも頭痛くなるわ。
そこに特有の最適化仕の把握しとかないと使えんだろうし、そんなもん普通のプログラマが使えるか。
>一方、JavaやJavaScriptは鎖国のようなことをやってCを使わないようにした
javascriptは知らんがjavaもc呼び出しはやるだろ。メモリモデルの違いで苦労はするがcの他からの呼び出しやすさはやっぱすげーと思う。
機械学習がPythonになったのは、JavaでCを呼び出していいのか躊躇したからだと思うよ
>>931 個人的にはdeeplearningの層を明示的に静的型付で表現するのがあんまり相性良くないから
と思ってるけど。javascriptでもある程度ライブラリ出し始めたところ考えるとそうかなと思う。
マルチプラットフォーム実装を前提とするライブラリならともかく
アプリ側からC呼ぶとか何のためのJVMか分からんがな
pythonは読みやすさからサンプルコードとしてよく使われていたのが
そのまま使われ続けただけ。
何のためのjvmというが現実にはcのコードをポートする方が楽だからな
jvm が使えないプラットフォームにも対応できるし
>>937 コレクションもまともに扱えない言語は遠慮します
>>430,431
RustはWebAssemblyを生成できるって点には魅力あるんだけどな
>>930 >haskellの評価順序とcの評価順序のバインディング考えるだけでも頭痛くなるわ。
どうせIOモナれば先行評価だろ。
そうなるわな
アプリを作らない言語は生産性がないと言われて作ってみたら
○○を作りたいだけの言語は汎用性がないと言われる
>>936 そりゃ極論かまってちゃんはどんな世界にも居るだろ。
>>942 趣味で重箱の隅に拘りたいやつならともかく、プロジェクトでは十分じゃん。
「次世代」ってビジネスの事だよ？
だから、C言語を使えるレベルならPythonも使えるし
C言語禁止したいならPythonを使う意味はあんまりないって
>>952 単純なコレクション操作すら可読性の低いコードになるという指摘に対して
「趣味で重箱の隅に拘る」と決めつける極論を返すなんて、さすがPython信者の鑑です
ここで「たしかにPythonの標準ライブラリ設計には問題がある」と認めた上で、
「しかしながら、機械学習/科学技術計算/ラズパイといった特定の分野に限れば、
Pythonには優れたライブラリ/フレームワークが数多く存在しているから、
ビジネスであれば標準ライブラリの問題は取るに足らない些細な事柄だ」と
切り返すなら、常識的で説得力もあるんですけど
>>953 君みたいなドカタが不十分と考えようが、多くの企業で好意的に採用されてるよ
バカバカしいのは君のドカタ人生の方だよ
pythonのリスト操作すらまともに理解できないならプログラムなんてしない方がいいレベルだと思うが。
理解できるできないの話をしてると思ってるアスペの登場
理解してても可読性が低いと思ってんのか。。それもよっぽどだよ。
C言語って言語仕様だけ知っててもほぼ実用性のあるものなんて作れないんだよね
ハードウェアだかOSだかバイナリファイル(画像、音声など)の仕様の理解が別で必要になるし
そっちが非常に難解なだけでC言語の言語仕様自体は極めてシンプル
失礼な！！Python は FORTRAN/COBOL/BASIC に代表される
伝統的な手続き型言語の正当な後継スクリプト言語、
次世代の純粋手続き型言語です
関数型？オブジェクト指向？
そんなのは飾りです、偉い人にはそれが分からんのですよ（必死
まぁそのうちGoogleがPythonで出来るような事を全部Golangで出来るように頑張って欲しいね
NumpyチックなこともできないGoがPythonにとって変われるとは思えないが
遅いけどGrumpyで良いんじゃねえの？
しかし自虐的な名前だよな。
Haskellの$が欲しい
Haskellの以降は後処理マンが欲しい
全く関係ないけど、並列とかGPUが得意なCみたいな言語欲しい
>>968 PythonでOpenCLみたいな本最近出てなかったっけ？
>>963 Smalltalkみたいなクソ言語が好きそうw
>>968 並列が得意なC++ならRustで決まり
PythonもだけどHaskellも次世代言語じゃなくない？
>>971 並列が得意なC++ではなく並列が得意なCが欲しいのじゃ
それを言ったらもうKotlinくらいしか
次世代言語と言えない
C#が高速バージョンアップでどんどん別言語になっていくくらい
>>974 そう言うような気はしてた。じゃあ逆に質問させてくれ
殆どCの上位互換であるC++をわざわざ避けた理由は？
そこに明確な理由が無い場合はやはりRustを勧める
>>976 横レスになるけど：
並列プログラミングという課題に対して、
CからC++へと拡張された「オブジェクト指向」は、
言語仕様を複雑怪奇にさせた阻害要因となっているから
と考える
>>978 殆どの言語のFFIが相手がCなの前提にしてるからな…
RustならC互換のABI公開出来るけど、
それなら素直にC使えば…と思わなくもない
俺はRustが好きなんでFFI前提でもRustを使うと思うが、
他人にお勧めはできないかも
別にC++のコンパイラを使うからと言ってクラス機能を必ず使う必要はないと思うのだけれども
C以外で一番C ABIが扱いやすい言語はやっぱりC++だわね。
次世代言語は、なんとなく見えてきた気がする。
そろそろ次々世代言語を考えるべきじゃないか。
正直プログラミング言語なんて全然進歩していない気がする。
2020年にもなってC言語が生き残っているとは思わなかった・・・・
>>986 君は進歩を記憶喪失か何かのように考えているのかね
Cの記憶は滅びぬ
Swiftの話題薄いから次のスレタイから入れ替えるのありかも
>>987 Dartについての肯定的な反応少ないし
スレタイがGoogle推しの言語(Go Dart Kotlin TypeScript)に偏りすぎるよ
【IT】いずれPythonのライバルに？新言語「Julia」の人気が急上昇
http://2chb.net/r/bizplus/1534668711/ 型無し糞言語ガイジどもが地獄の業火に焼かれてなるべく苦しんでグチャグチャに死にますように
ついでに末代まで呪われろ
lud20250125011119ncaこのスレへの固定リンク： http://5chb.net/r/tech/1530664695/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「次世代言語12 Go Rust Swift Kotlin TypeScript ->画像>2枚 」を見た人も見ています：
・次世代言語9[Haskell Rust Kotlin TypeScript Dart]
・次世代言語Part8[Haskell Rust Kotlin TypeScript]
・次世代言語議論スレ[Rust Kotlin Haskell]第6世代 [無断転載禁止]
・次世代言語議論スレ[Go Rust Kotlin Scala]第4世代 [無断転載禁止]
・次世代言語14 Elixir Crystal Julia Rust Swift
・【Nexusから】次世代Google端末を語るスレ Part15【Pixelへ】 [無断転載禁止]
・【PS5】RDNA2X SIE次世代機予想スレ HWRT 高速SSD 91世代目 【PS5PRO】TFLOPSだけでは語れない
・【Nexusから】次世代Google端末を語るスレ Part14【Pixelへ】
・次世代言語議論スレ[Go Rust Scala Haskell]第5世代
・Xboxの開発者、Project Scorpioは「本格的な次世代機」になると発言 [無断転載禁止]
・【車】ホンダ、AIを持つ次世代スポーツEV「Sports EV Concept」東京モーターショー2017で世界初公開 [無断転載禁止]
・【Pro】【Switch】 次世代ゲーム機テクノロジースレ No.6【Scorpio】 [無断転載禁止]
・【速報】次世代Xbox「Scarlett」はZen2、Navi、GDDR6、カスタムSSDで最高品質の次世代ゲーム機に★6
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★12
・【終戦】著名リーカー「次世代XBOXよりPS5の方が性能上」「次世代XBOXはメモリが少ない」【Scarlett】
・【Pro】【Switch】 次世代ゲーム機テクノロジースレ No.11【Scorpio】
・【Scorpio】次世代ゲーム機テクノロジースレ 【TegraX3版Switch 】
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★13
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★16
・【Pro】【Switch】 次世代ゲーム機テクノロジースレ No.5【Scorpio】
・【Switch】 次世代ゲーム機テクノロジースレ 【Scorpio】
・任天堂の次世代ゲーム機 Nintendo Smart、「すでに量産開始されている」とWSJが報道
・次世代たばこ「三つ巴の戦い」 JT反撃なるか？【iQOS/ploom tech/glo】
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★9
・【Scarlett】 Xbox次世代機はCSのパワー、スピード、パフォーマンスの新たな基準を打ち立てる製品 ★11
・【PS5】RDNA2X SIE次世代機予想スレ HWRT 高速SSD アンチ出禁 84世代目 【PS5PRO】
・【PS5】RDNA2X SIE次世代機卵zスレ HWRT 高速SSD アンチ出禁 80世代目 【PS5PRO】
・【PS5】RDNA2X SIE次世代機予想スレ HWRT 高速SSD 87世代目 【PS5PRO】
・【Pixel】次世代Google端末を語るスレ12【Nexus】
・【PS4で出ない】The Elder Scrolls VI発売は次世代機と判明
・【IT】iOS12のFace IDは2つの顔で顔認証が可能！次世代iPad向け機能か？
・【Type-C】USBの次世代仕様「USB4」が発表。Thunderbolt 3ベースで最大転送速度は40Gbpsに
・【初音ミク】グッドスマイルカンパニーが次世代型飛行フィギュア「ねんどろーん」を発表！あの「ねんどろいど」がついに大空へ！動画有り [無断転載禁止]
・【芸能】将来メチャ怖くなりそう！次世代ご意見番ランキング 有吉弘行、指原莉乃、ミッツ・マングローブ、加藤浩次 など [無断転載禁止]
・XBOX・PSの次世代ハード出たらSwitchは【世界】で戦っていけるの？
・【朗報】フィルついに沈黙を破る｢ゲームパスこそ次世代Xbox｣コンソール戦争の終結(勝利)を宣言
・【米】わずか５秒で時速３１０ｋｍ到達 次世代交通システム「ハイパーループ」、真空チューブでの高速試運転に成功（動画あり） [無断転載禁止]
・8/10(月)夜7時からのCDTVSPに出演する「AKB48グループ CDTVスペシャル次世代選抜」のメンバーを予想しよう！★1.2【夏ソングSPメドレー】
・NEC PC、次世代ゲーム機「Project Engine」を発表
・【これぞ次世代機】PS5専用ゲームのグラフィックがガチのマジで凄すぎて任豚発狂！
・【米】わずか５秒で時速３１０ｋｍ到達 次世代交通システム「ハイパーループ」真空チューブでの高速試運転に成功（動画あり） ★３
・【次世代通信規格】LTE and Others 総合スレ 84
・マイクロン広島新工場が完成、次世代DRAMとSSDを量産、韓国へのフッ化水素の輸出規制とは一切無関係
・【動画有】マスク+動いていても顔認証。感染症対策万全の次世代オフィス技術をNECが実証実験。
・【PS5】情報解禁 SIE次世代機予想スレ 【携帯機&PSVR2】 逆襲の38世代目
・めぐみ「SwitchはこのままだとPS5と次世代XBOXに食われる可能性がある」
・【IP表示】次世代iPhone part201
・【通信】次世代通信規格「５Ｇ」の実用化、19年に１年前倒し
・次世代ビデオコーデック総合スレPart1 【HEVC/VP9/AV1等】
・【Pro】【NX】 次世代ゲーム機テクノロジースレ No.18 【Scorpio】 [無断転載禁止]
・次世代iPhone Part213 [無断転載禁止]
・【PS5】大手メーカー「次世代機で驚くには100倍の性能差が必要」【Switch】
・【自作PC】AMD、32コア/64スレッドのEPYCを6月20日、次世代のRadeon VegaはSIGGRAPHで発表 [無断転載禁止]
・【PC】AMD、「Spectre」対策で次世代チップ「Zen 2」の設計を変更
・【PS5】情報解禁 SIE次世代機予想スレ 【携帯機&PSVR2】 逆襲の39世代目
・【慰安婦発言】「国会で”NHK会長は辞任すべき！”と追及する民主党・・メディアへの不当圧力と取られても仕方ない」 次世代の党・和田氏
・次世代iPhone Part225 [無断転載禁止]
・次世代iPhone Part206 [無断転載禁止]
・次世代iPhone Part193 [無断転載禁止]
・【次世代スピーカー】透過スクリーンに動く歌詞を表示「Lyric Speaker」発売 [無断転載禁止]
・【Polaris】次世代Windows予想スレ【Andromeda】
・次世代iPhone Part253
・次世代iPhone Part262
・次世代iPhone Part269
・次世代iPhone Part211
・次世代iPhone Part268
11:11:19 up 11 days, 12:14, 2 users, load average: 10.24, 8.90, 8.86
in 1.85537981987 sec
@0.11239886283875@0b7 on 012501
|
ブックマークへ