Code Bubblesについて言及しているこの質問を読み、彼らのビデオ プレゼンテーションを見ました。
ビデオは印象的で、少し未来的に見えますが、どうやらそれはやや現実的です.
しかし、それで私は考え続けました...開発者は本当にそのようなツールを使用するでしょうか?
私たちは開発者として、コードファイルを扱い、それらをディレクトリに整理し、何らかの方法で、いくつかの一般的なIDE（それらを持つ言語用）に慣れています。
彼らが提案するように、Code Bubbles のようなものを使用することは大きな飛躍になるでしょう。
個人的には、そのような環境で仕事ができるかどうかはわかりません... ただ、調整が必要だとは思いますが.
これについてどう思いますか？
私はハートビートでそれを使用します。とにかく常にそのように働きたいと思っています。
最初に作成するときは、ディレクトリ構造の観点からのみ物事を考えます。その後は、ファイルではなく、常に一連の思考で作業したいと考えています。
C# や Java など、コード ファイルとブロック (メソッドなど) の実際の構成がかなり厳密である言語 (C# よりも Java の方がより厳密) の場合、コードの斬新な「ビュー」を提供する何かが機能する可能性があります。ファイルごとに 1 つのクラス、可視性によって並べ替えられたメソッド、または任意のコーディング標準を使用して、ツールがコードを整理できるようにすることができます。 " ファイルを作成し、すべてを理解します。
基本的に好きなことを何でもできるC++のような言語では問題になるでしょう...
このように考えてください...もっと簡単なこと：
（1.）相互に呼び出された一連の関数をすべて1つの同時ビューで表示できるコードバブルを作成する
-また-
（2.）単一のテキストエディタで、6つまたは7つのソースコードファイルにまたがって、これらの関数間を常にタブで移動しますか？
コードバブルを使用しますか？MSが今後数年間で同等のVSを出さなければ、私は突然Java開発者になることに非常に強い関心を抱くかもしれません。
とても革新的なコンセプトだと思いました。試してみるのが待ちきれません!
コードが保存されているファイルとは別にコードを表示するという素晴らしいアイデアとは別に、私が最も興味深いと思ったのは、バブル レイアウトのミニチュアを表示し、「デスクトップ」を即座にスクロールまたは配置できる「ミニマップ」のようなバーでした。 「特定の領域で。
これが、オペレーティング システム レベルで仮想デスクトップを実装する方法です。
興味のある方のために説明すると、Microsoft Research は Visual Studio についても同様のことを行っています。コードキャンバスといいます。
詳細については、次のビデオを参照してください: http://blogs.msdn.com/b/kaelr/archive/2009/03/26/code-canvas.aspx
元の質問に関しては、Code Bubbles について知ってすぐにベータ版にサインアップしました。良いアイデアがたくさんあると思いますので、試してみたいと思います。彼らが主張するほど有用ではないことが判明したとしても、これらの概念のいくつかは、多くのプログラマーによって使用されるように進化すると確信しています.
本物のプログラマーはテキスト エディターを使用します。:)
Code Bubbles は好きですが、切り替えるには新しい GUI よりもはるかに多くのことが必要です。
コード バブルをリンクしてグループとして移動するというアイデアは、少しばかげているように思われ、ほとんどの実際のシナリオでは役に立たないでしょう。
ただし、すべてのプログラマーは、ファイル内の行として (あまり目立たない) スペースを占めるのではなく、アプリケーションが画面上のスペースを占めることをグラフィカルに確認するのに十分役立つと思います。それだけでも、プログラミング環境としてではなくても、プレゼンツールとしては重宝すると思います。
私は間違いなくそれをダウンロードして、利用可能になったらそれを使用しようとします. これは、デバッグ、コード レビュー、および一部の種類の開発を高速化できる優れたアイデアのように見えます。また、コード バブルの FAQ では、ファイル全体をスクロール可能な大きなバブルとして表示することをサポートしていると述べています。
おそらく私が頭に浮かんだ最大の問題は、Java 以外はサポートされていないと思うことです。私はほとんどの時間を C で過ごしました。彼らがこのアイデアを本当に成功させたいのであれば、複数言語のサポートは不可欠です。
Code Bubbles は、プログラミングだけでなく、GUI デスクトップ メタファー全体のアイデアを開くと思います。
私たちが行うことの多くは階層的です。プロジェクト文書を書くことを想像してみてください。見出しはありますか？小見出し？目次 (ToC) を作成し、各見出し/小見出しをクリックして、コンテンツを配置する別のウィンドウを取得することを想像してください。異なるバブルで同時に複数のサブセクションを開くことができます。最新のワード プロセッサを画面分割して同じことを行うことはいつでもできますが、アプリに頼るのではなく、パーツを別のウィンドウに移動して、自分の好きなように配置できるようにしたいと考えています。サブウィンドウを「並べて表示」します。Code-Bubbles-as-desktop はそれを可能にします。
そのドキュメントで共同作業を行っていると想像してください。ToC の小見出しをクリックして、作業を開始します。他の誰かが別のものをクリックして、作業を開始します。従来のロックを使用して、他の誰かが自分の作業を台無しにすることを回避できます。また、その逆も同様です。はい、EtherPad については知っています。私はそれを使用しました。それは私を夢中にさせます。
私は wiki ベースのドキュメント/プログラム構成システムを作ることを考えていました。このシステムでは、メイン ドキュメントに見出しを作成し、それぞれがそれらの見出しの実際のコンテンツにリンクしています。さまざまなパーツがさまざまなウィンドウに表示されるので、必要に応じて配置できます。Code-Bubbles-as-desktop は、間違いなく、より洗練されたソリューションです。
明らかに、これはプログラミングで行うことができます。なぜなら、プログラムは複雑で非常に正確なドキュメントにすぎず、非常に細かい対象者を対象としているためです。通常、プログラムは非常に階層的です。現状では、プログラミングをするときは Vim か Eclipse のどちらかを使用しています。両方とも、私が見ていないコードのセクションを「折りたたむ」機能を備えているため、高レベルの概要と実際のコードが混在しています。メソッド定義を示す 1 つのバブルと、メソッドの内容を含む他のバブルを作成することにより、コード バブルでも同じことが実現されます。それらはすべて、コンパイラーに供給する前に「織り戻され」ます。
また、私がプログラミングしているときは、通常、コメントに高レベルの疑似コードを入れてメソッドまたは関数を「具体化」し、次に疑似コードの各部分を実装するプログラム コードを調べて埋めます。これらの疑似コード コメントは、実際のコードを保持するためにバブルを開く ToC ピースを提供できます。システムは、これらの断片をメイン ドキュメントに「織り込む」必要があります。使用しているプログラミング言語に関係なく、それは機能します。
リテレート プログラミングに対する私の関心は、十分明確に伝わりますか?
これを次のレベルに進めましょう。タブレットまたはネットブックを使用しています。作業する画面の領域が大幅に少なくなります。ああ、それを見てください。泡はすべて比較的小さいです。上部の「コンテキスト バー」を使用して、探しているバブルを見つけます。バブルが画面を占有する可能性があります。これで、サイズに制約のある小型のデバイスで動作するドキュメント (プログラムを含む) を作成する方法が得られました。
おそらく希望的観測かもしれませんが、これはプログラミングだけでなく、GUI 全体にとって重要な新しいパラダイムになる可能性があると考えています。私は確かにそれを使用します。
見た目はいいと思いますが、コードをデバッグ/ステップインするときはもっと便利だと思います。IDE でコード ファイル全体を開かずに、小さなコード バブルを作成するだけで、ちょっとクールです。
絶対！ファイル構造はバブル ビューに影響しないため、技術的には従来の手段を使用してプロジェクトのソース ファイルを整理できます。これが本当に役立つのは、すでに確立されたコードをナビゲートする場合です。他の人のコードを学ぶために必要です。また、多くの小さくて簡潔なオブジェクトや関数など、コードをきれいに保つのにも役立ちます。
ワークフローへの変更（したがって、事前の学習曲線）は、最初に表示されるほど大きくはないと思います。Eclipseを（適切に）使用している場合は、Open Type（名前で）、Open Call Hierarchy、オープンタイプ階層、オープン宣言など。折りたたまれたコードブロックも、コードバブルの前兆のようです。
私はCodekaに同意します。これは、Javaのような「厳密に編成された」言語でのみ機能し、Perlのような言語ではうまく機能しないため、プログラマーが物事をどのように配置したいかを自由にできます（ツールサポートを犠牲にして）期待できます）。
デモからの私の印象は、そのアプローチが大規模なプログラムにどのように役立つかを理解できるということでした. しかし、生計を立てるためにプログラミングを行ってきた 14 年間で、それほど大きなプログラムを作成したのは 1 回だけです (さらに 2 回継承しました)。
それは私が 22 歳のときで、引退するまでの 6 年間、モノリシックにしていたことを後悔しました。私以外の誰も本当にすべてを理解していなかったので、それは絶え間ないメンテナンスの問題でした.
長期的に使い続けるかどうかはわかりませんが、その環境で数か月働きたいと思っています。
ここには、非常に興味深い GUI のアイデアがいくつかあります。これは刺激的なビデオです。
私は常に自分の IDE を使用して開発し、机の上にいくつかの書類を置き、さまざまなスニペットとコード/ソフトウェアのさまざまなセクションの考えを含むいくつかの異なるメモ帳/vim を開いたファイルを使用して、そのような環境で作業しようとしている自分を見ることができます。インターフェイスが Code Bubbles のように正確でなければならないと言っているわけではありませんが、アイデアが得られるものです。
...しかし、実際にテストして感じてみる必要があります。Bubbles と従来の IDE を何らかの形で組み合わせることが、進むべき道だと思います。
事実: 人々が私たちの開発方法を改善しようとして何かを発明しているのを見るのは本当に興味深いことです (例を挙げると、Web 開発におけるZen コーディングなど)。このアプローチが失敗したとしても、いくつかのアイデアは他のプロジェクトに借りることができます。 .
真剣に、私が将来起こることを期待しているのは、キーボードと応答性の高いマルチタッチ インターフェイスを使用し、アイテムとコードのセクションを IDE 間でドラッグし、設計とプログラミングを同時に手を使って行う日です。スクリーンと私のキーボードでの描画: プログラミング用の iPad のようなもの。
(この Code Bubbles ビデオについては、YouTube で非常に良いコメントがいくつかあります。チェックすることをお勧めします)。
ここしばらくの間、新しいコンセプトよりも Code Bubbles に興奮しています。ここ数年、私はコード コミュニティがコード ファイルではなく、コード データベースについて考え始めるのを待っていました。ファイルの比喩は私たちの思考を無力にし、私たちのツールに間違った影響を与えたと思います。
たとえば、単体テストを製品コードと同じファイルに入れる必要があるかどうかという疑問さえあるのはなぜですか? もちろん、これらは一緒に使用しますが、テストを .jar にパッケージ化したくないので、通常は別々にします。ファイルと呼ばれるこれらの人為的なアーティファクトの間をビルド ツールが強制的に行き来できるようにしています。Code Bubbles がより良い比喩であるかどうかはまだわかりませんが、ファイルの比喩から私たちを解放するものは何でも良いものでなければなりません.
Code Bubbles を発見したばかりで、ベータ版を発見して感激しました。これを自分の目で見るのが待ちきれません。