次世代のプログラミングを考える

2011年になっても車は車輪を付けたまま地面を走り、イルカは攻めてこなかった。

昔から変わらぬロジックの分離だの疎結合だのDRYだのという理想論はいまだに実現されず、
同じテーマの技法・フレームワーク・言語が手を変え品を変え作られ続けている。

「こんなこと位、自動でやってくれよ」と思いながら設定ファイルを書いたり、
「こんな作りじゃ、対応できねーじゃねぇか」と思いながら規約通りに作ったり、
「こう、パッと見てビュッとやったらポンと出来るのは…ないよな」と途方にくれる日々。

このスレでは我々が目指すべき、新たなプログラミングの地平線を
特にジャンルを設けず、全般的に考察していきたい。

そもそもチンパンジーとイルカは
ニッチが違うよね？

常日頃考えている点。

・GUIをベースとしたプログラミング
どのようなプロジェクトでも新規案件ならば企画があり、その際には業務フローの絵があるものである。
なぜこのフローをそのままシステムに落とし込めないのか忸怩たる思いがある。
基本設計段階ではまだしも実際のコーディングの現場ではifとforが入り乱れた、プリミティブなテキストに落とし込まれてしまい、もはやフローというダイアグラムはそこには存在しない。
そこでGUIによるプログラミングはもっと拡張されるべきだと考えている。BIツールを使っている人にはおなじみだろう。
しかし、いまだにこのようなツールは高価なBIツールか、ひどく制限された環境下でしか利用できない。
Mac OS XにはQuartz Composerというのがあるが、知っている方はあれを思い浮かべてもらえばいいだろう。
読んで分かるソースコードではなく、目で見て分かるソースコード。
これがキーワードではないかと考えている。

なお、COBOLならフローチャートからソースが生成できたと老害が言っていたが、勿論、そんなレベルの話ではない。

GUI でプログラミングと言うとこんな感じか

Yahoo! pipes

http://www.youtube.com/watch?v=bijSL5KR558

Scratch

http://www.youtube.com/watch?v=qFVg_zfc5Tg

裾野を広げるという意味では良いと思うけど、
テキストで書いた方が速いと思うわ

あとDBMSのスキーマレス化。
スキーマが定義されていることで、我々利用者が得をすることはほとんどない。
DBなんざ単なるストレージでしかないという認識なので、突っ込めるものはなんでも突っ込めるべきである。
これはオブジェクトリレーショナルインピーダンスミスマッチ解消という点で、
スキーマレスではなくオブジェクトDBへの転身であってもいいだろう。
テーブルの継承が出来ないことで作成される、似たようなテーブルの山、あるいはフラグ列の山はこれにより解消されるやもしれない。
性能は当然落ちるだろうが、そもそもRDBMSだって当初は遅い遅いと言われていたのだ。
Atomicに関しては譲歩出来ない場合が多いだろう。したがって、安易にNoSQLへの転換は出来ないし、NoSQLerのほとんどはRDBMSの代替ではないと宣言している。

某言語のように我々がプロパティのように宣言したものはプロパティになるべきであり、
DBにおいてはinsert intoで指定した列が増減していれば、そのように受け入れられるべきなのだ。
ただし、外部キーによる関係については何らかの考慮が必要だろう。
ドメインモデルは蜘蛛の巣のように張り巡らされることがあり、我々はそれをたどる必要があるからだ。

SQLは好きだが、オプティマイザのご機嫌を伺いながらクエリを書く、書かざるを得ないのは、本質的におかしい。

2011年になってもアイちゃんは半二足歩行です。

>>3
Windows Workflow Foundationでいいじゃないか

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

>>4
Yahooの方は知らなかった。ありがとう。
あとで見てみる。

＞裾野を広げるという意味では良いと思うけど、
＞テキストで書いた方が速いと思うわ
実際似たようなのがあるけど、WebのCRUDを考えた時、
GUIでDBのテーブル選択してページの絵に紐付けをすると、そのページからデータの参照が出来るみたいな。

これをもうちょっと高度にして動的に対象テーブルが変更出来ますとか、
アクションオブジェクト(今作った言葉)と紐付けて任意のロジック実行とかやると、
業務アプリでありがちな◯◯承認フローとかが簡単に出来る、と思う。
もう「承認がリジェクトされたら、どの状態だっけ？」とかロジック追わなくて済む。
まぁこんなのもクラスとメソッドxmlに書いて、実行時に判定・インスタンス化してメソッド実行とか実際にありますが。

裾野は自分より下だけじゃなく、自分の中にもあると思います。
自分のてっぺんから裾野までカバーされれば、それもいいと。
現状は僕の中ではモヤモヤした案でしかないですが。

Intellisenseでいいじゃないか

脳波で

>>3
自分もプログラムはグラフ表現するメリットがあるとおもってる
・一度に見渡せる範囲が広くなる
・コード断片相互の関係を把握しやすい

欠点は
・かならずしも二次元で見やすいとは限らない
・読みやすいノードを汎用的にデザインするのが難しい
だから既存のGUIプログラミングツールはノードやネットワーク構成が
単純なものが多い

コーディング操作がテキストほど容易ではないのは欠点にならないと考えている
なぜなら大半の時間はコーディングではなくデバッグに費やされるから。

>>5
オブジェクトDBは大昔からいろいろあるよ

UMLあたりを見るに
「プログラムを作ることは不可能ではないがプログラミングを継続するのは不可能」
というのがいくつもあり、チャート操作プログラミングは最たるものだと思う

仮想現実上で触って動かせる図形とかそういうブレイクスルーがない限り無理

>>12
君のデバッグは頻繁なコード書き作業を伴わないのか
そりゃ楽でいいなハハッ

サルがプログラミング

フルグラフ言語？は
gitとかでバージョン管理出来ないから無理

グラフ図形の同一判定や差分抽出は
NP完全じゃなかったっけ？

XMLやJSONみたいなストリームデータが基本で適宜グラフ表示＆編集できる
って程度ならいまの言語＋IDEと変わらない

>>17
そのフルグラフ言語？ではどういうデータ構造を想定してるの？
8bit時代のBASICみたく、メモリにロードした時はバイナリ、保存時にはASCIIみたいなのもアリだと思うけど。

>>18
グラフのデータ構造をどうこうしたところで
NP完全はどうのもならない

セーブしたテキストデータが異なるのに
グラフの相対的な接続は一緒である可能性を
排除できない

それを解析しようと頑張ると結局
確かNP完全になるんじゃなかったか
って話

グラフの構造をうまく制限すれば
回避出来ると思うけど
結局ダイクストラの構造化言語の
同等品にしかならないんじゃないか
ってのは俺のカンだけど

>>19
パラダイムシフトじゃなくて、エディタ側で見せ方を変えようってだけの話だから問題ないと思う。
IDEでGUIのコントロールをペタペタ貼るような感じ。

あと、グラフで表現されるプログラムは手続き型よりも関数型の方が親和性が高い。

エディタなんてどうでもいい。
コードやパラメータの表示にlと1の区別がつきやすく
0にスラッシュが入ってるフォントさえ使ってくれりゃ。
そんなことより明確にメモリをOS、プログラムエリアとデータエリアをわけるのはいつになったら実現するんだ？
15年経っても相変わらず不正な命令が実行される脆弱性におびえる未来なのか？

>>21
今のＰＣのアーキテクチャに限定すれば、
メモリ保護機構はCPUが80286のあたりからサポートされてるよ。

汎用的なデータ構造をどう定義するかが鍵となりそうだな
その場合、関数型よりＯＯＰの方が向いてる気がする

>>21
ハーバード アーキテクチャでググれ
組み込みではずっと前から在るわ

>>23
いや、データ構造は関数型言語の方が向いてる

オブジェクト指向言語はビューの部分を表現するのに向いてる

えっ！
OOPが次世代のプログラミングなの？

かつては

個人的には、オブジェクト指向関数型言語が、次世代になり得ると思ってるんだけど、ocamlもF#も、なんか違う

君が望むオブジェクト指向関数型言語というのは、
例えば何ができる言語なの？

事故って眠り続けても大丈夫

>>29
空想言語に何が出来るかって。。。
変な事を聞くね。。。

一応、windowプログラミングから、コマンドプログラミングまで一通り出来る事を妄想してる

敷いて言えば、c#ぐらいの用途を想定してる
それでいて、マルチスレッドが簡単・安全に作れて、F#より単純な文法

理想は、標準の文法がすでにマルチスレッドで動く様な、windowプログラミングをRAD(c#やvbみたいなIDE)で開発出来る関数型言語

>>31
すまん、訊き方がまずかった

では、>>31 のどの辺りが [オブジェクト指向] で、どの辺りが [関数型] なんだ？

>>32
空想言語にそこまでつっかかれる理由も無い気がするし、その質問も良い質問な気がしないんだけど。。。

GUI周りはオブジェクト指向
メソッドの中身は関数型言語

ってのが、ザックリした分け方かな

ocamlやf#が在るとおり、オブジェクト指向と関数型言語は、あい入れないものでは無いよ

RS232Cとか通信関連のことやればわかると思うけど、
手続型が必要な場面ってのもあるんだよね。

>>33
つっかかる分けじゃ無いよ
次世代のプログラミングを考えるスレなんだから、
次世代だと思っている人がいるオブジェクト指向関数型言語について考えてるだけ

相容れないなんて一言も言ってない
そもそもオブジェクト指向言語と関数型言語の融合は世界でまだ研究中で、
相容れないかどうか判断する材料があまりに少なすぎる


メソッドの中身は関数型言語というけど、
たとえば関数型言語の特徴である参照透過性は壊れないか？
壊してでも関数型っぽい表記を採用するメリットがあるのかな？

>>35
プログラム全体では参照透明性は崩れるでしょうが、メソッド単位で参照透明性を確保出来たら、メソッドからメソッドへの値の受け渡しで、参照透明性は無いけど、関数型言語のメリットを十分に享受出来るのでは？と考えてみたりしました

まずは何を解決したいのか、課題をはっきりさせるのが先かな。
1があげている、要件定義をソースコードに落とすのが面倒というのは良くわかる。
28が解きたい課題は良くわからない。

メソッド単位で参照透過性を確保するということは、
クラスのメンバー変数の値を直接書き換えることができないということじゃないか

参照透過性を確保したメソッドがメンバー変数の値を書き換えたかの様に見せかけるには、
参照透過性を確保したメソッドの戻り値として新しいオブジェクトを返す必要がある

つまり、C++ の演算子オーバーロードみたいな

と単純に考えてしまうんだが、なにか良い方法があるんだろうか

これまでのスレの流れでは、次世代言語より次世代IDEに未来を感じる

>>34
ところが、こういう記述には
宣言型の並列論理型言語のKL1なんかが
記述力では一番ということになるけど。

学術系の言語ってデバッグの効率無視されてたり習得が困難だったりイマイチ実用性に乏しい気がする

学術系言語ってカテゴリがいまいちよく分からんが、
それは自分が慣れてる学術系ではない言語のデバッグ環境を基に考えてるからじゃない？

学術系言語には学術系言語ならではのデバッグの考え方というものがあると思うよ
で、それはきっとデバッグだけじゃなくプログラミングそのものの考え方の違いでもあると思う

それはそうと、学術系言語というのは実用性よりもその学術的な研究を念頭に置いた言語じゃないの？
だったらイマイチ実用性に乏しいというのも、学術系言語の利用者から見れば
「お前何言ってるの、バカじゃない」と思われるんじゃないかと思うんだが・・・

で、学術系言語って何？

>>42
Haskellとかじゃね？
学者さんの論理実証のためのものってイメージで実用でない言語って他にもありそう。

学者さんの論理実証でなんで Haskell なんだ？

>>44
わからないんなら割って入ってくんな

>>44 は次世代のプログラミングを考えるスレにおいて
>>43 が単なるイメージ「だけ」で論理実証とかいう言葉と Haskell を結びつけているのか、
それとも意味があって結びつけているのかを試している

具体的に、どのような理論の実証を Haskell でやっているのか訊きたい
そしてそれが、Haskell が学術系言語と言うに相応しいほど一般的なのか

代わりに >>45 が解説してくれるのなら、してくれ

Haskell は確かに色々な用途で使えるからそういう用途もあるだろうとは思う
ただ、Haskell を何らかの理論を実証するためのものと位置づけている学者より、
それ以外の用途（事務処理や趣味など）と位置づけている人間の方が圧倒的に多いぞ

そもそも、Haskell は実用的なプログラミング ツールとして開発された言語であり
（http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/）
その理念・目的は今も変わっていないし、そのような方向に向けて進化させようとしている

>>46
>Haskell は実用的なプログラミング ツールとして開発された言語であり

論理学者が「実用的でエレガントなコードとはどうあるべきか」を実証するため作った言語だろ。
その後のブラッシュアップで実用になった。
言語の多くはプログラム言語の研究家や論理学者さんの考えた「ぼくのかんがえたりそうのげんご」に端を発してる側面がある。

ためさせて

test

オイラおっきくなったらT言語をつくるんだ

はいはいゴミゴミ
今日は燃えるゴミの日だな


放射性廃棄物のほうがマシ

＞＞＞＞ その理念・目的は今も変わっていないし、そのような方向に向けて進化させようとしている
ハッアアァァァァアァァァァァアァアァァァァァァァァァァァァアァアァァア？?？？？
ゴミグラマは社会底辺
死ねよゴミ
でもお前はゴミなんだけどねｗ



ゴミに何を言われても

これ ； デリミタっていうんだけどさ、これをつけなきゃエラーになるような
そんな言語使ってる奴ってどうみてもゴミだと思うんだけど

もしかして「；」これ打ち忘れてコンパイルエラー出すのが楽しいの？
そうか、二度と話かけんなよ
しねよ

今作れよ

カ　オ　ス　ラ　ウ　ン　ジ　ゆ　る　せ　な　ぁ　い　ー

>>1
BIツールの例と、目で見て分かるソースコードというキーワードから
UMLとUMLからコード生成が可能な開発環境が浮かぶけど、
↓みたいな事できたら良いのにね。

まず、UMLは「目で見て分かるコード」として使えなさそう。
・UMLが提供する表現はチューリング完全ではない。
・チューリング完全ではないということは、計算機上の処理と等価な記述がUMLにできない。

なので、UMLを「目で見て分かるコード」として使える仕様に拡張する。
・UMLをチューリング完全な表現が出来る仕様に拡張する。
・etc...その他必要な概念は学者にお任せ。

次に、あらゆる要件を構成し得る最小要件のグラフィカルな表現方法を仕様化する。
・最小要件は、UML++の組み合わせで表現される。
・最小要件は抽象的である。（抽象クラスやインタフェース的）
・その他必要な概念は学者にお任せ。

開発者は、以下を行う。
・最小要件のグラフィカルな表現を組み合わせて要件のカタマリを作り上げる。
・要件のカタマリはそのままでは抽象物なので、実データ（パラメタ）を与えて具体化(実現)する。
・Build！要件のカタマリはUML++集に落とされ、UML++集は実行ファイルに翻訳される。


処理(=命令n+値n)〜図(=処理n)〜要件(=図n)が等価に相互変換できて、
かつ要件がグラフィカルに表現できれば1の言う事は出来そうだけど、
どこかで何か決定的な数学・情報科学的なネックがあるんだろうな。

LispでいいよLispで

>>1
scratchはまだ言語のタイプ(そもそもコード書かないから言語じゃないかも)はjavaScriptと同じプロトタイプベースだが、良い線行ってるよ

デバッグし易くして、実行ファイル吐けるようになって、外部とのファイルのやりとりを出来るようになれば、vb位は駆逐出来るかも知れん

子供向けだと思ってたら、以外と言語としても(コード書かないけど)しっかりしてた

新しい言語が出てくる度にlispでいいや。って気持ちにさせられる
jvmで動くANSI準拠のcommon lispが生まれたら、
次世代のプログラミング言語開発なんて停滞しそうなもんなのに

本気でそう思ってるのか

余計なお世話かも知れんが、もっと色んな言語の作られた理由や経緯や理念、
実現方法（実現できたこと、諦めたこと）などを知った方がいいと思う

あと、好みの問題も大いにあるから、その程度の事では
次世代のプログラミング言語開発が停滞することは絶対にない、誓ってもいい

試しに、jvmで動くANSI準拠のcommon lispとやらを作ってみたらどうだ？

言語の作られた理念や実現法ってどこで見れるの？
pdfで論文になってたりするもんなの？

Haskell なら pdf になってる
http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/index.htm

英語が聞き取れるのなら、ついでに video も見てみるといい

>>5で言ってることは↓のが有効そうに思える。
ttp://www.cellulardatasystem.com/about/index.html

Haskell はHaskellで書かれたDarcsを捨てた時点で、見捨てた

義理を欠く言語は任侠道に反する