First of all, abstractions are inevitable because they help us to deal with the mind-blowing complexity of things.
Abstractions are also inevitable because it is more and more required of an individual to undertake more tasks or even complete projects. To address the problem, one uses libraries which wrap lower-level concepts and expose more complex behavior.
Naturally, a developer has less and less time to know the intrinsics of the things. The latest concern I heard about on SO pages is starting to learn JavaScript with jQuery library, ignoring the raw JavaScript at all.
The issue is about the balance between:
Know the little tiniest details of some technology and be a master of it, but at the same time being unable to work with anything else.
Superficial knowledge of a wide variety of technologies and tools which however proves sufficient for common everyday tasks which allows an individual to perform in multiple areas possibly covering all sides of some (moderately big) project.
Take your pick.
Some work requires the one, another position requires the other.
So, in you're opinion, how important is it that programmers actually know what is going below the abstractions?
It would be nice if people knew what is happening behind the scenes. This knowledge comes with time and practice, up to a certain degree. Depends on what kind of tasks you have. You certainly shouldn't blame people for not knowing everything. If you wish a person to be able to perform in a variety of fields, it is inevitable he won't have time to cover each up to the last bit.
What is essential, is the knowledge of the basic building blocks. Data structures, algorithms, complexity. That should provide a basis for everything else.
Knowing tiniest details of some particular technology is good, but not essential. Anyway, you can't learn them all. They're too many and they keep coming.
Finally, what do you think about the issue that schools are preferring to teach Java instead of C and Lisp ?
Schools shouldn't be teaching programming languages at all. They're to teach basics of theoretical and practical CS, social skills, communication, team work. To cover a vast variety of topics and problems to provide a wide angle view for their graduates. This will help them to find their way. Whatever they need to know in details, they'll do it on their own.
In this case, a piece of software was needed to communicate to many different third party data processors. The communication was done through various messaging protocols; the transport method/protocol is not important in this case. Just assume everyone communicated through messaging.
The idea was to abstract the features of each of these third parties into a single, unified message format. It seemed relatively straightforward because each of the third parties performed a similar service. The problem was that some third parties used different terms to explain similar features. It was also found that some third parties had additional features that other third parties did not have.
The designers of the abstraction did not see through the difference of third party terms nor did they think it was reasonable to limit the scope of the unified features to only support the common features of the third parties. Instead, a single, monolithic message schema was developed to support any and all features of the third parties considered at the time. In what was probably considered a future-proofing move, they added a means of also passing an infinite number of name/value pairs along with the monolithic message in case there were future data elements that the monolithic message could not handle.
Early on, it became clear that changing the monolithic message was going to be difficult due to so many people using it in mission critical systems. The use of the name/value pairs increased. Each name that could be used was documented inside a large spreadsheet, and developers were required to consult the spreadsheet to avoid duplication of name value function. The list got so large, however, that it was found that there were frequently collisions in purposes of name values.
The majority of the monolithic message's fields now have no purpose and are kept mainly for backwards compatibility. There are name values that can be used to replace fields in the monolithic message. The majority of the interfacing is now done through the name/value pairs. In cases where the client is intending to communicate with more than one third party, each client needs to reconcile the name values available for each third party. It would be almost simpler to interface directly to the third party themselves.
I believe this illustrates that, from a consumer of the monolithic message perspective, that it is important that developers of the consuming code not know what is happening under the covers. If the designers had considered that the consumers of the monolithic message should not have to understand the abstraction in great detail, the monolithic message and it's associated name/value pairs might never have happened. Documenting the abstraction with assertions regarding input and expected output would make life so much simpler.
As for colleges not teaching C and Lisp....they are cheating the students. You get a better understanding of what is going on with the machine and OS with C. You get a bit of a different perspective on processing data and approaching problems with Lisp. I have used some of the ideas I learned using Lisp in programs written in C, C++, .Net, and Java. Learning Java after knowing even just C is not very difficult. The OO part is really not programming language specific, so perhaps using Java for that is acceptable.
An understanding of fundamentals of algorithms (e.g. time complexity) and some knowledge about the metal is essential to designing/writing smells-good code.
I would suggest, though, that just as important is education in modern abstractions and profiling. I feel that modern abstractions make me so much more productive than I would be without them that they are at least as important as good fundamentals, if not more so.
An important element that lacked in my education was the use of profilers. When used routinely and correctly, profilers can help mitigate problems with poor fundamentals.
The term "astronaut architecture" is a reaction to over-abstraction.
I know I certainly curse abstraction when I haven't touched Java or C# in a while and i want to write to a file, but have to instance a Stream...Writer...Adaptor....Handler....
Also, Patterns, as in Gang Of Four. Seemed great when I first read about them in the mid-90's, but can never remember factory, facade, interface, helper, worker, flyweight....
发布评论
评论（4）
首先，抽象是不可避免的，因为它们帮助我们处理事物的令人兴奋的复杂性。
抽象也是不可避免的，因为越来越需要个人承担更多的任务甚至完成项目。为了解决这一问题，人们使用了包含较低级别概念并公开更复杂行为的库。
当然，开发人员了解事物本质的时间越来越少。我在 SO 页面上听到的最新关注是开始使用 jQuery 库学习 JavaScript，而完全忽略原始 JavaScript。
问题在于以下两者之间的平衡：
了解某些技术的最微小的细节并成为它的大师，但同时无法使用其他任何技术。
对各种技术和工具的肤浅了解，但事实证明，这些知识足以完成常见的日常任务，使个人能够在多个领域执行任务，可能涵盖某些（中等规模）项目的各个方面。
任你挑选。
有些工作需要其中一个，而另一个职位则需要另一个。
如果人们知道幕后发生的事情那就太好了。这些知识在一定程度上是随着时间和实践而来的。取决于您有什么类型的任务。你当然不应该责怪人们不知道一切。如果你希望一个人能够涉足多个领域，那么他难免没有时间去深入了解每一个领域。
至关重要的是基本构件的知识。数据结构、算法、复杂性。这应该为其他一切提供基础。
了解某些特定技术的最微小的细节是好的，但不是必需的。无论如何，你不可能全部学会。他们太多了，而且还在不断地涌来。
学校根本不应该教授编程语言。他们教授计算机科学的理论和实践基础知识、社交技能、沟通和团队合作。涵盖各种各样的主题和问题，为毕业生提供广阔的视角。这将帮助他们找到自己的路。无论他们需要详细了解什么，他们都会自己做。
First of all, abstractions are inevitable because they help us to deal with the mind-blowing complexity of things.
Abstractions are also inevitable because it is more and more required of an individual to undertake more tasks or even complete projects. To address the problem, one uses libraries which wrap lower-level concepts and expose more complex behavior.
Naturally, a developer has less and less time to know the intrinsics of the things. The latest concern I heard about on SO pages is starting to learn JavaScript with jQuery library, ignoring the raw JavaScript at all.
The issue is about the balance between:
Know the little tiniest details of some technology and be a master of it, but at the same time being unable to work with anything else.
Superficial knowledge of a wide variety of technologies and tools which however proves sufficient for common everyday tasks which allows an individual to perform in multiple areas possibly covering all sides of some (moderately big) project.
Take your pick.
Some work requires the one, another position requires the other.
It would be nice if people knew what is happening behind the scenes. This knowledge comes with time and practice, up to a certain degree. Depends on what kind of tasks you have. You certainly shouldn't blame people for not knowing everything. If you wish a person to be able to perform in a variety of fields, it is inevitable he won't have time to cover each up to the last bit.
What is essential, is the knowledge of the basic building blocks. Data structures, algorithms, complexity. That should provide a basis for everything else.
Knowing tiniest details of some particular technology is good, but not essential. Anyway, you can't learn them all. They're too many and they keep coming.
Schools shouldn't be teaching programming languages at all. They're to teach basics of theoretical and practical CS, social skills, communication, team work. To cover a vast variety of topics and problems to provide a wide angle view for their graduates. This will help them to find their way. Whatever they need to know in details, they'll do it on their own.
抽象失败的示例：
在这种情况下，需要一个软件来与许多不同的第三方数据处理器进行通信。通信是通过各种消息传递协议完成的；在这种情况下，传输方法/协议并不重要。假设每个人都通过消息进行交流。
这个想法是将每个第三方的特征抽象为一个统一的消息格式。这看起来相对简单，因为每个第三方都提供类似的服务。问题是一些第三方使用不同的术语来解释相似的功能。我们还发现，一些第三方具有其他第三方所没有的附加功能。
抽象的设计者没有看到第三方术语的差异，也不认为将统一特征的范围限制为仅支持第三方的共同特征是合理的。相反，开发了一个单一的整体消息模式来支持当时考虑的第三方的任何和所有功能。在可能被认为是面向未来的举措中，他们添加了一种方法，可以将无限数量的名称/值对与整体消息一起传递，以防未来出现整体消息无法处理的数据元素。
早期，很明显，由于有太多人在关键任务系统中使用单一消息，因此更改单一消息将会很困难。名称/值对的使用有所增加。每个可以使用的名称都记录在一个大型电子表格中，开发人员需要查阅电子表格以避免名称值函数的重复。然而，该列表变得如此之大，以至于人们发现名称值的用途经常发生冲突。
大多数整体消息字段现在没有任何用途，保留主要是为了向后兼容。有一些名称值可用于替换整体消息中的字段。现在大部分接口都是通过名称/值对完成的。如果客户端打算与多个第三方进行通信，则每个客户端都需要协调每个第三方可用的名称值。直接与第三方交互几乎会更简单。
我相信这说明，从单一消息的消费者角度来看，消费代码的开发人员不知道幕后发生了什么，这一点很重要。如果设计者认为整体消息的使用者不应该必须非常详细地理解抽象，那么整体消息及其关联的名称/值对可能永远不会发生。用有关输入和预期输出的断言记录抽象将使生活变得更加简单。
至于那些不教授 C 和 Lisp 的大学……他们是在欺骗学生。使用 C 语言，您可以更好地了解机器和操作系统的运行情况。使用 Lisp，您可以从不同的角度来处理数据和解决问题。我在用 C、C++、.Net 和 Java 编写的程序中使用了使用 Lisp 学到的一些想法。即使只了解 C，学习 Java 也不是很困难。 OO 部分确实不是特定于编程语言的，因此也许使用 Java 是可以接受的。
An example where abstraction has failed:
In this case, a piece of software was needed to communicate to many different third party data processors. The communication was done through various messaging protocols; the transport method/protocol is not important in this case. Just assume everyone communicated through messaging.
The idea was to abstract the features of each of these third parties into a single, unified message format. It seemed relatively straightforward because each of the third parties performed a similar service. The problem was that some third parties used different terms to explain similar features. It was also found that some third parties had additional features that other third parties did not have.
The designers of the abstraction did not see through the difference of third party terms nor did they think it was reasonable to limit the scope of the unified features to only support the common features of the third parties. Instead, a single, monolithic message schema was developed to support any and all features of the third parties considered at the time. In what was probably considered a future-proofing move, they added a means of also passing an infinite number of name/value pairs along with the monolithic message in case there were future data elements that the monolithic message could not handle.
Early on, it became clear that changing the monolithic message was going to be difficult due to so many people using it in mission critical systems. The use of the name/value pairs increased. Each name that could be used was documented inside a large spreadsheet, and developers were required to consult the spreadsheet to avoid duplication of name value function. The list got so large, however, that it was found that there were frequently collisions in purposes of name values.
The majority of the monolithic message's fields now have no purpose and are kept mainly for backwards compatibility. There are name values that can be used to replace fields in the monolithic message. The majority of the interfacing is now done through the name/value pairs. In cases where the client is intending to communicate with more than one third party, each client needs to reconcile the name values available for each third party. It would be almost simpler to interface directly to the third party themselves.
I believe this illustrates that, from a consumer of the monolithic message perspective, that it is important that developers of the consuming code not know what is happening under the covers. If the designers had considered that the consumers of the monolithic message should not have to understand the abstraction in great detail, the monolithic message and it's associated name/value pairs might never have happened. Documenting the abstraction with assertions regarding input and expected output would make life so much simpler.
As for colleges not teaching C and Lisp....they are cheating the students. You get a better understanding of what is going on with the machine and OS with C. You get a bit of a different perspective on processing data and approaching problems with Lisp. I have used some of the ideas I learned using Lisp in programs written in C, C++, .Net, and Java. Learning Java after knowing even just C is not very difficult. The OO part is really not programming language specific, so perhaps using Java for that is acceptable.
了解算法的基础知识（例如时间复杂度）和一些有关金属的知识对于设计/编写良好的代码至关重要。
不过，我建议，现代抽象和分析方面的教育同样重要。我觉得现代抽象使我比没有它们时更有效率，它们至少与良好的基础知识一样重要，甚至更重要。
我的教育中缺乏的一个重要元素是分析器的使用。如果定期正确使用，分析器可以帮助缓解基础较差的问题。
An understanding of fundamentals of algorithms (e.g. time complexity) and some knowledge about the metal is essential to designing/writing smells-good code.
I would suggest, though, that just as important is education in modern abstractions and profiling. I feel that modern abstractions make me so much more productive than I would be without them that they are at least as important as good fundamentals, if not more so.
An important element that lacked in my education was the use of profilers. When used routinely and correctly, profilers can help mitigate problems with poor fundamentals.
既然你引用了乔尔·斯波尔斯基的话，我想你知道他的“抽象泄漏法则”吗？我会为未来的读者提及它。 http://www.joelonsoftware.com/articles/LeakyAbstractions.html
绿色和绿色布莱克威尔的抽象的讽刺谈到了学习抽象的努力。 http://homepage.ntlworld.com/greenery/workStuff/Papers/index.html html
“宇航员架构”一词是对过度抽象的反应。
我知道当我有一段时间没有接触 Java 或 C# 并且我想写入文件，但必须实例化 Stream...Writer...Adaptor....Handler.... 时，我当然会咒骂抽象。
另外，还有《四人帮》中的模式。当我在 90 年代中期第一次读到它们时，看起来很棒，但永远记不起工厂、门面、界面、助手、工人、蝇量......
Since you quote Joel Spolsky, I take it your aware of his "Law of Leaky Abstractions"? I'll mention it for future readers. http://www.joelonsoftware.com/articles/LeakyAbstractions.html
Green & Blackwell's Ironies of Abstractions talks a bit about the effort of learning the abstraction. http://homepage.ntlworld.com/greenery/workStuff/Papers/index.html
The term "astronaut architecture" is a reaction to over-abstraction.
I know I certainly curse abstraction when I haven't touched Java or C# in a while and i want to write to a file, but have to instance a Stream...Writer...Adaptor....Handler....
Also, Patterns, as in Gang Of Four. Seemed great when I first read about them in the mid-90's, but can never remember factory, facade, interface, helper, worker, flyweight....