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

1 ：デフォルトの名無しさん：2010/03/18(木) 01:37:55

C/C++は高速だが過去のしがらみから文法が致命的に汚い。
C#の文法は洗練されているが中間コードやGCを前提としているため致命的に遅い。
LL系の言語さらに遅い。

そこで、C/C++に代わるOSも作れるような低級プログラミング言語を開発したい。

文法はCに似ている方が望ましいが、
低レベル記述、高パフォーマンス、可読性、簡潔さ、拡張性、学習の容易さ
を担保出来るなら、どんな形式でも構わない。

プログラミングパラダイムについても、オブジェクト指向を備えることが望ましいが
生産性を高めることが出来るのであれば、他の方式が入っても構わない。

2 ：デフォルトの名無しさん：2010/03/18(木) 01:39:11

ガベージコレクションは遅くないよきみはＣ＋＋がどうやってメモリ確保するか知ってるのかい

3 ：デフォルトの名無しさん：2010/03/18(木) 01:40:53

>>2
どうやって確保するの？

4 ：デフォルトの名無しさん：2010/03/18(木) 01:44:06

>>2
遅くないなら現在CやC++に含まれない理由って何なんだろう。

5 ：デフォルトの名無しさん：2010/03/18(木) 01:46:24

ハードリアルタイムだと
GCは実用にならん

6 ：デフォルトの名無しさん：2010/03/18(木) 01:48:02

C のコードを吐く初期の C++ コンパイラ (トランスレータ) みたいなもんでも作れよ。

7 ：デフォルトの名無しさん：2010/03/18(木) 01:50:56

ということで、

GCの無い、過去のしがらみの無い、
高速で、低レベル記述ができる
生産性、可読性、簡潔さ、拡張性、学習の容易さに優れる

言語を作ろう。

8 ：デフォルトの名無しさん：2010/03/18(木) 01:54:34

>>7
つ Pascal

9 ：デフォルトの名無しさん：2010/03/18(木) 01:56:16

Pascalの低レベル記述ってどうなのよ

10 ：デフォルトの名無しさん：2010/03/18(木) 01:57:30

C++を今の技術で１から作り直したらどうなるんだろうな。

11 ：デフォルトの名無しさん：2010/03/18(木) 02:02:28

別にD言語でいいだろ。
それとも構文が複雑すぎてコンパイルに時間掛かるのが嫌で言ってるのか？
asmでもやってろクズ

12 ：デフォルトの名無しさん：2010/03/18(木) 02:11:14

D言語が完成するより
ミッキーマウスの著作権が切れる方が早い

13 ：デフォルトの名無しさん：2010/03/18(木) 02:25:23

>>1
>C#の文法は洗練されているが
おまえは何を言っているんだ？

14 ：デフォルトの名無しさん：2010/03/18(木) 03:32:17

じゃあまずCの文法の汚いところを指摘して、改善案を出すところから始めようか？
どこが汚いの？

15 ：デフォルトの名無しさん：2010/03/18(木) 03:54:18

マクロ

16 ：デフォルトの名無しさん：2010/03/18(木) 04:10:59

C++のプリプロセッサはC++コード本体のセマンティクスの解析が行われる前にトークンレベルで処理が実行される。
美しいと思わんかね。

17 ：デフォルトの名無しさん：2010/03/18(木) 04:14:47

キチガイが出たぞー

18 ：デフォルトの名無しさん：2010/03/18(木) 04:36:20

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

19 ：デフォルトの名無しさん：2010/03/18(木) 07:29:49

D言語でおk

終了

20 ：GV：2010/03/18(木) 10:33:23

いちいち；つけることがとっても汚い

21 ：デフォルトの名無しさん：2010/03/18(木) 11:12:57

じゃぁ()にしようぜ

22 ：デフォルトの名無しさん：2010/03/18(木) 11:36:29

高速性を考えていくとアセンブラに落ちつく

23 ：デフォルトの名無しさん：2010/03/18(木) 11:52:01

D
C99
C++/CLI
Erlang
Go

24 ：デフォルトの名無しさん：2010/03/18(木) 12:04:49

>>1
悪いことは言わない。C/C++系言語の再発明はやめておくべき。
以前調べたことあったんで言うが、どういうわけかC/C++系の亜種は屍の山。
ざっと30...100以上あるんだが。呪いでもかかってんじゃないかってくらい(w

それでもやりたいってなら既存のライセンスの非常に寛大なC系インタプリタを
叩き台として紹介するけど？

25 ：デフォルトの名無しさん：2010/03/18(木) 12:23:17

>>9
それModular系言語では...?

26 ：デフォルトの名無しさん：2010/03/18(木) 12:40:01

>>1
Cは明らかに高級言語だろ
低級言語ってのは1文1命令に対応してるのをいうんだよ

27 ：デフォルトの名無しさん：2010/03/18(木) 12:46:33

・文法はC
・OOP
・テンプレートなし
・標準クラス装備(文字列やコレクションクラスなど)
・GCなし
その他新しい機能不要

これで十分だろ。
どいつもこいつも色々とステップ飛ばしすぎなんだよ。
先ずはコレ。

28 ：デフォルトの名無しさん：2010/03/18(木) 13:40:20

>>27
それ、トランスレータの頃のC++と同じだな。

29 ：デフォルトの名無しさん：2010/03/18(木) 15:04:03

ハードが進化してるのにソフトまで速くしてどうすんだよ

30 ：デフォルトの名無しさん：2010/03/18(木) 15:09:21

>>27
(void*)でOOPすれば十分
と思えないなら継承とテンプレートは必須

31 ：デフォルトの名無しさん：2010/03/18(木) 15:20:13

背後に仮想関数テーブルが必要なものは、Cの用途には向かないと思う。
OOPよりも、Cで欠けている機能は、例外処理を簡潔に書ける構文。

32 ：デフォルトの名無しさん：2010/03/18(木) 15:34:56

longjmpが大暴れ

33 ：デフォルトの名無しさん：2010/03/18(木) 15:51:20

しょうがないから関連スレ挙げてやるよ

新C言語を作ろう
http://pc12.2ch.net/test/read.cgi/tech/1185010023/

ブートストラッピングでコンパイラを作ろう
http://pc12.2ch.net/test/read.cgi/tech/1261910039/

C++ではこういう新しい機能が必要だと思う
http://pc12.2ch.net/test/read.cgi/tech/1173238573/

【信者】C++の問題点【アンチ】
http://pc12.2ch.net/test/read.cgi/tech/1223597633/

Ｃ系列って欠陥言語だろｗ
http://pc12.2ch.net/test/read.cgi/tech/1248205502/

例外機構を考察するスレ
http://pc12.2ch.net/test/read.cgi/tech/1249869471/

34 ：デフォルトの名無しさん：2010/03/18(木) 19:28:03

いまどきtemplateなしとかありえん

35 ：デフォルトの名無しさん：2010/03/18(木) 19:58:00

まじめに話する気ある奴いないみたいね

36 ：デフォルトの名無しさん：2010/03/18(木) 20:02:01

静的型なら、総称型の必要性には疑問を挟む余地は無いように思えるけど
C++のtemplateのことを言っているのなら、それが必要かと言われると？だな

37 ：デフォルトの名無しさん：2010/03/18(木) 21:22:43

C#ってC++とかわんなくね？

38 ：デフォルトの名無しさん：2010/03/18(木) 21:36:43

>>37
記法以外で似ているところを探すのが難しいぐらいだ。

39 ：デフォルトの名無しさん：2010/03/18(木) 21:44:20

Cの亜種のような小さい言語なら大学生の実習でやるだろ。
1はまず適当に作って、こんなのはどう？ってみんなに評価して貰った方がはやいぞ。

40 ：デフォルトの名無しさん：2010/03/18(木) 22:23:47

>>24
C/C++系言語の再発明を目指しているわけではない。

過去のしがらみの無い、
高速で、低レベル記述ができる
生産性、可読性、簡潔さ、拡張性、学習の容易さに優れる言語

であれば、C/C++と似ている必要は全くない。

41 ：デフォルトの名無しさん：2010/03/18(木) 22:36:11

ヘッダーファイルが要らない。

42 ：デフォルトの名無しさん：2010/03/18(木) 23:00:46

いまどきの最適化技術の高さを考えたら、GCさえなかったら、Cとおんなじ
くらいのパフォーマンス出せそう。

43 ：デフォルトの名無しさん：2010/03/18(木) 23:04:22

低級な処理に落とす段階で、C並の効率になるのなら、言語仕様は複雑でも構わないんじゃないか？

けれど、例えばHaskellみたいなのをかなり効率のいいアセンブラコードに変換なんてまず不可能ってことで言語仕様に制限がつくのであって、
言語仕様を制限することそのものには意義がない、ということは忘れちゃいけないな。

そういう意味では、プリプロセッサによるincludeは、あんまりいい処理とは言えないわけだ。
ヘッダファイルにいちいち
#ifndef FOO_H
#define FOO_H
～
#endif
の定型句を書かせる必要はない。
あるいは、>>41のいうようにヘッダファイルそのものがいらないかもしれない。

プロトタイプ宣言だけソースファイルから抜き出すなんてこと、コンパイラにできるはず。

44 ：デフォルトの名無しさん：2010/03/18(木) 23:06:09

まあヘッダは明らかに古臭いと思うよ
モダンな言語で、ヘッダなんて原始的コピペ機構を使ってるのC/C++ぐらいじゃないの

45 ：デフォルトの名無しさん：2010/03/18(木) 23:32:41

最新のプログラミングパラダイムを盛り込んでいながら、C並のパフォーマンスが出させる言語が欲しい。

最近の言語はパフォーマンスを度外視し過ぎ。安易にパフォーマンスを落とす機能を導入し過ぎ。

未だにC/C++以外では現実的にOS作れないわけで。

かと言って、C++は増築増築で言語仕様が巨大過ぎて生産性を下げているし。

そういう意味ではCが一番まともだが、せっかくプログラミング言語研究が進んでいるわけだから、Cに代わるもっと現代風の言語が出てきてもいいだろう。

46 ：デフォルトの名無しさん：2010/03/18(木) 23:39:42

いまどきのオサレ機能ってLispをはじめとする関数型言語由来のことが多くて
GC前提のものが多いような気がするんだが

最新のプログラミングパラダイムって具体的には何が欲しいの

47 ：デフォルトの名無しさん：2010/03/18(木) 23:41:14

まあ関数リテラルや型推論ぐらいは普通にできるか
がんがれ！

48 ：デフォルトの名無しさん：2010/03/19(金) 00:03:33

ヘッダと;は要らない子
あとコンパイルが速いのは絶対条件だろ

49 ：デフォルトの名無しさん：2010/03/19(金) 00:11:47

新言語の条件

（１）シンプルな言語仕様（言語仕様が小さいことで、プログラマーの学習不足によるヒューマンエラーが減る）
（２）低レベル記述可能（OS、デバイスドライバーを作れる）
（３）IDEによる開発支援可能（ソースをあちこち見なくても、ソースを覚えていなくても、プログラムを書ける）
（４）多くのバグはツールが見つける

50 ：デフォルトの名無しさん：2010/03/19(金) 00:26:06

>>49
それってＣじゃね？

51 ：デフォルトの名無しさん：2010/03/19(金) 00:33:51

>>40
そういう用途ならEuphoriaでいいんじゃないの？と思う。
ttp://www.rapideuphoria.com/
ttp://oe.cowgar.com/docs/eu400_0001.html
ttp://9tailfox.web.fc2.com/euphoria/3.1.1/html/ja_jp/overview.htm

少なくとも3.1のDOS32版なら直接低レベル操作できるし、
Cトランスレータ応用(おそらくランタイムライブラリも書き換えて)して
EuphoriaでEuOSなんていうOSを途中まで書いていた人もいた。

>49
まあ解っていると思うけど(言語開発者は自前スキーな人多いから忠告だけど)、
IDEの自前は良くないのでやらないほうがいいよ。周辺ツールも既存のものを使えるようにしたほうがいい。

理由は考えればすくわかるからあえて言わない。

52 ：デフォルトの名無しさん：2010/03/19(金) 01:00:25

>>50
Cは良いと思うが、Cが出来てから長い時間が立っているわけで
最近の研究成果を活かせば、
C程度の言語仕様の大きさで、もっと良い言語ができるんじゃないか？

C1Xはそういう方向性ではないようだし。

53 ：デフォルトの名無しさん：2010/03/19(金) 01:22:25

>>40
生産性を高くするってことは、ある程度の高レベルなロジック記述も支援するってこと?
関数オブジェクトくらいはほしいよね。C の関数ポインタでもいいんだけど、構文がアレ
すぎる。
GC なしならクロージャは無理だろうけど (たぶん)、環境なしでもいいから関数オブジェ
クトを簡単に扱える仕組みはほしいなぁ。

と書きながら、扱い自体は C の関数ポインタでも簡単なのだから、構文さえなんとかす
りゃいいのかということに気づいた。

54 ：デフォルトの名無しさん：2010/03/19(金) 01:30:49

>>53
> 生産性を高くするってことは、ある程度の高レベルなロジック記述も支援するってこと?

Yesだろうね。出来るに越したことはない。
パフォーマンスを落とさない範囲で可能な限りできればいい。

> 関数オブジェクトくらいはほしいよね。C の関数ポインタでもいいんだけど、構文がアレ
> すぎる。

型安全な（とは違っても少なくともコンパイラが誤りを検出可能な）関数オブジェクト（に相当するもの）は欲しい

> と書きながら、扱い自体は C の関数ポインタでも簡単なのだから、構文さえなんとかす
> りゃいいのかということに気づいた。

関数ポインタは構文よりは安全性が問題かな。。

55 ：デフォルトの名無しさん：2010/03/19(金) 01:55:55

>>49
Cの仕様が複雑だとは思わんが、それでも理解不足によるヒューマンエラーは少なくないように見えるぞ。

56 ：デフォルトの名無しさん：2010/03/19(金) 01:59:25

だから、近年の研究成果を取り入れて、C程度のパフォーマンスで、Cよりもヒューマンエラーの少ない言語が欲しい。

57 ：デフォルトの名無しさん：2010/03/19(金) 02:05:11

PHP to C++仕えよ

58 ：デフォルトの名無しさん：2010/03/19(金) 02:07:43

Cに代わる低級言語ってことはポインタ触れるんだろうし
GCも無いんだから、それでヒューマンエラー減らしたいつっても限界あるんでないの

JVMやCLRの上の世界と違って、よく定義された綺麗な型とだけお付き合いしてればいい
というわけにもいかんだろし

59 ：デフォルトの名無しさん：2010/03/19(金) 02:08:45

効率を上げるためには、安全性を犠牲にしないといけないこともあるよな。

例えば、いわゆるLLだと
int a[2];
a[100]=0;
のようなことすると例外なりエラーなりで止まってくれるけど、Cだとメモリ破壊につながるわけだ。

今回のように定数を直接書いてる場合とか、複雑ではあってもコンパイル時間で決定できるものは
コンパイラがエラー出すこともできるけど、動的なものの場合は実行時にチェックするか、あるいはチェックしないで危険を冒すことが必要。

個人的には、配列の境界チェックはプログラマの責任にして動的チェックはしないようにしてほしいが、
メモリアロケーションの失敗とファイルオープンの失敗は自動チェックしてほしいかも。

そのへんの匙加減って、どうすればいいんだろう。
理想を杓子定規で当てはめた結果、誰も喜ばない仕様を作り出す過激派になったり、
毎度毎度細かい仕様で答えのない泥仕合になったりしない方法なんてあるのかなぁ。

60 ：デフォルトの名無しさん：2010/03/19(金) 02:11:30

vc++は勝手に配列チェックして例外出る
リリースでも

61 ：デフォルトの名無しさん：2010/03/19(金) 02:16:13

>>60
そんなんされたら、高速化のためにループ中での条件分岐を減らすとかの努力が水の泡ですがな……

62 ：デフォルトの名無しさん：2010/03/19(金) 02:54:56

nullを

63 ：デフォルトの名無しさん：2010/03/19(金) 03:14:48

新しい言語を作ったとして、IDEへの対応は簡単なのかな？
たとえばeclipseのプラグインをかくとか、どのくらいの難易度なんだろう。
そもそもそれで対応できるとか全然知らないけど。

64 ：デフォルトの名無しさん：2010/03/19(金) 03:28:17

もうプログラムで速度を追求する時代は終わったのだよ

65 ：デフォルトの名無しさん：2010/03/19(金) 03:48:26

>>63
言語仕様やコンパイラ作れる能力がある人には、退屈な単純作業にしか思えないくらいの低難易度。

66 ：デフォルトの名無しさん：2010/03/19(金) 03:53:36

>>64
それはあまりに視野が狭すぎないかい？
科学計算とか、動画エンコードとか、まだまだいくらでも速度を追求したいプログラムはある。

けれど、大体の部分では速度を追求する必要がない時代に来ているのは事実。
LLとの連携強化だったり、ヘビーな高級ライブラリをboostやstlのようなポジションで用意するのはいい判断かもしれない。

67 ：デフォルトの名無しさん：2010/03/19(金) 03:56:08

PHP to C++があればいい。
ライブラリ不足さえ解消されればC++に問題はない。
PHPから変換できて、上級者はC++をいじくるようにする。
Hiphop phpというのがあるがvc++では今は動かないようだ。

68 ：デフォルトの名無しさん：2010/03/19(金) 03:58:13

HipHopはCentOSとFedora向けに開発されており、他のオペレーティングシステム上でのビルドは現在のところ機能しません。他のオペレーティングシステム向けのサポートは準備ができ次第追加されます。
http://blog.candycane.jp/archives/295

69 ：デフォルトの名無しさん：2010/03/19(金) 07:05:29

PHPは、言語としてだめでしょ

70 ：デフォルトの名無しさん：2010/03/19(金) 07:42:00

言語としてはちょっとと思うところはある。
しかし普及しているのでこれをメイン据えるのが良いと思う。
新規の言語開発するより低コスト。　仮に作ったところでPHP以下になる。
基本的には、C++のスクリプト板みたいな物だから少々手を加えればC++になる。

71 ：デフォルトの名無しさん：2010/03/19(金) 07:44:06

言語使用と性能は関係無いと
デルファイの開発者が行ってた気がする。
パスカルは教育用と見なされていた。
しかしデルファイは、デルファイで書かれているらしい。

72 ：デフォルトの名無しさん：2010/03/19(金) 09:52:58

>>61
もちろん嘘だから気にスンナ

73 ：デフォルトの名無しさん：2010/03/19(金) 11:06:23

セミコロンがいらないとか言っている人ってどうすればいいと思っているのかな？
1. 別の記号にしたい
2. 一行1命令
3. 1ブロック1命令
4. 予約語が来たらなんでも命令の区切り
5. 言語に冗長性を持たせて、構文的に命令の切れ目がわかる

74 ：デフォルトの名無しさん：2010/03/19(金) 12:39:42

6. 一行に2命令以上書く時だけセミコロン要求

75 ：デフォルトの名無しさん：2010/03/19(金) 12:47:07

ここまでForth無し。
Forthそのものである必要は無いけど、低級でも良いから高速な言語というのならスタック指向がいいんじゃね？

76 ：デフォルトの名無しさん：2010/03/19(金) 12:47:45

>>58
> Cに代わる低級言語ってことはポインタ触れるんだろうし
> GCも無いんだから、それでヒューマンエラー減らしたいつっても限界あるんでないの

それはお前の思考の限界だろ。まあ俺もそうだが。
どこかの頭の良い人間が解決するかもしれないし、もしかしたら既に解決しているかもしれない。
それを期待したい。

77 ：デフォルトの名無しさん：2010/03/19(金) 12:52:04

>>70
そもそも、PHPでは速度以外の面でCの代わりはできないよ

78 ：デフォルトの名無しさん：2010/03/19(金) 14:40:48

要は、

　　　　　目くそ鼻くその類似スクリプト言語ばかり安易に量産してないで

　　　　　これまでCが担ってきたOSやデバドラ開発の分野でも使える言語を

　　　　　最新の言語研究成果を取り入れて新しく作れ

ということだ。

79 ：デフォルトの名無しさん：2010/03/19(金) 14:52:49

>>77
Cの代わりがだめなら、プリプロセッサの代わりのcpphpをつくるんだ
<define id="NULL">0</define>
XMLが古臭くなるまで、これでしのげる

80 ：デフォルトの名無しさん：2010/03/19(金) 16:55:15

>>78
つかねぇ。漠然としすぎて、どうしたらいいか迷走していると思うんだが。
このままだと埒明かないから、まず言語名と言語族を決めて言語仕様書いたほうがいいんじゃないか？

とりあえず名前から。
このスレが立てられたのは3/18なので、とりあえず言語名のヒントになりそうなもの

Wikipedia(3/18) : ttp://ja.wikipedia.org/wiki/3%E6%9C%8818%E6%97%A5
誕生花 : とさみずき、アネモネ、折鶴蘭、ハナミズキ、イワウチワ、フロックス、アスパラガス...など
誕生石 : アレキサンドライト、エマイユ、アクアマリン...など

81 ：デフォルトの名無しさん：2010/03/19(金) 18:32:28

2言語

82 ：デフォルトの名無しさん：2010/03/19(金) 19:34:25

言語名に「言語」と付くプログラミング言語はあまりないけどな

83 ：デフォルトの名無しさん：2010/03/19(金) 19:39:22

>>81
検索しにくい、発音しにくい、変なのはやめておいたほうがいいと思う。
ある意味でネーミングは駄洒落と連想ゲームなので、>>80の誕生花と
3月の旧暦(ttp://ja.wikipedia.org/wiki/3%E6%9C%88)を引っ掛けると、

3月 = 三月 = 花美月 = みづき → mizuki programming langage

とかなる。あとは接頭辞に適当なものを当てて
MInimum Z-layered Useful development Kit(最小Z層実用開発キット)

といった風になる(文法としては滅茶苦茶だけど)。
Zの意味は究極、最強、低級といったところかと。

84 ：デフォルトの名無しさん：2010/03/19(金) 19:43:24

Ｃをもっと拡張して、クラスの概念を取り入れたら、良い言語ができるんじゃないかな。

85 ：デフォルトの名無しさん：2010/03/19(金) 19:45:33

C++ Alternative 2ch-otaku Style

86 ：デフォルトの名無しさん：2010/03/19(金) 20:09:36

これ見よがしに日本人が作ったんだとアピールするために日本語名にするべき

87 ：デフォルトの名無しさん：2010/03/19(金) 20:25:18

これ見よがしに、ヘッダをXMLにする案をスルーしてませんか？

88 ：デフォルトの名無しさん：2010/03/19(金) 20:55:52

XMLならS式の方がいいな。

89 ：デフォルトの名無しさん：2010/03/19(金) 21:00:53

名前なんかよりコンセプトを考えようぜ。
スピード重視というなら手続き重視・スタック重視・静的動作になるけど、どうするのよ？

>87
XMLはクソ。S式の方が100倍マシ。

90 ：デフォルトの名無しさん：2010/03/19(金) 21:04:23

言語と速度は関係無い。
C#やjavaやPHPですら、
最適化されたネイティブアセンブラに翻訳出来ればC言語に勝る。
コンパイラの性能次第。
言語使用はすでにあるやつで良いだろう。
php c# ruby バイソン　java c++使いやすいやつを受け継げよ。

91 ：デフォルトの名無しさん：2010/03/19(金) 21:04:44

>>89
> スピード重視というなら手続き重視・スタック重視・静的動作になる

これは現在の最先端の人類の知識で最も確からしい帰結なの？
それとも単なる素人の妄想？

どっち？

92 ：デフォルトの名無しさん：2010/03/19(金) 21:06:16

共通言語を開発して、多言語に
コンバートできる仕組みを作れば需要あるな。
出来るだけ簡易に記述が出来るなら。

93 ：デフォルトの名無しさん：2010/03/19(金) 21:06:52

>>90
> 最適化されたネイティブアセンブラに翻訳出来ればC言語に勝る。

それでは、今なぜやらないのか？

できないからだ。

94 ：デフォルトの名無しさん：2010/03/19(金) 21:07:59

コンパイルに時間掛かっちまうだろ

95 ：デフォルトの名無しさん：2010/03/19(金) 21:09:20

掛ければいいだろ。

96 ：デフォルトの名無しさん：2010/03/19(金) 21:10:16

手間かかるからな。
マイクロソフトでは、C#からネイティブexe作り出すコンパイラ作ってる気がする。
Hiphop for phpはC++のコードはき出す。

97 ：デフォルトの名無しさん：2010/03/19(金) 21:13:41

ネイティブよりも、JITコンパイルの方が速くなることも原理的にはある。
そもそも、Cに代わるものというところでは、速度意外に必要なことがあるだろ。

98 ：デフォルトの名無しさん：2010/03/19(金) 21:14:29

ネイティブexeができることと、Cと同等のパフォーマンスを出せることは全く別の話だろ。

99 ：デフォルトの名無しさん：2010/03/19(金) 21:15:31

安全性と生産性の向上

100 ：デフォルトの名無しさん：2010/03/19(金) 21:18:53

いまどきパフォーマンスのボトルネックになるのはDBアクセス、ファイルアクセス、通信等であって
いずれも言語は関係ないな

101 ：89：2010/03/19(金) 21:19:00

>91
素人なんで最新の情報は追えてないけど、
・最新のCPUの動作は基本手続きだろ。関数型のCPUは見たことがないよ。
・メモリ確保・解放でスタックよりも軽いのも知らないなあ。
・動作時よりもソースコード時点でたくさんの情報があったほうが最適化しやすいだろ。
　（もちろん、JITも併用した方がいいだろうけど）
じゃね？

102 ：デフォルトの名無しさん：2010/03/19(金) 21:21:36

何か他言語をベースにすること自体には異論はないが、
それとは別に、他言語(できるだけ言語を限定することなく、広く)との連携のしやすさは重視してほしい。

>>90
言ってること自体は正しいかもしれんが、そんな素晴らしいコンパイラを作る方法が現状見つかっていないからさてどうしましょう？って言っている段階。

>>87
XMLにするとどんないいことがある？
そもそもヘッダ自体が必要かどうか微妙なのに。

103 ：デフォルトの名無しさん：2010/03/19(金) 21:25:48

>>100
DB、ファイルシステム、通信ドライバはC/C++で記述されてるだろ。

DB、ファイルアクセス、通信を使うような上位プログラムは
LLでもHaskellでもC#でも今時の烏合のRAD系言語を使えばいい。

104 ：デフォルトの名無しさん：2010/03/19(金) 21:26:46

>>100
そのボトルネックになるところはCで書かれてますよ＾＾

105 ：デフォルトの名無しさん：2010/03/19(金) 21:37:45

>>100
いつの時代も巨大ループや多重ループはボトルネックになる。
計算のオーダがたとえ多項式オーダでも2乗3乗となってくると、
1個1個の処理が少し軽くなるだけで高速化の成果を実感できるようになる。

>>89
スタック利用、動的な処理は最小限に抑えてコンパイル時実行できるものを増やすというのは、外せないよな。

関数型言語に関してはほとんど知らないんだけど、純粋関数と静的処理って極めて相性がいいんじゃないのか？
あと、クラッシュバンディクーってゲームの一部がLispでかかれてるってのは、そこそこ有名な話。
関数型言語で書いてコンパイラが手続き型に翻訳するってのは非現実的な話なのかなぁ？
エロい人教えて

106 ：デフォルトの名無しさん：2010/03/19(金) 21:39:24

>>102
XMLは具体的で現実的
古臭いとかいう先入観で敬遠される可能性が低い

もちろん、ヘッダを無くす素晴らしい方法が具体的にあるなら、そのほうが良い
そもそも、古臭くても構わないというなら、今のCのままでも良い

107 ：デフォルトの名無しさん：2010/03/19(金) 21:42:38

単にネイティブコンパイル可能な関数型というだけなら別に珍しくも何ともないよ
パフォーマンスは
ttp://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php
この辺を見ればいい

108 ：デフォルトの名無しさん：2010/03/19(金) 21:47:53

人間が手続き型で逐一こうしてこうしてと書くよりも、
関数型や論理型のようにある程度大雑把にこうしたいと指定してコンパイラに頑張ってもらった方が大抵は早くすることができるだろう。

ただ、大雑把な指定では致命的に遅いことが容易に指示できてしまうことが問題。
処理の99%を10000倍早くできても、残りの1%が1000倍遅くなったら、全体は10倍遅くなるからな。
（0.99 * T/10000 + 0.01 * T*1000 ≒ 10*T）

そのあたりのバランスを上手く取って生産性とパフォーマンスを両立出来る言語が欲しいところだ。

109 ：デフォルトの名無しさん：2010/03/19(金) 21:53:53

>>108
俺は「低水準」が第一要求なのかと思ってたが
早い話が、ドライバやkernelのようなものが書けるということ

その方向性だと、また別物にならないか？
早い話が、少なくともメモリアドレスを隠蔽する程度に抽象度が高い言語では
ドライバは書けない

110 ：デフォルトの名無しさん：2010/03/19(金) 22:02:52

>>109
目的を絞ろう。まずは、
「最新のプログラミング言語研究成果を取り入れたドライバやkernelを掛ける言語」
でいいだろう。

>早い話が、少なくともメモリアドレスを隠蔽する程度に抽象度が高い言語では
>ドライバは書けない

これは現在の最先端の人類の知識で最も確からしい帰結なの？

通常は隠蔽されていて、必要なときに実アドレスを取り出せるようになっていればいいのでは。
もちろん、隠蔽せずに生産性の高い、安全性の高い記述をする手法があれば越したことはないが。

111 ：デフォルトの名無しさん：2010/03/19(金) 22:12:24

C++にいろいろと関数を標準でつけて、GUI作成も標準でつけて
面倒をなくせばOK。
C# PHP HSPの関数や簡単な記述法を持ち込めばいい。
C++ωにしておくか。

112 ：デフォルトの名無しさん：2010/03/19(金) 22:15:58

C++/CLI はどうだ

113 ：デフォルトの名無しさん：2010/03/19(金) 22:16:38

>>110
> 通常は隠蔽されていて、必要なときに実アドレスを取り出せるようになっていれば
> いいのでは。

.NETはまさにそういう仕様だが、ポインタはGC管理されているので、ロックないし
マーシャリングが発生する
低レベルなコードを扱うのだから、現存のCのobjやasmのコードと簡単に
協調できるようでなければならない

スレタイは「C/C++に代わる低級言語が開発したい」でしょ
それ以下で使われているのは現状アセンブリ言語しかないのだから、
C並に低級なことがC並に簡単にできるのでなければ、取って代われるはずは無いと
思うけど

114 ：デフォルトの名無しさん：2010/03/19(金) 22:18:43

>>111
ただでさえ複雑なC++をこれ以上肥え太らせるって正気か
大体、GUI作成標準って、組み込み用途はどうすんだ

115 ：デフォルトの名無しさん：2010/03/19(金) 22:19:36

>>112
それは簡単になっているとは言い難い。
それならc#使った方が良い。
STLとNETでかぶるってるしわかりにくい。

116 ：デフォルトの名無しさん：2010/03/19(金) 22:19:46

C++を正しいレールにのせた言語でいい

117 ：デフォルトの名無しさん：2010/03/19(金) 22:22:25

>>114
複雑と思う仕組みは使わなければすむ。C++をC言語として使うことも可能。
その複雑な仕組みで開発されたPHPやRubyも複雑か?
便利な機能を取り込んで不要な機能を使わなければすむ。

118 ：デフォルトの名無しさん：2010/03/19(金) 22:24:19

>>117
ttp://yosefk.com/c++fqa/defective.html
ここでも見ればいいんじゃないか？

Rubyは複雑性を（なるべく）隠蔽している
C++は複雑性のはらわたが丸出しだ

119 ：デフォルトの名無しさん：2010/03/19(金) 22:24:50

どんどん取り込んで、web、GUI、ゲームもこれ一本で済むようにする。
C++がサーバーで動く標準なり、他所でも同じコードがそのまま動くようにする。

120 ：デフォルトの名無しさん：2010/03/19(金) 22:25:18

>>113
> .NETはまさにそういう仕様だが、ポインタはGC管理されているので、ロックないし
> マーシャリングが発生する

だから、パフォーマンスの問題を解決できないのであればGCは使わない。

> 低レベルなコードを扱うのだから、現存のCのobjやasmのコードと簡単に
> 協調できるようでなければならない

そのとおり。そういうことができるような言語仕様にしよう。

> スレタイは「C/C++に代わる低級言語が開発したい」でしょ
> それ以下で使われているのは現状アセンブリ言語しかないのだから、
> C並に低級なことがC並に簡単にできるのでなければ、取って代われるはずは無いと
> 思うけど

だから、そういうことができるような言語仕様にしよう。
そのときに、最新のプログラミング言語研究の成果を取り入れてCより生産性を上げたい。

121 ：デフォルトの名無しさん：2010/03/19(金) 22:27:12

GCもいれてオプションで切り替えられるようにして、インタプリタ動作も出来るようにする。
C++のコードのままでもそれは可能。

122 ：デフォルトの名無しさん：2010/03/19(金) 22:27:22

>>118
はらわた丸出しで腹捩れるほど笑ったｗｗｗｗｗｗ

123 ：デフォルトの名無しさん：2010/03/19(金) 22:28:19

>>117
「使わなければ済む」のであれば、constもassertもいらないんだよ。
何らかの強制的な制約がなければ必ず発生する。

124 ：デフォルトの名無しさん：2010/03/19(金) 22:41:26

C++は改良されてきているとは言えベースは30年以上前に作られた言語だからな。
この30年の間に開発された手法を使ってより良いスマートな言語が作られてもいい頃だとは思う。
Cなら尚更だ。

125 ：デフォルトの名無しさん：2010/03/19(金) 22:49:04

とりあえずC++からC互換性や歴史的制約を取り除いた言語をC/C++の委員会メンバーが
作成してISOに提案してくれればいいよ。言語名はCleanC++で。
問題は彼らにそんな金も時間もなく、かつC++はまだ進化半ばであることだ。

126 ：デフォルトの名無しさん：2010/03/19(金) 22:52:52

>>125
誰得のそんなものはいらないな。

127 ：デフォルトの名無しさん：2010/03/19(金) 23:45:26

じゃあ我々には出来ることはありませんね

128 ：デフォルトの名無しさん：2010/03/19(金) 23:56:52

イメージとしてJavascript位の文法でカーネル書けるようになればいいのにな。

129 ：デフォルトの名無しさん：2010/03/19(金) 23:57:35

ム板のスーパーハカーがさくっと叩き台つくればいいやん。

130 ：デフォルトの名無しさん：2010/03/19(金) 23:58:48

c や c++ をスマートで記述性も高いと思わない人って居るの？

131 ：デフォルトの名無しさん：2010/03/19(金) 23:59:15

イメージとしてScheme位の文法でカーネルが掛けるようになって欲しい。

132 ：デフォルトの名無しさん：2010/03/20(土) 00:00:05

>>128
JavaScript は c より複雑じゃんｗｗｗ

133 ：デフォルトの名無しさん：2010/03/20(土) 00:01:51

Javascriptには、ヘッダファイルがないし、マクロもない、シンプルだろ？

134 ：デフォルトの名無しさん：2010/03/20(土) 00:06:30

こいうのを税金使ってやればいいんじゃないの？

135 ：デフォルトの名無しさん：2010/03/20(土) 00:08:04

税金使って低水準Prolog作ってもいいよ。

136 ：デフォルトの名無しさん：2010/03/20(土) 01:01:40

>>131
つうか、そんなのはC++でカーネルが書けるのも一緒だが中間言語的役割を
果たすに過ぎないし、今でも作る気なら作れる。意味が無いだけでｗ

137 ：デフォルトの名無しさん：2010/03/20(土) 01:10:06

Scheme位の文法って、文法の規模のことだろ

138 ：デフォルトの名無しさん：2010/03/20(土) 01:27:07

文法の規模を単純化したいって意味で言ってるなら、
アセンブラを高級言語に近づけた方がいいかもなｗ

139 ：デフォルトの名無しさん：2010/03/20(土) 01:28:56

それならForthライクな言語だろ。concatenative languageかもしれないけど。

140 ：デフォルトの名無しさん：2010/03/20(土) 01:54:16

Objective-C は？

141 ：デフォルトの名無しさん：2010/03/20(土) 02:19:54

ObjectiveCは恐ろしい言語だぞ！ｗ

142 ：デフォルトの名無しさん：2010/03/20(土) 02:29:12

Cycloneのruntimeを書き換えて手動メモリ管理できるunsafeモードを付け加えるとかじゃだめ？

143 ：デフォルトの名無しさん：2010/03/20(土) 02:32:22

>>138
結果的に既存の何かに似ているものになるのかもしれないが、
はじめから既存の何かから始めるアプローチはとるべきじゃない。

先ずは先入観を持たずに、一から新しい言語を作る事を考えるんだ。

144 ：デフォルトの名無しさん：2010/03/20(土) 02:40:08

>>143
その通り、だからCPU側からアプローチしようよｗ
高級言語からアプローチしても、ＯＳを作れる（つうか問題なのはデバドラ）
レベルのものにはなるまい。ノイマン型が滅びるその日までｗ

145 ：デフォルトの名無しさん：2010/03/20(土) 03:02:54

>>144
どうぞ別スレで行ってください。応援します。

146 ：デフォルトの名無しさん：2010/03/20(土) 03:16:24

>>144
第N世代コンピューターでも作ってProlog++でも開発してろ。

147 ：143：2010/03/20(土) 03:23:45

すまん飛びすぎたorz

148 ：デフォルトの名無しさん：2010/03/20(土) 03:24:46

144だ、もう酔いすぎだなｗ

149 ：デフォルトの名無しさん：2010/03/20(土) 04:25:30

PHPの文字列のなかに変数埋め込める機能は使えるな
Cだと面倒なんだ

150 ：デフォルトの名無しさん：2010/03/20(土) 07:34:42

ここは中学２年生のスレか

151 ：デフォルトの名無しさん：2010/03/20(土) 09:20:53

この手の話って時々出るけど、結局Cにはかなわないわけですよ。
Cをやってると、確かにいろいろな欠点、たとえば、マクロの仕様が適当だとか、staticの用途が複数あるとか、
プロトタイプ宣言がめんどくさいとか、関数のデフォルトがグローバルだとか、が目に付いて、もっと洗練された
高速な言語は作れないものかと考えてしまいがちなんだけれど、その辺を直してもしょせんは「亜流C」が
出来上がるだけで、それまでのCに慣れたプログラマが乗り換えるほどの価値のあるものにはならない。

この話は、「バイオリンは音は素晴らしいけれど、演奏の習得が大変なので、新しい技術を取り入れた
バイオリンを作ろう」っていう話に似ていて、結局こっちもうまくいかなくて（せいぜい、ピックアップをつけた
エレキバイオリンがある程度）、４００年前の仕様のままで演奏している。仕様変更してもたいした効果が
ないので、放置ってわけだ。

LL言語なら速度を度外視して、配列のサイズチェックやら、継承やらなんやら好き勝手に盛り込めばいいけど、
それの真似をすればするほどCの哲学である、簡潔さ、高速さ、プログラマが書いたままに動くこと、から
遠ざかっていく。

というわけで結論：ムリ。

152 ：デフォルトの名無しさん：2010/03/20(土) 09:47:23

そしたらまず、なんでRubyでOSが書けないのかを具体的に理由を挙げてみたら？

153 ：デフォルトの名無しさん：2010/03/20(土) 10:30:47

OSがどのように起動するのか知らないんだろうな

154 ：デフォルトの名無しさん：2010/03/20(土) 10:37:00

152みたいなやつには、説明は難しい

155 ：デフォルトの名無しさん：2010/03/20(土) 11:48:29

>>138
それだと、C構文を持つ低級言語としてC--なんて言語もある。
ttp://www.goosee.com/cmm/
ttp://www.cs.utexas.edu/users/tbone/c--/
ttp://sourceforge.net/projects/c--/
ttp://c--sphinx.narod.ru/indexe.htm

さらにアセンブリ言語風の文法を持つトイ言語としてEcstasy/Yaalなんてのもある。
> EcstasyYaal is a programming language with low level assembly-like syntax. It differs in that it is designed to be toyed with without worry of damaging the system, while keeping some of the feel of writing assembly.
http://sourceforge.net/projects/ecstasy/

156 ：デフォルトの名無しさん：2010/03/20(土) 11:54:09

低級といえばZincという言語もあるんだっけな。
ttp://tibleiz.net/zinc/

157 ：デフォルトの名無しさん：2010/03/20(土) 11:59:17

大昔はTurboPascalでもブートセクタが書けたけどな

158 ：デフォルトの名無しさん：2010/03/20(土) 12:04:47

>>157
Turbo Pascalはポインタもあるので、C並みのことはできるんじゃないか

159 ：デフォルトの名無しさん：2010/03/20(土) 12:14:16

>>158
C並みっつうかIO制御もできたし、インラインアセンブラも書けたし衝撃だった。
「Pascalって凄い低級言語じゃねえか！」と勘違いするくらいｗ

160 ：デフォルトの名無しさん：2010/03/20(土) 12:48:22

上でクロージャの話が少し出ていたけど
C++0xのlambdaは
http://ja.wikipedia.org/wiki/C%2B%2B0x#.E3.83.A9.E3.83.A0.E3.83.80.E9.96.A2.E6.95.B0.E3.81.A8.E3.83.A9.E3.83.A0.E3.83.80.E5.BC.8F
を読む限りでは
1. 環境はキャプチャできるが、キャプチャする変数を手動で指定する必要がある
（透過的ではない）、ふべん！
2. GC頼みの無限エクステントがあるわけではないので
　変数をキャプチャする際に、コピーするか参照するか指定する
　高機能！
3. スタック上の変数を（コピーではなく）参照しているクロージャを
　戻り値としてリターンした場合の挙動は当然未定義
（upwards funarg problemってやつ）
4. 構文がキモいですが何か？
5. lambdaの型がとにかくキモくなるのでautoやfunctionテンプレート必須？
という感じのようですね
さすがC++です

161 ：デフォルトの名無しさん：2010/03/20(土) 16:04:06

>>153-154
ある程度わかった上で、書いている。
ただ、その低級言語とやらを作る上での、最小の仕様を見つけるためにはそれが必要だと思っただけだ。
あと、Rubyってのは一例であって、別にRubyじゃなくても何でもいい。そもそも俺Rubyつかえねーし。

例えば、インタプリタ言語じゃOSどうやって起動するんだよ、ってのがまずある。
当然、ネイティブコードにコンパイル可能ってことは最低条件になるわなぁ。
(コンピュータサイエンス的意味でのできるできないじゃなく、現実的に実装可能という意味で)

で、じゃあRubyがネイティブコードにコンパイル可能になったとすれば、それでOSができんのか？まだ不十分だろ？
だったら、あとは何が必要か？って話がしたいわけ。
OSないとRuby動かねぇｗｗｗはい論破ｗｗｗなんて話はどうでもいい。

162 ：デフォルトの名無しさん：2010/03/20(土) 16:05:56

ＰＬ／Ｉなんてｄぴだろう

163 ：デフォルトの名無しさん：2010/03/20(土) 16:38:04

>151, 161
だからforth……smalltalkもほとんどOSだよな。

自分だけの知識が世界の全てだと思っちゃいかんよ。
それにOS開発が主目的じゃないだろ。

164 ：デフォルトの名無しさん：2010/03/20(土) 17:21:22

いま、C/C++が無かったとして、
現在の最高のプログラミング言語設計者を集めて
「OSを作るから最先端の研究成果活かしてプログラミング言語作ってよ」って頼んだだら
どういうプログライング言語を作るだろうか、って観点で考えてみるといい。

「XXがあるからいいじゃん」とか、「YYから乗り換えるほどの価値がどうのこうの」とかは、無意味。
そもそも前提が違う。そういうXX、YYが存在しない前提で考えたい。

165 ：デフォルトの名無しさん：2010/03/20(土) 17:30:00

そんなオレオレルール勝手につくられてもｗ
Cが無いプログラミングの世界なんて想像不可能です

166 ：デフォルトの名無しさん：2010/03/20(土) 17:30:34

まずC/C++のいけ好かない点を列挙するとかは？

167 ：デフォルトの名無しさん：2010/03/20(土) 17:31:29

{} ; が醜い

168 ：デフォルトの名無しさん：2010/03/20(土) 17:46:54

Cの短所なら>151にいくつか挙げられてるが

169 ：デフォルトの名無しさん：2010/03/20(土) 17:53:03

「おれの考えた最強言語」みたいな妄想スレっていろいろあるけど
実物ができたためしがない。

170 ：デフォルトの名無しさん：2010/03/20(土) 17:55:48

関数が第１級オブジェクトじゃない

171 ：140：2010/03/20(土) 18:07:25

>>141
レスありがとう
勉強不足だったよ

172 ：デフォルトの名無しさん：2010/03/20(土) 18:13:26

Cの短所を挙げるより、低級言語として何が必要かを挙げる方が、いいんじゃね？

先入観なく考えうる最高の低級言語を考えればいいわけだから。

173 ：デフォルトの名無しさん：2010/03/20(土) 18:23:17

必要な物ならCに揃ってるんじゃないのか？

174 ：デフォルトの名無しさん：2010/03/20(土) 18:30:53

>>1
そのとおり。
そこで、それは何であるかを明らかにし、
最新のやり方でCよりも優れたやり方でそれを実現したい。

175 ：デフォルトの名無しさん：2010/03/20(土) 18:48:50

ところで、ここで「作りたい」と言ってる人間（>>1 含めて）は、当然
CないしC++で最低限何か成果物出してる人なんだよね？

GC言語しか使えない人間がなんとかして難しいと感じてる言語を回避しようとしてる
スレではなくて

176 ：デフォルトの名無しさん：2010/03/20(土) 19:05:12

成果を出してる人間でも、成果を出してない人間でも、そんなのどちらでもいいよ。

C/C++に代わる低級言語を開発したい意志があれば、是非意見を述べて欲しい。

177 ：デフォルトの名無しさん：2010/03/20(土) 19:08:57

だから無理だっていってんだろ

178 ：デフォルトの名無しさん：2010/03/20(土) 19:09:55

無理な人間はあえて参加しなくてもいいのにね＾＾

179 ：デフォルトの名無しさん：2010/03/20(土) 19:22:01

じゃあ言い方を変えよう。
やれるもんならやってみろ。生暖かく見守っててやるよ。

180 ：デフォルトの名無しさん：2010/03/20(土) 19:42:37

低級言語というなら
◎メモリなどのH/Wへの高速アクセス手段
◎軽量なフロー制御
◎アトミック処理
◎リアルタイム性
辺りは欲しいかねぇ。後半はC/C++にも無いけど。
他にはどんなのが必要かな？

181 ：デフォルトの名無しさん：2010/03/20(土) 19:49:31

このあたりを言語としてあまりオーバーヘッドなくうまく扱えるようになってると便利かな。

・マルチスレッド
・割り込み処理
・メモリ管理
・物理アドレス

ライブラリでの対応でもいいけど、その場合は、
もともと言語に備わっている機能とライブラリで提供される機能が区別なく使えるのが望ましい。

182 ：デフォルトの名無しさん：2010/03/20(土) 20:04:37

先ずは、構文糖一切なしのベースとなるプリミティブな言語仕様を定義したいね。

その上で、あとから定義した機能がもともと言語に備わっている機能のように扱えるといいかも。

183 ：デフォルトの名無しさん：2010/03/20(土) 20:19:19

まずはbrainfuckから始めろということね

184 ：デフォルトの名無しさん：2010/03/20(土) 20:25:32

brainfuckは低水準処理のため効率的な記述ができないから不十分だろう。
やろうと思えばできるというだけではなく、効率的にできることが重要だから。

185 ：デフォルトの名無しさん：2010/03/20(土) 20:31:38

>>184
効率的なって何言ってんだあんた
あんなもんで何一つ書けやしないよ
ためしにあれで電卓でもつくってみ。絶対つくれないと思うけど。

186 ：デフォルトの名無しさん：2010/03/20(土) 20:35:42

あの、brainf*ckはTM等価なんですけど……

187 ：デフォルトの名無しさん：2010/03/20(土) 20:38:04

だから書いてみろって
絶対書けないから

188 ：デフォルトの名無しさん：2010/03/20(土) 21:36:20

>>185
>>184に言うなよ。>>184はbrainfuckを肯定してないだろ。>>183に言え。

189 ：デフォルトの名無しさん：2010/03/20(土) 21:36:20

さすがに自分で組む気は無いなぁ
ttp://www.unkar.org/read/pc11.2ch.net/tech/1177988460

190 ：デフォルトの名無しさん：2010/03/20(土) 22:17:01

俺もデバドラ開発でＣじゃない新しい言語使ってみたいよ。

191 ：デフォルトの名無しさん：2010/03/20(土) 22:25:30

奴隷は一生C使ってろｗｗｗｗ

192 ：デフォルトの名無しさん：2010/03/20(土) 22:28:35

一生使うならCよりもっと良い言語を使いたい。

193 ：デフォルトの名無しさん：2010/03/20(土) 22:28:51

Cと今、普通に使われている高級言語の大きな違いは、言語自体にランタイムが必要か必要でないかの違いがある
文字列型の演算、ヒープとGC、例外処理などは、ランタイムが必要

194 ：デフォルトの名無しさん：2010/03/20(土) 22:29:17

Cが出た当時は高級言語って位置づけだったような記憶が無くもない

195 ：デフォルトの名無しさん：2010/03/20(土) 22:36:37

>>193
何言ってんだこいつ

196 ：デフォルトの名無しさん：2010/03/20(土) 22:36:39

>>194
一般的には低級言語はアセンブリ言語だけ。
Cは高級言語の中では低級よりなんで、低級と言ってるひとが
いてもいちいちつっこまないけど。

197 ：デフォルトの名無しさん：2010/03/20(土) 22:38:16

中級とか言ってる奴もいるけどなｗ

198 ：デフォルトの名無しさん：2010/03/20(土) 22:39:53

中級という表現は悪くないと思うが

199 ：デフォルトの名無しさん：2010/03/20(土) 22:40:41

いや、別にスイーツという表現も悪くないよｗｗ

200 ：デフォルトの名無しさん：2010/03/20(土) 22:42:57

フルーツ

201 ：デフォルトの名無しさん：2010/03/20(土) 22:43:15

>>193
便利にすると必然的にランタイムが必要になるってこと？

202 ：デフォルトの名無しさん：2010/03/20(土) 22:48:41

使っていない機能を細かくリンクしないようにできるなら、別にランタイムがあってもいいんじゃないの。
でも、ランタイムが肥大化しないようにこの機能を使わないようにしましょうとかウザイことになるのも嫌だな。。

203 ：デフォルトの名無しさん：2010/03/20(土) 22:50:57

>201
そんなことは無いよ
ランタイムとして分割しておいた方がプログラムする側にとって都合がいいだけの話。

204 ：デフォルトの名無しさん：2010/03/20(土) 22:55:34

Cのマクロ削除してくれたらあとなんでもいいよ

205 ：デフォルトの名無しさん：2010/03/20(土) 22:57:08

>>193の処理はぜんぜんランタイムと関係ないだろ。

206 ：デフォルトの名無しさん：2010/03/20(土) 22:58:59

>>204
マクロの代わりにtemplate

207 ：デフォルトの名無しさん：2010/03/20(土) 23:00:49

つかランタイムの概念を根本的に勘違いしている

208 ：デフォルトの名無しさん：2010/03/20(土) 23:01:32

俺もヘッダーの;が要らないと思う

209 ：デフォルトの名無しさん：2010/03/20(土) 23:02:50

>>208
なにそれ？

210 ：デフォルトの名無しさん：2010/03/20(土) 23:08:41

クラスのメンバ定義部分(?)の最後に付いてるウンコ

211 ：デフォルトの名無しさん：2010/03/20(土) 23:20:09

そもそも、ヒープが必要な言語を使ってOSのヒープを提供する部分は記述できない。
ヒープの提供までのところは、ヒープを使わないような構文に制限するとか、
OS内部で使用するための特製のヒープを使うというのは原理的にはあり得るが、
スマートではない。

212 ：デフォルトの名無しさん：2010/03/20(土) 23:44:12

言語仕様をコア部と周辺部に分けて、コア部でヒープの実装をして、周辺部でヒープを使えるようにすればいいんじゃないの。

213 ：デフォルトの名無しさん：2010/03/21(日) 00:15:29

>>212
それは、CとC++の関係と同じだね　
むずかしそうだろ

214 ：デフォルトの名無しさん：2010/03/21(日) 00:20:55

いや、C++はC++で閉じてるだろ

215 ：デフォルトの名無しさん：2010/03/21(日) 00:29:07

言語を開発するだけではだめで、せめてLinux Kernelをその言語で書いて、
全てにおいて有用であることを実証しなければ、Cを置き換えることは無理

216 ：デフォルトの名無しさん：2010/03/21(日) 00:32:17

>>214
そう。
C++を使ったとたんに、たとえ外部の関数を全くつかわなくてもそれなりの大きさのランタイムが必要になる。
それがどのようになっているかを考えると、OSの記述ができる言語というものの条件が分かってくると思う。

217 ：デフォルトの名無しさん：2010/03/21(日) 00:40:15

>>215
まあ、それはその段階になったらやるから、今は言語仕様考えような。なっ。

218 ：デフォルトの名無しさん：2010/03/21(日) 00:44:05

ライブラリ使わない場合でもC++ってランタイムライブラリ必要なの？

219 ：デフォルトの名無しさん：2010/03/21(日) 00:46:01

必要

220 ：デフォルトの名無しさん：2010/03/21(日) 00:46:27

>>218
例えばnewを使っただけで内部関数を呼び出すコードになる。

221 ：デフォルトの名無しさん：2010/03/21(日) 00:50:16

ああ、そういう意味か。

222 ：デフォルトの名無しさん：2010/03/21(日) 00:57:04

new/deleteに関しては、
メモリ確保・解放を実際に行うoperator new関数とoperator delete関数を自分で定義すれば、
原理上、ランタイムへの依存は不要になる。

223 ：デフォルトの名無しさん：2010/03/21(日) 01:00:28

OSだってランタイムみたいなもん

224 ：デフォルトの名無しさん：2010/03/21(日) 01:01:37

ランタイムの有無は関係ない気がする

225 ：デフォルトの名無しさん：2010/03/21(日) 01:01:55

まあ、結局コンパイラをどう作るかって話しだろ。

226 ：デフォルトの名無しさん：2010/03/21(日) 01:05:49

>>223
OS作る場合の話してるんだけど

227 ：デフォルトの名無しさん：2010/03/21(日) 01:06:16

へー

228 ：デフォルトの名無しさん：2010/03/21(日) 01:08:30

どう作るかの前に誰が作るの？

229 ：デフォルトの名無しさん：2010/03/21(日) 01:09:14

その前に何を作るかだよ。先ずは言語仕様だ。

230 ：デフォルトの名無しさん：2010/03/21(日) 01:21:38

>>225
そういうこと。

231 ：デフォルトの名無しさん：2010/03/21(日) 02:00:22

言語仕様なんて適当に意見出しあってできるもんじゃないよ。
実装者は別としてもそれを集約してまとめる人が必要だと思うな。
仕様が実現可能か判断できる能力も必要。特に文法設計が一番大変だと思う。
>>1にコンパイラを書く技術があるなら当然>>1がすべき。

232 ：デフォルトの名無しさん：2010/03/21(日) 02:17:56

>1はもういないだろ。
誰もまとめようとしていないんだし、とりあえずは与太話を続けようぜ。

233 ：デフォルトの名無しさん：2010/03/21(日) 03:04:54

集約してまとめるのは後でするから、今はまず意見出せよ。

234 ：デフォルトの名無しさん：2010/03/21(日) 03:09:38

結局Cに修練するんだよ

235 ：デフォルトの名無しさん：2010/03/21(日) 03:11:22

テンプレートは欲しいな。

236 ：デフォルトの名無しさん：2010/03/21(日) 03:13:01

>>235
ということは、OOPが必須になりますね

237 ：デフォルトの名無しさん：2010/03/21(日) 03:13:36

テンプレートはOOではない。

238 ：デフォルトの名無しさん：2010/03/21(日) 03:19:08

>>234
こんな進化が早い業界で40年前の言語が最適解なわけがない。
C99だとしても10年以上前だ。

現在の知識で一から言語設計すれば、Cよりもっと良い解が必ず存在する。

239 ：デフォルトの名無しさん：2010/03/21(日) 03:36:02

じゃあテンプレートいらね

240 ：デフォルトの名無しさん：2010/03/21(日) 03:37:16

もうちょっと賢いマクロが欲しいな。型安全で。

241 ：デフォルトの名無しさん：2010/03/21(日) 03:51:35

>>237
OOなしでテンプレートあってもあまりうれしくない。

242 ：デフォルトの名無しさん：2010/03/21(日) 03:59:11

テンプレートはOOとは別の総称プログラミングパラダイムの実装であるので
テンプレートとOOの有無はあまり関係が無い

243 ：デフォルトの名無しさん：2010/03/21(日) 07:45:52

OSの中身は継承と仮想メソッドのオンパレードだから、OOは良くマッチすると思う。
で、例えばlinux kernelだとこれをC言語+キャスト+関数ポインタで実装しているから安全性が低くてかなり問題。
個人的には、これからは並列計算機の時代だしメッセージパッシングベースのオブジェクト指向言語でOSを
書いてみたい。

アドレスを直接操作する必要がある本当に低レベルな処理はOS全体の割合で見れば一部だから、それができることを
メインの仕様にする必要はないと思う。
高級な機能を制限して、低級な機能を開放するコンパイルオプションでもあればいいんじゃない？

244 ：デフォルトの名無しさん：2010/03/21(日) 09:39:47

abs, labs, llabs, fabs, fabsf, fabslが一つの記述にまとまるってだけでも十分にテンプレートの意義がある。
同様に、関数の多重定義も認めてほしいかも。

型付けは、どうせ動的型付けやら何でも入る変数やらは不適だろうから、静的な強い型付けでいいよね。

245 ：デフォルトの名無しさん：2010/03/21(日) 09:41:09

>>243
それでいいんだったら、Cのインラインアセンブラみたいなノリで、既存コードに
__C{
　　...
}
でいいんじゃね？

246 ：デフォルトの名無しさん：2010/03/21(日) 10:33:45

既存がどうこうではなく、
いま、最高のプログラミング言語研究者が新たに一から新しい言語を作るとしたらどういう言語を開発するか
という観点で考えて欲しい。

247 ：デフォルトの名無しさん：2010/03/21(日) 10:34:52

それならいま、最高のプログラミング言語研究者に聞けよ馬鹿かお前

248 ：デフォルトの名無しさん：2010/03/21(日) 10:49:21

お前には聞いてない

249 ：デフォルトの名無しさん：2010/03/21(日) 10:50:50

osの実装と言語の理想は水の油かな。
だからvmみたいなのが出てくる必要があるのかな。

250 ：デフォルトの名無しさん：2010/03/21(日) 10:53:19

>>246
またお前か
自分で考える気はないようだなｗ

251 ：デフォルトの名無しさん：2010/03/21(日) 11:01:06

>>249
(0)まっさら→(1)OSのサポートなしでコンパイラ実装→(2)OS実装→(3)OSのサポートありでコンパイラ実装→(4)アプリケーション実装

(1)(3)を両立できる言語仕様がいいね。

252 ：デフォルトの名無しさん：2010/03/21(日) 11:58:56

>>244
同意

あと、ラムダも欲しい。

253 ：デフォルトの名無しさん：2010/03/21(日) 12:07:54

>>246
あなたのやっていることは既存言語という基礎を無視して新しい
言語作ろうとしているようなもの。どの分野でも先人の正負合わ
せた遺産から学ばずに無視すると失敗するよ。

それに永久脳内言語なんざ付き合うほうは迷惑なんで4/1までに
色々な言語調べて叩き台の言語仕様書または良質なベース言語を
用意しませう。

254 ：デフォルトの名無しさん：2010/03/21(日) 12:17:22

俺大学でコンパイラ研究してる院生だけど、システム開発目的でC言語相当の低機能な言語を新しく作る研究なんて見かけた事ないな。
トレンドは速度より安全性で、関数型言語とか強い型付き言語でOS書こうとする研究が多い。

255 ：デフォルトの名無しさん：2010/03/21(日) 13:41:45

それは言語を開発してるの？それとも既存の言語？だとしたらどの言語なの？

256 ：デフォルトの名無しさん：2010/03/21(日) 13:57:23

例えばOSの為のプログラミング言語の学会でPLOS(Programming Languages and Operating Systems)ってのがある。
新しく言語を作るって研究はほとんどないね。JavaとかMLとかHaskellとか既存言語を使ってる。
日本だとFail-Safe Cとか有名。

でもこれは別にC言語の代替言語に需要がないといういう意味ではないよ。
CやC++と同レベルの物を作るってんじゃ研究ネタにならないから誰もやらないってだけ。

257 ：デフォルトの名無しさん：2010/03/21(日) 15:18:49

日本の雑魚研究者が何してるかなんて興味ねえ

258 ：デフォルトの名無しさん：2010/03/21(日) 15:32:22

と、雑魚以下のプランクトンが申しておりますｗ

259 ：デフォルトの名無しさん：2010/03/21(日) 15:33:07

ム板にはその雑魚すらいません

260 ：デフォルトの名無しさん：2010/03/21(日) 17:00:11

cへのトランスレータが流行る訳

261 ：デフォルトの名無しさん：2010/03/21(日) 19:31:46

OSを作りたいという需要について

262 ：デフォルトの名無しさん：2010/03/21(日) 19:50:05

誰もやってないから面白いんじゃないの?
研究者としてはw

263 ：デフォルトの名無しさん：2010/03/21(日) 19:56:51

おそらく未踏で出てくるぞ。で、詐欺のような結果をだして逃げ切るはずｗｗ

264 ：デフォルトの名無しさん：2010/03/21(日) 20:15:12

俺大学でコンパイラ研究してる院生だけど、プリキュアは初代以外認めないな

265 ：デフォルトの名無しさん：2010/03/21(日) 20:33:27

おまえら本当に口だけだなあ……
草案でもいいから、なにか出してみろよ

266 ：デフォルトの名無しさん：2010/03/21(日) 20:52:31

アイディアあるんだったら今作ってる俺言語に盛り込むよ。
面倒臭い思いしてまで草案なんて作るわけないだろ。

267 ：デフォルトの名無しさん：2010/03/21(日) 21:19:46

Cにさしたる欠点がないから出てこないよ

268 ：デフォルトの名無しさん：2010/03/21(日) 21:21:58

C(笑)

269 ：デフォルトの名無しさん：2010/03/21(日) 21:48:08

>>254
他人がやってないと安心できない研究者ってダメだろｗ

270 ：デフォルトの名無しさん：2010/03/21(日) 22:23:59

Cの再発明はそれ以下だけどな。

271 ：デフォルトの名無しさん：2010/03/21(日) 22:39:45

ということで、LispやRubyやJavaの再発明ばかりしていないで、
最新の言語研究の成果を取り入れたCに代わる低級言語を開発しよう。

272 ：デフォルトの名無しさん：2010/03/21(日) 22:51:24

D言語との差別化は？

273 ：デフォルトの名無しさん：2010/03/21(日) 23:07:05

既存の何かと違う何かを作るのではない。

最新の言語研究の成果を取り入れた新しい低級言語を作るのだ。

既存言語との差は、言語仕様ができてからdiffをとれば分かる。

274 ：デフォルトの名無しさん：2010/03/21(日) 23:30:49

だからお前の言う最新の言語研究の成果って具体的に何さ？論文持ってこいよ。

275 ：デフォルトの名無しさん：2010/03/21(日) 23:39:59

最新の言語研究の成果について知らないなら、このスレに参加しなくていいですよ＾＾

276 ：デフォルトの名無しさん：2010/03/21(日) 23:47:32

要はバカばっか

277 ：デフォルトの名無しさん：2010/03/21(日) 23:48:51

どういう境遇にいればこんなざまで生きてこれるのか興味が

278 ：デフォルトの名無しさん：2010/03/22(月) 00:05:33

最新の結果なんか、そいつらが実験的なプログラミング言語をつくってるだろ
実用を目指すなら、Matureなものから取捨選択だろ

279 ：デフォルトの名無しさん：2010/03/22(月) 00:10:30

っていうか、実際作るつもりのやつっているのか。

280 ：デフォルトの名無しさん：2010/03/22(月) 00:25:10

言語仕様ができたら作るだろ。

281 ：デフォルトの名無しさん：2010/03/22(月) 00:39:17

>>1はスレ立てた時点で開発とコミュニティ育成が始まっているという認識無さすぎ。
スレ立てる前に言語仕様草案を作っておいて、さらに議論進めながら
協力者募るって一切やってない時点で空中分解している。

>>275
「私は何もできません。中二病に羅漢したいです。だれかやってください。他力本願(はぁと)」
っつうくだらない自己弁明はうざいから、お前の言う最新の計算機言語学関連論文の
リソースちゃんと出してくれる？そうしないと一向に進まないんだが。

282 ：デフォルトの名無しさん：2010/03/22(月) 00:41:46

ｷﾓｲ

283 ：デフォルトの名無しさん：2010/03/22(月) 01:06:25

C相当の機能に、強力なマクロ（コンパイル時処理）とクラスと名前空間があればいい。

284 ：デフォルトの名無しさん：2010/03/22(月) 01:14:31

×羅漢(らかん)
○罹患(りかん)

285 ：デフォルトの名無しさん：2010/03/22(月) 01:15:31

>>283でいいよ

286 ：デフォルトの名無しさん：2010/03/22(月) 01:16:33

ヘッダーファイルが要らない

287 ：デフォルトの名無しさん：2010/03/22(月) 01:18:41

他人のマクロがうざい

288 ：デフォルトの名無しさん：2010/03/22(月) 01:22:39

今から新しく作るのにマクロかよ

289 ：デフォルトの名無しさん：2010/03/22(月) 01:24:19

型安全なマクロ

290 ：デフォルトの名無しさん：2010/03/22(月) 01:30:19

おれjava2cppつくったよ。
俺専用なんでいろんな縛りあるけど実用してる。

291 ：デフォルトの名無しさん：2010/03/22(月) 01:34:25

機能のトランスレートだけならどうにでもなる。
が、単にVMで動作していたものが関数呼び出しに変わるだけでは全く意味はない。

必要なのは実用的にオーバーヘッドなく低レベルの処理を記述できることだ。

292 ：デフォルトの名無しさん：2010/03/22(月) 01:37:27

cppネイティブな記述に変換してるし速度的なメリットもあると思うけどな。
コードがシンプルになる＆どちらのプラットホームでも使えることを目的としてるし。

293 ：デフォルトの名無しさん：2010/03/22(月) 01:39:02

>>83
langageって何語？
英単語では知らないけど、ドイツ語とかラテン語とかかな。
グーグルさんに「もしかして・・・」って指摘されないし。

294 ：デフォルトの名無しさん：2010/03/22(月) 01:41:43

ひとつの記述から生成される実行プログラムは原理的には同じような性能しか持ち得ない。

一方が他方より性能が優れるのであれば、他方が単に馬鹿なだけだ。

295 ：デフォルトの名無しさん：2010/03/22(月) 01:42:28

発想力が足りないね

296 ：デフォルトの名無しさん：2010/03/22(月) 01:42:46

>>293
languageじゃないの？

297 ：デフォルトの名無しさん：2010/03/22(月) 02:00:02

テンプレートが神速でコンパイルできる言語を開発して下さい
コンパイル時間短縮のためにメタ関数の遅延実行とか
考慮するのが面倒なんです

298 ：デフォルトの名無しさん：2010/03/22(月) 02:04:11

>>1
C/C++に代わる言語のコンパイラは、先ずはCで書くの？

299 ：デフォルトの名無しさん：2010/03/22(月) 02:04:37

コンパイル時間ために言語仕様を妥協することには反対。

コンパイルオプションでヘボイバイナリを高速に吐いたり、高速・コンパクトなバイナリをじっくり生成したり、選べるならいい。

300 ：デフォルトの名無しさん：2010/03/22(月) 02:05:26

>>298
好きにしろ。Cでもいいよ。

301 ：デフォルトの名無しさん：2010/03/22(月) 02:08:09

Dは、みなの希望を満たしているね

302 ：デフォルトの名無しさん：2010/03/22(月) 02:08:59

Dは違う。

303 ：デフォルトの名無しさん：2010/03/22(月) 02:11:34

>>302
何が不都合？

304 ：デフォルトの名無しさん：2010/03/22(月) 02:13:26

言語名

305 ：デフォルトの名無しさん：2010/03/22(月) 02:14:33

Linuxカーネルだって最初は小さいコードだったんだ。
どこかの一人の天才が先ず始めて、それからみんなでよってたかって作ればうまくいくよ。

306 ：デフォルトの名無しさん：2010/03/22(月) 02:16:52

小さいコードでもその段階で「いける」って思わせるレベルのものなんだよな

307 ：デフォルトの名無しさん：2010/03/22(月) 02:22:24

2ch発の言語が誕生するか見てるがまるで駄目だな。全くできそうな気配もないw

308 ：デフォルトの名無しさん：2010/03/22(月) 02:23:41

お前、ワクワクし過ぎｗ

309 ：デフォルトの名無しさん：2010/03/22(月) 02:30:38

結局どんな改良がしたいの？

310 ：デフォルトの名無しさん：2010/03/22(月) 02:31:14

言語仕様に組み込みの機能（forとかifとかあれば）と全く同じように扱える、my_forとかmy_ifとかを独自に定義できるといいな。

311 ：デフォルトの名無しさん：2010/03/22(月) 02:31:58

>>309
改良じゃない。

最新の言語研究の成果を取り入れた新しい低級言語を作るのだ。

312 ：デフォルトの名無しさん：2010/03/22(月) 02:32:47

>>311
言葉遊びはいい。Cでできないなにを目的に新しい言語作りたいの？

313 ：デフォルトの名無しさん：2010/03/22(月) 02:34:48

効率良くプログラミングをしたいんだろ。

Cがあるのに、C++、C#、Java、F#、Haskell、OCaml、Ruby、Pythonが出てきているのと同じことだ。

314 ：デフォルトの名無しさん：2010/03/22(月) 02:37:07

効率よくって具体的になんだよ。
C++じゃだめなの？Javaじゃだめなの？
どこがだめだから違う言語がほしいの？

315 ：デフォルトの名無しさん：2010/03/22(月) 02:37:31

蓮舫は来なくていいよ。

316 ：デフォルトの名無しさん：2010/03/22(月) 02:38:37

答えられないと仕分けされるよ

317 ：デフォルトの名無しさん：2010/03/22(月) 02:41:54

↓このヒトが言語仕様をまとめます

318 ：デフォルトの名無しさん：2010/03/22(月) 02:44:20

いらない

319 ：デフォルトの名無しさん：2010/03/22(月) 02:48:30

Cが無かったとして、

最高の研究者を集めてOS開発用のプログラミング言語を作らせたらどんな言語を作るだろうか

という思考実験としても興味がある。

320 ：デフォルトの名無しさん：2010/03/22(月) 02:57:31

このスレざっと見たけど具体的なこというやつほとんどいないな。

321 ：デフォルトの名無しさん：2010/03/22(月) 03:01:16

>>319
俺も興味アリ

322 ：デフォルトの名無しさん：2010/03/22(月) 03:03:03

結局Cに収斂するよ

323 ：デフォルトの名無しさん：2010/03/22(月) 03:08:21

>>1いわく
低レベル記述、高パフォーマンス、可読性、簡潔さ、拡張性、学習の容易さ
とOOを保ちながら文法を整理するといってるみたいだが
文法の汚さって具体的にどこ？C++の部分？

324 ：デフォルトの名無しさん：2010/03/22(月) 03:18:10

つーか、Cに不満はあっても、膨大な資産を捨てて新大陸作って移住しよう、ってほど
不満なCプログラマはほとんどいないだろ。
Cが全然使えません、って人なら新大陸欲しいのかもしれないけど。そんな奴が低水準
に触るのはぶっちゃけ無理だしスクリプト系で我慢しろと。重い安全装置付いてっから。

325 ：デフォルトの名無しさん：2010/03/22(月) 03:22:26

セミコロンが死ぬほど嫌いならトランスレータ作ればいいよ
それこそPythonあたりで簡単に作れるよ

そのセミコロン排除言語を使いこなすには、Cを使いこなす能力が必要だけどな
あと、改行で続けたい時はバックスラッシュな
あと、普通のCを読み書きしようとすると死ぬ、ってのも覚悟な

326 ：デフォルトの名無しさん：2010/03/22(月) 03:23:34

文法が汚いってだけならホントにどうでもいいな

327 ：デフォルトの名無しさん：2010/03/22(月) 04:15:30

同じ事を何回繰り返せば気が済むんだろう
環境に依存しないアセンブラが理想、それはCであり、究極的にはJavaなんだよ
それ以上もそれ以下も無い。車輪の再発明はやめろ

328 ：デフォルトの名無しさん：2010/03/22(月) 04:59:25

まずは、C のポインタで実現している機能・効率と、
Haskell 並みに強く型付けされた言語の安全性を両立したいなあ。

329 ：179：2010/03/22(月) 07:00:03

な、何も進まないだろ。
>>319のバカが同じこと何度も（すくなくとも４度は）書いてるだけで。
Ｃの牙城がいまだに崩れないのはそれなりに理由があるんだよ。

330 ：デフォルトの名無しさん：2010/03/22(月) 07:03:18

Dでいいでしょ
Cの資源も使えるし

331 ：デフォルトの名無しさん：2010/03/22(月) 07:12:41

Ｄって全然知らないけど何なの。
Ｃ＃はＣに見た目だけ似てるＬＬ言語だってのは知ってるけど、そんなようなもん？
ＪＡＶＡもそんなようなもんだし。
もしそうならＣの代わりなんてとても務められないじゃん。

332 ：デフォルトの名無しさん：2010/03/22(月) 07:18:36

想像で何を言っとるんだwww
ネイティブコンパイルなマルチパラダイム言語だよ

333 ：デフォルトの名無しさん：2010/03/22(月) 07:23:39

説明になってないな。
おまえは「プログラムできないやつが適当に話を合わせるスレ」に帰れよ。

334 ：デフォルトの名無しさん：2010/03/22(月) 07:47:07

＞C/C++は高速だが過去のしがらみから文法が致命的に汚い。
＞C#の文法は洗練されているが中間コードやGCを前提としているため致命的に遅い。
＞LL系の言語さらに遅い。
Dは中間コードを吐かずネイティブコンパイルするので高速。
GCは備えてるが、malloc を使う事もできるので、GCの速度が気になるなら malloc を使えばいい。

＞そこで、C/C++に代わるOSも作れるような低級プログラミング言語を開発したい。
GCさえ使わなければOSを作る事も可能。

＞文法はCに似ている方が望ましいが、
＞低レベル記述、高パフォーマンス、可読性、簡潔さ、拡張性、学習の容易さ
＞を担保出来るなら、どんな形式でも構わない。
文法はCにある程度似ている。
C++は文法がコンパイラの作成の容易さを考えて作られてないため
構文解析が非常に大変で、コンパイルも遅いが、
Dはコンパイラの作成の容易さも考えて作られているため、
コンパイラも作りやすいし、コンパイルが高速になる。
インラインアセンブラも使えて、ネイティブコンパイルなのでパフォーマンスも高く、
（敢えて複雑な事をしなければ）可読性も高く簡潔で、
Cの資源も利用できるし、現代的な各種言語仕様を取り入れており、拡張性も高い。
やれる事が多いので、学習の容易さに関しては難はあるかもしれない。

＞プログラミングパラダイムについても、オブジェクト指向を備えることが望ましいが
＞生産性を高めることが出来るのであれば、他の方式が入っても構わない。
OOP、テンプレート、mix-in、プロパティ、GC、高度な条件コンパイル、契約、
連想配列、遅延評価、ローカル関数、ラムダ式、クロージャなど、
伝統的な方式から現代的な方式までかたっぱしから取り入れられている。

欠点は言語仕様が安定しないこと。これに尽きる。
古いソースは今のコンパイラでは大抵コンパイルできない。
逆に言うと、言語仕様が安定しさえすれば普及するかもしんない。

335 ：デフォルトの名無しさん：2010/03/22(月) 08:25:13

なんか全然まとまらないから、言語仕様作るとこまで自分が仕切ってみても良いですか？

336 ：デフォルトの名無しさん：2010/03/22(月) 08:26:49

作るならDよりいいものにしてよね

337 ：デフォルトの名無しさん：2010/03/22(月) 08:37:56

>>335
言語仕様があっても、バイナリを生成するコンパイラが出来なければ、まさしく絵に書いた餅で終わるわけだが

コンパイラを作るにはCPUの詳細な知識が必須でしょ？そんなやついるの？

338 ：デフォルトの名無しさん：2010/03/22(月) 08:41:11

Cのソースにコンパイルできればそれでいいよ

339 ：デフォルトの名無しさん：2010/03/22(月) 08:41:46

作れるけどこんなバカバカしい話には乗れん

340 ：デフォルトの名無しさん：2010/03/22(月) 08:46:56

むしろ絵に書いた餅のうちが楽しいんだぞ
味を想像する余地があって

341 ：デフォルトの名無しさん：2010/03/22(月) 09:01:28

動画、サウンド、2D/3D描画とかのライブラリも全部作り直しになるのか？
移植するにしても、Cと似てない構文なら大変そうだし、Cからの単純移植ならそれは新言語の特性を生かさないという意味では

342 ：デフォルトの名無しさん：2010/03/22(月) 09:10:24

APIの呼び出しはそのままにしておけ
特に帰ることもないだろう

343 ：デフォルトの名無しさん：2010/03/22(月) 09:10:31

Cのライブラリをそのまま使えればいい話だろ

344 ：335：2010/03/22(月) 09:15:11

自分もコンパイラは作れますが、まとめ役だけに徹します。
すごく面白い発想の言語なら作りたい人が現れるかもしれません。

とりあえず

・手続き型＋OO＋テンプレートのマルチパラダイム
・バイトコード無し・VM無し・GC無し

という意見が多そうですが、ここは固定でいいですか？

345 ：デフォルトの名無しさん：2010/03/22(月) 09:20:15

多重継承out
mix-in in
で

346 ：デフォルトの名無しさん：2010/03/22(月) 09:25:01

PHPでいいよ　これを改良しろよ
ガベージコレクションがあるか無いかは言語の文法とは別な気はするが。
PHPをGCなしでコンパイル使用とすれば出来る
C言語をGCありのスクリプトにも出来る。

347 ：デフォルトの名無しさん：2010/03/22(月) 09:25:42

PHPみたいな糞言語をどうしろと

348 ：デフォルトの名無しさん：2010/03/22(月) 09:26:32

ヒロポンとかいうOS作っていたやつのOSはどうなった?一度も動かしたことがない。
ある程度のシェアとれる見込みはあったのか。起動だけ出来れば良かったのか。

349 ：デフォルトの名無しさん：2010/03/22(月) 09:44:21

テンプレートなんか許可したらコンパイラ作る手間が爆発的に増加するぞ

350 ：デフォルトの名無しさん：2010/03/22(月) 09:56:43

（テンプレートを何だと思ってるんだろう）

351 ：デフォルトの名無しさん：2010/03/22(月) 09:59:26

>>344
言語名はd--か。

352 ：デフォルトの名無しさん：2010/03/22(月) 10:00:11

C C++ D-- D

なんだこれ

353 ：355：2010/03/22(月) 10:31:36

>>349
手間はとりあえず無視しますか。技術的に可能ならOKということで。

>>351
このままだと劣化C++になりそうですね。つまらないですね。

VMの有無に関して意見ないですか？
自分は今時ネイティブコンパイルとか古臭いと思っているのですが、みなさんどう思いますか？

354 ：デフォルトの名無しさん：2010/03/22(月) 10:33:43

おいおい、低級プログラミング言語を作るんだろ？
ネイティブコンパイル一択だろ

355 ：デフォルトの名無しさん：2010/03/22(月) 10:39:34

劣化C++ですらねーな

356 ：デフォルトの名無しさん：2010/03/22(月) 10:46:24

だから>>151で終了してるんだと何度言えば

357 ：デフォルトの名無しさん：2010/03/22(月) 10:48:01

C++にそれなりにとって変わられてんのに
結局Cにはかなわないと結論づけてる文に
どれだけの価値があるのか

358 ：デフォルトの名無しさん：2010/03/22(月) 10:49:54

>>354
そもそもC言語ですら、低水準言語の定義には当てはまらないじゃないですか。
インラインアセンブリを使わないと書けない処理とかあるわけですから。

ネイティブコンパイルでも良いと思うんですが、OSが書けりゃいいんだし、
安全性や高速化という観点で検討してみてもいいかとは思います。
ただの問題提起です。

359 ：デフォルトの名無しさん：2010/03/22(月) 10:50:59

C++で書かれたOSってなんかあるの？

360 ：デフォルトの名無しさん：2010/03/22(月) 10:52:15

>>357
C++で書かれたOSの例を挙げてみろ

361 ：デフォルトの名無しさん：2010/03/22(月) 10:52:53

OSの話なのか

362 ：デフォルトの名無しさん：2010/03/22(月) 10:53:54

ずーっとＯＳの話してるだろアホかお前

363 ：デフォルトの名無しさん：2010/03/22(月) 10:55:53

pascalで書かれたOSならあるな

364 ：デフォルトの名無しさん：2010/03/22(月) 10:58:51

VMの話とかされちゃ
OSの話とは思わない罠

365 ：デフォルトの名無しさん：2010/03/22(月) 11:00:22

InfernoとLimboの劣化再発明を議論しているスレはここですか？

366 ：デフォルトの名無しさん：2010/03/22(月) 11:00:26

手続き型にするとして、駆動レコードとかどうする？
サブルーチン一択にする？コルーチンもOKにする？それともForthみたいにユーザーが駆動レコードを弄れるようにする？
新しいフレームを作らない手続きとかも欲しいなぁ。

というかForthやろうぜ。

367 ：デフォルトの名無しさん：2010/03/22(月) 11:00:44

Ring0の命令を扱うための構文とかあったほうがいいのだろうか
ライブラリで十分か

368 ：デフォルトの名無しさん：2010/03/22(月) 11:16:35

機種依存コードのIFDEFをすっきり書けるようにしてほしい
C++のclassとは別の枠組みで実装の特殊化ができる

後は、エンディアンやアラインメント指定のコンパイラ標準サポートとか

369 ：デフォルトの名無しさん：2010/03/22(月) 11:22:37

>>368
中間言語使わずにやるのは夢物語だな

370 ：デフォルトの名無しさん：2010/03/22(月) 11:24:53

＞機種依存コード・エンディアン
D言語のversion構文で十分
エンディアンによるversion分岐も標準でサポート

＞アライメント
D言語のalign属性で十分

371 ：デフォルトの名無しさん：2010/03/22(月) 11:29:36

D言語ではダメな理由は？

372 ：デフォルトの名無しさん：2010/03/22(月) 11:31:59

いろいろついてて重そうだな。
ゲーム機や組み込み機などの省資源では足かせになりそうだ。

373 ：デフォルトの名無しさん：2010/03/22(月) 11:36:39

>>370
そうか、そういうのはDから輸入すればいいな

ただしエンディアンについてはversionで分けるだけでなく
同一記述から、指定したエンディアン用のコードが生成できる必要があると思うが
そういうのもＤは可能？

374 ：デフォルトの名無しさん：2010/03/22(月) 11:37:21

enbeded Dでいいんじゃね

375 ：デフォルトの名無しさん：2010/03/22(月) 11:39:52

>>373
流石にそういうのはないかなあ
まあそういうクラスを作れば可能だろうけど

376 ：335：2010/03/22(月) 11:41:39

自分はD言語で十分に思います。
スレの内容的にツッコミどころあるとすれば

最新の言語研究成果を使いたい(?)
→ D言語は成熟した・古い技術しか使っていない

超高速にしたい
→ D言語は高速化に重点を置いた言語仕様ではない。最適化が効かない。

くらいでしょうか。

377 ：デフォルトの名無しさん：2010/03/22(月) 11:41:40

やっぱりD--だなw

378 ：デフォルトの名無しさん：2010/03/22(月) 11:42:41

最新技術って例えばどういうもの？

379 ：デフォルトの名無しさん：2010/03/22(月) 11:46:29

Dは仕様を提案すると
入れてくれることもあるで

380 ：335：2010/03/22(月) 11:49:12

>>378
例えば、JITや自動並列化などでしょうか？技術自体は古いですが、まだ広まっていはいないですね。
高速化以外だと、モデル検査による安全性の検証とかですかね。

381 ：デフォルトの名無しさん：2010/03/22(月) 11:54:23

>>380
OS記述するとき、それらはどうなる

382 ：デフォルトの名無しさん：2010/03/22(月) 12:03:05

JITはネイティブコンパイラには全くの無意味では・・・
自動並列化は面白いが、基本的にOSあってのものだよね

モデル検査とか一般的なプログラムで適用可能なんだろうか？
安全性に関してはDの契約が現実的な解な気がする

383 ：335：2010/03/22(月) 12:08:11

>>381

後者の場合、例えば
デバイスドライバなどのOSのモジュールが満たすべき要件を記述したファイルを用意しておいて、
ユーザのプログラムがそれを満たしているかコンパイル時に検査することで、安全性の高いOS開発ができる
といった使い方が提案がされています。

JITの場合は
OSの最下層にJITを組み込んだランタイムを用意して、OS本体やユーザアプリケーションはバイトコードの形式にし、
それをJITコンパイルして実行
という形が考えられます。高速化は期待できますね。
でもこれは、言語設計に制約は課さないから今考えなくてもいいかも知れません。

自動並列化の場合は言語設計が重要です。C・C++・Dの様な言語では困難な技術です。

384 ：デフォルトの名無しさん：2010/03/22(月) 12:18:35

ヒープや並列処理は、OSがあるというのが前提なので、そういうのを言語自体にとりこむのは、目的にかなっていない。

385 ：335：2010/03/22(月) 12:48:57

別にブートローダとかメモリマネージャとかを書く専用言語を作りたいわけじゃないじゃないですか。
低レベルな処理を記述できる言語機能を持たせればいいのでは？

386 ：デフォルトの名無しさん：2010/03/22(月) 12:53:54

コンパイラ自体が未知の（これから作る）OSの仕様に依存してどうすんのよと

387 ：335：2010/03/22(月) 12:59:59

並列化サポートのある言語で直列コードにコンパイルしても別にいいじゃないですか。
JITサポートのある言語をネイティブコードに(ry

GCとかとなれば話は別ですけれども。

388 ：デフォルトの名無しさん：2010/03/22(月) 13:04:04

簡易な記述でハードウェアリソースを使い倒せて
既存のコードやライブラリが流用できるなら
OSごと入れ替える価値はあるなぁ

ネットワーク上の別マシンのリソースもローカルのコアも意識せずに扱えるとか
んで、リソース配分はJITでとか、夢が広がりまくりですな

389 ：デフォルトの名無しさん：2010/03/22(月) 16:35:46

このスレでJITを持ち出すなんて
ただ技術的に新しいことやりたいって自己満足に過ぎないわ

390 ：デフォルトの名無しさん：2010/03/22(月) 18:22:26

>>344
ちょっと前に流行ったカンスーガタとかを含めるのは難しいかな。

391 ：デフォルトの名無しさん：2010/03/22(月) 19:19:44

文字列リテラルに直接文字列クラスのメソッドを適用できるようにして欲しい

392 ：デフォルトの名無しさん：2010/03/22(月) 19:38:31

いらね

393 ：デフォルトの名無しさん：2010/03/22(月) 19:50:22

便利で高速なライブラリでも開発した方が余程役立つだろ

394 ：デフォルトの名無しさん：2010/03/22(月) 19:53:55

便利で高速なライブラリを開発できる言語仕様ができればいいと思う。

395 ：デフォルトの名無しさん：2010/03/22(月) 19:54:51

理想言語スレなので役立つかどうかなんて正直どうでもいいのよ

396 ：デフォルトの名無しさん：2010/03/22(月) 19:56:30

D言語が有名になればいいだけみたいだな

397 ：デフォルトの名無しさん：2010/03/22(月) 19:57:24

>>395
同意。

398 ：デフォルトの名無しさん：2010/03/22(月) 20:02:16

>>396
仕様が安定すれば、もう少し有名になるんじゃないか？
いや最近のD言語まわりの事情を知らんのだけれど

399 ：デフォルトの名無しさん：2010/03/22(月) 20:04:05

D厨ウゼー

400 ：デフォルトの名無しさん：2010/03/22(月) 20:07:26

クロージャー欲しい

401 ：デフォルトの名無しさん：2010/03/22(月) 20:08:05

クロージャならD言語にあるで

402 ：デフォルトの名無しさん：2010/03/22(月) 20:09:01

あんたらの求めてるモンD言語に全てありまっせ

403 ：デフォルトの名無しさん：2010/03/22(月) 20:10:00

とりあえず片っ端からつっこみまくったからな

404 ：デフォルトの名無しさん：2010/03/22(月) 20:12:42

そしてゴミ溜め状態になるんですねわかります

405 ：デフォルトの名無しさん：2010/03/22(月) 20:13:07

腐臭がする

406 ：デフォルトの名無しさん：2010/03/22(月) 20:13:11

クロージャってGCない環境でも実装できるの？

407 ：デフォルトの名無しさん：2010/03/22(月) 20:13:36

コアの言語仕様は小さくして、拡張性を高めた方がいい

408 ：デフォルトの名無しさん：2010/03/22(月) 20:16:17

片っ端から仕様を詰め込んではいるが
構文解析が楽になるよう言語仕様を決めてるから
コンパイラを作るのはC++に比べて格段に楽らしい

409 ：デフォルトの名無しさん：2010/03/22(月) 20:19:41

何でもかんでも入れると結局使えない言語になるから、
>>407の言うように言語仕様は小さくて拡張性の高い言語にするのがいいだろうな。

410 ：デフォルトの名無しさん：2010/03/22(月) 20:20:48

コアを小さくする必要はどこにもない
進化に付いていけない奴はこのバスから降りるしかない

411 ：デフォルトの名無しさん：2010/03/22(月) 20:23:39

小さいからコアなんだろ、アホｗｗ

412 ：デフォルトの名無しさん：2010/03/22(月) 20:25:29

昭和脳がITを窮屈にする

413 ：デフォルトの名無しさん：2010/03/22(月) 20:25:29

何をコアと呼ぶかは議論があると思うが、言語仕様を階層化しておくのは良いやり方だと思う

414 ：デフォルトの名無しさん：2010/03/22(月) 20:30:35

小さいコアならCで十分なような

415 ：デフォルトの名無しさん：2010/03/22(月) 20:32:33

>>407ってLiXXとかLuXとかあの想像する
要するにカス

416 ：デフォルトの名無しさん：2010/03/22(月) 20:33:45

>>414
十分とかそう言うのは関係なくて、

いま1から言語を作れといったらCにならないだろ。
40年前ならCになった。

じゃあ、今ならどうなるの？って話。

417 ：デフォルトの名無しさん：2010/03/22(月) 20:35:15

ネイティブ生成が古いってのは、Googleの誰ぞが言ってるようなランタイム最適化
優位論に近いんかな？
正直あれはそんなうまく行くとは思わないんだけどな。Crusoe的な直線番長になる
だけだと思うが。立ち上がりは確実に悪いし、立ち上がりで作業が終わってしまう。
動的にやる分のコストもタダじゃない。MTで振り分ける手もあるかもしれないが、
MTならば並列化手法との比較優位が見えないと微妙。
不透明な動的コストが果たして低水準処理と相性がいいのかどうか。不透明な動的
コストといえばGCを思い出すが、原理的にはあれよりは扱いやすいかもしれないが。
そもそも低水準を触る理由は、速さが欲しいだけなのか、生じゃないと困るのか。
後者ならVMは論外。というか、VM路線がどうもうまく行かなくて後退してるのが
最近の流れだと思うが。VMと相性良さそうな携帯電話ですら。
つーかVMでいいならScalaでいいんじゃねーの。JavaVMはVMとしちゃ相当速いし。

418 ：デフォルトの名無しさん：2010/03/22(月) 20:37:48

「OS/VMを作るための低水準言語を考えよう」って言えばいいのかもな。

419 ：デフォルトの名無しさん：2010/03/22(月) 20:42:01

じゃあ今ならどうなるの？

→Dになります

420 ：デフォルトの名無しさん：2010/03/22(月) 20:42:50

ｷﾓｲ

421 ：デフォルトの名無しさん：2010/03/22(月) 20:44:57

今ならわざわざ作らない

422 ：デフォルトの名無しさん：2010/03/22(月) 20:49:29

それならCにできないけど低級言語に欲しい機能を挙げてみようぜ。
・Lispなみに弄くれるマクロ
- テンプレート
- 正規化された構文(S式とか)
・Forthなみに弄くれる駆動レコード
- コルーチン
- 強制インライン展開(レコードを新しく作らないルーチン)
- 駆動レコードへのアクセス
・実行制御
- 高度な並列処理(トランザクションとか)
- アトミック操作
- リアルタイム操作

こんなもんかね？他にどんなの欲しい？

423 ：デフォルトの名無しさん：2010/03/22(月) 20:51:04

>>422
>・Lispなみに弄くれるマクロ

これいいなぁ(ﾟＡﾟ;)ｺﾞｸﾘ

424 ：デフォルトの名無しさん：2010/03/22(月) 20:52:51

並列化しやすいデータ構造とかループ構文とかくれ

425 ：デフォルトの名無しさん：2010/03/22(月) 20:53:28

諸刃の剣だけどな

426 ：デフォルトの名無しさん：2010/03/22(月) 20:59:04

>>346
CGありのCは需要がありそうだけど、
deleteだかfreeだかやらないといけないPHPなんてだれも使わなそう。

427 ：デフォルトの名無しさん：2010/03/22(月) 21:00:08

1は「低級言語」って言ってんだからＤ言語なんて全く反対方向だと思うが…

それより、パフォーマンスだの可読性だのと一気に全て求める辺り
なんか>>1が言語の開発の何たるかを知らん臭い。

下記サイトでyacc/lexの勉強汁。
ttp://kmaebashi.com/programmer/devlang/index.html

つうか、じつは俺様もyaccの解説を幾ら読んでもチンプンカンプンだから、
そんとこを解るまで御教示願いたいと常々思ってるんだけどな。
解れば自分で勝手に好きな言語作ってシコシコする。

428 ：デフォルトの名無しさん：2010/03/22(月) 21:02:41

> なんか>>1が言語の開発の何たるかを知らん臭い。

それはスレタイの時点で既に

429 ：デフォルトの名無しさん：2010/03/22(月) 21:05:35

変数はレキシカルスコープでお願いします。

430 ：デフォルトの名無しさん：2010/03/22(月) 21:08:34

>>422
・マルチスレッド

機能としてはライブラリでの提供でいいけど、構文としても備えていて欲しいな。

431 ：デフォルトの名無しさん：2010/03/22(月) 21:45:56

>>422
トランスレータ形式での実装限定になるかもしれないがインラインアセンブリは当然としてインラインC/C++欲しいところです。
これによりライブラリラッパーが書きやすくなり、既存の資産を僅かな修正で活用できるかと。

さらに標準型(predefined-type)は少なく可読性に優れた文法のほうがいいですね。

432 ：デフォルトの名無しさん：2010/03/22(月) 21:49:51

D（ry

433 ：デフォルトの名無しさん：2010/03/22(月) 21:51:28

C/C++使えばいいだろ

じつに馬鹿だな君は

434 ：デフォルトの名無しさん：2010/03/22(月) 22:24:00

全然知らないんだけどさ、GOってどうなの？

435 ：デフォルトの名無しさん：2010/03/22(月) 22:41:24

>>335さんは今頃頑張ってる頃か。何にせよ具体的なものが出てきたら盛り上がるだろ。

436 ：335：2010/03/22(月) 22:53:32

>>435
今帰ってきた処で何も具体的な物は作ってません(--;
自分の分かる範囲で意見を書きます。

>>389
新しい事考えないと自分のモチベーションが維持できないので・・。確かに自己満足です。

>>390
手続き型言語に関数オブジェクトを追加という意味なら容易です。
関数型言語にするという意味なら、型システムの健全性(コンパイル可能ならプログラムは正しい)を保つのが大変そうです。でも面白そうですね。

>>406
ダイナミックスコープならGC無しでも可能だと思います。
レキシカルスコープなら、ヒープに確保した自由変数を解放する必要があります。GCがあった方が楽ではあるでしょう。

>>409
小さい仕様のコアを実装して、強力なメタプログラミング機能をつけるという感じでしょうか。

>>417
適材適所の一言に付きます。個人的にJITを推す理由を書きます。
- OS等の整数系プログラムの場合はAOTでは不可能な分岐除去が劇的に効く
- キャッシュ最適化はJITが遙かに優位
- ランタイムをOS組み込みにするならば、起動オーバヘッドは削減出来る。
- GCCがLLVMを取り入れたように、むしろ今のトレンドなのでは(自信ない)

>>422
LISPマクロいいですね。Forth面白いですね。
トランザクションは低級言語では難しそうですね。VM作ってSTMを実装ということになると思いますが、一部のプログラムを覗いて激しく遅いという噂です。

>>424
データ構造・ループ構文ももちろんですが、ポインタをどうにかする必要がありますね。

437 ：409：2010/03/22(月) 23:12:31

>>436
>小さい仕様のコアを実装して、強力なメタプログラミング機能をつけるという感じでしょうか。

そうだねー。
それと、”標準ライブラリ”が必要だろうから、それを見据えたメタプログラミング機能かな。

438 ：デフォルトの名無しさん：2010/03/22(月) 23:15:36

>>436
繰り返しの話になってる気がするんだが、
「速度が欲しいんじゃなくて、低水準をほとんど生で触りたい」っつー需要については
守備範囲外だから引き続きC/C++を使っててください、ってことでいいのね？
その場合、低水準に触れるメリットは全く無く、C/C++に匹敵する速度、だけが売りに
なる訳だけど、そうするとScala辺りでいいんじゃないの、ってのはどうなのよ。

あと、VMの起動が重いなんて話じゃなく、アプリの中身のコードの立ち上がりが重い。
トレンドについては、実験ネタとして流行ってるが、どれも実験してるだけに見える。

まぁ、成功の見込みがそもそも無いと思うから、好きに実験すればいい気もする。
つーかこのネタについては建設的意見を全く持ち合わせてないから、この辺にしとく。
一応頑張れ。

439 ：デフォルトの名無しさん：2010/03/22(月) 23:27:07

>>319
最高の研究者を集めてＣＰＵを作らせたらどんなＣＰＵを作るだろうか
という思考実験にはなぜ興味がないのだろうか

ＣＰＵに興味がないのと同様に、言語にも興味がなくなるように仕向けることは
できないだろうか

440 ：335：2010/03/22(月) 23:38:01

>>438
JITは言語バックエンドの話で、バックエンドは場合に応じて選択可能ですから「速度」と「低水準」を両立する事は可能だと思います。
「低水準を生で触る」という需要も満たせるように考えましょう。
というか、今JITの有無にこだわっても言語仕様には影響ないから意味なかったですね。すいません。

>>439
>>319は私ではありません。

441 ：デフォルトの名無しさん：2010/03/22(月) 23:42:41

>>439
> 最高の研究者を集めてＣＰＵを作らせたらどんなＣＰＵを作るだろうか
> という思考実験にはなぜ興味がないのだろうか

興味あるけど、スレ違いだから別のスレッドでやってね＾＾
応援するよ＾＾

442 ：デフォルトの名無しさん：2010/03/22(月) 23:47:00

「低水準を生で触る」を今風のやり方で出来るといいな。

443 ：デフォルトの名無しさん：2010/03/23(火) 01:00:01

既存の～があるからそっち使えばいいって正論だけど、日本発のオープンの言語を作ってやろうって
気概を持った人が少ないよ。いつから日本人はこんなに自信を失ってしまったんだ。
ガイジンが作ったものに飼い慣らされるな！

俺？気概も自信もあるわけないじゃないですか(^q^)

444 ：デフォルトの名無しさん：2010/03/23(火) 01:03:03

　　　　　　　　　　　　　　　　　　｜

　　　　＼　　　　　　　　　　　　ノ´⌒ヽ,,　　　　　　　　　　／
　　　　　　　　　　　　　　γ⌒´　　　　ヽ,
　　　　　　　＼　　　　／／ ""⌒⌒＼　　）　　　　　／
　　　　　　　　　　　　ｉ /　　 ⌒　 ⌒　ヽ　）
　　　　　　　　　　＼　!ﾞ　　 (･）｀ ´( ･）ｉ/　　／
　　　　　　　　　　　　 |　　　　（__人_）　|
　　　　　　　　　　　　　＼　　　　｀ー'　／　＜トラスト・ミー
　　　　　　　　　　　　／ノ⌒)　　､､､､ヽ
＿＿＿＿＿＿　　∈　彡彡　　　　　　 }　　＿＿＿＿＿＿＿＿
　　　　　　　　　　　　~`ー┬―┬――"
　　　　　　　　　　　　　　　```　```
　　　　　　殺伐としたスレにポッポちゃんが現れ2get！！

445 ：デフォルトの名無しさん：2010/03/23(火) 01:31:14

日本発はどうでもいいけど、>>422を備えた低級言語は使ってみたいな。

446 ：デフォルトの名無しさん：2010/03/23(火) 01:57:03

>>443
作っても意味の無い物を作ろうとする気概なら無くていい

447 ：335：2010/03/23(火) 02:01:18

「低水準を生で触る」に関してですが、その為の言語機能を標準として組み込むべきか、拡張仕様とするかについて意見ないですか？
例えばポインタ型変数は標準として提供すべきでしょうか？

448 ：デフォルトの名無しさん：2010/03/23(火) 02:04:42

提供すべき

449 ：335：2010/03/23(火) 02:05:42

具体的に根拠を是非

450 ：デフォルトの名無しさん：2010/03/23(火) 02:15:31

根拠：Cにポインタがあるから

451 ：デフォルトの名無しさん：2010/03/23(火) 02:22:39

>>447
「低水準を生で触る」ときパフォーマンスも要求されることが多いだろうから、
拡張仕様とすることによるオーバヘッド（実行時間が増える、記述の複雑になるなど）がない（or許容出来る程度に小さい）なら、拡張仕様でいいと思う。
そうでないなら、標準として提供すべきだろうね。

452 ：335：2010/03/23(火) 02:23:28

普段からポインタ演算や整数値からのキャスト、アドレス取得等を出来るようにしておくのか、
拡張機能として提供して普段は制限するのかという話です。

453 ：デフォルトの名無しさん：2010/03/23(火) 02:25:58

Cがどうであるかは、どうでもいいと思う。

454 ：335：2010/03/23(火) 02:26:02

>>451
拡張にする場合、普段は禁止しておいてコンパイルオプションかなんかで部分的に許可するという形になるかと思います。

455 ：デフォルトの名無しさん：2010/03/23(火) 02:29:25

>>454
コンパイルオプションでON/OFFするのは美しくないので、制限するにしてもソース中で解除出来た方がいいんじゃないかなー。
コンパイラがワーニング出すのはアリだと思うけど。

456 ：デフォルトの名無しさん：2010/03/23(火) 02:31:32

「低水準を生で触る」機能は拡張機能で、拡張機能を使う宣言はソース中で行う、というのに1票

457 ：デフォルトの名無しさん：2010/03/23(火) 02:33:55

隠蔽しすぎて敷居が高くなるのが懸念されるけど、、

458 ：デフォルトの名無しさん：2010/03/23(火) 02:57:17

C/C++でいいような気がする

459 ：デフォルトの名無しさん：2010/03/23(火) 03:58:15

Javaから入ってPython ,Ruby ,R,C# ときたけど
C/C++は本当に必要に迫られるまで触りたくない

460 ：デフォルトの名無しさん：2010/03/23(火) 04:05:37

もし本気で誰かが言語を作ったとして、
文法覚えて使おうと本気で思ってる人居るの？
どう考えても集団オナヌーだと思うけどな。

Ｃ言語のココが気に入らねーって話なら解る。
あと俺様の希望は、低機能で良いから数KByteのRAMでも動く
マイコン用のＣ言語インタプリタ。SilentC最高。

461 ：デフォルトの名無しさん：2010/03/23(火) 06:38:05

C、C++、C#のすべてを覚えれば代わりの言語なんて作る必要はない

462 ：デフォルトの名無しさん：2010/03/23(火) 10:37:43

>>460
普通の言語は類似品が乱立し競争にさらされ努力しています。
しかしC言語には競争相手がいません。C言語は努力が足りません。C言語は甘え。
なのでC言語が気に入らねーです。

463 ：デフォルトの名無しさん：2010/03/23(火) 10:51:18

Cycloneでいいんじゃね。
ttp://en.wikipedia.org/wiki/Cyclone_(programming_language)

464 ：デフォルトの名無しさん：2010/03/23(火) 11:48:50

oocなんて言語もあるがな。
ttp://ooc-lang.org/

465 ：デフォルトの名無しさん：2010/03/23(火) 11:59:04

C言語を拡張した言語ならいくらでもあるし、
CプリプロセッサもC言語へのトランスレータの一種

466 ：デフォルトの名無しさん：2010/03/23(火) 13:06:12

Cではいけない根拠が薄弱過ぎ
最強を批判したところで最強にはなれんのだぞ
計画倒れどころか計画すらフワフワしてて論外だし
どうしてもと言うのなら、とりあえずその理想の言語っつーやつを開発して持ってこいよ

467 ：デフォルトの名無しさん：2010/03/23(火) 13:27:42

まぐれで最強になったっぽい所が気に入らねーんだろうな。
偶然ではいけない、必然でないといけない、っていうのは宗教に近いが、
本人達は宗教だとは思っていないだろう。

468 ：デフォルトの名無しさん：2010/03/23(火) 13:43:04

お前らは何マジになってんのと言われるまで自覚できないのか？

469 ：デフォルトの名無しさん：2010/03/23(火) 13:51:41

俺らは常時本気なんだよ。

470 ：デフォルトの名無しさん：2010/03/23(火) 15:11:09

”作ったとしたら”とか”作ったとしても”とか、んな事はどうでもいいんだよ。
3億当たったらどうするみたいな話してる時に、
まず当ててみろとか、詳細な使途を書けとか、
コミュ障害でもなけりゃそんな水差さないだろ普通。

471 ：デフォルトの名無しさん：2010/03/23(火) 15:13:31

>>470
そんな途方もないことなわけ？ｗ
やっぱC/C++はすげーな

472 ：デフォルトの名無しさん：2010/03/23(火) 15:24:07

回り見てもコミュ障害しかいませんｗｗｗ

473 ：デフォルトの名無しさん：2010/03/23(火) 15:36:51

このスレの、どこが有意義なのかコミュ障害の人に教えてやれよ

474 ：デフォルトの名無しさん：2010/03/23(火) 16:19:39

有意義じゃなければならないって言う前提が既に自己中心的だね

475 ：デフォルトの名無しさん：2010/03/23(火) 16:21:11

つまりこのスレは無駄以外の何物でもないってことだな

476 ：デフォルトの名無しさん：2010/03/23(火) 16:22:15

いまさら確認するまで気づかなかったのかよ

477 ：デフォルトの名無しさん：2010/03/23(火) 16:26:06

みんな気付いてるよ。Cに代わる言語なんてないってね
馬鹿がC批判して偉そうにしてるだけ
逆にいえば、Cを批判して優越感に浸ると言う意味では、有意義かもしれないねｗ

478 ：デフォルトの名無しさん：2010/03/23(火) 16:31:43

どうしてそう有意義さを見出そうと努力するのかな～？
無駄な物、無駄な時間、無駄話があってもいいと思うのだけどｗ

神経質にやってるとハゲるよ

479 ：デフォルトの名無しさん：2010/03/23(火) 16:34:00

合理性のないコードは汚いです。
無意味なものは存在してはならない。

480 ：デフォルトの名無しさん：2010/03/23(火) 16:34:20

じゃあ>>470は何に水を差されたくなかったわけ
無駄ならいいじゃん。煽りだって無駄だろ？

481 ：デフォルトの名無しさん：2010/03/23(火) 16:39:25

その考え方がコミュ障害なんだけど自覚できないでしょ？
言っても分からないだろうからとっとと黙っとけよｗ

482 ：デフォルトの名無しさん：2010/03/23(火) 16:41:12

コミュ障害と言って話を終わらせる方がよっぽどコミュ障害だろｗｗｗ
「無駄な話してんのにツッコミいれんな！」ってかｗ
糞スレを正論で荒らされて発狂とかレベル低すぎ

483 ：デフォルトの名無しさん：2010/03/23(火) 16:51:52

で、最新のオサレな言語仕様で、マイコンのレジスタアクセスするとか泥臭いことできるの？

484 ：デフォルトの名無しさん：2010/03/23(火) 16:55:11

最新のオサレな言語が作られた理由が、そういう需要を満たすためならあるいは

485 ：デフォルトの名無しさん：2010/03/23(火) 17:49:11

こんなに伸びてるのに何も進まないスレ

x86マクロアセンブラに、まるで新言語みたいな物量のマクロを定義すれば完成

で、以降はマクロアセンブラ製品の選定と、実際のマクロ内容の案出し

あと、その実際にマクロで記述した際に何か気づきがあればそれを列挙して、
そこから言語案出発でどうよ

486 ：デフォルトの名無しさん：2010/03/23(火) 18:01:43

いいこと考えた
.NETのバイトコードのコンパイラを作るんだ

487 ：デフォルトの名無しさん：2010/03/23(火) 18:07:47

>>486
C++/CLIは、それなりに要望を満たしてるよ。
汚いといわれるC++の拡張であることと、MS製なんでアンチがわくという問題があるけどな。

488 ：デフォルトの名無しさん：2010/03/23(火) 18:16:16

>>486 関数呼び出しが大量に並ぶだけですね

>>485
マクロ名：STACKMAN
アドレス位置と長さを記録してるテーブルがあって、
主に関数呼び出し時のポインタPUSH/POPと引数の受け渡し、やローカル一時領域の確保に使う
またその際の記録(いわゆるポインタのポインタみたいな簡単な管理)をする

マクロ名：MEMORYMAN
仮想領域の確保を行うもっとも基本のマクロ。STACKMANもこれを使っている
アドレスのポインタ(レジスタに直入れする値)とサイズを持っていて、再確保の管理をする定型処理

マクロ名：PROCMAN
なんらかの引数と戻り値のポインタをレジスタに渡す為のポインタを管理する
ルーチンの呼び出し、プロシージャコールの原初的な実装

一番簡単な基礎がまずこれで‥ あとI/O関係はDOS/V関係の約束や仕様調べないとわかんね

489 ：デフォルトの名無しさん：2010/03/23(火) 18:18:20

>>459
機会があればSoftintegration(国内代理店はラクネシー)が開発した
CインタプリタとしてChというのがあるから触ってみたら？
無償版あり。

>>484
直接的なハードウェアアクセス用ライブラリがあるなら大抵の言語では可能。

>>485
マクロでは保守面倒そう...。初期段階ではC以外のスクリプト言語を使って
foobar -> Cトランスレータとして実装したほうがいいと思う。

あと俺も今やっているFLOSS翻訳終わっていたら、
仕様調停役担当してもいいんですが事情と物量が邪魔して中断不可能な仕様。

490 ：デフォルトの名無しさん：2010/03/23(火) 23:35:18

デバドラ屋だって、オサレ言語使いたい！

491 ：デフォルトの名無しさん：2010/03/24(水) 00:08:20

じゃD言語使えば？

492 ：デフォルトの名無しさん：2010/03/24(水) 00:15:52

D厨ウゼー

493 ：デフォルトの名無しさん：2010/03/24(水) 00:17:15

Dはオサレじゃないし

494 ：デフォルトの名無しさん：2010/03/24(水) 00:46:20

>>439
その結果できたのが、ItaniumやらCrusoeやら。そいつらがどうなったかは、ご存知の通り。

495 ：デフォルトの名無しさん：2010/03/24(水) 01:06:04

ポインタ型自体やポインタ関連の関数類は別モジュールに置く程度のことはしてもいいだろうけど、
構文中のキーワードで文法自体を制御するってのはいささか気持ち悪さを感じるなぁ。
それにC/C++でも、ポインタは使わざるをえないから使ってるだけで、うっかり間違って使っちゃったってのはあんまりない気がする。

C++の参照のようにポインタを覆い隠す存在も用意していること、それを利用し大抵の操作はポインタなしで行えることは必要。
(Cのように、ポインタどうでもいいのにポインタを使わざるをえない場面というのは避けたい。もう、ポインタ使うのはポインタ用モジュールにまとめちゃっていいかも)

ポインタをどう隠そうと、その背後にメモリとメモリアドレスがあることは避けようがないことだし、
LLとかだとポインタを覆い隠して「同値性と同一性」とか「変更可能な型と変更不能な型」とかいろいろ頑張ってるけど
Cやってる人から見たら、ようはポインタなんだけど言語からポインタを消すために無理してるようにしか見えない。
高級言語ではそれでもポインタを覆い隠すことに意味があるんだけど、低級言語ではそんなことする意味はない。

496 ：デフォルトの名無しさん：2010/03/24(水) 01:17:42

アドレスの抽象化ってポインタ変数が最良なのかな。

他のやり方はないのかな。

497 ：デフォルトの名無しさん：2010/03/24(水) 02:17:52

物に名前をつける以上の抽象化は人間には無理だろｗ

498 ：デフォルトの名無しさん：2010/03/24(水) 02:43:07

そもそもケースによってはメモリマップドIOだろうが、外部IOだろうが絶対アドレスをアクセスできるからこその
低級言語ではないのか？そこは「何らかの言語によるライブラリ」に任せるってのなら主題自体があまり意味が無い気が…

499 ：デフォルトの名無しさん：2010/03/24(水) 04:59:21

>>498
意味ないに決まってんだろ。
このスレ見て他にどう思えるんだよ。
なんか語り口が乱暴でスマンけど。

500 ：デフォルトの名無しさん：2010/03/24(水) 05:05:08

このスレは現実逃避のためだけにある

501 ：デフォルトの名無しさん：2010/03/24(水) 05:18:16

だれも言わないからいっとく
DMR, Ken Thompson, Brian Kernighanらは神
おまいらヒゲが足らねえんだよ

502 ：デフォルトの名無しさん：2010/03/24(水) 07:40:52

>>498
絶対アドレスへのアクセスをポインターよりももっと良いやり方があれば採用したい、ということだろう。

503 ：デフォルトの名無しさん：2010/03/24(水) 10:06:43

ハードウェアが現在のアドレスモデルを採用している以上、これがどうにかならないと無理だな
LISPマシン再来？

504 ：デフォルトの名無しさん：2010/03/24(水) 12:53:24

>>501
ICI言語の隠しページである

> Hey Kids! "Use ICI. It's good for your hair."
(やあボウヤ! ICIを使おう。こいつは髪(ヒゲ？)にいい(育毛剤ではなくカッコヨクなる)ぜ")
ttp://atrn.org/

かよ。

505 ：デフォルトの名無しさん：2010/03/24(水) 16:08:58

Cの最大の利点＆欠点は自由に動き回れるポインタに尽きる
ポインタ演算排したgoのアプローチは面白いんだがGCがネックだな

506 ：デフォルトの名無しさん：2010/03/24(水) 18:03:52

アドレス叩く能力が要らないならOCamlとかScalaとか既に優れた言語がある

507 ：デフォルトの名無しさん：2010/03/24(水) 18:25:14

新言語なんて八方塞だろ。凡人が考えることなんて既に余裕で実行されてるわな

508 ：デフォルトの名無しさん：2010/03/24(水) 19:14:18

トレンド（笑）な方面は特にな

509 ：デフォルトの名無しさん：2010/03/24(水) 19:38:03

>>505
ポインタの扱いを厳格化したものとして既にCycloneがあり、
C -> Cyclone移植ガイドも用意されている。無いのは日本語マニュアルだけか。やってるけど。

またCトランスレータの実装を持つEuphoriaにはポインタは無いが
低レベルメモリーアクセス向けの組み込み関数で用意されている。
これにより共有ライブラリおよび低レベル操作を可能としており。
(少なくともライブラリのユーザーレベルでは)ポインタを意識する必要は無い
さらに関数ポインタと似た機能はルーチンIDとして実装されている。

新言語とか言う前に既存のしかもマイナー言語に勝てない仕様では
どうなんだか。

510 ：デフォルトの名無しさん：2010/03/24(水) 19:41:20

じゃあそれらのマイナー言語を広めるだけで目的達成じゃね？

511 ：デフォルトの名無しさん：2010/03/24(水) 19:58:22

ライブラリによるポインタ操作でもいいというなら、ほとんどすべての言語でポインタを扱うことができる。

512 ：デフォルトの名無しさん：2010/03/24(水) 20:30:49

結局、低レベルに触りたい奴なら、Cをちょっと頑張って使いこなした方がいい
個人的にはアセンブラよりむしろCの方が理解しにくかったが、どっちにしろそう難しくはない

低レベルに触れなくてもいいなら、何度も言われてるが、いくらでも高速で便利な言語はある

513 ：デフォルトの名無しさん：2010/03/24(水) 21:04:19

>509
解説のアクセス先ぐらい置いといてクレ。
ttp://c2.com/cgi/wiki?CycloneLanguage
ttp://www.rapideuphoria.com/hotnew.htm

あと、>422の機能を持つ低レベル言語って存在するのかね？

514 ：デフォルトの名無しさん：2010/03/24(水) 21:15:41

　
　そしてこのスレは意外な　─　ある意味順当な　─　幕切れ迎えるのであった

　　　　　　　　　　　　　　　　　　　　　　　　完
　
　
　
　
　

515 ：デフォルトの名無しさん：2010/03/24(水) 22:45:43

516 ：デフォルトの名無しさん：2010/03/24(水) 22:52:36

C最強を確認するためだけのスレであった

517 ：デフォルトの名無しさん：2010/03/25(木) 00:36:47

>>422の機能が実現できたらいいなー

518 ：デフォルトの名無しさん：2010/03/25(木) 01:07:53

言語仕様どうこうより、優れたライブラリ、開発環境の方が100倍重要で、
>>1はその辺を致命的に勘違いしてる。
「低レベル記述、高パフォーマンス、可読性、簡潔さ、拡張性、学習の容易さ」
そんなもの開発効率と関係ないし、使う動機にならない。
GoやOCamlのような良さげな言語がいっこうに流行らないのもそんな理由でしょ。

519 ：デフォルトの名無しさん：2010/03/25(木) 01:18:42

だって C/C++ がさっぱりわからないし怖いから
GC言語しか触ったことない自分にも簡単に理解出来て、
それでいて使ってて胸が張れるような、別の言語を新たに作ればいいって、
甘えんぼで怠惰な中学生みたいに話摩り替えただけのスレだもの

520 ：デフォルトの名無しさん：2010/03/25(木) 01:35:23

Cのどこが怖いんだ
携帯の料金体系みたいな歪んだサービス精神で開発された言語のほうが怖いだろ

521 ：デフォルトの名無しさん：2010/03/25(木) 01:47:10

まあ特定のOSに特化したものはだいたいそうだな

522 ：デフォルトの名無しさん：2010/03/25(木) 02:34:49

Dでいいじゃない

523 ：デフォルトの名無しさん：2010/03/25(木) 02:42:14

つうか、ＩＯ制御が書けるくらいの奴ならポインタの概念自体難しいとか思わないだろうし、
わかってない奴が無理難題言ってるだけにしか聞こえない。
たぶん彼らの理想がかなっても、その言語を使ってまともなものが作れるとは思えないｗ

524 ：デフォルトの名無しさん：2010/03/25(木) 04:58:52

Dを知らないやつが、C++のアンチテーゼをほしがったんだろ

525 ：デフォルトの名無しさん：2010/03/25(木) 05:32:34

Dはダメだろ
あと20年は完成しない

526 ：デフォルトの名無しさん：2010/03/25(木) 05:33:47

そもそもDの仕様がさっさと安定すればこんなことには・・・

527 ：デフォルトの名無しさん：2010/03/25(木) 06:42:31

Eを新規開発して半年で完成されて、C、Dのシェアを
奪い取る勢いにする。

528 ：デフォルトの名無しさん：2010/03/25(木) 07:31:53

英語は不規則変化が多いからシンプルな言語を作りましょう、
つって今さら言っても誰もついてきてくれないのと一緒。
一番有名なエスペラントでさえ愛好者レベルでしか普及してないだろ。

プログラムの世界でも、
言語の一貫性なんかよりも、今ある資源や人口の方が重要。
言語は宗教でも学問でもないからな。

以前の言語でできないことができるようになった、ならともかく、
少しやりかたを変えてスマートにできるようになりました、ぐらいじゃ誰も移行しない。

529 ：デフォルトの名無しさん：2010/03/25(木) 14:47:18

もうあるんだろうと思うけど、
状態遷移図をストレートかつ簡潔にコード
に落とし込めるような言語は欲しいな

あと真逆になるけどルールベースのアクションをストレートかつ以下略

530 ：デフォルトの名無しさん：2010/03/25(木) 15:05:08

>>518
優れたライブラリを効率良く書くためには言語仕様も大事なわけで

531 ：デフォルトの名無しさん：2010/03/25(木) 15:51:07

前の方読んでないけどDはGCがあるからダメなんじゃないの？

532 ：デフォルトの名無しさん：2010/03/25(木) 16:13:31

>>509
Ken Thompson/Googleが作ったってのがポイントなんじゃw
どんなに優れていても話題にもならんのはダメ
自然言語と一緒だよ
goはnaclがらみで増えるかもしれん

533 ：デフォルトの名無しさん：2010/03/25(木) 17:27:05

>>531
GC使わなければいいじゃん

534 ：デフォルトの名無しさん：2010/03/25(木) 17:42:02

GC切れたんだｗ
詳しくないから知らなかったｗ
てかGC切ってまともに動くの？

535 ：デフォルトの名無しさん：2010/03/25(木) 17:51:16

Objective-Cの作者がC++が流行ったのは
AT&Tだからだいってたな

536 ：デフォルトの名無しさん：2010/03/25(木) 18:10:03

C++ はかなり早い時期に Microsoft と Apple が公式開発環境で採用したよね
Apple のなんて AT&T 謹製 cfront だった。

537 ：デフォルトの名無しさん：2010/03/25(木) 18:23:48

>>529
そういうのはDSLとして実装したらいい
機械的にやりたいなら言語じゃないけど
yacc/bisonなんかでオートマトンでどうよ

538 ：デフォルトの名無しさん：2010/03/25(木) 19:10:14

Objective-Cはあのキモい文法をまずなんとかしろと言いたい

539 ：デフォルトの名無しさん：2010/03/25(木) 21:05:09

ぶっちゃけObjective-Cは重いのが敗因だろ。
重いと負けることが分かってるから、C++は何が何でもゼロオーバーヘッドを守ろう
とし続けてる訳だし。まぁ最近は例外機構のオーバーヘッドは避けられなくなりつつ
あるが。RTTIは今でも基本オフでおｋの世界だけど。

マシンパワーが余りつつあるから重さは気にしなくてもいい、ってのはあくまでもPC
の事務用途の話で、鯖だのゲームだの携帯だの、今でも必死な方面は多い。そういう
ところでは実行速度が出るかが足切り基準。開発速度の選り好みはその後の話。

540 ：デフォルトの名無しさん：2010/03/25(木) 21:09:26

Objective-Cが重い？

541 ：デフォルトの名無しさん：2010/03/25(木) 21:32:07

動的だからな

542 ：デフォルトの名無しさん：2010/03/25(木) 21:57:30

糞言語と知れ渡ってるPHPが勝ち組なのも軽いからだな
軽さは要らないから圧倒的に手軽にしてくれ、という需要はLLが満たしてる

だから、軽い言語を求めるという点では>>1は間違っていない
その他が間違いだらけなだけで

543 ：デフォルトの名無しさん：2010/03/25(木) 21:58:24

>>542補足
s/その他が/その他の点が/

544 ：デフォルトの名無しさん：2010/03/25(木) 22:18:53

PHPのどこが軽い。

545 ：デフォルトの名無しさん：2010/03/25(木) 22:20:30

>>539
ぶっちゃけC++は糞フレームワークと使う奴らがヘボ

Cはランタイム云々って話があったが
リセットベクタからアセンブラ数行程度で動き始める言語は他にはない

546 ：デフォルトの名無しさん：2010/03/25(木) 22:26:04

どういう理由でCが使われているかということと、それに矛盾のないものしか機能として追加できないということは理解しておかないと。

547 ：デフォルトの名無しさん：2010/03/25(木) 22:30:57

>>422 の Lisp みたいなマクロって、要は言語を構成する要素をデータとして
扱えればいいんだよね。そいで、それをコンパイル時に評価できて、プログラ
ムとして生成すると。
そう考えると、仮に S 式を捨てたとしてもそこまで夢の機能ってわけでもない
気がするんだけど、どうだろ。S 式じゃないとなるとお手軽さは失われそうだ
けども。

548 ：デフォルトの名無しさん：2010/03/25(木) 22:36:56

Webサーバのグルー言語としちゃ断然軽いが、Apacheモジュールに比べたら非常に重い

549 ：デフォルトの名無しさん：2010/03/25(木) 22:55:15

>547
・引数を評価しないでそのまま関数内に展開
・関数の中ではあくまで一つの要素として扱われる
という扱いができればS式に拘らなくてもOKじゃね？

遅延評価でけっこうカバーできるだろうけど、上手く作りこめば効率などで有利になれるんじゃない？
例えば引数（適用前の関数）の中身をコンパイラが理解して最適化するとか。

550 ：デフォルトの名無しさん：2010/03/26(金) 00:53:49

>>545
CPUにもよるがうまく組めばRAMがまだ使えない状況でも動作するしなｗ

551 ：デフォルトの名無しさん：2010/03/26(金) 06:50:14

俺は結局、Mcrosoftの意向だと思うな。

Ｃ言語に「//」で始まるコメントを許しちまうとか、
char　str[10][10]={”123”,”abc”,0}こんな初期化もMicrosoft拡張だったか…
unsigned shortをWORDとか、defineで凌げると思ってたらLONGLONGがfloatと別物だったり。

VisualBasicなんか完全オリジナルな訳だが、ソレしか知らんオッサンには
自分がなんで他言語のプログラマに蔑まされるか理解不能だわな。
Mcrosoftが高効率のバイナリーを吐くVisualBasic作ったらソレが標準になりかねん。

552 ：デフォルトの名無しさん：2010/03/26(金) 06:54:57

いやそれはない

553 ：デフォルトの名無しさん：2010/03/26(金) 07:00:05

VB>>>>>>>>>>>>>>>>>>>>D>>>超えられない壁>>>>>>>>>>>>>>>>>>>>その他のマイナー言語
が現実

554 ：デフォルトの名無しさん：2010/03/26(金) 07:04:42

バカじゃね。COBOLだよCOBOL。

555 ：デフォルトの名無しさん：2010/03/26(金) 07:07:20

C++使ってようがC#だろうがVBだろうがなんでもいいけど
MSの世界しかしらねえ奴の方が
よほど蔑まされてることに気づけよ

556 ：デフォルトの名無しさん：2010/03/26(金) 07:08:47

COBOL>>>>>VB>>>>>>>>>>>>>>>>>>>無収入の壁>>>>>>>>>>>>>>>>>>>>D他マイナー言語

557 ：デフォルトの名無しさん：2010/03/26(金) 07:24:13

>>551
無知まるだし
Cの独自拡張ならGCC

558 ：デフォルトの名無しさん：2010/03/26(金) 07:26:33

LONGLONGがfloatってなに

559 ：デフォルトの名無しさん：2010/03/26(金) 12:50:59

時折、無知や知ったかが現れるのも中二スレの特徴なり

560 ：デフォルトの名無しさん：2010/03/26(金) 17:27:35

>>551
//はBCPL時代の仕様を勝手にサポートするコンパイラが多かっただけ
初期化の発祥は知らん
WORDやLONGLONGは言語標準じゃなくただのWindows標準ヘッダのマクロじゃね

とりあえずお前がMS以外の世界を全く知らないことはよく分かる

561 ：デフォルトの名無しさん：2010/03/26(金) 20:55:44

いつの時代だよｗｗｗ

LONGLONGAGO

562 ：デフォルトの名無しさん：2010/03/27(土) 13:17:13

GC無しのLispでいいんじゃね。
超高速だぞ。

563 ：デフォルトの名無しさん：2010/03/27(土) 14:33:31

こんなのどうだ。
C並に低レベルな関数型言語。
http://www.bitc-lang.org/docs/bitc/spec.html

564 ：デフォルトの名無しさん：2010/03/27(土) 14:34:13

BitC is a new systems programming language. It seeks to combine the flexibility, safety, and richness of Standard ML or Haskell with the low-level expressiveness of C.

565 ：デフォルトの名無しさん：2010/03/27(土) 19:23:07

>>560
それでも>>551の言うようにMSの意向が大きいよ。C#の次はF#がくるかもよ。

566 ：デフォルトの名無しさん：2010/03/27(土) 20:14:48

F#が来るにしても10年後の話だ
どうでもいい

567 ：デフォルトの名無しさん：2010/03/27(土) 23:24:53

>>1はどこいったんだろう

568 ：デフォルトの名無しさん：2010/03/27(土) 23:31:58

Cが最強だと納得して巣に帰りました

569 ：デフォルトの名無しさん：2010/03/27(土) 23:34:37

OCamlは、プロトタイプにはすでによくつかわれているから、すぐ来るんじゃないかと。

570 ：デフォルトの名無しさん：2010/03/27(土) 23:47:10

とりあえず、関数ベースのシステムコール設計はやめてgotoベースのシステムコールに設計し直して欲しい。

571 ：デフォルトの名無しさん：2010/03/28(日) 00:14:50

なんで

572 ：デフォルトの名無しさん：2010/03/28(日) 00:32:18

関数呼び出しは遅いから。

573 ：デフォルトの名無しさん：2010/03/28(日) 00:33:44

push popすんなよ遅いんだよ。ジャンプ命令でシステムコールする新しいOS作れ

574 ：デフォルトの名無しさん：2010/03/28(日) 00:46:14

昔のメインフレーム

575 ：デフォルトの名無しさん：2010/03/28(日) 00:57:28

今のUnixやWindowsなどのOSはC言語で扱うために設計されているから
システムコールが関数呼び出しなのはしょうがないんだよね。
別にC言語にこだわらないならジャンプ命令でいいんだよ。

576 ：デフォルトの名無しさん：2010/03/28(日) 01:16:34

最低でもリターンアドレスは詰む必要あるだろ
その際popは必要ないが
espをpush/popするかはコンパイラ次第
普通は必要なければpush/popしない

577 ：デフォルトの名無しさん：2010/03/28(日) 01:30:10

>>563
チラ見しかしてないが、かなり良い感じがする。

578 ：デフォルトの名無しさん：2010/03/28(日) 01:32:32

関数型でポインタとか泥臭いな
だがそこがいい

579 ：デフォルトの名無しさん：2010/03/28(日) 02:12:24

おまえら頭悪いな
全部mainでやりゃいんだよ

580 ：デフォルトの名無しさん：2010/03/28(日) 02:13:30

システムコールはtrapだろ

581 ：デフォルトの名無しさん：2010/03/28(日) 02:16:00

連投してみる
>>576
risc cpuはコールするときレジスタに戻りアドレスを入れる

582 ：デフォルトの名無しさん：2010/03/28(日) 02:59:18

>>454-455
C#のunsafe方式が頭をよぎった。

583 ：デフォルトの名無しさん：2010/03/28(日) 03:09:57

つーか386のコールゲートも変な仕組みだった気がするが忘れた

584 ：デフォルトの名無しさん：2010/03/28(日) 03:10:54

つまりCが最強C#が至高と言う事で宜しいか

585 ：デフォルトの名無しさん：2010/03/28(日) 10:18:59

C++/CLIは、Cの範囲からC#の範囲までカバーしている。

586 ：デフォルトの名無しさん：2010/03/28(日) 10:30:07

それはソース上の話じゃないか。実質C++/CLIは、どちらかと言えばほぼC#

587 ：デフォルトの名無しさん：2010/03/28(日) 15:49:19

それのほぼC++版がD言語

588 ：デフォルトの名無しさん：2010/03/28(日) 15:52:10

だから、デジタルマーズのD言語は流行らないんだって・・・いまどき

589 ：デフォルトの名無しさん：2010/03/28(日) 15:54:25

C++をわずかに変化させただけの言語を今更利用しようと思う理由がない。
よほどの理由がない限り、多少の改善程度ではユーザーは移動しないんだよ。

590 ：デフォルトの名無しさん：2010/03/28(日) 16:37:03

ありゃわずかじゃないだろ
膨大に変化してる

591 ：デフォルトの名無しさん：2010/03/28(日) 16:47:49

C++のコードを何％縮められる？

592 ：デフォルトの名無しさん：2010/03/28(日) 17:07:16

縮むとか縮まないとかそういう問題じゃないだろ

593 ：デフォルトの名無しさん：2010/03/28(日) 17:16:52

>>592
そういう問題だと思うんだけど。
俺に言わせてみれば、セミナー屋が
「この機能で大幅にバグを減らせます」
と言っていることの９９．９％がウソか大げさ。
バグが潜む原因のほとんどは設計とアルゴリズムにあると思うね。
C++→D程度なら設計を変えるほどの大幅な仕様変更ではないし、
そもそもアルゴリズムは言語とは無関係。

594 ：デフォルトの名無しさん：2010/03/28(日) 17:20:47

>>593
アルゴリズムのバグ。コード化で入り込むバグ。バグが発生しやすいような設計。
がきりわけられていないんじゃないか。
バグは言語と関係ないとう部分は多いが、脆弱性は大いに関係ある。

595 ：デフォルトの名無しさん：2010/03/28(日) 17:21:16

バグを減らせるとか関係ない
便利な機能が色々増えてるけど
それが「コードが縮む」と言う事に繋がるとは限らないということ
例えばC89ではマクロを使っていたのをC++ではinlineに変更したとして、
これは便利にはなっているけどコードはむしろ長くなるでしょ

596 ：デフォルトの名無しさん：2010/03/28(日) 17:24:33

言語的に原理的に発生しなくなるバグとかもあるしね
GC言語でのメモリリークとか
VBだとなぜか参照されていると見なされて似た現象が発生することもあるが・・・

597 ：デフォルトの名無しさん：2010/03/28(日) 17:27:34

>>595
> C89ではマクロを使っていたのをC++ではinline
コード量は長くも短くもならないと思うよ。

598 ：デフォルトの名無しさん：2010/03/28(日) 17:28:58

>>596
旧VBは、GCじゃないよ。

599 ：デフォルトの名無しさん：2010/03/28(日) 17:30:33

CからC++に利用者が移動した理由は、
上位互換性とオブジェクト指向の導入でしょ。
inlineが決定的な理由じゃないよ。

600 ：デフォルトの名無しさん：2010/03/28(日) 17:35:03

>>597
>コード量は長くも短くもならないと思うよ。
戻り値や引数に型つけたり { } つけたりするでしょ
inlineにする程度の長さなら、マクロ引数に ( ) をつける影響より大きくなる

601 ：デフォルトの名無しさん：2010/03/28(日) 17:35:46

場合によってはreturnもだな

602 ：デフォルトの名無しさん：2010/03/28(日) 17:39:04

>>600
それは、誤差範囲といっていいだろ。

603 ：デフォルトの名無しさん：2010/03/28(日) 17:40:10

500行が1000行になるわけではなし、そんな些細なことを大ごとに語るなよ。

604 ：デフォルトの名無しさん：2010/03/28(日) 17:44:30

C++からDに移行する最も大きい理由はなんですか？

605 ：デフォルトの名無しさん：2010/03/28(日) 17:55:23

C++で書かれたコードを同じアルゴリズムでHaskellのコードを記述したらコード量が10分の1になった、
という事例ならあるんだけどね。
それぐらいのメリットがないと誰も移行を考えたりはしない。

606 ：デフォルトの名無しさん：2010/03/28(日) 17:56:33

Haskellは難しいから普通のプログラマー向きじゃない

607 ：デフォルトの名無しさん：2010/03/28(日) 18:05:04

１行が多分３～４行になるけどね

608 ：デフォルトの名無しさん：2010/03/28(日) 18:07:31

BoostのspiritとかMPLとか、言語内言語みたいなのがあるじゃない。
ああいうのをもっと綺麗な形でサポートしてほしいな。

609 ：デフォルトの名無しさん：2010/03/28(日) 20:03:10

>>605
クイックソートのことなら、Haskellのは配列の要素入れ替えじゃなくて新しい配列を作って連結してるだけだろ。
それってSTLコンテナとか使ったらC++でも同じ方法ではできるようにならないの？
Haskellほど短くは書けないだろうけど、もっと少なくはなると思う。

610 ：デフォルトの名無しさん：2010/03/28(日) 20:11:39

>>609
haskellのクイックソートって、デモンストレーションで、
実用じゃ使えないしな。

611 ：デフォルトの名無しさん：2010/03/28(日) 20:25:18

そういえば、全く言語ごとの最適化とか考えずにベンチ書いて「Java最速でしたよ」
とかアホなこと書いた外人が理詰めでフルボッコされてたな

612 ：デフォルトの名無しさん：2010/03/28(日) 22:06:01

「Java最強でしたよ」なら真理なのにな

613 ：デフォルトの名無しさん：2010/03/28(日) 22:35:44

速度の話は、コードの良し悪し、向き不向きまで考えると、本当に難しい。大体の基準はあっても、個々にはケースバイケースとしか言いようがない。
ただ、言えることは

・高級言語では、アセンブラでの最速コードよりも速いコードは書けない(よくて同等。多くの場合はより落ちる)
・Cはアセンブラとほぼ同等な高級言語と言える
・C++はCとの互換性より、原理上はCと同等かもしくはより速いコードが書けるが「C++らしい」書き方をするにはCより遅くなる覚悟が必要
・JavaのようなVMを利用する言語、インタプリタ型言語のような非ネイティブな言語で、VMやインタプリタがネイティブな言語で書かれている場合
　　そのネイティブな言語で書き直せば、非ネイティブな言語で書いた場合と同等かそれ以上の速度で動作するコードを書ける
・VMやインタプリタが、非ネイティブな言語で書かれていたとしても、それが実際に動作する処理系である以上は元を辿ればネイティブな言語にたどり着く。
　　よって、やはり同等以上の速度でコードが書けるネイティブな言語は存在する

・ただし、最速のコードが「存在する」とは、書くことの大変さ、書ける人間が存在するかを一切無視しての話である
・例えば、下手にアセンブラ使うよりもCで書いてコンパイラの最適化に任せた方が結果的に速いコードができることが多い
・同様に、下手にCを使うよりもJavaやLLで書いた方が速くなることだってありうる
・けど、LLよりも遅いCコード書いちゃう人はさすがにちょっと残念

614 ：デフォルトの名無しさん：2010/03/28(日) 22:44:47

アセンブラでの最速コードは理論的最高値だから
同等だったら最高で文句の付けようが無い状態じゃん　＞よくて同等

615 ：デフォルトの名無しさん：2010/03/28(日) 22:50:47

つうかx86コードをマイクロコードに変換して実行するとか、投機実行をする現在のプロセッサにおいて、
アセンブラで書けば速いなんて脳が20年前で止まってるとは言えるが、Javaで書いてもCより速くなる
なんてのは絶対無い。同じ仕様を同じロジックで書けばね。静的であるか動的であるかはそれくらい違う。

616 ：デフォルトの名無しさん：2010/03/28(日) 22:54:35

Javaよりも遅いCコード書いちゃう人はさすがにちょっと残念ってことで

617 ：デフォルトの名無しさん：2010/03/28(日) 23:11:06

>>613
>・JavaのようなVMを利用する言語、… VMやインタプリタがネイティブな言語で
> 書かれている場合

そもそもVMやインタプリタがネイディブで無い言語で書かれてることってあるのか。
(実用的な処理系で)

618 ：デフォルトの名無しさん：2010/03/28(日) 23:14:11

「javaのVMがネイティブな言語で書かれてるから」って理由で
javaもネイティブな言語並みにスピード出せるっておかしいだろ。

619 ：デフォルトの名無しさん：2010/03/28(日) 23:48:32

なんか話がスレタイから全速力で遠ざかってないかｗ

620 ：デフォルトの名無しさん：2010/03/28(日) 23:53:57

必要ないってとこに収束しつつあるだけだよｗ

621 ：デフォルトの名無しさん：2010/03/29(月) 00:09:24

言語の純粋な仕様・性能よりも、どこが作ったかが運命の分かれ道

622 ：デフォルトの名無しさん：2010/03/29(月) 00:16:40

>>1 が自分でつくるつもりもなくてスレを立てたんなら、
最初から雑談スレになる運命。

623 ：デフォルトの名無しさん：2010/03/29(月) 00:16:57

>>613
このての議論って
＞・同様に、下手にCを使うよりもJavaやLLで書いた方が速くなることだってありうる
仮定を前提としてるけど、ひとつでも実例を示したことがあるのかって思うぞ。

624 ：デフォルトの名無しさん：2010/03/29(月) 00:45:31

>>623
そもそも、あるPGがループソートをCで書き、他の言語では別のPGがクイックで書くとか、
そういう前提だから意味が無いｗ

625 ：デフォルトの名無しさん：2010/03/29(月) 00:50:07

>>623
十数年前、Javaがではじめたころは、実行時にコードの実行状態を
見て動的に最適化できるから、Javaのほうが速くなる可能性があるって
話があったけど、いまだに「Javaで書いたwebサーバーのほうがapacheより
速いぜ」みたいな話って聞かないしな。

626 ：デフォルトの名無しさん：2010/03/29(月) 00:55:16

JavaはGCで使ってるメモリが整理されて局所的になるからキャッシュがヒットし易くなる「可能性がある」とかいってたな。
そこにいたるまで膨大なＧＣのオーバーヘッドがあるわけだし。パフォーマンスは最悪値を保証しなければならないんで可能性なんて無意味だし。

627 ：デフォルトの名無しさん：2010/03/29(月) 00:56:23

＞・同様に、下手にCを使うよりもJavaやLLで書いた方が速くなることだってありうる

この言い様って、まるで「１＋１は２とは限らない」みたいな、小５病的な台詞

628 ：デフォルトの名無しさん：2010/03/29(月) 01:14:52

>>627
そういう本読んだことがあるけど、水１リットルとアルコール１リットルを混ぜると２リットルより小さくなるって理屈だったな。
それは式の立て方が間違ってる。質量で計算しろと。

629 ：デフォルトの名無しさん：2010/03/29(月) 01:35:34

アルコールがいつの間にか減ってたんじゃないの？それ

630 ：デフォルトの名無しさん：2010/03/29(月) 01:46:19

たったの70グラムの砂糖を食べたらなぜか500グラム体重が増える不思議

631 ：デフォルトの名無しさん：2010/03/29(月) 02:47:31

Cより書いた方が”実行時間が”速くなるというのは詭弁だろうが、生産性を考えるとOOP言語の方が良いし
汎用性を考えるとVMを利用する言語が良い。アルゴリズムにも言えるけど、速さが全てなのかって話

632 ：デフォルトの名無しさん：2010/03/29(月) 03:20:33

vmはエコじゃねえな

633 ：デフォルトの名無しさん：2010/03/29(月) 03:27:02

>>631
VM で動くブラウザやらIMEやらを使い
動画のコーデックも Java でokとか
そういう人以外がその発言するのは偽善

正直に、バカしか使えないような貧乏な
客が殆どなんだから LL にも価値あるだろ
と言え

634 ：デフォルトの名無しさん：2010/03/29(月) 03:28:56

>>633
偽善じゃねーよ。環境に依存しないことがどれほどの意味を持ってるのか分かってんの？

635 ：デフォルトの名無しさん：2010/03/29(月) 04:07:11

なんでもいいんだが、スレ違いだろって話。
OSやVMやGCやLLを書ける低レベルな言語について考えるスレなんだから。

636 ：デフォルトの名無しさん：2010/03/29(月) 04:19:01

だからCより優れたものはあり得ないって結論が出ただろ。Cが最適
Cやアセンブラの弱点である汎用性はVMによって完成した。これだけの話なんだよ

637 ：デフォルトの名無しさん：2010/03/29(月) 04:32:16

CとJavaを速度で比べる場合、Cでヒープを使うときはGCを使い、配列を使うときにはバウンドチェックしているコードでないと意味がない。

638 ：デフォルトの名無しさん：2010/03/29(月) 05:31:00

Cとjavaを速度で比べるとか、正気かよ。それともただの初心者か。
比較にならないことは原理的にもすぐわかるし、Eclipseの殺人的な重さを見てみろよ。

639 ：デフォルトの名無しさん：2010/03/29(月) 05:35:59

>>631
速さが全てだろ。
汎用性だ何だってのはゴミプログラマが自分の無能さを隠すための言い訳だよ。
Cで書いたって、コア部分は共通にして、機種依存部分のみ分けることで多機種開発は可能になる。
Cがよくわからないゴミプログラマには無理だがなｗ

640 ：デフォルトの名無しさん：2010/03/29(月) 06:37:15

アルゴリズムは見た目の分かり易さが優先されることが往々にしてあるが。
悪意をもってしか文章を書けないなら他所でやればいいのに
正当性を欠いてるよ

641 ：デフォルトの名無しさん：2010/03/29(月) 07:19:03

>>638
この人は、Eclipseと何を比べたのだろうか。

642 ：デフォルトの名無しさん：2010/03/29(月) 07:23:48

NetBeansもJavaで書かれてるよね。Eclipseより速いとか聞いたんだがどうなんだろう

643 ：デフォルトの名無しさん：2010/03/29(月) 07:33:37

新しい言語でなくていいだろ。
C#のコンパイラでネイティブコードを出力できるのを作れば。

644 ：デフォルトの名無しさん：2010/03/29(月) 07:46:27

* Cでダメな理由は何か
* C++でダメな理由は何か
* Dでダメな理由は何か

これらの質問に多くの人が納得できる十分な答えがなければ、たぶん新しい言語はいらない

645 ：デフォルトの名無しさん：2010/03/29(月) 07:55:10

>>643
CLIからネイティブへのコンバーターはあるからあるも同じ。
ILGeneratorクラスがあるので、VMを完全になくすことはできない。

646 ：デフォルトの名無しさん：2010/03/29(月) 08:56:06

>>615
まぁ落ち着け。アセンブラで書けば一番速いのは事実だ。
何しろ、マイクロアーキへの最適化だろうがランタイム動的最適化だろうが、書く気に
なればアセンブラで書ける。労力が馬鹿馬鹿しいだけだ。

647 ：デフォルトの名無しさん：2010/03/29(月) 09:17:46

>>614
だから、そう書いてるんじゃん。

>>616
「理論上の最速コード」においてCがアセンブラを越えられないのは今でも変わらない。
それに「下手にアセンブラ使うよりもCで書いてコンパイラの最適化に任せた方が結果的に速いコードができることが多い」
と書いている。

>Javaで書いてもCより速くなるなんてのは絶対無い。
>>611参照。
厳密な意味では、同じ仕様を同じロジックで、というのは大変難しいと思うが。

>>617
広く使われている処理系では、知らない。
一応、jruby, jython, groovyみたいなのもあるらしい。

>>618
え？そんな理由で出せるの？それはおかしい。
どんなにうまく書いても、ネイティブな言語を越えることはできないと書いてるだけ。

同等のスピードが出せるのは、一旦VMを作って中間コードを処理していくのがCで書いても最速な処理だった場合のみだな。
そんなコードあるとはとても思えないが、ないと言いきる自信はなかったから、同等以下という表現に止めた。

>>623
>>611

>>624
それが真理。けど、最速コードなんていうどこにあるのか分からないものを追い求めるのが実質不可能なのだから、
簡単に使えるものの中で一番マシなのを選ぶことになる。

>>627
プログラマなら、1+1が1になったり0になったりする場合を知っているはずだが。

648 ：デフォルトの名無しさん：2010/03/29(月) 09:26:46

理論上の話をするなら、アセンブラで最適化するよりも、中間コードをJITで最適化する方が速いコードができる。

649 ：デフォルトの名無しさん：2010/03/29(月) 10:31:02

>>648
今時のマトモなプログラマならプロファイラ
使ってフィードバック最適化するだろうから、
そういうケースは実に稀だと思う。

650 ：デフォルトの名無しさん：2010/03/29(月) 10:32:34

その理論って、アセンブラは醜いCISCで、VMは美しいスタックマシン
という設定なんだろうな

651 ：デフォルトの名無しさん：2010/03/29(月) 10:38:04

>>647 お前仕事してないだろ
そしてなんでお前が全レスする必要があるの？

＞プログラマなら、1+1が1になったり0になったりする場合を知っているはずだが。

プログラマだったら文意くらい読み取れよ。

652 ：デフォルトの名無しさん：2010/03/29(月) 10:59:15

>>646
移植性が悪いじゃん

653 ：デフォルトの名無しさん：2010/03/29(月) 11:05:31

＞プログラマだったら文意くらい読み取れよ。

「CよりJavaの方が速い場合もありうる」なんて、本来ならば相当に前提や条件が "狭まらないと起こりえない話" を
例すら出さずに簡単に断言してしまうなんて、プログラマの感覚からするとありえない。
よって、「おまえ仕事してないだろ」　と仮定した。

また、細かい前提などはわからないけど、簡単な言葉で意表をつきたかった、っていう気持ちは、
何も知らない夢見がちな小学生くらいの子に時折見られる事なので、端的に例えて現した。

こういう事ですね。 >>647 は残念な子だとわかった。

654 ：デフォルトの名無しさん：2010/03/29(月) 12:51:56

>>644
仕方ないことだがCはSecureではない。Human Errorに弱い。人間工学上は問題が多い。
歴史的経緯からSyntax/Statementが混乱している。C++は最初は良かったが巨大になりすぎた。
DとかGoはキラーアプリ次第。

さらにECERE SDK(eC)[ ttp://www.ecere.com/]は技術水準は高いが全般的に未完成。

しかし、上記の欠点はツールや時間が解決する問題であって現代の問題は入門書。
基礎しか考慮していない本のほうが多い。ほとんどの場合は次に読む本べきの便覧を載せていない気がする。

655 ：デフォルトの名無しさん：2010/03/29(月) 12:53:38

前から思っていたが>>1の要求はEuphoria 4.0b3以降[ ttp://oe.cowgar.com/ ]で十分だろ。
これ以上に簡単で習得しやすく文法や構文の不自然さが少ない言語なんかあまり無いけどな。
BSDライセンスなんだし。必要eucを改造して生成コードの品質改善するなりGC無効化機能付ければいい。

もっとも、学生さんなら普通に生活しつつ言語開発に
３年くらい無駄にして失敗しても人生リカバリーできるから、やるならやっとけと。
(OSや言語といった規模の大きいものは若気の至りがないと進捗が遅い)

656 ：デフォルトの名無しさん：2010/03/29(月) 13:58:54

汎用性ならCが一番だよ
ほぼどんな環境でも動くし。
あと最近はコンパイラの最適化より
早いasm書けるやつは少ないな
パイプラインと実行ユニット意識して書くのはめんどい

657 ：デフォルトの名無しさん：2010/03/29(月) 14:02:17

つか、理論的にはどんな言語も大同小異
自然言語と同じでマイナーなのはダメ
誰もエスペラントなんて使わん

658 ：デフォルトの名無しさん：2010/03/29(月) 14:03:01

CPUの構造なんて多種多様で昔みたいに単純じゃなくなってるから、
もはやコンパイラの方が遥かに優秀だよ。

659 ：デフォルトの名無しさん：2010/03/29(月) 14:10:09

そもそもアセンブラでCPUを最大限まで活用できるプログラムが書けるほどの熟練者なら
世界最強のコンパイラを作れるよｗ
俺らより遥かに熟練した奴がコンパイラ作ってるんだから、そのコンパイラを使った方がいいに決まってる。

660 ：デフォルトの名無しさん：2010/03/29(月) 14:20:58

高性能な低レベル言語を作りたいなら、まずはアセンブラでのプログラミングを極めて、
さらに論文などを読んでいろんな人が考えた最適化法を学ばないといけない。
そんな積み重ね無しに既存のCコンパイラを超える低級言語を作ろうなんて片腹痛い。
Cコンパイラですら一人で作るには限界があるっていうのにね。
動くものを作るだけなら簡単。最速を目指すならその10000倍の努力が必要。

661 ：デフォルトの名無しさん：2010/03/29(月) 14:29:21

10000じゃすまないんじゃないか
熟練じゃ超えれない才能の壁がある
ぽっと出じゃ20年前のfortranすら超えれないなw

662 ：デフォルトの名無しさん：2010/03/29(月) 14:31:34

まぁ、このスレでできる事といったら、いい感じの文法を考えて、Cへのトランスレータを作ることだね。
最適化はCコンパイラに任せればいいさ。

663 ：デフォルトの名無しさん：2010/03/29(月) 14:37:13

>>662
それが現実的だな。

664 ：デフォルトの名無しさん：2010/03/29(月) 14:42:21

なんか違うなあ
Cは速さへの執着を捨てて勝ち組になったのに
Cの速さに追いつくことしか考えてないやつが多すぎる

665 ：デフォルトの名無しさん：2010/03/29(月) 14:51:06

>>664
アセンブラではプログラマの能力的に最速記述は現実的に不可能だし、
最新のCPUは全部C言語に最適化して設計されているし、
現状最速の低級言語は間違いなくC言語だという前提で話してるんだけどな。
そしてCコンパイラ並に最適化されたコンパイラを作るとなると相当な努力が必要だから、
最適化はCコンパイラに任せて、我々は文法を考えることに力を注ぐべきだと言っているわけね。

666 ：デフォルトの名無しさん：2010/03/29(月) 14:55:50

>>665
分業とか現実解を考えたらそうなるよな

667 ：デフォルトの名無しさん：2010/03/29(月) 14:59:22

665の最初の4行は読まなくていいと言っているわけね

668 ：デフォルトの名無しさん：2010/03/29(月) 15:21:04

突っ込みどころ満載だなｗ
まあでも現状Cは高級アセンブラとしての地位を確立したし
これ以上も以下もいらんだろ
C++の末裔は同じ立ち位置には立てないな

669 ：665：2010/03/29(月) 15:28:22

>>668
どうぞ、突っ込んでください。
ツッコミ大歓迎。

670 ：デフォルトの名無しさん：2010/03/29(月) 15:37:07

昔々国産でbaseとかいうアセンブラがあったな
ifでキャリーフラグとか見れた

671 ：デフォルトの名無しさん：2010/03/29(月) 16:05:26

なんだこのスレ馬鹿しか居ねぇ

672 ：デフォルトの名無しさん：2010/03/29(月) 16:07:46

>>671
賢そうに見える発言どうぞ

673 ：デフォルトの名無しさん：2010/03/29(月) 16:13:40

とりあえずyaccとかでなんか作って遊んでみたらいい

674 ：デフォルトの名無しさん：2010/03/29(月) 16:18:00

自分が何をやっているのか頭にするする入ってくるスパゲッティをかける言語作ってくださいよ

675 ：デフォルトの名無しさん：2010/03/29(月) 16:38:36

>>665の理由でcは不動だし、
c++はc形式で書けちゃうし、c++ゴリゴリも出来るし、ちょうど良い間でも書けるし…
足りない部分は経年によるノウハウと自作・自社・サードハーティーなどのライブラリもあるし……

困ったね。

676 ：デフォルトの名無しさん：2010/03/29(月) 16:41:16

>>675
> ゴリゴリ
用法がおかしい

677 ：デフォルトの名無しさん：2010/03/29(月) 16:43:00

>>676
じゃあ「c++る」で

678 ：デフォルトの名無しさん：2010/03/29(月) 17:00:07

スレ違いだが
センスは一年もたたずに開いてくる
ないヤツは経験でカバーしかないが
高見には登れないんだよな

679 ：デフォルトの名無しさん：2010/03/29(月) 18:16:34

>>669
SIMD でマトモなコードを吐くコンパイラがないから、
速度が必要なトコではまだまだアセンブラが使われてるよ。

680 ：デフォルトの名無しさん：2010/03/29(月) 18:26:15

>>679
SIMDはライブラリで利用できると思う。

681 ：デフォルトの名無しさん：2010/03/29(月) 18:27:45

>>679
ふつーintrinsics

682 ：デフォルトの名無しさん：2010/03/29(月) 18:31:56

普通は特定のCPU向きの機能を使うためのCライブラリが用意されていることがほとんどだから
インラインアセンブラを使うケースはほとんどなくなってきたね。

683 ：デフォルトの名無しさん：2010/03/29(月) 21:16:29

なんでアセンブラの話が出てくるの？

おじいちゃんしかいないのここ？

684 ：デフォルトの名無しさん：2010/03/29(月) 21:17:20

C/C++でアセンブラを使うのは普通

685 ：デフォルトの名無しさん：2010/03/29(月) 21:21:33

アセンブラに逃げるのは思考の放棄に他ならないのである。

686 ：デフォルトの名無しさん：2010/03/29(月) 21:22:34

とりあえず、静的なネイティブコンパイラよりも、
実行時中間コードコンパイラの方が速そうな気がする例。
本当かどうか知らない。ためしてない。

for (int i = 0 ; i < 1000000000 ; i++) {
switch (ユーザ入力値) {
case 50: a[i] *= b[i] ;
case 70: a[i] &= b[i] ;
case 110: a[i] |= b[i] ;
case 130: a[i] ^= b[i] ;
case 170: a[i] += b[i] ;
default: a[i] -= b[i] ;
}
}

687 ：デフォルトの名無しさん：2010/03/29(月) 21:30:17

>>685 アセンブラが逃げ道だとか本気で言ってるのか
そんなに狙ったロジックを実装するのが簡単だとでも思ってるのか

688 ：デフォルトの名無しさん：2010/03/29(月) 21:41:58

>>686
ちゃんと最適化をするJITなら相当速くなるだろうね。Tracing JITとLoop unrollingとか。

689 ：デフォルトの名無しさん：2010/03/29(月) 21:57:38

そりゃコンパイルなりコーディングなりしているときよりも、
JITの方が使える情報が多いから、理論的には中間コードをJITでコンパイルする方がアセンブラよりも速いコードになる。

690 ：デフォルトの名無しさん：2010/03/29(月) 22:09:18

>>686
極端にランタイム最適化が有利なコードは、サンプルとしてならいくらでも書けるはず。
ただ、実アプリで実行時間に影響するような事例としてどれだけ出てくるか、というのが
問題で、それが言語の需要に直結するし、実用性そのものにも繋がる。
少なくとも、最適化処理を回す負荷を上回るだけの利得があって、それが体感されるほど
の時間スケールになっていないといけない。最適化が効いてくるまでは単純に遅い。結局、
差し引きで利得があるアプリはかなりレアかと思われ。

691 ：デフォルトの名無しさん：2010/03/29(月) 22:12:13

去年は関数型言語が流行った気がするが
今年は中間コードか

692 ：デフォルトの名無しさん：2010/03/29(月) 22:12:58

コンパイルタイムの最適化でカバーできない部分がどの程度あるのかだな
Javaアプリとかぶっちゃけ「起動以外も」糞重いんだし、ほとんどランタイムの
最適化は効いてないんじゃね？
結局、コードモーフィングと同じ結論になるんじゃないかと思うんだが

693 ：デフォルトの名無しさん：2010/03/29(月) 22:14:44

心配しなくてもあと10年はJavaが第一線で使われ続けるよ

694 ：デフォルトの名無しさん：2010/03/29(月) 22:18:38

Javaの心配してる奴なんかいた？

695 ：デフォルトの名無しさん：2010/03/29(月) 22:20:29

一所懸命叩いてる奴ならいるな

696 ：デフォルトの名無しさん：2010/03/29(月) 22:29:01

VMがネイティブより遅いって話をするとJava叩きにされるのかｗ
まぁPARROTとかもいつ出てくるんだって感じだし、Rubyとかも微妙なままだしな

697 ：デフォルトの名無しさん：2010/03/29(月) 22:30:20

Javaは消えるなとは言わない、サーバサイドで頑張っていればいいと思う。
デスクトップ分野でだめなのはもう明らかだし、
あとはこれ以上携帯や組込分野に出しゃばってくれなければいいのだが。

698 ：デフォルトの名無しさん：2010/03/29(月) 22:30:24

Parrotと書かないとまずいか
PARROTじゃハイファのランタイム最適化みたいだし

699 ：デフォルトの名無しさん：2010/03/29(月) 22:30:44

Webサーバーで動いているものなら起動時間が長いといっても無視できる。

700 ：デフォルトの名無しさん：2010/03/29(月) 22:32:22

前にも勘違いしてる奴がいたけど、遅いと言ってるのは起動時間の話じゃないからよく読め

701 ：デフォルトの名無しさん：2010/03/29(月) 22:34:33

まぁ起動時間の遅さは一番目立ちやすいけどな
Javaアプリは起動した後も普通に重い

702 ：デフォルトの名無しさん：2010/03/29(月) 22:36:36

いつの時代の話だよ
糞PC乙

とツッコまれるぞ

703 ：デフォルトの名無しさん：2010/03/29(月) 22:38:44

モバイル系はしがらみの少ない分、純粋に性能で勝負できるからVM系が勝ち残るかも
しれないと思ったんだが、結局C++だのObjective-Cだのに完全に食われたな。

704 ：デフォルトの名無しさん：2010/03/29(月) 22:41:22

言語のパフォーマンスの話をしている時にPC性能の話にすり替える奴

と逆に突っ込まれるんじゃね

705 ：デフォルトの名無しさん：2010/03/29(月) 22:44:29

H.264のHD動画のデコーダをJavaで書かれてネットブックで再生してても気にならない
ような人ならあるいは

706 ：デフォルトの名無しさん：2010/03/29(月) 22:45:35

いずれにしても、CとJavaのどちらで開発しようかと迷うことはまずない。

707 ：デフォルトの名無しさん：2010/03/29(月) 22:50:34

>>703
RIMとGoogleとMicrosoft＋ガラケーがVM
NokiaとAppleがネイティブ

708 ：デフォルトの名無しさん：2010/03/29(月) 23:41:52

ま、なんだかんだCPUは速くなるし
今時java位いんじゃね
ネイティブコードキャッシュすれば起動もはやくなるのに

709 ：デフォルトの名無しさん：2010/03/30(火) 00:01:52

いつjavaはwindowsサービスで動くようになるの？

710 ：デフォルトの名無しさん：2010/03/30(火) 00:03:09

WindowsのシェアがLinuxと逆転したら

711 ：デフォルトの名無しさん：2010/03/30(火) 00:05:43

>>709
オープンソースになったんだから、お前がやればいい

712 ：デフォルトの名無しさん：2010/03/30(火) 00:32:24

>>711
なんで俺が？

713 ：デフォルトの名無しさん：2010/03/30(火) 00:47:27

Javaはウンコ過ぎる
少しはJavaScriptを見習え

714 ：デフォルトの名無しさん：2010/03/30(火) 02:26:58

JavaScriptのx86ネイティブコンパイラってないの？
gccでコンパイルできればいいのに。

715 ：デフォルトの名無しさん：2010/03/30(火) 03:24:18

phpとかperlとかのカスクリプト言語はjavascriptに統一されるべき

716 ：デフォルトの名無しさん：2010/03/30(火) 03:37:30

速度出す為に縛りが出てくることを理解できない奴は帰れよ

717 ：デフォルトの名無しさん：2010/03/30(火) 05:41:25

javascript？それはない

718 ：デフォルトの名無しさん：2010/03/30(火) 05:58:04

pyhonでいいんじゃね

719 ：デフォルトの名無しさん：2010/03/30(火) 08:43:21

ますますスレタイと離れて行くなw
goでいんじゃね

720 ：デフォルトの名無しさん：2010/03/30(火) 08:47:03

だからスレタイの話はとっくに終わってんだよ

721 ：デフォルトの名無しさん：2010/03/30(火) 10:53:39

C++は、まだまだ仕様を含ませてから、
もう後、30年ぐらいしてから一から新しく作り直せばいいよ

722 ：デフォルトの名無しさん：2010/03/30(火) 10:59:31

いやーソフトもハードも汚くてもいいから下位互換性がある言語の
方が寿命が長い傾向があるｗ

x86しかりC/C++しかりだ

このままC++はより一層文法を汚くしながらしぶとく生き残るだろうｗ

723 ：デフォルトの名無しさん：2010/03/30(火) 10:59:44

Cはあと30年はなくならない。C++は他の言語へシフトしていく。

724 ：デフォルトの名無しさん：2010/03/30(火) 14:10:09

やっぱシンプルイズペストなんだよな

725 ：デフォルトの名無しさん：2010/03/30(火) 14:14:23

いくらなんでもCは非力すぎ

726 ：デフォルトの名無しさん：2010/03/30(火) 14:17:47

>>725
スタートに戻る

727 ：デフォルトの名無しさん：2010/03/30(火) 17:29:59

Cが非力とかどんだけタコなんだよｗ

728 ：デフォルトの名無しさん：2010/03/30(火) 17:44:21

やはり職人によるパンチカードが一番ですね。

729 ：デフォルトの名無しさん：2010/03/30(火) 17:46:22

パンチカード世代ってどの辺り？

730 ：デフォルトの名無しさん：2010/03/30(火) 17:51:47

あん？紙テープだろ

731 ：デフォルトの名無しさん：2010/03/30(火) 17:52:23

カード枚数限られてる中、ミスるとどんどんカードが減っていくつらさ分からんだろ

732 ：デフォルトの名無しさん：2010/03/30(火) 20:24:14

バグで無限ループしてプリントアウトした紙が１０ｃｍ超えて涙目になった経験ある人

733 ：デフォルトの名無しさん：2010/03/30(火) 21:10:11

そのパンチカードは水玉パンツになりたかったのかよ。

734 ：デフォルトの名無しさん：2010/03/30(火) 22:04:48

あん？トグルスイッチでアドレスとデータラインセットしてストローブだろ

735 ：デフォルトの名無しさん：2010/03/30(火) 22:26:52

Cコンパイラがはくコードと同等のコードがはける
C#コンパイラをはやく出すんだ

736 ：デフォルトの名無しさん：2010/03/30(火) 22:30:16

お前が出せ。出すんだ！

737 ：デフォルトの名無しさん：2010/03/30(火) 22:40:42

Cはもっとスリムにしていくべき

738 ：デフォルトの名無しさん：2010/03/30(火) 22:43:29

Cのマクロをもっと強力に・・・

739 ：デフォルトの名無しさん：2010/03/30(火) 22:48:43

>>735 Cコンパイラと同等な結果がほしいなら
なんでCで書かないんだ
簡単な話じゃないか

740 ：デフォルトの名無しさん：2010/03/30(火) 22:51:57

GLSLやHLSLが「高級」って呼ばれてるのに、おまいらときたらｗ

741 ：デフォルトの名無しさん：2010/03/30(火) 22:54:12

めんどくさいからマネージドに向けて最適化したハード作れば良いよ

742 ：デフォルトの名無しさん：2010/03/30(火) 22:59:33

>>738
HTMLをもっと強力にしたPHPのようなものか

743 ：デフォルトの名無しさん：2010/03/30(火) 23:00:49

「俺は理解できないから、おまえが来ればいい」
って話か。めんどくさいなんて嘘

744 ：デフォルトの名無しさん：2010/03/30(火) 23:06:43

>>742
昔metahtmlつのがあったな
lispのカッコを<>にしたようなヤツ
実行可能なhtml

745 ：デフォルトの名無しさん：2010/03/30(火) 23:10:25

pythonの中にschemeっぽい（）を見かけたんだが、あれは何なんだ

746 ：デフォルトの名無しさん：2010/03/30(火) 23:38:58

PHPはメタプログラミングの幻想をぶち壊す

747 ：デフォルトの名無しさん：2010/03/31(水) 00:43:58

そもそもメタプログラミングが幻想なのかも知れない

748 ：デフォルトの名無しさん：2010/03/31(水) 00:55:36

>>747
コンパイル時間がめちゃめちゃ延びるけど、手書きよりはるかに楽で正確

749 ：デフォルトの名無しさん：2010/03/31(水) 00:58:00

メタプログラミングってメタボプログラミングの略ですか？

750 ：デフォルトの名無しさん：2010/03/31(水) 01:12:55

ははっワロス

751 ：デフォルトの名無しさん：2010/03/31(水) 01:13:40

Ultimate フレームワークとか超○○ツクールとかの劣化版。
メカプログラミングのなまりｗ

752 ：デフォルトの名無しさん：2010/03/31(水) 01:18:20

一理ある

753 ：デフォルトの名無しさん：2010/03/31(水) 01:19:04

クラスの自称人気者が集まるスレはここですか

754 ：デフォルトの名無しさん：2010/03/31(水) 01:24:35

コンパイラより速く
同じasmコードが吐けるようになったらいいべ

755 ：デフォルトの名無しさん：2010/03/31(水) 03:44:47

EclipseってJavaでできてるけど、結構快適だよな。
数少ない成功事例なのか。

756 ：デフォルトの名無しさん：2010/03/31(水) 03:47:20

>>723
C++のシフト先って今ないだろ。

757 ：デフォルトの名無しさん：2010/03/31(水) 04:03:26

>>755
ハァ？
超絶糞重いわプラグインはバグだらけだわの糞環境じゃねぇか
あんな糞を有難がるのは経済活動できてないクソニートだけだっつの
あれじゃ投資した時間の回収すらできねぇよ

758 ：デフォルトの名無しさん：2010/03/31(水) 04:21:32

>>757
誰が有難いなんて話をしたよ

Cコンパイラだってトランスレータなんだから、Cの拡張としての言語内言語を定義した方が効率的だと思う

759 ：デフォルトの名無しさん：2010/03/31(水) 05:57:57

この手のC言語関連のしょっぱい議論を見てると、マシンコードでコンピュータが走る
単純な流れを知ってるか否かだけで次元の壁があるよな、とつくづく実感させられる

760 ：デフォルトの名無しさん：2010/03/31(水) 07:58:54

>>759
日本語がヤバイ

761 ：デフォルトの名無しさん：2010/03/31(水) 10:14:28

この手のの内容をくわしく書けばいいんじゃないかな

762 ：デフォルトの名無しさん：2010/03/31(水) 10:21:03

Objective-Cは、OSも書けるCよりも便利な言語として設計されている。
その方向で成功しているとは言い難いが。

763 ：デフォルトの名無しさん：2010/03/31(水) 10:26:30

C++でできることがすべてできた上で何ができればいいのだ？

764 ：デフォルトの名無しさん：2010/03/31(水) 10:48:50

「できるけどしてほしくないこと」をわかりやすく表現できればいい
なにもしないprivateメソッドとかがわかりにくい

765 ：デフォルトの名無しさん：2010/03/31(水) 12:03:43

今やマシン語ですら高級言語じゃないの

766 ：デフォルトの名無しさん：2010/03/31(水) 12:12:35

じゃあ何が低級言語なんだ
VHDLか？

767 ：デフォルトの名無しさん：2010/03/31(水) 12:26:10

機械語でかけざん、割り算まで出来ちゃう現代のCPU

768 ：デフォルトの名無しさん：2010/03/31(水) 13:55:21

C++は互換性を強く意識してでかくなりすぎた
C++にやらせたくない事をコーディング規約としてまとめた物を作ったとしたら、
価値はないだろうか？

769 ：58：2010/03/31(水) 14:36:01

記述力が高くてわかりやすい数式の記法ってのがあれば
数学はカンタンになるのか？

770 ：デフォルトの名無しさん：2010/03/31(水) 14:46:07

>>769
微分積分の記号がない状態で微分積分の問題を取り扱うのが難しかったように、記述力が高い記号は数学を簡単にする助けになる

771 ：デフォルトの名無しさん：2010/03/31(水) 14:50:58

微積の記号（インテグラル記号とか）はニュートンがほぼ今の原型を作ってるから最初からあるってことだぞ

772 ：デフォルトの名無しさん：2010/03/31(水) 14:52:58

ニュートンじゃなくライプニッツな

773 ：デフォルトの名無しさん：2010/03/31(水) 14:54:48

イギリスは独自の微分積分の記号を使ってたから
大陸より発達が遅れたんだよな

774 ：デフォルトの名無しさん：2010/03/31(水) 14:56:31

ニュートンもライプニッツもイギリス人なんだが、そうなの？

775 ：デフォルトの名無しさん：2010/03/31(水) 14:58:37

ライプニッツはドイツ人かと思われ

776 ：デフォルトの名無しさん：2010/03/31(水) 15:03:10

はっきりとは言わなくても、実は数学に疎い人たちが多いって事だけはわかった
あと、>>769 は数学アレルギーで覚える気も無いって事もわかった

同じように、きっとJavaやC#のような単純なルールの言語なら覚えられるけど、
C/C++のようなあれもこれも可能な言語は覚えられない連中が多く、
そしてそれを認めるのが恥ずかしいって思ってる人たちが多いのもわかった。

以下、ひまわりスレ

777 ：デフォルトの名無しさん：2010/03/31(水) 15:03:20

プライムのことをダッシュって読む人いるよね

778 ：デフォルトの名無しさん：2010/03/31(水) 15:03:53

微分積分の概念は、関孝和も同水準に達していたけど、記号がないので発展しなかった面がある

779 ：デフォルトの名無しさん：2010/03/31(水) 15:10:00

プライムよりダッシュだべ
英論文でプライムを初めて見たとき何のことだかしばらくわからんかった

780 ：デフォルトの名無しさん：2010/03/31(水) 15:12:25

数学の教授が、日本人があんまりダッシュダッシュと言うからダッシュが普及し始めた
とか冗談言ってたな

781 ：デフォルトの名無しさん：2010/03/31(水) 15:21:56

CC'=Σ(the prime denoting transpose)
主要な転置表記

782 ：デフォルトの名無しさん：2010/03/31(水) 15:47:10

K'(ξ)=w, where prime denotes differentiation with respect to ξ.
素数はξの違いを表す

783 ：デフォルトの名無しさん：2010/03/31(水) 15:58:05

>>776
覚えられないから簡単にしろって云う人への批判として
769 を書いたつもりなんだけど、難し過ぎましたか。

784 ：デフォルトの名無しさん：2010/03/31(水) 16:21:26

cにあれ付けてこれ外してってよりも、javaにポインタつけて後どうしようか？
の方がスムーズに話が進む気がするんだけど。

785 ：デフォルトの名無しさん：2010/03/31(水) 16:25:28

>>783
「こういうつもりで書いたんだ」で済まさず一言余分に付け加えるあたり、
プライドの高さが垣間見えるようです。

786 ：デフォルトの名無しさん：2010/03/31(水) 16:44:41

>>784
C#

787 ：デフォルトの名無しさん：2010/03/31(水) 16:46:27

>>777
俺ミノムシって呼んでる
'←みのむし
"←ダブルみのむし
`←反対のみのむし

788 ：デフォルトの名無しさん：2010/03/31(水) 16:59:42

>>787
俺もそうよんでるｗ
流行ってんの？

789 ：デフォルトの名無しさん：2010/03/31(水) 17:02:44

俺の会社でもみんなみのむしって呼んでいるぞ

790 ：デフォルトの名無しさん：2010/03/31(水) 17:03:34

>>787
当たり前じゃん。
ミノムシは世界共通だぜ。

791 ：デフォルトの名無しさん：2010/03/31(水) 17:07:01

>>787-790
おい、誰だ　ミノムシ流行らせようとしてるやつｗ
俺も明日から使おうかな。

792 ：デフォルトの名無しさん：2010/03/31(水) 17:22:32

スレから適当にピックアップしたけど途中で面倒になった。
適当に足しとして。

C/C++に無いけど欲しい機能
○欲しい
・アトミック処理
・リアルタイム性
・Lispなみに弄くれる型安全なマクロ
・Forthなみに弄くれる駆動レコード
　- 駆動レコードへのアクセス
　- 実行制御
　- 強制インライン展開(レコードを新しく作らないルーチン)
・マトモなクロージャ
・マルチスレッド対応／自動並列化／トランザクション
・割り込み処理

○微妙
・GC
・多重継承の代わりにmix-in
・コルーチン
・契約プログラミング

793 ：デフォルトの名無しさん：2010/03/31(水) 17:41:50

C/C++に有るけど要らない機能はなんだよ

794 ：デフォルトの名無しさん：2010/03/31(水) 17:55:18

>>792
スレ違いな事してんじゃねぇ
ここはミノムシを語るスレだ

795 ：デフォルトの名無しさん：2010/03/31(水) 18:01:20

Cのマクロは今の視点ではいらないな。

796 ：デフォルトの名無しさん：2010/03/31(水) 18:25:11

inlineがLispのマクロに相当するんじゃないの

797 ：デフォルトの名無しさん：2010/03/31(水) 18:31:01

>>794
ある意味ネタスレだしな。これ以上の議論は期待できないね。

まあ、もっとも必要なら別スレとして
新言語Polka-dot(仮称)とか、C言語クローン総合スレ等の
新規スレとWiki立てるけど？

798 ：デフォルトの名無しさん：2010/03/31(水) 18:35:09

具体的な低級言語に求める機能のアイデアは誰も語らないの？

799 ：デフォルトの名無しさん：2010/03/31(水) 18:42:11

プログラミング初心者なんですが、GCが邪魔になるコードの例を教えてもらえませんか？
ゲームとか通信とか言われてもピンと来ないです。

800 ：デフォルトの名無しさん：2010/03/31(水) 20:25:17

Lispのマクロは2回評価するのだ

801 ：792：2010/03/31(水) 20:44:42

>798
俺が語ってるだろ。
他にc/c++では実装できない／言語の助けの無い機能があったら挙げてくれ。

802 ：デフォルトの名無しさん：2010/03/31(水) 20:48:07

C/C++の拡張が前提なわけ？

803 ：デフォルトの名無しさん：2010/03/31(水) 20:49:03

0と1だけでプログラムをかける低級言語、01を作ろう

804 ：デフォルトの名無しさん：2010/03/31(水) 21:20:48

>>799 GCが邪魔になるってのは、その処理そのものが害になると言うより、
しなくてもいいところでも走る（＝ＧＣ管理の為の処理や、開放など）から、
あえて言うなら邪魔だという話。　てか邪魔って言うより、常にそれありきじゃなくてOn/Offしたいって感じ

805 ：デフォルトの名無しさん：2010/03/31(水) 22:21:55

>>803
whitespace使っとけよ

806 ：デフォルトの名無しさん：2010/03/31(水) 22:23:54

ヘッダがいらない

807 ：デフォルトの名無しさん：2010/03/31(水) 22:28:06

じゃあヘッダ自動生成のCのIDE作る

808 ：デフォルトの名無しさん：2010/03/31(水) 22:54:21

>>804
> しなくてもいいところでも走る
はい、その点は理解しているのですが、
GCが走ると処理がわずかに中断されて、それが気になるほどの悪影響を与えるケースを
実証できるコードはどんなものか興味がありまして・・・

809 ：デフォルトの名無しさん：2010/03/31(水) 22:58:49

>>808 だから悪影響を与える実証コードが云々じゃなくて、
無くてもいいものなら無い方がいいって話。

例えば関数一つ呼んで、何かの戻り値を得るとかの処理があった時、中に作られる自動変数やら何やら、
あるいはクラスをnewして得たなにやらを、自分で管理出来た方が都合がいいだろ？って話だよ

810 ：デフォルトの名無しさん：2010/03/31(水) 23:04:31

>>808
FPSゲームなんかで交戦中には余計なことして画面がガクンとなるのはやめて欲しいから、
どうにもならない場面でだけGCするように作って、後は戦闘中以外の処理もたついてもいい場面でGCしたい。
なんてのは普通にあるんでないの？

811 ：デフォルトの名無しさん：2010/03/31(水) 23:10:40

>>810
でもゲームでは入力や通信やらで非同期に余計な処理が結構いろいろあるので
GCが起きるぐらい些細な事なのではないか、と素人ながら思ったのですが・・・

812 ：デフォルトの名無しさん：2010/03/31(水) 23:18:21

>>811
入力は全然問題ない。
動作を脅かすとんでもない入力なんてない。

通信はしらない。
フルタイムで通信してるようなゲームはその些細なことをそれなりに気にして作ってるんじゃないの。
だいたい通信量ってそんなめちゃくちゃな量はないと思う。

813 ：デフォルトの名無しさん：2010/03/31(水) 23:18:32

そりゃ素人以下だな

814 ：デフォルトの名無しさん：2010/03/31(水) 23:26:16

>>812
確かに通信料は少なそうですね。
実際グリグリ動くFPSでも100kbps程度だったりして驚きます。

う～ん、では質問を変えますが、ゲーム中にGCが起こったとして何ミリ秒ぐらいゲームがストップしますか？

>>813
決して皆さんを侮辱しているわけではありませんので、怒らないで聞いてください。
単なる素人の疑問ですから。

815 ：デフォルトの名無しさん：2010/03/31(水) 23:35:22

>>814
何が言いたいのかわからんが、認識できるレベルで止まる重くなるプログラムしか作れない言語なら問題があると言えないか？
作る側は良くてもやる方は甘くいこと言ってくれないぞ。

816 ：デフォルトの名無しさん：2010/03/31(水) 23:37:13

100kbpsもあるのかFPSは
結構あんのな

817 ：デフォルトの名無しさん：2010/03/31(水) 23:40:05

>>815
確かに問題ありますよね。
しかし、本当に言語に問題があるのかどうか皆さんの話を聞いているだけではピンと来ないので
そのケースを再現したプログラムなどがあれば理解もしやすいのですが・・・
リンクだけでも結構です

818 ：デフォルトの名無しさん：2010/03/31(水) 23:43:41

>>814
そんなのはプラットフォーム次第。
たとえばヒープの少ない古い携帯電話なんかで、断片化の起きやすいコードを書いてれば秒レベルで止まる。

819 ：デフォルトの名無しさん：2010/03/31(水) 23:50:01

たとえばだな

ルータを考えてみなよ
こっちの都合考えずに
パケットがガンガンくるでしょ
gcで0.1秒とか中断したら
パケット落ちちゃうかもでしょ？

動画のカメラのキャプチャが
1/30秒で画像送ってきたとする
途中でgcが走ったら画像おちるでしょ？

計測機が一定周期でモニタしてるとして
周期が乱れたらまずいでしょ？

gc避けたいのはそういう相手に合わせないといけない用途
人が使うものは時間短いなら普通大丈夫だが
ゲームや動画、音声なんかはシビアだね

820 ：デフォルトの名無しさん：2010/03/31(水) 23:51:28

>>817
最初から信じる気ないだろ？
自分で大量のオブジェクトnewしまくるコードでも書いてみたら？
困らないなら話題にもならないよ。

821 ：デフォルトの名無しさん：2010/03/31(水) 23:53:54

ゴミ回収のタイミングって、アルゴリズムがわかってればだいたい分かるんじゃないかな。
それにプログラミング側のテクニックでゴミが出にくいプログラミングも可能だと思うけど。

822 ：デフォルトの名無しさん：2010/03/31(水) 23:54:13

gcは書き方や処理でだいぶ頻度が変わるが
不可抗力やエラーでもないのに
データが落ちたり抜けたりは
設計上許されないわな

823 ：デフォルトの名無しさん：2010/03/31(水) 23:54:59

>>820
まさにそういうプログラミングするから大幅にGCに負荷がかかるんだよなぁ。

824 ：デフォルトの名無しさん：2010/03/31(水) 23:55:13

GCといっても言語ごとに違うだろ。
ちなみにluaだとGCの動作で2倍くらい速度変わる。
実例として、EU3(市販ゲーム)でGCの調整パッチで
動作速度1.5倍くらい変わった。

825 ：デフォルトの名無しさん：2010/03/31(水) 23:56:07

GCしたいときにGC関数実行すれば回収してくれるような仕様だったらどう？

826 ：デフォルトの名無しさん：2010/03/31(水) 23:58:16

>>821
ま、普通シビアな分野では
メモリなんて動的に取らんがねw
最初に確保したら後は増え減りもしないw

827 ：デフォルトの名無しさん：2010/03/31(水) 23:58:36

それはそれでGCが必要なときにGCされない危険が伴う。

828 ：デフォルトの名無しさん：2010/03/31(水) 23:59:15

>>820
私が信じていないのは、>>821さんの仰るように、
プログラマーがGCの挙動を理解していないがために
GCへの負荷がかかりすぎてしまうプログラムを書いてしまって
いるのではないかということなんです。

829 ：デフォルトの名無しさん：2010/04/01(木) 00:00:19

>>825
dojaがそうだけど、命令してもメモリがあまり使われてなかったらやらないとかいうし。

830 ：デフォルトの名無しさん：2010/04/01(木) 00:01:02

>>826
そうそう。
絶対回収されないようにずっと保持して、そこを使いまわすのが普通のスタイル。
newしまくるのは下の下のプログラマのやることじゃないの。

831 ：デフォルトの名無しさん：2010/04/01(木) 00:01:51

そもそもGCってのは自分でメモリのマネージできないようなアフォグラマの為のものだからね。
負荷の多いコーディングしてしまうのも仕方がないのさ。

832 ：デフォルトの名無しさん：2010/04/01(木) 00:04:10

820だけど、バカにされてるみたいで嫌だからいうけど俺はそんなコードは書かないぞ。
例で言っただけなんだからっ

833 ：素人：2010/04/01(木) 00:08:04

>>830
ではそういうプログラミングスタイルならば
GCありの言語でもリアルタイムな用途でつかえるということでしょうか？

834 ：デフォルトの名無しさん：2010/04/01(木) 00:09:48

>>833
JavaみたいにGCありの言語で組み込みプログラミングする例だってあるんだから、
やってる人はいるんだよ。

835 ：デフォルトの名無しさん：2010/04/01(木) 00:11:07

>>828
つまり、自分で結論出てるじゃないか
GCと言う便利な物があるからと言って、それにすべてを任せたら
まともに動作しない環境がある。昨今のデスクトップPCみたいに
恵まれている環境ばかりじゃないからね。

836 ：デフォルトの名無しさん：2010/04/01(木) 00:15:45

自分の結論に同意して欲しいだけなら知恵袋にでも書いておけよ。

837 ：デフォルトの名無しさん：2010/04/01(木) 00:20:34

PerlとかHaskellのゲームなら聞いたことがあるが
楽をするためではなくて、むしろ逆のような気がする

838 ：素人：2010/04/01(木) 00:21:06

>>836
いろいろお騒がせしてすみませんでした。

839 ：デフォルトの名無しさん：2010/04/01(木) 00:22:37

>>837
monadius有名だな

840 ：デフォルトの名無しさん：2010/04/01(木) 00:25:21

そういやmonadiusで暫くプレイしてるとどんどん遅くなるって作者が言ってたな。
あれもgcのせいなのかね。

841 ：デフォルトの名無しさん：2010/04/01(木) 00:26:57

>>840
原因が分からない（分かりにくい）のはデメリットだよな。

842 ：デフォルトの名無しさん：2010/04/01(木) 00:29:00

少なくともCなら原因がどこにあるのかコードを見れば分かるんだけど、
Haskellみたいな遅延評価の言語はGCの挙動がわからん。

843 ：デフォルトの名無しさん：2010/04/01(木) 00:32:48

>>834
組み込みにはリアルタイムのものと非リアルタイムのものがある。
リアルタイムのシステムには処理時間の最悪値が保障できないGCは使えない。
スレタイは超高速と謳ってる以上リアルタイムが最低条件だろ。

844 ：デフォルトの名無しさん：2010/04/01(木) 00:41:09

リアルタイム性が要求される環境でGCあり言語が使えるかどうかって話しだけど
選択可能だとしても、好んで選択する人はあまり居ないと思う。

それだけシビアな環境だとまずはスループットが要求されるわけで、Cやasmが
選択できるなら、そっちを選ぶんじゃないかな。つまりGC単体で処理系を判断
する事はまず無くて、現状のGC搭載言語より、総合してC、asmの方が向いていると
判断する事の方が多いと思うわけだ。

ちなみに「シビアな環境」とはどういう環境かと言うと、
* ヒープは何バイトまで利用します
* スタックは何バイトまで利用します
* どんな事があってもこの処理は何ナノセカンドで戻ります
と言う事を、仕様として明確にして、責任を持たなければならない環境の事なんで
GCが入り込む余地はほとんど無いかも知れない。

845 ：デフォルトの名無しさん：2010/04/01(木) 00:45:09

組み込み用処理系のGCならヒープどれだけ使うかは設定できるんじゃない？
Cとかアセンブラとかでやるときはプロファイラとにらめっこしながら試行錯誤するけど・・・
どっちも大して変わらんか。

846 ：素人：2010/04/01(木) 00:49:26

組み込みなどのシビアな環境に詳しい方にお聞きしますが、
C言語でプログラミングしていて、
こういう機能があったらこういうシーンでもっと楽ができるのに！
と思う事があったら教えてください。

847 ：デフォルトの名無しさん：2010/04/01(木) 00:53:52

脳に直接繋いで頭で考えるだけで実装されるデバイスがあれば良いのに

848 ：デフォルトの名無しさん：2010/04/01(木) 00:54:52

>>846
ヒープを使わない短い文字列クラス、とか。
でもC++があれば、こういう必要な機能は必要に応じて何でも作れるしな。

849 ：デフォルトの名無しさん：2010/04/01(木) 01:02:38

>>844で箇条書きした3つの要件を満たしているかどうかが
コンパイル時に分かれば、ムチャクチャうれしいね

850 ：デフォルトの名無しさん：2010/04/01(木) 01:04:06

必要な機能のキーワードで検索すると即使えるフリーなライブラリが自動で組み込まれる
IDE直結型の検索エンジンが欲しいな。

851 ：デフォルトの名無しさん：2010/04/01(木) 01:05:38

>>849
そこで形式的仕様記述言語での設計ですよ。

852 ：デフォルトの名無しさん：2010/04/01(木) 01:06:24

ここは本当に物事を進める能力絶無な底辺キーパンチャしかいねぇな
事を起こすならまず最初にやるべき事をやれ
名前を付けろ

853 ：デフォルトの名無しさん：2010/04/01(木) 01:07:39

じゃあ言語の名前つけます
「kuma-」
これでいいですか

854 ：デフォルトの名無しさん：2010/04/01(木) 01:08:04

現役時代はハードパンチャーって云われたよ

855 ：デフォルトの名無しさん：2010/04/01(木) 01:10:10

>>853
はい

856 ：デフォルトの名無しさん：2010/04/01(木) 01:11:04

はいじゃないが

857 ：デフォルトの名無しさん：2010/04/01(木) 01:11:23

>>853
はい

858 ：デフォルトの名無しさん：2010/04/01(木) 01:12:12

はいじゃないが

859 ：デフォルトの名無しさん：2010/04/01(木) 01:13:29

おし、じゃあまずはkuma-の言語仕様をBNFで書いてみることからはじめよう

860 ：デフォルトの名無しさん：2010/04/01(木) 01:14:10

↓どうぞ

861 ：デフォルトの名無しさん：2010/04/01(木) 01:14:24

クマって呼ばれてたものがあった気がするがなんだっけ

862 ：デフォルトの名無しさん：2010/04/01(木) 01:14:29

名付けに失敗したプロジェクトは99%失敗するから
初期段階に名前で存分に悩むのは経済的に正しい

863 ：デフォルトの名無しさん：2010/04/01(木) 01:15:27

ああ、AMDのCPUか。Kuma

864 ：デフォルトの名無しさん：2010/04/01(木) 01:15:31

名無し言語
↓
0x7C言語
↓
|言語

865 ：デフォルトの名無しさん：2010/04/01(木) 01:18:27

>853
どうせなら kummer- だろ。

名前以前にコンセプトをどうにかしようぜ。

866 ：デフォルトの名無しさん：2010/04/01(木) 01:18:43

>>864
ぐぐれねーよｗ

867 ：デフォルトの名無しさん：2010/04/01(木) 01:20:47

>>866
名無しなのに簡単に特定されたら困るだろ？

868 ：デフォルトの名無しさん：2010/04/01(木) 01:21:59

俺的にpythonみたく{}を除去したい＾＾

869 ：デフォルトの名無しさん：2010/04/01(木) 01:22:21

出た当初はC#もググれなかったんだが、今じゃ普通に出るな

870 ：デフォルトの名無しさん：2010/04/01(木) 01:23:29

C# とか、.NETとか、MSは意図してググれなくしたように思えて仕方がない

871 ：デフォルトの名無しさん：2010/04/01(木) 01:24:26

お前らが金出してGoogle アドワーズに表示するようにすればおｋ

872 ：デフォルトの名無しさん：2010/04/01(木) 01:27:38

じゃあ|で検索結果出るようになったら俺らの勝ちだな

873 ：デフォルトの名無しさん：2010/04/01(木) 01:33:29

{}がある方がブロックが明確でいいが強要はいやだな

組み込みやリアルタイムでもそこまでメモリシビアじゃないのも多いよ
特に32bit RISCの奴。
でも時間に関しては結構シビアだったりするな。

ただそういうのでも全てが時間制限あるわけじゃないし
単純にスループットならGCありでも稼げるしね。
GCが記述で決めれるなら静的に解析も出来るし
高プライオリティなのはNon GC, どうでもいい処理はGCありとか出来る

874 ：デフォルトの名無しさん：2010/04/01(木) 01:44:03

じゃあ、手動でメモリ解放する手段も提供されていて、
かつGCしたいときにGC命令を実行すればGCしてくれるようにするのはどうだろう。

875 ：デフォルトの名無しさん：2010/04/01(木) 01:48:35

問題ってのは言語が勝手に動的なメモリを解放・確保することなんよな
でもそれがメリットでもある
GC除外の宣言を変数にできたらどうだろ

876 ：デフォルトの名無しさん：2010/04/01(木) 01:49:34

>>873
> {}がある方がブロックが明確でいいが強要はいやだな
python使うまではインデントブロックが強要されるのは気持ち悪いと思っていたけど、
実際に使ってみると案外メリットばかり感じるようになるんだよね。
{}のブロックだとどこからどこまでがブロックなのか、非常に視認性が悪い。
もちろんemacsなどのエディタでは自動でインデントしてくれるが、し忘れることもあって、
例えば多重ifなどで範囲を間違って読んでしまうこともある。

877 ：876：2010/04/01(木) 01:52:01

ほんとに、こういう使い勝手の問題は実際に使ってみないと分からないんだけどね。。
プログラミング言語は道具なだけに。

878 ：デフォルトの名無しさん：2010/04/01(木) 01:58:37

>>875
確保はしないんじゃね

879 ：デフォルトの名無しさん：2010/04/01(木) 02:00:35

>>876
視認性に関してはエディタに強く依存すると思う。
インデント強制は保守の面から悪くないとは思うけど。

ところで関数は
public static int hoge(int aaa,String bbb = null){}
なの？
public static function(aaa:int, bbb:String = null):int{}
の方がなんとなく好きなんだけど。

880 ：デフォルトの名無しさん：2010/04/01(木) 02:12:29

>>878
言語によるよ

881 ：デフォルトの名無しさん：2010/04/01(木) 02:14:43

ML流の引数を()で閉じないタイプが好きなんだけど、マシン語に落とす時に問題ある？

882 ：デフォルトの名無しさん：2010/04/01(木) 02:37:26

1. 速度、移植性はC
2. その他(構文、ライブラリ)はPython

がベスト

883 ：デフォルトの名無しさん：2010/04/01(木) 02:52:55

>>882
＞1. 速度、移植性はC
＞2. その他(構文、ライブラリ)はPython

2はインデントブロックに関しては賛成
ライブラリはjava流が簡単な気がする。

884 ：デフォルトの名無しさん：2010/04/01(木) 06:29:30

>>882
Cがよくわからないからpython風に書きたいです、って言ってるだけじゃん

885 ：デフォルトの名無しさん：2010/04/01(木) 06:30:49

Cがよくわからないからpython風に書きたいです

886 ：デフォルトの名無しさん：2010/04/01(木) 06:45:59

習得しやすさはどうでもいい
強力で高速で普及してればいいから、C++で全く困らない

887 ：デフォルトの名無しさん：2010/04/01(木) 08:35:25

>>883
それ目指してんのがgolangだな

888 ：デフォルトの名無しさん：2010/04/01(木) 08:36:09

つーか一定以上難しくないと職を失うだろ

889 ：デフォルトの名無しさん：2010/04/01(木) 08:36:52

golangには先手を取られたが、必ず追いついて見せる（ｷﾘｯ

890 ：デフォルトの名無しさん：2010/04/01(木) 09:32:44

Pythonって書き方おかしいから嫌い

891 ：デフォルトの名無しさん：2010/04/01(木) 12:02:42

>>888
書き方なんて簡単な方がいいよ
問題は何をどう書くかだから
それで職失うってのはそもそも不毛な仕事で不要な人間だわｗ

892 ：デフォルトの名無しさん：2010/04/01(木) 12:08:38

いかにも難しくて一見して意味がわからない言語じゃないと
経営者が「俺でも分かる」と思い込んじゃって給料減らされるから。

893 ：デフォルトの名無しさん：2010/04/01(木) 12:14:00

英語が分からないから、COBOLが分からないやつ

894 ：デフォルトの名無しさん：2010/04/01(木) 12:14:12

そんな無能な経営者も不要だなｗ

895 ：デフォルトの名無しさん：2010/04/01(木) 12:32:03

簡単ってなんなの
C/C++が普及しているのはC/C++が簡単だから？

896 ：デフォルトの名無しさん：2010/04/01(木) 12:34:34

>>895
LinuxやWindowsがC言語で作られているので、システムコールがC言語の関数ベースだから。

897 ：デフォルトの名無しさん：2010/04/01(木) 12:42:16

>>895
歴史。実用的で無駄の少ないコードがこのコンパイラ言語のおかげでずいぶん楽になったね、
って言う歴史

898 ：デフォルトの名無しさん：2010/04/01(木) 14:23:42

>>875
CycloneはGCではなくregion based memory managementだな。
つか今のメモリー管理システムのトレンドってなんだろうな。
年表あればいいんだが。

>>892
無能な経営者は淘汰されるから心配しなくてもいい。
むしろバグ・ケアレスミス・保守や記述の冗長性が減れば
開発者の健康面で良いし、安全性や生産性があがるんで、
そっちのほうが重要だな。

それでプログラマの自殺減ったり開発がしやすくなればいいと思う。

899 ：デフォルトの名無しさん：2010/04/01(木) 14:39:08

C言語の国産セキュア実装といえばFail-Safe CやVITCなんかもある。

ttp://web.yl.is.s.u-tokyo.ac.jp/
ttp://www.rcis.aist.go.jp/project/FailSafeC-ja.html

900 ：デフォルトの名無しさん：2010/04/01(木) 14:42:19

>>875
その手の手法は既に C++/CLR で出来るな
新しいものなんて何も必要なかったんだ

901 ：デフォルトの名無しさん：2010/04/01(木) 14:52:09

それならポインタがあるC#だってできるぞ。

902 ：デフォルトの名無しさん：2010/04/01(木) 16:01:44

>>898
馬鹿め
無能な経営者は毎年途切れる事無く補充されるってことを知らんのか

903 ：デフォルトの名無しさん：2010/04/01(木) 16:15:25

>>902
大丈夫、この不況でだいぶ消毒されたから。

904 ：デフォルトの名無しさん：2010/04/01(木) 16:19:01

C++/CLIはもはやJavaのパクリではない点が新しい

905 ：デフォルトの名無しさん：2010/04/01(木) 16:29:05

まあ無能なエンジニアはもっと生産されてるがなｗ

>>900
MSの作ったモノは。。。(ry
といいたいが、仕様見てみた。こんなもんかね。

906 ：デフォルトの名無しさん：2010/04/01(木) 16:36:41

>>905
この不況で無能なエンジニアは就職できないんですよ。
だから少なくとも今年の新卒エンジニアは無能じゃない。

907 ：デフォルトの名無しさん：2010/04/01(木) 16:41:43

就職できたら有能ってのはチト早合点

908 ：デフォルトの名無しさん：2010/04/01(木) 17:11:27

なんかもう…
パフォーマンス必要な所だけCかasmで書いて、
あとはなんでもいいやー、な気分になってきてしまいました。
結局、今と変わらん。

909 ：デフォルトの名無しさん：2010/04/01(木) 17:12:40

>>908
そのパフォーマンス必要な所を書く言語を作ろうと言っているわけで。

910 ：デフォルトの名無しさん：2010/04/01(木) 17:27:23

なかなか伸びが速いが次スレか？
それともネタスレなので終了か？
次スレなら今の段階でスレ内容をまとめて>>2とかに貼るアレが必要だな。

911 ：デフォルトの名無しさん：2010/04/01(木) 17:29:46

Cが最高って結論で終了で良いけど

912 ：デフォルトの名無しさん：2010/04/01(木) 17:35:00

>>910
決まったこと：
言語名「kuma-」

913 ：デフォルトの名無しさん：2010/04/01(木) 17:35:18

高機能な言語の便利な機能が、どのようなしくみで実現されているかを知れば、Cにそれらの機能がないのはなぜかが分かると思うのだが。

914 ：デフォルトの名無しさん：2010/04/01(木) 17:40:20

リストもGCもないcamlとかどう？

915 ：デフォルトの名無しさん：2010/04/01(木) 17:51:25

パフォーマンスが必要な部分なんて本当に小規模になるはずだし
ならCでよくね？

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　完

916 ：デフォルトの名無しさん：2010/04/01(木) 17:56:32

OSのことを忘れているだろ。

917 ：デフォルトの名無しさん：2010/04/01(木) 18:27:58

>>912
次スレ作るならfc2 Wiki借りてくるが？ただし末尾のハイフン使えないサービスだから
そのままURLにするのは無理。次のうち一つ選んでくれ。

kuma-minus, kumamin, kumamens, kumaminkind, mrbear, mrkuma

918 ：デフォルトの名無しさん：2010/04/01(木) 18:48:57

言語名は、|言語だろ？

919 ：デフォルトの名無しさん：2010/04/01(木) 18:55:47

C with Classesでいいよ

920 ：デフォルトの名無しさん：2010/04/01(木) 19:01:14

オブジェクト指向機能はつけた方がいいのか？
stackless Cとかどう？

921 ：デフォルトの名無しさん：2010/04/01(木) 19:04:25

Cにクラスはいらない

922 ：デフォルトの名無しさん：2010/04/01(木) 21:52:04

全然参加する気はないが、検索しやすい名前にしてくれ。

923 ：デフォルトの名無しさん：2010/04/01(木) 21:59:14

>>919
欲しい機能を追加していくとC++になっちゃうな。

924 ：デフォルトの名無しさん：2010/04/01(木) 22:07:19

オブジェクト指向の代わりにCSP機能つけたらどうだろう。
golangみたいに並列で動くとリアルタイム性が失われるので、
手動でタスクを切り替えられるようなコマンドを用意するとか。

925 ：デフォルトの名無しさん：2010/04/02(金) 02:05:42

>>924
プリエンプティブなマルチスレッドにすればリアルタイム性は確保できる
プリミティブでPriority Inversion Safeなmutexと
シンプルなセマフォとメッセージがあればOKじゃね
手動での実行権放棄もありで。
。。。。言語にRTOS機能組み込みだなｗ

926 ：デフォルトの名無しさん：2010/04/02(金) 02:06:16

まずは、すぐに、確実に出来る事からやってみないか。

現状カーネルやドライバ等を記述できる言語で実用的なのは、asm, C, C++って所だけど、
この中で一番機能豊富なのはC++である事は言うまでもない。にも関わらずC++が使いにくい
という印象があるのは、言語仕様が大きく、その割りに標準ライブラリが貧弱だから。

で…、

1. C++で使わない事にする機能をリストアップする
2. 標準ライブラリとして利用すべきライブラリをリストアップする

つまりコーディング規約を作ってみると言う話しだ。

927 ：デフォルトの名無しさん：2010/04/02(金) 02:06:54

まずはclassがいらねえな

928 ：デフォルトの名無しさん：2010/04/02(金) 02:14:09

それはstructで十分だから？

929 ：デフォルトの名無しさん：2010/04/02(金) 02:19:00

CSPさえできればオブジェクト指向も理論的に実装可能

930 ：デフォルトの名無しさん：2010/04/02(金) 02:29:58

これ以上質問されると言語教室になっちまう。
3時間1万円くらいなら教えるけど。

そんなどーでもいいこと気にしてないで言語を一通り覚えて、
なんか実用的なソフトを一つ開発すれば、データの扱いなんたるかだいたいわかるよ。
今の段階じゃ無理。

931 ：デフォルトの名無しさん：2010/04/02(金) 02:31:05

盛大に誤爆した

932 ：デフォルトの名無しさん：2010/04/02(金) 02:32:41

www

933 ：デフォルトの名無しさん：2010/04/02(金) 02:38:32

>>928
えらい人にはわからんのですよ

934 ：デフォルトの名無しさん：2010/04/02(金) 03:12:26

クラスとテンプレートは要るけどポリモルフィズム
なんて要らないから vtbl は無くてもいいな。

935 ：デフォルトの名無しさん：2010/04/02(金) 03:32:21

インターフェースは多重継承したいね。
実装を伴うクラスは、継承できなくてもいいかも知れない。

936 ：デフォルトの名無しさん：2010/04/02(金) 04:37:30

インターフェイスとか要るなら C++ 使えばいいじゃん。
高級マクロとしてのクラスとテンプレートで十分。
でも実装の継承はもちろん要る。
異論はあるだろうけど。

とかバカ書いてて思ったけど、proxy パターンとか delegation というか
メッセージの forwarding を簡潔にやれる文法あると良いな

937 ：デフォルトの名無しさん：2010/04/02(金) 06:15:16

マルチスレッドを低級言語の言語体系に組み込むのは無意味。

938 ：デフォルトの名無しさん：2010/04/02(金) 07:19:43

何スレ使ったってＣが最強っていう結論で終わるに決まってるのに

939 ：デフォルトの名無しさん：2010/04/02(金) 07:26:34

>>937
今後はハイエンドの組み込みからシンメトリカルなマルチコア化が進んでいくだろうから
無意味とも言えないな

940 ：デフォルトの名無しさん：2010/04/02(金) 07:45:16

>>939
どうやってスレッドの管理をしているのかを考えてみよう。

941 ：デフォルトの名無しさん：2010/04/02(金) 11:25:45

>>939
標準ライブラリで良いと思うけど。

942 ：デフォルトの名無しさん：2010/04/02(金) 12:56:36

結局、低水準を触ったことの無い奴が「仕組みよく分かんないけどCと同じ速度が欲しい」
と言ってるだけなのが良く分かる流れだな