我与一位友好的程序员发生了争执，他受到了 Joel 的泄漏抽象定律的轻微损害。很难说服他使用任何新的框架/工具箱。我试图提出一个观点，即“只要允许对抽象级别的低级访问，抽象就可以了”。
例子：
好听吗？我错过了什么吗？
谢谢
我从阅读泄漏抽象文章中得到的并不是抽象是不好的，而是您应该重点了解幕后发生的事情，以便您可以解释“意外”行为并避免它们。
你朋友的程序是什么？机器语言？:)
Joel 的观点（据我所知）是，通过抽象复杂性，您牺牲了对潜在复杂性的更好控制。除了微不足道的情况外，您最终将需要访问更精细的控制粒度，此时抽象会崩溃。
因此，根据定义，所有抽象（几乎）都是泄漏的：
To some extent he has a point. Traditional c/unix development works to a platform that is simple enough to be able to understand more-or-less in its entirety. Modern platforms are orders of magnitude more complex, and understanding how all of the layers interact is much harder, often infeasible.
The law of leaky abstractions mainly applies when the framework does a bad job of managing the underlying complexity. Some of the ways in which a framework may be judged are its transparency (ease of understanding what's going on behind the scenes) and its ability to drop out to a custom workaround for limitations in its functionality.
When a framework does a lot of complex magic behind the scenes, diagnosing and troubleshooting become much harder, often requiring a disproportionately large amount of expertise in the underlying architecture of the framework. This means that productivity gains from the framework get absorbed in the extra effort of training and debugging the code. It also makes the framework difficult to learn and use with confidence, which is what your C programming friend is used to.
When a framework obstructs you from working around its limitations, then it becomes an impediment to development. When this happens often enough, the code base is either boxed in or becomes polluted with ever greater and messier hacks to work around the issues. This also leads to stability and debugging problems,
Examples of frameworks with these flaws abound. MFC was quite famous for failing to hide the underlying complexity of Win32. It also made extensive use of wizards that generated messy code that needed to be manually modified aftwrwards, defeating the purpose of having a code generator in the first place. Early Java GUI toolkits (AWT and early versions of Swing) have very little uptake in desktop applications because they obstructed developeers from implementing a native look-and-feel for the applications. SWT was built in no small part because of these limitations with Swing.
However, now Java has matured a bit, it could be argued that most of its early sins have been fixed in modern frameworks. J2EE is still a large, complex system, and developing a non-triviall user interface in a browser is also quite a substantial undertaking. Becoming proficient in this platform is quite a lot of work. However, it's not beyond the wit of man.
虽然我认为每个抽象都是有漏洞的，但这并不一定是坏事。
例如，在传统的纯 C（C#、Java 等）代码中，您通常使用循环、ifs 等从数组中检索数据。但这样您就过度指定了问题的解决方案。
SQL、Linq 处理相同问题的方式更加智能：你只要说出你想要的，机器就会计算出如何去做。这样，它就没有传统方式的任何特定命令排序，并且可以将工作拆分到不同的 cpu 上，或者重新排序以更好地利用缓存等。
所以是的，你给了机器一些控制权，但是机器比你有一个很大的优势：它在用户/客户的位置，这样可以做出按需决策（比如使用多核，利用 MMX 的优势，无论如何）。