次世代言語Part7[Go Rust Swift Kotlin TypeScript] ->画像>5枚

文字数制限きついので改題
スレタイ以外の言語もok

前スレ
次世代言語議論スレ[Rust Kotlin Haskell]第6世代
http://2chb.net/r/tech/1503924817/

そろそろSwiftとTypeScript入れときたかったので

5chってなんだよ

２ちゃんねる、正式に「５ちゃんねる」に名称変更！色々あって5chが誕生！
http://www.yukawanet.com/51096/archives/5274335.html

TSは普通に現代だろ
生JSはもうやれない

生JSもVSCodeによってコード補完がTypeScriptと比べてさほど遜色ないレベルにまで引き上げられたからなあ
結局MSが本気で開発環境を作ればどんな言語でもゴリ押しできることが証明されてしまった

次世代というか、2010年代の企業発の静的型付け言語でまとめてみた
まだ載ってないのだとNim Hack Julia Crystal辺りがいいのかな

>>6
限定的な型補完のみだろ
静的チェックには絶対型が必要

>>6
JS含む動的言語は大抵ダックタイピングって時点で補完が効かないじゃん。

個人的には「ダックタイピングのほうがインターフェース書かなくて済むから
手軽で良い」って言ってる奴がマジで理解できん
補完できなきゃどのメソッド呼べるのかいちいちコードかドキュメント見に行かんとならんからむしろ面倒

>>9
型が決まってれば動的言語だろうと補完できるでしょ

>>10
JSDocに型を書いてないコードとかあったら発狂したくならない?
仕事じゃ周りのアホどもが書いてくれないからよくにあるんだけど

>>9
最初にコード補完をIDEに組み込んだのは動的言語

>>12
それは知らんかった
何て言語?

>>13
皆さんよくご存じのVBです。

>>14
バカいうんじゃないSmalltalkに決まっとるがな

>>15
https://en.wikipedia.org/wiki/Intelligent_code_completion

>>9
ﾎﾝｺﾚﾝｺﾞ

>>16
何を調べるにしてもウィキペ情報は参考程度に留めておいたほうがいいよ

ご多分に漏れずこの件に関しても間違っていてちょっとググっただけでも
少なくとも1980年代にはコンテキストを考慮した補完機能を有するAliceというPascalのIDEが出ていることがわかる
http://www.atarimagazines.com/v6n2/Alice.html

だから動的言語が初かの真偽はともかくVBがしかも1990年代にもなってから「最初」ということはあり得ない

動的か静的かよりも暗黙に型変換するのかしないのかのが重要。

typescriptの凄さってIDEの機能言語に組み込んだことだよな。
リファクタリングの機能を言語に用意してるから、
どのエディターでも使える。

>>16
>>18

Wikipediaが間違ってるんじゃなくてお前らの読み方が間違ってるだけだろ
最初にコード補完をIDEに組み込んだのはVBなんて事どこにも書いてない

>>11
JSDocとコード補完と何か関係あるの？

折角の補完機能ガン無視してVimで書いててすまん
Vimに補完つけると重いんだよな

vimの補間が重い…？

Jedi-vimとか謎に重くならん？
あれ？そうでもない？

>>20
MSは昔からやってるけどね
MSにとって目新しいのは、コンパイラ及びエディタをコード補完やリファクタリングに対応させるためのオープンなプロトコルを策定したこと
これほど早い段階でそのレベルにまで達するのはMSにしかできないこと

誰だよ未だにプログラミング言語未満のRustをスレタイにいれてるやつ
ハロワ以上のプログラムをことごとくコンパイル弾く欠陥品、言語としての体をなしていない

普通にrestでwebserverたててるが…

Rustね

名前間違う時点でろくすっぽ使ってないのバレバレ

晩酌してたのとRest APIと混ざったんだよ
めちゃめちゃ使ってるっちゅーの

自動補完は正直うざいからオフにする

>>31
じゃあさくっと木構造実装してみてよ

>>33
ほい

enum Tree<T> {
Leaf(T),
Node(Box<Tree<T>>, Box<Tree<T>>),
}

まあそれが一番素直な実装だね。

問題は循環するかもなグラフの場合。持ち主が曖昧になるから。

>>34
データ構造定義だけ書かれてもな
それに対して余計なアロケーション発生させずにappendとdelete実装してみてくれよ
できるもんなら

問題はTypeScriptに対して競合としてflowがあることだよな。
Reactを使うのにTypeScript使っててすごく便利なんだけどReactがflow押ししそうで怖い。

>>36
まずはCかC++でお前の言う無駄なアロケーションのないappendとdelete付きの木構造とやらを書け。
そしたらそれをRustで書き直してやるよ。

>>37
Web系に言語は作れないってのはさすがにCoffeeやDartで世間に理解されたと信じたい

>>20
IDEの機能を言語に組み込むぐらい、LISPもSmalltalkもとっくの昔にやってるじゃん。

おまえらが次世代と呼んでいる機能のほとんどが60年代の再発明だなw

>>37
うちの案件フロウ使ってるわ
最初の技術選定でクソ馬鹿野郎が生JS選択したせい
しかも途中で辞職、いやいなくなってくれてせいせいしたが

んで、どうしようもないから後付けでフロウ
クソみたいな生JSに後から挿入れられるのはメリットだわな
ライブラリの対応はゴミだけど

>>41
まあそういうところもあるけど、Rust なんかはだいぶ機能を整理した方かなとは思うよ。
実際に作って使ってみるとボローイングの解決しづらさがよくわかるってのはある。
理論と実践は繰り返してなんぼ。

言語レベルのリファクタリングを備えたTypeScript 2.5がリリース
https://www.infoq.com/jp/news/2017/10/typescript-2-5-refactoring

>>42
Typescriptも該当ディレクトリ内にXXXX.d.ts(XXXは生jsのファイル名)を置くだけで
型が付与できるけどな。しかも生jsの箇所をいじらずに。
どっちがいいかは何とも言えないが。

jsというかTypeScriptを使ってるんだけど。async-awaitマジでいいわ
と思ったが例えばclassのコンストラクタをasync対応してくれたらな〜って思うわ
初期化時に非同期関数使いたいと詰む。

>>46
c#でずいぶんお世話になってるから嬉しいわ

>>45
ま？

>>46
わざわざasyncのinitializeメソッド作るの馬鹿らしいよな、仕方ないんだけど

>>46
constructor() {
　(async () => {
　 await this.hogeAsync();
　})();
}
インスタンス作成側ではawait newとかできないけど、分かってて使えば
今のとここれで特に問題ないわ。

>>50
非同期関数がそのクラスの生成タイミングで終わる保証無いだろ。
大概ストレージとかネットワークアクセスしてるわけだし。
それで事足りてんの？マジで？

>>9
使ってみたらわかるが、ちょっと頭おかしいレベルで補完効くぞ。
関数の型が、「Date | "不正日付" | "演算不能"」と、stringの中身まできちんと出してきたときにはびっくりした。

コンストラクタ非同期にしたい時は>>51の言ってる問題があるから、値をセットするだけのprivate constructor準備してpublicは別に公開したほうがいい

例↓

class Hoge{
  private constructor(public foo:string){}
  async create():Promise<Hoge>{
    const foo=await asyncFunction();
    return new Hoge(foo);
  }
}

>>41
lisper召喚したいのか?

Lisperとかもしいるなら是非来て欲しい

LisperはSmalltalker以上にめんどくさいぞやめとけ

>>43
> 理論と実践は繰り返してなんぼ。

同意

めんどくささを恐れてはならぬ。

その通り
テキストエディタで打ったコードにこそ温もりがある
補完や静的解析なんて邪道
日本人ならPHPを使うべき

>>59
日本人ならとか言うんならRuby使えよ。。。
何でPHPなんだよアホちゃうかと。。。

HSPだろ。

ひまわり ちゃうかな

Elixirってダメなん？将来性ないの？
サーバーがCowboyとかいう変なやつになるからダメなのかな

>>60
偽装・不正・いい加減がモットーのジャップランド土人村にとって
PHPほど相性のいい言語はない
PHPは日本人なんだよ、わかるか？

>>52
それは裏でTypeScriptの型情報を再利用してる。
だから標準APIとか有名所は使える。でも自分でライブラリを作るととたんに効かなくなるぞ。

>>52の内容なら型アノテーションに頼らずとも型推論だけでいけるだろう。

>>63
将来性とかさ〜自分で判断しろや。
それともここで将来性あるとか言われたらなんも考えずにその言語使っちゃうわけ？
将来メンテされなけりゃおれがやるくらいの気概をもって言語使ってほしいわ。

>>64
それはあくまで偏見の塊の君の個人的意見だろ。
そんなこと言い出したら
「日本人はもともと職人気質の人間が多いから
使いこなすのに職人レベルの技術が求められるC++と相性がいい。
だからC++こそ日本人のための言語だ。」
なんていう、今俺が適当に作ったトンデモ論法でも通っちまうだろうが。

>>65
違うよ。自作関数の戻り値と、それが代入されてる変数のヒントに出る。
自分でライブラリ作ってもバッチリ出てくれるけど、doc書いといたら間違いは更にないな。

>>63
Elixirいいよ
将来性はコミュニティの頑張り次第
Phoenixはよく出来てる

実質的にWebアプリに用途が限定されるだろうから
このスレでは人気ない

>>68
いや、日本人はPHPでしょ
空気読んで面倒臭いことはナーナーにして
今が良ければそれでよし

当事者がたんまりお金盗って無事退職した後、
年単位越しでツケ払って大騒ぎ

PHPですか？いいえ、日本です

日本の技術力ガーとか言ってたくせに
結局全部嘘ばかり
バカチョン以下やでホンマ
そりゃペチパーが闊歩しますわ

ponyはまだまだマイナーだな

>>72
多分お前よりはまともなもの作ってるとおもうわ。

haskellがやっと外れたなｗスレタイ

PHp本当に速くなったからな
相変わらずポーリングも特殊操作でしかできないクソだけど

異常者の迷言「PHPは日本人」「日本人はPHP」

気に食わない奴でも合法なら許す
違法なら許さない
この優先順位を歪めるから無法地帯になるのだ

>>70
Elixirってrubyに強く影響受けてる言語なんだよな。
Phoenix触ってたらRailsの匂いを感じる。
でも今は動的言語は弱い気がする。Elixir + 型 が欲しい
TypeScriptが触ってて気持ちいいからサーバサイドもJSがいい気がする。

Elixirの問題は込み入ったことやるとErlangに足突っ込まなきゃいけないことで
プロダクションコードに突っ込むには人材要求が高すぎること

結局ネットワーク系統のエラー処理は低レイヤーに突っ込んでいかないとどうにもならんよ。
抽象レイヤーでなんとかしたいって願望はわかるけどさ。

Elixir（というかBEAM=ErlangVM)の場合はプロセス復活のために型情報が必要だし
静的にしたからって型情報は省略できない

C++を書きたくないんだが代替言語は今だとrustとdどっちがゆうぼ？
最近はnimと言うのが注目されてるとも聞いたが……

誠に残念ながら今そのポジションはGoの一強

Cよりスピード出るのはNimだけ！

ジャップランド土人村企業が詐欺のために求めているのはPHPだけ！

どうかんかえてもRustだろ

>>84
Goも弱点が多い言語だけど初期の学習コストとか考えると
rustよりGoかな。
もちろんrustもいいんだけどc++並に学習コスト高そう感ある。

Rustは言語と名乗れる水準に達してないのでGo
深くシステムに触るのには向いてないがな

Goなのか……
他言語が純粋な次世代Cを目指してる中、Goは微妙に設計思想が違うイメージだからあえて外したんだが……やっぱりgoogle正義なのか

>>83
c++ で何を書くつもりなの？
無理に c++ で書かなきゃならんものって最近は減ってると思うけど。

>>91
c++ で書かれたオープンソースプログラムのdllプラグイン
悲しいことにc++ 選ぶ理由なんて結局既存ソースがc++ だからの理由に尽きる……

>>90
goとか言ってる連中の言うこと本気にするなよ。
goは数年周期でバズってるだけでC++の代替なら
Dかrustって考えは間違ってないしrust理解できないやつが
こことrustスレで騒いでるだけだぞ。

Dはもう流行らんだろうが、rustは学習コストより標準ライブラリの弱さが面倒。
自分で書くか外部ライブラリに依存しまくるかで基本的なスレッドプールすら無い。
低レベル向けだから結局自分で書くならrustでいいし、それが嫌ならDでいいよ。

rustとD位の差なら正直好みの差。

>>92
ならやっぱりrustじゃない？
bindgen使えばc++のヘッダもパースしてc ffi用のglue code生成してくれる。
bindgenがどの程度まで万能かは俺もよくは知らんけど、
mozillaがfirefox quantumでservoとgeckoの橋渡しのために使ってるくらいだから
結構まともに動くんじゃないかとは思ってる。

おまんらの大好き　ぷ〜えちピーーﾌﾞﾘﾌﾞﾘｯ　でも使えばええじゃろｗ

みんなサンクス。
Goは学習コスト低いらしいから後追いでもなんとかなりそうだし、とりあえずrustで書いてみることにするわ
一刻も早くc++ が絶滅する事を祈る

TypeScriptとGoを交互に触ってるけど
やっぱりnull安全な言語とそうじゃない言語の差が際立つな。
Goのほうは早速null pointerアクセスで落ちる。

c++が絶滅したら今c++で書かれてる様々なコードベースが色んな言語に分裂するんだぜ
バベルの塔

バベルの塔を高くし過ぎたからしょうがないね

>>93
既存のまともに動いてるCコード移植しようとしてまともにコンパイルも通らなかった経験からまともな言語の水準に達してないといってるわけだが
少なくともRustでものが書けると信じこんでるお前よりはRust理解してるぞ

>>100
お前が前に沸いたアンチと同一人物かどうかは分からんが、前に言った木構造をとっとと書きやがれ。
それすらできないならお前はC、C++もそもそもまともに出来てないんだから黙ってろ。

> 38
> >>36
> まずはCかC++でお前の言う無駄なアロケーションのないappendとdelete付きの木構造とやらを書け。
> そしたらそれをRustで書き直してやるよ。

>>101
まずRustの木構造をちゃんと動くように書いてから言えよ

rust で木構造云々言ってる奴って、コンパイラすら通せない rust コードしか書けない奴だろ。

Cで書いてあった平衡木のライブラリを rust に移植したけど、
> それに対して余計なアロケーション発生させずにappendとdelete実装してみてくれよ
こんなん普通に出来るぞ。
Option<Node> に get_or_insert() するだけ。

かなり苦労したのは木の回転だけど、それでも rust 用に頭を使ったら、
take() して mem::swap, mem::swap, mem::swap, そして代入の 5 行で終わり。
全体を通して余計なアロケーションなんて普通に無い。

rust は学習コスト結構高いけど、初歩の初歩で躓いた落ちこぼれ>>100,>>102 とかは何を言う権利も無いよ。

Cのコードを示せないrustアンチは糞ゴミだけど、動くコードを示していない>>103も何も言えていない

自分の頭を撃ち抜くCのプログラム書いても運良く助かってる人は
Rustのコンパイル通せなくなるよね

そういう、Rustのコンパイルが通らなければ危険なコードって決めつけるRust信者本当にうぜえ
Rustが言語として表現できる範囲が狭いのをごまかすための方便でしかないのに

TypeScriptは本家のplaygroundを触るだけで凄さが分かるんだけど
https://www.typescriptlang.org/play/

rustってそういうのある？ちょっと試すとかできる？

>>105
自分の頭というよりユーザーにデバッグのコストを転嫁して儲けてるな
運が良いというより確信犯的に

>>107
ググるとかしない人？単にTypeScript宣伝したいだけ？
https://play.rust-lang.org/

もとよりゆるふわTypeScript使いがRustのコンパイルを通せるとも思えないので端から試す気ゼロだろうけど…

選ばれた人しかコンパイラ通せない言語とかそれプログラミング言語って言えないよね

>>109
そこは知ってるけど全然補完が効かないんだけど。rust使いは
しょぼいエディターで頑張る感じ？

TypeScriptはplaygroundから補完が効きまくって楽しい。

AltJSであるtsとRustのブラウザ上で動くplaygroundの機能差を語りたかったの？マジで？
Rustサゲしてる人はこの程度ってレッテル貼っていいの？

単にプロダクト開発のスキルの違いだな
MSの開発環境チームのメンバーはHelloWorldの代わりにインテリセンス実装するんだろう

>>112
単純にPlaygroundの質からして違うってだけの話だろ
その程度もみとめられないよかよ

なぜrustの対抗馬にTypeScriptが挙がるのかまるで理解できない
用途が全然違うだろ……

WebAssemblyが期待されてるから、あながち間違いでもない

>>113
ほんとMSってそういう所は笑えるくらいすごいよな
Rust開発者たちも見習ってほしい

一応rustもコード補完にrlsとかいうヤツあるけどなんかまだいまいちなんだよな。
vscodeにrust(rls)っていうエクテンション入れて使ってるんだけど、
クロージャ書いてるときは補完が効かないのは俺だけ？
あとlint?(エラー・警告を赤・緑の下線で表示してくれるやつ)が
時々なんの前触れもなく急に無反応になるんだけどそれも俺だけ？

少人数のMS社員が片手間でVSCode作ってみたら一瞬で天下獲れちゃいましたというチート集団
MSがRust推せば余裕でGo潰してベターC++の定番を奪えるだろうな

片手間ってことはないし、エディタ作成なんてのは人数増やせばいいものでもない。
まあチート軍団ってのは確かだけど。
しかし Rust とか c++ みたいに教条主義的な言語ってやっぱ信者が湧くね。
わかりやすくていいとは思うけど。

片手間とか余裕とか、良い子は絶対に真似してはいけない情報ばっかり教えるんだよな
そんなところに信者を集めたら怠け者の集団ができそうだ

>>36じゃないけど、雑に平衡木（AA木）Cで実装してみた。
つってもWikipediaのまるコピだが。
#include <stdio.h>
#include <stdlib.h>

typedef struct tree {
int value;
struct tree* left;
struct tree* right;
int level;
} tree_t;

int level(tree_t* t) {
if (t == NULL) {
return 0;
}
return t->level;
}

tree_t* leftEnd(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->left == NULL) {
return t;
} else {
return leftEnd(t->left);
}
}
（続く）

tree_t* rightEnd(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->right == NULL) {
return t;
} else {
return rightEnd(t->right);
}
}

tree_t* skew(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->left == NULL) {
return t;
} else if (t->left->level != t->level) {
return t;
}
tree_t* l = t->left;
t->left = l->right;
l->right = t;
return l;
}
（まだ続く）

tree_t* split(tree_t* t) {
if (t == NULL) {
return t;
} else if (t->right == NULL) {
return t;
} else if (t->right->right == NULL) {
return t;
} else if (t->level != t->right->right->level) {
return t;
}
tree_t* r = t->right;
t->right = r->left;
r->left = t;
r->level += 1;
return r;
}
（続く）

tree_t* decreaseLevel(tree_t* t) {
if (t == NULL) {
return t;
}
int ll = level(t->left);
int rl = level(t->right);
int expectedLv;
if (ll < rl) {
expectedLv = ll + 1;
} else {
expectedLv = rl + 1;
}
if (expectedLv < t->level) {
t->level = expectedLv;
if (t->right != NULL) {
if (expectedLv < t->right->level) {
t->right->level = expectedLv;
}
}
}
return t;
}

tree_t* insertTree(tree_t* t, int v) {
if (t == NULL) {
t = malloc(sizeof(tree_t));
t->value = v;
t->left = NULL;
t->right = NULL;
t->level = 1;
} else if (v > t->value) {
t->right = insertTree(t->right, v);
} else {
t->left = insertTree(t->left, v);
}
t = skew(t);
t = split(t);
return t;
}
肝心の関数まで遠いなほんと

tree_t* removeTree(tree_t* t, int v) {
if (t == NULL) { return t; }
else if (v == t->value) {
if (t->left == NULL && t->right == NULL) {
free(t);
return NULL;
} else if (t->left == NULL) {
tree_t* e = leftEnd(t->right);
int succ = e->value;
t->right = removeTree(t->right, succ);
t->value = succ;
} else {
tree_t* e = rightEnd(t->left);
int pred = e->value;
t->left = removeTree(t->left, pred);
t->value = pred;
}
} else if (v > t->value) { t->right = removeTree(t->right, v); }
else { t->left = removeTree(t->left, v); }

t = decreaseLevel(t);
t = skew(t);
t->right = skew(t->right);
if (t->right != NULL) {
t->right->right = skew(t->right->right);
}
t = split(t);
t->right = split(t->right);
return t;
}
おしまい。 まじこんなクソコードに何レスもついやしてすまん。

改めて書いてみて思ったが、平衡木って平衡保つための操作がポインタのつけかえ多くて
確かにRustにはキツそうだなとか思ったり

データコピーなし縛りで実装するのはRust歴1週間の自分には無理そうだ

Rust 的にはそんなに派手に持ち主変えるな、もしくはコピーを使えって感覚なんだろう。
そういうのは上のレイヤーだったら正しいと思うけど、アルゴリズムなコードの場合は
ちと厳しいかもしれん。
付け替えが頻繁に発生する構造の場合は
int parent[]; int right[]; int left[];
みたいな配列実装しろてな記事は見た事なるな。
直感的ではないけど速度は出るし、まあ慣れてる奴からすればどっちも一緒といえば一緒かな。

そういう、どうしても生ポインタごそごそつけかえる必要がある基幹アルゴリズムは、unsafeでくるんでやれって感じなのかね
実際この平衡木の実体が複数スレッドから独立に操作されるとか考えると割と困る

gitみたいに、古いデータを消去することなく
しかも変更のない部分はいちいちコピーしないアルゴリズムを考えるんだ
そうすれば古い方のデータに別スレッドから安全にアクセスできるよ

結局たかが赤黒木すらRustでは書けないって認識でいいの？
ほんとプログラミング言語名乗るなよ

>>131
その認識は間違いだけど正解を無料で教えてくれるボランティアが足りないね
GNUみたいなボランティアがいっぱいいないとプログラミング言語を名乗れないのが現実

Rustの問題は後発のくせにIDE連携が弱すぎる。
KotlinとかSwiftとか後発の言語は大概IDEと一緒に提供してるから
最初から補完がきっちり効く。

Goも昔はイマイチだったけど改善してるから許せる。
TypeScriptは言語そのものにIDE連携のための機能をたっぷり盛り込んでいるから
見習ってほしいって話。

初学者程IDE連携が必要だからな。言語仕様が優れてていても
ツールとして使い勝手が良くなきゃ使わんよ。

それにRustの立ち位置って
OS開発とブラウザ開発くらいしかメリットが思い浮かばんのだけども

CLIならGoだし
WebならPHPとかRubyとかGoとか乱立状態だし
WEBのクライアントサイドならTypeScriptだし
スマホならKotlinかSwiftかObjC

このどこにRustが入り込むの？

そもそもC++があまり成功してないから改善するためにRustがある
C/C++と合計して考えるとJavaより上だけど合計しなければC++は成功してないよ

C++が成功してないwwwwwwwwwww
どこの平行宇宙ですかwwwwwwwwwwwwwwwww

まあ c++ がうまくいってればこんなに言語がたくさんできることはなかっただろうね。
c++ の存在意義は今や高級な機能をどれだけランタイム速度落とさずに入れられるのかの
実験場って位置づけかな。

C++は完璧な言語だとか口が割けても言えないのは間違いないが、Rustなんて言語ですらない汚物使うくらいならC++使うわなあ

ID:KYsAJ7k0のコードのRust版まだー？

>>133
rlsあるし十分やん

TSは手段と目的がたまに入れ替わるのが見てるとちょっもモヤモヤするな。
C#が最近もう一度好きになってきた。

>>138
まあまあ今ごろコンパイラに怒られてる頃だしもうちょっと待ってやろうぜwwwwww

rustスレよりもりあがっとるやんここ

cに名前空間とラムダとattribute((cleanup))が入るだけでもだいぶ助かるのに。
なんでcの規格のバージョンアップは遅いんだ？
c++みたく3年毎にしてくれたらいいのに。

>>142
あそこモジラの工作員しかいねえし

Rustが言語ですらないただの汚物って正しい認識を共有できる人がちゃんといるのは素晴らしいと思う

>>143
C++みたく闇鍋状態にしたくないからだろ。

モジラが2ch見てるわけねーだろ
糖質かよ

rustをそこまで毛嫌いする必要もないと思うけどな
rustのメモリオーナーシップモデルとかコードの改善に貢献するという話もあるし
ちょっと気にはなってる。

rustアンチって同一人物だろ
コンパイル通らなくてイライラしてるんだね＾＾
コテ付けて、どうぞ

rustは何がそんなに駄目なんだろ
そこ迄言われると学びたくなってくる

>>149
他の言語にはない所有権システムが原因で学習コストが高い
使いこなせば強力だけどとても難しい機能
それで使いこなせてない人が「コンパイル通らない」って発狂してる

例えると、初めてHaskell言語触る人が「変数に代入出来ないから何も出来ない！Haskellは欠陥言語！」って言ってるような物

rustのコンパイルを通せない低級汚グラマーが
嫉妬で腐してるだけだろ

腐ってるのはテメーの言語センスだろってね

Haskell言語って何だ
夜は誤字増えるから寝よう

>>150
なるほど、でも面白そうだな

パフォーマンスは良いって聞くし
haskellも好きだし一通り触ってみるかな

まあ御託はいいからデータコピーなしの平衡二分木をRustで書いてからにしてくれよ
Cのコードは出たぞ

Haskellなら副作用だらけのコードは断固拒否するだけだが
Rustで副作用を拒否すると延々と粘着されそう

ついでにPythonは静的型を拒否するだけだが
Goはジェネリクスがない件で永久にいじめられるんだろう

Haskellは速さは捨てて副作用を無くすことに全振りしてるけど、Rustはそうではないからな

Rustはunsafeつかえば（ffiしたほうがはやいだろうが）できないことはないと思ってるんだが違うのかな？

Goはいつものgoogleのフカしで持ち上げられてる感がプンプンするぜ。
単なる昔ながらのVM使ってない静的型付け言語を
システムプログラミングとかいうバズワードを作って
スクリプトしか描いたことない奴らにいかにも新しいものであるかのように錯覚させてる。

>>157
初めからプログラム全体をunsafeで囲ってある状態を仕様にすればいいのにな

>>158
バズワードだろうがなんだろうが、速くて書きやすけりゃ正義よ

最近は新しいOSSもGoで書かれてるの多くてうんざりする
再来年辺りには「Goは終わった」とか言われだしてScalaと同じ道を辿るのわかりきってるのにWeb系の馬鹿共は何度同じ間違いを繰り返すのか

個人的にはDが一番純粋なc++ 後継って感じで頑張って欲しいんだけどなぁ
まったく流行る兆しがない……
別に新しい言語を求めてるんじゃないんだ。c++ からc互換を取り除いて標準ライブラリと文法見直してくれるだけでいいんだ

>>160
「新しいOSSもGoで書かれてるのが多」いのに
「再来年辺りには『Goは終わった』とか言われだ」すのか。すげえな

まあGo2.0の漏れ聞く噂によると可能性なくもないんだが

>>161
GC言語な時点でそりゃねえわ
全く同じ理由でGoもC++の完全な後継ではないと思ってるけど

>>162
Scalaという前例があるからね
特にビッグデータ系はScalaのOSSが多くて悲惨だよ
壮大な糞の山が残されてしまった

>>164
Scalaが廃れた理由は、言語のバージョンアップ戦略がクソofクソだったってのと
コンパイル回りの性能が悪いっていう言語自体の特徴、
それから置き換えを狙っていたはずのJavaの進化に取り残されたことっていう色々と複合的な原因がある

Goがその後追いをするかって言われると、
少なくとも書きやすさの面でC++がGoに勝てる目は向こう5年はないだろうし、
バージョン戦略は少なくとも1系の間は下位互換性崩さんだろうしな

不安があるとするなら、なんか1系と完全に互換性なくすとか言われてるGo2.0なんだよな
この辺の方針次第では、おっしゃる通り再来年にはゴミの山になってる可能性が無視できない

Swiftがクソバージョンアップでもなんとか成功してるのはプラットフォーム囲い込んでるのがでかい

AA木のRust版の移植を練習がてらやったぞ。
みんなunsafeが必要とか言ってるが、別に必要なくない？
ポインタ演算もサイズの違う型の変換もしてるわけじゃないから生ポインタ扱う必要ないと思うんだけど。
だた、マジで愚直に移植したから全くRustっぽくはないし、
俺がバカなだけで無駄なオーバーヘッドが気づかんうちにいっぱい発生してるかもだから指摘よろしく。
一応何回か適当にinsertとremoveして正しく動いてるとこまでは確認してる。
みんなunsafe使わないとダメ的なこと言ってるから正直これでいいのか全然自信がない。

#[derive(Debug)]
struct Tree {
value: i32,
left: Option<Box<Tree>>,
right: Option<Box<Tree>>,
level: isize,
}

fn level(root: &Option<Box<Tree>>) -> isize {
if root.is_none() {
return 0;
}
root.as_ref().unwrap().level
}

fn left_end(root: &Option<Box<Tree>>) -> &Option<Box<Tree>> {
if root.is_none() {
root
} else if root.as_ref().unwrap().left.is_none() {
root
} else {
left_end(&root.as_ref().unwrap().left)
}
}
（続く）

fn right_end(root: &Option<Box<Tree>>) -> &Option<Box<Tree>> {
if root.is_none() {
root
} else if root.as_ref().unwrap().right.is_none() {
root
} else {
right_end(&root.as_ref().unwrap().right)
}
}

fn skew(mut root: Option<Box<Tree>>) -> Option<Box<Tree>> {
if root.is_none() {
return root;
} else if root.as_ref().unwrap().left.is_none() {
return root;
} else if root.as_ref().unwrap().left.as_ref().unwrap().level != root.as_ref().unwrap().level {
return root;
}
let mut left = root.as_mut().unwrap().left.take();
root.as_mut().unwrap().left = left.as_mut().unwrap().right.take();
left.as_mut().unwrap().right = root;
left
}
(まだ続く)

fn split(mut root: Option<Box<Tree>>) -> Option<Box<Tree>> {
if root.is_none() {
return root;
} else if root.as_ref().unwrap().right.is_none() {
return root;
} else if root.as_ref().unwrap().right.as_ref().unwrap().right.is_none() {
return root;
} else if root.as_ref().unwrap().right.as_ref().unwrap().right.as_ref().unwrap().level != root.as_ref().unwrap().level {
return root;
}
let mut right = root.as_mut().unwrap().right.take();
root.as_mut().unwrap().right = right.as_mut().unwrap().left.take();
right.as_mut().unwrap().left = root;
right.as_mut().unwrap().level += 1;
right
}

fn decrease_level(mut root: Option<Box<Tree>>) -> Option<Box<Tree>> {
if root.is_none() {
return root;
}
let left_level = level(&root.as_ref().unwrap().left);
let right_level = level(&root.as_ref().unwrap().right);
let mut expected_level = 0;
if left_level < right_level {
expected_level = left_level + 1
} else {
expected_level = right_level + 1
}
if expected_level < root.as_ref().unwrap().level {
root.as_mut().unwrap().level = expected_level;
if root.as_ref().unwrap().right.is_some() {
if expected_level < root.as_ref().unwrap().right.as_ref().unwrap().level {
root.as_mut().unwrap().right.as_mut().unwrap().level = expected_level;
}
}
}
root
}

fn insert_tree(mut root: Option<Box<Tree>>, value: i32) -> Option<Box<Tree>> {
if root.is_none() {
root = Some(Box::new(Tree {
value: value,
left: None,
right: None,
level: 1, }));
} else if value > root.as_ref().unwrap().value {
root.as_mut().unwrap().right = insert_tree(root.as_mut().unwrap().right.take(), value);
} else {
root.as_mut().unwrap().left = insert_tree(root.as_mut().unwrap().left.take(), value);
}
root = skew(root);
root = split(root);
root
}

fn remove_tree(mut root: Option<Box<Tree>>, value: i32) -> Option<Box<Tree>> {
if root.is_none() { return root; }
else if value == root.as_ref().unwrap().value {
if root.as_ref().unwrap().left.is_none() && root.as_ref().unwrap().right.is_none() {
return None;
} else if root.as_ref().unwrap().left.is_none() {
let succ = {
let end = left_end(&root.as_ref().unwrap().right);
end.as_ref().unwrap().value
};
root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value);
root.as_mut().unwrap().value = succ;
} else {
let pred = {
let end = right_end(&root.as_ref().unwrap().left);
end.as_ref().unwrap().value
};
root.as_mut().unwrap().left = remove_tree(root.as_mut().unwrap().left.take(), value);
root.as_mut().unwrap().value = pred;
}
} else if value > root.as_ref().unwrap().value { root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value); }
else { root.as_mut().unwrap().left = remove_tree(root.as_mut().unwrap().left.take(), value); }

関数途中です（1レスに収まらんかった）

root = decrease_level(root.take());
root = skew(root.take());
root.as_mut().unwrap().right = skew(root.as_mut().unwrap().right.take());
if root.as_ref().unwrap().right.is_some() {
root.as_mut().unwrap().right.as_mut().unwrap().right = skew(root.as_mut().unwrap().right.as_mut().unwrap().right.take());
}
root = split(root.take());
root.as_mut().unwrap().right = split(root.as_mut().unwrap().right.take());
root
}
終わり。
クソコードの上に長くてほんとすんません。

あと、おもてのコードでは一度もunsafeは使ってはないけど
Option型のtakeメソッドが所有権を誤魔化すために裏でunsafe使ってる。
あとは、裏でも使ってないと思う。

Rustトーシロの初見だけどこんなにunwrap必要なの怖いって気分になるな……
CのポインタをOption<Box<>>で表現してるからしゃーないとはいえ

ここまでやったらもう飽きた。
誰かメソッド構文とかコンビネータとかをきちんと使ったRustyなコードに書き換えて。

Rust嫌いな奴はCをすぐ引き合いに出すが、misraの案件やったら死ぬんじゃねえかなって思う。

GC言語も悪くはないぞ。ちゃんとGCの動き考えれば、正しく開放「されてない」理由もわかるだろ。
最初からデカイ配列を握って離さない、それを切り貼りして使う、みたいなJavaのプロジェクトあるしな。

>>175
あくまでも愚直に書いてるからこんなにunwrapとas_refとas_mutだらけになる。
if letとかコンビネータとかをきちんと使えばこんなひどいコードにはならないよ。

rustのコード<>だらけで読みにくい
これはlispの括弧みたいに慣れたら読みやすいものなのか？

>>153
難しいとは言ってもOOP→関数型のパラダイムシフトに比べれば簡単だけどね

>>154
おい、お前でてこいよ

rust も haskell も理解できても面倒だし無駄に言語に気使ってるだけじゃねーかって
思うんだが、信者はききやしない。。
「お前らは理解できないものを理解できる俺偉い」で思考停止しちゃってんだよ。

一番言語に気を遣わないといけないのはC++だがなｗ

型っていうシステムが
そもそも良くないっていうのは無いの？

>>181
出てきたが、お前まさかこんな汚いコード未満とCのコード比較させる気か？勝負にならん。解散

>>182
それならマシで、Rust信者の工作員はモジラブランドのためなら使えないものを世界中の企業に絶賛させるための工作をに熱心すぎてもうね

>>185
おめー流石に一から書いてもいない奴が言うセリフじゃねえよ
Cライク信者からしても何様だてめえは

>>185
てめえがしね

>>182
「俺偉い」はさすがにないわ。笑かすな。

Rustに移植してみての感想だけど、確かにコンパイルを通すのには苦労したけど、
通ってしまえばメモリーリークはないって安心感がある。これが重要。
特に今回はunsafe一度も使ってないからなおさら安心できる。
Cのほうのコード一通り眺めてメモリーリーク無いって確信できる？
それができる超人君なら確かにRustは全く必要ないが。
Rustは君の嫌う面倒さと引き換えに安心を得ることができる言語。
むしろCで書いたコードにメモリーリークがあるのかないのか
自分の書いたコードに自信が持てないやつのためにこそRustがあると思ってる。
面倒だけが理由で思考停止しているのはどっちだ。

>>185
確かにこのコードは汚いよな。そこは自覚してる。
マジで誰かRust風に書き換えてくれない？
動いたところまで確認したところで集中が切れてしまってもうやる気が出ない。
Rustはオブジェクト指向も関数型のパラダイムを両方とも持っているし、
きちんと書けばかなり綺麗で整ったコードに書き直せるはずなんだよ。

あと、Rustアンチに１つ聞きたいことがある。
Rustが嫌いってことはわかったけど、じゃあアンチ君の好きな(愛用してる)言語は何なの？
その言語のメリット・デメリット含めて詳しく解説してくんない？

はっきり言わせてもらうけれど、
この規模のコードで書くのにそれだけ苦労する価値があると思えんが。
メモリリークについてもこの規模なら一通り見て、あるかないかくらい判断できるよ。

まあ主観といえば主観だけれど
本当に本心からこの程度のコードについてメモリリークを心配しちゃってるの？
言語を持ち上げるために無理に納得しようとしてない？

そりゃこの程度の規模じゃRust使うメリット皆無だよ
で、実際のプロジェクトがこの程度の規模なの？

なんでこの規模に限定した話をされているの？

Rustアンチスレ
http://2chb.net/r/tech/1509028624/

ブラウザの性能が圧倒的にchromeより上になったらrustの優位性が証明されるけど。
それをまとうかな。

性能の差で優位性を証明したことなんて今まであったっけ
オブジェクト指向も関数型もiPhoneもみんな性能と関係ない価値観だったような

>>185
さすがにコード一行も書いてない奴が言っていいセリフじゃねえわ……

>>189
さすがに後出し条件がひどい。そもそも発端は「Rustでは（unsafe使わずに）木構造すら書けねえだろ」って煽りが発端で
「さすがに木構造くらい（unsafeなし）Rustででも書けるわ」ってのの話がこれだろ

そりゃコンセプトが「安全性」なんだからCで書くより面倒なのは確かだし、この程度ならCの方がいいってのも当然だが、
そこを比較するために書いたもんじゃねえだろ

見苦しくなってきたな

流石に自演かすぎる…

>>183
そんなことはないと思うが
何か具体例ある？

>>195
言いたいことはわかるが
その「この程度」のも全部快適に書けるのが理想なわけだよね

この程度のをいっぱい書かなきゃいけなくなったときにこの調子じゃ萎える人も出てくるだろう

>>195
安全性のためとか言って結局まともにかけないアルゴリズムがあることを見て見ぬふりの信者

健康のためなら死んでもいいを地で行ってるな
これが宗教ってやつか

Rustが面倒そうなのは伝わったが
C側の奴がコピペ野郎のくせに暴れてるクズすぎてなんとも

>>200
まともに書けるけど無料で教えてくれる人が少ないだけだってそろそろ気付けよ
普通は健康のためではなくカネのためにやってるから

というかさ、Rustのコードバグってるんだけどwwwww
バwグwっwてwるwんwだwけwどwwwww
remove_treeで要素Removeできてないwwwww

Rustはコンパイル通れば安心できる（ドヤァ）とかいってバwグwっwてwるwwwww

ここにRustは、安全性を高めると言いつつまともにアルゴリズムを書こうとすると制約回避のためにとてつもなく汚いコードになり、
バグもCより出やすくなることが公になりましたとさ

ちゃんちゃん

>>198
言語に気を遣わないとすぐ自分の足元を撃ち抜く言語であるということに同意しないということ？

具体例っていざ言われると困るなあ。ふと思い出した阿呆な失敗談を一つ挙げると、クラスの値型配列を作れちゃうところとか、クラスは絶対ポインタで持たないといけないDとは対照的に感じたな

常識的に考えたらクラスの値型配列なんてやったらダメなのはわかるんだけど、なぜかやってしまって、コンパイル通ってんのに思ってたのと違う挙動して困ったわ。こういう常識的に考えたらわかるけど、考えないといけない部分があるから言語に気を遣わないとやっていけん。

これは全然大したことない例だけど、なんか他にもあったような気もするし思い出したら書き込むわ

代入がなければ値型でもポインタでも同じ挙動だ
だから、代入しようとしたらコンパイルが通らない言語が現れた

haskell追い出したら次はrustですか？

追い出す権利はないね
あると思ってるやつは権利に甘えすぎ

https://cpplover.blogspot.jp/2017/10/range-based-for.html

まあこう言う馬鹿がいなくなるまでは
実際のコードについて議論したほうがいいとは思うよ。

別にrustとかhaskellが悪いとは思わんけれど、コードなんて実際に現場で機能するかどうかが
一番重要なわけだから。原理に走ると都合の悪いことを無視し始めるのは気に入らん。

>>203
すまぬ。すまぬ。完全なうっかりミスだったわ。
訂正した。

fn remove_tree(mut root: Option<Box<Tree>>, value: i32) -> Option<Box<Tree>> {
if root.is_none() { return root; }
else if value == root.as_ref().unwrap().value {
if root.as_ref().unwrap().left.is_none() && root.as_ref().unwrap().right.is_none() {
return None;
} else if root.as_ref().unwrap().left.is_none() {
let succ = {
let end = left_end(&root.as_ref().unwrap().right);
end.as_ref().unwrap().value
};
>> 訂正前 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value);
>> 訂正後 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), succ);
root.as_mut().unwrap().value = succ;
} else {
let pred = {
let end = right_end(&root.as_ref().unwrap().left);
end.as_ref().unwrap().value
};
>> 訂正前 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value);
>> 訂正後 root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), pred);
root.as_mut().unwrap().value = pred;
}
} else if value > root.as_ref().unwrap().value { root.as_mut().unwrap().right = remove_tree(root.as_mut().unwrap().right.take(), value); }
else { root.as_mut().unwrap().left = remove_tree(root.as_mut().unwrap().left.take(), value); }
...

>>204
何度も言ってるがこのコードが汚いのは制約回避のためじゃなくて、Cのコードを愚直に移植してるからだぞ。
CのNULLを表現するためにOption型を使用してるから、コンビネータとかを
きちんと使わない限りはunwrapだらけになってコードが汚くなる。
Rustのコードが汚いんじゃなくてRustyに書いてないから汚いだけ。
同じことを何度も言わせないでくれ。

確かに、Rustはコンパイル通すために苦労するから、
執行錯誤してるうちにうっかりミスしやすくなるという考えはあるのかもな。
まあ、この程度のミスを犯す俺が単純にバカすぐるのか、これもRustの課題のひとつだと考えるかは
人によって意見が分かれてくるところじゃないか？みんなどう思う？

カネもないし時間のゆとりもないからコードが汚くなった
言語よりもカネと時間の使い方が間違っている

>>205
クラスの値型配列はごく基本的で有用なデータ構造なんだけど…

いや俺もちゃんと具体例出すか。例えば
class Point { public: double x; double y; }; だの Point3D だのが定義できて、
vector<Point> や Point v[..] が扱えなかったらシステムプログラミングなんかできやしない
…かどうかは別として別に値型の配列は必要なデータ構造だし、
immutable であれば直感に反した動作もないのでは。

実際に用途の多くは inmutable なオブジェクトの配列で、
C++17 では vector<const T> が許容されるようになりそうな流れ。

>>214
ああ、すまん。Dでは構造体は継承出来ない代わりに値型可能、クラスは継承出来る代わりに値型不能なんよ。そのイメージが残ってたわ。
継承したものを値型で混ぜ混ぜしてしまったというのが俺のミスなのです

何でスレタイからHaskell外したんだよ
それならGo外せよ

なんか元々の C のコードを Rust に下から生じた問題みたいに言ってるけれど
tree のアルゴリズムを実直に書けばそういうふうになるだろ。
それってつまり実直にアルゴリズムを記述するのに向いてないって言ってるようなもんだろ。

また無様なHaskellのコード見るの嫌だし、むしろスレタイには言語一切入れんでもいいだろ。

好きなら、なぜ好きかを推すだけで充分議論になるのに、
他の言語を貶めて、○○はゴミだから△△が良い、って論調にするのはちょっとおかしいんじゃないの？

ホームレスが椅子で寝るの見て、俺はブラック企業戦士だけど屋根のある部屋で椅子で寝てるだけマシ、って言ってるように聞こえるよ。
好きで椅子で寝てるなら椅子寝のこだわりぐらい書けよ。パイプ椅子なら圧倒的に互い違い派だ、とか。

貶めるのが許せないという気持ちがよくわからない
例えば残業代未払いは許せるが貶めるのは許せないとか
なんでそういう優先順位になったのか理解できない

エアプガイジの言ってることわかる訳ないんだから絡むな��

Rust派の意見としては、

�@TreeはCより汚いけど他のメリットが大きいから許せ

�Aもっとうまく書けるから俺が書いてやるぜ

�B副作用のある木は糞

どれ？

>>218
隔離スレだしな。
プログラマ自体、人口のほんの一部だし、複数の計算モデルが異なる言語を使いこなしてるのなんて更に希少種だから、もともと言語のマトモな比較が出来る奴が殆ど居ない。
だからここで言い合ってるのはおま環がデフォ。

>>184
型がないと引数なり戻り値なりで与えられた情報をどう扱っていいかわからないでしょう

返り値が返るのも
それも副作用って事にならないのはなんで？

式に値があるのは副作用と言わないから

>>224
主の作用だからだろ

>>218
無様なHaskellコードって？

>>211
ちゃんと具体的にコードを書いてくれて議論しやすくしてくれたのはありがたい。
tree を rust で実装しろって言われたら 10 人中 9 人は Box と Option を
使ったそういう構造体作ると思う。

>>214
Pointの例に限って言えば同意できないな
大量の小さなベクトルを扱うような場合、構造体を使うより各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
C++系の言語で行持ちの方が好まれるのは、一番の理由は言語の性質上そのほうが扱いやすいからに過ぎない
最近は列指向DBなんかも普通に使われるようになって、データの列持ちが見直されつつある今、
列持ちのデータ構造をスマートに扱える言語があってもいいと思うわ

>>229
Fortran, Juliaのことか？

>>227
>無様なHaskellのコード

908 ：あ：2017/05/31(水) 09:15:21.09 ID:dc+IbjjD
>>905
具体的に上げろと言われてもなぁ。
<T>を持ったenumがOptionかcar(T)とcdr(<T,T>)である時くらいかな。

これのことじゃないの？（適当）

てか
>>229
> 各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
これってどういう演算の時にそうなるんです？

Rustアンチくんはペチパー

はっきりわかんだね

>>219
許せないんじゃなくて、健全ではないよね、と。
なんせ改善せずとも、自分があたかもまともであるかのように思える一番楽な方法だし、進歩もない。

>>222
ホントに。好きなら好きで良いんだよ。
バカで比べる事ができないなら素直に信者してりゃ良いの。
狂信者が戦争起こすような真似をネットでまでやらんでもよろしい。

>>227
>>231
しかも、結局すごくひねり倒してグダグダ言った割に、最後まで動くコードが出てこなかったんだけっけ。

>>232
分かりやすいのはパディングが入るケース
ループのベクトル化もスカラー配列の方が効きやすいらしい

>>235
うーむ……
もしかしてPoint3Dのベクトルに一括して行列を掛けたりする状況を想定しているのか？

そういう状況でもない限りそもそもボトルネックにならないからな

>>211
試行錯誤の過程でアルゴリズムぶっこわれるってのはよくあるが、そうならないためにテストコードがあるっちゃそうだから、
明確な欠点とは言えないかもな

まさかスレに貼るサンプルコードにまでテストコードつけろなんて言えねえし。

>>234
ドアの奴なかな？
あれならHaskellのコード出てただろ
いつまで言ってるんだ

コード出すという行動ではなく
コードが正義っていう知見への承認とか共感が欲しかったんじゃないか
だから行動だけでは駄目

>>239
じゃ、いつまで、スレタイにはHaskellが、って言ってんだよ(笑)

なぜ私達は Python から Go に移行したのか
https://frasco.io/why-we-switched-from-python-to-go-19581e27de7c

よくあんな無様な知ったかぶりしといて人のこと無様とか言えるな

これだからペチプァは

>>243
自分が無様だと思ってる奴に無様だと言われるのはさぞ辛かろうが、
俺が無様なのとHaskell書いたやつが無様なのは別の事象で、

同時に無様でありえるんだから、その指摘はナンセンスだろ。
その理解力でHaskell最高！と思ってるのも面白いな。Maybeの真髄だろ。事象を整理するのは。

なんだこいつなんで俺がHaskell 信者みたいな前提で煽って来てんだ

もう最新規格のFortranで良いよ

Fortranに第一級関数がついてimplicit noneがデフォルトになってinterface文をもうちょっと短く書けるようになって引数の型指定をCみたいに書けるようになって
配列の大きさ指定の関数に組み込みでない関数を使えるようになってgfortranのbind(C)周りのバグを解消してくれたらFortranでいいよ

西京言語PHPを使えばいいじゃん（いいじゃん）

PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい

mod_perlとだったら大して変わらん気がする

＞PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい

キリッ

ｗｗｗ

皆がCGIという共通ルールを守る中
汎用性のない独自実装をしたphp

まあ今更Perlとかって選択肢はないからね

FacebookはなんでPHP推しなの？

PHPをC++に変換するんだっけ
むしろJavaをC++に変換するのを誰もやらない理由を知りたい

>>256
Javaは事実上サーバーでしか使われていないので、
全くメリットがないから

phpのがサーバでしか使われてない印象
どっかで使ってる?

>>254
別にCGIはperlでなくてもいいだろ
プロセスを起動するインタフェースのお約束だよな
perlは文字列処理が得意だっただけで

PHPの特徴ってインスタンスの生存時間が極端に短い。ってこと。
request受けてからresponse返すまで。
だからGCが貧弱でも何の問題もないし。糞汚いコードでもメモリリークが問題にならない。

>>256
GCC
http://news.mynavi.jp/news/2016/09/08/290/

あと、AndroidはJavaじゃないからノーカンなのかもしれないが、
以前はネイティブに全部変換していたのをやめた

>>255
むしろPHPを積極的に潰そうとしてる印象なんだが
クソ挙動しかしないウンコ製造機PHPを潰すためにHHVMは作られたんだぞ

>>255
最初は何も考えずにお手軽に作れたからPHPだった
大きくなりすぎてから管理コストを考えてノロノロと移行を企てている
そんなとこだろ

それ以上ペチパーの心のより所を叩くのはやめてやれｗ
彼ら、憤死してしまうでｗｗｗ

>>260
言ってること滅茶苦茶だな

伝えようとすれば滅茶苦茶
隠そうとすればバレバレ
だから型情報とか一生懸命伝えようとする言語が報われない

>>242
go 好きな人ってまともすぎてつまらんな。

>>261
ARTは全部変換なんてしてない
元からJITとAOTの複合

>>267
きんも

>>268
http://gihyo.jp/lifestyle/clip/01/awt/201603/24
＞しかし，AOT方式をいざ導入してみると，サイズの大きなアプリのインストールや，
＞一度に複数のアプリをアップデートするような場合にコンパイルに時間がかかり，
＞場合によっては20分程度かかるケースが存在していたようです。
＞このインストール時間を問題と捉えて，Android NのARTでは，JIT方式をもう一度使うことになりました。

>>242
GOいいな

>>271
Goは色々足りないところも多いが、生産性にステガン振りしてるって点で評価できる
Rubyみたいに前借りではない

Rubyの教訓は、「Perlよりマシ」に全振りしたけどPythonと比べると大したことなかった

Goのどこに生産性があるんだよ

>>274
そりゃ、ひたすら書ける部分だろ。
迷わんぞ。書く量が多いだけで。

生産性と言うと表現力ばっかり取り上げられるが、単位時間あたりのアウトプットも見ないといかん。
その点、信じられないレベルで楽。

>>275
行数多くなるから生産性が高いように見えるだけだろ

そいつは関数型しったか野郎なので話すだけ無駄
無知が無知なりの常識で頑張って答えてくれるかも知れないけど参考にはならないだろう

迷わずひたすらに書かれたF77のコード読みづらすぎ

Goは構造体へのタグ埋め込みや、codegenまわりのツールが充実してるお陰で
ボイラープレートコードを書かんでいいのがでかい
それだけならLLでもできるが、テスト作ってから設置して実行するまでの作法が簡潔に固まってるのが更に強い

少なくとも時間当たりのテスト含めた成果物は他の言語と比べ物にならん

逆に、汎用ライブラリ書こうとするととたんにinterface地獄になってボイラープレート増えるんだがな
だから、目の前の仕事の案件片付けるのに特化した言語だと思ってる

>>221
ちょっといまさらだがRust版平衡木(AA木)をリファクタリングしたぞ。
まあ、だれも書いてくれそうになかったし、数日たったらまたやる気も出たから自分でやり直したわけだが。

基本的には�Aだが、すべて当てはまるな。
RustはNull安全なのでOption型のチェックが必須、コンパイラに所有権を伝えるためas_ref等が必要、
デフォルトはイミュターブルのためミュータブルを扱うためにmutキーワードが必要などが主な理由。
そこら辺の安全性と引き換えに多少は目をつぶってくれという感じはある。
�Bに関しては副作用もあるが、それよりもどちらかというと木構造の回転操作みたいな
変数の所有者が次々に代わるようなコードはRustでは所有権システムがあるため書きづらい。

とはいえ、前のコードに比べれば大分マシにはなったかと。
まあコードが綺麗か汚いかなんて個人の主観によるところが大きいから、まだ文句を言うやつもいると思うけど。。。
特に>>217なんかには「どんなアルゴリズムだろうが言語によって最適な書き方は違う」
ということをきちんと理解してもらいたい。

あと、コードのリンクを貼るという手段があることを知った。
比較できるように全て載せておく。
C版
https://wandbox.org/permlink/fc1xI7dDCdOMgysC
Rust版 before
https://wandbox.org/permlink/cbzzpLw97K2Tydk1
Rust版 after
https://wandbox.org/permlink/ppQOQREnDlpccpJV

ほう

>>276
そーでもないぞ。

>>277
関数型以外シッタカの意識だけ高い系に言われてもな。
人をディスるんじゃなくて、自分を高めれば？
無理なんだろうけど(笑)

関数型以外シッタカ←根拠なしのただのディス
からの
人をディスるんじゃなくて自分を高めれば？

自戒かな？

そいつの相手しても得るもん無いってことくらいはそろそろ分かって欲しい

言い返されてそれはみっともないリアクションだな。
よほど、関数型言語が好きなんだね(笑)

専スレ立ててやれよ。次世代言語でもないわ。

好きなら好きで良いのに、なぜ固執するかわからん。
ナイフで整備できるようにネジを全部マイナスネジにしたロシア(？)の戦車みたいな間抜けな話と同じように、目的に対して使う道具なんか考えりゃ良いのに。

よほど関数型言語が好きなんだね←誰もそんなことは言っていない

なぜ固執するかわからん←固執していない

誰と闘っているんだコイツは。少なくとも俺じゃねえな

おまえら旧世代猿人類どもはウンコブラシのプェチピィのゲリクソピィでもプリプリしてろ

>>281
コンパイル通らんのを試行錯誤してる間に答えが出てしまった悲しみ
まとめてもらって感謝。勉強してみるわ

>>281
比較を載せてくれてありがたい。
やっぱり
C -> rust before -> rust after
となっていくごとに読みづらくなってるんだけれど。。

>>270
それの何が反論になってると？
元から速度云々関係なしにネイティブ変換できない部分があったんだよ

>>291
root.as_ref().unwrap().level
を
root->level
と書いて良いというシンタックスシュガーを導入すれば良い気がする

unwrapはNoneだった場合にランタイムクラッシュする関数だから本来使ったらアカン関数
この辺はnil安全うたってる言語はおおむねそう

Goは最初期Javaかっていう後退レベルだし、Rustは木構造すら数日かかりで必要な難解言語だしでどっちもクソ言語
はいこれで仲直り

パラダイムシフトを強いる言語は地雷が多いな。
俺はリアクティブプログラミングで懲りた。

数日がかりというが兎と亀みたいにRust以外の言語は寝てたから
Rustが一番早い

その理屈だとCが一番じゃん？

結局当面はC#系(TypeScript/Kotlin)の天下ということでよろしいか

>>294
そういうこと。だからRust版 afterではunwrapはほとんど使用していない。
通常、Optionの中身を取り出すときはunwrap_or, unwrap_or_else, unwrap_or_default
のどれかを使用してNoneだったときはどうするのか指定する。
unwrapを使用するときはアルゴリズム的に中身が存在しないこと自体がありえなくて、
Noneならバグと判断してむしろそのタイミングで落ちてバグを知らせてほしい時のみ使用する。
この仕組みによってNullが存在しない(いわゆるNull安全な)言語を実現している。
多少書くのは面倒だが「10億ドルの損失」に比べればこのくらいカワイイもんだろってこと。

ちなみにC#なんかでも導入が検討されているらしいが、既存コードとの互換性が保てないので難儀しているようだ。
Type scriptみたいにコンパイルオプション付ければいいのにとか俺は思うんだが、なんか理由があるのかな？

コンパイルオプションだと既存コードを一緒にビルドできなくなるだろ
互換性を絶対神とするC#に導入するなら、#pragmaでソースファイルごとにオプトインするか、
asyncみたいに修飾子で特定のスコープだけ解釈を変えるか、
デフォルトをnull非許容にするのは諦めてstring!にするかのいずれかだよ

Goが優れてる点はcode生成に最適化されてる点だと思う。

Goはメソッド定義が同じディレクトリ内なら何処でもできる。
つまりコード生成によってメソッドを追加できる。
ファイルでコード生成の箇所と自作の箇所をわけれる。

>>296
Rxはもっとシンプルな定義にできないのかなーって思う。
「全てはストリーム」という考え方はシンプルなのにいざ使おうとすると
ライブラリは複雑すぎる。

もしかしたら言語まるごとRxの考え方で作ったら簡単になるんかな。
Rubyの作者がStreamって言語をつくってるけど、、、、完成しそうもないし

rust で
if root.is_none() {
return 0;
}
root.as_ref().unwrap().level
を
match root {
Some(node) => node.level,
None => 0
}
と書かないのは何故？所有権とかの問題？

>>304
え？どっちでもいいよ？
リファクタリング後のコードでは使用してないはずだけど。。。
それでもいいし
root.as_ref()
.map(|node| node.level)
.unwrap_or_default()
でもいいし
if let Some(ref node) = *root {
node.level
} else {
0
}
でもいい。どれを使うかは好みの問題。
ただし、>>304のmatch文は正確にはこうなると思う。
match *root {
Some(ref node) => node.level,
None => 0,
}
rootはたぶん型が &T (借用) だから*で参照外しないといけないし、
ref は所有権を「移動」じゃなくて「借用」するために必要。

>>304
>> リファクタリング後のコードでは使用してないはずだけど。。。
誤解を招くかもだな。すまぬ。
if root.is_none() {
return 0;
}
root.as_ref().unwrap().level
のほうはリファクタリング後のコードでは使用してないはずだけど。。。だな

なるほど。ありがとう。

いいってことよ

if not is_none 判定時に実行される、
コンパイラさんにも非noneと分かるコードパスでは
unwrap省略できれば読み書きする際にもPanic起こさないと分かりやすいしシンプルになるな。

実際にも最適化でチェックのコードも吐かれてないだろうし。

>>308
んん？ちょっと待て。良くないぞ
誰だぁ？俺の手柄を取ったヤツは？

>>309
そのやり方は所有権システムの関係で難しいかもしれないな。
非noneが分かっていたとしても中身を取り出す時に所有権を移動する借用するのか決める必要がある。
そして、移動するにせよ借用するにせよ、取り出した時点から所有権システムの制約により
その親にあたるOption型の変数がスコープを抜けるまでは参照不可になる。
移動する場合は、スコープが抜ければOption変数ごと一緒に消費されるはずなので問題ないと思うが、
借用の場合は、スコープを抜けるまでOption変数が参照不可のままじゃ困る場合も多いだろう。
結局は、if let や match 等のスコープを使って借用が終わるタイミングを
コンパイラに知らせるための表現が必要になるんじゃないかと思う。

自分も所有権システムを完全に把握してるわけではないので、間違ってたら指摘してくれ。

panic の代わりに未定義動作を行うことで、最適化時にNone時の経路が取り除かれる unchecked_unwrap() とかある。
外部クレートだけど。

FFIと静的型は相性悪いなあ

嫌われているプログラミング言語ランキング - Stack Overflow
http://news.mynavi.jp/news/2017/11/02/073/

最も嫌われているプログラミング言語は？--Stack Overflowが調査結果を発表
https://japan.zdnet.com/article/35109803/

だから何度も言ってるだろ
型なし能なし未来なしの糞言語が
使ってる連中は今すぐ首吊ってなるべく苦しんで無様に血糞尿にまみれて死ねよ

>>316
死ぬだけじゃダメだな
来世でも来来世でも苦しみ抜いてもらわないと

>>317
せやな
一族郎党末代まで呪われて地獄の業火で焼かれるべきだ

その政策の予算をいくらまでなら払えるか考えよう
予算なしは能なし未来なし

すまんが型なし言語って何ンゴ？

機械語のことかな？

変数に型の無い言語か

Go言語で
var 変数名 = 値

の表記の時は型を省略できるそうですが
値が数値で、値から型が確定できない場合はどうなるのでしょうか？
値から型を確定できるのは文字列型と真偽値くらいだと思いますが

>>323
値に応じたデフォルトの型か決まっている

>>324
なるほど
たしかにだいたい推測できますね
ありがとうございました

>>319
予算がないからクソゴミクズ汚物言語を使い続ける？
地獄に落ちろビチグソ野郎

VBA は explicit 付ければ堅く書くこともできるんやで〜。
そんな書き方するやつあんまいないけど。。

>>326
誘導尋問するなよ
というかどうせ誘導するなら天国に誘導しろよ

>>320
PHPは型がないから
とかおっしゃってるいつもの人だろ

>>328
なーにが誘導尋問じゃ
どんな理由があろうと下痢未満言語未満のぷぃーえっちぷぃーを使うことを肯定する時点でお前は地獄行きじゃ！

地獄でビチグソにまみれて二度と転生してくるな！！

次スレはﾜｯﾁｮｲつけないとな。
330みたいな異常者をNGするために。

HHVMを使うという手もあるんじゃ

と言うか、では実務ではウェブの案件には何をお使いで？と聞きたいな。
ホントに何なんだろ。

>>333
330じゃねーけど、フツーにRailsって答えそうではある
フロントいらないAPIサーバならFlaskかGoかってところか

node + ts

未だにphpでlampとかもう（笑）も付かないレベル

叩きは理想の言語とやらでRails越を越える
フレームワークを作ってからしてくれ。

俺の中ではgoでgoaかな。swagger.jsonを介して通信周りもコード生成できる。
API設計するとclientライブラリまで一括して作れるからSPA開発が捗る。
TypeScriptのクライアントライブラリ生成してapiの返すjsonのinterfaceまで作ってくれるから至れり尽くせり。

Railsか。なるほどありがち。
APIサーバはGoとかnode確かに便利。
tsは置いといて。
あれやるくらいならc#とnancyで書いたほうが余程安定する。寿命の面でも。
そして.net coreすごいわ。

TSは最近イケイケドンドン過ぎる気がする。
イシューは閉じれてないけど、次以降のリリースに頑張るわ、ところでこれ！新機能盛りました！
みたいなノリ。

nodeはnodeで闇深いがな……あいつ結構非自明なメモリリーク起こしやがる

ts on nodeってその辺解決できてるのか？

で。おまえは実務ではウェブの案件には何をお使いで？
PHPとか言って笑いを取る必要はないぞ

Django
何だかんだ言われてるけど強いよこいつは

>>340
何でも使う。書捨てでビューがあればphp
ビューがあって書捨てじゃなけりゃasp.net
Tomcatとservletは嫌い。
安定したAPIサーバはGoかc#とNancy。
nodeは個人用。
イントラ多いから、デプロイ先がWindowsサーバで、セットアップが必要な処理系は入れづらいのよね。
phpは過去の案件ですでに入ってたり、だいたいIISは動いてる。

ウチはseaside.st

>>342
浅く広くの器用貧乏なんだね
どうりで、知識はあるけど深い話になるとボロがでるわけで

>>344
器用貧乏だろうなぁ。メインの言語以外は特に。
そもそもしばらくシステム屋じゃないし。
道具としては色々使うけど。用を果たせば良い部分と、趣味として使う分は別けてる。
流石に20代でもあるまいし、わきまえてるよ。仕事は。

ボロが出るというより、単純に知らんので参考になってる事も多いよ。

しったかするから、自分の知らない領域ついても知識があるように見えるだけだぞ

>>346
勝手にそう見てるだけで、俺自身が知ってるよ言ったことはあんま無いんじゃないかな。
俺はこう捉えてる、は話すけど。

>>347
854 ：デフォルトの名無しさん：2017/05/30(火) 13:17:09.64 ID:ynDKwlR5
851
>当たり前だがHaskellみたいに実行時に多相性を解決してる
おいおい、Haskellの実装知ってんのか？
Haskellで実行時に型情報が必要な多相性はほんの一部だ。
ほとんどの場合、コンパイル時に解決される。

863 ：あ：2017/05/30(火) 16:00:40.31 ID:CncaY8jR
854
知ってるよ。実行時に多相性を「しない」のならその主張もわかるが、「ほとんどの場合しない」は「してる」だよ。
「施錠確認した？」「ほとんどしました」って、要は全く施錠の確認できてないのと変わらんよね。

>>348
おお、それは知ってたから。
あんまりと書いてるからわかるだろうけど。

>>341
scaffoldがないのが非常に残念
俺は言語としてはPythonが好きなのに、webとなると無意識にRailsを選ぶようになってしまった

器用貧乏の対義語に名前をつけたい
サンクコスト貧乏かな

Railsって未だに生産性高いんか。
PHPがパクっていろんなフレームワーク作ってるけど

ペチパーって何であんなにフレームワーク作りたがるんだろうな
自己主張が強いのか、ママの愛が足りなくて承認欲求に飢えてるのか

>>353
たかがテンプレートエンジンがでしゃばりやがって感ある。
でもインスタンスの生存時間が短いから開発者に優しい言語ではある。
まぁwebScoketとか繋ぎっぱなしにするような仕組みには弱くなるけど

>>352
なんだかんだであれは死なないよ
資産が豊富で、webのラピッドプロトタイピングにおいては群を抜いておる
Railsライクな他言語のフレームワークがRailsを羨ましがる場面はあっても、恐らくその逆はない

慣れの世界って感じもするけどな
俺はテンプレートエンジンより、Reactで書くほうが最近は楽なのでtypescriptで書いちゃうことが多いな
サーバサイドも必要ならrustかJavaでちょろって感じ

時代はSPAの方向を向いている中あえて今Rails使うメリットってあるんかな。
最初からWebAPI提供できたほうがいいし。

React覚えるとモバイルももれなく作れるのがいい

Node.jsとTypeScript使っとけば幸せになれるということ？

>>358
webassemblyの時代が来るまではね

wasm時代の覇権がどうなるか想像出来ん
とりあえずC++は安定だろうけど

PHP使ってれば食いっぱぐれることはないやろ
ガイジどもが作った負の遺産を保守し続ける楽なお仕事が半永久的にあるで

>>351
器用貧乏の反対は、ホントにその役職に居なければ「大先生」とか「教授」だろ。

フレームワークやIDEを
ドラえもんの道具にたとえると四次元ポケット

>>361
真っ先に自動化されるか、見捨てられるシステムだな。

COBOLやJavaならわかるけどPHPではなあ
ある日突然消えてなくなったところで大した問題のないゴミばかりだろ

おい、アスペチプァさんを馬鹿にするなよ
彼らが本気出したらお前ら血便漏らして死ぬようなコード書くぞ

日本の技術力ガーとか言ってたくせに
結局全部嘘ばかり
バカチョン以下やでホンマ
そりゃペチパーが闊歩しますわ
Rustアンチくんはペチパー
はっきりわかんだね
これだからペチプァは
それ以上ペチパーの心のより所を叩くのはやめてやれｗ
彼ら、憤死してしまうでｗｗｗ
ペチパーって何であんなにフレームワーク作りたがるんだろうな
自己主張が強いのか、ママの愛が足りなくて承認欲求に飢えてるのか
おい、アスペチプァさんを馬鹿にするなよ

ﾏｼﾞｷﾁ

>>367
巣へお帰り

自称次世代言語議論スレ[PHP PHP PHP] [無断転載禁止]©2ch.net
http://mevius.2ch.net/test/read.cgi/tech/1506823587/

ペチアンチの面白語録非難してる奴って胸に突き刺さって抜けないペチパーか？

好きの反対は無関心になるはずだしな。
嫌いな事と言うのは、実は興味があったり、かつて好きだった事があったり、強制され抵抗できなかった惨めさがあったりするもんだ。
あまり人の憎しみを面白半分で扱ってはいかんな。

>>357
SPAは一番最初のローディングがアホみたいに遅いじゃん
これ解決するためだけにSSRもやるの辛い
じゃあ最初からSPAいらないやってなる

【泥沼】 京都市のシステム開発失敗、IT企業に７億５千万円の損害賠償請求　企業側は支払い拒否
http://2chb.net/r/news/1509849067/

>>371
dynamic importが実装されている現状から言って最初のローディングが遅いって問題は解決する。というかminifyすれば十分小さい。
せいぜい500kbとかでしょ開発中は10MBとかだったりしてビビるけど。

>>371
後、最初のローディングが遅い問題がSSRで解決するって初耳なんだけど。
どっちかというとSEO的な問題の解決かと

>>374
意味不明
順序的な動作いらないし負荷や遅延も減るんだから速いだろ

>>373
最初のローディングを早くするのとSEOできるっていう二つがSSRのメリットだと言われてないか？
それからSPAの初回表示が5000msとかかかるのは、DOMを構築する処理のせいだろ？
500kbというのはjsのサイズか？ファイルがいくら小さくてもな…

dynamic importは調べてもよくわからなかったが、解決するというなら良いことだ

>>373
これも意味不明
スクリプトのサイズは飽くまでグロスの転送量の問題であって
動的モジュール読み込みだろうと結局初動が重けりゃ処理遅延するし

>>376
だよなあ…
こいつ絶対エアプだわ

>>367
Rustアンチスレ立てられる原因になったと自認してる俺だが、
PHPはゴミだと思ってるぞ安心しろ

cobol, fortran, vb あたりも相当恨みを買ってる言語だが、ここでの php への
恨みはそんなもんじゃないな。。
使ったことないからわからんが、そこまで嫌われるのは興味あるわ。

>>377
俺の勘違いなのか？
動的ローディング使えばルーティングで該当ページが開く時にネットワークアクセスするから初回転送量は抑えられるだろ。

DOMの構築が遅いっていうのも意味がわかんないな。
現在表示している画面以外のレンダリングも裏でやってるとでも思ってるのか？

PHPは使う必要ないの？

無い

>>381
仮想DOMを作ってDOMツリーに展開していく部分でしょ、初回を早くするためのSSRって。
割と時間掛かる上に描画がロックしがちだから、最初からHTMLとしてDOMツリー渡して、仮想DOMとあとからバインドするんじゃねえの？
該当ページが開く前にロード、じゃなくて、初回の話でしょ。

むしろ「使い慣れてるから」とかいうクソペチパーの戯れ事以外でぷぃーえっちぷぃーなんて使う理由あるならそっちの方が聞きたい

PHPが滅んだとしてその穴を埋める言語って何？Js？

phpの良い所なぁ。
楽な部分だと、nginx+php-fpmでも、apacheでも、IISでも、ファイル置くだけで動く所が一番初心者には楽なんじゃないの？
あれやってるとContent-Typeとかヘッダを覚えない！なんて言うPerl使いももういねぇんだし。
aspやasp.netもまぁ同じ部類か。

unicornもsupervisordもforeverもpm2も要らない、サーバのポートを使う事もない。
リバースプロキシも要らない。リバースプロキシがヘッダを触ろうが割と平気。
こんな言語あんま無いぞ。良いか悪いかは別としても。

>>387
そういうレベルの奴が遊ぶからウンコ量産機になるっていう話なんだよなあ

>>384
はー。なるほど。そこがボトルネックになるっていうのか。
じゃあSPA使わないという選択肢が一番だな。おつかれ。

お手軽魔法のLAMP

仮想DOMからDOMツリーに展開するのとHTMLをレンダリングしてDOMツリーを構築するのと
どっちが速いかって自明じゃないよね？
「HTMLとしてDOMツリー渡して」とか書いてるところを見ると、そこコスト0と思ってるとか？

>>388
単にうんこも作れると言うことだ。

>>389
古き良きFormとポストバックでも何でもすれば良いよ。

>>391
微妙な所では？プロファイルはしてないけど。
DOMツリーも、仮想DOMからどうエレメント作ってるかにもよると思うし、リフロー、リペイントが何回起きるかにもよると思うが、
HTMLとしてDOMツリーを渡して一番得なのは、DOMツリーを解釈したレンダツリーをレイアウトする所まで決定的関数になるから取り敢えず形としては一発で書けるという認識だった。
だから、AMPではレイアウト計算が走らんように、ロード後にサイズが変わる画像は使えない、みたいな縛りを入れてると思ってたよ。
違ったら教えて。

SSRの実装次第じゃね。情報が古いことを許容するならキャッシュしたレンダリング結果を返すという手もある。

>>387
ぶっちゃけPHP貶すやつはプログラマの経験浅いだけだろと思う
言語がどんだけクソだろうと、結局PHPほど、短時間でパッケージ売れて取り回しが楽な環境他にないからな

>>370
> 好きの反対は無関心になるはずだしな。

じゃ、対偶と裏は何？
煽りじゃなくて純粋に疑問

>>393
まぁ、つまるところaspのUpdatePanelだな。
何回歴史を回ってるんだかわからん。

>>394
取り敢えずPHPをdisればウケるという安易な芸風なのか、本気で憎んでるのかはわからんが、ホントに便利だと思うよ。
作者の言う通り、歯ブラシなんだと思う。

>>395
裏とか対偶を取ると何か意味がぼやける気がするが。

好きならば、関心がある
好きでないならば、関心は無い
関心が無いならば、好きではない

嫌いならば、関心がある
嫌いでないならば、関心は無い
関心が無いならば、嫌いではない

「関心」を共通項として消しこんでしまうから好きと嫌いが直結してるように見えるが、
本質的には好きと嫌いは全く違う感情として捉えるべきだと昔習ったよ。精神医学か臨床心理学かどっちかで。
そうしないと凄く嫌いな状態が好き、みたいなややこしいドMとかメンヘラ感情を説明出来なくなる。

頭にプリプリうんこの詰まったペチプリパァのおじちゃん

年収200万なのに生きてて恥ずかしくないの？

WP納品してセキュリティも保守も拡張も考えなくていいならPHPで勝手にすればって感じだけど
まぁ関わりたくないよね

phpがというより動的言語が嫌なんだよなぁ。
リファクタリングとかIDE支援が期待できない。

だからhackなら良さそうなんだけどだれも使おうとしないのはなんで

GoをGAE/Goで使うとインフラもセットで完成した状態で使えるしオススメ。
dockerも、結局インフラ構築と変わんないから触らないで済ましたい

>>400
その理屈なら、DOM操作をIDEで支援する方が良さそう
静的型がないhtmlは終わコンになる

>>402
reactがけっこう静的型html感ある。特にtypescriptでpropsのinterfaceをちゃんと定義した場合ね。

react もなんかだいぶごっつくなってきちゃってるね。
大丈夫なんだろうか。

>>397
395ではないがなるほど。
でも、好きを+1、嫌いを-1、無関心を0と言うふうに数直線で見ると0を挟んで好き嫌いって反対という感じなんだよなぁ。
どMとかは虚数とか。

>>248
実際Fortranって最新規格を見ると超素晴らしいんだよな……
コンパイラを見ると実装が全然追いついて無くてしょぼーんってなる

>配列の大きさ指定の関数に組み込みでない関数を使えるようになって
よくわからんがもしparameterized derived typesのことなら最近gccにも実装された

CやFortranはやっぱ根幹だわ。
枯れて信頼性の高い処理系から、最新機能
を装備した処理系までとバラエティに富み、
常に進化し続けている。

CもFortranも規格だけは刷新され続けているのに実際使える範囲はC99やF95で止まってるけどな
Cを止めてるのは主にVC++だけど

そりゃ基本はC++の処理系だし、Cには関心ないんだろ。
それにそもそも、VC++がC11に対応したからといってC11が普及するとも思えんがな。
誰が使いたがるんだろう、あれ。

>>405
好きが実軸なら、嫌いは虚軸だよ。

C++が糞だから使いたくない人はCくらいしか選択しないだろう。

swiftむずい

Cもラムダ式(かBlocks)とattribute((cleanup))入るだけで随分と楽になるのに。。。
規格更新が遅すぎるんだよ。

それな。特にBlocks

jsの世界のbabelみたく新規格をとりあえずすぐ使えるaltCみたいなものを作ればいいんじゃないの？

は？

昔、Cfront と呼ばれるものがあってね。。

Blocksは江添にクソって批判されてたような
C++との互換性考えたらラムダ式が現実的かと

規格または実装のどちらかが遅すぎる法則
これ9割当たるだろ

最悪なのは「実装がバグだらけ！」

自己書き換えコードが禁止されてるからCでラムダ式とかが考えられてこないんだろうな。

いやCなら単純に関数定義と関数ポインタ渡しの構文糖衣でいいだろ

C++のラムダ式とか最適化のおばけやんけ
あれCに入れれるのか？

素直にC++使わないのは何故。

よくわからんし苦手だから

C++のラムダは文法、型付けともに最悪だろ
第一templateもautoもないCでどうやって持ち運ぶんだよ

それにBlocksもそうだけど
気軽に他言語からのFFIができなくなるんじゃないか
基本的なAPIにこういうのが使われだしたら他が困る……

あとC++ラムダもBlocksもローカル変数をキャプチャーする糞仕様だし
そんなのがABIとして定まってしまうと、例えばD言語が関数ポインタとスタックポインタのペアだけでやってるみたいな
シンプルかつより優れた実装を取ってる組が迷惑するだろ

Cの戻り値が一つしか出来ないというのも意味わからないよな。
２つのレジスターに値をセットして戻せばできるのにな。

評価した結果,値を2つ持つって方が意味わからん気がする
複数の戻り値を表すならタプルみたいなもので1つの値にしてしまうのが一般的だと思うけどCでそれは流石に…という感じ

x86_64のSysVみたいに環境によっては
レジスタ2つ分程度なら構造体で返してもrax, rdx使ってくれるぞ
それに10個とかになると結局構造体返しと同じになるだろうから区別する理由がない

引数は複数なのに戻り値は一つって対称性が乱れてるからな。
引数が一つってきまってるなら戻り値が一つでもいいんだけどな。

まー、今更呼び出し規約変更するのも虚しい結果に至るだろ。

俺は今の言語が解析しにくいのが不満
xmlみたいにシリアライズ容易であって欲しい
プログラムからコードを作成したり
ビジュアル的にコードを表現したり出来ていいと思う

これが出来てやっと次のステージにすすめると思う

それ lisp やんけ

>>434
全然駄目だ
俺には読めないｗ
xmlとかcsvとか形式が決まってた方がいいな

htmlみたいにxmlでフローの書けるプログラムが組めるような言語とか次の覇権を握る
次世代はプログラムの自動生成がメインに来ると思うな
モジュールのビジュアル化
それらを組み合わせるAIとか１０年後のスタンダードになると思う

>>431
カリー化祭

Apache Jellyは全然流行らなかったな。

ID:aP107Usiじゃないけど、俺も言いたい

それLispやんけ

確かに人間の能力で解析できるのはLisp程度かもしれないが
次世代AIだったらLispは甘え

c#は構文解析やるのも字句解析やるのも
結構疲れる
こんなんじゃビジュアル開発できないじゃん
IDEなんてリソースエディタまわり強化するぐらいしか進化する先ねーのに
言語複雑にしてっと自分のクビしめっぞ

C#はRoslyn使えば一発でAST取れるぞ
MSのコンパイラというのは開発ツールのための言語サービスなんだよ

CもABI変えない範囲で新機能は追加してほしい

常にデ／シリアライズ可能って良さげだな
ある時点のスタックトレースを丸ごとダンプして、丸ごと状態を復元できる

>>436
なんかxmlを通すと形が変わる処理系なかったっけ？
SGML通した覚えがある。

ビジュアルなフローを繋いでいくとなると、LabVIEWとか色々あるじゃん。流行らなかったやつだと.netのワークフローとかあったし、
最近だとnode-redとか、Amazonのフローとか。

>>444
仮想マシンを一時停止にするほうが気が楽。

みんなー、Nimでにむにむしよっ

むにゃ

>>445
そうじゃないニム
例えばニムね、Reduxのある時点のStoreを丸ごとjsonにニムしたら
バグとかニムとかの再現に便利だと思ったニムンゴよ

>>448
仮想マシン一時停止にしてスナップショット撮って、再開するのは不便だって事かな。
まぁ確かに不便か。

まあ、普通WPF書いてればモデルクラスにMVVMしてるだろうし、そいつをシリアライズしとけば良いと思うけどね。Reduxみたいに、となると。

みんなー、Nimでにむにむしよっ

>>444
Smalltalk？

フォンノイマンマシーンではデータとプログラムの区別とかレジスターとかはないから
メモリーをコピーするだけで実行時と同じになるんだよな。

fortranって学生の頃に触ったけどなんか独自性あったっけ？basicと変わんないような気がしたけど

>>453
numpyに匹敵する強力な配列アクセスと、明示的なfunctionとsubroutineの区別、引数の入力専用や出力専用を明示するintent機能、moduleなどの便利な機能がfortran90あたりから加わった

学生の頃に触るfortranは77が多いのでfortanはゴミという認識の人は多い

>>452
ところが、メモリを完全に再現する方法がどんどんめんどくさくなってきて、逆にコンピュータ自体はどんどん高速になって、仮想マシンごと取るのが一番楽になってきてしまった。
データとプログラムの区別もつけ始めたしね。

>>453
pureな関数に対して、forallとかつけるだけでバラして実行にしてくれるとか、十年くらい前から、do concurrent で同時実行してくれるとか、でかい計算機使わないとあんまりメリット見えない便利機能とかが独自機能とかかな。

>>453
C99のrestrictや複素数、VLA等の「C++に無いのにどこから出てきた」みたいなのは
Fortran対抗だったりするんだぜ
その後も改定は続いて今のFortranは驚くほど色んなことができるし速度面は依然最強格

実装があればね(´･ω･`)

Juliaを持ち上げる奴は大抵Fortranを古そうというだけで食わず嫌いしてるよね
Fortranをちゃんと触ったことがあれば、今更Juliaなんか全く必要ないことがわかる

ま、Fortranは構文がきもいからね……
あと実装(

Juliaは関数を返す関数があるから……

Fortran触ったことないゆとりの自分に、Fortranで3rd packageの導入・管理する方法を教えてくださらんか……

スクリプト言語ならソースを置くだけか、Cに丸投げだもんな
スクリプトとCを笑う者はパッケージ管理に泣く

>>460
良いように言えばFortranはC言語と同じく下層で使われる言語なので
管理はOSのパッケージマネージャでやらないといけない

悪いように言えば、管理するほどライブラリがない

そもそも、ベンダが出すライブラリが一番速い。
その話は残念ながらできん、といったところかな。

>>461
そう考えるとcargoやgoはよくやってるって気分になるな

他の言語だとあんまり思わないんだけど、 CやFortranの話になると何故か
「LD_LIBRARY_PATHの通っている領域に置くだけじゃん……」
って思う

>>465
例えばプロジェクトAではlibevent2.0を、プロジェクトBでは2.1を使ってる場合どうすんの？
1. LD_LIBRARY_PATHをプロジェクト毎にdirenvかなんかで切り替える
2. -Lオプションで切り替える
3. RustでいうcargoやRubyでいうBundleを手動で頑張る

どれがベストプラクティス？

>>466
静的ライブラリなら-Lでいいんじゃね？
ベストプラクティスかは知らんけど

>>466
マシン二台用意しろよ

>>466
プロジェクト違うとライブラリだけじゃなく設定ファイルとかリソースファイルとかも変わるんじゃない？
そのための環境「変数」なんだと思うがね

dockerみたいなのでやるってこと？

んな大げさな、切り替えたいだけならpkgconfigでいい

てかそこまで動的に切り替えが必要かまず考えた方がいいのでは？

プロジェクトのディレクトリ内に適当に置いとけばいいじゃんあほらし

ちゃんとmakefile書け、じゃない？

>>405
好きの反対は嫌い
無関心の反対は有関心
好きも嫌いも有関心

>>475
なるほどまとまってる。

抽象度が低すぎる単語はポリコレ違反なんだな
だから性別や宗教等を特定できないレベルまで抽象化する

好きも嫌いも、言葉は同じでも指すものが違うからな。
可愛さ余ってなんとやら。

Goみたくメッセージパッシングう方式での並行性に非常に優れていて、そこそこ速いML言語とか誰か作らないかな…

>>479　何に使う？

>>480
Webのサーバーサイドでのプログラミングとか？

F#がもうそうなってるんじゃね

あれ？かつて次代の大物言語とかいわれてたelixirは入ってないの？

そもそも関心があるかどうか関心を持った時点で関心があるから
関心が無いものは思いつかないものでないと関心が無いと言えない。

>484
心理学の話はもういいよ。言語の話しようぜ。

俺の哲学的考察ドヤァ

次世代言語の話をしろ

日常会話にもプログラミングにも使える言語とか誰か作れよ
厳密に文法定義するだけだからできるやろ

需要、なし！ｗ

>>488
ここ数年で広辞苑に「うざい」が載るようになったように日常会話は時代によって変容する。
つまり、日常会話に使う言語は「厳密に文法定義する」こと自体が不可能に近い。
だから厳密に文法定義できるプログラミング専用の言語が必要になった。
そして日常会話に使う言語を「時代によって変容できない」ようにすることも不可能だ。

プログラミング言語も時代によって変わる
逆に変化しないプログラミング言語は取り残されていく

lojban使えば？PEGで構文解析できる人工言語で新しい単語も導入できる
プログラミング言語を覚えるより遥かに大変だけど

>>492
ざっと見たけど糞やん
読み方あいまいやん
bridi
ブリヂか？
バリディか？
頭がブリブリなのか？