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

#1 楼

没必要，因为处理能力和可用内存的增加。


拥有便宜的内存，巨大的磁盘和快速的处理器并不是唯一的选择使人们摆脱了对每个字节和每个周期的困扰。如今，编译器在产生重要的优化代码方面远胜于人类。

此外，让我们不要忘记我们实际上要优化的东西，这是在给定成本下产生的价值。程序员比机器贵得多。我们所做的一切都会使程序员更快，更便宜地生成工作，正确，健壮，功能齐全的程序，从而在世界上创造更多的价值。


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


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

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


您认为年轻的程序员会在探索扩展库领域之前能从中受益，从而进一步学习底层编程？


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

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

#2 楼

我对这个主题有想法，二十年前就把它们写进了一本书。
已经绝版了，但是您仍然可以在Amazon上获得二手的副本。

一个简单的答案您的问题就像亚里斯多德一样古老：自然不喜欢真空。
随着机器变得越来越快，体积越来越大，软件变得越来越慢，体积越来越大。

为了更具建设性，我提出了什么信息论及其与软件的直接关系才是计算机科学教育的一部分。
现在，如果有的话，它只能以非常切线的方式进行教授。

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

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

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

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

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

要终止一篇冗长的文章，我开发了一种编程风格（有时会给我带来麻烦），其中


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

#3 楼

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

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

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

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

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

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

但是，当有必要时，您仍然可以打帐篷这样做，在编程中，您仍然可以（如果您很愿意）下降到更接近硬件的水平，以获得性能或内存方面的好处，而这些好处是您可能无法使用高级语言实现的。


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

#4 楼

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

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

从高层次看：一般概念，例如使用关联数组，闭包等，而不必浪费时间担心它在引擎盖下的工作方式。

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

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


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

#5 楼

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

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

#6 楼

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

我已经进行了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结尾，因为社区就是在那里。

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

#7 楼

但是，我的问题是人们对这种“隐藏”底层元素的感觉如何。您是老一辈的程序员，是将其视为天赐之物还是不必要的层吗？


两者都不是。

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

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


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


如其他答案中所指出的那样，在吸引人之间有一个平衡点并保持新手的注意力，并为他们提供从下而上的理想教育。如果您不能做前者，那么后者就不会发生。

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

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

#8 楼

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

在这里
或在这里进行了恰当的描述-“只需一行代码，您就可以将500个用户添加到域中” ...

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

#9 楼

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


我不这样认为。在很多情况下，需要注意“下一层”的工作量较低，例如


，当调试第n层上的问题时，通常可以通过考虑进行解释在n-1层（即下面的层）上会发生什么。我猜第0层将是“晶体管”，但是如果您要解释晶体管的问题，您可能会谈论物理（例如，热量），因此物理可能实际上是第0级。
优化代码时（不幸的是）有时会帮助降低抽象级别，即在较低级别的层上实现算法。但是，如果编译器实际上看到了所有涉及的代码，它们就会真正为您做到这一点。最近，随着移动和嵌入式设备的兴起，这个原因变得越来越流行，这些设备往往具有较弱的处理器，并且“每瓦性能”比台式机更重要。

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

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


让计算机帮助您在编写的程序中查找逻辑错误。诸如静态类型系统或源代码分析器之类的东西（我听说Eric Lippert如今正在相当流行的一种）可以帮助实现这一目标。
拥有一种可以由编译器有效处理并传达程序员意图的语言。其他程序员可以简化程序的工作。荒谬的极端是，想象用简单的英语编写程序是可能的。资深的程序员可能更容易想象发生了什么，但是仍然很难将描述编译为机器讲师，并且这是模棱两可的。因此，您需要一种编译器可以理解但也可以理解的语言。

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

#10 楼

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

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

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

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

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

OTOH，即使您的目标是作为技术人员/机械手工作，但一定程度的底层编程经验仍将对发展您的问题解决能力有所帮助。

#11 楼

我的第一个程序（作为15岁的少年）是1974年在PL / 1上用IBM 370/168大型机的打孔卡制作的。我父亲在IBM工作，我很幸运能够在周日去数据中心。
那时，包含数千条语句（即打孔卡）的程序是一个很大的程序（而沉重的也是如此，因为成千上万张打孔卡重达几公斤。视觉界面不存在（使用从//GO.SYSIN DD * IIRC开头的打孔卡命令从其“标准输入”读取的典型程序，但我不掌握JCL）。
算法很重要，IIRC标准库很小按照今天的标准。
如今，通常认为数千行的程序很小。例如，GCC编译器具有超过一千万行的源代码，没有人能完全理解它们。
我的感觉是，当今的编程与1970年代大不相同，因为您需要使用更多的资源（特别是现有的库和软件框架）。但是，我想开发数据中心软件（例如Google的搜索引擎）或某些嵌入式软件的人们比1970年代普通程序员更关心算法和效率。
我仍然认为理解底层编程很重要。即使在今天（即使大多数程序员都不会自己编写基本的容器算法，例如平衡树，二元访问的排序数组等），因为了解整个情况仍然很重要。
1970年代与今天的主要区别是开发人员（人类）的努力与计算机能力之间的成本比率。