-
プログラム
-
【超高速】C/C++に代わる低級言語を開発したい 8
-
UPLIFTで広告なしで体験しましょう！快適な閲覧ライフをお約束します！
70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。
しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。
既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。
「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。
◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 7
http://toro.2ch.net/.../tech/1275235018/l50 - コメントを投稿する
-
◆新言語の要件 v0.1◆
（１）ハードウェアを直接操作する低レベルの記述が可能
（２）プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能
◆主な要望◆
・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性（絶対条件） ＞ 構文の美しさ(読みやすさ、学習の容易さ) ＞ 再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。 -
◆新言語の前提 ver0.02◆
・言語仕様が小さい
・言語仕様に例外事項（但し書き）が少ない
・標準ライブラリーが充実している
・組込みとユーザー定義の区別がない
・標準的なコンピュータアーキテクチャを直接制御するための記述ができる
（オーバーヘッド最小限にI/O・メモリアクセス、割込み処理ができて、かつ、その記述が平易、直感的、誤解が少ないことが望ましい）
・仕様にコーディング規則を含み、それに従うことをある程度強要する
・ドキュメント自動生成を仕様を含む
・既存のバイナリーオブジェクトをリンクして呼び出せる
◆新言語の位置づけ◆
Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, …
烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。
一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。
そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。
◆新言語でのリソース管理方針◆
・確保したリソースを明示的に後始末しなくても問題が発生しない
・何らかのメリットのために確保したリソースを明示的に後始末してもよい
※GCは手段であって上記が満たされていれば必ずしも必須ではない。 -
チューリング完全になれば何でも良かったんだよ
高価な機能はいると訳分からなくなる低脳はC
そういうのがはいっても効率的に扱える奴はC++
既にすみわけは出来てるCとC++の中間くらいの言語が存在しないってだけで
そんなのあってもなくてもどちらでもいい
いま一番Cの代替になる可能性が高いのはGO -
営利目的で言語は作ったほうがいいよ
Cの代替になる言語を作ったら金になるか？
ならないのであれば作る価値はないし、使われる価値もない
金金金金金金金金金金金金金金金金金金金金金金金金金金金金
本物のハッカーとかそんなもの関係ない、
金の力が人の学習意欲をかりたたせる
どんな雑魚でも生活のためならC++言語でもなんだろうと使いこなす
本物の天才が金を得るためにプログラムを組む
いくら優秀な言語があっても、金から遠ざかれば使われない -
で、C/C++に代わる低級言語としての提案は？
-
ネイティブはけるruby
-
Objective C でいいだろ。
-
おれもObjectiveCでいいと思うね
-
＜ハードウェアを直接操作する低レベルの記述が可能
ってことは移植性は要らないんだよね
アセンブラでいいんじゃね -
アセンブラを超進化させるのが近道じゃね？
-
おれもアセンブラでいいと思うね
-
マジレすすると、
しっかりとC++技術者を育てたらいい
C++が使えない は甘え -
アセンブラに化け物なマクロ入れるだけでいいんじゃねぇの？
欲しい機能はマクロで定義
-
C言語の価値もプリプロセッサにあるんだよね
アセンブラにもマクロあるじゃないの
ただ、アセンブラ毎にマクロの仕様が違ったりするから
併合しようとした人はこれまで何人もいた
でも結局使わないんだわそんなの -
CLASSは欲しいのかな？
-
uyが社畜みたいな発言をしていて雑魚くさい。
-
C++は、仮想関数テーブルがいまいち。
-
なんでC++は仮想関数使うと異様に遅くなるんだろう。
-
アセンブラマクロに強力な型機能を持たせて、ついでに多態性も付けて
単純な継承・カプセル化程度をサポートすればおｋ？ -
アセンブラマクロでイテレータつくれる？
-
どういう風に使いたいのか仕様 plz.
-
kuin最強伝説
-
プログラミングは最終的にはアセンブラになるかもしれないね
よく考えたら無理じゃない気がしてきた -
せっかくよく考えたのなら、その考えを文章にしてみよう。
鉄は熱いうちに打て。 -
C/C++は高級じゃないと申すか
-
昔は知らんが
今はCは低級、C++でOOPすれば何とか高級？ -
恒久
-
制御対象が十分に抽象化されていれば高級、ベタに見えていれば低級
言語はそれほど関係ない -
サーバーサイドjsが持てはやされるぐらいなんだから、
自社サービスを展開してるようなところではc/c++は使われなくなるんじゃないかしら
そういう企業じゃシステム言語はgolangが主流になると思うよ
-
WebでC/C++は珍しい。
goは当分ならねーよｗ -
いまの言語とか制御構造や予約語の文法以前とか以前に
ライブラリーの便利さと豊富さが基本であって、言語の重要性はあまり関係ない。
同じコードを書くのに少ないコードで実現できる（内部が見えない）
類が抽象化の度合いでどれだけ高機能を呼び出すだけで実装できるかが
重要になっている。
低級なそれは多くの仕組みと手順を細かく表現しなければいけないのだが
高級になれば何も表現しなくても「あれ」「これ」な感覚で作れてしまう。
本当に低級ならば四則演算とか使わずにプログラム作れよサブルーチンという
概念も使うな！ -
魔法みたいなことが出来る関数があれば終わりですって
-
Webやスクリプト言語には興味ありません
ハードウェア制御・リアルタイム・マルチコアなどなど
抽象化のための「見えない」コードを書きたいのです -
>>32
ラッパー経由で思いっきり使われてる。 -
>>37
スクリプト言語もHTTPサーバーもOSもCで書かれてるしな。おもいっきり使われてる。 -
ある程度モデルになる言語は要るだろ
Objective-C++をモデルにすることを提案する -
モデルにすることを提案するだけではなく、どのようにモデルにするのかを提案するともっといいぞ
-
局所変数をすべて静的大局変数にするなんてどうだい？
-
41 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん
-
>>41
その効果は？ -
ポストPHP/CGIを狙うような静的型付き言語を開発したいがそういうスレはないものか
-
（どうやら俺の他にはいないようだな…しめしめ、勝った）
-
C/C++なくても、型付Lispが開発されて、もっと遅かったであろう。
-
実用化されるまで10年以上遅れていたであろう。
ていうかPCという概念すら生まれなかったであろう。 -
概念ｗ
-
Cができるようになる前から安価なPCってあったんだっけか
-
ない
-
エレキてきバグでまくるだろ
-
41みたいなことをするとバグ、多発。
-
CもC++も高級言語で、スレタイがそもそも間違ってるのに、いつまで続けてるんだ。
マシンコードそのままなのと、アセンブリ言語だけが低級言語ということも知らないのか。
コンピュータの勉強して最初にわかることじゃないか。
それに開発したいのはどういう目的があってのことなのかね。 -
>>53
スレ違い -
オブジェクト思考なんて何十年も前
今は最新なんなんだ？ -
ラムダ関数
-
なるほろ
サンクス -
アスペクト指向はソースコードのXML化といって差し支えない
XMLタグの量を増やせばできることも増えるがソースは冗長で不細工になる。
OWL推論でコンポーネント間が繋がれば、超冗長だが再利用しやすくなったりするかもな
<Entity name="DBTable">
class Persons {}
</Entity>
@Entity(name="DBTable")
class Persons -
型付きlisp風言語作ればいいじゃんて話だろ、まとめると
-
関数コール時値やアドレス値をスタックやレジスタへ積み積みする暗黙に埋め込まれるコードもアスペクト
暗黙だけでなくあちこちにユーザーコードまで混ぜれるようにしちまう開放的且つカオス世界への招待を
有難いと感じるかどうかが別れめっスね -
自分一人でやる分にはいいが複数人でやるとたちまち世界が破滅する
-
構文を工夫して文字数を減らしても仕方ないし、XML/アスペクト指向も終わった。
最近の新しい発想というとKVSぐらいだな。１人でプログラミングすると効率悪いが、
多人数での分業に向いている言語とかいんじゃね？ -
Javaのことですねわかります
-
>>59
なにか変だと思ったら DIとAOPを混同しているな -
JPAとかEntityBeanはDIなのか？
-
>>54
スレ通りの発言だろうが -
Cは読める低級
-
D言語でいいじゃん
-
E言語でEじゃん
-
>>70
似非システム言語はすっこんでてください -
Cを高級アセンブラという人はアセンブラを知らない。
高級アセンブラは p-code や IL。 -
俺は C よりアセンブラを先にやったクチだが
C はまっとうな高級アセンブラだよ
ソフトウエアで構築したVMが機械語のつもりのやつこそ
diagnose 命令を知らない -
初期のCは高級アセンブラと言って良かったが、最新のC/C++はインラインアセンブラがサポートされなくなってきたので
高級アセンブラとは言いにくくなってきた。Cはロジックのわかりやすさを優先して、CPUのレジスタを意識させない構文に
してしまったから、レジスタを意識しなくてよくなった反面、フラグを見ることもできないし、CPUの固有命令を使うことも
できない。インラインアセンブラも使えなくなってきたので、いろいろある言語の1つに落ちぶれてしまった。
簡単なサンプルをCとアセンブラで書いて比較すると速度が違うし、実行ファイルサイズも大きく違う。
Cは非常に無駄が多いということだ。 -
インラインアセンブラは関係ない
特権命令が必要な箇所はもともとアセンブラで書いてリンクするのが正統派で
Cソースの中に直接ニーモニックを書くのは邪道である
フラグやローテートはアーキテクチャによる相違が強烈なので抽象化しなかっただけ
レジスタ名称もそうで、このためアセンブラはオンレジスタ、Cはオンメモリという相違が生じた
アセンブラを習得している者がCを憶えるとき自動変数に違和感を持つのはこのためで
いついつからCがそうなってしまったわけではなく、始めからそうなのだ
Hello C world のサイズだけ見てCそのものが非効率という人は
サイズの違いの主成分を知らないだけ -
>>76
> Cソースの中に直接ニーモニックを書くのは邪道である
今まで正式な文法としてインラインが書けたのに、それを勝手に邪道と言い切るのはどうかと。
単なる個人的意見だよね。
> フラグやローテートはアーキテクチャによる相違が強烈なので抽象化しなかっただけ
> いついつからCがそうなってしまったわけではなく、始めからそうなのだ
もちろんわかってるよ。別にCの文法に文句を言いたいわけじゃないから。
でも抽象化できるというなら、ニーモニックを直接書ける仕様にして、
それをラップ関数で覆って見えなくしてライブラリに入れてしまえば
Cで書いたソースはそのまま使えるよね。
> Hello C world のサイズだけ見てCそのものが非効率という人は
> サイズの違いの主成分を知らないだけ
その主成分を知ってる人に聞きたいんだけど、アセンブラでは不要で、
Cならその主成分とやらが必要という根拠は何か教えてくれないかな。 -
インラインアセンブラなら、ふつうのユーザーもビルドで悩まないですむ
移植性を重視した言語なのにasm文があるのは何故ですか？
asm文は、Dの関数内に直接アセンブリのコードを書き込むことを可能にします。
アセンブラのコードは自明に移植性のないものとなりますが、しかし、
システムアプリの開発には非常に便利なものです。
システムアプリは 大なり小なりシステム依存のコードを含むことになるので、
インラインアセンブラは 大した問題にはなりません。
インラインアセンブラは、CPUの特殊命令や フラグビットへのアクセスによって、
特別な処理の場合や、 限界までコードを最適化したいときに役立ちます。
Cコンパイラがインラインアセンブラ機能を持つ前は、 私は外部のアセンブラを使っていました。
アセンブラは 沢山の、本当に沢山のバージョンがあって、
各バージョン毎に微妙に 構文が違っていたりバグがあったりコマンドラインの文法まで
変わっていたりして、非常に残念な思いをしました。 つまり、アセンブラの必要なコードは、
ユーザーには安心してビルドはできなかったのです。
インラインアセンブラができてからは、そんなことはなくなりました。
よくある質問 - プログラミング言語 D (日本語訳)
http://www.kmonos.ne...lang/d/faq.html#q1_1 -
>>77
単なる個人的意見？ #pragma のオンパレードと同じだと言っているんだが
単にニーモニックが書けるだけでは不十分で
オペランドの装飾名やレジスタアサインまで最適化の影響も受けずにクリアする必要がある
高級言語でだぞ？ これを邪道だというのの、どこが個人的意見なんだ？
> ラップ関数で覆って見えなくして
日本語でおｋ
> その主成分を知ってる人に聞きたい
逆アセンブル読めよ、読めないならもう一度言ってやる「主成分を知らないやつめ」 -
>>78
asmがあるのはなぜって、俺に聞くのはお門違いだ
移植性を重視しながら sizeof(int) が処理系定義だしねえ
> システムアプリは大なり小なりシステム依存のコードを含むことになるので
そのとおりだが
> インラインアセンブラは大した問題にはなりません
なぜこうつながる？
> 私は外部のアセンブラを使っていました。
過去形ということは「あの問題」を知らないわけだね
このくだり、突っ込みどころ多すぎて投げたわ -
>>80
日本語不自由な人みたいなので wrap function と書けば理解できるのかな。在日君ですか？
Cがアセンブラより太る原因は逆アセなんかしなくてもわかるんだが。
おまいさあ、Cコンパイラのソース一度も読んだことないだろw
「低レベルなやつめ」 -
シッタカ君に権威主義君か
どんどんやれ -
淫乱NISSENブラ
-
Cのファイルサイズサイズ語るならリンカだろ？
gcc読むにしてもCコンパイラ部分は読まねえよ。
コンパイラなら普通にアセンブリ吐くから逆アセンブルもしねえ。 -
具体的な説明でもobjdumpで十分だろ。
逆アセンブルしたコードなんて読まねえよ低能。 -
逆汗読めねえ低脳でもリンカのマップくらい読めよせめて
-
ついに逆アセンブルに意味がないことを認めてしまった低能ｗ
-
は？ 10倍という定量的な値に反論できないのはてめえだろうが
-
説明出来れば十分だろ？
構造とシンボル情報見せてlibcの初期化コードが含まれているで十分じゃん
サイズ知るためだけに逆アセンブルコード読む必要なんて全然ないだろｗ
どこに必要あるのか言ってみろよ低能ｗ -
それは10倍にならないコードを示せれば充分だ
Hello World しかできねーバカにそれは無理だが -
このまま逆アセンブルが必要である具体的な理由を示せないなら負けだぞ低能
-
別に負けで結構だ
有料なノウハウをただでぶちまける必要はない -
具体的に言えないどころかあえて言わないだってｗ
ここまで否定してきて根拠も出せないｗ
まさに負け犬の遠吠えｗ -
readmemoryとか
writememoryがどうなるのだろうか -
なんの話？
-
ナンではありません
↑今すぐ読める無料コミック大量配信中！↑
