70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。
しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。
そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。
既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。
「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。
◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 7
http://toro.2ch.net/test/read.cgi/tech/1275235018/l50
【超高速】C/C++に代わる低級言語を開発したい 8
1デフォルトの名無しさん
2012/08/23(木) 23:03:00.692デフォルトの名無しさん
2012/08/23(木) 23:07:31.21 ◆新言語の要件 v0.1◆
（１）ハードウェアを直接操作する低レベルの記述が可能
（２）プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能
◆主な要望◆
・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性（絶対条件） ＞ 構文の美しさ(読みやすさ、学習の容易さ) ＞ 再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。
（１）ハードウェアを直接操作する低レベルの記述が可能
（２）プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
（３）最新のオサレ機能が使えてワクワクしながらプログラミング可能
◆主な要望◆
・デバドラ屋だって、オサレ言語で開発したい！
・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
・組込み屋だけど、関数型とダックタイピングしたい。
・shared_ptrの構文糖が欲しいな
・低レベル記述性（絶対条件） ＞ 構文の美しさ(読みやすさ、学習の容易さ) ＞ 再利用性(抽象性)
・算術演算以外の演算子は後置
・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。
3デフォルトの名無しさん
2012/08/23(木) 23:08:53.74 ◆新言語の前提 ver0.02◆
・言語仕様が小さい
・言語仕様に例外事項（但し書き）が少ない
・標準ライブラリーが充実している
・組込みとユーザー定義の区別がない
・標準的なコンピュータアーキテクチャを直接制御するための記述ができる
（オーバーヘッド最小限にI/O・メモリアクセス、割込み処理ができて、かつ、その記述が平易、直感的、誤解が少ないことが望ましい）
・仕様にコーディング規則を含み、それに従うことをある程度強要する
・ドキュメント自動生成を仕様を含む
・既存のバイナリーオブジェクトをリンクして呼び出せる
◆新言語の位置づけ◆
Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, …
烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。
一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。
そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。
◆新言語でのリソース管理方針◆
・確保したリソースを明示的に後始末しなくても問題が発生しない
・何らかのメリットのために確保したリソースを明示的に後始末してもよい
※GCは手段であって上記が満たされていれば必ずしも必須ではない。
・言語仕様が小さい
・言語仕様に例外事項（但し書き）が少ない
・標準ライブラリーが充実している
・組込みとユーザー定義の区別がない
・標準的なコンピュータアーキテクチャを直接制御するための記述ができる
（オーバーヘッド最小限にI/O・メモリアクセス、割込み処理ができて、かつ、その記述が平易、直感的、誤解が少ないことが望ましい）
・仕様にコーディング規則を含み、それに従うことをある程度強要する
・ドキュメント自動生成を仕様を含む
・既存のバイナリーオブジェクトをリンクして呼び出せる
◆新言語の位置づけ◆
Ruby, Python, Haskell, OCaml, Scala, Clojure, Erlang, …
烏合のごとく言語が生まれてきているのにどれも似たようなLLばかりで、ハードウェア制御のような低レベル処理を行える言語が無い。
一方、Cは40年使われ続けてきているわけで、そろそろ置き換えられる言語が出てきてもいいだろう。
そこで、C程度の性能が出せて、Cが使われている分野を全てカバーでき、
過去の互換性に囚われて構文を妥協せず、今時の機能を使えてCよりもプログラミングしやすい新言語を作りたい。
◆新言語でのリソース管理方針◆
・確保したリソースを明示的に後始末しなくても問題が発生しない
・何らかのメリットのために確保したリソースを明示的に後始末してもよい
※GCは手段であって上記が満たされていれば必ずしも必須ではない。
4uy
2012/08/23(木) 23:52:58.78 チューリング完全になれば何でも良かったんだよ
高価な機能はいると訳分からなくなる低脳はC
そういうのがはいっても効率的に扱える奴はC++
既にすみわけは出来てるCとC++の中間くらいの言語が存在しないってだけで
そんなのあってもなくてもどちらでもいい
いま一番Cの代替になる可能性が高いのはGO
高価な機能はいると訳分からなくなる低脳はC
そういうのがはいっても効率的に扱える奴はC++
既にすみわけは出来てるCとC++の中間くらいの言語が存在しないってだけで
そんなのあってもなくてもどちらでもいい
いま一番Cの代替になる可能性が高いのはGO
5uy
2012/08/23(木) 23:55:19.82 営利目的で言語は作ったほうがいいよ
Cの代替になる言語を作ったら金になるか？
ならないのであれば作る価値はないし、使われる価値もない
金金金金金金金金金金金金金金金金金金金金金金金金金金金金
本物のハッカーとかそんなもの関係ない、
金の力が人の学習意欲をかりたたせる
どんな雑魚でも生活のためならC++言語でもなんだろうと使いこなす
本物の天才が金を得るためにプログラムを組む
いくら優秀な言語があっても、金から遠ざかれば使われない
Cの代替になる言語を作ったら金になるか？
ならないのであれば作る価値はないし、使われる価値もない
金金金金金金金金金金金金金金金金金金金金金金金金金金金金
本物のハッカーとかそんなもの関係ない、
金の力が人の学習意欲をかりたたせる
どんな雑魚でも生活のためならC++言語でもなんだろうと使いこなす
本物の天才が金を得るためにプログラムを組む
いくら優秀な言語があっても、金から遠ざかれば使われない
6デフォルトの名無しさん
2012/08/24(金) 00:28:39.62 で、C/C++に代わる低級言語としての提案は？
7uY
2012/08/24(金) 01:38:47.62 ネイティブはけるruby
2012/08/24(金) 06:57:07.24
Objective C でいいだろ。
9デフォルトの名無しさん
2012/08/24(金) 08:36:44.50 おれもObjectiveCでいいと思うね
2012/08/24(金) 08:39:30.70
＜ハードウェアを直接操作する低レベルの記述が可能
ってことは移植性は要らないんだよね
アセンブラでいいんじゃね
ってことは移植性は要らないんだよね
アセンブラでいいんじゃね
2012/08/24(金) 09:17:19.82
アセンブラを超進化させるのが近道じゃね？
2012/08/24(金) 09:19:05.28
おれもアセンブラでいいと思うね
13uY
2012/08/24(金) 10:04:10.55 マジレすすると、
しっかりとC++技術者を育てたらいい
C++が使えない は甘え
しっかりとC++技術者を育てたらいい
C++が使えない は甘え
2012/08/24(金) 11:14:03.28
アセンブラに化け物なマクロ入れるだけでいいんじゃねぇの？
欲しい機能はマクロで定義
欲しい機能はマクロで定義
2012/08/24(金) 11:51:37.60
C言語の価値もプリプロセッサにあるんだよね
アセンブラにもマクロあるじゃないの
ただ、アセンブラ毎にマクロの仕様が違ったりするから
併合しようとした人はこれまで何人もいた
でも結局使わないんだわそんなの
アセンブラにもマクロあるじゃないの
ただ、アセンブラ毎にマクロの仕様が違ったりするから
併合しようとした人はこれまで何人もいた
でも結局使わないんだわそんなの
2012/08/24(金) 13:31:30.10
CLASSは欲しいのかな？
2012/08/24(金) 13:55:21.91
uyが社畜みたいな発言をしていて雑魚くさい。
2012/08/24(金) 15:08:59.25
C++は、仮想関数テーブルがいまいち。
2012/08/24(金) 15:23:43.08
なんでC++は仮想関数使うと異様に遅くなるんだろう。
2012/08/24(金) 15:26:50.19
アセンブラマクロに強力な型機能を持たせて、ついでに多態性も付けて
単純な継承・カプセル化程度をサポートすればおｋ？
単純な継承・カプセル化程度をサポートすればおｋ？
2012/08/24(金) 15:30:13.75
アセンブラマクロでイテレータつくれる？
2012/08/25(土) 21:09:56.18
どういう風に使いたいのか仕様 plz.
2012/08/27(月) 01:11:28.07
kuin最強伝説
24uy
2012/08/28(火) 01:52:32.53 プログラミングは最終的にはアセンブラになるかもしれないね
よく考えたら無理じゃない気がしてきた
よく考えたら無理じゃない気がしてきた
25デフォルトの名無しさん
2012/08/28(火) 02:11:48.33 せっかくよく考えたのなら、その考えを文章にしてみよう。
鉄は熱いうちに打て。
鉄は熱いうちに打て。
2012/08/28(火) 09:08:24.23
2012/08/28(火) 09:23:08.58
C/C++は高級じゃないと申すか
2012/08/28(火) 10:18:55.39
昔は知らんが
今はCは低級、C++でOOPすれば何とか高級？
今はCは低級、C++でOOPすれば何とか高級？
2012/08/28(火) 21:32:53.34
恒久
30デフォルトの名無しさん
2012/08/28(火) 23:32:52.57 制御対象が十分に抽象化されていれば高級、ベタに見えていれば低級
言語はそれほど関係ない
言語はそれほど関係ない
2012/08/29(水) 21:10:23.64
サーバーサイドjsが持てはやされるぐらいなんだから、
自社サービスを展開してるようなところではc/c++は使われなくなるんじゃないかしら
そういう企業じゃシステム言語はgolangが主流になると思うよ
自社サービスを展開してるようなところではc/c++は使われなくなるんじゃないかしら
そういう企業じゃシステム言語はgolangが主流になると思うよ
2012/08/30(木) 09:11:23.27
WebでC/C++は珍しい。
goは当分ならねーよｗ
goは当分ならねーよｗ
2012/09/07(金) 12:59:14.71
いまの言語とか制御構造や予約語の文法以前とか以前に
ライブラリーの便利さと豊富さが基本であって、言語の重要性はあまり関係ない。
同じコードを書くのに少ないコードで実現できる（内部が見えない）
類が抽象化の度合いでどれだけ高機能を呼び出すだけで実装できるかが
重要になっている。
低級なそれは多くの仕組みと手順を細かく表現しなければいけないのだが
高級になれば何も表現しなくても「あれ」「これ」な感覚で作れてしまう。
本当に低級ならば四則演算とか使わずにプログラム作れよサブルーチンという
概念も使うな！
ライブラリーの便利さと豊富さが基本であって、言語の重要性はあまり関係ない。
同じコードを書くのに少ないコードで実現できる（内部が見えない）
類が抽象化の度合いでどれだけ高機能を呼び出すだけで実装できるかが
重要になっている。
低級なそれは多くの仕組みと手順を細かく表現しなければいけないのだが
高級になれば何も表現しなくても「あれ」「これ」な感覚で作れてしまう。
本当に低級ならば四則演算とか使わずにプログラム作れよサブルーチンという
概念も使うな！
2012/09/07(金) 15:55:23.51
魔法みたいなことが出来る関数があれば終わりですって
2012/09/07(金) 21:58:26.62
Webやスクリプト言語には興味ありません
ハードウェア制御・リアルタイム・マルチコアなどなど
抽象化のための「見えない」コードを書きたいのです
ハードウェア制御・リアルタイム・マルチコアなどなど
抽象化のための「見えない」コードを書きたいのです
36デフォルトの名無しさん
2012/09/08(土) 23:31:28.522012/09/09(日) 10:25:22.63
>>32
ラッパー経由で思いっきり使われてる。
ラッパー経由で思いっきり使われてる。
2012/09/09(日) 10:41:47.62
>>37
スクリプト言語もHTTPサーバーもOSもCで書かれてるしな。おもいっきり使われてる。
スクリプト言語もHTTPサーバーもOSもCで書かれてるしな。おもいっきり使われてる。
2013/02/04(月) 16:57:39.03
ある程度モデルになる言語は要るだろ
Objective-C++をモデルにすることを提案する
Objective-C++をモデルにすることを提案する
40デフォルトの名無しさん
2013/02/04(月) 22:40:20.04 モデルにすることを提案するだけではなく、どのようにモデルにするのかを提案するともっといいぞ
41片山博文MZパンク ◆0lBZNi.Q7evd
2013/02/24(日) 22:49:04.87 局所変数をすべて静的大局変数にするなんてどうだい？
2013/02/24(日) 22:50:35.00
41 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん
43デフォルトの名無しさん
2013/02/24(日) 23:04:15.58 >>41
その効果は？
その効果は？
44デフォルトの名無しさん
2013/03/21(木) 16:10:03.33 ポストPHP/CGIを狙うような静的型付き言語を開発したいがそういうスレはないものか
2013/03/21(木) 16:47:09.32
（どうやら俺の他にはいないようだな…しめしめ、勝った）
2013/04/01(月) 00:11:54.06
C/C++なくても、型付Lispが開発されて、もっと遅かったであろう。
2013/04/01(月) 11:36:10.71
実用化されるまで10年以上遅れていたであろう。
ていうかPCという概念すら生まれなかったであろう。
ていうかPCという概念すら生まれなかったであろう。
48デフォルトの名無しさん
2013/04/01(月) 23:04:46.27 概念ｗ
2013/04/02(火) 14:56:01.95
Cができるようになる前から安価なPCってあったんだっけか
2013/04/03(水) 00:57:47.82
ない
51デフォルトの名無しさん
2013/04/05(金) 23:47:23.21 エレキてきバグでまくるだろ
52デフォルトの名無しさん
2013/04/07(日) 05:37:26.11 41みたいなことをするとバグ、多発。
2013/04/07(日) 22:19:02.62
CもC++も高級言語で、スレタイがそもそも間違ってるのに、いつまで続けてるんだ。
マシンコードそのままなのと、アセンブリ言語だけが低級言語ということも知らないのか。
コンピュータの勉強して最初にわかることじゃないか。
それに開発したいのはどういう目的があってのことなのかね。
マシンコードそのままなのと、アセンブリ言語だけが低級言語ということも知らないのか。
コンピュータの勉強して最初にわかることじゃないか。
それに開発したいのはどういう目的があってのことなのかね。
2013/04/07(日) 22:40:29.84
>>53
スレ違い
スレ違い
55デフォルトの名無しさん
2013/04/10(水) 19:39:49.93 オブジェクト思考なんて何十年も前
今は最新なんなんだ？
今は最新なんなんだ？
2013/04/10(水) 19:46:59.55
ラムダ関数
2013/04/10(水) 21:27:07.91
58デフォルトの名無しさん
2013/04/11(木) 05:53:27.68 なるほろ
サンクス
サンクス
2013/04/11(木) 07:32:56.17
アスペクト指向はソースコードのXML化といって差し支えない
XMLタグの量を増やせばできることも増えるがソースは冗長で不細工になる。
OWL推論でコンポーネント間が繋がれば、超冗長だが再利用しやすくなったりするかもな
<Entity name="DBTable">
class Persons {}
</Entity>
@Entity(name="DBTable")
class Persons
XMLタグの量を増やせばできることも増えるがソースは冗長で不細工になる。
OWL推論でコンポーネント間が繋がれば、超冗長だが再利用しやすくなったりするかもな
<Entity name="DBTable">
class Persons {}
</Entity>
@Entity(name="DBTable")
class Persons
2013/04/11(木) 21:45:02.95
型付きlisp風言語作ればいいじゃんて話だろ、まとめると
2013/04/11(木) 22:22:45.21
関数コール時値やアドレス値をスタックやレジスタへ積み積みする暗黙に埋め込まれるコードもアスペクト
暗黙だけでなくあちこちにユーザーコードまで混ぜれるようにしちまう開放的且つカオス世界への招待を
有難いと感じるかどうかが別れめっスね
暗黙だけでなくあちこちにユーザーコードまで混ぜれるようにしちまう開放的且つカオス世界への招待を
有難いと感じるかどうかが別れめっスね
2013/04/12(金) 12:58:38.54
自分一人でやる分にはいいが複数人でやるとたちまち世界が破滅する
2013/04/13(土) 13:20:43.36
構文を工夫して文字数を減らしても仕方ないし、XML/アスペクト指向も終わった。
最近の新しい発想というとKVSぐらいだな。１人でプログラミングすると効率悪いが、
多人数での分業に向いている言語とかいんじゃね？
最近の新しい発想というとKVSぐらいだな。１人でプログラミングすると効率悪いが、
多人数での分業に向いている言語とかいんじゃね？
2013/04/14(日) 01:15:12.51
Javaのことですねわかります
2013/04/14(日) 16:08:49.81
>>59
なにか変だと思ったら DIとAOPを混同しているな
なにか変だと思ったら DIとAOPを混同しているな
2013/04/14(日) 23:03:21.36
JPAとかEntityBeanはDIなのか？
2013/04/24(水) 19:52:56.12
>>54
スレ通りの発言だろうが
スレ通りの発言だろうが
2013/04/24(水) 20:03:03.76
2013/04/26(金) 09:31:25.15
Cは読める低級
2013/04/28(日) 02:58:49.44
D言語でいいじゃん
2013/04/28(日) 10:17:28.30
E言語でEじゃん
2013/05/23(木) 12:53:53.21
>>70
似非システム言語はすっこんでてください
似非システム言語はすっこんでてください
2013/08/06(火) NY:AN:NY.AN
Cを高級アセンブラという人はアセンブラを知らない。
高級アセンブラは p-code や IL。
高級アセンブラは p-code や IL。
74デフォルトの名無しさん
2013/08/24(土) NY:AN:NY.AN 俺は C よりアセンブラを先にやったクチだが
C はまっとうな高級アセンブラだよ
ソフトウエアで構築したVMが機械語のつもりのやつこそ
diagnose 命令を知らない
C はまっとうな高級アセンブラだよ
ソフトウエアで構築したVMが機械語のつもりのやつこそ
diagnose 命令を知らない
2013/08/25(日) NY:AN:NY.AN
初期のCは高級アセンブラと言って良かったが、最新のC/C++はインラインアセンブラがサポートされなくなってきたので
高級アセンブラとは言いにくくなってきた。Cはロジックのわかりやすさを優先して、CPUのレジスタを意識させない構文に
してしまったから、レジスタを意識しなくてよくなった反面、フラグを見ることもできないし、CPUの固有命令を使うことも
できない。インラインアセンブラも使えなくなってきたので、いろいろある言語の1つに落ちぶれてしまった。
簡単なサンプルをCとアセンブラで書いて比較すると速度が違うし、実行ファイルサイズも大きく違う。
Cは非常に無駄が多いということだ。
高級アセンブラとは言いにくくなってきた。Cはロジックのわかりやすさを優先して、CPUのレジスタを意識させない構文に
してしまったから、レジスタを意識しなくてよくなった反面、フラグを見ることもできないし、CPUの固有命令を使うことも
できない。インラインアセンブラも使えなくなってきたので、いろいろある言語の1つに落ちぶれてしまった。
簡単なサンプルをCとアセンブラで書いて比較すると速度が違うし、実行ファイルサイズも大きく違う。
Cは非常に無駄が多いということだ。
76デフォルトの名無しさん
2013/08/25(日) NY:AN:NY.AN インラインアセンブラは関係ない
特権命令が必要な箇所はもともとアセンブラで書いてリンクするのが正統派で
Cソースの中に直接ニーモニックを書くのは邪道である
フラグやローテートはアーキテクチャによる相違が強烈なので抽象化しなかっただけ
レジスタ名称もそうで、このためアセンブラはオンレジスタ、Cはオンメモリという相違が生じた
アセンブラを習得している者がCを憶えるとき自動変数に違和感を持つのはこのためで
いついつからCがそうなってしまったわけではなく、始めからそうなのだ
Hello C world のサイズだけ見てCそのものが非効率という人は
サイズの違いの主成分を知らないだけ
特権命令が必要な箇所はもともとアセンブラで書いてリンクするのが正統派で
Cソースの中に直接ニーモニックを書くのは邪道である
フラグやローテートはアーキテクチャによる相違が強烈なので抽象化しなかっただけ
レジスタ名称もそうで、このためアセンブラはオンレジスタ、Cはオンメモリという相違が生じた
アセンブラを習得している者がCを憶えるとき自動変数に違和感を持つのはこのためで
いついつからCがそうなってしまったわけではなく、始めからそうなのだ
Hello C world のサイズだけ見てCそのものが非効率という人は
サイズの違いの主成分を知らないだけ
2013/08/25(日) NY:AN:NY.AN
>>76
> Cソースの中に直接ニーモニックを書くのは邪道である
今まで正式な文法としてインラインが書けたのに、それを勝手に邪道と言い切るのはどうかと。
単なる個人的意見だよね。
> フラグやローテートはアーキテクチャによる相違が強烈なので抽象化しなかっただけ
> いついつからCがそうなってしまったわけではなく、始めからそうなのだ
もちろんわかってるよ。別にCの文法に文句を言いたいわけじゃないから。
でも抽象化できるというなら、ニーモニックを直接書ける仕様にして、
それをラップ関数で覆って見えなくしてライブラリに入れてしまえば
Cで書いたソースはそのまま使えるよね。
> Hello C world のサイズだけ見てCそのものが非効率という人は
> サイズの違いの主成分を知らないだけ
その主成分を知ってる人に聞きたいんだけど、アセンブラでは不要で、
Cならその主成分とやらが必要という根拠は何か教えてくれないかな。
> Cソースの中に直接ニーモニックを書くのは邪道である
今まで正式な文法としてインラインが書けたのに、それを勝手に邪道と言い切るのはどうかと。
単なる個人的意見だよね。
> フラグやローテートはアーキテクチャによる相違が強烈なので抽象化しなかっただけ
> いついつからCがそうなってしまったわけではなく、始めからそうなのだ
もちろんわかってるよ。別にCの文法に文句を言いたいわけじゃないから。
でも抽象化できるというなら、ニーモニックを直接書ける仕様にして、
それをラップ関数で覆って見えなくしてライブラリに入れてしまえば
Cで書いたソースはそのまま使えるよね。
> Hello C world のサイズだけ見てCそのものが非効率という人は
> サイズの違いの主成分を知らないだけ
その主成分を知ってる人に聞きたいんだけど、アセンブラでは不要で、
Cならその主成分とやらが必要という根拠は何か教えてくれないかな。
レスを投稿する
