新言語を開発したい

1 ：2010/05/30 〜 最終レス ：2012/11/02

http://pc12.2ch.net/test/read.cgi/tech/1274015781/l50 の継続スレのかたわれです。
低水準言語にこだわる人は「低水準言語を開発したい」のほうへどうぞ。

2 ：

Ｃん言語だって？

3 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

4 ：

関数型とか、GCありとかな言語を作りたい人用らしいです

5 ：

アイちゃんのための自然言語は可？

6 ：

今時GC無し言語なんてありえないだろ

7 ：

いまさら、GCありの言語を作ってもね。
関数型でGCなしとかどうだ。

8 ：

これからはテストがしやすい言語が出てくるだろうな。
ユニットテスト普及以降、テストの考え方が変わった。
コードでテストするようになった。
だけど既存の言語はテストしやすいようには作られていない。
ユニットテストというフレームワークを使うことである程度改善できるけど
さらなる機能が必要。
たとえばprivateメソッドをテストのときだけ外部から呼び出し可能にしたり、
テストのときだけ、関数内部で生成しているクラスのインスタンスを
コードを変えることなく、テスト用のインスタンスにすり替えたり、
テスト対象のコード任意の地点の値をテストコードから監視したり。
アスペクト指向はあまりはやってないけど、テストするには使える技術だと思うな。

9 ：

>>8
C#で不満なところは？

10 ：

>>8
うん。大規模なプロジェクト、あるいは一人だけで作る場合の生産性を上げるようなものだね

11 ：

>>9
上司にC#の言語の制約で出来ませんと言い訳できないところ。

12 ：

オブジェクト指向寄りでGC有りより、
関数型寄りでGC,VM無しのCって方が面白そうだわな。

13 ：

そんな時代遅れ言語はあっちでよろしく

14 ：

scalaでいいじゃん

15 ：

あっちは紙降臨した模様

16 ：

髪(笑)

17 ：

Gentee でいいだろ

18 ：

ここが一番負けてるな

19 ：

見えない敵と戦ってる人こわい

20 ：

見えない敵が一番手ごわい

21 ：

分割前のスレに書いたことの要約
【新言語開発が破綻する典型的なパターン】
言語比較厨登場。言語仕様を大量に盛り込む。工数が膨大に。
↓
開発者が不足。しかも楽しい仕事しかやりたがらないダメな奴ばっかり。
↓
よってライブラリ、デバッガ、IDEの製作やドキュメントの整備等の
面倒だが重要な仕事は手抜きし放題。場合によっては完全放置。
↓
使えない糞言語なので、ユーザーが集まらない。
誰も使ってくれないので開発者のモチベーションが保てない。
↓
終了。
【対策】
・言語ヲタを排除する。工数を増やす人はいらない。
・達成目標をよく議論して明確にする。無計画に始めない。
・小さい言語仕様にする。出来上がってから少しづつ拡張すればいい。
・他の言語に勝てる分野で勝負する。使えない言語を開発することに意義はない。

22 ：

まだ始まってもいないのに気の早いやつだな

23 ：

汎用言語を作っても無視されるか他言語の劣化コピー扱いされるのがオチだし
ライブラリ作成の工数を減らす意味でも対象にするドメインを絞ったほうがいい。
自分が勝算がありそうだと思う分野をあげておく。
【ゲーム専用言語】
有名なところだとノベルゲームやアドベンチャーゲーム用の吉里吉里2やNScripter
なんかがあるが、GOTO指向の時代遅れの言語なので普通にやれば勝てると思われる。
ネトゲは無理でも、アクションゲーム、パズルゲーム、シューティングゲーム
くらい対応できれば十分。
【携帯用言語】
携帯電話やAndroidやiPad上でプログラミングできるようにする。
既にやってる人もいるだろうが、メジャーなものはないから今なら
まだ勝てるチャンスがある。ライブラリが小さいもので済むのも利点。
【日本語プログラミング言語】
現在は"なでしこ"一人勝ち状態だが実はかなり低速な上にバグだらけ。
文法も破綻気味なのでもう少し洗練された言語を作ればシェアを
全部奪えるのではないかと思う。
【画像/動画/音声 処理用言語】
例えば本格的な画像編集をGIMPとScript-Fuなんぞで頑張るのには無理があるし
GPLでがっちり固められてしまっているのでつまらない。
およそマルティメディア関係のアプリケーションでは速度の問題が大きすぎて
結局C++でプラグイン書いてリンクのパターンになってしまう。
簡単な記述でそこそこ高速なデータ処理言語があればシェアがとれるはず。

24 ：

gotoは速いんだよ

25 ：

gotoはゲームシナリオとの親和性が高いしな

26 ：

>>25
いやノベルゲームのバグの原因の大半はGOTOとグローバル変数だと思うけど。
ノベルであっても関数言語的な構造をもっているなら自動テストを行って
ある行動をプレーヤーがとると無限ループになるとか
絶対に取れないフラグが存在するとか、バグを検出するのが容易になるので
素人こそ先進的な道具を使わせておくべきじゃないの。

27 ：

バグの原因は素人

28 ：

結局フラグ使ったステートマシンにするしかないんだから
switchのラベルでもgotoのラベルでも同じことだろう。

29 ：

>>28
例えば
ストーリー() {R, 事件, 別れ}
R() {移動, 発見, 挨拶}
移動() {台詞="
長い文章"}
…
と構造化されてるのと
*ストーリー
(長い文章)
goto R
*R
(長い文章)
goto 移動
*移動
(長い文章)
goto 発見
…
が同じわけがねえ。
実際はif文とクラスに属してない総称型のフラグが散らばっててさらに
分けわかんないことになってるんだよ。よくあんな言語使うと思うけど。

30 ：

エロゲ作ってんの？くれよ

31 ：

総称型じゃないやw。型の決まってないフラグね。さっきまでJavaの本読んでたんでスマン。

32 ：

ｗ。

33 ：

エロゲスクリプトで総称型ってなんに使うんかな。

34 ：

モザイクの量とか

35 ：

巨Rでも貧Rでも同じメソッドを

36 ：

着衣プレイの時の制服の種類とか

37 ：

AS3を汎用言語にしたい
30歳になったら本気出す

38 ：

普通にjsのエンジンは一杯あるわな

39 ：

いや、AS3です^^;

40 ：

おっと、調べたらかなり違うのね
でもあそこまでやるなら他の言語でも良さげな

41 ：

>着衣プレイの時の制服の種類とか
詳しく

42 ：

そこかよ

43 ：

∨∨
(((((((((( >着衣プレイの時の制服の種類とか ))))))))))(キリッッッッ!!!!
ゴミグラマじゃねーか

44 ：

これ ； デリミタっていうんだけどさ、これをつけなきゃエラーになるような
そんな言語使ってる奴ってどうみてもゴミだと思うんだけど
もしかして「；」これ打ち忘れてコンパイルエラー出すのが楽しいの？
そうか、二度と話かけんなよ
なんだ、ただのゴミか（笑）

45 ：

カオスラウンジR

46 ：

ここもやはりgdgdか。上げ。
このままだと数年後も完成しないだろうから手法を提案をするか。
まず、初心に戻って明確なプロパガンダといいますかキャッチコピーを決めるといい。
可能であれば利用状況などの想定を盛り込んだ短編小説もね。すると必要なものがわかる。
例えばコピーであれば、
- ロケット制御用言語なら「Rock:et を使って月のウサギに会いに行こう」
- 日本語異性型ロボットAI言語はぢらひ「俺の嫁、旦那様、バーニング」
- 従来の汎用言語の改良であれば「あなたは今日からリア充です(※効果には個人差があります)」
など...。

47 ：

こういう言語が欲しい、作れというのであれば、一通り網羅した仕様書書いたほうが受け入れられやすい。
それに仕様は複数存在しても別に問題はないよ。rejectされても別プロジェクトでやればいい。
つか欲しい・作れって言うだけでは、仕様書いている人からすれば
「これこれこういう言語があるからそっち使っては？」になることが多いと思うよ。

48 ：

言語仕様を書きあげるのは意外と大変だからねえ。
やっぱり謎の重圧と戦う、調べることが数千件、細かいことに
配慮して悩みぬくなどあります。使うと書くとでは大違いですよ。
では押しの強いひとが現れることを願って。以上。

49 ：

新言語→信玄後→

50 ：

やっぱなんらかの既存処理系においては存在しない、または直接扱うのが困難な計算モデルがあって
それを容易に扱う為の言語といった形の必要性で無いと作る意義が乏しいだろうな
こう言語仕様においてはその扱いたい計算モデルに都合の良い文法とそのプログラミング言語としての意味論を定義することが
結構大きな割合占めてると思うのよね

51 ：

>>50
俺はそんな、適用する場所があまりない、つまり効果が薄いことよりも
もっと人間が楽になる言語がほしいよ。
具体的には、言語機能として、ユニットテスト、リファクタリング、
デザインパターン、ドキュメントの書き方まで考慮されていて、
特別な何かを別に用意しなくてもこれらが簡単に実行できること。
簡単にというのは、正規表現やワンライナーができるということも含まれている。
それでいてstrictモードなら、型をきっちり明記して、様々な統合環境を作ることも可能。

52 ：

なんていうか言語よりも開発環境の問題だろう。

53 ：

>>52
言語によって開発環境ができることが限られてくるんだよ。
たとえば変数に型を持たない言語では、
メソッドの補完は不可能。
だからそういうのを減らして、言語がコードの解析をして全体を理解し、
その情報を開発環境に提供することで開発環境の機能を
さらに向上できるように考慮された言語。
それは結果的に人間を楽にしてくだれる。

54 ：

あと、開発環境に頼り過ぎなのも良くない。
たとえば名前でも意味が違う変数があるだろ？
それは開発環境ではどれが同じで違うか理解できても
テキストエディタでは理解出来ない。
もしこれが開発環境ではなく言語自体で情報を提供されるようになったら
テキストエディタからでもコマンド一発で簡単に知ることができるだろうし
テキストエディタを拡張することも簡単だろう。
だから開発環境の問題ではなく、その問題を言語側に移そうという話でもある。

55 ：

言語処理系と言語そのものがごっちゃになってるな
リフレクションの機構は処理系が提供するものだ
仕様としてその言語処理系対する要件として定義はできるがな

56 ：

Google、新プログラミング言語 " Dart " を来月発表、「構造化ウェブプログラミング」向け
http://japanese.engadget.com/2011/09/09/google-dart/

57 ：

>>55
リフレクション？ リファクタリングの間違い？

リファクタリングは確かに処理系が提供するもの。
だけど、なにかの機能を載せたいと思ったとき、
その機能を実現するためには、その機能を実現するための情報が
ソースコードに書かれていないといけない。
だから、開発環境、処理系、にフォーカスを当てて
それに搭載したい機能を考え、
その機能を実現できる言語を作りましょうってことだよ。

58 ：

>リフレクション
プログラムの実行中、コンパイル中にそのプログラム自身の構造を参照したり書き換えたりする機構の事だよ
インスタンスから自分自身の型や型からその属性や継承木を言語内で1級のオブジェクトの形で取得できるわけだ
そのインスタンスが生成されたコード内の位置を取得することができるものもある

59 ：

>>58
リフレクションの機能がわからいんじゃなくて、
どこからそんな話が出てきたんだってことなんだが。

60 ：

プログラミング押しえてぇえええええええええええええええええええええええええ

61 ：

>>51
具体的に新しい言語によって何を解決したいのかが何一つ読み取れない。
例えばC#（＋VisualStudio）なら何が不満なの？
どういう部分に考慮が足りないと感じる？

62 ：

>>59
ゴミ相手に何マジレスしちゃってんの？
これでわかっただろ
ここには58こういうゴミみたいな「知ったか」しかいない事実
覚えたての単語を使いたがる精神年齢中学生
適当にカタカナ言葉を混ぜておけば
>>58
いっぱしに、プログラマー気取りっすかあああああああああああああｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
カンケーネータンゴダシテシッタカデスカアォアアアアアアアアアアア！！！！！！！！！
さっさとR　　黙ってR　今すぐRよ　ゴミ
ゴミはさっさとRばいいのに

63 ：

>>50
よくある方法で思い切って概念の整理を行うことで新しい言語を生み出すこともできる。
また一般に難しいとされるものをすっきり記述できるようにするといいと思う。
例えばオブジェクト指向や関数という概念などを、もっと単純でなものにできるか、
バグの出ない記法や間違っているものを間違っているように見せる方法はあるか、
など未だ色々と解決する問題はあるね。

64 ：

>>51
それって...まだ未実装のようだが Cobra だよな...
ttp://cobra-language.com/
ttp://cobra-language.com/docs/quality/

65 ：

cの完全上位互換にとなっているobjective-cのアプローチが好きだ
ネイティブ吐いて、オブジェクト指向で理想的な言語だ
だが、objective-cは何かが違う。あの言語は何かを間違えた。

66 ：

stとCのハイブリッドだしな
@なんちゃらを無くして
gc前提なら悪くないかもしれん

67 ：

かもしれんね

68 ：

objective-cってi-phoneアプリでも使われている言語だよね？
純粋なC言語ではi-phoneアプリは組めないのかな？
もしCで書けるならJAVAでも書けるって事だから
そうなるとJAVAプログラマーはキャッキャウフフになるんだけど
それを実現するには努力が必要だよね

69 ：

iPhoneを駆逐するために、Javaプログラマはもっと熱意を持ってAndroidアプリに取り組むべき

70 ：

そういうことは自分が率先してやれ

71 ：

>>68
Cで作れるならJavaでも作れる？
どういう論理か教えて欲しい

72 ：

>>71
まずCでJavaバイトコードを実行するVMを書きます

73 ：

それを煮ます

74 ：

なるほど。そりゃ努力が必要だわな

75 ：

JNIの事だと思うよ

76 ：

dartがえらく素っ気ないc++もどきでワロタ

77 ：

>>75
でもそれじゃiPhoneで走らないだろ
あ、JNIを呼び出す為にVMも実装するのか
偉いな

78 ：

perlやphp,pythonの失敗を見てわかる通り、
個人やコミュニティが開発する規模の言語が
普及してから大きなメジャーアップデートしても誰もついてこない
最初に文法を決めてしまったのであれば、後から修正してはならない

79 ：

失敗してんの？

80 ：

個人が作った言語だろうが、大企業が作った言語だろうが、委員会が作った言語だろうが、
アップデートについてこれない低能を相手にしてたらやってられるわけがない。
そういう低能は切り捨てるだけ、そういうレベルの企業には潰れる以外の末路はない。そんだけ。

81 ：

文法を修正したら駄目だろ。できるのは追加だけだ

82 ：

文法を修正したら別言語じゃんｗ

83 ：

言語自体古い
文字通り生きてる有機コンピューターつくれよ

84 ：

脳みそ直結だろ
防壁は張っとけよ

85 ：

現生人類と比べ、喉の奥（上気道）が短い。このため、分節言語を発声する能力が低かった可能性
ネアンデルタール人 - Wikipedia

86 ：

甘ったれた滑舌の悪いネアン
可愛いかもしれん

87 ：

このスレを総合すると c++ が良いということですね。

88 ：

それだけは無いな

89 ：

というか、コンセプトがみんなバラバラなんだよね、多分
汎用言語を作りたいのか
専用言語を作りたいのか
汎用の言語なら、動的言語か、静的型付け言語かでざっくり分かれるけど
代替の場合、自分の使っている or 愛している言語に、ほかの言語の機能を取り込む方で頭が回っている
自分の場合、Rubyのメタプログラミングの機構や、Object型にくっついている、黒魔術的なメソッドの細かい仕様バグを取り除いて再設計されたものとかを欲しいと思ってしまう

90 ：

汎用型で静的型付け言語、
それでいて動的言語で出来るメタプログラミングを
できるようにした言語が作りたい。
あとコンパイラのアーキテクチャを変更したい。
今のように実行したらバイナリが出来る方式ではなく
”プロジェクト” を "コンパイラーサーバー" に読み込ませると
ファイルを更新するたびに、コンパイル可能な所をリアルタイムでコンパイルし、
コンパイルができてる場所、エラーにある場所、その他様々な情報を取得できるという設計。
言語仕様ももそれが出来るように考慮する必要があるだろう。
そしてリファクタリングやコーディング規約チェックなど、
コンパイラの助けを得たほうが出来ることを、コンパイラにやらせ、
その機能の呼び出しをテキストエディタから行いたい。

91 ：

>>90
最新のIDEを使えばオケ

92 ：

>>91
最新のIDEの限界を超えた所を狙ってる。

93 ：

なら言語じゃなくIDE作れよ
今の言語の文法難しくてパーサー作れない
処理系の吐く情報難しくて解析出来ない
よしオラ言語作る！
これでは進まないのも当たり前

94 ：

>>93
言語（ソースコード）はデータであり
IDEはそのデータを処理するツール
いくらツールがすごくても
データがなければ、なにも処理できない。
つまりIDEを更に進化させるためには
データである言語をIDEに適したものに改良する必要がある。

95 ：

普通に静的型付けなら実現不可能ではない内容に見えるが

96 ：

>>94
その考えが既に浅薄だとは気づかないのか
構文解析やリンケージやシンボル情報うんぬんありきのIDEだと気づけ
文法をパーサが簡単になるようにするとかは
別に構わないが、IDEありきの言語とか
本末転倒にもほどがある
最近のだどgolangの設計方針とか
パッケージとかgocodeとかみてみ

97 ：

>>96
IDEありきなんて言ってないですよ？
>>90を読んでください。むしろ180度逆で
IDEがやっているようなことをコンパイラサーバーに
やらせることで、テキストエディタでも
IDEと同等の高度なことができるようにするという書いてあるでしょ。
なんでこう人の話聞かないかな。

98 ：

本質的に同じだろ
パーサにどう吐かせるか
吐いた情報をどう加工するかだけの話
そんなのは言語自体ではなく単なる処理系のバックエンドの話
その辺と言語をごっちゃにしてるから浅薄だと

99 ：

>>98
頭悪いねぇ。
吐いた情報？ じゃあその情報はどこから持ってきた。
言ってみ。

100 ：

パーサーと書いてるだろ
ASTなりなんなりを吐くんだよ
サーバに置こうがローカルだろうがやることは同じに決まってんだろ
処理系の知識0ならまずは
ドラゴンでも中田さんのでも読んで来い

101 ：

コンパイルフェーズをプラガブルにしてフロントエンドだろうが、中間言語処理部だろうが、バイナリに落とすところだろうが
どこでも割り込み可能にしたら多分なんでも持ってこれる
昔、gccで中間言語をXMLに落としたり、情報拾って部分式の型や逆参照を類推するような実験的プロジェクトがあったんだけどそういうやり方だった
まぁ当時はgccプラグインとか無かったから、無理やりコード改変でやってたけど今ならもう少し楽かも

102 ：

LLVM

103 ：

まあコンパイラの基本だよな
gccも昔は弄りやすかったけど
今はモンスターになっちまって見る気にならんけど

104 ：

>>100
> パーサーと書いてるだろ
パーサーはなんでもでてくる四次元ポケットじゃないぞｗ
パーサーはただ情報をコンピュータが理解できる形に変換するだけ。
情報はそもそもソースコードにある。
ソースコードになにを書くか。それは言語によって決まる。
言語によって、どれだけ情報を取り出せるかが決まる。
多くの情報を取り出せるようにするには、言語を作るという話になる。
ここまで説明すれば理解できるよな？
単純にパーサーが頑張ればなんでもできるってわけじゃないことが。

105 ：

じゃあどんな情報が必要だと思ってるんだ

106 ：

たとえばJavaに「このメソッドは自分自身のオブジェクトを変更しない」という情報をつける構文があれば、
自分自身を変更しようとした時に警告を出せる。
これはいくらパーサーが頑張ってもできないことだ。

107 ：

他にも、言語仕様が不足していたためIDEで
コーディングサポートが実装出来なかった機能として
Javaのenumがあるよな。昔のJavaはenumがなかったら
引数に入る値のコーディングサポートが出来なかった
パーサーや言語以外の何かが頑張ればなんでもできるってわけじゃない。
言語仕様によって、IDEが出来る機能は変わってくる。
これは紛れも無い事実。
なら逆に、IDEの機能をさらに発展させるには
言語仕様を変える必要があるという発想は自然と出てくるはずだ。

108 ：

なんというか、自説を認めさせたいだけでそこまで凄いアイデアがあったわけじゃないのね

109 ：

あと、言っておくがIDEを出したのは話がわかりやすいからであって
別にテキストエディタでも同じ事だぞ。
俺は存在を知らないが、高度なテキストエディタがあれば
IDEと同等の文法を理解した上での、コーディングサポートをしてくれるだろう。
で、なぜそんな高度なテキストエディタは存在しないのか？俺は存在を知らんのだｗ
その理由は、今のコンパイラは、コンパイルすることしか出来ず
コンパイル途中の情報を取り出せない。
IDEなみの機能を搭載するには、テキストエディタ開発者がコンパイラを作らなきゃいけない。
それは普通に考えてありえない話。だからコンパイラのアーキテクチャも変更しないといけない。
それがコンパイラのサーバー化という話。
テキストエディタを進化させるためのコンパイラサーバー化だ。

110 ：

>>108
誰がすごいアイデアといったんだ？
最初から、このスレらしく「そういう言語を開発したい」と言ってるだけだろ。
　　↓
>>90
> できるようにした言語が作りたい。
そんだけしか言うことがないなら、難癖つけてくんなよ。

111 ：

ここまでで、開発全体を快適にするためには、
IDEで頑張る前に、言語仕様を頑張る必要があるという話に
同意いただけましたでしょうか？

112 ：

constをあんなに早くに導入したC++は神ということで

113 ：

>>112
おい、答え言うなよｗ
せっかく、そんな機能に何の意味があるんだ？って
素人丸出しレスを待っていたのにｗ

114 ：

意味が全くわからん
enumがIDEとかエディタとか
IDEとエディタを分けて考えてたり
コンパイラが情報を出してくれないとか
色々ツッコミ所が多すぎて…
モノを知らなさ過ぎる
enumもconstもvolatileもprivateなんてのも
言語の必要性から来たもの
人間にもコンパイラにも理解出来るものは
IDE/エディタにも理解させれるのは当然だが…
後は冗長で縛り過ぎる言語は誰も使わないぞ
契約プログラミングとか今や何それだろ
興味があるなら色々処理系みて見るといい
gccなんかの中間情報もだが
goとかは自分のパーサが標準ライブラリだし
エディタで補完するための情報吐くツールもある

115 ：

>>114
意味がわからんのはお前が馬鹿だからじゃね？
そもそも言語の必要性ってなんだ？ｗ
enumになんの言語の必要性があるんだ。
言語の必要性で言えば、constで十分じゃねぇか。
実際ちょっと前まではenumしか無かったんだし。
極論いえば、全部アセンブラでも作れる。
言語っていうのは「人間が書きやすくするため」に作られたもんだ。
ならば、人間がさらに書きやすくするためには、言語を改良するのは当たり前の話。
IDE・エディタが頑張るのは、その次の段階だし、
言語機能が不足していれば、IDE・エディタががんばろうとしても
不可能なのは、enumやメソッドのconstで例に出したとおり。
具体的な例は出てる。それが違うというのなら、関係ないごちゃごちゃとして文章はいらない。
「言語仕様によって、IDE・エディタがサポートできる機能が変わってくる」
このことに”だけ”に反論してくれ。

116 ：

>>115
理想のIDEを作るために最適な言語仕様を考えよう
と言いたいなら理解できる。
本末転倒であることは分かってると思うが
百歩譲って、それが生産性や快適さをどう改善するんだ？

117 ：

>>116
理想のIDEというのは正確じゃないな。
コーディングサポートと言ったほうが的確。テキストエディタであっても
多かれ少なかれコーディングのサポート機能はあるだろう。
例えば、構文に色をつけるのだってその一つだ。
さすが色があっても生産性や快適さを改善することにならないと
主張するわけじゃあるまい？
あとは「どう改善するんだ？」という話じゃないのは解るかな？
どう改善するかではなく「どう改善したいか？」だよ。
それが、言語仕様で決まっていなくてもできることなら、言語仕様の変更はいらない。
だがenumみたいに、言語仕様があることでコーディングサポートが改善する、
ということはあるというのが事実。
もう限界でこれ以上生産性も快適さも上がらないよ。言語はもう発展しきった。と
いうのなら、そいつには、君のとってはそうだねって俺は言うだけだ。

118 ：

その「どう改善したいか」を君が示せないから賛同を得られないのだが

119 ：

>>118
つ「言語仕様によって、IDE・エディタがサポートできる機能が変わってくる」
このことに”だけ”に反論してくれ。

120 ：

コテハンかトリップ付けてくれ

121 ：

俺の好きにする

122 ：

114だがconstやenumを#defineがわりとしか見てないとか、もう…
とにかく言語云々よりIDE()が作りたい事だけはわかった
もし実際になにかを作り始めたら
いずれ俺の書いた意味がわかる日も来るよ

123 ：

>>122
なんか偉そうだなｗ
俺の書いたことに一切反論出来なかったくせに。

124 ：

>>122
お前卑怯者。
#defineという単語を出したのはお前が初めてだ。
お前の書き込みは、#defineがわりとしてみていると
周りの人に錯覚させようという書き込みだろ。
#defineがわりと勘違いしているのはお前だけだ。

125 ：

どう見ても、そうとしか見えない、と表明したら、
「周りの人に錯覚させようという書き込み」になるのかwwwwwwwwwwww

126 ：

>>122では
「がわりとしか見てない」
>>125では
「そうとしか見えない」
相手に対して言った言葉が、
自分の感想に摩り替わってる。
無意識で自分の都合の言いように
自分の発言を思い込む人なのか？

127 ：

違うならどう違うか、具体的に反論すればいいだけなのに、人格攻撃しかできないの？

128 ：

なにに反論すればいいかわかんなくなってきてるみたいだから
もっかい書いておくわ。
> 「言語仕様によって、IDE・エディタがサポートできる機能が変わってくる」
> このことに”だけ”に反論してくれ。
これに対する反論はでてない。

129 ：

それ以外の主張はどうでもいいことだから無視していいわけね。
全く見なかったものとして、無視しても一切文句ないわけね。了解。

130 ：

>>129
そもそも>>90になにがしたいかは書いてある。
それにして、反論したい人がいるみたいだが、
その内容が、「お前はわかってない（その理由は書いてない）」ばかりで
何の反論にもなってないのだ。
そしてそいつは質問ばかりする。それに対して
enumやconstの例を出して説明があるが、
それに対しても「お前はわかってない（その理由は書いてない）」と
言うばかりで、何の反論もない。
どっちのワンサイドゲームになっているか一目瞭然だろう。

131 ：

挙句の果てに、constを#defineの代わりとか言い出す。
話をちゃんと見ていれば、ここで出ているconstは
定数のconstではなく、メソッドのconstであることはわかるはず。
そこに根本的なレベルの差を感じるよ。

132 ：

根本的なレベルの差、って、2ちゃんねるに思いのたけを書き綴るしかできないレベルの低さのこと？

133 ：

人格攻撃しかできないの？

134 ：

「言語仕様によって、IDE・エディタがサポートできる機能が変わってくる」
別にそのことそれ自体に対しては誰も否定していないので安心してね
という事でこの話はもう終わりにしよう

135 ：

完全勝利で終わらす気かｗ
反論しろよ。

136 ：

だってそれ以外には何も書いてない、とみなしていいということなんだから、
そういうことでしょ？

137 ：

どうでもいいよ。
ここまでの間>>90の言うことに
まともな反論はなかったという事実が全てだから。

138 ：

自分の主張している範囲を絞って相手に同意させて
元々の主張全体を正しいように見せる
この詭弁のテクニックは何か名前がついてた気がするけどなんだっけ

139 ：

> なにに反論すればいいかわかんなくなってきてるみたいだから
> もっかい書いておくわ。
> > 「言語仕様によって、IDE・エディタがサポートできる機能が変わってくる」
> > このことに”だけ”に反論してくれ。
このこと以外についての反論は相手にしない、って明言してるもんな。

140 ：

で>>90に負けたわけかｗ
情けないな。

141 ：

実装してから勝利宣言しろよw

142 ：

「開発したい」スレでなに言ってんだ？

143 ：

全ての視点がツールでのサポートがどうたらで
その事を言語仕様の重要点にする意味が
ないって指摘をしてんだが
フルシカトだから話にならんね
あ、constがあればenumいらねと書いた事は面倒だから忘れてやるよ

144 ：

>>143
言語仕様ってのは、人間が使いやすくするために存在するもの。
すべてがシンタックスシュガーであるといってもいい。
使いにくくてもいいなら、比較とジャンプができれば、事足りるんだからさ。

人間が使いやすくする＝ツールのサポートも含まれる。
最終的な目的は何だ？　ツールを使ったらダメなのか？
そうじゃないだろ。使いやすく出来るのであれば
どんな手段もとっていいはずだ。

145 ：

普通チューリング等価であることをシンタクティックシュガーと表現したりはせんぞ

146 ：

だからなんだよｗ

147 ：

コーディングサポートの為だけに言語仕様を追加するのは効果が薄い（無い）のではという批判が主なのに
何ズレた反論を延々としてるんだろう
例に上がってるenumやconstだって開発環境の為のヒントの為だけに作られたわけじゃないし
ぶっちゃけそういうのはアノテーションで十分じゃん

148 ：

> コーディングサポートの為だけに言語仕様を追加するのは効果が薄い（無い）のではという批判が主なのに
その批判に根拠が無いから
だらだらと続いているんだろ。

149 ：

快適なスレッドリーディングサポートのために
コテハンの追加を所望

150 ：

言いだしっぺからどうぞ

151 ：

こうか

152 ：

ほらよ、コテハン。
これでなにがしたいのかしらんが。

153 ：

ちなみに、こんなのもある。

154 ：

さて、これでなにが快適になると思うか。
だがコテハンできたのだから、満足したろ？

155 ：

コテハンと言われてトリップを付けるか。
まぁ他人になりすまされることがないからそのほうがいいか。

156 ：

じゃあそういうことで。なお、コテハンもトリップも
つけたり外したり変えたりするのでよろしくｗ

157 ：

それなら言語の処理系本体に持たせて、各々のIDEが車輪の再発明しないだけでも
小さな一歩と言えると思うんだけど
全体的に見て、後退と言える要素がほとんど見当たらないんだけど
>> 97
の意見は私はいいカンしているように見える

158 ：

外部ツールで補完の情報やらクロスリファレンスを
出させてエディタで利用する
なんてのはかなり昔から存在する
構文解析はエディタの外部だと反応が鈍くなる
どっちにしろ新言語というより処理系の話

159 ：

かといってemacsのように重たくなっても困るしな
だれかemacsにコンパイラ仕込んだ奴いる？

160 ：

excelなら見たことあるな、うろ覚えでググる気にもならんが・・・

161 ：

エディタにコンパイラ仕込むっていう意味が不明だが
flymakeで裏で文法チェックとか出来る
eclipseもjavaは知らんがCDTはgccとかを呼んでるだろ

162 ：

>>160
これのことか？
http://d.hatena.ne.jp/n7shi/20100519

163 ：

面白いな、これのemacs版でも作ってみるといいかもな

164 ：

http://babanba-n.iobb.net/mylang.txt
マジレスするとこんな感じの言語が欲しい
中二病の妄想投下だよね、失礼…

165 ：

真面目な回答をすると人工言語ロジバンがコンパイルして実行可能なので
院生とかでこのコンパイラ作れば歴史に名を残せそう…

166 ：

GUI の作成を含め、IDE が作りやすい言語、作りにくい言語と
いうのはある
Smalltalk は、IDE が作りやすい言語
C++ は、IDE が作りにくい言語
Microsoft の Visual C++ なんて、Visual という言葉を捨てた
方がいい

167 ：

>>166
VC++を捨てるのはいいとして、
Smalltalkは使われてないだろｗ
他にまともなものを出さないと
捨てようにも捨てられない。

168 ：

C++は文法が複雑になり過ぎて
機械的なパーザが作りにくいからな
STはObjectiveCとして生きながらえるしか…

169 ：

>>168
よくわからん。
いくら複雑といってもコンパイラはパース出来るんだろ？
ならIDEだって同じ方法で理解できると思うんだが。

170 ：

IDEで開発支援するなら動的言語が最適

171 ：

>>170
動的言語で一括りにするなよ。
っていうか、世の中のほとんどは動的言語じゃね？
IDEが発達している言語は、Java、C++、
C、C#、VB.NET、Smalltalkぐらいじゃね？
あとの言語は数世代遅れた所で止まってる。

172 ：

>>169
文字打つたびに長ったらしいコンパイルなんてやり始めたら作業にならんだろ

173 ：

>>172
バックグラウンドでやるから関係ないよ。

174 ：

デバッグしながらコード書ける？

175 ：

>>172
BoostのTMP系でも食ってなきゃ滅多にないだろ。

176 ：

>>164
俺も昔はこんなのだったなあと思いつつ言うので許してね…。
ぶっちゃけ酷い。プログラマーとして初心者以下のレベル。

177 ：

ひどい理由が書いていない。
ぶっちゃけ評価する人間として、初心者以下のレベル。

178 ：

>>177
これで軽く気持ち悪くなった。
＞i=0.to_i // 一度Int型で固定
＞i : Obj // どんな方でも受け入れることに変更
モンキーパッチ推奨、DRYと真逆の発想、可読性無視、スコープ破壊
もうお腹いっぱいです。
・動的型と静的型の違いは明確に。
・シノニムが多い。統一性を。(これではただのRRuby)
・ライブラリ、型、言語仕様の境界が曖昧すぎ。
　NullContext： 継承による拡張はライブラリ側。スコープは言語。
・メソッド接尾子
　if enabled? ... else ... :　truthy、falsyが曖昧。可読性悪。
　array.push! : 強制すると感染しますので破綻します。
　　万が一実装するにしても、これこそ型を使うべき。(C++のconst)

179 ：

追加
・オペレーターオーバーロードっぽい機能は静的型用。動的メソッドは無理。

180 ：

いい過ぎた。すまん。
読んでて実装無視の仕様に腹が立っただけなんだ。
本人も中二と認めてるものにいちいち口出して済まんかった。

181 ：

一時の感情で発言して、その後謝罪するという無駄行為は謹んでください。

182 ：

どっちもキモイので謹んでください。

183 ：

ide言語君よりかなりマシな流れ

184 ：

>>183
なにも言うことがないお前よりも、ide言語君の方がマシ。

185 ：

とりあえず、そのide言語君が「何を、いつまでに」作ってくるか
答えるまでは評価しないという方向で・・・
ネタは>>162で与えた筈

186 ：

>>185
言い出しっぺの法則。
まずお前から

187 ：

パス

188 ：

>> 180
どうも、真面目な話参考になりました
具体的に非難されるとよく考えるきっかけになるし、ありがたかったです
ちょいちょいと修練しなおしてきます
少し恥ずかしいですが、恥の記念碑みたいなもので少し残しておきます
こういうスレは進みが遅いので、1000行くまで残すことはないですが

189 ：

ないね

190 ：

まずは 新言語からCに変換してgccで実行ファイル作るとこまでやる
これだけでも世界が変わる
納得いくものができたら次のステップへ

191 ：

今ならjs吐かせてブラウザから
試せるようにしたら話題を少し掴めるかもな

192 ：

sapphireって名前にしようと思ったんだけど、すでにそういう言語あるんだね
http://d.hatena.ne.jp/Matthew/20110908

193 ：

｢新言語｣と言うがあまり新しさのある言語は出てきてないな。
もうそんなに新しいのはないということかな？
どっか隠れたところに思わぬ見つけ物はないんかな？

194 ：

多くの論理や構造の表現は既存言語上で動くライブラリやフレームワークで実現できるからな。

195 ：

>>194
俺の誤読かもしれんが、それは新言語が出てこん理由にはならんな。
”多くの論理や構造の表現は機械語上で動くライブラリやフレームワークで実現できるからな。”
も言えるからな。

196 ：

目新しいパラダイムの大きなのがないし
しかたなくね？

197 ：

最近のじゃ目新しいのはπ計算ぐらいか？
それでも、ラムだ計算をデフォルトで並列に対応させた体系って意味じゃ目新しくないかもだが

198 ：

おとなし過ぎるな。
まじめにお勉強しているようなのはダメかもな。
なんかトンデモに近いようなのでもないんかな？
ジョブスだったらどんなのやるかな？

199 ：

時間のムダ

200 ：

> ジョブスだったらどんなのやるかな？
テンプレートそのままのバカだな

201 ：

0は、偽
それ以外は真
false
true
それ以外は灰色

202 ：

ファジィ制御（ファジィせいぎょ、Fuzzy Control）

203 ：

>>197
π計算ってλ計算を並列にしただけじゃないから。

204 ：

scratchとかのビジュアルプログラミング環境は新しいって言えるかな？
プログラマの感覚としては、なんかこのスレの趣旨とズレている感じもするんだけど
時代には合っていると思うんだけ

205 ：

ファジィ制御って3の倍数と5の倍数がどうのって話だっけ

206 ：

机上の空論

207 ：

>>193
存在すると思うよ。
俺が苦心しているのはそれがプログラマーの仕事を奪う可能性があるので公開しない方針。
つまり素人でもプログラミングできてしまうことでプログラマーが用無しになるのは困る。

208 ：

俺の場合はそういうことをスレに書き込むことも自重してる。

209 ：

俺の場合、業界の情況を見るといいたくもなる。

210 ：

黙ってそれ使って金儲けするのがお前の為であり社会の為

211 ：

プログラミングなんて人間がやることじゃない

212 ：

プログラミングなんて、人間にしか出来ないだろ

213 ：

いや、そう遠くない未来に。

214 ：

人類が絶滅しているかも知れません

215 ：

俺は非ノイマン型の言語を開発中だよ、オマエラ程度では非ノイマンの
可能性すら分からないだろうけど。
多くのものがチャレンジした従来型の非ノイマンの類はどれもそれぞれの
パクりにすぎないわけで。新しい概念を生み出すことが一番障壁になる。

216 ：

分からないから早く完成させてきてね

217 ：

非ノイマン型言語ってどういうことなん？
Cみたいな命令型言語じゃなく、Haskellみたいなやつってことかい？

218 ：

データフローアプローチなんて既にいくらもあるし。
Prologあたりとかぜんぜんノイマン型じゃないけど、そういったことも
知らないバカのようだから、反応する必要ないよ。

219 ：

言語を作るのはいいが、
開発に便利な機能を取り入れた言語を作ってくれ。
いつまでもコード補完機能をコンパイラじゃないIDEが
担当するのはおかしいと思わないのか？
コンパイラは100%コードを理解できる。
ならコンパイラに聞けば良い。
再発明する必要はない。

220 ：

何も分かってない恥さらしはしない方がいいと思うんだ

221 ：

言い返せないのなら、黙ってれば？ｗ

222 ：

書きかけのプログラムが問題で、プログラムとしては不整合な状態だから
型推論とかがうまく行くとは限らないが、
書いてる最中なのでまさに入力補完機能とかが欲しい
たぶんアドホックな手法を導入する必要がある

223 ：

コンパイラのフロントエンドの処理をIDEと共有しようというのはあるかもしれない。

224 ：

そのとおりだな。
そうなれば、vimやemacsの低機能なエディタでも
完全なコード補完が出来るようになる。
今テキストエディタが低機能なのは
コンパイラを再発明しなければ
ならないような状態だからだ。

225 ：

何言ってるんだこいつ

226 ：

ghc-mod

227 ：

織田信長？

228 ：

DLLみたいに、読み込んで加工せずに実行できるコードとか、exeファイルに組み込みたい場合もあるよね。
加工が必要なファイルでも、暗号化だけ施したコードとか、ソースコードで表現するならIDEと連携する必要があるね。

229 ：

そーゆーのは言語とは独立したユーティリティとして実装できるじゃん
独立させられるものは独立させといた方が、一般的にはいい

230 ：

中間コードという概念がある言語ならユーティリティでも実装できないかも。
でも、中間コードという概念自体、配布以外で意味があるのかどうか。

231 ：

219: 言語と開発環境を区別して考えられない。
230: 言語と実行環境を区別して考えられない。
231: 仕様と環境を区別しないと考えられない。

232 ：

なんか、どうやって実行するかという話ばかりで、具体的にどういう言語仕様にしようかという話が出ないね。

233 ：

仕様語るのは難しいから。それなりの教養がないと。

234 ：

不毛な話ばかりだから、強引に展開しよう。
動的型言語の利点は、classなどの代入を簡単にすることにある。
しかし、一般的なプログラミングの仕方では、3種（もしくは2種）以上の型を代入しながら作るという事はしない。
それならば、静的型言語に「一回だけならどんな型を代入しても良い」という機能を付けた方が良いのではないか。
異論があっても構わない。動的型言語の存在意義も見出したいから。

235 ：

>>231
なぜ区別しないといけないのか？
頭が硬すぎる。

236 ：

言語と実行・開発環境をセットにしたくてしたくてしょうがない人が少し前から居ついちゃったねw

237 ：

つ 目の前のものしか考えられない頭

238 ：

まあ言語と環境は完全に切り離せないからな。
動的型付け言語で、まともに静的コード補完が出来ないのは
言語仕様のせいなわけだし。
開発環境を補完するための言語仕様があってもいいでしょ。

239 ：

くっつけると新しいものが生まれてくると思い込んでる頭がいるね

240 ：

>>239
それは正しいよ。
たとえばVisual StudioとかEclipseとかね。

241 ：

うわべだけ別の話を持ち込まれても何にもならないね

242 ：

そのコメントも意味が無いねｗ

243 ：

とりあえず使える文字決めようぜ

244 ：

プログラムの最後は.にするか。

245 ：

begin end でプログラムを区切ると、使える記号増えるけど、begin end　という名前の関数と変数が使えない

246 ：

環境込みの言語を開発するのは良いよ。
でも、その前に何故Smalltalkではダメなのか
はっきりさせないと、車輪の再発明になるだけだよ。
>>224
>>223の方法でemacsやvimでコード補完できる言語（コンパイラ）あるよ。

247 ：

Smalltalkの良さを語ってくれ。

248 ：

OCamlとかな

249 ：

「環境込みの言語」ってのは、なに言ってるのかさっぱり分からん。
単に開発環境と実行環境を統合した環境のことを言っているのだろうか、
それともさらにリフレクション機能がを持った環境のことを言っているのだろうか。
いずれにせよ言語仕様と言語処理系実装を区別して考えられない人らしい。

250 ：

環境込みの言語とは、これの事じゃ！
http://www.runexy.co.jp/personal/ultra_c/outline/
C言語という独立した仕組みがあるんじゃ…という突っ込みは無し。

251 ：

環境を実装と直結した形でしか考えられないほうが
どうかしてるよ。
環境というものを抽象化する能力が欠如してるだけじゃなく、
その発想すら無いってことだからね。

252 ：

ぷｗ　今までと同じやり方の
発想しか出来な人がなんか言ってるよｗ

253 ：

このスレに今までと違う発想なんて
一片たりとも存在してないけど……

254 ：

一片たりとも存在していないのであれば、
一体何に対して反論していたというのか？

255 ：

このスレって要するに
・Haskell, OCamlレベルの型推論があって
・Visual Studio並みのコード補完がEmacsやvimのようなエディタからも使えて
・馬鹿でも使いこなす事ができる
そんな言語が欲しいってことでしょ？

256 ：

> 馬鹿でも使いこなす事ができる
これさえ満たしていれば後はどうでもいい

257 ：

じゃあVBとPHPを参考にすれば良い

258 ：

それは馬鹿なら使いこなせる言語。
馬鹿でも使いこなせる言語は別物。

259 ：

じゃあJavaだな
馬鹿用に設計され、初心者も熟練者も一律して冗長なコードになる

260 ：

馬鹿には、汎用言語すらむいてない。

261 ：

馬鹿にも分かってほしい最低要素
・プログラムカウンタとスタックカウンタ
・フラグレジスタと、その他のレジスタ
・スタティック領域、ヒープ領域、スタック領域の違い。
・関数と変数のポインタ
・ポリモーフィズムとインターフェース
・コンパイル時リンクと、実行時リンクの違い
・GUIとCUIの最大の違い

262 ：

COBOLでいいじゃん

263 ：

たし算すら統一されてない言語のどこがいいんだ。

264 ：

ぶっちゃけ制作中だが宣伝してもいいかい？Ｃベースの図形言語なんだけど

265 ：

>>264
IDE言語統合厨がいるから、何でもいいから話を作ってくれ

266 ：

ぶっちゃけIDEのコード補完が重要なのは冗長な言語だけ
他は「あったら良いけど、無くても問題無い」レベル

267 ：

>>234
それ、型を宣言するのと何が違うん？
ああ、実行時に異なる変数を代入すれば違う型として扱えるってことか。
んでも、違う型になりえる変数を使うことにイマイチメリットが見いだせないなぁ。

268 ：

>>265
んじゃ、「12」っていうんだが・・・
http://d.hatena.ne.jp/programmingshape12/20121028/1351384322

269 ：

>>267
例えば、関数の引数なんかが何でも代入できたら便利って思わない？
でも、実行コードは、テンプレートと同じように膨れ上がるけど。

270 ：

それって只の多相型じゃん
静的型付け関数型言語なら大抵あるぞ
テンプレートのように実行コードが膨れ上がったりもしない

271 ：

テンプレート関数って、多相型あればいらなくね？

272 ：

>>269
> 例えば、関数の引数なんかが何でも代入できたら便利って思わない？
例えば、fooという関数があって、intとstringを引数に取れるとする。
それはfoo(int value)とfoo(string str)の２つの関数を定義するのと同じ事。
オーバーロードって呼ばれる機能のことね
君がそういう意図で書いたのではないということはわかっているが、
つまり、「関数の引数なんかが何でも代入できる」というのは
オーバーロードを備えている言語、Javaなども当てはまる。

273 ：

そう、オーバーロードやテンプレートで関数の引数は
なんでも代入できるってのは実装できる。
ここで比較するべきことは、
「オーバーロードやテンプレートを使ってなんでも代入できる」と
「型がないがゆえになんでも代入できる」の２つの違い。
型が違えば、処理もわずかながら違ってくる。
つまり、後者は引数に何が入っているかで処理を切り替えないといけなくなる。
そして想定外のものが入っている可能性もあるので、引数チェックも必要になる。
つまり、後者は劣った方式。

274 ：

Javaにはジェネリクスもあるのに
何でオーバーロードで例えるんだよ
ほんとに分かってんのか？

275 ：

型無しの変数だけ、型名にvarと宣言させれば、
オーバーロードと同時に使えるかもしれない

276 ：

メソッドのオーバーロードの話をしているのか
型システムでいう多相型の話をしているのか
（動的型付け言語で見られる）型の無い変数の話をしているのか

277 ：

多相型を予約語一つで実装しながら、オーバーロードも実装したいという話。

278 ：

多相型って、OCamlとかにあるアレのこと？
それともVBのVariantのこと？

279 ：

OCamlとかのアレのことです

280 ：

>>271
C++のtemplateは、
・クラスごとに実装を別に出来る
　(実装を別にしたくない場合は、templateでなくvirtual関数を駆使する)
・クラスだけでなく整定数ごとに別の実装を持てる
・再帰的に定義できる (コンパイル時に原始帰納関数が計算できる)
という特徴がある。
後者２つのせいでtemplate meta-programmingが炸裂した。

281 ：

多相型を実現する機能とメタプログラミングを実現する機能、
それぞれ分かれてる方が良いんじゃないかな

282 ：

>>277
型クラス

283 ：

多相とオーバーロードって
関数のエントリポイントが
同一か型ごとに分かれてるかの違いだろ？

284 ：

型推論しないなら、多相型とオーバーロードの共存も難しく無いよ

285 ：

＞273
そういうのはダックタイピングで対応できる。
完全には行かないけどね。

286 ：

C++のtemplate、メタプログラミングは発展途上だと思う。
もっと使い易くしてほしい。

287 ：

それはconceptでFA．

288 ：

ダックタイピングってインターフェースを
定義しないインターフェース。
型安全性をなくしたインターフェースなんだよね。

289 ：

いやインターフェイスだけを定義したといった方がいいだろ。
型安全がないから例外は必須だよね

290 ：2012/11/02

テンプレートもインターフェースも多用すると
マクロ展開多用したコードみたいになる。何事も
バランスというか節度は大切やね