次世代言語Part7[Go Rust Swift Kotlin TypeScript]
レス数が1000を超えています。これ以上書き込みはできません。
文字数制限きついので改題
スレタイ以外の言語もok
前スレ
次世代言語議論スレ[Rust Kotlin Haskell]第6世代
http://mevius.5ch.net/test/read.cgi/tech/1503924817/ そろそろSwiftとTypeScript入れときたかったので 生JSもVSCodeによってコード補完がTypeScriptと比べてさほど遜色ないレベルにまで引き上げられたからなあ
結局MSが本気で開発環境を作ればどんな言語でもゴリ押しできることが証明されてしまった 次世代というか、2010年代の企業発の静的型付け言語でまとめてみた
まだ載ってないのだとNim Hack Julia Crystal辺りがいいのかな >>6
限定的な型補完のみだろ
静的チェックには絶対型が必要 >>6
JS含む動的言語は大抵ダックタイピングって時点で補完が効かないじゃん。
個人的には「ダックタイピングのほうがインターフェース書かなくて済むから
手軽で良い」って言ってる奴がマジで理解できん
補完できなきゃどのメソッド呼べるのかいちいちコードかドキュメント見に行かんとならんからむしろ面倒 >>9
型が決まってれば動的言語だろうと補完できるでしょ >>10
JSDocに型を書いてないコードとかあったら発狂したくならない?
仕事じゃ周りのアホどもが書いてくれないからよくにあるんだけど >>9
最初にコード補完をIDEに組み込んだのは動的言語 >>14
バカいうんじゃないSmalltalkに決まっとるがな >>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に補完つけると重いんだよな Jedi-vimとか謎に重くならん?
あれ?そうでもない? >>20
MSは昔からやってるけどね
MSにとって目新しいのは、コンパイラ及びエディタをコード補完やリファクタリングに対応させるためのオープンなプロトコルを策定したこと
これほど早い段階でそのレベルにまで達するのはMSにしかできないこと 誰だよ未だにプログラミング言語未満のRustをスレタイにいれてるやつ
ハロワ以上のプログラムをことごとくコンパイル弾く欠陥品、言語としての体をなしていない 晩酌してたのとRest APIと混ざったんだよ
めちゃめちゃ使ってるっちゅーの >>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 なんかはだいぶ機能を整理した方かなとは思うよ。
実際に作って使ってみるとボローイングの解決しづらさがよくわかるってのはある。
理論と実践は繰り返してなんぼ。 >>42
Typescriptも該当ディレクトリ内にXXXX.d.ts(XXXは生jsのファイル名)を置くだけで
型が付与できるけどな。しかも生jsの箇所をいじらずに。
どっちがいいかは何とも言えないが。 jsというかTypeScriptを使ってるんだけど。async-awaitマジでいいわ
と思ったが例えばclassのコンストラクタをasync対応してくれたらな〜って思うわ
初期化時に非同期関数使いたいと詰む。 >>46
c#でずいぶんお世話になってるから嬉しいわ >>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);
}
} LisperはSmalltalker以上にめんどくさいぞやめとけ >>43
> 理論と実践は繰り返してなんぼ。
同意 その通り
テキストエディタで打ったコードにこそ温もりがある
補完や静的解析なんて邪道
日本人ならPHPを使うべき >>59
日本人ならとか言うんならRuby使えよ。。。
何でPHPなんだよアホちゃうかと。。。 Elixirってダメなん?将来性ないの?
サーバーがCowboyとかいう変なやつになるからダメなのかな >>60
偽装・不正・いい加減がモットーのジャップランド土人村にとって
PHPほど相性のいい言語はない
PHPは日本人なんだよ、わかるか? >>52
それは裏でTypeScriptの型情報を再利用してる。
だから標準APIとか有名所は使える。でも自分でライブラリを作るととたんに効かなくなるぞ。 >>52の内容なら型アノテーションに頼らずとも型推論だけでいけるだろう。 >>63
将来性とかさ〜自分で判断しろや。
それともここで将来性あるとか言われたらなんも考えずにその言語使っちゃうわけ?
将来メンテされなけりゃおれがやるくらいの気概をもって言語使ってほしいわ。 >>64
それはあくまで偏見の塊の君の個人的意見だろ。
そんなこと言い出したら
「日本人はもともと職人気質の人間が多いから
使いこなすのに職人レベルの技術が求められるC++と相性がいい。
だからC++こそ日本人のための言語だ。」
なんていう、今俺が適当に作ったトンデモ論法でも通っちまうだろうが。 >>65
違うよ。自作関数の戻り値と、それが代入されてる変数のヒントに出る。
自分でライブラリ作ってもバッチリ出てくれるけど、doc書いといたら間違いは更にないな。 >>63
Elixirいいよ
将来性はコミュニティの頑張り次第
Phoenixはよく出来てる
実質的にWebアプリに用途が限定されるだろうから
このスレでは人気ない >>68
いや、日本人はPHPでしょ
空気読んで面倒臭いことはナーナーにして
今が良ければそれでよし
当事者がたんまりお金盗って無事退職した後、
年単位越しでツケ払って大騒ぎ
PHPですか?いいえ、日本です 日本の技術力ガーとか言ってたくせに
結局全部嘘ばかり
バカチョン以下やでホンマ
そりゃペチパーが闊歩しますわ >>72
多分お前よりはまともなもの作ってるとおもうわ。 PHp本当に速くなったからな
相変わらずポーリングも特殊操作でしかできないクソだけど 気に食わない奴でも合法なら許す
違法なら許さない
この優先順位を歪めるから無法地帯になるのだ >>70
Elixirってrubyに強く影響受けてる言語なんだよな。
Phoenix触ってたらRailsの匂いを感じる。
でも今は動的言語は弱い気がする。Elixir + 型 が欲しい
TypeScriptが触ってて気持ちいいからサーバサイドもJSがいい気がする。 Elixirの問題は込み入ったことやるとErlangに足突っ込まなきゃいけないことで
プロダクションコードに突っ込むには人材要求が高すぎること 結局ネットワーク系統のエラー処理は低レイヤーに突っ込んでいかないとどうにもならんよ。
抽象レイヤーでなんとかしたいって願望はわかるけどさ。 Elixir(というかBEAM=ErlangVM)の場合はプロセス復活のために型情報が必要だし
静的にしたからって型情報は省略できない C++を書きたくないんだが代替言語は今だとrustとdどっちがゆうぼ?
最近はnimと言うのが注目されてるとも聞いたが…… ジャップランド土人村企業が詐欺のために求めているのはPHPだけ! >>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の橋渡しのために使ってるくらいだから
結構まともに動くんじゃないかとは思ってる。 おまんらの大好き ぷ〜えちピーーブリブリッ でも使えばええじゃろw みんなサンクス。
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版まだー? TSは手段と目的がたまに入れ替わるのが見てるとちょっもモヤモヤするな。
C#が最近もう一度好きになってきた。 >>138
まあまあ今ごろコンパイラに怒られてる頃だしもうちょっと待ってやろうぜwwwwww cに名前空間とラムダとattribute((cleanup))が入るだけでもだいぶ助かるのに。
なんでcの規格のバージョンアップは遅いんだ?
c++みたく3年毎にしてくれたらいいのに。 >>142
あそこモジラの工作員しかいねえし
Rustが言語ですらないただの汚物って正しい認識を共有できる人がちゃんといるのは素晴らしいと思う >>143
C++みたく闇鍋状態にしたくないからだろ。 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→関数型のパラダイムシフトに比べれば簡単だけどね rust も haskell も理解できても面倒だし無駄に言語に気使ってるだけじゃねーかって
思うんだが、信者はききやしない。。
「お前らは理解できないものを理解できる俺偉い」で思考停止しちゃってんだよ。 一番言語に気を遣わないといけないのはC++だがなw 型っていうシステムが
そもそも良くないっていうのは無いの? >>181
出てきたが、お前まさかこんな汚いコード未満とCのコード比較させる気か?勝負にならん。解散
>>182
それならマシで、Rust信者の工作員はモジラブランドのためなら使えないものを世界中の企業に絶賛させるための工作をに熱心すぎてもうね >>185
おめー流石に一から書いてもいない奴が言うセリフじゃねえよ
Cライク信者からしても何様だてめえは >>182
「俺偉い」はさすがにないわ。笑かすな。
Rustに移植してみての感想だけど、確かにコンパイルを通すのには苦労したけど、
通ってしまえばメモリーリークはないって安心感がある。これが重要。
特に今回はunsafe一度も使ってないからなおさら安心できる。
Cのほうのコード一通り眺めてメモリーリーク無いって確信できる?
それができる超人君なら確かにRustは全く必要ないが。
Rustは君の嫌う面倒さと引き換えに安心を得ることができる言語。
むしろCで書いたコードにメモリーリークがあるのかないのか
自分の書いたコードに自信が持てないやつのためにこそRustがあると思ってる。
面倒だけが理由で思考停止しているのはどっちだ。
>>185
確かにこのコードは汚いよな。そこは自覚してる。
マジで誰かRust風に書き換えてくれない?
動いたところまで確認したところで集中が切れてしまってもうやる気が出ない。
Rustはオブジェクト指向も関数型のパラダイムを両方とも持っているし、
きちんと書けばかなり綺麗で整ったコードに書き直せるはずなんだよ。
あと、Rustアンチに1つ聞きたいことがある。
Rustが嫌いってことはわかったけど、じゃあアンチ君の好きな(愛用してる)言語は何なの?
その言語のメリット・デメリット含めて詳しく解説してくんない? はっきり言わせてもらうけれど、
この規模のコードで書くのにそれだけ苦労する価値があると思えんが。
メモリリークについてもこの規模なら一通り見て、あるかないかくらい判断できるよ。
まあ主観といえば主観だけれど
本当に本心からこの程度のコードについてメモリリークを心配しちゃってるの?
言語を持ち上げるために無理に納得しようとしてない? そりゃこの程度の規模じゃRust使うメリット皆無だよ
で、実際のプロジェクトがこの程度の規模なの? ブラウザの性能が圧倒的に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とは対照的に感じたな
常識的に考えたらクラスの値型配列なんてやったらダメなのはわかるんだけど、なぜかやってしまって、コンパイル通ってんのに思ってたのと違う挙動して困ったわ。こういう常識的に考えたらわかるけど、考えないといけない部分があるから言語に気を遣わないとやっていけん。
これは全然大したことない例だけど、なんか他にもあったような気もするし思い出したら書き込むわ 代入がなければ値型でもポインタでも同じ挙動だ
だから、代入しようとしたらコンパイルが通らない言語が現れた 追い出す権利はないね
あると思ってるやつは権利に甘えすぎ 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
型がないと引数なり戻り値なりで与えられた情報をどう扱っていいかわからないでしょう 返り値が返るのも
それも副作用って事にならないのはなんで? >>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
> 各成分をそれぞれスカラー配列で持った方が効率いいよ
キャッシュに乗りやすくなる
これってどういう演算の時にそうなるんです? >>219
許せないんじゃなくて、健全ではないよね、と。
なんせ改善せずとも、自分があたかもまともであるかのように思える一番楽な方法だし、進歩もない。
>>222
ホントに。好きなら好きで良いんだよ。
バカで比べる事ができないなら素直に信者してりゃ良いの。
狂信者が戦争起こすような真似をネットでまでやらんでもよろしい。
>>227
>>231
しかも、結局すごくひねり倒してグダグダ言った割に、最後まで動くコードが出てこなかったんだけっけ。 >>232
分かりやすいのはパディングが入るケース
ループのベクトル化もスカラー配列の方が効きやすいらしい >>235
うーむ……
もしかしてPoint3Dのベクトルに一括して行列を掛けたりする状況を想定しているのか? そういう状況でもない限りそもそもボトルネックにならないからな >>211
試行錯誤の過程でアルゴリズムぶっこわれるってのはよくあるが、そうならないためにテストコードがあるっちゃそうだから、
明確な欠点とは言えないかもな
まさかスレに貼るサンプルコードにまでテストコードつけろなんて言えねえし。 >>234
ドアの奴なかな?
あれならHaskellのコード出てただろ
いつまで言ってるんだ コード出すという行動ではなく
コードが正義っていう知見への承認とか共感が欲しかったんじゃないか
だから行動だけでは駄目 >>239
じゃ、いつまで、スレタイにはHaskellが、って言ってんだよ(笑) よくあんな無様な知ったかぶりしといて人のこと無様とか言えるな >>243
自分が無様だと思ってる奴に無様だと言われるのはさぞ辛かろうが、
俺が無様なのとHaskell書いたやつが無様なのは別の事象で、
同時に無様でありえるんだから、その指摘はナンセンスだろ。
その理解力でHaskell最高!と思ってるのも面白いな。Maybeの真髄だろ。事象を整理するのは。 なんだこいつなんで俺がHaskell 信者みたいな前提で煽って来てんだ Fortranに第一級関数がついてimplicit noneがデフォルトになってinterface文をもうちょっと短く書けるようになって引数の型指定をCみたいに書けるようになって
配列の大きさ指定の関数に組み込みでない関数を使えるようになってgfortranのbind(C)周りのバグを解消してくれたらFortranでいいよ PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい >PHPが、前世紀末に流行したPerlでCGIという極悪システムを撲滅した功績は大きい
キリッ
www 皆がCGIという共通ルールを守る中
汎用性のない独自実装をした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だった
大きくなりすぎてから管理コストを考えてノロノロと移行を企てている
そんなとこだろ それ以上ペチパーの心のより所を叩くのはやめてやれw
彼ら、憤死してしまうでwww 伝えようとすれば滅茶苦茶
隠そうとすればバレバレ
だから型情報とか一生懸命伝えようとする言語が報われない >>242
go 好きな人ってまともすぎてつまらんな。 >>261
ARTは全部変換なんてしてない
元からJITとAOTの複合 >>268
http://gihyo.jp/lifestyle/clip/01/awt/201603/24
>しかし,AOT方式をいざ導入してみると,サイズの大きなアプリのインストールや,
>一度に複数のアプリをアップデートするような場合にコンパイルに時間がかかり,
>場合によっては20分程度かかるケースが存在していたようです。
>このインストール時間を問題と捉えて,Android NのARTでは,JIT方式をもう一度使うことになりました。 >>271
Goは色々足りないところも多いが、生産性にステガン振りしてるって点で評価できる
Rubyみたいに前借りではない Rubyの教訓は、「Perlよりマシ」に全振りしたけどPythonと比べると大したことなかった >>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#系(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() とかある。
外部クレートだけど。 最も嫌われているプログラミング言語は?--Stack Overflowが調査結果を発表
https://japan.zdnet.com/article/35109803/ だから何度も言ってるだろ
型なし能なし未来なしの糞言語が
使ってる連中は今すぐ首吊ってなるべく苦しんで無様に血糞尿にまみれて死ねよ >>316
死ぬだけじゃダメだな
来世でも来来世でも苦しみ抜いてもらわないと >>317
せやな
一族郎党末代まで呪われて地獄の業火で焼かれるべきだ その政策の予算をいくらまでなら払えるか考えよう
予算なしは能なし未来なし Go言語で
var 変数名 = 値
の表記の時は型を省略できるそうですが
値が数値で、値から型が確定できない場合はどうなるのでしょうか?
値から型を確定できるのは文字列型と真偽値くらいだと思いますが >>323
値に応じたデフォルトの型か決まっている >>324
なるほど
たしかにだいたい推測できますね
ありがとうございました >>319
予算がないからクソゴミクズ汚物言語を使い続ける?
地獄に落ちろビチグソ野郎 VBA は explicit 付ければ堅く書くこともできるんやで〜。
そんな書き方するやつあんまいないけど。。 >>326
誘導尋問するなよ
というかどうせ誘導するなら天国に誘導しろよ >>320
PHPは型がないから
とかおっしゃってるいつもの人だろ >>328
なーにが誘導尋問じゃ
どんな理由があろうと下痢未満言語未満のぷぃーえっちぷぃーを使うことを肯定する時点でお前は地獄行きじゃ!
地獄でビチグソにまみれて二度と転生してくるな!! 次スレはワッチョイつけないとな。
330みたいな異常者をNGするために。 と言うか、では実務ではウェブの案件には何をお使いで?と聞きたいな。
ホントに何なんだろ。 >>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は動いてる。 >>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アンチくんはペチパー
はっきりわかんだね
これだからペチプァは
それ以上ペチパーの心のより所を叩くのはやめてやれw
彼ら、憤死してしまうでwww
ペチパーって何であんなにフレームワーク作りたがるんだろうな
自己主張が強いのか、ママの愛が足りなくて承認欲求に飢えてるのか
おい、アスペチプァさんを馬鹿にするなよ
マジキチ ペチアンチの面白語録非難してる奴って胸に突き刺さって抜けないペチパーか? 好きの反対は無関心になるはずだしな。
嫌いな事と言うのは、実は興味があったり、かつて好きだった事があったり、強制され抵抗できなかった惨めさがあったりするもんだ。
あまり人の憎しみを面白半分で扱ってはいかんな。 >>357
SPAは一番最初のローディングがアホみたいに遅いじゃん
これ解決するためだけにSSRもやるの辛い
じゃあ最初からSPAいらないやってなる >>371
dynamic importが実装されている現状から言って最初のローディングが遅いって問題は解決する。というかminifyすれば十分小さい。
せいぜい500kbとかでしょ開発中は10MBとかだったりしてビビるけど。 >>371
後、最初のローディングが遅い問題がSSRで解決するって初耳なんだけど。
どっちかというとSEO的な問題の解決かと >>374
意味不明
順序的な動作いらないし負荷や遅延も減るんだから速いだろ >>373
最初のローディングを早くするのとSEOできるっていう二つがSSRのメリットだと言われてないか?
それからSPAの初回表示が5000msとかかかるのは、DOMを構築する処理のせいだろ?
500kbというのはjsのサイズか?ファイルがいくら小さくてもな…
dynamic importは調べてもよくわからなかったが、解決するというなら良いことだ >>373
これも意味不明
スクリプトのサイズは飽くまでグロスの転送量の問題であって
動的モジュール読み込みだろうと結局初動が重けりゃ処理遅延するし >>367
Rustアンチスレ立てられる原因になったと自認してる俺だが、
PHPはゴミだと思ってるぞ安心しろ cobol, fortran, vb あたりも相当恨みを買ってる言語だが、ここでの php への
恨みはそんなもんじゃないな。。
使ったことないからわからんが、そこまで嫌われるのは興味あるわ。 >>377
俺の勘違いなのか?
動的ローディング使えばルーティングで該当ページが開く時にネットワークアクセスするから初回転送量は抑えられるだろ。
DOMの構築が遅いっていうのも意味がわかんないな。
現在表示している画面以外のレンダリングも裏でやってるとでも思ってるのか? >>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使わないという選択肢が一番だな。おつかれ。 仮想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が普及するとも思えんがな。
誰が使いたがるんだろう、あれ。 C++が糞だから使いたくない人はCくらいしか選択しないだろう。 Cもラムダ式(かBlocks)とattribute((cleanup))入るだけで随分と楽になるのに。。。
規格更新が遅すぎるんだよ。 jsの世界のbabelみたく新規格をとりあえずすぐ使えるaltCみたいなものを作ればいいんじゃないの? Blocksは江添にクソって批判されてたような
C++との互換性考えたらラムダ式が現実的かと 規格または実装のどちらかが遅すぎる法則
これ9割当たるだろ 自己書き換えコードが禁止されてるからCでラムダ式とかが考えられてこないんだろうな。 いやCなら単純に関数定義と関数ポインタ渡しの構文糖衣でいいだろ C++のラムダ式とか最適化のおばけやんけ
あれCに入れれるのか? C++のラムダは文法、型付けともに最悪だろ
第一templateもautoもないCでどうやって持ち運ぶんだよ
それにBlocksもそうだけど
気軽に他言語からのFFIができなくなるんじゃないか
基本的なAPIにこういうのが使われだしたら他が困る…… あとC++ラムダもBlocksもローカル変数をキャプチャーする糞仕様だし
そんなのがABIとして定まってしまうと、例えばD言語が関数ポインタとスタックポインタのペアだけでやってるみたいな
シンプルかつより優れた実装を取ってる組が迷惑するだろ Cの戻り値が一つしか出来ないというのも意味わからないよな。
2つのレジスターに値をセットして戻せばできるのにな。 評価した結果,値を2つ持つって方が意味わからん気がする
複数の戻り値を表すならタプルみたいなもので1つの値にしてしまうのが一般的だと思うけどCでそれは流石に…という感じ x86_64のSysVみたいに環境によっては
レジスタ2つ分程度なら構造体で返してもrax, rdx使ってくれるぞ
それに10個とかになると結局構造体返しと同じになるだろうから区別する理由がない 引数は複数なのに戻り値は一つって対称性が乱れてるからな。
引数が一つってきまってるなら戻り値が一つでもいいんだけどな。 まー、今更呼び出し規約変更するのも虚しい結果に至るだろ。 俺は今の言語が解析しにくいのが不満
xmlみたいにシリアライズ容易であって欲しい
プログラムからコードを作成したり
ビジュアル的にコードを表現したり出来ていいと思う
これが出来てやっと次のステージにすすめると思う >>434
全然駄目だ
俺には読めないw
xmlとかcsvとか形式が決まってた方がいいな htmlみたいにxmlでフローの書けるプログラムが組めるような言語とか次の覇権を握る
次世代はプログラムの自動生成がメインに来ると思うな
モジュールのビジュアル化
それらを組み合わせるAIとか10年後のスタンダードになると思う ID:aP107Usiじゃないけど、俺も言いたい
それLispやんけ 確かに人間の能力で解析できるのはLisp程度かもしれないが
次世代AIだったらLispは甘え c#は構文解析やるのも字句解析やるのも
結構疲れる
こんなんじゃビジュアル開発できないじゃん
IDEなんてリソースエディタまわり強化するぐらいしか進化する先ねーのに
言語複雑にしてっと自分のクビしめっぞ C#はRoslyn使えば一発でAST取れるぞ
MSのコンパイラというのは開発ツールのための言語サービスなんだよ 常にデ/シリアライズ可能って良さげだな
ある時点のスタックトレースを丸ごとダンプして、丸ごと状態を復元できる >>436
なんかxmlを通すと形が変わる処理系なかったっけ?
SGML通した覚えがある。
ビジュアルなフローを繋いでいくとなると、LabVIEWとか色々あるじゃん。流行らなかったやつだと.netのワークフローとかあったし、
最近だとnode-redとか、Amazonのフローとか。
>>444
仮想マシンを一時停止にするほうが気が楽。 >>445
そうじゃないニム
例えばニムね、Reduxのある時点のStoreを丸ごとjsonにニムしたら
バグとかニムとかの再現に便利だと思ったニムンゴよ >>448
仮想マシン一時停止にしてスナップショット撮って、再開するのは不便だって事かな。
まぁ確かに不便か。
まあ、普通WPF書いてればモデルクラスにMVVMしてるだろうし、そいつをシリアライズしとけば良いと思うけどね。Reduxみたいに、となると。 フォンノイマンマシーンではデータとプログラムの区別とかレジスターとかはないから
メモリーをコピーするだけで実行時と同じになるんだよな。 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は構文がきもいからね……
あと実装( 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
プロジェクト違うとライブラリだけじゃなく設定ファイルとかリソースファイルとかも変わるんじゃない?
そのための環境「変数」なんだと思うがね んな大げさな、切り替えたいだけならpkgconfigでいい てかそこまで動的に切り替えが必要かまず考えた方がいいのでは? プロジェクトのディレクトリ内に適当に置いとけばいいじゃんあほらし >>405
好きの反対は嫌い
無関心の反対は有関心
好きも嫌いも有関心 抽象度が低すぎる単語はポリコレ違反なんだな
だから性別や宗教等を特定できないレベルまで抽象化する 好きも嫌いも、言葉は同じでも指すものが違うからな。
可愛さ余ってなんとやら。 Goみたくメッセージパッシングう方式での並行性に非常に優れていて、そこそこ速いML言語とか誰か作らないかな… >>480
Webのサーバーサイドでのプログラミングとか? あれ?かつて次代の大物言語とかいわれてたelixirは入ってないの? そもそも関心があるかどうか関心を持った時点で関心があるから
関心が無いものは思いつかないものでないと関心が無いと言えない。 >484
心理学の話はもういいよ。言語の話しようぜ。 日常会話にもプログラミングにも使える言語とか誰か作れよ
厳密に文法定義するだけだからできるやろ >>488
ここ数年で広辞苑に「うざい」が載るようになったように日常会話は時代によって変容する。
つまり、日常会話に使う言語は「厳密に文法定義する」こと自体が不可能に近い。
だから厳密に文法定義できるプログラミング専用の言語が必要になった。
そして日常会話に使う言語を「時代によって変容できない」ようにすることも不可能だ。 プログラミング言語も時代によって変わる
逆に変化しないプログラミング言語は取り残されていく lojban使えば?PEGで構文解析できる人工言語で新しい単語も導入できる
プログラミング言語を覚えるより遥かに大変だけど >>492
ざっと見たけど糞やん
読み方あいまいやん
bridi
ブリヂか?
バリディか?
頭がブリブリなのか? >>495
初耳だったのでちょっと調べてみたけど面白そう。是非とも良さを語ってほしい 変わり続けることとは変わらない法則である。
したがって変わらないことこそ変わることなのだ。 Pony Julia Crystal Nim
いいからv1.0になって出直してこい系言語 本当に並列化で速度を稼ぎたい場合は
オーソドックスな手法で並列化するので・・・
というか割と稀
それとは別に、UIを固めないためだけの並列化が鬱陶しくて
async/awaitがあればかなり楽になるから、それでいいやって >>501
コロコロ言語仕様が変わるのは次世代言語じゃなくてお遊び言語だろ
言語仕様が固まってから、さて次世代的にどういう用途が向いてるだろうかって議論するべきじゃないのか? >>502
結局、モジュラリティー高くなるように書けや
って話でどんなツール、言語が出てきても関係ないっていう気はする。
ツール、言語を強要するよりかは
アンチパターンとして急いでる時にはどうしても依存しまくったコード
書いちゃうよねってなことを教えた方がなんぼかまともな気がしてる。 >>503
「言語仕様が固まってない」って「前のバージョンのコードが動かない」って意味か?
「推奨される、もしくは書きやすいコードの書き方が変わる」って意味ならC++でさえC++11以前と以降では全然違うし、「言語仕様が固まっている」言語なんてCくらいしか思いつかないんだけど。 前者の意味だが、文法自体に変更なくとも、標準ライブラリのAPIが変わってしまうのも含むな
Scalaとかマイナーバージョン変わるだけで文法変わってなくてもコンパイル失敗するとかあったろ 前のバージョンのコードが動くことって、今職場で使える言語を語るのには大切だと思うけど、未来を語るのにそんなに大切だろうか?
むしろ試行錯誤して、ダメな所はダメな所として直して文法を綺麗に整理してくれている分、C++みたいなキメラ感溢れる追加機能よりも期待が持てると思うんだけど
まあ俺はScala知らんし、Juliaなんかはdeprecatedになった機能はちゃんと警告してくれるし、いきなり機能削除で困ったことがないから出て来る感想かも知らんけど CPUみたいに特殊な命令をコードの最初の行に書けば
上位のモードに移行するみたいな仕様にすればいいのにな。 DockerのコンテナとかGoで書いてるらしいね
これからどんどんコンテナってつかわれるみたいだからその関係でGoって人気でてきたの?
もしかしたらこれから一気に流行るの? いろいろ突っ込みたいがキリがないので、
Docker使う分にはGoを意識する機会は全く無いから関係ないとだけ言っておこう >>503
それswiftにも同じこと言えんの?
正直swiftの先進性には感謝する。関数型言語に興味を持つきっかけになった。
だがGo並に仕様を固めてから公開してほしかった。もうswift4? swift0.4だろボケ Swift Xへようこそ。
世界一ピュアなキス
ここから未来が始まります。 >>512
林檎信者に刺されたくないからあえて名前出さなかったんだが、まさにswiftは念頭にあった
あれが言語になれてる理由は他ならぬ林檎がごり押ししてプラットフォームを囲い込んでるだけなんだよな 言語開発者って企業戦士としては碌なのいないな
ヘルスバーグくらいか Matzはエンタープライズ系ITからの典型的なドロップアウト勢じゃなかったっけ? ケントンプソンとかは?ベル研。
ジョンバッカスもずっとIBMだったような。
Wolframもずっとアカデミックな人で、途中で会社立ち上げてずっとmathmaticaを責任持って作ってるイメージ。 >>516
swiftが登場したばっかのときは良かったんだよ。その後
何度も下位互換性がない仕様変更が繰り返されて開発者が疲弊していった。
正直言語仕様も複雑化の一途を取っているrustのメモリオーナーシップモデルも取り入れるって話も聞いたし、正直つらみがます一方。
androidのkotlinが羨ましくみえる。 確かRustの主要開発者の一人が林檎行ってswiftやってんだっけか?
Rustもまあ言語仕様お世辞にも簡単とは言えんが、1.0以降下位互換性崩してないところは評価できるわな Rust は所有権とかボローイングとか、そもそもパーサーの方もまともに
理解できてねーじゃんとか思ってしまう。 >>526
まあそもそもRustはモジラの提灯のための言語モドキで、プログラミング用途じゃないからな モジラ「これからは安全性!所有権!(って言っとけば金とれるわ。言語自体の出来?適当でいいじゃん)」
泥箱「Rust使ってます!(って言っとけばモジラが提灯代くれるし使ってないけど言っとこ)」 >>523
kotlinも使いやすさ的にはGroovyから一部劣化してるとこもあるが
今生きてる言語の中では一番まともな解だと思う
正直StaticなGroovyまんまだけど >>531
直感は人それぞれだから
誰もが平等だという直感もあれば、強者だけ生き残り弱者は淘汰されるという直感もある 直観でわかるようになるようになるまで練習するならわかるけれど
初めから直観でわかる言語はないだろ。 何か一つの言語を知っていれば直感的に判る言語
その名もパイソン Pythonは「なんでこれができてこれができないのか」という変な例外が少ないのがいいよね
RubyとかPoweShellのような驚異に満ちた楽しい言語を触ってから戻るとすごく安心する それはあるな。
メソッド第一引数のselfを隠さなかったり、構文だとpassが存在したり、
他の言語では言語仕様を工夫して誤魔化した部分に諦めを見せてくれる。 OSコマンドインジェクションを考慮しなければならない用途では特に価値のない言語だから perl自体時代遅れという風潮と、perlはゴミ!という今のphpディスの空気感そのものみたいなのがあったからでは?
結果、まともに書いてないperlは問題だったが、まともなperlスクリプトは今でも生き残ってるしそんなに問題視もされない(というか意識もされないレベル)になったけど。
今のphpディスは、今35〜40くらいの世代がperlを叩きまくってたのと被って、健全には見えんな。 >>542
RoRでも本来は考慮すべきだよ。バッククォートの再定義とかそういう話になるかもしれんが。 >>543
perlが生き残ってるってどこの話だよ
生き残ってるってだけならそれこそCOBOLだって生き残ってるわ
perlが生き残ってるような環境ならPHPみたいな汚物を肯定もできるんだろうな胸糞悪い 昔からperlは宣伝がうまい
「なんでlinuxができてperlができないのか」ってつっこみ入れるだけで普及する >>545
カーネルのソースにも沢山いるし、あとはrpm -q --whatrequires gitってやってみれば?
確かまだいると思う。メインコマンドじゃないけど。
胸糞悪い環境でgit commitしてるんだね。 しかし perl はやっぱきついよ。
あんなにコンテクストに依存して記号の意味が与えられる言語、
他にないと思う。 Perlはワンライナーでしか使わない、汎用sed, awk >>549
まあその程度で罪悪感を覚えるような正義感の強いコミュニティが
あったらいいなと思う 頭がパーのP
PerlとPHP
ウンポコピー
ガイジ専用 まー仕事してりゃ、嫌な言語の1つや2つ、保守する羽目になることもあるだろ。
ディスは簡単だが、その言語がなぜ使われたかまで考えると意外にディスる気も無くなるし「なるほどなあ…」と苦笑いにもなる。
ガイジ専用、と言って切り捨ててると、ガイジでも出来る事が出来てないままの、自分の実質ガイジ以下の部分に目をつぶることになるぞ。 >>538
pythonでのバイナリ配列内の特定の1バイト(0x00)の検索方法がよくわからん 今どき新規でPerlとPHP選んでるようじゃ
ガイジ扱いされてもしゃーない 誰がどこで「新規でperl」って書いたのか、書いてないものが書いてあるように見えるのってちょっと精神的に破綻してるよね。 >>545
これは恥ずかしいな
Linux触ってたら普通に知ってる事なのに >>558
?
新規で〜の話をしただけで、別に君を非難したわけじゃないぞ?
大丈夫か? >>560
>>545からの流れかと。安価つけないのってメリットあるんだな 「ここは後でちゃんと作るはずだからperlでテキトーに実装しておこう」
↓
数年後: 誰も読めない長大perlコード perlは正規表現でごちょごちょやるなら現役じゃないの? rebuildfmの中の人とか小飼弾とか。
できるエンジニアはもとperl使いってイメージある 知ったかくんちょっと調子乗って人のこと侮辱し過ぎでしょ なんでperlが残ってること誇ってんの?汚点じゃん
perlがあまりに保守性悪くてリプレイスできないけど機能自体を捨てたらキレる老害がいるから化石のように残ってるだけ
要するにCOBOLと同じ。残ってることは恥
それを逆に誇ってるんだから、そりゃー世の中にPHPみたいな汚物がはびこる訳だわ perlは確かに難読化言語だけれども、一回わかってしまえば
PHPみたいに仕様が変な部分はほぼない……と思う
PHPって内部で変換を繰り返して変な結果が帰ってきたり
数学関数の解釈が間違ってたりするんだろ? perlのソフトdisってる人は開発当時の時代背景知ってて言ってんの? >>567
言うに事欠いてそれかよw
読めるように書いたらちゃんと読めるし、何より
「新しく作るコストと現行のものを保守する(していく)コスト」の天秤の問題だし、
枯れきった環境ってのは大事じゃん。
ついていけないから置いてるんじゃなくて、それはそれで良いから置いてるんだよ。
誇るも何も、それより良い物作ってコミットすれば良いんじゃない?それより誇りたいなら。
物にはついてくるよ、みんな。 Perlは変な書き方もできるが
PHPの頭のおかしな仕様に振りまわされることに比べたら
いたって普通。 比較対象が PHP ってところからすでにおかしいだろ。 マクロアセンブラ―みたいにマクロC言語って出てこないかな。
これがあれば絶対使いたいんだけど。 マクロPHP 或いは altPHPトランスパイラは銅ですか? 次世代言語スレで新規じゃない話してる奴ってなんなんだ >>575
#define
または template
がすでにその用途である >>575
あとatteibute((cleanup))も標準になって欲しい まずなんで次世代言語スレでPerlの話題が上がるんだよ
せめてPerl6以外のPerlの話は禁止しろ >>577
過去にあったものより、良かったり違う思想だったりするものを議論するのに、
「知らない、話題にも上げなくて良い、知らなくても良い、どうせゴミだから。知らないけどね」って無責任と思うけど。 次世代言語を議論する上で引き合いに出すならアリって感じか。
となると perl から得られる最大の教訓はなんだ。
使いやすくても読み難いものは宜しくない、と。
APL もそうか。 >>583
>>577の「新規」は>>558、>>560、>>561のレスを見て思ったことを書いたんだが、そのレスはそれに対する返答か? >>584の意味でperlに触れるのはありだと思うけど、当時の状況が云々とか未だに残ってるperlは恥だとか新しく作るコストが云々とかはスレ違い以外の何者でもない perl の教訓は python, ruby に受け継がれてるからいいんだよ。 rubyは最初からオブジェクト指向を言語仕様に含めた。
だから基本型もクラスなんだろ? Rubyは設計者やVM実装者があっても大学院生レベルの知識で四苦八苦してるから
過去言語で解決済みの問題も顰みにならって抱え込んじゃってる
他言語のパクりの塊で元ネタを知らない大衆にはウケる面もあるけど正直新しみは何も無い言語 >>584
アリどころか、違う思想、って言葉が使えなくなるでしょ。
perlの最大の教訓は、お前はEAXレジスタか、みたいな変数の使い方はやっぱり書くときは楽だけど読みづらいとか、
<>みたいな、便利なんだけど、それが正しい姿だと断言しづらい構文は辞めよう、ってとこみたいな負の部分と、
間接参照は正しく使えば可読性を下げずにうまくコードを短くできるみたいな正の部分色々あると思うよ。 >>585
そうだよ。
新規だから次世代言語を使うべきだ、なんて新しい筆箱買ってもらった子供みたいな真似はするべきじゃない。 >>593
おまえはいったい>>577をどう解釈しているんだ
俺はそんなこと一言も書いてねえぞ
書いてないものが書いてあるように見えるのってちょっと精神的に破綻してるよね。ってやつか python なんかは明らかに書き方の自由度を落とす方向で
perl の教訓を活かしてる。
ruby に関しては以下の感じらしい。
https://www.ruby-lang.org/ja/documentation/ruby-from-other-languages/to-ruby-from-perl/
まあ古い言語を勉強すると老人が鬱陶しいというのはあると思うけど
勉強として悪くはないよ。 苦労することが美徳だと死んでるあのお爺ちゃん、おりゅ? >>594
お前が何を言ってるかわからん。
次世代言語のスレで、古い言語の話をすべきでない、に対して、古い言語知らないと新しい言語が相対的に「新しい」じゃなくなるよね、次世代じゃないよね、って。前や今が無いと次はありえないんだから。
そこで、切り口として、「新規で作成するなら旧、現世代の言語なんてあり得ないよね」という論旨を受けて、
「そんなこと無いよね、今でもいっぱい使われてるし、その上に成り立ってんじゃん?旧、現世代があり得ないという理由が、我々は次世代言語を持っているから」なら、
それは子供が新しい筆箱買ってもらって嬉しくて今使ってる筆箱わざと壊して、意気揚々と新しい筆箱を持っていくようなもんだよね、建設的じゃないよね。
って話をしたつもりだが。 クソ言語メンテするよりかは
クソ言語の歴史を学ぶ方が苦労は少ないと思うよ。 皆が苦労した歴史のつまみ食いできる奴らの方が圧倒的に楽だし、そうすべきじゃん。苦労自体はせずに、>>555で言う苦笑いだよ。
それに、それが本来あるべき姿の「昔の苦労」ってやつだろ。 ペェ〜ルとプェチピィは真性糞ゴミで
未だにそんな言語しか使えない連中は糞以下の蛆虫って
みんな共通認識もってるんだからそれでいいじゃん 日下部の名台詞「ということにしたいのですね」が浮かんだわw
今日日、perlしか書けない奴なんか絶滅してるか、片手間にsed代わりにperl使う他の言語使える奴になってるだろ。 あは自分が全く相手にされてないことに気付いてないのだろうか
perl以前にその冗長で可読性の低い自然言語をなんとかすることを考えたら?
君みたいな人は話し言葉や書き言葉に対してもプログラミング言語なんかと同じように論理的に距離をおいて考えることを身につけるといい
だいぶマシになるから まあ、建設的な事も意見も言わずに、論旨も汲まずにシンプルに発言だけを否定していくと楽だよね。
俺もそうしようかなと思うぐらい。 多分だけど、
新規とはいえ、経験やライブラリといった既存資産は開発生産性に大きく寄与するものである。
それでもなお新しい言語を使いたいなら、捨てるものに見合った見返りがあることを証明すべきである。
そのためには我々は既存言語を知らねばならないのだ。
という趣旨のことが言いたいんだと思う >>604
端的に書くと理解できない、一つ一つ説明すると冗長だと言う。
毎回随分な事言うなぁ。
まぁ、相手にされてないのだろうか、という相手をしてもらえるだけ広栄だと思っとくわ。 >>607
サンクス。だいぶわかりやすい。
もしかして、そもそも>>577の
>>558の
>誰がどこで「新規でperl」って書いたのか、書いてないものが書いてあるように見えるのってちょっと精神的に破綻してるよね。
に対する反応としての
>>577の
>次世代言語スレで新規じゃない話してる奴ってなんなんだ
だって伝わってないのか???
俺は「新規で作成するなら旧、現世代の言語なんてあり得ないよね」とか一言も言ってないのに、その意見への反論を俺にぶつけられても意味わからんぞ?? >>608
端的冗長以前に文が下手糞。
>>607を見習え >>607
ちょっと違う。
既存のものとは世代が違う「次世代」というものを議論したいならば、
少なくとも既存の物がどういうもので、何かその「次世代」と違うのかわからん、単なる「新しいよくあるゴミ」ではないと言えない、ってのが前半。
旧世代言語はもう使うべきではない、と言う発想が、「旧世代言語は語れるほど知らないが、もううんざりして嫌いだし、次世代言語は楽しそうだから」と言う所から来てるなら、
ほんとに新しいおもちゃを「道具だ」と言い張って、今まで立派に道具として成り立っていた道具をわざわざ壊して捨ててまで学校に持っていく子供と精神性が変わらん、と言ってる。
見返りはその道具が本当に良いものであれば、あとからついてくるから割とどうでも良い。
考え方の問題。 >>609
伝わってないな。
だって、次世代言語スレで、旧世代言語を無視できる方が頭おかしいと思ってるから。 >>611
三行目、「わからん、単なる」→「わからんと、単なる」だな。ごめん。 Uberが言語(と称する何かを)発表したけどもろPythonよな
言語ではない気がするが一応
http://docs.pyro.ai/ >>613
俺は「旧世代言語を無視しろ」とは少なくとも>>577で言ってないぞ
ただ、「新規でperl使う話してない」っていうから、「新規プロジェクトに使う言語の話しろよ」って書いただけだぞ >>615
これ割と面白いな。ナナメに読んだ感じpythonに確率分布と確率勾配なんかの計算をを苦しみのない形でライブラリとしてのっけてる感じ。
>>616
あ、なるほど。それは読み違えてたわ。
マジで申し訳ない。
ただ、新規プロジェクトなら余計に過去の苦しみは引っ張り出してきて、「本プロジェクトの課題と目的」みたいな節に並べるかもしれん。 「旧世代言語はもう使うべきではない」とか「新規で作成するなら旧、現世代の言語なんてあり得ないよね」とかって俺の意見じゃないんだよな
なのにその意見への反論持ってこられても意味わかんね〜
たしか、ちっちゃい子供ってAさんとBさんの意見の違いを区別出来ずに自分or他人になるんだっけ?
こんなん困るわ やっぱそこか
ちょっと他の人に聞きたいんだけどさ
俺は
「旧世代言語はもう使うべきではない」とか「新規で作成するなら旧、現世代の言語なんてあり得ないよね」とか言ってるように見えた? >>618
すまなんだ。IDまで見てなかったわ。そもそも俺もちょくちょくID変わるし。 そこまで個の意見読めてるのか俺も気になる。
赤くなるのは俺ぐらいのスレだし。 覚えた言語を捨てる勇気が無い奴は、その言語を肯定して
自分に言い訳をする卑怯者だよ。 >>619
簡単な話
そいつの相手してもなーんも得るもん無いから君は最初から放置すべきだった
そいつは病的なしったか自己弁護野郎で
自分の頭の悪いことすらを、文章の「端的冗長」などという問題に置き換えちゃってる
それも、何度も何度も何度も何度も、絶対最後はそういう逃げに走ってる
悲しく単調な茶番劇 間違った事は言ってないつもりだし、明らかに間違えたら認めてるぞ。
冗長だから理解できない、話が下手だから理解できない、に俺は持ってって無いじゃん。 頭の$見えてるぞ
はやくプェチピィを保守する工程に戻るんだ 何回か間違って認めているのに同じ間違いを繰り返すのは、学習能力のないガイジとしか言いようがない
話してる最中に「もしかして俺が間違ってるかも」って疑ったりしないんだろうな 高速逆走ボケ老人「なんてこった!ワシ以外の全員が逆走しとる!」 そもそもパールやプィエッチピィを少しでも評価する下痢クソ野郎がなんで次世代言語議論スレにいるのか
俺にはわかりましぇーん perlやphpしか選択肢がなかった貧しい時代もあったんですよ!!! 普通にCで書いてたり、極端なところだとbashのcgiとかもあったなぁ。 選択肢がなかった。それは残念、悲しい時代でしたね
だからこそそれは否定されなければいけないと思うんですけど
その時代を肯定しないと精神崩壊するような老害がなんでこのスレにいるのかって聞いてるんですよー >>637
あっさんを馬鹿にするやつはPで殴り殺すぞ!この野蛮人! 汚物できゃっきゃしてるやつの方が野蛮人ではありませんこと? >>637
単に否定されるべき、ではなくて、より高度に「専用品」が作られてきたようなもんで、
要は適材適所なのよ。今のperlの残り方見てもわかるように。
濫用はもちろんいかんが。 ウンコの適所って?
それしか選択肢がなかった哀しい時代ならともかく今ウンコの適所を探すやつがなんでここにいるのって何度言ったらわかるのかねー? タイムリーにスラドの新システムがperlだな
結局perlが可搬性最強ということらしい 最近の言語ってclassは無くなって構造体にメソッド生やしてclassっぽく使える言語が多いイメージだけど
この場合の設計はオブジェクト指向的にするのが多いのかな そういうのは基盤領域が中心だから、
ビジネスドメインのモデリングとは違ってデータはデータとして真面目に設計するでしょ ああいうのって、ウィンドウライブラリみたいな実装継承が中心になるようなやつは
面倒くさいんだろなーと思って眺めてる
というより初期のOOPLが実装継承が中心だったのは
まさにウィンドウライブラリ作りたかったからだろうな
GUIをHTMLにできるようになったからウィンドウライブラリから開放されたみたいな勝手な想像 P言語っていうウィキペディアの記事あるけど、Pythonに失礼すぎん? 適所を探すと言うより、最初からそれが無難な手だとわかってるから使うんだよなぁ。
適所を探して彷徨ってるのは、それこそ現世代で活用方法がイマイチ定まってない、次世代言語だと思うけど。
いちおう補足するが、単に旧世代、現世代言語を使う事を肯定して次世代言語を否定してるんじゃないからな。
それで充分なら、それを使えばいいってだけで。
僕鉛筆削れないから、ケータイに打ち込んでメモします、それが正しい。この時代鉛筆なんか使わないっしょ、常識的に考えて。削れないと言うか、削らなくて済むことを美徳として受け取ってほしい、みたいな極論に走るんじゃなくて、
鉛筆使うと手で擦ると汚れる、ボールペンって一回書いたら消せない、だからケータイでメモします。電池が切れると読めないって問題は認識してます。って話であるべきだと思うって事。 確実に使えると断言できるなら何でも使えばいい。
確実にこれにハマる!と断言しづらいのは次世代言語と言われる言語の方
ただし、次世代言語を否定して、旧世代言語を肯定してる訳じゃない、次世代言語が肯定できるならばそれもよい。かな。 鉛筆とか携帯とか子供のおもちゃとか謎の比喩なんなん? なんでもないよ。もし理解できないなら可哀想だなと思ったゆえの空回りだから。 意訳
旧世代言語には実績があるので使いどころは明らか。
対して、次世代言語はそれを模索している最中だ。
明らかに次世代言語が適しているという明確な理由がない限り、実績のある旧世代言語の方が推奨されるのは当然であろう。
なぜこう書けないのか たとえば、>>654を正常な人間が書いたとしたら、
(もし理解できないとしたら可哀想だな、つまり、)理解しやすいように配慮した。
(空回りだから、と言いたいが、冒頭の「なんでもないよ」と被るので省こう)
という思考をすると思うんだよな
彼はADHDなので書いたそばから頭から抜け落ちてて、こういう頭の中でのフィードバックが機能してないんだろう >>656
そんなに高尚なもんでもなく、単なる嫌味だよ。残念だけど。 >>655
旧世代言語が推奨される、とは言ってない。
次世代言語を推奨するに足る明確な理由があるのであれば、そうすべきとは言ってる。
「実績」を根拠にした「使いどころ」の2行目に対して、2行目はひとつの代名詞で受けるのもどうかと思うし、そもそも「それら」複数で受けるべきでもないんじゃないの?
実績と使いどころって前提に対して出す結論が「適す」「推奨」なのも変じゃん。
それでいいならそう書くけど。
次世代、現次世代の二者択一ではなくて「そもそも買ってくりゃいい」 途中で書き込み押しちゃった。
「そもそも買ってくりゃ良い」「既存のものが望む言語ではないが存在する」なら、それは、どちらの言語も選ばずに問題解決するんだし、作りたいものの性質によってベストも変わるんじゃない? >>658
ごめん、よく読んだら行数無茶苦茶だったわ。代名詞で、受けてるのは三行目な。 >>657, 658
言葉遣い(言語定義)に関して「変」とか「べき」とか相手が間違っているかのように言っているが、
使い方が仕様として定められているプログラミング言語とは違い、
自然言語では「大多数の人間が直感的に理解できる」言葉遣いこそが一般的に好まれる傾向が強い。
つまり、自然言語の場合は自分以外の大多数の他人の総意により言葉遣いの正しさが決定される。
そして、君は言葉は>>655と比べて大多数に対して理解されやすい言葉なのだろうか?
嫌味というのは上記のように反語のかたちで使用する方が相手は理解しやすいと私は思う。
(わざと相手に理解されないようにさりげなく使用する嫌味もあるが)
「理解してほしい」という気持ちがあるのならば、言葉選びには多少注意を払ったほうが賢明だ。 ただでさえ壊滅的な文章力なのに、嫌味やら比喩やらぶっ込もうとしてさらに壊滅的になった結果がこれなんどなあ 知識も文章力もガバガバなのに嫌味だけは一丁前にぶち込んでくるの凄いわ 文章力はガバガバ、文章力を指摘されたら怒って相手の理解力に転化しようとしてたこともあったけど、本人は人の意見もちゃんと区別出来ない理解力
すごい奴だ >>655の「それ」が指すのって、実績かもしれないし使いどころかもしれないし前文の文意全体かもしれないけど
どれでも意味は変わらないので曖昧なままでいいと正常な人間は判断するんだよ
ADHDの人みたいにそんなことをいちいち確定させないと頭のスタックがオーバーフローしてしまう、なんてことはないの 一般論と自分の意見をごっちゃにしてるのは彼のレスが読みづらい大きな一因だな。
(彼以外にとって)>>655があくまで一般論を述べているのは明らかであり、だから旧世代言語を使えという主張ではない。
俺はできれば次世代言語を使いたいという個人的意見を入れたいなら>>655の後に付け足すだけでいい。
一般的な事実+主張 という教科書的な論述の形になる。 お前らガイジをデバッグしてやってるつもりかもしれんが
そーいうのは医者かそいつの身内に任せとけ
そんなカンタンに直らないことだから放置されて今に至ったの分かるでしょ?
今後も、基本的にそいつは放置され行く運命なんよ… >>645
今の知識から適当に過去を想像するとそう見えるのかもしれないけど、
Smalltalk も C++ も全くそれに当てはまらない。 大学とかの学術系の人達って、オブジェクト指向言語を、
GUIのWindow制御と関係付けられて語られるのを
非常に嫌がるよね。 だってそれ一部の linux の gui だけだからなあ
要は「きっとそうに違いない」レベルの嘘なんだもん linux系の人達はシェルスクリプトでできることをC言語 (に似た言語) で書くのが嫌がる
「でもスクリプトでGUIは無理だよね」とかいう人は
自分自身が「スクリプトを非常に嫌がる人」だと自覚すればいい
他人のことは気にするな MicrosoftもWindowsのGUIプログラミングにオブジェクト指向を最大限
利用してたけどな 動的な要素が必要なものなら必然的にオブジェクト指向的な何かはでてくるだろうね。
逆にアルゴリズムみたいな静的なコードにはあんま馴染まない。 >>645
やってみればわかると思うが
ウィンドウシステムの実装で多用するのは
継承よりもコンポジションだ 直感的に理解した気分になれれば、正誤は気にしない。
これは理解に苦しむわ。 ADHDと言う病名がつく前から、「してはいけない、気をつけるべきこと」と指導教官に言われて徹底した事だけどな。議論の際の言葉の揺れは。
文は長くなれど語彙を少なく、時制の一致、代名詞は慎重に使用、もし使用するならば数詞は一致させる。
議論ごっこしたいだけならもう黙るわ。健全でもなんでもないよ。 >>677
議論ごっこって具体的にどういうことを指してるの?
健全でもなんでもない、ってことは不健全でもないと理解していいの?じゃあ何が言いたいんだ?
あまりにも曖昧すぎる 君自身は気付いてないみたいだけど、君の文章を君の言うような基準で評価するとこうなるんだよ
落ち着いて他の人のレスをじっくり読んでみると、曖昧な言葉遣いに見えて意外と厳密な言葉で書かれてることがわかるはずだよ
君自身のレスに比べれば遥かにね 言葉の揺れは注意されたようだが、文章力は指導しきれなかったようだな
指導教官に出会う前は今の文体+表記揺れだったんだろうか
指導教官の苦労が垣間見えて涙が出ますよ 大企業の偉い人でも決算や証明書に嘘を書いてしまう
一般人が文章を正確に書けるわけがない
嘘を書いたとしても反省したり罰を受けたりするようなシステムはもうないよ >>680
変に単語だけ注意したのが失敗だったのかもね
それによって、ただでさえADHDで文章構成が苦手だったのが余計に単語に気を取られて全体を見れなくなってしまったんだろう
俺の上司もADHDだったけど、逆に全体の構成はおかしくなくて単語がおかしいタイプだったから、彼の文章に比べればずっと読みやすかった すまん自分で言っときながら曖昧だな
683の「彼」は「あ」を指す >>678
以前、スレタイに議論がついていた頃にもうやってる、その話。
読んできて。二回するの嫌。
>>679
曖昧だよ。
>>680
苦労されてましたな。まぁそのおかげで英語で論文出すときに訳に苦労しない論文がかけてるし、知財部に怒られることもなく割と通るし、
先生様々だよ。
>>683
だってこれで苦労してねえもんなぁ。
誤解の余地が生まれるほど歪めて読みやすさを作らないと読めない時点でどうかと思うが。 >>668
SmalltalkがGUIのために作られたのは純然たる事実じゃね
例え本人が否定していたとしてもそうだろう
>>670
WindowsでもOWLから数えてMFC、VCL、WinFormsと歴代のGUIクラスライブラリは
全部実装継承中心だったぞ。JavaもそうだしNext→Macもそう 今時学振とかでもとにかく一目でわかるように書けって指導されるのに、わかりやすさが二の次なんてことは断じてないゾ 日本語についてはわかりやすさを重視するのに、
プログラミング言語となると抽象化が著しい関数型を推すお前らがわからない >>690
単位時間あたりで読める文字数を可読性と定義するなら可読性は極めて高い 時間当たりのスクロール量を可読性と定義するならたしかに関数型言語は可読性が極めて低いな >>687
SmalltalkはOS(しかしユーザーが全体を理解可能な)を目指して作られているからGUIがすべてではないよ?
▼Smalltalkの底を流れる設計思想
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24# 別にGUIだけではないが、GUIが最初からあったのも事実だろう >>695
かなり初期(Smalltalk-72、74)にGUIは整えられたが、この時点で継承機構はなかった
http://squab.no-ip.com/collab/uploads/61/smalltalk-72-1977.jpg
そしてその後Smalltalk-76で継承機構が入ったのも、GUIだけのためじゃない
(例えば、Smalltalk-76でGUIに使われるクラス数の割合を調べてみたら分かる)
GUIはつねに&あくまでもSmalltalkの大きな野望(?)の一部にすぎないよ
ジョブズみたいなのが色々見せられても、結局GUIスゲーで終わっちゃったって話はあるかもしれんけど
https://pbs.twimg.com/media/DM3GJ4lUIAESUOx.jpg
https://pbs.twimg.com/media/DM3GODAVwAEg3rP.jpg >>696
貴重な資料をありがとう
で、物は言いようみたいであれだけど、Smalltalkの歴史はそのままOOPの歴史であり
GUIを実装する試行錯誤の歴史なんだから、継承が後からなのはむしろ当然で
継承がGUIに有効なことの左証では >>701
> 継承がGUIに有効なことの左証では
実装継承がGUIに *も* 有効な事はだれも否定してないと思うよ
ID:ZQLxHiSg の
> というより初期のOOPLが実装継承が中心だったのは
> まさにウィンドウライブラリ作りたかったから
や ID:D9ZDsmXZ の
> SmalltalkがGUIのために作られたのは純然たる事実じゃね
> 例え本人が否定していたとしてもそうだろう
というように、GUIやそれに付随するウインドウシステムの構築のみに実装継承の目的を限定したり
SmalltalkがGUIだけのために進化してきたかのような言い方は少々視野が狭すぎませんか?という話 値型のメンバー変数を作れない言語だったら
無駄なポインタを減らすために実装継承が有効だろう GUIはオブジェクト指向のインスタンスだしょ。
インスタンスは抽象化の具現化の一つで抽象化とは
実体のない仮想的なオブジェクトの集合であり、
その存在を具現化して表現してしまった瞬間
それは実体化し具現化してしまうのだよ。 PHP書いてるのなんてジャップランド土人村の頭がチンパンジーのエスアイアイのオサールサンダヨーだけだよー https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
PHPといえば顔本のHHVMの今後
HHVMは来年にはPHP5のサポートを落として、PHP7には寄せずにHack言語に絞るそうな
やっぱり顔本もPHPは焼き払いたいんだな。Hack言語とやらがどれだけPHPから脱却できるか 技術選定の段階でいい加減にPHPを選んだクズ野郎は
相当恨まれてそうだな
いやどこの下痢糞プェチピィ現場でもそうだろうけど Hack言語はダメだろ。発表から大分立ってるのに進展が遅い。
フェイスブックの中でも重視されてないだろ? 必要性があるならどんどん開発してるはず。 それぞれ問題に対して最適な言語というものがあるわけで
何もかもに適した言語というのは存在しないよ。 何もかもに適してない言語ならありそうだな
いやどのPのこととは言わないがな? 単にディスるだけなら簡単だからな。
とはいえ、phpなんかにも「一番無難」以外に新しいメリット入れてかないとな。
もちろん他の次世代言語も「一番無難」を目指す所はあったほうがいいと思う。
.netに対してIIS、javaに対してTomcatみたいに、Dockerとか仕組みごと出す前にその言語の用のアプリケーションコンテナを強く押せば、一定のパイはあると思うんだが。 PL/Iのことか
理路整然としてて意外と良い言語だそ
業務系がC系やVBに流れることなくこのままの方向で進化してれば、業務系の開発は今よりずっとマシなものになってたと思う PHPのどこが無難やねん
PHPでまともにシステム作れてた案件1割もなかったわ WebとGUIのデザインって時代背景に依存する消耗品じゃね? >>708
面白いなHackは独自言語に進化するんだ。
そう言えばHackのXHPって面白いな。
ReactにおけるJSXみたいなもの。
PHPではhtmlコード部分はただのテキストでHTML 部分の構文がどうだろうと無視されるけどXHPはHackの処理系で妥当性が検証される。
メリットとしては事前に構文がチェックされるのと
XSS対策くらいだろうか?詳しい人に聞きたい。
Reactみたいに独自のタグが作れるとかだったら面白いな。 >>710
単純に旧PHPのサポートしなきゃいけなかったから実体反映遅れてんじゃねえの?
最近のHHVMはHackのバイトコード実行する機能入れてるし
文法はシラネ >>721
日本全体で見れば店員や肉体労働の求人が多いのと同じことでは。 >>723
なるほど、頭を使わんでいい仕事は求人が多いってことか。
なんかすげー納得した。
それを言われて気づいたんだが、「PHPが世界で一番使われてる言語だから一番良い言語」って理屈は
「ハンバーガーとコーラが世界で一番売れている食べ物だから一番うまい食べ物」って理屈と同じってことだな。 >>714
> PL/Iのことか
> 理路整然としてて意外と良い言語だそ
言語仕様が大きな言語は最初から慎重に言語設計がされているから理路整然としているし
その後で言語仕様の拡張をしてもグダグダになりにくい(理路整然さを保った拡張が可能なことが多い)
これはPL/Iだけでなくそれ以降に開発された(各々の開発時点で最も複雑とされた)言語であるAlgol 68やAdaでも同様
> 業務系がC系やVBに流れることなくこのままの方向で進化してれば、業務系の開発は今よりずっとマシなものになってたと思う
Cのように本来は小さく単純なものとして産まれた言語は拡張に耐えるような基本設計になっていないので
拡張するとグダグダになり勝ち
ちょうど最初から巨大なビルとして設計されたビルは通路(人の動線)やエレベーターや水回りや電気系統などが整然と配置され
その後の多少の拡張や変更にもそれらの整然さが余り乱されないですむが、最初に小さな建物として作られた旅館が
色々と増築を受けると通路(特に避難通路)が迷路の如くなり電気配線や水回りの配管もほとんど誰も知らない謎めいた代物に
なるのと似ている Java や C# は巨大ビルですか?それとも旅館ですか? PCは部品を増設できるからダメ
SIMロックしたスマホが最強に儲かる
ってことだろ >>723
>>724
ここ最近で一番的確なレスだね >>724
という勘違いな。
頭使わないのは、仕事じゃなくて単なる作業だからいずれは機械に取って変わられる。
どんな仕事でも、マトモな奴はちゃんと頭使ってる、って事が社会に出たら分かるよ。 実際にはExelのマクロ使えば数秒で終わるような作業を
毎日数時間かけてタラタラ打ち込んで給料を貰ってる事務職は大量にいるよね >>732
そのとおりだ。
それで稼いだカネをITに注ぎ込んてくれるんで、プログラマーの仕事が有る、っていうのも事実だけどな。 >>731
なにぃ⤴!?
社会に出てるのに分からなかったよぉ。俺ってバカなんだなぁ⤴
社会に出てる君にはそのことが分かるんだろうなぁ⤴wwwww
すごいなぁ⤴wwww
少しまじめにレスすると「社会に出たら、まともな奴ってかなり少ないことが分かった」というのが俺の経験則だな。
大した根拠もなく、他人に勝手な偏見を持った発言をするのは控えたほうがいいと思うよ。
「こいつ、まともな人間じゃないな」と思われる危険性があるよ。 多数決だから
まともなじゃない事象があっても確率が51%になるまで無視するから見えない 多数決は単なるきれいな暴力だからな。
きれいにお前らを封殺したいんよ、って意思表示も込められるくらいに腹に据えかねてるときしか使わん。 票が足らん?普段出ないような社員を「幅広い意見を募るため」と集めたるわ、ぐらいの時。 >>733
だから、事務社員様の仕事を奪わないように、
業務モデルを効率化することなく
紙の上でやっていたことをPC上でやって
最終的に紙に印刷できなければならないのさ。
全ては事務社員様の雇用のために。 紙に印字できないといかんのはどっちかと言うと事務方よりITでないエンジニアの人の方がこだわるイメージだけどな。
医者は昔相手にしたことあるけど、常に野戦病院と化しても運用できる体制にこだわってたし、実際何度か近い大惨事を経験した。
機械屋も同じで、明るければ読める形での設計資料、過去整備記録、縮退運転切り替え要領書みたいなのにこだわってたな。
入力が楽になるのは素晴らしいけど、入力したものが必要な時って平常時とは限らない、みたいな思想だった。
いずれも、事務方のほうが力弱いから、負けた方の事務方は「今この場には必要ないかもしれませんが、こうすべきと言われてるのでオール電子化は反対です」と端的に言いよるけどね。 >>738
日本の受託ITにそれを批判する資格は無いんだよなあ
業務モデルを変えられないからIT屋に開発の仕事があるんだよ
システムに合わせて業務変えられる民族なら、そもそも大抵の案件は出来合いのパッケージ使えば終わりということになっちゃう >>738
ウンコードにウンコード激盛大将軍してウンコードを積む作業を生み出す
現代の錬金術師ペチパー様のことかね? Googleが採用決めたSwiftが覇権で決まりか バカ「うーん、これは適材適所だからPHP!wこれもPHP!wあれもPHP!w」 >>734
>大した根拠もなく、他人に勝手な偏見を持った発言
724みたいなのも居るしね。
おま環で判断してないで、より良いものを探したら? GoogleがSwiftってことはC++の代替ってことだよな。
あれ、Go言語はどうなるんだ。 >>745
やめるわけがない
iOS 11やmacOS High Sierraで内部での採用も順調に増えてる >>746
ん?ごめん。ちょっと意味が分からない。もう少し詳しく説明してくれ。 未だにObjective-Cのほうが安全という事実 うちは社内の保守的なエンジニアのおかげでSwift移行しなかった。
現状を見れば良い判断だったと思う。
RustもいずれSwiftと同じことになると思う。 Swiftはプラットフォーム囲ってるからまだ無茶が効く
囲ってる訳でもないRustが同じことなんてしたら一瞬で客が離れるだけだわ。火狐の現状がRustの未来だ RustはABIを安定させないことで最適化と改良の余地を残しているから
1アプリで完結するようなのはいいけど、基礎的なものを置きかえるには適さないんだよね
サイズの問題もあるし
ま、こんなこといったらC++含めて全部不適格だけどな
C言語とJavaぐらいしか残らん まあ確かに、イミュータブルによる安全高速化、動的ってんなら既にHaskell、Erlang、Crystalとか有るので、Rustが何を目指してるかは俺には不明だが、Rustファンでその辺知ってる人居る? Rust は haskell と同じ道をたどるんじゃねーの?
ファン層も似たようなもんでしょ。
なんか理解しずらい高級な機能があるから覚えるとどや顔できるって感じで。 >>756
GCのアルゴリズムが副作用だらけなのにイミュータブルとか嘘つくのをやめよう
RustはGC無しがデフォルト
副作用はある程度容認する
これなら嘘つかなくてすむ >>758
既存言語を貶してもRustの価値が上がるわけ無いじゃん。
GC無しってのはアプローチの一つなんだから、既存言語の改良では済まない「何か」を何故可決できるのかを訴求しなきゃ、「僕の考えた最強言語」で終わっちゃうってだけだよ? >>759
価値は上げなくてもいい
実際に上げなくても、上がった上がったって嘘つくだけでも別にいいよ
嘘に寛容な世界とはそういう世界だ
だが、もし本当に価値を上げたいなら嘘つかない方法を考えた方がいいんじゃないか GCってのは副作用を前提としたCPU上で副作用無しの世界を作る舞台装置なんだから
意味的な文句を付けてもしょうがないだろ
「GCはリアルタイム性落ちるし並列化にも適さないから糞」とか性能の話なら言っていい >>760
何だ思い付き厨か、つまらん。
何でGCがポイントなのかも知らんのだろ。 >>763
お前さんの脳内世界でお好きにどうぞ。
計算モデルが違うもんを比較する事に意味があると言うなら、別に止めはしない。 >>756, >> 759
Rustが目指しているのは基本的にはC++の後継。
C++との一番の違いは、Cとの互換性を捨てることで、より厳格(安全)に書けるようにすること。
厳格であることを実現するために、型システムとメモリ管理などについて比較的新しい概念を導入している。
型システム、イミュタービリティやその他の構文に関してはHaskellの影響を強く受けている。
メモリ管理については、従来のC++ではプログラマがメモリ安全を保障するしかなかったが、
C++14以降のスマートポインタやそれに伴うメモリオーナーシップの概念の影響を受けて、
所有権、借用(参照)、ライフタイム(3つ合わせて所有権システムなどと呼ばれる)という形で構文にそれらを組み込むことで、
コンパイラがメモリ安全を保障することができるようにした。
ただし、あくまでC++の後継なので比較的簡単にFFI(Cを呼ぶ)ことができるようにという点も意識して作られている。
だから、unsafeを使えば生ポインタを直に使えるように設計されている。
Haskellとの違いはGCを使っていないこととミュータブルも扱えるようにしていること等で、
結局、それらはC++並みの実行速度を実現するため。
他にも細かい違いは多々あるが、大まかにはこんなところかな。 >>765
コンテナ系(hashmap等)を標準でサポートしてくれ hashmapを仲間にしたら自動的にジェネリクスとGCが仲間になるパターン
だから仲間にしない <generic.h>という伝説の凶悪なやつがあるぞ コンテナを提供するのに GC も Generics も要らんだろ >>726
本質的には複雑に積み上げられた旅館でしょ
多少はリフォームして整理されてるけど >>770
ただのコンテナではなく標準のコンテナだろ
GCとGenericsを使わずに標準やってる感を出せるか? qsortがあるんだからいけるいける
全部void*で qsortの闇は深い
void*もあるが、要素の比較が本当にO(1)なのかどうかの責任を呼び出し側に転嫁する 結局、型とgeneric(もしくはマクロ)をいい感じに統合するのって
かなり難しいんだろう。
アドホックなやり方になりやすい。 比較のオーダーはcのqsortに限らずなんでもそうだろ
なんだかんだ言って C++ はよく出来てるよね。
constexp なんて他の言語も見習って欲しい Fortranのparameterもその類いだっけ? >>778
あんなもんチューリング完全厨のおもちゃにしかなっとらんわ。
コード生成系のがまだマシじゃねーかと思う。 スレタイにjava君も入れてあげて〜
使用人口の多い言語ですお >>778
C++のconstexprなんて後発もいいとこだろ
本格的な先鞭としてD言語のCTFEがあって、その前にも幾らかある 新興言語って少なくない割合でただの企業が持ち上げて広告収入に使ってるだけの詐欺なんだよな
M$のTypescript然り、顔本のD然り、mozillaのRust然り、TypesafeのScala然り
やっぱ実績の積み上がってる言語でないと信用ならん >>784
まぁ、実績のあるなしなんて個人の主観によって変わるからな。
>>783にとってはJava, C++, JavaScriptくらいの言語じゃないと実績があるとは言えないんだろう。
振興言語がそれらと同じ実績を持つためには一体どれだけの年月がかかることやら。 TypeScriptはともかくScalaは負債ばかりを残して消えた逆実績じゃね
唯一褒められる点としては関数型を流行させたこととKotlinを生み出したことかな C++がモダン言語の基本なので小学校で教えるべき。 基本であるC++の理解なくして言語を語ることはできない。 >>783
林檎教団のSwiftも仲間に入れてあげて >>790
Swiftは別に林檎以外で使ってるやついないしええんちゃう?
信者と信者相手にコード書く仕事してる人は大変だろうけど Scalaは分かりやすい詐欺の典型だな
あれのせいでログ基盤まわりのOSSは焼け野原になってる
CoffeeScriptもちょっと古いが同類事例
GoやらTypescriptやらRustもそのうちそうなる
Dはバズるまえに自滅したのが幸い 変な言語を使うとSCALAの様に開発が止まる危険性があるから
企業はリスクを回避するために独自の言語をつかって思い道理の仕様にできるように
するのだろうな。 >>792
TypeScriptは大丈夫でしょ
Goは危なそう。Dartの前例があるし
RustはGCが邪魔でパフォーマンスが必要な一部の分野でしか使われないだろうからそんなに流行らないだろうし多分問題ない >>794
Rust は Web assembly で化けることに儚い期待を抱いている。
でも、正直 Web assembly はそのうち GC に対応するって言ってるし、
GC に対応したらGo, C#とかが Web assembly に対応するって言ってるから
そっちに取られるんだろうなぁとも思ってる。
そもそも Web assembly が普及すること自体いつになることやら。 しかし CoffeeScript って何がだめだったん?
es2015, typescript がそれなりにうまくいってるのを見るとよくわからんところなんだが。 >>796
・構文が独特なのでJSerが手を出しにくい
・動的型付けなのでJSの根本的な問題解決にはなっていない >>796
提灯記事にかける金と、企業間根回しの差
M$は金をかけまくって提灯記事を書かせまくり、Googleに根回ししてAngularをTypescriptで書き直させた
要するに大企業が本気で詐欺をやっただけ 言語そのものはともかくとして、狂信的な信者が付いてる印象。 >>800
別人だが確かに言い回し似てたな……アレと同類はさすがに勘弁
Sで始まる言語っていうと、
Swift、Scala、Smalltalk、SMLがこのスレでよく見るやつだが
確かに信者がうるさい言語だな >>804
おっさんなんでpascalとprologしか思い浮かばない Smalltalkは儲のロートルっぷりが笑えるがそれはさておき
アンチの低脳っぷり(「うんこ」連発)と粘着が常軌を逸してて笑えない
いずれにせよ迷惑だからこっちくんな Pythonはたまたま流行ったお陰で便利なライブラリが沢山あるというだけで、言語仕様だけ見ると別に良い言語ではないよね >>811
シンプルで良くない?
他の言語だと空ブロック書くところにpassって書かないといかんところなんか滅茶苦茶良い割り切りだと思うけど。
変な構文で逃げるんじゃなくて、基本構文の上でNOP書かせるとか潔いと思うけどな。
メソッド第一引数を隠さない、とか。 Smalltalkは信者のキモさだけは圧勝してるけど、言語自体の出来はTcl/Tkにも劣る Python は private なメンバにもアクセスし放題だからね、言語としてどうかしていると思うときもある
その場しのぎのお助け機能満載なところはあるね >>813
型がなければ解決できない問題、ってのはあんまり無いからな。
型があるから解決できる、という触れ込みをあまり本気にしてもどうかと思う。
単に管理できない人が居るというだけ。
単なるlint目的なら、静的解析でもすりゃ良いと思うよ。
型がある言語には大体、型を無視できる構文があるようなもんで、ダックタイプにはダックタイプの利点がある。 >>815
作法とルールの違いだろうな。
やっては行けないっぽい事をマナーとして守れるか、
やっては行けないっぽい事を一律排斥するか。
後者で仕組み上排斥した上で、それでもどうしても必要だと構文を作ると、そこから「コンパイルは通るけど動かすと動かない」みたいに破綻する。結局動的より酷い。
void*に一度キャストするとか、リフレクションするとか、スタック書き換えるとか。極端だけど。
だから俺は紳士協定止まりで良いと思うけど。
「出来ないことはチェックされるんだから、チェックされないならやって良いんでしょ」みたいな奴が増えるのは、本来のメリットを壊してるようなもんだと思うけどね。 根回しといえば
GCCにGoが速攻入ったのってどう考えても利権だと思うんだけど
GNUはGoogleに乗っ取られてるんだろうな >>818
もともとgccgoがあったからなぁ。
利権も何も、普通にgccのコミッタだった人がGoogleの人で、その人が「メインラインに取り込むわ」って言い出したのが7年前だぞ。
gcj外してgo入れようぜって言い出したのはたしかRed Hatの人。 >>814
その程度の嫌いでアンチ続ける執念がキモイわ Go人気なのか
オブジェクト指向勢から嫌われてたのに
なんかのフレームワークとか流行りのOAuth2とかが実装し易いとかあるん? 気持ちよくおしゃべりしているあは依存型も知らん様子 まだ gcj の方が役に立つと思うのだが…openJDK に移行してしまったようだね TSやFlowtypeは明らかに救済だろ
地獄のごった煮なフロントエンドに一筋の光をもたらした
実案件でTS使ってるが、素のJSなら確実に破綻していた >>822
依存型が、いわゆる依存積みたいなものの事を言ってるなら、それこそ的外れ。
>>823
gcj、あんま良いところ無かったからな。
AOTぐらいだけど、パフォーマンスは落ちがちだったし。 積だけじゃなくて、和もそうだな。
どーせTypeScriptのUnionTypesあたりの、直和型と見せかけて、undefinedなんかも入りうる気持ち悪いものをありがたがってるんだろうけど。
それこそ意識高いHaskeller様で、何かとても良い空論でも教えてくれるのかもしれんけどな。 >>822 単に「型が無ければ解決できない問題は無いからなあ」という馬鹿発言を嘲笑してるだけだぞ
酒が抜けるまでレスすんな。酒飲んでないでそんなレスしかできないならトリップ付けてろ。NGに入れといてやるから >>821
標準ライブラリが充実してる。
httpサーバが簡単に作れる。各種プロトコルも標準ライブラリに入ってる。
例えばsshもopensshに頼らずに自前で実装してる。
結果として外部依存が少ないバイナリが作れる。
https://mattn.kaoriya.net/software/lang/go/20170111165324.htm
ってところが魅力。
あとオブジェクト指向的には継承の簡易さに対してデメリットがでかいことがわかってきたからgoの方向性はそんなに変でもないと思う。
後はコンパイルが早い。と言うかコンパイルの速さのために
言語仕様を妥協してるところがある。(継承がないのもコンパイルの速さを優先してる) 継承がない場合、GUIライブラリはどういう形に落ち着くんだろう? >>830
横からすまんが、
依存型を使ったことがないゆとりの俺に依存型がないと解決できない問題の例を教えてはくれないか…… Rustの静的型チェックは確かに発見困難なバグを見つけてくれる感ある
他のしょーもない言語の型チェックは
ふつうにテスト書けば見つかるようなエラーしか見つからんので
正直、動的型付けとくらべて優位性が無いわ (一般的な)静的型が本領発揮するのは運用開始後に手を入れるときだろ
依存関係が完璧に把握できるからな MLまでいかなくてもPascalでも使ったことあれば>>837のような幼い感想は出てこないと思うので
なんだか微笑ましい 静的型とちゃんとしたIDEならカーソル箇所のメンバを使ってる元とメンバが依存してる先が自動的に一瞬で全部表示される
grep(笑)
作りっぱなしで逃げられる開発なら型なんかいらないと思うよ >>835 「遅くて実用に耐えないが明快で仕様を満たしていることが分かる関数」と
「速いけど複雑で仕様を満たしているか分からない関数」が数学的に等価であることを示せる
あるいは求められている仕様を型として表現することで、その型を返す関数は仕様通りであることを示せる
証明駆動開発は依存型じゃないとできない >>842
RustをHaskellで置き換えたら数スレ前によく見たやつになる やっぱRustもHaskellも、強烈な選民思想を産み出すという点で、
この世に存在したらいけない言語だなほんと 他を使ったこともないやつがいきなり先進的なのを使うと
全てがそのひとつの手柄みたいに思えてしまうんだよな
C#のときもD言語のときもよく見た 話は聞かせてもらったぞ
静的型と動的型のうち選民思想が強い方が滅亡する >>830
酒飲んでないぞ。
>>836
レンジチェックとか静的解析で割となんとでもなるでしょ。安物の解析ツール使ってるならアレだけど。 >>837
あれぐらい縛るなら俺は両手を上げて賛成する。 配列の境界チェックぐらいなら気の利いた処理系ならなんとでもなるが、
そういう類のをユーザー定義できると想像するといい 静的型づけと動的型づけのほかにも強い型づけと弱い型づけがあるぞ。
両方を合わせると4パターンあることを考えたほうがいいぞ。 >>852
弱い動的型付けは存在しないから3パターンだぞ 動的型付けでも、異なる型を混ぜた時に自動で変換されるのとエラーになるのがある
そういうやつのことじゃないの?
いや>>852に訊かないとわからないけど >>854
弱い型付けってのはキャストはエラーはかずに出来るけどメモリぶっ壊して全く違う所でエラー起きたりするCとかC++みたいな奴の事だぞ >>855
その定義だとreinterpret_castができるやつは全部弱型になるだろ
んで、その定義でもObjCのid型やOO風拡張付きアセンブラやForthなんかは動的弱型じゃね
まあ>>825にry >>856
ObjCは分からんが
unsafeブロックとかで限定的に弱い型付け許してる言語もあるけどそういうのは基本的に弱い型付けとは言わないね 一般的にはnominalで暗黙の型変換を許さないやつがstring typeだと思うぜ >>861
神に選ばれたとか生まれながらの血筋とか、
とにかく一部の選ばれた人間のみを良しとする思想。
白人至上主義みたいになのが代表的なものだろうな。
そのぐらいググれば出ると思うけど。 >>862
選民思想自体の意味はわかるよ。
言語に対して選民思想がある、ってのがわからん。
知れば選民なの?って感じ。
一見さんお断り、紹介制ね、セミナー・講習・試験受けてねー(笑)
でもあるまいし、なんか知ろうとする努力を放棄して便利な言葉でごまかしてるように見えるって事。 >>845のことなら強烈な自己肯定感と言い換えてもいいんじゃね
たかが2chの言葉遣いに厳密に意味を当てはめてもしょうがない なるほど。自己肯定感を他者への否定で裏打ちしてるような人たち、か。
いるな。Ruby使いが全体的にそんな印象。 自分が使ってる言語以外は覚えるの面倒だから滅べっていう奴だな。
わかりやすいし、正直だとは思うが恥ずかしい言い分だということも理解しておいた方がいい。 >>818
go はそもそもシンタックスがパースしやすいようになってるから
実装が楽だって話だろ。 そもそもgccのgoってメンテされてないのでは?1.2くらいで止まってなかったっけ? >>868
言語を2つくらい学ぶとそれ以降はソンナ手間でもなくなってくけどな?
最近は学習しやすいべ。
それよりエコシステムの使い勝手が大事。
nodejsは最近やっとまともになってきた >>871
まあ個人的な見解になるんだが
そういう奴のいうところの「覚える」ってのは機能だったりシンタックスについて
すみずみまで覚えるってことだったりするわけよ。
なんか周りにも自分にもハードル上げちゃって原理主義に走ってしまうって感じ。
言語を覚えるっつっても人によってとらえ方はだいぶ差はあるかもね。 頭にウンポコピーのプェチピがつまった動的池沼型なしウンコマンがまた喚いてるようだね
うるさいゴミ虫だな!つぶれちゃえ、プチッw >>872
>機能だったりシンタックスについてすみずみまで覚えるってこと
最近になって、当方主力のC/C++についても、これを諦めることにしました、楽になりました… C++を「覚えて」いるやつなんて数えられる程度だろう >>872
それこそ忘れたらググればいいし、
IDE連携でfixも出来る。
機能の存在を知ってることが重要だよね。
あと大概の概念は言語間で共有してる。 共有してるが細かい違いがストレスになったりしない?特に「ぼくのかんがえたさいきょうのOO」は辛い 型システムの概念はC++とHaskellですら共有してる
一方、オブジェクト指向の概念は共有してないのでストレスになる 昔はこの手のスレだと、補完が効くのは静的型だけだから動的型はダメだ!的な
無知丸出しのカキコミしてたJavaドカタを良く見たけど、
最近は流石に学習したのか、そういうの減ったね とはいえpythonの補完はpycharmでさえたまにしょっぱい結果になるがな つうか補完って個人的にはうざいからいらない。
補完ってそんな有難いかねぇ。 何でやjsは最高やろ
javascriptはうんこだけど jsはブラウザ標準だから広まってるけど実際かなりの変態言語だよね
大分マシになってきてるけど phpは、protectedとか何だかんだ大先生が要るって言うものはつけたけど、正直必要性がわからんね、みたいな事を作者が言ってるぐらいだからな。
JSはあの変態具合がじつに良い。 >>881
ダメだろ。動的言語の言語仕様として正確な補完は不可能。
PHPとかPHPDocで追跡できるようにもできるけど、結局ドキュメント部分だから
信用できるとは限らないし >>889
ポリシーがない作者の言語は大体そう。
投票制で機能の実装を決めるって結局糞になる一方だと思うんだけど。
swiftも最近はそうだっけ? ハンバーガーとコーラとWindowsが多数派になったおかげで、少数派の自己肯定感が強い >>891
作者は、ポリシーがないのがポリシーみたいな人だしな。
たまに引数の順序とか違うけど、仕方ねえじゃん。積み重ねってあるんだから。それに便利さって尺度あるじゃん?とか、
自然言語だって言語学者が整理して作ったら英語なんかと全然違う整然としたもの出来るけど、それってホントに実用になるかはわからんよね。
って開き直ってるからな。
goto実装したときのやり取りとか滅茶苦茶面白かった。
譲れない部分以外は適当に決めろよ、俺使わねえし、みたいな方向性もアリだとは思う。 >>890
補完が無いからダメ、を否定してるんでは?
「補完なんか無くても書ける」レベルのやつが書けばいいんだよ、っていう主張かと。
そんで、俺はそれでいいと思う。
補完が無くても大体間違いようがない、っていう使い方はあるもんだし。システムハンガリアンじゃない、本当の意味の方のハンガリアンとか。 >>894
その読解力でよく人に訂正できるな
間違ってるのはお前だよ >>896
是非も糞もお前以外正しく解釈してるんだからかき混ぜんな 最近の言語なんて全部ポリシーないじゃん。
他の言語で流行ってる機能だからうちも入れよう
みたいな話ばっか。 >>897
見えないすべての他人の代弁者ご苦労様。 >>898
Go言語はポリシーあるけどね。と言うかGoogle社内で使うための言語として
進化してきたって感じ?
結局C++コードベースで作ってきたシステムがコンパイルするたびに40分とかかかるようになってきたから、Go言語でそこを改善した。
具体的には継承を使わないようにしたり
パッケージ間の依存関係を極力抑えるために敢えてDRY原則無視したり。
後プリプロセッサを削除してパッケージシステムをしっかりしたもの(未使用なパッケージをimportしたらコンパイルエラー)
にしたり。 Goとか見るに、googleって意外と線形代数使わないのかなあ? tensorflowを作ってるんだぞ?使ってるに決まってるだろw goは線形代数使わない用途向けか?
TensorFlow for goで全部やってるってわけでもなかろうし>>903の言う通りだろうか? Grumpyも単純に書くと遅いしな。
速度を出したいならcとインラインアセンブラで書くだろうし、大規模に走らせるならHPC系に載せやすいfortranとかベンダのCだろうし、
気楽に書きたいならpythonで良いし、
その為に何か言語を、って手段と目的が入れ替わってる気がする。
既存の道具で目的が果たせるならそれで良い分野だろ、それ。 Cとインラインアセンブラで書いた数学コードなんて今時見たことねえよ Cで数学コード書く奴いるけどあいつら凄いわ
俺なんかFortanの形状引き継ぎ配列使わない縛りでも発狂しそうになるのに、さらにサポート少ないCでよくやるわ いや、Cとインラインアセンブラって、もしかしてあれか。よく知らんけど、CPUベンダーが実装してるような何かか >>907
ゲーム目的とかならCでやるんじゃないの。
と言っても今は優秀なゲームエンジンが無料の時代だから意味ないかもだけど。 Numerical Recipes in C にはお世話になりました >>909
しれっとC++にしてEigenかublasかなんか混ぜたりしない?そうでもない?
あれCで書いてる奴本当に凄いと思うわ アドベントカレンダー見てたら地味にelmユーザ増えてる?
reduxきっかけで流れてきたユーザー居るのかね >>911
すげーかもしれんがそういう低レベルのコードを書くプログラマーっていま日本にどれだけいるんだろうな。もはや大手ゲームベンダーも他社のゲームエンジンに頼る時代だし みんなC言語が分ってるのが当たり前だと思ってたけど、
最近はC言語は知らないのが前提らしい
低レベルプログラミングという本が殆どC言語の解説書なのは驚いた。 elmのアドベントカレンダー
2つめ全然埋まらなくてブチ凹む Cについて知っててもらわんと色々説明しづらい部分があると思うんだが
大丈夫なんかね。 >>909
流体のシミュレーション書いたことある。
多分同業は同じように内製してるか、か今は外注するかしてるけど、ガチの方のシミュレーションでは結構使う。 >>916
ここで宣伝してよ。elmのメリット何?
使ってて気持ちいい?開発環境って使いやすい? >>914
あんなもんCで書いてて嫌にならないのは怠惰さの足りない奴でしょ
そういうのをやらされる/やる人が減るのは健全なことだと思う 新しい言語を作ってそしてメンテしていくほうが面倒だと知ってるからな。
トランスパイラに近い闇マクロがCにはあるので、その辺で逃げるが勝ちの部分もある。 >>921
C11ってジェネリクスがあるの?
正直プリプロセッサで頑張れば何でもありな気もする。
ライナスがあんだけCだけ大好きっ子なのは何かあるんだろうね。 >>922
思ってるようなジェネリクスとは多分違うけど型ジェネリクスで型から、呼び出される関数と引数を列挙してswitchみたいな事は出来る。それをマクロに書いたら型ごとに呼び出される関数が切り替わるように書ける。
けど使わん。ポインタなんかであっさり意図してない呼び出しになったりする事がままある。
ただの文字置換として展開出来るように書くほうが無難だと未だに思ってる。 違うジェネリックスが出来る前は
関数の名前の後ろに_intとかつけなければ同じことはマクロでも出来なかったんだよ 標準機能だけでtgmath.hを実現できなかったから補うように追加したものではあるけど
そもそもサンプル以外でtgmath.hを実際に使っているところを見たことない >>925
>tgmath.h
そんなのあるんか、正直Cは10年以上書いてないから知らんかった。
http://www.c-lang.org/detail/tgmath_h.html
型総称マクロかー。linuxとかでもそう言うの駆使して進化した書き方してんのかな。
Cって二段構えなんだよね。マクロでプリプロセスするから結構、動的な処理もかける。obj-cも初期の頃はマクロで出来てるって聞いた。
それが現在でもiOSで健在だし、結構良く出来てる。
例えば、obj-cのコンテキストとcのコンテキストが明確に分離できてる。
正直c++よりobj-cのほうが好き
cの資産を利用できるし。なによりc++より言語仕様が理解しやすい。 まじめに20年以上c++追ってればこれほどコンパイラ毎に動作の異なる言語もないことはわかるよ。
残念ながらlinuxコードにあるプリプロセスマクロのがよっぽど安定してる。 Cもattribute((cleanup))が標準ならなぁ 今更Cプリプロセッサが派手に変わることなんて無いもんな、そりゃド安定よ
しかしそろそろローカル変数名はマクロで置換されない程度の改良は欲しい >>924
ヘッダごと切り替えて、typedef自体も定義してたんじゃねえの?そういう時は。 >>929
ハイジェニックでない事が予想もつかない活用()を生み出せる原点では?
bashかなにかのソースでびっくりしたことがある。十年以上前かな。 >>932
なんだ?Cの悪口か?
そもそも文章下手くそなくせに「活用()」とか独特な用語使ったり、突然bashの話始まったりして何が言いたいのかわからん TypeScriptでジェネリクス使っててちょっと複雑なことをしようとすると
とたんにしんどくなるのを体験して、型がない世界が羨ましいと思ったことはある。
(本末転倒感)
メタプログラミング部分を動的言語に任せてハイブリットにするというのが
ありかもしれない。
メタプログラミングツールの例
http://moapp.hateblo.jp/entry/2017/06/30/210636 >>933
悪口じゃなくて、良くも悪くも無茶苦茶書けるのが良い所だって言ってるんだが。
今回はちゃんと会話できてる相手が居る以上、最低限、読もうと思ったら読めると思うが、なんか特別な説明要るの?怠惰な人には。
あとごめん、shのソースだった。見たらわかる。
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh >>934
TSやJavaのような型消去のジェネリックはいわば単なるLintの一種
メタプログラミングに使えるようなものじゃないよ
テンプレート方式じゃないなら.NETみたいにリフレクションでジェネリック型をnewできたりするような実行時サポートがないと
ジェネリックを活かしたメタプログラミングは無理 >>792
>>793
Scala をdisってんのかよ?
大人気動画サイトのドワンゴで使われてるって知らないのか?
Scalaにおける最適なDependency Injectionの方法を考察する
?なぜドワンゴアカウントシステムの生産性は高いのか?
https://qiita.com/pab_tech/items/1c0bdbc8a61949891f1f >>937
ニュース見てないのか?
このタイミングでドワンゴの生産性はscalaのおかげって、
思いっきりディスってるとしか。
scalaのイメージ落ちたわ >>939
いくらなんでも、すぐに釣られすぎじゃね?
ドワンゴがScala使ってるのは↓で知ったよ。
https://anond.hatelabo.jp/20171129214218 >>935
話し通じてるってなんだ?会話できてる人がいることと>>932の文が荒れていることにはなんの相関もないし、>>932をちゃんと読めていることを明示している人はいないぞ
要約するとこうか?
Cのマクロはハイジェニックでないが故に良い
何が良いかというと、予想もしない活用()を生み出せる所である
だとするとこの活用()に込められたニュアンスはなんだ? ニコ動の問題にアカウントシステム関係なく無い?
何がどう破綻してるのか謎だし
こじつけで無理やり並べてるだけだろ >>942
解ってると明示する必要が無いのが、解ってるって事そのものだろ。
会話と文章が荒れてる事と相関がないと言うなら、文章の荒れと表現力に相関も無く、あるのは単純な読み手の理解力の問題では?
()に込められた意味?
もはやCのソースとしては成り立ってないような構文すら許される所。
せっかく探して貼ったんだから、どの.cでも良いから読んできたらホントに一瞬でなんの事言ってるかわかる。 >>944
そのレスに触れているのが俺だけなのによくそんなこと言えるな。前に黙っている多数の意見はわからないから代弁しない方が良いみたいなこと書いてたくせに自分は良いのか?
貼ってくれたshのソース見たわ。おまえこのmac.hのマクロの使い方はいいものだって思うのか?
いやこのマクロの使い方のどの辺がいいんだ? ニコ生は今、Rust で書き直しているらしい
これからは、Rust, Elixir の2択じゃないの? >>945
代弁してないじゃんw
必要無いのが解ってるって事だ、って言ってるだけで、皆は解ってるから明示してない、って主張じゃない。
「犬はワンって鳴くよね」と「皆はワンって鳴いたからあれが犬だと理解してる」の違い。
この表記が良いとは言ってないだろ。だから「予想もつかない活用()」なんだよ。
>>935で言ったように「良くも悪くも無茶苦茶書けること」自体が良い事だって言ってるの。 >>948
おまえに触れると面倒だからみんな触れてないんだよ
そこんところ勘違いしてるのは良くない >>949
今回はわりと正しい事言ってる自信はあったんだがな。 >>948
はあ?Cのマクロが良いものだって言うんならせめて良い使い方の例持って来いや 一回名無しに戻って、煽りを辞めて書いたらどうなるかやってみるか。 >>946
なるほど。Rustで書いてるってモジラの提灯持ちすることで金をもらってる訳か
本当にRustで書けるわきゃねーからな >>951
#define swap(a, b) \ do { typeof(a) __tmp = (a); (a) = (b); (b) = __tmp; } while (0)
なんて良いマクロじゃない?kernelのswap。 >>946
そういう新しい言語にすぐ飛びつくようじゃ終わりなんじゃ。 >>955
それはハイジェニックでない、無茶苦茶書いてる良い例ですか?
あとコピペしたけどコンパイル通らん >>948
あと、
『代弁してないじゃんw
必要無いのが解ってるって事だ、って言ってるだけで、皆は解ってるから明示してない、って主張じゃない。
「犬はワンって鳴くよね」と「皆はワンって鳴いたからあれが犬だと理解してる」の違い。』
って何?面倒だから放置されてるそうだけどw >>950
おまえが間違ってると思うし、読みにくいと思う。
それでよくそこまで相手を煽れるなと感心までする。
正直ウザいし二度と書き込まないで欲しい >>957
だから、無茶苦茶書くのが良い例なんじゃなくて、無茶苦茶書ける余地があることに意義を見出してるんだが。
コンパイル通らんのは何て出てんの?
kernel.hから取ってきた事は覚えてるが、俺のアンチョコが間違ってるかもしれん。
#define pf(fmt, val) fprintf(stderr, #val " = " fmt ";\n", val);
これは割と無茶してるかな。出典不明。
>>958
そうだなぁ、これは俺が悪かったかもしれん。 >>959
思う分には個人の自由だからな。
よくぞそこまで煽らせるなぁ、とも思うが。 >>906と>>907がたった6分で矛盾してるし、まぁそういう人なんだろう。 コンパイル通らんとか言ってる奴はマジで言ってんのか?
そんな理解度でよくCの話題に絡もうと思ったな >>960
ハイジェニックでなく、滅茶苦茶書けるのが利点って言っておきながら、それをしたコードは悪いコードってどういうことやねん。
それハイジェニックな方がいいってことじゃん。何言ってんだ
あと、おまえは文が下手なことはいい加減認めろ
この関連何度目だよ >>964
悪いコードとも言ってないだろ。
コード自体は良い悪い自体言ってない。書く奴が好きに書ければそれで良い。
よく読め。 あとエラーコードはstray ‘¥’ in programって奴だな
cのマクロなるべく避けてるし、正直初めて見た
>>963
ちょっとideonにでも書いて動いてる状態紹介してくれんか? >>962
Cは見るけどインラインアセンブラは見ないってことなんだけど、お判りにならない? >>966
swapの後ろについてる¥マーク取ったら動くよ
見たらわかるだろ >>968
あ、動いたわ。これ改行の代わりか
久々に見たわ。ありがとう >>965
あのさあ。ハイジェニックなマクロはちゃんとメリットあってハイジェニックなの
ハイジェニックでないことが良いって言っておきながら、ハイジェニックな良い例を挙げられないってどういうこと?
色々書けることそのものなんて、ハイジェニックなことの利点と比べたらゴミみたいな利点なわけ
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.8.2.htmlみたいなコード量産可能になることがハイジェニックなことより重いって思ってるわけ? ていうか、kernelから引用するならもっと良いマクロあると思うんだが
container_ofとか
http://d.hatena.ne.jp/big-eyed-hamster/touch/20091226/1261754005
でもC言語大好きだった頃は凄いと思ったが、いま見たら全然しょーもないわ c11が実行できるところだと実行できると思う。pfの便利さもわかる。
ideoneはc11が動かんからcでは確認できないけど、c++14だと動いた。
https://ideone.com/0PBzBG
このままtest.cでも動くんじゃないかな。
スマホからでほかの環境めんどくさくて見てない。ごめん。 >>973
あー。いや。マクロ動かないのは完全に俺が悪かった。申し訳ない >>970
知ってるよ。利点は。lispまだ使ってるしな。
>>971
それより、maxとminと、min_not_zeroの方が好き。 そういやプリプロセッサが乗ってる言語って最新の言語では見ないよな。
Go言語は意図的に削ったのは分かるんだけど(コンパイル速度優先のため)
他のはどういう理由なんだろうな。swiftとかあったほうがいいと思うんだが 構文として統合されたマクロならむしろ盛況な気がする
DやTemplate Haskellやcamlp[45]が散々こねくりまわして、nimにもrustにも
Cプリプロセッサのような、言語からも独立して使えるようなマクロはないけどさ >>977
単純にダサいからだよ
言語設計者にとってみれば、自分の言語はテキストマクロに頼らないと使い物にならないゴミですと恥を晒してるようなもんだ まあC言語のポータビリティの高さはマクロがテキストマクロってことが大きい
構文マクロだと、複数のコンパイラによって拡張構文がちょっとずつ違うみたいな状況には対応できん
次世代言語が実用に耐えてるのは処理系が「まだ」ひとつしかないって面もあると思う >>945
すまんが今来た俺もお前が手抜き過ぎると思うわ
分かんないなら無闇に質問するんじゃなく勉強するか
じふには理解できないものと諦めろよ。
自分に理解できないのは相手が悪いみたいな態度は、
もっとこう、なんでも分かる人にしか許されないと思うぞ
それに相手ちゃんと質問に詳しく答えてくれてるじゃん。
以上。 どうせあが言ってる事はまた理解できない事だろうから、俺が理解できないのもこいつが悪いに違いない
まあ仕方無いかもしれないな cのマクロで言いたかったことは
別にcのマクロが良いものだって話ではなくて、
高級な機能のマクロでバカが作ったものより
低級な機能でも優秀な人が作った枯れた技術のが安定するってことなんだけどな。 >>977
include 処理とか, Boost みたいに高級な事すると恐ろしいコンパイル時間になることが分かったからでしょ。
あれのせいでファイル分割しないのがベストなプログラミングとかいう奴まで出始めたわけで。。
まあそういう実験所を提供してるってのはc++の良いところな気もするけどね。
実験に巻き込まれたくはないけど。 >>985
>include 処理とか, Boost みたいに高級な事すると恐ろしいコンパイル時間になることが分かったからでしょ。
これ。
インクルード処理にマクロを使ってるからな。
例えばpsコマンドのソースをコンパイルする時<sys/stat.h>を37回includeしようとするらしい。
こういうのがソースの依存関係が大きくなるに従って指数関数的に増えていく。
結果としてコンパイルに40分とかかかるように。
Goは上記のコンパイルの無駄な時間から生まれたらしい。
詳細は
https://talks.golang.org/2012/splash.article 40分とか掛かるのはPSの話じゃないし、
40分が30分くらいに短縮したってだけじゃん。 マトモな実用OSでC以外の言語で記述したの
何かある? 次スレのタイトル考えた
現行のままでもいいけど
文字数制限(48byte)には注意
次世代言語Part8[Elm Nim Julia Elixir Crystal]
次世代言語Part8[C#7.2 C++17 Java9 ES2017 PHP7.2] (他Python3.6) 次世代言語議論スレ[略]
で良いじゃん、毎度揉めるなら。
2ぐらいに各言語入れとけば? メジャー言語はいらないと思う
代わりにRustやSwift, Kotlin, Hack等の新興言語入れればいい hackはnull安全だからあり。
elmも仲間に入れて このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 43日 4時間 40分 58秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。