未来の開発環境？ インタラクティブなプログラミング環境のデモが話題に 30
ストーリー by hylom
未来のVisual-Studio？ 部門より
未来のVisual-Studio？ 部門より
taraiok 曰く、
本家/.で「A Better Way To Program」と言うサイトの中にある「Inventing on Principle」と書かれた動画が話題だ。この1時間ほどの長い動画では、現在のプログラム言語の抱える問題を指摘している。動画では現在のプログラマが抱える縛りを解き放つには「interactive」、つまり双方向性を有したプログラム環境が必要だという。
プログラマーはコードを書き、それをコンパイルし、コンパイルが終わったら実行してデバッグを行うのが一般的だ。しかし、この動画中のプログラミング環境では、コードを書いて選択するとそのコードの行の上にスライダー（時間経過などを指定できる）などが現れる。スライダーを動かすとその場で書いたコードをリアルタイムに実行できるというものだ。このように、動画内の環境では直感的なインタフェースを使い、無駄な時間であるコンパイル無しで素早く動作確認ができる様子が見て取れる。
本家/.のコメントではこの環境は素晴らしいという意見もあれば、この開発ソフトのような仮想環境とコンパイルして実際のPC上で試すのとでは大きな違いがあるので実用性に課題があるといった意見などがある模様。
対話的？ (スコア:3, おもしろおかしい)
Re:対話的？ (スコア:3)
コンパイル？ (スコア:2)
> プログラマーはコードを書き、それをコンパイルし、コンパイルが終わったら実行してデバッグを行うのが一般的だ。
最近の言語や環境だといちいちコンパイル意識しないよね。
＃Visual Studioはコンパイル意識させられるところがイマイチ
Re: (スコア:0)
最近の言語って？
Re: (スコア:0)
きっと、とっても、みじかくて、早いんだよ。
わかってくださいよ
#ああ、デバッグ情報ONにすると最適化レベル下がってしまって遅くなってうまく動かなくなる
#ような仕事とは皆無なんですよきっと。
Re: (スコア:0)
確かに遅くなっただけでうまく動かなくなるようなコードを書くやっつけ仕事はしないな。
Re:コンパイル？ (スコア:1)
組み込みやっていると、CPU止めるとコイルが焼けたりしてたなあ。
なのでまずはバックグラウンドで動くモニタを作ったらICEはほぼ出番なし。
今はDSPが手軽に使えるんでメインCPUでサーボの制御なんてやらなくていいけど、バックグラウンドで動くモニタでのdebugが楽なので、実速度で動かしながらメモリやportをcheckするとか常用しますね。動的にオブジェクトを差し替えるなんてことはできないですけど。
Re: (スコア:0)
ICEなら当然のようにユーザプログラム実行中のメモリの読み書きができると思いますが。
本当に実時間で。
＃バックグラウンドで動くモニタといっても結局割り込みで動いているだけだから、その分実時間動作より遅くなってるはずだし。
Re: (スコア:0)
ICEでうっかりブレークしたら焼けるでしょ。
実時間と云っても定周期が重要で、フルスピードという意味ではない。
定周期内に処理が終われば、速度(=クロック)は遅くても良い。
CPUから観た実世界=人間ではなく、機械なのが組込み。
人間はイラつくくらいだけど、機械は焼けたり、ノイズになったり、空から落ちたりする。
#スラドでは組込みはITに含まれないってほんとだな。
Re: (スコア:0)
フィボナッチ数列がとてもエレガントに書ける言語の事でしょう。
ただし、みんな、フィボナッチ数列をエレガントに書けたことに満足し
それ以上の実用的なソフトウェアを作りたがらない・・・
オブジェクト (スコア:2)
動画つまみ見ですが、オブジェクトが目に見えるような存在なら十分に可能ですが、
そうでない抽象的なプログラミングにどう対応するんだろう。
全てを可視化し関係を図示するための手法を組み込んでいるというなら凄いですが。
#それってUML
一部の工業用のプロセスコントローラと似ていますね (スコア:2)
昭和の頃から、工業用のプロセスコントローラには、図形エディタでシンボル間に線を渡したりディスプレー上のダイアルでパラメータを変更したりするとリアルタイムに稼働中のプラントの制御に反映されるシステムがありました。
ハード的にはディスクリートで組んだマイクロシーケンサの集合体だったようです。
ある意味懐かしいかも (スコア:1)
もっと泥臭いやり方だったけど。
画像処理だとある (スコア:1)
少なくとも動画の最初、変更1回ごとの結果とかレイヤみたいなものは画像処理ソフトにある。
変更するとその行までの処理を再計算して表示してくれるし、レイヤみたいに表示もできる。
動画を見ると開発するときにパラメータ変更画面とかもプログラミングで作っていたのを
開発環境の中でできるようにしてくれってことでしょう。
パラメータ数が多い画像処理関数はいちいちコンパイルしてたら時間ばっかかかるし
こういうことが出来るようになるのは必然だったけど。
ゲーム開発には便利 (スコア:1)
ゲーム開発するときはこういうパラメータ調整をすることが頻繁にあるので、たいていはゲーム自体に調整するインターフェイスを実装して、テストプレイ時に適宜呼び出しながら調節するのが一般的かもしれませんね。その場合わざわざそうした実装をするのが手間ですが、IDE で提供してくれるのはとても便利ですね。動画後半の、キャラクターの一連の動きを表示して狭い隙間に入る微妙な調整をするデモも面白かったです。これもどこかのゲームエンジンが実装してくれないかな。ただしかなり高レベルなインターフェイスを強要することになるので、嫌がる開発者もいるかもしれませんけど。たぶんこれらは一般のソフトウェア開発に即座に応用できるものではないでしょうが、ゲームや映像製作では便利でしょうね。
この「開発環境のインターフェイスの改良」と、タレコミのいう「再コンパイルが面倒」という問題は別の概念ですね。Eclipse の Hotswap Bug Fixing でもリテラルや式を変更する位なら再起動しなくても反映してくれますから、とくに新しい概念でもありません。自分は強い型付けの言語のほうが好きですが、スクリプト言語に比べるとコンパイルが遅い(というかリンクがとにかく遅い)のがうんざりするので、最近は JavaScript も結構好きです。
Re:ゲーム開発には便利 (スコア:2)
例えばGAみたいに、ブン回す→１日後にグラフでトレンドを見てまたパラメータ調整→ブン回す→・・・というような話になると、
スライダの調節でトレンドを見ながらパラメータ調整できたら非常に有り難い話ですが、
スライダをちょいと右に動かすと、その結果を表示するのに数時間かかるみたいな。
こういうのって、CPUのパワーだけはどうにもならんですよね。
それってLISP? (スコア:0)
LISPとかSmalltalkとかFORTHとか‥‥‥‥
Re:それってLISP? (スコア:2)
当該ビデオもJavaScriptだったし似たようなものですか。
JavaScriptはSmallTalkの流れらしいし。
C/C++を始めとするコンパイルが必要な処理系でやるならC/C++インタープリタを
IDEに実装するということになるのかな。
C/C++で記述する処理は多岐に渡るので、こううまくいかないものも多そうだけど。
Break、ステップ実行で十分な気も。
とはいえ、CPUパワーはいくらでもある状況だから開発環境に贅沢するのも悪くはないか。
いまのIDEもずいぶん便利になりましたけど。
単体テストツール (スコア:0)
動画を見てないので的外れかもしれませんが、タレこみを読む限りは、GUIで操作可能な単体テストツールなのかな、と。
いまどきのIDEって単体テストの機能もあると思いますが、それらと比べてどれぐらい有用なのでしょうか。
Re: (スコア:0)
それはIDEの仕事じゃない。Frameworkの仕事だ。
パラメータを変更しながら行った内容を記録してテストコードに落としてくれるとかなら、これはIDEの仕事だ。
Re: (スコア:0)
動画には、プログラミングだけでなく、電子回路の挙動の確認や、フラッシュ的なアニメーションの作成などの、例が挙げられています。
思うに、彼が伝えたかったのは、単に新しいデバッガのを作ったということではなく、いかにコンピューターとの間を直感的にインタラクティブにするかに関する「コンセプト」の方だと思います。そして、そのコンセプトは、デバッグ作業を含むいろいろな局面で使えるっということだと理解しました。
Re: (スコア:0)
彼は最初から「Concept」という言葉を強調して、最期もその言葉で締めくくってますからね。
Re: (スコア:0)
失礼、彼が強調してたのは「Principle」（原理）という語でした。彼の提案している考え方が、非常に強力で、とても汎用性があるという、彼の主張がにじみ出ていますね。
なんだ (スコア:0)
マジックナンバー推奨？
いまだって (スコア:0)
十分インタラクティブだと思う、
好きな所で止められるし、好きな所まで進められるって普通のデバッガじゃないか、、
Re: (スコア:0)
好きなところでプログラムの書き換えはできないですけどね。
Re: (スコア:0)
Re: (スコア:0)
SwingをEclipseの上で動かしてると、小さな修正は実行中のものに適用される。
ほんとに小さなものだけだけど。
こういう場合、往々にして (スコア:0)
スライダーを動かした時の動作と、
実際にコンパイルした時の動作が違って頭抱えるわけですね、わかりますん。
現在の開発環境 (スコア:0)
プログラマーはコードを設計し、それをカードにパンチし、パンチが終わったら投入してデバッグを行うのが一般的だ。
しかし、この動画中のプログラミング環境では、コードを書くとそのコードに対応したバイナリデータ（最適化レベルなどを指定できる）を生成できる。バイナリデータをメモリに読み込むだけで書いたコードをリアルタイムに実行できるというものだ。
このように、動画内の環境では直感的なインタフェースを使い、無駄な時間であるカードパンチ無しで素早く動作確認ができる様子が見て取れる。