编程中应采用哪些替代用户输入技术？
编程与文字处理特别不同，因为需要输入大量的特殊符号等。
当前一批新的用户界面技术中，哪些适合编程，为什么？
或者语言语法的想法是否是问题所在，我们是否应该更加符号化地进行编程？如果是这样，这将如何影响用户界面？
编辑：当我指定用户界面技术时，我将其开放给使用现有硬件（鼠标/键盘）和其他一些东西，例如多点触控、手势识别、增强现实（有关一些很好的示例，请参阅 HitLabNz）。 我对如何将这些应用到编程中感兴趣。
Programming is particularly different to, for example word processing due to the wealth of special symbols etc that need to be entered.
Of the current crop of new user interface techniques, which are suited to programming and why?
Or is the idea of a language syntax the problem, should we be programming more symbolically, and if so, how would this affect user interface?
Edit: When I specified user interface techniques, i left it open to both using existing hardware (mouse/keyboard) and some other things, like multi-touch, gesture recognition, augmented reality (see HitLabNz for some great examples). I'm interested in how we can apply these to programming.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我只是在想这个。 我本来打算写一篇关于它的博客文章，我不妨从这里开始。 在编程中，我认为我们需要的不仅仅是一种新的输入法，还需要有一个新的隐喻与之相配。 这是一个三层的事情。 模型-隐喻-界面。
我最近越来越多地认为，语言对于表示计算来说是一个糟糕的隐喻。 语言是我们用来交流的东西。 您可以将程序视为与计算机的通信，同时也是与其他程序员的通信。 但除了书面文字之外，还有其他沟通方式。 我正在这里处理一个列表，请随意编辑这篇文章以向列表中添加更多内容。
沟通方法
编程的另一个比喻是构建。 以下是构建功能性事物的一些可能方法，它们可以构成编程接口的基础
构建功能性事物的方法
指定计算的另一种方法是通过定义。
定义方法
- 限制
- 分类
- 集合论
- 特性
- 症状
- 逻辑表
- 规则
- 铁路（如铁路图中）
但请记住我们这样做的原因。 现在的编程语言的工作方式显然存在一些弱点（否则我们就不会想要创造新的语言），所以让我们在设计新语言时牢记它们
当前语言的问题
API被隐藏
副作用是错误的一个重要原因 - 程序的任何部分都可以影响任何其他部分 副作用是导致
重构 - 有时您会发现自己在重复，因此您需要一种简单的方法将重复内容分解为宏、函数或其他隐喻。 这主要是通过大量的文本操作工作手动完成的（或者在 java 中半自动完成的）。 有没有一个新的隐喻可以让这样的事情看起来完全愚蠢？
您需要一种简单的方法来定义自己的构建块、“单词”或习语，以用于构建更复杂的结构。 您自己的工具，您自己的环境部分。 许多语言不允许您以一流的方式执行此操作。
编译器会因为最轻微的错误而严厉惩罚程序员。
变量缺乏时间感 - 无法查询变量过去设置的所有值的历史记录。 换句话说，我们是否可以拥有一种可以“倒带”程序进度的编程语言？ 变量经常更改为意外值这一事实是错误的另一个来源。 这是副作用问题的另一半
大多数编程语言都有相当陡峭的学习曲线
在整个代码中引用库或小部件 X 在很大程度上结合在一起你到那个库 - 如果不进行大量重构就很难切换到类似的等效库。 这很大程度上与库有名称这一事实有关，为了使用库，我们在整个代码中对该库的名称及其方法进行了硬编码。 有更好的方法吗？
并行性差、多线程会导致错误、竞争条件、死锁。 是否有更好的并行方法可以消除此类错误？ 仅这个问题就导致了许多新语言的创建。
各位，请超越计算机屏幕来思考。 也许键盘是输入复杂关系和符号的最有效的界面。 你确定吗？ 除了鼠标、触摸屏或平板电脑之外，还有更多选择。 与计算机交互的方式有无数种 - 我们都选择了一两种相当普通的方式。
I was just thinking about this. I was going to write a blog post about it, I may as well get started here. In programming, I think we need more than just a new input method, there needs to be a new metaphor to go with it. It's a three tiered thing. Model-Metaphor-Interface.
I've been thinking more and more lately that language is a poor metaphor for representing a computation. Language is something we use for communication. You could look at a program as a communication to a computer, and simultaneously a communication to other programmers. But there are other ways to communicate other than just the written word. I'm working on a list here, feel free to edit this post to add more stuff to the list.
Methods of Communication
Another metaphor for programming is building. Here's some possible ways of building functional things, that could form the basis for a programming interface
Methods of building functional things
Yet another way of specifying a computation is by definition.
Methods of Definition
- Constraints
- Categorization
- Set Theory
- Properties
- Symptoms
- Logic tables
- Rules
- Railroads (as in railroad diagrams)
But keep in mind why we're doing this. There's obviously some weaknesses in the way programming languages work now, (otherwise we wouldn't want to make new languages) so let's keep them in mind while we're designing our new languages
problems with current languages
The interface is hidden
the APIs are hidden
Side effects are a huge cause of bugs- Any part of a program can effect any other part.
Refactoring- Sometimes you find that you're repeating yourself, so you need an easy way to factor out the repetition into a macro, or a function, or some other metaphor. This is largely done by hand (or semi-automatically in java) by a massive text manipulation effort. Is there a new metaphor that would make such a thing look utterly silly?
You need an easy way to define your own building blocks, or "words" or idioms, to use to build more complex structures. Your own tools, your own parts of the environment. A lot of languages don't let you do this in a first class way.
compilers punish the programmer severely for the slightest mistake.
Variables lack a sense of time- There's no way to query the history of all the values a variable has been set to in the past. In other words, can we have a programming language where we can "rewind" the progress of our program? The fact that a variable can change, frequently to unexpected values is another source of bugs. This is the other half of the side effects problem
most programming languages have a fairly steep learning curve
Making reference to library or widget X throughout your code largely marries you to that library- Making it difficult to switch to a similar equivalent library without a lot of refactoring. This is largely to do with the fact that libraries have names, and in order to use a library, we're hardcoding the name of that library and its methods throughout our code. Is there a better way?
Poor parallelism, multithreading leads to bugs, race conditions, deadlocks. Is there a better approach to parallelism that makes such bugs impossible? This issue alone is causing the creation of many new languages.
Think beyond the computer screen, people. Maybe the keyboard is the most efficient interface for entering in complex relationships and symbols. Are you sure? There are more alternatives than just a mouse, or a touch screen, or a tablet. Zillions of ways of interacting with a computer- We have just all settled on one or two rather ordinary ways.
几乎所有想要拥有一种非文本编程语言的努力都以失败告终。 如果没有文本语言，就很难既精确又高效。
UI 方面的大量工作都集中在制作更好的工具上。 例如，您可以只使用简单的文本编辑器进行编程，也可以使用成熟的 IDE，如 Visual Studio 或 Eclipse。 除此之外，还有 Rational Rose 等可视化和设计工具。 这些工具提供了探索和/或修改底层代码的补充方法。
Just about every effort to have a non-textual programming language has fallen flat on its face. It's very hard to be both precise and efficient without a textual language.
Where a lot of the UI effort goes is in making better tools. For example, you can just use a simple text editor to do the programming or you can have full-blown IDEs like Visual Studio or Eclipse. Beyond that, there are visualization and design tools like Rational Rose. These tools offer complementary ways of exploring and/or modifying the underlying code.
我认为，即使您使用非文本（例如图形、语音识别、直接神经接口）输入方法，对您的编程内容进行文本表示也非常重要。
程序基本上就像菜谱：“要实现这一点，请执行这些步骤”。 文本表示是这个菜谱的书面记录。 如果您需要一个食谱来制作食谱（“单击此菜单，使用此对话框...”），并且无法进行文本交互，那么您将与您制作的内容失去联系。
我认为程序员对替代输入/编程方法的愿望与他使用的语言中的概念缺陷相关。 最近，我读到有人接到一项任务，要编写一堆 setter 和 getter——用一种更好的语言，这将是其元编程工具的工作。
关于图形编程的主题：我可以比用鼠标绘制三角形之类的东西更快地键入“for”一词。 即使通过让我从某个菜单中获取这个三角形来“促进”该绘图，情况也是如此。 编程时，您会使用数百种不同的符号； 如何组织他们无需打字即可访问？ 呵呵，我知道，键盘快捷键怎么样……等等……
键盘是目前向计算机传达含义最快的工具，而一段文本是在计算机上存储含义最简洁、最有用的表示形式。
I think that it's very important to have a textual representation of what you program, even if you use a non-textual (e.g. graphical, speech recognition, direct neural interface) input method.
A program is basically something like a recipe: "to achieve this, go through these steps". The textual representation is a write-up of this recipe. If you need a recipe for making the recipe ("click this menu, use this dialog box..."), and a textual interaction is not possible, then you lose contact with what you produce.
I think that a programmer's wish for alternative input/programming methods is correlated to the conceptual flaws in the language he uses. Recently I read about someone who got an assignment to write a bunch of setters and getters -- in a better language, this would be a job for its metaprogramming facilities.
On the subject of graphical programming: I can much faster type the word "for" than draw something like a triangle with the mouse. This is so even if this drawing is "facilitated" by letting me get this triangle from some menu. When programming, you use hundreds of different symbols; how can they be organized to access without typing? Heh, I know, how about keyboard shortcuts ... wait ...
The keyboard is currently the fastest instrument for conveying meaning to a computer, and a piece of text ist the most concise and useful representation for storing meaning on a computer.
像多点触控这样的东西可能会提高代码创建的机械效率，但我认为这不是编程中的主要问题。 当您考虑分析、设计、记录和测试算法所需的所有工作时，实际键入代码所花费的时间比例是如此之小，以至于在这里或那里节省按键或鼠标单击的时间并不会太多。
在我看来，当今编程的主要挑战不是特殊符号或语法，它们相对较少，大多是直观的，并且接近接近 C 约定的事实上的标准。 在我看来，编程的主要挑战是理解更大的代码单元，即 API 和程序本身的函数和类：可用的内容、每个类的作用、每个函数需要和返回什么、哪里有相似之处和差异，以及它们如何组合成一个架构。 我认为最严重的问题是由于不了解代码可能遇到的所有可能条件组合的类和函数的微妙之处。
也许 AR 可视化技术可以帮助程序员和分析师查看和操作代码结构或流程的更大图景，但坦率地说，可以使用更传统的 UI 技术和控件（例如表格、表单和菜单）来完成很多工作。进入编码世界。 晚期的 Gupta/Centura 编程语言使用树状控件来更容易地查看更大的代码结构。 智能感知是促进代码创建的正确想法，但还可以做更多工作来为开发人员提供更大规模地理解和分析代码的工具。 Roedy Green 的数据库源代码是一个好的开始 (http://mindprod.com/project/scid.html ），允许开发者智能查询代码库。 更好的是一个编程用户界面推动开发人员进行分析，明确开发人员对于给定的程序设计需要考虑的内容。
Things like multitouch could potentially increase the mechanical efficiency of code creation, but I don’t think that’s a major concern in programming. When you consider all the work necessary to analyze, design, document, and test algorithms, the proportion of time spent actually typing code is so small that saving a key-press or mouse-click here or there isn’t going to amount to much.
It seems to me the main challenge in programming these days isn’t the special symbols or syntax, which are relatively few, mostly intuitive, and approaching a de facto standard of something close to C conventions. It seems to me the main challenge in programming is understanding the larger units of code, namely the functions and classes of both the API and the program itself: what is available, what each class does, what each function requires and returns, where there are similarities and differences, and how they fit together into an architecture. I believe the most serious problems are due to not understanding subtleties in the classes and functions for all possible combinations of conditions the code may encounter.
Maybe AR visualization techniques could help programmers and analysts see and manipulate the larger picture of the code structure or processes, but frankly a lot could be done with much more conventional UI techniques and controls, such as tables, forms, and menus, that have yet to make it into the coding world. The late Gupta/Centura programming language used a tree-like control to make it easier to see larger code structures. Intellisense is the right idea for prompting code creation, but more could be done to provide the developer the tools to understand and analyze the code at larger scales. Roedy Green’s Source Code in Database is a good start (http://mindprod.com/project/scid.html), allowing the developer to intelligently query the code base. Even better would be a programming UI that pushes analysis on the developer, making explicit what the developer needs to consider for a given program design.
对此已经进行了多次尝试。
APL 使用一系列特殊符号来表示每个操作。 这仍然以“J”语言的形式存在，等等，它用两个或三个字母的 ASCII 字符组合替换了所有符号。
IBM 的视觉时代大约在 1998 年。有一个图形 IDE，您可以在其中执行诸如将“套接字”图标拖到工作空间并将其连接到“流”图标之类的操作。 不过，它只是生成了 C++，并且在最初的 g-whizz 之后，大多数程序员发现了“文本视图”选项并坚持使用它。
Suns Fortress —— 仍然是文本的，但它允许您使用 √ 这样的 unicode 符号作为运算符。 不过，大多数已发布的示例程序似乎都坚持使用 ASCII 字符集。
这里有两个问题。
文字非常非常好！ 几千年来人们都能够画出漂亮的图画，但亚马逊销售的 99% 的书籍只包含简单的文字。 这可能是有充分理由的。
虽然“插座”和相关“连接”点的图形可能很容易使用，但开发起来并不容易。 现在，您不需要进行方法签名和一些 Javadoc，而是需要图形设计师来设计“错误消息显示图标”并定义一组有关如何以及在何处使用图形的规则。
There have been several attempts at this.
APL which used a selection of special symbols to represent each operation. This still exists in the form of the "J" language which -- wait for it -- replaced all the symbols with two or three letter ASCII character combinations.
IBMs Visual Age circa 1998. Had a graphical IDE where you did things like drag a "socket" icons to your work space and join it to a "stream" icon. It just generated C++ though, and, after the intial g-whizz most programmers found the "text view" option and stuck with it.
Suns Fortress -- still textual but it lets you use unicode symbols like √ as operators. Most published examples programs seem to stick with the ASCII character set though.
There are two problems here.
Text is very very good! People have been able to draw pretty good pictures for thousands of years but 99% of the books Amazon sells contain only simple text. There is probably a good reason for this.
While a graphic for a "socket" and the associated "connection" points may be easy to use, its not trivial to develop. Instead of doing a method signature and perhaps a bit of Javadoc you now need a graphic designer to design an "Error message display icon" and define a set of rules as to how and where the graphic can be used.
等等...您需要的不仅仅是文本编辑器和编译器/链接器？
Wait... You need more than a text editor and a compiler/linker?
好吧，某种符号场景的全部目的实际上只是归结为基于 GUI 的开发，这是 Visual Studio 慢慢尝试的一个主题，但我们距离这个目标还有很多年。
创建某种代表 FOR 循环的符号不会加快开发速度。 如果您想更快地编码，只需使用任何像样的 IDE 已经支持的拖放代码块即可。
Well the whole purpose of some kind of symbolic scenario really just boils down to GUI based development, which is a subject Visual Studio slowly flirts with, but we're still many years away from.
Creating some kind of symbol that represents a FOR loop wouldn't speed up development. If you want to code faster just use drag'n'drop code blocks that any decent IDE already supports.