新的编程语言可以添加哪些功能
让它更“直观”？当谈到网站和
台式机，我们喜欢高可用性，几乎直观
可用性。人们越来越期望您的
应用程序应该“正常工作”。对于某一类
应用人们必须RTFM的想法，是一个标记
反对申请的有效性。人们倾向于
期望应用程序按照他们“认为”的方式工作
应该有效。有人可能会说这是一个有价值的标准
设计师应该努力的目标。
同样的可用性严格性可以适用于编程语言吗
和开发环境？我意识到有类似的工具
IntelliSense 提供提示，一个好的 IDE 提供
很多帮助。但核心语言本身又如何呢？什么
可以添加（或删除）以进行某些编程
技术或算法更容易实现？怎么样
一个让正则表达式或递归更直观？或者
这只是愚蠢吗？
举一个更具体的例子：HTML、CSS 中的液体布局，
或 Flex 和 MXML。在 HTML 和 CSS 中，盒子模型可以是任何东西
但考虑到不同的实现，直观
Internet Explorer 和其他浏览器。除非有人
阅读文档或研究盒子的概念
模型设计时很难“直接得到它”
第一次尝试 CSS 时的布局。我认为这是
为什么桌子在早期蓬勃发展。盒子模型是
隐含在表格单元格的概念中。在以下人员的帮助下
像 Dreamweaver 这样的工具可以让他们思考
表格约束内的百分比宽度和布局
细胞。然后CSS成熟了，有一整套有效的
表格不适合布局的原因出现了。但要
达到同样的效果设计师必须真正研究
CSS 实现和盒子模型，并注入一个新的
他们的思维中的抽象层。
在另一个例子中，我发现在编程时有很多事情
在 ActionScript 和 MXML 中，流体布局的整个概念
元素的基于百分比的宽度不是很明显并且
并不总是遵循直觉。我了解基本的
问题在于 Adobe Flash 播放器 和布局需要
以绝对像素的方式理解事物。当它到来时
到组件的潜在宽度，我明白为什么
百分比并不是立即明显可以实施的
代码的核心层。理论上来说Flash
玩家需要知道（或计算）a 的准确宽度
组件，以便它可以提供正确的几何形状
在屏幕上绘图时的显卡。但是当你
介绍一些百分比的概念，然后介绍
理论上无限宽度的可能性。并找到
“无穷大 - 1”像素不是计算机可以做到的
直接做没有一些抽象层和
计算。必须引用视口。该计划
必须知道它的界限。所以绝对宽度是常态，
尽管人类可能更喜欢根据
百分比。
当谈到编程语言时，可以有
思考时有助于直觉的表达和特征
关于一个编程任务。或者我们最好“思考”
就像一台计算机”，当我们需要时，只需 RTFM 即可查看手册
了解如何实现某些功能或布局
代码？
如果你可以改变你的语法或语义
选择的编程语言您会添加、更改什么、
或者去掉以提高“直观性”呢？
附录，提出这个问题的原因是受到启发
查看“新手”能够实现的示例
Alan Kay 的讲座中的 Smalltalk：用图像做事
符号。
What features could be added to a new programming language
to make it more "intuitive"? When it comes to websites and
desktops, we favor high usability, almost intuitive
usability. It is becoming increasingly expected that your
application should "just work". For a certain class of
applications the idea that one has to RTFM, is a mark
against the effectiveness of the application. People tend to
expect the application to just work the way they "think" it
should work. One could argue that this is a worthy standard
that designers should strive for.
Can the same usability rigor apply to programming languages
and developer environments? I realize there are tools like
IntelliSense that provide hints, and a good IDE provides a
lot of assist. But what about the core language itself? What
could be added (or removed) that makes certain programming
techniques or algorithms more obvious to implement? How does
one make regular expressions or recursion more intiutive? Or
is this just folly?
Take a more concrete example: liquid layouts in HTML, CSS,
or Flex and MXML. In HTML and CSS, the box model is anything
but intuitive given the different implementations of
Internet Explorer and the other browsers. And unless someone
reads the documentation or studies the concept of the box
model it would be difficult to "just get it" when designing
a layout on one's first stab at CSS. I would argue this is
why tables thrived in the early days. The box model was
implicit in the concept of a table cell. With the help of
tools like Dreamweaver one could get their mind around
percentage widths and layout within the constraints of table
cells. Then CSS came into maturity and a whole set of valid
reasons emerged for why tables are not for layout. But to
achieve the same effects designers had to really study the
CSS implementations and the box model, and inject a new
layer of abstraction into their thinking.
In another example, I find when programming lots of things
in ActionScript and MXML, the whole concept of fluid layouts
and percentage based widths of elements not very obvious and
doesn't always follow intuition. I understand the basic
problem in that the Adobe Flash player and the layout need
to understand things in absolute pixel terms. When it comes
to the potential width of a component, I understand why
percentages are not immediately obvious to implement at the
core level of the code. Theoretically speaking the Flash
Player needs to know (or calculate) the exact width of a
component so that it can provide the proper geometry to the
video card when doing a draw on the screen. But when you
introduce some concept of percentages then you introduce the
theoretical possibility of an infinite width. And to find
"infinity - 1" pixels is not something a computer can
directly do without some layer of abstraction and
calculation. The viewport must be referenced. The program
must know its boundaries. So absolute widths are the norm,
although humans might prefer to design in terms of
percentages.
When it comes to programming languages can there be
expressions and features that assist intuition when thinking
about a programming task. Or are we better off "thinking
like a computer" and just RTFM'ing the manual when we need
to understand how to implement some feature or layout in
code?
If you could change the syntax or semantics of your
programming language of choice what would you add, change,
or remove to improve the "intuitiveness" of it?
Addendum, the reason for asking this question is inspired by
seeing example of what "novices" were able to achieve in
Smalltalk in Alan Kay's lecture: Doing with Images Makes
Symbols.
发布评论
评论（3）
“如果你可以改变你选择的编程语言的语法或语义，你会添加、改变或删除什么来提高它的“直观性”？
“
编程很难。真的很难。语法变化并不重要。IDE 与编程的基本挑战无关。
经常令人困惑的是语言的语义。
我不知道“直观”意味着什么事实上，对于像编程语言这样抽象的东西来说，“直觉”可能是一件坏事，带着直觉而来的编程语言意味着先入为主的观念、偏见和知识垃圾将占据上风
。 “对于任何级别、任何地方的任何事物。编程需要清晰的思维，而不是“直觉”，而不是“期望”。
我们唯一能做的就是阅读手册，理解我们新事物的独特、独特、新颖的语义。 我确实知道
这一点：简洁的特性是必不可少的。最重要的是，
是很糟糕的。
通过分层来覆盖语言问题 复杂的IDE更糟糕。
请参阅http://www.cs.utexas.edu/~EWD /transcriptions/EWD08xx/EWD854.html
“当面对新的和不熟悉的事物时，我们尝试将其与我们熟悉的事物联系起来。在这个过程中，我们发明了使我们能够这样做的类比。
它很明显，当我们面对如此全新、史无前例的事物时，上述尝试理解的方式不太有效，我们所能想到的所有类比都太弱、太浅薄，无法提供很大帮助。全新的技术可能会造成这种情况，而对编程的广泛误解强烈表明，随着自动计算机的出现，这种情况已经发生了。”
简而言之，“直觉”和“智力包袱”是程序员的问题。 理解一项技术的最好方法是将其视为新鲜的、新的和未知的事物。
底线。
复杂性是固有的。
你有两个选择。
开发智力工具（即抽象、概括等）来应对它。
在另一个领域找到一份工作。
要求本质上复杂的计算世界转变为任何人都认为“直观”的东西是不可能发生的。计算太复杂而无法“直观”。
"If you could change the syntax or semantics of your programming language of choice what would you add, change, or remove to improve the "intuitiveness" of it?
"
Programming is hard. Really hard. Syntax changes don't matter much. IDE's are irrelevant to the fundamental challenge of programming.
The thing that is often baffling is the semantics of the language.
I don't know what "intuitive" means with respect to a thing as abstract as a programming language. Indeed, "intuition" is probably a bad thing. Coming to a programming language with intuition means preconceived notions, biases and intellectual junk will take over.
I would never expect to "just get it" for anything on any level anywhere. Programming requires clear thinking -- not "intuition" -- not "expectation".
The only thing we can ever do is read the manual and understand the unique, distinct, novel semantics of the new thing we're confronted with.
I do know this: elegant simplicity is essential. Orthogonality of features. Clarity. Precision. Absence of exceptions or special cases. Above all, simplicity.
Layering on language features is fundamentally bad.
Covering language problems by layering in a complex IDE is worse.
See http://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD854.html
"when faced with something new and unfamiliar we try to relate it to what we are familiar with. In the course of the process we invent the analogies that enable us to do so.
It is clear that the above way of trying to understand does not work too well when we are faced with something so radically new, so without precedent, that all analogies we can come up with are too weak and too shallow to be of great help. A radically new technology can create such circumstances and the wide-spread misunderstanding about programming strongly suggests that this has happened with the advent of the automatic computer. "
In short, "intuition" and "intellectual baggage" is the problem of the programmer. The best way to understand a technology is to approach it as something fresh, new and otherwise unknown.
Bottom Line.
The complexity is inherent.
You have two choices.
Develop intellectual tools (i.e., abstraction, summarization, etc.) to cope with it.
Get a job in another field.
Asking for the inherently complicated world of computing to morph into something any one person finds "intuitive" can't happen. Computing is too complicated to be "intuitive".
我见过的另一个解决编程语言“语法”复杂性的领域是可视化编程语言。 VPL 背后的基本思想是采用编程语言的结构（决策、子例程、函数等）并以图形方式表示它们，通常为数据流图。最近流行的一种语言是 Microsoft 可视化编程语言。我没有使用过它，也无法声称它的强大功能，但我使用过 LabView效果非常好，我可以说，即使在 LabView 中，您也可以做几乎任何您能想到的事情——但是您确实必须以一种非常不同的方式来思考它。
也就是说，我发现我个人更喜欢代码而不是 VPL。
Another field I've seen that addresses the complexity of the "syntax" of a programming languages is that of Visual Programming Languages. The basic idea behind VPLs is to take the constructs of programming languages (decisions, subroutines, functions, etc.) and represent them graphically, typically as a data-flow diagram. One such language that's gaining popularity recently is the Microsoft Visual Programming Language. I have not used it, and cannot make claims as to its power, but I have used LabView to great effect and I can say that you can do pretty much anything you can think of even in LabView -- but you do have to think of it in a very different way.
That said, I find I have a personal preference for code rather than VPLs.
人们正在采取的一个步骤与基类库和语言本身一样重要——尽管说实话，两者通常是同义词——是 Fluent API。基本思想是让代码“读起来像一个句子”，这个想法是这使得代码更加灵活和可维护。
One step folks are taking that has as much to do with base class library as it does the language itself -- although to be honest, the two are often synonymous -- is the concept of a Fluent API. The basic idea is to make code "read like a sentence", the idea being that this makes the code more flexible and maintainable.