次世代のプログラミングを考える
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2011/04/08(金) 01:48:28.60昔から変わらぬロジックの分離だの疎結合だのDRYだのという理想論はいまだに実現されず、
同じテーマの技法・フレームワーク・言語が手を変え品を変え作られ続けている。
「こんなこと位、自動でやってくれよ」と思いながら設定ファイルを書いたり、
「こんな作りじゃ、対応できねーじゃねぇか」と思いながら規約通りに作ったり、
「こう、パッと見てビュッとやったらポンと出来るのは…ないよな」と途方にくれる日々。
このスレでは我々が目指すべき、新たなプログラミングの地平線を
特にジャンルを設けず、全般的に考察していきたい。
0002デフォルトの名無しさん
2011/04/08(金) 01:53:14.48ニッチが違うよね？
00031
2011/04/08(金) 02:20:42.53・GUIをベースとしたプログラミング
どのようなプロジェクトでも新規案件ならば企画があり、その際には業務フローの絵があるものである。
なぜこのフローをそのままシステムに落とし込めないのか忸怩たる思いがある。
基本設計段階ではまだしも実際のコーディングの現場ではifとforが入り乱れた、プリミティブなテキストに落とし込まれてしまい、もはやフローというダイアグラムはそこには存在しない。
そこでGUIによるプログラミングはもっと拡張されるべきだと考えている。BIツールを使っている人にはおなじみだろう。
しかし、いまだにこのようなツールは高価なBIツールか、ひどく制限された環境下でしか利用できない。
Mac OS XにはQuartz Composerというのがあるが、知っている方はあれを思い浮かべてもらえばいいだろう。
読んで分かるソースコードではなく、目で見て分かるソースコード。
これがキーワードではないかと考えている。
なお、COBOLならフローチャートからソースが生成できたと老害が言っていたが、勿論、そんなレベルの話ではない。
0004デフォルトの名無しさん
2011/04/08(金) 02:39:36.24Yahoo! pipes
http://www.youtube.com/watch?v=bijSL5KR558
Scratch
http://www.youtube.com/watch?v=qFVg_zfc5Tg
裾野を広げるという意味では良いと思うけど、
テキストで書いた方が速いと思うわ
00051
2011/04/08(金) 02:41:28.52スキーマが定義されていることで、我々利用者が得をすることはほとんどない。
DBなんざ単なるストレージでしかないという認識なので、突っ込めるものはなんでも突っ込めるべきである。
これはオブジェクトリレーショナルインピーダンスミスマッチ解消という点で、
スキーマレスではなくオブジェクトDBへの転身であってもいいだろう。
テーブルの継承が出来ないことで作成される、似たようなテーブルの山、あるいはフラグ列の山はこれにより解消されるやもしれない。
性能は当然落ちるだろうが、そもそもRDBMSだって当初は遅い遅いと言われていたのだ。
Atomicに関しては譲歩出来ない場合が多いだろう。したがって、安易にNoSQLへの転換は出来ないし、NoSQLerのほとんどはRDBMSの代替ではないと宣言している。
某言語のように我々がプロパティのように宣言したものはプロパティになるべきであり、
DBにおいてはinsert intoで指定した列が増減していれば、そのように受け入れられるべきなのだ。
ただし、外部キーによる関係については何らかの考慮が必要だろう。
ドメインモデルは蜘蛛の巣のように張り巡らされることがあり、我々はそれをたどる必要があるからだ。
SQLは好きだが、オプティマイザのご機嫌を伺いながらクエリを書く、書かざるを得ないのは、本質的におかしい。
0006デフォルトの名無しさん
2011/04/08(金) 02:48:04.540007デフォルトの名無しさん
2011/04/08(金) 02:50:06.76Windows Workflow Foundationでいいじゃないか
0008デフォルトの名無しさん
2011/04/08(金) 03:14:24.31言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
00091
2011/04/08(金) 03:16:02.53Yahooの方は知らなかった。ありがとう。
あとで見てみる。
＞裾野を広げるという意味では良いと思うけど、
＞テキストで書いた方が速いと思うわ
実際似たようなのがあるけど、WebのCRUDを考えた時、
GUIでDBのテーブル選択してページの絵に紐付けをすると、そのページからデータの参照が出来るみたいな。
これをもうちょっと高度にして動的に対象テーブルが変更出来ますとか、
アクションオブジェクト(今作った言葉)と紐付けて任意のロジック実行とかやると、
業務アプリでありがちな◯◯承認フローとかが簡単に出来る、と思う。
もう「承認がリジェクトされたら、どの状態だっけ？」とかロジック追わなくて済む。
まぁこんなのもクラスとメソッドxmlに書いて、実行時に判定・インスタンス化してメソッド実行とか実際にありますが。
裾野は自分より下だけじゃなく、自分の中にもあると思います。
自分のてっぺんから裾野までカバーされれば、それもいいと。
現状は僕の中ではモヤモヤした案でしかないですが。
0010デフォルトの名無しさん
2011/04/08(金) 08:49:27.480011デフォルトの名無しさん
2011/04/08(金) 10:31:54.260012デフォルトの名無しさん
2011/04/08(金) 11:48:34.25自分もプログラムはグラフ表現するメリットがあるとおもってる
・一度に見渡せる範囲が広くなる
・コード断片相互の関係を把握しやすい
欠点は
・かならずしも二次元で見やすいとは限らない
・読みやすいノードを汎用的にデザインするのが難しい
だから既存のGUIプログラミングツールはノードやネットワーク構成が
単純なものが多い
コーディング操作がテキストほど容易ではないのは欠点にならないと考えている
なぜなら大半の時間はコーディングではなくデバッグに費やされるから。
0013デフォルトの名無しさん
2011/04/08(金) 11:49:22.02オブジェクトDBは大昔からいろいろあるよ
0014デフォルトの名無しさん
2011/04/08(金) 12:23:27.49「プログラムを作ることは不可能ではないがプログラミングを継続するのは不可能」
というのがいくつもあり、チャート操作プログラミングは最たるものだと思う
仮想現実上で触って動かせる図形とかそういうブレイクスルーがない限り無理
0015デフォルトの名無しさん
2011/04/08(金) 12:27:04.23君のデバッグは頻繁なコード書き作業を伴わないのか
そりゃ楽でいいなハハッ
0016デフォルトの名無しさん
2011/04/08(金) 13:18:00.240017デフォルトの名無しさん
2011/04/08(金) 20:18:46.99gitとかでバージョン管理出来ないから無理
グラフ図形の同一判定や差分抽出は
NP完全じゃなかったっけ？
XMLやJSONみたいなストリームデータが基本で適宜グラフ表示＆編集できる
って程度ならいまの言語＋IDEと変わらない
0018デフォルトの名無しさん
2011/04/08(金) 20:26:15.63そのフルグラフ言語？ではどういうデータ構造を想定してるの？
8bit時代のBASICみたく、メモリにロードした時はバイナリ、保存時にはASCIIみたいなのもアリだと思うけど。
0019デフォルトの名無しさん
2011/04/08(金) 20:48:54.66グラフのデータ構造をどうこうしたところで
NP完全はどうのもならない
セーブしたテキストデータが異なるのに
グラフの相対的な接続は一緒である可能性を
排除できない
それを解析しようと頑張ると結局
確かNP完全になるんじゃなかったか
って話
グラフの構造をうまく制限すれば
回避出来ると思うけど
結局ダイクストラの構造化言語の
同等品にしかならないんじゃないか
ってのは俺のカンだけど
0020デフォルトの名無しさん
2011/04/08(金) 22:27:21.38パラダイムシフトじゃなくて、エディタ側で見せ方を変えようってだけの話だから問題ないと思う。
IDEでGUIのコントロールをペタペタ貼るような感じ。
あと、グラフで表現されるプログラムは手続き型よりも関数型の方が親和性が高い。
0021デフォルトの名無しさん
2011/04/09(土) 00:50:44.49コードやパラメータの表示にlと1の区別がつきやすく
0にスラッシュが入ってるフォントさえ使ってくれりゃ。
そんなことより明確にメモリをOS、プログラムエリアとデータエリアをわけるのはいつになったら実現するんだ？
15年経っても相変わらず不正な命令が実行される脆弱性におびえる未来なのか？
0022デフォルトの名無しさん
2011/04/09(土) 13:25:12.02今のＰＣのアーキテクチャに限定すれば、
メモリ保護機構はCPUが80286のあたりからサポートされてるよ。
0023デフォルトの名無しさん
2011/04/09(土) 13:34:02.53その場合、関数型よりＯＯＰの方が向いてる気がする
0024デフォルトの名無しさん
2011/04/09(土) 13:36:35.54ハーバード アーキテクチャでググれ
組み込みではずっと前から在るわ
0025デフォルトの名無しさん
2011/04/09(土) 13:39:01.77いや、データ構造は関数型言語の方が向いてる
オブジェクト指向言語はビューの部分を表現するのに向いてる
0026デフォルトの名無しさん
2011/04/09(土) 20:45:36.27OOPが次世代のプログラミングなの？
0027デフォルトの名無しさん
2011/04/09(土) 21:06:08.010028デフォルトの名無しさん
2011/04/09(土) 21:10:38.350029デフォルトの名無しさん
2011/04/09(土) 21:12:50.77例えば何ができる言語なの？
0030デフォルトの名無しさん
2011/04/09(土) 21:30:49.710031デフォルトの名無しさん
2011/04/09(土) 21:54:39.68空想言語に何が出来るかって。。。
変な事を聞くね。。。
一応、windowプログラミングから、コマンドプログラミングまで一通り出来る事を妄想してる
敷いて言えば、c#ぐらいの用途を想定してる
それでいて、マルチスレッドが簡単・安全に作れて、F#より単純な文法
理想は、標準の文法がすでにマルチスレッドで動く様な、windowプログラミングをRAD(c#やvbみたいなIDE)で開発出来る関数型言語
0032デフォルトの名無しさん
2011/04/09(土) 22:30:26.79すまん、訊き方がまずかった
では、>>31 のどの辺りが [オブジェクト指向] で、どの辺りが [関数型] なんだ？
0033デフォルトの名無しさん
2011/04/09(土) 22:41:50.54空想言語にそこまでつっかかれる理由も無い気がするし、その質問も良い質問な気がしないんだけど。。。
GUI周りはオブジェクト指向
メソッドの中身は関数型言語
ってのが、ザックリした分け方かな
ocamlやf#が在るとおり、オブジェクト指向と関数型言語は、あい入れないものでは無いよ
0034デフォルトの名無しさん
2011/04/09(土) 23:03:50.71手続型が必要な場面ってのもあるんだよね。
0035デフォルトの名無しさん
2011/04/09(土) 23:07:12.66つっかかる分けじゃ無いよ
次世代のプログラミングを考えるスレなんだから、
次世代だと思っている人がいるオブジェクト指向関数型言語について考えてるだけ
相容れないなんて一言も言ってない
そもそもオブジェクト指向言語と関数型言語の融合は世界でまだ研究中で、
相容れないかどうか判断する材料があまりに少なすぎる
メソッドの中身は関数型言語というけど、
たとえば関数型言語の特徴である参照透過性は壊れないか？
壊してでも関数型っぽい表記を採用するメリットがあるのかな？
0036デフォルトの名無しさん
2011/04/09(土) 23:22:37.51プログラム全体では参照透明性は崩れるでしょうが、メソッド単位で参照透明性を確保出来たら、メソッドからメソッドへの値の受け渡しで、参照透明性は無いけど、関数型言語のメリットを十分に享受出来るのでは？と考えてみたりしました
0037デフォルトの名無しさん
2011/04/09(土) 23:30:20.141があげている、要件定義をソースコードに落とすのが面倒というのは良くわかる。
28が解きたい課題は良くわからない。
0038デフォルトの名無しさん
2011/04/09(土) 23:36:23.53クラスのメンバー変数の値を直接書き換えることができないということじゃないか
参照透過性を確保したメソッドがメンバー変数の値を書き換えたかの様に見せかけるには、
参照透過性を確保したメソッドの戻り値として新しいオブジェクトを返す必要がある
つまり、C++ の演算子オーバーロードみたいな
と単純に考えてしまうんだが、なにか良い方法があるんだろうか
0039デフォルトの名無しさん
2011/04/09(土) 23:44:05.400040デフォルトの名無しさん
2011/04/10(日) 05:15:42.71ところが、こういう記述には
宣言型の並列論理型言語のKL1なんかが
記述力では一番ということになるけど。
0041デフォルトの名無しさん
2011/04/11(月) 12:25:45.720042デフォルトの名無しさん
2011/04/11(月) 12:52:16.90それは自分が慣れてる学術系ではない言語のデバッグ環境を基に考えてるからじゃない？
学術系言語には学術系言語ならではのデバッグの考え方というものがあると思うよ
で、それはきっとデバッグだけじゃなくプログラミングそのものの考え方の違いでもあると思う
それはそうと、学術系言語というのは実用性よりもその学術的な研究を念頭に置いた言語じゃないの？
だったらイマイチ実用性に乏しいというのも、学術系言語の利用者から見れば
「お前何言ってるの、バカじゃない」と思われるんじゃないかと思うんだが・・・
で、学術系言語って何？
0043デフォルトの名無しさん
2011/04/11(月) 13:46:39.19Haskellとかじゃね？
学者さんの論理実証のためのものってイメージで実用でない言語って他にもありそう。
0044デフォルトの名無しさん
2011/04/11(月) 18:06:16.320045デフォルトの名無しさん
2011/04/11(月) 22:47:21.74わからないんなら割って入ってくんな
0046デフォルトの名無しさん
2011/04/12(火) 07:42:54.89>>43 が単なるイメージ「だけ」で論理実証とかいう言葉と Haskell を結びつけているのか、
それとも意味があって結びつけているのかを試している
具体的に、どのような理論の実証を Haskell でやっているのか訊きたい
そしてそれが、Haskell が学術系言語と言うに相応しいほど一般的なのか
代わりに >>45 が解説してくれるのなら、してくれ
Haskell は確かに色々な用途で使えるからそういう用途もあるだろうとは思う
ただ、Haskell を何らかの理論を実証するためのものと位置づけている学者より、
それ以外の用途（事務処理や趣味など）と位置づけている人間の方が圧倒的に多いぞ
そもそも、Haskell は実用的なプログラミング ツールとして開発された言語であり
（http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/）
その理念・目的は今も変わっていないし、そのような方向に向けて進化させようとしている
0047デフォルトの名無しさん
2011/04/12(火) 08:45:30.11>Haskell は実用的なプログラミング ツールとして開発された言語であり
論理学者が「実用的でエレガントなコードとはどうあるべきか」を実証するため作った言語だろ。
その後のブラッシュアップで実用になった。
言語の多くはプログラム言語の研究家や論理学者さんの考えた「ぼくのかんがえたりそうのげんご」に端を発してる側面がある。
0049デフォルトの名無しさん
2011/05/29(日) 11:18:30.360050デフォルトの名無しさん
2011/06/09(木) 10:20:02.790051天使 ◆uL5esZLBSE
2011/07/02(土) 14:23:53.90今日は燃えるゴミの日だな
放射性廃棄物のほうがマシ
0052天使 ◆uL5esZLBSE
2011/07/03(日) 05:22:49.79ハッアアァァァァアァァァァァアァアァァァァァァァァァァァァアァアァァア？?？？？
ゴミグラマは社会底辺
死ねよゴミ
でもお前はゴミなんだけどねｗ
ゴミに何を言われても
0053天使 ◆uL5esZLBSE
2011/07/04(月) 19:18:02.32そんな言語使ってる奴ってどうみてもゴミだと思うんだけど
もしかして「；」これ打ち忘れてコンパイルエラー出すのが楽しいの？
そうか、二度と話かけんなよ
しねよ
0054デフォルトの名無しさん
2011/07/04(月) 20:54:19.750055ななし。
2011/07/27(水) 16:20:31.110056デフォルトの名無しさん
2011/07/28(木) 01:34:30.42BIツールの例と、目で見て分かるソースコードというキーワードから
UMLとUMLからコード生成が可能な開発環境が浮かぶけど、
↓みたいな事できたら良いのにね。
まず、UMLは「目で見て分かるコード」として使えなさそう。
・UMLが提供する表現はチューリング完全ではない。
・チューリング完全ではないということは、計算機上の処理と等価な記述がUMLにできない。
なので、UMLを「目で見て分かるコード」として使える仕様に拡張する。
・UMLをチューリング完全な表現が出来る仕様に拡張する。
・etc...その他必要な概念は学者にお任せ。
次に、あらゆる要件を構成し得る最小要件のグラフィカルな表現方法を仕様化する。
・最小要件は、UML++の組み合わせで表現される。
・最小要件は抽象的である。（抽象クラスやインタフェース的）
・その他必要な概念は学者にお任せ。
開発者は、以下を行う。
・最小要件のグラフィカルな表現を組み合わせて要件のカタマリを作り上げる。
・要件のカタマリはそのままでは抽象物なので、実データ（パラメタ）を与えて具体化(実現)する。
・Build！要件のカタマリはUML++集に落とされ、UML++集は実行ファイルに翻訳される。
処理(=命令n+値n)〜図(=処理n)〜要件(=図n)が等価に相互変換できて、
かつ要件がグラフィカルに表現できれば1の言う事は出来そうだけど、
どこかで何か決定的な数学・情報科学的なネックがあるんだろうな。
0057デフォルトの名無しさん
2011/07/28(木) 16:36:46.530058デフォルトの名無しさん
2011/07/30(土) 01:44:52.23scratchはまだ言語のタイプ(そもそもコード書かないから言語じゃないかも)はjavaScriptと同じプロトタイプベースだが、良い線行ってるよ
デバッグし易くして、実行ファイル吐けるようになって、外部とのファイルのやりとりを出来るようになれば、vb位は駆逐出来るかも知れん
子供向けだと思ってたら、以外と言語としても(コード書かないけど)しっかりしてた
0059デフォルトの名無しさん
2011/08/03(水) 00:57:44.90jvmで動くANSI準拠のcommon lispが生まれたら、
次世代のプログラミング言語開発なんて停滞しそうなもんなのに
0060デフォルトの名無しさん
2011/08/03(水) 07:24:24.47余計なお世話かも知れんが、もっと色んな言語の作られた理由や経緯や理念、
実現方法（実現できたこと、諦めたこと）などを知った方がいいと思う
あと、好みの問題も大いにあるから、その程度の事では
次世代のプログラミング言語開発が停滞することは絶対にない、誓ってもいい
試しに、jvmで動くANSI準拠のcommon lispとやらを作ってみたらどうだ？
0061デフォルトの名無しさん
2011/08/03(水) 21:08:01.62pdfで論文になってたりするもんなの？
0062デフォルトの名無しさん
2011/08/03(水) 21:21:30.39http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/index.htm
英語が聞き取れるのなら、ついでに video も見てみるといい
0063デフォルトの名無しさん
2011/12/15(木) 11:12:45.68ttp://www.cellulardatasystem.com/about/index.html
0064デフォルトの名無しさん
2011/12/17(土) 02:19:24.54義理を欠く言語は任侠道に反する
■ このスレッドは過去ログ倉庫に格納されています