我读过这个提到Code Bubbles的问题，并且看过他们的视频演示。
该视频令人印象深刻，看起来确实有点未来感，但显然它有点真实。
但这让我一直在思考……开发人员真的会使用这样的工具吗？
作为开发人员，我们习惯于处理代码文件，将它们组织在目录中，以一种或另一种方式，一些常见的 IDE（对于那些拥有它们的语言）。
正如他们所建议的那样，使用像 Code Bubbles 这样的东西将是一个巨大的飞跃。
就我个人而言，我不确定我是否可以在这样的环境中工作......虽然我认为我只需要一些调整......但我真的不认为我的想法会解决它的问题。
您对此有何看法？
我会在心跳中使用它。无论如何，我总是想那样工作。
当我第一次创建它们时，我只考虑目录结构：之后我总是想通过思路而不是文件来工作。
对于像 C# 和 Java 这样的语言，代码文件和块（方法等）的实际组织相当严格（在 Java 中甚至比 C# 更严格），那么提供新的代码“视图”的东西可能会起作用。您可以允许该工具使用每个文件一个类、按可见性排序的方法或您想要的任何编码标准来组织您的代码，并且该工具可以以这样一种方式处理这一切，以至于有人仍然可以出现并查看“原始" 文件并理解这一切。
对于像 C++ 这样的语言来说，这将是一个问题，你基本上可以做任何你喜欢的事情......
这样想......什么会更容易：
(1.) 有代码气泡，您可以在其中查看在一个同时视图中相互调用的一系列函数
-或者-
(2.) 在单个文本编辑器中不断地在这些函数之间来回切换，分布在 6 或 7 个源代码文件中？
我会使用代码气泡吗？如果在接下来的几年里 MS 没有推出与 VS 相当的产品，我可能会突然对成为一名 Java 开发人员产生浓厚的兴趣。
我认为这是一个令人印象深刻的创新概念，我迫不及待地想尝试一下！
除了独立于存储的文件查看代码的绝妙想法之外，我发现最有趣的是类似于“小地图”的栏，它显示了您的气泡布局的缩影，让您可以立即滚动或定位您的“桌面“在特定区域。
这就是应该在操作系统级别上实现虚拟桌面的方式！
真正的程序员使用文本编辑器。:)
不认真，我喜欢 Code Bubbles，但我需要的不仅仅是一个新的 GUI 来切换。
将代码气泡链接在一起并将它们作为一个组移动的想法似乎有点愚蠢，并且在大多数实际场景中可能没有用。
但是，我认为所有程序员都可以很好地以图形方式查看他们的应用程序占用屏幕上的空间，而不是像文件中的行一样占用（不太明显的）空间。仅就这一点而言，我认为它作为演示工具很有用，如果不是作为编程环境的话。
对于那些感兴趣的人，微软研究院也在为 Visual Studio 做类似的事情。它被称为代码画布。
您可以在此处了解更多信息并观看视频：http: //blogs.msdn.com/b/kaelr/archive/2009/03/26/code-canvas.aspx
关于最初的问题，我一发现 Code Bubbles 就注册了测试版。我认为它有一些非常好的想法，并想尝试一下。即使事实证明它没有他们声称的那么有用，我相信其中一些概念会演变为被许多程序员使用。
我一定会下载它并在可用时尝试使用它。它看起来像是一个可以加速调试、代码审查和某些类型开发的好主意。此外，代码气泡常见问题解答表示它们支持将整个文件视为大的、可滚动的气泡 - 因此您可以在需要时打破气泡隐喻。
可能我脑海中最大的问题是我认为除了 Java 之外不支持任何东西。我大部分时间都花在 C 语言上，如果他们想让这个想法真正起飞，多语言支持是至关重要的。
出于多种原因，我会使用代码气泡，但真正让我兴奋的是调试。我喜欢这样的想法，即当您进入一个函数时，它会为该函数打开一个新的气泡，因此您可以查看调用该函数的代码并同时查看该函数的自身，我认为这是很好的生产力。
加思
绝对地！文件结构不会影响气泡视图，因此您可以在技术上使用传统方法来组织项目源文件。这真正有帮助的是导航已经根深蒂固的代码。学习别人的代码的必备工具。它还有助于保持代码整洁——许多小而简洁的对象和函数。
我认为它看起来不错，但对我来说，它看起来在调试/单步执行代码时会更有用。没有 IDE 打开整个代码文件，只是创建一个小代码气泡有点酷。
我认为 Code Bubbles 为整个 GUI 桌面隐喻开辟了思路，而不仅仅是编程。
我们所做的大部分工作都是分层的。想象一下编写项目文档。它有标题吗？副标题？想象一下构建目录 (ToC)，然后单击每个标题/副标题以获取放置内容的单独窗口。您可以在不同的气泡中同时打开多个子部分。你总是可以分屏一个现代文字处理器来完成同样的事情，但我希望能够将这些部分移到单独的窗口中，这样我就可以按照我想要的方式排列它们，而不是仅仅依靠应用程序来为我“平铺”子窗口。Code-Bubbles-as-desktop 将允许这样做。
想象一下，您正在协作处理该文档。您单击 ToC 中的一个子标题并开始处理它。其他人点击另一个并开始处理它。您可以使用传统锁定来避免让其他人弄乱您正在做的事情，反之亦然。是的，我知道 EtherPad。我用过。它让我发疯。
我一直在考虑做一个基于 wiki 的文档/程序组合系统，您可以在主文档中创建标题，每个标题都链接到这些标题的实际内容。不同的部分会出现在不同的窗口中，您可以根据需要进行安排。Code-Bubbles-as-desktop 可以说是一种更优雅的解决方案。
显然，这可以通过编程来完成，因为程序只不过是一个复杂、非常精确的文档，目标受众非常挑剔。程序通常是非常分层的。就目前而言，当我编程时，我使用的是 Vim 或 Eclipse。他们都能够“折叠”我没有看到的代码部分，给我一个高级概述和实际代码的混合。在 Code Bubbles 中也可以做到这一点，其中一个气泡显示您的方法定义，而其他气泡包含方法内容。在将它们提供给编译器之前，它们都会被“编织”在一起。
另外，当我在编程时，我通常会通过在注释中放入高级伪代码来“充实”一个方法或函数，然后遍历并填写实现每段伪代码的程序代码。这些伪代码注释可以提供 ToC 部分，这将打开气泡来保存实际代码。系统需要将各个部分“编织”到主文档中。无论您使用哪种编程语言，这都会起作用。
我对文学编程的兴趣是否足够清晰？
让我们把它带到一个新的水平。您正在使用平板电脑或上网本。您可以使用的屏幕空间要少得多。哦，天哪，看那个；气泡都比较小。使用顶部的“上下文栏”找到您正在寻找的气泡，并且气泡可以占据屏幕。现在，您有了一种编写文档（包括程序）的方法，该方法适用于更小、尺寸受限的设备。
这可能是一厢情愿，但我认为这可能是一个重要的新范式，不仅适用于编程，而且适用于整个 GUI。我当然会使用它。
我可以看到自己尝试在这样的环境中工作，因为我总是使用我的 IDE 进行开发，我桌上的一些文件和一些不同的记事本/vim 打开的文件具有不同的片段和代码/软件的不同部分的想法。我并不是说界面必须像 Code Bubbles 一样精确，而是说要有想法。
...但我需要真正测试它，感受它。我认为以某种方式混合使用 Bubbles 和传统 IDE 是可行的方法。
事实是：看到人们发明一些东西试图改进我们的开发工作方式真的很有趣（比如Web 开发中的Zen Coding，只是举个例子），即使这种方法失败，一些想法也可以借鉴到其他项目.
说真的，我期待在未来发生的那一天，我将使用键盘和响应式多点触控界面，在 ide 上拖动项目和代码段，同时用我的双手进行设计和编程在屏幕和我的键盘上绘图：类似于用于编程的 iPad。
（在 youtube 上有一些关于这个 Code Bubbles 视频的非常好的评论，看看它是个好主意）。
我认为您的工作流程（以及前期的学习曲线）的变化不会像最初出现的那么大：如果您正在使用 Eclipse（正确），您已经在使用 Open Type（按名称）、Open Call Hierarchy 进行导航，开放类型层次结构、开放声明等。折叠的代码块似乎也是代码泡沫的前兆。
我同意 Codeka 的观点，它可能只适用于像 Java 这样的“严格组织”的语言，而不适用于像 Perl 这样的东西，这给了程序员更多的自由来安排事情（以牺牲他的工具支持为代价）可以期待）。
我不能说我是否会长期坚持下去，但我当然想在那种环境中工作几个月。
这里有一些非常有趣的 GUI 创意——这是一个鼓舞人心的视频。
一段时间以来，我对 Code Bubbles 的兴奋程度超过了对新概念的兴奋。几年来，我一直在等待代码社区开始考虑代码数据库，而不是代码文件。我认为文件隐喻削弱了我们的思维并以错误的方式影响了我们的工具。
例如，为什么会有单元测试是否应该与生产代码放在同一个文件中的问题？当然它们是一起使用的，但我们通常将它们分开，因为我们不希望将测试打包到 .jar 中。我们让构建工具迫使我们在这些称为文件的人为工件之间来回切换。Code Bubbles 是否是一个更好的隐喻还有待观察，但任何能让我们摆脱文件隐喻的东西都必须是一件好事。
I've just discovered Code Bubbles and was ecstatic to discover the beta. I can't wait to see this for myself.
My impression from the demo was that I could see how that approach would be useful for large programs. However, in the 14 years I've been programming for a living, I've only written a program that large once (inherited a couple more).
That was when I was 22, and I regretted making it so monolithic for the next six years until it was retired. It was a constant maintenance problem, because no one but me ever really understood the whole thing.