【超高速】C/C++に代わる低級言語を開発したい 7
1 :
デフォルトの名無しさん :
2010/05/31(月) 00:56:58 70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。
しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。
既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。
「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。
◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 6
http://pc12.2ch.net/test/read.cgi/tech/1274015781/
2 :
デフォルトの名無しさん :2010/05/31(月) 01:00:37
このスレッドは天才チンパンジー「アイちゃん」が 言語訓練のために立てたものです。 アイと研究員とのやり取りに利用するスレッドなので、 関係者以外は書きこまないで下さい。 京都大学霊長類研究所
3 :
デフォルトの名無しさん :2010/05/31(月) 01:01:24
◆新言語の要件 v0.1◆ (1)ハードウェアを直接操作する低レベルの記述が可能 (2)プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易 (3)最新のオサレ機能が使えてワクワクしながらプログラミング可能 ◆主な要望◆ ・デバドラ屋だって、オサレ言語で開発したい! ・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。 ・組込み屋だけど、関数型とダックタイピングしたい。 ・shared_ptrの構文糖が欲しいな ・低レベル記述性(絶対条件) > 構文の美しさ(読みやすさ、学習の容易さ) > 再利用性(抽象性) ・算術演算以外の演算子は後置 ・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。
4 :
デフォルトの名無しさん :2010/05/31(月) 01:02:50
◆新言語の名称(仮)◆ Programming Language I ◆新言語の位置づけ◆ Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, … 烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。 一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。 そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、 過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。 ◆新言語でのリソース管理方針◆ ・確保したリソースを明示的に後始末しなくても問題が発生しない ・何らかのメリットのために確保したリソースを明示的に後始末してもよい ※GCは手段であって上記が満たされていれば必ずしも必須ではない。
>>1 > しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
> 新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
概念的には全く同じものになるだろう。
>>4 なんでLLが(ハッカーの手により)生まれ、Cみたいなのが生まれないのか
少し考えれば分かるだろ
7 :
デフォルトの名無しさん :2010/05/31(月) 01:16:05
◆新言語を考える上でのキーワード◆ クロージャー カリー化 型推定 構文を操作できるマクロ ファーストクラス関数、正規表現、文字列、スレッド、XML、イベント ◆マクロについて◆ 「マクロ」に必要な要件って何なんだろう。 ・構文を置き換えるルールを定義できる ・シンボルを置き換えるルールを定義できる Lisp級の構文木を操作可能なマクロを作る要件 ・マッチングプログラムが簡単に書ける ・マクロの実行時に構文木を返すプログラムを書ける また、作るのを容易にするには ・単純な式として構文解析が可能
8 :
デフォルトの名無しさん :2010/05/31(月) 01:20:46
◆低水準に関連するキーワード◆ ・ハードウェアを直接操作 ・デバドラ ・直接アドレス参照 ・OS ・GCとかVMとか目的のプログラム以外のものが動作しなくても動くこと。 ・8bit/16bitCPU対応で、RAMが32KBしかなくても動作するプログラムが作れること。 ・0オーバーヘッド
forkと連呼してる奴w
新言語の方は、GC付きオブジェクト指向でいくっぽいし。
低水準な方は、高級マクロアセンブラっぽいし。
>>1 乙
俺よくわかってないんだけど
超高速ってC以上に高速なバイナリ吐くってこと?
機械語に落とす時に最適化される部分をプログラマが
指定できるみたいな要件が
ってとこで
>>4 読んだ
リソース管理でどっちでもいいよって言うのは
結局プログラマがリソース?の状態を気にしてプログラムしないといけないから
後始末必要の方が好み
Cと同じ位の低レベルな時点で RAMリソースなんて0で動かなきゃ
0ってスタックも無しかよw
RISC系のCPUで変数少なかったら 葉っぱの関数ではスタックもいらないのを見越して書く メモリとかバスユニットの初期化コードとか。
正直マジでレジスタとROMしか使えないんなら素直にアセンブラ使ったほうが 良くないか
仮に使ってもゴミ読むだけなら 問題ない場合もあるしな
>>16 見た目は普通に書けるよ
呼び出し側はアセンブラかもしれんけど
アセンブラでよくてもポータビリティのためにCに書き直すことは意味ある。
俺は後で自分や他人が読むためかなw 数ヶ月たつと忘れちまうし、若い奴に見せてもアセンブラだと敬遠しやがるし
>>12 そもそもこのスレのテンプレは
>>1 が重要だろうと思ってるレスを 過去ログから拾って来て、
適当に羅列してるだけだから、何一つ決まってないよ。
決めたい人が決めればいいよ
23 :
デフォルトの名無しさん :2010/05/31(月) 22:59:29
他人が決めてくれるのを待つ必要なんて無いんだよ
ははぁ勝手にやればいいよってことですね 思いつきで書き込んだんですが、今思えば コンパイラがやってることをCのレベルに持ってくるのは難しいというか無駄? 上に乗っけるのと違って現状の処理が変わるわけですし優秀なコンパイラあるし。 でもアセンブラいじりましたって状況がなくなるなら面白そうなのかな? とりあえずC?にもってきたらどんな記法になるかを書いてみたいけど 当方素人なのでGCCが吐いたアセンブラを変更しないといけないシチュエーションが思いつきませんw
あ?
26 :
デフォルトの名無しさん :2010/06/01(火) 00:12:20
テンプレートメタプログラミングは必須だな
手続き型アセンブラ オブジェクトアセンブラ 関数型アセンブラ LLアセンブラ
アセンブラアセンブラ
アスペクト指向アセンブラでダックタイピング
どこかに小型のCコンパイラのソースって無い? ベル研のPCCはテーブル定義が足りない。 TCCはちょいとでかい。
31 :
デフォルトの名無しさん :2010/06/01(火) 22:35:29
なぜC
Cにネタを積んで遊んでみようかと。
>>31 僕の理由はCの実績。すでにあるプログラムに
手を加えるだけで恩恵が得られるって夢のようだとは思いませんか?
まあCに埋め込むものがどんなものになるかはまだ想像つかないです。
コンパイラ?を拡張するならまったく違う語法?でもいいのかもしれないし
改修してしまうならCがちょっと形を変えたものになるのかもしれない。
ベースになるのはCだろうなとは思ってますが
C++やC++0x、Java、Lisp?、といった言語だけでなく
Struts2やらシンフォニーといったフレームワークだったりとか
も参考にできるところがあるんじゃないかなあと
C++0xについてはいいものを見つけられた気がします。
とりあえず僕は他の言語をつまみ食いしながら
C99をよく見直して吟味するとこからなのでマイルストーンも何も置けない状況
今日は他の事してたので進捗はナシ。
34 :
デフォルトの名無しさん :2010/06/02(水) 00:30:34
schemeから始めればいいのに。
プロファイラ作ってみなよ
プロファイラもデバッガも仕組みさえわかれば 下の方は簡単だが問題は見せ方だよな XcodeのInstrumentsとか面白い
37 :
デフォルトの名無しさん :2010/06/02(水) 21:24:24
プロファイラを言語機能に入れてよ
え?もしかして僕ですか? 言語機能には入れないけど作ることにはなるんじゃないですかねー 新言語にしか興味ないので見せ方は他の方がどこかの誰かに丸投げ 僕のがモノになるのはずーっと先だろうなあ。
アセンブラ言語から先は同じでいいんだからプロファイラ自体は先に作れるのかな? アセンブラだから評価はステップベースでいいしあとはリソースの扱いを考えて・・・ 静的なメソッドごとのステップと消費リソースを吐き出せばおkだったり
アセンブラ言語って呼び方やめてくれ。ムズ痒くなる
アセンブラングエッジ
アセンブラ言語なんていってごめんねアセンブラ言語なんてもう言わないよ あーあーアセンブリ言語をアセンブルするアセンブラ。
ラ行3段活用?
国語の話はやめてくれ。ムズ痒くなる
国語の能力とプログラミング能力の相間について
国語というより作文能力とは相関がある
どうせアセンブラやらないといけないし プロファイラ先に作ってみる
48 :
デフォルトの名無しさん :2010/06/03(木) 22:40:29
○静的な機能として ・ラムダ式 ・名前空間 ・テンプレート ・型推論 ・マクロ ○動的な機能として ・文字列 ・リスト、キュー、スタック、ハッシュテーブル ・正規表現 ・並列処理 ・多倍長演算 ・ベクトル演算
文字列とリスト以外いらん
これからの時代、ベクトル計算は要るだろ。
51 :
デフォルトの名無しさん :2010/06/05(土) 00:21:49
メニーコアプロセッサが普及するだろうから、並列処理とベクトル計算は必須。
結局理想を追求したらGoになったでござるの巻
低級言語にベクトル計算とか要らないよ インラインアセンブラでやってくれ
ベクトル計算機のベクトル計算のことだろ。 そういう計算機では機械語がベクトル計算なんだが。
ベクトル演算専用言語を作るのは面白いけど それが目的じゃないならインラインアセンブラでやればいいんじゃないの
ベクトル演算は言語標準でまではいらないが 標準クラスライブラリに含まれて然るべきだろう。 その方が演算器にCPUだけでなくGPUも使えていい。
ここはあれか、Core2DuoとかCellとかが最低ラインなのか。
最近のコンパイラは配列をループで回したら勝手にベクトル化してくれるから、ベクトルかが良くかかるガイドラインを示せば言語仕様には特に組み込む必要は無くないか?
59 :
デフォルトの名無しさん :2010/06/05(土) 16:03:11
C/C++って低級言語じゃないんじゃ?
配列はベクトルでは無い ベクトルは行列、そして積和演算
61 :
デフォルトの名無しさん :2010/06/05(土) 16:57:13
>>58 > 最近のコンパイラは配列をループで回したら勝手にベクトル化してくれるから、ベクトルかが良くかかるガイドラインを示せば言語仕様には特に組み込む必要は無くないか?
ガイドラインを示すくらいなら、言語仕様に組み込んだほうがいいだろう。
特殊な小手先のハンドオプティマイズより、言語仕様に基づく公式なやり方の方がソースのポータビリティーも確保できる。
Fortran と正しく書かないと
えらいロングパスだな
581に期待
並列処理の構文欲しい
ベクトル演算ってどんな感じで作るんですか?
68 :
デフォルトの名無しさん :2010/06/06(日) 03:59:51
int a[5], b[5], c[5]; c = a*b; int d[3][5], e[2][3], f[5][2]; d = e*f; こんな感じとか。
配列とベクトルは論理的に違うもの。 記述性を考えればdouble2,int4,float3とかのベクトル型は 組み込みで持っていたほうがいい。
70 :
デフォルトの名無しさん :2010/06/06(日) 10:09:47
>>69 >配列とベクトルは論理的に違うもの。
これはどういう事?
3次元が特殊なのは分かるけど その他は特殊な事ってあったっけ
73 :
デフォルトの名無しさん :2010/06/06(日) 10:48:50
>>72 ググったってたくさん出てくるから
>>69 が何を言いたいのかよく分からないよ。
具体的に説明して欲しい。
>>69 配列で十分だろう。ベクトルの足し算だってループでまとめて記述できるしコンパイラが自動的にベクトル化してくれる。
75 :
デフォルトの名無しさん :2010/06/06(日) 10:59:44
regster int a[5], b[5], c[5]; c = a*b; regster int d[3][5], e[2][3], f[5][2]; d = e*f; こんな感じで、コンパイラに努力目標を伝えられたらいいかもね。
行列演算なんて普通lapack/blasだろ
77 :
デフォルトの名無しさん :2010/06/06(日) 12:16:40
>>76 そういう機能をうまく構文に取り込めるといいね。
志村!スレタイ、スレタイ
だからFortranを勉強しろと FORTRANじゃないぞ? Fortranだ
Fortranに変わる新言語を作りtai!!のスレになりました。
81 :
デフォルトの名無しさん :2010/06/06(日) 18:12:11
AVXとかLNIとかに対応できる構文があればいいよね。
>>79 「Fortranを」と言うより、「Fortranのどの機能が良いから新言語に取り入れよう」と提案した方が議論が進むと思うよ。
みんなロングパス受け取ってくれたみたいだな
84 :
デフォルトの名無しさん :2010/06/06(日) 18:37:50
>>83 それが決まってるのは結構なことだけど、それがどう良いのかの説明があればもっと議論が深まるのにね。
素直にFortran知りませんと言えばいいのに
86 :
デフォルトの名無しさん :2010/06/06(日) 18:46:29
別に知らないことは無理に表明しなくてもいいんだよ。 それぞれが知っていること、成し遂げたいことを語ったほうが前向きだからね。 だから、Fortranの並列演算に価値を見出している人がいるなら、その人がどう良いのかを説明して仲間を増やせばいいと思うよ。
Fortranの並列演算なんてライブラリで出来んじゃねえの どうせならOccamとかの方が面白いだろ
行列に関しては、clapakでだめなの? 並列演算(SSE2/VelocityEngineほか)を直接制御したいというのは別だろうか。
>>87-88 既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。
マルチコアのプロセッサが今後主流になるだろうから、並列処理の構文はあったほうがいいだろう。 整数の四則演算だってライブラリで提供することは可能だが、多くのプログラミング言語にはしっかり構文があるわけだし。
脊髄反射すんなよ 高速演算ライブラリの必要性や配列の演算出来るって話は否定しないが 言語の話するなら並列実行構文の方が面白くねえかっつってんの
あ、89に書いたのよ お前みたいな凡人が寄り集まってんだから既存の言語を参考にすんのは当然だろうがよ
93 :
デフォルトの名無しさん :2010/06/06(日) 19:04:41
並列実行構文の方が面白いと思う。
並列に実行して!という構文より 並列化コンパイラが作りやすい構文にした方が
並列実行構文 と 並列演算構文 を両方議論を進めよう。
96 :
デフォルトの名無しさん :2010/06/06(日) 19:08:54
>>94 自動で並列化してくれるのはもちろん嬉しいけど、プログラマがある程度制御できるようにもしておきたいかも。低レベルを目指しているので。
並列に実行して! ってだけじゃなく、出来れば並列に実行して!みたいなのが面白そう
並列化を考えるなら、OpenMPのforの分担みたいにデータを並列化するんじゃなく、 普通のマルチスレッドアプリみたいな処理を分担するものを自動生成できるといいなあ 思いつかないけど 並列度は、明に指定も出来るし、デフォルトはシステムのプロセッサ数とかから 自動的にチューニングできるといいね。 あと、同期とかスレッド間通信もある程度は検討したい。 goのchannelはシンプルながら面白いよね
channel面白いね でもやはり同期と排他と共有メモリは欲しくなるね
100 :
デフォルトの名無しさん :2010/06/06(日) 19:35:06
channel欲しいかも。
粒度が荒い並列はスレッド的な何かでいいが 細かいのは
ワッフルワッフル
103 :
デフォルトの名無しさん :2010/06/07(月) 08:12:59
並列化ってのは、そう難しいものじゃないんだけど、 並列時でもACIDを保証する事とパフォーマンスをスケール させる事が難しくて、この難しさは、ようは、リエントラント性の 確保と、キャッシュ分散に関わってくる所なので、その辺をどう考えてるの したいとか言う気分述べられても困るんだよね。 OSが無い状況で、言語が資源を持つ事の意味をどう位置付けるのか その辺を考えないと議論にならない。
どうせ低レベルじゃそんなの保証できないししてちゃ性能でないだろ 最低バリアーopとかcasみたいなのでクリティカルなとこだけ保護できれば後はなんとかなるんじゃね 粒度の高いのはコンパイラマターでいけるし 低いのはRTOSのカーネル程度のショぼいディスパッチャとスケジューラをランタイムに入れとく。 分散はライブラリ。
単なるディスパッチャとかmutexとかメッセージ含めて数kb程度でおさまるだろ OS上で動かす時はそいつをpthreadとか使うように置き換えで
106 :
デフォルトの名無しさん :2010/06/07(月) 09:34:08
>>104-105 そのモデル違いがいかに混乱を巻き起こすのかってのは、
Linuxの事例で明らかなんだけどね。
君らその辺の難しさも理解しないで暮れ暮れ言い過ぎ。
一応OS屋のはしくれだが どこらへんが明らかか後学のために教えて欲しいね
108 :
デフォルトの名無しさん :2010/06/07(月) 10:10:15
>>107 ふぇ?最近のOS屋はそんなレベルなんだ・・・
110 :
デフォルトの名無しさん :2010/06/07(月) 11:08:12
具体的な説明は一切できずに人格攻撃か。
112 :
デフォルトの名無しさん :2010/06/07(月) 11:25:29
職業倫理の問題なので、人格攻撃と捉えられても困るし。 詐欺師を叩く事が、人格攻撃というのなら、そうなんだろうが、 俺は詐欺師の存在が、社会へ対する害悪だし、詐欺師へ攻撃する 事の方が正しいと思う。 君が詐欺師好きなのは分かったけども、そんな人間だと公言されても 困るだけだし。
ただの質問をしただけの他人を詐欺師と決めつけて攻撃するほうが、 社会へ対する害悪だし、そういう馬鹿に対して馬鹿と言う事の方が正しいと思う。 君が馬鹿なのは分かったけども、馬鹿が馬鹿を晒すのは勝手にすればいいし。
全角に期待した俺がアホだったかな 学校でうだうだしてないで社会に出なさいよ
あ、113にじゃないよ
116 :
デフォルトの名無しさん :2010/06/07(月) 12:36:38
>>113 OS屋さんが、ただ質問したいと言って質問する内容じゃないよ。
OS屋さんであんな質問するのは詐欺師。
ランタイムライブラリにリアルタイムOSカーネルを乗っけるのか。 さっぱり分からん。OS-9辺りから学べばいいか?
RTOSのカーネルなんてしれてるよ 言語に並列組み込むなら 環境によってOS上ならスレッド、 無しなら小さいディスパッチャと 基本的なmutexとメッセージはいるやろって話 うーむ。詐欺師かねえ
で、具体的に Linux の事例、ってどういうこと?
120 :
デフォルトの名無しさん :2010/06/07(月) 15:28:57
>>119 ライブラリスレッディングが、スピンロックするんだけど、
それがLinuxのLWPと競合して、スピンロックのエスカレーションを
発生させて、システムを致命的な状況に落としかねないって話と、
スケールアウトしないって問題を引き起こしていて、GNUPOSIXに
問題があるので、ユーザーランドスピンロックを解消しにくいとか、
じゃあOS側でLWPのスケジューリングをどうしようかってのが、
ここ2年議論されつづけている。
LWPそれ単独、ユーザーランドスレッディングそれ単独では成り立つ
話でも混ぜると大騒ぎって話で、色々とね、難しいのよ。
排他制御のタイミングも違ってくるし。リソースの待ち方も違ってくるし。
で、それをOS屋であれば周知のはずだと思い込むのが犬厨か
122 :
デフォルトの名無しさん :2010/06/07(月) 16:28:39
僕じゃ理解できないかもしれないけど
>>120 の議論について読んでみたいので
進行形のスレッドか議論の流れがまとまってるサイトが知りたいんですけど
そういうのってどこ見ればいいんですか?
もったいぶった割につまらんオチだったな
なかなか、有意義な話じゃないすか
bsdとかSolarisとかでも相当昔に揉んだ話 どっちにしろ言語の並列機能やるならOSの上に乗っかるから関係ない 俺はまたthread以外の有用な並列化のモデルが出てくるかと思った
クライアントサーバモデルに代わる言語を開発したい
晩ご飯のおかずに代わる言語を開発したい
129 :
デフォルトの名無しさん :2010/06/08(火) 16:37:48
>>126 また脊髄反射かよ(w
前にリンク張ったからもう張らないけども、
なんでその俺は分かってるんだって文体で
頓珍漢書くかなぁ・・・
議論の流れを追えば、OSがあるからって
発言はありえないだろ。
諦めてOSに任せるべき、という発言になるべきだろ。
OSに任せると性能が出ないから、ってんでたとえば Erlang なんかは言語が並列化を まる抱えしてるし、どこをどう読めば「諦めてOSに任せるべき、という発言になるべき」 なんだかわけわからんわ。
131 :
デフォルトの名無しさん :2010/06/08(火) 17:04:51
>>130 あぁ、君がスレッドモデルを小学生レベルで理解してない事を
理解し損ねて俺が頓珍漢な発言をしてた。ごめん。
Erlang なんかは、この時点で君がキチガイだと了解したわ。
スレッドモデルを勉強しなおせWikiにまとまってるのでOK
どんだけアイちゃんスレだよ
アイちゃん隔離スレだろ、ここはw
アイちゃんって何匹も居るの?
しむらすれたい
まずはシングルスレッドの動きを規定すべきだろ。 マルチスレッドはシングルスレッドの動きに直交する形で設計すりゃ良い。 だからForthを(ry
137 :
デフォルトの名無しさん :2010/06/08(火) 23:19:46
>>136 シングルスレッドの議論も、マルチスレッドの議論も並行に進めていいよ。
シングルスレッドの動きを規定する案があるなら提案してくれると、議論が進むと思うよ。
OSがいない状況、言語がリソース管理、GC? 低級言語にしては大きくなっちゃう、 スレッドをCPU数やリソースに応じたチューニング、アイちゃん
>>131 お前ほど自分で人に書いてる罵詈が自分に当てはまる奴も珍しいなw
Erlang出したのは俺じゃないが、今更カビの生えたスレッド実装の問題出した上に結局スレッド使えとかレベルが低すぎる。最近の論文とか読んでないから期待したじゃねえか
もういいからちょっと齧った程度の狭い知見で恥さらすな。お前程度の話ならみんなわかってるよw
140 :
19 :2010/06/09(水) 10:43:45
スレッドの実装って通常はC言語で実装されているのですか? それともアセンブラで実装されているのですか? インラインアセンブラですか?
両方だよ つ−か分家へ帰れ
142 :
19 :2010/06/09(水) 13:15:53
>>140 あまり気になるようなら19はフィルタしてください。
C言語とアセンブラで書くということですね。ありがとうございます。
そんなてきとーな回答しなくていいのに いまや分家の方が本家っぽい
144 :
デフォルトの名無しさん :2010/06/09(水) 19:55:34
新言語でも、新言語とインラインアセンブラを組み合わせて開発ができるといいな。
Cにネームスペースが入れば満足
ネームスペースは要らない
クラスだけでいい。
クラスはもっといらない
ソフトウェア開発しないならクラスもデザインパターンもいらないわな
要る要らないじゃわからんから、理由も付けれ。
151 :
デフォルトの名無しさん :2010/06/10(木) 19:58:23
ネームスペースは必要だよ。 名前に接頭辞を付けると名前が長くなって可読性が低いけど、 ネームスペースならコード中で省略できるから可読性が高い。
確かに複数ファイルにまたがるスコープなら、あっても良いような気がする。
クラスは要らない。 というかあっても良いと思うんだけど、マルチパラダイムな言語では、 ぐちゃぐちゃなヒドい実装になりがちだからダメ。 OOPLにするならするで、現状C言語を使わざるをえないような チープな環境はターゲットとしては捨てるべきだよ。
糞環境だけにピンポイントかよwCOBOL並みの糞言語じゃん
COBOLは、糞ではない。 幾多の消え去った言語を尻目に、いまだにたくさん使われている。
一時期デファクトスタンダードみたいになったからだろ。今から積極的に学ぼうなんて奴はいない
OOPって本当はピンポイントだけど、C言語風のOOPは汎用っぽく見えるよな
158 :
デフォルトの名無しさん :2010/06/11(金) 01:31:44
クラスはともかくとしても、デストラクタは欲しいから、結局クラスがあったほうがいいんだろうな。
GCに代わるデストラクタをピンポイントしたい
今ってコボラーが一番平均年収高いんだぜ? つまり最高の言語って事じゃん
レガシーシステムの管理者が貴重なだけだろ
だから、そんだけ払える(価値がある)ってことだろ 社会的に「最高に価値のある言語/技術者」と評価されているわけ わかった?
じゃあなんで大学で必修にしないのかな なんで「学習する価値がある言語」と評価されてないのかな
COBOLが糞か糞でないか、終わってるか終わってないかの議論では 糞だし終わってるというのが一般的な見解だろ
>>163 うんまぁそういう事は大学行ってから言おうね
大学で教えるのは、学習に適した言語だよ
COBOLは糞だし終わってるが、お前らより遥かに社会的に価値がある。以上。
COBOLを有難がってる奴の社会的価値は終わってる。社会的に抹殺した方が良い
次スレは 【超年収】COBOLに代わる金融言語を開発したい で
都会は下水道完備だが田舎ではまだまだボットン便所が多数派だ。 ボットン便所は確かに糞だが汲み取り業者はお前らより遙かに社会的に価値がある。以上。
バキュームカー臭い議論すんな
おまいらの給料だってCOBOLがハンドリングしてるんだろ
COBOL以後にそれ並みになったのは、C、BASICぐらい。
まあ、なんだぁ おれには「それ並み」って言葉の意味がわからないけどな 日本語なのか?
金融系でCOBOLから 他の言語に移行なんてベンダー主導でやらないと無理じゃん
ベンダーってなんですか? 社内で科学技術計算する立場なんですがIT業界の用語が良く分からないんですよね
すまんが、マ板でやってくれ。
>>175 ぐぐってきたぞ。製品を販売する会社なんだって。
汎用機だとIBM,富士通,、NECか金融系の開発受託してるのは違う会社か
>>176 語るならCOBOLは言語的にどう優れているのかって点かなあ
>>177 他の言語で金の計算なんてやってらんねえよw
勘定系は伝統的にcobol、pl/iだったけど 市場系は開発スピードが評価されて20年くらい前からc/c++だけどね
二進化十進表現はのいいものかも。贅沢
>>177 余計なことができない言語は特定分野で重宝するのは事実。
ウメハラのような言語か
一山なんぼのバカでも使えるからな
ほんとのバカにはCOBOLで書くプログラムはまかせないけどね。
185 :
デフォルトの名無しさん :2010/06/11(金) 23:01:05
バカにプログラムは任せないし、COBOLでプログラムも書かない。
ガキのケンカw退屈。 クラスについてだけどマルチパラダイムな状況を許容することで 自由な実装ができてるのだと思うけどどうなんですかね 可読性と天秤にかけられるものなんでしょうか。 ガッチリ決めちゃえば実装は楽になるとは思うけど。 あとクラスがあるからスレッドの実装なんかも楽になってるのでは?
クラス考えるならインターフェイスどうするか考えないと。 まあ、簡単にはメソッドオンリーだろうけど。 チャネルとかストリームとかトランザクションなんかも魅力的だけど重たいしね。
あくまで低級言語なんで、 マルチパラダイム万歳で、リッチな言語は違う気がする。
191 :
デフォルトの名無しさん :2010/06/12(土) 14:12:13
新言語の記述レベルは低レベルであっても、記述力はリッチにしたい。 特にビルド時に処理できる構文は積極的に取り入れていい。
低級言語って、Cは低級言語ではないのだが (Cは高級言語です) 低級言語を開発するという意味が よく、わからない。 最初にスレタイを考えたやつは アホではないでしょうか?
今更何言ってんだ?空気嫁よ
そう思うあなたは分割されたスレ行けばいいと思うの
>>192 高級アセンブラといいたいんですね。解ります
196 :
デフォルトの名無しさん :2010/06/12(土) 15:24:55
昔はCは高級言語であるとされてきたが、近年はそうとはかぎらない。高い低いはあくまで、比較してどうかだから。
>>197 > 昔はCは高級言語であるとされてきたが
いつ頃の話してるのか知らんが、昔から PL/I だの Ada だのの豪華な
言語はあったから、コンパイラ言語としては C は常に末席付近だった
と思うぞ。
>>198 初期の lisp に比べても十分低レベル
つか, 非常に良くできた高級アセンブラだわな
# それがいいんだけど…
200 :
デフォルトの名無しさん :2010/06/13(日) 10:59:38
PDP-11 の頃と今の違いといえば並列 それと翻訳環境の怪物化 パイプラインやベクトル演算も簡潔かつ辛辣に抽象化した 移植可能アセンブラができれば C の二番煎じにはなるだろう # 実はそれっぽいのがもうあったりするが文法的な面白さがいまいち あと operator くらいあれば浮動小数点あたりは強制から任意に緩和できる もっと言えば基本型は bool と配列だけでいい ワード幅 8bit はそろそろぶっ壊してもいいと思う
192じゃないが、
>>196 で見直して気付いた。
「C言語、C言語」言ってるから騙されたけど、
欲しいのはCの代替じゃなくて「綺麗なC++」なのか。
C言語が選択される理由のうち、
記述が機械語に近しいって所はいらんのだな。
コンパイラが作りやすいとか、
コード見てアセンブリが想像出来るとか。
>>201 その二つを両立させたいんだろ
Cの代替であり、尚且つC++並みの高機能にしたい
前者を捨てて後者に特化した言語はごまんとあるから、もうこれ以上いらない
なら、まずC++の何が不満かを洗い出さないと
>>203 C++があるのにCの人気が衰えないことが不満なんだよ
C++への不満が絶えないことが不満
進化、成長しないことが不満 抽象的なモデルより、具体的なソフトを作る人間の方が勝ってると思われることが不満
C++0xは進化でも成長でもないと
0xの勉強するより、Cだけでソフト作った方が有意義だろ常識的に
常識を覆す言語を開発したい
そのためにはまず常識を理解しないと
211 :
デフォルトの名無しさん :2010/06/13(日) 20:18:55
岡目八目ってこともあるが
ストラウさんの 「c++の設計と進化」あたりを読むのがいいんじゃないですかね。 いろいろ c と simula の不満を述べてますがな。
>>202 そうかぁ。
知識不足ですまんけど、動的メモリ確保無しで書けて、物理メモリアクセスや
チップのクロックに依存するようなタイミング制御が出来るような
高機能な言語ってC++ぐらいしか知らんので、
そういう方向もアリかな、と思ったんだ。
Cはシンプルさを目指した言語だし C++は複雑化する一途だし別物なだけ
>>214 そのとおりだとおもう。
でもC++はどんなに複雑でも零オーバーヘッドの原則ですべてが許される。
C++ の不満。ぱっと思い付いたのだけ。 * C との構文的互換性。文脈自由文法でない → リファクタリング支援系のツールの貧困さ * モジュールが無い * 巨大な std 名前空間 * 例外を投げない保証を明示できない → 例外安全なコンテナを作るのが難しい * 資源管理の責任の明示が困難 ( move である程度改善? ) * 型安全な可変個引数が無い * 可変長テンプレート引数が無い
C++は、0オーバーヘッドじゃないだろ。
オーバーヘッドの必然性がない所は 0オーバーヘッドにするように作られている
0.01ぐらいで許せ
C++は共用体を安全に使うのが難しそう Cは安全とか考えないから楽 共用体の配列のかわりにポインタの配列を使うとか ポインタ配列に何か代入するたびにnewするとか Java臭いコードになりそう
共用体は型フィールドのチェックのオーバーヘッドがある けど分岐予測が当たりやすい気がする 仮想関数はパイプライン的にどうなるのかよくわからん
型安全な共用体なら boost::variant があるから OK > 共用体は型フィールドのチェックのオーバーヘッドがある の意味が良く分からないんだけど。 これは C++ 側の話じゃなくてユーザコードでってこと?
223 :
デフォルトの名無しさん :2010/06/16(水) 20:42:01
> 仮想関数はパイプライン的にどうなるのかよくわからん 分岐予測泣かせ
分岐予測ってそんなに重要なの? いや、ループでは重要なんだろうけど、 switchのような類いのものはあまり役に立たないんじゃないかと
225 :
デフォルトの名無しさん :2010/06/16(水) 20:50:25
switchを繰り返すループがよく出てくるんだが
switchでは失敗しまくって、 ループでは成功しまくってんじゃないの
>>222 そう。型フィールドの値をassertとかswitchするユーザコード。
switchはdefaultとか特定のケースに偏ってないと役に立たないと思う。
assertの類のチェックは、失敗することは滅多にないから役に立つ。
分岐予測が当たるかどうかで50%ぐらい性能低下する場合もあるよ
レンホー「なぜ低級言語なんですか。Cじゃだめなんですか」
リストの各要素の仮想関数を呼び出す場合 交互に別の呼び出し先だったりすると 分岐予測機能一般化後の主流各CPUだとパターン検出すら出来ずに全て予測失敗する パイプラインが長いCPUだと即死短くても瀕死になる
231 :
デフォルトの名無しさん :2010/06/17(木) 18:19:09
>>230 わかりそうで分からない。
多分、個々の用語が一般的ではないオレ用語・用法だからだろう。
>>230 それはCでどちらを実行するか分岐しても同じなんじゃないの、と
マルチコアもパイプライン無い時からCは存在してたのかな?
卵が先か玉子が先か
今のCPUはC的言語に最適化されとる
C++で分岐予測が外れた時どれ位のオーバーヘッドが生じるか試してみました #include <stdio.h> #include <stdlib.h> #include <windows.h> struct foo { __int64 start, end, freq; HANDLE hprocess; DWORD oldclass; foo() : hprocess(GetCurrentProcess()), oldclass(GetPriorityClass(hprocess)) { Sleep(10); // SetPriorityClass(hprocess, REALTIME_PRIORITY_CLASS); QueryPerformanceFrequency((LARGE_INTEGER*)&freq); QueryPerformanceCounter((LARGE_INTEGER*)&start); } ~foo() { QueryPerformanceCounter((LARGE_INTEGER*)&end); // SetPriorityClass(hprocess, oldclass); printf("%d\n", (int)(end - start)); } }; void func1() {} void func2() {} void func3() {} void func4() {} void func5() {} void func6() {} void func7() {}
void func8() {} void func9() {} void func10() {} #define MAXITER 10000000 int main() { void (*func[])() = {func1, func2, func3, func4, func5, func6, func7, func8, func9, func10}; { printf("Alternative Call : "); // 分岐予測が効きやすい foo f; for (int i = 0; i < MAXITER; i++) func[i % 2](); } { printf("Ranom Call : "); // 分岐予測が効きにくい foo f; for (int i = 0; i < MAXITER; i++) func[(std::rand() >> 4) % 10](); } } 自宅の環境(Athlon64 X2 5000+)では乱数CALLの方が10倍強のコストが 生じました
上、%2なん? randのコストは?
>>240 てか、そもそもこれ予測分岐のコスト評価になってるか?
>>242 分岐予測が外れる以外に10倍近く差が開く理由はないだろ
>>240 そんなに気になるなら
func[std::rand(), i % 2]();
とでもしろ
ほとんど結果に影響しないから
コード見るとレベルが知れるな
同じ計算コスト、コードで分岐頻度だけ異なる場合でないと意味ない
そもそも分岐予測で間接ジャンプ?
>>245 まだ提示する方がお前さんのような上から目線よりはいいと思うZE
細かく突っ込みたいが…釣りだよな
------------------------------------------------------------ こ こ ま で 成 果 物 一 切 無 し ------------------------------------------------------------
俺が成果だ
成果なんか永遠に出ねえよ
このまま2chにスレを立て続けてたところで何も出てきやしねぇよ。
>>1
255 :
19 :2010/06/19(土) 23:42:33
いちお、このスレ見てやる気が出てきて、色々作ってますよ。 template<T>T add(T a, T b) { return a + b; } というものをうまいこと型推論などで型付きで add(a,b){return a+b;}みたいに書けるといいなと思うのですが、 どうでしょう?
省略なしの場合 def add(a : int, b : int) : int { return a + b; } 型推論で def add(a, b) { return a + b; } 単一式returnの場合のreturn省略で def add(a, b) { a + b; } 何か関数型言語じみてきたが、 最近の言語はおしなべて関数型言語に近づいてる感があるので問題はなかろう
型推論はPTしづらい、と思ってんだがどうだろう? 低水準な開発は実機来るまでプログラムが動かないんで 関数レベルの単体テストが結構重要だと思う。 むー・・・既に時代遅れな考え方な気もするんだけどね。
関数テンプレートを作る意図がなければ 型を省略しなけりゃいいだけじゃない
259 :
19 :2010/06/20(日) 03:19:44
>>256 そんな感じがいいと思います。
省略可能な文法でパースも楽なのがいいなと。
型推論なしでもtemplateの型用トークンを用意するというのはどうでしょう?
def add(a:'T, b:'T):'T = a + b
こんなかんじで、'Tから始まる変数はテンプレート型とするので
template<T>って書かなくてもいいとか。
型理論やばいなあ 落とし所が見つからないと廃人になる
Brainf*ck系はもういいよ!
263 :
デフォルトの名無しさん :2010/06/23(水) 23:53:36
で?成果品ないの?
シビレを切らした
>>1 が、とにかく成果物出せとわめくスレになりました
1日1スレ消費する勢いだったあの頃
いまみたいに規制されてなかったからな
tesutesu
一気に過疎化したな
全部他力本願だもん そりゃ過疎化するわ 誰かが自分で処理系作って発表しないかぎり机上の空論でしかない
お前もそうじゃんw
言語なんて空想しているときが一番楽しい
274 :
デフォルトの名無しさん :2010/07/27(火) 17:33:39
>>271 自力で作れる人がアイデアを精査したく、議論を投げても
ループマンや、LISP厨、一行コメンター等が酷すぎて議論にならないって
はっきりしてしまうんだと思うのですよ。
少し高度な話題振ってる人間も、単にC++0xの議論を持ち込んでる
だけですし。C++0xがの流れを否定してるこのスレなのに、そのスレ主旨
の違いが分からず、C++0xで議論(本当に酷い人はC++0xのスレのコピペ)
されてることを書き込めば、レスが付く、スレに参加してるとでも勘違い
してるかのように。
どうも2chは勢いのスレに参加してると何かメリットあるとか勘違い
してる、無能な屑がかなり存在してるみたいで、それがこの結果
>>270 なんだと思うんですよね。
便所の落書きに何を期待しているんだ?
276 :
デフォルトの名無しさん :2010/07/27(火) 22:35:24
>>274 いや、べつにC++0xの議論を持ち込んでもいいんだよ。
ただ、現状のC++0xは従来のC/C++とのある程度の互換性というシバリを引きずっているから、記述が非効率で、美しくなく、学習しにくいといった問題がある。
だから、従来のプログラミング言語にとらわれず、新しい言語がほしい。
ところが、今出てくる新しい言語といえば、LLばかリで、CやC++がカバーしている分野につかえるような言語はなかなか無い。
そこで、「C/C++に代わる低級言語を開発したい」というこのスレッドが立ち上がった。
過去のしがらみで不必要な制約がなければ、結果的に従来のプログラミング言語に似ていても問題ないよ。
じゃあGCを入れるべきか議論しようか
入れるべき。以上
279 :
デフォルトの名無しさん :2010/07/28(水) 19:08:09
GC の是非はしがらみじゃない
言語設計の観点からは、無いのはかなり困る むしろGCとうまく付き合う方法を考えてくれ エスケープ解析や明示的な寿命指定で GCへの負荷をある程度下げることはできるだろうし もともとスループットだけで言えば、GCは下手な手動管理より高効率 しかし、やはり最悪停止時間が保証できない問題は残る 部分的にGCを停止させるぐらいで妥協できないかなあと考えてるが、 う〜ん……
スレタイ目指すならGCなんてありえんだろ。 別スレでやれw
>>281 無しで考えてもいいが、
それだとC/C++と大差なくなるんじゃないかなあ
そういやGCな言語って最大使用RAMとか見積もれるのか? これが無理だと、かなり組み込みで使えるトコが限られるんだけど。 実はまだメモリ解放されてません、とかだと凄く困る。
>>284 GC ってのは資源が有り余ってるときに使える手法
GC が発生する頻度とその時に回収出来るメモリー量と回収に必要な時間が
許容範囲内なら使える
つか, 「malloc 実装したとしてメモリー足りなくなったときにブロックするの禁止」
な, 世界ではほぼ使えない
引数に渡すものを構造体限定にすれば速くなるんじゃない? 他には、 スタック関連の呼び出しや初期化を極力抑えて、 メモリの割り当てもメモリープール的な考え方で割り当てて、 メモリ解放の概念を取っ払って、 安全性のチェックを全部やらない。 要するに、ハードウェアは弄るけど、全責任を開発者に投げる的な。 最悪、OSごと落ちるかもしれないけど、高速化するんだったらこうなるでしょ。 後は、Pen4以前をサポートしないようにしたり、 SIMDの命令をもうちょっと使いやすいようにしたり。
そんなシロモノは C/C++に代わる低級言語 にはならないと思うなボクは
たしかにメモリ開放のタイミングを制御できないGC言語はC/C++の代用にはならんわな
GC言語がメモリ解放のタイミングを制御できない?????
290 :
デフォルトの名無しさん :2010/07/29(木) 18:22:29
> 後は、Pen4以前をサポートしないようにしたり、
んなクソでかい CPU を強制される言語はやだな
>>289 仮に制御できたとして、だから何だい?
288 はタイミングとしか言ってないから開始時期のみの話にも聞こえるが
仮にベストなタイミングで開始できても何秒かかってもいいってことではあるまい
C/C++って組み込みでしかシビアな組み込みでしか使われてないと思ってるの?
日本語が変になった。つまりアンチGCは頭の固いただの老害ってことだよ
293 :
デフォルトの名無しさん :2010/07/29(木) 21:17:13
いわゆる「富豪的」な環境でもかまわんよ ナノ秒がミリ秒に遅延する仮想記憶でさえ要注意な場面はあるわけで ナノ秒が秒まで遅延する仕組みが天使の取り分でいつも済むとは限らない おまえさんの言う老害は年齢ではなくシステムプログラミングに対する知見の違いで もしかしてブーメランかもね
何言ってんだコイツw なんでGC言語ではGCを必ず使わなければいけないって決まってるわけ?www
295 :
デフォルトの名無しさん :2010/07/29(木) 21:25:38
で、free という GC を選択的に使えばいいわけだw
マジで言ってるのなら頭が悪すぎて話にならない
297 :
デフォルトの名無しさん :2010/07/29(木) 21:45:32
おまえに褒められても気持ち悪いだけさ
お前もGCされたら? ↓
>>294 てか今時GCが使える状況でC/C++を選択する理由が思いつかんのだけど
どういう状況でどういう利点があるの?
実際に使われてるんだから仕方ないだろ
しょぼ・・・ C++しか使えない奴らが作ってたり、過去資産があるだけのトコに 互換性のない言語突っ込んで何がしたいの?
302 :
デフォルトの名無しさん :2010/07/29(木) 23:13:49
日本語でおk
私にとって、本当のオブジェクトのセマンティクスに関する素晴らしいことの1つは、 本当のオブジェクトが「端から端まで本当のコンピュータ (RCATWD)」であることです。 これによって、何でも表せる完全な能力をいつでも保持できます。古いやり方は、 すぐにコンピュータではない2つのこと、データとプロシージャに行き着き、 不意にふるまいに合わせて最適化と特定の決定を任せる能力を失っていました。 言い換えれば、常に本当のオブジェクトを持つことにより、ほしいものを再現し、 惑星の周りに送る能力を保持します。そして、RCATWDはまた、両方向を完璧に保護します。 これはインターネットのハードウェアモデルの中に見られます。(使えるもので、 唯一の本当のオブジェクト指向システムかもしれません) 無料で言語拡張機能を手に入れるには、 メッセージ形式に従うだけです。私が70年代に考えたのは、パーソナルコンピューティングと 同時に取り組んでいるインターネットは、本当に素晴らしいスケーラブルな設計であり、 ハードウェアでキャッシュできる仮想マシンの仮想インターネットを作るべきだというものでした。 これが実現されなかったのは本当に残念です。
私は、オブジェクト指向プログラミングというものに疑問を持ち始めました。 Erlangはオブジェクト指向ではなく、関数型プログラミング言語だと考えました。 そして、私の論文の指導教官が言いました。 「だが、あなたは間違っている。Erlangはきわめてオブジェクト指向です。」 彼は、オブジェクト指向言語はオブジェクト指向ではないといいました。 これを信じるかどうかは確かではありませんでしたが、Erlangは唯一のオブジェクト指向言語かもしれないと思いました。 オブジェクト指向プログラミングの3つの主義は、メッセージ送信に基づいて、 オブジェクト間で分離し、ポリモーフィズムを持つものです。
お年寄りの話は面白くないです
元々緩やかな下降線にはあったけど、人が減った事によって それまでは人混みに隠れていた工作員の存在が目立つようになったのが致命傷だったな 工作員の誘導を嫌って参加者が減り、他所からの工作員を排除しようとして規制をするから 参加機会が奪われて更に参加者が減るという負のスパイラルにおちいってる
このスレまだあったのか
こんなゴミスレでもスレタイにC++が入ってるだけでパート7まで行くとはな
309 :
デフォルトの名無しさん :2010/07/30(金) 07:58:26
GCを実装していても低級言語と呼べるのか。勉強になる。 だったらGCを実装したアセンブラとかならスレタイを満たすんじゃないのかな。
もしかしたらハードウェアレベルでGCの機能を提供できるようになるかもよ
312 :
デフォルトの名無しさん :2010/07/30(金) 16:25:56
アホが1人キレやがったw
>>290 >んなクソでかい CPU を強制される言語はやだな
なぜですか?
>>299 リアルタイム系だと止まるのでGCは使いません。
ゲーム(XNA)だと勝手にGCを発動されるとフレーム描画が止まるので、
ロード中に全て開放して全て読み出しています。
ゲーム中はデータの読み込みやnewを一切行いません。止まるので。
メモリの中にあるものが全てです。
314 :
デフォルトの名無しさん :2010/07/30(金) 18:54:56
C/C++ は元々システムプログラミング用言語で how な部分に深く立ち入ることにミッションがある what に特化したアプリ用言語と相容れないのは論を待たない オブジェクトが動的か否かも how の領域であり、問題そのものが本質的に持つ要求ではなく アプリの土方がここに無気になることには上も下も見えていない滑稽さが漂う
315 :
デフォルトの名無しさん :2010/07/30(金) 19:53:59
>>314 >what に特化したアプリ用言語と相容れないのは論を待たない
そうやって思考停止して満足してるわけだ。
昔はそういう止まると困るものは割り込みで処理するようにして、 本体では重い処理をやるようにしてたものだが。
>>313 「開放」と「解放」の区別もつかない人に語る資格はないと思うが。
人民開放軍ではなく 人民解放軍なんですね
言語にRTOSを組み込めば解決だな gcもスレッド毎にon/off gcより高レベルなタスクは止まらないとか
>>320 CPUごとに異なる言語を作るって意味ね。がんばれ。
機械語やってろよもう
> CPUごとに異なる言語を作るって意味ね。がんばれ。 意味がわからん。 言語がモニタとかの同期機構の面倒を見る、というのはAdaなんかであたりまえにやってるし、 AdaがCPUごとに異なるなんて話は聞いたことがない。
なんで伸びてるのかと思えば、
>>1 が巻き添え規制から解除されてまた暴れてるのか。
言語にRTOSを組めば→そのRTOSは何言語で組むの→その言語自身で…
>>313 GCで不意に止まっちゃ駄目な環境で最近作ってないんだけど、
昔ながらにプールしてGC極力走らせないとか毎フレ強制GCしたりの他に、
止まらないGCとかそういう手法みたいなのって開発されてないの?
コンシューマ機だと本体はC/C++ばっかりだと思うけど
最近はLuaとか当たり前に使われているよね?
そのへんどうしているのかな、と思って
>>324 VESAのような統一規格があるモニタと、全くないCPUを同一と考えてるの?
CPUの型番で周辺機器も異なるし、物理メモリ空間の使い方も異なるし、
割り込み番号の振り方だって違うんだよ?
フリーのOSのソースコード読んだことある?
モニタと言われて同期機構のことだとピンとこないような、RTOSのド素人は黙ってたほうが身のためですよ?
OSとか組み込みマイコンとかの”チープな環境”の領域まで、 C(/C++)にとって変わらなくていいだろ。 言語にOS乗っけるとか、H/WでGCしろとか、本末転倒な話ばっかりじゃんかよ。
ガベコレにはOSやハードウェア支援があったほうがいいし(現状あまり研究とかないけど)、 言語機能とOSの機能が(たとえばスレッドとか)密であっても悪くないだろ。 どこが本末転倒?
>>324 モニタって既存RTOSのサポートがあってこそ。
既存CPUすべてサポートしてるRTOSなんて聞いたことないが。
そりゃPICからスパコンまで全部サポートしてるシステムなんてないだろ。
>>321 は、CPUが異なったら、同期機構が異なるものになる、と主張してるようにしか読めん。
確かにテストアンドセット系のプリミティブはCPUごとに異なるけど、もしかしてそれを
直接言語にしたら、っていう意味なのかな?
たいていのOSでは、OSで共通化した同期機構を提供していて、CPUのそういったプリミティブは
掩蔽されているものだが。
「C/C++に代わる」というのスレタイの解釈が、GC有り派とGC無し派で違うから 話が全くかみ合わない。
>>1 としては「超高速」の存在によってGC有りは排除されると考えてるんじゃないだろうか。
GC前提のコーティングとGCレスのコーティングって全く違ってくると思う
337 :
デフォルトの名無しさん :2010/07/31(土) 22:25:43
GC有り排除は考えなくていいよ。 言語仕様にはGCを含めて、実装できる環境なら実装すればいい。 はじめから無しとする必要はない。
GCがあって高速な言語がいまだかつてあっただろうか?
LISPってC並に速いんじゃなかった?
340 :
デフォルトの名無しさん :2010/07/31(土) 22:41:49
瞬間最大じゃなく瞬間最小が問題になるんだが # 保証という課題に対する思想が深刻にまずいのがいるな
実測結果を提示せよ
このスレで考えようとしてるのってどう考えてもC++以下のゴミ言語だよね アセンブラの方がマシってレベルだよ。脳みそ空っぽなんだろうな
GC有りでCより速いのはないよな? つまりGC有りは議論の余地すらないんじゃないか? ここらでばっさり不要なものは枝刈りしないか?
LISPのマクロは星井
アセンブラのマクロって意外と便利だよな 俺はああいうのでいいよ
>>343 GCは汎用のアルゴリズムだから、問題領域固有の条件を用いることができない
だから、理屈の上では、プログラマが慎重に手動管理すれば
速くなる可能性はある
……理論的にはね
>>348 何その手動管理って。
GCレスより面倒な気がするが?
汎用のアルゴリズムと言いつつ、 GC有り無しは完全に言語を2分する存在だよね。 このスレでも「GC有りは遅い」と思い込む人多数。 つまり性能がどうあれ需要がない。 そして需要はコード品質に直結する。 GC有りのJabaやどとねとは業界権力で生き残ってるけど、 使われてるから使うだけで、単なる1技術として見たら 本来は見向きもされない存在。
351 :
デフォルトの名無しさん :2010/07/31(土) 23:19:31
シムラ、後ろ後ろ
.NETからしか使えないようにするとか DirectX10以上じゃないと動かないとか すべて商売上の都合だな あ、javaは影響力弱いから無くても困らないけどな
GC無しの言語こそ需要ないけど
GCって、意味解析レベルでGC発動がいつ起きて何を開放するか、 ってわかんないんだよね。これが気持ち悪いって人いると思う。 ライブラリで一応実装できるんだから言語機能に入れることないよ。
355 :
デフォルトの名無しさん :2010/07/31(土) 23:26:09
最近の言語は、言語機能もライブラリで実装されているから、 ライブラリで一応実装できるんだから言語機能に入れることない、なんて必要はない。
>>354 まあ失うものは結構あるけども、
それはそれで一つのアプローチだとは思う
ところでPerl並に普及してるGCなしのスクリプトってある? shとか?
とりあえず、GCありきの文法にならなきゃ、あろうがなかろうがどうでも良い話。 最後の最後に辻褄あわせるようにGC向けの構文入れりゃ満足だろ?
360 :
デフォルトの名無しさん :2010/08/01(日) 01:34:38
構文上、プログラマーが意識しなくても適切にリソース管理が行われるなら、GCは無くてもいいよ。 GCは手段であって、目的ではない。
>>327 GCのメリットデメリットは自動的に監視して解放することだから、
仮に自動監視を外したとしてC/C++でメモリをリスト使って管理するのと大差なくなるのでは?
Luaで止まるってことはなかなかないですよ。
どの道、利用しているのはC/C++の関数やクラスなので、
止まるとしたらC/C++側の問題のほうが多いです。
関数の実装に近いような使い方をするので生成とかは通常させません。
int *hoge = (int*)GC::alloc(sizeof(int)*10); これでいいんじゃないか?
> GCって、意味解析レベルでGC発動がいつ起きて何を開放するか、 > ってわかんないんだよね。 資源を確保するところで起きる可能性がある。 はっきりわかってるじゃないか。
364 :
デフォルトの名無しさん :2010/08/01(日) 06:56:34
「使わない」選択のない realloc か
ほらな、みんなPCで動かすことしか考えてない。
366 :
デフォルトの名無しさん :2010/08/01(日) 11:03:52
チープな環境ならGC使わなきゃ良いっつーけど、 ぶっちゃけ言うと、リソース管理を自力で出来ない奴が その言語経験者としてアサインされることが一番困る。
そこは事前に振り分けとけよ。
その人事振り分けもやってくれるコンパイラを作ればおk
>>327 ソフトリアルタイムシステムまでであれば
Erlangっていう実例があるので、決して不可能ではない
----
Erlangをベースとする初期のプロダクトが1993年に開発されていた頃、
(Javaのような)ゴミ集め処理を伴うVM用にコンパイルする言語を、
ソフトリアルタイムシステムに対して使うなどというのは狂気の沙汰だと批判されたものです
(Francesco Cesarini, Simon Thompson著 『Erlangプログラミング』より)
----
このスレはまずwintel脳、言語どころかOSやシステムプログラムをロクに知らないヤツらを隔離すべきだな
久しぶりに書き込める!! 構造化されたパターンマッチング機能だけなら、GCなしでも入れられるよね。
373 :
デフォルトの名無しさん :2010/11/07(日) 03:36:30
まだこのスレあったのか。 一時期凄い勢いだったのにやっぱり言語仕様まとまらなかったのかね。
よくある話だろ。 すでにまとまってる言語仕様にすらあーだこーだ言う連中がうようよ してるんだから。
376 :
デフォルトの名無しさん :2010/11/07(日) 13:07:19
なんども言っているが、ここは、何かをまとめるスレではなくて、考えるスレなので。
377 :
デフォルトの名無しさん :2010/11/07(日) 13:53:20
何か「成果物」ができてきたら、それ専用のスレをたてるべきだな
いいプログラミング言語に必要なのは 複雑なロジックを簡単に書ける事だと思うんだよね 読みやすくて、ロジックが短くなる言語って何があったろ?
Python
ブロック要素がインデント依存ってのは独特だが、確かに短いな 短いと言ってもブロック定義の関係で短いって感じだけど
381 :
デフォルトの名無しさん :2010/11/07(日) 15:04:19
複雑なロジックを簡単なロジックに分割ってのは ほとんどの言語が目指すところで特にどれってこともない 一見簡単そうな記述が書いた本人もびっくりのオーバーなことになっている言語ってどうなんだろ BASIC とか
382 :
デフォルトの名無しさん :2010/11/07(日) 15:36:35
「簡単」というのは表記が短いことも当然あるが、その表記の意味を容易に学習できることも重要。 そのためには、一貫性のある最小限の文法であることが望ましい。 表記を短くするためであっても、「ただし、こういう場合にはこうでなければならない」といった、場合による例外事項は避けるべきだ。
>>376 考えるスレですらなかったろ
全員が好き放題妄想を垂れ流してただけ
384 :
デフォルトの名無しさん :2010/11/07(日) 20:30:13
結局誰も考えをまとめようとしなかったから結局言いっぱなしのスレに・・・
385 :
デフォルトの名無しさん :2010/11/07(日) 21:18:21
何か成果を出さなきゃならないとの強迫観念に駆られてるノイローゼ諸君はわざわざ参加しなくていいんだよ。 言語好きが集まって、理想の言語に付いていろいろ語り合って、知識を増やしり、楽しんだり出来ればそれで十分。 そこから派生して何か「成果」を出したいなら出せばいいが、それはこのスレに求めることじゃない。
このスレにそんな俺様ルールがあったのか。
387 :
デフォルトの名無しさん :2010/11/07(日) 23:32:09
ルールも何も、何か成果を出すなんてことはこのスレの目的にそもそも無い。
言うことは言うけど、参加するって人が少ないなと。 そんな自分はプログラミング言語その物について勉強中だが、 趣味時間だけで言語の作り方把握するのってちょっと大変
>>387 そうだったのね。
てっきりスレタイには開発したいとかテンプレ
>>3-4 みたら成果を求めてるんだと思った。
まぁ意見は言っても参加はしてないから関係ないけど。
まあ、勘違いは誰にでもある。そんなに気にしなくてもいいよ。
自治厨乙
言語仕様まで考えて発言してる人を見たことがないがな。 理想理想と言いながら実現不可能な仕様上で議論しても仕方ないだろう。 実現可能な仕様を考えることも成果と呼ぶのかい?
また自治厨が現れた
394 :
デフォルトの名無しさん :2010/11/08(月) 01:57:14
仕方が無いと思うなら議論に参加しなければいい。誰も強制はしない。
395 :
デフォルトの名無しさん :2010/11/12(金) 22:30:22
話を蒸し返すようだが、低級言語を目指すのであれば、GCは最適化の手段として位置づければよい。 文字列や木のノードのような純粋なデータを効率よく扱うためにGCを利用するオプションがあればそれでいい。 ストリームだのウィンドウだのをGCする必要はないし、本当は高級言語でもそうすべきではない。 その点ではよくあるOOPLよりC++の方が理念的に正しい。
だれも知らないだろうけどamigaEは
>>3 のコンセプトにわりと合致するんだ
E is an object-oriented/procedural/unpure functional/whatever language with quite a popular implementation
on the amiga. It's mainly influenced by languages such as C++, Ada, Lisp etc., and features extremely fast
compilation, inline assembler, large set of integrated functions, powerful module concept, flexible type-system,
quoted expressions, immediate and typed lists, parametric and object polymorphism, exception handling,
inheritance, data-hiding, methods, multiple return values, default arguments, register allocation, fast memory
management, unification, LISP-Cells, macro-preprocessing, a very powerful source-level debugger, gui-toolkit,
library linker, and then some.
過去ログが大勢の目から隠されてしまう2ch掲示板でこういう理論って不毛じゃね?
398 :
デフォルトの名無しさん :2011/01/29(土) 16:49:41
GCやVMいらないならセキュア、リアルタイム、マルチコア向けC派生言語(というかほとんどC++)として
Sappeur Compiler [
ttp://www.sappeur.eu/ ]とか既に段階で存在する。BSDライセンスね。
さらに一部の関数型言語ではCソースも吐けるわ、小型の組み込みSchemeインタプリタも
あるわけで。なんか今更Cの派生言語なんか必要かよと思うわけですが...。と釣ってみる。
399 :
デフォルトの名無しさん :2011/01/29(土) 17:18:40
段階?
400 :
デフォルトの名無しさん :2011/01/29(土) 17:58:59
ある言語(またはツール)が吐いた C ソースでは、 できることの範囲がそいつと C の積集合になるのは わかってる?
401 :
デフォルトの名無しさん :2011/01/29(土) 18:00:23
チューリング完全∩チューリング完全≡チューリング完全
402 :
デフォルトの名無しさん :2011/01/29(土) 18:40:49
Sappeur面白そうだな。勉強してみよう。
403 :
デフォルトの名無しさん :2011/01/29(土) 18:45:10
もしかして万能と混同してる?
404 :
デフォルトの名無しさん :2011/01/29(土) 18:46:26
どういう意味?
405 :
デフォルトの名無しさん :2011/01/29(土) 19:00:41
401 がチューリング完全と万能を混同しているように聞こえた
406 :
デフォルトの名無しさん :2011/01/29(土) 19:09:49
聞こえちゃったならしょうがないな
407 :
デフォルトの名無しさん :2011/01/29(土) 19:20:43
へーえ、違うのかい?
408 :
デフォルトの名無しさん :2011/01/29(土) 19:24:09
まあ、チューリング完全でも、空飛べたり、子供産めたりはしないだろうから、完全とは違うだろうな。
409 :
デフォルトの名無しさん :2011/01/29(土) 19:27:39
そんな空想論を持ち出さなくても 切実な問題がいくらでもあろうが
410 :
デフォルトの名無しさん :2011/01/29(土) 19:28:44
例えば?
411 :
デフォルトの名無しさん :2011/01/29(土) 19:31:06
疑似でない乱数が標準 C だけで作れるか?
412 :
デフォルトの名無しさん :2011/01/29(土) 19:36:26
確かに切実な問題だな
413 :
デフォルトの名無しさん :2011/01/29(土) 19:39:24
ごく単純化したモデルで示すが int a(b, c, d, e) { return b * c + d * e; } のような処理に CPU アフィニティをどう指定する? 時間的保証はどうする?
414 :
デフォルトの名無しさん :2011/01/29(土) 19:49:23
俺の就職はどうする?
415 :
デフォルトの名無しさん :2011/01/29(土) 19:50:20
プログラミング言語は神ではない。
416 :
デフォルトの名無しさん :2011/01/29(土) 20:22:28
と、ここまで全部独り言
417 :
デフォルトの名無しさん :2011/01/29(土) 20:28:09
遠吠え乙
418 :
デフォルトの名無しさん :2011/01/30(日) 20:22:23
え?
お?
ジョブズみたく、C++を再定義します って言えば、もっと盛り上がったかなぁ
421 :
デフォルトの名無しさん :2011/02/03(木) 00:00:02
要は、CPUやメモリやハードウェアを何の制限もなくいじれて、 マシン語とちゃんぽんにできる言語ってことだろ。 昔の AppleII の BASIC みたいに。
422 :
デフォルトの名無しさん :2011/02/03(木) 00:14:00
Cを完全に置き換え可能で、Cより新しいスタイルでの記述が可能なプログラミング言語
423 :
デフォルトの名無しさん :2011/02/03(木) 04:04:08
D言語?
>>421 みたいな仕様になってもWindows上で動く限り制限されまくるよな
OSでも作るなら別だけど
go go google
>>424 みたいなバカが居るからこのスレは駄目なんだ
427 :
デフォルトの名無しさん :2011/02/03(木) 13:15:28
一行バカレスが 他のスレにも出没しているみたいなので スルーよろ
むりやり 改行してるだけで ブーメラン
429 :
デフォルトの名無しさん :2011/02/04(金) 23:55:21
RiteVMがこう言う方向性なのかと一瞬思ったけど、違った。
CやC++は高級言語だから前提が間違ってるのに、7まで続けるとは何ぞや。
431 :
デフォルトの名無しさん :2011/02/05(土) 12:56:26
何度読もうが高級言語なのは事実だ
433 :
デフォルトの名無しさん :2011/02/05(土) 13:11:48
CやC++が高級言語ではないとは言ってないだろ。
434 :
デフォルトの名無しさん :2011/02/05(土) 14:13:28
あー、
>>432 の定義する「高級言語」でいいよ別に
名前をどうしたいかじゃないから
>>1 C++でいいんじゃねえの
C++ですら手が届かないところはインラインアセンブラでGO
436 :
デフォルトの名無しさん :2011/02/06(日) 01:12:27
スレタイ嫁
リアルタイム性を損なわず、かつコードがでかくならずに
>>1 の仕組みを実行できれば完璧なんだろうけどなぁ
age
1日1スレ消化してたあの頃 このスレが何かしてくれるんじゃないかと夢見たなぁ・・・
C/C++の範囲をカバーするだけの言語なら既に山ほどあるからな。 C/C++だけでしかできないなんてものは最初から無い。それこそC言語の誕生当時から、C言語に存在価値なんて全くなかった。 単に物好きなUNIX屋が使ってて、CとBASIC以外の言語では他ベンダに押されてたMSがWindows APIに採用したというだけで 偶然広まった言語に過ぎない。 問題は「代わる」の部分で、これは要するに既にあるC系言語の資産を全て書き換えた上で、 C言語を使ってる連中を転向させなければならない。こっちのほうが遥かにムズイ。 ってかこれができるなら何十年も前に既にModula-2はCを置き換えてた。
442 :
デフォルトの名無しさん :2011/03/31(木) 23:19:18.86
単にModula-2がその程度の言語だってことだろ。
443 :
デフォルトの名無しさん :2011/03/31(木) 23:34:22.53
餌でか杉
>>443 は
>>442 へのレスだよな?
実際Modula-2は、まともなモジュール化機能、ポインタ演算、豊富な型、structural typing、例外、オプショナルなGC、
コンパイラによってはgenericやオブジェクト指向の拡張があって、70年代後半としては超先進的な言語だぞ。
しかも開発者本人によるOSのリファレンス実装まであった。
予約語が大文字でキモイことを除けば、言語仕様だけの評価なら十人が十人Modula-2 > Cと言うだろう。
それでもC言語に代われなかった、そういうことだ。
> 予約語が大文字でキモイことを除けば、 これが結構致命的だったのでは
446 :
デフォルトの名無しさん :2011/04/01(金) 00:12:36.04
だから、Cに対するModula-2のアドバンテージがその程度だってことだ。
キモさ勝負ならCの文法だって充分キモイし、当時はBASICやらALGOLやらCOBOLやら全部大文字で書く言語も珍しくなかったから その辺割とどうでも良かったと思うんだけどなあ。 まあ今の感覚で見ると間違いなくキモイんだが。
>>446 だったらどれぐらい差があればいいと思うんだ?
ぶっちゃけ当時の規格化もされてないCとModula-2の差は、
>>1 が作ろうとしてる言語とC++0xの差よりでかかったと思うぞ。
>>441 Cはアセンブラと混ぜて書くことも簡単にできるから、
「代わる」作業を分割払いできる。
一括がムズイなら分割すればいいだけ。
450 :
デフォルトの名無しさん :2011/04/01(金) 00:22:34.25
451 :
デフォルトの名無しさん :2011/04/01(金) 00:24:02.79
> だったらどれぐらい差があればいいと思うんだ? 頭の悪そうな質問しますね
453 :
デフォルトの名無しさん :2011/04/01(金) 00:25:49.98
分割して「代わる」部分を書くためには、Cと代わる部分の2言語を知る必要があるから、
それなら代わる部分も含めて一つの言語で書ける新言語が欲しいというのが
>>1 の意図。
共産主義者とかユートピア思想などと呼ばれるやつですね
>>449 なんでCがアセンブラと混ぜて使えることが、代わる作業を分割払いできる理由になるんだ?
ぶっちゃけ呼び出し規約に互換性さえあれば、大抵のコンパイラで、Cのコードを
オブジェクトファイル単位で順次置き換えていくことは可能だぞ?
問題は、可能不可能ではなく、回りの人間に置き換え後verを使わせられるかどうかだ。
例えばzlibは多くの言語でリライトされてて中にはC版より高速と主張してるのもあるが、
実際使われてるのはオリジナルのC版なわけで。
まあCが良い言語かどうかはともかく、Modula-2はねーよ。 予約語大文字は想像以上にキモイからね。 そういうシンプルな理由が人気を左右するんだよ。 Lispが天下取ってないことでも分かるだろうに。
>>455 おそらく、高速バージョンよりも単純で小さいのを目指すほうが評価は高い。
>>456 別に今からModula-2を推そうってわけじゃねーよ。単に過去にCに挑んで敗れた言語ってだけだ。
ただまあ、予約語大文字がキモイってのは、現在予約語が小文字の言語ばっかになって慣らされてしまってるからで、
当時はそんな珍しいものではなかったはずなんで、Lispと同列に語るのはねーよ。Lispは当時でもキモかったはずだw
比較演算子==と!=も、初めて見たときは相当にキモかったはずだろう?
>>458 その当時の人も大文字ばかりの言語はウザイと思ってて、
だから大文字小文字の区別あり/予約語小文字のCが受け入れられた可能性もある。
当時を知らんけど。
C/C++のスクリプト言語つくってくれ。 インタプリタだが、Cのソースもはけるやつ。 およそPHPみたいなやつ。ライブラリが豊富なやつ。
461 :
デフォルトの名無しさん :2011/04/01(金) 20:43:06.35
Modula-2がキモかったというよりは、言語としてCを置き換える(というか普及する)ほどの魅力がなかったというだけ。 コンパイラやライブラリがショボかったのも問題。
別にいいんだけど、俺が自分で挙げたこと以上の具体的な話が何も出てこないじゃないか。 それで魅力がないだの良く言えるなあ……。
463 :
デフォルトの名無しさん :2011/04/01(金) 21:55:03.78
無いものは挙げられない。
けなす方向にしたって何もでてきてないじゃないか。
言語のシンプルさは、それだけで一つの魅力なんだよ Modula-2にはそれが欠けていた
だから具体的にはなんだよ? 文法だけで見ればModula-2のほうが今のC(++じゃなくてC)より遥かにシンプルだぞ
えーどこがシンプルなの? ちょっと説明してみ?
Modula-2なんてPascalに分割コンパイルの機能を付加しただけじゃん タイプ量も多いしCに比べると明らかに使いにくい
キーボードが苦手な奴はどの言語選んでも中途半端な事やって終わるだけ
結局俺に説明させてばっかじゃないか。 どこが複雑と思ってるんだよ? まあ自分で調べる脳も無いんだろうから俺から書いてやると、 Modula-2は超典型的な構造化言語で、COBOLの書式化やらFortranの行列みたいな 変な機能がない分当時としても今から見てもシンプルな部類。 典型的な構造化言語という点ではCも同じだが、Cのほうには超複雑なマクロの展開規則と、 超複雑な宣言分の意味解析が付いて回る。意味解析の結果をパーサにフィードバックしないと構文解析できないのもコンパイラを複雑にする。 比べてModula-2は何も考えずパースできるLL(1)文法で、教科書通りにコンパイラが書ける。 型は当時のCとModula-2ならModula-2の方が多いが、せいぜい集合と部分範囲型まわりぐらいで これも動的配列と複素数型が追加されてる今のCのほうが複雑だろ。
俺が俺がってウザいね
472 :
デフォルトの名無しさん :2011/04/01(金) 22:45:42.61
Modula厨がどんなに頑張っても、Modula-2には世の中に普及するほどの魅力がなかったのは事実なわけで。
超複雑なマクロの展開規則と超複雑な宣言分の意味解析 が、今や、普通に出来るみたいだけど
>>472 だからそれを書けって言ってるんだよ。
あと別に俺はModula-2をプッシュしてるわけじゃないぞ。話の流れ読めてるか?
過去にCに挑んで敗れた言語の何が駄目だったかもわからん奴に、Cの代わりなんて作れるはず無いだろうが。
>>473 一度自分でCのパーサ書いてみるといい。
教科書通りではなくて、実際にその辺に転がってるソースが通るやつ。
甘く見てると死ねるから、マジで。
一から作るのは、相当時間がかかるよ。
>>475 自分でやる気なんかないよ。
大変なのはわかってるし、そっち方面はやったことないし、
今やってるのは、自分なりにgccをいじるぐらいだよ。
今のCと当時のModula-2を比べて何の意味がある訳?
479 :
デフォルトの名無しさん :2011/04/01(金) 23:13:14.14
C でなくても、アセンブラを作ってみるだけでも 「そもそも、問題の本質は何か?」という疑問には自然に遭遇できる
問題の本質は何だったの?
>という疑問には自然に遭遇できる だから、アセンブラを作ってみて、そういう疑問が浮かんだんだろうな。 答えが得られてるかは別にして。
手間かかる割に、ないものねだりする人が多いからでしょ
コンパイル可能なC++インタプリタ作ってくれよ。 PHPみたいにライブラリは豊富で。
>>460 >>483 これもよくわからんな。
C++インタプリタができた時点で既存のC++ライブラリが使えるから、
というかそれを使いたいからC++を指名してるんだろうに、2行目は何の意図があるんだ?
インタプリタは動的に型を変更できる。型宣言なしで動きかつ純粋C++ソースをはける。 PHPのソースをパクルなりして、PHPの関数も動かせるようにする。
おそらく、具体的なイメージが固まってないまま言ってるんだろうな……。 そもそもコンパイル可能なインタプリタって時点で?が付くし、 C++で書くのか出力としてC++ソースを吐くのか混乱してそうだし、 型を要求するC++の言語仕様にどうやって矛盾なく型無しを溶けこませるかも漠然としてそうだし。 まあ突き詰めていっても、最終的にC++/CLIができあがるだけの気がするが。
487 :
デフォルトの名無しさん :2011/04/01(金) 23:56:17.19
それがお前の想像力の限界。
具体的なことを何一つ書けないやつに言われたかないね
今のコンピュターで何が出来るかわかってない感じ この程度のド素人が実務やったら怖いな
実務w
しらんな、自分で考えろ
知らないことについて語るのは、このスレではともかく世間一般では普通に迷惑だぜ
常識とか持ち出されても
C++をスクリプト言語化しつつ、純粋なC++のソースもはけるやつ。 易しいC++から厳格なC++に変換可能。
楽したいと思うようなことは考えないほうが
C++のスクリプト言語化(C++ソースはける)のはかなり需要あるはず。 webプログラムも、アプリ開発、ゲーム開発もこれに統一できるだろう。 そして既存C++ソースは読み込めて流用できる。 標準でPHP並の装備付きで。
素人でもかける言語が欲しいのかいな?
Cのソースを吐くならValaがあるが、 C++のソースを吐くなんて需要あるのだろうか
C++に憧れを抱くPHPerってところか
>>497 良かったな、C++0xで、ローカル変数についてはほとんど型書かなくて良くなるし、
ranged-forみたいな構文糖も入るし、正規表現も入るぞ!
徹底的に型を排除したければboost::anyみたいなものもあるしな!
PHP並のWeb用のライブラリなら腐るほどその辺にあるし、ばっちしだな!
そんな馬鹿なことやってるんだ
労力の割には、報われんこと?をやってるんだ、かわいそう
俺、アセンブラは68000しか経験のない素人だけど。 元々PDP-11のアセンブラを高級言語風に表現したのがC言語なんでしょ? なら,x64辺りのニーモニックをC風に表現したら、 取り敢えずWindowsプログラミングは多少楽になるんでね?
> 元々PDP-11のアセンブラを高級言語風に表現したのがC言語なんでしょ? その言説は、合ってる部分もあるし、違う部分もある。 たとえばインクリメント・デクリメントが += 1, -= 1 とは別にあるのはPDP-11の機械語の 影響だとされているけど、hoge_t 型を指すポインタに対する演算が sizeof(hoge_t) 倍に なるなんてのはぜんぜんアセンブラ的じゃない。 > なら,x64辺りのニーモニックをC風に表現したら、 > 取り敢えずWindowsプログラミングは多少楽になるんでね? 意味不明。
CISCの命令拡張で生き延びてるから、C風にはならないような レジスタで固定の命令も結構あるし
bsfなんかが組込み演算子になると、便利ではあるな。 特定用途でのみ。
特定用途でアセンブラ使ってる人は自分でコンパイラ書けちゃうんじゃないかと思う今日この頃。
509 :
デフォルトの名無しさん :2011/04/08(金) 17:01:03.30
アイディアを思いつくかどうかと それを実装できるかどうかは別問題 俺がやってみての実感: 構文設計は始めサクサクだんだんgdgd 字句解析の1段目からすでに結構な大仕事で最終段に来る頃にはくたくた 後で思いついたアイディアは素晴らしいがそれは振り出しへ戻ることを意味し ハンドアセンブルしてた頃のMっけと重なりだす Ken さんは偉いよやっぱ
まずは「コンパイラ」か何か読んで理論を押さえるべき。
May the Forth be with you.
512 :
504 :2011/04/09(土) 22:40:16.41
>>505 >その言説は、合ってる部分もあるし、違う部分もある。
アセンブラをアセンブラのまま置き換えても構造化は出来ませんからね、
違う部分もあって当然でしょう。
でも、ポインタ概念自体がアセンブラ的だと私は思うけど。
その辺りの境界は人それぞれですけどね。
>意味不明。
今自分で読み返してみて、通じる訳ないよね、と思った。スイマセン。
ターゲット環境のハードを記述言語の下敷きにすれば、意図した事が
思い通りに書けるし、コンパイラ側の最適化も見通し楽にならないかな、
と思った訳です。
甘いでしょうけど。
513 :
デフォルトの名無しさん :2011/04/10(日) 03:07:10.29
> アセンブラをアセンブラのまま置き換えても構造化は出来ませんからね、 アセンブラのマクロは構造化の最もプリミティブな単位たる「モジュール」の要件を満たす
514 :
デフォルトの名無しさん :2011/04/10(日) 03:07:46.21
追加: ように作れる
今時のコンパイラは ソース(中間コード)レベルでの最適化 archレベルでの最適化 みたいなことやってるみたいだよ
516 :
デフォルトの名無しさん :2011/04/10(日) 03:28:31.62
最適化とモジュール構造は別問題 俺が言うのも何だが、早まった最適化はあとで仇なすのを承知ですること
>>516 お前は覚えたばっかの言葉を使いたいだけだろ
518 :
デフォルトの名無しさん :2011/04/10(日) 04:39:09.04
いーや、おまえが生まれる前におぼえたが何か?
とりあえず、どんな言語作りたいのか 文法一覧書いてみろ
ここの人は手続き型言語しかやったことない人達?
521 :
デフォルトの名無しさん :2011/04/14(木) 11:54:57.53
コーディング作業の8〜9割がデータ構造の記述で 最後に補助的に手続きを書く言語とか ひたすら並列が基本で時系列はメタな存在という言語ならやったが
種の割れてる手品しかやったことない人達 かっこいいじゃん
手続き型言語とかいってる時点で...
論理型はやったこと無いな。
525 :
デフォルトの名無しさん :2011/04/14(木) 21:10:48.02
Basicでいいや♪
ていうか、アセンブリなんて 主な命令は大同小異だし 元にしても意味ないよ 高級言語風アセンブラはいくつも 製品化されてるでしょ 生き残ってないけど。 昔から最適化は今でいうASTのような 式とかソースレベルのものと、 コード直結のピープホールがあるよ 太古のFortranとかかなりのモノ 今から2-30年前には基本的な技術は 完成してる
C/C++言語でいいじゃん。コンパイラの性能上げろ。
531 :
デフォルトの名無しさん :2011/04/23(土) 19:35:01.48
533 :
デフォルトの名無しさん :2011/05/10(火) 22:49:49.34
だからそれを高級言語風アセンブラと言ってるんだろ
もっといろいろ機能付けたアセンブラがあったわけですよ
(´ι _` )アッソ
構造化アセンブラとかいってたけど...
537 :
デフォルトの名無しさん :2011/05/11(水) 11:24:46.17
新低級言語 「X+-」 名前だけ参入 読み方は自由
ばつ・たす・ひく でバタヒー
結局いくつかの言語混ぜればいいだけじゃねーの?
540 :
デフォルトの名無しさん :2011/05/12(木) 00:01:23.38
どう混ぜるの? 具をテキトウに混ぜても、おいしいチャーハンにはならないよ。
541 :
デフォルトの名無しさん :2011/05/12(木) 01:02:15.62
カリー化カリー化うるせーやつが出てきてこのスレは終わった
そんなに悔しかったのかw
543 :
デフォルトの名無しさん :2011/05/12(木) 01:15:30.19
カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化 カリー化
今日はカレーか
コンパイラの勉強もかねてCのサブセットでも作りますか。 その名もC--ってもうあr・・・無いね。
ぐぐれ
547 :
uy :2011/05/14(土) 00:46:55.49
誰も作ろうとしない
ObjC も C++ もそうだけど、初期のうちは C へのトランスレータがあるというのが重要かもね つうことで、Vala で良いじゃん
ある程度以上の独自言語らしい機能を搭載したら、変換後のCコードなんて 普通に読めたもんじゃないぞ。 単にバックエンド自分で実装しなくて楽だね、ってだけの理由しかない。 今時LLVMとかあるんだからその重要性はどんどん低くなってる。
いや、Valaの出力は結構読める
552 :
デフォルトの名無しさん :2011/05/15(日) 00:35:32.97
トランスレータに徹した言語なら昔使った それ自体が何用なのかが、翻訳後の言語によるという位置づけのやつ
553 :
デフォルトの名無しさん :2011/05/24(火) 02:32:41.45
カリー化
554 :
デフォルトの名無しさん :2011/05/24(火) 18:25:14.46
_ -、`ヽ、ヽ//:::::::::::::::::::::::::::::::::::::::::::::::::\ー-'′ , ___ -l-l- ,. -‐ヽ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ヽ Z三|ヨ‐ / _亞亞_ /,ィ:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ノ X ニ|ニ /\‘ 夕 ’ /;::::::::::::::::::/:;ィイヽ//ハ\:::::::::::::::::::::::::::::::-=二 二二′│ 「三 | //:::::::::::::::::// !ト、ヽ、::::::::::::::::::::::::::::::::::::::`ヽ (_ |,/ フ亡 ,ィ:::::::::::::::::::ハ:| ,: |l ヽx≧ヽ、__::::::::::::; - 、::::ノ Z_ ⊥ -{- // !::::::::::::::::::トk、 、 ヽ !ィ〆‐- 、 _ユ イ 广 \`ヽ tz_) ‘X ヽ_` !{ |::::::::::::::::::レ‐≧kx ヾィj√云¨ヽ Y´ |::::| r 、 〉 }::く‐/‐ 、 └‐ -|-l- ヽ. |::i::::::::::::∧イ t込,`Y¬! ' _二 -′} レリ j ベ /:::丿 tト └‐ !ハ:::ト、::t{ヽ} ー¨ '_ } ヾ、" ‐ / 〈 //:∠ {j {j Z_ ヽ ';ヽヽ、ヽl '", イ ` ̄´ /´ ̄/::::/ \・ ・ tz_) ヽ\ ` l` ̄´ / |-ーヘ:::イ ヽ /ヽ/⌒\ l ヽ=≧ | レN ∨ ヽ / l _,. -‐¬、 | ヽ ∨ ', { <´ ̄`\ / \ ヽ | ̄ィ´ ̄`ソ / :. ゙、 Y└-‐/ /.:: :. ヽ `二´ ′/.:.:.: :. ヘ、 _/.:.:.:.:.:: :. ` ̄´ \.:.:.:.:. :. /\.:.:.. :. / { \: :. :.
555 :
デフォルトの名無しさん :2011/06/02(木) 04:34:34.44
このAAがこのスレの全てだな
557 :
デフォルトの名無しさん :2011/06/05(日) 17:56:34.51
transcript
>>557 それって言語の名前?
ググったけど Revolution とか HyperCard とか出てきた。
トランスレータには見えないんだけど・・・
初期のC++じゃん
Colm使っておけ
とりあえず、最近は、アセンブラレベルで見てみてます。
とりあえず誰かBisonか boost::spiritでコード上げろや。 まぁ、んな事書いたら言い出しっぺの法則って言われるからとりあえず一部だけ書いとく とりあえずココマデ。 template<typename Iterator> struct Expression : qi::grammar<Iterator, int(), ascii::space_type>
563 :
デフォルトの名無しさん :2011/06/15(水) 00:31:42.39
浮上
一部過ぎるwww
565 :
デフォルトの名無しさん :2011/06/18(土) 12:39:37.77
(・∀・)Goとか凄いらしいよ
GCCでも標準サポートだし、このスレの役目も終わったな。
567 :
デフォルトの名無しさん :2011/07/03(日) 16:21:56.60
以上カリー化って言いたいだけのスレでした
568 :
デフォルトの名無しさん :2011/07/03(日) 22:33:44.39
そんなに悔しかったのかwww
カリー化 マリー化 弦を弾いて
570 :
デフォルトの名無しさん :2011/07/09(土) 00:59:10.55
_ -、`ヽ、ヽ//:::::::::::::::::::::::::::::::::::::::::::::::::\ー-'′ , ___ -l-l- ,. -‐ヽ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ヽ Z三|ヨ‐ / _亞亞_ /,ィ:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ノ X ニ|ニ /\‘ 夕 ’ /;::::::::::::::::::/:;ィイヽ//ハ\:::::::::::::::::::::::::::::::-=二 二二′│ 「三 | //:::::::::::::::::// !ト、ヽ、::::::::::::::::::::::::::::::::::::::`ヽ (_ |,/ フ亡 ,ィ:::::::::::::::::::ハ:| ,: |l ヽx≧ヽ、__::::::::::::; - 、::::ノ Z_ ⊥ -{- // !::::::::::::::::::トk、 、 ヽ !ィ〆‐- 、 _ユ イ 广 \`ヽ tz_) ‘X ヽ_` !{ |::::::::::::::::::レ‐≧kx ヾィj√云¨ヽ Y´ |::::| r 、 〉 }::く‐/‐ 、 └‐ -|-l- ヽ. |::i::::::::::::∧イ t込,`Y¬! ' _二 -′} レリ j ベ /:::丿 tト └‐ !ハ:::ト、::t{ヽ} ー¨ '_ } ヾ、" ‐ / 〈 //:∠ {j {j Z_ ヽ ';ヽヽ、ヽl '", イ ` ̄´ /´ ̄/::::/ \・ ・ tz_) ヽ\ ` l` ̄´ / |-ーヘ:::イ ヽ /ヽ/⌒\ l ヽ=≧ | レN ∨ ヽ / l _,. -‐¬、 | ヽ ∨ ', { <´ ̄`\ / \ ヽ | ̄ィ´ ̄`ソ / :. ゙、 Y└-‐/ /.:: :. ヽ `二´ ′/.:.:.: :. ヘ、 _/.:.:.:.:.:: :. ` ̄´ \.:.:.:.:. :. /\.:.:.. :. / { \: :. :.
Cのマクロを代替して、ネームスペースを解決する言語があればそれでいい。 Go言語が近いけどたぶんそれる。
572 :
デフォルトの名無しさん :2011/07/13(水) 18:51:53.54
カリー化できればなんでもいいよ
言語仕様覚書 構造化の言語要素として ・ループ ・条件分岐 は必須。 ループ命令は大きく2種類、for文とdo文 for文はループカウンタや集合イテレータのループ。 for(継続条件 on 増分)ループ内容 か for(変数 in 集合変数)ループ内容 の形式 ループ内容は init{初期処理}{ループ処理}final{終了処理} の形式。init節とfinal節はそれぞれ省略化。 do文は、do ループ内容 while(継続条件) か while(継続条件) do ループ内容 のどちらか。 ループ中に以下の命令があればジャンプ continue (増分処理をして)ループ処理先頭に飛ぶ break final節に飛ぶ(無ければループ終了) exit for(またはdo) ループ終了 条件分岐は2種類。if文とswitch文。 if (条件) 真文 else 偽文 endif ただし、「else 偽文」は再帰的に「elsif (条件) 真文 else 偽文」 に置き換え可能。 switch (式左辺) case 比較演算子 式右辺 : 真文 | default : 偽文 真文の中にcontinueと記述すると次のcaseの真文に飛ぶ。真文の末尾にきたら switch文を抜ける。
何これ?
言語仕様覚書 並列処理可能な部分を明示するにはsync文 sync(並列可能定数)init{初期処理および共用変数宣言}{並列処理1}{並列処理2}… 全てのsync内文が終わるまで同期を取る。 共用変数へのアクセスは lock(共用変数1,共用変数2,…){変数使用処理} の文で排他制御を行う。タイムアウトについては別途仕様を精査する。 並列演算 2次元配列同士の演算は行列演算とみなす。 int a[][]={{1,2},{3,4}}, b[][]={{3,4},{5,6}},c[2][2] c=a*b ベクトル演算はpara文。para(変数 mask マスクパターン){処理} int a[256]={1,2,3,…,256} byte m1=0x55, m2=0xaa sync(2)init{int b[256]}{ para(b mask m1){ b=a*2} } { para(b mask m2){ b=a*3} }
あ、bがsync文の外に持っていけないな。 syncにもfinal節が必要だわ。
578 :
デフォルトの名無しさん :2011/11/20(日) 01:08:23.69
◆新言語の前提◆ ・言語仕様が小さい ・言語仕様に例外事項(但し書き)が少ない ・標準ライブラリーが充実している ・組込みとユーザー定義の区別がない ・標準的なPCアーキテクチャを直接制御するための記述ができる ・仕様にコーディング規則を含み、それに従うことをある程度強要する ・ドキュメント自動生成を仕様を含む
Cにかわるとか野望がでかすぎて無理くさい。 アッパーコンパチ以外、想像もつかない。
無料RPG製作ツール「ロープレジェネレーター」 直感的操作で簡単なゲームが作れます。 簡単に配布可能な状態に出力する ことができます。(HSP製のソースコード付きで、スクリプトの知識があれば 自由度の非常に高いカスタマイズができます) 他にも仲間預かり機能(100人も)や、仲間の状態/状態異常を細かく設定 できたり、乗り物が作れたり、ゲーム中に画像を差し込んだり、回転や フラッシュなどのエフェクトなんかも簡単に作れる様です。 移動は矢印キーの他に、キャラがマウスを追っかけたりするとのこと。 戦闘はデフォだとドラクエ系。 ・次期バージョンのロープレジェネレーター2.00アルファ版2を公開しました。(2011/10/29)
言語レベルでドキュメント生成とか狂ってる
582 :
デフォルトの名無しさん :2011/11/21(月) 02:30:34.29
> ・標準的なPCアーキテクチャを直接制御するための記述ができる つまり PC の仕様変更に、PC 絶滅まで振り回されるわけか
583 :
デフォルトの名無しさん :2011/11/21(月) 02:31:47.97
> ・仕様にコーディング規則を含み、それに従うことをある程度強要する 「ある程度」が蟻の一穴ということを、まだ学んでいないな
で?
>>578 CがOS作成向けってのはOSの機能を使わない(ライブラリなし状態)でもポインタとかは使えるのが強みだぞ
つgolang
587 :
デフォルトの名無しさん :2011/11/21(月) 23:08:07.36
なんでPC限定?かわからんが アドレス直アクセス、 I/Oポートアクセス、 割り込みハンドラが書けるとかかね Cでは普通は後者二つは出来ない アドレスの自由なポインタは強力だが 危険過ぎてC直系以外ではほぼ採用されてないね それにポインタで読み書きしても実際に アクセスされる保証がないから むしろライブラリで対処かな
>>588 > アドレスの自由なポインタは強力だが
> 危険過ぎてC直系以外ではほぼ採用されてないね
つか, ないとカーネルとかデバドラとかかけない
頼むから高級アセンブラを、 その他の高級言語と同じに扱わないでくれ
自由に指す機能が必要なのは、ヒープ管理とか、ごく限られた モジュールだけじゃないかという気がするが。 ていうか「高級アセンブラ」とか得意がる奴はたいていハッタリ野郎というのが俺の印象。
591 :
デフォルトの名無しさん :2011/11/22(火) 21:42:12.41
物理が苦手な化学屋みたいなもんで、ありえねえ
処理系側としては、極力ポインタは制限したい どこを指してるのか・何が指されてるのか・何を指す可能性があるのか 静的に分からないと最適化できん
593 :
デフォルトの名無しさん :2011/11/23(水) 01:47:55.78
◆新言語の前提 ver0.01◆ ・言語仕様が小さい ・言語仕様に例外事項(但し書き)が少ない ・標準ライブラリーが充実している ・組込みとユーザー定義の区別がない ・標準的なコンピュータアーキテクチャを直接制御するための記述ができる ・仕様にコーディング規則を含み、それに従うことをある程度強要する ・ドキュメント自動生成を仕様を含む
という言語が欲しいのです、ということですか?
595 :
デフォルトの名無しさん :2011/11/23(水) 10:13:47.58
YES
言語仕様覚書 式について {}で囲まれ、「,」で区切られた値の組は集合を表す。 集合は各要素変数への一括演算が可能。 例){a,b,c}={1,2,3} 関数の戻り値に集合を指定して複数の戻り値を返すことも可能。
Linuxカーネルは元が86てこともあるが 移植性やアドレス空間を考慮して I/Oのアドレス直なんてあんまり使ってないよ volatile,aliasing,restrictとかが必要になるが 言語的に結構面倒なんよね 高級アセンブラはc99でかなり完成してるし goのように少し違う方向性がいんじゃね
598 :
デフォルトの名無しさん :2011/11/23(水) 17:24:48.51
オーバーヘッド最小限にI/O・メモリアクセス、割込み処理ができて かつ、その記述が平易、直感的、誤解が少ないことが望ましい。
文字列はどうするんだ?基本の型に入れるのかな。 入れたとすると多言語とかどうすんの。
>>598 組み込みとかOSやドライバやったことないだろ
文字列型入れると問題になるのはメモリ管理だね
602 :
デフォルトの名無しさん :2011/11/23(水) 19:51:56.02
文字列型は必須だが、「組込みとユーザー定義の区別がない」のであれば、基本型である必要はないかな。
基本型に入れないと結局Cのnull終端のバイト列にしかならんのじゃないか?
>>598 なんか過去にひどい目にあったかのような要望だなw
全くランタイムに依存しない言語なんてのは 実際には難しいわな
606 :
デフォルトの名無しさん :2011/11/23(水) 21:18:09.44
CPU のμOP にすら依存しない言語が身近にあるのに・・・
607 :
デフォルトの名無しさん :2011/11/23(水) 22:13:35.77
別にPascal風にレングス+バイト列でもかまわんだろ。 基本型から外すとウザい気もするが。
別にPascal風にレングス+バイト列でもかまわんだろ。 基本型から外すとウザい気もするが。
610 :
デフォルトの名無しさん :2011/11/23(水) 22:47:50.57
レングスのフィールドは可変長?
611 :
デフォルトの名無しさん :2011/11/23(水) 23:10:29.75
文字列の内部表現はあまり重要な問題では無いので、テキトウに。 NULL終端でいいんじゃないの。
>>606 マシン語とかCPUアーキテクチャといいたいのか?w
メモリ管理やらブートストラップやら
どのCコンパイラも結構ランタイムとがっぷりだよ
自分でそのへんまで弄れる言語は他にはないけどさ
613 :
デフォルトの名無しさん :2011/11/24(木) 00:36:11.90
>>612 そのランタイムの大部分を自身で書けることが C の存在意義で
どうしてもアセンブラや diagnose が必要なコードが無視しがたい量になるかどうかが境だ
614 :
デフォルトの名無しさん :2011/11/24(木) 00:43:09.03
>>606 CPUのμOPに依存する言語なんてあるの?
アセンブリ言語はマイクロコードの組み方に影響をうける つか、インストラクションセット自体が変化するわな
616 :
デフォルトの名無しさん :2011/11/24(木) 00:52:45.95
プロセッサのインストラクションセットが変われば、アセンブリ言語が影響を受けるって話? まあ、そりゃそうだわな。
マシン語互換ならマイクロなんちゃらは 関係ねえからw せいぜい最適化位 armとかriscはほとんどハードワイヤードで マイクロなんちゃら持たない
618 :
デフォルトの名無しさん :2011/11/24(木) 22:45:59.04
既存のバイナリーオブジェクトをリンクして呼び出せること
>>614 μOPという以前にマシン語レベルで従来のそれらとはまったく違う価値観な
プロセッサは存在している。例えばスキップ命令(条件分岐命令がない)を実装したものとか
四則演算(整数&浮動小数点両方)が存在しないとか。
メジャーな高級CPUばかりな人は知識にすらないだろうけどね。
今はロジックが余るし電力無駄だから マイクロコードなんてx86位だろ しかし条件実行は知ってるが 四則演算がないCPUは知らんな そろそろスレ違いか
そいや昔の8bitなんかは掛け算割り算なかったか
>>620 除算命令のマイクロコード実装すらサボってるARM
623 :
デフォルトの名無しさん :2011/11/27(日) 01:34:36.56
◆新言語の前提 ver0.02◆ ・言語仕様が小さい ・言語仕様に例外事項(但し書き)が少ない ・標準ライブラリーが充実している ・組込みとユーザー定義の区別がない ・標準的なコンピュータアーキテクチャを直接制御するための記述ができる (オーバーヘッド最小限にI/O・メモリアクセス、割込み処理ができて、かつ、その記述が平易、直感的、誤解が少ないことが望ましい) ・仕様にコーディング規則を含み、それに従うことをある程度強要する ・ドキュメント自動生成を仕様を含む ・既存のバイナリーオブジェクトをリンクして呼び出せる
7までいってver0.02とかねえ
え、今まで成果物出てないの?
ざくっとgoの多値とinterface{}と 後置宣言をなんとかすればok
goの改良点全否定っすか。
sliceとか型推論とかgcはいいよね
>>620 >四則演算がないCPUは知らんな
お前の家にもリモコンぐらいあるだろ?
液晶などが付いてない単純な送信だけの赤外線のTVリモコンの類が
それだ、
そのCPUは非常に単純な機能だが福島原発の原子炉横のような放射線を
浴びても問題なく動く。
駆動の電源が波動するような状況で動くことが前提になっていてデータが
常に化けて誤動作するような状況でも暴走しない設計になっている。
630 :
デフォルトの名無しさん :2011/12/04(日) 14:29:08.09
それを「CPU」と呼べるなら、犬の餌だって「CPU」だ。
C#がネイティブバイナリを吐けて、CやC++のライブラリをそのまま使用出来たらそれで満足だ。
除算機が付いてないCPUとかアホほどあるだろ
バスガス爆発
javaよりがいいっす
>>630 乗算が無くシフト演算で実装するしか無いRisc CPUは、
CPUでは無いのか?
誤爆
ぶっちゃけ、大抵のプログラムは、C#なりPythonなりHaskellなりGoなりの高級言語を使えばよくて、 わざわざ「Cに代わる低級言語」を持ち出す必要はない 一方で、本当にC言語に取って代わろうとするなら、 高級言語を持ち出せない、プアな環境で使えないといけない ・ポインタ演算は手放せない ・GCは使えない ・ポリモーフィズムも使えない ・テンプレートも容量を食い過ぎる ・正規表現を実行時にコンパイルするのは贅沢すぎる ・標準ライブラリーが充実させても意味が無い ・標準でないアーキテクチャをサポートしなければならない それなら、C言語で十分じゃない? 文字列型?ハッシュマップ?サードパーティ製のを使えばいい ドキュメント自動生成なら、言語仕様を変更しなくても、Pythonとかでツールを作ればいい Cのシンタックスがキモいとか、Lisp風マクロとかが欲しいと言うのなら、 JavaScriptに対するCoffeeScriptみたいな物を作ればいい
639 :
デフォルトの名無しさん :2011/12/22(木) 22:37:18.06
>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、 >「既存のXX言語を使えばいい。」という類の発言は無意味である。
640 :
デフォルトの名無しさん :2011/12/22(木) 23:56:30.66
> ・ポリモーフィズムも使えない 関数ポインタが使えないアフォの鳴き声だなw 実行時にコンパイルとか標準でないアーキテクチャとか発狂する気持ちはわかるわ、同意せんが
ちっちゃいのしかやったこと無いんだろ 組み込みはむしろ千差万別が前提だから でもまともなのライブラリがある方が楽だしな h8とかしか知らなかったら不幸
プアな環境では、ポリモーフィズムは使えないっつーか要らないよな。
どうせ静的なのしか使わないからあって困らん 使うかどうかは別だけど。 rttiみたいなのがいらんだけ
rttiの必要性はいまだによくわからない どう考えてもC++向きじゃなかった
645 :
デフォルトの名無しさん :2011/12/28(水) 00:20:22.38
本来はユーザ定義でよかったんだよ 規格化するにしてもライブラリとして言語とは別枠で 若かった禿さまが耐えきれず出ちゃったんだよ
ホントにプアな環境だと、mallocなんてありえないし、 バイト単位でコードサイズを削るハメになる。 けど、そこターゲットじゃないだろ。 スレ的には、低水準かどうかの話なんじゃないの? 要は直接レジスタを叩くようなハード制御ができるかどうか。
まあレジスタ叩くだけなら ライブラリ用意すればいいだけだからな しかし組込にはC11が順当に上がってて とって代わるというのが考えにくいな
ARMアセンブラでアプリ開発してる人いる?
650 :
デフォルトの名無しさん :2012/01/29(日) 17:54:19.68
このスレッドの成果がようやく現実のものとなったか
651 :
デフォルトの名無しさん :2012/02/01(水) 20:36:10.42
これだけ根の生えた C を枯らす気なら それこそ化学反応や物理現象まで降りることができて、 且つ少なくとも BASIC よりはユーザ寄りなことができないと無理だろ
>一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで うーんそこからは新しい物は何も生まれないんじゃないかと思う。
653 :
デフォルトの名無しさん :2012/02/11(土) 00:05:49.04
思うことは誰にでも許された自由である。
Cより高級でC#より低級なObjective-Cみたいなのは需要ありそう。 メモリが節約できること、Cを呼び出した時にJavaのような データ転送コストがないことが満たされれば十分低級なはず。
おまえは間違ってる。 低級と高級の差は性能じゃない。 JavaやC#のコンパイラがC言語ソースに翻訳したり、ネイティブライブラリとリンクすればC言語なみの性能になる。 オールアセンブラでも無駄な処理をするプログラムは遅い。
逆にCコンパイラーでJava仮想マシーン上で動くバイナリを生成する物も作れる。 そしたらC言語の性能が良いとは言えないだろ。 人間にとって扱いやすさが高級だ。
混同しておりました
658 :
デフォルトの名無しさん :2012/02/11(土) 18:06:05.42
へー、objc はメモリが節約できるのかw
既存言語を採用してもいいんじゃまいか? そのままでもいいし改善しても良いし。 ゼロから開発するのは手間掛かる。 C#などはいちおう新言語だがC/C++、デルファイ、Javaなどを参考にしてる。 それでもマイクロソフトで大人数が関わって開発しただろ。 新言語で既存の物より使える物は簡単には作れない。 コンパイラかコンバータでいいんじゃまいか。
660 :
デフォルトの名無しさん :2012/02/11(土) 18:52:34.88
>「既存のXX言語を使えばいい。」という類の発言は無意味である。
たとえば初期のC++はCへの翻訳だった。 C++ - Wikipedia 初期のC++はCへのトランスレータとして実装された(すなわち、C++プログラムを一旦Cプログラムに変換してからコンパイルしていた)。
>>660 実用上も、実装上も、まともに動作する言語を基盤にした方が良い。
現存するC/C++コンパイラもアセンブラ言語への翻訳機能しかないものもあるだろ。ほとんどかも?
663 :
デフォルトの名無しさん :2012/02/11(土) 19:01:52.22
>「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。 基盤にするのは構わない。 「既存言語を使えばいい。」で話が終わるのがイカンといっている。
言語仕様の確定している言語のコンパイラ、トランスレータすら作れないなら新言語なんて作れるか。 既製品を模倣する技術は新言語開発にも役立つ。
665 :
デフォルトの名無しさん :2012/02/11(土) 19:10:04.60
ここは言語仕様を考えるスレである。 言語仕様を考える前にコンパイラやトランスレーターを実装したいのなら他スレでやれ。
666 :
デフォルトの名無しさん :2012/02/11(土) 21:21:29.99
実装してみなきゃ空想論でしょ
667 :
デフォルトの名無しさん :2012/02/11(土) 22:07:30.46
意味不明
668 :
デフォルトの名無しさん :2012/02/11(土) 22:16:24.31
言語仕様を決める前に実装をするのは自由だが、先に行われた実装によって言語仕様が何らかの制約を受けることは一切ない。
実装と仕様は関係し合ってるだろ。GNUカーネルの実装の正式版はできない。 作りながら可能かどうか修正が必要。 GNU Hurd - Wikipedia GNUプロジェクトにとって、カーネルに相当するHurd(及びMach)の開発は最重要課題とも言えるが、その開発スピードは遅く、 2011年現在でも正式版のリリースには至っていない。また、Hurdを採用したディストリビューションとして、Debianによる開発版が存在するが、 これについても公式版のリリース時期は未定である。 開発の遅れにより、UNIX互換のフリーなカーネルとしては、GNUのプロジェクトによるものではないLinuxがデファクトスタンダードとなっている。
670 :
デフォルトの名無しさん :2012/02/11(土) 22:33:29.06
※このスレッドはGNUカーネルのスレッドではありません
まずC言語に変わる言語を開発する理由がない
>>671 ハードの性能も常に向上しているしパフォーマンスは問題にならないからね。
しかし俺にはある。
理由何なの?俺らを共感させてくれないとアイデアも出せないし 逆に反発もできない
いや説明するに足る理由は無いかもしれない。個人的事情って奴だ。
675 :
デフォルトの名無しさん :2012/02/12(日) 01:15:09.14
>>671 理由がないならこのスレに書き込むなよw
676 :
デフォルトの名無しさん :2012/02/12(日) 01:22:20.00
コンパイラの最適化視点にたった言語だったら意味あるかもな 最近SSEとかコンパイラが使いづらい命令多いじゃん でも人間がゴリゴリ書くのめんどいじゃん 数学を駆使して、ある命令セットを使ってできる計算の集合みたいなのをさ 過不足無く表現できる言語 xorとかandとかシフトとか駆使してマジックみたいなコーディングすることあるじゃん あれを数学的に分析して、どういう計算は速く計算できるのかっていうことが厳密に分かるようになったら面白いなって ある計算を与えたときに、それを最小クロックで計算する命令列を出力するコンパイラっていうかさ そういうの考えたら面白いと思う
677 :
デフォルトの名無しさん :2012/02/12(日) 01:25:50.25
具体的に問題にすると、 32bit -> 32bitの任意の写像を与えたときに それを最短で計算できるx86の命令列を求めよ っていう。32bit -> 32bitの写像は四則演算とかテーブルとかで与えるのよ それを式変形していくと命令列になっちゃう。みたいな数学考えたら面白そう まあ、そのために写像の表現方法 命令セットは数学として使いやすいのに限定することになるだろうけど
>>677 その問題に数学でどこまで迫れるかな?
ナップザック問題のようなNP困難である臭いがする。
679 :
デフォルトの名無しさん :2012/02/12(日) 04:10:29.13
知ってる単語並べるだけの噛み合わない会話はご遠慮ください。
東日本大震災以来、天皇、皇后両陛下は幾度も被災地にお見舞いに向かわれた。
今あらためて被災した東北3県を取材し、お見舞いの際に両陛下と被災者の間に生まれた心温まる秘話を再現する。
東北3県のうち最初のお見舞い先は4月27日の宮城県。両陛下が同県で最初に視察された被災地、
南三陸町の町長・佐藤仁氏(60歳)が振り返る。
「両陛下は町立伊里前小学校の校庭に自衛隊ヘリで降りられ、被災した市街地を校庭の隅から視察されました。
学校は高台にあり、校庭の先は崖になっているため、安全を考えて校庭の隅にある花壇の手前に立っていただく予定にしていたのですが、
両陛下は崖のすぐ近くまで歩み寄られ、じっと眼下の市街地を見ておられました」
両陛下は市街地に向かって黙祷を捧げ、佐藤町長から被災状況などについて説明を受けられると、
被災者が待つ町立歌津中学校の体育館を訪ねられた。同行した佐藤町長はそこで両陛下の心遣いの深さを目の当たりにする。
「私が先に体育館に入り、両陛下をお迎えしました。実は当時はまだ物が不足していて、
スリッパも用意できたのは両陛下に履いていただく2足分だけで、私はスリッパを履いていませんでした。
すると、それを見られた皇后陛下が、いったん履かれたスリッパを脱がれたのです。
さらに天皇陛下までがスリッパを脱ごうとなさった。それで皆で慌ててお止め申し上げたのですが、
他の誰も履いていないのに、自分たちだけ履くわけにいかない、というお心遣いだったのでしょう」
http://www.news-postseven.com/archives/20120211_87099.html
681 :
デフォルトの名無しさん :2012/02/12(日) 12:44:10.60
682 :
デフォルトの名無しさん :2012/02/12(日) 12:59:01.63
最低でも、整数の四則演算にビット演算とシフト演算を追加して、式変形みたいのできたら楽しいよな
683 :
デフォルトの名無しさん :2012/02/12(日) 13:13:36.40
それじゃ、四則演算、ビット演算、シフト演算を仕様に含めよう。 演算子は仮に+,-,*,/,>>,<<.>>>.<<<でいいかな。
アセンブラ→C言語→オブジェクト指向言語→スクリプト言語 or VM用言語→関数型言語 と言語の文化は進んで来ました。現状はスクリプト言語やJava、C#が最新です。 スクリプト言語やJavaやC#はアセンブラとC,C++で作られています。 WindowsをC#で書き直そうとしましたが失敗しました。 結局、OS,言語は古いC言語やC++で書かれています。 C言語やC++を置き換える言語の試みにはGOやD言語がありますがGCがはずせない問題がありました。 Pascal,Adaは逆に完全なGCを含む事ができません。 GCなしで、GCを後付け出来る構文の言語を作りましょう。 新しいC言語風な関数型言語でスキッと作りましょう。 低レベル言語ではマクロは必要なのでLispのマクロを導入しましょう。 オブジェクト指向や関数型、GC等を導入可能な言語構文の低レベル言語を作り 今後の基礎とするのです。
685 :
デフォルトの名無しさん :2012/02/13(月) 01:38:13.37
GC導入ってコピーGCを望むならオーバーヘッドは避けられないし 保守的なBoehmっぽいやつなら、CだろうがPascalだろうが行けるし 言語作るのにあんまり意識する必要も無いな
>>684 >アセンブラ→C言語→オブジェクト指向言語→スクリプト言語 or VM用言語→関数型言語
Lisp(1958年〜)は関数型言語に分類される。
C言語(1972年〜)はその24年後だ。
アセンブリ→関数型言語野→C言語→シェルスクリプト→オブジェクト指向言語
って順番だろ?
「野」が余分だったすまん
>>686 あと算数間違えた24年後じゃなくて14年後だ
RAIIパターン強制で例外で投げるものとか一部GCっぽいものがあればいいよ
690 :
デフォルトの名無しさん :2012/02/13(月) 12:17:30.61
そういうのとGCはできることの集合が根本的に違うんだよな クロージャの循環参照とか
691 :
デフォルトの名無しさん :2012/02/13(月) 12:22:08.30
( ´_ゝ`)フーン
最近は、型推論が最新技術としてもてはやされてるそうだよ
何十年も前の話をいまさらって感じだよな
694 :
デフォルトの名無しさん :2012/02/13(月) 20:46:55.60
とりあえずGCの恩恵って凄いじゃん。でも遅いじゃん それを解決する方法を考えれば
>>690 よそのクロージャへの参照なんてものは、ナマポか弱参照で持つのが正しい。
GCがある言語でも、理想論としてはそうあるべき。
文字列だの連結リストだのを使い捨てするとか、
グラフを繋いだり切ったりするアルゴリズムを実装するとか、
そういう用途ならGCに頼りまくって何の問題もないと思うけどね。
696 :
デフォルトの名無しさん :2012/02/13(月) 20:55:00.56
>>695 クロージャーって上のスコープの変数にアクセスできちゃうじゃん
それによってGCが必要となってくる
グラフはGCあるとメガ楽だよな
上のスコープにアクセス出来るのは欠点
C++/CLIはgcnewを後付けしてclassが二種類になり 元々標準だった方のclassが要らなくなってきた 結局、classなしでdllを作ってからC#でdllimportすればいいし dllを作る言語はCでなくてもいいからCの影響はもうなくなっている
>>698 Windowsの.net frameworkのネイティブなライブラリはC++/CLI と gcnewでうまく作れて
高速にロード出来てうれしいというかんじなんでしょうか?
newはgcを使って、calloc はスタック使うとか mallocはヒープ使うとかにすればいいのかも。
var gc:A = new A()
var stack:A = calloc A()
var heap:A = malloc A()
Rubyっぽく
var gc:A = A.new()
var stack:A = A.calloc()
var heap:A = A.malloc()
と書くとか。gcはgallocにするとか。
var gc:A = A.galloc()
var stack:A = A.calloc()
var heap:A = A.malloc()
700 :
デフォルトの名無しさん :2012/02/14(火) 12:58:30.02
>>699 プログラミング暦浅いだろwww
糞設計だな
それと、gcをどうやって実装するか知ってるのか?
>【超高速】C/C++に代わる低級言語を開発したい 7 スレッド趣旨からするとクローじゃとかGCはいらない。 デバイスドライバーとかハードウェア制御と相性が悪い。
>>699 もちろんGCの実装はもちろん知っててコピーGCとか、LispのGCとか
作った事あるぜ
GCなしは基本だけど、シンタックスを考える上でGCありを考えておき、Rubyのような
言語をエレガントに実装したり、Cのライブラリも奇麗に実装できたらいいだろ。
そういう仕組みを考えようぜと言ってるのよ。
シンタックスだけならバックエンドと切り離して考えられるから考えてみようぜ
くそ設計いうなら、おまいさんのすばらしい設計を見せてくれ
GCとかは言語と関係ない。 GC付き言語からGC外せばメモリリークするだけ。 GCなし言語にGC付ければメモリリークしないだけ。
GCの有無がシンタックスにも影響するんだが Rubyボーイの低脳なこと
メモリリークを手動(コード)で解放するか自動の違い。
GCだって、大規模なプログラムだと、外してもいい参照を永遠と 持ち続けて実質的にメモリーリークと同じ状況になる場合だってある
あおいりぃJapan
GCは解放のタイミングを遅延させる意味もあるでしょう。 遅延した解放処理が悪いタイミングで重い処理と重なるとまずい。 並列GCでもゲームのような安定性の求められる分野では厳しい。
えらい低レベルな議論してるのう。 スマートポインタ使えばGCは必要ないし。手動で解放することもない。 ただしスマートポインタでもGCでも同様に循環参照は手動で解放するか弱参照を用いるしかない。 まあGCだと色々面白いアルゴリズムを使う余地ができるというメリットはある。
>>702 「○○なしは基本だけど○○ありを考えておく」パターンはC++にたくさん出てくる
・多重継承なしは基本だけど多重継承ありを考えておく
・実行時型情報なしは基本だけど実行時型情報ありを考えておく
このイメージを払拭しない限り、糞設計と思われても仕方ない
さすが低級言語スレ、低級だのう。
C++/CLIは以下のようになっていて、書式がバラバラで美しくないので奇麗に書きたいのだ T t; // スタックに T *t = new T(); // ヒープに T^ t = gcnew T(); // GC管理領域に auto_ptr<T> p(new T()); // スマートポインタ
今は深く考えてないので、考えてみる必要があるんです。 最初から設計が決まってたら議論なんていらない。 多重継承は結局mixiとかtraitとかで行うみたいな流れですよね。 C++は未来を読み違えた感があるけどしょうがない。昔に考えた言語なのだから。 で、考えておく考えをしてたのがC++でメジャーな考え方なので悪い考え方ではないと思いますよ。 今、我々はC++を設計していた時代の未来を知っている。 どういう物を作りたいっていうイメージはある。 でも、構文は決まってない。だから考えようと主張してるのです。
で、考える最初の段階ではブレーンストーミングが必要なので、 自由に意見を言ったらいいと思うのです。 ただ人の意見にすぐ否定するのはブレーンストーミング的にいまいちです。 ただ、ブレーンストーミングだけでは、具体性に欠ける部分があります。 だから詳細について議論して本当に駄目そうなら議論をやめればいいんです。
抽象論に終始して虚しくならないかい?
このスレから成果が現れない理由がわかった気がする。
717 :
デフォルトの名無しさん :2012/02/14(火) 19:32:27.28
今さら多重継承に反対されても聞こえないなあ
718 :
デフォルトの名無しさん :2012/02/14(火) 20:05:21.11
(∩゚д゚)ァー ァー キコエナイ
多重継承の成果が聞こえない
多重継承はアホな使い方しなければ問題ない
>>706 >永遠と
>持ち続けて
きみはまずこくごをべんきょうしなさい
ところでパッケージシステムはどうしたらいいでしょうねと。
パッケージシステムって何?
var a1:A = alloc A() // ヒープからアロケートする。 var a3:A = auto A() // ローカルスタックからアロケート var a2:A = new A() // GCで管理 var a4:A = auto_ptr A() // 自前なスマートポインタ と書くとすれば、型情報をどう管理するかが問題で保守的なGCか 型情報をデータに持たせる動的な型の管理になる。 今までのC言語は静的に型の情報を解決しないと実現出来ないから保守的なGCでしか 上のシンタックスは実現出来なさそう。
型情報を管理するとなると型に何かしら書かないと行けない。 初期化や型を美しく2つあるいは複数の概念を奇麗に美しくかき分けたい。 var a:Int=1; var $a:Int=1; // gc管理下の変数とする。 perl,phpから$が付いているとかしたらどうだろう? 動的型というか、変数名にgc管理下にあるかどうかを持たせる。 def add($a:Int,$b:Int):Int = { return $a+$b;} でも返り値の型が指定出来なさそうで困る。うーん。
var a:Int = 1 // 値 var a&Int = 1 // 1の参照 var b^Int = a // bのハンドル GC管理 短縮形 var a := 1 // 値 var a &= 1 // 1のポインタ var a ^= a // bのハンドル こんな感じで、:以外に変数に演算子を適用するとか。
>>726 >def add($a:Int,$b:Int):Int = { return $a+$b;}
>でも返り値の型が指定出来なさそうで困る。うーん。
この例では、Intが指定できてるんじゃないの?
729 :
デフォルトの名無しさん :2012/02/18(土) 16:29:34.00
お前らセンス無さすぎだろ
書き分ける -> コンパイラにヒントを与えて最適化の余地 or コンパイル時にエラーチェック or 文法上意味がある
書き分ける意味ってだいたいこのどれかが目的でしょ。
>>726 とか俺らが考えないといけないこと増やすだけだし、パフォーマンス上がるわけじゃないし。メリットが一個も無い
そもそも
>>712 はさ、パフォーマンス気にしないなら全部どれかに統一すればいいじゃん
全部ヒープでいいじゃん
パフォーマンス気にするなら書き分ける必要があって(コンパイラへのヒントってことね)統一なんかできないのよ
統一しちゃったら最適化が利かせづらい
パフォーマンス気にする必要があるので、書き分ける必要はあるだろうね。 ぜひセンスのある解法を提案してほしい。
731 :
デフォルトの名無しさん :2012/02/18(土) 16:35:35.84
rubyとかで$が必要なのは文法上必要だからな まあ俺はあれが気に入らないんだけど globalっていうクラスのをグローバル変数用に使いましょうって言っておくだけで、 グローバル変数なんていう特例作らなくてもいいのにな せっかくの動的な言語なんだから そういうの考えたいなら、効率的にアセンブラに落としやすい言語考えようぜ? クリティカルな関数とかをアセンブラで書くかわりにこの言語を使うのよ ループの並列化、ベクトル化 とかを主軸にした言語な 出来合いのループ -> 並列化 じゃなくて 並列ループ構文 -> ループを作る っていう逆転の発想な。fortranとかはそうか でももう少しインテリジェントにさ、もっと書きやすい ループに内在する並列性を人間よりもインテリジェントに見つけ出してくれるやつ
732 :
デフォルトの名無しさん :2012/02/18(土) 16:39:38.71
>>730 お前クリティカルなコード書いたこと無いだろ。気にするところが間違ってんだよ
ヒープに取ろうが、スタックに取ろうが、参照渡ししようが値渡ししようが大差ねえから
クロック数と触るメモリのサイズ・・・clock/byteとか
メモリがキャッシュに収まるかどうかとか
そういうほうがはるかに大事だから
ネットワークとかHDDとか絡んだら台無しだしな
並列ループ構文の案を出してほしい。 OpenMPくらいの機能が構文にうまく組み込まれるといいかもね。
>>732 ヒープとスタックを区別する必要のないクリティカルなコードを書く用途にも、そうでない用途にも使えるように、
ヒープとスタックは区別できるようにしておきたいね。
735 :
デフォルトの名無しさん :2012/02/18(土) 16:47:14.97
OpenMPくらいじゃ意味ねえだろ。世界中で研究してるでしょ intelとかはさ、金に直結するわけだし もっとアルゴリズムまで踏み込んで並列化するようなのが欲しいよな 数学に近いのかな 問題を記述すると、アルゴリズムから考えてくれるような奴 人間が記述しやすくて、コンパイラも理解しやすいようなのが必要だな
>>735 コンパイラなりオプティマイザなりにそのような処理をさせるために必要な構文をアイディアがあるなら提案してほしい。
737 :
デフォルトの名無しさん :2012/02/18(土) 16:56:17.59
>>736 残念ながらアイデアの手持ちは無い
思いついたら書きこむ
逆に高級言語になるだろうな。メモリにどこからどこまでアクセスするのかとか厳密にコンパイラ側が知ってないといけないから
研究の方向としては
・いろんなアルゴリズムを表現できるコンパクトは構文セット
・さらにその構文セットは変形がしやすい
・同じアルゴリズムを表す別々の二つのコードを、同じ形に変形する方法がある
こんな感じでアルゴリズムを式として表して、その変形で最適化を行えるようになれば
738 :
デフォルトの名無しさん :2012/02/18(土) 17:01:20.56
マージソートとクイックソートとバブルソートが同じアルゴリズムだってコンパイラが認識できたら面白くない? そしたらコンパイラならではのさ、ハイブリッドソートを作れて。世界最速のアルゴリズムになるかも そしたら俺が有名になれる。マイクロソフトからさ、そのコンパイラ1億ドルで売らないか?って誘われてさ
面白いけど、それ言語の話なの?コンパイラの話じゃなくて?
なんか突然スレが動き出したなw
多分停止問題に帰着できて不可能って話になりそうな気がするけど
742 :
デフォルトの名無しさん :2012/02/18(土) 17:25:50.68
アセンブラ見せてこれ最適化してよって言ってもアセンブラレベルの最適化しかできないじゃん C見せて・・・これでもまだアルゴリズムには踏み込めない でも、整数式はいろいろまとめたりできるわけじゃん アルゴリズムも数式みたいに扱えるようになったらいいのかなって そのために言語も変える必要があるなって 数学的には自動証明に近いかも
743 :
デフォルトの名無しさん :2012/02/18(土) 17:26:09.19
744 :
デフォルトの名無しさん :2012/02/18(土) 17:29:53.13
まあ、俺は数学には詳しくないんだけどな これを機に勉強してみようかなって思ってるんだ 証明論の本買ったし
>>742 お前はセンスがいいと思うが、数学がダメなのか?
演繹的にプログラムの変形が自由になればプログラムの複雑度を数値化できる。
そうするとステップ数よりもより厳密な工数計算が可能になる。
PGに対する評価も正確になり。
頑張れば報われる世界に近づくと思っている。
数学数学って、数学ってそんなに怖いものじゃないよw
747 :
デフォルトの名無しさん :2012/02/18(土) 18:49:23.75
数学を使えば何か凄いことができると思うのは高卒プログラマーのよくある妄想 事務職の女子社員が英語で自己実現とか言ってるのと基本的に同じ
>>747 みたいなのが計算機科学を知らない高卒プログラマーのよくある妄想
749 :
デフォルトの名無しさん :2012/02/18(土) 18:51:40.90
ここで計算機科学に幻想を抱く患者さんの登場
>>747 言っとくけど俺は高卒じゃねーぞw
俺の格言「些細な夢は必ず実現する」
751 :
デフォルトの名無しさん :2012/02/18(土) 22:10:33.81
夢語りはいいのだが、最低限、「何をしたいのか」を言ってほしい。あとその目的も。 単に「数学を使えば何か凄いことができるぞ」だけなら、全く不毛。続きは数学板でやってください。
最低限は、Lispのマクロが出来て、ネイティブコンパイラとして複数の型や文字列、 ポインタ操作が一通りできるようにすること。 これは今年中に完成するのが俺の目標。 今年中が無理なら2、3年で完成させたい。 今の作業は、複数の型をコンパイラに入れる事。 作った言語で作りたいのはゲームだったり、言語だったり、ウェブアプリだったりする。 目的はC言語の層をCのような関数型言語(Scala)でパターンマッチを使って 奇麗に実装することだ。 S式の代わりにC式を使ってプログラムをデータとして扱いLisp級マクロも入れる。 この辺の仕組みはすでに出来てる。 式を使う事で構文上の大きな方針が決まる。 新しいC言語はC++のように拡張出来る必要がある。 だから十分検討した上で構文を決める必要がある。 フロントエンドとバックエンドは別に考える事が出来る。 バックエンドが嫌になったら気晴らしにシンタックスを考えたりしたい。 で、多分どっかの時点で誰かにパクられて、世に広まれば十分だ。 それが俺の手で出来たら大満足だ。
753 :
デフォルトの名無しさん :2012/02/19(日) 02:32:44.40
数学は好きなんだけどさ、大学以降のはちゃんと勉強してなくて
記号ばっかりになって分野も凄い広がるじゃん
記号だけ難しくて実は簡単?って思うと中身も難しいじゃん
ゆっくりしか進まなくてさ。やっぱりガチの数学にはコンプレックスがあるのよ
>>745 それも面白いな
>>752 あんまり魅力を感じないな。言語として新しいのを作るってよりも
自分だけのコンパイラを作ってみよう!っていう日曜プログラマ的な動機?
あと実装の楽さってだけなら関数型言語じゃなくて、PEGでいいんじゃないの?
>>753 高校卒業レベルまでの数学はただの算術だって中学の先生が言ってたお
>>745 Cの目的はプログラムの変形ではない
全く逆だ
プログラムの変更なしで移植するのが目的
>>755 Cを再開発してもしょうがあるまい。
その方向性はCやC++やDに任せておけばいい。
値が同じかどうかは判定できないから、型が同じかどうかを判定している。 型は「値より弱い」概念だから「強い型付け」などと言っても高が知れている。 これが数学。
>>753 誰もお前が数学得意だと思っていないし、お前が数学コンプレックスなんだろうことはみんな分かってるから安心しろ。
lispベースのクズ言語じゃC/C++に代わるはずねぇよw
まあ、
>>752 が逃亡しなければ、今年中に完成まで行かなくても、ある程度具体的な仕様は見えるだろうから、
クズと判断するかどうかは、それを見極めてからでもいいだろう。
このスレはこのスレで、
>>752 とは別に粛々と進めればいい。
>>758 そういう根拠のない思い込みは全く数学ではないし、科学ですらない。
文学か宗教だ。
>>762 値が同じならば型も同じ。
型が同じでも値が同じとは限らない。
これが根拠。
>>753 日曜大工で造れるくらい簡単にすることはとても大変な作業なのですが、
アインシュタインは日曜大工で相対性理論を作ったのです。
Cのマクロを奇麗にすることが1つの目的です。
低レベルな言語にマクロは不可欠です。マクロのないアセンブラは使い物になりません。
マクロ機能ですばらしいのがLispのマクロなのだから、Lispのマクロがあると便利です。
Lispのマクロを実現するにはC言語の言語一族を一般化した式があると非常に便利です。
必要なのはC言語の言語族の良い性質を取り出したS式のような式言語です。
この式言語のパースは正規表現と下降型の演算子順位法が最も短く記述できました。
式を一度構文解析してただの、構文木を作ると演算子で繋がれただけのデータとして扱う事が出来ました。
木を別な木に変換作業がコンパイラの仕事です。
これをどう扱うと奇麗に書けるか調べていくと、関数型言語が良いことが分かりました。
しかし、私が考えているC言語には似ていないのでC言語風な関数型言語を探しました。
結果としてScalaが最もC言語に近い関数型言語であることが分かりました。
パターンマッチは要するにvisitorパターンを言語機能として持っているということでした。
構文解析にとどまらず、コンパイラ全般の記述がきわめて簡単に出来たのです。
今はバックエンドを作っていて動くものが完成したら、シンタックスをいじったり、
GCを追加したり、最適化したりしようと考えてます。
>>763 /: : : : : __: :/: : ::/: : ://: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ ___
/;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::、 / ヽ
/ヽヽ: ://: :!:,X~::|: /;,,;,/: :/ リ!: ::/ノ l`ヽl !: : |: : : :l: :l: リ / そ そ お \
/: : ヽヾ/: : l/::l |/|||llllヾ,、 / |: :/ , -==、 l\:::|: : : :|i: | / う う 前 |
. /: : : //ヾ ; :|!: イ、||ll|||||::|| ノノ イ|||||||ヾ、 |: ::|!: : イ: ::|/ な 思 が
/: : ://: : :ヽソ::ヽl |{ i||ll"ン ´ i| l|||l"l `|: /|: : /'!/l ん う
∠: : : ~: : : : : : : :丶ゝ-―- , ー=z_ソ |/ ハメ;, :: ::|. だ ん
i|::ハ: : : : : : : : : : : 、ヘヘヘヘ 、 ヘヘヘヘヘ /: : : : : \,|. ろ な
|!l |: : : : : : : : :、: ::\ 、-―-, / : : :丶;,,;,:ミヽ う ら
丶: :ハ、lヽ: :ヽ: : ::\__ `~ " /: : ト; lヽ) ゝ
レ `| `、l`、>=ニ´ , _´ : :} ` /
,,、r"^~´"''''"t-`r、 _ -、 ´ヽノ \ノ / お ・
,;'~ _r-- 、__ ~f、_>'、_ | で 前 ・
f~ ,;" ~"t___ ミ、 ^'t | は ん ・
," ,~ ヾ~'-、__ ミ_ξ丶 | な 中 ・
;' ,イ .. ヽ_ ヾ、0ヽ丶 l /
( ;":: |: :: .. .`, ヾ 丶 ! \____/
;;;; :: 入:: :: :: l`ー-、 )l ヾ 丶
"~、ソ:: :い:: : \_ ノ , ヾ 丶
cのコンパイラくらいちょちょっと作れよwww。まっさら状態から一日でできるぞ 関数型言語って何をいまさら。勉強したいわけだな コード全部晒したらアドバイスするよ
無意味な煽りは無視していい。 年末までじっくりやれ。 出来たら、出来たでこのスレで評価すればいい。 今はまだ何も無いので評価に値しない。
>>766 includeをimportに置き換えただけ、みたいな等価な変更なんざ何の価値もないの。
1日でできようが1秒でできようが無意味。
新言語なんてやる意味ねえよ。 やるならC/C++の上位互換にしとけ。 速度と言語は関係ないし。 C/C++の互換だったら膨大なコードを利用できるし。 関数型やGCが好きだったらC/C++に組み込めばいい。
770 :
デフォルトの名無しさん :2012/02/19(日) 20:26:58.54
速度と言語は関係ないし。 速度と言語は関係ないし。 速度と言語は関係ないし。 速度と言語は関係ないし。 速度と言語は関係ないし。
言語と、言語に付随するコンパイラは分けて考えろよ。 JavaやC#はC++より遅いっていうのは定説だろうが、 仮想マシーン不要で動作する実行ファイルを生成するコンパイラが出来れば C++を超える可能性はある。
773 :
デフォルトの名無しさん :2012/02/19(日) 20:38:35.39
IntelがPentiumの回路技術でjavaチップ作れば余裕で超えるでしょ。
774 :
デフォルトの名無しさん :2012/02/19(日) 20:51:13.56
>>771 おいおい、コンパイラに与えられるヒントの量が違うだろ
そこらの普通の言語だと似たりよったりだろうけど
きっとJVMをハードウェアチップ化すればいい、と言いたいんだろうな。 で「JVMがハード化されること」は「一般論として言語と速度が無関係ではないこと」の反論になるのか?
>>772 gcjも知らんででかい口を叩かないでもらおうか
はい、わかりました。
速度は言語でなくコンパイラの性能、最適化次第。 GCCやVC++やインテルC++では速度差があるだろ。
言語によって、コンパイラが性能の出しやすさ、最適化のしやすさに違いは当然ある。
GCとポインタをなくせば速くなると思う。 そのためにはコンパイラを変えるより言語を変えるのが簡単だ。
>>780 gcもポインタもあることによって速くなるんだけどね。
ポインタでデータコピーのオーバーヘッドを削れる
gcによって逐次解放のオーバーヘッドを減らし、後でまとめて解放する際に
賢いアルゴリズムを用いる事ができる。
782 :
デフォルトの名無しさん :2012/02/19(日) 22:16:10.75
ちいせえレベルで語ってんじゃねえよ 速い言語なら、c++もしくは人力アセンブラより速くないと意味が無い 使いやすい言語なら、C#より使いやすくないと意味が無い
>>782 レジスタ、一次キャッシュ、二次キャッシュ、HDD、のそれぞれの速度差
パイプラインの隅々までクロックサイクル単位で考慮する
最適化人間の俺様による人力アセンブラより早いのは無理。
>>781 関数はコピーも解放もしないから、関数ポインタはないほうがいい
Singletonもコピーしない
コピーしないものは結構多い
だめだこりゃ Singletonはポインタを各所に持つことで実体を共有してるんだぜ。ポインタが無かったら成り立たない。 関数のポインタも必須。
>>778 言語仕様の影響がないなんてありえないよ
例えばC言語ではポインタがあるから
別名解析が極めて困難になっている。それに伴って
最適化も限定的にしかできなかったりする
Intel C/C++も解析できない部分はプラグマや拡張構文に頼る
一方でポインタはCの強力な武器であって
むしろポインタを使って手作業で最適化という事もよく行われる
コストはかかるが、それが実現できるというのがCの偉大な所
どちらを取るか、あるいはどうバランスさせるかというのは難しい問題
理想的には、コンパイラの最適化が効きやすいが、
そうでないケースも必要があれば手作業で「なんとかなる」のが良い
>>785 具体的にどこでポインタが必須なのか分かってるなら、
それ以外の場所で、ポインタがいらない所が結構多いってことも分かるだろ。
>>786 どうもヴィルト先生が、「最適化の話と言語仕様の話を混同しちゃいかんよ」と言ってるらしいのだが、
それをどうも拡大解釈して、言語仕様は最適化に関与しない、と誤解してる人がいるらしいのだ。
789 :
デフォルトの名無しさん :2012/02/20(月) 00:23:53.91
最適化というのはプログラマーの意図により近づけることだから、 最適化に適した言語仕様とは、プログラマーの意図をより正確に記述できるものである。
そんなことはないと思うけどね 最適化は単に与えられたアーキテクチャの都合に合わせてプログラムを変形するだけ レジスタが今何個使えるかとか、Cレベルですらほとんど意識しなくても 悪くない効率のプログラム書けるでしょ 最適化コンパイラはグラフ彩色法とかを使って頑張るわけだが、 そこにプログラマの意思はない
ポインタ必須厨はもっと勉強したほうがいい 速度重視のためにポインタを使用しない言語を作れないこともないだろ
792 :
デフォルトの名無しさん :2012/02/20(月) 05:00:43.49
>>783 おいおい、お前visual c++の浮動小数点の最適化に勝てるか?
有る程度長いコードな。マジ無理だから
793 :
デフォルトの名無しさん :2012/02/20(月) 05:02:21.39
C++のコンパイラがキャッシュに収まらないから自動的にブロック化とかするか? fortranならできる。言語による速度の違い
LLVMがあるからもういいだろ
795 :
デフォルトの名無しさん :2012/02/20(月) 08:34:32.99
コンピュータによる最適化はな、ちゃんとヒントさえ与えてあれば人間よりも賢くやるんだよ それこそ、パイプラインだのなんだのって最近のCPU人間が把握するには複雑すぎんじゃん でもなんで人間がコンピュータに勝つかって言えば、アセンブラを見て何をやっているコードが分かるからなんだよな 一歩引いた視点から最適化できる コンピュータにうまくヒントを与えることさえできれば、人間が勝てなくなるかも そういうコンテスト開いたらどうかな。最適化コンテスト チェスみたいにさ コード食わせて最適化して実行速度で勝負 世界中のハッカーが手書きアセンブラで乱入 人間vsコンピュータっていうさ
> 最適化というのはプログラマーの意図により近づけることだから、 前提がそもそもおかしい。てかバカか? プログラマの意図から一切外れてはいけない、というのが処理系における大前提。 そのうえで、可能であれば効率の良いコードを生成する、というのが最適化。
797 :
デフォルトの名無しさん :2012/02/20(月) 08:43:16.54
とらんすぺあれんしーな
798 :
デフォルトの名無しさん :2012/02/20(月) 09:17:06.90
最適化で最適になると勘違いしている奴が多すぎ。何人バカを見たことか。 せいぜい「快適化」が妥当。
↑C言語を「高級アッセンブラ」とか称して、プログラマはアセンブリ言語を意図して書くべき、 とか思ってるバカ?
LLVMで実行時のプラットフォームに合わせてコードを変更すべきだ 例えばCPUのプロセッサ数、コア数、NumaなのかSMPなのか、などなど アセンブラで禁じ手とされてきた自己変更コードが今や管理できる対象に
コンパイラのコード最適化も、CPUの仕組みとかを利用した 手作業の最適化をする職人さんから見たら大したレベルでは ないよ
>>799 でも、ここはそういう趣旨が含まれているスレだろ
スレタイ的に
>>801 NP完全問題解決職人の朝は早い、っていうギャグですかそれはw
>>802 そういう趣旨ならANSI標準化以後のC、ましてやC++なんて目もくれないはず。
C言語の欠陥として、マシンスタックに触れないとか、関数をまたぐgotoができない、
といったことを把握していて、gcc拡張などでそういう制限を突破する方法を熟知。
まずはそういうレベルに達してから四の五の言えと。
>>795 チェスは人間対人間のデータがヒントになってるんだろ
まず人間だけでデータを蓄積するべきじゃないか
>>803 NP完全問題だから何?
人の創造力でコンパイラができない最適化が可能だと考えられないの?
そもそも、保守的なコンパイラの最適化なんて人が直接行った最適化に勝てるとか思ってるの?
806 :
デフォルトの名無しさん :2012/02/20(月) 18:05:12.99
>>805 だからお前はずるしてんだよ。コンパイラはお前よりずっと少ない情報量で頑張ってる
そこでだよ、コンパイラにも同等の情報を与えられないかって考える
openmpとかはさ情報与える手段のひとつよ。でもしょぼいじゃん
アルゴリズムを創造するレベルにはいたらないじゃん
なんか新しいの考えようぜ
807 :
デフォルトの名無しさん :2012/02/20(月) 18:06:27.04
>>804 おう、人間がアルゴリズムを考えるときにやることっていうのを書き連ねてみるのな
そこにヒントがあるかもしれない
コンパイラのコード生成に乗らないようなすごい命令作りましたー、っていうCISC原理主義者ですかw
コンパイラよりもアセンブラ手書きの方が速いなんてアタリマエのことだろ まあ、有名な本とかでも誤解させるような言い回しをしていることも多いけど アセンブラがコンパイラのコードに負けるなんて、C言語がJavaより遅いという のと同レベルの議論だぞ
お前のレベルが30年前
お前こそ、本とか人の話を鵜呑みにして信じているだけ いまでもアセンブラが最速
実行プロファイルを利用した最適化を超えるほど 完璧に最適された手書きアセンブラを想定するなら速くてアタリマエ
利用できるものは全部利用しないと完璧とはいえないな
費やす時間が無限なら人間が最強に決まってる
えー時間は無限でも寿命は有限じゃん・・・とくだらない揚げ足をとってみる
揚げ足にすらなってないな。会話が通じないやつ
速度と言語は関係ある。 だから機械と人間は連携している。勝負しているのではない。 ただ、連携を意識させるべきではないという透過性の思想もあって それを誤解して、連携してないし強い方だけが生き残ると思ってる人がいる。
連携、というのは対称性があって良い みんな抽象とか具象とか言うけど非対称で気持ち悪い
819 :
デフォルトの名無しさん :2012/02/21(火) 20:03:23.73
大工が屋根は始めからあるべきというようなもの そりゃー仕事なくすだろ
一階の屋根は二階の床
ドメイン固有型を構築する記法
超高速BASICインタープリターの復活まだ? 見た目は中間言語方式だが解読などせずに、中間言語バイナリーが 実行CPUの命令語で直接表現されているタイプだ。 つまりアセンブラと同等の速度で動く。
でかい釣り針だな
いるんだよ、天然でこういうバカ
Implicit conversion is difficult now...
clay, cyclone, decac, rust, bitCといったsystem programming languageを標榜しているものが沢山勃興している件について。 このスレじゃるrust以外は言及もされてないが、需要はあるんだと思うよ。
827 :
デフォルトの名無しさん :2012/02/25(土) 16:20:26.20
以前のスレで言及されてたよ
828 :
デフォルトの名無しさん :2012/02/25(土) 16:24:37.06
つまり動作だけじゃなくて、CPUに与える命令までをも自由にいじくれる言語か Cで表現できるプログラムと、アセンブラで表現できるプログラムの集合は同じだけど 生成される命令列の集合は一致しない それを一致させて、しかも書きやすい言語か
829 :
デフォルトの名無しさん :2012/02/25(土) 17:01:33.96
それを抽象的にプラットフォーム依存性なく記述できれば尚いい。
830 :
デフォルトの名無しさん :2012/02/25(土) 17:08:18.07
>>828 同じじゃねえよ全然
反論は UNIX を完全に C だけで書いてからぬかせ
831 :
デフォルトの名無しさん :2012/02/25(土) 17:21:38.31
832 :
デフォルトの名無しさん :2012/02/25(土) 17:25:02.85
集合とか言いながら定義の曖昧な意味のよくわからない書き込み
プラットフォーム依存性なく記述出来るのは その下(処理系)で吸収する手があるけど、それは最大公約数的になってしまう そして溢れた部分は同階層(ライブラリ)で吸収したりするよね そんで、ライブラリに出来る幅を広げるため コンパイル自体に介入して言語を拡張する機能を内包してるといいと思う 例えば「ソース内にインラインアセンブラを書けるようにする」処理を書けるとか lispとかはそんな感じのこと出来るんだっけ? //その言語で関数とか書いて void asmPlugin(Compiler cp){ cp.getParser().addBlockKeyword("_asm", new AsmParse() ); } //コンパイラに取り込んでもらうと compile_plugin asmPlugin; //拡張構文が書けるようになるとか _asm{ ... } この場合、asmPlugin関数がコンパイル途中で実行可能になる必要があるから ブートストラップ問題にならないよう、ファイル分けたりフェーズ分けたりするのが必要だと思うけど
>>833 ファイルを分けるのは既存のやり方と同じ。
cのファイルとasmのファイルに分けるなら拡張構文は不要だ。
逆にファイルを分けないとすると、Pascalはそんな感じだっけ
今はCPUの保護機能のせいで、データと命令が分離されてデータを 命令として実行できないとか聞いたことあるような気がする
837 :
デフォルトの名無しさん :2012/02/25(土) 18:57:22.09
function test(a: Integer): Integer begin Result := 2 * a; end; function test(a: Integer): Integer asm add eax, eax; end; で終りやで。すばらしいのよ 前後に追加されるのは、retのみ
分割はカッコ悪いという価値観が、ある程度普及しているのは間違いないと思うが いつどこから広まったんだろうか
>>834 ファイルを分けるってのはコンパイラ用プラグイン部分のことね
例えばC言語ならCで、JavaならJavaで記述出来て、
先にコンパイルされてコンパイラにプラグインとして入りこんで
メインのソースのコンパイルする際に動くってことで
別途拡張したコンパイラを用意しなくても
その言語自身で、コンパイル時に言語をある程度拡張出来れば
別途コンパイラを用意する必要もなく、
boostみたいにプリプロセッサを酷使せんでも色々出来そうだし
VC++とgccで独自のインラインアセンブラ機能付けなくても
boost作成メンバーみたいなのが作ったソースとかをincludeするだけで出来るとか
言語仕様を変えることなく、後付けてリフレクション機能を付けたりとか
いや、言語設計とか初心者レベルなんだけどね
そんなこと出来たらいいな的な
何か2回ほどコンパイラを用意とか言った気がするけど脳内添削してください
つまり、言語自身で想定した環境の外に別途環境が用意され言語が酷使されるような ことが起きないようにするのが目標か
842 :
デフォルトの名無しさん :2012/02/26(日) 01:09:27.03
面白いな、コンパイラコンパイラ と コンパイラを一緒にしちゃうのか? 冒頭に言語仕様を書いておくっていう それをフレキシブルに拡張できるっていう
それって、lisp系の言語のマクロじゃね
マクロみたいな制限やデメリットがない
マクロだって原理的にはチューリング完全だよ
846 :
デフォルトの名無しさん :2012/02/26(日) 08:16:38.55
とおりすがりでごめんなさいね >4 に書かれている名称は随分昔に PL/I って言語で存在してますので不都合が生じるかもしれません
>846 >3-8 のテンプレ自体がネタだからw
848 :
デフォルトの名無しさん :2012/02/26(日) 13:49:29.74
c言語のコンパイラをlispのマクロで書けたりするの? lispのマクロ使ったことないからわからん
849 :
デフォルトの名無しさん :2012/02/26(日) 13:53:18.31
コンパイラを書くことが目的ではなく C言語のソースとLispのソースを一つのファイル内に書くことが目的なのだと思うよ
>>846 こんな頭の悪そうなスレを立てたり、ハシャいでぼくのかんがえたさいきょう言語を
披露しちゃうような奴は、たいてい過去を学んでいないものだ。
まあいいじゃないか視野と行動力は反比例の関係であるみたいだし。
854 :
デフォルトの名無しさん :2012/02/28(火) 00:18:09.34
>>846 Programming Language I は「あいげんご」あるいは、単に「あい」と呼ばれる。
PL/Iは「ぴーえるわん」と呼ぶから困ることはないよ。
何その錆びた釣り針
急増する「女ネット右翼」の背景
昨年8月の「フジテレビデモ」の頃からでしょうか。
現実のデモだけではなくネット上でも、こうした「ネット右翼」と呼ばれる層に明らかな変化(それも「急変」と言ってよい程の大変化)が起こりました。
具体的に言えば女性、それも特に子供を持つ既婚女性の急増という大変化です。
韓国朝鮮人への敵意や嫌悪感、それも「もうとにかく嫌! 生理的に受け付けない!」とか「韓国人は近付かないで! 気持ち悪い! 吐き気がする!」といった類の、
私のような男性とは明らかに異なる、極めて生理的・感覚的なレベルでの韓国・朝鮮人への嫌悪感を剥き出しにした投稿が急増しているように思えます。
それにしてもなぜ急に、ここまで日本人女性の韓国・朝鮮人に対する嫌悪感が盛り上がってきたのでしょうか。昨年の「高岡蒼佑のツイッター」騒動が
発端になっていることは間違いありませんが、それはあくまでも一つの「きっかけ」に過ぎず、そこに至るまでには長い不満の積み重ねがあったものと思われます。
「人権擁護法案が通ると、日本女性が韓国男達・在日韓国男達からレイプされて明らかに犯人が分かっており警察へ訴えても
『俺が在日韓国人・韓国人だからそんなことを言うのだろう!』
と言われたら、日本の警察も司法も社会も一切韓国男達・在日韓国男達に手出しは出来ず、レイプされても単なる泣き寝入りになると。
要するに日本女性の訴えは完璧にレイプ犯が分かっていても完全無視され、韓国男達・在日韓国男達が徹底的に無罪として日本で守られると。
日本社会は韓国男達・在日韓国男達が日本女性を合法的に好き放題レイプすることが出来てしかもそれが罪に一切問われない社会になる」
迂闊でした。
確かに彼女らの怯えるとおり「人権侵害救済法案(旧名『人権擁護法案』)」が万々一にも成立してしまった場合、
真っ先にその犠牲になるのは彼女たち日本人女性なのです。
そして世界一日本人女性に妄執する韓国男どもは「法律が出来たら、日本女を強姦し放題だぜヒャッハー!!」とばかり、股間を膨らませ、
涎を垂れ流しながら法案成立の時を今か今かと待ち構えているのです。
http://ameblo.jp/issuikai/entry-11170747316.html
一水会大丈夫か? もはや沈没しつつある「行動する右翼」たちに巻き込まれて沈んじゃうぞ、気をつけないと。
858 :
デフォルトの名無しさん :2012/03/02(金) 20:59:27.69
広まることはない 「C系の言語に慣れたユーザー」にとって変換されたコードは可読性が悪すぎる
860 :
デフォルトの名無しさん :2012/03/02(金) 22:30:15.06
まあC++1xがあればいいか
861 :
デフォルトの名無しさん :2012/03/02(金) 22:31:19.17
次はもっとこの関数型のパラダイムをふんだんに盛り込んで欲しいな
関数型と手続型は混ぜると可読性が落ちるから もうお腹いっぱいだわ
関数言語厨は、関数言語自体は大昔からあるのに どうして広まっていないのか考えたほうがいいよ
反原発左翼と一緒だな
原発右翼の方が頭おかしいだろ
自然エネルギーは広まってない広まってない、と呪文のように繰り返す、 原発脳と同じですね。
関数型言語は、処理を単一の値を媒介しつつ記述しなければならない。 手続型言語は、処理を機能として記述する。 C/C++は処理の記述が目的なんだから そういう目的ならば、関数型言語が劣るのは自明。 関数型言語はそもそも目的が異なるのだから 無理に混在させたり置き換えたりするものではない。
HaskellはC++と同じくらい使いにくい OCamlはC++より使いやすい
無理に混在させるんじゃなくて、奇麗に統合されていると嬉しい。 マクロ自体は関数型であろうがなかろうがあったら便利だ。 型推論もあったら便利。 パターンマッチングもあったら便利。 immutableな変数もあったら便利。 末尾再帰最適化もしてくれたら嬉しい。 便利な機能がそろっていつつ、作りが簡単で高速に動いたら最高だ。
871 :
デフォルトの名無しさん :2012/03/05(月) 16:57:55.17
末尾じゃない再帰もアンロールしろよ横着しねえで
PL/Iのスレ?
もう、Camlと強力なプリプロセッサがあればいいんじゃね。
全ての再帰はループに置き換えられる。 末尾再帰最適化だけなんて思考停止も甚だしい。
>>874 中間結果どこに置く気だ?
その場でスタックもどきを作るような変換は「最適化」とは呼ばん。
874じゃないけど void f(int n){ if(n<=0){return;} int* p = new int(n); f(n-1); delete p; } ↓最適化 void f(int n){ for(; !(n<=0); n--){ int* p = new int(n); } } 富豪的最適化 メモリは16EiBあって当然
>>875 まあそんなに顔真っ赤にするなや。
Cやjavaに言えることで他の言語の事は知らないけど
関数呼び出しのオーバーヘッドは10回ループするよりデカイ。
>>876 解放し忘れてるし。
878 :
デフォルトの名無しさん :2012/03/05(月) 21:21:58.28
実際、テンプレートの再帰とかあるわけだし // スタックがどうたらって、アンロールの本質が見えてねえな
879 :
875 :2012/03/05(月) 22:23:04.05
>>876 スワップで死ねるよね…てか、中間結果いらん例やん(´・ω・`)
>>877 >まあそんなに顔真っ赤にするなや。
別に。何? 否定されて悔しかった?
>関数呼び出しのオーバーヘッドは10回ループするよりデカイ。
気のせい。
880 :
ループ厨 :2012/03/05(月) 23:52:29.99
うへ、再帰厨ってのが確かに存在する事がわかった。
後学のためにクイックソートをループでやってみてくれ。
再帰はループに置き換えられる。
夢のような欲張り言語がリリースされたらしいよ。julialangでググると出てくる。
すべての再帰をループに置き換えるのは難しいだろ
885 :
デフォルトの名無しさん :2012/03/06(火) 06:27:49.49
えっ
泣きながら実験したら再帰と互角だった。ただしループの方は改良してある。 ループ time=172 (10000個のランダムの数字を100回ソート) 再帰 time=188 (10000個のランダムの数字を100回ソート)
再帰 public void quickSort(int[] a,int left,int right0){ int pivot=getPivot(a,left,right0); int right=right0; right=group(a,left,pivot,right); if(left+1<right && right!=right0)quickSort(a,left,right); if(right+1<right0)quickSort(a,right,right0); }
ループ public void loopQuickSort(int[] a,int[] arm){ int left=0; arm[0]=a.length; int depth=0; int pivot; while(true){ int right=arm[depth]; if(verbose)System.out.println("["+left+","+right+"]"+depth); if(left+1<right){ pivot=getPivot(a,left,arm[depth]); right=group(a,left,pivot,arm[depth]); if(verbose)show(a); if(verbose)System.out.println("pivot="+pivot); } if(left<right && arm[depth]!=right){ depth++; arm[depth]=right; }else{ left=arm[depth]; depth--; if(depth<0)break; } } }
これらが呼んでいる共通の関数 public int getPivot(int[] a,int start,int end){ int pivot=0; for(int i=start;i<end;i++){ pivot+=a[i]; } return pivot/(end-start); } public int group(int[] a,int left,int pivot,int right){ for(int i=left;i<right;i++){ if(a[i]>pivot){ if(i==right-1 && a[i]<a[right-1]){ right++; break; } int n=a[--right]; a[right]=a[i]; a[i]=n; i--; } } return right; }
すまん再帰の方がかっこ悪かったのでリファクタリング public void quickSort(int[] a,int left,int right){ int pivot=getPivot(a,left,right); int middle=group(a,left,pivot,right); if(left+1<middle && middle!=right)quickSort(a,left,middle); if(middle+1<right)quickSort(a,middle,right); }
891 :
876 :2012/03/06(火) 10:03:14.42
動かしてないコードを溜め込むやつは強力な静的型付けを欲しがる 溜まる前に動かすやつは動的型付けで満足できる
すみませんコードが冗長でした。 public int group(int[] a,int left,int pivot,int right){ for(int i=left;i<right;i++){ if(a[i]>pivot){ int n=a[--right]; a[right]=a[i]; a[i]=n; i--; } } return right; }
動かすコードならideoneに貼れよ
896 :
デフォルトの名無しさん :2012/03/06(火) 16:24:49.22
再帰をループに置き換えただけではアンロールになってない ループの回数を特定してインライン展開までやらないと中途半端だ
一番重要なのはスタックを片付けるかどうかだろ
898 :
デフォルトの名無しさん :2012/03/06(火) 17:15:47.81
そんなのプロローグとエピローグに全部まとめるだけ
899 :
デフォルトの名無しさん :2012/03/06(火) 19:53:03.45
組み込みやってると再帰なんて怖くて使えない
900 :
デフォルトの名無しさん :2012/03/07(水) 01:17:49.55
じゃあ使うなよw
901 :
デフォルトの名無しさん :2012/03/07(水) 10:30:16.97
合理的な理由があって使わないのは自由なんだが、グローバル変数を多用する理由付けとか として「再帰使わないから」とか言い出す奴がいたりするのがこの業界の厄介なところ。
「コンパイルが通れば安全」と言う奴と 「コンパイラが許しても俺は許さない」と言い出す奴が同居しているのが厄介だな
コンパイルが通っただけじゃぜんぜん安全じゃない、ということがわからない奴がいるからな。
904 :
デフォルトの名無しさん :2012/03/07(水) 18:56:06.72
通ったか通っていないかの区別もつかないアホ多いしな
コンパイルが通ることと安全かどうかは全く別の話だからな
そもそも安全じゃない奴と同居しているのが問題だからな。
907 :
デフォルトの名無しさん :2012/03/07(水) 19:39:58.86
洩れ、Vzのマクロっぽい言語でバイナリ吐く perlスクリプト使っているけど、 ちょっとしたDOS向けCOMファイル作るのには便利〜♪
908 :
デフォルトの名無しさん :2012/03/08(木) 14:13:33.93
言語仕様から書けるっていうメタ言語が欲しいな そして言語同士をフレキシブルにつなげられるのよ 言語仕様と中身が混在してる。というか本質的に区別がつかないようなエレガントな言語をさ
悪くは無いと思うけど、 混在している時点でエレガントじゃないだろ。
910 :
デフォルトの名無しさん :2012/03/08(木) 19:05:39.56
>>909 人間が見ると混在してるように見えるけど、コンピュータ側から見ると言語仕様の定義も実際のコードも同じルールで裁くのよ
全ての言語を表現できる最強の言語みたいな感じ?
911 :
デフォルトの名無しさん :2012/03/08(木) 19:22:03.74
>>833-845 のあたりの話をさらに汎用にした感じか
でもあまり広げすぎるとコンパイラ作成ツールキットだけ渡されそうなw
伝統的にはyacc/lexとかの守備範囲ですね。 文法を定義して、ある言語を別の言語に翻訳する、 というシステム自体が実はチューリング完全だったりします。 (あまり「低級」な話ではないので、ややスレ違いか…)
913 :
デフォルトの名無しさん :2012/03/09(金) 01:53:58.62
構文解析はコンパイル時の処理だから実行時の性能に影響を与えない点で低級と言えるし 言語自体をアセンブルする点でも低級と言える(メタ言語と言ってしまうと高級な感はあるが)
boost/spiritの出番ですね
ノScalaとパーサコンビネータとコンパイラプラグイン
916 :
デフォルトの名無しさん :2012/03/10(土) 19:08:38.12
それらをどう整理・再設計するかだな
そろそろプログラミングはコンピュータにやらせないか? 人間はミスが多すぎる。
918 :
デフォルトの名無しさん :2012/03/12(月) 00:13:43.58
できるならそうしたい プログラミングめんどい
では人間様は何をすればよろしいか
アニメ、映画みたいなことが今出来るとでも言ってるのかね?917は
>>917 スレタイによれば、このスレの目的は、高速に実行すること。
プログラマが楽をすることではない
922 :
デフォルトの名無しさん :2012/03/12(月) 01:49:17.09
いかにも中二な発想だよな。
プログラマが楽をすることをめざしているのは、Rubyだ
誰かRubyのコンパイラ書いてくれ。VMとか使わないで動くやつ。そしたら本気で使う。
926 :
デフォルトの名無しさん :2012/03/12(月) 12:50:42.58
>>917 そろそろって今までどうだって言いたいんだ?
昔、コーディング用紙でハンドアセンブルしてて確かにミスが多くて困った
それでアセンブラを自作とかはしたぜ
コンパイラがあってアセンブラがないという変な環境でもアセンブラを自作した
コンパイラが出力するバイナリに不満だらけだったからだ
人力と機械化は相互補完的なものってことだ
最近、ネイティブなバイナリを吐く言語が減ったね
減ってはいないだろ 他が増えたから割合が小さくなってるが。
ABIがうざいからVMの割合が大きくなる ABIをうざいと思わないやつは多分C言語に慣れていて不満も感じていない
プログラミングをコンピュータに任せられるようになると プログラミングで食ってる人はむしろ苦しくなる気がするw
931 :
デフォルトの名無しさん :2012/03/12(月) 18:43:27.29
C に慣れると ABI に無関心になるって? それは C に慣れたんではなく単一 ABI で いつもまっさらのシステムに慣れただけだろ 慣れたというより、その域を出られないままとでも言うべき
>>930 設計とテストだけ書いて、あとは全部おまかせ出来たら超便利そうなんだが。
933 :
デフォルトの名無しさん :2012/03/12(月) 19:03:19.52
機: エラー。その設計は矛盾している。 機: エラー。テストが発散している。 機: エラー。○月△日までに修正しろ。 人: まさか、そんな・・・ 機: 交信終了。
>>931 最初の一つに慣れるのが大変なんだよ
二つも三つもあって困るというのは、技術的にはかなり慣れていて
政治的な問題に関心が移っている
935 :
デフォルトの名無しさん :2012/03/13(火) 00:54:04.56
>>921 ハードワイヤードではなく、わざわざ言語を作(ってソフトウェアを作)るというだから、当然楽をすることを指向している。
C程度に高速な用途に用いることが出来、Cより楽にプログラミングできる言語を目指す。
936 :
デフォルトの名無しさん :2012/03/13(火) 01:00:43.00
今ある言語だとどれがスレタイに近いの?
937 :
デフォルトの名無しさん :2012/03/13(火) 01:02:21.87
MASM?
938 :
デフォルトの名無しさん :2012/03/13(火) 01:03:27.82
C
939 :
デフォルトの名無しさん :2012/03/13(火) 01:05:54.53
システム開発の効率化なら仮想化だろ。低級言語なんてもう要らないわ したっぱがやってりゃいいんだよ
>仮想化 ?
941 :
デフォルトの名無しさん :2012/03/13(火) 12:12:14.27
「おまえ、これ作っとけ」
943 :
デフォルトの名無しさん :2012/03/13(火) 13:10:39.85
いまどきなんでもlinux動くじゃん。Cで十分じゃん
>>935 ネイティブならC程度に高速だわな。C#とかJavaだってGC以外はC程度に高速
必要性を感じない
プログラムの全部を最適化する必要ってほとんど無いんだぜ?
一部なんだよ。そこはガチでアルゴリズムからアセンブラまで見直して最適化すればいいの
まあ、これも本当はしたっぱがやればいいんだけどな
944 :
デフォルトの名無しさん :2012/03/13(火) 13:41:36.70
マトモな書き方してたら遅くてダメだったときに アブノーマルな書き方で速度を稼ぐのは下っ端には荷が重すぎるだろ ここで言う下っ端とはスキルが低い者のことで 下流工程を専門に引き受ける人のことではない
>>944 そんな俺様辞書の俺様用語を説明されても
不要な知識だからな
>>944 > ここで言う下っ端とはスキルが低い者のことで
日本語の辞書には無いけど、それは何言語?
947 :
デフォルトの名無しさん :2012/03/13(火) 14:00:25.22
全部したっぱがやればいいんだよ。俺は書類にはんこを押すだけな
遅延評価ならぬ遅延設計 その機能が必要になる直前まで設計・実装しない これさえできれば 「機械に大まかに指示を投げる」だけですむ
ホンバン方式として日本の主力商品に育てよう
「電池は韓国より日本が優秀」 米テスラのケルティ氏
EV(電気自動車)スポーツカー「ロードスター」で一躍脚光を浴びた米国のテスラモーターズ。
今年、第2弾としてEVセダン「モデルS」も発売。全世界で9千台以上を受注した。
EVの心臓部であるリチウムイオン電池について、バッテリー技術部門を統括するカート・ケルティ部長に聞いた。
■韓国メーカーが車載用電池市場でも価格攻勢をかけているが、性能についての評価は?
「サムスンやLGの場合は、他社の商品をまねするのがうまいうえが、
ただ、技術優位性では、パナソニックはじめ日本メーカーの方がやはり高い」
■どういった点で日本勢の技術レベルが高いのか?
「日本メーカーは、高密度化など電池の性能を決定づける材料を深く知り尽くしている。
例えば、『電池の寿命が短くなったのはなぜか』との問い合わせに、すぐ対応してくれる。さらに、
材料の組み合わせによる電池の特性の変化なども深い部分で理解している。
一方、韓国メーカーに同じ質問をすると、『いろいろ試して、直すように頑張ります』となる。
材料に至るまで電池を化学的に理解しているという点で、日本は韓国メーカーより技術的に優位だ」
http://sankei.jp.msn.com/economy/news/120318/biz12031807000001-n3.htm
951 :
デフォルトの名無しさん :2012/03/20(火) 08:02:55.18
今日も朝からアッセンブリブリ
やはリアセンブラ最強だな
リアセンブラ
ただのアセンブリはつらいので型と式とブロックを追加しました。
名前はCでいいかな
⊂⊃∪∩cUCつっСс
目の検査か
ということで、型推論を理解しよう。 その前に、パターンマッチングとユニフィケーションを理解しよう。 ユニフィケーションのもっと簡単な説明が今必要。
Window window; Size* p = window.GetSize(); int w = p->width; int h = p->height; この参照pをdeleteしていいのかわからんのがC++の嫌なところ。 メンバ変数の参照である可能性もあるし、オブジェクトプールに返す 必要があるかもしれない。GetSize()内で返り値に対する deleteの振る舞いを変えられれば参照を取得した側にわかりやすい。
>>959 生ポインタなんか使うからそうなる。言語のせいじゃないだろ。
962 :
デフォルトの名無しさん :2012/04/13(金) 11:26:08.92
963 :
デフォルトの名無しさん :2012/04/13(金) 17:23:34.67
スマポとナマポの混在はいやれす
ナマポを見たらガッするスレ
ナマポ
>959 C++では参照とポインタは別もんだよ。
967 :
デフォルトの名無しさん :2012/07/01(日) 10:06:25.60
GC無しで循環参照って対応出来ないんだろうか
>>967 循環参照に対応する機構を作れば、それはGCと呼ばれることになるだろう
回収のタイミングが構文に対して不定でないという意味でってことね。 求めたのはstaticやglobal、ローカル変数などのルートノードから切り離された際に 循環参照があっても即時回収されるshared_ptrのようなもの。 もちろん大きすぎる計算量は無しで 例えばC#のusingやjavaのtry-finally-closeは、 (タスク/スレッド型の)GCのタイミングでは困るリソースの生存管理を行う手段(RAII)で、 GCは本質的にはメモリにしか対応していない
アウトオーダー式に計算結果を事前に格納して、 あれはあれ、これはこれ、みたいにイベント入ったら 直値参照orコールバックで処理済ませるのってどうだろ
971 :
デフォルトの名無しさん :2012/07/23(月) 19:33:22.23
そろそろ次スレたてようず 俺が一人で1000目指す
Dがあるやん
973 :
デフォルトの名無しさん :2012/07/23(月) 20:21:01.89
ところで激安中古CAD専門店でググると使えるソフトがかなり安い おススメ!!使えた
雑談スレで暴れてたひとか
>>972 作ること自体が目的でもいいじゃん
楽しいじゃん
そうやって出来たのが Ruby ですね わかります
javaとC++で同じコード書いたら最近はjavaの方が早いのな。 単純な計算だとC++の方が速いが最大でも倍程度に過ぎないし、世の中そんな単純な計算ばかりではない。 virtual使ったらjavaの方が速くなるのでオブジェクト指向を捨ててCライクに書かないと対抗できない。
Javaや.NETだと動的にコードを差し替えられるから 仮想メソッド呼び出しをインライン展開できるんだっけ
C++のコードがアホなだけだろ
コンパイラが賢くなればなるほど抽象度が高い方が速くなる
>>977 単純な計算をJavaで書き直したことがあるけどJavaの方が速かったよ
一箇所だけO(N^2)のループがあってそこがほとんど時間食ってるんだが
実行開始してから時間が経つにつれて段階的に最適化されて速くなっていくのが目に見えて面白かった
バカ丸出し
バカはバカって言葉を平気で使う、俺の第一法則
>>981 そう動的に最適化されていく感じなんだよな。
じゃあ、無能君のほうがいいかな?
無能は無能って言葉を平気で使う、俺の第二法則
おちょくり返しにしては、今ひとつだね