【超高速】C/C++に代わる低級言語を開発したい 8

70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。

そこで、このスレッドでは、
低レベルなシステム開発のためのプログラミング言語
を一から考えたい。

既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
「既存のXX言語を使えばいい。」という類の発言は無意味である。

「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
という観点で考えたい。

◆前スレ
【超高速】C/C++に代わる低級言語を開発したい 7
http://toro.2ch.net/test/read.cgi/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最強伝説

プログラミングは最終的にはアセンブラになるかもしれないね
よく考えたら無理じゃない気がしてきた

せっかくよく考えたのなら、その考えを文章にしてみよう。
鉄は熱いうちに打て。

>>24
それは、高級言語プログラミングしてる時に、
頭の中でアセンブラが思い浮かぶような人だけだよ。

C/C++は高級じゃないと申すか

昔は知らんが
今はCは低級、C++でOOPすれば何とか高級？

恒久

制御対象が十分に抽象化されていれば高級、ベタに見えていれば低級
言語はそれほど関係ない

サーバーサイドjsが持てはやされるぐらいなんだから、
自社サービスを展開してるようなところではc/c++は使われなくなるんじゃないかしら
そういう企業じゃシステム言語はgolangが主流になると思うよ

WebでC/C++は珍しい。
goは当分ならねーよｗ

いまの言語とか制御構造や予約語の文法以前とか以前に
ライブラリーの便利さと豊富さが基本であって、言語の重要性はあまり関係ない。
同じコードを書くのに少ないコードで実現できる（内部が見えない）
類が抽象化の度合いでどれだけ高機能を呼び出すだけで実装できるかが
重要になっている。
低級なそれは多くの仕組みと手順を細かく表現しなければいけないのだが
高級になれば何も表現しなくても「あれ」「これ」な感覚で作れてしまう。
本当に低級ならば四則演算とか使わずにプログラム作れよサブルーチンという
概念も使うな！

魔法みたいなことが出来る関数があれば終わりですって

Webやスクリプト言語には興味ありません

ハードウェア制御・リアルタイム・マルチコアなどなど
抽象化のための「見えない」コードを書きたいのです

>>33
であれば、具体的にどのようなライブラリが必要と考えるのかを述べるのがこのスレッドの意義である。

「使うな」で終わるのは建設的ではない。前半は良い発言だから、頑張れ。

>>32
ラッパー経由で思いっきり使われてる。

>>37
スクリプト言語もHTTPサーバーもOSもCで書かれてるしな。おもいっきり使われてる。

ある程度モデルになる言語は要るだろ
Objective-C++をモデルにすることを提案する

モデルにすることを提案するだけではなく、どのようにモデルにするのかを提案するともっといいぞ

局所変数をすべて静的大局変数にするなんてどうだい？

41 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

>>41
その効果は？

ポストPHP/CGIを狙うような静的型付き言語を開発したいがそういうスレはないものか

（どうやら俺の他にはいないようだな…しめしめ、勝った）

C/C++なくても、型付Lispが開発されて、もっと遅かったであろう。

実用化されるまで10年以上遅れていたであろう。
ていうかPCという概念すら生まれなかったであろう。

概念ｗ

Cができるようになる前から安価なPCってあったんだっけか

ない

エレキてきバグでまくるだろ

41みたいなことをするとバグ、多発。

CもC++も高級言語で、スレタイがそもそも間違ってるのに、いつまで続けてるんだ。
マシンコードそのままなのと、アセンブリ言語だけが低級言語ということも知らないのか。
コンピュータの勉強して最初にわかることじゃないか。
それに開発したいのはどういう目的があってのことなのかね。

>>53
スレ違い

オブジェクト思考なんて何十年も前
今は最新なんなんだ？

ラムダ関数

>>55
アスペクト指向というのがあるがまだ実用化されてない

アスペルガー指向の方が多くないか？wwww

なるほろ
サンクス

アスペクト指向はソースコードの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
スレ通りの発言だろうが

>>53 と >>67 って同一人物?
C++ はともかく, C って高級アセンブラだろ?
立派な低級言語じゃん

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.net/alang/d/faq.html#q1_1

>>53
英語で
middle-level
検索したらでてくる

>>77
単なる個人的意見？ #pragma のオンパレードと同じだと言っているんだが
単にニーモニックが書けるだけでは不十分で
オペランドの装飾名やレジスタアサインまで最適化の影響も受けずにクリアする必要がある
高級言語でだぞ？　これを邪道だというのの、どこが個人的意見なんだ？

> ラップ関数で覆って見えなくして
日本語でおｋ

> その主成分を知ってる人に聞きたい
逆アセンブル読めよ、読めないならもう一度言ってやる「主成分を知らないやつめ」

>>78
asmがあるのはなぜって、俺に聞くのはお門違いだ
移植性を重視しながら sizeof(int) が処理系定義だしねえ

> システムアプリは大なり小なりシステム依存のコードを含むことになるので
そのとおりだが

> インラインアセンブラは大した問題にはなりません
なぜこうつながる？

> 私は外部のアセンブラを使っていました。
過去形ということは「あの問題」を知らないわけだね
このくだり、突っ込みどころ多すぎて投げたわ

>>80
なんだ、ただの知ったか君か、ご苦労w
もう来なくていいから

>>81
おいおい、>>78はD言語のFAQのコピペだぞ。つまり「私」というのはD言語の開発者だ。
どう見てもおまいよりコンパイラの内部に詳しい。
「あの問題」とかわけわかんないこと言ってんじゃないぞw
知ったか君はろくに文章も読めないから困る。話にならんな。

>>80
日本語不自由な人みたいなので wrap function と書けば理解できるのかな。在日君ですか？

Cがアセンブラより太る原因は逆アセなんかしなくてもわかるんだが。
おまいさあ、Cコンパイラのソース一度も読んだことないだろw
「低レベルなやつめ」

シッタカ君に権威主義君か
どんどんやれ

淫乱NISSENブラ

Cのファイルサイズサイズ語るならリンカだろ？
gcc読むにしてもCコンパイラ部分は読まねえよ。
コンパイラなら普通にアセンブリ吐くから逆アセンブルもしねえ。

>>84
いーや、逆アセよまなきゃ10倍にもなる理由は説明できない
コンパイラのソースとか何言ってるんだ？　頭が発狂したのか？

具体的な説明でもobjdumpで十分だろ。
逆アセンブルしたコードなんて読まねえよ低能。

逆汗読めねえ低脳でもリンカのマップくらい読めよせめて

ついに逆アセンブルに意味がないことを認めてしまった低能ｗ

は？　10倍という定量的な値に反論できないのはてめえだろうが

説明出来れば十分だろ？
構造とシンボル情報見せてlibcの初期化コードが含まれているで十分じゃん
サイズ知るためだけに逆アセンブルコード読む必要なんて全然ないだろｗ
どこに必要あるのか言ってみろよ低能ｗ

それは10倍にならないコードを示せれば充分だ
Hello World しかできねーバカにそれは無理だが

このまま逆アセンブルが必要である具体的な理由を示せないなら負けだぞ低能

別に負けで結構だ
有料なノウハウをただでぶちまける必要はない

具体的に言えないどころかあえて言わないだってｗ
ここまで否定してきて根拠も出せないｗ
まさに負け犬の遠吠えｗ

readmemoryとか
writememoryがどうなるのだろうか

なんの話？

ナンではありません

scalaみたいな、Cかアセンブラのコードに変換してくれる言語作れば？

そう。その具体的な仕様を決めようとしている。

PGはバカでいいという思想はCOBOLの轍そのもの

開発環境は言語のうち
つまりVisualStudioを超える開発環境を作れ

>>103
Javaも割とその思想が入ってる
まあJavaの場合はC++がPGを過信してることへのアンチテーゼもあるんだろうけど

PGはバカでいいというなどという突拍子もない捉え方は１ビット脳そのもの
なぜ中間がないのか

>>106
いいえ

Lazy kでよくね？

>既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
>「既存のXX言語を使えばいい。」という類の発言は無意味である。

>「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
>現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
>一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
>という観点で考えたい。

>>1

大事なのは俺TUEEE感に浸れるかどうかだから
既存のものを流用するなどというのは根本から間違っている

トランスコーダから始めよう。
謎言語toASMが最終目標だ！

>>110
既存の言語を使えと言って思考停止するのは間違っているが
既存のものを流用するのは間違っていない。

C言語が糞なのはヘッダファイルが原因だ
#includeが#importになれば全て解決する

ヘッダ面倒臭ぇ

相変わらず低レベルなところを這い回ってるな

上からモノ言う人って、すごい人なのかと思ってた。
でも意外とそうでもないんだね。

昨日、C言語スレで構文解析の話題があった時、上からモノを言ってくるので
凄い人だと思って話を聞いてたら、実は初心者だった。

人の話は板違いです。
ご遠慮ください。

ステートマシン風な言語でも作ればいいじゃん。

いいね。先ずは具体的なアイディアを聞かせて。

欲しい言語機能は全てRUSTに入っていた

RUSTは正解に近い感じがする。

RUSTってC++と比較されるけど低レベル組み込み系もいけんの？

C++、stlが許されるだけのリソースがあるなら大丈夫そうだ。

コンパイル時リフレクション(javaでいうアノテーション・プロセッサ）がほしいな
シリアライザーとか自動でつくってほしい

C++は低級言語なのか？

Dがもっと流行れば解決する。

Dはないわ。

LLVM IRみたいのでいいだろ。

vecterはc、c++から外して欲しい、元はjavaだろ、イテレータとか。

Javaは外した方がいいというのは、銅管だ。

　___　_
　 ヽo,´-'─ 、　♪
　　 r, "~~~~"ヽ
　　 i. ,'ﾉﾚノﾚ!ﾚ〉　　　　☆ 日本のカクブソウは絶対に必須です ☆
　__ '!从.ﾟ ヮﾟﾉﾙ　　　総務省の『憲法改正国民投票法』のURLです。
　ゝﾝ〈(つY_i(つ　http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html
　 ｀,.く,§_,_,ゝ,
　　　~i_ﾝｲﾉ

低級言語はアセンブラと初期のCだけだろう

言語作ってるんだけど、
コンパイラ作る時って一旦アセンブラ出力してからmasmとかに機械語出力してもらった方がいいの？
masm自身はアセンブラコードの最適化とかはしてくれなそうだしそのまま機械語出力したいんだけど

アセンブラ介したほうが少なくともデバッグはしやすいと思うぞ

そのコンパイラで何ができるもしくは何をやらせるのかも
決めてないんだ

>>134
どれくらいしやすくなる？
命令のバイナリ列を理解しやすい(?)形でアセンブラに1対1で置き換えてデバッグする、っていう手間が省ける程度なら雀の涙という感じ
むしろデバッグするときは結局機械語読むことになるから最初から機械語で出力したほうが理解が早い気もする
それ以上のメリットってなにかあるのかな

>>135
一応決まってるよ
Windows8以降向けのUI・ゲーム開発言語

x86系の命令、１６進数で読めるんだ
なら、直接コード出して、ハマりまくったほうがいいかもね

>>136
用途からすると機械語やアセンブラへのコンパイルどころか
C言語+HLSLへのトランスレータが最適解な気もするなあ…
結局、何だかんだでDirectXの関数呼ぶことになりそう

んで関数呼び出して処理するなら、機械語とC言語の差は間の計算処理になるが
そこも巷のC処理系の最適化はノウハウ詰まってるから
下手なアセンブラコードより速かったりする

何れにしても何層かに処理を分けることにはなるだろうから
いきなり全部やろうとするより、やるべき層をひとつひとつ集中してやったほうが

>>137
わーい

>>138
そのとおりです
DirectXの関数は呼ぶよ。でもスレの主旨的にもC言語を介したくないのよね
GPUへの命令はさすがに手に余るからとりあえずHLSL出力することになると思うけど…

ううーん。とりあえずCに翻訳してコンパイルして、でてきたアセンブリを研究してみようかな
ありがとう

LLVMという選択肢は

本スレは、コンパイラをどのように作るか、ではなく、どのような言語仕様にするか、を重視しています。

コンパイラの話が終わったら、言語仕様の話をしましょう。

LLVM/Clang 実践活用 ハンドブック、出村成和、2014


LLVM 言語マニュアル(Language Reference Manual)
ttp://www.h3.dion.ne.jp/~mu-ra/llvm/LangRefJ.html

日本語訳です。ただし、翻訳は適当と書いてある

>>140,142
奥が深そうだねえ
どれくらいのパフォーマンス出してくれるのか想像つかない

>>141
C/C++並の低レベルプログラミングができて、人間が話せて、かつ人工知能も理解しやすいような言語という設定でいろいろ考えてる
自然言語に声調というのがあって、これは抽象化すれば音階としても処理できるから、人工知能にも扱いやすいし、
音階の配列である声調は命令の配列である機械語とも相性が良い。

LLVMはフロント・ミドル・バックの、3つの部分に独立している
フロントはプログラミング言語とコンパイラ
Clangなら、C/C++ → IR

ミドルはコンパイル後の擬似的なアセンブラ。IR(中間コード)
バックはx86,ARMなどのCPU

新言語を作っているなら、
フロントのコンパイラ(字句・構文解析)の部分だけを作って、
IRになるようにすればよい

>142の本を買うのが速い

>>143
「人工知能も理解しやすい」というのはコンパイラにとって効率が良いという意味？

>>145
人間との会話のときに相互の情報伝達の効率がいいということ
わりと強めの人工知能を想定している

>>146
その効率はプログラミング言語としてどういう意味を持つの？

人口無能を作ってるんでは？

>人間との会話のときに相互の情報伝達の効率がいい

いわゆるドラえもんをつくる気か。すごいな。

何でも良いけど、動作速度がトロくて高級言語がとかぬかして
ジェネリック要求してくるLL使いが鬱陶しいわ

>>1
Cは高級言語だ。
そんなことも知らないのか。

>>147
基本的な記述はより直感的になるし、抽象度の高い表現もそのまま扱える
プログラミングと会話は違うけど、そこをあえて統一した規格で表現できるような言語仕様
>>2にも書いてあるように既存のプログラミング言語にないような機能でプログラム書いてみるの楽しいでしょ

>>149
そうそうそんな感じ

>>152
人工知能とか、ネタなのか本気なのか分からなかったので若干しつこく聞いたけど、本気ならその方針で面白いものへと広げてほしい。

といいながら、興味本位で聞いてしまうけど、人間はともかく、人工知能にとって「直感的」ってどういうことなの？
人工知能ってコンパイラだよね。コンパイラにとっての直感性というのが分からなかったので。

それと、作りたいのは「言語」でいいんだよね？コンパイル可能な自然言語とか。

しゃべればしゃべるほど非マの妄言と化していくな
板違いだべ

>>153
純粋なコンパイラというよりはコンパイラとインタプリタを統合した処理系だね。
Prologのような対話(厳密にはうちの言語のは対話ではないけど似たようなもの)を繰り返してプログラミングすることもできる。
その場合、処理系は対話によって学習できるし、学習したところから発話もするように考えてるから人工知能と呼んでいる。
人工知能にとって直感的っていうのは、手続き型の制御フローに沿った発話がそのままできるってこと。
たとえばうちの言語はそもそも語順がかなり自由だから、手続き型プログラミング的な構文をそのまま人間の言葉として理解できる、とか。

一言で言えば言語だね。芸術言語とプログラミング言語を足したようなものだよ。

>>155
OK。現状ではコンセプトを理解するのが難しいということがわかった。

早く具体的な言語仕様を知りたいので、ぜひその議論を進めてほしい。

>>155
実験言語で終わりそうな悪寒

エプロンおねえさん、めざしてるのかしら

Cは高級言語であって、スレタイがすでに間違ってるのに、お前ら
はあほか、こんなものを続けて何の意味があるんだ。

Cは低級言語だろ何言ってんだ

高水準言語の基準は人間がそのまま動作を読み取れる言語だろ
よってC言語は当然高水準言語

ハードウェアを直接操作できるのが低級、できないのは低脳

高級、低級の呼び名はどうでもいい。C言語を低級言語と呼びたくないならそれでも構わない。そのことに大した意味はない。

スレタイの意味は>>162がほぼ正しい。

>>162の言葉を借りれば、「ハードウェアをオーバーヘッド最小で直接操作できる言語」、それがこのスレで言うところの低級言語。

低級言語という言葉が嫌なら、ハナモゲラでもゲゲボでも好きな呼び方をすればよい。
但し、呼び方を使用する前に、定義を明確にすること。

Cは昔から「高級アセンブラ」と呼ばれていたと思ったが

>>157
どうやっても個人開発だから実験言語までいけばいいところだね。
それでむしろ実用的な最適化とかはちゃんとノウハウのあるところに開発してもらうのが一番いいんだけどな。

高級言語でも低級言語でもないから、中級言語である。
There are following reason that C is called Middle Level Language as:

C programming language behaves as high level language through function, it gives a modular programming and breakup, increased the efficiency for resolvability.
C programming language support the low level language i.e. Assembly Language.
C language also gives the facility to access memory through pointer.
Its combines the elements of high-level languages with the functionalism of assembly language.

So, C language neither a High Level nor a Low level language but a Middle Level Language.

C Programming: Middle level Language
http://cprogrammingcodes.blogspot.jp/2011/12/middle-level-language.html

諸説あるよ

"middle-level language"
Googleで検索

各CPUのアセンブラを勉強しなくていいから、Cは、高級な感じがするが、
オブジェクト指向言語ではないし、セキュリティが不足している（実際は、それもCで達成できるはず）ようにみえるから、
Cは、高級言語ではない。

ID:997Wnr2J には、このスレでCを「高級言語ではない」と呼ぶ権利を与えます。どうぞご自由に。

高級言語ではあるけど、メモリアドレスを直接指定しての書き込みや
必要とあらばインラインアセンブラも使える言語って意味だろ

更にC言語の場合、アドレスの抽象化があまりされていなくて
それらが必要でなくともアドレスを扱うことになるからそう言われるんだろう

高級言語って３０年前の言葉だからな。C/C++より上のいまどきの言語は超高級言語だろ。

肉体労働向け言語に進化しましたから、超高級とかいってるのは

高級言語だから定休知能では扱えないということはなく
むしろ反比例の関係にある

マ板に高級＝デラックスと勘違いしてるやつがいるとは。

ここム版ですが

マイッタ

>>2->>3を読む限り＞1の望みを満たして居るのはかつてとは段違いに美しく高水準に整えられた今時のアセンブラと思われる

愛西市の山本ウィメンズクリニックは、婦人科検診・乳腺内科を診療。また、予防接種外来・注射
六本木レディースクリニック院長 山中智哉のブログ. 六本木レディースクリニックのコンセプトにもなっている不妊治療、婦人科治療、
アンチエイジング治療などについて、いろいろな話題をお届けしたいと思います。 ブログトップ
ケイ・レディースクリニック新宿 (東京都新宿区) の評判
・実績・口コミはCalooでチェック！ユーザによるリアルな口コミ、評判、
ケイレディースクリニック新宿　川越信隆　大阪北
区の堂山レディースクリニックは、性病･性感染症･婦人科･ピル･コンジローム･クラミジア･ブライダルチェック･緊急避妊･人工妊娠中絶･
モーニングアフターピル･プラセンタ･ビタミン･女性ドック･人工妊娠中絶やホルモン異常を専門にしている女性専門医院
仙台市の産婦人科 吉田レディースクリニック. 吉田レディースクリニック 〒981-1105 仙台市太白区西中田2丁目23-5 TEL：022-741-0303
ケイ・レディースクリニック
www5.plala.or.jp/keilacs/&amp;#8206;
お産の好きなドクター募集！！ 一緒にステキなお産をサポートしませんか？ 年齢、勤務条件など相談に応じます. 院宅も完備しています. お問い合わせは 0572−24−5855 まで.

配列を表現する場合無限にメモリーなりCPUなりが利用できる場合リストになるよね
数値の表現も
色々な型がサポートされている時点で低級言語じゃないか
細かいリストや配列の加工操作がしたいんじゃなくて
もっと抽象的に状態に対する結果が欲しい
高級言語と呼ばれるものも抽象化で捉えると低級言語？

各CPUを勉強するのが低級言語

ギガヘルツとか、正気か？　とおもうぞ

何の話？

PCは15年ぐらい前から、スマホは5年ぐらい前から、ギガヘルツ超えのCPUが載ってるけど
電子レンジもWi-FiもBluetoothも2〜5ギガヘルツの電波出してるけど
正気か？　とおもうか？

>>183
衛星とかFWA無線とかもっと速かった気が

ムーアの法則で想定内。

低級言語って
言語の基本機能だけじゃまともなアプリ作るの苦労するって言語ってこと？

低いレイヤにアクセスすることが前提の言語な
プログラミングにおける低級高級は優劣の話ではなくレイヤの話だから

低レイヤってOSやハードウェアと直接やり取りするって感じ？

このスレとは違うが
一般に、低級言語はアセンブリ、C言語以上の言語は高級言語。

超高級言語クレとは言わないけど
高高級言語くらい欲しいって思ってたら有ったっぽい
通常パターンマッチてif文の羅列やネストで重複した論理演算を省略して速度他を稼ぐんだけど
パターンマッチ指向はその常識がないｗ
なんて恐ろしい子
その代わりマッチする条件をダラダラ例記すればよいから
直感的にこの組み合わせおかしいとか修正が楽
なんか条件の検出に正規表現？使っている様な雰囲気ワロタｗ

最適化なしの高級っぽい言語ってマクロの親玉みたいな感じだから
実装は楽じゃないの
デバッグ環境もセットで用意しろと言われるといきなり敷居があがるけど

>>190
おまえ、ここで何言ってんの？

LLVMそのものやん

僕が考えた最強の言語Swift
各言語の構文てんこ盛りで、LLVM介してコンパイルで、>>1が望むものじゃねーか？

どっかのC/C++コンパイラは一度アセンブリのソースに変換してからオブジェクトコードにするって聞いたな

よく分からないならROMっとけよ

>>193
Swiftってデバドラを実用的に書けたりするの？

まっくのでばどらはぜんぶ Swift でかかれるよ

それはすごいね。

C言語用のVMを作ればいいじゃん
GCCがVMの役割を持てばいい

そういうのを言葉遊びという

なんでVMの話が出てくるんだよ。

で、どこまでできたの？

あ

LLVMは大体分かった。GCや例外が大変。
テンプレートを型推論したくてHaskellの型推論読んでみたりしたけど難しい。
Yacc慣れするために、OCamlYaccでトランスレータ書いたりしてて、
今は文法を洗練させようとしてOCamlの別シンタックスを考えてる。
マクロはPHP的な物も検討中だな。
Swiftは悪くないけど、仕様を自分で弄れないからなぁ。

組み込みの構文と違和感なく構文を拡張できればいいね。

大事なのはエラーメッセージが適切な内容になる構造を持たせることと
実用的なデバッガサポートがあること

作るのを優先するとその辺が落とし穴になる

DylanとNemerleや、天才高校生プログラマの言語とか参考になると言えばなるんだけど
結構難しそうなので、Lisp的な式レベルでどうにか簡単な仕組みが作れれば良いなと思ってます。

エラーメッセージやデバッガは、言語機能がしっかり出来上がってからですね。
位置情報埋め込むと構文木が煩雑になるし、デバッガの為の位置情報の埋め込みも同じ。
その辺頑張ると、それだけで大変なので結局今の言語と同じ物しか作れなくなってしまう。
納得いかない文法で、エラーメッセージとか詰めても結局捨てる事になってしまうし。
エラーメッセージも出来れば、グローバライゼーションして、日本語と英語くらいは用意してあると良いけど。
それも含めて、構文拡張が出来て、うまくデバックできてっていうのは難しい。

エラーメッセージは特に、エラー発生箇所と、エラー内容が作っている箇所からは
特定出来ない事が多いので、エラーが発生するようなテストケース作って
エラー内容のテストをしていけば、良くなるんだろうけど、１つ１つ作り込む感じにしないと
出来なさそうなので大変だけど、ちゃんと作ると、それなりに成果があっていいんでしょうねぇ
Rubyが成功している理由ってそういう所もあったのかなぁ？

>>206
それを実現するのに有効な言語的な特性は？

具体的に提案があるとわかりやすい。

おうお前らがモタモタしてるうちにRustが1.0になったぞ
ランタイム&GC不要のメモリ管理、メタプログラミングのための各種機能をゼロ・オーバーヘッドで用意、パターンマッチもついて中々のイケメンに仕上がってるぞ

>>209メジャーな言語と似たものなら大体はいいぞ。関数型はエラーメッセージが分かりにくくて有名だからそれは避けてね

フルスクラッチでcを実装するブログ読んで思わず自分もって感じで始めた
まずは、物凄くシンプルなc言語っぽい仕様書をシコシコ書いてる
実装するまでは中二病に浸れて気持ちいいなこれｗｗ
あと、ここの
http://homepage1.nifty.com/herumi/prog/x64.html
c言語でのレジスタの扱いとか読むと
行儀の良さげなレジスタの扱い方とか参考になる
だけど、一番目の整数引数rcxの下り
一番目が実数だった場合はxm0と言う排他的にrcxもしくはxm0で受け渡すって言う意味なのは
サンプルコードを見るまで理解できなかったｗｗ
vs2013も入れたけどコンパイルしたあとのアセンブラのコード何処で見るのか不明ｗ

>>1
低級なのはお前の頭だろ。

.NETでどうでもよくなったよなー
ていれべるなことなんてほんとしなくなったわ

このスレは言語について議論するスレである。

「.NETでていれべるなことしなくなった」というのはこのスレでは的外れな発言である。

ほんとにいい時代になったよな

>>213 マ板へお帰り

新しい言語に何を求める？

モアパワーそしてモアトルクだ

求めたのは低級言語
出来上がったのは低脳言語
無能が開発すると(以下略

vc++とかgccの吐き出すコードってそんなに酷いかな？
吐き出されたコードがアセンブラレベルで手を加えやすいと助かる
そんな感覚はあるけど、小さい規模なら問題ないけど
規模が膨らむと放棄するしかないような

このスレは言語仕様を議論するスレであって、処理系が吐き出すコード（バイナリ？）に関しての議論はスレ違い。

低級言語ってアセンブラレベルでお手入れができたり
アセンブラに近い処理ができたりCに近い感覚じゃダメなのかね
言語仕様のなかにこれはアセンブラに近い記述でありコードもそれに近いコード
この部分の記述はガベージコレクタを含む重い処理を暗黙で行っていますって感じで
ソースを一見するだけで明確なのが良いのいでは？
変数の宣言でint型をINTと大文字で書いて[0...100]とか範囲指定がある場合とか
var I:INT[0..100]
I=I+101
//一見したときの明確さは変数は大文字、型指定も大文字
//ああ、厳格な範囲検査してるから遅くなるってわかるみたいな

>>220
Objective-C がそんな感じで c / c++ の文法に加えて
コスト大なメッセージパッシングの仕組みを混在させてる

Objective-Cは文法のセンスが致命的に悪い。

>>220
>低級言語ってアセンブラレベルでお手入れができたり
>アセンブラに近い処理ができたりCに近い感覚じゃダメなのかね

それでいいよ。

で、その時に、それをどのような文法で実現するのか、がこのスレの主題。

いま、Cと同じことができる言語を1から考えたら、Cと全く同じ文法にはならないだろう。
それを考えるのがこのスレの趣旨。

Luaはどうよ？

どこのスレの誤爆ですか？

>>224
Luaいいね
色々考えるとLuaの再定義っぽい感じかな
Luaってスクリプト言語に分類されるアセンブラみたい

低級言語だから高級っぽい文法でプログラムを書き下して
コンパイルして一旦アセンブラのソースの形で出力
必要ならここで編集
最後にアセンブラさんにお任せみたいな

アセンブラって基本ラベルとメモリー空間があって
そこにどんな形式のどんなデータが格納されているのかは自己責任って世界だから
ここら辺を援護してくれるマクロアセンブラっぽい物が良いのかな

あえて言おう
rustでおｋ

スレ立てから3年が経った今、時は動き出す
ってことではよ何か作ろうや

最近の名前だけ高級言語スクリプトを見てると仕様も技術者もアホの極地にしか見えん。
その技術者の得意言語でもやっちゃいけないって事を平気でやる

>>229
具体的に知りたいな

逆に超高級言語を作りたいな（´・ω・｀）

今一番超高級な言語って何がありますか？

haskell

依存型のAgda、Coq、Idris、ATSとか

ここは勉強になるスレだぬ
>>233聞いたこと無いので検索してみるｗ
>>232キチぴーご用達なｗｗ

日本語かな

マイナーな言語は習得が大変なことと、わからないことがあったとき情報やノウハウがないので
全部自分で何とかしないといけない。普及している言語の中から好きなのを選んで使いこなすのが一番いいよ。

マイナーだけどメジャーになりそうなら本書いて印税うはうは