系统复杂性的增加如何影响连续几代程序员？

作为一名“新”程序员（我于2009年首次写了一行代码），我注意到创建一个程序时相对容易，该程序现在可以显示诸如.NET框架之类的非常复杂的元素。现在，只需很少的命令即可创建可视界面或对列表进行排序。

在学习编程的同时，我也在并行学习计算理论。诸如排序算法，硬件如何协同工作的原理，布尔代数和有限状态机之类的东西。但是我注意到，如果我想测试我从理论上学到的一些非常基本的原理，那么入门总是要困难得多，因为很多技术被诸如库，框架和操作系统之类的东西所遮盖。

40/50年前就需要制作一个内存有效的程序，因为内存不足，而且价格昂贵，因此大多数程序员都密切关注数据类型以及处理器如何处理指令。如今，有些人可能会争辩说，由于处理能力和可用内存的增加，这些问题已不再是重点。

我的问题是，年长的程序员是否将此类创新视为天赐之物或抽象的附加层，为什么他们会这样认为？在探索扩展库领域之前，年轻的程序员是否会从学习低级编程中受益？如果是这样，那为什么呢？

只是因为处理能力和可用内存的增加而没有必要。

拥有廉价的内存，巨大的磁盘和快速的处理器并不是使人们摆脱对每个字节和每个周期的困扰的唯一原因。现在，编译器在产生至关重要的情况下产生高度优化的代码方面远比人类好得多。

此外，我们不要忘记我们实际上要优化的内容，这是在给定成本下产生的价值。程序员比机器贵得多。我们所做的任何使程序员能够更快，更便宜地生成有效，正确，健壮，功能齐全的程序的方法，可以在世界上创造更多的价值。

我的问题是，人们对这种“低层”元素的“隐藏”感觉如何。您年龄较大的程序员是否将其视为天赐之物或不必要的工作？

完成任何工作都是绝对必要的。我写代码分析器为生；如果我不得不担心寄存器分配或处理器调度或数百万其他详细信息中的任何一个，那么我就不会花费时间来修复错误，查看性能报告，添加功能等等。

所有的编程工作都是要抽象掉您下面的层，以便在它上面形成更有价值的层。如果您做一个“层蛋糕图”来显示所有子系统以及它们如何相互构建，您会发现在硬件和用户体验之间确实有几十个层。我认为在Windows层蛋糕图中，原始硬件和在C＃中执行“ hello world”的能力之间大约有60个级别的必要子系统。

您认为年轻的程序员在探索扩展库领域之前会从中学习更多的低级编程受益吗？

您强调之前，所以我必须否定回答您的问题。我正在帮助一个12岁的朋友现在开始学习编程，您最好相信我是在Processing.js中而不是x86汇编程序中启动它们的。如果您以某种类似的方式开始年轻的程序员，Processing.js他们将在大约八小时内编写自己的射击游戏。如果您在汇编器中启动它们，它们将在大约八个小时内将三个数字相乘。您认为哪个更可能引起年轻程序员的兴趣？

现在的问题是：“了解蛋糕第n层的程序员是否会从了解n-1方面受益？” 答案是肯定的，但这与年龄或经验无关。通常情况下，您可以通过更好地理解底层抽象来改进高级编程。

我有关于这个主题的想法，并将它们写在20年前的书中。它已经绝版了，但是您仍然可以在Amazon上获取二手副本。

一个简单的答案就和亚里斯多德一样古老：自然讨厌真空。就像机器变得越来越快越来越大，软件变得越来越慢越来越大。

为了更具建设性，我提出的是信息理论及其与软件的直接相关性，应成为计算机科学教育的一部分。现在只是以非常切线的方式进行授课。

例如，如果您将程序视为具有输入符号，输出符号，噪声，冗余和带宽的香农类型信息通道，则可以非常整洁直观地理解算法的big-O行为。

另一方面，可以使用Kolmogorov信息论以类似的术语来理解程序员的生产力。输入是大脑中的符号概念结构，输出是通过指尖显示的程序文本。编程过程是两者之间的通道。当噪声进入过程时，它将创建不一致的程序（错误）。如果输出程序文本具有足够的冗余性，则可以允许捕获并纠正错误（错误检测和纠正）。但是，如果它太冗余，它就会太大，并且它的大小以及错误率会导致引入错误。由于这种推理，我在本书中花了很多时间来展示如何将编程视为语言设计的过程，目的是能够定义适合需要的领域特定语言。在CS教育中，我们确实对特定领域的语言提供口头服务，但这又是切线的。

建立语言很容易。每次定义函数，类或变量时，都将词汇表添加到开始使用的语言中，从而创建一种新的工作语言。通常不能理解的是，目标应该是使新语言更接近问题的概念结构。如果这样做了，那么它的作用就是缩短代码并减少错误，这仅仅是因为理想情况下，概念和代码之间存在1-1映射。如果映射为1-1，您可能会犯错，并且将一个概念错误地编码为另一个概念，但是该程序将永远不会崩溃，这是当它不对一致的要求进行编码时会发生的情况。

我们没有得到这个。在我们所有关于软件系统设计的勇敢讨论中，代码与需求的比例越来越大。

是的，我们有非常有用的库。但是，我认为我们应该对抽象非常谨慎。我们不应该假设B是否建立在A上，那就好，如果C建立在B上，那就更好了。我称之为“公主与豌豆”现象。在麻烦的事物上堆积图层不一定能解决问题。

为了结束一篇长篇文章，我开发了一种编程风格（有时会给我带来麻烦），

• 发明不是一件坏事。就像在其他工程部门一样，这是一件好事。当然，这可能会为其他人创造学习曲线，但是如果总体结果是提高生产率，那是值得的。
• Haiku风格的极简代码。这尤其也适用于数据结构设计。以我的经验，当今软件的最大问题是过大的数据结构。

高级抽象对于实现计算的持续进步至关重要。

为什么？因为在任何给定时刻，人类只能在大脑中拥有如此多的知识。现代的大规模系统仅在今天才有可能，因为您可以利用这种抽象。没有这些抽象，软件系统将在自身的负担下崩溃。

每次编写方法时，都在创建一个抽象。您正在创建一些隐藏在方法调用后面的功能。你为什么写它们？因为您可以测试该方法，证明它可以工作，然后在任何需要的时候通过调用该方法就可以调用该功能，而不必再考虑该方法内部的代码。

在计算的早期，我们使用机器语言。我们编写了很小的裸机程序，对我们要为其编写的硬件有深入的了解。这是一个艰苦的过程。没有调试器。您的程序通常可以运行，或者崩溃。没有图形用户界面；一切都是命令行或批处理过程。您编写的代码只能在该特定计算机上运行；它不能在具有不同处理器或操作系统的计算机上运行。

因此，我们编写了高级语言来抽象所有这些细节。我们创建了虚拟机，以便我们的程序可以移植到其他计算机上。我们创建了垃圾回收，以便程序员不必在管理内存方面如此勤奋，从而消除了一整类棘手的错误。我们在语言中添加了边界检查功能，以使黑客无法利用缓冲区溢出来利用它们。我们发明了函数式编程，以便我们可以以其他方式推理程序，并在最近重新发现了它，以更好地利用并发性。

所有这些抽象是否使您与硬件隔离？当然可以。住在房子里而不是搭帐篷会使您与自然隔绝吗？绝对。但是每个人都知道为什么他们住在房子而不是帐篷里，而盖房子与投帐篷完全不同。

但是，您仍然可以在有必要时搭起帐篷，并且在编程时，您可以（如果您很愿意）下降到更接近硬件的水平，以获取可能无法获得的性能或内存优势否则，请使用您的高级语言。

您可以抽象太多吗？斯科蒂会说：“超越管道” ？当然可以。编写好的API很难。编写以直观，可发现的方式正确，全面地体现问题域的良好API变得更加困难。堆放在新的软件层上并不总是最好的解决方案。 软件设计模式在某种程度上使这种情况变得更糟，因为缺乏经验的开发人员有时会在更精简，更精简的工具更合适时找到他们。

真正好的培训既涉及极端，也涉及两者之间的桥梁。

从低端看：计算机如何从头开始执行代码，包括汇编语言知识以及编译器在做什么。

从高级的角度来看：一般概念，例如使用关联数组，闭包等，而不必浪费时间担心它在后台的工作方式。

恕我直言，每个人都应具有两者的经验，包括其缺点，以及如何从低级概念过渡到高级概念的经验。喜欢关联数组吗？太好了，现在尝试在具有1kB RAM的50美分嵌入式处理器上使用它们。喜欢使用C编写快速代码吗？太好了，现在您有三个星期的时间来编写网络应用程序；您可以花时间使用C处理数据结构和内存管理，也可以花时间学习新的Web框架，然后在几天内实现Web应用程序。

就复杂性而言：我确实认为，如今在不清晰地了解这样做成本的情况下，制造复杂的系统太容易了。结果，作为一个社会，我们积累了大量的技术债务，这些债务时不时地困扰着我们。这就像地震（只是生活在地质断层附近的代价，对不对？），只是它逐渐变得越来越糟。而且我不知道该怎么办。理想情况下，我们会学习并在管理复杂性方面变得更好，但是我认为这不会发生。负责任的工程​​教育需要比当前大多数大学提供更多有关复杂性后果的讨论。

*而且，无论如何，计算机执行代码的“基础”在哪里？它是汇编语言吗？还是计算机架构？还是数字逻辑？还是晶体管？还是设备物理学？

我认为高级编程具有许多优点，并且是编程语言的重要组成部分。Java取得成功的原因之一是它具有完善的库。您可以用更少的代码获得更多收益-只需调用预定义函数即可。

现在，我们可以将编程语言用户与编程语言作者（编译器作者）区分开。我们将优化留给编译器作者。我们更多地关注可维护性，重用性等

系统复杂性的增加是无情的，令人压迫的，最终是残酷的。对于我作为老一辈的程序员来说，这也令人非常失望。

我从事编程已经40多年了，用50-100种不同的语言或方言编写了代码，并成为5-10的专家。我之所以能说很多的原因是，大多数情况下它们只是同一种语言，但有一些调整。这些调整增加了复杂性，使每种语言都略有不同。

我已经实现了无数次相同的算法：收集，转换，排序和搜索，编码/解码，格式/解析，缓冲区和字符串，算术，内存，I / O。每个新的实现都会增加复杂性，因为每个实现都有点不同。

我想知道Web框架和移动应用程序的高飞空中飞人艺术家创造的魔力，如何在如此短的时间内产生如此美丽的东西。然后，我意识到他们不知道多少，他们将需要多少知识来学习数据或通信，测试或线程，或者在它们变得有用之前需要做什么。

我在第四代语言时代学到了我的手艺，我们真正地相信我们会产生一系列越来越高级的语言，以逐步捕获越来越多的写作软件的重复部分。那么结果如何呢？

微软和IBM通过返回C语言为Windows和OS / 2编写应用程序来终结了这个想法，而dBase / Foxpro甚至Delphi都陷入了困境。然后，网络再次使用其最终的三大汇编语言：HTML，CSS和JavaScript / DOM再次实现了这一目标。从那里到那里都是下坡路。总是会有更多的语言，更多的库，更多的框架和更多的复杂性。

我们知道我们应该做不同的事情。我们了解CoffeeScript和Dart，了解Less和Sass，了解避免编写HTML的模板。我们知道，而且我们还是这样做。我们拥有我们的框架，充满了抽象的漏洞，我们看到了那些学习奥秘咒语的少数人可以做些什么，但是我们和我们的程序被过去的决策所困。它太复杂了，无法更改或重新开始。

结果是，由于复杂性，本来应该容易的事情并不容易，而应该可能的事情几乎是不可能的。我可以估算进行更改以在已建立的代码库中实施新功能的成本，并且确信我会做对的。我可以估算，但是我不能证明或解释它。它太复杂了。

在回答您的最后一个问题时，我强烈建议年轻的程序员尽可能地从高层次开始，并仅在需求和欲望提供推动力时才跳到较低层次。我的首选语言是没有循环，几乎没有分支或没有显式状态的语言。Lisp和Haskell浮现在脑海。在实践中，我总是以C＃/ Java，Ruby，Javascript，Python和SQL为结尾，因为这就是社区所在的地方。

最后一句话：复杂性是最终的敌人！击败它，生活变得简单。

我的问题是，人们对这种“低层”元素的“隐藏”感觉如何。您年龄较大的程序员是否将其视为天赐之物或不必要的工作？

两者都不是。

分层是必要的，因为没有分层，您将达到系统无法维护的意大利面的地步。这也是可重用性的宗旨之一：如果库的开发人员做得很好，那么使用它的人就不必关心实现的细节。与35年前我编写第一个程序时相比，我们在系统中使用的固定代码的数量已经增加了一定程度。随着时间的流逝，这种增长意味着我们能够做更强大的事情。很好

对我来说一直是个问题的地方完全是文化上的。我务实的那半人明白，不再可能将我的思绪束之高阁，无法完成我想完成的事情。（变老也无济于事。）我那残酷的灰胡须一半很难让我多年对我所做的一切都有如此细致的了解。

您认为年轻的程序员在探索扩展库领域之前会从中学习更多的低级编程受益吗？

正如在其他答案中指出的那样，在吸引和保持新手的注意力以及为他们提供理想的，自下而上的教育之间要取得平衡。如果您做不到前者，那么后者就不会发生。

我看到我们行业中与其他社会平行的事物。过去几乎每个人都自己种植食物，并花大量时间这样做。从那时起，我们萌芽了称为农民的专家，他们从事这项工作，使其他人腾出更多精力去做对社会有贡献的事情。我在杂货店买菜，如果需要的话，我将完全无法自行生产大部分食物。我们正在进行类似的事情，尽管压缩的时间要多得多。程序员专门研究某些层而不是其他层。一般编写GUI的人可能知道交换空间之类的东西，但可能并不了解或不太关心操作系统如何对其进行管理。

所有这些的结果是，它不再仅仅是开发。持续的专业化意味着开发人员将需要继续提高他们的沟通和集成技能。

与一切一样，一点点都对您有好处，但会带来太多伤害。问题是太多的系统不知道什么时候停止-只是多了一种抽象，可以帮助您更快地进行编程...但是您最终会在现实世界中进行编码，在现实世界中，事情从来都不像您想要的那么简单，与没有特色的抽象相比，花在边缘工作上的时间更多。

它在这里恰当地描述

或这里 -“使用单行代码，您可以将500个用户添加到域中” ...

您的抽象试图向您隐藏复杂性，但实际上他们所做的只是隐藏了这种复杂性。复杂性仍然存在，只是您对它的控制要少得多，这就是为什么您会遇到这种情况。

在探索扩展库领域之前，年轻的程序员是否会从更多的学习低级编程中受益？如果是这样，那为什么呢？

我不这么认为。在很多情况下，了解“下一层”作品的好处是有益的，例如

• 在调试层上的问题时n，通常可以通过考虑在层n-1（即下一层）上发生的事情来进行解释。我猜第0层将是“晶体管”，但是如果您要解释晶体管的问题，则可能会谈到物理（例如，热），因此物理也许确实是第0级。

• 优化代码时（不幸的是）有时确实有助于降低抽象级别，即以较低级别的层实现算法。然而，编译器变得真的在这样做对你有好处，如果他们真的看到所有相关的代码。最近，随着移动和嵌入式设备的兴起，这个原因变得越来越流行，移动设备和嵌入式设备的处理器往往性能较弱，并且“每瓦性能”比台式机更重要。

但是，总的来说，使计算机做事变得容易得多（即使使用效率稍低的方式），这意味着程序员比以前要多得多。反过来，这又使“人”的因素变得更加重要：罗伯特·哈维（Robert Harvey）的答案已经提到“人在任何特定时刻只能拥有如此多的知识”，我认为这是当今非常重要的一个方面。

编程语言和库（即API）设计的主要动机是使人的大脑变得更容易。直到今天，所有内容仍被编译为机器代码。但是，这不仅容易出错，而且众所周知也很难理解。所以这是非常可取的

• 让计算机帮助您在编写的程序中查找逻辑错误。诸如静态类型系统或源代码分析器之类的东西（我听说Eric Lippert目前正在使用一种相当流行的工具）可以帮助实现这一点。

• 具有能够有效地通过编译器处理的语言和它通信的意图程序员的其他程序员，使工作程序更加容易。荒谬的极端是，想象用简单的英语编写程序是可能的。资深的程序员可能更容易想象发生了什么，但是仍然很难将描述编译为机器讲师，并且这是模棱两可的。因此，您需要一种编译器可以理解但也可以理解的语言。

鉴于许多（大多数？）编译器仍然是通用的，因此它们具有非常通用的指令集。没有“绘制按钮”指令或“播放这部电影”。因此，向下移动抽象层次结构会使您最终获得难以理解和维护的程序（尽管编译起来很琐碎）。唯一的选择是向上移动层次结构，从而导致越来越多的抽象语言和库。

“如果年长的程序员将像这样的创新视为天赐之物或抽象的附加层，他们为什么会这样呢？”

我从高中开始就从事编程工作，大约有34年的时间，从Basic和Z80汇编程序开始，逐渐发展为C，各种4GL语言，Scheme，SQL，以及现在的各种Web语言。该行业解决的问题的范围，规模和深度在那个时期经历了通货膨胀时期，尤其是在1990年代。库，框架和OS服务等构造都是为了解决复杂性以及问题扩展空间而设计的。它们既不是天赐之物，也不是它们本身的负担，而只是对巨大解决方案空间的不断探索。

但是，恕我直言，“创新”可以通过新颖的形式得到更好的理解，而不会误认为是横向运动-重新引入我们已经看到的引入形式。在某些方面，当原始形式不组成，固定原始演化过程中的决策或无法重新处理自己的碎屑时，生态系统的繁殖力就会受到损害。我们仍然关注的一些（如果不是大多数的话）构架没有将长期维持价值作为优先考虑的问题。这已经开始发生变化-例如服务导向和域驱动设计之类的方法，更不用说基于超文本和基于图形的模型，正在改变格局。像任何生态系统一样，最终占主导地位的形式将让位给新形式。允许多样性是我们最好的服务，

“在探索扩展库领域之前，年轻的程序员在学习低级编程方面是否会从中受益？如果是，那为什么呢？”

我会说大多数人类语言早就被遗忘了，所以它是基于隐喻的，因此，尽管我会支持从科学/数字素养的角度学习低级编程，但更重要的是我们寻求能够支持隐喻规模和范围的原语。我们正在解决的问题可以安全地忽略较低层次的细节。框架不是原始的，也不是OS或库，它们在执行我们真正需要的抽象方面相当差劲。真正的进步将使人们（a）知道以前发生的事情，（b）可以以足够新颖的方式思考，以提出足够不同的东西来探索以前从未探索过，或者已经被探索和遗忘的解决方案空间。

OTOH，即使您的目标是成为技术人员/机械手，也可以通过某种程度的低级编程来提高自己的解决问题能力。

我的第一个程序（作为15岁的少年）是1974年在PL / 1上用IBM 370/168大型机的打孔卡制作的。我父亲在IBM工作，我很幸运能够在周日去数据中心。

那时，具有数千个语句（即打孔卡）的程序是一个大程序（也是沉重的程序，因为成千上万个打孔卡重达数公斤）。视觉界面不存在（使用//GO.SYSIN DD *IIRC 开头的打孔卡命令从“标准输入”中读取典型程序，但我不掌握JCL）。算法学很重要，按照今天的标准，IIRC标准库很小。

今天，通常认为数千行的程序很小。例如，GCC编译器具有超过一千万行的源代码，没有人完全理解它们。

我的感觉是，当今的编程与1970年代大不相同，因为您需要使用更多的资源（尤其是现有的库和软件框架）。但是，我想开发数据中心软件（例如Google的搜索引擎）或某些嵌入式软件的人们比1970年代普通程序员更关心算法和效率。

我仍然认为即使在今天，理解底层编程也很重要（即使大多数程序员不会自己编写基本的容器算法，例如平衡树，二元访问的排序数组等），因为了解整个情况仍然很重要。

1970年代与今天之间的主要区别是开发人员（人类）的努力与计算机能力之间的成本比。