为什么大多数编程语言中没有更多的控制结构？
为什么从逻辑的角度来看，大多数语言似乎只表现出相当基本的控制结构？像 If ...then、Else...、循环、Foreach、switch 语句等之类的东西。从逻辑的角度来看，标准列表似乎相当基本。
为什么没有更多的逻辑语法糖呢？也许类似于命题引擎，您可以在其中提供一系列前提或函数，这些前提或函数返回复杂的自引用相互依赖的函数和结果。您可以将一系列复杂的条件链接在一起，但以一种在代码中易于阅读的方式表示。
前提 1
前提 2 当且仅当 前提 1
前提 3
前提 4 如果前提 2 和前提 3 前提
5 当且仅当前提 4
等等...
结论
我意识到这种逻辑 this 可以在函数和/或嵌套中构造条件语句。但是，为什么通常没有更多的语法选项来构建此类逻辑命题，而又不会导致看起来难以阅读和调试的条件语句呢？
对于我们在主流编程语言中通常看到的控制结构类型有解释吗？您是否希望看到语言语法直接支持特定的控制结构？这是否会给语言增加不必要的复杂性？
Why do most languages seem to only exhibit fairly basic control structures from a logic point of view? Stuff like If ... then, Else..., loops, For each, switch statement, etc. The standard list seems fairly basic from a logic point of view.
Why is there not much more in the way of logic syntactical sugar? Perhaps something like a proposition engine, where you could feed an array of premises or functions that return complicated self referential interdependent functions and results. Something where you could chain together a complex array of conditions, but represented in a way that was easy and clear to read in the code.
Premise 1
Premise 2 if and only if Premise 1
Premise 3
Premise 4 if Premise 2 and Premise 3
Premise 5 if and only if Premise 4
etc...
Conclusion
I realize that this kind of logic this can be constructed in functions and/or nested conditional statements. But why are there not generally more syntax options for structuring these kind of logical propositions without resulting in hairy looking conditional statements that can be hard to read and debug?
Is there an explanation for the kinds of control structures we typically see in mainstream programming languages? Are there specific control structures you would like to see directly supported by a language's syntax? Does this just add unnecessary complexity to the language?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
你看过Prolog吗？ Prolog 程序基本上是一组规则，被转变为一个大型评估引擎。
从我个人的经验来看，Prolog 有点太奇怪了，我实际上更喜欢 if、while 等，但是 YMMV。
Have you looked a Prolog? A Prolog program is basically a set of rules that is turned into one big evaluation engine.
From my personal experience Prolog is a bit too weird and I actually prefer ifs, whiles and so on but YMMV.
布尔代数并不困难，并且为您能想到的任何条件以及无数其他变体提供了解决方案。
您不妨要求“常用”算术表达式的特殊语法。谁能说出什么才是常用的？在哪里停止添加特殊情况语法？
增加语言解析器的复杂性并不比使用构造性表达式语法与通过定义函数的可扩展性相结合更可取。
Boolean algebra is not difficult, and provides a solution for any conditionals you can think of, plus an infinite number of other variants.
You might as well ask for special syntax for "commonly-used" arithmetic expressions. Who is to say what qualifies as commonly-used? And where do you stop adding special-case syntax?
Adding to the complexity of a language parser is not preferable to using constructive expression syntax, combined with extensibility through defining functions.
自从我在大学上逻辑课以来已经有很长一段时间了，但我猜想这是将它们写入语言的难度与它们的使用频率的混合。我不能说我曾经需要它们（我不记得了）。当您需要类似的东西时，语言设计者可能会认为您可以仅使用基本结构自己计算出逻辑。
不过这只是我的疯狂猜测。
It's been a long time since my Logic class in college but I would guess it's a mixture of difficulty in writing them into the language vs. the frequency with which they'd be used. I can't say I've ever had the need for them (not that I can recall). For those times that you would require something of that ilk the language designers probably figure you can work out the logic yourself using just the basic structures.
Just my wild guess though.
由于大多数编程语言没有为用户提供足够的工具来实现它们，因此实现者不认为它是一个足够重要的功能来提供扩展，并且没有足够的需求或使用来将其添加到标准中。
如果您确实想要它，请使用提供它的语言，或者提供实现它的工具（例如，lisp 宏）。
Because most programming languages don't provide sufficient tools for users to implement them, it is not seen as an important enough feature for the implementer to provide as an extension, and it isn't demanded enough or used enough to be added to the standard.
If you really want it, use a language that provides it, or provides the tools to implement it (for instance, lisp macros).
听起来好像您正在描述一个规则引擎。
It sounds as though you are describing a rules engine.
我们使用的基本控制算法反映了处理器可以有效执行的操作。基本上这可以归结为简单的测试和分支。
这似乎对您有限制，但许多人不喜欢编写看起来简单的代码行需要数百或数千（或数百万）个处理器周期才能完成的想法。这些人中有系统软件人员，他们编写操作系统和编译器之类的东西。当然，大多数编译器都会反映他们自己的作者的担忧。
The basic control algorithms we use mirror what processor can do efficiently. Basicly this boils down to simple test-and-branches.
It may seem limiting to you, but many people don't like the idea of writing a simple-looking line of code that requires hundreds or thousands (or millions) of processor cycles to complete. Among these people are systems software folks, who write things like Operating Systems and compilers. Naturally most compilers are going to reflect their own writer's concerns.
它涉及对原子性的关注。如果你可以用更简单的结构 Y、Z 来表达 A、B、C、D，为什么不简单地不提供 A、B、C、D 而提供 Y、Z 呢？
现有的语言反映了 60 年来原子性和可用性之间的紧张关系。现代方法是“小语言，大图书馆”。 （C#、Java、C++ 等）。
It relates to the concern regarding atomicity. If you can express A,B,C,D in simpler structures Y, Z, why not simply not supply A,B,C,D but supply Y, Z instead?
The existing languages reflect 60 years of the tension between atomicity and usability. The modern approach is "small language, large libraries". (C#, Java, C++, etc).
因为计算机是二进制的，所以所有决策都必须归结为 1/0、是/否、真/假等。
为了提高效率，语言结构必须反映这一点。
Because computers are binary, all decisions must come down to a 1/0, yes/no, true/false, etc.
To be efficient, the language constructs must reflect this.
最终，所有代码都会变成一次执行一条指令的微代码。在微代码和附带的 CPU 能够描述更丰富多彩的东西之前，我们只能使用一种非常简单的语言。
Eventually all your code goes down to a micro-code that is executed one instruction at a time. Until the micro-code and accompanying CPU can describe something more colorful, we are stuck with a very plain language.