当谈论编程语言时，Magic的定义是什么？
“魔法”这个词在“X 语言有太多魔法”或“Y 平台通常避免魔法”等上下文中经常出现。 然而，这个术语的定义似乎相当模糊，人们一看到它就知道了。 例如，Java 被认为包含很少的魔法，但它的垃圾收集器向程序员隐藏了很多东西。 如果魔法仅仅意味着隐藏细节的抽象，那么既然没有人再用汇编语言编写大型程序，为什么它被认为是一件坏事呢？ 如果魔法还有更多意义，那么它又意味着什么呢？
The word "magic" gets thrown around a lot here in contexts like "language X just has too much magic", or "platform Y generally avoids magic". However, it seems the term is pretty poorly defined, something people know when they see it. For example, Java is reputed to contain very little magic, but its garbage collector hides a lot from the programmer. If magic simply means abstraction that hides details, then why is it considered a bad thing, given that nobody writes large programs in assembly language anymore? If magic means something more, then what does it mean?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
“任何足够先进的技术都与魔法没有区别”——亚瑟·C·克拉克。
实际上不完全是这样 - magic 用于复杂和隐藏而不是高级（尽管设计者可能认为它们是高级的），例如在过程调用之前需要特定状态的系统（COM 线程模型）以及“自动”类型转换（VB 变体、Javascript ==、Java 自动装箱）。
一旦系统向程序员隐藏了不再可预测的细节，它们就会变得神奇。 您不得不用一种您不理解的语言重复调用，因为它在过去具有正确的效果。 那是不好的魔法，或者巫术。
还有很棒的魔法 - http://aggregate.org/MAGIC/
"Any technology sufficiently advanced is indistinguishable from magic" — Arthur C. Clarke.
Actually not quite that — magic is used for complicated and hidden rather than advanced (though presumably the designers thought they were being advanced), such as systems which require specific states before procedure calls (COM threading models) as well as 'automagic' type conversions (VB variants, Javascript ==, Java autoboxing).
Once systems hide details from the programmer that they are no longer predictable, they become magic. You're stuck with repeating an invocation in a language you don't understand because it's had the right effect in the past. That's bad magic, or voodoo.
There's also good magic — http://aggregate.org/MAGIC/
当你忽略某些东西/你不知道它是如何运作时，它就是神奇的。
Something is magic while you ignore it / you don't know how it works.
在 Microsoft，这往往有两种使用方式：
1) 消极方式（可能是最常见的用法）。 例如，有人可能会说“我不明白；首先你将重构 API，接下来你将保留旧的 API，并在它们之间有一个执行魔法的层？”
这意味着魔法组件太复杂、太未定义或太“某种东西”。
另一个消极的情况是当某些东西被天真地定义时：当有人假设一个复杂问题有一个简单的解决方案时，通常会发生这种情况，因为他们没有意识到问题确实很复杂。 Raymond Chen 的博客 充满了此类示例。
2）“魔法”一词很少被正面使用。 但它确实发生了。 有用地指执行有效的复杂任务的事物。 对我来说 NTFS 就是这样的魔力。 NTFS 确实非常成熟，并且在一些非常简单的 API 背后隐藏了很多复杂性。 编译器也可以通过这种方式被视为“魔法”——您真的深入了解 C++ 编译器是如何工作的吗？ 我不——我只是相信他们会。
At Microsoft this tends to be used two ways
1) In a negative way (probably the most common usage). For example, someone might say the following "I don't understand; first you will refactor the API, next you will keep the old API and have a layer between them that performs magic?"
The implication is that the magic component is too complex, too undefined, or too 'something'.
The other negative context is when something is defined naively: This often happens when someone assumes there is a simple solution to a complex problem because they do not realize that the problem is really complex. Raymond Chen's blog is full of these kinds of examples.
2) Its less often that the term 'magic' is used positively. But it does happen. Usefully to refer to things that perform complex tasks that just work. To me NTFS is that kind of magic. NTFS is really, really mature and hides a lot of complexity behind some pretty simple APIs. Compiler's can be seen as 'magic' in this way as well - do you really understand, deeply, how a C++ compiler works? I don't - I just trust that they do.
魔法与你的理解力密切相关。
在开始使用 Java 编写之前，我编写了大量的 C 和 C++ 代码。 我必须分配和释放我的所有内存。 一旦我开始出现内存泄漏，事情就没那么有趣了。 一旦我开始用 Java 编写，我（基本上）就知道幕后发生了什么，以便创建我的所有实例对象。 因此，对我来说，它并不像刚开始学习 Java 的人那么神奇（我已经完成了分配，但它如何实际存储对象并知道何时释放它们对我来说更“神奇”） （从未需要手动处理内存。）
另一个例子是 ORM。 我在项目的早期就推出了自己的临时对象关系映射结构，直到我有时间真正认真学习 Hibernate 或类似的东西。 我必须编写诸如 ResultSet 映射器、延迟加载和一些基本缓存之类的内容。 现在，当我返回并用更成熟的 Hibernate 或 JPA 映射实体替换这些东西时，我仍然会对正在发生的事情有一个基本的了解。 如果您从未使用过 JBDC 或类似的东西，您将真正知道的是数据从数据库到对象然后再返回。
每个人在职业生涯中都会遇到一定程度的魔法。 我们不可能知道一切。 魔术确实可以与抽象同义。 当它变得“太神奇”时，抽象就开始掩盖你需要能够控制的事物。 前几天的一个例子是，在 JSF 程序中，我不知道如何启动 JSF 上下文。 JSF 只是在您第一次导航到 JSF 页面时执行此操作。 我需要从常规 servlet 启动上下文。 我最终不得不制作一个虚拟 JSF 页面来处理它。 我根本没有时间在这个项目中学习 JSF 上下文管理的“魔力”。
Magic is very relative to your understanding.
I wrote a fair amount of C and C++ before I started writing in Java. I had to allocate and deallocate all of my memory. It wasn't a lot of fun once I started getting memory leaks. Once I started writing in Java, I knew (basically) what was going on behind the scenes in order to make all my instance objects. Thus, to me, it's not near as much magic (I've done allocation but how it actually stores objects and knows when to deallocate them is a little more "magical" to me) as it would be to someone who had started on Java (who has never had to manually handle memory.)
Another example is ORM. I rolled my own temporary Object Relational Mapping structure early in a project until I had time to really buckle down and learn Hibernate or something similar. I had to write in things like ResultSet mappers, Lazy Loading and some basic caching. Now, when I go back and replace this stuff with more mature Hibernate or JPA mapped entities, I'll still have a basic understanding of what's going on. If you've never used JBDC or anything similar, all you're going to really know is that the data goes from the database to the object and back again.
Everyone deals with a certain level of magic in their careers. We can't know everything. Magic really can be synonomous with Abstraction. When it becomes "too magic" is when the Abstraction begins to cover up things that you need to be able to control. An example the other day was that in a JSF program, I didn't know how to start a JSF context. JSF just does this when you navigate to a JSF page for the first time. I needed to start the context from a regular servlet. I ended up having to make a dummy JSF page to handle it instead. I simply didn't have time in this project to learn the "magic" of JSF context management.
魔法与其他上下文具有相同的含义：具有隐藏的复杂性和逻辑的东西。 这并不总是坏事，但对于程序员（他们是非技术人员的魔术师）来说却是坏事。 当你（能够）知道它看起来如何运作时，魔法就不再是魔法了。
例如，魔法常量：具有隐藏含义的常量。
当我们谈论某些混淆代码中发生的“黑魔法”时，我们的意思是在这段代码中发生了一些我们不理解的事情； 或者发生了一些非书面的事情，但对代码阅读器来说是隐藏的。
在某些情况下，你会以积极的方式谈论魔法：当你看不到一个简单易懂的东西的真正复杂性时。
例如，一些非常复杂的代码可以隐藏在一个微小且易于使用的接口类中。 这看起来很神奇，因为它用简单的用法就能完成复杂的事情。
这是很好的魔法（但很少见）。
Magic has the same meaning than in other context : something with hidden complexity and logic. It's not always bad, but for programmers (that are magicians for non-techie people) it is. Magic is not magic when you (can) know how it work the way it look.
For example, magic constants : constants with a hidden meaning.
When we talk about "black magic" occurring in some obfuscated code, we mean that something happen in this code that we don't understand; or that something non-written happen but is hidden from the code reader.
In some cases, you talk about magic in a positive way : when you don't see the real complexity of a simple to understand how to use thing.
For example, some really complex code can be hidden in a tiny and simple to use interface class. That seems magic because it does complex thing with simple usage.
That is good magic (but rare).
例如，Ruby on Rails 就是魔法。
在基础层面上，尤其是天真地接触时，极简代码和数据库之间有一个很大的厚层，然后神奇的事情发生了，你就得到了粗略的功能和所有其他的东西。
有些人可以忍受这种非常高水平的体验，但最终你会开始遇到障碍，你需要了解“技巧”的“秘密”，这样你才能更好地操纵它以达到你的目的。
语言本身并没有太多的魔力（好吧，也许是 Prolog——它的核心有点魔力），但现代框架和中间件却充满了魔力。
坦率地说，每当你遇到一个系统或组件做“令人惊奇的事情”并且你想知道“他们是如何做到这一点”时，它就是神奇的。
Ruby on Rails, for example, is Magic.
At the basic level, especially when approached naively, there's a big thick layer between your minimalist code and the database, and then Magic Happens, and you get crud functionality and all the rest.
Some folks can live with that very high level experience, but eventually you'll start running in to barriers where you need to understand the "secret" of the "trick", so you can manipulate it betters towards your end.
Languages themselves don't have a lot of Magic (well, maybe Prolog -- it's core is somewhat magical), but the modern frameworks and middleware can be chock full of it.
Frankly, anytime you encounter a system or component that does "something amazing" and you wonder "how do they do that", it's magic.
有趣的是：术语“魔法”与正式编程语言相关，它是计算机科学的理论基础之一。 在 Morgan 的《Programming fromSpecifications》一书中，我们对魔法有这样的定义：
这个符号的形式如下：
表示一个程序，当在
P为 true 的状态下执行时，将终止于状态Q为 true，同时仅更改w中的变量。在这种情况下，“魔法”是一种不可行的程序，它可以将程序从任何状态（因为
true总是true）转变为不可能的状态（因为false永远不可能是true）。一个更简单的程序是：
这是一个总是终止的程序，但不保证特定的结果。 这可以通过简单的
skip来实现。显然，当人们谈论“神奇”程序时，这个技术定义已经被滥用了，因为这应该意味着一个被证明不可行的程序。 尽管如此，这个术语仍然是通俗的，因为当我们不知道或不理解某些东西是如何工作时，想象在幕后发生一些神奇的事情是很好的。
An interesting aside: the term
magicis linked to formal programming languages, which are one of the theoretical foundations of computer science. In Morgan's book "Programming from Specifications", we have this definition of magic:This notation is of the form:
and represents a program that, when executed in a state where
Pis true, will terminate in a state whereQis true, whilst changing only the variables inw.In this context, then, "magic", is an infeasable program that can take a program from any state (since
trueis alwaystrue) into one that is impossible (sincefalsecan never betrue).A much easier program is :
which is the program that always terminates, but guarantees no particular result. This can be implemented with a simple
skip.Obviously, this technical definition has been abused when people talk of
magicprograms, since this ought to mean a program that is provably infeasible. Nevertheless, the term remains colloquially, since it's nice to imagine that something magical happens behind the scenes when we don't know, or understand how something works.当你不理解某件事时，你称它为“魔法”。
在中世纪，当人们做了/知道/说了一些其他人无法理解的事情时，他们就会被烧死。 他们被指控施展“魔法”。
当你不明白代码/框架/语言的作用时，你会称其为“魔法”。 称某些东西为“魔法”比花时间去理解它更容易。
魔法不存在！
不要称某些东西为“魔法”，而是要亲自动手并了解它在做什么……或者称其为“（您的）知识中未探索的部分”。
You call something "magic" when you don't understand it.
People were used to be burned in middle ages when they where doing / knowing / saying something, that the rest of men coundn't understand. They were accused of doing "magic".
You call code / framework / language a "magic" when you don't understand what it does. It's easier to call something "magic" than to spend time to understand it.
Magic Does Not Exist!
Instead of calling something "magic" get your hands dirty and understand what that thing is doing... Or call it "unexplored part of (your) knowledge".
对于 Java
For Java
未知行为经常被称为魔法。 有些事情的发生没有明显的原因。
但也存在未知之王：
开发人员缺乏对事物如何运作的了解。 （例如 GC，它并不神奇，只是太少的开发人员实际上费心去找出并理解它的基础）
未定义的行为魔法，事情发生在幕后，并且没有公众了解它们实际上是如何工作的。 这是编程中真正的魔力。
例如 Rails，它不是魔法，Ruby 也不是魔法，但对于某些人来说，如果他们从不费心去了解其内部原理（这是公共知识并且可用），那么对于他们来说，它肯定可能看起来如此。
Unknown behavior is very often spoken of as magic. Some things happen for no apparent reason.
But there are tho kings of unknown:
The lack of knowledge on the developers side on how things work. (For example GC, it's not magic, just too few developers actually have bothered to find out and understand it's underpinnings)
Undefined behavior magic, where things happen behind the curtains and there's no public knowledge on how they actually work. This is the true magic in programming.
For example Rails, it's not magic and Ruby is not magic, but it certainly may seem so for some of people if they never bothered to understand the internals (which are public knowledge and available).
我使用术语“黑魔法”的一个上下文是字节码操作（在 Java 中）——在运行时转换程序代码，使其执行与纯代码不同的操作。 很多时候，字节码操作非常有用，但也很容易搬起石头砸自己的脚。
许多框架和中间件使用 AOP 和字节码操作来实现横切关注点。 这减少了程序员的工作量，但在某些情况下可能会使调试系统的行为变得困难。 而且字节码转换中很容易残留一些细微的错误。
我自己做过一些字节码操作，所以基本上我知道如何更改字节码指令，从这个意义上说，这对我来说并不是“魔法”，我不会理解它是如何工作的。 但我仍然将其称为“魔法”，因为它改变了代码正常工作的方式，并且在被更改的类的源代码中不可见。
One context where I use the term "black magic" is bytecode manipulation (in Java) - transforming the program code at runtime so that it does something different than what the plain code would do. Often times bytecode manipulation is very useful, but it's also very easy to shoot yourself in the foot with it.
Many frameworks and middleware use AOP and bytecode manipulation to implement cross-cutting concerns. This reduces the programmers work, but in some situations it may make debugging the behaviour of the system hard. And it's easy to have some subtle bugs remain in the bytecode transformations.
I have done some bytecode manipulation myself, so basically I know how the bytecode instructions can be changed and it's not "magic" to me in that sense, that I would not understand how it works. But still I refer to it as "magic", because it changes the way the code normally works and is not visible in the source code of the classes being changed.
有关黑魔法的一些很好的示例，请查看 Perl 源代码中的文档;-)
For some nice examples of black magic, look at the documentation in the perl source code ;-)
行话文件附录中的经典魔法故事。
http://catb.org/jargon/html/magic-story.html
去读吧。
The classic magic story from the jargon file appendix.
http://catb.org/jargon/html/magic-story.html
go read it.